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