[alsa-devel] [PATCH][ASoC]Add ability to remove rate constraints from generic ASoC AC'97 CODEC driver

[Mark Brown]

On Sun, Mar 29, 2015 at 06:00:33PM +0200, Maciej S. Szmigiero wrote:
> W dniu 22.03.2015 19:27, Mark Brown pisze:

> > Please use subject lines matching the style for the subsystem.  This is
> > helpful for identifying relevant patches and not getting your messages
> > deleted unread...

> I assume "[PATCH] ASoC: driver: subject" format would be right?

Yes.

> > I'm sorry but this just doesn't explain what this patch is intended to
> > accomplish.  If we can talk to the AC'97 CODEC at all we can already
> > identify whatever constraints it has by looking at the ID registers so
> > it's not clear when or why a platform would need to use this.  It feels
> > like there is some underlying problem that you're trying to address.

> This patch itself is supposed to allow using this CODEC driver with
> CODECs that support other rates that these that were already hard-coded
> in the driver (8000, 11025, 22050, 44100, 48000).

You're talking about Linux internal implementation details here but the
change you are proposing a change to the device tree?  Like I think I
said in reply to a previous iteration of this patch we can clearly
enumerate the required information from the hardware already.

> While it would be possible to simply add ac97 bus enumeration to
> either fsl_ssi driver or fsl-asoc-card sound card driver it looks to me
> that even in this case a platform device for codec would need to be
> registered anyway.

That's the way the ASoC AC'97 support currently works, yes.

> If the ac97 bus enumeration is added to fsl_ssi driver then there is
> also a problem of communicating a name of ac97 platform device
> to sound card driver so it can then reference it in DAI links
> that it builds.

...

> And, naturally, this would result in a small code duplication with
> regard to this generic driver.

This sounds like something that can easily be put in some generic code
and either used as a helper library by the drivers or just done directly
from the framework when it knows it's dealing with an AC'97 bus.

Alternatively if you're just trying to open up the constraints why not
just open them up by default and make sure that the AC'97 generic code
is constraining things appropriately if it's not doing so already?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150329/160dc9c4/attachment-0001.sig>