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. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
signature.asc
Description: This is a digitally signed message part.
