Hi, Am Mittwoch, 15. August 2018, 16:46:36 CEST schrieb Heikki Krogerus: > On Tue, Aug 14, 2018 at 03:58:31PM +0200, Heiko Stuebner wrote: > > Am Montag, 13. August 2018, 15:36:37 CEST schrieb Heikki Krogerus: > > > On Mon, Aug 13, 2018 at 12:36:55PM +0200, Heiko Stuebner wrote:ß > > > > I'm currently trying to wrap my head around the new typec subsystem and > > > > also how to do it correctly on Rockchip rk3399 devices. > > > > > > > > The issue (and Guenter might know quite a bit about that) is that on > > > > ChromeOS devices the embedded controller hides the whole tcpm/vdm > > > > logic from the operating system and just provides a custom interface to > > > > query things like cable state, display-port hotplug status and so on. > > > > > > > > So right now the rk3399-typec-phy uses that extcon-based interface to > > > > get all status changes but that of course leaves out all systems directly > > > > talking to a fusb302. I did a small drawing to showcase that: > > > > > > > > ------------- ------------------ > > > > | typec-phy |----| extcon-cros-ec |\ > > > > ------------- ------------------ \ > > > > | \ \ > > > > ------------- \ ------------------ \ ----------- > > > > | cdn-dp | \| ????? |-----| fusb302 | > > > > ------------- ------------------ ----------- > > > > > > > > So to bring everything on the same page, I guess the cros-ec extcon > > > > (drivers/extcon/extcon-usbc-cros-ec.c) should somehow use the typec > > > > functions instead of implementing an extcon? > > > > > > I don't think the two necessary exclude each other. You can continue > > > to register the extcon device and use it for communication with the > > > phy driver, and also register your Type-C port(s), partners, and > > > optionally the port and partner alternate modes. I guess Guenter has > > > patches for that already? > > > > The issue is less with the working ChromeOS devices :-) . > > > > What I'm trying to fit in there are all the other boards directly talking > > to a fusb302 via i2c and needing to do all these negotiations. > > Ah, OK. Now I get it. > > > So the rockchip typec phy would need to handle both cases. In the Rockchip > > vendor kernel they bolted the extcon export onto their fusb302 driver > > but I don't think that is really future proof ;-) . > > > > Hence the easiest way would probably be to have everything use the newer > > typec APIs and not try to make the Rockchip typec-phy handle both cases. > > > > > > And looking at Guenters mail, it seems like he had the same idea as well > > in the past, so I'll hope for his archeology-skills :-) . > > > > > > > It looks to me like that phy driver could just register a Type-C > > > switch for the orientation, and mux for the mode. Those seem to be the > > > only details the driver needs from extcon-usbc-cros-ec. > > > > Looks like it - I'm still trying to find my way through the typec subsystem > > though. > > > > > > But from reading into the typec code, it somehow looks like the > > > > typec framework expects to be in control of things like altmode > > > > negotiations, or am I misreading something? > > > > > > The alternate mode drivers will assume they are in control of the > > > negotiation with the partner, but note that you will not always need > > > them. The rest of the code in the framework doesn't expect to be in > > > control of the communication. > > > > > > If the EC (or some other microcontroller) firmware is taking care of > > > the actual entering and configuring of the alternate modes, the port > > > driver (so extcon-usbc-cros-ec in your case) will need to "emulate" > > > the VDM communication if the alt mode drivers need to be used, and > > > that means they need to do so with every supported alternate mode > > > separately. > > > > > > Of course if the details that for example the DisplayPort alt mode > > > driver supplies to the user space is not relevant on your system, and > > > there is no requirement to allow the user to be able to reconfigure > > > the DisplayPort alt mode (note: you will also be unable to exit the > > > mode from sysfs in this case), you can still register the partner alt > > > mode device and simply allow the binding to the driver fail, or don't > > > register the partner alt modes with the USB Type-C framework at all. > > > > As said above, I'm mainly trying to make the typec framework usable > > for all the rk3399 boards using the "standard" setup of talking directly > > to the fusb302 but of course want to pull the cros-ec special case along, > > to not create to much overhead anywhere. > > > > Thankfully it is really only the DisplayPort Alt Mode that is supported > > on the rk3399. > > > > While the extcon driver doesn't seem to use it right now, looking through > > the ec-commands shows that muxes, roles etc seem configurable from the > > host side. > > > > > > > I've prepared patches for the ucsi driver that add displayport alt > > > mode support to it. UCSI is just a standardised firmware interface for > > > USB Type-C conncetors, so the situation is exactly the same as with > > > extcon-usbc-cros-ec. I was planning to send the patches out for review > > > after next -rc1, but I guess I could send a RFC already. With UCSI we > > > do have a requirement to allow the user to reconfigure the DisplayPort > > > alternate mode if needed. > > > > That might be helpful. But you don't really have to hurry that much. > > -rc1 isn't that far away and I do have enough individual projects to > > keep me busy ;-) . > > > > Especially also as the device_connection stuff does seem to still > > miss graph-parsing [0] to connect my dt-stuff together, there > > is no really hurry. > > True, the graph parsing is indeed missing from that API. I'll see if I > can propose something for that at one point (soon hopefully). as I'm just sitting next to Guenter at ELCE talking about that type-c stuff, did you manage that graph parsing patch we talked about two months ago ;-) ? Thanks Heiko
