W dniu 08.05.2015 23:32, Fabio Estevam pisze:
On Fri, May 8, 2015 at 6:16 PM, Maciej S. Szmigiero mail@maciej.szmigiero.name wrote:
Remove rate constraints from generic ASoC AC'97 CODEC and make it selectable in config.
Shouldn't this be split in two patches?
I've submitted it as one patch because they are two trivial changes to make the generic ASoC AC'97 CODEC usable for me outside existing platform files.
But naturally, I can split them and submit them separately if that would be better.
Supported rates should be detected and constrained anyway by AC'97 generic code - was tested with VT1613 CODEC and iMX6 SSI controller.
Nice, I would like to test this on a Udoo board. Care to share the dts changes? (I know this is off topic for this list ;-) Apart from the dts changes: are there still missing patches in linux-next to make audio work in Udoo?
I currently have audio running on this board at kernel based on vanilla 3.19 and porting required changes part-by-part to linux-next.
Changes required on vanilla 3.19 to have it working are: * AC'97 audio support needs to be added to fsl-asoc-card,
* AC'97 CODEC platform device needs to be instantiated in fsl_ssi,
* IPG clock needs to be enabled in fsl_ssi AC'97 mode, so AC'97 regs can be accessed,
* Few small fixes for AC'97 mode in fsl_ssi (missing switch label for format, missing fsl_ssi_dai_probe entry in fsl_ssi_ac97_dai, etc.).
There also is a problem with this CODEC that it seems to pull samples for S/PDIF output from time to time even if S/PDIF output is disabled.
By default this requests samples in AC'97 slots 10/11 via SLOTREQ, which in turn causes SSI to enable these slots in SACCST register and start sending half of the sound samples there.
The end result is that audio suddenly starts to play two times too fast.
Currently, I have a workaround of setting S/PDIF slot assignment in CODEC to first front pair so at least it doesn't affect playback rate.
If you like to have these changes or DT file diff then naturally I can share them, just they aren't production-quality as of now.
This way this driver can be used for platforms which don't need specialized AC'97 CODEC drivers while at the same avoiding code duplication from implementing equivalent functionality in a controller driver.
Resending due to no response received.
No need to put this in the commit log.
Thanks
Thanks for looking into patch and best regards, Maciej Szmigiero