ucsi and DRD controller interaction

ucsi and DRD controller interaction

[Shah, Nehal-bakulchandra]

Hi Heikki ,

I need some pointer from you, so in a system where I have UCSI driver for DRD Controller, then how call stack will be?

I am unable to comprehend the flow from UCSI infrastructure to DRD controller code base.

 
Thanks

Nehal Shah

Re: ucsi and DRD controller interaction

[Heikki Krogerus]

Adding linux-usb mailing list.

On Mon, Apr 20, 2020 at 07:09:17PM +0530, Shah, Nehal-bakulchandra wrote:
> Hi Heikki ,
> 
> I need some pointer from you, so in a system where I have UCSI driver for DRD
> Controller, then how call stack will be?
> 
> I am unable to comprehend the flow from UCSI infrastructure to DRD controller
> code base.

Do you need to tell the negotiated data role to your USB controller
driver from the UCSI driver? For that we would need to know which USB
controller, or more precisely, which USB port is connected to the
USB Type-C connector in question.

That would require ACPI tables to be able to describe the connection
between the USB Type-C connector and the USB port (and the connection
between DisplayPort and the USB Type-C connector etc.). Unfortunately
there is currently no documented way of doing that, however, there is
a proposal for a document the defines how the USB Type-C connectors
should be described in ACPI in general. The proposal does consider
this problem as well. For this the solution is to use _DSD device
properties "usb2-port" and "usb3-port" that have references to the
correct USB port nodes as values.

Which USB controller are you using btw?

thanks,

-- 
heikki

Re: ucsi and DRD controller interaction

[Shah, Nehal-bakulchandra]

Hi

On 4/21/2020 1:13 PM, Heikki Krogerus wrote:
> Adding linux-usb mailing list.
>
> On Mon, Apr 20, 2020 at 07:09:17PM +0530, Shah, Nehal-bakulchandra wrote:
>> Hi Heikki ,
>>
>> I need some pointer from you, so in a system where I have UCSI driver for DRD
>> Controller, then how call stack will be?
>>
>> I am unable to comprehend the flow from UCSI infrastructure to DRD controller
>> code base.
> Do you need to tell the negotiated data role to your USB controller
> driver from the UCSI driver? For that we would need to know which USB
> controller, or more precisely, which USB port is connected to the
> USB Type-C connector in question.
>
> That would require ACPI tables to be able to describe the connection
> between the USB Type-C connector and the USB port (and the connection
> between DisplayPort and the USB Type-C connector etc.). Unfortunately
> there is currently no documented way of doing that, however, there is
> a proposal for a document the defines how the USB Type-C connectors
> should be described in ACPI in general. The proposal does consider
> this problem as well. For this the solution is to use _DSD device
> properties "usb2-port" and "usb3-port" that have references to the
> correct USB port nodes as values.
>
> Which USB controller are you using btw?
>
> thanks,

Thanks for the mail.

Here is the configuration

1. DRD Controller (DWC3 controller)

2. TI PD Controller

3. TI PD Controller and Host has I2C as transport layer. So ACPI mechanism wont work here.


Hence i was wondering, is there any way from UCSI Driver we inform to DWC3 driver stack about Role change. I can understand one point that,

DWC3 controller can work without UCSI Implementation i.e Only PD firmware. But i want to understand  if there is a role change, PD interrupt will be generated

and UCSI Driver will come to know about this role change. But from this onwards , i am  unable to comprehend how it can be propagated upto DWC3 stack.


Thanks

Nehal Shah

Re: ucsi and DRD controller interaction

[Heikki Krogerus]

On Tue, Apr 21, 2020 at 07:23:30PM +0530, Shah, Nehal-bakulchandra wrote:
> Hi
> 
> On 4/21/2020 1:13 PM, Heikki Krogerus wrote:
> > Adding linux-usb mailing list.
> >
> > On Mon, Apr 20, 2020 at 07:09:17PM +0530, Shah, Nehal-bakulchandra wrote:
> >> Hi Heikki ,
> >>
> >> I need some pointer from you, so in a system where I have UCSI driver for DRD
> >> Controller, then how call stack will be?
> >>
> >> I am unable to comprehend the flow from UCSI infrastructure to DRD controller
> >> code base.
> > Do you need to tell the negotiated data role to your USB controller
> > driver from the UCSI driver? For that we would need to know which USB
> > controller, or more precisely, which USB port is connected to the
> > USB Type-C connector in question.
> >
> > That would require ACPI tables to be able to describe the connection
> > between the USB Type-C connector and the USB port (and the connection
> > between DisplayPort and the USB Type-C connector etc.). Unfortunately
> > there is currently no documented way of doing that, however, there is
> > a proposal for a document the defines how the USB Type-C connectors
> > should be described in ACPI in general. The proposal does consider
> > this problem as well. For this the solution is to use _DSD device
> > properties "usb2-port" and "usb3-port" that have references to the
> > correct USB port nodes as values.
> >
> > Which USB controller are you using btw?
> >
> > thanks,
> 
> Thanks for the mail.
> 
> Here is the configuration
> 
> 1. DRD Controller (DWC3 controller)
> 
> 2. TI PD Controller
> 
> 3. TI PD Controller and Host has I2C as transport layer. So ACPI mechanism wont work here.
> 
> 
> Hence i was wondering, is there any way from UCSI Driver we inform to DWC3 driver stack about Role change. I can understand one point that,
> 
> DWC3 controller can work without UCSI Implementation i.e Only PD firmware. But i want to understand  if there is a role change, PD interrupt will be generated
> 
> and UCSI Driver will come to know about this role change. But from this onwards , i am  unable to comprehend how it can be propagated upto DWC3 stack.

If the Type-C drivers need to tell DWC3 driver the data role (USB
role) the connector is operating in, then you use the USB Role Switch
Class for that (drivers/usb/role/). The USB Type-C driver (so ucsi.c
or tps6598x.c in this case) that knows the USB role tells it to the
USB role class by calling usb_role_switch_set_role().

The USB role switch class then takes care of forwarding the
information to the actual switch, which is DWC3 in this case. The DWC3
driver already registers the USB role switch for you
(drivers/usb/dwc3/drd.c), but the UCSI driver, and also tps6598x.c,
does not use the USB role switch API yet. There has never been need
for that before this.

Adding USB role switch handling to the UCSI and tps6598x drivers can
easily be fixed, but it's still not enough. You still need to describe
the connection between the USB PD controller and DWC3 somewhere.

thanks,

-- 
heikki

Re: ucsi and DRD controller interaction

[Shah, Nehal-bakulchandra]

Hi

On 4/22/2020 4:30 PM, Heikki Krogerus wrote:
> On Tue, Apr 21, 2020 at 07:23:30PM +0530, Shah, Nehal-bakulchandra wrote:
>> Hi
>>
>> On 4/21/2020 1:13 PM, Heikki Krogerus wrote:
>>> Adding linux-usb mailing list.
>>>
>>> On Mon, Apr 20, 2020 at 07:09:17PM +0530, Shah, Nehal-bakulchandra wrote:
>>>> Hi Heikki ,
>>>>
>>>> I need some pointer from you, so in a system where I have UCSI driver for DRD
>>>> Controller, then how call stack will be?
>>>>
>>>> I am unable to comprehend the flow from UCSI infrastructure to DRD controller
>>>> code base.
>>> Do you need to tell the negotiated data role to your USB controller
>>> driver from the UCSI driver? For that we would need to know which USB
>>> controller, or more precisely, which USB port is connected to the
>>> USB Type-C connector in question.
>>>
>>> That would require ACPI tables to be able to describe the connection
>>> between the USB Type-C connector and the USB port (and the connection
>>> between DisplayPort and the USB Type-C connector etc.). Unfortunately
>>> there is currently no documented way of doing that, however, there is
>>> a proposal for a document the defines how the USB Type-C connectors
>>> should be described in ACPI in general. The proposal does consider
>>> this problem as well. For this the solution is to use _DSD device
>>> properties "usb2-port" and "usb3-port" that have references to the
>>> correct USB port nodes as values.
>>>
>>> Which USB controller are you using btw?
>>>
>>> thanks,
>> Thanks for the mail.
>>
>> Here is the configuration
>>
>> 1. DRD Controller (DWC3 controller)
>>
>> 2. TI PD Controller
>>
>> 3. TI PD Controller and Host has I2C as transport layer. So ACPI mechanism wont work here.
>>
>>
>> Hence i was wondering, is there any way from UCSI Driver we inform to DWC3 driver stack about Role change. I can understand one point that,
>>
>> DWC3 controller can work without UCSI Implementation i.e Only PD firmware. But i want to understand  if there is a role change, PD interrupt will be generated
>>
>> and UCSI Driver will come to know about this role change. But from this onwards , i am  unable to comprehend how it can be propagated upto DWC3 stack.
> If the Type-C drivers need to tell DWC3 driver the data role (USB
> role) the connector is operating in, then you use the USB Role Switch
> Class for that (drivers/usb/role/). The USB Type-C driver (so ucsi.c
> or tps6598x.c in this case) that knows the USB role tells it to the
> USB role class by calling usb_role_switch_set_role().
>
> The USB role switch class then takes care of forwarding the
> information to the actual switch, which is DWC3 in this case. The DWC3
> driver already registers the USB role switch for you
> (drivers/usb/dwc3/drd.c), but the UCSI driver, and also tps6598x.c,
> does not use the USB role switch API yet. There has never been need
> for that before this.
>
> Adding USB role switch handling to the UCSI and tps6598x drivers can
> easily be fixed, but it's still not enough. You still need to describe
> the connection between the USB PD controller and DWC3 somewhere.
>
> thanks,

appreciate your input.  So if understand correctly, something like below  patch has to be done

http://lkml.iu.edu/hypermail/linux/kernel/2003.1/04687.html

So this patch is still under review? right, and this will take for "Registering a role switch in the DRD code". So then from ucsi.c we need to

call the role class. Also, the above patch is based on device tree binding (i.e for arm platform)but in my case i have x86 so do i have to expose this via ACPI?

Regards

Nehal Shah

Re: ucsi and DRD controller interaction

[Heikki Krogerus]

On Wed, Apr 22, 2020 at 06:37:10PM +0530, Shah, Nehal-bakulchandra wrote:
> Hi
> 
> On 4/22/2020 4:30 PM, Heikki Krogerus wrote:
> > On Tue, Apr 21, 2020 at 07:23:30PM +0530, Shah, Nehal-bakulchandra wrote:
> >> Hi
> >>
> >> On 4/21/2020 1:13 PM, Heikki Krogerus wrote:
> >>> Adding linux-usb mailing list.
> >>>
> >>> On Mon, Apr 20, 2020 at 07:09:17PM +0530, Shah, Nehal-bakulchandra wrote:
> >>>> Hi Heikki ,
> >>>>
> >>>> I need some pointer from you, so in a system where I have UCSI driver for DRD
> >>>> Controller, then how call stack will be?
> >>>>
> >>>> I am unable to comprehend the flow from UCSI infrastructure to DRD controller
> >>>> code base.
> >>> Do you need to tell the negotiated data role to your USB controller
> >>> driver from the UCSI driver? For that we would need to know which USB
> >>> controller, or more precisely, which USB port is connected to the
> >>> USB Type-C connector in question.
> >>>
> >>> That would require ACPI tables to be able to describe the connection
> >>> between the USB Type-C connector and the USB port (and the connection
> >>> between DisplayPort and the USB Type-C connector etc.). Unfortunately
> >>> there is currently no documented way of doing that, however, there is
> >>> a proposal for a document the defines how the USB Type-C connectors
> >>> should be described in ACPI in general. The proposal does consider
> >>> this problem as well. For this the solution is to use _DSD device
> >>> properties "usb2-port" and "usb3-port" that have references to the
> >>> correct USB port nodes as values.
> >>>
> >>> Which USB controller are you using btw?
> >>>
> >>> thanks,
> >> Thanks for the mail.
> >>
> >> Here is the configuration
> >>
> >> 1. DRD Controller (DWC3 controller)
> >>
> >> 2. TI PD Controller
> >>
> >> 3. TI PD Controller and Host has I2C as transport layer. So ACPI mechanism wont work here.
> >>
> >>
> >> Hence i was wondering, is there any way from UCSI Driver we inform to DWC3 driver stack about Role change. I can understand one point that,
> >>
> >> DWC3 controller can work without UCSI Implementation i.e Only PD firmware. But i want to understand  if there is a role change, PD interrupt will be generated
> >>
> >> and UCSI Driver will come to know about this role change. But from this onwards , i am  unable to comprehend how it can be propagated upto DWC3 stack.
> > If the Type-C drivers need to tell DWC3 driver the data role (USB
> > role) the connector is operating in, then you use the USB Role Switch
> > Class for that (drivers/usb/role/). The USB Type-C driver (so ucsi.c
> > or tps6598x.c in this case) that knows the USB role tells it to the
> > USB role class by calling usb_role_switch_set_role().
> >
> > The USB role switch class then takes care of forwarding the
> > information to the actual switch, which is DWC3 in this case. The DWC3
> > driver already registers the USB role switch for you
> > (drivers/usb/dwc3/drd.c), but the UCSI driver, and also tps6598x.c,
> > does not use the USB role switch API yet. There has never been need
> > for that before this.
> >
> > Adding USB role switch handling to the UCSI and tps6598x drivers can
> > easily be fixed, but it's still not enough. You still need to describe
> > the connection between the USB PD controller and DWC3 somewhere.
> >
> > thanks,
> 
> appreciate your input.  So if understand correctly, something like below  patch has to be done
> 
> http://lkml.iu.edu/hypermail/linux/kernel/2003.1/04687.html
> 
> So this patch is still under review?

The patch is in mainline:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a0a137997448690a642e2325fe73242788b26fe

> right, and this will take for "Registering a role switch in the DRD code". So then from ucsi.c we need to
> 
> call the role class. Also, the above patch is based on device tree binding (i.e for arm platform)but in my case i have x86 so do i have to expose this via ACPI?

That patch does not actually have anything devicetree specific, but
you do need to supply the description of the connection like I said,
and ideally you can do that in your ACPI tables.

Can you still influence what goes to your ACPI tables, or are we
talking about products that are already on the market?


thanks,

-- 
heikki

Re: ucsi and DRD controller interaction

[Shah, Nehal-bakulchandra]

Hi

On 4/22/2020 7:58 PM, Heikki Krogerus wrote:
> On Wed, Apr 22, 2020 at 06:37:10PM +0530, Shah, Nehal-bakulchandra wrote:
>> Hi
>>
>> On 4/22/2020 4:30 PM, Heikki Krogerus wrote:
>>> On Tue, Apr 21, 2020 at 07:23:30PM +0530, Shah, Nehal-bakulchandra wrote:
>>>> Hi
>>>>
>>>> On 4/21/2020 1:13 PM, Heikki Krogerus wrote:
>>>>> Adding linux-usb mailing list.
>>>>>
>>>>> On Mon, Apr 20, 2020 at 07:09:17PM +0530, Shah, Nehal-bakulchandra wrote:
>>>>>> Hi Heikki ,
>>>>>>
>>>>>> I need some pointer from you, so in a system where I have UCSI driver for DRD
>>>>>> Controller, then how call stack will be?
>>>>>>
>>>>>> I am unable to comprehend the flow from UCSI infrastructure to DRD controller
>>>>>> code base.
>>>>> Do you need to tell the negotiated data role to your USB controller
>>>>> driver from the UCSI driver? For that we would need to know which USB
>>>>> controller, or more precisely, which USB port is connected to the
>>>>> USB Type-C connector in question.
>>>>>
>>>>> That would require ACPI tables to be able to describe the connection
>>>>> between the USB Type-C connector and the USB port (and the connection
>>>>> between DisplayPort and the USB Type-C connector etc.). Unfortunately
>>>>> there is currently no documented way of doing that, however, there is
>>>>> a proposal for a document the defines how the USB Type-C connectors
>>>>> should be described in ACPI in general. The proposal does consider
>>>>> this problem as well. For this the solution is to use _DSD device
>>>>> properties "usb2-port" and "usb3-port" that have references to the
>>>>> correct USB port nodes as values.
>>>>>
>>>>> Which USB controller are you using btw?
>>>>>
>>>>> thanks,
>>>> Thanks for the mail.
>>>>
>>>> Here is the configuration
>>>>
>>>> 1. DRD Controller (DWC3 controller)
>>>>
>>>> 2. TI PD Controller
>>>>
>>>> 3. TI PD Controller and Host has I2C as transport layer. So ACPI mechanism wont work here.
>>>>
>>>>
>>>> Hence i was wondering, is there any way from UCSI Driver we inform to DWC3 driver stack about Role change. I can understand one point that,
>>>>
>>>> DWC3 controller can work without UCSI Implementation i.e Only PD firmware. But i want to understand  if there is a role change, PD interrupt will be generated
>>>>
>>>> and UCSI Driver will come to know about this role change. But from this onwards , i am  unable to comprehend how it can be propagated upto DWC3 stack.
>>> If the Type-C drivers need to tell DWC3 driver the data role (USB
>>> role) the connector is operating in, then you use the USB Role Switch
>>> Class for that (drivers/usb/role/). The USB Type-C driver (so ucsi.c
>>> or tps6598x.c in this case) that knows the USB role tells it to the
>>> USB role class by calling usb_role_switch_set_role().
>>>
>>> The USB role switch class then takes care of forwarding the
>>> information to the actual switch, which is DWC3 in this case. The DWC3
>>> driver already registers the USB role switch for you
>>> (drivers/usb/dwc3/drd.c), but the UCSI driver, and also tps6598x.c,
>>> does not use the USB role switch API yet. There has never been need
>>> for that before this.
>>>
>>> Adding USB role switch handling to the UCSI and tps6598x drivers can
>>> easily be fixed, but it's still not enough. You still need to describe
>>> the connection between the USB PD controller and DWC3 somewhere.
>>>
>>> thanks,
>> appreciate your input.  So if understand correctly, something like below  patch has to be done
>>
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flkml.iu.edu%2Fhypermail%2Flinux%2Fkernel%2F2003.1%2F04687.html&data=02%7C01%7Cnehal-bakulchandra.shah%40amd.com%7Cafa9696669a74336186a08d7e6c96354%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637231624939620306&sdata=nwwQbBBlAduAOhIfvfYv9UzR%2B478yN%2Fldb9%2FLK%2F6eiE%3D&reserved=0
>>
>> So this patch is still under review?
> The patch is in mainline:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D8a0a137997448690a642e2325fe73242788b26fe&data=02%7C01%7Cnehal-bakulchandra.shah%40amd.com%7Cafa9696669a74336186a08d7e6c96354%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637231624939620306&sdata=%2BIf%2Bz0Cm7CG32POOf3tdue%2FSamAqWPGjaZQYwBuRFwE%3D&reserved=0
>
>> right, and this will take for "Registering a role switch in the DRD code". So then from ucsi.c we need to
>>
>> call the role class. Also, the above patch is based on device tree binding (i.e for arm platform)but in my case i have x86 so do i have to expose this via ACPI?
> That patch does not actually have anything devicetree specific, but
> you do need to supply the description of the connection like I said,
> and ideally you can do that in your ACPI tables.
>
> Can you still influence what goes to your ACPI tables, or are we
> talking about products that are already on the market?
>
>
> thanks,

Yes still it is in development phase so i can work out with BIOS team for the same. When you say description of connection ,something like this should be part of _DSD method right? (i.e from below dts
to _DSD of ACPI)

 usb_con: connector {
compatible = "usb-c-connector";
 label = "USB-C";
 data-role = "dual";
 power-role = "dual";
 try-power-role = "sink";
 source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
 sink-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)
 PDO_VAR(5000, 5000, 1000)>;
 op-sink-microwatt = <10000000>;
 };

regards

Nehal Shah

Re: ucsi and DRD controller interaction

[Heikki Krogerus]

On Wed, Apr 22, 2020 at 08:23:54PM +0530, Shah, Nehal-bakulchandra wrote:
> > Can you still influence what goes to your ACPI tables, or are we
> > talking about products that are already on the market?
> 
> Yes still it is in development phase so i can work out with BIOS team for the same. When you say description of connection ,something like this should be part of _DSD method right? (i.e from below dts
> to _DSD of ACPI)
> 
>  usb_con: connector {
> compatible = "usb-c-connector";
>  label = "USB-C";
>  data-role = "dual";
>  power-role = "dual";
>  try-power-role = "sink";
>  source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
>  sink-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)
>  PDO_VAR(5000, 5000, 1000)>;
>  op-sink-microwatt = <10000000>;
>  };

Here's how the ASL for the _DSD should look like. I don't know how
are all these components placed on your platform, so I'm just assuming
that your I2C host is under PCI0, as well as your DWC3 controller.
It's just an example, but hopefully you get the point from it:

/*
 * I2C1 is the I2C host, and PDC1 is the USB PD Controller (I2C slave device).
 */
Scope (\_SB.PCI0.I2C1.PDC1)
{
        /* Each connector should have its own ACPI device entry (node). */
        Device (CON0)
        {
                Name (_ADR, 0)

                Name (_DSD, Package () {
                    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                    Package() {
                        Package () {"usb-role-switch", \_SB.PCI0.DWC3},
                    }
                })
        }
}

So that property "usb-role-switch" has reference to the DWC3 node as
its value. That's what we are after here. If you have that property,
the subsystem will find the USB controller for you.

If you need for example the properties for the roles, then the _DSD
would look like this:

Name (_DSD, Package () {
    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
    Package() {
        Package () {"usb-role-switch", \_SB.PCI0.DWC3},
        Package () {"power-role", "dual"},
        Package () {"data-role", "dual"},
    }
})

and so on...


Thanks,

-- 
heikki

Re: ucsi and DRD controller interaction

[Shah, Nehal-bakulchandra]

Hi Heikki,

On 4/27/2020 5:30 PM, Heikki Krogerus wrote:
> On Wed, Apr 22, 2020 at 08:23:54PM +0530, Shah, Nehal-bakulchandra wrote:
>>> Can you still influence what goes to your ACPI tables, or are we
>>> talking about products that are already on the market?
>> Yes still it is in development phase so i can work out with BIOS team for the same. When you say description of connection ,something like this should be part of _DSD method right? (i.e from below dts
>> to _DSD of ACPI)
>>
>>  usb_con: connector {
>> compatible = "usb-c-connector";
>>  label = "USB-C";
>>  data-role = "dual";
>>  power-role = "dual";
>>  try-power-role = "sink";
>>  source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
>>  sink-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)
>>  PDO_VAR(5000, 5000, 1000)>;
>>  op-sink-microwatt = <10000000>;
>>  };
> Here's how the ASL for the _DSD should look like. I don't know how
> are all these components placed on your platform, so I'm just assuming
> that your I2C host is under PCI0, as well as your DWC3 controller.
> It's just an example, but hopefully you get the point from it:
>
> /*
>  * I2C1 is the I2C host, and PDC1 is the USB PD Controller (I2C slave device).
>  */
> Scope (\_SB.PCI0.I2C1.PDC1)
> {
>         /* Each connector should have its own ACPI device entry (node). */
>         Device (CON0)
>         {
>                 Name (_ADR, 0)
>
>                 Name (_DSD, Package () {
>                     ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>                     Package() {
>                         Package () {"usb-role-switch", \_SB.PCI0.DWC3},
>                     }
>                 })
>         }
> }
>
> So that property "usb-role-switch" has reference to the DWC3 node as
> its value. That's what we are after here. If you have that property,
> the subsystem will find the USB controller for you.
>
> If you need for example the properties for the roles, then the _DSD
> would look like this:
>
> Name (_DSD, Package () {
>     ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>     Package() {
>         Package () {"usb-role-switch", \_SB.PCI0.DWC3},
>         Package () {"power-role", "dual"},
>         Package () {"data-role", "dual"},
>     }
> })
>
> and so on...
>
>
> Thanks,

Thanks for the details so this will enable the role switch  for drd controller. Now for UCSI driver to call the role make functions it needs the reference of the same switch reference,

so for that do i have to use device_get_named_child_node(dev,"CON0"), in UCSI Driver?

Thanks

Nehal Shah

Re: ucsi and DRD controller interaction

[Heikki Krogerus]

On Mon, Apr 27, 2020 at 07:45:07PM +0530, Shah, Nehal-bakulchandra wrote:
> Hi Heikki,
> 
> On 4/27/2020 5:30 PM, Heikki Krogerus wrote:
> > On Wed, Apr 22, 2020 at 08:23:54PM +0530, Shah, Nehal-bakulchandra wrote:
> >>> Can you still influence what goes to your ACPI tables, or are we
> >>> talking about products that are already on the market?
> >> Yes still it is in development phase so i can work out with BIOS team for the same. When you say description of connection ,something like this should be part of _DSD method right? (i.e from below dts
> >> to _DSD of ACPI)
> >>
> >>  usb_con: connector {
> >> compatible = "usb-c-connector";
> >>  label = "USB-C";
> >>  data-role = "dual";
> >>  power-role = "dual";
> >>  try-power-role = "sink";
> >>  source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
> >>  sink-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)
> >>  PDO_VAR(5000, 5000, 1000)>;
> >>  op-sink-microwatt = <10000000>;
> >>  };
> > Here's how the ASL for the _DSD should look like. I don't know how
> > are all these components placed on your platform, so I'm just assuming
> > that your I2C host is under PCI0, as well as your DWC3 controller.
> > It's just an example, but hopefully you get the point from it:
> >
> > /*
> >  * I2C1 is the I2C host, and PDC1 is the USB PD Controller (I2C slave device).
> >  */
> > Scope (\_SB.PCI0.I2C1.PDC1)
> > {
> >         /* Each connector should have its own ACPI device entry (node). */
> >         Device (CON0)
> >         {
> >                 Name (_ADR, 0)
> >
> >                 Name (_DSD, Package () {
> >                     ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >                     Package() {
> >                         Package () {"usb-role-switch", \_SB.PCI0.DWC3},
> >                     }
> >                 })
> >         }
> > }
> >
> > So that property "usb-role-switch" has reference to the DWC3 node as
> > its value. That's what we are after here. If you have that property,
> > the subsystem will find the USB controller for you.
> >
> > If you need for example the properties for the roles, then the _DSD
> > would look like this:
> >
> > Name (_DSD, Package () {
> >     ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >     Package() {
> >         Package () {"usb-role-switch", \_SB.PCI0.DWC3},
> >         Package () {"power-role", "dual"},
> >         Package () {"data-role", "dual"},
> >     }
> > })
> >
> > and so on...
> >
> >
> > Thanks,
> 
> Thanks for the details so this will enable the role switch  for drd controller. Now for UCSI driver to call the role make functions it needs the reference of the same switch reference,
> 
> so for that do i have to use device_get_named_child_node(dev,"CON0"), in UCSI Driver?

No. If you use the ucsi driver, and if your connector child nodes are
in correct order, then ucsi_find_fwnode() takes care of assigning the
node for you.

But you do need to use the USB role class API to get a handle to the
switch (dwc3) in the typec driver.

UCSI is really meant to be a status interface. The specification
states that the USB Type-C connectors should function autonomously
without any OS involvement. So by relying on the driver to configure
the muxes, you are actually corrupting that part of the specification.

I would still strongly recommend that you use TI's own host interface.


Cheers,

-- 
heikki

Re: ucsi and DRD controller interaction

[Heikki Krogerus]

Hi again,

> > Thanks for the details so this will enable the role switch  for drd controller. Now for UCSI driver to call the role make functions it needs the reference of the same switch reference,
> > 
> > so for that do i have to use device_get_named_child_node(dev,"CON0"), in UCSI Driver?
> 
> No. If you use the ucsi driver, and if your connector child nodes are
> in correct order, then ucsi_find_fwnode() takes care of assigning the
> node for you.
> 
> But you do need to use the USB role class API to get a handle to the
> switch (dwc3) in the typec driver.
> 
> UCSI is really meant to be a status interface. The specification
> states that the USB Type-C connectors should function autonomously
> without any OS involvement. So by relying on the driver to configure
> the muxes, you are actually corrupting that part of the specification.

I had to recheck that. I seem to be wrong about this. It does not
clearly state that the ports need to function autonomously. Also, in
this case the USB role switch isn't a mux.

Sorry about that.

> I would still strongly recommend that you use TI's own host interface.

-- 
heikki

Re: ucsi and DRD controller interaction

[Shah, Nehal-bakulchandra]

Hi,

On 4/29/2020 6:33 PM, Heikki Krogerus wrote:
> Hi again,
>
>>> Thanks for the details so this will enable the role switch  for drd controller. Now for UCSI driver to call the role make functions it needs the reference of the same switch reference,
>>>
>>> so for that do i have to use device_get_named_child_node(dev,"CON0"), in UCSI Driver?
>> No. If you use the ucsi driver, and if your connector child nodes are
>> in correct order, then ucsi_find_fwnode() takes care of assigning the
>> node for you.
>>
>> But you do need to use the USB role class API to get a handle to the
>> switch (dwc3) in the typec driver.
>>
>> UCSI is really meant to be a status interface. The specification
>> states that the USB Type-C connectors should function autonomously
>> without any OS involvement. So by relying on the driver to configure
>> the muxes, you are actually corrupting that part of the specification.
> I had to recheck that. I seem to be wrong about this. It does not
> clearly state that the ports need to function autonomously. Also, in
> this case the USB role switch isn't a mux.
>
> Sorry about that.
>
>> I would still strongly recommend that you use TI's own host interface.

Thanks for the mail, in my view role switch is just software interface here to update the DWC3 controller for role change.

I may be wrong here but this is my understanding.

So on our platform PD is also connected as Master to USB/DP phy. Hence here is sequence as per my understanding during the role change.

1. PD detects the role change and update the phy register over I2C (as a i2c master)

2. PD also generated the interrupt to UCSI Driver (PD as a i2c slave) regarding the role change.

3. UCSI driver has to update same to DRD ( this is what we are all after that)

4. DRD will program controller register.

 I can implement /use TI's own host interface but requirement for us to have UCSI based driver.


Regards

Nehal