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