[Ksummit-discuss] Unconference Read-Out: Device Model / Driver Properties / ACPI _DSD

[Ksummit-discuss] Unconference Read-Out: Device Model / Driver Properties / ACPI _DSD

[Darren Hart]

Device Model / Driver Properties / ACPI _DSD

This was a fairly uneventful session with only a few minor changes required to
the patches Mika Westerberg sent out for review. There was some valuable
consensus reached with respect to guiding principles and next steps.

ACPI _DSD Device Specific Data
   * _DSD+UUID provides for free-form hardware description to ACPI
   * This enables ACPI to provide DT schema data
   * Agreed that for existing drivers, the existing schemas should be common
     across implementations

Unified Driver Properties Interface
   * The device_property* interface allows for firmware-agnostic property access
     for drivers
   * Update drivers as needed - not in a giant sweeping patch (Grant)
   * For the few broken schemas, better to have the schema broken everywhere.
     Ultimately, the driver is in charge (Grant)
   * Some drivers will remain firmware-specific. In existing drivers, _DSD is
     primarily useful for pdata creation. Other uses include config augmentation
     of existing ACPI or PCI devices.
   * We will rename the interfaces to be closer to the of_* names (Olof)
   * We will eliminate the ops pointer in favor of checks for ACPI or OF in the
     two accessors. We can address this if the function count or the backend
     count grows above three or so. (Grant)
   * Where appropriate, subsystem accessors like those provided by gpiolib
     should be used as opposed to freeform properties. This is especially true
     whenever a DT or ACPI specific data format is required.

Enumeration / Driver Matching
   * Preference for new drivers is to get a new HID
   * For the existing 250+ OF aware drivers, we don't want to allocate so many
     new HIDs
   * We will use a common DT-compatible type HID, PRP0001 is preferred over
     PRP0000 to avoid unintentional matches. (HPA)
   * Such DSDs will include a "compatible" property which must also match by the
     driver core, using the DT match table.
   * Some existing OF-only drivers blindly assume OF and will break if matched
     to an ACPI enumerated/described device.
   * The "compatible" property should include some kind of ACPI namespacing,
     such as "acpi,<drivername>" to allow drivers to easily know where it came
     from, and to prevent matching if necessary (Olof, Grant)

Thanks,

Darren Hart
Intel Opensource Technology Center