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