[alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing

[Mark Brown]

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.

> 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).

> > 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.  :)

> > > > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20141201/e8ed94d7/attachment.sig>