Using TCPM for ports without Power Delivery support

Using TCPM for ports without Power Delivery support

[Cristian.Birsan]

Hi,

My name is Cristian and I'm working on bringing up a USB Type-C Port Controller
(TCPC) without Power Delivery support which is intended to work with USB 2.0
Host/Device.

The IP is integrated into one of Microchip's SoCs, it is memory-mapped and it
was designed based on USB Type-C Cable and Connector specification revision 1.2.

In brief, it has support for detecting the threshold voltages on CC1, CC2 lines,
control of the current source (Ip), and pull-down resistors (Rd). The management
of the controller is to be implemented in software (it is not autonomous).

Having in mind that the controller uses proprietary registers, I chose to
implement it using TCPM directly and skip the TCPC Interface.

For the beginning, I would like to enable simple use cases like the ones
described in Connection State Diagram: Source and Connection State Diagram: Sink
from USB Type-C Cable and Connector Specification.

Some of the problems that I encountered until now are:

1. tcpm_register_port() fails if set_pd_rx(), pd_transmit() or set_vconn()
functions are missing.

2. the port capabilities are specified in the connector DT bindings only through
PDOs, even though PDOs are specific to PD mode.

3. once I was able to start the TCPM state machine, it called pd_transmit() in
the process to negotiate the capabilities. For my case I used a dummy function
just to be able to register the port.

Please let me know what you think and if you have any advice. Am I going in the
right direction or is there a better way to implement this?

Kind regards,
Cristian

Re: Using TCPM for ports without Power Delivery support

[Heikki Krogerus]

Hi Cristian,

On Mon, Feb 15, 2021 at 05:25:29PM +0000, Cristian.Birsan@microchip.com wrote:
> My name is Cristian and I'm working on bringing up a USB Type-C Port Controller
> (TCPC) without Power Delivery support which is intended to work with USB 2.0
> Host/Device.
> 
> The IP is integrated into one of Microchip's SoCs, it is memory-mapped and it
> was designed based on USB Type-C Cable and Connector specification revision 1.2.
> 
> In brief, it has support for detecting the threshold voltages on CC1, CC2 lines,
> control of the current source (Ip), and pull-down resistors (Rd). The management
> of the controller is to be implemented in software (it is not autonomous).
> 
> Having in mind that the controller uses proprietary registers, I chose to
> implement it using TCPM directly and skip the TCPC Interface.
> 
> For the beginning, I would like to enable simple use cases like the ones
> described in Connection State Diagram: Source and Connection State Diagram: Sink
> from USB Type-C Cable and Connector Specification.
> 
> Some of the problems that I encountered until now are:
> 
> 1. tcpm_register_port() fails if set_pd_rx(), pd_transmit() or set_vconn()
> functions are missing.
> 
> 2. the port capabilities are specified in the connector DT bindings only through
> PDOs, even though PDOs are specific to PD mode.
> 
> 3. once I was able to start the TCPM state machine, it called pd_transmit() in
> the process to negotiate the capabilities. For my case I used a dummy function
> just to be able to register the port.
> 
> Please let me know what you think and if you have any advice. Am I going in the
> right direction or is there a better way to implement this?

Don't bother with tcpm if you don't have PD support. Just register
your port(s) and the partners directly with the connector class:
https://www.kernel.org/doc/html/latest/driver-api/usb/typec.html

You can use the driver for the TI HD3SS3220 controller as an example
how to do that (drivers/usb/typec/hd3ss3220.c). That thing is also
just USB Type-C PHY without PD support just like your port controller.


Br,

-- 
heikki

Re: Using TCPM for ports without Power Delivery support

[Cristian.Birsan]

Hi Heikki,

On 2/16/21 11:12 AM, Heikki Krogerus wrote:
> 
> Hi Cristian,
> 
> On Mon, Feb 15, 2021 at 05:25:29PM +0000, Cristian.Birsan@microchip.com wrote:
>> My name is Cristian and I'm working on bringing up a USB Type-C Port Controller
>> (TCPC) without Power Delivery support which is intended to work with USB 2.0
>> Host/Device.
>>
>> The IP is integrated into one of Microchip's SoCs, it is memory-mapped and it
>> was designed based on USB Type-C Cable and Connector specification revision 1.2.
>>
>> In brief, it has support for detecting the threshold voltages on CC1, CC2 lines,
>> control of the current source (Ip), and pull-down resistors (Rd). The management
>> of the controller is to be implemented in software (it is not autonomous).
>>
>> Having in mind that the controller uses proprietary registers, I chose to
>> implement it using TCPM directly and skip the TCPC Interface.
>>
>> For the beginning, I would like to enable simple use cases like the ones
>> described in Connection State Diagram: Source and Connection State Diagram: Sink
>> from USB Type-C Cable and Connector Specification.
>>
>> Some of the problems that I encountered until now are:
>>
>> 1. tcpm_register_port() fails if set_pd_rx(), pd_transmit() or set_vconn()
>> functions are missing.
>>
>> 2. the port capabilities are specified in the connector DT bindings only through
>> PDOs, even though PDOs are specific to PD mode.
>>
>> 3. once I was able to start the TCPM state machine, it called pd_transmit() in
>> the process to negotiate the capabilities. For my case I used a dummy function
>> just to be able to register the port.
>>
>> Please let me know what you think and if you have any advice. Am I going in the
>> right direction or is there a better way to implement this?
> 
> Don't bother with tcpm if you don't have PD support. Just register
> your port(s) and the partners directly with the connector class:
> https://www.kernel.org/doc/html/latest/driver-api/usb/typec.html
> 
> You can use the driver for the TI HD3SS3220 controller as an example
> how to do that (drivers/usb/typec/hd3ss3220.c). That thing is also
> just USB Type-C PHY without PD support just like your port controller.
> 

Thank you for the suggestion. I had a look at the driver you mentioned and also
other drivers from the same folder. The chips have logic embedded into
them to handle CC lines and VBUS while the controller on which I'm working
provides basic access to CC lines and it is up to the software to drive it.
VBUS is to be detected/enabled through a standard GPIO.

The reason for which I tried to use TCPM is that I need to implement in software
the Sink/Source Connection State Diagrams, CC debounce, and VBUS management.
I tried to avoid code duplication but on the other hand, my use case does not
involve PD.

If there are better chances to upstream the driver using just the connector
class, I'll move forward with this direction. I just wanted to make sure I
explained correctly may use case before implementing it.

Cristian

> 
> Br,
> 
> --
> heikki
> 

Re: Using TCPM for ports without Power Delivery support

[Guenter Roeck]

On 2/17/21 7:28 AM, Cristian.Birsan@microchip.com wrote:
> Hi Heikki,
> 
> On 2/16/21 11:12 AM, Heikki Krogerus wrote:
>>
>> Hi Cristian,
>>
>> On Mon, Feb 15, 2021 at 05:25:29PM +0000, Cristian.Birsan@microchip.com wrote:
>>> My name is Cristian and I'm working on bringing up a USB Type-C Port Controller
>>> (TCPC) without Power Delivery support which is intended to work with USB 2.0
>>> Host/Device.
>>>
>>> The IP is integrated into one of Microchip's SoCs, it is memory-mapped and it
>>> was designed based on USB Type-C Cable and Connector specification revision 1.2.
>>>
>>> In brief, it has support for detecting the threshold voltages on CC1, CC2 lines,
>>> control of the current source (Ip), and pull-down resistors (Rd). The management
>>> of the controller is to be implemented in software (it is not autonomous).
>>>
>>> Having in mind that the controller uses proprietary registers, I chose to
>>> implement it using TCPM directly and skip the TCPC Interface.
>>>
>>> For the beginning, I would like to enable simple use cases like the ones
>>> described in Connection State Diagram: Source and Connection State Diagram: Sink
>>> from USB Type-C Cable and Connector Specification.
>>>
>>> Some of the problems that I encountered until now are:
>>>
>>> 1. tcpm_register_port() fails if set_pd_rx(), pd_transmit() or set_vconn()
>>> functions are missing.
>>>
>>> 2. the port capabilities are specified in the connector DT bindings only through
>>> PDOs, even though PDOs are specific to PD mode.
>>>
>>> 3. once I was able to start the TCPM state machine, it called pd_transmit() in
>>> the process to negotiate the capabilities. For my case I used a dummy function
>>> just to be able to register the port.
>>>
>>> Please let me know what you think and if you have any advice. Am I going in the
>>> right direction or is there a better way to implement this?
>>
>> Don't bother with tcpm if you don't have PD support. Just register
>> your port(s) and the partners directly with the connector class:
>> https://www.kernel.org/doc/html/latest/driver-api/usb/typec.html
>>
>> You can use the driver for the TI HD3SS3220 controller as an example
>> how to do that (drivers/usb/typec/hd3ss3220.c). That thing is also
>> just USB Type-C PHY without PD support just like your port controller.
>>
> 
> Thank you for the suggestion. I had a look at the driver you mentioned and also
> other drivers from the same folder. The chips have logic embedded into
> them to handle CC lines and VBUS while the controller on which I'm working
> provides basic access to CC lines and it is up to the software to drive it.
> VBUS is to be detected/enabled through a standard GPIO.
> 
> The reason for which I tried to use TCPM is that I need to implement in software
> the Sink/Source Connection State Diagrams, CC debounce, and VBUS management.
> I tried to avoid code duplication but on the other hand, my use case does not
> involve PD.
> 
> If there are better chances to upstream the driver using just the connector
> class, I'll move forward with this direction. I just wanted to make sure I
> explained correctly may use case before implementing it.
> 

Personally I think it would be a bad idea to make the mandatory functions optional.
PD is an integral part of tcpm, after all. How about implementing dummy functions
as needed ?

Thanks,
Guenter