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:
- IRQ
- Reset GPIO
- 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