Comment 2 by Nikolaus Schaller, Oct 2, 2013
Analysis shows how it is intended to work: * either the hsmmc.1 driver (WLAN) or the UART1.DTR line (BT) should enable power * this requires a gpio-reg, i.e. a "virtual" GPIO that is virtually connected to the DTR line of the UART driver on one end and to the VAUX4 regulator at the other end * both are registered in the board file as REGULATOR_SUPPLY for VAUX4 * the gpio-reg driver is (currently) a private driver for the GTA04 project Now the problem is that in 3.9 the GPIO code was reworked to use a gpiolib.c providing the function gpiod_request(desc, label). Up to 3.11 it did only check if the desc is NULL. And if desc->chip is NULL, it did silently continue. In 3.12 desc->chip == NULL also returns an -EINVAL. For yet to be found reasons we have desc->chip == NULL for the gpio-reg driver - because there is no chip structure involved. Most likely we have to fix that first. This makes the kernel report: [ 0.262817] gpiod_request: invalid GPIO [ 0.262817] omap_uart: probe of omap_uart.0 failed with error -22 The result is that UART1 (/dev/ttyO0) is not initialized and missing. Why this always enables the VAUX4 is not clear - maybe a default behaviour of gpio-reg.
Comment 3 by Nikolaus Schaller, Oct 2, 2013
as a minor difference, in 3.12-rc3 WLAN is now never enabled (although the gpio_reset of the omap_hsmmc driver is pulsed). This indicates that the whole problem is with the control of VAUX4.
Comment 4 by Nikolaus Schaller, Oct 3, 2013
More analysis results: after booting, the regulator VAUX4 reports 1 as num_users. If someone opens /dev/ttyO0 it increases to 2 and closing the tty reduces it back to 1. This means that the HSMMC always keeps the WLAN side powered. Interestingly, the ifconfig does not report the wlan0 interface, although it exists. Doing an ifconfig wlan0 up makes the interface appear and WLAN works. Doing a ifconfig wlan0 down still does not power down. Rather we may see a page fault which indicates that there is a bug in the SDIO subsystem.
Comment 5 by Nikolaus Schaller, Oct 12, 2013
The segfault/kernel Oops issue has been solved. We now only have the remaining issue that the first firmware load does not power down the chip at the end of if_sdio_finish_power_on() although pm_runtime_put_noidle is called.
Comment 7 by Nikolaus Schaller, Oct 13, 2013
Was fixed by using pm_runtime_put_autosuspend instead of pm_runtime_put_noidle
Comment 8 by William Kisner, Sep 1, 2019
This is my first visit to this website,you have shared very beautiful images of buildings https://prowritingpartner.com/domywriting-com-review/ which i like it a lot.Keep up your good work.
Sign in to reply to this comment.
Reported by Nikolaus Schaller, Sep 4, 2013