Messages in this thread | | | Subject | Re: [PATCH 1/2] extcon-intel-cht-wc: Make charger detection co-existed with OTG host mode | From | Hans de Goede <> | Date | Thu, 14 Feb 2019 16:32:36 +0100 |
| |
Hi,
On 14-02-19 08:09, Yauhen Kharuzhy wrote: > On Thu, Feb 14, 2019 at 12:15:00AM +0100, Hans de Goede wrote: >> Hi, >> >> On 10-02-19 21:36, Yauhen Kharuzhy wrote: >>> Whiskey Cove Cherry Trail PMIC requires disabling OTG host mode before >>> of charger detection procedure. Do this by manipulationg of CHGRCTRL1 >>> register. >>> >>> Source: APCI DSDT code of Lenovo Yoga Book YB1-X91L and open-sourced >>> Intel's drivers. >> >> Hmm, of the ACPI code is updating the otg-mode, then there should be >> no reason for us to do this, can you provide an acpidump of your >> device please? > > sure: https://github.com/jekhor/yogabook-linux/blob/master/yoga/acpi/yoga.acpidump.log > > Yes, there is ACPI routine for switching this but it is not called at > IRQ handling because it is handled by extcon driver. See my notes here: > https://github.com/jekhor/yogabook-linux/blob/master/yoga/acpi/investigate.txt#L364
The reason the _E12 and/or _E1F methods are not called is because they are GPIO interrupt handlers for virtual GPIOs on the PMIC, this is another abomination on these devices, that the ACPI GPIO interface is abused to make it look like the PMIC has more GPIOs then it really does and a bunch if them are used either to create event handlers for no-one knows which events exactly, where as the 0x20 - 0x55 ones are write-only virtual GPIOs where writing them is supposed to do no-one knows what. For some reason the people who engineered this decided it was not a good idea to have the AML code actually just directly talk to the hardware (except that in other cases it does of course) and it goes through these fake GPIOs which presumably are implemented by the Windows GPIO driver for the PMIC
Note that we do implement the custom opregion 0x8F for the INT34D3 / PMI5 device, so the GET/SET calls could work, except that we have the following bug:
-drivers/acpi/pmic/intel_pmic.c intel_pmic_regs_handler is wrong, assumes everything is a write, read of address 3 should return last value read on writing 0 to address 4, see the GET method on INT34D3 / PMI5
Even if we fix that bug though, there still is the issues that we:
1) Do not know when to execute the _E12 and/or _E1F methods 2) Do not know what to do of any of the "virtual" GPIOs are written 3) There is no valid ACPI battery interface for querying battery status
So we are better of just not executing the _E12 and/or _E1F methods ever and directly talking to the hardware.
<grumble mode on> If only the engineers who did the firmware interface for these devices had actually known what they were doing. </grumble mode>
Regards,
Hans
| |