| Message ID | CAKor6Td83zgOS+iHGHGhFW4n26H=tC-QQDuzaHHfybhLeH-jvw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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.
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
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
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
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
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
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...
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
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().
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
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.
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
> 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
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.
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
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