On Wed, Aug 10, 2016 at 12:31:29AM +0000, Kuninori Morimoto wrote:
My understanding is that current "codec" is already part of "component", and new ASoC controls "component" only. This means, if we switches to new ASoC style, it can't call "codec" side callback ? Indeed my patch-set is using/keeping "codec" pointer, but it is each driver's matter, ASoC framework side doesn't care about it.
If something is only using the component interfaces except for things like probe and remove then converting them to component interfaces makes sense. If it's still using CODEC interfaces for some bits then it's less clear that this is a good idea.
But it seems your opinion is like this ?
- ASoC will care only "component" (same as my opinion)
- This "component" includes all features (= Codec feature, CPU feature, Platform feature, etc)
I think so, yes. To me the goal is to avoid too much rigid categorization of components so that we can handle devices that have combinations of these features effectively without having to worry about exactly what terminology we use to describe them.
Anyway, I don't want to create new issue on ASoC. It seems we (or only me ?) still don't have cristal clear big-picture (?) If so, my previous patch-set might make new style switching difficult. Mark, because of this reasons, is it possible to remove my previous patch-set (= topic/codec-component) from your repository ? Incomplete big-patch-set will cause new trouble. I want to cleanup ASoC, but I want to do it under cristal clear agreement.
I think that's a reasonable thing to do in general, I don't see a particular need to revert it. Like Lars said I probably wouldn't have done it right now but you've done the work so I don't see any need to revert it.