Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1427765 > unrolled thread

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-06-21 15:40 +0200
    Re: [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-06-21 16:00 +0200
      Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-06-21 22:50 +0200
        Re: [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-06-22 11:50 +0200
          Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-06-22 12:20 +0200
            Re: [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-06-22 13:30 +0200

#1427765 — Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> The purpose of this class is to provide unified interface for user
> space to get the status and basic information about USB Type-C
> Connectors in the system, control data role swapping, and when USB PD
> is available, also power role swapping and Alternate Modes.

This raises two more questions.

1. Booting

It is possible that our only display and, worse, our source
of power is a display that can be used only in an alternate mode
and is connected via a type C connector.

We need some kind of boot time support for alternate modes.

The firmware will surely want to display something. So it is possible
that we start the OS will a valid power contract. How do we deal
with that? Renegotiate?

2. Multiple GPUs

How do we know which GPU is connected to which port?

	Regards
		Oliver

[toc] | [next] | [standalone]

#1427777

On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > The purpose of this class is to provide unified interface for user
> > space to get the status and basic information about USB Type-C
> > Connectors in the system, control data role swapping, and when USB PD
> > is available, also power role swapping and Alternate Modes.
> 
> This raises two more questions.
> 
> 1. Booting
> 
> It is possible that our only display and, worse, our source
> of power is a display that can be used only in an alternate mode
> and is connected via a type C connector.
> 
> We need some kind of boot time support for alternate modes.
> 
> The firmware will surely want to display something. So it is possible
> that we start the OS will a valid power contract. How do we deal
> with that? Renegotiate?

Systems where the firmware has to negotiate PD will likely provide
firmware interface like UCSI, and where the OS has no direct
interaction with the USB PD transceiver. In these case there is no
need to renegotiate as we are just reporting in OS the initial state
after bootup.

We do have a system where the typec port is used to power the board.
On these systems the firmware does not communicate PD (so we will
never have the firmware displaying anything over Type-C on those
systems), but the USB PD chargers for example are detected as 3.0A
Type-C power supplies before any USB PD negotiation takes place, just
like the spec says, and that is more then enough to power these boards.

> 2. Multiple GPUs
> 
> How do we know which GPU is connected to which port?

With ACPI we will have to be able to bind the correct companion to the
device presenting the DP alternate mode under the port. Just like we
will have to bind the ACPI companion of the actual USB port to the
typec port device itself.


Cheers,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1428152

On Tue, 2016-06-21 at 16:58 +0300, Heikki Krogerus wrote:
> On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote:
>  
> > The firmware will surely want to display something. So it is possible
> > that we start the OS will a valid power contract. How do we deal
> > with that? Renegotiate?
> 
> Systems where the firmware has to negotiate PD will likely provide
> firmware interface like UCSI, and where the OS has no direct
> interaction with the USB PD transceiver. In these case there is no
> need to renegotiate as we are just reporting in OS the initial state
> after bootup.

How certain is that? I was under the impression that on many systems
the OS would speak to the TCPM directly.

> We do have a system where the typec port is used to power the board.
> On these systems the firmware does not communicate PD (so we will
> never have the firmware displaying anything over Type-C on those
> systems), but the USB PD chargers for example are detected as 3.0A
> Type-C power supplies before any USB PD negotiation takes place, just
> like the spec says, and that is more then enough to power these boards.

Now correct me, if I am misreading the spec. I am sure the system
will boot unless it needs ridiculous amounts of power, but
will we see anything on the screen? As far as I can tell the spec
actually says that you cannot enter an alternate mode without having
established a power contract.
If we really leave entering modes up to user space, we have lost
printk before getting into the initrd at the earliest.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1428610

Hi Oliver,

On Tue, Jun 21, 2016 at 10:43:05PM +0200, Oliver Neukum wrote:
> On Tue, 2016-06-21 at 16:58 +0300, Heikki Krogerus wrote:
> > On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote:
> >  
> > > The firmware will surely want to display something. So it is possible
> > > that we start the OS will a valid power contract. How do we deal
> > > with that? Renegotiate?
> > 
> > Systems where the firmware has to negotiate PD will likely provide
> > firmware interface like UCSI, and where the OS has no direct
> > interaction with the USB PD transceiver. In these case there is no
> > need to renegotiate as we are just reporting in OS the initial state
> > after bootup.
> 
> How certain is that? I was under the impression that on many systems
> the OS would speak to the TCPM directly.

I think we gonna see systems where the OS has access to TCPC and
where the TCPM is expected to be implemented in the OS, but we
will have quite a few systems where the TCPC/PD controller/non TCPC
compliant Type-C PHY is attached to a microcontroller like EC, and
where that microcontroller will implement TCPM and the OS is exposed
just a separate interface, most likely UCSI.

> > We do have a system where the typec port is used to power the board.
> > On these systems the firmware does not communicate PD (so we will
> > never have the firmware displaying anything over Type-C on those
> > systems), but the USB PD chargers for example are detected as 3.0A
> > Type-C power supplies before any USB PD negotiation takes place, just
> > like the spec says, and that is more then enough to power these boards.
> 
> Now correct me, if I am misreading the spec. I am sure the system
> will boot unless it needs ridiculous amounts of power, but
> will we see anything on the screen? As far as I can tell the spec
> actually says that you cannot enter an alternate mode without having
> established a power contract.
> If we really leave entering modes up to user space, we have lost
> printk before getting into the initrd at the earliest.

With these boards, you will not see anything on the screen that is
attached to a Type-C connector until the OS has booted to the point
where it has negotiated the power contract and entered a mode.

If the system has BIOS/FW/EC capable of negotiating the power contract
and enter a mode, but where we still are expected to take over the
whole TCPM in OS, I think the connection will be reset.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1428657

On Wed, 2016-06-22 at 12:31 +0300, Heikki Krogerus wrote:

Hi,

> > Now correct me, if I am misreading the spec. I am sure the system
> > will boot unless it needs ridiculous amounts of power, but
> > will we see anything on the screen? As far as I can tell the spec
> > actually says that you cannot enter an alternate mode without having
> > established a power contract.
> > If we really leave entering modes up to user space, we have lost
> > printk before getting into the initrd at the earliest.
> 
> With these boards, you will not see anything on the screen that is
> attached to a Type-C connector until the OS has booted to the point
> where it has negotiated the power contract and entered a mode.
> 
> If the system has BIOS/FW/EC capable of negotiating the power contract
> and enter a mode, but where we still are expected to take over the
> whole TCPM in OS, I think the connection will be reset.

Think about a DP over type C display with a USB PD power brick on a
daisy chain.
If the host needs more than 15W or more than 5V, a reset is suicide.

And losing earlyprintk hurts a lot.
This means we need USB PD statically in the kernel. And a kernel
based policy that brings up all displays.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1428702

On Wed, Jun 22, 2016 at 12:08:57PM +0200, Oliver Neukum wrote:
> On Wed, 2016-06-22 at 12:31 +0300, Heikki Krogerus wrote:
> 
> Hi,
> 
> > > Now correct me, if I am misreading the spec. I am sure the system
> > > will boot unless it needs ridiculous amounts of power, but
> > > will we see anything on the screen? As far as I can tell the spec
> > > actually says that you cannot enter an alternate mode without having
> > > established a power contract.
> > > If we really leave entering modes up to user space, we have lost
> > > printk before getting into the initrd at the earliest.
> > 
> > With these boards, you will not see anything on the screen that is
> > attached to a Type-C connector until the OS has booted to the point
> > where it has negotiated the power contract and entered a mode.
> > 
> > If the system has BIOS/FW/EC capable of negotiating the power contract
> > and enter a mode, but where we still are expected to take over the
> > whole TCPM in OS, I think the connection will be reset.
> 
> Think about a DP over type C display with a USB PD power brick on a
> daisy chain.
> If the host needs more than 15W or more than 5V, a reset is suicide.

If the host needs more then 15W from Type-C to bootup, which does not
have enough capacitance the manage the renegotiation, I think will
always have only the FW interface (most likely UCSI) to deal with the
Type-C ports, if even that. The Thunderbolt3 controllers for example
don't give any details about or control over the Type-C ports to OS.
Though I think their firmwares may be made to support UCSI in the
future with some of them.

> And losing earlyprintk hurts a lot.
> This means we need USB PD statically in the kernel. And a kernel
> based policy that brings up all displays.

Yep.

I'm guessing these points are probable one of the major reason why the
control of the Type-C ports was made a responsibility of a discrete
microcontroller or the FW in general.


Thanks,

-- 
heikki

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web