| Message ID | 1485946422-2066-1-git-send-email-jjhiblot@ti.com |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
On Wed, Feb 01, 2017 at 11:53:42AM +0100, Jean-Jacques Hiblot wrote: > Add qspi control module register maps to device tree. This register map had > been removed by error when syncing the DTS with the latest linux at the > time (commit 7aa1a4087 "ARM: dts: dra7xx: sync DT with latest Linux"). > Without this entry the driver do not support memory-mapped access and the > data read from the SF is invalid. > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Why is this not in the upstream DTS file?
On 03/02/2017 17:52, Tom Rini wrote: > On Wed, Feb 01, 2017 at 11:53:42AM +0100, Jean-Jacques Hiblot wrote: > >> Add qspi control module register maps to device tree. This register map had >> been removed by error when syncing the DTS with the latest linux at the >> time (commit 7aa1a4087 "ARM: dts: dra7xx: sync DT with latest Linux"). >> Without this entry the driver do not support memory-mapped access and the >> data read from the SF is invalid. >> >> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> > Why is this not in the upstream DTS file? In Linux, a syscon/regmap is used to map this register while the QSPI driver in u-boot uses a direct memory access.
On Mon, Feb 06, 2017 at 12:09:12PM +0100, Jean-Jacques Hiblot wrote: > > > On 03/02/2017 17:52, Tom Rini wrote: > >On Wed, Feb 01, 2017 at 11:53:42AM +0100, Jean-Jacques Hiblot wrote: > > > >>Add qspi control module register maps to device tree. This register map had > >>been removed by error when syncing the DTS with the latest linux at the > >>time (commit 7aa1a4087 "ARM: dts: dra7xx: sync DT with latest Linux"). > >>Without this entry the driver do not support memory-mapped access and the > >>data read from the SF is invalid. > >> > >>Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> > >Why is this not in the upstream DTS file? > In Linux, a syscon/regmap is used to map this register while the > QSPI driver in u-boot uses a direct memory access. OK, but it's a valid part of the upstream kernel binding, yes?
On 06/02/2017 13:47, Tom Rini wrote: > On Mon, Feb 06, 2017 at 12:09:12PM +0100, Jean-Jacques Hiblot wrote: >> >> On 03/02/2017 17:52, Tom Rini wrote: >>> On Wed, Feb 01, 2017 at 11:53:42AM +0100, Jean-Jacques Hiblot wrote: >>> >>>> Add qspi control module register maps to device tree. This register map had >>>> been removed by error when syncing the DTS with the latest linux at the >>>> time (commit 7aa1a4087 "ARM: dts: dra7xx: sync DT with latest Linux"). >>>> Without this entry the driver do not support memory-mapped access and the >>>> data read from the SF is invalid. >>>> >>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> >>> Why is this not in the upstream DTS file? >> In Linux, a syscon/regmap is used to map this register while the >> QSPI driver in u-boot uses a direct memory access. > OK, but it's a valid part of the upstream kernel binding, yes? syscon-chipselects is part of the mainlined binding. Using a 3rd memory range used to be the way to do it, but it is not supported anymore (I think it has been removed removed in 4.6). Using a third memory range has been supported in u-boot for some time now. So you think we should move to using the syscon ?
On Mon, Feb 06, 2017 at 02:27:42PM +0100, Jean-Jacques Hiblot wrote: > > > On 06/02/2017 13:47, Tom Rini wrote: > >On Mon, Feb 06, 2017 at 12:09:12PM +0100, Jean-Jacques Hiblot wrote: > >> > >>On 03/02/2017 17:52, Tom Rini wrote: > >>>On Wed, Feb 01, 2017 at 11:53:42AM +0100, Jean-Jacques Hiblot wrote: > >>> > >>>>Add qspi control module register maps to device tree. This register map had > >>>>been removed by error when syncing the DTS with the latest linux at the > >>>>time (commit 7aa1a4087 "ARM: dts: dra7xx: sync DT with latest Linux"). > >>>>Without this entry the driver do not support memory-mapped access and the > >>>>data read from the SF is invalid. > >>>> > >>>>Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> > >>>Why is this not in the upstream DTS file? > >>In Linux, a syscon/regmap is used to map this register while the > >>QSPI driver in u-boot uses a direct memory access. > >OK, but it's a valid part of the upstream kernel binding, yes? > syscon-chipselects is part of the mainlined binding. Using a 3rd > memory range used to be the way to do it, but it is not supported > anymore (I think it has been removed removed in 4.6). > Using a third memory range has been supported in u-boot for some time now. > So you think we should move to using the syscon ? Based on what I see in v4.10-rc7, yes, we should adapt the driver to know about the new property and things are working as expected wrt DT compatibility.
On 06/02/2017 14:37, Tom Rini wrote: > On Mon, Feb 06, 2017 at 02:27:42PM +0100, Jean-Jacques Hiblot wrote: >> >> On 06/02/2017 13:47, Tom Rini wrote: >>> On Mon, Feb 06, 2017 at 12:09:12PM +0100, Jean-Jacques Hiblot wrote: >>>> On 03/02/2017 17:52, Tom Rini wrote: >>>>> On Wed, Feb 01, 2017 at 11:53:42AM +0100, Jean-Jacques Hiblot wrote: >>>>> >>>>>> Add qspi control module register maps to device tree. This register map had >>>>>> been removed by error when syncing the DTS with the latest linux at the >>>>>> time (commit 7aa1a4087 "ARM: dts: dra7xx: sync DT with latest Linux"). >>>>>> Without this entry the driver do not support memory-mapped access and the >>>>>> data read from the SF is invalid. >>>>>> >>>>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> >>>>> Why is this not in the upstream DTS file? >>>> In Linux, a syscon/regmap is used to map this register while the >>>> QSPI driver in u-boot uses a direct memory access. >>> OK, but it's a valid part of the upstream kernel binding, yes? >> syscon-chipselects is part of the mainlined binding. Using a 3rd >> memory range used to be the way to do it, but it is not supported >> anymore (I think it has been removed removed in 4.6). >> Using a third memory range has been supported in u-boot for some time now. >> So you think we should move to using the syscon ? > Based on what I see in v4.10-rc7, yes, we should adapt the driver to > know about the new property and things are working as expected wrt DT > compatibility. Ok. I have prepared a new series to do this >
diff --git a/arch/arm/dts/dra7.dtsi b/arch/arm/dts/dra7.dtsi index 5570e30..46febc5 100644 --- a/arch/arm/dts/dra7.dtsi +++ b/arch/arm/dts/dra7.dtsi @@ -1302,9 +1302,10 @@ qspi: qspi@4b300000 { compatible = "ti,dra7xxx-qspi"; reg = <0x4b300000 0x100>, - <0x5c000000 0x4000000>; - reg-names = "qspi_base", "qspi_mmap"; - syscon-chipselects = <&scm_conf 0x558>; + <0x5c000000 0x4000000>, + <0x4a002558 0x4>; + reg-names = "qspi_base", "qspi_mmap", + "qspi_ctrlmod"; #address-cells = <1>; #size-cells = <0>; ti,hwmods = "qspi";
Add qspi control module register maps to device tree. This register map had been removed by error when syncing the DTS with the latest linux at the time (commit 7aa1a4087 "ARM: dts: dra7xx: sync DT with latest Linux"). Without this entry the driver do not support memory-mapped access and the data read from the SF is invalid. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> --- arch/arm/dts/dra7.dtsi | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)