[alsa-devel] [RFC v2 3/3] ALSA: hda: add hda controller to hda

[Vinod Koul]

On Wed, Mar 25, 2015 at 09:31:22AM +0100, Takashi Iwai wrote:
> At Wed, 25 Mar 2015 13:31:41 +0530,
> Vinod Koul wrote:
> > 
> > On Wed, Mar 25, 2015 at 08:05:21AM +0100, Takashi Iwai wrote:
> > > At Wed, 25 Mar 2015 11:31:39 +0530,
> > > Vinod Koul wrote:
> > > > 
> > > > From: Jeeja KP <jeeja.kp at intel.com>
> > > > 
> > > > This adds hdac_controller into hda core.
> > > > 
> > > > Signed-off-by: Jeeja KP <jeeja.kp at intel.com>
> > > > Signed-off-by: Vinod Koul <vinod.koul at intel.com>
> > > 
> > > Now the question is whether we need all codes.
> > > For example, the bus reset isn't needed for Intel chips but it's a
> > > workaround for old AMD chips.  Also, polling and single_cmd fallbacks
> > > are also for buggy chips, and I don't think we'd need them for SKL.
> > I dont have a reason to think this is required
> > > 
> > > The rirb_error flag can be removed and converted to the normal error
> > > code propagation with the new code.  It's there just because the old
> > > interface didn't give the error code in get_response op.  And, of
> > > course, there are superfluous DSP loader for CA0132...
> > okay, but the DSP loader code would be bought in for us. We need to use that
> > to load code for the DSP. I was planning to send that out after this
> 
> Ah, if it's usable for you guys, then it's good to keep / reorg the
> code.
> 
> > > You can find some code I wrote in a couple of weeks ago in
> > > test/hda-dev2 branch of sound-unstable git tree.  I rebased it on top
> > > of hda-regmap branch now, so it's mostly clean.  There you can find
> > > the subset of HDA controller codes that should be enough for a clean
> > > controller driver implementation.
> > > 
> > > I don't mean that mine is necessarily the best.  But my point is that
> > > we don't have to copy the whole in sound/hda.  Rather start from a
> > > smaller and mandatory subset for the new driver, then integrate this
> > > into the existing legacy driver.
> > 
> > Okay sounds okay to me. The current code set has lots of legacy so deciding
> > which bits are required and which are not will take a while for us! Thanks
> > for pointing them out. I will take the code from unstable on top of this
> > series and see what else do we need to do.
> 
> Note that the commit is incomplete, lacking the whole description,
> etc.  But you can grasp the idea behind it, at least.
Yes I am cherry-picking this branch now and modifying and trying to bring it
to some logical conslusion. We can keep adding on top of it.
Will be able to send by tomorrow or so

> > One question I have is regarding conventions to be adopted, do we need
> > hdac_xxx everywhere, since I though hdac stands for hda codec.
> 
> It's hda "core".  I didn't want to have too lengthy names as a
> prefix.
Sounds good

-- 
~Vinod