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: > >> > Is it function or interface clock? >> > >> > We have standard property for the functional clock rate, I.e. “clock-frequency” (in Hz), can it be used here? >> >> I believe this is a "functional" clock. It it is a reference for the USB >> signals. I'm not sure exactly what the purpose of this clock is, since I >> do not have access to the databook for this IP. I considered using >> "clock-frequency", but I am concerned about ambiguity because there is a >> second "suspend" clock which is also a "functional" clock. The latter >> clock appears to be used when the PHY is shut down (and not necessarily >> corresponding to Linux's notion of a suspended device). If it is >> necessary in the future to configure that clock on ACPI platforms (e.g. >> to set GCTL.PWRDNSCALE) I think it is clear what the property name would >> be (snps,susp-clock-frequency-hz). > > 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? --Sean
