| Message ID | 4aa2ab13-7890-6904-86b3-e2dbcb6d6daa@lechnology.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2018-02-06 19:25 GMT+01:00 David Lechner <david@lechnology.com>: > On 02/06/2018 12:16 PM, David Lechner wrote: >> >> On 02/06/2018 07:51 AM, Sekhar Nori wrote: >>> >>> On Tuesday 06 February 2018 06:38 PM, Bartosz Golaszewski wrote: >>>> >>>> 2018-02-06 12:07 GMT+01:00 Sekhar Nori <nsekhar@ti.com>: >>>>> >>>>> On Monday 05 February 2018 09:22 PM, Bartosz Golaszewski wrote: >>>>>> >>>>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >>>>>> >>>>>> Make nand work with the common clock framework by specifying which >>>>>> clock should be used and what name to look up. >>>>>> >>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> >>>>>> --- >>>>>> arch/arm/boot/dts/da850-evm.dts | 3 +++ >>>>>> 1 file changed, 3 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/da850-evm.dts >>>>>> b/arch/arm/boot/dts/da850-evm.dts >>>>>> index a86a8a1816f2..2602ad8e99ee 100644 >>>>>> --- a/arch/arm/boot/dts/da850-evm.dts >>>>>> +++ b/arch/arm/boot/dts/da850-evm.dts >>>>>> @@ -296,6 +296,9 @@ >>>>>> reg = <0 0x02000000 0x02000000 >>>>>> 1 0x00000000 0x00008000>; >>>>>> >>>>>> + clocks = <&psc0 3>; >>>>>> + clock-names = "aemif"; >>>>> >>>>> >>>>> Looks like this is being added only to satisfy the devm_clk_get() call >>>>> in nand_davinci_probe() which I think is superfluous since we also >>>>> enable the same clock in aemif_probe(). >>>>> >>>>> Perhaps the better solution is to drip the clk code in >>>>> drivers/mtd/nand/davinci_nand.c and shift legacy code to start using >>>>> drivers/memory/aemif.c as well? This way we can also drop >>>>> arch/arm/mach-davinci/aemif.c >>>>> >>>>> Thanks, >>>>> Sekhar >>>> >>>> >>>> Yes, this sounds good, but I think we should leave it for later as an >>>> additional improvement, once everything else is in place. I think >>>> these patches should be applied together with David's series in order >>>> to not break the support on davinci boards and the aemif work would go >>>> in later as a follow-up. How about that? >>> >>> >>> No, I dont think we should add temporary hacks to DT to work around >>> driver issues (I do think its a hack since the clock belongs to aemif >>> module not NAND flash). >>> >>> An easier driver hack might be to not treat devm_clk_get() failure in >>> davinci_nand.c as catastrophic. It will safely fail in DT case and we >>> should get the clock in legacy boot case. >>> >>> I think we are looking at a driver update dependency anyway. >> >> >> It looks like keystone.dtsi is using the clock-ranges property in the >> aemif node to pass the clock to child nodes. Could we not do the same >> in da850.dtsi? > > > Bartosz, please try this instead of your patch. > > FYI, this is just following the existing memory-controllers/ti-aemif.txt > device tree bindings, so not a "hack". > > --- > diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi > index 3a1f2ce..ff9d807 100644 > --- a/arch/arm/boot/dts/da850.dtsi > +++ b/arch/arm/boot/dts/da850.dtsi > @@ -796,6 +796,8 @@ > ranges = <0 0 0x60000000 0x08000000 > 1 0 0x68000000 0x00008000>; > clocks = <&psc0 3>; > + clock-names = "aemif"; > + clock-ranges; > status = "disabled"; > }; > memctrl: memory-controller@b0000000 { > --- Yes, this works. Sekhar: can we include it in David's series, while still keeping the plan to move legacy boards to using the aemif driver? Best regards, Bartosz
On Wednesday 07 February 2018 12:15 AM, Bartosz Golaszewski wrote: > 2018-02-06 19:25 GMT+01:00 David Lechner <david@lechnology.com>: >> On 02/06/2018 12:16 PM, David Lechner wrote: >>> >>> On 02/06/2018 07:51 AM, Sekhar Nori wrote: >>>> >>>> On Tuesday 06 February 2018 06:38 PM, Bartosz Golaszewski wrote: >>>>> >>>>> 2018-02-06 12:07 GMT+01:00 Sekhar Nori <nsekhar@ti.com>: >>>>>> >>>>>> On Monday 05 February 2018 09:22 PM, Bartosz Golaszewski wrote: >>>>>>> >>>>>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >>>>>>> >>>>>>> Make nand work with the common clock framework by specifying which >>>>>>> clock should be used and what name to look up. >>>>>>> >>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> >>>>>>> --- >>>>>>> arch/arm/boot/dts/da850-evm.dts | 3 +++ >>>>>>> 1 file changed, 3 insertions(+) >>>>>>> >>>>>>> diff --git a/arch/arm/boot/dts/da850-evm.dts >>>>>>> b/arch/arm/boot/dts/da850-evm.dts >>>>>>> index a86a8a1816f2..2602ad8e99ee 100644 >>>>>>> --- a/arch/arm/boot/dts/da850-evm.dts >>>>>>> +++ b/arch/arm/boot/dts/da850-evm.dts >>>>>>> @@ -296,6 +296,9 @@ >>>>>>> reg = <0 0x02000000 0x02000000 >>>>>>> 1 0x00000000 0x00008000>; >>>>>>> >>>>>>> + clocks = <&psc0 3>; >>>>>>> + clock-names = "aemif"; >>>>>> >>>>>> >>>>>> Looks like this is being added only to satisfy the devm_clk_get() call >>>>>> in nand_davinci_probe() which I think is superfluous since we also >>>>>> enable the same clock in aemif_probe(). >>>>>> >>>>>> Perhaps the better solution is to drip the clk code in >>>>>> drivers/mtd/nand/davinci_nand.c and shift legacy code to start using >>>>>> drivers/memory/aemif.c as well? This way we can also drop >>>>>> arch/arm/mach-davinci/aemif.c >>>>>> >>>>>> Thanks, >>>>>> Sekhar >>>>> >>>>> >>>>> Yes, this sounds good, but I think we should leave it for later as an >>>>> additional improvement, once everything else is in place. I think >>>>> these patches should be applied together with David's series in order >>>>> to not break the support on davinci boards and the aemif work would go >>>>> in later as a follow-up. How about that? >>>> >>>> >>>> No, I dont think we should add temporary hacks to DT to work around >>>> driver issues (I do think its a hack since the clock belongs to aemif >>>> module not NAND flash). >>>> >>>> An easier driver hack might be to not treat devm_clk_get() failure in >>>> davinci_nand.c as catastrophic. It will safely fail in DT case and we >>>> should get the clock in legacy boot case. >>>> >>>> I think we are looking at a driver update dependency anyway. >>> >>> >>> It looks like keystone.dtsi is using the clock-ranges property in the >>> aemif node to pass the clock to child nodes. Could we not do the same >>> in da850.dtsi? >> >> >> Bartosz, please try this instead of your patch. >> >> FYI, this is just following the existing memory-controllers/ti-aemif.txt >> device tree bindings, so not a "hack". >> >> --- >> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi >> index 3a1f2ce..ff9d807 100644 >> --- a/arch/arm/boot/dts/da850.dtsi >> +++ b/arch/arm/boot/dts/da850.dtsi >> @@ -796,6 +796,8 @@ >> ranges = <0 0 0x60000000 0x08000000 >> 1 0 0x68000000 0x00008000>; >> clocks = <&psc0 3>; >> + clock-names = "aemif"; >> + clock-ranges; >> status = "disabled"; >> }; >> memctrl: memory-controller@b0000000 { >> --- > > Yes, this works. Sekhar: can we include it in David's series, while > still keeping the plan to move legacy boards to using the aemif > driver? Okay. Fine with me. Actually the chipselect node already has clock-ranges defined, but that doesn't have any meaning unless its also included in aemif node. Thanks, Sekhar
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi index 3a1f2ce..ff9d807 100644 --- a/arch/arm/boot/dts/da850.dtsi +++ b/arch/arm/boot/dts/da850.dtsi @@ -796,6 +796,8 @@ ranges = <0 0 0x60000000 0x08000000 1 0 0x68000000 0x00008000>; clocks = <&psc0 3>; + clock-names = "aemif"; + clock-ranges; status = "disabled"; }; memctrl: memory-controller@b0000000 {