linux-kernel - Re: [PATCH][ASoC]Add ability to remove rate constraints from generic ASoC AC'97 CODEC driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Mar 2015 18:00:33 +0200
From:	"Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:	Mark Brown <broonie@...nel.org>
CC:	alsa-devel@...a-project.org, Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Brian Austin <brian.austin@...rus.com>,
	Bard Liao <bardliao@...ltek.com>,
	Oder Chiou <oder_chiou@...ltek.com>,
	Wolfram Sang <wsa@...-dreams.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][ASoC]Add ability to remove rate constraints from generic
 ASoC AC'97 CODEC driver

Thanks for looking into the patch.

W dniu 22.03.2015 19:27, Mark Brown pisze:
> On Wed, Mar 11, 2015 at 12:28:19AM +0100, Maciej S. Szmigiero wrote:
>> Add ability to remove rate constraints from generic ASoC AC'97 CODEC
>> driver via passed platform data, make it selectable in config.
> 
> 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?

>> This way this driver can be used for platforms which don't need
>> specialized AC'97 CODEC drivers while at the same avoiding
>> code duplication from implementing equivalent functionality in
>> a controller driver.
> 
> 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).

In general sense what I want to accomplish is to add sound support for
UDOO board to the mainline kernel.
It uses i.MX6 SSI core as controller with VT1613 AC'97 codec.

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.

This is because as far I see ASoC CODEC DAIs in links are identified
either by OF node or name of their platform device.
I've already tried to accomplish all of this via adding OF node of
AC'97 codec but such patch was rejected.

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.
If such name would be hardcoded then there would be a possibility to
use only one such CODEC in the system
(this SoC theoretically allows up to three).

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

Best regards,
Maciej Szmigiero

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/