[alsa-devel] [PATCH 1/3] ALSA: hda: add hdac_adsp_enable module flag

[Pierre-Louis Bossart]

On 4/30/15 11:39 PM, Vinod Koul wrote:
> On Thu, Apr 30, 2015 at 10:44:21PM +0200, Takashi Iwai wrote:
>> At Thu, 30 Apr 2015 20:27:26 +0100,
>> Mark Brown wrote:
>>>
>>> On Thu, Apr 30, 2015 at 11:02:19AM -0500, Pierre-Louis Bossart wrote:
>>>> On 4/30/15 9:52 AM, Vinod Koul wrote:
>>>
>>>>> Some Intel HDA controllers sport a DSP. These systems can also be enabled
>>>>> with ASoC HDA driver as well. So add a flag in hda-core to enable/disable
>>>>> aDSP This flag for now is false, and should be true once the ASoC based
>>>>> systems mature.  The integrators/OS vendors can configure this flag based on
>>>>> system preference.
>>>
>>>> This choice is contingent on the BIOS options, you can't enable the DSP if
>>>> the BIOS said no DSP...
> That is right, but by default DSP in On. Btw this is not like older HSW
> platform where HDA and DSP and muxed and BIOS plays key role.
>>>
>>> Presumably this flag should be coming from the BIOS by default and this
>>> providing a disable only setting for test/development?
>>
>> It's hard to know exactly how many models will be with DSP and how
>> many without...  The problem we're dealing with is that we'll have two
>> individual drivers supporting the very same PCI ID.  And, there is no
>> good mechanism to prioritize the driver load on Linux, so far.
>>
>> So, this is the consequence after lengthy discussions: it's fairly
>> simple but effective enough.  Distros may build both drivers, but
>> which driver to use can be decided by this option.  The default value
>> of this switch should be set via a Kconfig, but it can be overridden
>> dynamically via either a static module option or boot option.
> Okay i will respin the series based on latest discussion

Maybe I confused everyone, it's not complicated: there is a register 
that indicates if the DSP is enabled and that can be queried before 
launching the DSP driver. There is no guessing or need for DMI-based 
quirks, the capabilities are exposed and that should be used. You can 
then add a driver parameter to fall back to legacy mode, e.g. for 
testing, but that would be a second level disable. For once the hardware 
does tell us what to do, we need to use the information...