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
