Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Andrew Lunn <andrew@lunn.ch>,
	alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
	Jyri Sarha <jsarha@ti.com>, Xiubo Li <Li.Xiubo@freescale.com>,
	Jean Delvare <khali@linux-fr.org>
Subject: Re: Using simple-card to replace kirkwood-t5325.c
Date: Tue, 15 Apr 2014 23:29:02 +0100	[thread overview]
Message-ID: <20140415222902.GI12304@sirena.org.uk> (raw)
In-Reply-To: <534D7D31.6040802@metafoo.de>


[-- Attachment #1.1: Type: text/plain, Size: 2582 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2014-04-15 22:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 16:13 Using simple-card to replace kirkwood-t5325.c Andrew Lunn
2014-04-15 18:40 ` Lars-Peter Clausen
2014-04-15 22:29   ` Mark Brown [this message]
2014-04-16 11:17     ` Andrew Lunn
2014-04-16 11:13   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140415222902.GI12304@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Li.Xiubo@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andrew@lunn.ch \
    --cc=jsarha@ti.com \
    --cc=khali@linux-fr.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox