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@intel.com
This adds hdac_controller into hda core.
Signed-off-by: Jeeja KP jeeja.kp@intel.com Signed-off-by: Vinod Koul vinod.koul@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