Re: [PATCHv3 1/2] dt-bindings: usb: typec: anx7688: start a binding document

[Ondřej Jirman]

On Mon, Apr 08, 2024 at 01:59:12PM GMT, Krzysztof Kozlowski wrote:
> On 08/04/2024 13:52, Ondřej Jirman wrote:
> > On Mon, Apr 08, 2024 at 01:24:03PM GMT, Krzysztof Kozlowski wrote:
> >> On 08/04/2024 13:21, Pavel Machek wrote:
> >>> Hi!
> >>>
> >>>>> Add binding for anx7688 usb type-c bridge. I don't have a datasheet,
> >>>>> but I did best I could.
> >>>>>
> >>>>> Signed-off-by: Pavel Machek <pavel@xxxxxx>
> >>>>
> >>>> ...
> >>>>
> >>>>> +  cabledet-gpios:
> >>>>> +    maxItems: 1
> >>>>> +    description: GPIO controlling CABLE_DET (C3) pin.
> >>>>> +
> >>>>> +  avdd10-supply:
> >>>>> +    description: 1.0V power supply going to AVDD10 (A4, ...) pins
> >>>>> +
> >>>>> +  dvdd10-supply:
> >>>>> +    description: 1.0V power supply going to DVDD10 (D6, ...) pins
> >>>>> +
> >>>>> +  avdd18-supply:
> >>>>> +    description: 1.8V power supply going to AVDD18 (E3, ...) pins
> >>>>> +
> >>>>> +  dvdd18-supply:
> >>>>> +    description: 1.8V power supply going to DVDD18 (G4, ...) pins
> >>>>> +
> >>>>> +  avdd33-supply:
> >>>>> +    description: 3.3V power supply going to AVDD33 (C4, ...) pins
> >>>>> +
> >>>>> +  i2c-supply: true
> >>>>> +  vconn-supply: true
> >>>>
> >>>> There are no such supplies like i2c and vconn on the schematics.
> >>>>
> >>>> I think this represents some other part of component which was added
> >>>> here only for convenience.
> >>>
> >>> Can you give me pointer to documentation you are looking at?
> >>
> >> The schematics you linked in the document at the beginning. Page 13. Do
> >> you see these pins there? I saw only VCONN1_EN, but that's not a supply.
> > 
> > The supply is U1308.
> 
> That's not a supply to anx7688.

Yeah, I understand where the confusion is. The driver is not for anx7688 chip
really. The driver is named anx7688, but that's mostly a historical accident at
this point.

I guess there can be a driver for anx7688 chip that can directly use the chip's
resources from the host by directly manipulating its registers and implementing
type-c functionality via eg. Linux's TCPM or TCPCI stack, etc. (eg. like
fusb302 driver, or various tcpci subdrivers).

But in this case the chip is driven by an optional on-chip microcontroller's
firmware and *this driver* is specifically for *the Type-C port on Pinephone*
and serves as an integration driver for quite a bunch of things that need to
work together on Pinephone for all of the Type-C port's features to operate
reasonably well (and one of those is some communication with anx7688 firmware
that we use, and enabling power to this chip and other things as appropriate,
based on the communication from the firmware).

It handles the specific needs of the Pinephone's Type-C implementation, all of
its quirks (of which there are many over several HW revisions) that can't be
handled by the particular implementation of on-chip microcontroller firmware
directly and need host side interaction.

In an ideal world, many of the things this driver handles would be handled by
embedded microcontroller on the board (like it is with some RK3399 based Google
devices), but Pinephone has no such thing and this glue needs to be implemented
somewhere in the kernel.

Kind regards,
	o.

> Best regards,
> Krzysztof
>