[alsa-devel] [PATCH 08/10 v3] ASoC: rsnd: don't call clk_prepare_enable/unprepare() from inside spin lock
Kuninori Morimoto
kuninori.morimoto.gx at renesas.com
Mon Mar 23 10:03:55 CET 2015
Hi Mark again
> > +static int rsnd_ssi_clk(struct rsnd_mod *mod, int enable)
> > +{
> > + struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
> > + struct rsnd_dai_stream *io = rsnd_mod_to_io(mod);
> > + struct rsnd_dai *rdai = rsnd_io_to_rdai(io);
> > +
> > + rsnd_mod_clk(mod, enable);
> > +
> > + if (rsnd_rdai_is_clk_master(rdai)) {
> > + if (rsnd_ssi_clk_from_parent(ssi))
> > + rsnd_mod_clk(&ssi->parent->mod, enable);
> > + }
>
> This would be clearer with a single if statement with an &&, however it
> seems like something that the clock API should be doing itself - it's
> already got support for handling enabling of parents. If we need to
> manually handle dependencies (which is what this looks like) that seems
> like a problem.
I rechecked this.
In our sound device, sound LR and clock pin is controled by PFC (= pin function controller)
and, these pins are shared with other device. it depends on platform/board.
If other device uses this pin, we can't use it in sound device.
Then, this sound device share LR/clock pin in sound device.
And then, device clock has no relation to this
The image is like this
If no other devices use pin, sound device can use all pins
SSI0 deivce clock
SSI0 LR ----------------|------
SSI0 clk ----------------|------
|
SSI1 deivce clock |
SSI1 LR ----------------|------
SSI1 clk ----------------|------
If other device uses pin, sound device share same pins
SSI0 deivce clock
SSI0 LR ---+------------|------
SSI0 clk ---|+-----------|------
|| |
SSI1 deivce clock |
SSI1 LR ---+| Dev A --|------
SSI1 clk ----+ Dev B --|------
Here, SSI1 needs SSI0's LR/clk pin, but it doesn't need SSI0's device clock
because SSI1 has SSI1 device clock.
SSI0 is called as parent for SSI1 in my driver, but it is not "clock parent".
And here, if you want to use SSI1, you need to start SSI0 too.
So Unfortunately, manually handle dependencies is understandable IMO.
More information about the Alsa-devel
mailing list