Re: [PATCH 3/6] ASoC: Intel: Skylake: Add functions for DSP module configuration

[Vinod Koul <vinod.koul@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2950 bytes --]

On Thu, Jul 30, 2015 at 08:01:04PM +0100, Mark Brown wrote:
> On Thu, Jul 30, 2015 at 08:45:07AM +0530, Vinod Koul wrote:
> > On Wed, Jul 29, 2015 at 06:56:31PM +0100, Mark Brown wrote:
> 
> > > But isn't this also protecting against attempts to use the resource
> > > multiple times within the configuration (or shouldn't we be doing that)?
> 
> > In case of static since a module pin is allocated while designing
> > topology we shouldn't have clash as per design of topology
> 
> > For example I have a Gain module connected to Mixer. Gain module pin 0 will
> > be allocated to connect to Mixer Pin0. I wont assign Pin0 to any other
> > module if I am doing static mapping.
> 
> > Whereas in dynamic we will check for first free pin and allocate.
> 
> > If all the pins has same meaning then dynamic would make sense, but non
> > linear modules need reference signals so they have special pins so we need
> > both approaches here
> 
> I'm not sure where I see the thing in here that controls the routing?  I
> thought this might be something to do with it.
> 
> > > Please bear in mind that this stuff has basically zero documentation or
> > > explanation so I'm kind of guessing as to what this is supposed to do.
> 
> > I did try to add explanation where I felt was missing, but yes this is good
> > feedback, I will add more bits in next rev. Also please do point out where
> > you feel we missed.
> 
> So, the summary for the series was:
> 
> | This series adds NHLT table support in the driver. This also adds support
> | for dsp init, modules configuration and messaging support
> 
> and the description for this patch was:
> 
> | This adds helper functions to configure DSP FW modules and to be used when
> | the modules is initialized, or when modules have to be bind/unbind.
> 
> so there's a *little* room for more detail.  I don't have any kind of
> big picture of what the firmware does, what it needs from the kernel,
> how this fits in with the bigger picture of the driver or anything.
> Some more of that where this is going direction stuff would be helpful,
> right now I'm not 100% sure where this is going or anything.
Fair enough.

I am adding more text and comments in the updated patchset to explain.
That should help :)

On your questions above, one thing I would like to point that typically we
have alsa controls and dapm widgets to model the DSP, but now with topology
core, we have moved these into the usermode.
In driver we have handlers for the topology events, so yes it becomes little
difficult to visualize but we can do better by adding comments.
This series is mostly helper code for getting topology created in DSP and
next (last series in current SKL driver work) series will add topology
handlers which will use these helpers, so the big picture will be clear
easily and complete flow can be visualized when these helpers are invoked.

-- 
~Vinod

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]