[alsa-devel] Fwd: [PATCH 1/1] SPI : spi-pxa2xx : fix spi init of WM510205 codec via ACPI (resend)

Christian Hartmann cornogle at googlemail.com
Mon Jun 29 10:12:47 CEST 2015


Hi,

I do not want to guess and I also want to minimize the try&error circle,
some questions are open yet:


2015-06-25 17:56 GMT+02:00 Mark Brown <broonie at kernel.org>:
> On Thu, Jun 25, 2015 at 04:44:07PM +0100, Charles Keepax wrote:
>> On Thu, Jun 25, 2015 at 03:58:53PM +0100, Mark Brown wrote:
>> > On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
>
>> > >                 Name (_HID, "WM510205")  // _HID: Hardware ID
>> > >                 Name (_CID, "WM510205")  // _CID: Compatible ID
>> > >                 Name (_DDN, "Wolfson Microelectronics Audio WM5102")
>
>> > Separately to the chip select discussion one thing to highlight here is
>> > that for some reason the BIOS is listing the device as "WM510205" rather
>> > than "WM5102" - do those extra numbers mean anything and does this mean
>> > that WM50120[1-4] and possibly higher numbers are also valid?
>
>> From my brief discussions with the Windows guys here on this
>> basically those last two digits are being used to inform the
>> Windows driver of use-case setup. So here it will set things up
>> for whatever the Window's driver considers to be setup "5".
>
> Yay for scalability and abstraction.
>
>> I think from the Linux side we can safely ignore those last two
>> digits. I expect that all systems of the same make and model
>> would report the same last two digits but that it might change
>> between models if the Windows driver is expected to something
>> differently for that model.
>
> Well, we might want to consider using this to set our platform data
> instead of the machine ID if people have just been copying a smallish
> set of reference designs, it might might make for a slightly smaller set
> of ID tables than the machine ID based stuff does.
>
> Due to the way ACPI ID matching works we'll also need to add every
> suffix individually to the table, we're looking for complete matches not
> substring matches here.


I saw in the file mfd/arizona/core.h
the ENUMs of the arizona_type and one of my first tries
was to simple add a new type (like WM510205 = 5,) but it was not clear
to me if this will work as expect. I had added in all
arizona-{core,spi,i2c) files the WM510205 but that was undeclared,
cause I did not added this ENUM yet...

What do you think??


More information about the Alsa-devel mailing list