From: Sean Anderson <seanga2@gmail.com>
To: Simon Glass <sjg@chromium.org>
Cc: Peng Fan <peng.fan@nxp.com>,
"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
"lukma@denx.de" <lukma@denx.de>,
"trini@konsulko.com" <trini@konsulko.com>,
"u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: Re: [PATCH] clk: introduce u-boot,ignore-clk-defaults
Date: Mon, 25 Oct 2021 21:59:48 -0400 [thread overview]
Message-ID: <57a7e4eb-4c81-d15e-3211-6f35fc2ee19e@gmail.com> (raw)
In-Reply-To: <126ed56e-58c2-e80c-95d9-17874ca254c3@gmail.com>
On 10/25/21 9:23 PM, Sean Anderson wrote:
> On 10/25/21 11:18 AM, Simon Glass wrote:
>> Hi Sean,
>>
>> On Sun, 24 Oct 2021 at 18:13, Sean Anderson <seanga2@gmail.com> wrote:
>>>
>>> On 10/14/21 10:19 PM, Simon Glass wrote:
>>>> Hi Peng, Sean,
>>>>
>>>> On Thu, 14 Oct 2021 at 19:17, Peng Fan <peng.fan@nxp.com> wrote:
>>>>>
>>>>>> Subject: Re: [PATCH] clk: introduce u-boot,ignore-clk-defaults
>>>>>>
>>>>>>
>>>>>> On 10/13/21 5:37 AM, Peng Fan (OSS) wrote:
>>>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>>>
>>>>>>> Current code has a force clk_set_defaults in multiple stages, U-Boot
>>>>>>> reuse the same device tree and Linux Kernel device tree, but we not
>>>>>>> register all the clks as Linux Kernel, so clk_set_defaults will fail
>>>>>>> and cause the clk provider registeration fail.
>>>>>>>
>>>>>>> So introduce a new property to ignore the default settings which could
>>>>>>> be used by any node that wanna ignore default settings.
>>>>>>>
>>>>>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>>>>>> ---
>>>>>>> doc/device-tree-bindings/device.txt | 3 +++
>>>>>>> drivers/clk/clk-uclass.c | 3 +++
>>>>>>> 2 files changed, 6 insertions(+)
>>>>>>>
>>>>>>> diff --git a/doc/device-tree-bindings/device.txt
>>>>>>> b/doc/device-tree-bindings/device.txt
>>>>>>> index 73ce2a3b5b..fe34ced268 100644
>>>>>>> --- a/doc/device-tree-bindings/device.txt
>>>>>>> +++ b/doc/device-tree-bindings/device.txt
>>>>>>> @@ -28,6 +28,9 @@ the acpi,compatible property.
>>>>>>> Linux will only load the driver if the device can be detected (e.g. on
>>>>>> I2C
>>>>>>> bus). Note that this is an out-of-tree Linux feature.
>>>>>>>
>>>>>>> +Common device bindings that could be shared listed below:
>>>>>>> + - u-boot,ignore-clk-defaults : ignore the assigned-clock-parents
>>>>>>> + and assigned-clock-rates for a device that has the property.
>>>>>>>
>>>>>>> Example
>>>>>>> -------
>>>>>>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index
>>>>>>> 493018b33e..6bf3179e7b 100644
>>>>>>> --- a/drivers/clk/clk-uclass.c
>>>>>>> +++ b/drivers/clk/clk-uclass.c
>>>>>>> @@ -376,6 +376,9 @@ int clk_set_defaults(struct udevice *dev, enum
>>>>>> clk_defaults_stage stage)
>>>>>>> if (!dev_has_ofnode(dev))
>>>>>>> return 0;
>>>>>>>
>>>>>>> + if (ofnode_get_property(dev_ofnode(dev), "u-boot,ignore-clk-defaults",
>>>>>> NULL))
>>>>>>> + return 0;
>>>>>>> +
>>>>>>> /*
>>>>>>> * To avoid setting defaults twice, don't set them before relocation.
>>>>>>> * However, still set them for SPL. And still set them if
>>>>>>> explicitly
>>>>>>>
>>>>>>
>>>>>> Why not just have the property ignore errors?
>>>>>
>>>>> I think the force err return was done by Simon?
>>>>>
>>>>>>
>>>>>> In the long term, it may be better to standardize that e.g. ENOENT means that
>>>>>> the clock doesn't exist. That way we can skip setting the defaults.
>>>>>> ENOSYS should probably be treated the same way (warn, but don't fail).
>>>>>
>>>>> I am not sure whether people expect force error for ENOENT/ENOSYS in U-Boot.
>>>>> For i.MX, I not expect force error.
>>>>
>>>> Yes that is me, indeed. It's just that we should not silently ignore
>>>> errors. If we know the clock is optional, then the driver that knows
>>>> that can handle it. But if we start having things quietly fail,
>>>> debugging becomes a pain.
>>>
>>> Can't we have them loudly fail instead?
>>>
>>
>> That is how it works today, as I understand it. But some boards want
>> the defaults to be there but not to implement them in U-Boot. This
>> seems fair enough to me. Perhaps we could add something to each node
>> instead, to disable it?
>
> u-boot,assigned-clock-status = "disabled";
Actually, I think that was Peng's idea in the first place :)
--Sean
prev parent reply other threads:[~2021-10-26 2:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 9:37 [PATCH] clk: introduce u-boot,ignore-clk-defaults Peng Fan (OSS)
2021-10-14 15:11 ` Simon Glass
2021-10-14 15:14 ` Tom Rini
2021-10-15 8:58 ` Peng Fan (OSS)
2021-10-24 19:53 ` Simon Glass
2021-10-15 1:10 ` Sean Anderson
2021-10-15 1:17 ` Peng Fan
2021-10-15 2:19 ` Simon Glass
2021-10-25 0:13 ` Sean Anderson
2021-10-25 15:18 ` Simon Glass
2021-10-26 1:23 ` Sean Anderson
2021-10-26 1:59 ` Sean Anderson [this message]
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=57a7e4eb-4c81-d15e-3211-6f35fc2ee19e@gmail.com \
--to=seanga2@gmail.com \
--cc=lukma@denx.de \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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