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...