-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSP: need to support MCLK/BCLK/LRCLK on-demand on/off capabilities #629
Comments
This could be done with another optional IPC sent during prepare() and before trigger. |
@plbossart @lgirdwood |
On 2/22/19 1:26 AM, Daniel Baluta wrote:
One question: so the clock handling is done on the host side and DSP
sends request for various operations on the clocks, right?
No, it's the other way around.
The machine driver may request the I2S/MCLK clocks to be turned-on
(either at boot e.g. for an automotive platform) or on-demand with DAPM
events (e.g. for mobile devices). the machine driver uses the clk API to
make that request, and the clk is actually exposed by the SOF driver
which in turn tells the firmware to activate the clocks. On intel
platforms if the bclk or frame_sync are requested, we have to enable a
dummy transfer with zero samples to avoid underflow interrupts/status.
On older devices (Baytrail/Cherrytrail) the MCLK is already exposed with
the clock API, but it's enabled with PMC registers and not the audio DSP
ones.
|
@plbossart Thanks, I understand! On i.MX clock handling would be really fun to implement :). That's because the clock handling is taken care by a separate firmware (running on an M4) and now is handled with commands from the host (Linux) side. So for this reason I've asked about the direction. |
@dbaluta looks like your i.MX SOF driver will need to program M4 ? There are PCM callbacks in the SOF HW abstraction layer so you could add your M4 programming to the hw_params() or prepare() callback ? Btw, if you need other callbacks, then feel free to send a PR. |
Comments from Pierre "These features will be enabled with IPC4, in fact I am working on them at the moment since the way to control them is via a gateway configuration in addition to the binary blobs coming from NHLT. The activation of clocks is handled with a 'gateway configuration', which is made of the 'SSP blob' along with additional commands to configure clocks early. This capability is handled by the cAVS firmware... I am thinking this is part of the plan for the converged firmware." @mwasko @lgirdwood Can you please confirm this capability will be supported by the converged firmware? |
@mmaka1 @marcinszkudlinski pls confirm ? |
yes |
Some codecs need the MCLK/BCLK/LRCLK to be on before streaming starts (typically 10s of ms to avoid clicks/pops), see e.g. https://elixir.bootlin.com/linux/latest/source/sound/soc/intel/boards/kbl_rt5663_max98927.c#L86 for RT5663
The SSP IPC supports keeping the clock on a boot via the clks_control field, but it's not currently implemented. We would also miss IPC support for on/off requests on-demand (new IPC required?)
Adding @lgirdwood and @mmaka1 as assignees mainly to get comments on what IPC changes would be needed, the implementation can be done later.
The text was updated successfully, but these errors were encountered: