On Fri, Dec 01, 2017 at 02:02:29AM +0100, Maciej S. Szmigiero wrote:
I will clean up the driver a bit and I think the change would be highly related to AC97 code. So I'll later need you review/test.
From my perspective it would be great if the whole cleanup was in one series, so the whole testing doesn't need to be repeated per patch (it involves a lot of manual work).
Understood.
Regarding a sample rate in AC'97 mode its effective value isn't really controlled by the CPU (that is, SSI), but by a CODEC since it is the CODEC which tells the CPU when it should send a next sample for playback and when a next capture sample is ready. There are no problems if they are different (as long as the CODEC supports this, naturally, but it's up to its driver to restrict the sample rate space accordingly).
It's because CODEC drives the bit clock and framesync clock, isn't it?
Strictly speaking, the frame sync is driven by the controller (SSI), but it is simply the CODEC-provided bit clock divided by 256. And the CODEC-provided bit clock is fixed at 12.288MHz by the AC'97 specs.
But every frame from CODEC also has 'TAG' bits which tell the controller whether this frame contains valid capture samples or not. If the capture sample rate currently programmed in CODEC is less than 48kHz (the frame rate) it simply means that some of incoming frames will contain 'TAG' bits indicating that these frames do not contain valid capture samples (for example, if the capture rate is 24kHz then only half of the frames, on average, will be marked by CODEC as containing valid capture samples).
The situation with playback is similar: the frame from CODEC also has 'SLOTREQ' bits which tell the controller if it should send playback samples (and which) in the next frame - for example, if the playback rate is 24kHz then in half of the frames, on average, the CODEC will request playback samples.
Hope it is clear now.
Thanks for the explain. It's clear now.
Nicolin