Letux Kernel

Issue 480: enabling/disabling WLAN/BT appears to be broken

Reported by Nikolaus Schaller, Sep 4, 2013

it appears that the automatic power control of WLAN/BT is broken in 
the 3.11 kernel and WLAN is always powered on making the device draw 
more current than necessary.

Power is controlled by VAUX4.

On my device it is:

/sys/devices/platform/omap_i2c.1/i2c-1/1-004b/twl_reg.13/regulator/re
gulator.14/

state is "enabled".

Comment 1 by Nikolaus Schaller, Oct 1, 2013

Status: Accepted
Owner: hns

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 6 by Nikolaus Schaller, Oct 13, 2013

Status: Fixed

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.

Created: 6 years 1 month ago by Nikolaus Schaller

Updated: 1 month 19 days ago

Status: Fixed

Owner: Nikolaus Schaller

Followed by: 1 person

Labels:
Type:Defect
Priority:Critical
Milestone:3.12