On Tue, Apr 15, 2014 at 08:40:49PM +0200, Lars-Peter Clausen wrote:
> On 04/15/2014 06:13 PM, Andrew Lunn wrote:

> >	snd_soc_dapm_enable_pin(dapm, "Mic Jack");
> >	snd_soc_dapm_enable_pin(dapm, "Headphone Jack");
> >	snd_soc_dapm_enable_pin(dapm, "Speaker");

> I'm not sure where this got started, but this mostly seems to be
> cargo-culting. External pins are enabled by default, there is no need to
> call snd_soc_dapm_enable_pin() unless snd_soc_dapm_disable_pin() has been
> called before for the same pin.

It started before I ever started working on ASoC.  Sometimes it's done
for documentation.

> >It also seems
> >common to disable pins and to set them to NC. Is this a generic enough
> >feature it could be added to the DT binding?

> We should probably require that the DAPM routes and widgets are always
> completely specified. In this case the fully_routed flag can be set and
> unconnected pins will automatically be marked as not connected. Although it
> might be too late now to require this since there are already users of the
> simple card out in the wild which may have incomplete constraints.

I think we can do something like say that anything that specifies off
chip widgets needs to fully specify.

> >static int t5325_hw_params(struct snd_pcm_substream *substream,
> >        	   struct snd_pcm_hw_params *params)
> >{

> >This seems a lot less common requirements. All the Marvell SoCs need
> >it, but not many others. So i don't think it makes sense to add it
> >directly to simple-card, otherwise simple-card quickly becomes
> >complex-card as everybody else wants there quirks adding.

> Maybe the drivers can be reworked to not require this anymore. The CODEC
> driver may be able to figure this out on its own.

I don't think it can, that looks like the CODEC MCLK being supplied by
the SoC (it's nothing to do with a requirement from the SoC really).
Ideally this would be handled through the clock API but that's a bit
fail at the minute for architecture neutral code.  It's a bit of a hack
but specifying the ratio in the DT (which I thought we supported in
simple-card already but don't seem to) would sidestep the issue.

> >Has there been any thoughts about turning simple-card.c into a
> >library, or adding hooks so that a driver can modify the created
> >dai_link structures to add in ops like this?

> A few of the function that got added for the simple card are already
> available as library functions in soc-core.c. More can probably made
> available to other drivers if useful.

Yes, that's the preferred approach - where it's useful.