lkml.org 
[lkml]   [2020]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device
    On Wed, Dec 02, 2020 at 02:48:47PM +0200, Laurent Pinchart wrote:
    > On Tue, Dec 01, 2020 at 09:34:58PM +0100, Hans de Goede wrote:
    > > On 12/1/20 8:21 PM, Andy Shevchenko wrote:
    > > > On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote:

    ...

    > > > I would rather ask Hans' opinion since he has quite an expertise with DMI for
    > > > good and bad.
    > >
    > > So generally there are 2 ways how things like this can go:
    > >
    > > 1) There is sufficient information in the ACPI table and we use data from the
    > > ACPI tables
    > >
    > > 2) There is unsufficient info in the ACPI tables (or we don't know how to
    > > get / interpret the data) and we use DMI quirks
    >
    > And this specific case I believe there is sufficient data in the ACPI
    > tables, as I don't believe the Windows driver uses DMI quirks, or comes
    > in the form of machine-specific binaries. We however don't know how to
    > interpret all the data, but that should hopefully get better over time
    > (especially as we'll get more data points, with ACPI dumps from machines
    > whose schematics have leaked).

    I think you are too optimistic about this part of Windows drivers.
    I would rather think about hardware stuck with the same frequencies which
    simply are hard coded in the Windows driver.

    I have description of ASL for this camera, but I don't see anything like this
    you are describing.

    > > Although we do often also use a combination, getting what we can from ACPI,
    > > combined with a set of defaults for what we cannot get from ACPI
    > > based on what reference designs use (IOW what most devices seem to have
    > > copy and pasted). Combined with DMI quirks for when the defaults do not
    > > work (which is quite often).
    > >
    > > Depending on if "not working because of wrong defaults" has bad side effects,
    > > another option is also to only allow the driver to load on devices which
    > > have the necessary info provided through a DMI match.
    >
    > Right now there shouldn't be bad side effects, but in the future we'll
    > need to setup a PMIC whose output voltages can be controlled, and
    > getting it wrong would be very bad. For that I'll definitely vote for
    > DMI match to start with, but I don't think that precludes using data
    > from ACPI. We could just prevent the driver from loading if the machine
    > isn't whitelisted in DMI matches, and still use ACPI data.

    I also think about DMI as a narrowing scope of supported platforms.

    --
    With Best Regards,
    Andy Shevchenko


    \
     
     \ /
      Last update: 2020-12-02 16:17    [W:2.745 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site