mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	devicetree@vger.kernel.org, linux-clk@vger.kernel.org
Cc: Conor Dooley <conor+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Rob Herring <robh+dt@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: clock: Add nvmem-clock
Date: Mon, 5 Jun 2023 13:56:24 +0200	[thread overview]
Message-ID: <27baa521-4350-23a6-0e2c-470ecf9bb306@topic.nl> (raw)
In-Reply-To: <578088ff-9feb-3d03-f12e-577f105144f5@linaro.org>

On 05-06-2023 12:13, Krzysztof Kozlowski wrote:
> On 05/06/2023 12:01, Mike Looijmans wrote:
>> On 31-05-2023 21:27, Krzysztof Kozlowski wrote:
>>> On 26/05/2023 16:38, Mike Looijmans wrote:
>>>> Add bindings for a fixed-rate clock that retrieves its rate from an
>>>> NVMEM provider. This allows to store clock settings in EEPROM or EFUSE
>>>> or similar device.
>>>>
>>>> Component shortages lead to boards being shipped with different clock
>>>> crystals, based on what was available at the time. The clock frequency
>>>> was written to EEPROM at production time. Systems can adapt to a wide
>>>> range of input frequencies using the clock framework, but this required
>>>> us to patch the devicetree at runtime or use some custom driver. This
>>>> provides a more generic solution.
>>> This does not look like real hardware. I mean, the clock does not fetch
>>> its rate from nvmem, right? It's the Linux which does it, so basically
>>> you described here driver, not hardware.
>> Right, this just reads a setting from an NVMEM provider.
>>> Extend existing fixed-clock bindings to allow reading frequency via
>>> nvmem cells.
>> I just tried and implemented this, but it does not work. The reason is
>> that the fixed-clock implementation returns "void" in its
>> of_fixed_clk_setup() init function. The nvmem provider returns
>> EPROBE_DEFER because it isn't ready at this early stage, and this error
>> will not be propagated up because of the "void" signature. Thus, it's
>> never retried and the clock just disappears.
> Linux driver problems are not a reason to add bindings for virtual
> hardware...
>
Okay, so what are you proposing?

The implementation needs a compatible string other than "fixed-clock", 
because of the way the fixed-clock driver is being loaded (it can never 
be deferred).

So I should add another compatible string to fixed-clock.yaml? That'd 
make the syntax in fixed-clock.yaml rather awkward, since some 
properties would only apply to some compatible strings?

-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl




      reply	other threads:[~2023-06-05 11:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.2167d5ad-7e99-4eb9-a313-030fc7a7d546@emailsignatures365.codetwo.com>
2023-05-26 14:38 ` Mike Looijmans
     [not found]   ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.c94258f7-321c-4603-be80-fc92c2c311e9@emailsignatures365.codetwo.com>
2023-05-26 14:38     ` [PATCH v2 2/2] clk: Add nvmem-clock provider Mike Looijmans
2023-05-26 18:47   ` [PATCH v2 1/2] dt-bindings: clock: Add nvmem-clock Conor Dooley
2023-06-02 13:19   ` Krzysztof Kozlowski
     [not found]   ` <c6d886d9-8f74-7af3-5478-030f5d6e4b1c@linaro.org>
2023-06-05 10:01     ` Mike Looijmans
2023-06-05 10:13       ` Krzysztof Kozlowski
2023-06-05 11:56         ` Mike Looijmans [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=27baa521-4350-23a6-0e2c-470ecf9bb306@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@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®