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