Re: [PATCH 1/2] extcon-intel-cht-wc: Make charger detection co-existed with OTG host mode

[Hans de Goede]

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