diff mbox

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

Message ID CAKor6Tep1jjOnoPn7e5Djird3RVDNP8Gjcb8HOKO6g-_R5++VQ@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Christian Hartmann Aug. 19, 2015, 10:29 a.m. UTC 
Hi

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

ok, after some changes I got it compiled, but there seems another
mistake (by me?), it does not find the GPIOs yet.

[    5.851524] sst-acpi 80860F28:00: No matching ASoC machine driver found
[    5.873318] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    5.877982] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    5.878667] rfkill_gpio BCM2E84:00: GPIO lookup for consumer reset
[    5.878677] rfkill_gpio BCM2E84:00: using ACPI for GPIO lookup
[    5.878683] acpi BCM2E84:00: GPIO: looking up reset-gpios
[    5.878690] acpi BCM2E84:00: GPIO: _DSD returned BCM2E84:00 3 0 0 0
[    5.878836] rfkill_gpio BCM2E84:00: GPIO lookup for consumer shutdown
[    5.878844] rfkill_gpio BCM2E84:00: using ACPI for GPIO lookup
[    5.878850] acpi BCM2E84:00: GPIO: looking up shutdown-gpios
[    5.878857] acpi BCM2E84:00: GPIO: _DSD returned BCM2E84:00 3 1 0 0
[    5.884010] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    5.884019] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    5.884102] spi spi-WM510205:00: checking WM510205 with bmp180
[    5.884108] spi spi-WM510205:00: checking WM510205 with bmp181
[    5.884113] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    5.884140] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    5.884146] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    5.884151] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    5.884155] arizona spi-WM510205:00: regmap set to wm5102_spi
[    5.884765] rfkill_gpio BCM2E84:00: BCM2E84:00 device registered.
[    5.884831] rfkill_gpio LNV4752:00: GPIO lookup for consumer reset
[    5.884837] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
[    5.884843] acpi LNV4752:00: GPIO: looking up reset-gpios
[    5.884850] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 0 0 0
[    5.884926] rfkill_gpio LNV4752:00: GPIO lookup for consumer shutdown
[    5.884931] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup
[    5.884936] acpi LNV4752:00: GPIO: looking up shutdown-gpios
[    5.884941] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 1 0 0
[    5.884977] acpi LNV4752:00: GPIO: looking up shutdown-gpio
[    5.884983] acpi LNV4752:00: GPIO: looking up 0 in _CRS
[    5.885019] gpio-411 (reset): gpiod_request: status -16
[    5.889424] arizona spi-WM510205:00: spi_irq = -1
[    5.889435] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    5.889442] arizona spi-WM510205:00: acpi_dev_add_driver_gpios done, 0
[    5.889447] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    5.889774] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    5.889781] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.889788] acpi WM510205:00: GPIO: looking up reset-gpios
[    5.889794] acpi WM510205:00: GPIO: looking up reset-gpio
[    5.889798] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.891255] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    5.891263] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.891269] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    5.891274] acpi WM510205:00: GPIO: looking up ldoena-gpio
[    5.891279] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.891324] gpio-342 (reset): gpiod_request: status -16
[    5.891330] arizona spi-WM510205:00: Failed to get ldoena line: -16
[    5.891335] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.891409] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    5.891415] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  23
[    5.891421] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  -184850384
[    5.891425] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    5.891430] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    5.891434] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    5.894845] rfkill_gpio: probe of LNV4752:00 failed with error -16
[    5.906587] LDO1: Failed to request enable GPIO23: -517
[    5.906673] arizona spi-WM510205:00: Failed to register LDO1 supply: -517
[    5.923633] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.923687] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    5.923718] spi-WM510205:00 supply DCVDD not found, using dummy regulator
[    5.923751] ------------[ cut here ]------------
[    5.923763] WARNING: CPU: 2 PID: 474 at drivers/gpio/gpiolib.c:86
gpio_to_desc+0xbb/0xd0()

in  arizona-spi I try to map these GPIOs, which I want to get in
arizona-core: arizona_dev_init

 #endif


@@ -812,6 +840,70 @@ EXPORT_SYMBOL_GPL(arizona_of_match);
 #else
 static inline int arizona_of_get_core_pdata(struct arizona *arizona)
 {
+       struct arizona_pdata *pdata = &arizona->pdata;
+       struct gpio_desc *reset, *ldoena;
+       int ret;
+
+       switch (arizona->type) {
+       case WM5102:
+               /* TODO:
+                * get the actual GPIO pins from ACPI namespace
+                * instead of hardcoding it here
+               pdata->reset = 0x03 ;
+               pdata->ldoena = 0x17 ;
+                */
+
+               reset = devm_gpiod_get_optional(arizona->dev,
+                                                       "reset",
+                                                       GPIOD_OUT_LOW);
+               if (IS_ERR(reset)) {
+                       ret = PTR_ERR(reset);
+                       dev_err(arizona->dev, "Failed to get reset
line: %d\n", ret);
+                       pdata->reset = 0x03 ;
+                       /*
+                        *return ret;
+                        */
+               } else {
+                       pdata->reset = (int )reset;
+               }
+
+               ldoena = devm_gpiod_get_optional(arizona->dev,
+                                                       "ldoena",
+                                                       GPIOD_OUT_LOW);
+               if (IS_ERR(ldoena)) {
+                       ret = PTR_ERR(ldoena);
+                       dev_err(arizona->dev, "Failed to get ldoena
line: %d\n", ret);
+                       pdata->ldoena = 0x17 ;
+                       /*
+                        * return ret;
+                       */
+               } else {
+                       pdata->ldoena = (int )ldoena;
+               }
+
+               pdata->irq_flags = IRQF_TRIGGER_RISING|
+                                       IRQF_TRIGGER_FALLING;
+
+               /* get the ACPI GpioInt ressource for this device
+                *
+                */
+               if (ACPI_COMPANION(arizona->dev)) {
+                       pdata->irq_gpio =
acpi_dev_gpio_irq_get(ACPI_COMPANION(arizona->dev), 0);
+               } else {
+                       pdata->irq_gpio = 0x04 ;
+               }
+
+               dev_err(arizona->dev, "arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = %i\n",
+                       pdata->irq_gpio);
+               dev_err(arizona->dev, "arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  %i\n",
+                       pdata->ldoena);
+               dev_err(arizona->dev, "arizona_of_get_core_pdata
(ACPI) using reset GPIO =  %i\n",
+                       pdata->reset);
+               break;
+       default:
+               break;
+       }
+

so far, this are the most important and current testing changes.
Does anybody has some ideas or hints about how to get the annoying
GPIOs ldoena and reset ?

cheers
chris

Comments

Mika Westerberg Aug. 19, 2015, 1:43 p.m. UTC | #1 
On Wed, Aug 19, 2015 at 12:29:08PM +0200, Christian Hartmann wrote:
> Hi
> 
> >> 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.
> 
> ok, after some changes I got it compiled, but there seems another
> mistake (by me?), it does not find the GPIOs yet.
> 

...

> [    5.891255] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    5.891263] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    5.891269] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    5.891274] acpi WM510205:00: GPIO: looking up ldoena-gpio
> [    5.891279] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.891324] gpio-342 (reset): gpiod_request: status -16
> [    5.891330] arizona spi-WM510205:00: Failed to get ldoena line: -16

It returns -EBUSY so is the GPIO already requested?

> [    5.891335] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.891409] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    5.891415] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  23
> [    5.891421] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  -184850384
> [    5.891425] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    5.891430] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    5.891434] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    5.894845] rfkill_gpio: probe of LNV4752:00 failed with error -16
> [    5.906587] LDO1: Failed to request enable GPIO23: -517
> [    5.906673] arizona spi-WM510205:00: Failed to register LDO1 supply: -517
> [    5.923633] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    5.923687] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    5.923718] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> [    5.923751] ------------[ cut here ]------------
> [    5.923763] WARNING: CPU: 2 PID: 474 at drivers/gpio/gpiolib.c:86
> gpio_to_desc+0xbb/0xd0()
> 
> in  arizona-spi I try to map these GPIOs, which I want to get in
> arizona-core: arizona_dev_init
> 
> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> index 1e845f6..52872a0 100644
> --- a/drivers/mfd/arizona-spi.c
> +++ b/drivers/mfd/arizona-spi.c
> @@ -18,28 +18,58 @@
>  #include <linux/slab.h>
>  #include <linux/spi/spi.h>
>  #include <linux/of.h>
> +#include <linux/acpi.h>
> 
>  #include <linux/mfd/arizona/core.h>
> 
>  #include "arizona.h"
> 
> +const struct acpi_gpio_params reset_gpio = { 1, 0, false};
> +const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
> +
> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
> +       { "reset_gpio", &reset_gpio, 1,},
> +       { "ldoena_gpio", &ldoena_gpio, 1},

The correct names are "reset-gpios" and "ldoena-gpios". If you call

        reset = devm_gpiod_get_optional(arizona->dev, "reset", GPIOD_OUT_LOW);

GPIO core will look for "reset-gpios" and then "reset-gpio" not
"reset_gpio" so it will not find the mapping.
Christian Hartmann Aug. 20, 2015, 9:38 a.m. UTC | #2 
Hi again,

>> in  arizona-spi I try to map these GPIOs, which I want to get in
>> arizona-core: arizona_dev_init
>>
>> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
>> index 1e845f6..52872a0 100644
>> --- a/drivers/mfd/arizona-spi.c
>> +++ b/drivers/mfd/arizona-spi.c
>> @@ -18,28 +18,58 @@
>>  #include <linux/slab.h>
>>  #include <linux/spi/spi.h>
>>  #include <linux/of.h>
>> +#include <linux/acpi.h>
>>
>>  #include <linux/mfd/arizona/core.h>
>>
>>  #include "arizona.h"
>>
>> +const struct acpi_gpio_params reset_gpio = { 1, 0, false};
>> +const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
>> +
>> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
>> +       { "reset_gpio", &reset_gpio, 1,},
>> +       { "ldoena_gpio", &ldoena_gpio, 1},
>
> The correct names are "reset-gpios" and "ldoena-gpios". If you call
>
>         reset = devm_gpiod_get_optional(arizona->dev, "reset", GPIOD_OUT_LOW);
>
> GPIO core will look for "reset-gpios" and then "reset-gpio" not
> "reset_gpio" so it will not find the mapping.

yes you are right, I had fixed it yesterday by changing the names.

+const struct acpi_gpio_params reset_gpios = { 1, 0, false};
+const struct acpi_gpio_params ldoena_gpios = { 2, 0, false};
+
+const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
+       { "reset-gpios", &reset_gpios, 1,},
+       { "ldoena-gpios", &ldoena_gpios, 1},
+       { },
+};



Today I can see that the mapping is working as seen below.
But for unknown reasons I got wrong values read
via devm_gpiod_get_optional() in the arizona_dev_init ->
arizona_of_get_core_pdata()

[    6.387993] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    6.389258] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    6.389416] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    6.389424] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    6.389567] spi spi-WM510205:00: checking WM510205 with bmp180
[    6.389574] spi spi-WM510205:00: checking WM510205 with bmp181
[    6.389578] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    6.405723] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    6.405735] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    6.405740] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    6.405744] arizona spi-WM510205:00: regmap set to wm5102_spi
[    6.406557] arizona spi-WM510205:00: spi_irq = -1
[    6.406565] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    6.406569] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    6.406574] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    6.406580] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.406585] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.406590] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.406597] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.406673] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.406724] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    6.406729] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.406733] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    6.406739] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
[    6.406790] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.406844] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    6.406850] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  -185173228
[    6.406855] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  -184741840
[    6.406859] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    6.406864] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    6.406868] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    6.407100] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    6.407131] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.407162] LDO1: supplied by regulator-dummy
[    6.407214] ------------[ cut here ]------------
[    6.407226] WARNING: CPU: 0 PID: 472 at drivers/gpio/gpiolib.c:86
gpio_to_desc+0xbb/0xd0()


did I cast the values wrong?

cheers
chris
Mika Westerberg Aug. 20, 2015, 9:45 a.m. UTC | #3 
On Thu, Aug 20, 2015 at 11:38:13AM +0200, Christian Hartmann wrote:
> Hi again,
> 
> >> in  arizona-spi I try to map these GPIOs, which I want to get in
> >> arizona-core: arizona_dev_init
> >>
> >> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> >> index 1e845f6..52872a0 100644
> >> --- a/drivers/mfd/arizona-spi.c
> >> +++ b/drivers/mfd/arizona-spi.c
> >> @@ -18,28 +18,58 @@
> >>  #include <linux/slab.h>
> >>  #include <linux/spi/spi.h>
> >>  #include <linux/of.h>
> >> +#include <linux/acpi.h>
> >>
> >>  #include <linux/mfd/arizona/core.h>
> >>
> >>  #include "arizona.h"
> >>
> >> +const struct acpi_gpio_params reset_gpio = { 1, 0, false};
> >> +const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
> >> +
> >> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
> >> +       { "reset_gpio", &reset_gpio, 1,},
> >> +       { "ldoena_gpio", &ldoena_gpio, 1},
> >
> > The correct names are "reset-gpios" and "ldoena-gpios". If you call
> >
> >         reset = devm_gpiod_get_optional(arizona->dev, "reset", GPIOD_OUT_LOW);
> >
> > GPIO core will look for "reset-gpios" and then "reset-gpio" not
> > "reset_gpio" so it will not find the mapping.
> 
> yes you are right, I had fixed it yesterday by changing the names.
> 
> +const struct acpi_gpio_params reset_gpios = { 1, 0, false};
> +const struct acpi_gpio_params ldoena_gpios = { 2, 0, false};
> +
> +const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
> +       { "reset-gpios", &reset_gpios, 1,},
> +       { "ldoena-gpios", &ldoena_gpios, 1},
> +       { },
> +};
> 
> 
> 
> Today I can see that the mapping is working as seen below.
> But for unknown reasons I got wrong values read
> via devm_gpiod_get_optional() in the arizona_dev_init ->
> arizona_of_get_core_pdata()
> 
> [    6.387993] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
> [    6.389258] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
> [    6.389416] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    6.389424] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    6.389567] spi spi-WM510205:00: checking WM510205 with bmp180
> [    6.389574] spi spi-WM510205:00: checking WM510205 with bmp181
> [    6.389578] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.405723] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.405735] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.405740] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.405744] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.406557] arizona spi-WM510205:00: spi_irq = -1
> [    6.406565] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> arizona_acpi_gpios added done, 0
> [    6.406569] arizona spi-WM510205:00: arizona_spi_probe done,
> calling arizona_dev_init
> [    6.406574] arizona spi-WM510205:00: dev_set_drvdata done for 1
> [    6.406580] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    6.406585] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.406590] acpi WM510205:00: GPIO: looking up reset-gpios
> [    6.406597] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    6.406673] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.406724] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    6.406729] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.406733] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    6.406739] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
> [    6.406790] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.406844] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    6.406850] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  -185173228
> [    6.406855] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  -184741840
> [    6.406859] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    6.406864] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    6.406868] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    6.407100] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    6.407131] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    6.407162] LDO1: supplied by regulator-dummy
> [    6.407214] ------------[ cut here ]------------
> [    6.407226] WARNING: CPU: 0 PID: 472 at drivers/gpio/gpiolib.c:86
> gpio_to_desc+0xbb/0xd0()
> 
> 
> did I cast the values wrong?

devm_gpiod_get_optional() returns GPIO descriptor which should not be
cast to anything else. If you want to get the numberic value for
logging purposes you can call desc_to_gpio(desc) for the returned
descriptor.
Christian Hartmann Aug. 20, 2015, 11:34 a.m. UTC | #4 
Hi,

2015-08-20 11:45 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> devm_gpiod_get_optional() returns GPIO descriptor which should not be
> cast to anything else. If you want to get the numberic value for
> logging purposes you can call desc_to_gpio(desc) for the returned
> descriptor.


that done, it looks much better. thank you, Mika

I got a new error instead for the LDO1 as seen below:

[    5.951646] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    5.951650] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.951656] acpi WM510205:00: GPIO: looking up reset-gpios
[    5.951663] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    5.951779] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.951831] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    5.951838] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    5.951843] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    5.951852] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
[    5.951909] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    5.951975] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    5.951980] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  405
[    5.951985] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  342
[    5.951989] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    5.951994] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    5.951999] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    5.952283] arizona spi-WM510205:00: mfd_add_devices done for 1
[    5.952291] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.952338] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    5.952381] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    5.952387] LDO1: supplied by regulator-dummy
[    5.952452] arizona spi-WM510205:00: regulator_get done for 1
[    5.952457] ------------[ cut here ]------------
[    5.952469] WARNING: CPU: 3 PID: 464 at drivers/gpio/gpiolib.c:86
gpio_to_desc+0xbb/0xd0()
[    5.952472] invalid GPIO -184850384
[    5.952475] Modules linked in: int3400_thermal(+)
int3403_thermal(+) processor_thermal_device(+)
snd_soc_sst_mfld_platform int3402_thermal in
t340x_thermal_zone rfkill_gpio acpi_thermal_rel intel_soc_dts_iosf
acpi_pad spi_pxa2xx_platform(+) i2c_designware_platform(+) rfkill
pwm_lpss_pl
atform snd_soc_sst_acpi pwm_lpss i2c_designware_core ax88179_178a usbnet i2c_hid
[    5.952510] CPU: 3 PID: 464 Comm: systemd-udevd Not tainted 4.2.0.84-rc7 #252
[    5.952513] Hardware name: LENOVO 60072/INVALID, BIOS 02WT18WW 08/01/2014
[    5.952517]  c0e619a7 b4cc43d7 00000000 f3687974 c0b606c4 f36879b4
f36879a4 c044cad8
[    5.952528]  c0d90c73 f36879d4 000001d0 c0d90c84 00000056 c0711d6b
c0711d6b c0ebf250
[    5.952538]  f4fb6830 f4fb6830 f36879c0 c044cb4f 00000009 f36879b4
c0d90c73 f36879d4
[    5.952548] Call Trace:
[    5.952558]  [<c0b606c4>] dump_stack+0x41/0x52
[    5.952565]  [<c044cad8>] warn_slowpath_common+0x88/0xc0
[    5.952570]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
[    5.952575]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
[    5.952579]  [<c044cb4f>] warn_slowpath_fmt+0x3f/0x60
[    5.952584]  [<c0711d6b>] gpio_to_desc+0xbb/0xd0
[    5.952590]  [<c0713f7b>] gpio_request_one+0x1b/0xf0
[    5.952595]  [<c0710da3>] devm_gpio_request_one+0x43/0x80
[    5.952602]  [<c08e6de7>] arizona_dev_init+0x257/0xc90
[    5.952607]  [<c077bf65>] ? acpi_get_data_full+0x68/0x77
[    5.952614]  [<c08c46e9>] ? dev_err+0x39/0x60
[    5.952619]  [<c08e8635>] arizona_spi_probe+0x195/0x240
[    5.952625]  [<c075c016>] ? acpi_dev_pm_attach+0x57/0x79
[    5.952632]  [<c092e286>] spi_drv_probe+0x36/0x60
[    5.952640]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
[    5.952646]  [<c075e61b>] ? acpi_driver_match_device+0x36/0x3f
[    5.952651]  [<c092eab2>] ? spi_match_device+0x22/0x70
[    5.952655]  [<c08c82fb>] __device_attach_driver+0x5b/0x70
[    5.952660]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
[    5.952665]  [<c08c6197>] bus_for_each_drv+0x57/0xa0
[    5.952670]  [<c08c7d02>] __device_attach+0xb2/0x120
[    5.952674]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
[    5.952679]  [<c08c8442>] device_initial_probe+0x12/0x20
[    5.952685]  [<c08c7267>] bus_probe_device+0x67/0x70
[    5.952690]  [<c08c52c0>] device_add+0x3c0/0x5b0
[    5.952695]  [<c092e859>] spi_add_device+0xe9/0x220
[    5.952700]  [<c092da10>] ? spi_drv_shutdown+0x20/0x20
[    5.952706]  [<c06e58a4>] ? strlcpy+0x34/0x50
[    5.952712]  [<c0930db3>] acpi_spi_add_device+0x123/0x170
[    5.952739]  [<c077b7fd>] acpi_ns_walk_namespace+0xba/0x16d
[    5.952745]  [<c077bcd7>] acpi_walk_namespace+0x8d/0xbc
[    5.952750]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
[    5.952755]  [<c0930a19>] spi_register_master+0x229/0x420
[    5.952760]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
[    5.952766]  [<c0930c4b>] devm_spi_register_master+0x3b/0x80
[    5.952775]  [<f81cec4a>] pxa2xx_spi_probe+0x24a/0x530 [spi_pxa2xx_platform]
[    5.952781]  [<c075bfd9>] ? acpi_dev_pm_attach+0x1a/0x79
[    5.952786]  [<c08ca01d>] platform_drv_probe+0x2d/0x80
[    5.952792]  [<c08c7802>] ? driver_sysfs_add+0x62/0x80
[    5.952796]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
[    5.952801]  [<c08c8261>] __driver_attach+0x71/0x80
[    5.952806]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
[    5.952811]  [<c08c60d7>] bus_for_each_dev+0x57/0xa0
[    5.952817]  [<c08c79af>] driver_attach+0x1f/0x30
[    5.952821]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
[    5.952826]  [<c08c7557>] bus_add_driver+0x1c7/0x290
[    5.952831]  [<f81d5000>] ? 0xf81d5000
[    5.952835]  [<f81d5000>] ? 0xf81d5000
[    5.952839]  [<c08c8b5a>] driver_register+0x5a/0xe0
[    5.952845]  [<c06ec1c1>] ? kvasprintf+0x41/0x50
[    5.952850]  [<c08c9f83>] __platform_driver_register+0x43/0x50
[    5.952857]  [<f81d5012>] pxa2xx_spi_init+0x12/0x1000 [spi_pxa2xx_platform]
[    5.952863]  [<c0400472>] do_one_initcall+0xc2/0x1f0
[    5.952867]  [<f81d5000>] ? 0xf81d5000
[    5.952873]  [<c0ad0a4f>] ? netlink_broadcast_filtered+0x10f/0x390
[    5.952880]  [<c052fd2e>] ? free_pages_prepare+0x1ce/0x320
[    5.952886]  [<c05718ad>] ? kmem_cache_alloc_trace+0x17d/0x1e0
[    5.952890]  [<c0570b87>] ? kfree+0xe7/0x130
[    5.952897]  [<c0b5c764>] do_init_module+0x54/0x1cd
[    5.952903]  [<c04c7895>] load_module+0x1145/0x17d0
[    5.952910]  [<c04c4549>] ? copy_module_from_fd.isra.53+0x109/0x1a0
[    5.952916]  [<c04c810d>] SyS_finit_module+0x8d/0xd0
[    5.952922]  [<c0544ce3>] ? vm_mmap_pgoff+0x93/0xb0
[    5.952929]  [<c0b6a20f>] sysenter_do_call+0x12/0x12
[    5.952933] ---[ end trace 1e444d913002c55d ]---
[    5.952936] gpiod_request: invalid GPIO
[    5.952941] arizona spi-WM510205:00: Failed to request /RESET: -22
[    5.982461] arizona: probe of spi-WM510205:00 failed with error -22
[    5.982478] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
[    5.988213] i2c i2c-11: Failed to register i2c client MAGN0001:00
at 0x1d (-16)

the code in arizona-core.c arizona_dev_init looks like

if (arizona->pdata.reset) {
 /* Start out with /RESET low to put the chip into reset */
 ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
}

which fails here. seems that I have to use desc_to_gpio() here too.
Does anybody have an idea whats wrong with LDO1? I try the
desc_to_gpio at first and will report soon

cheers
chris
Christian Hartmann Aug. 20, 2015, 11:52 a.m. UTC | #5 
hi,


2015-08-20 13:34 GMT+02:00 Christian Hartmann <cornogle@googlemail.com>:

> the code in arizona-core.c arizona_dev_init looks like
>
> if (arizona->pdata.reset) {
>  /* Start out with /RESET low to put the chip into reset */
>  ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
> }
>
> which fails here. seems that I have to use desc_to_gpio() here too.
> Does anybody have an idea whats wrong with LDO1? I try the
> desc_to_gpio at first and will report soon
>
> cheers
> chris

hm, in include/linux/mfd/arizona/pdata.h
the structur arizona_pdata has declared ints for the GPIOs ldoena and reset.

struct arizona_pdata {
int reset;      /** GPIO controlling /RESET, if any */
int ldoena;     /** GPIO controlling LODENA, if any */
}

so I have to respect the type of the two fields while getting the GPIO
descriptors.
On the other hand I can also add two new fields or change the code
that it uses the GPIO names instead of the numbers.

What do you think?
Mika Westerberg Aug. 20, 2015, 11:58 a.m. UTC | #6 
On Thu, Aug 20, 2015 at 01:34:00PM +0200, Christian Hartmann wrote:
> Hi,
> 
> 2015-08-20 11:45 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> > devm_gpiod_get_optional() returns GPIO descriptor which should not be
> > cast to anything else. If you want to get the numberic value for
> > logging purposes you can call desc_to_gpio(desc) for the returned
> > descriptor.
> 
> 
> that done, it looks much better. thank you, Mika
> 
> I got a new error instead for the LDO1 as seen below:
> 
> [    5.951646] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    5.951650] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    5.951656] acpi WM510205:00: GPIO: looking up reset-gpios
> [    5.951663] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    5.951779] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.951831] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    5.951838] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    5.951843] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    5.951852] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
> [    5.951909] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    5.951975] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    5.951980] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  405
> [    5.951985] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  342
> [    5.951989] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    5.951994] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    5.951999] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    5.952283] arizona spi-WM510205:00: mfd_add_devices done for 1
> [    5.952291] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    5.952338] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    5.952381] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
> [    5.952387] LDO1: supplied by regulator-dummy
> [    5.952452] arizona spi-WM510205:00: regulator_get done for 1
> [    5.952457] ------------[ cut here ]------------
> [    5.952469] WARNING: CPU: 3 PID: 464 at drivers/gpio/gpiolib.c:86
> gpio_to_desc+0xbb/0xd0()
> [    5.952472] invalid GPIO -184850384
> [    5.952475] Modules linked in: int3400_thermal(+)
> int3403_thermal(+) processor_thermal_device(+)
> snd_soc_sst_mfld_platform int3402_thermal in
> t340x_thermal_zone rfkill_gpio acpi_thermal_rel intel_soc_dts_iosf
> acpi_pad spi_pxa2xx_platform(+) i2c_designware_platform(+) rfkill
> pwm_lpss_pl
> atform snd_soc_sst_acpi pwm_lpss i2c_designware_core ax88179_178a usbnet i2c_hid
> [    5.952510] CPU: 3 PID: 464 Comm: systemd-udevd Not tainted 4.2.0.84-rc7 #252
> [    5.952513] Hardware name: LENOVO 60072/INVALID, BIOS 02WT18WW 08/01/2014
> [    5.952517]  c0e619a7 b4cc43d7 00000000 f3687974 c0b606c4 f36879b4
> f36879a4 c044cad8
> [    5.952528]  c0d90c73 f36879d4 000001d0 c0d90c84 00000056 c0711d6b
> c0711d6b c0ebf250
> [    5.952538]  f4fb6830 f4fb6830 f36879c0 c044cb4f 00000009 f36879b4
> c0d90c73 f36879d4
> [    5.952548] Call Trace:
> [    5.952558]  [<c0b606c4>] dump_stack+0x41/0x52
> [    5.952565]  [<c044cad8>] warn_slowpath_common+0x88/0xc0
> [    5.952570]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
> [    5.952575]  [<c0711d6b>] ? gpio_to_desc+0xbb/0xd0
> [    5.952579]  [<c044cb4f>] warn_slowpath_fmt+0x3f/0x60
> [    5.952584]  [<c0711d6b>] gpio_to_desc+0xbb/0xd0
> [    5.952590]  [<c0713f7b>] gpio_request_one+0x1b/0xf0
> [    5.952595]  [<c0710da3>] devm_gpio_request_one+0x43/0x80
> [    5.952602]  [<c08e6de7>] arizona_dev_init+0x257/0xc90
> [    5.952607]  [<c077bf65>] ? acpi_get_data_full+0x68/0x77
> [    5.952614]  [<c08c46e9>] ? dev_err+0x39/0x60
> [    5.952619]  [<c08e8635>] arizona_spi_probe+0x195/0x240
> [    5.952625]  [<c075c016>] ? acpi_dev_pm_attach+0x57/0x79
> [    5.952632]  [<c092e286>] spi_drv_probe+0x36/0x60
> [    5.952640]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
> [    5.952646]  [<c075e61b>] ? acpi_driver_match_device+0x36/0x3f
> [    5.952651]  [<c092eab2>] ? spi_match_device+0x22/0x70
> [    5.952655]  [<c08c82fb>] __device_attach_driver+0x5b/0x70
> [    5.952660]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
> [    5.952665]  [<c08c6197>] bus_for_each_drv+0x57/0xa0
> [    5.952670]  [<c08c7d02>] __device_attach+0xb2/0x120
> [    5.952674]  [<c08c82a0>] ? driver_allows_async_probing+0x30/0x30
> [    5.952679]  [<c08c8442>] device_initial_probe+0x12/0x20
> [    5.952685]  [<c08c7267>] bus_probe_device+0x67/0x70
> [    5.952690]  [<c08c52c0>] device_add+0x3c0/0x5b0
> [    5.952695]  [<c092e859>] spi_add_device+0xe9/0x220
> [    5.952700]  [<c092da10>] ? spi_drv_shutdown+0x20/0x20
> [    5.952706]  [<c06e58a4>] ? strlcpy+0x34/0x50
> [    5.952712]  [<c0930db3>] acpi_spi_add_device+0x123/0x170
> [    5.952739]  [<c077b7fd>] acpi_ns_walk_namespace+0xba/0x16d
> [    5.952745]  [<c077bcd7>] acpi_walk_namespace+0x8d/0xbc
> [    5.952750]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
> [    5.952755]  [<c0930a19>] spi_register_master+0x229/0x420
> [    5.952760]  [<c0930c90>] ? devm_spi_register_master+0x80/0x80
> [    5.952766]  [<c0930c4b>] devm_spi_register_master+0x3b/0x80
> [    5.952775]  [<f81cec4a>] pxa2xx_spi_probe+0x24a/0x530 [spi_pxa2xx_platform]
> [    5.952781]  [<c075bfd9>] ? acpi_dev_pm_attach+0x1a/0x79
> [    5.952786]  [<c08ca01d>] platform_drv_probe+0x2d/0x80
> [    5.952792]  [<c08c7802>] ? driver_sysfs_add+0x62/0x80
> [    5.952796]  [<c08c7faa>] driver_probe_device+0x1ca/0x410
> [    5.952801]  [<c08c8261>] __driver_attach+0x71/0x80
> [    5.952806]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
> [    5.952811]  [<c08c60d7>] bus_for_each_dev+0x57/0xa0
> [    5.952817]  [<c08c79af>] driver_attach+0x1f/0x30
> [    5.952821]  [<c08c81f0>] ? driver_probe_device+0x410/0x410
> [    5.952826]  [<c08c7557>] bus_add_driver+0x1c7/0x290
> [    5.952831]  [<f81d5000>] ? 0xf81d5000
> [    5.952835]  [<f81d5000>] ? 0xf81d5000
> [    5.952839]  [<c08c8b5a>] driver_register+0x5a/0xe0
> [    5.952845]  [<c06ec1c1>] ? kvasprintf+0x41/0x50
> [    5.952850]  [<c08c9f83>] __platform_driver_register+0x43/0x50
> [    5.952857]  [<f81d5012>] pxa2xx_spi_init+0x12/0x1000 [spi_pxa2xx_platform]
> [    5.952863]  [<c0400472>] do_one_initcall+0xc2/0x1f0
> [    5.952867]  [<f81d5000>] ? 0xf81d5000
> [    5.952873]  [<c0ad0a4f>] ? netlink_broadcast_filtered+0x10f/0x390
> [    5.952880]  [<c052fd2e>] ? free_pages_prepare+0x1ce/0x320
> [    5.952886]  [<c05718ad>] ? kmem_cache_alloc_trace+0x17d/0x1e0
> [    5.952890]  [<c0570b87>] ? kfree+0xe7/0x130
> [    5.952897]  [<c0b5c764>] do_init_module+0x54/0x1cd
> [    5.952903]  [<c04c7895>] load_module+0x1145/0x17d0
> [    5.952910]  [<c04c4549>] ? copy_module_from_fd.isra.53+0x109/0x1a0
> [    5.952916]  [<c04c810d>] SyS_finit_module+0x8d/0xd0
> [    5.952922]  [<c0544ce3>] ? vm_mmap_pgoff+0x93/0xb0
> [    5.952929]  [<c0b6a20f>] sysenter_do_call+0x12/0x12
> [    5.952933] ---[ end trace 1e444d913002c55d ]---
> [    5.952936] gpiod_request: invalid GPIO
> [    5.952941] arizona spi-WM510205:00: Failed to request /RESET: -22
> [    5.982461] arizona: probe of spi-WM510205:00 failed with error -22
> [    5.982478] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> [    5.988213] i2c i2c-11: Failed to register i2c client MAGN0001:00
> at 0x1d (-16)
> 
> the code in arizona-core.c arizona_dev_init looks like
> 
> if (arizona->pdata.reset) {
>  /* Start out with /RESET low to put the chip into reset */
>  ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
> }
> 
> which fails here. seems that I have to use desc_to_gpio() here too.
> Does anybody have an idea whats wrong with LDO1? I try the
> desc_to_gpio at first and will report soon

I don't think passing the converted GPIO numbers in pdata is good idea.
Instead you can just get the GPIO descriptors in the driver itself using
devm_gpiod_get*().

For example you can try following:

        if (arizona->pdata.reset) {
                /* Start out with /RESET low to put the chip into reset * */
                ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
                                            GPIOF_DIR_OUT | GPIOF_INIT_LOW,
                                            "arizona /RESET");
                if (ret != 0) {
                        dev_err(dev, "Failed to request /RESET: %d\n", ret);
                        goto err_dcvdd;
                }
        } else {
		struct gpio_desc *desc;

		desc = devm_gpiod_get(arizona->dev, "reset",
				      GPIOF_DIR_OUT | GPIOF_INIT_LOW);
		if (!IS_ERR(desc))
			arizona.pdata.reset = desc_to_gpio(desc);
	}

Eventually it might be good idea to convert the driver to use GPIO
descriptors. The above can be intermediate step to that.
Christian Hartmann Aug. 21, 2015, 7:31 a.m. UTC | #7 
Hi,


2015-08-20 13:58 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> On Thu, Aug 20, 2015 at 01:34:00PM +0200, Christian Hartmann wrote:
>
> I don't think passing the converted GPIO numbers in pdata is good idea.
> Instead you can just get the GPIO descriptors in the driver itself using
> devm_gpiod_get*().
>
> For example you can try following:
>
>         if (arizona->pdata.reset) {
>                 /* Start out with /RESET low to put the chip into reset * */
>                 ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
>                                             GPIOF_DIR_OUT | GPIOF_INIT_LOW,
>                                             "arizona /RESET");
>                 if (ret != 0) {
>                         dev_err(dev, "Failed to request /RESET: %d\n", ret);
>                         goto err_dcvdd;
>                 }
>         } else {
>                 struct gpio_desc *desc;
>
>                 desc = devm_gpiod_get(arizona->dev, "reset",
>                                       GPIOF_DIR_OUT | GPIOF_INIT_LOW);
>                 if (!IS_ERR(desc))
>                         arizona.pdata.reset = desc_to_gpio(desc);
>         }
>
> Eventually it might be good idea to convert the driver to use GPIO
> descriptors. The above can be intermediate step to that.

I have just changed the code as you suggested, and I got no bug,
excepting that the
WM5102 codec does not initialize at all yet.


[    6.169473] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    6.169501] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    6.169507] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    6.169511] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    6.169515] arizona spi-WM510205:00: regmap set to wm5102_spi
[    6.170301] arizona spi-WM510205:00: spi_irq = -1
[    6.170309] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    6.170313] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    6.170317] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    6.170323] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.170328] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.170333] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.170340] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.175675] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.175733] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
[    6.175739] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.175744] acpi WM510205:00: GPIO: looking up ldoena-gpios
[    6.175750] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
[    6.175805] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.175860] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    6.175867] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using ldoena GPIO =  405
[    6.175871] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using reset GPIO =  342
[    6.175875] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    6.175880] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    6.175885] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    6.176079] gpio-405 (ldoena): gpiod_request: status -16
[    6.176084] LDO1: Failed to request enable GPIO405: -16
[    6.176154] arizona spi-WM510205:00: Failed to register LDO1 supply: -16
[    6.189631] arizona-ldo1: probe of arizona-ldo1 failed with error -16
[    6.189656] arizona spi-WM510205:00: mfd_add_devices done for 1
[    6.189665] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    6.189721] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.189753] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    6.189757] spi-WM510205:00 supply DCVDD not found, using dummy regulator
[    6.189786] arizona spi-WM510205:00: regulator_get done for 1
[    6.189794] gpio-342 (reset): gpiod_request: status -16
[    6.189799] arizona spi-WM510205:00: Failed to request /RESET: -16
[    6.189805] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.189809] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.189815] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.189821] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.189883] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.189957] gpio-342 (reset): gpiod_request: status -16
[    6.189963] arizona spi-WM510205:00: Failed to request /RESET: -16
[    6.190221] arizona: probe of spi-WM510205:00 failed with error -16
[    6.190230] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00

as we can see in  the current dmesg the driver is still unable to get
the reset line, I tried at first the old way,
than via devm_gpiod_get(), if this fails to, than it goes to err_dcvdd....

I do need help here, do not know how to fix this at the moment.

cheers
chris
Mika Westerberg Aug. 21, 2015, 7:43 a.m. UTC | #8 
On Fri, Aug 21, 2015 at 09:31:25AM +0200, Christian Hartmann wrote:
> [    6.169473] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.169501] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.169507] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.169511] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.169515] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.170301] arizona spi-WM510205:00: spi_irq = -1
> [    6.170309] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> arizona_acpi_gpios added done, 0
> [    6.170313] arizona spi-WM510205:00: arizona_spi_probe done,
> calling arizona_dev_init
> [    6.170317] arizona spi-WM510205:00: dev_set_drvdata done for 1
> [    6.170323] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    6.170328] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.170333] acpi WM510205:00: GPIO: looking up reset-gpios
> [    6.170340] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    6.175675] acpi WM510205:00: GPIO: looking up 0 in _CRS

1) You got "reset-gpios" here.

> [    6.175733] arizona spi-WM510205:00: GPIO lookup for consumer ldoena
> [    6.175739] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.175744] acpi WM510205:00: GPIO: looking up ldoena-gpios
> [    6.175750] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 2 0 0
> [    6.175805] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.175860] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    6.175867] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using ldoena GPIO =  405
> [    6.175871] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using reset GPIO =  342
> [    6.175875] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    6.175880] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    6.175885] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    6.176079] gpio-405 (ldoena): gpiod_request: status -16
> [    6.176084] LDO1: Failed to request enable GPIO405: -16
> [    6.176154] arizona spi-WM510205:00: Failed to register LDO1 supply: -16
> [    6.189631] arizona-ldo1: probe of arizona-ldo1 failed with error -16
> [    6.189656] arizona spi-WM510205:00: mfd_add_devices done for 1
> [    6.189665] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    6.189721] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    6.189753] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
> [    6.189757] spi-WM510205:00 supply DCVDD not found, using dummy regulator
> [    6.189786] arizona spi-WM510205:00: regulator_get done for 1
> [    6.189794] gpio-342 (reset): gpiod_request: status -16
> [    6.189799] arizona spi-WM510205:00: Failed to request /RESET: -16

2) and fail here with -EBUSY because you have already requested the GPIO.

So please drop the code in 1) to be able to request the GPIO in the
driver.
Christian Hartmann Aug. 21, 2015, 12:09 p.m. UTC | #9 
Hi

2015-08-21 9:43 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> So please drop the code in 1) to be able to request the GPIO in the
> driver.

[    6.129664] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    6.129675] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    6.129759] spi spi-WM510205:00: checking WM510205 with bmp180
[    6.129765] spi spi-WM510205:00: checking WM510205 with bmp181
[    6.129797] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    6.129825] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    6.129831] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    6.129836] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    6.129840] arizona spi-WM510205:00: regmap set to wm5102_spi
[    6.130630] arizona spi-WM510205:00: spi_irq = -1
[    6.130638] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    6.130642] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    6.130647] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    6.130653] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.130703] arizona spi-WM510205:00: arizona_of_get_core_pdata
(ACPI) using irq_gpio GPIO = 146
[    6.130708] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    6.130713] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    6.130717] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    6.131255] arizona spi-WM510205:00: mfd_add_devices done for 1
[    6.131267] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    6.131301] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    6.131332] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    6.131338] LDO1: supplied by regulator-dummy
[    6.131389] arizona spi-WM510205:00: regulator_get done for 1
[    6.131397] arizona spi-WM510205:00: GPIO lookup for consumer reset
[    6.131401] arizona spi-WM510205:00: using ACPI for GPIO lookup
[    6.131407] acpi WM510205:00: GPIO: looking up reset-gpios
[    6.131414] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
[    6.131498] acpi WM510205:00: GPIO: looking up 0 in _CRS
[    6.131543] no flags found for reset
[    6.131549] arizona spi-WM510205:00: devm_gpiod_get done to request
/RESET: -1
[    6.131556] arizona spi-WM510205:00: regulator_bulk_enable done,
enable core supplies: 0
[    6.131561] arizona spi-WM510205:00: regulator_enable done, enable DCVDD: 0
[    6.141803] arizona spi-WM510205:00: arizona_disabe_reset
[    6.141813] arizona spi-WM510205:00: regcache_cache_only
[    6.144796] arizona spi-WM510205:00: regmap_read : read ID
register, return value: 0
[    6.144806] arizona spi-WM510205:00: found device ID: ffff
[    6.175352] arizona spi-WM510205:00: Unknown device ID ffff
[    6.175584] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
[    6.177870] sst-acpi 80860F28:00: No matching ASoC machine driver found

as you said, I removed the code in 1) so the EBUSY error is gone.

What is with the spi_irq = -1 ?? is this a problem here?

the message "no flags found for reset" seems also ok, but it does not
read the device id yet,
 what else can be wrong here?

In previous mails I added the _CRS for this device WM510202, is the
gpio-mapping, with its indexes ok so far??

The last two messages are clear to me.
I will add the machine driver if the device id was read correctly etc.

cheers
chris
Christian Hartmann Aug. 21, 2015, 12:33 p.m. UTC | #10 
Hi and upps,


2015-08-21 14:09 GMT+02:00 Christian Hartmann <cornogle@googlemail.com>:
> Hi
>
> 2015-08-21 9:43 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
>> So please drop the code in 1) to be able to request the GPIO in the
>> driver.
>
> [    6.129664] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    6.129675] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    6.129759] spi spi-WM510205:00: checking WM510205 with bmp180
> [    6.129765] spi spi-WM510205:00: checking WM510205 with bmp181
> [    6.129797] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.129825] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.129831] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.129836] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.129840] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.130630] arizona spi-WM510205:00: spi_irq = -1
> [    6.130638] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> arizona_acpi_gpios added done, 0
> [    6.130642] arizona spi-WM510205:00: arizona_spi_probe done,
> calling arizona_dev_init
> [    6.130647] arizona spi-WM510205:00: dev_set_drvdata done for 1
> [    6.130653] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.130703] arizona spi-WM510205:00: arizona_of_get_core_pdata
> (ACPI) using irq_gpio GPIO = 146
> [    6.130708] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
> [    6.130713] arizona spi-WM510205:00: regcache_cache_only for 1 set
> [    6.130717] arizona spi-WM510205:00: added wm5102_core_supplies for 1
> [    6.131255] arizona spi-WM510205:00: mfd_add_devices done for 1
> [    6.131267] spi-WM510205:00 supply AVDD not found, using dummy regulator
> [    6.131301] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
> [    6.131332] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
> [    6.131338] LDO1: supplied by regulator-dummy
> [    6.131389] arizona spi-WM510205:00: regulator_get done for 1
> [    6.131397] arizona spi-WM510205:00: GPIO lookup for consumer reset
> [    6.131401] arizona spi-WM510205:00: using ACPI for GPIO lookup
> [    6.131407] acpi WM510205:00: GPIO: looking up reset-gpios
> [    6.131414] acpi WM510205:00: GPIO: _DSD returned WM510205:00 3 1 0 0
> [    6.131498] acpi WM510205:00: GPIO: looking up 0 in _CRS
> [    6.131543] no flags found for reset
> [    6.131549] arizona spi-WM510205:00: devm_gpiod_get done to request
> /RESET: -1
> [    6.131556] arizona spi-WM510205:00: regulator_bulk_enable done,
> enable core supplies: 0
> [    6.131561] arizona spi-WM510205:00: regulator_enable done, enable DCVDD: 0
> [    6.141803] arizona spi-WM510205:00: arizona_disabe_reset
> [    6.141813] arizona spi-WM510205:00: regcache_cache_only
> [    6.144796] arizona spi-WM510205:00: regmap_read : read ID
> register, return value: 0
> [    6.144806] arizona spi-WM510205:00: found device ID: ffff
> [    6.175352] arizona spi-WM510205:00: Unknown device ID ffff
> [    6.175584] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> [    6.177870] sst-acpi 80860F28:00: No matching ASoC machine driver found
>
> as you said, I removed the code in 1) so the EBUSY error is gone.
>
> What is with the spi_irq = -1 ?? is this a problem here?
>
> the message "no flags found for reset" seems also ok, but it does not
> read the device id yet,
>  what else can be wrong here?
>
> In previous mails I added the _CRS for this device WM510202, is the
> gpio-mapping, with its indexes ok so far??
>
> The last two messages are clear to me.
> I will add the machine driver if the device id was read correctly etc.
>
> cheers
> chris

I have overseen the code, where the function
arizona_ldo1_of_get_pdata() is called only if  CONFIG_OF is
enabled....
will fix this first...

sorry for the extra noise


cheers
chris
Charles Keepax Aug. 24, 2015, 8:51 a.m. UTC | #11 
On Fri, Aug 21, 2015 at 02:09:46PM +0200, Christian Hartmann wrote:
> Hi
> 
> 2015-08-21 9:43 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> > So please drop the code in 1) to be able to request the GPIO in the
> > driver.
> 
> [    6.129664] spi spi-WM510205:00: 8333333 Hz actual, PIO
> [    6.129675] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
> [    6.129759] spi spi-WM510205:00: checking WM510205 with bmp180
> [    6.129765] spi spi-WM510205:00: checking WM510205 with bmp181
> [    6.129797] spi spi-WM510205:00: modalias WM510205 in id_table not
> found, returns NULL
> [    6.129825] arizona spi-WM510205:00: arizona_acpi_get_type(), than
> via spi_get_device_id().
> [    6.129831] arizona spi-WM510205:00: arizona_acpi_get_type matched
> [    6.129836] arizona spi-WM510205:00: using 1 as type for arizona audio codec
> [    6.129840] arizona spi-WM510205:00: regmap set to wm5102_spi
> [    6.130630] arizona spi-WM510205:00: spi_irq = -1
> [    6.130638] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
> [    6.144806] arizona spi-WM510205:00: found device ID: ffff
> [    6.175352] arizona spi-WM510205:00: Unknown device ID ffff
> [    6.175584] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
> [    6.177870] sst-acpi 80860F28:00: No matching ASoC machine driver found
> 
> as you said, I removed the code in 1) so the EBUSY error is gone.
> 
> What is with the spi_irq = -1 ?? is this a problem here?

The IRQ needs pulled from the ACPI as well, having no IRQ
specified will not interfer with basic functionality of the
driver but will become a problem eventually.

Thanks,
Charles
Christian Hartmann Aug. 24, 2015, 1:25 p.m. UTC | #12 
Hi,

2015-08-24 10:51 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
>> What is with the spi_irq = -1 ?? is this a problem here?
>
> The IRQ needs pulled from the ACPI as well, having no IRQ
> specified will not interfer with basic functionality of the
> driver but will become a problem eventually.
>
> Thanks,
> Charles

ok, I will have an eye on it these days for the IRQ.
For me its looking that the pxa2xx does not have an irq yet,
nor an dma channel (thats should be fine, as I understand it correctly)

actually I cleanup and want to rework / begin with a new v2 patch
series, but first it should drive this chip  before beginning with a
v2 patch.

one more question: the function devm_gpio_request_one() which is used
here to request "arizona /RESET"

<code in arizona-core.c>

/* Start out with /RESET low to put the chip into reset */
ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
GPIOF_DIR_OUT | GPIOF_INIT_LOW,
"arizona /RESET");
</code>

the string arizona /RESET, where is this documented, where can I find
it? It fails here, and my question is, is this string correct at all
for my case? Should it be called only "reset" in my case??

All I have found is:
Documentation/devicetree/bindings/mfd/arizona.txt:  - wlf,reset : GPIO
specifier for the GPIO controlling /RESET

in devres.c its documented as a label only:
@label: a literal description string of this GPIO

I am curios about the answers, anyway I will change it, it looks
faulty (but do not know why exactly at all :) )

cheers
chris
Mark Brown Aug. 25, 2015, 6:21 a.m. UTC | #13 
On Mon, Aug 24, 2015 at 03:25:57PM +0200, Christian Hartmann wrote:

> /* Start out with /RESET low to put the chip into reset */
> ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
> GPIOF_DIR_OUT | GPIOF_INIT_LOW,
> "arizona /RESET");
> </code>

> the string arizona /RESET, where is this documented, where can I find
> it? It fails here, and my question is, is this string correct at all
> for my case? Should it be called only "reset" in my case??

That string is documentation - it's used purely for display purposes,
which is what this...

> in devres.c its documented as a label only:
> @label: a literal description string of this GPIO

...says.  In cases like this looking at the code is often helpful (you
can see exactly how the string gets used...) but obviously patches to
improve the doumentation are welcome.
Christian Hartmann Aug. 26, 2015, 8:47 a.m. UTC | #14 
Hi,


2015-08-25 8:21 GMT+02:00 Mark Brown <broonie@kernel.org>:
> On Mon, Aug 24, 2015 at 03:25:57PM +0200, Christian Hartmann wrote:
>
>> /* Start out with /RESET low to put the chip into reset */
>> ret = devm_gpio_request_one(arizona->dev, arizona->pdata.reset,
>> GPIOF_DIR_OUT | GPIOF_INIT_LOW,
>> "arizona /RESET");
>> </code>
>
>> the string arizona /RESET, where is this documented, where can I find
>> it? It fails here, and my question is, is this string correct at all
>> for my case? Should it be called only "reset" in my case??
>
> That string is documentation - it's used purely for display purposes,
> which is what this...
>
>> in devres.c its documented as a label only:
>> @label: a literal description string of this GPIO
>
> ...says.  In cases like this looking at the code is often helpful (you
> can see exactly how the string gets used...) but obviously patches to
> improve the doumentation are welcome.

ok so far all fine with that label, this is no problem here anyway

chris
Christian Hartmann Aug. 26, 2015, 8:58 a.m. UTC | #15 
Hi at all,


the current logs shows me, that something else is missing here.
The spi irq is one of the issues I will try to solve today

Looking at the read_regmap() where it reads its device id,
I do not understand why it gots only an ID of 0xffff !

I have (silly or not), added a case for 0xffff in the next switch
statements but anyway this seems not okay.
I do not know what else (other than the wrong or missing spi irq,
which is currently only -1)

[    2.427561] ALSA device list:
[    5.503750] sst-acpi 80860F28:00: No matching ASoC machine driver found
[    5.544365] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO
[    5.544449] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic)
[    5.544646] spi spi-WM510205:00: 8333333 Hz actual, PIO
[    5.544653] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0
[    5.544717] spi spi-WM510205:00: checking WM510205 with bmp180
[    5.544723] spi spi-WM510205:00: checking WM510205 with bmp181
[    5.544728] spi spi-WM510205:00: modalias WM510205 in id_table not
found, returns NULL
[    5.544752] arizona spi-WM510205:00: arizona_acpi_get_type(), than
via spi_get_device_id().
[    5.544758] arizona spi-WM510205:00: arizona_acpi_get_type matched
[    5.544763] arizona spi-WM510205:00: using 1 as type for arizona audio codec
[    5.544767] arizona spi-WM510205:00: regmap set to wm5102_spi
[    5.545559] arizona spi-WM510205:00: spi_irq = -1
[    5.545565] arizona spi-WM510205:00: acpi_dev_add_driver_gpios
arizona_acpi_gpios added done, 0
[    5.545570] arizona spi-WM510205:00: arizona_spi_probe done,
calling arizona_dev_init
[    5.545574] arizona spi-WM510205:00: dev_set_drvdata done for 1
[    5.545578] arizona spi-WM510205:00: arizona_of_get_core_pdata for 1
[    5.545583] arizona spi-WM510205:00: regcache_cache_only for 1 set
[    5.545587] arizona spi-WM510205:00: added wm5102_core_supplies for 1
[    5.545841] arizona spi-WM510205:00: mfd_add_devices done for 1
[    5.545849] spi-WM510205:00 supply AVDD not found, using dummy regulator
[    5.545888] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator
[    5.545919] arizona spi-WM510205:00: devm_regulator_bulk_get done for 1
[    5.545924] LDO1: supplied by regulator-dummy
[    5.545973] arizona spi-WM510205:00: regulator_get done for 1
[    5.546036] arizona spi-WM510205:00: (ACPI) using irq_gpio GPIO = 146
[    5.546050] arizona spi-WM510205:00: devm_gpio_request_one done for
request reset: 0
[    5.546057] arizona spi-WM510205:00: regulator_bulk_enable done,
enable core supplies: 0
[    5.551362] arizona spi-WM510205:00: regulator_enable done, enable DCVDD: 0
[    5.562754] arizona spi-WM510205:00: arizona_disabe_reset
[    5.562766] arizona spi-WM510205:00: regcache_cache_only
[    5.565842] arizona spi-WM510205:00: regmap_read : read ID
register, return value: 0
[    5.565852] arizona spi-WM510205:00: found device ID: ffff
[    5.609712] arizona spi-WM510205:00: WM5102 revision H
[    5.637683] arizona spi-WM510205:00: Polling reg 23 timed out: ffff
[    5.637953] arizona spi-WM510205:00: arizona_dev_init : Failed to
apply hardware patch: -110
[    5.670927] arizona: probe of spi-WM510205:00 failed with error -110
[    5.670945] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
[    5.728336] intel_sst_acpi 80860F28:00: No matching machine driver found

any ideas or what I can do next to find out was is the root issue here?
Question about the spi-irq to clarify it for me: does this spi irq
device belongs to the arizona child (the wm5102) or is this irq only
of the spi master ? I much as I understand, this irq is from the spi
master, the arizona spi child , the wm510205, has another irq ,
attachted at the irq_gpio - I am right so far??

in some previous mails it was mentioned, that I should or _must_ use
and irqchip handler?

still encouraged to get this device working as expected :)

cheers
chris
Charles Keepax Aug. 26, 2015, 9:13 a.m. UTC | #16 
On Wed, Aug 26, 2015 at 10:58:06AM +0200, Christian Hartmann wrote:
> Hi at all,
> 
> 
> the current logs shows me, that something else is missing here.
> The spi irq is one of the issues I will try to solve today
> 
> Looking at the read_regmap() where it reads its device id,
> I do not understand why it gots only an ID of 0xffff !

I would probably focus on getting the device ID to read back
first. The interrupts aren't that important until you can talk to
the device and the interrupt setup won't have any effect on being
able to talk to the device.

> 
> I have (silly or not), added a case for 0xffff in the next switch
> statements but anyway this seems not okay.
> I do not know what else (other than the wrong or missing spi irq,
> which is currently only -1)

Yeah adding a case for 0xffff probably won't help much as this
likely means that the device isn't responding at all when you are
talking to it, so you can't really do anything meaningful when
you get past reading the ID register anyway.

Basically to be able to talk to the device you need the following
things:

 1) The supplies need to be applied.
 2) The device needs to be out of reset.
 3) The device needs to have the LDO enabled.
 4) The chip select needs to be active.

It seems very likely that 1) is already taken care of, so I
probalby won't spend too much time worrying about that. It looks
like we are getting a valid GPIO for the reset (2) and LDOENA (3),
so it feels like those are probably ok. I guess this leaves the
SPI config as the next place to investigate, are there other
devices on the SPI that you can talk to that might at least
verify the SPI is working? Also might be worth trying to look at
how the chip selects are done perhaps that is not happening for
some reason?

Thanks,
Charles
Mika Westerberg Aug. 26, 2015, 10:01 a.m. UTC | #17 
On Wed, Aug 26, 2015 at 10:58:06AM +0200, Christian Hartmann wrote:
> Question about the spi-irq to clarify it for me: does this spi irq
> device belongs to the arizona child (the wm5102) or is this irq only
> of the spi master ? I much as I understand, this irq is from the spi
> master, the arizona spi child , the wm510205, has another irq ,
> attachted at the irq_gpio - I am right so far??

The master should already have IRQ. This is about assigning IRQ for the
SPI childe device.

You probably want to do same to SPI core that was done for I2C:

845c877009cf014b9 ("i2c / ACPI: Assign IRQ for devices that have GpioInt automatically")

Then it will automatically assign first found GpioInt to the SPI device
in question.
Christian Hartmann Aug. 27, 2015, 11:44 a.m. UTC | #18 
Hey,

2015-08-26 12:01 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> The master should already have IRQ. This is about assigning IRQ for the
> SPI childe device.
ok, *saved*
>
> You probably want to do same to SPI core that was done for I2C:
>
> 845c877009cf014b9 ("i2c / ACPI: Assign IRQ for devices that have GpioInt automatically")
I looked at this log and have added or better set spi->irq now in
arizon-spi.c arizona_spi_probe()
and its that what I have already via local patches added:
(ACPI) using irq_gpio GPIO = 146
The question for me is, this looks like an GPIO number, not like an IRQ number.
Also it seems better to look again into pxa2xx.c or spi.c (not done
yet) and get the irq there.

>
> Then it will automatically assign first found GpioInt to the SPI device
> in question.

I again saw also the following files, which are not used under this
device or they need some attention

drivers/gpio/gpio-arizona.c
and drivers/extcon/extcon-arizona.c

I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
Is it save to ignore ?? Or should I use them as well ??

cheers
chris
Mika Westerberg Aug. 27, 2015, 11:59 a.m. UTC | #19 
On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> Hey,
> 
> 2015-08-26 12:01 GMT+02:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> > The master should already have IRQ. This is about assigning IRQ for the
> > SPI childe device.
> ok, *saved*
> >
> > You probably want to do same to SPI core that was done for I2C:
> >
> > 845c877009cf014b9 ("i2c / ACPI: Assign IRQ for devices that have GpioInt automatically")
> I looked at this log and have added or better set spi->irq now in
> arizon-spi.c arizona_spi_probe()
> and its that what I have already via local patches added:
> (ACPI) using irq_gpio GPIO = 146
> The question for me is, this looks like an GPIO number, not like an IRQ number.
> Also it seems better to look again into pxa2xx.c or spi.c (not done
> yet) and get the irq there.

If you are calling acpi_dev_gpio_irq_get() for the SPI device it should
return you valid Linux IRQ number (or fail with an error). But it
requires that your device has GpioInt resource somewhere in _CRS.

> >
> > Then it will automatically assign first found GpioInt to the SPI device
> > in question.
> 
> I again saw also the following files, which are not used under this
> device or they need some attention
> 
> drivers/gpio/gpio-arizona.c
> and drivers/extcon/extcon-arizona.c
> 
> I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> Is it save to ignore ?? Or should I use them as well ??

If the SPI device interrupt is connected to arizona GPIO pin, then you
probably need that.
Mark Brown Aug. 27, 2015, 2:56 p.m. UTC | #20 
On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:

> > drivers/gpio/gpio-arizona.c
> > and drivers/extcon/extcon-arizona.c

> > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > Is it save to ignore ?? Or should I use them as well ??

> If the SPI device interrupt is connected to arizona GPIO pin, then you
> probably need that.

I can't see how that would work, the interrupt output isn't a GPIO.
Christian Hartmann Aug. 28, 2015, 7:22 a.m. UTC | #21 
Hi Mika,
hi,


2015-08-26 11:13 GMT+02:00 Charles Keepax <ckeepax@opensource.wolfsonmicro.com>:
>  4) The chip select needs to be active.
>
> It seems very likely that 1) is already taken care of, so I
> probalby won't spend too much time worrying about that. It looks
> like we are getting a valid GPIO for the reset (2) and LDOENA (3),
> so it feels like those are probably ok. I guess this leaves the
> SPI config as the next place to investigate, are there other
> devices on the SPI that you can talk to that might at least
> verify the SPI is working? Also might be worth trying to look at
> how the chip selects are done perhaps that is not happening for
> some reason?

ok, that seems logical .
And no I cannot prove or check other devices, I just learned a lot in
the past three month about
this (driver, spi, gpio, acpi, dsdt etc. ) at all.

cheers
chris
Mika Westerberg Aug. 28, 2015, 9 a.m. UTC | #22 
On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> > On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> 
> > > drivers/gpio/gpio-arizona.c
> > > and drivers/extcon/extcon-arizona.c
> 
> > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > Is it save to ignore ?? Or should I use them as well ??
> 
> > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > probably need that.
> 
> I can't see how that would work, the interrupt output isn't a GPIO.

I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
pin of arizona instead of GPIO pin of the SoC itself.
Richard Fitzgerald Aug. 28, 2015, 9:07 a.m. UTC | #23 
On Fri, 2015-08-28 at 12:00 +0300, Mika Westerberg wrote:
> On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> > > On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> > 
> > > > drivers/gpio/gpio-arizona.c
> > > > and drivers/extcon/extcon-arizona.c
> > 
> > > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > > Is it save to ignore ?? Or should I use them as well ??
> > 
> > > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > > probably need that.
> > 
> > I can't see how that would work, the interrupt output isn't a GPIO.
> 
> I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
> pin of arizona instead of GPIO pin of the SoC itself.

It makes no sense to connect the codec interrupt pin back to one of its
own GPIOs. If you did that the GPIO could only generate another
interrupt to itself and you'd have a circular interrupt storm that went
nowhere.

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Mika Westerberg Aug. 28, 2015, 9:12 a.m. UTC | #24 
On Fri, Aug 28, 2015 at 10:07:35AM +0100, Richard Fitzgerald wrote:
> On Fri, 2015-08-28 at 12:00 +0300, Mika Westerberg wrote:
> > On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> > > On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:
> > > > On Thu, Aug 27, 2015 at 01:44:45PM +0200, Christian Hartmann wrote:
> > > 
> > > > > drivers/gpio/gpio-arizona.c
> > > > > and drivers/extcon/extcon-arizona.c
> > > 
> > > > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > > > Is it save to ignore ?? Or should I use them as well ??
> > > 
> > > > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > > > probably need that.
> > > 
> > > I can't see how that would work, the interrupt output isn't a GPIO.
> > 
> > I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
> > pin of arizona instead of GPIO pin of the SoC itself.
> 
> It makes no sense to connect the codec interrupt pin back to one of its
> own GPIOs. If you did that the GPIO could only generate another
> interrupt to itself and you'd have a circular interrupt storm that went
> nowhere.

Ah, arizona is the chip providing the codec functionality as well? I
thought they were separate chips.

In that case, I take my previus comment back. Sorry about the confusion.
Mark Brown Aug. 28, 2015, 9:16 a.m. UTC | #25 
On Fri, Aug 28, 2015 at 12:00:42PM +0300, Mika Westerberg wrote:
> On Thu, Aug 27, 2015 at 03:56:14PM +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2015 at 02:59:14PM +0300, Mika Westerberg wrote:

> > > > I have already CONFIG_GPIO_ARIZONA=y, but it does not be used at all.
> > > > Is it save to ignore ?? Or should I use them as well ??

> > > If the SPI device interrupt is connected to arizona GPIO pin, then you
> > > probably need that.

> > I can't see how that would work, the interrupt output isn't a GPIO.

> I mean that if the SPI device (codec) interrupt pin is connected to a GPIO
> pin of arizona instead of GPIO pin of the SoC itself.

I understand what you mean, I'm just saying that the GPIO driver for the
chip seems unlikely to be useful.
diff mbox

Patch

diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
index 1e845f6..52872a0 100644
--- a/drivers/mfd/arizona-spi.c
+++ b/drivers/mfd/arizona-spi.c
@@ -18,28 +18,58 @@ 
 #include <linux/slab.h>
 #include <linux/spi/spi.h>
 #include <linux/of.h>
+#include <linux/acpi.h>

 #include <linux/mfd/arizona/core.h>

 #include "arizona.h"

+const struct acpi_gpio_params reset_gpio = { 1, 0, false};
+const struct acpi_gpio_params ldoena_gpio = { 2, 0, false};
+
+const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
+       { "reset_gpio", &reset_gpio, 1,},
+       { "ldoena_gpio", &ldoena_gpio, 1},
+       { },
+};
 static int arizona_spi_probe(struct spi_device *spi)
 {
-       const struct spi_device_id *id = spi_get_device_id(spi);
+       const struct spi_device_id *id;
        struct arizona *arizona;
+       struct acpi_device *adev;
        const struct regmap_config *regmap_config;
        unsigned long type;
+       acpi_handle handle;
        int ret;

        if (spi->dev.of_node)
                type = arizona_of_get_type(&spi->dev);
-       else
-               type = id->driver_data;
+       else {
+               dev_err(&spi->dev, "arizona_acpi_get_type(), than via
spi_get_device_id().\n");
+               if (( type = arizona_acpi_get_type(&spi->dev))) {
+               } else {
+                       id = spi_get_device_id(spi) ;
+                       if (!id || !id->driver_data)
+                               return -ENODEV;
+                       dev_err(&spi->dev, "matched spi\n");
+                       type = id->driver_data;
+               }
+       }
+
+
+       /* check if type is NULL before going on
+        */
+       if (!type) {
+               dev_err(&spi->dev, "type is NULL, unable to get the id
/ type of this device\n");
+               return -ENODEV;
+       } else
+               dev_err(&spi->dev, "using %lu as type for arizona
audio codec\n",type);

        switch (type) {
 #ifdef CONFIG_MFD_WM5102
        case WM5102:
                regmap_config = &wm5102_spi_regmap;
+               dev_err(&spi->dev, "regmap set to wm5102_spi \n");
                break;
 #endif
 #ifdef CONFIG_MFD_WM5110
@@ -66,10 +96,32 @@  static int arizona_spi_probe(struct spi_device *spi)
                return ret;
        }

-       arizona->type = id->driver_data;
+       /*
+        * take the id if it is an spi id,  or take the acpi id
+        * the case that it has no id and no acpi_id is yet open (yes the
+        * openfirmare interface introducted by apple)
+        */
+       arizona->type = type;
+
        arizona->dev = &spi->dev;
        arizona->irq = spi->irq;

+       dev_err(&spi->dev, "spi_irq = %i \n",spi->irq);
+       dev_err(&spi->dev, "arizona_spi_probe done, calling
arizona_dev_init \n");
+
+#ifdef CONFIG_ACPI
+       /*
+        *arizona->dev.fwnode = acpi_fwnode_handle(adev);
+        */
+       handle = ACPI_HANDLE(&spi->dev);
+       if (!handle || acpi_bus_get_device(handle, &adev)) {
+               dev_err(&spi->dev, "unable to get ACPI handle\n");
+               return -ENODEV;
+       }
+       ret = acpi_dev_add_driver_gpios(adev, arizona_acpi_gpios);
+       dev_err(&spi->dev, "acpi_dev_add_driver_gpios done, %i\n",ret);
+
+#endif
        return arizona_dev_init(arizona);
 }

@@ -90,12 +142,22 @@  static const struct spi_device_id arizona_spi_ids[] = {
 };
 MODULE_DEVICE_TABLE(spi, arizona_spi_ids);

+static const struct acpi_device_id arizona_acpi_match[] = {
+       {
+               .id = "WM510205",
+               .driver_data = WM5102,
+       },
+       { },
+};
+MODULE_DEVICE_TABLE(acpi, arizona_acpi_match);
+
static struct spi_driver arizona_spi_driver = {
        .driver = {
                .name   = "arizona",
                .owner  = THIS_MODULE,
                .pm     = &arizona_pm_ops,
                .of_match_table = of_match_ptr(arizona_of_match),
+               .acpi_match_table = ACPI_PTR(arizona_acpi_match),
        },
        .probe          = arizona_spi_probe,
        .remove         = arizona_spi_remove,
diff --git a/drivers/mfd/arizona.h b/drivers/mfd/arizona.h
index fbe2843..ba9e9bc 100644
--- a/drivers/mfd/arizona.h
+++ b/drivers/mfd/arizona.h
@@ -55,4 +55,14 @@  static inline unsigned long
arizona_of_get_type(struct device *dev)
 }
 #endif

+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+unsigned long arizona_acpi_get_type(struct device *dev);
+
+extern const struct acpi_gpio_params reset_gpio;
+extern const struct acpi_gpio_params ldoena_gpio;
+
+extern const struct acpi_gpio_mapping arizona_acpi_gpios[];
+#endif
+