QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
However it relies on usb-conn-gpio driver to read the vbus and id
gpio's and provide role switch. However the driver currently has
only gpio-b-connector compatible present in ID table. Adding that
in DT would mean that the device supports Type-B connector and not
Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
This series intends to add that compatible in driver and bindings
so that it can be used in QDU1000 IDP DT.
[1]: https://lore.kernel.org/all/[email protected]/
[2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
Krishna Kurapati (2):
dt-bindings: connector: Add gpio-usb-c-connector compatible
usb: common: usb-conn-gpio: Update ID table to add usb-c connector
Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
drivers/usb/common/usb-conn-gpio.c | 1 +
2 files changed, 4 insertions(+)
--
2.34.1
QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
However it relies on usb-conn-gpio driver to read the vbus and id
gpio's and provide role switch. However the driver currently has
only gpio-b-connector compatible present in ID table. Adding that
in DT would mean that the device supports Type-B connector and not
Type-c connector.
Add gpio-usb-c-connector compatible to the driver to support such
cases.
[1]: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Krishna Kurapati <[email protected]>
---
Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index fb216ce68bb3..2af27793c639 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -30,6 +30,9 @@ properties:
- const: samsung,usb-connector-11pin
- const: usb-b-connector
+ - items:
+ - const: gpio-usb-c-connector
+
reg:
maxItems: 1
--
2.34.1
Add gpio-usb-c-connector to Device ID compatible list to be used by
QDU1000 IDP.
Signed-off-by: Krishna Kurapati <[email protected]>
---
drivers/usb/common/usb-conn-gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/common/usb-conn-gpio.c b/drivers/usb/common/usb-conn-gpio.c
index 501e8bc9738e..37b5c5a8ccd0 100644
--- a/drivers/usb/common/usb-conn-gpio.c
+++ b/drivers/usb/common/usb-conn-gpio.c
@@ -334,6 +334,7 @@ static SIMPLE_DEV_PM_OPS(usb_conn_pm_ops,
static const struct of_device_id usb_conn_dt_match[] = {
{ .compatible = "gpio-usb-b-connector", },
+ { .compatible = "gpio-usb-c-connector", },
{ }
};
MODULE_DEVICE_TABLE(of, usb_conn_dt_match);
--
2.34.1
On Fri, 29 Mar 2024 at 09:20, Krishna Kurapati
<[email protected]> wrote:
>
> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
> However it relies on usb-conn-gpio driver to read the vbus and id
> gpio's and provide role switch. However the driver currently has
> only gpio-b-connector compatible present in ID table. Adding that
> in DT would mean that the device supports Type-B connector and not
> Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
USB-B connector is pretty simple, it really has just an ID pin and
VBUS input, which translates to two GPIOs being routed from the
_connector_ itself.
USB-C is much more complicated, it has two CC pins and a VBus power
pin. It is not enough just to measure CC pin levels. Moreover,
properly handling USB 3.0 inside a USB-C connector requires a separate
'orientation' signal to tell the host which two lanes must be used for
the USB SS signals. Thus it is no longer possible to route just two
pins from the connector to the SoC.
Having all that in mind, I suspect that you are not describing your
hardware properly. I suppose that you have a Type-C port controller /
redriver / switch, which handles CC lines communication and then
provides ID / VBUS signals to the host. In such a case, please
describe this TCPC in the DT file and use its compatible string
instead of "gpio-c-connector".
>
> This series intends to add that compatible in driver and bindings
> so that it can be used in QDU1000 IDP DT.
>
> [1]: https://lore.kernel.org/all/[email protected]/
> [2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
>
> Krishna Kurapati (2):
> dt-bindings: connector: Add gpio-usb-c-connector compatible
> usb: common: usb-conn-gpio: Update ID table to add usb-c connector
>
> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
> drivers/usb/common/usb-conn-gpio.c | 1 +
> 2 files changed, 4 insertions(+)
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
On Fri, Mar 29, 2024 at 12:49:47PM +0530, Krishna Kurapati wrote:
> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
> However it relies on usb-conn-gpio driver to read the vbus and id
> gpio's and provide role switch. However the driver currently has
> only gpio-b-connector compatible present in ID table. Adding that
> in DT would mean that the device supports Type-B connector and not
> Type-c connector.
>
> Add gpio-usb-c-connector compatible to the driver to support such
> cases.
This is not a driver. Bindings commit messages should talk about the
hardware they're supporting, not about drivers.
>
> [1]: https://lore.kernel.org/all/[email protected]/
>
> Signed-off-by: Krishna Kurapati <[email protected]>
> ---
> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index fb216ce68bb3..2af27793c639 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -30,6 +30,9 @@ properties:
> - const: samsung,usb-connector-11pin
> - const: usb-b-connector
>
> + - items:
> + - const: gpio-usb-c-connector
This is over complicated, just needs to be "- const: gpio-usb-c-connector"
Thanks,
Conor.
> +
> reg:
> maxItems: 1
>
> --
> 2.34.1
>
On 3/29/2024 6:23 PM, Dmitry Baryshkov wrote:
> On Fri, 29 Mar 2024 at 09:20, Krishna Kurapati
> <[email protected]> wrote:
>>
>> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
>> However it relies on usb-conn-gpio driver to read the vbus and id
>> gpio's and provide role switch. However the driver currently has
>> only gpio-b-connector compatible present in ID table. Adding that
>> in DT would mean that the device supports Type-B connector and not
>> Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
>
> USB-B connector is pretty simple, it really has just an ID pin and
> VBUS input, which translates to two GPIOs being routed from the
> _connector_ itself.
>
> USB-C is much more complicated, it has two CC pins and a VBus power
> pin. It is not enough just to measure CC pin levels. Moreover,
> properly handling USB 3.0 inside a USB-C connector requires a separate
> 'orientation' signal to tell the host which two lanes must be used for
> the USB SS signals. Thus it is no longer possible to route just two
> pins from the connector to the SoC.
>
> Having all that in mind, I suspect that you are not describing your
> hardware properly. I suppose that you have a Type-C port controller /
> redriver / switch, which handles CC lines communication and then
> provides ID / VBUS signals to the host. In such a case, please
> describe this TCPC in the DT file and use its compatible string
> instead of "gpio-c-connector".
>
Hi Dmitry,
My bad. I must have provided more details of the HW.
I presume you are referring to addition of a connector node, type-c
switch, pmic-glink and other remote endpoints like in other SoC's like
SM8450/ SM8550/ SM8650.
This HW is slightly different. It has a Uni Phy for Super speed and
hence no DP.
For orientation switching, on mobile SoC's, there is a provision for
orientation gpio given in pmic-glink node and is handled in ucsi_glink
driver. But on this version of HW, there is a USB-C Switch with its own
firmware taking care of orientation switching. It takes 8 SS Lines and 2
CC lines coming from connector as input and gives out 4 SS Lines (SS
TX1/TX2 RX1/RX2) as output which go to the SoC. So orientation switch is
done by the USB-C-switch in between and it automatically routes
appropriate active SS Lane from connector to the SoC.
As usual like in other targets, the DP and DM lines from type-c
connector go to the SoC directly.
To handle role switch, the VBUS and ID Pin connections are given to
SoC as well. There is a vbus controller regulator present to provide
vbus to connected peripherals in host mode.
There is no PPM entity (ADSP in mobile SoC's) and no UCSI involved
here. Hence we rely on usb-conn-gpio to read the vbus/id and switch
roles accordingly.
Hope this answers the query as to why we wanted to use usb-conn-gpio
and why we were trying to add a new compatible.
Regards,
Krishna,
>>
>> This series intends to add that compatible in driver and bindings
>> so that it can be used in QDU1000 IDP DT.
>>
>> [1]: https://lore.kernel.org/all/[email protected]/
>> [2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
>>
>> Krishna Kurapati (2):
>> dt-bindings: connector: Add gpio-usb-c-connector compatible
>> usb: common: usb-conn-gpio: Update ID table to add usb-c connector
>>
>> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
>> drivers/usb/common/usb-conn-gpio.c | 1 +
>> 2 files changed, 4 insertions(+)
>>
>> --
>> 2.34.1
>>
>
>
> --
> With best wishes
> Dmitry
On Sat, 30 Mar 2024 at 11:13, Krishna Kurapati PSSNV
<[email protected]> wrote:
> On 3/29/2024 6:23 PM, Dmitry Baryshkov wrote:
> > On Fri, 29 Mar 2024 at 09:20, Krishna Kurapati
> > <[email protected]> wrote:
> >>
> >> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
> >> However it relies on usb-conn-gpio driver to read the vbus and id
> >> gpio's and provide role switch. However the driver currently has
> >> only gpio-b-connector compatible present in ID table. Adding that
> >> in DT would mean that the device supports Type-B connector and not
> >> Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
> >
> > USB-B connector is pretty simple, it really has just an ID pin and
> > VBUS input, which translates to two GPIOs being routed from the
> > _connector_ itself.
> >
> > USB-C is much more complicated, it has two CC pins and a VBus power
> > pin. It is not enough just to measure CC pin levels. Moreover,
> > properly handling USB 3.0 inside a USB-C connector requires a separate
> > 'orientation' signal to tell the host which two lanes must be used for
> > the USB SS signals. Thus it is no longer possible to route just two
> > pins from the connector to the SoC.
> >
> > Having all that in mind, I suspect that you are not describing your
> > hardware properly. I suppose that you have a Type-C port controller /
> > redriver / switch, which handles CC lines communication and then
> > provides ID / VBUS signals to the host. In such a case, please
> > describe this TCPC in the DT file and use its compatible string
> > instead of "gpio-c-connector".
> >
>
> Hi Dmitry,
>
> My bad. I must have provided more details of the HW.
>
> I presume you are referring to addition of a connector node, type-c
> switch, pmic-glink and other remote endpoints like in other SoC's like
> SM8450/ SM8550/ SM8650.
>
> This HW is slightly different. It has a Uni Phy for Super speed and
> hence no DP.
This is fine and it's irrelevant for the USB-C.
> For orientation switching, on mobile SoC's, there is a provision for
> orientation gpio given in pmic-glink node and is handled in ucsi_glink
> driver. But on this version of HW, there is a USB-C Switch with its own
> firmware taking care of orientation switching. It takes 8 SS Lines and 2
> CC lines coming from connector as input and gives out 4 SS Lines (SS
> TX1/TX2 RX1/RX2) as output which go to the SoC. So orientation switch is
> done by the USB-C-switch in between and it automatically routes
> appropriate active SS Lane from connector to the SoC.
This is also fine. As I wrote, you _have_ the Type-C port controller.
So your DT file should be describing your hardware.
> As usual like in other targets, the DP and DM lines from type-c
> connector go to the SoC directly.
>
> To handle role switch, the VBUS and ID Pin connections are given to
> SoC as well. There is a vbus controller regulator present to provide
> vbus to connected peripherals in host mode.
>
> There is no PPM entity (ADSP in mobile SoC's) and no UCSI involved
> here. Hence we rely on usb-conn-gpio to read the vbus/id and switch
> roles accordingly.
This is also fine.
You confirmed my suspicions. You have an external Type-C switch which
handles orientation (and most likely PD or non-PD power negotiation)
for you. It has GPIO outputs, etc.
But it is not a part of the connector. Instead of adding the
"gpio-usb-c-connector", add proper compatible string (see, how this is
handled e.g. by the spidev - it is a generic driver, but it requires
hardware-specific compatibles).
Your hardware description should look like:
typec {
compatible = "your,switch";
id-gpios = <&gpio 1>;
vbus-gpios = <&gpio 2>;
vbus-supplies = <®-vbus>;
ports {
#address-cells = <1>;
#size-cells = <1>;
port@0 {
endpoint {
remote-endpoint = <&usb_dwc3_hs_out>;
};
};
port@1 {
endpoint {
remote-endpoint = <&usb_uni_phy_out>;
};
};
/* No SBU port */
};
};
Note, I haven't said anything regarding the driver. You can continue
using the usb-conn-gpio driver. Just add a compatible string for you
switch.
>
> Hope this answers the query as to why we wanted to use usb-conn-gpio
> and why we were trying to add a new compatible.
>
> Regards,
> Krishna,
>
> >>
> >> This series intends to add that compatible in driver and bindings
> >> so that it can be used in QDU1000 IDP DT.
> >>
> >> [1]: https://lore.kernel.org/all/[email protected]/
> >> [2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
> >>
> >> Krishna Kurapati (2):
> >> dt-bindings: connector: Add gpio-usb-c-connector compatible
> >> usb: common: usb-conn-gpio: Update ID table to add usb-c connector
> >>
> >> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
> >> drivers/usb/common/usb-conn-gpio.c | 1 +
> >> 2 files changed, 4 insertions(+)
> >>
> >> --
> >> 2.34.1
> >>
> >
> >
> > --
> > With best wishes
> > Dmitry
--
With best wishes
Dmitry
On 3/30/2024 7:09 PM, Dmitry Baryshkov wrote:
> On Sat, 30 Mar 2024 at 11:13, Krishna Kurapati PSSNV
> <[email protected]> wrote:
>> On 3/29/2024 6:23 PM, Dmitry Baryshkov wrote:
>>> On Fri, 29 Mar 2024 at 09:20, Krishna Kurapati
>>> <[email protected]> wrote:
>>>>
>>>> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
>>>> However it relies on usb-conn-gpio driver to read the vbus and id
>>>> gpio's and provide role switch. However the driver currently has
>>>> only gpio-b-connector compatible present in ID table. Adding that
>>>> in DT would mean that the device supports Type-B connector and not
>>>> Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
>>>
>>> USB-B connector is pretty simple, it really has just an ID pin and
>>> VBUS input, which translates to two GPIOs being routed from the
>>> _connector_ itself.
>>>
>>> USB-C is much more complicated, it has two CC pins and a VBus power
>>> pin. It is not enough just to measure CC pin levels. Moreover,
>>> properly handling USB 3.0 inside a USB-C connector requires a separate
>>> 'orientation' signal to tell the host which two lanes must be used for
>>> the USB SS signals. Thus it is no longer possible to route just two
>>> pins from the connector to the SoC.
>>>
>>> Having all that in mind, I suspect that you are not describing your
>>> hardware properly. I suppose that you have a Type-C port controller /
>>> redriver / switch, which handles CC lines communication and then
>>> provides ID / VBUS signals to the host. In such a case, please
>>> describe this TCPC in the DT file and use its compatible string
>>> instead of "gpio-c-connector".
>>>
>>
>> Hi Dmitry,
>>
>> My bad. I must have provided more details of the HW.
>>
>> I presume you are referring to addition of a connector node, type-c
>> switch, pmic-glink and other remote endpoints like in other SoC's like
>> SM8450/ SM8550/ SM8650.
>>
>> This HW is slightly different. It has a Uni Phy for Super speed and
>> hence no DP.
>
> This is fine and it's irrelevant for the USB-C.
>
>> For orientation switching, on mobile SoC's, there is a provision for
>> orientation gpio given in pmic-glink node and is handled in ucsi_glink
>> driver. But on this version of HW, there is a USB-C Switch with its own
>> firmware taking care of orientation switching. It takes 8 SS Lines and 2
>> CC lines coming from connector as input and gives out 4 SS Lines (SS
>> TX1/TX2 RX1/RX2) as output which go to the SoC. So orientation switch is
>> done by the USB-C-switch in between and it automatically routes
>> appropriate active SS Lane from connector to the SoC.
>
> This is also fine. As I wrote, you _have_ the Type-C port controller.
> So your DT file should be describing your hardware.
>
>> As usual like in other targets, the DP and DM lines from type-c
>> connector go to the SoC directly.
>>
>> To handle role switch, the VBUS and ID Pin connections are given to
>> SoC as well. There is a vbus controller regulator present to provide
>> vbus to connected peripherals in host mode.
>>
>> There is no PPM entity (ADSP in mobile SoC's) and no UCSI involved
>> here. Hence we rely on usb-conn-gpio to read the vbus/id and switch
>> roles accordingly.
>
> This is also fine.
>
> You confirmed my suspicions. You have an external Type-C switch which
> handles orientation (and most likely PD or non-PD power negotiation)
> for you. It has GPIO outputs, etc.
>
> But it is not a part of the connector. Instead of adding the
> "gpio-usb-c-connector", add proper compatible string (see, how this is
> handled e.g. by the spidev - it is a generic driver, but it requires
> hardware-specific compatibles).
> Your hardware description should look like:
>
> typec {
> compatible = "your,switch";
> id-gpios = <&gpio 1>;
> vbus-gpios = <&gpio 2>;
> vbus-supplies = <®-vbus>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <1>;
> port@0 {
> endpoint {
> remote-endpoint = <&usb_dwc3_hs_out>;
> };
> };
> port@1 {
> endpoint {
> remote-endpoint = <&usb_uni_phy_out>;
> };
> };
> /* No SBU port */
> };
> };
> > Note, I haven't said anything regarding the driver. You can continue
> using the usb-conn-gpio driver. Just add a compatible string for you
> switch.
>
Got it. So the "usb_conn_gpio: usb-conn-gpio" in [1] to be replaced
with something like a "typec- " naming convention and add a new
compatible to gpio-conn (something specific to qcom-qdu) and use it in
the new DT node.
Thanks for the suggestion. Is it fine if it put the whole of the above
text in v2 and push it for getting a new compatible added to connector
binding and usb-conn driver and then send v3 of DT changes or mix this
series with the DT series ?
[1]:
https://lore.kernel.org/all/[email protected]/
Thanks,
Krishna,
>>
>> Hope this answers the query as to why we wanted to use usb-conn-gpio
>> and why we were trying to add a new compatible.
>>
>> Regards,
>> Krishna,
>>
>>>>
>>>> This series intends to add that compatible in driver and bindings
>>>> so that it can be used in QDU1000 IDP DT.
>>>>
>>>> [1]: https://lore.kernel.org/all/[email protected]/
>>>> [2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
>>>>
>>>> Krishna Kurapati (2):
>>>> dt-bindings: connector: Add gpio-usb-c-connector compatible
>>>> usb: common: usb-conn-gpio: Update ID table to add usb-c connector
>>>>
>>>> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
>>>> drivers/usb/common/usb-conn-gpio.c | 1 +
>>>> 2 files changed, 4 insertions(+)
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>>
>>> --
>>> With best wishes
>>> Dmitry
>
>
>
On Sat, 30 Mar 2024 at 15:46, Krishna Kurapati PSSNV
<[email protected]> wrote:
>
>
>
> On 3/30/2024 7:09 PM, Dmitry Baryshkov wrote:
> > On Sat, 30 Mar 2024 at 11:13, Krishna Kurapati PSSNV
> > <[email protected]> wrote:
> >> On 3/29/2024 6:23 PM, Dmitry Baryshkov wrote:
> >>> On Fri, 29 Mar 2024 at 09:20, Krishna Kurapati
> >>> <[email protected]> wrote:
> >>>>
> >>>> QDU1000 IDP [1] has a Type-c connector and supports USB 3.0.
> >>>> However it relies on usb-conn-gpio driver to read the vbus and id
> >>>> gpio's and provide role switch. However the driver currently has
> >>>> only gpio-b-connector compatible present in ID table. Adding that
> >>>> in DT would mean that the device supports Type-B connector and not
> >>>> Type-c connector. Thanks to Dmitry Baryshkov for pointing it out [2].
> >>>
> >>> USB-B connector is pretty simple, it really has just an ID pin and
> >>> VBUS input, which translates to two GPIOs being routed from the
> >>> _connector_ itself.
> >>>
> >>> USB-C is much more complicated, it has two CC pins and a VBus power
> >>> pin. It is not enough just to measure CC pin levels. Moreover,
> >>> properly handling USB 3.0 inside a USB-C connector requires a separate
> >>> 'orientation' signal to tell the host which two lanes must be used for
> >>> the USB SS signals. Thus it is no longer possible to route just two
> >>> pins from the connector to the SoC.
> >>>
> >>> Having all that in mind, I suspect that you are not describing your
> >>> hardware properly. I suppose that you have a Type-C port controller /
> >>> redriver / switch, which handles CC lines communication and then
> >>> provides ID / VBUS signals to the host. In such a case, please
> >>> describe this TCPC in the DT file and use its compatible string
> >>> instead of "gpio-c-connector".
> >>>
> >>
> >> Hi Dmitry,
> >>
> >> My bad. I must have provided more details of the HW.
> >>
> >> I presume you are referring to addition of a connector node, type-c
> >> switch, pmic-glink and other remote endpoints like in other SoC's like
> >> SM8450/ SM8550/ SM8650.
> >>
> >> This HW is slightly different. It has a Uni Phy for Super speed and
> >> hence no DP.
> >
> > This is fine and it's irrelevant for the USB-C.
> >
> >> For orientation switching, on mobile SoC's, there is a provision for
> >> orientation gpio given in pmic-glink node and is handled in ucsi_glink
> >> driver. But on this version of HW, there is a USB-C Switch with its own
> >> firmware taking care of orientation switching. It takes 8 SS Lines and 2
> >> CC lines coming from connector as input and gives out 4 SS Lines (SS
> >> TX1/TX2 RX1/RX2) as output which go to the SoC. So orientation switch is
> >> done by the USB-C-switch in between and it automatically routes
> >> appropriate active SS Lane from connector to the SoC.
> >
> > This is also fine. As I wrote, you _have_ the Type-C port controller.
> > So your DT file should be describing your hardware.
> >
> >> As usual like in other targets, the DP and DM lines from type-c
> >> connector go to the SoC directly.
> >>
> >> To handle role switch, the VBUS and ID Pin connections are given to
> >> SoC as well. There is a vbus controller regulator present to provide
> >> vbus to connected peripherals in host mode.
> >>
> >> There is no PPM entity (ADSP in mobile SoC's) and no UCSI involved
> >> here. Hence we rely on usb-conn-gpio to read the vbus/id and switch
> >> roles accordingly.
> >
> > This is also fine.
> >
> > You confirmed my suspicions. You have an external Type-C switch which
> > handles orientation (and most likely PD or non-PD power negotiation)
> > for you. It has GPIO outputs, etc.
> >
> > But it is not a part of the connector. Instead of adding the
> > "gpio-usb-c-connector", add proper compatible string (see, how this is
> > handled e.g. by the spidev - it is a generic driver, but it requires
> > hardware-specific compatibles).
> > Your hardware description should look like:
> >
> > typec {
> > compatible = "your,switch";
> > id-gpios = <&gpio 1>;
> > vbus-gpios = <&gpio 2>;
> > vbus-supplies = <®-vbus>;
> >
> > ports {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > port@0 {
> > endpoint {
> > remote-endpoint = <&usb_dwc3_hs_out>;
> > };
> > };
> > port@1 {
> > endpoint {
> > remote-endpoint = <&usb_uni_phy_out>;
> > };
> > };
> > /* No SBU port */
> > };
> > };
> > > Note, I haven't said anything regarding the driver. You can continue
> > using the usb-conn-gpio driver. Just add a compatible string for you
> > switch.
> >
>
>
> Got it. So the "usb_conn_gpio: usb-conn-gpio" in [1] to be replaced
> with something like a "typec- " naming convention and add a new
> compatible to gpio-conn (something specific to qcom-qdu) and use it in
> the new DT node.
It should be the actual name of the switch chip.
>
> Thanks for the suggestion. Is it fine if it put the whole of the above
> text in v2 and push it for getting a new compatible added to connector
> binding and usb-conn driver and then send v3 of DT changes or mix this
> series with the DT series ?
I think USB subsystem maintainers prefer separate series.
>
> [1]:
> https://lore.kernel.org/all/[email protected]/
>
> Thanks,
> Krishna,
>
> >>
> >> Hope this answers the query as to why we wanted to use usb-conn-gpio
> >> and why we were trying to add a new compatible.
> >>
> >> Regards,
> >> Krishna,
> >>
> >>>>
> >>>> This series intends to add that compatible in driver and bindings
> >>>> so that it can be used in QDU1000 IDP DT.
> >>>>
> >>>> [1]: https://lore.kernel.org/all/[email protected]/
> >>>> [2]: https://lore.kernel.org/all/CAA8EJprXPvji8TgZu1idH7y4GtHtD4VmQABFBcRt-9BQaCberg@mail.gmail.com/
> >>>>
> >>>> Krishna Kurapati (2):
> >>>> dt-bindings: connector: Add gpio-usb-c-connector compatible
> >>>> usb: common: usb-conn-gpio: Update ID table to add usb-c connector
> >>>>
> >>>> Documentation/devicetree/bindings/connector/usb-connector.yaml | 3 +++
> >>>> drivers/usb/common/usb-conn-gpio.c | 1 +
> >>>> 2 files changed, 4 insertions(+)
> >>>>
> >>>> --
> >>>> 2.34.1
> >>>>
> >>>
> >>>
> >>> --
> >>> With best wishes
> >>> Dmitry
> >
> >
> >
--
With best wishes
Dmitry