On Wed, Oct 12, 2016 at 02:42:25PM +0200, Rafael J. Wysocki wrote: > On Wed, Oct 12, 2016 at 2:32 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Right, this is currently the idiomatic way to handle these things in > > ACPI unfortunately and it's what Windows (which I'm assuming is the > > alternative OSs you're referencing here!) does. Are people working on > > trying to move this forwards? > "Forward" in what way? To convince the Windows people to change their > ecosystem? No. Well, at least trying to get standard ACPI able to express these ideas better. > > What we've been doing up until now to support these systems in Linux is > > to have platform data in the driver that's matched via DMI information. > That is becoming more and more problematic, though, and generally > leads to inflated DMI tables in drivers which is not perfect to put it > lightly. Tell me about it - as far as I can see we're going to end up with a kernel patch for most laptops or tablets anyone tries to run Linux on in order to get audio working which is going to be a pretty miserable experience for users and distros. > > The Windows systems don't appear to be in the slightest bit interested > > in using the Linux bindings or updating their firmware to accomodate us > > so the sensible thing is to work in the same way as they do. > That would mean adding static data tables to drivers based on device > IDs somehow, but that pretty much would be what happened in the ARM > camp before DT, wouldn't it? Yes, that's what it means. It's pretty much a step backwards from what architectures doing board files have - no changes are needed in the drivers, instead when you add a new board you add a file which describes everything on the board including all the platform data for the device. It at least keeps all the support for the board and the matching code in one place rather than scattering it through drivers.
Attachment:
signature.asc
Description: PGP signature
