linux-kernel - Re: [alsa-devel] [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID

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 for Android: free password hash cracker in your pocket

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

Message-ID: <s5hiot4icmd.wl%tiwai@suse.de>
Date:	Tue, 28 Jan 2014 12:12:26 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Mark Brown <broonie@...nel.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Jean-Francois Moine <moinejf@...e.fr>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, Rob Clark <robdclark@...il.com>,
	Dave Airlie <airlied@...il.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [alsa-devel] [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID

At Tue, 28 Jan 2014 11:00:51 +0000,
Mark Brown wrote:
> 
> On Tue, Jan 28, 2014 at 10:23:57AM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> > > On Mon, Jan 27, 2014 at 08:49:15PM +0000, Russell King - ARM Linux wrote:
> 
> > > > Yes, preferably as a generic ALSA helper rather than an ASoC helper -
> > > > I don't see any need for this to be ASoC specific (I have a pure ALSA
> > > > driver which has very similar code in it.)
> 
> > > Indeed, definitely ALSA generic - ideally we could factor a lot of the
> > > integration with the video side out.
> 
> > Yes, indeed.
> 
> > OTOH, as discussed recently, we're heading to move from ELD parsing to
> > more direct communication between video and audio drivers for
> > HD-audio.  ELD will be still provided to user-space, but not evaluated
> > any longer in the new scenario.
> 
> That sort of refactoring being one of the best reasons to keep things
> out of individual drivers!  Having said all this I don't know if it's
> worth blocking Jean-Francois' work on that, it's an improvement in
> itself.  Splitting the code out a bit would be good to help prepare but
> having the full refactoring done might be too much of a blocker.

I just rather wanted to point out the general direction for the
further development, didn't mean NAK.  Jean-Francois' patch itself
looks simple enough, so I see no problem to take it for now as is.


Takashi
--
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/