Re: [RFC PATCH 0/2] Add software node support to regulator framework

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Wed, Jul 14, 2021 at 08:18:55PM +0100, Mark Brown wrote:
> On Wed, Jul 14, 2021 at 08:41:27PM +0300, Laurent Pinchart wrote:
> > On Wed, Jul 14, 2021 at 06:28:46PM +0100, Mark Brown wrote:
> > > On Wed, Jul 14, 2021 at 08:18:13PM +0300, Laurent Pinchart wrote:
> > > > It's only one data point, but we're seeing adoption of the ACPI
> > > > DT-in-DSD for camera. It's still not pretty of course.
> > >
> > > By non-Linux system vendors?
> >
> > For Windows-based machines, yes. It's fairly new, and the information I
> > have is that those machines may ship DSDT containing both Windows-style
> > (read: crap) data and Linux-style data for the same nodes. My fear is
> > that only the former will be properly tested and the latter will thus be
> > incorrect. The future will tell (I'm as usual very hopeful).
> 
> Adding the Intel audio people - it'd be good if we could get some
> similar stuff started for the audio things.  Sadly in these sorts of
> cases AIUI the Windows thing is broadly to match DMI data and supply
> platform data so it's more a case of just not having essential
> information in firmware, a bad format would be better TBH (assuming it's
> accurate which also requires loads of quirks...).

On the camera side, the Windows-based machines I've worked with (Skylake
and Kabylak) have data in the DSDT. There's data we can use directly,
and there's a lot that is hardcoded in the Windows driver (including
what voltage to program on the different outputs of an I2C-controlled
regulator - you get that wrong, you fry your camera). I believe Intel
provides a small set of reference designs with several options to the
OEMs, and I wouldn't be surprised if some of the data present in ACPI
that we don't know how to interpret would identify these options. I
don't think the Windows driver has DMI-based quirks, the driver isn't
machine-specific as far as I can tell.

For newer devices, ACPI should contain Windows data in a format that the
Windows team decides on its own, and data that is actually usable in the
_DSD for Linux. I've also heard that the power management would be
saner, with PM actually implemented in the DSDT. I haven't seen those
DSDT yet though.

-- 
Regards,

Laurent Pinchart