On Monday, December 01, 2014 10:19:07 PM Mark Brown wrote:
On Mon, Dec 01, 2014 at 11:16:31PM +0100, Rafael J. Wysocki wrote:
On Monday, December 01, 2014 05:51:00 PM Mark Brown wrote:
The dream here is that people working on building systems, people working on Windows drivers and people working on Linux drivers will at some point be able to collaborate. If we're going to go off and do our own thing for Linux without talking to anyone that's not really addressing the issue.
Well, that's already going on in the DT land, isn't it? It has been going on for quite a while AFAICS.
In theory (and where it's actually relevant in practice to at least some extent) this stuff is all OS neutral, there's a definite willingness for it to be so.
There's also the option that Windows drivers start using _DSD themselves which is, I understand, the goal towards which the people working on at least audio are heading.
Technically, Windows driver writers can evaluate _DSD and handle the information the way we do, but I'm not sure if this is really convenient for them.
I'm not sure how convenient it is, though I'm reasonably sure a helper library could make it so.
Well, for that we'd need to find a Windows developer willing to write one I suppose ...
We use _DSD, because we want drivers to work with DT as well with ACPI without adding special DT-specific or ACPI-specific code to them. The people who work on Windows drivers don't have this problem, so as I said, if they care about Linux at all, that may be a good enough motivation for them to look at _DSD, but if they don't, I honestly don't see why they would do that.
They care about getting properties out, or at least they should, and in this market many of the device vendors care about Linux at least as much as they do Windows (sometimes even more than they care about Windows, there's overlap with the Android market).
OK
Note that all this discussion is pretty much about drivers for single devices which can be wired into the system in a flexible manner, even in a Windows world you won't vary the device ID. At present we're quirking on DMI.
So the answer to that in my view is: Use _DSD and allocate your own device IDs for Windows drivers to bind to.
Right, so we circle back to the original question about documenting those IDs and _DSD properties. :)
IDs are allocated by whoever owns the device description (the starting 3 or 4 code letters need to be registered via the UEFI Forum/ASWG).
Properties can be registered with the UEFI Forum via the ASWG too.
We also need a way of getting the word out to people that they should be doing this (also a problem no matter if we use PRP0001 or something UEFI specific).
What do you mean by "something UEFI specific"?
Sorry, I mean ACPI specific (UEFI forum).
Do you mean a special device ID of some sort, then?
No, just a regular one.
It's not just the device IDs you need, it's the properties too.
I suppose you have some specific examples in mind that I may not be familiar with and we may spend an arbitrary amount of time speaking past each other. :-)
Things like Documentation/devicetree/bindings/sound/wm8962.txt (at least the optional properties), basically "how is this device wired into the board" properties.
That's where we are today. Do you have any suggestions on what else we can do?
I'd like to see a space where people working with a device can publish what they've done in terms of firmware binding for it in a manner that might work for them; at present it seems like the UEFI forum is the best place to start doing that, there's the start of a register and process for updating it there at least.
That's correct.