On 12 February 2020 15:48, Pierre-Louis Bossart wrote: > >> Thanks Ranjani. That information closes the door on the idea of playing > >> with the trigger order suggested earlier in the thread, so my guess is > >> that we really need to expose the MCLK/BCLK with the clk API and turn > >> them on/off from the machine driver as needed. I hope is that we don't > >> need the FSYNC as well, that would be rather painful to implement. > > > > Am not going to make myself popular here. It's MCLK and FSYNC (or WCLK as > it's > > termed for our device) that is required for SRM to lock in the PLL. > > > > So far I've not found a way in the codec driver to be able to get around this. > > I spent a very long time with Sathya in the early days (Apollo Lake) looking at > > options but nothing would fit which is why I have the solution that's in place > > right now. We could probably reduce the number of rechecks before timeout in > the > > driver but that's really just papering over the crack and there's still the > > possibility of noise later when SRM finally does lock. > > Sorry, you lost me at "the solution that's in place right now". There is > nothing in the bxt_da7219_max98357a.c code that deals with clocks or > defines a trigger order? I meant solution in the context of the codec driver. The approach or expectation (maybe more suitable wording) for the driver is that the required clocking can be enabled prior to the DAI widget for the codec being powered via DAPM as part of an audio path. This approach has been there since the beginning, for want of a better option, and I've always highlighted this need when platforms are using our device with SRM. You're right though that this isn't taken care of in existing mainline Linux machine files that use this device with SRM. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
