2018-02-06 19:25 GMT+01:00 David Lechner <david@xxxxxxxxxxxxxx>:
> 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@xxxxxx>:
>>>>>
>>>>> On Monday 05 February 2018 09:22 PM, Bartosz Golaszewski wrote:
>>>>>>
>>>>>> From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
>>>>>>
>>>>>> 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@xxxxxxxxxxxx>
>>>>>> ---
>>>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
