On Wed, Oct 12, 2016 at 4:59 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > 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. There are things that could be covered by ACPI proper (clocks and regulators support in particular), but some other things covered by DT in Linux really go beyond that. The "ports" and "endpoints" concept is a good example of that I think, as the use case is not in the traditional ACPI space (configuration and PM). I'm not really sure if the ASWG is the right venue to talk about that would-be standard even and if the ACPI spec is the right place to put it into. >> > 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. Exactly. >> > 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. Right. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
