From: Sekhar Nori <nsekhar@ti.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>,
David Lechner <david@lechnology.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Kevin Hilman <khilman@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Russell King <linux@armlinux.org.uk>,
arm-soc <linux-arm-kernel@lists.infradead.org>,
linux-devicetree <devicetree@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: dts: da850-evm: add clock properties to the nand node
Date: Wed, 7 Feb 2018 18:36:30 +0530 [thread overview]
Message-ID: <37e034fe-5951-9a58-8698-d34226e8279e@ti.com> (raw)
In-Reply-To: <CAMRc=Mcf0aEQvieNaZ3cMHJTE23Gf1jUNf0=vuO9-PA=9ObDvQ@mail.gmail.com>
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
next prev parent reply other threads:[~2018-02-07 13:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 15:52 Bartosz Golaszewski
2018-02-06 11:07 ` Sekhar Nori
2018-02-06 13:08 ` Bartosz Golaszewski
2018-02-06 13:51 ` Sekhar Nori
[not found] ` <794024f3-f87a-58ed-2722-a4a2d09df3ce@lechnology.com>
2018-02-06 18:25 ` David Lechner
2018-02-06 18:45 ` Bartosz Golaszewski
2018-02-07 13:06 ` Sekhar Nori [this message]
2018-02-11 5:06 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37e034fe-5951-9a58-8698-d34226e8279e@ti.com \
--to=nsekhar@ti.com \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=david@lechnology.com \
--cc=devicetree@vger.kernel.org \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®