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

[Krzysztof Kozlowski]

On 08/04/2024 14:48, Ondřej Jirman wrote:
> 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*

We do not talk here about the driver, but bindings, so hardware.

> 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).

That's still looking like putting board design into particular device
binding.

> 
> 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.

You might need multiple schemas, because this is for anx7688, not for
Pinephone type-c implementation.

However I still do not see yet a limitation of DTS requiring stuffing
some other properties into anx7688 or creating some other, virtual entity.


Best regards,
Krzysztof