Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 15 Jul 2021 00:53:32 +0300
From:   Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To:     Mark Brown <broonie@kernel.org>
Cc:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Daniel Scally <djrscally@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Platform Driver <platform-driver-x86@vger.kernel.org>,
        Hans de Goede <hdegoede@redhat.com>,
        Mark Gross <mgross@linux.intel.com>,
        Maximilian Luz <luzmaximilian@gmail.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        kieran.bingham@ideasonboard.com,
        Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
        Cezary Rojewski <cezary.rojewski@intel.com>,
        Liam Girdwood <liam.r.girdwood@linux.intel.com>,
        Jie Yang <yang.jie@linux.intel.com>
Subject: Re: [RFC PATCH 0/2] Add software node support to regulator framework
Message-ID: <YO9c3Aofj0UJ1c3f@pendragon.ideasonboard.com>
References: <e17af9dc-78c0-adb8-1dfb-0698e7a4e394@gmail.com>
 <20210713152454.GC4098@sirena.org.uk>
 <CAHp75Ve=eY2KaPFgq3JDv1aGo_ajcNuKTV9rZQ+1f8uMJBocUw@mail.gmail.com>
 <20210713181837.GE4098@sirena.org.uk>
 <YO6RTh8ngNKZxzj+@pendragon.ideasonboard.com>
 <20210714165948.GG4719@sirena.org.uk>
 <YO8cVWNmUvU/LKGi@pendragon.ideasonboard.com>
 <20210714172846.GI4719@sirena.org.uk>
 <YO8hxyrHqY7K43wp@pendragon.ideasonboard.com>
 <20210714191855.GJ4719@sirena.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20210714191855.GJ4719@sirena.org.uk>
Precedence: bulk

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