* usb typec not doing handling in-kernel @ 2018-08-13 10:36 Heiko Stuebner 2018-08-13 12:29 ` Guenter Roeck ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Heiko Stuebner @ 2018-08-13 10:36 UTC (permalink / raw) To: Heikki Krogerus Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-usb-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck Hi, 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? 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? Thanks Heiko ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: usb typec not doing handling in-kernel 2018-08-13 10:36 usb typec not doing handling in-kernel Heiko Stuebner @ 2018-08-13 12:29 ` Guenter Roeck [not found] ` <6e3e7449-1957-e98d-c186-97d960e06c09-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> 2018-08-13 13:36 ` Heikki Krogerus 2018-08-13 20:20 ` Alexandru M Stan 2 siblings, 1 reply; 10+ messages in thread From: Guenter Roeck @ 2018-08-13 12:29 UTC (permalink / raw) To: Heiko Stuebner, Heikki Krogerus Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-usb-u79uwXL29TY76Z2rM5mHXA On 08/13/2018 03:36 AM, Heiko Stuebner wrote: > Hi, > > 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? 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? > I used to have a patch for the cros-ec extcon driver which ties it into the typec subsystem. Let me see if I can dig it up. Guenter ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <6e3e7449-1957-e98d-c186-97d960e06c09-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>]
* Re: usb typec not doing handling in-kernel [not found] ` <6e3e7449-1957-e98d-c186-97d960e06c09-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> @ 2018-09-20 8:21 ` Heiko Stuebner 2018-09-20 20:49 ` Guenter Roeck 0 siblings, 1 reply; 10+ messages in thread From: Heiko Stuebner @ 2018-09-20 8:21 UTC (permalink / raw) To: Guenter Roeck Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heikki Krogerus, linux-usb-u79uwXL29TY76Z2rM5mHXA Hi Guenter, Am Montag, 13. August 2018, 14:29:15 CEST schrieb Guenter Roeck: > On 08/13/2018 03:36 AM, Heiko Stuebner wrote: > > Hi, > > > > 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? 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? > > > I used to have a patch for the cros-ec extcon driver which ties it into the > typec subsystem. Let me see if I can dig it up. were your archeological skills working in finding said old patch? Thanks Heiko ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: usb typec not doing handling in-kernel 2018-09-20 8:21 ` Heiko Stuebner @ 2018-09-20 20:49 ` Guenter Roeck 0 siblings, 0 replies; 10+ messages in thread From: Guenter Roeck @ 2018-09-20 20:49 UTC (permalink / raw) To: Heiko Stuebner Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heikki Krogerus, linux-usb-u79uwXL29TY76Z2rM5mHXA On Thu, Sep 20, 2018 at 10:21:59AM +0200, Heiko Stuebner wrote: > Hi Guenter, > > Am Montag, 13. August 2018, 14:29:15 CEST schrieb Guenter Roeck: > > On 08/13/2018 03:36 AM, Heiko Stuebner wrote: > > > Hi, > > > > > > 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? 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? > > > > > I used to have a patch for the cros-ec extcon driver which ties it into the > > typec subsystem. Let me see if I can dig it up. > > were your archeological skills working in finding said old patch? > Not very well :-( Guenter ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: usb typec not doing handling in-kernel 2018-08-13 10:36 usb typec not doing handling in-kernel Heiko Stuebner 2018-08-13 12:29 ` Guenter Roeck @ 2018-08-13 13:36 ` Heikki Krogerus [not found] ` <20180813133637.GA25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org> 2018-08-13 20:20 ` Alexandru M Stan 2 siblings, 1 reply; 10+ messages in thread From: Heikki Krogerus @ 2018-08-13 13:36 UTC (permalink / raw) To: Heiko Stuebner Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-usb-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck Hi Heiko, On Mon, Aug 13, 2018 at 12:36:55PM +0200, Heiko Stuebner wrote: > Hi, > > 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? 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. > 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. 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. Br, -- heikki ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <20180813133637.GA25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org>]
* Re: usb typec not doing handling in-kernel [not found] ` <20180813133637.GA25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org> @ 2018-08-14 13:58 ` Heiko Stuebner 2018-08-15 14:46 ` Heikki Krogerus 0 siblings, 1 reply; 10+ messages in thread From: Heiko Stuebner @ 2018-08-14 13:58 UTC (permalink / raw) To: Heikki Krogerus Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-usb-u79uwXL29TY76Z2rM5mHXA, amstan-F7+t8E8rja9g9hUCZPvPmw, Guenter Roeck Hi Heikki, 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. 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. Thanks Heiko [0] https://patchwork.kernel.org/patch/10418263/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: usb typec not doing handling in-kernel 2018-08-14 13:58 ` Heiko Stuebner @ 2018-08-15 14:46 ` Heikki Krogerus [not found] ` <20180815144636.GB25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 10+ messages in thread From: Heikki Krogerus @ 2018-08-15 14:46 UTC (permalink / raw) To: Heiko Stuebner Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-usb-u79uwXL29TY76Z2rM5mHXA, amstan-F7+t8E8rja9g9hUCZPvPmw, Guenter Roeck Hi, 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). Cheers, -- heikki ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <20180815144636.GB25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org>]
* Re: usb typec not doing handling in-kernel [not found] ` <20180815144636.GB25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org> @ 2018-10-23 13:49 ` Heiko Stuebner 2018-10-24 6:49 ` Heikki Krogerus 0 siblings, 1 reply; 10+ messages in thread From: Heiko Stuebner @ 2018-10-23 13:49 UTC (permalink / raw) To: Heikki Krogerus Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-usb-u79uwXL29TY76Z2rM5mHXA, amstan-F7+t8E8rja9g9hUCZPvPmw, Guenter Roeck 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: usb typec not doing handling in-kernel 2018-10-23 13:49 ` Heiko Stuebner @ 2018-10-24 6:49 ` Heikki Krogerus 0 siblings, 0 replies; 10+ messages in thread From: Heikki Krogerus @ 2018-10-24 6:49 UTC (permalink / raw) To: Heiko Stuebner Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-usb-u79uwXL29TY76Z2rM5mHXA, amstan-F7+t8E8rja9g9hUCZPvPmw, Guenter Roeck Hi guys, On Tue, Oct 23, 2018 at 03:49:03PM +0200, Heiko Stuebner wrote: > > 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 ;-) ? To be honest, I've forgotten about this completely, sorry. I did prepare the patch for this, but I never managed to test it. I'll send the patch as RFC right a way. Sorry for the delay. Enjoy the conference! -- heikki ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: usb typec not doing handling in-kernel 2018-08-13 10:36 usb typec not doing handling in-kernel Heiko Stuebner 2018-08-13 12:29 ` Guenter Roeck 2018-08-13 13:36 ` Heikki Krogerus @ 2018-08-13 20:20 ` Alexandru M Stan 2 siblings, 0 replies; 10+ messages in thread From: Alexandru M Stan @ 2018-08-13 20:20 UTC (permalink / raw) To: Heiko Stuebner Cc: Heikki Krogerus, linux-usb-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., Enric Balletbo i Serra, Benson Leung, Guenter Roeck Hello everyone, Enric was looking recently at some of this to get gadget mode working. I drew this diagram around that time to help explain how things are hooked up on the rk3399 chromebooks. I hope it might be useful for this discussion. https://sites.google.com/a/chromium.org/dev/chromium-os/type-c-on-rk3399-chromebooks Some things to note (which may or may not be already know in here): * CC lines on the rk3399 are not connected to anything, we have an external TCPC * OTG_ID pin not connected to anything * rk3399 doesn't do much in terms of negotiating type C things or charging, everything must be handled by the EC (since such things might happen when the rk3399 is off or asleep). Instead the EC communicates most of that state via the SPI lines (hence cros-ec driver). Alexandru Stan (amstan) On Mon, Aug 13, 2018 at 3:36 AM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote: > > Hi, > > 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? 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? > > > Thanks > Heiko > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-10-24 6:49 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-13 10:36 usb typec not doing handling in-kernel Heiko Stuebner 2018-08-13 12:29 ` Guenter Roeck [not found] ` <6e3e7449-1957-e98d-c186-97d960e06c09-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> 2018-09-20 8:21 ` Heiko Stuebner 2018-09-20 20:49 ` Guenter Roeck 2018-08-13 13:36 ` Heikki Krogerus [not found] ` <20180813133637.GA25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org> 2018-08-14 13:58 ` Heiko Stuebner 2018-08-15 14:46 ` Heikki Krogerus [not found] ` <20180815144636.GB25757-FZxXFokcWpatqXYlAKuG4QC/G2K4zDHf@public.gmane.org> 2018-10-23 13:49 ` Heiko Stuebner 2018-10-24 6:49 ` Heikki Krogerus 2018-08-13 20:20 ` Alexandru M Stan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.