On Fri, Feb 4, 2022 at 8:44 PM Sean Anderson <sean.anderson@xxxxxxxx> wrote: > On 2/4/22 1:38 PM, Andy Shevchenko wrote: > > On Fri, Feb 4, 2022 at 6:00 PM Sean Anderson <sean.anderson@xxxxxxxx> wrote: > >> On 2/4/22 7:54 AM, Andy Shevchenko wrote: > >> > On Thursday, January 27, 2022, Sean Anderson <sean.anderson@xxxxxxxx <mailto:sean.anderson@xxxxxxxx>> wrote: ... > > In order to have more or less unified APIs in the future I would > > suggest using 'clock-frequency' for the "main" functional clock. For > > example, 8250_dw uses it for the baud rate generator, while it also > > utilizes auxiliary clock(s) on some platforms. > > OK, I had a look though that driver, and it seems like it uses > clock-frequency only for the baudclk, and e.g. apb_pclk has no > corresponding frequency property. For this driver, it would mean that > the suspend clock would only be configurable through device tree. Is > that the approach you recommend? What I meant is to use the "clock-frequency" property as it is kinda standard de facto for the "main'' functional clock. The rest is up to the individual drivers. From the API perspective I would expect a common helper in the future that takes clock name and returns rate based on clock (if found) or "clock-frequency" property. We may also extend in far future to support any combinations of the [clock name, property name] to get a clock rated either via Device Tree or via ACPI. -- With Best Regards, Andy Shevchenko
