On Fri, Jun 20, 2014 at 10:04:51AM +0200, Lars-Peter Clausen wrote:
On 06/13/2014 02:33 PM, Vinod Koul wrote:
Here is the split patch series for adding DSP support for Intel's merrfield platform.
The last patch si mxer update patch which we have been discussing over the list. This is only for discussion and sake of complteness. For that patch we need the dapm_kcontrol_get/set series to do merged OR patch to be reworked after compenent series
Hi,
Some general feedback on this series.
Thanks a bunch for that :)
You are often accessing data structures which are more or less internal to the DAPM core, all without doing any of the necessary locking. Those are in particular the widget and path structures. This access in the driver will make it harder to make modifications to the core as you'd not only understand the core but also the special semantics that this driver puts on those data structures. If you think the core does not provide what you need try to extend the core with helper functions, with well defined semantics, that do what you need.
Also this series is a bit of a step backwards in terms of compartmentalization as it re-introduces things that we've been trying to get rid of over the last few months:
Well the series was developed on 3.10 and forward ported for upstreaming. So yes you can get that feel. I will try to clean these bits up. Where ever missed please do point it out.
- Don't access widget->platform or dapm->platform, use
snd_soc_dapm_to_platform()
- Don't access dai->platform, use rtd->platform.
Will update above two
- Use regmap for IO instead of the read/write callbacks in the
platform_driver struct.
I dont think we need that for our DSP. The read/write are writing to driver memory which is later used to send data to DSP using IPCs. So how will regmap help here?