On 05/06/2023 12:01, Mike Looijmans wrote:Okay, so what are you proposing?
On 31-05-2023 21:27, Krzysztof Kozlowski wrote:Linux driver problems are not a reason to add bindings for virtual
On 26/05/2023 16:38, Mike Looijmans wrote:Right, this just reads a setting from an NVMEM provider.
Add bindings for a fixed-rate clock that retrieves its rate from anThis does not look like real hardware. I mean, the clock does not fetch
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.
its rate from nvmem, right? It's the Linux which does it, so basically
you described here driver, not hardware.
Extend existing fixed-clock bindings to allow reading frequency viaI just tried and implemented this, but it does not work. The reason is
nvmem cells.
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.
hardware...