public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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


      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