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

Message ID CAKor6Td83zgOS+iHGHGhFW4n26H=tC-QQDuzaHHfybhLeH-jvw@mail.gmail.com
State New
Headers show

Commit Message

Christian Hartmann July 15, 2015, 7:01 a.m. UTC
2015-07-13 11:53 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
>> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
>> > 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@kernel.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@googlemail.com>
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@googlemail.com>



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

Comments

Christian Hartmann July 15, 2015, 7:17 a.m. UTC | #1
2015-07-15 9:01 GMT+02:00 Christian Hartmann <cornogle@googlemail.com>:
> 2015-07-13 11:53 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
>> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
>>> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
>>> > 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@kernel.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@googlemail.com>
> 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@googlemail.com>
>
> 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
Charles Keepax July 15, 2015, 8:12 a.m. UTC | #2
On Wed, Jul 15, 2015 at 09:17:08AM +0200, Christian Hartmann wrote:
> 2015-07-15 9:01 GMT+02:00 Christian Hartmann <cornogle@googlemail.com>:
> > 2015-07-13 11:53 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
> >> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
> >>> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
> >>> > 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@kernel.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@googlemail.com>
> > 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@googlemail.com>
> >
> > 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
Mark Brown July 15, 2015, 9:17 a.m. UTC | #3
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.
Christian Hartmann July 17, 2015, 6:56 a.m. UTC | #4
2015-07-15 11:17 GMT+02:00 Mark Brown <broonie@kernel.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
Christian Hartmann July 17, 2015, 7:11 a.m. UTC | #5
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
Charles Keepax July 17, 2015, 8:54 a.m. UTC | #6
On Fri, Jul 17, 2015 at 08:56:26AM +0200, Christian Hartmann wrote:
> 2015-07-15 11:17 GMT+02:00 Mark Brown <broonie@kernel.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
Christian Hartmann Aug. 10, 2015, 7 a.m. UTC | #7
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
Charles Keepax Aug. 10, 2015, 7:53 a.m. UTC | #8
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
Christian Hartmann Aug. 10, 2015, 8 a.m. UTC | #9
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...
Charles Keepax Aug. 10, 2015, 8:10 a.m. UTC | #10
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
Mika Westerberg Aug. 10, 2015, 8:35 a.m. UTC | #11
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().
Christian Hartmann Aug. 10, 2015, 9:20 a.m. UTC | #12
2015-08-10 10:35 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> 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
Mika Westerberg Aug. 10, 2015, 9:26 a.m. UTC | #13
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.
Christian Hartmann Aug. 10, 2015, 12:43 p.m. UTC | #14
2015-08-10 11:26 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> 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
Christian Hartmann Aug. 10, 2015, 1:48 p.m. UTC | #15
> 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
Mika Westerberg Aug. 10, 2015, 2:02 p.m. UTC | #16
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.
Christian Hartmann Aug. 14, 2015, 10:08 a.m. UTC | #17
2015-08-10 16:02 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> 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

Patch
diff mbox

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