Re: Splitting out controls

[Mark Brown <broonie@kernel.org>]

[-- 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 --]