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

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

[Christian Hartmann]

[-- Attachment #1: Type: text/plain, Size: 5481 bytes --]

Hi Mika, Dan et al.

@Dan : thank you, I will use get_maintainer.pl as of now.

@Mika: you mean I should prepare a new DSDT table and in this case
overwrite the SPI  value there with the 0 and load it (the DSDT table
) into a custom kernel build ?? I will do this (cause all what I want
is to enable the codec and to hear sound)

currently I have in the extracted DSDT table from this device the SPI1
controller for the "AUDI" device as seen in this snippet :

    Scope (_SB)
    {
        Device (LPEA)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "80860F28" /* Intel SST Audio DSP */)  //
_HID: Hardware ID
            Name (_CID, "80860F28" /* Intel SST Audio DSP */)  //
_CID: Compatible ID
            Name (_DDN, "Intel(R) Low Power Audio Controller -
80860F28")  // _DDN: DOS Device Name
            Name (_SUB, "17AA7004")  // _SUB: Subsystem ID
            Name (_UID, One)  // _UID: Unique ID
            Name (_DEP, Package (0x01)  // _DEP: Dependencies
            {
                ^SPI1.AUDI
            })
            Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0
            {
                PLPE
            })

.... some lines later follows the AUDI device with
            Device (AUDI)
            {
                Name (_HID, "WM510205")  // _HID: Hardware ID
                Name (_CID, "WM510205")  // _CID: Compatible ID
                Name (_DDN, "Wolfson Microelectronics Audio WM5102")
// _DDN: DOS Device Name
                Method (_CRS, 0, NotSerialized)  // _CRS: Current
Resource Settings
                {
                    Name (SBUF, ResourceTemplate ()
                    {
                        SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08,
                            ControllerInitiated, 0x007A1200, ClockPolarityLow,
                            ClockPhaseFirst, "\\_SB.SPI1",
                            0x00, ResourceConsumer, ,
                            )
                        GpioInt (Edge, ActiveLow, ExclusiveAndWake,
PullNone, 0x0000,
                            "\\_SB.GPO2", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0004
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000,
0x0000, IoRestrictionOutputOnly,
                            "\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0003
                            }
                        GpioIo (Exclusive, PullDefault, 0x0000,
0x0000, IoRestrictionOutputOnly,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0017
                            }
                    })
                    Return (SBUF) /* \_SB_.SPI1.AUDI._CRS.SBUF */
                }
....

I t makes sense to me, to change the current value(s) in the DSDT and
I have read about it to use a custom DSDT table but I am not 100% sure
yet (until I have tested it).

If I understand you correct, than all I have to do is to change the
'SPI1' string in this dsdt to SPI0 like
^SPI1.AUDI to ^SPI0.AUDI and this block here
SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08,
                            ControllerInitiated, 0x007A1200, ClockPolarityLow,
                            ClockPhaseFirst, "\\_SB.SPI1",
                            0x00, ResourceConsumer, ,

becomes
SpiSerialBus (0x0000, PolarityLow, FourWireMode, 0x08,
                            ControllerInitiated, 0x007A1200, ClockPolarityLow,
                            ClockPhaseFirst, "\\_SB.SPI0",
                            0x00, ResourceConsumer, ,

For this case, could you please have a look in the whole DSDT table
that I extract from this device? If nothing else seems relevant and
the current system dsdt has to be changed as suggested,  I will try
this out as soon as possible

@Jarkko : as you suggested , I attach the current system DSDT as a
binary. I have also disassembled,
and if someone needs it, I can also paste it somewhere else as a reference

After all I will assembly the new dsdt and include it in my custom
kernel builld as documented, but will wait for some new infos etc.


thank you for you answers @all

cheers
chris




2015-06-25 9:36 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> On Thu, Jun 25, 2015 at 09:29:31AM +0200, Christian Hartmann wrote:
>> Hello Maintainer(s)s of SPI,
>>
>> hope I got all of you maintainers now. This email was already sent out
>> last week to the alsa-devel list and I resent it here to you.
>>
>> I have one patch that enables the spi initialization of the WM510205 audio codec
>> Without the patch, this message indicates that the codec chip fails
>> with the current chipselect number in spi-pxa2xx:
>>
>>
>> [ 0.296256] pxa2xx-spi 80860F0E:00: cs1 >= max 1
>> [ 0.296270] spi_master spi32766: failed to add SPI device
>> WM510205:00 from ACPI
>>
>> So raise num_chipselect by one to enable the codec. The WM510202 is on
>> chipselect = 1.
>
> The hardware only has one chipselect.
>
> You can fix this by specifying the correct chipselect in the ACPI
> SpiSerialBus connector:
>
>        SpiSerialBus (0, PolarityLow, FourWireMode, 8, ControllerInitiated, ..
>
> First parameter is the chipselect.

[-- Attachment #2: DSDT_sys_firmware_acpi_tables.bin --]
[-- Type: application/octet-stream, Size: 42677 bytes --]

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

[Mika Westerberg]

On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
> Hi Mika, Dan et al.
> 
> @Dan : thank you, I will use get_maintainer.pl as of now.
> 
> @Mika: you mean I should prepare a new DSDT table and in this case
> overwrite the SPI  value there with the 0 and load it (the DSDT table
> ) into a custom kernel build ?? I will do this (cause all what I want
> is to enable the codec and to hear sound)

I thought that you are developing a new system where you can affect the
firmware/BIOS source.

Obviously this is not the case so you have close to zero possibility to
get the vendor to fix the broken firmware :-/

> currently I have in the extracted DSDT table from this device the SPI1
> controller for the "AUDI" device as seen in this snippet :
> 
>     Scope (_SB)
>     {
>         Device (LPEA)
>         {
>             Name (_ADR, Zero)  // _ADR: Address
>             Name (_HID, "80860F28" /* Intel SST Audio DSP */)  //
> _HID: Hardware ID
>             Name (_CID, "80860F28" /* Intel SST Audio DSP */)  //
> _CID: Compatible ID
>             Name (_DDN, "Intel(R) Low Power Audio Controller -
> 80860F28")  // _DDN: DOS Device Name
>             Name (_SUB, "17AA7004")  // _SUB: Subsystem ID
>             Name (_UID, One)  // _UID: Unique ID
>             Name (_DEP, Package (0x01)  // _DEP: Dependencies
>             {
>                 ^SPI1.AUDI
>             })
>             Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0
>             {
>                 PLPE
>             })
> 
> .... some lines later follows the AUDI device with
>             Device (AUDI)
>             {
>                 Name (_HID, "WM510205")  // _HID: Hardware ID
>                 Name (_CID, "WM510205")  // _CID: Compatible ID
>                 Name (_DDN, "Wolfson Microelectronics Audio WM5102")
> // _DDN: DOS Device Name
>                 Method (_CRS, 0, NotSerialized)  // _CRS: Current
> Resource Settings
>                 {
>                     Name (SBUF, ResourceTemplate ()
>                     {
>                         SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08,
>                             ControllerInitiated, 0x007A1200, ClockPolarityLow,
>                             ClockPhaseFirst, "\\_SB.SPI1",
>                             0x00, ResourceConsumer, ,
>                             )

This is wrong as, like I said the Intel Baytrail SPI host controller
only supports one native chipselect. 

>                         GpioInt (Edge, ActiveLow, ExclusiveAndWake,
> PullNone, 0x0000,
>                             "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>                             )
>                             {   // Pin list
>                                 0x0004
>                             }
>                         GpioIo (Exclusive, PullDefault, 0x0000,
> 0x0000, IoRestrictionOutputOnly,
>                             "\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,
>                             )
>                             {   // Pin list
>                                 0x0003
>                             }
>                         GpioIo (Exclusive, PullDefault, 0x0000,
> 0x0000, IoRestrictionOutputOnly,
>                             "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>                             )
>                             {   // Pin list
>                                 0x0017
>                             }
>                     })
>                     Return (SBUF) /* \_SB_.SPI1.AUDI._CRS.SBUF */
>                 }
> ....
> 
> I t makes sense to me, to change the current value(s) in the DSDT and
> I have read about it to use a custom DSDT table but I am not 100% sure
> yet (until I have tested it).
> 
> If I understand you correct, than all I have to do is to change the
> 'SPI1' string in this dsdt to SPI0 like
> ^SPI1.AUDI to ^SPI0.AUDI and this block here
> SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08,
>                             ControllerInitiated, 0x007A1200, ClockPolarityLow,
>                             ClockPhaseFirst, "\\_SB.SPI1",
>                             0x00, ResourceConsumer, ,
> 
> becomes
> SpiSerialBus (0x0000, PolarityLow, FourWireMode, 0x08,
>                             ControllerInitiated, 0x007A1200, ClockPolarityLow,
>                             ClockPhaseFirst, "\\_SB.SPI0",
>                             0x00, ResourceConsumer, ,

Only change the chipselect above. \\SB.SPI1 is the host controller and
that's probably correct.

It is worth a try using the custom DSDT. If it brings you working audio
then we need to figure out how to work this around in the kernel.

BTW, does the audio work in Windows?

I somehow suspect that it just ignores the chipselect in the SPI driver
which might explain why it works (if it works, that is).
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

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?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Charles Keepax]

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

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.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Charles Keepax]

On Thu, Jun 25, 2015 at 04:56:12PM +0100, Mark Brown wrote:
> 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.

Well it certainly is abstract.

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

>From what I can gather currently yes every system has a different
suffix so it should be fine to skip checking the machine ID and
just use the ACPI ID to select the pdata.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Thu, Jun 25, 2015 at 05:11:08PM +0100, Charles Keepax wrote:
> On Thu, Jun 25, 2015 at 04:56:12PM +0100, Mark Brown wrote:

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

> Well it certainly is abstract.

Just not the same abstraction the rest of the world is using there :(

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Christian Hartmann]

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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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??
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Mon, Jun 29, 2015 at 10:12:47AM +0200, Christian Hartmann wrote:
> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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??

I think you are confusing two things here. You shouldn't need to
add any new entries to the arizona_type enum there is already an
entry for wm5102. "WM510205" is what needs to go into the ACPI
match table, we were just discussing that it is probably enough
to look up some fixed pdata to configure the driver for this
device, rather than needing to seperately check the machine ID.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pierre-Louis Bossart]

On 6/25/15 5:44 PM, 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".
>
> 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.

Here's the summary of what a valid _HID  should look like. It took me a 
couple of days to gather the rules from different sources, I hope it 
helps others figure things out.
-Pierre

_HID must be one of these forms:
- "AAA####” or EisaID(“AAA####”) where A is an uppercase letter and # is 
a hex digit. The AAA PNP Vendor ID consists of 3 characters, verified on
http://www.uefi.org/sites/default/files/resources/PNPID_List.pdf

- "ACPI####” where # is a hex digit

- "NNNN####” where N is an uppercase letter or decimal digit (0-9) and # 
is a hex digit (ACPI 5.0).
The NNNN Vendor ID can be
--> a PCI ID: 4 hex digits (0-9 and A-F), verified on
https://www.pcisig.com/membership/vid_search/
--> or an ACPI ID: 4 characters, each character being either an 
uppercase letter (A-Z) or a numeral (0-9), verified on
http://www.uefi.org/sites/default/files/resources/ACPIID_List.pdf




--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

On Fri, Jun 26, 2015 at 01:46:50PM +0200, Pierre-Louis Bossart wrote:
> On 6/25/15 5:44 PM, Charles Keepax wrote:

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

> Here's the summary of what a valid _HID  should look like. It took me a
> couple of days to gather the rules from different sources, I hope it helps
> others figure things out.

None of which really affact the matching that the kernel does since
whatever form the string is generated in we need to do a full string
match (nor do they correspond to what it seems the Wolfson drivers have
invented but that's a separate issue).  Yay standards.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Christian Hartmann]

Hi,

@all

FYI: I can confirm that with the changed DSDT.dsl file and loading
the new custom DSDT table, I do not need this patch mentioned above.

So the patch is indeed only needed, as long as there is no
BIOS (DSDT change by manufacturer) update available.

In this case special case a custom DSDT table is loaded to
 fix the by ACPI wrongly set of SPIController to  1, which must be 0.

On the other hand I have now an tained kernel too :/ cause of the unset
"Select only drivers that don't need compile-time external firmware" and
 the ''Include Custom DSDT' options.


The dmesg message seems to be the same as with the patch applied but
with the current system DSDT table: here

[    0.000000] Linux version 4.1.0.60-rc0
(b23-/dWd7jAXU0ArCNBCT51S8nv7hrKZn54GTYPjME8WTGQ@public.gmane.org) (gcc version 4.8.3 20140911 (Red Hat
4.8.3-9) (GCC) ) #199 SMP Fri Jun 26
13:47:46 CEST 2015
...
[    0.000000] ACPI: Early table checksum verification disabled
...
[    5.916597] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    5.916733] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    5.926671] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    5.926681] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    5.926805] spi spi-WM510205:00: checking WM510205 with bmp180
[    5.926812] spi spi-WM510205:00: checking WM510205 with bmp181
[    5.926816] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    5.926843] arizona spi-WM510205:00: acpi_match_device() first,
than via spi_get_device_id().
[    5.926849] arizona spi-WM510205:00: matched ACPI ID and data
[    5.926853] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    5.926857] arizona spi-WM510205:00: regmap set to wm5102_spi
[    5.927665] arizona spi-WM510205:00: arizona_spi_probe done, call
and return of  arizona_dev_init
[    5.927759] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.927782] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
[    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
[    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00

notice : some of these messages above are coming from local added dev_err();

cheers
chris


2015-06-26 13:58 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> On Fri, Jun 26, 2015 at 01:46:50PM +0200, Pierre-Louis Bossart wrote:
>> On 6/25/15 5:44 PM, Charles Keepax wrote:
>
>> >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.
>
>> Here's the summary of what a valid _HID  should look like. It took me a
>> couple of days to gather the rules from different sources, I hope it helps
>> others figure things out.
>
> None of which really affact the matching that the kernel does since
> whatever form the string is generated in we need to do a full string
> match (nor do they correspond to what it seems the Wolfson drivers have
> invented but that's a separate issue).  Yay standards.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hello,

Thank you so far at all.

I have sent an email about the Bug in this firmware to lenovo.
So I can work on with thhe custom DSDT and will try again to get ACPI
working with the WM5102.

As soon as Lenovo has a new BIOS available, I will report that but for
the case their will not be a new BIOS update in the near future, what
should we do with the patch??
As some suggested, its a firmware bug workaround.

If some Intel developers have some ideas or better some patches in the
right directions to let this device initialize correctly and to bind
this with the Baytrail (intel_sst_acpi) sound system, than I would be
happy to test these patches (or to know the infos I got from you).

cheers
chris


2015-06-29 9:27 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
> Hi,
>
> @all
>
> FYI: I can confirm that with the changed DSDT.dsl file and loading
> the new custom DSDT table, I do not need this patch mentioned above.
>
> So the patch is indeed only needed, as long as there is no
> BIOS (DSDT change by manufacturer) update available.
>
> In this case special case a custom DSDT table is loaded to
>  fix the by ACPI wrongly set of SPIController to  1, which must be 0.
>
> On the other hand I have now an tained kernel too :/ cause of the unset
> "Select only drivers that don't need compile-time external firmware" and
>  the ''Include Custom DSDT' options.
>
>
> The dmesg message seems to be the same as with the patch applied but
> with the current system DSDT table: here
>
> [    0.000000] Linux version 4.1.0.60-rc0
> (b23-/dWd7jAXU0ArCNBCT51S8nv7hrKZn54GTYPjME8WTGQ@public.gmane.org) (gcc version 4.8.3 20140911 (Red Hat
> 4.8.3-9) (GCC) ) #199 SMP Fri Jun 26
> 13:47:46 CEST 2015
> ...
> [    0.000000] ACPI: Early table checksum verification disabled
> ...
> [    5.916597] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
> [    5.916733] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
> [    5.926671] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    5.926681] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    5.926805] spi spi-WM510205:00: checking WM510205 with bmp180
> [    5.926812] spi spi-WM510205:00: checking WM510205 with bmp181
> [    5.926816] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    5.926843] arizona spi-WM510205:00: acpi_match_device() first,
> than via spi_get_device_id().
> [    5.926849] arizona spi-WM510205:00: matched ACPI ID and data
> [    5.926853] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    5.926857] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    5.927665] arizona spi-WM510205:00: arizona_spi_probe done, call
> and return of  arizona_dev_init
> [    5.927759] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    5.927782] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
>
> notice : some of these messages above are coming from local added dev_err();
>
> cheers
> chris
>
>
> 2015-06-26 13:58 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> On Fri, Jun 26, 2015 at 01:46:50PM +0200, Pierre-Louis Bossart wrote:
>>> On 6/25/15 5:44 PM, Charles Keepax wrote:
>>
>>> >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.
>>
>>> Here's the summary of what a valid _HID  should look like. It took me a
>>> couple of days to gather the rules from different sources, I hope it helps
>>> others figure things out.
>>
>> None of which really affact the matching that the kernel does since
>> whatever form the string is generated in we need to do a full string
>> match (nor do they correspond to what it seems the Wolfson drivers have
>> invented but that's a separate issue).  Yay standards.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Mon, Jun 29, 2015 at 09:46:41AM +0200, Christian Hartmann wrote:
> Hello,

Please don't top post.

> I have sent an email about the Bug in this firmware to lenovo.
> So I can work on with thhe custom DSDT and will try again to get ACPI
> working with the WM5102.

> As soon as Lenovo has a new BIOS available, I will report that but for
> the case their will not be a new BIOS update in the near future, what
> should we do with the patch??
> As some suggested, its a firmware bug workaround.

We'll need to work around this, I wouldn't hold your breath on Lenovo
fixing their BIOS and even if they do we really ought to support the
shipped BIOS since not everyone is going to want to upgrade (or know to
do that).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:

> FYI: I can confirm that with the changed DSDT.dsl file and loading
> the new custom DSDT table, I do not need this patch mentioned above.

Are you sure?

> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00

The above is saying that SPI I/O to the device isn't working - the
device ID is not being read back successfully.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Christian Hartmann]

Hi,


2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
>
>> FYI: I can confirm that with the changed DSDT.dsl file and loading
>> the new custom DSDT table, I do not need this patch mentioned above.
>
> Are you sure?
[    0.000000] ACPI: Override [DSDT-CS-02   ], this is unsafe: tainting kernel
[    0.000000] Disabling lock debugging due to kernel taint
[    0.000000] ACPI: DSDT 0x0000000078CE2000 Logical table override,
new table: 0x00000000C0EBB470
[    0.000000] ACPI: DSDT 0x00000000C0EBB470 00A6A2 (v02 LENOVO CS-02
  00000001 INTL 20150410)
[    0.000000] ACPI: Local APIC address 0xfee00000
...
[    7.308741] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    7.308837] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    7.308978] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    7.309002] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
...

without the DSDT load, I must have this patch applied,
otherwise the wm5102 will not be attached.
I have checked it both and yes I am really sure since yesterday.

>
>> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
>> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
>> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
>
> The above is saying that SPI I/O to the device isn't working - the
> device ID is not being read back successfully.

Ok that is the next problem that must be solved.
I have yesterday made a patchset where I have added
the enum type 5, but as you said already,
that was not needed.
All what I see the same: : Unknown device ID: ffff

So where I have to look now or what can I do to let this device id
register correctly?
I hope the baytrail machine driver is easy peasy to add, but here I
stuck at the moment.

cheers
Christian

-- 
--
......oooO..............
.....(....).....Oooo...
......)../.....(....)....
.....(_/.......)../.....
...............(_/.......
... I WAS ..............
.......... HERE...... ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:

> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff

> > The above is saying that SPI I/O to the device isn't working - the
> > device ID is not being read back successfully.

> Ok that is the next problem that must be solved.
> I have yesterday made a patchset where I have added
> the enum type 5, but as you said already,
> that was not needed.
> All what I see the same: : Unknown device ID: ffff

> So where I have to look now or what can I do to let this device id
> register correctly?
> I hope the baytrail machine driver is easy peasy to add, but here I
> stuck at the moment.

You need to look at the SPI controller configuration still - like I say
that's saying that I/O to the device is not working correctly.  Most
likely there is some meaning to the chip select setting that's being
used and so the main chip select is not doing the job.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Charles Keepax]

On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
> Hi,
> 
> 
> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> >
> > The above is saying that SPI I/O to the device isn't working - the
> > device ID is not being read back successfully.
> 
> Ok that is the next problem that must be solved.
> I have yesterday made a patchset where I have added
> the enum type 5, but as you said already,
> that was not needed.
> All what I see the same: : Unknown device ID: ffff
> 
> So where I have to look now or what can I do to let this device id
> register correctly?
> I hope the baytrail machine driver is easy peasy to add, but here I
> stuck at the moment.

As I said in my other emails the next step is to work out what
the reset and ldoena gpio's are. You won't be able to read the
device ID until you have those setup. Unfortunately, finding the
right GPIOs is likely to be a bit of a chore, I will see if I can
find anything out from the Windows guys at this end.

Also can you check that the arizona-ldo1 regulator is built in I
am surprised that is falling back to the dummy regulator.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
>> Hi,
>>
>>
>> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
>> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
>> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
>> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
>> >
>> > The above is saying that SPI I/O to the device isn't working - the
>> > device ID is not being read back successfully.
>>
>> Ok that is the next problem that must be solved.
>> I have yesterday made a patchset where I have added
>> the enum type 5, but as you said already,
>> that was not needed.
>> All what I see the same: : Unknown device ID: ffff
>>
>> So where I have to look now or what can I do to let this device id
>> register correctly?
>> I hope the baytrail machine driver is easy peasy to add, but here I
>> stuck at the moment.
>
> As I said in my other emails the next step is to work out what
> the reset and ldoena gpio's are. You won't be able to read the
> device ID until you have those setup. Unfortunately, finding the
> right GPIOs is likely to be a bit of a chore, I will see if I can
> find anything out from the Windows guys at this end.
>
> Also can you check that the arizona-ldo1 regulator is built in I
> am surprised that is falling back to the dummy regulator.
>
> Thanks,
> Charles

Hi,

I just want to ask, if the windows guys have such infos about the
gpios in question (reset,ldoena) and of course the irq details.

I am thinking actually to get a second device with Win installed, so
that I can get more infos which I really need here.
Anyway  I can also provide more infos here (if its not against valid laws :) )
But indeeed I can need some hints where to put the pdata structure.

I have some more questions that I want to ask/discuss later on irc -
if its possible

cheers
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> > On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
> >> Hi,
> >>
> >>
> >> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> >> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
> >> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> >> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
> >> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> >> >
> >> > The above is saying that SPI I/O to the device isn't working - the
> >> > device ID is not being read back successfully.
> >>
> >> Ok that is the next problem that must be solved.
> >> I have yesterday made a patchset where I have added
> >> the enum type 5, but as you said already,
> >> that was not needed.
> >> All what I see the same: : Unknown device ID: ffff
> >>
> >> So where I have to look now or what can I do to let this device id
> >> register correctly?
> >> I hope the baytrail machine driver is easy peasy to add, but here I
> >> stuck at the moment.
> >
> > As I said in my other emails the next step is to work out what
> > the reset and ldoena gpio's are. You won't be able to read the
> > device ID until you have those setup. Unfortunately, finding the
> > right GPIOs is likely to be a bit of a chore, I will see if I can
> > find anything out from the Windows guys at this end.
> >
> > Also can you check that the arizona-ldo1 regulator is built in I
> > am surprised that is falling back to the dummy regulator.
> >
> > Thanks,
> > Charles
> 
> Hi,
> 
> I just want to ask, if the windows guys have such infos about the
> gpios in question (reset,ldoena) and of course the irq details.

Still chasing them up on this.

> 
> I am thinking actually to get a second device with Win installed, so
> that I can get more infos which I really need here.
> Anyway  I can also provide more infos here (if its not against valid laws :) )
> But indeeed I can need some hints where to put the pdata structure.

I think in this case we need to hard code the pdata into the
driver. Probably in arizona-core.c would be the best place.

> 
> I have some more questions that I want to ask/discuss later on irc -
> if its possible

Yeah I shall jump on and you can give me a shout.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Tue, Jul 07, 2015 at 10:56:13AM +0100, Charles Keepax wrote:
> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:

> > I am thinking actually to get a second device with Win installed, so
> > that I can get more infos which I really need here.
> > Anyway  I can also provide more infos here (if its not against valid laws :) )
> > But indeeed I can need some hints where to put the pdata structure.

> I think in this case we need to hard code the pdata into the
> driver. Probably in arizona-core.c would be the best place.

This is how other drivers with ACPI support like the Realtek ones do
this.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Charles Keepax]

On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> > On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
> >> Hi,
> >>
> >>
> >> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> >> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
> >> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> >> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
> >> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> >> >
> >> > The above is saying that SPI I/O to the device isn't working - the
> >> > device ID is not being read back successfully.
> >>
> >> Ok that is the next problem that must be solved.
> >> I have yesterday made a patchset where I have added
> >> the enum type 5, but as you said already,
> >> that was not needed.
> >> All what I see the same: : Unknown device ID: ffff
> >>
> >> So where I have to look now or what can I do to let this device id
> >> register correctly?
> >> I hope the baytrail machine driver is easy peasy to add, but here I
> >> stuck at the moment.
> >
> > As I said in my other emails the next step is to work out what
> > the reset and ldoena gpio's are. You won't be able to read the
> > device ID until you have those setup. Unfortunately, finding the
> > right GPIOs is likely to be a bit of a chore, I will see if I can
> > find anything out from the Windows guys at this end.
> >
> > Also can you check that the arizona-ldo1 regulator is built in I
> > am surprised that is falling back to the dummy regulator.
> >
> > Thanks,
> > Charles
> 
> Hi,
> 
> I just want to ask, if the windows guys have such infos about the
> gpios in question (reset,ldoena) and of course the irq details.
> 
> I am thinking actually to get a second device with Win installed, so
> that I can get more infos which I really need here.
> Anyway  I can also provide more infos here (if its not against valid laws :) )
> But indeeed I can need some hints where to put the pdata structure.
> 
> I have some more questions that I want to ask/discuss later on irc -
> if its possible
> 
> cheers
> Chris

Oh yeah my nick on IRC is ckeepax, also could you send me through
a full copy of the dsdt you included a snippet of in your earlier
emails? The Windows guys here are saying the GPIOs should
actually be in the ACPI tables and that contray to what I
understood from my last conversation with them only some of the
setup for the driver is encoded in the single magic number.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> > On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
> >> Hi,
> >>
> >>
> >> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> >> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
> >> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> >> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
> >> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> >> >
> >> > The above is saying that SPI I/O to the device isn't working - the
> >> > device ID is not being read back successfully.
> >>
> >> Ok that is the next problem that must be solved.
> >> I have yesterday made a patchset where I have added
> >> the enum type 5, but as you said already,
> >> that was not needed.
> >> All what I see the same: : Unknown device ID: ffff
> >>
> >> So where I have to look now or what can I do to let this device id
> >> register correctly?
> >> I hope the baytrail machine driver is easy peasy to add, but here I
> >> stuck at the moment.
> >
> > As I said in my other emails the next step is to work out what
> > the reset and ldoena gpio's are. You won't be able to read the
> > device ID until you have those setup. Unfortunately, finding the
> > right GPIOs is likely to be a bit of a chore, I will see if I can
> > find anything out from the Windows guys at this end.
> >
> > Also can you check that the arizona-ldo1 regulator is built in I
> > am surprised that is falling back to the dummy regulator.
> >
> > Thanks,
> > Charles
> 
> Hi,
> 
> I just want to ask, if the windows guys have such infos about the
> gpios in question (reset,ldoena) and of course the irq details.
> 
> I am thinking actually to get a second device with Win installed, so
> that I can get more infos which I really need here.
> Anyway  I can also provide more infos here (if its not against valid laws :) )
> But indeeed I can need some hints where to put the pdata structure.
> 
> I have some more questions that I want to ask/discuss later on irc -
> if its possible
> 
> cheers
> Chris

Ok so it does indeed seem the information I got from the Windows
team was not fully accurate last time. The IRQ pin, reset line
and LDO enable are actually specified in ACPI. This block here
has them:

GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
	 "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{   // Pin list
	0x0004
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
	"\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,)
{   // Pin list
	0x0003
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
	"\\_SB.GPO1", 0x00, ResourceConsumer, ,)
{   // Pin list
	0x0017
}

The order here being:

1) IRQ
2) Reset GPIO
3) LDOENA GPIO

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

2015-07-13 11:53 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
>> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
>> > On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
>> >> Hi,
>> >>
>> >>
>> >> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> >> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
>> >> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
>> >> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
>> >> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
>> >> >
>> >> > The above is saying that SPI I/O to the device isn't working - the
>> >> > device ID is not being read back successfully.
>> >>
>> >> Ok that is the next problem that must be solved.
>> >> I have yesterday made a patchset where I have added
>> >> the enum type 5, but as you said already,
>> >> that was not needed.
>> >> All what I see the same: : Unknown device ID: ffff
>> >>
>> >> So where I have to look now or what can I do to let this device id
>> >> register correctly?
>> >> I hope the baytrail machine driver is easy peasy to add, but here I
>> >> stuck at the moment.
>> >
>> > As I said in my other emails the next step is to work out what
>> > the reset and ldoena gpio's are. You won't be able to read the
>> > device ID until you have those setup. Unfortunately, finding the
>> > right GPIOs is likely to be a bit of a chore, I will see if I can
>> > find anything out from the Windows guys at this end.
>> >
>> > Also can you check that the arizona-ldo1 regulator is built in I
>> > am surprised that is falling back to the dummy regulator.
>> >
>> > Thanks,
>> > Charles
>>
>> Hi,
>>
>> I just want to ask, if the windows guys have such infos about the
>> gpios in question (reset,ldoena) and of course the irq details.
>>
>> I am thinking actually to get a second device with Win installed, so
>> that I can get more infos which I really need here.
>> Anyway  I can also provide more infos here (if its not against valid laws :) )
>> But indeeed I can need some hints where to put the pdata structure.
>>
>> I have some more questions that I want to ask/discuss later on irc -
>> if its possible
>>
>> cheers
>> Chris
>
> Ok so it does indeed seem the information I got from the Windows
> team was not fully accurate last time. The IRQ pin, reset line
> and LDO enable are actually specified in ACPI. This block here
> has them:
>
> GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
>          "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
> {   // Pin list
>         0x0004
> }
> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>         "\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,)
> {   // Pin list
>         0x0003
> }
> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>         "\\_SB.GPO1", 0x00, ResourceConsumer, ,)
> {   // Pin list
>         0x0017
> }
>
> The order here being:
>
> 1) IRQ
> 2) Reset GPIO
> 3) LDOENA GPIO
>
> Thanks,
> Charles

(email resend to all)
Hello,

@Charles : thank you.

As Charles suggested prior in one of the mails, I have yesterday added
this patch belowe and tried it out, but unfortunately I got some
new/other errors now while the regulator stuff seems not to be working
for the wm5102 device currently


commit 305f33d58632f85730e245df08dc7070789f9789
Author: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date:   Mon Jul 13 13:29:07 2015 +0200

    mfd/arizona/pdata.h : added wm5102_pdata with structur of type arizona_pdata

    Signed-off-by: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>

diff --git a/include/linux/mfd/arizona/pdata.h
b/include/linux/mfd/arizona/pdata.h
index 43db4fa..df9153b 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -181,4 +181,17 @@ struct arizona_pdata {
        int irq_gpio;
 };

+/* added for the WM510205 case here
+ *
+ */
+
+const static struct arizona_pdata wm5102_pdata = {
+       .reset = 0x03,
+       .ldoena = 0x17,
+       .irq_flags = IRQF_TRIGGER_RISING|
+                       IRQF_TRIGGER_FALLING,
+       .irq_gpio = 0x04,
+
+};
+
 #endif


The dmesg I got in an endless loop is seen below and please note:
the messages below are most of local added dev_err() to be sure which
code path was running here.


[ 5858.229428] spi spi-WM510205:00: checking WM510205 with bmp180
[ 5858.229437] spi spi-WM510205:00: checking WM510205 with bmp181
[ 5858.229443] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[ 5858.229497] arizona spi-WM510205:00: acpi_match_device() first,
than via spi_get_device_id().
[ 5858.229504] arizona spi-WM510205:00: matched ACPI ID and data
[ 5858.229508] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[ 5858.229512] arizona spi-WM510205:00: regmap set to wm5102_spi
[ 5858.230063] arizona spi-WM510205:00: spi_irq = -1
[ 5858.230069] arizona spi-WM510205:00: arizona_irq = -1
[ 5858.230073] arizona spi-WM510205:00: arizona_spi_probe done, call
and return of  arizona_dev_init
[ 5858.230339] spi-WM510205:00 supply AVDD not found, using dummy regulator
[ 5858.230411] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[ 5858.230451] arizona spi-WM510205:00: Failed to resolve LDOVDD-supply for LDO1
[ 5858.230458] arizona spi-WM510205:00: Failed to request DCVDD: -517
.... repeating now all the time until reboot/power off / energy=0

Did the patch I added here looks good ? or is there an error that I oversight??

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

2015-07-15 9:01 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
> 2015-07-13 11:53 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
>> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
>>> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
>>> > On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
>>> >> Hi,
>>> >>
>>> >>
>>> >> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>> >> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
>>> >> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
>>> >> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
>>> >> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
>>> >> >
>>> >> > The above is saying that SPI I/O to the device isn't working - the
>>> >> > device ID is not being read back successfully.
>>> >>
>>> >> Ok that is the next problem that must be solved.
>>> >> I have yesterday made a patchset where I have added
>>> >> the enum type 5, but as you said already,
>>> >> that was not needed.
>>> >> All what I see the same: : Unknown device ID: ffff
>>> >>
>>> >> So where I have to look now or what can I do to let this device id
>>> >> register correctly?
>>> >> I hope the baytrail machine driver is easy peasy to add, but here I
>>> >> stuck at the moment.
>>> >
>>> > As I said in my other emails the next step is to work out what
>>> > the reset and ldoena gpio's are. You won't be able to read the
>>> > device ID until you have those setup. Unfortunately, finding the
>>> > right GPIOs is likely to be a bit of a chore, I will see if I can
>>> > find anything out from the Windows guys at this end.
>>> >
>>> > Also can you check that the arizona-ldo1 regulator is built in I
>>> > am surprised that is falling back to the dummy regulator.
>>> >
>>> > Thanks,
>>> > Charles
>>>
>>> Hi,
>>>
>>> I just want to ask, if the windows guys have such infos about the
>>> gpios in question (reset,ldoena) and of course the irq details.
>>>
>>> I am thinking actually to get a second device with Win installed, so
>>> that I can get more infos which I really need here.
>>> Anyway  I can also provide more infos here (if its not against valid laws :) )
>>> But indeeed I can need some hints where to put the pdata structure.
>>>
>>> I have some more questions that I want to ask/discuss later on irc -
>>> if its possible
>>>
>>> cheers
>>> Chris
>>
>> Ok so it does indeed seem the information I got from the Windows
>> team was not fully accurate last time. The IRQ pin, reset line
>> and LDO enable are actually specified in ACPI. This block here
>> has them:
>>
>> GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
>>          "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
>> {   // Pin list
>>         0x0004
>> }
>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>>         "\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,)
>> {   // Pin list
>>         0x0003
>> }
>> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>>         "\\_SB.GPO1", 0x00, ResourceConsumer, ,)
>> {   // Pin list
>>         0x0017
>> }
>>
>> The order here being:
>>
>> 1) IRQ
>> 2) Reset GPIO
>> 3) LDOENA GPIO
>>
>> Thanks,
>> Charles
>
> (email resend to all)
> Hello,
>
> @Charles : thank you.
>
> As Charles suggested prior in one of the mails, I have yesterday added
> this patch belowe and tried it out, but unfortunately I got some
> new/other errors now while the regulator stuff seems not to be working
> for the wm5102 device currently
>
>
> commit 305f33d58632f85730e245df08dc7070789f9789
> Author: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Date:   Mon Jul 13 13:29:07 2015 +0200
>
>     mfd/arizona/pdata.h : added wm5102_pdata with structur of type arizona_pdata
>
>     Signed-off-by: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>
> diff --git a/include/linux/mfd/arizona/pdata.h
> b/include/linux/mfd/arizona/pdata.h
> index 43db4fa..df9153b 100644
> --- a/include/linux/mfd/arizona/pdata.h
> +++ b/include/linux/mfd/arizona/pdata.h
> @@ -181,4 +181,17 @@ struct arizona_pdata {
>         int irq_gpio;
>  };
>
> +/* added for the WM510205 case here
> + *
> + */
> +
> +const static struct arizona_pdata wm5102_pdata = {
> +       .reset = 0x03,
> +       .ldoena = 0x17,
> +       .irq_flags = IRQF_TRIGGER_RISING|
> +                       IRQF_TRIGGER_FALLING,
> +       .irq_gpio = 0x04,
> +
> +};
> +
>  #endif
>
>
> The dmesg I got in an endless loop is seen below and please note:
> the messages below are most of local added dev_err() to be sure which
> code path was running here.
>
>
> [ 5858.229428] spi spi-WM510205:00: checking WM510205 with bmp180
> [ 5858.229437] spi spi-WM510205:00: checking WM510205 with bmp181
> [ 5858.229443] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [ 5858.229497] arizona spi-WM510205:00: acpi_match_device() first,
> than via spi_get_device_id().
> [ 5858.229504] arizona spi-WM510205:00: matched ACPI ID and data
> [ 5858.229508] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [ 5858.229512] arizona spi-WM510205:00: regmap set to wm5102_spi
> [ 5858.230063] arizona spi-WM510205:00: spi_irq = -1
> [ 5858.230069] arizona spi-WM510205:00: arizona_irq = -1
> [ 5858.230073] arizona spi-WM510205:00: arizona_spi_probe done, call
> and return of  arizona_dev_init
> [ 5858.230339] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [ 5858.230411] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [ 5858.230451] arizona spi-WM510205:00: Failed to resolve LDOVDD-supply for LDO1
> [ 5858.230458] arizona spi-WM510205:00: Failed to request DCVDD: -517
> .... repeating now all the time until reboot/power off / energy=0
>
> Did the patch I added here looks good ? or is there an error that I oversight??
>
> cheers
> chris


Hello,

I have a LDO1 in dmesg now with the patch from yesterday sent to the
lkml from Mark Brown (thank you, Mark).

("[PATCH] regulator: core: Handle full constraints systems when
resolving supplies").

here is the feedback after applying Mark's patch above.

I got NO loop in arizona_dev_init() anymore -
so far so good. This patch does work at least for me.

The actual dmesg shows me that LDO1 seems to be set right.
[    6.558123] sst-acpi 80860F28:00: No matching ASoC machine driver found
[    6.698840] ACPI: Battery Slot [BATC] (battery present)
[    6.699157] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    6.699233] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    6.699511] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    6.699519] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    6.699586] spi spi-WM510205:00: checking WM510205 with bmp180
[    6.707160] spi spi-WM510205:00: checking WM510205 with bmp181
[    6.714689] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    6.722833] arizona spi-WM510205:00: acpi_match_device() first,
than via spi_get_device_id().
[    6.730565] arizona spi-WM510205:00: matched ACPI ID and data
[    6.738341] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    6.746119] arizona spi-WM510205:00: regmap set to wm5102_spi
[    6.754063] rfkill_gpio LNV4752:00: GPIO lookup for consumer reset
[    6.754075] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
[    6.754086] acpi LNV4752:00: GPIO: looking up reset-gpios
[    6.754096] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 0 0 0
[    6.754180] rfkill_gpio LNV4752:00: GPIO lookup for consumer shutdown
[    6.754185] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
[    6.754190] acpi LNV4752:00: GPIO: looking up shutdown-gpios
[    6.754196] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 1 0 0
[    6.754232] acpi LNV4752:00: GPIO: looking up shutdown-gpio
[    6.754238] acpi LNV4752:00: GPIO: looking up 0 in _CRS
[    6.754275] gpio-411 (reset): gpiod_request: status -16
[    6.754684] arizona spi-WM510205:00: spi_irq = -1
[    6.762292] arizona spi-WM510205:00: arizona_irq = -1
[    6.769865] arizona spi-WM510205:00: arizona_spi_probe done, call
and return of  arizona_dev_in
it
[    6.788702] rfkill_gpio: probe of LNV4752:00 failed with error -16
[    6.789036] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    6.789072] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.789140] LDO1: supplied by regulator-dummy
[    6.789391] arizona spi-WM510205:00: Unknown device ID: ffff
[    6.798044] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
[    6.805653] i2c i2c-4: Failed to register i2c client MAGN0001:00 at
0x1d (-16)


the only open issue seems the unkown device id, and this could be
coming from the (wrong) spi initialization I think.

As I have changed to not use the spi_get_device_id() function., and
there still seems to be missing some code (the read back of the device
id fails as another developer mentioned)

The first line "sst-acpi 80860F28:00: No matching ASoC machine driver found"
should be fine with the last patch holding on the local stash.

Also I have some new questions regarding to the firmware I have
to load here.
Currently I have the fw_sst_0f28.bin-48kHz_i2s_master which seems not
correct (i2c)
Do not know yet if I can or should take the default one ( which should
be in this case fw_sst_0f28.bin)
Does somebody of for intel_sst_acpi and the WM5102 codec if a new or
specific firmware must be used to
let this codec work at all.




cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Wed, Jul 15, 2015 at 09:17:08AM +0200, Christian Hartmann wrote:
> 2015-07-15 9:01 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
> > 2015-07-13 11:53 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> >> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
> >>> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> >>> > On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
> >>> >> Hi,
> >>> >>
> >>> >>
> >>> >> 2015-06-29 11:48 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> >>> >> > On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
> >>> >> >> [    5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> >>> >> >> [    5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
> >>> >> >> [    5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> >>> >> >
> >>> >> > The above is saying that SPI I/O to the device isn't working - the
> >>> >> > device ID is not being read back successfully.
> >>> >>
> >>> >> Ok that is the next problem that must be solved.
> >>> >> I have yesterday made a patchset where I have added
> >>> >> the enum type 5, but as you said already,
> >>> >> that was not needed.
> >>> >> All what I see the same: : Unknown device ID: ffff
> >>> >>
> >>> >> So where I have to look now or what can I do to let this device id
> >>> >> register correctly?
> >>> >> I hope the baytrail machine driver is easy peasy to add, but here I
> >>> >> stuck at the moment.
> >>> >
> >>> > As I said in my other emails the next step is to work out what
> >>> > the reset and ldoena gpio's are. You won't be able to read the
> >>> > device ID until you have those setup. Unfortunately, finding the
> >>> > right GPIOs is likely to be a bit of a chore, I will see if I can
> >>> > find anything out from the Windows guys at this end.
> >>> >
> >>> > Also can you check that the arizona-ldo1 regulator is built in I
> >>> > am surprised that is falling back to the dummy regulator.
> >>> >
> >>> > Thanks,
> >>> > Charles
> >>>
> >>> Hi,
> >>>
> >>> I just want to ask, if the windows guys have such infos about the
> >>> gpios in question (reset,ldoena) and of course the irq details.
> >>>
> >>> I am thinking actually to get a second device with Win installed, so
> >>> that I can get more infos which I really need here.
> >>> Anyway  I can also provide more infos here (if its not against valid laws :) )
> >>> But indeeed I can need some hints where to put the pdata structure.
> >>>
> >>> I have some more questions that I want to ask/discuss later on irc -
> >>> if its possible
> >>>
> >>> cheers
> >>> Chris
> >>
> >> Ok so it does indeed seem the information I got from the Windows
> >> team was not fully accurate last time. The IRQ pin, reset line
> >> and LDO enable are actually specified in ACPI. This block here
> >> has them:
> >>
> >> GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
> >>          "\\_SB.GPO2", 0x00, ResourceConsumer, ,)
> >> {   // Pin list
> >>         0x0004
> >> }
> >> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> >>         "\\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,)
> >> {   // Pin list
> >>         0x0003
> >> }
> >> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> >>         "\\_SB.GPO1", 0x00, ResourceConsumer, ,)
> >> {   // Pin list
> >>         0x0017
> >> }
> >>
> >> The order here being:
> >>
> >> 1) IRQ
> >> 2) Reset GPIO
> >> 3) LDOENA GPIO
> >>
> >> Thanks,
> >> Charles
> >
> > (email resend to all)
> > Hello,
> >
> > @Charles : thank you.
> >
> > As Charles suggested prior in one of the mails, I have yesterday added
> > this patch belowe and tried it out, but unfortunately I got some
> > new/other errors now while the regulator stuff seems not to be working
> > for the wm5102 device currently
> >
> >
> > commit 305f33d58632f85730e245df08dc7070789f9789
> > Author: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > Date:   Mon Jul 13 13:29:07 2015 +0200
> >
> >     mfd/arizona/pdata.h : added wm5102_pdata with structur of type arizona_pdata
> >
> >     Signed-off-by: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> >
> > diff --git a/include/linux/mfd/arizona/pdata.h
> > b/include/linux/mfd/arizona/pdata.h
> > index 43db4fa..df9153b 100644
> > --- a/include/linux/mfd/arizona/pdata.h
> > +++ b/include/linux/mfd/arizona/pdata.h
> > @@ -181,4 +181,17 @@ struct arizona_pdata {
> >         int irq_gpio;
> >  };
> >
> > +/* added for the WM510205 case here
> > + *
> > + */
> > +
> > +const static struct arizona_pdata wm5102_pdata = {
> > +       .reset = 0x03,
> > +       .ldoena = 0x17,
> > +       .irq_flags = IRQF_TRIGGER_RISING|
> > +                       IRQF_TRIGGER_FALLING,
> > +       .irq_gpio = 0x04,
> > +
> > +};
> > +
> >  #endif
> >
> >
> > The dmesg I got in an endless loop is seen below and please note:
> > the messages below are most of local added dev_err() to be sure which
> > code path was running here.
> >
> >
> > [ 5858.229428] spi spi-WM510205:00: checking WM510205 with bmp180
> > [ 5858.229437] spi spi-WM510205:00: checking WM510205 with bmp181
> > [ 5858.229443] spi spi-WM510205:00: modalias WM510205 in id_table not
> > found, returns NULL
> > [ 5858.229497] arizona spi-WM510205:00: acpi_match_device() first,
> > than via spi_get_device_id().
> > [ 5858.229504] arizona spi-WM510205:00: matched ACPI ID and data
> > [ 5858.229508] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> > [ 5858.229512] arizona spi-WM510205:00: regmap set to wm5102_spi
> > [ 5858.230063] arizona spi-WM510205:00: spi_irq = -1
> > [ 5858.230069] arizona spi-WM510205:00: arizona_irq = -1
> > [ 5858.230073] arizona spi-WM510205:00: arizona_spi_probe done, call
> > and return of  arizona_dev_init
> > [ 5858.230339] spi-WM510205:00 supply AVDD not found, using dummy regulator
> > [ 5858.230411] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> > [ 5858.230451] arizona spi-WM510205:00: Failed to resolve LDOVDD-supply for LDO1
> > [ 5858.230458] arizona spi-WM510205:00: Failed to request DCVDD: -517
> > .... repeating now all the time until reboot/power off / energy=0
> >
> > Did the patch I added here looks good ? or is there an error that I oversight??
> >
> > cheers
> > chris
> 
> 
> Hello,
> 
> I have a LDO1 in dmesg now with the patch from yesterday sent to the
> lkml from Mark Brown (thank you, Mark).
> 
> ("[PATCH] regulator: core: Handle full constraints systems when
> resolving supplies").
> 
> here is the feedback after applying Mark's patch above.
> 
> I got NO loop in arizona_dev_init() anymore -
> so far so good. This patch does work at least for me.
> 
> The actual dmesg shows me that LDO1 seems to be set right.
> [    6.558123] sst-acpi 80860F28:00: No matching ASoC machine driver found
> [    6.698840] ACPI: Battery Slot [BATC] (battery present)
> [    6.699157] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
> [    6.699233] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
> [    6.699511] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    6.699519] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    6.699586] spi spi-WM510205:00: checking WM510205 with bmp180
> [    6.707160] spi spi-WM510205:00: checking WM510205 with bmp181
> [    6.714689] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.722833] arizona spi-WM510205:00: acpi_match_device() first,
> than via spi_get_device_id().
> [    6.730565] arizona spi-WM510205:00: matched ACPI ID and data
> [    6.738341] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.746119] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.754063] rfkill_gpio LNV4752:00: GPIO lookup for consumer reset
> [    6.754075] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
> [    6.754086] acpi LNV4752:00: GPIO: looking up reset-gpios
> [    6.754096] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 0 0 0
> [    6.754180] rfkill_gpio LNV4752:00: GPIO lookup for consumer shutdown
> [    6.754185] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
> [    6.754190] acpi LNV4752:00: GPIO: looking up shutdown-gpios
> [    6.754196] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 1 0 0
> [    6.754232] acpi LNV4752:00: GPIO: looking up shutdown-gpio
> [    6.754238] acpi LNV4752:00: GPIO: looking up 0 in _CRS
> [    6.754275] gpio-411 (reset): gpiod_request: status -16
> [    6.754684] arizona spi-WM510205:00: spi_irq = -1
> [    6.762292] arizona spi-WM510205:00: arizona_irq = -1
> [    6.769865] arizona spi-WM510205:00: arizona_spi_probe done, call
> and return of  arizona_dev_in
> it
> [    6.788702] rfkill_gpio: probe of LNV4752:00 failed with error -16
> [    6.789036] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    6.789072] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    6.789140] LDO1: supplied by regulator-dummy
> [    6.789391] arizona spi-WM510205:00: Unknown device ID: ffff
> [    6.798044] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> [    6.805653] i2c i2c-4: Failed to register i2c client MAGN0001:00 at
> 0x1d (-16)
> 
> 
> the only open issue seems the unkown device id, and this could be
> coming from the (wrong) spi initialization I think.
> 
> As I have changed to not use the spi_get_device_id() function., and
> there still seems to be missing some code (the read back of the device
> id fails as another developer mentioned)
> 
> The first line "sst-acpi 80860F28:00: No matching ASoC machine driver found"
> should be fine with the last patch holding on the local stash.
> 
> Also I have some new questions regarding to the firmware I have
> to load here.
> Currently I have the fw_sst_0f28.bin-48kHz_i2s_master which seems not
> correct (i2c)
> Do not know yet if I can or should take the default one ( which should
> be in this case fw_sst_0f28.bin)
> Does somebody of for intel_sst_acpi and the WM5102 codec if a new or
> specific firmware must be used to
> let this codec work at all.

I don't really know about the Intel side, but on the CODEC side
you shouldn't need any specific firmware to make things work. I
would also be somewhat surprised if you needed firmware for the
SPI to work. So I think we should be able to register the CODEC
happily.

I suspect we still have some issues with the GPIO lookups, I
suspect we want to actually pull them from ACPI rather than
putting them into the pdata, as I don't know if the number will
translate directly over.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On Wed, Jul 15, 2015 at 09:12:24AM +0100, Charles Keepax wrote:

Folks, please remember to delete irrelevant context from your replies so
it's possible to find any new content you might have added.

> I suspect we still have some issues with the GPIO lookups, I
> suspect we want to actually pull them from ACPI rather than
> putting them into the pdata, as I don't know if the number will
> translate directly over.

Yes, you shouldn't be fishing numbers directly out of ACPI but instead
resolving them into Linux GPIO numbers.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Christian Hartmann]

2015-07-15 11:17 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> On Wed, Jul 15, 2015 at 09:12:24AM +0100, Charles Keepax wrote:
>
> Folks, please remember to delete irrelevant context from your replies so
> it's possible to find any new content you might have added.
>
>> I suspect we still have some issues with the GPIO lookups, I
>> suspect we want to actually pull them from ACPI rather than
>> putting them into the pdata, as I don't know if the number will
>> translate directly over.
>
> Yes, you shouldn't be fishing numbers directly out of ACPI but instead
> resolving them into Linux GPIO numbers.

Hi,

as mentioned before it should be using the gpiolib.h to get the right
gpios from ACPI space, right??
I am looking how this would be done in this case, hope to understand
and get it today working with gpiolib

By the way I have restest (with a lot more local debugs) and I know
now that the function arizona_dev_init()
wrongly calls the arizona_of_get_core_pdata() which could not work here...

so these two open issues I have to resolve yet before I can have fun
with the new alsa sound device


cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi,

I had already asked about the pxa2xx and the PIO mode (aka no DMA
channels available).
If I remember correctly, it does not need DMA at all.

Otherwise I see later in dmesg the DesignWare DMA Controller (2x) à 8 channels.

Is the pxa2xx not using the DMA mode cause the Designware controllers
are initialized later??
Or has this nothing to do with it at all ? Still interested...

snip of dmesg:
[    6.164409] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    6.164485] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    6.165020] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    6.165028] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
...
[    6.392552] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels
[    6.396310] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 channels


so far
chris
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Charles Keepax]

On Fri, Jul 17, 2015 at 08:56:26AM +0200, Christian Hartmann wrote:
> 2015-07-15 11:17 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> > On Wed, Jul 15, 2015 at 09:12:24AM +0100, Charles Keepax wrote:
> By the way I have restest (with a lot more local debugs) and I know
> now that the function arizona_dev_init()
> wrongly calls the arizona_of_get_core_pdata() which could not work here...

That implies the pdata is not set for the device when you are
entering arizona_dev_init, also might be worth checking if it is
calling the stub version of the full version (basically is
CONFIG_OF turned on).

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi,

> That implies the pdata is not set for the device when you are
> entering arizona_dev_init, also might be worth checking if it is
> calling the stub version of the full version (basically is
> CONFIG_OF turned on).
# CONFIG_OF is not set here, so the current code as in arizona_dev_init()

...
if (dev_get_platdata(arizona->dev,0)) {
/* currently not working... */
else
 arizona_of_get_core_pdata(arizona);

which returns only '0' in this case  because the config option
CONFIG_OF is disabled.

Today I am back at this device and I have changed the above function
(arizona_of_get_core_pdata) where I set
currently the pdata with its values for the arizona type = WM5102.

So the pdata is at the moment hardcoded, that is not the way I want to
go on, but
it seems the code works so far, except the LDO1 makes trouble with the
current GPIO value 0x17 (extracted from dsdt.dsl as seen above).

[    5.790655] systemd-journald[434]: Received request to flush
runtime journal from PID 1
[    7.263225] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    7.263339] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    7.263482] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    7.263490] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    7.263551] spi spi-WM510205:00: checking WM510205 with bmp180
[    7.263557] spi spi-WM510205:00: checking WM510205 with bmp181
[    7.263562] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    7.263610] arizona spi-WM510205:00: acpi_match_device() first,
than via spi_get_device_id().
[    7.263617] arizona spi-WM510205:00: matched ACPI ID and data
[    7.263621] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    7.263625] arizona spi-WM510205:00: regmap set to wm5102_spi
[    7.264424] arizona spi-WM510205:00: spi_irq = -1
[    7.264432] arizona spi-WM510205:00: arizona_irq = -1
[    7.264436] arizona spi-WM510205:00: arizona_spi_probe done, call
and return of  arizona_dev_init
[    7.264440] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    7.264445] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    7.264450] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    7.264454] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    7.269430] LDO1: Failed to request enable GPIO23: -517
[    7.269506] arizona spi-WM510205:00: Failed to register LDO1 supply: -517
[    7.289191] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    7.289246] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    7.289366] spi-WM510205:00 supply DCVDD not found, using dummy regulator
[    7.289415] arizona spi-WM510205:00: Failed to request /RESET: -517
[    7.289690] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00

... arizona spi-wm510202 tries to init the device 2 times again ....

side-note: added a lot of dev_err to see whats going on, so the most
messages are not in master, only in my local branch (today its
4.2.0-rc6)

Instead of hardcoding and finding the correct GPIOs by Try&Error I
want as mentioned above already by Charles Keepax, to pull them from
ACPI.

currently I am not using the the gpiolib.h and its functions to get
the named and relevant GPIOs in question,
failing yet searching for examples which fits into the arizona mfd code easily.

I saw the drivers/gpio/gpio-arizona.h, which is also not using the
gpiolib.h, too.also it is not clear to me, if I should use
gpio-arizona at all (or extend it for using it with the wm5102).


zitat from Charles:

"I suspect we still have some issues with the GPIO lookups, I
suspect we want to actually pull them from ACPI rather than
putting them into the pdata, as I don't know if the number will
translate directly over."

What I have understand today :  the three values (irq_gpio, reset,
ldoena) have different 'parents' as seen in the dsdt.dsl
irq_gpio = _SB.GPO2 -> 0x0004
reset = _SB.I2C7.PMIC

Looking in other wmXXXX drivers how they get and set there gpios, but
nothing found what I can adapt or reuse here at the moment.

Does anybody has a clue??

cheers
chris

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

[Charles Keepax]

On Mon, Aug 10, 2015 at 09:00:50AM +0200, Christian Hartmann wrote:
> [    7.269430] LDO1: Failed to request enable GPIO23: -517
> [    7.269506] arizona spi-WM510205:00: Failed to register LDO1 supply: -517
> [    7.289191] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    7.289246] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    7.289366] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> [    7.289415] arizona spi-WM510205:00: Failed to request /RESET: -517
> [    7.289690] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> 
> ... arizona spi-wm510202 tries to init the device 2 times again ....
> 
> side-note: added a lot of dev_err to see whats going on, so the most
> messages are not in master, only in my local branch (today its
> 4.2.0-rc6)
> 
> Instead of hardcoding and finding the correct GPIOs by Try&Error I
> want as mentioned above already by Charles Keepax, to pull them from
> ACPI.
> 
> currently I am not using the the gpiolib.h and its functions to get
> the named and relevant GPIOs in question,
> failing yet searching for examples which fits into the arizona mfd code easily.

Yes this driver has not been converted over to use gpiod yet.

> 
> I saw the drivers/gpio/gpio-arizona.h, which is also not using the
> gpiolib.h, too.also it is not clear to me, if I should use
> gpio-arizona at all (or extend it for using it with the wm5102).

The gpio-arizona driver is the driver that provides support for
the GPIOs on the actual CODEC (it has 5 GPIO pins of its own) and
has nothing to do with the GPIOs that are controlling the RESET
and LDOENA.

> 
> 
> zitat from Charles:
> 
> "I suspect we still have some issues with the GPIO lookups, I
> suspect we want to actually pull them from ACPI rather than
> putting them into the pdata, as I don't know if the number will
> translate directly over."
> 
> What I have understand today :  the three values (irq_gpio, reset,
> ldoena) have different 'parents' as seen in the dsdt.dsl
> irq_gpio = _SB.GPO2 -> 0x0004
> reset = _SB.I2C7.PMIC

The point here is that although the GPIOs are defined as 0x0004,
0x0003 and 0x0017 in the ACPI that doesn't necessarily mean those
will be the GPIO numbers in Linux.

Alas my knowledge of how things are done in ACPI is not up to
telling you how to translate the numbers but for example with
device tree we are calling the function of_get_named_gpio to pull
the actual GPIO number, I would expect there would be some
loosely equivalent function for ACPI.

If such functions are only available through gpiod then we could
look at upgrading the driver to use gpiod it is something I have
been intending to do for a while but it pretty annoying because
the gpiod stuff assumes the DT bindings for gpios will have the
suffix "-gpios" or "-gpio" (which "wlf,reset" and "wlf,ldoena"
obviously don't have) so moving to it necessitates a change of
the device tree binding which is far from ideal.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi again,

in the case of CONFIG_OF (this machine has no OF) the arizona_of_get_core_pdata
sets also gpio_defaults for struct pdata, which I had not added into
the #else switch (CONFIG_OF is not set).

All I have is an one example in
Documentation/devicetree/bindings/mfd/arizona.txt.

What should I do here cause I do not now the defaults but they seem to
be needed too and I cannot use devicetree here.
Where can I get the gpio-defaults or how can I use gpiolib to extract
these defaults and gpio pins as expected?



Looking again ( and again at the code), I have to use a function
similar to arizona_of_get_named_gpio to find all of these pins, is
there a function for the acpi case?
I have not the the full view and I am not well-informed yet

cheers
chris

PS: just reading the latest answer and evaluating...

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

[Charles Keepax]

On Mon, Aug 10, 2015 at 10:00:38AM +0200, Christian Hartmann wrote:
> Hi again,
> 
> in the case of CONFIG_OF (this machine has no OF) the arizona_of_get_core_pdata
> sets also gpio_defaults for struct pdata, which I had not added into
> the #else switch (CONFIG_OF is not set).
> 
> All I have is an one example in
> Documentation/devicetree/bindings/mfd/arizona.txt.
> 
> What should I do here cause I do not now the defaults but they seem to
> be needed too and I cannot use devicetree here.
> Where can I get the gpio-defaults or how can I use gpiolib to extract
> these defaults and gpio pins as expected?
> 

Those defaults are for the GPIOs on the CODEC and have nothing to
do with getting the reset and ldo enable working. You only need
to set them if you are going to use pins on the CODEC to control
something else.

> 
> 
> Looking again ( and again at the code), I have to use a function
> similar to arizona_of_get_named_gpio to find all of these pins, is
> there a function for the acpi case?

No as we have discussed currently the driver has no support for
ACPI. I would imagine there is an ACPI equivalent of
of_get_named_gpio which is what the function you mention uses to
get the actual GPIO number though. But I don't know what the
exact function is.

Thanks,
Charles

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Mon, Aug 10, 2015 at 09:10:01AM +0100, Charles Keepax wrote:
> No as we have discussed currently the driver has no support for
> ACPI. I would imagine there is an ACPI equivalent of
> of_get_named_gpio which is what the function you mention uses to
> get the actual GPIO number though. But I don't know what the
> exact function is.

You should use devm_gpiod_get() and friends. If you do not have
corresponding Linux device node, then it is fwnode_get_named_gpiod().

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

[Christian Hartmann]

2015-08-10 10:35 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> On Mon, Aug 10, 2015 at 09:10:01AM +0100, Charles Keepax wrote:
>> No as we have discussed currently the driver has no support for
>> ACPI. I would imagine there is an ACPI equivalent of
>> of_get_named_gpio which is what the function you mention uses to
>> get the actual GPIO number though. But I don't know what the
>> exact function is.
>
> You should use devm_gpiod_get() and friends. If you do not have
> corresponding Linux device node, then it is fwnode_get_named_gpiod().

Hello,

thanks Charles and Mika.

@Mika: I actually view a patch by you from 6. May 2015 where you
added dev_gpio_irq_get() and the acpi_dev_gpio_irq_get() functions,
seems to be related here to, right??

So I create the next patch to get the right IRQ and the right GPIOs in
question (ldoena, reset).
Will report soon again

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Mon, Aug 10, 2015 at 11:20:04AM +0200, Christian Hartmann wrote:
> @Mika: I actually view a patch by you from 6. May 2015 where you
> added dev_gpio_irq_get() and the acpi_dev_gpio_irq_get() functions,
> seems to be related here to, right??

That's right if you have GpioInt -resource somewhere you need to
translate to Linux IRQ number (and use it via irqchip instead of gpiolib
API).

What was done for I2C core with addition of acpi_dev_gpio_irq_get() is
that now it automatically takes first GpioInt of an I2C device and
assigns the translated IRQ number to client->irq if it is not yet
assigned to a valid IRQ.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

2015-08-10 11:26 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> On Mon, Aug 10, 2015 at 11:20:04AM +0200, Christian Hartmann wrote:
>> @Mika: I actually view a patch by you from 6. May 2015 where you
>> added dev_gpio_irq_get() and the acpi_dev_gpio_irq_get() functions,
>> seems to be related here to, right??
>
> That's right if you have GpioInt -resource somewhere you need to
> translate to Linux IRQ number (and use it via irqchip instead of gpiolib
> API).
>
> What was done for I2C core with addition of acpi_dev_gpio_irq_get() is
> that now it automatically takes first GpioInt of an I2C device and
> assigns the translated IRQ number to client->irq if it is not yet
> assigned to a valid IRQ.


Hi,

@Mika

some feedback to the first patch today

I have patched it to use the acpi_dev_gpio_irq_get()
and after reboot I have a message seen below, it seems the irq uses
actually the gpio pin 146 .


[    6.195479] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.195560] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq 146

So I go on and patching again to have also the ldoena and reset lines
getting via acpi...

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

> You should use devm_gpiod_get() and friends. If you do not have
> corresponding Linux device node, then it is fwnode_get_named_gpiod().

It seems the fwnode_get_named_gpiod() function will be used in my case,
but how can I get the fwnode??

looking at the moment to the i2c-core code where it is also used....

chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Mon, Aug 10, 2015 at 03:48:31PM +0200, Christian Hartmann wrote:
> > You should use devm_gpiod_get() and friends. If you do not have
> > corresponding Linux device node, then it is fwnode_get_named_gpiod().
> 
> It seems the fwnode_get_named_gpiod() function will be used in my case,
> but how can I get the fwnode??

There is acpi_fwnode_handle() in include/acpi/acpi_bus.h. However, if
you have Linux device available you should really use devm_gpio_*
functions instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

2015-08-10 16:02 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> On Mon, Aug 10, 2015 at 03:48:31PM +0200, Christian Hartmann wrote:
>> > You should use devm_gpiod_get() and friends. If you do not have
>> > corresponding Linux device node, then it is fwnode_get_named_gpiod().
>>
>> It seems the fwnode_get_named_gpiod() function will be used in my case,
>> but how can I get the fwnode??

I am trying to use devm_gpiod_get now
but before I have to add the gpios via the mapping as decscribed in
the consumer documentation
>
> There is acpi_fwnode_handle() in include/acpi/acpi_bus.h. However, if
> you have Linux device available you should really use devm_gpio_*
> functions instead.
Hi,

I am actually stucking to get the ACPI handle via
handle = ACPI_HANDLE(&arizona->dev)
it complaints about dev->fwnode

I am looking to get it working with acpi_fwnode_handle() at the moment

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi

>> There is acpi_fwnode_handle() in include/acpi/acpi_bus.h. However, if
>> you have Linux device available you should really use devm_gpio_*
>> functions instead.

ok, after some changes I got it compiled, but there seems another
mistake (by me?), it does not find the GPIOs yet.

[    5.851524] sst-acpi 80860F28:00: No matching ASoC machine driver found
[    5.873318] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    5.877982] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    5.878667] rfkill_gpio BCM2E84:00: GPIO lookup for consumer reset
[    5.878677] rfkill_gpio BCM2E84:00: using ACPI for GPIO lookup
[    5.878683] acpi BCM2E84:00: GPIO: looking up reset-gpios
[    5.878690] acpi BCM2E84:00: GPIO: _DSD returned BCM2E84:00 3 0 0 0
[    5.878836] rfkill_gpio BCM2E84:00: GPIO lookup for consumer shutdown
[    5.878844] rfkill_gpio BCM2E84:00: using ACPI for GPIO lookup
[    5.878850] acpi BCM2E84:00: GPIO: looking up shutdown-gpios
[    5.878857] acpi BCM2E84:00: GPIO: _DSD returned BCM2E84:00 3 1 0 0
[    5.884010] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    5.884019] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    5.884102] spi spi-WM510205:00: checking WM510205 with bmp180
[    5.884108] spi spi-WM510205:00: checking WM510205 with bmp181
[    5.884113] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    5.884140] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    5.884146] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    5.884151] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    5.884155] arizona spi-WM510205:00: regmap set to wm5102_spi
[    5.884765] rfkill_gpio BCM2E84:00: BCM2E84:00 device registered.
[    5.884831] rfkill_gpio LNV4752:00: GPIO lookup for consumer reset
[    5.884837] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
[    5.884843] acpi LNV4752:00: GPIO: looking up reset-gpios
[    5.884850] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 0 0 0
[    5.884926] rfkill_gpio LNV4752:00: GPIO lookup for consumer shutdown
[    5.884931] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
[    5.884936] acpi LNV4752:00: GPIO: looking up shutdown-gpios
[    5.884941] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 1 0 0
[    5.884977] acpi LNV4752:00: GPIO: looking up shutdown-gpio
[    5.884983] acpi LNV4752:00: GPIO: looking up 0 in _CRS
[    5.885019] gpio-411 (reset): gpiod_request: status -16
[    5.889424] arizona spi-WM510205:00: spi_irq = -1
[    5.889435] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    5.889442] arizona spi-WM510205:00: acpi_dev_add_driver_gpios done, 0
[    5.889447] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    5.889774] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    5.889781] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.889788] acpi WM510205:00: GPIO: looking up reset-gpios
[    5.889794] acpi WM510205:00: GPIO: looking up reset-gpio
[    5.889798] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.891255] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    5.891263] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.891269] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    5.891274] acpi WM510205:00: GPIO: looking up ldoena-gpio
[    5.891279] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.891324] gpio-342 (reset): gpiod_request: status -16
[    5.891330] arizona spi-WM510205:00: Failed to get ldoena line: -16
[    5.891335] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.891409] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    5.891415] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  23
[    5.891421] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  -184850384
[    5.891425] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    5.891430] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    5.891434] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    5.894845] rfkill_gpio: probe of LNV4752:00 failed with error -16
[    5.906587] LDO1: Failed to request enable GPIO23: -517
[    5.906673] arizona spi-WM510205:00: Failed to register LDO1 supply: -517
[    5.923633] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.923687] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    5.923718] spi-WM510205:00 supply DCVDD not found, using dummy regulator
[    5.923751] ------------[ cut here ]------------
[    5.923763] WARNING: CPU: 2 PID: 474 at drivers/gpio/gpiolib.c:86
gpio_to_desc+0xbb/0xd0()

in  arizona-spi I try to map these GPIOs, which I want to get in
arizona-core: arizona_dev_init

diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
index 1e845f6..52872a0 100644
--- a/drivers/mfd/arizona-spi.c
+++ b/drivers/mfd/arizona-spi.c
@@ -18,28 +18,58 @@
 #include <linux/slab.h>
 #include <linux/spi/spi.h>
 #include <linux/of.h>
+#include <linux/acpi.h>

 #include <linux/mfd/arizona/core.h>

 #include "arizona.h"

+const struct acpi_gpio_params reset_gpio = { 1, 0, false};
+const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
+
+const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
+       { "reset_gpio", &reset_gpio, 1,},
+       { "ldoena_gpio", &ldoena_gpio, 1},
+       { },
+};
 static int arizona_spi_probe(struct spi_device *spi)
 {
-       const struct spi_device_id *id = spi_get_device_id(spi);
+       const struct spi_device_id *id;
        struct arizona *arizona;
+       struct acpi_device *adev;
        const struct regmap_config *regmap_config;
        unsigned long type;
+       acpi_handle handle;
        int ret;

        if (spi->dev.of_node)
                type = arizona_of_get_type(&spi->dev);
-       else
-               type = id->driver_data;
+       else {
+               dev_err(&spi->dev, "arizona_acpi_get_type(), than via
spi_get_device_id().\n");
+               if (( type = arizona_acpi_get_type(&spi->dev))) {
+               } else {
+                       id = spi_get_device_id(spi) ;
+                       if (!id || !id->driver_data)
+                               return -ENODEV;
+                       dev_err(&spi->dev, "matched spi\n");
+                       type = id->driver_data;
+               }
+       }
+
+
+       /* check if type is NULL before going on
+        */
+       if (!type) {
+               dev_err(&spi->dev, "type is NULL, unable to get the id
/ type of this device\n");
+               return -ENODEV;
+       } else
+               dev_err(&spi->dev, "using %lu as type for arizona
audio codec\n",type);

        switch (type) {
 #ifdef CONFIG_MFD_WM5102
        case WM5102:
                regmap_config = &wm5102_spi_regmap;
+               dev_err(&spi->dev, "regmap set to wm5102_spi \n");
                break;
 #endif
 #ifdef CONFIG_MFD_WM5110
@@ -66,10 +96,32 @@ static int arizona_spi_probe(struct spi_device *spi)
                return ret;
        }

-       arizona->type = id->driver_data;
+       /*
+        * take the id if it is an spi id,  or take the acpi id
+        * the case that it has no id and no acpi_id is yet open (yes the
+        * openfirmare interface introducted by apple)
+        */
+       arizona->type = type;
+
        arizona->dev = &spi->dev;
        arizona->irq = spi->irq;

+       dev_err(&spi->dev, "spi_irq = %i \n",spi->irq);
+       dev_err(&spi->dev, "arizona_spi_probe done, calling
arizona_dev_init \n");
+
+#ifdef CONFIG_ACPI
+       /*
+        *arizona->dev.fwnode = acpi_fwnode_handle(adev);
+        */
+       handle = ACPI_HANDLE(&spi->dev);
+       if (!handle || acpi_bus_get_device(handle, &adev)) {
+               dev_err(&spi->dev, "unable to get ACPI handle\n");
+               return -ENODEV;
+       }
+       ret = acpi_dev_add_driver_gpios(adev, arizona_acpi_gpios);
+       dev_err(&spi->dev, "acpi_dev_add_driver_gpios done, %i\n",ret);
+
+#endif
        return arizona_dev_init(arizona);
 }

@@ -90,12 +142,22 @@ static const struct spi_device_id arizona_spi_ids[] = {
 };
 MODULE_DEVICE_TABLE(spi, arizona_spi_ids);

+static const struct acpi_device_id arizona_acpi_match[] = {
+       {
+               .id = "WM510205",
+               .driver_data = WM5102,
+       },
+       { },
+};
+MODULE_DEVICE_TABLE(acpi, arizona_acpi_match);
+
static struct spi_driver arizona_spi_driver = {
        .driver = {
                .name   = "arizona",
                .owner  = THIS_MODULE,
                .pm     = &arizona_pm_ops,
                .of_match_table = of_match_ptr(arizona_of_match),
+               .acpi_match_table = ACPI_PTR(arizona_acpi_match),
        },
        .probe          = arizona_spi_probe,
        .remove         = arizona_spi_remove,
diff --git a/drivers/mfd/arizona.h b/drivers/mfd/arizona.h
index fbe2843..ba9e9bc 100644
--- a/drivers/mfd/arizona.h
+++ b/drivers/mfd/arizona.h
@@ -55,4 +55,14 @@ static inline unsigned long
arizona_of_get_type(struct device *dev)
 }
 #endif

+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+unsigned long arizona_acpi_get_type(struct device *dev);
+
+extern const struct acpi_gpio_params reset_gpio;
+extern const struct acpi_gpio_params ldoena_gpio;
+
+extern const struct acpi_gpio_mapping arizona_acpi_gpios[];
+#endif
+
 #endif


@@ -812,6 +840,70 @@ EXPORT_SYMBOL_GPL(arizona_of_match);
 #else
 static inline int arizona_of_get_core_pdata(struct arizona *arizona)
 {
+       struct arizona_pdata *pdata = &arizona->pdata;
+       struct gpio_desc *reset, *ldoena;
+       int ret;
+
+       switch (arizona->type) {
+       case WM5102:
+               /* TODO:
+                * get the actual GPIO pins from ACPI namespace
+                * instead of hardcoding it here
+               pdata->reset = 0x03 ;
+               pdata->ldoena = 0x17 ;
+                */
+
+               reset = devm_gpiod_get_optional(arizona->dev,
+                                                       "reset",
+                                                       GPIOD_OUT_LOW);
+               if (IS_ERR(reset)) {
+                       ret = PTR_ERR(reset);
+                       dev_err(arizona->dev, "Failed to get reset
line: %d\n", ret);
+                       pdata->reset = 0x03 ;
+                       /*
+                        *return ret;
+                        */
+               } else {
+                       pdata->reset = (int )reset;
+               }
+
+               ldoena = devm_gpiod_get_optional(arizona->dev,
+                                                       "ldoena",
+                                                       GPIOD_OUT_LOW);
+               if (IS_ERR(ldoena)) {
+                       ret = PTR_ERR(ldoena);
+                       dev_err(arizona->dev, "Failed to get ldoena
line: %d\n", ret);
+                       pdata->ldoena = 0x17 ;
+                       /*
+                        * return ret;
+                       */
+               } else {
+                       pdata->ldoena = (int )ldoena;
+               }
+
+               pdata->irq_flags = IRQF_TRIGGER_RISING|
+                                       IRQF_TRIGGER_FALLING;
+
+               /* get the ACPI GpioInt ressource for this device
+                *
+                */
+               if (ACPI_COMPANION(arizona->dev)) {
+                       pdata->irq_gpio =
acpi_dev_gpio_irq_get(ACPI_COMPANION(arizona->dev), 0);
+               } else {
+                       pdata->irq_gpio = 0x04 ;
+               }
+
+               dev_err(arizona->dev, "arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = %i\n",
+                       pdata->irq_gpio);
+               dev_err(arizona->dev, "arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  %i\n",
+                       pdata->ldoena);
+               dev_err(arizona->dev, "arizona_of_get_core_pdata
(ACPI) using reset GPIO =  %i\n",
+                       pdata->reset);
+               break;
+       default:
+               break;
+       }
+

so far, this are the most important and current testing changes.
Does anybody has some ideas or hints about how to get the annoying
GPIOs ldoena and reset ?

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Wed, Aug 19, 2015 at 12:29:08PM +0200, Christian Hartmann wrote:
> Hi
> 
> >> There is acpi_fwnode_handle() in include/acpi/acpi_bus.h. However, if
> >> you have Linux device available you should really use devm_gpio_*
> >> functions instead.
> 
> ok, after some changes I got it compiled, but there seems another
> mistake (by me?), it does not find the GPIOs yet.
> 

...

> [    5.891255] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    5.891263] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    5.891269] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    5.891274] acpi WM510205:00: GPIO: looking up ldoena-gpio
> [    5.891279] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.891324] gpio-342 (reset): gpiod_request: status -16
> [    5.891330] arizona spi-WM510205:00: Failed to get ldoena line: -16

It returns -EBUSY so is the GPIO already requested?

> [    5.891335] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.891409] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    5.891415] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  23
> [    5.891421] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  -184850384
> [    5.891425] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    5.891430] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    5.891434] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    5.894845] rfkill_gpio: probe of LNV4752:00 failed with error -16
> [    5.906587] LDO1: Failed to request enable GPIO23: -517
> [    5.906673] arizona spi-WM510205:00: Failed to register LDO1 supply: -517
> [    5.923633] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    5.923687] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    5.923718] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> [    5.923751] ------------[ cut here ]------------
> [    5.923763] WARNING: CPU: 2 PID: 474 at drivers/gpio/gpiolib.c:86
> gpio_to_desc+0xbb/0xd0()
> 
> in  arizona-spi I try to map these GPIOs, which I want to get in
> arizona-core: arizona_dev_init
> 
> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> index 1e845f6..52872a0 100644
> --- a/drivers/mfd/arizona-spi.c
> +++ b/drivers/mfd/arizona-spi.c
> @@ -18,28 +18,58 @@
>  #include <linux/slab.h>
>  #include <linux/spi/spi.h>
>  #include <linux/of.h>
> +#include <linux/acpi.h>
> 
>  #include <linux/mfd/arizona/core.h>
> 
>  #include "arizona.h"
> 
> +const struct acpi_gpio_params reset_gpio = { 1, 0, false};
> +const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
> +
> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
> +       { "reset_gpio", &reset_gpio, 1,},
> +       { "ldoena_gpio", &ldoena_gpio, 1},

The correct names are "reset-gpios" and "ldoena-gpios". If you call

        reset = devm_gpiod_get_optional(arizona->dev, "reset", GPIOD_OUT_LOW);

GPIO core will look for "reset-gpios" and then "reset-gpio" not
"reset_gpio" so it will not find the mapping.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi again,

>> in  arizona-spi I try to map these GPIOs, which I want to get in
>> arizona-core: arizona_dev_init
>>
>> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
>> index 1e845f6..52872a0 100644
>> --- a/drivers/mfd/arizona-spi.c
>> +++ b/drivers/mfd/arizona-spi.c
>> @@ -18,28 +18,58 @@
>>  #include <linux/slab.h>
>>  #include <linux/spi/spi.h>
>>  #include <linux/of.h>
>> +#include <linux/acpi.h>
>>
>>  #include <linux/mfd/arizona/core.h>
>>
>>  #include "arizona.h"
>>
>> +const struct acpi_gpio_params reset_gpio = { 1, 0, false};
>> +const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
>> +
>> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
>> +       { "reset_gpio", &reset_gpio, 1,},
>> +       { "ldoena_gpio", &ldoena_gpio, 1},
>
> The correct names are "reset-gpios" and "ldoena-gpios". If you call
>
>         reset = devm_gpiod_get_optional(arizona->dev, "reset", GPIOD_OUT_LOW);
>
> GPIO core will look for "reset-gpios" and then "reset-gpio" not
> "reset_gpio" so it will not find the mapping.

yes you are right, I had fixed it yesterday by changing the names.

+const struct acpi_gpio_params reset_gpios = { 1, 0, false};
+const struct acpi_gpio_params ldoena_gpios = { 2, 0, false};
+
+const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
+       { "reset-gpios", &reset_gpios, 1,},
+       { "ldoena-gpios", &ldoena_gpios, 1},
+       { },
+};



Today I can see that the mapping is working as seen below.
But for unknown reasons I got wrong values read
via devm_gpiod_get_optional() in the arizona_dev_init ->
arizona_of_get_core_pdata()

[    6.387993] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    6.389258] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    6.389416] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    6.389424] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    6.389567] spi spi-WM510205:00: checking WM510205 with bmp180
[    6.389574] spi spi-WM510205:00: checking WM510205 with bmp181
[    6.389578] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    6.405723] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    6.405735] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    6.405740] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    6.405744] arizona spi-WM510205:00: regmap set to wm5102_spi
[    6.406557] arizona spi-WM510205:00: spi_irq = -1
[    6.406565] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    6.406569] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    6.406574] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    6.406580] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.406585] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.406590] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.406597] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.406673] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.406724] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    6.406729] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.406733] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    6.406739] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
[    6.406790] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.406844] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    6.406850] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  -185173228
[    6.406855] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  -184741840
[    6.406859] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    6.406864] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    6.406868] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    6.407100] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    6.407131] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.407162] LDO1: supplied by regulator-dummy
[    6.407214] ------------[ cut here ]------------
[    6.407226] WARNING: CPU: 0 PID: 472 at drivers/gpio/gpiolib.c:86
gpio_to_desc+0xbb/0xd0()


did I cast the values wrong?

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Thu, Aug 20, 2015 at 11:38:13AM +0200, Christian Hartmann wrote:
> Hi again,
> 
> >> in  arizona-spi I try to map these GPIOs, which I want to get in
> >> arizona-core: arizona_dev_init
> >>
> >> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> >> index 1e845f6..52872a0 100644
> >> --- a/drivers/mfd/arizona-spi.c
> >> +++ b/drivers/mfd/arizona-spi.c
> >> @@ -18,28 +18,58 @@
> >>  #include <linux/slab.h>
> >>  #include <linux/spi/spi.h>
> >>  #include <linux/of.h>
> >> +#include <linux/acpi.h>
> >>
> >>  #include <linux/mfd/arizona/core.h>
> >>
> >>  #include "arizona.h"
> >>
> >> +const struct acpi_gpio_params reset_gpio = { 1, 0, false};
> >> +const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
> >> +
> >> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
> >> +       { "reset_gpio", &reset_gpio, 1,},
> >> +       { "ldoena_gpio", &ldoena_gpio, 1},
> >
> > The correct names are "reset-gpios" and "ldoena-gpios". If you call
> >
> >         reset = devm_gpiod_get_optional(arizona->dev, "reset", GPIOD_OUT_LOW);
> >
> > GPIO core will look for "reset-gpios" and then "reset-gpio" not
> > "reset_gpio" so it will not find the mapping.
> 
> yes you are right, I had fixed it yesterday by changing the names.
> 
> +const struct acpi_gpio_params reset_gpios = { 1, 0, false};
> +const struct acpi_gpio_params ldoena_gpios = { 2, 0, false};
> +
> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
> +       { "reset-gpios", &reset_gpios, 1,},
> +       { "ldoena-gpios", &ldoena_gpios, 1},
> +       { },
> +};
> 
> 
> 
> Today I can see that the mapping is working as seen below.
> But for unknown reasons I got wrong values read
> via devm_gpiod_get_optional() in the arizona_dev_init ->
> arizona_of_get_core_pdata()
> 
> [    6.387993] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
> [    6.389258] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
> [    6.389416] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    6.389424] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    6.389567] spi spi-WM510205:00: checking WM510205 with bmp180
> [    6.389574] spi spi-WM510205:00: checking WM510205 with bmp181
> [    6.389578] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.405723] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.405735] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.405740] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.405744] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.406557] arizona spi-WM510205:00: spi_irq = -1
> [    6.406565] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> arizona_acpi_gpios added done, 0
> [    6.406569] arizona spi-WM510205:00: arizona_spi_probe done,
> calling arizona_dev_init
> [    6.406574] arizona spi-WM510205:00: dev_set_drvdata done for 1
> [    6.406580] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    6.406585] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.406590] acpi WM510205:00: GPIO: looking up reset-gpios
> [    6.406597] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    6.406673] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.406724] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    6.406729] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.406733] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    6.406739] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
> [    6.406790] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.406844] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    6.406850] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  -185173228
> [    6.406855] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  -184741840
> [    6.406859] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    6.406864] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    6.406868] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    6.407100] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    6.407131] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    6.407162] LDO1: supplied by regulator-dummy
> [    6.407214] ------------[ cut here ]------------
> [    6.407226] WARNING: CPU: 0 PID: 472 at drivers/gpio/gpiolib.c:86
> gpio_to_desc+0xbb/0xd0()
> 
> 
> did I cast the values wrong?

devm_gpiod_get_optional() returns GPIO descriptor which should not be
cast to anything else. If you want to get the numberic value for
logging purposes you can call desc_to_gpio(desc) for the returned
descriptor.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi,

2015-08-20 11:45 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> devm_gpiod_get_optional() returns GPIO descriptor which should not be
> cast to anything else. If you want to get the numberic value for
> logging purposes you can call desc_to_gpio(desc) for the returned
> descriptor.


that done, it looks much better. thank you, Mika

I got a new error instead for the LDO1 as seen below:

[    5.951646] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    5.951650] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.951656] acpi WM510205:00: GPIO: looking up reset-gpios
[    5.951663] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    5.951779] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.951831] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    5.951838] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.951843] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    5.951852] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
[    5.951909] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.951975] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    5.951980] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  405
[    5.951985] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  342
[    5.951989] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    5.951994] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    5.951999] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    5.952283] arizona spi-WM510205:00: mfd_add_devices done for 1
[    5.952291] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.952338] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    5.952381] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    5.952387] LDO1: supplied by regulator-dummy
[    5.952452] arizona spi-WM510205:00: regulator_get done for 1
[    5.952457] ------------[ cut here ]------------
[    5.952469] WARNING: CPU: 3 PID: 464 at drivers/gpio/gpiolib.c:86
gpio_to_desc+0xbb/0xd0()
[    5.952472] invalid GPIO -184850384
[    5.952475] Modules linked in: int3400_thermal(+)
int3403_thermal(+) processor_thermal_device(+)
snd_soc_sst_mfld_platform int3402_thermal in
t340x_thermal_zone rfkill_gpio acpi_thermal_rel intel_soc_dts_iosf
acpi_pad spi_pxa2xx_platform(+) i2c_designware_platform(+) rfkill
pwm_lpss_pl
atform snd_soc_sst_acpi pwm_lpss i2c_designware_core ax88179_178a usbnet i2c_hid
[    5.952510] CPU: 3 PID: 464 Comm: systemd-udevd Not tainted 4.2.0.84-rc7 #252
[    5.952513] Hardware name: LENOVO 60072/INVALID, BIOS 02WT18WW 08/01/2014
[    5.952517]  c0e619a7 b4cc43d7 00000000 f3687974 c0b606c4 f36879b4
f36879a4 c044cad8
[    5.952528]  c0d90c73 f36879d4 000001d0 c0d90c84 00000056 c0711d6b
c0711d6b c0ebf250
[    5.952538]  f4fb6830 f4fb6830 f36879c0 c044cb4f 00000009 f36879b4
c0d90c73 f36879d4
[    5.952548] Call Trace:
[    5.952558]  [<c0b606c4>] dump_stack+0x41/0x52
[    5.952565]  [<c044cad8>] warn_slowpath_common+0x88/0xc0
[    5.952570]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
[    5.952575]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
[    5.952579]  [<c044cb4f>] warn_slowpath_fmt+0x3f/0x60
[    5.952584]  [<c0711d6b>] gpio_to_desc+0xbb/0xd0
[    5.952590]  [<c0713f7b>] gpio_request_one+0x1b/0xf0
[    5.952595]  [<c0710da3>] devm_gpio_request_one+0x43/0x80
[    5.952602]  [<c08e6de7>] arizona_dev_init+0x257/0xc90
[    5.952607]  [<c077bf65>] ? acpi_get_data_full+0x68/0x77
[    5.952614]  [<c08c46e9>] ? dev_err+0x39/0x60
[    5.952619]  [<c08e8635>] arizona_spi_probe+0x195/0x240
[    5.952625]  [<c075c016>] ? acpi_dev_pm_attach+0x57/0x79
[    5.952632]  [<c092e286>] spi_drv_probe+0x36/0x60
[    5.952640]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
[    5.952646]  [<c075e61b>] ? acpi_driver_match_device+0x36/0x3f
[    5.952651]  [<c092eab2>] ? spi_match_device+0x22/0x70
[    5.952655]  [<c08c82fb>] __device_attach_driver+0x5b/0x70
[    5.952660]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
[    5.952665]  [<c08c6197>] bus_for_each_drv+0x57/0xa0
[    5.952670]  [<c08c7d02>] __device_attach+0xb2/0x120
[    5.952674]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
[    5.952679]  [<c08c8442>] device_initial_probe+0x12/0x20
[    5.952685]  [<c08c7267>] bus_probe_device+0x67/0x70
[    5.952690]  [<c08c52c0>] device_add+0x3c0/0x5b0
[    5.952695]  [<c092e859>] spi_add_device+0xe9/0x220
[    5.952700]  [<c092da10>] ? spi_drv_shutdown+0x20/0x20
[    5.952706]  [<c06e58a4>] ? strlcpy+0x34/0x50
[    5.952712]  [<c0930db3>] acpi_spi_add_device+0x123/0x170
[    5.952739]  [<c077b7fd>] acpi_ns_walk_namespace+0xba/0x16d
[    5.952745]  [<c077bcd7>] acpi_walk_namespace+0x8d/0xbc
[    5.952750]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
[    5.952755]  [<c0930a19>] spi_register_master+0x229/0x420
[    5.952760]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
[    5.952766]  [<c0930c4b>] devm_spi_register_master+0x3b/0x80
[    5.952775]  [<f81cec4a>] pxa2xx_spi_probe+0x24a/0x530 [spi_pxa2xx_platform]
[    5.952781]  [<c075bfd9>] ? acpi_dev_pm_attach+0x1a/0x79
[    5.952786]  [<c08ca01d>] platform_drv_probe+0x2d/0x80
[    5.952792]  [<c08c7802>] ? driver_sysfs_add+0x62/0x80
[    5.952796]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
[    5.952801]  [<c08c8261>] __driver_attach+0x71/0x80
[    5.952806]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
[    5.952811]  [<c08c60d7>] bus_for_each_dev+0x57/0xa0
[    5.952817]  [<c08c79af>] driver_attach+0x1f/0x30
[    5.952821]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
[    5.952826]  [<c08c7557>] bus_add_driver+0x1c7/0x290
[    5.952831]  [<f81d5000>] ? 0xf81d5000
[    5.952835]  [<f81d5000>] ? 0xf81d5000
[    5.952839]  [<c08c8b5a>] driver_register+0x5a/0xe0
[    5.952845]  [<c06ec1c1>] ? kvasprintf+0x41/0x50
[    5.952850]  [<c08c9f83>] __platform_driver_register+0x43/0x50
[    5.952857]  [<f81d5012>] pxa2xx_spi_init+0x12/0x1000 [spi_pxa2xx_platform]
[    5.952863]  [<c0400472>] do_one_initcall+0xc2/0x1f0
[    5.952867]  [<f81d5000>] ? 0xf81d5000
[    5.952873]  [<c0ad0a4f>] ? netlink_broadcast_filtered+0x10f/0x390
[    5.952880]  [<c052fd2e>] ? free_pages_prepare+0x1ce/0x320
[    5.952886]  [<c05718ad>] ? kmem_cache_alloc_trace+0x17d/0x1e0
[    5.952890]  [<c0570b87>] ? kfree+0xe7/0x130
[    5.952897]  [<c0b5c764>] do_init_module+0x54/0x1cd
[    5.952903]  [<c04c7895>] load_module+0x1145/0x17d0
[    5.952910]  [<c04c4549>] ? copy_module_from_fd.isra.53+0x109/0x1a0
[    5.952916]  [<c04c810d>] SyS_finit_module+0x8d/0xd0
[    5.952922]  [<c0544ce3>] ? vm_mmap_pgoff+0x93/0xb0
[    5.952929]  [<c0b6a20f>] sysenter_do_call+0x12/0x12
[    5.952933] ---[ end trace 1e444d913002c55d ]---
[    5.952936] gpiod_request: invalid GPIO
[    5.952941] arizona spi-WM510205:00: Failed to request /RESET: -22
[    5.982461] arizona: probe of spi-WM510205:00 failed with error -22
[    5.982478] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
[    5.988213] i2c i2c-11: Failed to register i2c client MAGN0001:00
at 0x1d (-16)

the code in arizona-core.c arizona_dev_init looks like

if (arizona->pdata.reset) {
 /* Start out with /RESET low to put the chip into reset */
 ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
}

which fails here. seems that I have to use desc_to_gpio() here too.
Does anybody have an idea whats wrong with LDO1? I try the
desc_to_gpio at first and will report soon

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

hi,


2015-08-20 13:34 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:

> the code in arizona-core.c arizona_dev_init looks like
>
> if (arizona->pdata.reset) {
>  /* Start out with /RESET low to put the chip into reset */
>  ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
> }
>
> which fails here. seems that I have to use desc_to_gpio() here too.
> Does anybody have an idea whats wrong with LDO1? I try the
> desc_to_gpio at first and will report soon
>
> cheers
> chris

hm, in include/linux/mfd/arizona/pdata.h
the structur arizona_pdata has declared ints for the GPIOs ldoena and reset.

struct arizona_pdata {
int reset;      /** GPIO controlling /RESET, if any */
int ldoena;     /** GPIO controlling LODENA, if any */
}

so I have to respect the type of the two fields while getting the GPIO
descriptors.
On the other hand I can also add two new fields or change the code
that it uses the GPIO names instead of the numbers.

What do you think?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Thu, Aug 20, 2015 at 01:34:00PM +0200, Christian Hartmann wrote:
> Hi,
> 
> 2015-08-20 11:45 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> > devm_gpiod_get_optional() returns GPIO descriptor which should not be
> > cast to anything else. If you want to get the numberic value for
> > logging purposes you can call desc_to_gpio(desc) for the returned
> > descriptor.
> 
> 
> that done, it looks much better. thank you, Mika
> 
> I got a new error instead for the LDO1 as seen below:
> 
> [    5.951646] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    5.951650] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    5.951656] acpi WM510205:00: GPIO: looking up reset-gpios
> [    5.951663] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    5.951779] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.951831] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    5.951838] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    5.951843] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    5.951852] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
> [    5.951909] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.951975] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    5.951980] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  405
> [    5.951985] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  342
> [    5.951989] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    5.951994] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    5.951999] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    5.952283] arizona spi-WM510205:00: mfd_add_devices done for 1
> [    5.952291] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    5.952338] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    5.952381] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
> [    5.952387] LDO1: supplied by regulator-dummy
> [    5.952452] arizona spi-WM510205:00: regulator_get done for 1
> [    5.952457] ------------[ cut here ]------------
> [    5.952469] WARNING: CPU: 3 PID: 464 at drivers/gpio/gpiolib.c:86
> gpio_to_desc+0xbb/0xd0()
> [    5.952472] invalid GPIO -184850384
> [    5.952475] Modules linked in: int3400_thermal(+)
> int3403_thermal(+) processor_thermal_device(+)
> snd_soc_sst_mfld_platform int3402_thermal in
> t340x_thermal_zone rfkill_gpio acpi_thermal_rel intel_soc_dts_iosf
> acpi_pad spi_pxa2xx_platform(+) i2c_designware_platform(+) rfkill
> pwm_lpss_pl
> atform snd_soc_sst_acpi pwm_lpss i2c_designware_core ax88179_178a usbnet i2c_hid
> [    5.952510] CPU: 3 PID: 464 Comm: systemd-udevd Not tainted 4.2.0.84-rc7 #252
> [    5.952513] Hardware name: LENOVO 60072/INVALID, BIOS 02WT18WW 08/01/2014
> [    5.952517]  c0e619a7 b4cc43d7 00000000 f3687974 c0b606c4 f36879b4
> f36879a4 c044cad8
> [    5.952528]  c0d90c73 f36879d4 000001d0 c0d90c84 00000056 c0711d6b
> c0711d6b c0ebf250
> [    5.952538]  f4fb6830 f4fb6830 f36879c0 c044cb4f 00000009 f36879b4
> c0d90c73 f36879d4
> [    5.952548] Call Trace:
> [    5.952558]  [<c0b606c4>] dump_stack+0x41/0x52
> [    5.952565]  [<c044cad8>] warn_slowpath_common+0x88/0xc0
> [    5.952570]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
> [    5.952575]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
> [    5.952579]  [<c044cb4f>] warn_slowpath_fmt+0x3f/0x60
> [    5.952584]  [<c0711d6b>] gpio_to_desc+0xbb/0xd0
> [    5.952590]  [<c0713f7b>] gpio_request_one+0x1b/0xf0
> [    5.952595]  [<c0710da3>] devm_gpio_request_one+0x43/0x80
> [    5.952602]  [<c08e6de7>] arizona_dev_init+0x257/0xc90
> [    5.952607]  [<c077bf65>] ? acpi_get_data_full+0x68/0x77
> [    5.952614]  [<c08c46e9>] ? dev_err+0x39/0x60
> [    5.952619]  [<c08e8635>] arizona_spi_probe+0x195/0x240
> [    5.952625]  [<c075c016>] ? acpi_dev_pm_attach+0x57/0x79
> [    5.952632]  [<c092e286>] spi_drv_probe+0x36/0x60
> [    5.952640]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
> [    5.952646]  [<c075e61b>] ? acpi_driver_match_device+0x36/0x3f
> [    5.952651]  [<c092eab2>] ? spi_match_device+0x22/0x70
> [    5.952655]  [<c08c82fb>] __device_attach_driver+0x5b/0x70
> [    5.952660]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
> [    5.952665]  [<c08c6197>] bus_for_each_drv+0x57/0xa0
> [    5.952670]  [<c08c7d02>] __device_attach+0xb2/0x120
> [    5.952674]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
> [    5.952679]  [<c08c8442>] device_initial_probe+0x12/0x20
> [    5.952685]  [<c08c7267>] bus_probe_device+0x67/0x70
> [    5.952690]  [<c08c52c0>] device_add+0x3c0/0x5b0
> [    5.952695]  [<c092e859>] spi_add_device+0xe9/0x220
> [    5.952700]  [<c092da10>] ? spi_drv_shutdown+0x20/0x20
> [    5.952706]  [<c06e58a4>] ? strlcpy+0x34/0x50
> [    5.952712]  [<c0930db3>] acpi_spi_add_device+0x123/0x170
> [    5.952739]  [<c077b7fd>] acpi_ns_walk_namespace+0xba/0x16d
> [    5.952745]  [<c077bcd7>] acpi_walk_namespace+0x8d/0xbc
> [    5.952750]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
> [    5.952755]  [<c0930a19>] spi_register_master+0x229/0x420
> [    5.952760]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
> [    5.952766]  [<c0930c4b>] devm_spi_register_master+0x3b/0x80
> [    5.952775]  [<f81cec4a>] pxa2xx_spi_probe+0x24a/0x530 [spi_pxa2xx_platform]
> [    5.952781]  [<c075bfd9>] ? acpi_dev_pm_attach+0x1a/0x79
> [    5.952786]  [<c08ca01d>] platform_drv_probe+0x2d/0x80
> [    5.952792]  [<c08c7802>] ? driver_sysfs_add+0x62/0x80
> [    5.952796]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
> [    5.952801]  [<c08c8261>] __driver_attach+0x71/0x80
> [    5.952806]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
> [    5.952811]  [<c08c60d7>] bus_for_each_dev+0x57/0xa0
> [    5.952817]  [<c08c79af>] driver_attach+0x1f/0x30
> [    5.952821]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
> [    5.952826]  [<c08c7557>] bus_add_driver+0x1c7/0x290
> [    5.952831]  [<f81d5000>] ? 0xf81d5000
> [    5.952835]  [<f81d5000>] ? 0xf81d5000
> [    5.952839]  [<c08c8b5a>] driver_register+0x5a/0xe0
> [    5.952845]  [<c06ec1c1>] ? kvasprintf+0x41/0x50
> [    5.952850]  [<c08c9f83>] __platform_driver_register+0x43/0x50
> [    5.952857]  [<f81d5012>] pxa2xx_spi_init+0x12/0x1000 [spi_pxa2xx_platform]
> [    5.952863]  [<c0400472>] do_one_initcall+0xc2/0x1f0
> [    5.952867]  [<f81d5000>] ? 0xf81d5000
> [    5.952873]  [<c0ad0a4f>] ? netlink_broadcast_filtered+0x10f/0x390
> [    5.952880]  [<c052fd2e>] ? free_pages_prepare+0x1ce/0x320
> [    5.952886]  [<c05718ad>] ? kmem_cache_alloc_trace+0x17d/0x1e0
> [    5.952890]  [<c0570b87>] ? kfree+0xe7/0x130
> [    5.952897]  [<c0b5c764>] do_init_module+0x54/0x1cd
> [    5.952903]  [<c04c7895>] load_module+0x1145/0x17d0
> [    5.952910]  [<c04c4549>] ? copy_module_from_fd.isra.53+0x109/0x1a0
> [    5.952916]  [<c04c810d>] SyS_finit_module+0x8d/0xd0
> [    5.952922]  [<c0544ce3>] ? vm_mmap_pgoff+0x93/0xb0
> [    5.952929]  [<c0b6a20f>] sysenter_do_call+0x12/0x12
> [    5.952933] ---[ end trace 1e444d913002c55d ]---
> [    5.952936] gpiod_request: invalid GPIO
> [    5.952941] arizona spi-WM510205:00: Failed to request /RESET: -22
> [    5.982461] arizona: probe of spi-WM510205:00 failed with error -22
> [    5.982478] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> [    5.988213] i2c i2c-11: Failed to register i2c client MAGN0001:00
> at 0x1d (-16)
> 
> the code in arizona-core.c arizona_dev_init looks like
> 
> if (arizona->pdata.reset) {
>  /* Start out with /RESET low to put the chip into reset */
>  ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
> }
> 
> which fails here. seems that I have to use desc_to_gpio() here too.
> Does anybody have an idea whats wrong with LDO1? I try the
> desc_to_gpio at first and will report soon

I don't think passing the converted GPIO numbers in pdata is good idea.
Instead you can just get the GPIO descriptors in the driver itself using
devm_gpiod_get*().

For example you can try following:

        if (arizona->pdata.reset) {
                /* Start out with /RESET low to put the chip into reset * */
                ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
                                            GPIOF_DIR_OUT | GPIOF_INIT_LOW,
                                            "arizona /RESET");
                if (ret != 0) {
                        dev_err(dev, "Failed to request /RESET: %d\n", ret);
                        goto err_dcvdd;
                }
        } else {
		struct gpio_desc *desc;

		desc = devm_gpiod_get(arizona->dev, "reset",
				      GPIOF_DIR_OUT | GPIOF_INIT_LOW);
		if (!IS_ERR(desc))
			arizona.pdata.reset = desc_to_gpio(desc);
	}

Eventually it might be good idea to convert the driver to use GPIO
descriptors. The above can be intermediate step to that.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi,


2015-08-20 13:58 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> On Thu, Aug 20, 2015 at 01:34:00PM +0200, Christian Hartmann wrote:
>
> I don't think passing the converted GPIO numbers in pdata is good idea.
> Instead you can just get the GPIO descriptors in the driver itself using
> devm_gpiod_get*().
>
> For example you can try following:
>
>         if (arizona->pdata.reset) {
>                 /* Start out with /RESET low to put the chip into reset * */
>                 ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
>                                             GPIOF_DIR_OUT | GPIOF_INIT_LOW,
>                                             "arizona /RESET");
>                 if (ret != 0) {
>                         dev_err(dev, "Failed to request /RESET: %d\n", ret);
>                         goto err_dcvdd;
>                 }
>         } else {
>                 struct gpio_desc *desc;
>
>                 desc = devm_gpiod_get(arizona->dev, "reset",
>                                       GPIOF_DIR_OUT | GPIOF_INIT_LOW);
>                 if (!IS_ERR(desc))
>                         arizona.pdata.reset = desc_to_gpio(desc);
>         }
>
> Eventually it might be good idea to convert the driver to use GPIO
> descriptors. The above can be intermediate step to that.

I have just changed the code as you suggested, and I got no bug,
excepting that the
WM5102 codec does not initialize at all yet.


[    6.169473] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    6.169501] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    6.169507] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    6.169511] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    6.169515] arizona spi-WM510205:00: regmap set to wm5102_spi
[    6.170301] arizona spi-WM510205:00: spi_irq = -1
[    6.170309] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    6.170313] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    6.170317] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    6.170323] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.170328] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.170333] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.170340] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.175675] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.175733] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    6.175739] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.175744] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    6.175750] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
[    6.175805] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.175860] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    6.175867] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  405
[    6.175871] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  342
[    6.175875] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    6.175880] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    6.175885] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    6.176079] gpio-405 (ldoena): gpiod_request: status -16
[    6.176084] LDO1: Failed to request enable GPIO405: -16
[    6.176154] arizona spi-WM510205:00: Failed to register LDO1 supply: -16
[    6.189631] arizona-ldo1: probe of arizona-ldo1 failed with error -16
[    6.189656] arizona spi-WM510205:00: mfd_add_devices done for 1
[    6.189665] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    6.189721] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.189753] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    6.189757] spi-WM510205:00 supply DCVDD not found, using dummy regulator
[    6.189786] arizona spi-WM510205:00: regulator_get done for 1
[    6.189794] gpio-342 (reset): gpiod_request: status -16
[    6.189799] arizona spi-WM510205:00: Failed to request /RESET: -16
[    6.189805] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.189809] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.189815] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.189821] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.189883] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.189957] gpio-342 (reset): gpiod_request: status -16
[    6.189963] arizona spi-WM510205:00: Failed to request /RESET: -16
[    6.190221] arizona: probe of spi-WM510205:00 failed with error -16
[    6.190230] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00

as we can see in  the current dmesg the driver is still unable to get
the reset line, I tried at first the old way,
than via devm_gpiod_get(), if this fails to, than it goes to err_dcvdd....

I do need help here, do not know how to fix this at the moment.

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Fri, Aug 21, 2015 at 09:31:25AM +0200, Christian Hartmann wrote:
> [    6.169473] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.169501] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.169507] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.169511] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.169515] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.170301] arizona spi-WM510205:00: spi_irq = -1
> [    6.170309] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> arizona_acpi_gpios added done, 0
> [    6.170313] arizona spi-WM510205:00: arizona_spi_probe done,
> calling arizona_dev_init
> [    6.170317] arizona spi-WM510205:00: dev_set_drvdata done for 1
> [    6.170323] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    6.170328] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.170333] acpi WM510205:00: GPIO: looking up reset-gpios
> [    6.170340] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    6.175675] acpi WM510205:00: GPIO: looking up 0 in _CRS

1) You got "reset-gpios" here.

> [    6.175733] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    6.175739] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.175744] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    6.175750] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
> [    6.175805] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.175860] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    6.175867] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  405
> [    6.175871] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  342
> [    6.175875] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    6.175880] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    6.175885] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    6.176079] gpio-405 (ldoena): gpiod_request: status -16
> [    6.176084] LDO1: Failed to request enable GPIO405: -16
> [    6.176154] arizona spi-WM510205:00: Failed to register LDO1 supply: -16
> [    6.189631] arizona-ldo1: probe of arizona-ldo1 failed with error -16
> [    6.189656] arizona spi-WM510205:00: mfd_add_devices done for 1
> [    6.189665] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    6.189721] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    6.189753] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
> [    6.189757] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> [    6.189786] arizona spi-WM510205:00: regulator_get done for 1
> [    6.189794] gpio-342 (reset): gpiod_request: status -16
> [    6.189799] arizona spi-WM510205:00: Failed to request /RESET: -16

2) and fail here with -EBUSY because you have already requested the GPIO.

So please drop the code in 1) to be able to request the GPIO in the
driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi

2015-08-21 9:43 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> So please drop the code in 1) to be able to request the GPIO in the
> driver.

[    6.129664] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    6.129675] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    6.129759] spi spi-WM510205:00: checking WM510205 with bmp180
[    6.129765] spi spi-WM510205:00: checking WM510205 with bmp181
[    6.129797] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    6.129825] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    6.129831] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    6.129836] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    6.129840] arizona spi-WM510205:00: regmap set to wm5102_spi
[    6.130630] arizona spi-WM510205:00: spi_irq = -1
[    6.130638] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    6.130642] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    6.130647] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    6.130653] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.130703] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    6.130708] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    6.130713] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    6.130717] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    6.131255] arizona spi-WM510205:00: mfd_add_devices done for 1
[    6.131267] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    6.131301] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.131332] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    6.131338] LDO1: supplied by regulator-dummy
[    6.131389] arizona spi-WM510205:00: regulator_get done for 1
[    6.131397] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.131401] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.131407] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.131414] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.131498] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.131543] no flags found for reset
[    6.131549] arizona spi-WM510205:00: devm_gpiod_get done to request
/RESET: -1
[    6.131556] arizona spi-WM510205:00: regulator_bulk_enable done,
enable core supplies: 0
[    6.131561] arizona spi-WM510205:00: regulator_enable done, enable DCVDD: 0
[    6.141803] arizona spi-WM510205:00: arizona_disabe_reset
[    6.141813] arizona spi-WM510205:00: regcache_cache_only
[    6.144796] arizona spi-WM510205:00: regmap_read : read ID
register, return value: 0
[    6.144806] arizona spi-WM510205:00: found device ID: ffff
[    6.175352] arizona spi-WM510205:00: Unknown device ID ffff
[    6.175584] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
[    6.177870] sst-acpi 80860F28:00: No matching ASoC machine driver found

as you said, I removed the code in 1) so the EBUSY error is gone.

What is with the spi_irq = -1 ?? is this a problem here?

the message "no flags found for reset" seems also ok, but it does not
read the device id yet,
 what else can be wrong here?

In previous mails I added the _CRS for this device WM510202, is the
gpio-mapping, with its indexes ok so far??

The last two messages are clear to me.
I will add the machine driver if the device id was read correctly etc.

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi and upps,


2015-08-21 14:09 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
> Hi
>
> 2015-08-21 9:43 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
>> So please drop the code in 1) to be able to request the GPIO in the
>> driver.
>
> [    6.129664] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    6.129675] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    6.129759] spi spi-WM510205:00: checking WM510205 with bmp180
> [    6.129765] spi spi-WM510205:00: checking WM510205 with bmp181
> [    6.129797] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.129825] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.129831] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.129836] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.129840] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.130630] arizona spi-WM510205:00: spi_irq = -1
> [    6.130638] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> arizona_acpi_gpios added done, 0
> [    6.130642] arizona spi-WM510205:00: arizona_spi_probe done,
> calling arizona_dev_init
> [    6.130647] arizona spi-WM510205:00: dev_set_drvdata done for 1
> [    6.130653] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.130703] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    6.130708] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    6.130713] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    6.130717] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    6.131255] arizona spi-WM510205:00: mfd_add_devices done for 1
> [    6.131267] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    6.131301] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    6.131332] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
> [    6.131338] LDO1: supplied by regulator-dummy
> [    6.131389] arizona spi-WM510205:00: regulator_get done for 1
> [    6.131397] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    6.131401] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.131407] acpi WM510205:00: GPIO: looking up reset-gpios
> [    6.131414] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    6.131498] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.131543] no flags found for reset
> [    6.131549] arizona spi-WM510205:00: devm_gpiod_get done to request
> /RESET: -1
> [    6.131556] arizona spi-WM510205:00: regulator_bulk_enable done,
> enable core supplies: 0
> [    6.131561] arizona spi-WM510205:00: regulator_enable done, enable DCVDD: 0
> [    6.141803] arizona spi-WM510205:00: arizona_disabe_reset
> [    6.141813] arizona spi-WM510205:00: regcache_cache_only
> [    6.144796] arizona spi-WM510205:00: regmap_read : read ID
> register, return value: 0
> [    6.144806] arizona spi-WM510205:00: found device ID: ffff
> [    6.175352] arizona spi-WM510205:00: Unknown device ID ffff
> [    6.175584] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> [    6.177870] sst-acpi 80860F28:00: No matching ASoC machine driver found
>
> as you said, I removed the code in 1) so the EBUSY error is gone.
>
> What is with the spi_irq = -1 ?? is this a problem here?
>
> the message "no flags found for reset" seems also ok, but it does not
> read the device id yet,
>  what else can be wrong here?
>
> In previous mails I added the _CRS for this device WM510202, is the
> gpio-mapping, with its indexes ok so far??
>
> The last two messages are clear to me.
> I will add the machine driver if the device id was read correctly etc.
>
> cheers
> chris

I have overseen the code, where the function
arizona_ldo1_of_get_pdata() is called only if  CONFIG_OF is
enabled....
will fix this first...

sorry for the extra noise


cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Fri, Aug 21, 2015 at 02:09:46PM +0200, Christian Hartmann wrote:
> Hi
> 
> 2015-08-21 9:43 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> > So please drop the code in 1) to be able to request the GPIO in the
> > driver.
> 
> [    6.129664] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    6.129675] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    6.129759] spi spi-WM510205:00: checking WM510205 with bmp180
> [    6.129765] spi spi-WM510205:00: checking WM510205 with bmp181
> [    6.129797] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.129825] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.129831] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.129836] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.129840] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.130630] arizona spi-WM510205:00: spi_irq = -1
> [    6.130638] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> [    6.144806] arizona spi-WM510205:00: found device ID: ffff
> [    6.175352] arizona spi-WM510205:00: Unknown device ID ffff
> [    6.175584] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> [    6.177870] sst-acpi 80860F28:00: No matching ASoC machine driver found
> 
> as you said, I removed the code in 1) so the EBUSY error is gone.
> 
> What is with the spi_irq = -1 ?? is this a problem here?

The IRQ needs pulled from the ACPI as well, having no IRQ
specified will not interfer with basic functionality of the
driver but will become a problem eventually.

Thanks,
Charles

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

[Christian Hartmann]

Hi,

2015-08-24 10:51 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
>> What is with the spi_irq = -1 ?? is this a problem here?
>
> The IRQ needs pulled from the ACPI as well, having no IRQ
> specified will not interfer with basic functionality of the
> driver but will become a problem eventually.
>
> Thanks,
> Charles

ok, I will have an eye on it these days for the IRQ.
For me its looking that the pxa2xx does not have an irq yet,
nor an dma channel (thats should be fine, as I understand it correctly)

actually I cleanup and want to rework / begin with a new v2 patch
series, but first it should drive this chip  before beginning with a
v2 patch.

one more question: the function devm_gpio_request_one() which is used
here to request "arizona /RESET"

<code in arizona-core.c>

/* Start out with /RESET low to put the chip into reset */
ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
GPIOF_DIR_OUT | GPIOF_INIT_LOW,
"arizona /RESET");
</code>

the string arizona /RESET, where is this documented, where can I find
it? It fails here, and my question is, is this string correct at all
for my case? Should it be called only "reset" in my case??

All I have found is:
Documentation/devicetree/bindings/mfd/arizona.txt:  - wlf,reset : GPIO
specifier for the GPIO controlling /RESET

in devres.c its documented as a label only:
@label: a literal description string of this GPIO

I am curios about the answers, anyway I will change it, it looks
faulty (but do not know why exactly at all :) )

cheers
chris

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Mon, Aug 24, 2015 at 03:25:57PM +0200, Christian Hartmann wrote:

> /* Start out with /RESET low to put the chip into reset */
> ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
> GPIOF_DIR_OUT | GPIOF_INIT_LOW,
> "arizona /RESET");
> </code>

> the string arizona /RESET, where is this documented, where can I find
> it? It fails here, and my question is, is this string correct at all
> for my case? Should it be called only "reset" in my case??

That string is documentation - it's used purely for display purposes,
which is what this...

> in devres.c its documented as a label only:
> @label: a literal description string of this GPIO

...says.  In cases like this looking at the code is often helpful (you
can see exactly how the string gets used...) but obviously patches to
improve the doumentation are welcome.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Christian Hartmann]

Hi,


2015-08-25 8:21 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> On Mon, Aug 24, 2015 at 03:25:57PM +0200, Christian Hartmann wrote:
>
>> /* Start out with /RESET low to put the chip into reset */
>> ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
>> GPIOF_DIR_OUT | GPIOF_INIT_LOW,
>> "arizona /RESET");
>> </code>
>
>> the string arizona /RESET, where is this documented, where can I find
>> it? It fails here, and my question is, is this string correct at all
>> for my case? Should it be called only "reset" in my case??
>
> That string is documentation - it's used purely for display purposes,
> which is what this...
>
>> in devres.c its documented as a label only:
>> @label: a literal description string of this GPIO
>
> ...says.  In cases like this looking at the code is often helpful (you
> can see exactly how the string gets used...) but obviously patches to
> improve the doumentation are welcome.

ok so far all fine with that label, this is no problem here anyway

chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi at all,


the current logs shows me, that something else is missing here.
The spi irq is one of the issues I will try to solve today

Looking at the read_regmap() where it reads its device id,
I do not understand why it gots only an ID of 0xffff !

I have (silly or not), added a case for 0xffff in the next switch
statements but anyway this seems not okay.
I do not know what else (other than the wrong or missing spi irq,
which is currently only -1)

[    2.427561] ALSA device list:
[    5.503750] sst-acpi 80860F28:00: No matching ASoC machine driver found
[    5.544365] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    5.544449] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    5.544646] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    5.544653] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    5.544717] spi spi-WM510205:00: checking WM510205 with bmp180
[    5.544723] spi spi-WM510205:00: checking WM510205 with bmp181
[    5.544728] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    5.544752] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    5.544758] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    5.544763] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    5.544767] arizona spi-WM510205:00: regmap set to wm5102_spi
[    5.545559] arizona spi-WM510205:00: spi_irq = -1
[    5.545565] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    5.545570] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    5.545574] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    5.545578] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    5.545583] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    5.545587] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    5.545841] arizona spi-WM510205:00: mfd_add_devices done for 1
[    5.545849] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.545888] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    5.545919] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    5.545924] LDO1: supplied by regulator-dummy
[    5.545973] arizona spi-WM510205:00: regulator_get done for 1
[    5.546036] arizona spi-WM510205:00: (ACPI) using irq_gpio GPIO = 146
[    5.546050] arizona spi-WM510205:00: devm_gpio_request_one done for
request reset: 0
[    5.546057] arizona spi-WM510205:00: regulator_bulk_enable done,
enable core supplies: 0
[    5.551362] arizona spi-WM510205:00: regulator_enable done, enable DCVDD: 0
[    5.562754] arizona spi-WM510205:00: arizona_disabe_reset
[    5.562766] arizona spi-WM510205:00: regcache_cache_only
[    5.565842] arizona spi-WM510205:00: regmap_read : read ID
register, return value: 0
[    5.565852] arizona spi-WM510205:00: found device ID: ffff
[    5.609712] arizona spi-WM510205:00: WM5102 revision H
[    5.637683] arizona spi-WM510205:00: Polling reg 23 timed out: ffff
[    5.637953] arizona spi-WM510205:00: arizona_dev_init : Failed to
apply hardware patch: -110
[    5.670927] arizona: probe of spi-WM510205:00 failed with error -110
[    5.670945] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
[    5.728336] intel_sst_acpi 80860F28:00: No matching machine driver found

any ideas or what I can do next to find out was is the root issue here?
Question about the spi-irq to clarify it for me: does this spi irq
device belongs to the arizona child (the wm5102) or is this irq only
of the spi master ? I much as I understand, this irq is from the spi
master, the arizona spi child , the wm510205, has another irq ,
attachted at the irq_gpio - I am right so far??

in some previous mails it was mentioned, that I should or _must_ use
and irqchip handler?

still encouraged to get this device working as expected :)

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Wed, Aug 26, 2015 at 10:58:06AM +0200, Christian Hartmann wrote:
> Hi at all,
> 
> 
> the current logs shows me, that something else is missing here.
> The spi irq is one of the issues I will try to solve today
> 
> Looking at the read_regmap() where it reads its device id,
> I do not understand why it gots only an ID of 0xffff !

I would probably focus on getting the device ID to read back
first. The interrupts aren't that important until you can talk to
the device and the interrupt setup won't have any effect on being
able to talk to the device.

> 
> I have (silly or not), added a case for 0xffff in the next switch
> statements but anyway this seems not okay.
> I do not know what else (other than the wrong or missing spi irq,
> which is currently only -1)

Yeah adding a case for 0xffff probably won't help much as this
likely means that the device isn't responding at all when you are
talking to it, so you can't really do anything meaningful when
you get past reading the ID register anyway.

Basically to be able to talk to the device you need the following
things:

 1) The supplies need to be applied.
 2) The device needs to be out of reset.
 3) The device needs to have the LDO enabled.
 4) The chip select needs to be active.

It seems very likely that 1) is already taken care of, so I
probalby won't spend too much time worrying about that. It looks
like we are getting a valid GPIO for the reset (2) and LDOENA (3),
so it feels like those are probably ok. I guess this leaves the
SPI config as the next place to investigate, are there other
devices on the SPI that you can talk to that might at least
verify the SPI is working? Also might be worth trying to look at
how the chip selects are done perhaps that is not happening for
some reason?

Thanks,
Charles

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

[Christian Hartmann]

Hi Mika,
hi,


2015-08-26 11:13 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
>  4) The chip select needs to be active.
>
> It seems very likely that 1) is already taken care of, so I
> probalby won't spend too much time worrying about that. It looks
> like we are getting a valid GPIO for the reset (2) and LDOENA (3),
> so it feels like those are probably ok. I guess this leaves the
> SPI config as the next place to investigate, are there other
> devices on the SPI that you can talk to that might at least
> verify the SPI is working? Also might be worth trying to look at
> how the chip selects are done perhaps that is not happening for
> some reason?

ok, that seems logical .
And no I cannot prove or check other devices, I just learned a lot in
the past three month about
this (driver, spi, gpio, acpi, dsdt etc. ) at all.

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Wed, Aug 26, 2015 at 10:58:06AM +0200, Christian Hartmann wrote:
> Question about the spi-irq to clarify it for me: does this spi irq
> device belongs to the arizona child (the wm5102) or is this irq only
> of the spi master ? I much as I understand, this irq is from the spi
> master, the arizona spi child , the wm510205, has another irq ,
> attachted at the irq_gpio - I am right so far??

The master should already have IRQ. This is about assigning IRQ for the
SPI childe device.

You probably want to do same to SPI core that was done for I2C:

845c877009cf014b9 ("i2c / ACPI: Assign IRQ for devices that have GpioInt automatically")

Then it will automatically assign first found GpioInt to the SPI device
in question.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hey,

2015-08-26 12:01 GMT+02:00 Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>:
> The master should already have IRQ. This is about assigning IRQ for the
> SPI childe device.
ok, *saved*
>
> You probably want to do same to SPI core that was done for I2C:
>
> 845c877009cf014b9 ("i2c / ACPI: Assign IRQ for devices that have GpioInt automatically")
I looked at this log and have added or better set spi->irq now in
arizon-spi.c arizona_spi_probe()
and its that what I have already via local patches added:
(ACPI) using irq_gpio GPIO = 146
The question for me is, this looks like an GPIO number, not like an IRQ number.
Also it seems better to look again into pxa2xx.c or spi.c (not done
yet) and get the irq there.

>
> Then it will automatically assign first found GpioInt to the SPI device
> in question.

I again saw also the following files, which are not used under this
device or they need some attention

drivers/gpio/gpio-arizona.c
and drivers/extcon/extcon-arizona.c

I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
Is it save to ignore ?? Or should I use them as well ??

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mika Westerberg]

On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> Hey,
> 
> 2015-08-26 12:01 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> > The master should already have IRQ. This is about assigning IRQ for the
> > SPI childe device.
> ok, *saved*
> >
> > You probably want to do same to SPI core that was done for I2C:
> >
> > 845c877009cf014b9 ("i2c / ACPI: Assign IRQ for devices that have GpioInt automatically")
> I looked at this log and have added or better set spi->irq now in
> arizon-spi.c arizona_spi_probe()
> and its that what I have already via local patches added:
> (ACPI) using irq_gpio GPIO = 146
> The question for me is, this looks like an GPIO number, not like an IRQ number.
> Also it seems better to look again into pxa2xx.c or spi.c (not done
> yet) and get the irq there.

If you are calling acpi_dev_gpio_irq_get() for the SPI device it should
return you valid Linux IRQ number (or fail with an error). But it
requires that your device has GpioInt resource somewhere in _CRS.

> >
> > Then it will automatically assign first found GpioInt to the SPI device
> > in question.
> 
> I again saw also the following files, which are not used under this
> device or they need some attention
> 
> drivers/gpio/gpio-arizona.c
> and drivers/extcon/extcon-arizona.c
> 
> I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> Is it save to ignore ?? Or should I use them as well ??

If the SPI device interrupt is connected to arizona GPIO pin, then you
probably need that.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:

> > drivers/gpio/gpio-arizona.c
> > and drivers/extcon/extcon-arizona.c

> > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > Is it save to ignore ?? Or should I use them as well ??

> If the SPI device interrupt is connected to arizona GPIO pin, then you
> probably need that.

I can't see how that would work, the interrupt output isn't a GPIO.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mika Westerberg]

On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> > On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> 
> > > drivers/gpio/gpio-arizona.c
> > > and drivers/extcon/extcon-arizona.c
> 
> > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > Is it save to ignore ?? Or should I use them as well ??
> 
> > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > probably need that.
> 
> I can't see how that would work, the interrupt output isn't a GPIO.

I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
pin of arizona instead of GPIO pin of the SoC itself.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Richard Fitzgerald]

On Fri, 2015-08-28 at 12:00 +0300, Mika Westerberg wrote:
> On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> > > On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> > 
> > > > drivers/gpio/gpio-arizona.c
> > > > and drivers/extcon/extcon-arizona.c
> > 
> > > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > > Is it save to ignore ?? Or should I use them as well ??
> > 
> > > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > > probably need that.
> > 
> > I can't see how that would work, the interrupt output isn't a GPIO.
> 
> I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
> pin of arizona instead of GPIO pin of the SoC itself.

It makes no sense to connect the codec interrupt pin back to one of its
own GPIOs. If you did that the GPIO could only generate another
interrupt to itself and you'd have a circular interrupt storm that went
nowhere.

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

[Mika Westerberg]

On Fri, Aug 28, 2015 at 10:07:35AM +0100, Richard Fitzgerald wrote:
> On Fri, 2015-08-28 at 12:00 +0300, Mika Westerberg wrote:
> > On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> > > On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> > > > On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> > > 
> > > > > drivers/gpio/gpio-arizona.c
> > > > > and drivers/extcon/extcon-arizona.c
> > > 
> > > > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > > > Is it save to ignore ?? Or should I use them as well ??
> > > 
> > > > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > > > probably need that.
> > > 
> > > I can't see how that would work, the interrupt output isn't a GPIO.
> > 
> > I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
> > pin of arizona instead of GPIO pin of the SoC itself.
> 
> It makes no sense to connect the codec interrupt pin back to one of its
> own GPIOs. If you did that the GPIO could only generate another
> interrupt to itself and you'd have a circular interrupt storm that went
> nowhere.

Ah, arizona is the chip providing the codec functionality as well? I
thought they were separate chips.

In that case, I take my previus comment back. Sorry about the confusion.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Fri, Aug 28, 2015 at 12:00:42PM +0300, Mika Westerberg wrote:
> On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:

> > > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > > Is it save to ignore ?? Or should I use them as well ??

> > > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > > probably need that.

> > I can't see how that would work, the interrupt output isn't a GPIO.

> I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
> pin of arizona instead of GPIO pin of the SoC itself.

I understand what you mean, I'm just saying that the GPIO driver for the
chip seems unlikely to be useful.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Christian Hartmann]

Hi,

this is a resend with all recipients in cc now


---------- Forwarded message ----------
From: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date: 2015-08-28 9:41 GMT+02:00
Subject: Re: [alsa-devel] Fwd: [PATCH 1/1] SPI : spi-pxa2xx : fix spi
init of WM510205 codec via ACPI (resend)
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>


hi Mark et al.,



2015-08-27 16:56 GMT+02:00 Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> I can't see how that would work, the interrupt output isn't a GPIO.

yes I think also that this is the GPIO pin number.
I am not familiar with the interrupt handling, have again to look (in
other drivers or similar), to understand how things should work, never
done that before.

I have added three dev_info() into spi-pxa2xx pxa2xx_spi_probe() to
found out more whats wrong with the slave/master:

commit 4b6ff73610deef478e53b958a02617f024bbef22
Author: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date:   Thu Aug 27 14:51:48 2015 +0200

    spi/spi-pxa2xx.c : added three new dev_infos, which prints irq,
bus_num and num_chipselect

    Signed-off-by: Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 6d795a5..cf02094 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1389,6 +1389,9 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
        master->unprepare_transfer_hardware = pxa2xx_spi_unprepare_transfer;
        master->auto_runtime_pm = true;

+       dev_info(&pdev->dev, "bus_num = %d\n",master->bus_num);
+       dev_info(&pdev->dev, "num_chipselect = %d\n",master->num_chipselect);
+
        drv_data->ssp_type = ssp->type;
        drv_data->null_dma_buf = (u32 *)PTR_ALIGN(&drv_data[1], DMA_ALIGNMENT);

@@ -1423,6 +1426,8 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)

        }

+       dev_info(&pdev->dev, "IRQ %d\n", ssp->irq);
+
        /* Setup DMA if requested */
        drv_data->tx_channel = -1;
        drv_data->rx_channel = -1;


 and thats what I got:

[    6.182903] pxa2xx-spi 80860F0E:00: bus_num = -1
[    6.182909] pxa2xx-spi 80860F0E:00: num_chipselect = 2
[    6.182928] pxa2xx-spi 80860F0E:00: IRQ 194
[    6.183049] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    6.183111] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    6.192761] spi spi-WM510205:00: 8333333 Hz actual, PIO
.... the rest of the dmesg is currently the same....


Q:  this thread is about the patch for the pxa2xx-spi where the
num_chipselect was raised by one to so that the slave connects here at
all. otherwise the cs1 >= max will be hit.
Do you think the bus_number is ok ?
And shouldn't it be set the cs1=0 and num_chipselect=1  ??

The DSDT has wrongly SPI=1 as chipselect,  either the firmware (DSDT)
must be updated or a correct patch enables the spi master/slave init
here.

I hope or expect that when the spi slave will be init correctly, that
the device would also work.
The ACPI stuff is already done here, and I am running out of time.

In the last resort I have to give up or have to do that at night :)

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

hi

2015-08-28 11:50 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
>
>  and thats what I got:
>
> [    6.182903] pxa2xx-spi 80860F0E:00: bus_num = -1
> [    6.182909] pxa2xx-spi 80860F0E:00: num_chipselect = 2
> [    6.182928] pxa2xx-spi 80860F0E:00: IRQ 194
> [    6.183049] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
> [    6.183111] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
> [    6.192761] spi spi-WM510205:00: 8333333 Hz actual, PIO
> .... the rest of the dmesg is currently the same....
>
>
> Q:  this thread is about the patch for the pxa2xx-spi where the
> num_chipselect was raised by one to so that the slave connects here at
> all. otherwise the cs1 >= max will be hit.
> Do you think the bus_number is ok ?
> And shouldn't it be set the cs1=0 and num_chipselect=1  ??

What is with the bus_num ? where can I find the correct one ?
I have no working example, is it possible to find the right settings
only via a windows installation??

cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Tue, Sep 01, 2015 at 11:45:31AM +0200, Christian Hartmann wrote:
> hi
> 
> 2015-08-28 11:50 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
> >
> >  and thats what I got:
> >
> > [    6.182903] pxa2xx-spi 80860F0E:00: bus_num = -1
> > [    6.182909] pxa2xx-spi 80860F0E:00: num_chipselect = 2
> > [    6.182928] pxa2xx-spi 80860F0E:00: IRQ 194
> > [    6.183049] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
> > [    6.183111] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
> > [    6.192761] spi spi-WM510205:00: 8333333 Hz actual, PIO
> > .... the rest of the dmesg is currently the same....
> >
> >
> > Q:  this thread is about the patch for the pxa2xx-spi where the
> > num_chipselect was raised by one to so that the slave connects here at
> > all. otherwise the cs1 >= max will be hit.
> > Do you think the bus_number is ok ?
> > And shouldn't it be set the cs1=0 and num_chipselect=1  ??
> 
> What is with the bus_num ? where can I find the correct one ?
> I have no working example, is it possible to find the right settings
> only via a windows installation??

I am not sure the problem would be the bus number it is basically
just a number allocated in the kernel, it should really matter as
long as it represents the right device. Which as far as we can
see here looks likely.

The chip select being wrong could well be the issue, perhaps the
Windows driver supports multiple chipselects where as the Linux
one doesn't? Do you have access to any datasheets for the SPI on
the AP? Alternatively you could try hacking it to use chip select
0 and see if that makes the system work, seems like a long shot
but perhaps worth a quick go.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Tue, Sep 01, 2015 at 11:45:31AM +0200, Christian Hartmann wrote:
> hi
> 
> 2015-08-28 11:50 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
> >
> >  and thats what I got:
> >
> > [    6.182903] pxa2xx-spi 80860F0E:00: bus_num = -1
> > [    6.182909] pxa2xx-spi 80860F0E:00: num_chipselect = 2
> > [    6.182928] pxa2xx-spi 80860F0E:00: IRQ 194
> > [    6.183049] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
> > [    6.183111] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
> > [    6.192761] spi spi-WM510205:00: 8333333 Hz actual, PIO
> > .... the rest of the dmesg is currently the same....
> >
> >
> > Q:  this thread is about the patch for the pxa2xx-spi where the
> > num_chipselect was raised by one to so that the slave connects here at
> > all. otherwise the cs1 >= max will be hit.
> > Do you think the bus_number is ok ?
> > And shouldn't it be set the cs1=0 and num_chipselect=1  ??
> 
> What is with the bus_num ? where can I find the correct one ?
> I have no working example, is it possible to find the right settings
> only via a windows installation??

I am not sure the problem would be the bus number it is basically
just a number allocated in the kernel, it should really matter as
long as it represents the right device. Which as far as we can
see here looks likely.

The chip select being wrong could well be the issue, perhaps the
Windows driver supports multiple chipselects where as the Linux
one doesn't? Do you have access to any datasheets for the SPI on
the AP? Alternatively you could try hacking it to use chip select
0 and see if that makes the system work, seems like a long shot
but perhaps worth a quick go.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi,


2015-09-02 10:13 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> On Tue, Sep 01, 2015 at 11:45:31AM +0200, Christian Hartmann wrote:
>> hi
>>
>> 2015-08-28 11:50 GMT+02:00 Christian Hartmann <cornogle-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
>> >
>> >  and thats what I got:
>> >
>> > [    6.182903] pxa2xx-spi 80860F0E:00: bus_num = -1
>> > [    6.182909] pxa2xx-spi 80860F0E:00: num_chipselect = 2
>> > [    6.182928] pxa2xx-spi 80860F0E:00: IRQ 194
>> > [    6.183049] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
>> > [    6.183111] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
>> > [    6.192761] spi spi-WM510205:00: 8333333 Hz actual, PIO
>> > .... the rest of the dmesg is currently the same....

> The chip select being wrong could well be the issue, perhaps the
> Windows driver supports multiple chipselects where as the Linux
> one doesn't? Do you have access to any datasheets for the SPI on
> the AP? Alternatively you could try hacking it to use chip select
> 0 and see if that makes the system work, seems like a long shot
> but perhaps worth a quick go.
>
> Thanks,
> Charles

ok, that was a one-shot, in effect nothing changed .
I did set the num_chipsselect = 1 (as in vanilla kernels, so its more
a revert) and
changed the cs value from 1 to 0 (as a testpatch).
as soon as the SPI device WM510205:00 is allocated,
it tries to add the acpi_resource and in the case of the wrong SPI
chip_select with the value 1 from the DSDT ACPI table entry, but here
I set it again to 0.

expected : chip id register can be read, but
nothing changed. the logs are the same in the end.
I saw also that acpi_add_resource tries to add an irq (init with -1), but fails

[    5.966307] acpi INT33FD:00: GPIO: looking up 0 in _CRS
[    5.966806] intel_soc_pmic_i2c i2c-INT33FD:00: using lookup tables
for GPIO lookup
[    5.966814] intel_soc_pmic_i2c i2c-INT33FD:00: lookup for GPIO
intel_soc_pmic failed
[    5.975702] sst-acpi 80860F28:00: No matching ASoC machine driver found
[    5.986039] pxa2xx-spi 80860F0E:00: bus_num = -1
[    5.986047] pxa2xx-spi 80860F0E:00: num_chipselect = 1
[    5.986076] pxa2xx-spi 80860F0E:00: IRQ 194
[    5.986368] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    5.987011] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    5.987123] spi_master spi32766: allocated SPI device for WM510205:00
[    5.987172] spi (null): acpi_spi_add_resource : chip_select = 1
[    5.987177] spi (null): acpi_spi_add_resource : new chip_select = 0
[    5.987182] spi (null): acpi_spi_add_resource : irq = -1
[    5.987186] spi (null): acpi_spi_add_resource : irq < 0,
acpi_dev_resource_interrupt
[    5.987189] spi (null): acpi_spi_add_resource : irq = -1
[    5.987193] spi (null): acpi_spi_add_resource : irq < 0,
acpi_dev_resource_interrupt
[    5.987197] spi (null): acpi_spi_add_resource : irq = -1
[    5.987201] spi (null): acpi_spi_add_resource : irq < 0,
acpi_dev_resource_interrupt
[    5.987204] spi (null): acpi_spi_add_resource : irq = -1
[    5.987208] spi (null): acpi_spi_add_resource : irq < 0,
acpi_dev_resource_interrupt
[    5.987212] spi (null): acpi_spi_add_resource : irq = -1
[    5.987217] pxa2xx-spi 80860F0E:00: cs0 < max 1
[    5.987243] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    5.987249] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    5.991261] spi spi-WM510205:00: checking WM510205 with bmp180
[    5.991271] spi spi-WM510205:00: checking WM510205 with bmp181
[    5.991276] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    5.991310] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    5.991316] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    5.991323] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.991401] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    5.991406] arizona spi-WM510205:00: regmap set to wm5102_spi
[    5.991980] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    5.991986] arizona spi-WM510205:00: spi_irq = 146
[    5.991990] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    5.991994] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    5.991999] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    5.992004] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    5.992008] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    5.994493] arizona spi-WM510205:00: mfd_add_devices done for 1
[    5.994505] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.994553] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.007337] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    6.007348] LDO1: supplied by regulator-dummy
[    6.007419] arizona spi-WM510205:00: regulator_get done for 1
[    6.007427] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.007517] arizona spi-WM510205:00: (ACPI) using irq_gpio GPIO = 146
[    6.007534] arizona spi-WM510205:00: devm_gpio_request_one done for
request reset: 0
[    6.007541] arizona spi-WM510205:00: regulator_bulk_enable done,
enable core supplies: 0
[    6.010032] arizona spi-WM510205:00: regulator_enable done, enable DCVDD: 0
[    6.017864] arizona spi-WM510205:00: arizona_disabe_reset
[    6.017875] arizona spi-WM510205:00: regcache_cache_only
[    6.019067] arizona spi-WM510205:00: regmap_read : read ID
register, return value: 0
[    6.019077] arizona spi-WM510205:00: found device ID: ffff


I asked to get more technical docs / datasheets from lenovo , but I do
not think, that I will get them.

Has anybody directions and hints / some tools known to get started
with win8.1 to get such hardware details extracted? I mean, it must
work under windows, why to not look there and write down / dump whats
needed.

Any hints or suggestions for me ?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Fri, Sep 04, 2015 at 03:32:03PM +0200, Christian Hartmann wrote:
> Hi,
> 
> 
> 2015-09-02 10:13 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
> > On Tue, Sep 01, 2015 at 11:45:31AM +0200, Christian Hartmann wrote:
> >> hi
> >>
> >> 2015-08-28 11:50 GMT+02:00 Christian Hartmann <cornogle@googlemail.com>:
> >> >
> > The chip select being wrong could well be the issue, perhaps the
> > Windows driver supports multiple chipselects where as the Linux
> > one doesn't? Do you have access to any datasheets for the SPI on
> > the AP? Alternatively you could try hacking it to use chip select
> > 0 and see if that makes the system work, seems like a long shot
> > but perhaps worth a quick go.
> >
> > Thanks,
> > Charles
> 
> ok, that was a one-shot, in effect nothing changed .
> I did set the num_chipsselect = 1 (as in vanilla kernels, so its more
> a revert) and
> changed the cs value from 1 to 0 (as a testpatch).
> as soon as the SPI device WM510205:00 is allocated,
> it tries to add the acpi_resource and in the case of the wrong SPI
> chip_select with the value 1 from the DSDT ACPI table entry, but here
> I set it again to 0.
> 
> expected : chip id register can be read, but
> nothing changed. the logs are the same in the end.
> I saw also that acpi_add_resource tries to add an irq (init with -1), but fails

Not entirely unexpected I guess, but certainly my gut feel here
is that this is a problem with the chip selects. I guess really
trying to find any available documentation on the AP/SPI and
tearing apart the SPI driver are the next steps from here. But
afraid I don't really have any great ideas for diving much
deeper. I will try to chase the Windows guys here again and see
if I can gain any clues from them but I don't really know at what
level these things are abstracted in Windows and thus if they can
really help us much.

Thanks,
Charles

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

[Christian Hartmann]

Hello,

2015-09-04 16:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> Not entirely unexpected I guess, but certainly my gut feel here
> is that this is a problem with the chip selects. I guess really
> trying to find any available documentation on the AP/SPI and
what do you mean with AP ?

I have googled and found some technical datasheets and
developer documentation about the marvell pxa27 under this link/webpage
http://www.marvell.com/application-processors/pxa-family/

I also asked lenovo about datasheets (not the short brief productsheet) to get
facts about it. But again,  I do not think that lenovo will ever
support me in this case.
if I got some datasheets and if its not against laws etc I will report it here.

> tearing apart the SPI driver are the next steps from here. But
> afraid I don't really have any great ideas for diving much
> deeper. I will try to chase the Windows guys here again and see
That would be nice, hope they got some glues.

> if I can gain any clues from them but I don't really know at what
> level these things are abstracted in Windows and thus if they can
> really help us much.
>
> Thanks,
> Charles

Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Mon, Sep 07, 2015 at 09:58:22AM +0200, Christian Hartmann wrote:
> Hello,
> 
> 2015-09-04 16:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> > Not entirely unexpected I guess, but certainly my gut feel here
> > is that this is a problem with the chip selects. I guess really
> > trying to find any available documentation on the AP/SPI and
> what do you mean with AP ?
> 
> I have googled and found some technical datasheets and
> developer documentation about the marvell pxa27 under this link/webpage
> http://www.marvell.com/application-processors/pxa-family/
> 
> I also asked lenovo about datasheets (not the short brief productsheet) to get
> facts about it. But again,  I do not think that lenovo will ever
> support me in this case.
> if I got some datasheets and if its not against laws etc I will report it here.
> 
> > tearing apart the SPI driver are the next steps from here. But
> > afraid I don't really have any great ideas for diving much
> > deeper. I will try to chase the Windows guys here again and see
> That would be nice, hope they got some glues.
> 
> > if I can gain any clues from them but I don't really know at what
> > level these things are abstracted in Windows and thus if they can
> > really help us much.

Ok no major hints from them, they do have a 10 inch version of
the same tablet lying around though so I will get them to post
that up and have a look see if I can figure anything out.

If you had anywhere I can pull in what you have done already that
would be handy.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Mon, Sep 07, 2015 at 09:58:22AM +0200, Christian Hartmann wrote:
> Hello,
> 
> 2015-09-04 16:34 GMT+02:00 Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>:
> > Not entirely unexpected I guess, but certainly my gut feel here
> > is that this is a problem with the chip selects. I guess really
> > trying to find any available documentation on the AP/SPI and
> what do you mean with AP ?
> 
> I have googled and found some technical datasheets and
> developer documentation about the marvell pxa27 under this link/webpage
> http://www.marvell.com/application-processors/pxa-family/
> 
> I also asked lenovo about datasheets (not the short brief productsheet) to get
> facts about it. But again,  I do not think that lenovo will ever
> support me in this case.
> if I got some datasheets and if its not against laws etc I will report it here.
> 
> > tearing apart the SPI driver are the next steps from here. But
> > afraid I don't really have any great ideas for diving much
> > deeper. I will try to chase the Windows guys here again and see
> That would be nice, hope they got some glues.
> 
> > if I can gain any clues from them but I don't really know at what
> > level these things are abstracted in Windows and thus if they can
> > really help us much.

Ok no major hints from them, they do have a 10 inch version of
the same tablet lying around though so I will get them to post
that up and have a look see if I can figure anything out.

If you had anywhere I can pull in what you have done already that
would be handy.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Christian Hartmann]

Hi,


> Ok no major hints from them, they do have a 10 inch version of
> the same tablet lying around though so I will get them to post
> that up and have a look see if I can figure anything out.
>
nice to hear, I am stuck at reading the chip registers ID value
correctly at the moment.

> If you had anywhere I can pull in what you have done already that
> would be handy.
I have no such public or secure repo setup yet, time to do that.
in that case with the wm510205 branched from torvalds/master, what do
you prefer or
is it okay, if I make an repo on github for it ??
Another options are available too, I can also make them as a patch
series (in email format)
and send them to this group or to you.

Let me know whats the best way for all of us
cheers
chris
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Charles Keepax]

On Tue, Sep 29, 2015 at 09:48:45AM +0200, Christian Hartmann wrote:
> Hi,
> 
> 
> > Ok no major hints from them, they do have a 10 inch version of
> > the same tablet lying around though so I will get them to post
> > that up and have a look see if I can figure anything out.
> >
> nice to hear, I am stuck at reading the chip registers ID value
> correctly at the moment.
> 
> > If you had anywhere I can pull in what you have done already that
> > would be handy.
> I have no such public or secure repo setup yet, time to do that.
> in that case with the wm510205 branched from torvalds/master, what do
> you prefer or
> is it okay, if I make an repo on github for it ??

Yeah branched of Linus's tree is probably best and shoving it on
github works for me.

Thanks,
Charles

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

[Christian Hartmann]

> Yeah branched of Linus's tree is probably best and shoving it on
> github works for me.
>
> Thanks,
> Charles

wow, I had already a github account for some years, but not used it yet.

I just forked torvalds/linux now and I have to re-apply my patches
into the github workflow.

Anyway, I give you the url, where you can find the patches I made.
I will update the repository today.

I actually clone the linux repo. In the next steps I create a yoga851f
branch , will apply the patches
and will push them soon back to github.

The URL will be:
https://github.com/cornbob/linux

Overview under:
https://github.com/cornbob


cheers
chris