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

[Vinod Koul]

On Fri, Jul 31, 2015 at 07:09:25PM +0100, Mark Brown wrote:
> On Fri, Jul 31, 2015 at 10:23:50AM +0530, Vinod Koul wrote:
> > 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:
> 
> > > | This series adds NHLT table support in the driver. This also adds support
> > > | for dsp init, modules configuration and messaging support
> 
> One issue I should probably highlight is - what is a NHLT table and has
> is it documented (I guess it is part of some part of some ACPI spec
> given my understanding of the rules on publication of ACPI bindings).
So by default, SKL BIOS has a new ACPI Table called NHLT, Non
HDA-Link Table. This table contains the settings the driver has to pick up
for the non HDA links (SSP, PDM) and send them to firmware for applying.

The firmware expects it in the same format as stored in the BIOS so we just
query the 'endpoint' blob and send it to FW when that BE is enabled from
DPCM. These contain the hardware register settings that are required for
that 'board' and also the DMA gateway settings. All these are taken up by FW
and applied for that link. We are reusing infrastructure made for other OSes
here and will help us when someone installs Linux on SKL devices we always
get the link settings which have been already tested.

> > 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.
> 
> I'm not sure how that's relevant?
> 
> > 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.
> 
> Right, but you're sending all this stuff piecemeal with no advance
> explanation of where we're going.  This is a recurring problem here -
> there's lots of Intel specific abstraction layers which aren't terribly
> clear and some of which seem to turn out to be redundant on review.
The piecemeal approach was required to manage and split the traffic. This
series adds the handlers on how send bind and unbind messages, pin
management routines, how driver compute PCM params when we have a 'converter
widget' like SRC, channel converter etc
Next series will add the topology handler which will use these. Okay need to
create a pipeline so call module init, bind, calculate pcm params, apply
them etc
I will try my best to add more clarity to updated patchset (holding that up
and rereading to see if I can add more comments to help) and pls do ask
where you feel where stuff is ambiguous

-- 
~Vinod

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150801/2a360153/attachment.sig>