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.
Best regards,
Krzysztof
--
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@xxxxxxxx
W: www.topic.nl
