[alsa-devel] [PATCH v4 1/7] ASoC: hda - add ASoC HDA codec match function

[Mark Brown]

On Mon, May 25, 2015 at 01:55:59PM +0200, Takashi Iwai wrote:
> Vinod Koul wrote:

> > The hdac core doesn't actually do matching. If you see the match
> > function provided by core (hda_bus_match), it is a wrapper and
> > actual matching for legacy devices is being done in legacy code, see
> > hda_codec_match. This match function expects the hdac_device to be
> > wrapped in legacy hda_codec, which we don't need here.

> > So for ASoC we are embedding hdac_device in soc_hda_codec and using
> > the vendor_id and revision_id to match, so hda to write a new one.

You keep on describing what the code does; I can mostly see what the
code does (and could probably figure out extra bits if I wasn't getting
scared off by what I do see) - that's basically what I'm flagging as an
issue.  What I'm having trouble seeing is why this makes sense.  The
question isn't what, it's why.

> > I do not mind if we commonize this and have common match function in
> > hdac, if legacy is happy with it. Or perhaps the move to core later on
> > as ASoC HDA matures, either way whatever you n Takashi agree with
> > would be okay by me.

> This is the next step.  It would need a fairly big amount of rewrite
> in each legacy HDA codec driver, and I don't want it for 4.2.

So how does this actually work then?  If we need to rework all the HDA
CODEC drivers before they work with this new HDA bus (or at least this
new HDA bus when used with controllers that implement a custom match
function) then does it make sense to start trying to use it now?

I would have expected this to be the /first/ step - refactor the
existing HDA code, then add new users.

> Once when we get the common criteria for matching (both for asoc and
> legacy), we can move to the unified match method.

I really don't understand this idea that we need to work out what the
common criteria for matching are, HDA is an enumerable bus isn't it?

> That said, the reason for individual match mechanism is not to break
> the legacy hda code.  If anyone can provide a patch to achieve that
> within 100 LOCs and without regression, I'd happily take it :)

Another way of looking at this is to ask why the CODEC driver matching
can't continue to work the way it currently does - we're transitioning
to a bus (which makes sense as a cleanup) but I've not seen any reason
articulated for tying that up the merge of the Sky Lake code and it
seems like we're not very near being in a position to be able to do
that.  Or could we just keep the bigger hda_codec struct around in the
bus code for now even if it winds up being bloated?

Like I say it's all the why questions that aren't making sense to me
beyond the "we're too scared to touch the existing code" ones.

I'm also wondering how this interacts with the Tegra HDA device by the
way...
-------------- 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/20150525/3fa73c62/attachment-0001.sig>