Re: [PATCH v2 0/3] Add support for LTC2688

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 16, 2022 at 7:28 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
>
>
> >   * Have a clock property per channel. Note that we this I moved to OF
> > since we now have to use 'devm_get_clk_from_child()' which is using
> > device_node. Note that I could use 'to_of_node()' but mixing of.h and
> > property.h does not feel like a good idea.
>
> Ah, that's unfortunate given the clk is only needed in certain modes...
>
> Andy/Rafael/Rob, any thoughts on how we should handle this?  Obviously
> ACPI and clocks is generally a no go, but in this particular case we
> aren't looking at a power management related use of clocks, but rather
> using the clk framework to provide a way to control one of our inputs
> used to generate the output dithered signal...  If the device just its
> own clock then we'd just control it directly with no problems, but it uses
> and external source.
>
> We don't know of anyone actually looking at this device in conjunction with
> ACPI so maybe just using dt specific calls for now rather than generic
> firmware properties is the best we can do.

The problem is the CCF is so OF-centric and maintainer(s) seems
skeptical about switching it to use fwnode APIs (they wanted, last
time I tried, to show how exactly it will be used, so here is your
chance!), but OTOH switching to fwnode API is a half made road,
because for ACPI we might need a glue layer which may be way too
tricky to be considered as a part of this series.

-- 
With Best Regards,
Andy Shevchenko



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux