Re: [PATCH 1/2] ASoC: rt5677: Add ACPI device probing

[Rafael J. Wysocki]

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.

Attachment: signature.asc
Description: This is a digitally signed message part.