On Tue, Apr 14, 2020 at 01:14:41PM -0500, Pierre-Louis Bossart wrote:
> On 4/14/20 12:45 PM, Mark Brown wrote:
> > On Thu, Apr 09, 2020 at 02:58:27PM -0500, Pierre-Louis Bossart wrote:

> > > Using devm_clk_get() with a NULL string fails on ACPI platforms, use
> > > the "sclk" string as a fallback.

> > Is this something that could be fixed at the ACPI level?

> I guess to fix this we'd need some sort of ACPI-level connection or
> description of the clock, and I've never seen such a description?

Wait, so SCLK is in the *global* namespace and the provider has to
register the same name?  That doesn't sound clever.  It might be better
to have the board register the connection from the clock provider to the
device rather than hard code global namespace strings like this, that
sounds like a recipie for misery.

It is really sad that nobody involved in producing these systems that
don't work with the current limitations in ACPI has been able to make
progress on improving ACPI so it can cope with modern hardware and we're
having to deal with this stuff.

> All the examples I've seen use an explicit 'mclk' string (that's e.g. what
> we did for the PMC clocks for Baytrail/Cherrytrail machine drivers, we added
> a lookup). Here I used 'sclk' since it's what TI refers to in their
> documentation.

They appear to call it SCK not SCLK.