[alsa-devel] [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver

Tomasz Figa tomasz.figa at gmail.com
Sat Aug 17 14:26:40 CEST 2013


On Friday 16 of August 2013 10:56:32 Sascha Hauer wrote:
> On Fri, Aug 16, 2013 at 04:01:25PM +0800, Nicolin Chen wrote:
> > Hi Sascha,
> > 
> >    Thank you for the detailed comments.
> > 
> > On Fri, Aug 16, 2013 at 09:08:18AM +0200, Sascha Hauer wrote:
> > > Which of them the driver should use is configuration and thus
> > > normally
> > > should *not* be described in the devicetree. However, there may be
> > > no
> > > good way for the driver to know which clock to use in which case.
> > > There
> > > may be additional board requirements which are unknown to the
> > > driver. So in this case it might be valid to put the information
> > > which clock to use into the devicetree. But be aware that from the
> > > moment you put this information into the devicetree the driver is
> > > no longer free to chose the best clock, even if in future we find a
> > > good way to automatically guess the best clock. Do you have some
> > > insights in which case I would use which input clock? Is this only
> > > about which clock has the best suitable input frequency or is this
> > > also about synchronization of the audio signal with some other
> > > unit?
> > 
> > I understand. What I'm thinking now is to let the driver find the best
> > clock source for tx clock and a correspond divisor like this:
> > 
> > "tx<0-8>"	Optional	Tx clock source for spdif playback.
> > 
> > 				If absent, will use core clock.
> > 				The index from 0 to 8 is identical
> > 				to the clock source list described
> > 				in TxClk_Source bit of register STC.
> > 				Multiple clock source are allowed
> > 				for this tx clock source. The driver
> > 				will select one source from them for
> > 				each supported sample rate according
> > 				to the clock rates of these provided
> > 				clock sources.
> 
> You mean tx<0-7>.
> 
> Also I would make this option required. Use a dummy clock for mux inputs
> that are grounded for a specific SoC.

Why do you need a dummy clock?

The driver can simply try to grab all the possible clocks and discard 
those that failed, so you can just keep those grounded clocks unspecified.

Best regards,
Tomasz



More information about the Alsa-devel mailing list