[Minutes] ELCE Audio mini conf.

[Minutes] ELCE Audio mini conf.

[Liam Girdwood]

I've written up the minutes here below (including Vinod's minutes after
I left for my flight). Please do feel free to correct or add any missing
items.

If you intend to reply and discuss a topic in detail then it would
probably be helpful to include the topic in the $SUBJECT (so that it's
easy to track multiple topics that may arise from the minutes).

Jaroslav, I have some PDF slides from a few delegates. Can I post them
on to the Wiki ? This failed last time I tried after the Edinburgh audio
conference (Wiki could not upload PDFs ??). 
 

Soundwire: Pierre
=================

 - Slides to be posted. 
 - Shadow registers required for regamp. Mark: need to make sure we can
commit changes, and rules for witting. Reuse of codec drivers since reg
mapping should be similar to i2c regmaps. 
 - Some devices wont support run time clock changes. Need compatible
devices on bus. 
 - Each device has unique ID set by HW. Device enumeration can be auto
discovered. Can detect device but not capabilities. 
 - Device capabilities can come from hard coded driver data or ACPI/DT
data. Windows may use inf files for capabilities. 
 - Define bus api for master "controller".
 - Grouped triggers can be used for start duplex streams for
similtanious capture and playback. 
 - DAI is physical connection, logical links need to be worked out with
Routing config Mark: Redefining of ports/slots at runtime i.e. Leave up
to userspace for handling supported configurations of ports.



Energy efficiency: Alexander (Minutes also supplied by Alexander).
==================================================================

Power consumption of a SandyBridge-based Sony laptop has been measured
with a workload that does only audio playback. To ensure a reproducible
workload, the whole system has been constructed by a script using
debootstrap, and placed into an initramfs. Various versions of
PulseAudio were compared to CRAS and to the use of ALSA hw device, at
latencies 7 ms, 28 ms and 448 ms. Even in the best case (ALSA), going
from 448 to 28 ms means using extra 300 mW. For PulseAudio, the overhead
of using low latency is even higher, presumably because of a chatty
protocol. In version 7, there was some work (srbchannel) with the aim to
reduce this overhead, but there is still more way to go. There was a
suggestion to use perf to analyze the problem further. It should be
noted that latencies as high as 448 ms are not usable without the
ability to rewind, which PulseAudio posesses (at the cost of more
complex, and actually incorrect, code) and CRAS doesn't. So CRAS
decision to never do rewinds costs it 300 mW (448 ms latency is usable
only for benchmarking purposes). Note: at least two people in the
audience misunderstood this statement as originally formulated
(thinko?), and got it as "PulseAudio decision to do rewinds costs it 300
mW", which is of course wrong. The cost of rewinds is in code
complexity, real user-reported bugs and "how to test this code path"
questions from developers, which, in the opinion of Alexander Patrakov,
may outweigh the gains in energy efficiency (Arun Raghavan disagrees). A
proposal was made by P.-L. Bossart to introduce a hw param that the
application would set if it intends to never do rewinds, with the
implication that a SkyLake driver can use this information for
codec-side power saving (by prefetching audio data and powering the link
off). Arun Raghavan (presumably due to the above misunderstanding)
disagreed and instead proposed to make the device non-rewindable if this
means power savings. Alexander is in favor of the hw param, because it
would be useful for CRAS, but harmful for the current PulseAudio (it
would force abandoning high latency). A future version of PulseAudio
could, though, use a separate DSP stream for a music application (if
there is only one), and, because a new application never appears, and
the hardware volume is precise enough, there would never be a need to
rewind. This, though, would need eliminating the support for rewinds
from the client API (the last two parameters for pa_stream_write()),
which can be done by ignoring these parameters.



Documentation: Takashi
======================
 - Patches that introduce new functionality should also include
documentation.
 - Caretaker required for docs. Who ?
 - Uploading materials, in central location, ask kernel.org. 
 - Charles and Rakesh voluntered to write some docs.



Alsa-lib: release schedule: Vinod.
================================== 
 - Request for more frequent release. Release inline with 1 - 2 kernel
releases.
 - Integrate tinycompress into alsa release.



Testing/QA: Liam, Takashi, Mark, Pierre
=======================================
 - BAT tool: Now upstream, WiP for review comments docs and new
features. 
 - Mark doing brute force tool for kcontrol testing.  Kcontrol status
can be watched via debubFS. Multiple threads. 
 - Takashi: Need unit testing codec drivers. Some codec vendors have
tools for this but something generic would be good. QA unit test could
use topology readback to check topology in userspace.
 - Pierre: Latency testing, USB device to toggle GPIO (to indicate
stream start) and audio latency measured from this point. Available on
01.org latency tools. To be extended to BAT. 



HDA/gfx: relevant people not in room.
=====================================
 - Pierre: Hotplug DP over USB C required. Needs input from GFX folks.



BATCH flag for USB: Arun.
=========================
 - Flag does not respond to reality, lets deprecate it. no users.
 - Dylan: need to know transfer size for CRAS (uses extra samples for
buffering). 
 - BATCH flag means period size transfers, applications that use new
granularity API can ignore batch flag. Pierre: to implement.



Splitting out controls: Takashi
===============================

 - Restricted access.  Consensus to restrict access to some controls due
to possibility of breaking HW at kernel level. i.e. prevent feeding
digital Mic into HP amp to prevent speaker over heating.
 - Some clamping APIs already exist, but these should be extended to
include DAPM. 



Simple card: ACPI support. Vinod
================================

 - Clock drivers required alongside helper functions to help initialise
DAI links etc.
 - Vinod to publish spec as RFC in Q4.
 - Doubts of using DMI names for differentiation.



Topology: Liam, Mengdong
========================
 - Proposals to use debugFS/ioctl/media controller for exporting
topology data to userspace. Drawbacks with all three approaches, but are
aimed at different end users i.e. debugFS aimed at kernel audio
developers/integrators/testers and media aimed at userspace developers
and end users. Will probably support both debugFS (or other kernel file)
and media API. Mark to discuss at Media team in Seoul. ASoC internals to
gather data for debugFS and Media API will be the same code so nothing
blocking initial development. 



Tiny-fication. Keyon, Liam
==========================

 - IoT devices have tight memory footprints so audio kernel and
userspace can be very limited.
 - Userspace is fine with tinyalsa. 
 - Currently Keyon has worked on some IoT device options to disable ALSA
functions. e.g. code saving of 13k for refinement, but some IoT options
can break existing userpsace.
 - Suggestion is to research tinycompress API for general PCM usage.
 - Look at removing DAPM strings (will need topology dump tool to
automate this though).
 - Some structures can also be shrunk.


Android configuration consolidation
===================================

- different configuration formats XML, ucm, This tool takes Android XML
and converts to UCM 
- uses Sony Xperia 
- generates UCM file from XML 
- Android: Try to converge to a HAL, but diverges quickly. Quirks for
modem etc cant be represented well. 
- Arun will send the link to his work


HDA Restructuring: Vinod & Rakesh
=================================

- Discussed HW and SW overview
- Future HDA work and codec conversion discussion
<dont have detailed notes here as I was talking>



DPMST: Mengdong
================
- One DVI port can be used to transmit multiple independent streams. 
- Three display pipelines in HW, so at most 3 streams can be supported
across all ports
- Need to modify representation to have stream on device rather than per
pin.
- While moving the monitor can be incompatible so should be modified
- display should tell us unplug/plug on move. Sound server reacts to it.
- This notification thru Component fwk.
- Various options are discussed. Needs more offline discussion on
approach and to solve this issue



ALSA Core Challenges:
======================
- ALSA Core locking is complicated. Core code is quite difficult to
understand.
- PCM linking makes things complex
- Add documentation for locks. 
 - Controls can be hidden in UI tools through iface_cards.
 - DPCM hidden PCMs should not be shown in usermode, hide them from
Usermode


Multi Channel ASoC Controls;
=============================
- channel maps dont make sense for ASoC as asoc paths dont have channel
information
- conclusion: add channel maps on HDMI edge. 
- we can add multi-channel controls to the asoc


Liam

Re: [Minutes] ELCE Audio mini conf.

[Jaroslav Kysela]

Dne 12.10.2015 v 15:49 Liam Girdwood napsal(a):
> I've written up the minutes here below (including Vinod's minutes after
> I left for my flight). Please do feel free to correct or add any missing
> items.

Thank you very much for this work.

				Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Splitting out controls

[James Cameron]

On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> I've written up the minutes here below

Thanks!

> Splitting out controls: Takashi
> ===============================
> 
>  - Restricted access.  Consensus to restrict access to some controls due
> to possibility of breaking HW at kernel level. i.e. prevent feeding
> digital Mic into HP amp to prevent speaker over heating.

I'd like that.  rt5631.  Avoiding at the moment by removing the controls.

-- 
James Cameron
http://quozl.linux.org.au/

Re: Splitting out controls

[David Henningsson]

On 2015-10-12 22:59, James Cameron wrote:
> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>> I've written up the minutes here below
>
> Thanks!
>
>> Splitting out controls: Takashi
>> ===============================
>>
>>   - Restricted access.  Consensus to restrict access to some controls due
>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>> digital Mic into HP amp to prevent speaker over heating.
>
> I'd like that.  rt5631.  Avoiding at the moment by removing the controls.

IIRC, the debate was over "do not expose dangerous controls to userspace 
at all" vs "expose dangerous controls controls only to root".

I'm strongly voting for "do not expose to userspace at all".

I personally believe that if the physical hardware can be set to state 
where it's bricked, the hardware itself is buggy.

If the hardware is buggy, this should be worked around in BIOS or 
whatever firmware is present on the machine. Otherwise there is a bug in 
BIOS.

If BIOS is buggy and cannot protect the machine from being physically 
damaged, then we need to work around that in the kernel. Otherwise there 
is a bug in the kernel.

And if the kernel is buggy, we should fix the kernel. Period. :-)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Splitting out controls

[Keyon]

On 2015年10月13日 15:07, David Henningsson wrote:
>
>
> On 2015-10-12 22:59, James Cameron wrote:
>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>> I've written up the minutes here below
>>
>> Thanks!
>>
>>> Splitting out controls: Takashi
>>> ===============================
>>>
>>>   - Restricted access.  Consensus to restrict access to some 
>>> controls due
>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>> digital Mic into HP amp to prevent speaker over heating.
>>
>> I'd like that.  rt5631.  Avoiding at the moment by removing the 
>> controls.
>
> IIRC, the debate was over "do not expose dangerous controls to 
> userspace at all" vs "expose dangerous controls controls only to root".
>
> I'm strongly voting for "do not expose to userspace at all".
>
> I personally believe that if the physical hardware can be set to state 
> where it's bricked, the hardware itself is buggy.
>
> If the hardware is buggy, this should be worked around in BIOS or 
> whatever firmware is present on the machine. Otherwise there is a bug 
> in BIOS.
>
> If BIOS is buggy and cannot protect the machine from being physically 
> damaged, then we need to work around that in the kernel. Otherwise 
> there is a bug in the kernel.
>
> And if the kernel is buggy, we should fix the kernel. Period. :-)
I agree that also we don't expose dangerous controls at all, or expose 
but do some restraining at codec driver side, e.g. changing dangerous 
setting to save one.
We *cannot* make sure 'root' may know the detail about it and leave the 
risk to him. :)

~Keyon

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

'BATCH flag for USB' and 'ALSA Core Challenges'

[Takashi Sakamoto]

Hi,

(If I were in ±0200、I would have joined in the meeting...)

There're some interesting issues in the minutes. Would I request someone
more explaination about it?

> BATCH flag for USB: Arun.
> =========================
>  - Flag does not respond to reality, lets deprecate it. no users.
>  - Dylan: need to know transfer size for CRAS (uses extra samples for
> buffering). 
>  - BATCH flag means period size transfers, applications that use new
> granularity API can ignore batch flag. Pierre: to implement.

The first item said 'BATCH flag should be deprecated', while
BLOCK_TRANSFER flag is not mentioned. Are there some discussions about
the differences between these two flags?

I think the APIs suppose that the number of PCM frames in one
transferring is the same as the number of PCM frames in one period of
buffer. PCM device driver developers must always satisfy this principle?
Or the APIs allow them to implement such differences and present proper
value to userspace?

> ALSA Core Challenges:
> ======================
> - ALSA Core locking is complicated. Core code is quite difficult to
> understand.
> - PCM linking makes things complex
> - Add documentation for locks. 
>  - Controls can be hidden in UI tools through iface_cards.
>  - DPCM hidden PCMs should not be shown in usermode, hide them from
> Usermode

The third item mentions about 'iface_cards', while there'no such
structure in kernel/userspace.
What's it and what is the 'UI tools'? Does it means to produce some GUI
widget?

Sorry just to take my questions but I'm not a participant of the meeting...


Regards

Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 'BATCH flag for USB' and 'ALSA Core Challenges'

[Alexander E. Patrakov]

13.10.2015 19:09, Takashi Sakamoto wrote:
> Hi,
>
> (If I were in ±0200、I would have joined in the meeting...)
>
> There're some interesting issues in the minutes. Would I request someone
> more explaination about it?
>
>> BATCH flag for USB: Arun.
>> =========================
>>   - Flag does not respond to reality, lets deprecate it. no users.
>>   - Dylan: need to know transfer size for CRAS (uses extra samples for
>> buffering).
>>   - BATCH flag means period size transfers, applications that use new
>> granularity API can ignore batch flag. Pierre: to implement.
> The first item said 'BATCH flag should be deprecated', while
> BLOCK_TRANSFER flag is not mentioned. Are there some discussions about
> the differences between these two flags?

There is no conspiracy here, just inaccurately-written minutes. The 
proposal to deprecate was about the BLOCK_TRANSFER flag (because 
currently it means absolutely othing and has no users), although I 
support deprecation of the BATCH flag too. Please see this email that 
explains the intended meaning of the flags:

http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093750.html

>
> I think the APIs suppose that the number of PCM frames in one
> transferring is the same as the number of PCM frames in one period of
> buffer. PCM device driver developers must always satisfy this principle?
> Or the APIs allow them to implement such differences and present proper
> value to userspace?

The intention is to provide driver developers the means to express the 
situation with the transfer size and pointer granularity in a useful 
manner, and two boolean flags just don't cut it. So some new API is needed.

-- 
Alexander E. Patrakov
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Splitting out controls

[Pierre-Louis Bossart]

On 10/13/15 2:07 AM, David Henningsson wrote:
>
>
> On 2015-10-12 22:59, James Cameron wrote:
>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>> I've written up the minutes here below
>>
>> Thanks!
>>
>>> Splitting out controls: Takashi
>>> ===============================
>>>
>>>   - Restricted access.  Consensus to restrict access to some controls
>>> due
>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>> digital Mic into HP amp to prevent speaker over heating.
>>
>> I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
>
> IIRC, the debate was over "do not expose dangerous controls to userspace
> at all" vs "expose dangerous controls controls only to root".
>
> I'm strongly voting for "do not expose to userspace at all".
>
> I personally believe that if the physical hardware can be set to state
> where it's bricked, the hardware itself is buggy.
>
> If the hardware is buggy, this should be worked around in BIOS or
> whatever firmware is present on the machine. Otherwise there is a bug in
> BIOS.
>
> If BIOS is buggy and cannot protect the machine from being physically
> damaged, then we need to work around that in the kernel. Otherwise there
> is a bug in the kernel.
>
> And if the kernel is buggy, we should fix the kernel. Period. :-)

There are just too many variables linked to acoustic, mechanical and 
thermal design that just can't be handled with a simple rule at the 
kernel level or even BIOS/firmware. There were quite a few people in the 
room who voiced their opinion that handling 'dangerous' controls was an 
exercise for the integrator, not something that can be handled with a 
one-size-fits-all fix. 'userspace' is also a vague definition, most 
audio servers will use profiles that will avoid using bad 
configurations. It's not clear to me that we have to protect against a 
user setting random values with alsamixer.

Re: Splitting out controls

[David Henningsson]

On 2015-10-13 16:55, Pierre-Louis Bossart wrote:
> On 10/13/15 2:07 AM, David Henningsson wrote:
>>
>>
>> On 2015-10-12 22:59, James Cameron wrote:
>>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>>> I've written up the minutes here below
>>>
>>> Thanks!
>>>
>>>> Splitting out controls: Takashi
>>>> ===============================
>>>>
>>>>   - Restricted access.  Consensus to restrict access to some controls

Note: There is NOT consensus.

>>>> due
>>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>>> digital Mic into HP amp to prevent speaker over heating.
>>>
>>> I'd like that.  rt5631.  Avoiding at the moment by removing the
>>> controls.
>>
>> IIRC, the debate was over "do not expose dangerous controls to userspace
>> at all" vs "expose dangerous controls controls only to root".
>>
>> I'm strongly voting for "do not expose to userspace at all".
>>
>> I personally believe that if the physical hardware can be set to state
>> where it's bricked, the hardware itself is buggy.
>>
>> If the hardware is buggy, this should be worked around in BIOS or
>> whatever firmware is present on the machine. Otherwise there is a bug in
>> BIOS.
>>
>> If BIOS is buggy and cannot protect the machine from being physically
>> damaged, then we need to work around that in the kernel. Otherwise there
>> is a bug in the kernel.
>>
>> And if the kernel is buggy, we should fix the kernel. Period. :-)
>
> There are just too many variables linked to acoustic, mechanical and
> thermal design that just can't be handled with a simple rule at the
> kernel level or even BIOS/firmware. There were quite a few people in the
> room who voiced their opinion that handling 'dangerous' controls was an
> exercise for the integrator, not something that can be handled with a
> one-size-fits-all fix.

If userspace can make complex decisions to avoid damage, then so can the 
kernel. The integrator can just write that logic into the kernel instead 
of writing it into userspace.

> 'userspace' is also a vague definition, most
> audio servers will use profiles that will avoid using bad
> configurations. It's not clear to me that we have to protect against a
> user setting random values with alsamixer.

Whether the devices are phones, laptops, or everything in between, 
people are replacing their original software with other software. Surely 
those people are messing around with mixer controls, and surely they 
don't want their devices damaged.

These people might replace the kernel as well, of course, but are less 
likely to do so than to replace userspace; and if they do, they are less 
likely to mess around with a particular audio driver, especially if that 
driver has a big warning sign saying "changing this value might fry your 
speaker" (which, IMO, would be appropriate).

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: 'BATCH flag for USB' and 'ALSA Core Challenges'

[Pierre-Louis Bossart]

On 10/13/15 9:09 AM, Takashi Sakamoto wrote:
> Hi,
>
> (If I were in ±0200、I would have joined in the meeting...)
>
> There're some interesting issues in the minutes. Would I request someone
> more explaination about it?
>
>> BATCH flag for USB: Arun.
>> =========================
>>   - Flag does not respond to reality, lets deprecate it. no users.
>>   - Dylan: need to know transfer size for CRAS (uses extra samples for
>> buffering).
>>   - BATCH flag means period size transfers, applications that use new
>> granularity API can ignore batch flag. Pierre: to implement.
>
> The first item said 'BATCH flag should be deprecated', while
> BLOCK_TRANSFER flag is not mentioned. Are there some discussions about
> the differences between these two flags?
>
> I think the APIs suppose that the number of PCM frames in one
> transferring is the same as the number of PCM frames in one period of
> buffer. PCM device driver developers must always satisfy this principle?
> Or the APIs allow them to implement such differences and present proper
> value to userspace?

The idea was to rely on the new hw_params field that was tentatively 
called max_burst to report how much data is pulled/pushed at once by the 
hardware. If the driver indicated that it handles a complete period this 
would provide the same functionality as the BATCH flag that could then 
be deprecated. I will try to post patches soon.

>
>> ALSA Core Challenges:
>> ======================
>> - ALSA Core locking is complicated. Core code is quite difficult to
>> understand.
>> - PCM linking makes things complex
>> - Add documentation for locks.
>>   - Controls can be hidden in UI tools through iface_cards.
>>   - DPCM hidden PCMs should not be shown in usermode, hide them from
>> Usermode
>
> The third item mentions about 'iface_cards', while there'no such
> structure in kernel/userspace.
> What's it and what is the 'UI tools'? Does it means to produce some GUI
> widget?

The idea was that if there is a new interface used instead of 'mixer' 
then the new controls would not be made visible to UI tools that look 
for the mixer interface. But of course a new tool looking for the new 
iface would be able to display everything so it's only a work-around.

> Sorry just to take my questions but I'm not a participant of the meeting...

we certainly hope you can join next time :-)





_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Splitting out controls

[Pierre-Louis Bossart]

On 10/13/15 10:56 AM, David Henningsson wrote:
>
>
> On 2015-10-13 16:55, Pierre-Louis Bossart wrote:
>> On 10/13/15 2:07 AM, David Henningsson wrote:
>>>
>>>
>>> On 2015-10-12 22:59, James Cameron wrote:
>>>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>>>> I've written up the minutes here below
>>>>
>>>> Thanks!
>>>>
>>>>> Splitting out controls: Takashi
>>>>> ===============================
>>>>>
>>>>>   - Restricted access.  Consensus to restrict access to some controls
>
> Note: There is NOT consensus.
>
>>>>> due
>>>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>>>> digital Mic into HP amp to prevent speaker over heating.
>>>>
>>>> I'd like that.  rt5631.  Avoiding at the moment by removing the
>>>> controls.
>>>
>>> IIRC, the debate was over "do not expose dangerous controls to userspace
>>> at all" vs "expose dangerous controls controls only to root".
>>>
>>> I'm strongly voting for "do not expose to userspace at all".
>>>
>>> I personally believe that if the physical hardware can be set to state
>>> where it's bricked, the hardware itself is buggy.
>>>
>>> If the hardware is buggy, this should be worked around in BIOS or
>>> whatever firmware is present on the machine. Otherwise there is a bug in
>>> BIOS.
>>>
>>> If BIOS is buggy and cannot protect the machine from being physically
>>> damaged, then we need to work around that in the kernel. Otherwise there
>>> is a bug in the kernel.
>>>
>>> And if the kernel is buggy, we should fix the kernel. Period. :-)
>>
>> There are just too many variables linked to acoustic, mechanical and
>> thermal design that just can't be handled with a simple rule at the
>> kernel level or even BIOS/firmware. There were quite a few people in the
>> room who voiced their opinion that handling 'dangerous' controls was an
>> exercise for the integrator, not something that can be handled with a
>> one-size-fits-all fix.
>
> If userspace can make complex decisions to avoid damage, then so can the
> kernel. The integrator can just write that logic into the kernel instead
> of writing it into userspace.

That seems to go against everything we've done over the last few years.
And it's not even feasible to put kernel-level safeguards with the new 
topology tool, since the kcontrols are instantiated at run time based on 
a firmware description.

>> 'userspace' is also a vague definition, most
>> audio servers will use profiles that will avoid using bad
>> configurations. It's not clear to me that we have to protect against a
>> user setting random values with alsamixer.
>
> Whether the devices are phones, laptops, or everything in between,
> people are replacing their original software with other software. Surely
> those people are messing around with mixer controls, and surely they
> don't want their devices damaged.
>
> These people might replace the kernel as well, of course, but are less
> likely to do so than to replace userspace; and if they do, they are less
> likely to mess around with a particular audio driver, especially if that
> driver has a big warning sign saying "changing this value might fry your
> speaker" (which, IMO, would be appropriate).

It's a valid case but I would argue that if you install new software you 
should use profiles that have been shared or used by others. If you want 
to protect against the limited knowledge of an individual user 'messing 
around mixer controls' then this is going too far.

Re: 'BATCH flag for USB' and 'ALSA Core Challenges'

[Liam Girdwood]

On Tue, 2015-10-13 at 23:09 +0900, Takashi Sakamoto wrote:
> Hi,
> 
> (If I were in ±0200、I would have joined in the meeting...)
> 

Fwiw, maybe we should do an additional hangout option next time for
people who cant travel. This depends on demand though and whether the
venue will give us decent internet access and we can get a mic set up
for presenters. Lets look into it for next time though....

Liam

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Splitting out controls

[Liam Girdwood]

On Tue, 2015-10-13 at 17:56 +0200, David Henningsson wrote:
> 
> On 2015-10-13 16:55, Pierre-Louis Bossart wrote:
> > On 10/13/15 2:07 AM, David Henningsson wrote:
> >>
> >>
> >> On 2015-10-12 22:59, James Cameron wrote:
> >>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> >>>> I've written up the minutes here below
> >>>
> >>> Thanks!
> >>>
> >>>> Splitting out controls: Takashi
> >>>> ===============================
> >>>>
> >>>>   - Restricted access.  Consensus to restrict access to some controls
> 
> Note: There is NOT consensus.

Sorry, this should be "control values" instead of "controls". I guess my
typing speed was not fast enough to keep up :(

My understanding at the time was we could use the existing clamp API to
clamp kcontrol values (in machine drivers) to reasonable/safe values.

I did hear many objections to setting some kcontrols as RO for certain
users and RW for other users.

Liam

Re: Splitting out controls

[David Henningsson]

On 2015-10-13 18:08, Pierre-Louis Bossart wrote:
> On 10/13/15 10:56 AM, David Henningsson wrote:
>>
>>
>> On 2015-10-13 16:55, Pierre-Louis Bossart wrote:
>>> On 10/13/15 2:07 AM, David Henningsson wrote:
>>>>
>>>>
>>>> On 2015-10-12 22:59, James Cameron wrote:
>>>>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>>>>> I've written up the minutes here below
>>>>>
>>>>> Thanks!
>>>>>
>>>>>> Splitting out controls: Takashi
>>>>>> ===============================
>>>>>>
>>>>>>   - Restricted access.  Consensus to restrict access to some controls
>>
>> Note: There is NOT consensus.
>>
>>>>>> due
>>>>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>>>>> digital Mic into HP amp to prevent speaker over heating.
>>>>>
>>>>> I'd like that.  rt5631.  Avoiding at the moment by removing the
>>>>> controls.
>>>>
>>>> IIRC, the debate was over "do not expose dangerous controls to
>>>> userspace
>>>> at all" vs "expose dangerous controls controls only to root".
>>>>
>>>> I'm strongly voting for "do not expose to userspace at all".
>>>>
>>>> I personally believe that if the physical hardware can be set to state
>>>> where it's bricked, the hardware itself is buggy.
>>>>
>>>> If the hardware is buggy, this should be worked around in BIOS or
>>>> whatever firmware is present on the machine. Otherwise there is a
>>>> bug in
>>>> BIOS.
>>>>
>>>> If BIOS is buggy and cannot protect the machine from being physically
>>>> damaged, then we need to work around that in the kernel. Otherwise
>>>> there
>>>> is a bug in the kernel.
>>>>
>>>> And if the kernel is buggy, we should fix the kernel. Period. :-)
>>>
>>> There are just too many variables linked to acoustic, mechanical and
>>> thermal design that just can't be handled with a simple rule at the
>>> kernel level or even BIOS/firmware. There were quite a few people in the
>>> room who voiced their opinion that handling 'dangerous' controls was an
>>> exercise for the integrator, not something that can be handled with a
>>> one-size-fits-all fix.
>>
>> If userspace can make complex decisions to avoid damage, then so can the
>> kernel. The integrator can just write that logic into the kernel instead
>> of writing it into userspace.
>
> That seems to go against everything we've done over the last few years.

Alsactl, a tool I believe is running by default on boot of almost every 
Linux distro, sets the mixer to (pretty high) values solely based on 
their names. It does so without user interaction, and it runs as root.

Likewise, alsamixer is one of the first tools you go to when you have 
problems with your sound not working. Ubuntu, Debian, Arch and more have 
guides on their wikis of how to use it.

Hence I'd say that allowing mixer controls to destroy your hardware is 
to go against everything done over *more* than the last few years.

Also, if simply booting up a Linux distro from a USB stick (or however 
you root your device) has even the slightest chance of destroying your 
hardware, that'd be a pretty big punch against getting people to try it 
out. :-(

And if that wasn't enough, it's also an attack vector for malicious apps.

> And it's not even feasible to put kernel-level safeguards with the new
> topology tool, since the kcontrols are instantiated at run time based on
> a firmware description.

Again, not buying it. A topology tool must not create kcontrols that 
could destroy the machine.

>>> 'userspace' is also a vague definition, most
>>> audio servers will use profiles that will avoid using bad
>>> configurations. It's not clear to me that we have to protect against a
>>> user setting random values with alsamixer.
>>
>> Whether the devices are phones, laptops, or everything in between,
>> people are replacing their original software with other software. Surely
>> those people are messing around with mixer controls, and surely they
>> don't want their devices damaged.
>>
>> These people might replace the kernel as well, of course, but are less
>> likely to do so than to replace userspace; and if they do, they are less
>> likely to mess around with a particular audio driver, especially if that
>> driver has a big warning sign saying "changing this value might fry your
>> speaker" (which, IMO, would be appropriate).
>
> It's a valid case but I would argue that if you install new software you
> should use profiles that have been shared or used by others.If you want
> to protect against the limited knowledge of an individual user 'messing
> around mixer controls' then this is going too far.

We actively enable and advocate that people with limited knowledge can 
'mess around mixer controls'. That's why we have an alsamixer 
application in the first place, and teach people how to use it.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Splitting out controls

[Pierre-Louis Bossart]

> We actively enable and advocate that people with limited knowledge can
> 'mess around mixer controls'. That's why we have an alsamixer
> application in the first place, and teach people how to use it.

What you are describing is the traditional approach where the number of 
controls is limited, a couple of switches here and a set of volume 
controls there.
With new devices having mixers all over the place, be it in codecs or 
DSPs, it's not uncommon to have several hundred controls. There is no 
way users will be able to find out on their own what values they should 
use and it would be misleading to think developers are able to identify 
all lethal combinations of settings. We've also moved all these control 
settings from kernel to userspace to avoid hardcoding values that are 
platform specific.
Bottom line we have to move to profiles, stop guessing values based on 
control names or avoid letting users poke random values in alsamixer. 
This just doesn't scale any more. thinking that the alsamixer 
command-line remains the default user-facing interface moving forward is 
just not right, it's a developer tool.

Re: Splitting out controls

[Richard Fitzgerald]

On Fri, 2015-10-16 at 09:49 -0500, Pierre-Louis Bossart wrote:
> > We actively enable and advocate that people with limited knowledge can
> > 'mess around mixer controls'. That's why we have an alsamixer
> > application in the first place, and teach people how to use it.
> 
> What you are describing is the traditional approach where the number of 
> controls is limited, a couple of switches here and a set of volume 
> controls there.
> With new devices having mixers all over the place, be it in codecs or 
> DSPs, it's not uncommon to have several hundred controls. There is no 
> way users will be able to find out on their own what values they should 
> use and it would be misleading to think developers are able to identify 
> all lethal combinations of settings. We've also moved all these control 
> settings from kernel to userspace to avoid hardcoding values that are 
> platform specific.
> Bottom line we have to move to profiles, stop guessing values based on 
> control names or avoid letting users poke random values in alsamixer. 
> This just doesn't scale any more. thinking that the alsamixer 
> command-line remains the default user-facing interface moving forward is 
> just not right, it's a developer tool.

I believe that you are misunderstanding David's point. Yes, there can be
a large number of controls (the Wolfson WM8280 has over 400 controls,
some Cirrus Logic codecs have nearly 900). The point was not whether the
users should understand the meaning of all these controls but that they
should be able to "play around and see what happens" without any risk of
bricking their hardware. Regardless of whether what they are doing is
meaningful or whether it's really feasible to set hundreds of controls
correctly from the command line, they shouldn't damage the hardware. Not
even root should have the ability to actually damage the hardware.

Re: Splitting out controls

[Takashi Iwai]

On Fri, 16 Oct 2015 16:49:25 +0200,
Pierre-Louis Bossart wrote:
> 
> > We actively enable and advocate that people with limited knowledge can
> > 'mess around mixer controls'. That's why we have an alsamixer
> > application in the first place, and teach people how to use it.
> 
> What you are describing is the traditional approach where the number of 
> controls is limited, a couple of switches here and a set of volume 
> controls there.
> With new devices having mixers all over the place, be it in codecs or 
> DSPs, it's not uncommon to have several hundred controls. There is no 
> way users will be able to find out on their own what values they should 
> use and it would be misleading to think developers are able to identify 
> all lethal combinations of settings. We've also moved all these control 
> settings from kernel to userspace to avoid hardcoding values that are 
> platform specific.

Right, and this is the problem.  The system integration information
isn't the thing a typical user would need to handle.

OK, we can leave them in user space.  It's more flexible, yes.  But
it's a bad design if a *normal* user is allowed and needs to handle
all these.  A normal user needs (and is allowed) only limited presets;
your car won't allow you accessing hundreds of knobs, e.g. a child on
a rear seat suddenly triggers the turbo-jump button in combination
with a back-fire while driving on a highway :)

> Bottom line we have to move to profiles, stop guessing values based on 
> control names or avoid letting users poke random values in alsamixer. 
> This just doesn't scale any more. thinking that the alsamixer 
> command-line remains the default user-facing interface moving forward is 
> just not right, it's a developer tool.

Well, it doesn't matter whether it's alsamixer or whatever program.
The point is that *any* user program might screw up things easily,
even if it's not intentional.

For Android, it wasn't a big issue, so far, just because only few
people touch the audio setup manually.  But now the former embedded
things get more migrated to the desktop scenes, and it's pretty normal
that a user just runs normal PA and ALSA apps with it nowadays like
PC.  It'll get more and more in the next years.

So, yes, we have profiles to manage the setups in user-space.  This is
very good, scalable, per se.  The problem is, however, rather how to
harden this management.


I still think that the driver can give the first-level filter or
permission isolation.  It should be doable also in topology f/w, in
theory.

Then, we can think of more hardening in user-space side on top of it.
For example, running sound (or UCM) daemon with a privileged user, and
let it alone managing the sensitive sound setup while a normal user is
allowed to adjust only limited presets given by the profile.

Just my $0.02, currently floating on my fuzzy head in bed.


Takashi

Re: Splitting out controls

[Richard Fitzgerald]

On Tue, 2015-10-13 at 09:07 +0200, David Henningsson wrote:
> 
> On 2015-10-12 22:59, James Cameron wrote:
> > On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> >> I've written up the minutes here below
> >
> > Thanks!
> >
> >> Splitting out controls: Takashi
> >> ===============================
> >>
> >>   - Restricted access.  Consensus to restrict access to some controls due
> >> to possibility of breaking HW at kernel level. i.e. prevent feeding
> >> digital Mic into HP amp to prevent speaker over heating.
> >
> > I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
> 
> IIRC, the debate was over "do not expose dangerous controls to userspace 
> at all" vs "expose dangerous controls controls only to root".
> 
> I'm strongly voting for "do not expose to userspace at all".
> 
> I personally believe that if the physical hardware can be set to state 
> where it's bricked, the hardware itself is buggy.
> 
> If the hardware is buggy, this should be worked around in BIOS or 
> whatever firmware is present on the machine. Otherwise there is a bug in 
> BIOS.
> 
> If BIOS is buggy and cannot protect the machine from being physically 
> damaged, then we need to work around that in the kernel. Otherwise there 
> is a bug in the kernel.
> 
> And if the kernel is buggy, we should fix the kernel. Period. :-)
> 
I agree with you in principle that if it can break the hardware then
either it shouldn't be exposed to user-side at all, or it should be
checked by the kernel/driver to prevent bad settings.

However, what about this sort of scenario: some codec has a speaker
volume range of 0..100, all of which are valid and safe. Manufacturer X
makes a device with an inadequate speaker that can be damaged with
volume settings above 80. How is that protected? There's nothing wrong
with the codec driver. There's no software at all for a speaker - it's
just a speaker. Where do we put a hard limit of 80 on a codec control
for one specific device? If it was my codec driver I don't want to have
to put a workaround for one specific device because manufacturer X chose
the wrong type of speaker. Or do we not care about the "stupid
manufacturer" cases and we're only interested in protecting the device
the control directly applies to - in this example it's a codec control
so it mustn't damage the codec but we don't care if poor hardware design
means it could damage other hardware connected to the codec.

Re: Splitting out controls

[Takashi Iwai]

On Fri, 16 Oct 2015 17:35:30 +0200,
Richard Fitzgerald wrote:
> 
> On Tue, 2015-10-13 at 09:07 +0200, David Henningsson wrote:
> > 
> > On 2015-10-12 22:59, James Cameron wrote:
> > > On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> > >> I've written up the minutes here below
> > >
> > > Thanks!
> > >
> > >> Splitting out controls: Takashi
> > >> ===============================
> > >>
> > >>   - Restricted access.  Consensus to restrict access to some controls due
> > >> to possibility of breaking HW at kernel level. i.e. prevent feeding
> > >> digital Mic into HP amp to prevent speaker over heating.
> > >
> > > I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
> > 
> > IIRC, the debate was over "do not expose dangerous controls to userspace 
> > at all" vs "expose dangerous controls controls only to root".
> > 
> > I'm strongly voting for "do not expose to userspace at all".
> > 
> > I personally believe that if the physical hardware can be set to state 
> > where it's bricked, the hardware itself is buggy.
> > 
> > If the hardware is buggy, this should be worked around in BIOS or 
> > whatever firmware is present on the machine. Otherwise there is a bug in 
> > BIOS.
> > 
> > If BIOS is buggy and cannot protect the machine from being physically 
> > damaged, then we need to work around that in the kernel. Otherwise there 
> > is a bug in the kernel.
> > 
> > And if the kernel is buggy, we should fix the kernel. Period. :-)
> > 
> I agree with you in principle that if it can break the hardware then
> either it shouldn't be exposed to user-side at all, or it should be
> checked by the kernel/driver to prevent bad settings.
> 
> However, what about this sort of scenario: some codec has a speaker
> volume range of 0..100, all of which are valid and safe. Manufacturer X
> makes a device with an inadequate speaker that can be damaged with
> volume settings above 80. How is that protected? There's nothing wrong
> with the codec driver. There's no software at all for a speaker - it's
> just a speaker. Where do we put a hard limit of 80 on a codec control
> for one specific device? If it was my codec driver I don't want to have
> to put a workaround for one specific device because manufacturer X chose
> the wrong type of speaker. Or do we not care about the "stupid
> manufacturer" cases and we're only interested in protecting the device
> the control directly applies to - in this example it's a codec control
> so it mustn't damage the codec but we don't care if poor hardware design
> means it could damage other hardware connected to the codec.

There is snd_soc_limit_volume() function to override the volume range
from a machine driver for such a purpose.  This was what was suggested
in the meeting.


Takashi

Re: Splitting out controls

[Richard Fitzgerald]

On Fri, 2015-10-16 at 18:00 +0200, Takashi Iwai wrote:
> On Fri, 16 Oct 2015 17:35:30 +0200,
> Richard Fitzgerald wrote:
> > 
> > On Tue, 2015-10-13 at 09:07 +0200, David Henningsson wrote:
> > > 
> > > On 2015-10-12 22:59, James Cameron wrote:
> > > > On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> > > >> I've written up the minutes here below
> > > >
> > > > Thanks!
> > > >
> > > >> Splitting out controls: Takashi
> > > >> ===============================
> > > >>
> > > >>   - Restricted access.  Consensus to restrict access to some controls due
> > > >> to possibility of breaking HW at kernel level. i.e. prevent feeding
> > > >> digital Mic into HP amp to prevent speaker over heating.
> > > >
> > > > I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
> > > 
> > > IIRC, the debate was over "do not expose dangerous controls to userspace 
> > > at all" vs "expose dangerous controls controls only to root".
> > > 
> > > I'm strongly voting for "do not expose to userspace at all".
> > > 
> > > I personally believe that if the physical hardware can be set to state 
> > > where it's bricked, the hardware itself is buggy.
> > > 
> > > If the hardware is buggy, this should be worked around in BIOS or 
> > > whatever firmware is present on the machine. Otherwise there is a bug in 
> > > BIOS.
> > > 
> > > If BIOS is buggy and cannot protect the machine from being physically 
> > > damaged, then we need to work around that in the kernel. Otherwise there 
> > > is a bug in the kernel.
> > > 
> > > And if the kernel is buggy, we should fix the kernel. Period. :-)
> > > 
> > I agree with you in principle that if it can break the hardware then
> > either it shouldn't be exposed to user-side at all, or it should be
> > checked by the kernel/driver to prevent bad settings.
> > 
> > However, what about this sort of scenario: some codec has a speaker
> > volume range of 0..100, all of which are valid and safe. Manufacturer X
> > makes a device with an inadequate speaker that can be damaged with
> > volume settings above 80. How is that protected? There's nothing wrong
> > with the codec driver. There's no software at all for a speaker - it's
> > just a speaker. Where do we put a hard limit of 80 on a codec control
> > for one specific device? If it was my codec driver I don't want to have
> > to put a workaround for one specific device because manufacturer X chose
> > the wrong type of speaker. Or do we not care about the "stupid
> > manufacturer" cases and we're only interested in protecting the device
> > the control directly applies to - in this example it's a codec control
> > so it mustn't damage the codec but we don't care if poor hardware design
> > means it could damage other hardware connected to the codec.
> 
> There is snd_soc_limit_volume() function to override the volume range
> from a machine driver for such a purpose.  This was what was suggested
> in the meeting.
> 
> 
> Takashi

OK, I didn't know that but I do now, so that wasn't a good example. But
how about something more complex. Let's say it was a set of coefficient
values for a filter. That's not a simple range check, it would need
specialized code to understand whether the coefficients were safe.

Really my point was that if all hardware was completely isolated from
other hardware you can error-check controls. But when you start hooking
up bits of hardware to other bits of hardware, it becomes more complex
defining what is safe, and who is responsible for checking that it is
safe, and where the knowledge about how to check it's safe should live.

That said, I'm not a fan of the "unless we can fix everything we
shouldn't fix anything" attitude. Fixing something is always better than
fixing nothing. So the fact that combining real hardware can introduce
new types of unsafe settings isn't an argument against error-checking
control values.

Re: Splitting out controls

[Takashi Iwai]

On Fri, 16 Oct 2015 18:31:54 +0200,
Richard Fitzgerald wrote:
> 
> On Fri, 2015-10-16 at 18:00 +0200, Takashi Iwai wrote:
> > On Fri, 16 Oct 2015 17:35:30 +0200,
> > Richard Fitzgerald wrote:
> > > 
> > > On Tue, 2015-10-13 at 09:07 +0200, David Henningsson wrote:
> > > > 
> > > > On 2015-10-12 22:59, James Cameron wrote:
> > > > > On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> > > > >> I've written up the minutes here below
> > > > >
> > > > > Thanks!
> > > > >
> > > > >> Splitting out controls: Takashi
> > > > >> ===============================
> > > > >>
> > > > >>   - Restricted access.  Consensus to restrict access to some controls due
> > > > >> to possibility of breaking HW at kernel level. i.e. prevent feeding
> > > > >> digital Mic into HP amp to prevent speaker over heating.
> > > > >
> > > > > I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
> > > > 
> > > > IIRC, the debate was over "do not expose dangerous controls to userspace 
> > > > at all" vs "expose dangerous controls controls only to root".
> > > > 
> > > > I'm strongly voting for "do not expose to userspace at all".
> > > > 
> > > > I personally believe that if the physical hardware can be set to state 
> > > > where it's bricked, the hardware itself is buggy.
> > > > 
> > > > If the hardware is buggy, this should be worked around in BIOS or 
> > > > whatever firmware is present on the machine. Otherwise there is a bug in 
> > > > BIOS.
> > > > 
> > > > If BIOS is buggy and cannot protect the machine from being physically 
> > > > damaged, then we need to work around that in the kernel. Otherwise there 
> > > > is a bug in the kernel.
> > > > 
> > > > And if the kernel is buggy, we should fix the kernel. Period. :-)
> > > > 
> > > I agree with you in principle that if it can break the hardware then
> > > either it shouldn't be exposed to user-side at all, or it should be
> > > checked by the kernel/driver to prevent bad settings.
> > > 
> > > However, what about this sort of scenario: some codec has a speaker
> > > volume range of 0..100, all of which are valid and safe. Manufacturer X
> > > makes a device with an inadequate speaker that can be damaged with
> > > volume settings above 80. How is that protected? There's nothing wrong
> > > with the codec driver. There's no software at all for a speaker - it's
> > > just a speaker. Where do we put a hard limit of 80 on a codec control
> > > for one specific device? If it was my codec driver I don't want to have
> > > to put a workaround for one specific device because manufacturer X chose
> > > the wrong type of speaker. Or do we not care about the "stupid
> > > manufacturer" cases and we're only interested in protecting the device
> > > the control directly applies to - in this example it's a codec control
> > > so it mustn't damage the codec but we don't care if poor hardware design
> > > means it could damage other hardware connected to the codec.
> > 
> > There is snd_soc_limit_volume() function to override the volume range
> > from a machine driver for such a purpose.  This was what was suggested
> > in the meeting.
> > 
> > 
> > Takashi
> 
> OK, I didn't know that but I do now, so that wasn't a good example. But
> how about something more complex. Let's say it was a set of coefficient
> values for a filter. That's not a simple range check, it would need
> specialized code to understand whether the coefficients were safe.
> 
> Really my point was that if all hardware was completely isolated from
> other hardware you can error-check controls. But when you start hooking
> up bits of hardware to other bits of hardware, it becomes more complex
> defining what is safe, and who is responsible for checking that it is
> safe, and where the knowledge about how to check it's safe should live.
> 
> That said, I'm not a fan of the "unless we can fix everything we
> shouldn't fix anything" attitude. Fixing something is always better than
> fixing nothing. So the fact that combining real hardware can introduce
> new types of unsafe settings isn't an argument against error-checking
> control values.

Sure, systems will get more complex in future and more dynamic via
f/w.  It's impossible to cover all statically in each driver.
As I mentioned in another mail, we should think of hardening in
multiple levels.


Takashi

Re: Splitting out controls

[Pierre-Louis Bossart]

On 10/16/15 11:00 AM, Takashi Iwai wrote:
> On Fri, 16 Oct 2015 17:35:30 +0200,
> Richard Fitzgerald wrote:
>>
>> On Tue, 2015-10-13 at 09:07 +0200, David Henningsson wrote:
>>>
>>> On 2015-10-12 22:59, James Cameron wrote:
>>>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>>>> I've written up the minutes here below
>>>>
>>>> Thanks!
>>>>
>>>>> Splitting out controls: Takashi
>>>>> ===============================
>>>>>
>>>>>    - Restricted access.  Consensus to restrict access to some controls due
>>>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>>>> digital Mic into HP amp to prevent speaker over heating.
>>>>
>>>> I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
>>>
>>> IIRC, the debate was over "do not expose dangerous controls to userspace
>>> at all" vs "expose dangerous controls controls only to root".
>>>
>>> I'm strongly voting for "do not expose to userspace at all".
>>>
>>> I personally believe that if the physical hardware can be set to state
>>> where it's bricked, the hardware itself is buggy.
>>>
>>> If the hardware is buggy, this should be worked around in BIOS or
>>> whatever firmware is present on the machine. Otherwise there is a bug in
>>> BIOS.
>>>
>>> If BIOS is buggy and cannot protect the machine from being physically
>>> damaged, then we need to work around that in the kernel. Otherwise there
>>> is a bug in the kernel.
>>>
>>> And if the kernel is buggy, we should fix the kernel. Period. :-)
>>>
>> I agree with you in principle that if it can break the hardware then
>> either it shouldn't be exposed to user-side at all, or it should be
>> checked by the kernel/driver to prevent bad settings.
>>
>> However, what about this sort of scenario: some codec has a speaker
>> volume range of 0..100, all of which are valid and safe. Manufacturer X
>> makes a device with an inadequate speaker that can be damaged with
>> volume settings above 80. How is that protected? There's nothing wrong
>> with the codec driver. There's no software at all for a speaker - it's
>> just a speaker. Where do we put a hard limit of 80 on a codec control
>> for one specific device? If it was my codec driver I don't want to have
>> to put a workaround for one specific device because manufacturer X chose
>> the wrong type of speaker. Or do we not care about the "stupid
>> manufacturer" cases and we're only interested in protecting the device
>> the control directly applies to - in this example it's a codec control
>> so it mustn't damage the codec but we don't care if poor hardware design
>> means it could damage other hardware connected to the codec.
>
> There is snd_soc_limit_volume() function to override the volume range
> from a machine driver for such a purpose.  This was what was suggested
> in the meeting.

To say that a configuration is 'safe' requires a breadth of information 
from thermal, acoustic and mechanical design that is just not available 
to kernel contributors who work in parallel on different building blocks 
and different configurations. Adding a safeguard in the machine driver 
is not practical: it's not uncommon for manufacturers to swap out 
speakers to save a couple of cents on a specific production batch and a 
value set in stone in a driver would not work for all those different 
batches.
So yes everyone should try and make sure that there are no 'dangerous' 
controls at their individual level but there is no way to protect 
hardware integrity in all cases if users punch-in values in alsamixer.

Re: Splitting out controls

[Takashi Iwai]

On Sat, 17 Oct 2015 17:54:09 +0200,
Pierre-Louis Bossart wrote:
> 
> On 10/16/15 11:00 AM, Takashi Iwai wrote:
> > On Fri, 16 Oct 2015 17:35:30 +0200,
> > Richard Fitzgerald wrote:
> >>
> >> On Tue, 2015-10-13 at 09:07 +0200, David Henningsson wrote:
> >>>
> >>> On 2015-10-12 22:59, James Cameron wrote:
> >>>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> >>>>> I've written up the minutes here below
> >>>>
> >>>> Thanks!
> >>>>
> >>>>> Splitting out controls: Takashi
> >>>>> ===============================
> >>>>>
> >>>>>    - Restricted access.  Consensus to restrict access to some controls due
> >>>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
> >>>>> digital Mic into HP amp to prevent speaker over heating.
> >>>>
> >>>> I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
> >>>
> >>> IIRC, the debate was over "do not expose dangerous controls to userspace
> >>> at all" vs "expose dangerous controls controls only to root".
> >>>
> >>> I'm strongly voting for "do not expose to userspace at all".
> >>>
> >>> I personally believe that if the physical hardware can be set to state
> >>> where it's bricked, the hardware itself is buggy.
> >>>
> >>> If the hardware is buggy, this should be worked around in BIOS or
> >>> whatever firmware is present on the machine. Otherwise there is a bug in
> >>> BIOS.
> >>>
> >>> If BIOS is buggy and cannot protect the machine from being physically
> >>> damaged, then we need to work around that in the kernel. Otherwise there
> >>> is a bug in the kernel.
> >>>
> >>> And if the kernel is buggy, we should fix the kernel. Period. :-)
> >>>
> >> I agree with you in principle that if it can break the hardware then
> >> either it shouldn't be exposed to user-side at all, or it should be
> >> checked by the kernel/driver to prevent bad settings.
> >>
> >> However, what about this sort of scenario: some codec has a speaker
> >> volume range of 0..100, all of which are valid and safe. Manufacturer X
> >> makes a device with an inadequate speaker that can be damaged with
> >> volume settings above 80. How is that protected? There's nothing wrong
> >> with the codec driver. There's no software at all for a speaker - it's
> >> just a speaker. Where do we put a hard limit of 80 on a codec control
> >> for one specific device? If it was my codec driver I don't want to have
> >> to put a workaround for one specific device because manufacturer X chose
> >> the wrong type of speaker. Or do we not care about the "stupid
> >> manufacturer" cases and we're only interested in protecting the device
> >> the control directly applies to - in this example it's a codec control
> >> so it mustn't damage the codec but we don't care if poor hardware design
> >> means it could damage other hardware connected to the codec.
> >
> > There is snd_soc_limit_volume() function to override the volume range
> > from a machine driver for such a purpose.  This was what was suggested
> > in the meeting.
> 
> To say that a configuration is 'safe' requires a breadth of information 
> from thermal, acoustic and mechanical design that is just not available 
> to kernel contributors who work in parallel on different building blocks 
> and different configurations. Adding a safeguard in the machine driver 
> is not practical: it's not uncommon for manufacturers to swap out 
> speakers to save a couple of cents on a specific production batch and a 
> value set in stone in a driver would not work for all those different 
> batches.
> So yes everyone should try and make sure that there are no 'dangerous' 
> controls at their individual level but there is no way to protect 
> hardware integrity in all cases if users punch-in values in alsamixer.

The question is *which* user.  If it's a system user for a daemon or a
management tool, it's fine.  But if it's a normal user, it's bad.  My
original proposal (the separation of access levels) came from this
POV.

I won't say that we can always save the world.  But there is certainly
a room for improvement for a little bit more safety than now.  At
least, if hardware manufacturer or system integrator already knows the
dangerous part, we should provide some easy way to paper over it.


Takashi

Re: Splitting out controls

[Alexander E. Patrakov]

17.10.2015 20:54, Pierre-Louis Bossart wrote:
> To say that a configuration is 'safe' requires a breadth of information
> from thermal, acoustic and mechanical design that is just not available
> to kernel contributors who work in parallel on different building blocks
> and different configurations. Adding a safeguard in the machine driver
> is not practical: it's not uncommon for manufacturers to swap out
> speakers to save a couple of cents on a specific production batch and a
> value set in stone in a driver would not work for all those different
> batches.

So, here is a strawman counterproposal.

Design some safe and hardware-agnostic form of bytecode. This bytecode 
should be able to access mixer controls by name or by index, get 
proposed values, and decide, using arithmetical and logical operations, 
whether the proposal is safe. Load this bytecode as firmware, just like 
we load various overrides in snd-hda-intel.

I.e. the mechanism remains in the kernel, but the policy becomes easily 
swappable by the board manufacturer.

-- 
Alexander E. Patrakov

Re: 'BATCH flag for USB' and 'ALSA Core Challenges'

[Takashi Sakamoto]

Hi Alexander,

On Oct 13 2015 23:44, Alexander E. Patrakov wrote:
> 13.10.2015 19:09, Takashi Sakamoto wrote:
>> Hi,
>>
>> (If I were in ±0200、I would have joined in the meeting...)
>>
>> There're some interesting issues in the minutes. Would I request someone
>> more explaination about it?
>>
>>> BATCH flag for USB: Arun.
>>> =========================
>>>   - Flag does not respond to reality, lets deprecate it. no users.
>>>   - Dylan: need to know transfer size for CRAS (uses extra samples for
>>> buffering).
>>>   - BATCH flag means period size transfers, applications that use new
>>> granularity API can ignore batch flag. Pierre: to implement.
>> The first item said 'BATCH flag should be deprecated', while
>> BLOCK_TRANSFER flag is not mentioned. Are there some discussions about
>> the differences between these two flags?
> 
> There is no conspiracy here, just inaccurately-written minutes. The
> proposal to deprecate was about the BLOCK_TRANSFER flag (because
> currently it means absolutely othing and has no users), although I
> support deprecation of the BATCH flag too.

In my understanding, these two flags relate to calculating the number of
transferred PCM frames within a period. Although, just menthioning about
one of them is a bit strange to me. So I asked it. I have no interests
in the others.

> Please see this email that explains the intended meaning of the flags:
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093750.html

Anyway, I think it's a worse way to change the interfaces between
userspace without enough documentation.

>> I think the APIs suppose that the number of PCM frames in one
>> transferring is the same as the number of PCM frames in one period of
>> buffer. PCM device driver developers must always satisfy this principle?
>> Or the APIs allow them to implement such differences and present proper
>> value to userspace?
> 
> The intention is to provide driver developers the means to express the
> situation with the transfer size and pointer granularity in a useful
> manner, and two boolean flags just don't cut it. So some new API is needed.

Ditto.


Regards

Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Splitting out controls

[Ricard Wanderlof]

On Sat, 17 Oct 2015, Takashi Iwai wrote:

> I won't say that we can always save the world.  But there is certainly
> a room for improvement for a little bit more safety than now.  At
> least, if hardware manufacturer or system integrator already knows the
> dangerous part, we should provide some easy way to paper over it.

Is there any form of statistics on more precisely what type of failures in 
this area occur in the real world? Speakers have been mentioned (and I 
think were the original issue that started the discussion) and are a clear 
case. One could imagine output stages being overdriven (even with no load) 
in some way, or mismatched signal levels which could cause an opamp to 
fail for instance. But have any such cases been reported? It would seem 
very hard to diagnose for one thing, unless a hardware manufacturer 
explicitly noted it in some documentation (which I suspect would be very 
unlikely for say a motherboard or sound card manufacturer).

My point is really that it might be a good idea to get some idea of the 
potential failure modes before introducing a mechanism to protect us from 
them.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: [Minutes] ELCE Audio mini conf.

[Mark Brown]

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

On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
> I've written up the minutes here below (including Vinod's minutes after
> I left for my flight). Please do feel free to correct or add any missing
> items.

Thanks Liam and Vinod for doing the minutes!

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: DP hotplug on USB C

[Mark Brown]

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

On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:

> HDA/gfx: relevant people not in room.
> =====================================
>  - Pierre: Hotplug DP over USB C required. Needs input from GFX folks.

Not just display people either, there's a bunch of core infrastructure
needed for handling USB C before we get onto any particular functions.
There's some people looking at it but it's not clear that they're
working together or heading towards mainline yet.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: Splitting out controls

[Mark Brown]

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

On Tue, Oct 13, 2015 at 09:07:20AM +0200, David Henningsson wrote:
> On 2015-10-12 22:59, James Cameron wrote:

James, please don't drop CCs (this is the convention for kernel lists).

> I personally believe that if the physical hardware can be set to state where
> it's bricked, the hardware itself is buggy.

> If the hardware is buggy, this should be worked around in BIOS or whatever
> firmware is present on the machine. Otherwise there is a bug in BIOS.

This is just not possible for most systems, there is no BIOS only a
bootoloader which hands off control to the kernel and stops running at
that point.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: Splitting out controls

[Mark Brown]

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

On Fri, Oct 16, 2015 at 04:24:02PM +0100, Richard Fitzgerald wrote:
> On Fri, 2015-10-16 at 09:49 -0500, Pierre-Louis Bossart wrote:

> > Bottom line we have to move to profiles, stop guessing values based on 
> > control names or avoid letting users poke random values in alsamixer. 
> > This just doesn't scale any more. thinking that the alsamixer 
> > command-line remains the default user-facing interface moving forward is 
> > just not right, it's a developer tool.

> I believe that you are misunderstanding David's point. Yes, there can be
> a large number of controls (the Wolfson WM8280 has over 400 controls,
> some Cirrus Logic codecs have nearly 900). The point was not whether the
> users should understand the meaning of all these controls but that they
> should be able to "play around and see what happens" without any risk of
> bricking their hardware. Regardless of whether what they are doing is
> meaningful or whether it's really feasible to set hundreds of controls
> correctly from the command line, they shouldn't damage the hardware. Not
> even root should have the ability to actually damage the hardware.

No, the point here is that it's unrealistically difficult to prevent
hardware damage on all systems without substantial work - even at the
simple level of constraining the maximum gain through the system we
currently lack the information to do that (never mind the capacity to do
the calculations), and getting the limits into the kernel would involve
carrying the machine specific callibration data around since it's not in
the firmwares of the relevant systems.

We can't even think about the possibility of doing this without getting
the controls into the topology and once we can do that we would need to
work out what we're trying to protect against and how.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: Splitting out controls

[Mark Brown]

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

On Fri, Oct 16, 2015 at 04:35:30PM +0100, Richard Fitzgerald wrote:

> However, what about this sort of scenario: some codec has a speaker
> volume range of 0..100, all of which are valid and safe. Manufacturer X
> makes a device with an inadequate speaker that can be damaged with
> volume settings above 80. How is that protected? There's nothing wrong
> with the codec driver. There's no software at all for a speaker - it's
> just a speaker. Where do we put a hard limit of 80 on a codec control
> for one specific device? If it was my codec driver I don't want to have
> to put a workaround for one specific device because manufacturer X chose
> the wrong type of speaker. Or do we not care about the "stupid
> manufacturer" cases and we're only interested in protecting the device
> the control directly applies to - in this example it's a codec control
> so it mustn't damage the codec but we don't care if poor hardware design
> means it could damage other hardware connected to the codec.

This is what machine drivers are for - providing system specific
integration.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: Splitting out controls

[Mark Brown]

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

On Sun, Oct 18, 2015 at 08:41:42AM +0200, Ricard Wanderlof wrote:

> Is there any form of statistics on more precisely what type of failures in 
> this area occur in the real world? Speakers have been mentioned (and I 
> think were the original issue that started the discussion) and are a clear 
> case. One could imagine output stages being overdriven (even with no load) 
> in some way, or mismatched signal levels which could cause an opamp to 
> fail for instance. But have any such cases been reported? It would seem 
> very hard to diagnose for one thing, unless a hardware manufacturer 
> explicitly noted it in some documentation (which I suspect would be very 
> unlikely for say a motherboard or sound card manufacturer).

Speaker related issues are overwhelmingly the most common thing here,
either straight burnout due to overdriving or mechanical damage caused
by vibrations.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

Re: Splitting out controls

[David Henningsson]

On 2015-10-30 03:36, Mark Brown wrote:
> On Tue, Oct 13, 2015 at 09:07:20AM +0200, David Henningsson wrote:
>> On 2015-10-12 22:59, James Cameron wrote:
>
> James, please don't drop CCs (this is the convention for kernel lists).
>
>> I personally believe that if the physical hardware can be set to state where
>> it's bricked, the hardware itself is buggy.
>
>> If the hardware is buggy, this should be worked around in BIOS or whatever
>> firmware is present on the machine. Otherwise there is a bug in BIOS.
>
> This is just not possible for most systems, there is no BIOS only a
> bootoloader which hands off control to the kernel and stops running at
> that point.

The BIOS can poke the hardware, set registers in such ways that volumes 
are limited. Registers that the kernel never touches. From my knowledge, 
this is more common than not on modern laptops with HDA codecs. A 
bootloader could potentially do the same - but in many embedded setups I 
suspect it makes just as much sense to do that during driver 
initialization instead.

Anyhow, we both agree on the fact that sometimes there is no hardware 
and no BIOS that protect us against hardware failure.

We currently have some kind of mechanism that protects the end user from 
unintentionally destroying the hardware. What we're arguing about is 
whether that mechanism should be in userspace (e g by having the GUI 
talk to UCM instead of amixer directly), or in the kernel.

I'm advocating having it as close to the hardware as possible - i e, in 
the kernel, because that protects additional classes of users from 
unintentionally destroying the hardware. As well as making it harder for 
malicious apps that intentionally want to do it.

There is no calculation that userspace can do, that the kernel can't do 
almost as easily, so I don't buy the argument that doing things in the 
kernel would be "unrealistically difficult".
However, it seems that we have done (IMO) such a gross mis-design that 
changing this isn't possible overnight. But can we then try to move in 
the right direction, instead of moving in the wrong one?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Splitting out controls

[James Cameron]

On Fri, Oct 30, 2015 at 09:36:39AM +0100, David Henningsson wrote:
> 
> 
> On 2015-10-30 03:36, Mark Brown wrote:
> >On Tue, Oct 13, 2015 at 09:07:20AM +0200, David Henningsson wrote:
> >>On 2015-10-12 22:59, James Cameron wrote:
> >
> >James, please don't drop CCs (this is the convention for kernel lists).
> >
> >>I personally believe that if the physical hardware can be set to state where
> >>it's bricked, the hardware itself is buggy.
> >
> >>If the hardware is buggy, this should be worked around in BIOS or whatever
> >>firmware is present on the machine. Otherwise there is a bug in BIOS.
> >
> >This is just not possible for most systems, there is no BIOS only a
> >bootoloader which hands off control to the kernel and stops running at
> >that point.
> 
> The BIOS can poke the hardware, set registers in such ways that
> volumes are limited. Registers that the kernel never touches.

I'm not sure how that would work.  The BIOS developers and the kernel
developers would have to agree on what registers are to be touched by
the BIOS only.  In my case, with the rt5631, the registers could not
be easily isolated in that fashion.  And if the kernel hit the reset
bit in one of the registers, whatever the BIOS had set would be lost.

Oh, and power management.  The codec can be powered down by suspend,
with the BIOS uninvolved in resume.

> From
> my knowledge, this is more common than not on modern laptops with
> HDA codecs. A bootloader could potentially do the same - but in many
> embedded setups I suspect it makes just as much sense to do that
> during driver initialization instead.
> 
> Anyhow, we both agree on the fact that sometimes there is no
> hardware and no BIOS that protect us against hardware failure.
> 
> We currently have some kind of mechanism that protects the end user
> from unintentionally destroying the hardware. What we're arguing
> about is whether that mechanism should be in userspace (e g by
> having the GUI talk to UCM instead of amixer directly), or in the
> kernel.
> 
> I'm advocating having it as close to the hardware as possible - i e,
> in the kernel, because that protects additional classes of users
> from unintentionally destroying the hardware. As well as making it
> harder for malicious apps that intentionally want to do it.
> 
> There is no calculation that userspace can do, that the kernel can't
> do almost as easily, so I don't buy the argument that doing things
> in the kernel would be "unrealistically difficult".
> However, it seems that we have done (IMO) such a gross mis-design
> that changing this isn't possible overnight. But can we then try to
> move in the right direction, instead of moving in the wrong one?
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

-- 
James Cameron
http://quozl.linux.org.au/

Re: Splitting out controls

[David Henningsson]

On 2015-10-30 09:53, James Cameron wrote:
> On Fri, Oct 30, 2015 at 09:36:39AM +0100, David Henningsson wrote:
>>
>>
>> On 2015-10-30 03:36, Mark Brown wrote:
>>> On Tue, Oct 13, 2015 at 09:07:20AM +0200, David Henningsson wrote:
>>>> On 2015-10-12 22:59, James Cameron wrote:
>>>
>>> James, please don't drop CCs (this is the convention for kernel lists).
>>>
>>>> I personally believe that if the physical hardware can be set to state where
>>>> it's bricked, the hardware itself is buggy.
>>>
>>>> If the hardware is buggy, this should be worked around in BIOS or whatever
>>>> firmware is present on the machine. Otherwise there is a bug in BIOS.
>>>
>>> This is just not possible for most systems, there is no BIOS only a
>>> bootoloader which hands off control to the kernel and stops running at
>>> that point.
>>
>> The BIOS can poke the hardware, set registers in such ways that
>> volumes are limited. Registers that the kernel never touches.
>
> I'm not sure how that would work.  The BIOS developers and the kernel
> developers would have to agree on what registers are to be touched by
> the BIOS only.  In my case, with the rt5631, the registers could not
> be easily isolated in that fashion.  And if the kernel hit the reset
> bit in one of the registers, whatever the BIOS had set would be lost.
>
> Oh, and power management.  The codec can be powered down by suspend,
> with the BIOS uninvolved in resume.

The way it has come to work on HDA is that the codec vendor has a number 
of "secret" registers, which they only tell the BIOS developers about, 
and (to our frustration) are quite reluctant to tell us about.

And certainly the BIOS is involved in setting these registers on S3 
resume, too.

One could imagine having ACPI calls for putting a codec in 
suspend/resume, but as I said, in many cases (such as yours) this just 
makes things more complicated. It's better dealt with in the kernel 
codec driver instead.

>> From
>> my knowledge, this is more common than not on modern laptops with
>> HDA codecs. A bootloader could potentially do the same - but in many
>> embedded setups I suspect it makes just as much sense to do that
>> during driver initialization instead.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Splitting out controls

[Mark Brown]

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

On Fri, Oct 30, 2015 at 10:04:30AM +0100, David Henningsson wrote:
> On 2015-10-30 09:53, James Cameron wrote:
> >On Fri, Oct 30, 2015 at 09:36:39AM +0100, David Henningsson wrote:

> >>The BIOS can poke the hardware, set registers in such ways that
> >>volumes are limited. Registers that the kernel never touches.

> >I'm not sure how that would work.  The BIOS developers and the kernel
> >developers would have to agree on what registers are to be touched by
> >the BIOS only.  In my case, with the rt5631, the registers could not
> >be easily isolated in that fashion.  And if the kernel hit the reset
> >bit in one of the registers, whatever the BIOS had set would be lost.

> >Oh, and power management.  The codec can be powered down by suspend,
> >with the BIOS uninvolved in resume.

> The way it has come to work on HDA is that the codec vendor has a number of
> "secret" registers, which they only tell the BIOS developers about, and (to
> our frustration) are quite reluctant to tell us about.

> And certainly the BIOS is involved in setting these registers on S3 resume,
> too.

This is all extremely specific to how HDA works on x86 systems with
UEFI and ACPI, it's not at all applicable generally.

> One could imagine having ACPI calls for putting a codec in suspend/resume,
> but as I said, in many cases (such as yours) this just makes things more
> complicated. It's better dealt with in the kernel codec driver instead.

This then gets us back into the problem of having to have very system
specific tuning in drivers somehow which is challenging to deploy.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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