On Wed, May 02, 2018 at 10:13:55AM +0000, Adam Thomson wrote:
On 01 May 2018 21:50, Mark Brown wrote:
There's a lot of things that ACPI *should* do but doesn't - it's a bit of a shambles how ACPI standards get defined and what's there is not really intended to handle systems like these semi-embedded ones. One of the big gaps in ACPI is that it has no handling at all of clocks, that's supposed to be done transparently by firmware in the ACPI model. What a lot of the embedded Intel people have been doing is coopting the DT bindings wholesale for ACPI systems but that has problems when you get into areas which should be handled in some way on ACPI systems like power and unfortunately clocks are kind of power adjacent so might be a bit sketchy here.
Yes I was aware that previously that was the case, although have not followed this for a while. It just feels here that we should aim for something more generic rather than a device specific property/binding, if possible, as that feels messy to me and I'm sure other drivers could take advantage of this as well. I've not looked at the clock code in too much detail though, at least with regards to this area, so not sure how feasible that is.
As a suggestion for ACPI would it be possible to re-use the 'clock-names' property and add something in the framework to handle this?
I completely agree that ACPI should have handling for clocks but it really feels like something that should be done as a proper spec rather than just ad hoc by Linux like the x86 embedded people often do - it's too close to the power management stuff that ACPI definitely does handle.