Hi all,
On Wed, 4 Sep 2019 13:42:50 +0100 Mark Brown <broonie(a)kernel.org> wrote:
[...]
> with Arm laptops coming on the market it's becoming more of an issue so
> let's do something about it.
For the record: I try to run a stock distribution kernel (lots of modules)
on an Olimex Teres-I. The PMIC driver is of course a module.
> In the absence of any better idea just defer the powering off for 30s
> after late_initcall(), this is obviously a hack but it should mask the
> issue for now and it's no more arbitrary than late_initcall() itself.
> Ideally we'd have some heuristics to detect if we're on an affected
> system and tune or skip the delay appropriately, and there may be some
> need for a command line option to be added.
Am I the only one having problems with this change? I get
[ 11.917136] anx6345 0-0038: 0-0038 supply dvdd12-supply not found, using dummy regulator
[ 11.917174] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP803 found
Despite being loaded as a very early module, PMIC init ^^^ only starts now.
[ 11.928664] hub 1-0:1.0: 1 port detected
[ 11.943230] anx6345 0-0038: 0-0038 supply dvdd25-supply not found, using dummy regulator
So far, so bad, but lucky me has an U-Boot which already enabled the display
along with the relevant voltages in the proper sequence.
[ 11.981316] [drm] Found ANX6345 (ver. 170) eDP Transmitter
But much later on
[ 38.248573] dcdc4: disabling
[ 38.268493] vcc-pd: disabling
[ 38.288446] vdd-edp: disabling
screen goes dark and stays dark. Use count of the regulators is 0. I guess
this is because the driver code had been returned the dummy instead?
It's a mobile device so in principle there is nothing wrong with powering
down unused circuitry, and always-on is not an option.
Am I correct to perceive this solution as not 100% mature yet? The anx6345
driver in particular needs to do a little "voltage dance" with specific
timing on the real regulators should the device come up really unpowered,
so IMHO it's probably neccessary to return EPROBE_DEFER at least in this
particular case and prepare the driver for it? Or what would be the real
solution in this case?
Torsten
Hi Johan,
this is probably caused by the move of the driver to staging in
kernel release 5.3 half a year ago. If you want your patches to
apply to pre-5.3 stable releases you'll have to submit a version
with the paths changed from drivers/staging/isdn/gigaset to
drivers/isdn/gigaset.
HTH
Tilman
Am 01.12.2019 um 01:15 schrieb Sasha Levin:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 07dc1f9f2f80 ("[PATCH] isdn4linux: Siemens Gigaset drivers - M105 USB DECT adapter").
>
> The bot has tested the following trees: v5.4.1, v5.3.14, v4.19.86, v4.14.156, v4.9.205, v4.4.205.
>
> v5.4.1: Build OK!
> v5.3.14: Build OK!
> v4.19.86: Failed to apply! Possible dependencies:
> Unable to calculate
>
> v4.14.156: Failed to apply! Possible dependencies:
> Unable to calculate
>
> v4.9.205: Failed to apply! Possible dependencies:
> Unable to calculate
>
> v4.4.205: Failed to apply! Possible dependencies:
> Unable to calculate
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>