On Mon, Jun 04, 2018 at 08:48:40AM -0500, Pierre-Louis Bossart wrote:
What I find odd is the selection between the two static clocks. I have nothing against the clock API, I just find that the Pi solution isn't terribly elegant. The machine driver selects the 44.1 or 48kHz oscillator by configuring GPIO using registers exposed by the codec driver, the clock API implementation does nothing related to hardware, so we have three entities involved to flip 2 GPIOs.
That just sounds like a not great implementation decision in that platform code rather than a fundamental problem.
And even if I use this solution, I still don't know how to tell the codec driver which sclk to use in an ACPI environment (this is to enable HiFiberry cards on Up/Up^2). At the moment the code does pcm512x->sclk = devm_clk_get(dev, NULL); and I don't have a moral equivalent for ACPI. I can add information for the codec driver to get from the DSDT, I'd need however a agreed solution based on _DSD or some property, and the thread with AMD on their 'mclk_name' topic for DA7219 didn't go anywhere, did it?
For systems out in the wild now you're going to need to have a bit of platform glue code anyway so I'm not sure there's that big an overhead (other than the data tables, but that seems idiomatic for ACPI). It's a bit of work to get something set up but I'd not expect it to be that bad, but perhaps I'm missing something there.
Bottom line there is an 'easy' solution for this specific case and a more complicated one but potentially more generic based on the clock API - hence the RFC.
As far as I can see the two aren't that far off - creating a fixed frequency clock based on DMI data shouldn't be that much harder than doing a set_sysclk().