[alsa-devel] [RFC 0/5] Create hdalib for common hda code

[Takashi Iwai]

At Sun, 8 Mar 2015 22:25:36 +0530,
Vinod Koul wrote:
> 
> On Sun, Mar 08, 2015 at 04:50:52PM +0100, Takashi Iwai wrote:
> > At Sun,  8 Mar 2015 20:07:54 +0530,
> > Vinod Koul wrote:
> > > 
> > > This patch series attempts to split existing HDA code to create common hda
> > > library. This is done in order to make HDA code available to other users like
> > > upcoming Intel platforms which sport a HDA controller along with an I2S
> > > link.  This series is 1st patch series which will try to refactor HDA by
> > > splitting it up and then adding ASoC HDA controller driver for these
> > > platforms.
> > > 
> > > This series moves code to sound/hda, renames the files mostly. The second
> > > series will do API changes and subsequent ones will be using HDA bus patches
> > > which Takashi posted recently
> > > 
> > > Comments welcome...
> > 
> > I have a working tree that already contains some HD-audio core stuff
> > changes (I think I formed it in private mail threads), too.  They are
> > found in topic/hda-core branch.  This will be rather picking up only
> > the necessary pieces into sound/hda core directory instead of copying
> > the whole fat ones, targeted to build up a minimalistic HD-audio codec
> > driver.  So, it's a bit different strategy.  You can find the header
> > file (include/sound/hdaudio.h) below and understand what I meant.
> > (BTW, it contains the regmap support, found in topic/hda-regmap
> > branch.)
> I don't mind using this statergy if you recommend that :)
> 
> In that case let me post incremental patches moving code on top of
> topic/hda-core picking changes one by one.

I'm open for any options at this point.  I think it'd be cleaner to
have a small subset (so I've started like that), but of course it
would need more works than using the full set.  Note that currently
I've done only for a smaller codec driver, and the split / porting of
the controller driver is still on the way.

If ASoC driver might be used alone without the legacy mode, it might
be worth to think of the slim version by a smaller core.  OTOH, if
both modes are more or less tagged, splitting to the smaller core
wouldn't be a big win any longer because the both objects are loaded
in anyway.

> > I don't mind to abandon my patches, but before that, we should define
> > the global goal and discuss how to achieve in a better form.
> From our side the goal is to split the current HDA code and move the common
> bits into sound/hda/ That way both existing code and new ASoC HDA code can
> use the existing interfaces. We didn't do much changes on existing HDA since
> we were concerned about possible regressions on existing HDA, but I think
> you want to improve HDA, so we can do both bits togther... :)

Right, a regression is a bigger risk of such code splits.  We'll be
able to catch most of regressions in the codec driver side by hda-emu,
I suppose, but a regression in the controller side is a bit more
difficult to catch.  So this has to be done carefully.

So, the question remains how large we'd take a common part wrt the
controller driver code.


thanks,

Takashi