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

[Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Jul 15, 2015 at 09:17:08AM +0200, Christian Hartmann wrote:
> 2015-07-15 9:01 GMT+02:00 Christian Hartmann <cornogle@xxxxxxxxxxxxxx>:
> > 2015-07-13 11:53 GMT+02:00 Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
> >> On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
> >>> 2015-06-30 12:34 GMT+02:00 Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx>:
> >>> > 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@xxxxxxxxxx>:
> >>> >> > 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@xxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html