* [PATCH 0/3] extcon: Add Type-C Virtual PD
@ 2020-09-04 19:18 Jagan Teki
2020-09-04 19:18 ` [PATCH 1/3] dt-bindings: extcon: Document Type-C Virtual PD driver Jagan Teki
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: Jagan Teki @ 2020-09-04 19:18 UTC (permalink / raw)
To: MyungJoo Ham, Chanwoo Choi, Rob Herring, Heiko Stuebner
Cc: Tom Cubie, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, linux-amarula, Jagan Teki
USB Type-C protocol supports various modes of operations
includes PD, USB3, and Altmode. If the platform design
supports a Type-C connector then configuring these modes
can be done via enumeration.
However, there are some platforms that design these modes
of operations as separate protocol connectors like design
Display Port from on-chip USB3 controller. So accessing
Type-C Altmode Display Port via onboard Display Port
connector instead of a Type-C connector.
These kinds of platforms require an explicit extcon driver
in order to handle Power Delivery and Port Detection.
This series support this Type-C Virtual PD and enable the
same in ROCK Pi 4C SBC.
Any inputs?
Jagan.
Jagan Teki (3):
dt-bindings: extcon: Document Type-C Virtual PD driver
extcon: Add Type-C Virtual PD driver
arm64: dts: rk3399-rock-pi-4c: Enable Display Port
.../extcon/extcon-usbc-virtual-pd.yaml | 66 ++++
MAINTAINERS | 6 +
.../boot/dts/rockchip/rk3399-rock-pi-4c.dts | 16 +
drivers/extcon/Kconfig | 10 +
drivers/extcon/Makefile | 1 +
drivers/extcon/extcon-usbc-virtual-pd.c | 285 ++++++++++++++++++
6 files changed, 384 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usbc-virtual-pd.yaml
create mode 100644 drivers/extcon/extcon-usbc-virtual-pd.c
--
2.25.1
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH 1/3] dt-bindings: extcon: Document Type-C Virtual PD driver 2020-09-04 19:18 [PATCH 0/3] extcon: Add Type-C Virtual PD Jagan Teki @ 2020-09-04 19:18 ` Jagan Teki 2020-09-04 19:18 ` [PATCH 2/3] extcon: Add " Jagan Teki ` (2 subsequent siblings) 3 siblings, 0 replies; 8+ messages in thread From: Jagan Teki @ 2020-09-04 19:18 UTC (permalink / raw) To: MyungJoo Ham, Chanwoo Choi, Rob Herring, Heiko Stuebner Cc: Tom Cubie, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, linux-amarula, Jagan Teki USB Type-C protocol supports various modes of operations includes PD, USB3, and Altmode. If the platform design supports a Type-C connector then configuring these modes can be done via enumeration. However, there are some platforms that design these modes of operations as separate protocol connectors like design Display Port from on-chip USB3 controller. So accessing Type-C Altmode Display Port via onboard Display Port connector instead of a Type-C connector. These kinds of platforms require an explicit extcon driver in order to handle Power Delivery and Port Detection. Document dt-bindings for it. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> --- .../extcon/extcon-usbc-virtual-pd.yaml | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usbc-virtual-pd.yaml diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-virtual-pd.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-virtual-pd.yaml new file mode 100644 index 000000000000..8110fbe2ddc2 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-virtual-pd.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/extcon-usbc-virtual-pd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Type-C Virtual PD extcon + +maintainers: + - Jagan Teki <jagan@amarulasolutions.com> + +description: | + USB Type-C protocol supports various modes of operations includes PD, + USB3, and Altmode. If the platform design supports a Type-C connector + then configuring these modes can be done via enumeration. + + However, there are some platforms that design these modes as separate + protocol connectors like design Display Port from on-chip USB3 controller. + So we can access Type-C Altmode Display Port via onboard Display Port + connector instead of a Type-C connector. These kinds of platforms require + an explicit extcon driver in order to handle Power Delivery and + Port Detection. + +properties: + compatible: + const: linux,extcon-usbc-virtual-pd + + det-gpios: + description: Detect GPIO pin. Pin can be Display Port Detect or USB ID. + maxItems: 1 + + vpd-polarity: + description: USB Type-C Polarity. false for Normal and true for Flip. + type: boolean + + vpd-super-speed: + description: USB Super Speed. false for USB2 and true for USB3. + type: boolean + + vpd-data-role: + description: USB Data roles for Virtual Type-C. + $ref: /schemas/types.yaml#definitions/string + + enum: + - host + - device + - display-port + +required: + - compatible + - det-gpios + - vpd-data-role + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/pinctrl/rockchip.h> + + virtual_pd: virtual-pd { + compatible = "linux,extcon-usbc-virtual-pd"; + det-gpios = <&gpio4 RK_PD1 GPIO_ACTIVE_LOW>; + vpd-data-role = "display-port"; + vpd-super-speed; + }; -- 2.25.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 2/3] extcon: Add Type-C Virtual PD driver 2020-09-04 19:18 [PATCH 0/3] extcon: Add Type-C Virtual PD Jagan Teki 2020-09-04 19:18 ` [PATCH 1/3] dt-bindings: extcon: Document Type-C Virtual PD driver Jagan Teki @ 2020-09-04 19:18 ` Jagan Teki 2020-09-04 19:18 ` [PATCH 3/3] arm64: dts: rk3399-rock-pi-4c: Enable Display Port Jagan Teki 2020-09-04 21:23 ` [PATCH 0/3] extcon: Add Type-C Virtual PD Heiko Stübner 3 siblings, 0 replies; 8+ messages in thread From: Jagan Teki @ 2020-09-04 19:18 UTC (permalink / raw) To: MyungJoo Ham, Chanwoo Choi, Rob Herring, Heiko Stuebner Cc: Tom Cubie, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, linux-amarula, Jagan Teki USB Type-C protocol supports various modes of operations includes PD, USB3, and Altmode. If the platform design supports a Type-C connector then configuring these modes can be done via enumeration. However, there are some platforms that design these modes of operations as separate protocol connectors like design Display Port from on-chip USB3 controller. So accessing Type-C Altmode Display Port via onboard Display Port connector instead of a Type-C connector. These kinds of platforms require an explicit extcon driver in order to handle Power Delivery and Port Detection. Add extcon driver for it. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> --- MAINTAINERS | 6 + drivers/extcon/Kconfig | 10 + drivers/extcon/Makefile | 1 + drivers/extcon/extcon-usbc-virtual-pd.c | 285 ++++++++++++++++++++++++ 4 files changed, 302 insertions(+) create mode 100644 drivers/extcon/extcon-usbc-virtual-pd.c diff --git a/MAINTAINERS b/MAINTAINERS index 68f21d46614c..aeb161b19dae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6466,6 +6466,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git F: Documentation/filesystems/ext4/ F: fs/ext4/ +EXTCON DRIVER FOR TYPE-C VIRTUAL PD +M: Jagan Teki <jagan@amarulasolutions.com> +S: Maintained +F: Documentation/devicetree/bindings/extcon/extcon-usbc-virtual-pd.yaml +F: drivers/extcon/extcon-usbc-virtual-pd.c + Extended Verification Module (EVM) M: Mimi Zohar <zohar@linux.ibm.com> L: linux-integrity@vger.kernel.org diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index aac507bff135..edd6c3c52699 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -186,4 +186,14 @@ config EXTCON_USBC_CROS_EC Say Y here to enable USB Type C cable detection extcon support when using Chrome OS EC based USB Type-C ports. +config EXTCON_USBC_VIRTUAL_PD + tristate "Virtual Type-C PD EXTCON support" + depends on GPIOLIB || COMPILE_TEST + help + Say Y here to enable Virtual Type-C PD extcon driver support, if + hardware platform designed Type-C modes separately. + + Example, of designing Display Port separately from Type-C Altmode + instead of accessing Altmode Display Port in Type-C connector. + endif diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile index 52096fd8a216..c35191eef0e1 100644 --- a/drivers/extcon/Makefile +++ b/drivers/extcon/Makefile @@ -25,3 +25,4 @@ obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o obj-$(CONFIG_EXTCON_USBC_CROS_EC) += extcon-usbc-cros-ec.o +obj-$(CONFIG_EXTCON_USBC_VIRTUAL_PD) += extcon-usbc-virtual-pd.o diff --git a/drivers/extcon/extcon-usbc-virtual-pd.c b/drivers/extcon/extcon-usbc-virtual-pd.c new file mode 100644 index 000000000000..e0713670e33d --- /dev/null +++ b/drivers/extcon/extcon-usbc-virtual-pd.c @@ -0,0 +1,285 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Type-C Virtual PD Extcon driver + * + * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd + * Copyright (c) 2019 Radxa Limited + * Copyright (c) 2019 Amarula Solutions(India) + */ + +#include <linux/extcon-provider.h> +#include <linux/gpio.h> +#include <linux/interrupt.h> +#include <linux/init.h> +#include <linux/irq.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of_gpio.h> +#include <linux/platform_device.h> +#include <linux/slab.h> + +static const unsigned int vpd_cable[] = { + EXTCON_USB, + EXTCON_USB_HOST, + EXTCON_DISP_DP, + EXTCON_NONE, +}; + +enum vpd_data_role { + DR_NONE, + DR_HOST, + DR_DEVICE, + DR_DISPLAY_PORT, +}; + +enum vpd_polarity { + POLARITY_NORMAL, + POLARITY_FLIP, +}; + +enum vpd_usb_ss { + USB_SS_USB2, + USB_SS_USB3, +}; + +struct vpd_extcon { + struct device *dev; + struct extcon_dev *extcon; + struct gpio_desc *det_gpio; + + u8 polarity; + u8 usb_ss; + enum vpd_data_role data_role; + + int irq; + bool enable_irq; + struct work_struct work; + struct delayed_work irq_work; +}; + +static void vpd_extcon_irq_work(struct work_struct *work) +{ + struct vpd_extcon *vpd = container_of(work, struct vpd_extcon, irq_work.work); + bool host_connected = false, device_connected = false, dp_connected = false; + union extcon_property_value property; + int det; + + det = vpd->det_gpio ? gpiod_get_raw_value(vpd->det_gpio) : 0; + if (det) { + device_connected = (vpd->data_role == DR_DEVICE) ? true : false; + host_connected = (vpd->data_role == DR_HOST) ? true : false; + dp_connected = (vpd->data_role == DR_DISPLAY_PORT) ? true : false; + } + + extcon_set_state(vpd->extcon, EXTCON_USB, host_connected); + extcon_set_state(vpd->extcon, EXTCON_USB_HOST, device_connected); + extcon_set_state(vpd->extcon, EXTCON_DISP_DP, dp_connected); + + property.intval = vpd->polarity; + extcon_set_property(vpd->extcon, EXTCON_USB, + EXTCON_PROP_USB_TYPEC_POLARITY, property); + extcon_set_property(vpd->extcon, EXTCON_USB_HOST, + EXTCON_PROP_USB_TYPEC_POLARITY, property); + extcon_set_property(vpd->extcon, EXTCON_DISP_DP, + EXTCON_PROP_USB_TYPEC_POLARITY, property); + + property.intval = vpd->usb_ss; + extcon_set_property(vpd->extcon, EXTCON_USB, + EXTCON_PROP_USB_SS, property); + extcon_set_property(vpd->extcon, EXTCON_USB_HOST, + EXTCON_PROP_USB_SS, property); + extcon_set_property(vpd->extcon, EXTCON_DISP_DP, + EXTCON_PROP_USB_SS, property); + + extcon_sync(vpd->extcon, EXTCON_USB); + extcon_sync(vpd->extcon, EXTCON_USB_HOST); + extcon_sync(vpd->extcon, EXTCON_DISP_DP); +} + +static irqreturn_t vpd_extcon_irq_handler(int irq, void *dev_id) +{ + struct vpd_extcon *vpd = dev_id; + + schedule_delayed_work(&vpd->irq_work, msecs_to_jiffies(10)); + + return IRQ_HANDLED; +} + +static enum vpd_data_role vpd_extcon_data_role(struct vpd_extcon *vpd) +{ + const char *const data_roles[] = { + [DR_NONE] = "NONE", + [DR_HOST] = "host", + [DR_DEVICE] = "device", + [DR_DISPLAY_PORT] = "display-port", + }; + struct device *dev = vpd->dev; + int ret; + const char *dr; + + ret = device_property_read_string(dev, "vpd-data-role", &dr); + if (ret < 0) + return DR_NONE; + + ret = match_string(data_roles, ARRAY_SIZE(data_roles), dr); + + return (ret < 0) ? DR_NONE : ret; +} + +static int vpd_extcon_parse_dts(struct vpd_extcon *vpd) +{ + struct device *dev = vpd->dev; + bool val = false; + int ret; + + val = device_property_read_bool(dev, "vpd-polarity"); + if (val) + vpd->polarity = POLARITY_FLIP; + else + vpd->polarity = POLARITY_NORMAL; + + val = device_property_read_bool(dev, "vpd-super-speed"); + if (val) + vpd->usb_ss = USB_SS_USB3; + else + vpd->usb_ss = USB_SS_USB2; + + vpd->data_role = vpd_extcon_data_role(vpd); + + vpd->det_gpio = devm_gpiod_get_optional(dev, "det", GPIOD_OUT_LOW); + if (IS_ERR(vpd->det_gpio)) { + ret = PTR_ERR(vpd->det_gpio); + dev_warn(dev, "failed to get det gpio: %d\n", ret); + return ret; + } + + vpd->irq = gpiod_to_irq(vpd->det_gpio); + if (vpd->irq < 0) { + dev_err(dev, "failed to get irq for gpio: %d\n", vpd->irq); + return vpd->irq; + } + + ret = devm_request_threaded_irq(dev, vpd->irq, NULL, + vpd_extcon_irq_handler, + IRQF_TRIGGER_FALLING | + IRQF_TRIGGER_RISING | IRQF_ONESHOT, + NULL, vpd); + if (ret) + dev_err(dev, "failed to request gpio irq\n"); + + return ret; +} + +static int vpd_extcon_probe(struct platform_device *pdev) +{ + struct vpd_extcon *vpd; + struct device *dev = &pdev->dev; + int ret; + + vpd = devm_kzalloc(dev, sizeof(*vpd), GFP_KERNEL); + if (!vpd) + return -ENOMEM; + + vpd->dev = dev; + ret = vpd_extcon_parse_dts(vpd); + if (ret) + return ret; + + INIT_DELAYED_WORK(&vpd->irq_work, vpd_extcon_irq_work); + + vpd->extcon = devm_extcon_dev_allocate(dev, vpd_cable); + if (IS_ERR(vpd->extcon)) { + dev_err(dev, "allocat extcon failed\n"); + return PTR_ERR(vpd->extcon); + } + + ret = devm_extcon_dev_register(dev, vpd->extcon); + if (ret) { + dev_err(dev, "register extcon failed: %d\n", ret); + return ret; + } + + extcon_set_property_capability(vpd->extcon, EXTCON_USB, + EXTCON_PROP_USB_VBUS); + extcon_set_property_capability(vpd->extcon, EXTCON_USB_HOST, + EXTCON_PROP_USB_VBUS); + + extcon_set_property_capability(vpd->extcon, EXTCON_USB, + EXTCON_PROP_USB_TYPEC_POLARITY); + extcon_set_property_capability(vpd->extcon, EXTCON_USB_HOST, + EXTCON_PROP_USB_TYPEC_POLARITY); + extcon_set_property_capability(vpd->extcon, EXTCON_USB, + EXTCON_PROP_USB_SS); + extcon_set_property_capability(vpd->extcon, EXTCON_USB_HOST, + EXTCON_PROP_USB_SS); + + extcon_set_property_capability(vpd->extcon, EXTCON_DISP_DP, + EXTCON_PROP_USB_SS); + extcon_set_property_capability(vpd->extcon, EXTCON_DISP_DP, + EXTCON_PROP_USB_TYPEC_POLARITY); + + platform_set_drvdata(pdev, vpd); + + vpd_extcon_irq_work(&vpd->irq_work.work); + + return 0; +} + +static int vpd_extcon_remove(struct platform_device *pdev) +{ + struct vpd_extcon *vpd = platform_get_drvdata(pdev); + + cancel_delayed_work_sync(&vpd->irq_work); + + return 0; +} + +#ifdef CONFIG_PM_SLEEP +static int vpd_extcon_suspend(struct device *dev) +{ + struct vpd_extcon *vpd = dev_get_drvdata(dev); + + if (!vpd->enable_irq) { + disable_irq_nosync(vpd->irq); + vpd->enable_irq = true; + } + + return 0; +} + +static int vpd_extcon_resume(struct device *dev) +{ + struct vpd_extcon *vpd = dev_get_drvdata(dev); + + if (vpd->enable_irq) { + enable_irq(vpd->irq); + vpd->enable_irq = false; + } + + return 0; +} +#endif + +static SIMPLE_DEV_PM_OPS(vpd_extcon_pm_ops, + vpd_extcon_suspend, vpd_extcon_resume); + +static const struct of_device_id vpd_extcon_dt_match[] = { + { .compatible = "linux,extcon-usbc-virtual-pd", }, + { /* sentinel */ } +}; + +static struct platform_driver vpd_extcon_driver = { + .probe = vpd_extcon_probe, + .remove = vpd_extcon_remove, + .driver = { + .name = "extcon-usbc-virtual-pd", + .pm = &vpd_extcon_pm_ops, + .of_match_table = vpd_extcon_dt_match, + }, +}; + +module_platform_driver(vpd_extcon_driver); + +MODULE_AUTHOR("Jagan Teki <jagan@amarulasolutions.com>"); +MODULE_DESCRIPTION("Type-C Virtual PD extcon driver"); +MODULE_LICENSE("GPL v2"); -- 2.25.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH 3/3] arm64: dts: rk3399-rock-pi-4c: Enable Display Port 2020-09-04 19:18 [PATCH 0/3] extcon: Add Type-C Virtual PD Jagan Teki 2020-09-04 19:18 ` [PATCH 1/3] dt-bindings: extcon: Document Type-C Virtual PD driver Jagan Teki 2020-09-04 19:18 ` [PATCH 2/3] extcon: Add " Jagan Teki @ 2020-09-04 19:18 ` Jagan Teki 2020-09-04 21:23 ` [PATCH 0/3] extcon: Add Type-C Virtual PD Heiko Stübner 3 siblings, 0 replies; 8+ messages in thread From: Jagan Teki @ 2020-09-04 19:18 UTC (permalink / raw) To: MyungJoo Ham, Chanwoo Choi, Rob Herring, Heiko Stuebner Cc: Tom Cubie, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, linux-amarula, Jagan Teki Enable Display Port on ROCK Pi 4C board. Unlike, other RK3399 platforms with accessing DP Altmode via Type-C connector, the display Port on ROCK Pi 4C is accessible via physical display port connector by means of Type-C Virtual PD extcon configuration. Enable support for it. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> --- .../boot/dts/rockchip/rk3399-rock-pi-4c.dts | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts index 4c7ebb1c5d2d..19a648add355 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts @@ -11,6 +11,22 @@ / { model = "Radxa ROCK Pi 4C"; compatible = "radxa,rockpi4c", "radxa,rockpi4", "rockchip,rk3399"; + + virtual_pd: virtual-pd { + compatible = "linux,extcon-usbc-virtual-pd"; + det-gpios = <&gpio4 RK_PD1 GPIO_ACTIVE_LOW>; /* DP_HPD */ + vpd-data-role = "display-port"; + vpd-super-speed; + }; +}; + +&cdn_dp { + extcon = <&virtual_pd>; + status = "okay"; +}; + +&tcphy0 { + extcon = <&virtual_pd>; }; &sdio0 { -- 2.25.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 0/3] extcon: Add Type-C Virtual PD 2020-09-04 19:18 [PATCH 0/3] extcon: Add Type-C Virtual PD Jagan Teki ` (2 preceding siblings ...) 2020-09-04 19:18 ` [PATCH 3/3] arm64: dts: rk3399-rock-pi-4c: Enable Display Port Jagan Teki @ 2020-09-04 21:23 ` Heiko Stübner 2020-09-09 13:56 ` Jagan Teki 2020-09-14 23:15 ` Rob Herring 3 siblings, 2 replies; 8+ messages in thread From: Heiko Stübner @ 2020-09-04 21:23 UTC (permalink / raw) To: MyungJoo Ham, Chanwoo Choi, Rob Herring, Jagan Teki Cc: Tom Cubie, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, linux-amarula, Jagan Teki Hi Jagan, Am Freitag, 4. September 2020, 21:18:27 CEST schrieb Jagan Teki: > USB Type-C protocol supports various modes of operations > includes PD, USB3, and Altmode. If the platform design > supports a Type-C connector then configuring these modes > can be done via enumeration. > > However, there are some platforms that design these modes > of operations as separate protocol connectors like design > Display Port from on-chip USB3 controller. So accessing > Type-C Altmode Display Port via onboard Display Port > connector instead of a Type-C connector. > > These kinds of platforms require an explicit extcon driver > in order to handle Power Delivery and Port Detection. > > This series support this Type-C Virtual PD and enable the > same in ROCK Pi 4C SBC. > > Any inputs? I tend to disagree on the design via an extcon. That the Rockchip rk3399 currently carries that extcon thingy is unfortunate and only works for ChromeOS devices based on the rk3399. The kernel now has a real type-c framework so we should not extend this extcon hack any further, because that will make it even harder to roll back later. Also simply because other Rockchip boards currently can't really make use of type-c due to this, as they use the fsusb302 phys directly connected. ChromeOS actually spend some time to make the cros-ec pd part of the type-c framework if I remember correctly, so a viable battle plan would be to: (1) move the Rockchip type-c phy driver to actually be part of the type-c framework, with the extcon being a deprecated fallback for old DTs. (2) implement your gpio-altmode as part of the type-c framework (which may even already exist) In short, please don't extend the rk3399 type-c extcon hack. Thanks Heiko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/3] extcon: Add Type-C Virtual PD 2020-09-04 21:23 ` [PATCH 0/3] extcon: Add Type-C Virtual PD Heiko Stübner @ 2020-09-09 13:56 ` Jagan Teki 2020-09-14 23:15 ` Rob Herring 1 sibling, 0 replies; 8+ messages in thread From: Jagan Teki @ 2020-09-09 13:56 UTC (permalink / raw) To: Heiko Stübner Cc: MyungJoo Ham, Chanwoo Choi, Rob Herring, Tom Cubie, devicetree, linux-arm-kernel, open list:ARM/Rockchip SoC..., linux-kernel, linux-amarula Hi Heiko, On Sat, Sep 5, 2020 at 2:53 AM Heiko Stübner <heiko@sntech.de> wrote: > > Hi Jagan, > > Am Freitag, 4. September 2020, 21:18:27 CEST schrieb Jagan Teki: > > USB Type-C protocol supports various modes of operations > > includes PD, USB3, and Altmode. If the platform design > > supports a Type-C connector then configuring these modes > > can be done via enumeration. > > > > However, there are some platforms that design these modes > > of operations as separate protocol connectors like design > > Display Port from on-chip USB3 controller. So accessing > > Type-C Altmode Display Port via onboard Display Port > > connector instead of a Type-C connector. > > > > These kinds of platforms require an explicit extcon driver > > in order to handle Power Delivery and Port Detection. > > > > This series support this Type-C Virtual PD and enable the > > same in ROCK Pi 4C SBC. > > > > Any inputs? > > I tend to disagree on the design via an extcon. Okay, are you disagree with the extcon extension for fusb chips routing or entire rk3399 designs? I totally agree with this point of bypassing extcon for the designs which has fusb302 chips. My only concern is about designs that don't have fusb chips - for example rock-pi-4. Designs that do have fusb302 chips, has dynamic possibilities to identify data roles, like detecting Altmode DP via Type-C connector whereas designs that don't have fusb302 or any type-c chip need static identification of data role, polarity, and ss for detecting direct DP port ie where virtual-pd is useful. Look like we have two potential issues of handling DP on rk3399 here, let me know if you think these non-type-c chips designs also possible to detect w/o extcon? Jagan. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/3] extcon: Add Type-C Virtual PD 2020-09-04 21:23 ` [PATCH 0/3] extcon: Add Type-C Virtual PD Heiko Stübner 2020-09-09 13:56 ` Jagan Teki @ 2020-09-14 23:15 ` Rob Herring 2020-09-15 1:17 ` Chanwoo Choi 1 sibling, 1 reply; 8+ messages in thread From: Rob Herring @ 2020-09-14 23:15 UTC (permalink / raw) To: Heiko Stübner, Jagan Teki Cc: MyungJoo Ham, Chanwoo Choi, Tom Cubie, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, linux-amarula On Fri, Sep 04, 2020 at 11:23:21PM +0200, Heiko Stübner wrote: > Hi Jagan, > > Am Freitag, 4. September 2020, 21:18:27 CEST schrieb Jagan Teki: > > USB Type-C protocol supports various modes of operations > > includes PD, USB3, and Altmode. If the platform design > > supports a Type-C connector then configuring these modes > > can be done via enumeration. > > > > However, there are some platforms that design these modes > > of operations as separate protocol connectors like design > > Display Port from on-chip USB3 controller. So accessing > > Type-C Altmode Display Port via onboard Display Port > > connector instead of a Type-C connector. > > > > These kinds of platforms require an explicit extcon driver > > in order to handle Power Delivery and Port Detection. > > > > This series support this Type-C Virtual PD and enable the > > same in ROCK Pi 4C SBC. > > > > Any inputs? > > I tend to disagree on the design via an extcon. I don't accept new extcon bindings or users of it either. It's a poorly thought out collection of Linux driver properties. Use the usb connector binding. > > That the Rockchip rk3399 currently carries that extcon thingy is unfortunate > and only works for ChromeOS devices based on the rk3399. > > The kernel now has a real type-c framework so we should not extend this > extcon hack any further, because that will make it even harder to roll back > later. Also simply because other Rockchip boards currently can't really make > use of type-c due to this, as they use the fsusb302 phys directly connected. > > ChromeOS actually spend some time to make the cros-ec pd part of the type-c > framework if I remember correctly, so a viable battle plan would be to: > > (1) move the Rockchip type-c phy driver to actually be part of the type-c > framework, with the extcon being a deprecated fallback for old DTs. > (2) implement your gpio-altmode as part of the type-c framework > (which may even already exist) > > > In short, please don't extend the rk3399 type-c extcon hack. > > Thanks > Heiko > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 0/3] extcon: Add Type-C Virtual PD 2020-09-14 23:15 ` Rob Herring @ 2020-09-15 1:17 ` Chanwoo Choi 0 siblings, 0 replies; 8+ messages in thread From: Chanwoo Choi @ 2020-09-15 1:17 UTC (permalink / raw) To: Rob Herring, Heiko Stübner, Jagan Teki Cc: MyungJoo Ham, Tom Cubie, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel, linux-amarula Hi Rob, On 9/15/20 8:15 AM, Rob Herring wrote: > On Fri, Sep 04, 2020 at 11:23:21PM +0200, Heiko Stübner wrote: >> Hi Jagan, >> >> Am Freitag, 4. September 2020, 21:18:27 CEST schrieb Jagan Teki: >>> USB Type-C protocol supports various modes of operations >>> includes PD, USB3, and Altmode. If the platform design >>> supports a Type-C connector then configuring these modes >>> can be done via enumeration. >>> >>> However, there are some platforms that design these modes >>> of operations as separate protocol connectors like design >>> Display Port from on-chip USB3 controller. So accessing >>> Type-C Altmode Display Port via onboard Display Port >>> connector instead of a Type-C connector. >>> >>> These kinds of platforms require an explicit extcon driver >>> in order to handle Power Delivery and Port Detection. >>> >>> This series support this Type-C Virtual PD and enable the >>> same in ROCK Pi 4C SBC. >>> >>> Any inputs? >> >> I tend to disagree on the design via an extcon. > > I don't accept new extcon bindings or users of it either. It's a > poorly thought out collection of Linux driver properties. Use the usb > connector binding. I agree the prior binding format of extcon with 'extcon' property name is not proper. So, I'll try to bind new style. But, I have a question. Do you have the objection of the use of extcon like 'users of it either' of your comment? > >> >> That the Rockchip rk3399 currently carries that extcon thingy is unfortunate >> and only works for ChromeOS devices based on the rk3399. >> >> The kernel now has a real type-c framework so we should not extend this >> extcon hack any further, because that will make it even harder to roll back >> later. Also simply because other Rockchip boards currently can't really make >> use of type-c due to this, as they use the fsusb302 phys directly connected. >> >> ChromeOS actually spend some time to make the cros-ec pd part of the type-c >> framework if I remember correctly, so a viable battle plan would be to: >> >> (1) move the Rockchip type-c phy driver to actually be part of the type-c >> framework, with the extcon being a deprecated fallback for old DTs. >> (2) implement your gpio-altmode as part of the type-c framework >> (which may even already exist) >> >> >> In short, please don't extend the rk3399 type-c extcon hack. >> >> Thanks >> Heiko >> >> >> >> > > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-09-15 1:05 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-04 19:18 [PATCH 0/3] extcon: Add Type-C Virtual PD Jagan Teki 2020-09-04 19:18 ` [PATCH 1/3] dt-bindings: extcon: Document Type-C Virtual PD driver Jagan Teki 2020-09-04 19:18 ` [PATCH 2/3] extcon: Add " Jagan Teki 2020-09-04 19:18 ` [PATCH 3/3] arm64: dts: rk3399-rock-pi-4c: Enable Display Port Jagan Teki 2020-09-04 21:23 ` [PATCH 0/3] extcon: Add Type-C Virtual PD Heiko Stübner 2020-09-09 13:56 ` Jagan Teki 2020-09-14 23:15 ` Rob Herring 2020-09-15 1:17 ` Chanwoo Choi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).