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().
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
