lkml.org 
[lkml]   [2020]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] clk-si5341: Support NVM programming through sysfs
From
Date
Quoting Mike Looijmans (2020-11-05 01:06:54)
> On 05-11-2020 02:48, Stephen Boyd wrote:
> > Quoting Mike Looijmans (2020-11-03 06:17:41)
> >> Export an attribute program_nvm_bank that when read reports the current
> >> bank value. To program the chip's current state into NVM, write the
> >> magic value 0xC7 into this attribute.
> >>
> >> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
> >> ---
> >
> > Any chance this can be done through the nvmem framework?
>
> This part doesn't fit. The purpose is to store the current state of the clock
> chip into its non-volatile storage so it boots up with that configuration the
> next POR. Main use case is that some vendors initialize PLLs only in a
> bootloader and thus need the clock running at boot. Or it might just be to
> save on that 300ms initialization time.

Can these details be put in the commit text? It would go a long way
towards helping reviewers understand the motivation if it is to speed up
boot and stash away clk configuration across resets. Why is userspace
involved? Why can't the driver write to the non-volatile storage with
shutdown or reboot driver hooks instead of implementing a bespoke sysfs
ABI?

>
> Having said that, the clock chip does have some "scratch" areas that'd be
> useful as NVMEM storage. That'd be for a separate patch.
>
> For this device to be NVMEM compatible, nvmem would need to have a sort of
> transaction model, where you write several values and then "commit" them all
> to NVM in one call. The nvmem framework wasn't intended for that I think.

I suppose patches could be written to support that if desired.

\
 
 \ /
  Last update: 2020-11-13 09:03    [W:0.055 / U:1.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site