[alsa-devel] Fwd: [PATCH 1/1] SPI : spi-pxa2xx : fix spi init of WM510205 codec via ACPI (resend)
Hi Mika, Dan et al.
@Dan : thank you, I will use get_maintainer.pl as of now.
@Mika: you mean I should prepare a new DSDT table and in this case overwrite the SPI value there with the 0 and load it (the DSDT table ) into a custom kernel build ?? I will do this (cause all what I want is to enable the codec and to hear sound)
currently I have in the extracted DSDT table from this device the SPI1 controller for the "AUDI" device as seen in this snippet :
Scope (_SB) { Device (LPEA) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "80860F28" /* Intel SST Audio DSP */) // _HID: Hardware ID Name (_CID, "80860F28" /* Intel SST Audio DSP */) // _CID: Compatible ID Name (_DDN, "Intel(R) Low Power Audio Controller - 80860F28") // _DDN: DOS Device Name Name (_SUB, "17AA7004") // _SUB: Subsystem ID Name (_UID, One) // _UID: Unique ID Name (_DEP, Package (0x01) // _DEP: Dependencies { ^SPI1.AUDI }) Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 { PLPE })
.... some lines later follows the AUDI device with Device (AUDI) { Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102") // _DDN: DOS Device Name Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (SBUF, ResourceTemplate () { SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\_SB.SPI1", 0x00, ResourceConsumer, , ) 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 } }) Return (SBUF) /* _SB_.SPI1.AUDI._CRS.SBUF */ } ....
I t makes sense to me, to change the current value(s) in the DSDT and I have read about it to use a custom DSDT table but I am not 100% sure yet (until I have tested it).
If I understand you correct, than all I have to do is to change the 'SPI1' string in this dsdt to SPI0 like ^SPI1.AUDI to ^SPI0.AUDI and this block here SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\_SB.SPI1", 0x00, ResourceConsumer, ,
becomes SpiSerialBus (0x0000, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\_SB.SPI0", 0x00, ResourceConsumer, ,
For this case, could you please have a look in the whole DSDT table that I extract from this device? If nothing else seems relevant and the current system dsdt has to be changed as suggested, I will try this out as soon as possible
@Jarkko : as you suggested , I attach the current system DSDT as a binary. I have also disassembled, and if someone needs it, I can also paste it somewhere else as a reference
After all I will assembly the new dsdt and include it in my custom kernel builld as documented, but will wait for some new infos etc.
thank you for you answers @all
cheers chris
2015-06-25 9:36 GMT+02:00 Mika Westerberg mika.westerberg@linux.intel.com:
On Thu, Jun 25, 2015 at 09:29:31AM +0200, Christian Hartmann wrote:
Hello Maintainer(s)s of SPI,
hope I got all of you maintainers now. This email was already sent out last week to the alsa-devel list and I resent it here to you.
I have one patch that enables the spi initialization of the WM510205 audio codec Without the patch, this message indicates that the codec chip fails with the current chipselect number in spi-pxa2xx:
[ 0.296256] pxa2xx-spi 80860F0E:00: cs1 >= max 1 [ 0.296270] spi_master spi32766: failed to add SPI device WM510205:00 from ACPI
So raise num_chipselect by one to enable the codec. The WM510202 is on chipselect = 1.
The hardware only has one chipselect.
You can fix this by specifying the correct chipselect in the ACPI SpiSerialBus connector:
SpiSerialBus (0, PolarityLow, FourWireMode, 8, ControllerInitiated, ..First parameter is the chipselect.
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Hi Mika, Dan et al.
@Dan : thank you, I will use get_maintainer.pl as of now.
@Mika: you mean I should prepare a new DSDT table and in this case overwrite the SPI value there with the 0 and load it (the DSDT table ) into a custom kernel build ?? I will do this (cause all what I want is to enable the codec and to hear sound)
I thought that you are developing a new system where you can affect the firmware/BIOS source.
Obviously this is not the case so you have close to zero possibility to get the vendor to fix the broken firmware :-/
currently I have in the extracted DSDT table from this device the SPI1 controller for the "AUDI" device as seen in this snippet :
Scope (_SB) { Device (LPEA) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "80860F28" /* Intel SST Audio DSP */) //_HID: Hardware ID Name (_CID, "80860F28" /* Intel SST Audio DSP */) // _CID: Compatible ID Name (_DDN, "Intel(R) Low Power Audio Controller - 80860F28") // _DDN: DOS Device Name Name (_SUB, "17AA7004") // _SUB: Subsystem ID Name (_UID, One) // _UID: Unique ID Name (_DEP, Package (0x01) // _DEP: Dependencies { ^SPI1.AUDI }) Name (_PR0, Package (0x01) // _PR0: Power Resources for D0 { PLPE })
.... some lines later follows the AUDI device with Device (AUDI) { Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102") // _DDN: DOS Device Name Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (SBUF, ResourceTemplate () { SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\_SB.SPI1", 0x00, ResourceConsumer, , )
This is wrong as, like I said the Intel Baytrail SPI host controller only supports one native chipselect.
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 } }) Return (SBUF) /* _SB_.SPI1.AUDI._CRS.SBUF */ } ....
I t makes sense to me, to change the current value(s) in the DSDT and I have read about it to use a custom DSDT table but I am not 100% sure yet (until I have tested it).
If I understand you correct, than all I have to do is to change the 'SPI1' string in this dsdt to SPI0 like ^SPI1.AUDI to ^SPI0.AUDI and this block here SpiSerialBus (0x0001, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\_SB.SPI1", 0x00, ResourceConsumer, ,
becomes SpiSerialBus (0x0000, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\_SB.SPI0", 0x00, ResourceConsumer, ,
Only change the chipselect above. \SB.SPI1 is the host controller and that's probably correct.
It is worth a try using the custom DSDT. If it brings you working audio then we need to figure out how to work this around in the kernel.
BTW, does the audio work in Windows?
I somehow suspect that it just ignores the chipselect in the SPI driver which might explain why it works (if it works, that is).
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102")
Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
On Thu, Jun 25, 2015 at 03:58:53PM +0100, Mark Brown wrote:
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102")Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
From my brief discussions with the Windows guys here on this
basically those last two digits are being used to inform the Windows driver of use-case setup. So here it will set things up for whatever the Window's driver considers to be setup "5".
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Thanks, Charles
On Thu, Jun 25, 2015 at 04:44:07PM +0100, Charles Keepax wrote:
On Thu, Jun 25, 2015 at 03:58:53PM +0100, Mark Brown wrote:
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102")
Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
From my brief discussions with the Windows guys here on this basically those last two digits are being used to inform the Windows driver of use-case setup. So here it will set things up for whatever the Window's driver considers to be setup "5".
Yay for scalability and abstraction.
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Well, we might want to consider using this to set our platform data instead of the machine ID if people have just been copying a smallish set of reference designs, it might might make for a slightly smaller set of ID tables than the machine ID based stuff does.
Due to the way ACPI ID matching works we'll also need to add every suffix individually to the table, we're looking for complete matches not substring matches here.
On Thu, Jun 25, 2015 at 04:56:12PM +0100, Mark Brown wrote:
On Thu, Jun 25, 2015 at 04:44:07PM +0100, Charles Keepax wrote:
On Thu, Jun 25, 2015 at 03:58:53PM +0100, Mark Brown wrote:
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102")Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
From my brief discussions with the Windows guys here on this basically those last two digits are being used to inform the Windows driver of use-case setup. So here it will set things up for whatever the Window's driver considers to be setup "5".
Yay for scalability and abstraction.
Well it certainly is abstract.
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Well, we might want to consider using this to set our platform data instead of the machine ID if people have just been copying a smallish set of reference designs, it might might make for a slightly smaller set of ID tables than the machine ID based stuff does.
Due to the way ACPI ID matching works we'll also need to add every suffix individually to the table, we're looking for complete matches not substring matches here.
From what I can gather currently yes every system has a different
suffix so it should be fine to skip checking the machine ID and just use the ACPI ID to select the pdata.
Thanks, Charles
On Thu, Jun 25, 2015 at 05:11:08PM +0100, Charles Keepax wrote:
On Thu, Jun 25, 2015 at 04:56:12PM +0100, Mark Brown wrote:
Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
From my brief discussions with the Windows guys here on this basically those last two digits are being used to inform the Windows driver of use-case setup. So here it will set things up for whatever the Window's driver considers to be setup "5".
Yay for scalability and abstraction.
Well it certainly is abstract.
Just not the same abstraction the rest of the world is using there :(
Hi,
I do not want to guess and I also want to minimize the try&error circle, some questions are open yet:
2015-06-25 17:56 GMT+02:00 Mark Brown broonie@kernel.org:
On Thu, Jun 25, 2015 at 04:44:07PM +0100, Charles Keepax wrote:
On Thu, Jun 25, 2015 at 03:58:53PM +0100, Mark Brown wrote:
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102")Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
From my brief discussions with the Windows guys here on this basically those last two digits are being used to inform the Windows driver of use-case setup. So here it will set things up for whatever the Window's driver considers to be setup "5".
Yay for scalability and abstraction.
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Well, we might want to consider using this to set our platform data instead of the machine ID if people have just been copying a smallish set of reference designs, it might might make for a slightly smaller set of ID tables than the machine ID based stuff does.
Due to the way ACPI ID matching works we'll also need to add every suffix individually to the table, we're looking for complete matches not substring matches here.
I saw in the file mfd/arizona/core.h the ENUMs of the arizona_type and one of my first tries was to simple add a new type (like WM510205 = 5,) but it was not clear to me if this will work as expect. I had added in all arizona-{core,spi,i2c) files the WM510205 but that was undeclared, cause I did not added this ENUM yet...
What do you think??
On Mon, Jun 29, 2015 at 10:12:47AM +0200, Christian Hartmann wrote:
Hi,
I do not want to guess and I also want to minimize the try&error circle, some questions are open yet:
2015-06-25 17:56 GMT+02:00 Mark Brown broonie@kernel.org:
On Thu, Jun 25, 2015 at 04:44:07PM +0100, Charles Keepax wrote:
On Thu, Jun 25, 2015 at 03:58:53PM +0100, Mark Brown wrote:
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102")Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
From my brief discussions with the Windows guys here on this basically those last two digits are being used to inform the Windows driver of use-case setup. So here it will set things up for whatever the Window's driver considers to be setup "5".
Yay for scalability and abstraction.
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Well, we might want to consider using this to set our platform data instead of the machine ID if people have just been copying a smallish set of reference designs, it might might make for a slightly smaller set of ID tables than the machine ID based stuff does.
Due to the way ACPI ID matching works we'll also need to add every suffix individually to the table, we're looking for complete matches not substring matches here.
I saw in the file mfd/arizona/core.h the ENUMs of the arizona_type and one of my first tries was to simple add a new type (like WM510205 = 5,) but it was not clear to me if this will work as expect. I had added in all arizona-{core,spi,i2c) files the WM510205 but that was undeclared, cause I did not added this ENUM yet...
What do you think??
I think you are confusing two things here. You shouldn't need to add any new entries to the arizona_type enum there is already an entry for wm5102. "WM510205" is what needs to go into the ACPI match table, we were just discussing that it is probably enough to look up some fixed pdata to configure the driver for this device, rather than needing to seperately check the machine ID.
Thanks, Charles
On 6/25/15 5:44 PM, Charles Keepax wrote:
On Thu, Jun 25, 2015 at 03:58:53PM +0100, Mark Brown wrote:
On Thu, Jun 25, 2015 at 02:18:23PM +0200, Christian Hartmann wrote:
Name (_HID, "WM510205") // _HID: Hardware ID Name (_CID, "WM510205") // _CID: Compatible ID Name (_DDN, "Wolfson Microelectronics Audio WM5102")Separately to the chip select discussion one thing to highlight here is that for some reason the BIOS is listing the device as "WM510205" rather than "WM5102" - do those extra numbers mean anything and does this mean that WM50120[1-4] and possibly higher numbers are also valid?
From my brief discussions with the Windows guys here on this basically those last two digits are being used to inform the Windows driver of use-case setup. So here it will set things up for whatever the Window's driver considers to be setup "5".
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Here's the summary of what a valid _HID should look like. It took me a couple of days to gather the rules from different sources, I hope it helps others figure things out. -Pierre
_HID must be one of these forms: - "AAA####” or EisaID(“AAA####”) where A is an uppercase letter and # is a hex digit. The AAA PNP Vendor ID consists of 3 characters, verified on http://www.uefi.org/sites/default/files/resources/PNPID_List.pdf
- "ACPI####” where # is a hex digit
- "NNNN####” where N is an uppercase letter or decimal digit (0-9) and # is a hex digit (ACPI 5.0). The NNNN Vendor ID can be --> a PCI ID: 4 hex digits (0-9 and A-F), verified on https://www.pcisig.com/membership/vid_search/ --> or an ACPI ID: 4 characters, each character being either an uppercase letter (A-Z) or a numeral (0-9), verified on http://www.uefi.org/sites/default/files/resources/ACPIID_List.pdf
On Fri, Jun 26, 2015 at 01:46:50PM +0200, Pierre-Louis Bossart wrote:
On 6/25/15 5:44 PM, Charles Keepax wrote:
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Here's the summary of what a valid _HID should look like. It took me a couple of days to gather the rules from different sources, I hope it helps others figure things out.
None of which really affact the matching that the kernel does since whatever form the string is generated in we need to do a full string match (nor do they correspond to what it seems the Wolfson drivers have invented but that's a separate issue). Yay standards.
Hi,
@all
FYI: I can confirm that with the changed DSDT.dsl file and loading the new custom DSDT table, I do not need this patch mentioned above.
So the patch is indeed only needed, as long as there is no BIOS (DSDT change by manufacturer) update available.
In this case special case a custom DSDT table is loaded to fix the by ACPI wrongly set of SPIController to 1, which must be 0.
On the other hand I have now an tained kernel too :/ cause of the unset "Select only drivers that don't need compile-time external firmware" and the ''Include Custom DSDT' options.
The dmesg message seems to be the same as with the patch applied but with the current system DSDT table: here
[ 0.000000] Linux version 4.1.0.60-rc0 (b23@berkelium.fyedot.greenzone) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #199 SMP Fri Jun 26 13:47:46 CEST 2015 ... [ 0.000000] ACPI: Early table checksum verification disabled ... [ 5.916597] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO [ 5.916733] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic) [ 5.926671] spi spi-WM510205:00: 8333333 Hz actual, PIO [ 5.926681] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 [ 5.926805] spi spi-WM510205:00: checking WM510205 with bmp180 [ 5.926812] spi spi-WM510205:00: checking WM510205 with bmp181 [ 5.926816] spi spi-WM510205:00: modalias WM510205 in id_table not found, returns NULL [ 5.926843] arizona spi-WM510205:00: acpi_match_device() first, than via spi_get_device_id(). [ 5.926849] arizona spi-WM510205:00: matched ACPI ID and data [ 5.926853] arizona spi-WM510205:00: using 1 as type for arizona audio codec [ 5.926857] arizona spi-WM510205:00: regmap set to wm5102_spi [ 5.927665] arizona spi-WM510205:00: arizona_spi_probe done, call and return of arizona_dev_init [ 5.927759] spi-WM510205:00 supply AVDD not found, using dummy regulator [ 5.927782] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator [ 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
notice : some of these messages above are coming from local added dev_err();
cheers chris
2015-06-26 13:58 GMT+02:00 Mark Brown broonie@kernel.org:
On Fri, Jun 26, 2015 at 01:46:50PM +0200, Pierre-Louis Bossart wrote:
On 6/25/15 5:44 PM, Charles Keepax wrote:
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Here's the summary of what a valid _HID should look like. It took me a couple of days to gather the rules from different sources, I hope it helps others figure things out.
None of which really affact the matching that the kernel does since whatever form the string is generated in we need to do a full string match (nor do they correspond to what it seems the Wolfson drivers have invented but that's a separate issue). Yay standards.
Hello,
Thank you so far at all.
I have sent an email about the Bug in this firmware to lenovo. So I can work on with thhe custom DSDT and will try again to get ACPI working with the WM5102.
As soon as Lenovo has a new BIOS available, I will report that but for the case their will not be a new BIOS update in the near future, what should we do with the patch?? As some suggested, its a firmware bug workaround.
If some Intel developers have some ideas or better some patches in the right directions to let this device initialize correctly and to bind this with the Baytrail (intel_sst_acpi) sound system, than I would be happy to test these patches (or to know the infos I got from you).
cheers chris
2015-06-29 9:27 GMT+02:00 Christian Hartmann cornogle@googlemail.com:
Hi,
@all
FYI: I can confirm that with the changed DSDT.dsl file and loading the new custom DSDT table, I do not need this patch mentioned above.
So the patch is indeed only needed, as long as there is no BIOS (DSDT change by manufacturer) update available.
In this case special case a custom DSDT table is loaded to fix the by ACPI wrongly set of SPIController to 1, which must be 0.
On the other hand I have now an tained kernel too :/ cause of the unset "Select only drivers that don't need compile-time external firmware" and the ''Include Custom DSDT' options.
The dmesg message seems to be the same as with the patch applied but with the current system DSDT table: here
[ 0.000000] Linux version 4.1.0.60-rc0 (b23@berkelium.fyedot.greenzone) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #199 SMP Fri Jun 26 13:47:46 CEST 2015 ... [ 0.000000] ACPI: Early table checksum verification disabled ... [ 5.916597] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO [ 5.916733] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic) [ 5.926671] spi spi-WM510205:00: 8333333 Hz actual, PIO [ 5.926681] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 [ 5.926805] spi spi-WM510205:00: checking WM510205 with bmp180 [ 5.926812] spi spi-WM510205:00: checking WM510205 with bmp181 [ 5.926816] spi spi-WM510205:00: modalias WM510205 in id_table not found, returns NULL [ 5.926843] arizona spi-WM510205:00: acpi_match_device() first, than via spi_get_device_id(). [ 5.926849] arizona spi-WM510205:00: matched ACPI ID and data [ 5.926853] arizona spi-WM510205:00: using 1 as type for arizona audio codec [ 5.926857] arizona spi-WM510205:00: regmap set to wm5102_spi [ 5.927665] arizona spi-WM510205:00: arizona_spi_probe done, call and return of arizona_dev_init [ 5.927759] spi-WM510205:00 supply AVDD not found, using dummy regulator [ 5.927782] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator [ 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
notice : some of these messages above are coming from local added dev_err();
cheers chris
2015-06-26 13:58 GMT+02:00 Mark Brown broonie@kernel.org:
On Fri, Jun 26, 2015 at 01:46:50PM +0200, Pierre-Louis Bossart wrote:
On 6/25/15 5:44 PM, Charles Keepax wrote:
I think from the Linux side we can safely ignore those last two digits. I expect that all systems of the same make and model would report the same last two digits but that it might change between models if the Windows driver is expected to something differently for that model.
Here's the summary of what a valid _HID should look like. It took me a couple of days to gather the rules from different sources, I hope it helps others figure things out.
None of which really affact the matching that the kernel does since whatever form the string is generated in we need to do a full string match (nor do they correspond to what it seems the Wolfson drivers have invented but that's a separate issue). Yay standards.
On Mon, Jun 29, 2015 at 09:46:41AM +0200, Christian Hartmann wrote:
Hello,
Please don't top post.
I have sent an email about the Bug in this firmware to lenovo. So I can work on with thhe custom DSDT and will try again to get ACPI working with the WM5102.
As soon as Lenovo has a new BIOS available, I will report that but for the case their will not be a new BIOS update in the near future, what should we do with the patch?? As some suggested, its a firmware bug workaround.
We'll need to work around this, I wouldn't hold your breath on Lenovo fixing their BIOS and even if they do we really ought to support the shipped BIOS since not everyone is going to want to upgrade (or know to do that).
On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
FYI: I can confirm that with the changed DSDT.dsl file and loading the new custom DSDT table, I do not need this patch mentioned above.
Are you sure?
[ 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.
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:
FYI: I can confirm that with the changed DSDT.dsl file and loading the new custom DSDT table, I do not need this patch mentioned above.
Are you sure?
[ 0.000000] ACPI: Override [DSDT-CS-02 ], this is unsafe: tainting kernel [ 0.000000] Disabling lock debugging due to kernel taint [ 0.000000] ACPI: DSDT 0x0000000078CE2000 Logical table override, new table: 0x00000000C0EBB470 [ 0.000000] ACPI: DSDT 0x00000000C0EBB470 00A6A2 (v02 LENOVO CS-02 00000001 INTL 20150410) [ 0.000000] ACPI: Local APIC address 0xfee00000 ... [ 7.308741] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO [ 7.308837] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic) [ 7.308978] spi spi-WM510205:00: 8333333 Hz actual, PIO [ 7.309002] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 ...
without the DSDT load, I must have this patch applied, otherwise the wm5102 will not be attached. I have checked it both and yes I am really sure since yesterday.
[ 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.
cheers Christian
On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
2015-06-29 11:48 GMT+02:00 Mark Brown broonie@kernel.org:
[ 5.928958] arizona spi-WM510205:00: Unknown device ID: ffff
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.
You need to look at the SPI controller configuration still - like I say that's saying that I/O to the device is not working correctly. Most likely there is some meaning to the chip select setting that's being used and so the main chip select is not doing the job.
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
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
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.
Still chasing them up on this.
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 think in this case we need to hard code the pdata into the driver. Probably in arizona-core.c would be the best place.
I have some more questions that I want to ask/discuss later on irc - if its possible
Yeah I shall jump on and you can give me a shout.
Thanks, Charles
On Tue, Jul 07, 2015 at 10:56:13AM +0100, Charles Keepax wrote:
On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
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 think in this case we need to hard code the pdata into the driver. Probably in arizona-core.c would be the best place.
This is how other drivers with ACPI support like the Realtek ones do this.
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
Oh yeah my nick on IRC is ckeepax, also could you send me through a full copy of the dsdt you included a snippet of in your earlier emails? The Windows guys here are saying the GPIOs should actually be in the ACPI tables and that contray to what I understood from my last conversation with them only some of the setup for the driver is encoded in the single magic number.
Thanks, Charles
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
2015-07-13 11:53 GMT+02:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
2015-06-30 12:34 GMT+02:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
Hi,
2015-06-29 11:48 GMT+02:00 Mark Brown broonie@kernel.org:
On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote:
[ 5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator [ 5.928958] arizona spi-WM510205:00: Unknown device ID: ffff [ 5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
The above is saying that SPI I/O to the device isn't working - the device ID is not being read back successfully.
Ok that is the next problem that must be solved. I have yesterday made a patchset where I have added the enum type 5, but as you said already, that was not needed. All what I see the same: : Unknown device ID: ffff
So where I have to look now or what can I do to let this device id register correctly? I hope the baytrail machine driver is easy peasy to add, but here I stuck at the moment.
As I said in my other emails the next step is to work out what the reset and ldoena gpio's are. You won't be able to read the device ID until you have those setup. Unfortunately, finding the right GPIOs is likely to be a bit of a chore, I will see if I can find anything out from the Windows guys at this end.
Also can you check that the arizona-ldo1 regulator is built in I am surprised that is falling back to the dummy regulator.
Thanks, Charles
Hi,
I just want to ask, if the windows guys have such infos about the gpios in question (reset,ldoena) and of course the irq details.
I am thinking actually to get a second device with Win installed, so that I can get more infos which I really need here. Anyway I can also provide more infos here (if its not against valid laws :) ) But indeeed I can need some hints where to put the pdata structure.
I have some more questions that I want to ask/discuss later on irc - if its possible
cheers Chris
Ok so it does indeed seem the information I got from the Windows team was not fully accurate last time. The IRQ pin, reset line and LDO enable are actually specified in ACPI. This block here has them:
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000, "\_SB.GPO2", 0x00, ResourceConsumer, ,) { // Pin list 0x0004 } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,) { // Pin list 0x0003 } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\_SB.GPO1", 0x00, ResourceConsumer, ,) { // Pin list 0x0017 }
The order here being:
- IRQ
- Reset GPIO
- LDOENA GPIO
Thanks, Charles
(email resend to all) Hello,
@Charles : thank you.
As Charles suggested prior in one of the mails, I have yesterday added this patch belowe and tried it out, but unfortunately I got some new/other errors now while the regulator stuff seems not to be working for the wm5102 device currently
commit 305f33d58632f85730e245df08dc7070789f9789 Author: Christian Hartmann cornogle@googlemail.com Date: Mon Jul 13 13:29:07 2015 +0200
mfd/arizona/pdata.h : added wm5102_pdata with structur of type arizona_pdata
Signed-off-by: Christian Hartmann cornogle@googlemail.com
diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h index 43db4fa..df9153b 100644 --- a/include/linux/mfd/arizona/pdata.h +++ b/include/linux/mfd/arizona/pdata.h @@ -181,4 +181,17 @@ struct arizona_pdata { int irq_gpio; };
+/* added for the WM510205 case here + * + */ + +const static struct arizona_pdata wm5102_pdata = { + .reset = 0x03, + .ldoena = 0x17, + .irq_flags = IRQF_TRIGGER_RISING| + IRQF_TRIGGER_FALLING, + .irq_gpio = 0x04, + +}; + #endif
The dmesg I got in an endless loop is seen below and please note: the messages below are most of local added dev_err() to be sure which code path was running here.
[ 5858.229428] spi spi-WM510205:00: checking WM510205 with bmp180 [ 5858.229437] spi spi-WM510205:00: checking WM510205 with bmp181 [ 5858.229443] spi spi-WM510205:00: modalias WM510205 in id_table not found, returns NULL [ 5858.229497] arizona spi-WM510205:00: acpi_match_device() first, than via spi_get_device_id(). [ 5858.229504] arizona spi-WM510205:00: matched ACPI ID and data [ 5858.229508] arizona spi-WM510205:00: using 1 as type for arizona audio codec [ 5858.229512] arizona spi-WM510205:00: regmap set to wm5102_spi [ 5858.230063] arizona spi-WM510205:00: spi_irq = -1 [ 5858.230069] arizona spi-WM510205:00: arizona_irq = -1 [ 5858.230073] arizona spi-WM510205:00: arizona_spi_probe done, call and return of arizona_dev_init [ 5858.230339] spi-WM510205:00 supply AVDD not found, using dummy regulator [ 5858.230411] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator [ 5858.230451] arizona spi-WM510205:00: Failed to resolve LDOVDD-supply for LDO1 [ 5858.230458] arizona spi-WM510205:00: Failed to request DCVDD: -517 .... repeating now all the time until reboot/power off / energy=0
Did the patch I added here looks good ? or is there an error that I oversight??
cheers chris
2015-07-15 9:01 GMT+02:00 Christian Hartmann cornogle@googlemail.com:
2015-07-13 11:53 GMT+02:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
On Tue, Jul 07, 2015 at 09:06:25AM +0200, Christian Hartmann wrote:
2015-06-30 12:34 GMT+02:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
On Tue, Jun 30, 2015 at 09:14:37AM +0200, Christian Hartmann wrote:
Hi,
2015-06-29 11:48 GMT+02:00 Mark Brown broonie@kernel.org:
On Mon, Jun 29, 2015 at 09:27:17AM +0200, Christian Hartmann wrote: > [ 5.927801] spi-WM510205:00 supply DCVDD not found, using dummy regulator > [ 5.928958] arizona spi-WM510205:00: Unknown device ID: ffff > [ 5.929098] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00
The above is saying that SPI I/O to the device isn't working - the device ID is not being read back successfully.
Ok that is the next problem that must be solved. I have yesterday made a patchset where I have added the enum type 5, but as you said already, that was not needed. All what I see the same: : Unknown device ID: ffff
So where I have to look now or what can I do to let this device id register correctly? I hope the baytrail machine driver is easy peasy to add, but here I stuck at the moment.
As I said in my other emails the next step is to work out what the reset and ldoena gpio's are. You won't be able to read the device ID until you have those setup. Unfortunately, finding the right GPIOs is likely to be a bit of a chore, I will see if I can find anything out from the Windows guys at this end.
Also can you check that the arizona-ldo1 regulator is built in I am surprised that is falling back to the dummy regulator.
Thanks, Charles
Hi,
I just want to ask, if the windows guys have such infos about the gpios in question (reset,ldoena) and of course the irq details.
I am thinking actually to get a second device with Win installed, so that I can get more infos which I really need here. Anyway I can also provide more infos here (if its not against valid laws :) ) But indeeed I can need some hints where to put the pdata structure.
I have some more questions that I want to ask/discuss later on irc - if its possible
cheers Chris
Ok so it does indeed seem the information I got from the Windows team was not fully accurate last time. The IRQ pin, reset line and LDO enable are actually specified in ACPI. This block here has them:
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000, "\_SB.GPO2", 0x00, ResourceConsumer, ,) { // Pin list 0x0004 } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\_SB.I2C7.PMIC", 0x00, ResourceConsumer, ,) { // Pin list 0x0003 } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\_SB.GPO1", 0x00, ResourceConsumer, ,) { // Pin list 0x0017 }
The order here being:
- IRQ
- Reset GPIO
- LDOENA GPIO
Thanks, Charles
(email resend to all) Hello,
@Charles : thank you.
As Charles suggested prior in one of the mails, I have yesterday added this patch belowe and tried it out, but unfortunately I got some new/other errors now while the regulator stuff seems not to be working for the wm5102 device currently
commit 305f33d58632f85730e245df08dc7070789f9789 Author: Christian Hartmann cornogle@googlemail.com Date: Mon Jul 13 13:29:07 2015 +0200
mfd/arizona/pdata.h : added wm5102_pdata with structur of type arizona_pdata Signed-off-by: Christian Hartmann <cornogle@googlemail.com>diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h index 43db4fa..df9153b 100644 --- a/include/linux/mfd/arizona/pdata.h +++ b/include/linux/mfd/arizona/pdata.h @@ -181,4 +181,17 @@ struct arizona_pdata { int irq_gpio; };
+/* added for the WM510205 case here
- */
+const static struct arizona_pdata wm5102_pdata = {
.reset = 0x03,.ldoena = 0x17,.irq_flags = IRQF_TRIGGER_RISING|IRQF_TRIGGER_FALLING,.irq_gpio = 0x04,+};
#endif
The dmesg I got in an endless loop is seen below and please note: the messages below are most of local added dev_err() to be sure which code path was running here.
[ 5858.229428] spi spi-WM510205:00: checking WM510205 with bmp180 [ 5858.229437] spi spi-WM510205:00: checking WM510205 with bmp181 [ 5858.229443] spi spi-WM510205:00: modalias WM510205 in id_table not found, returns NULL [ 5858.229497] arizona spi-WM510205:00: acpi_match_device() first, than via spi_get_device_id(). [ 5858.229504] arizona spi-WM510205:00: matched ACPI ID and data [ 5858.229508] arizona spi-WM510205:00: using 1 as type for arizona audio codec [ 5858.229512] arizona spi-WM510205:00: regmap set to wm5102_spi [ 5858.230063] arizona spi-WM510205:00: spi_irq = -1 [ 5858.230069] arizona spi-WM510205:00: arizona_irq = -1 [ 5858.230073] arizona spi-WM510205:00: arizona_spi_probe done, call and return of arizona_dev_init [ 5858.230339] spi-WM510205:00 supply AVDD not found, using dummy regulator [ 5858.230411] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator [ 5858.230451] arizona spi-WM510205:00: Failed to resolve LDOVDD-supply for LDO1 [ 5858.230458] arizona spi-WM510205:00: Failed to request DCVDD: -517 .... repeating now all the time until reboot/power off / energy=0
Did the patch I added here looks good ? or is there an error that I oversight??
cheers chris
Hello,
I have a LDO1 in dmesg now with the patch from yesterday sent to the lkml from Mark Brown (thank you, Mark).
("[PATCH] regulator: core: Handle full constraints systems when resolving supplies").
here is the feedback after applying Mark's patch above.
I got NO loop in arizona_dev_init() anymore - so far so good. This patch does work at least for me.
The actual dmesg shows me that LDO1 seems to be set right. [ 6.558123] sst-acpi 80860F28:00: No matching ASoC machine driver found [ 6.698840] ACPI: Battery Slot [BATC] (battery present) [ 6.699157] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO [ 6.699233] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic) [ 6.699511] spi spi-WM510205:00: 8333333 Hz actual, PIO [ 6.699519] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 [ 6.699586] spi spi-WM510205:00: checking WM510205 with bmp180 [ 6.707160] spi spi-WM510205:00: checking WM510205 with bmp181 [ 6.714689] spi spi-WM510205:00: modalias WM510205 in id_table not found, returns NULL [ 6.722833] arizona spi-WM510205:00: acpi_match_device() first, than via spi_get_device_id(). [ 6.730565] arizona spi-WM510205:00: matched ACPI ID and data [ 6.738341] arizona spi-WM510205:00: using 1 as type for arizona audio codec [ 6.746119] arizona spi-WM510205:00: regmap set to wm5102_spi [ 6.754063] rfkill_gpio LNV4752:00: GPIO lookup for consumer reset [ 6.754075] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup [ 6.754086] acpi LNV4752:00: GPIO: looking up reset-gpios [ 6.754096] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 0 0 0 [ 6.754180] rfkill_gpio LNV4752:00: GPIO lookup for consumer shutdown [ 6.754185] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup [ 6.754190] acpi LNV4752:00: GPIO: looking up shutdown-gpios [ 6.754196] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 1 0 0 [ 6.754232] acpi LNV4752:00: GPIO: looking up shutdown-gpio [ 6.754238] acpi LNV4752:00: GPIO: looking up 0 in _CRS [ 6.754275] gpio-411 (reset): gpiod_request: status -16 [ 6.754684] arizona spi-WM510205:00: spi_irq = -1 [ 6.762292] arizona spi-WM510205:00: arizona_irq = -1 [ 6.769865] arizona spi-WM510205:00: arizona_spi_probe done, call and return of arizona_dev_in it [ 6.788702] rfkill_gpio: probe of LNV4752:00 failed with error -16 [ 6.789036] spi-WM510205:00 supply AVDD not found, using dummy regulator [ 6.789072] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator [ 6.789140] LDO1: supplied by regulator-dummy [ 6.789391] arizona spi-WM510205:00: Unknown device ID: ffff [ 6.798044] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00 [ 6.805653] i2c i2c-4: Failed to register i2c client MAGN0001:00 at 0x1d (-16)
the only open issue seems the unkown device id, and this could be coming from the (wrong) spi initialization I think.
As I have changed to not use the spi_get_device_id() function., and there still seems to be missing some code (the read back of the device id fails as another developer mentioned)
The first line "sst-acpi 80860F28:00: No matching ASoC machine driver found" should be fine with the last patch holding on the local stash.
Also I have some new questions regarding to the firmware I have to load here. Currently I have the fw_sst_0f28.bin-48kHz_i2s_master which seems not correct (i2c) Do not know yet if I can or should take the default one ( which should be in this case fw_sst_0f28.bin) Does somebody of for intel_sst_acpi and the WM5102 codec if a new or specific firmware must be used to let this codec work at all.
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:
- IRQ
- Reset GPIO
- LDOENA GPIO
Thanks, Charles
(email resend to all) Hello,
@Charles : thank you.
As Charles suggested prior in one of the mails, I have yesterday added this patch belowe and tried it out, but unfortunately I got some new/other errors now while the regulator stuff seems not to be working for the wm5102 device currently
commit 305f33d58632f85730e245df08dc7070789f9789 Author: Christian Hartmann cornogle@googlemail.com Date: Mon Jul 13 13:29:07 2015 +0200
mfd/arizona/pdata.h : added wm5102_pdata with structur of type arizona_pdata Signed-off-by: Christian Hartmann <cornogle@googlemail.com>diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h index 43db4fa..df9153b 100644 --- a/include/linux/mfd/arizona/pdata.h +++ b/include/linux/mfd/arizona/pdata.h @@ -181,4 +181,17 @@ struct arizona_pdata { int irq_gpio; };
+/* added for the WM510205 case here
- */
+const static struct arizona_pdata wm5102_pdata = {
.reset = 0x03,.ldoena = 0x17,.irq_flags = IRQF_TRIGGER_RISING|IRQF_TRIGGER_FALLING,.irq_gpio = 0x04,+};
#endif
The dmesg I got in an endless loop is seen below and please note: the messages below are most of local added dev_err() to be sure which code path was running here.
[ 5858.229428] spi spi-WM510205:00: checking WM510205 with bmp180 [ 5858.229437] spi spi-WM510205:00: checking WM510205 with bmp181 [ 5858.229443] spi spi-WM510205:00: modalias WM510205 in id_table not found, returns NULL [ 5858.229497] arizona spi-WM510205:00: acpi_match_device() first, than via spi_get_device_id(). [ 5858.229504] arizona spi-WM510205:00: matched ACPI ID and data [ 5858.229508] arizona spi-WM510205:00: using 1 as type for arizona audio codec [ 5858.229512] arizona spi-WM510205:00: regmap set to wm5102_spi [ 5858.230063] arizona spi-WM510205:00: spi_irq = -1 [ 5858.230069] arizona spi-WM510205:00: arizona_irq = -1 [ 5858.230073] arizona spi-WM510205:00: arizona_spi_probe done, call and return of arizona_dev_init [ 5858.230339] spi-WM510205:00 supply AVDD not found, using dummy regulator [ 5858.230411] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator [ 5858.230451] arizona spi-WM510205:00: Failed to resolve LDOVDD-supply for LDO1 [ 5858.230458] arizona spi-WM510205:00: Failed to request DCVDD: -517 .... repeating now all the time until reboot/power off / energy=0
Did the patch I added here looks good ? or is there an error that I oversight??
cheers chris
Hello,
I have a LDO1 in dmesg now with the patch from yesterday sent to the lkml from Mark Brown (thank you, Mark).
("[PATCH] regulator: core: Handle full constraints systems when resolving supplies").
here is the feedback after applying Mark's patch above.
I got NO loop in arizona_dev_init() anymore - so far so good. This patch does work at least for me.
The actual dmesg shows me that LDO1 seems to be set right. [ 6.558123] sst-acpi 80860F28:00: No matching ASoC machine driver found [ 6.698840] ACPI: Battery Slot [BATC] (battery present) [ 6.699157] pxa2xx-spi 80860F0E:00: no DMA channels available, using PIO [ 6.699233] pxa2xx-spi 80860F0E:00: registered master spi32766 (dynamic) [ 6.699511] spi spi-WM510205:00: 8333333 Hz actual, PIO [ 6.699519] spi spi-WM510205:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 [ 6.699586] spi spi-WM510205:00: checking WM510205 with bmp180 [ 6.707160] spi spi-WM510205:00: checking WM510205 with bmp181 [ 6.714689] spi spi-WM510205:00: modalias WM510205 in id_table not found, returns NULL [ 6.722833] arizona spi-WM510205:00: acpi_match_device() first, than via spi_get_device_id(). [ 6.730565] arizona spi-WM510205:00: matched ACPI ID and data [ 6.738341] arizona spi-WM510205:00: using 1 as type for arizona audio codec [ 6.746119] arizona spi-WM510205:00: regmap set to wm5102_spi [ 6.754063] rfkill_gpio LNV4752:00: GPIO lookup for consumer reset [ 6.754075] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup [ 6.754086] acpi LNV4752:00: GPIO: looking up reset-gpios [ 6.754096] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 0 0 0 [ 6.754180] rfkill_gpio LNV4752:00: GPIO lookup for consumer shutdown [ 6.754185] rfkill_gpio LNV4752:00: using ACPI for GPIO lookup [ 6.754190] acpi LNV4752:00: GPIO: looking up shutdown-gpios [ 6.754196] acpi LNV4752:00: GPIO: _DSD returned LNV4752:00 3 1 0 0 [ 6.754232] acpi LNV4752:00: GPIO: looking up shutdown-gpio [ 6.754238] acpi LNV4752:00: GPIO: looking up 0 in _CRS [ 6.754275] gpio-411 (reset): gpiod_request: status -16 [ 6.754684] arizona spi-WM510205:00: spi_irq = -1 [ 6.762292] arizona spi-WM510205:00: arizona_irq = -1 [ 6.769865] arizona spi-WM510205:00: arizona_spi_probe done, call and return of arizona_dev_in it [ 6.788702] rfkill_gpio: probe of LNV4752:00 failed with error -16 [ 6.789036] spi-WM510205:00 supply AVDD not found, using dummy regulator [ 6.789072] spi-WM510205:00 supply DBVDD1 not found, using dummy regulator [ 6.789140] LDO1: supplied by regulator-dummy [ 6.789391] arizona spi-WM510205:00: Unknown device ID: ffff [ 6.798044] pxa2xx-spi 80860F0E:00: registered child spi-WM510205:00 [ 6.805653] i2c i2c-4: Failed to register i2c client MAGN0001:00 at 0x1d (-16)
the only open issue seems the unkown device id, and this could be coming from the (wrong) spi initialization I think.
As I have changed to not use the spi_get_device_id() function., and there still seems to be missing some code (the read back of the device id fails as another developer mentioned)
The first line "sst-acpi 80860F28:00: No matching ASoC machine driver found" should be fine with the last patch holding on the local stash.
Also I have some new questions regarding to the firmware I have to load here. Currently I have the fw_sst_0f28.bin-48kHz_i2s_master which seems not correct (i2c) Do not know yet if I can or should take the default one ( which should be in this case fw_sst_0f28.bin) Does somebody of for intel_sst_acpi and the WM5102 codec if a new or specific firmware must be used to let this codec work at all.
I don't really know about the Intel side, but on the CODEC side you shouldn't need any specific firmware to make things work. I would also be somewhat surprised if you needed firmware for the SPI to work. So I think we should be able to register the CODEC happily.
I suspect we still have some issues with the GPIO lookups, I suspect we want to actually pull them from ACPI rather than putting them into the pdata, as I don't know if the number will translate directly over.
Thanks, Charles
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
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
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 + #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
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.
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
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.
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
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?
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.
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
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.
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
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
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
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
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.
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
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
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
Hi Mika, hi,
2015-08-26 11:13 GMT+02:00 Charles Keepax ckeepax@opensource.wolfsonmicro.com:
- 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
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.
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
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.
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.
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.
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
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.
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.
participants (6)
-
Charles Keepax -
Christian Hartmann -
Mark Brown -
Mika Westerberg -
Pierre-Louis Bossart -
Richard Fitzgerald