[RFC v4 0/7] extcon: usb-gpio: fixes and improvements

[Krzysztof Kozlowski]

Hi,


Some time ago, Robert tried to add VBUS detection to extcon-usb-gpio
driver [1]. There was a discussion about patch #2 ("extcon: usb-gpio:
add support for VBUS detection").

The final conclusion was that Chanwoo will add VBUS/ID notifiers [2].
That unfortunately never happened so this patchset is a follow up.

1. Add VBUS/ID cable state notifiers to extcon, so USB controllers
could use it.
2. Add VBUS detection to extcon-usb-gpio driver.

Some parts are based on old Robert's work, some are new, some are
reworked.


Best regards,
Krzysztof


[1] http://thread.gmane.org/gmane.linux.kernel/1923192/focus=1923193
[2] http://thread.gmane.org/gmane.linux.kernel/1923192/focus=1941152


Krzysztof Kozlowski (5):
Revert "extcon: usb-gpio: switch to use pm wakeirq apis"
extcon: Add raw VBUS and ID cable states
extcon: usb-gpio: Add support for VBUS detection
ARM: exynos_defconfig: Enable EXTCON_USB_GPIO for Odroid XU3 USB OTG
ARM: dts: exynos: Add extcon-usb-gpio node for Odroid XU3

Robert Baldyga (2):
Documentation: extcon: usb-gpio: update usb-gpio binding description
extcon: usb-gpio: make debounce value configurable in devicetree

.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 28 ++++-
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 21 ++++
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 21 ++++
arch/arm/configs/exynos_defconfig | 1 +
drivers/extcon/extcon-usb-gpio.c | 138 +++++++++++++++++----
drivers/extcon/extcon.c | 3 +
include/linux/extcon.h | 8 +-
7 files changed, 190 insertions(+), 30 deletions(-)

--
1.9.1

[Krzysztof Kozlowski]

The USB 3.0 OTG requires working extcon for reporting VBUS/ID changes.
This is provided by extcon-usb-gpio driver.

Signed-off-by: Krzysztof Kozlowski <k.koz...@samsung.com>
---
arch/arm/configs/exynos_defconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index daf9762ec794..755c4de94eca 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -219,6 +219,7 @@ CONFIG_COMMON_CLK_MAX77686=y
CONFIG_COMMON_CLK_MAX77802=y
CONFIG_COMMON_CLK_S2MPS11=y
CONFIG_EXTCON=y
+CONFIG_EXTCON_USB_GPIO=y
CONFIG_EXTCON_MAX14577=y
CONFIG_EXTCON_MAX77693=y
CONFIG_EXTCON_MAX8997=y
--
1.9.1

[Krzysztof Kozlowski]

From: Robert Baldyga <r.ba...@samsung.com>

Add information about VBUS pin detection support, 'debounce' property
and some other details.

Signed-off-by: Robert Baldyga <r.ba...@samsung.com>
Acked-by: Roger Quadros <rog...@ti.com>

Signed-off-by: Krzysztof Kozlowski <k.koz...@samsung.com>
---

.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 28 ++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
index af0b903de293..7096f399b771 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -1,16 +1,40 @@
USB GPIO Extcon device

-This is a virtual device used to generate USB cable states from the USB ID pin
-connected to a GPIO pin.
+This is a virtual device used to generate USB cable states from the USB
+ID and VBUS signals connected to GPIO pins.
+
+The extcon cable states USB and USB_HOST are actually VBUS and !ID
+pin states and do not indicate what mode the USB needs to operate in.
+That decision is done by the USB stack.
+
+Some devices have only one of these GPIO pins, so we support cases when
+only one of them is present. Hence properties 'id-gpio' and 'vbus-gpio'
+are described as optional, but at least one of them has to be present
+in extcon-usb-gpio node.
+
+In general we have three cases:
+1. If VBUS and ID gpios are present we pass them as is
+ USB-HOST = !ID, USB = VBUS
+2. If only VBUS gpio is present we assume that ID pin is always High.
+ USB-HOST = false, USB = VBUS.
+3. If only ID pin is available we infer the VBUS pin states based on ID.
+ USB-HOST = !ID, USB = ID

Required properties:
- compatible: Should be "linux,extcon-usb-gpio"
+
+Optional properties
- id-gpio: gpio for USB ID pin. See gpio binding.
+- vbus-gpio: gpio for USB VBUS pin. See gpio binding.
+- debounce: gpio debounce time in milliseconds (u32).
+

Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
extcon_usb1 {
compatible = "linux,extcon-usb-gpio";
id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+ vbus-gpio = <&gpio6 2 GPIO_ACTIVE_HIGH>;
+ debounce = <25>;
}

&omap_dwc3_1 {
--
1.9.1

[Krzysztof Kozlowski]

Hi,


On 06/09/2016 10:35 AM, Chanwoo Choi wrote:
> Hi,
>
> It is good to support USB_ID and USB_VBUS by extcon.
>
> But,
> there is some issue about adding the new cable type for
> both EXTCON_USB_ID and EXTCON_USB_VBUS
>
> I think that the ID and VBUS state are not cable type
> Instead, ID and VBUS state are the property of USB cable.
>
> So, I'd like to add the following function to support
> the property of each cable as following:
> The client driver can get the state of property by using
> the extcon_get_cable_property_state().
>
> - int extcon_get_cable_property_state(struct extcon_dev *edev,
> unsigned int id,
> enum extcon_property property);
> - int extcon_set_cable_property_state(struct extcon_dev *edev,
> unsigned int id,
> enum extcon_property property,
> unsigned int state);
>
> For example,
> In extcon-usb-gpio.c, set state of property as follwoing:
> extcon_set_cable_property_state(edev, EXTCON_USB, EXTCON_USB_PROP_ID, 1);
> extcon_set_cable_property_state(edev, EXTCON_USB, EXTCON_USB_PROP_VBUS, 1);
>
>
> In the extcon client driver, get state of property as following:
> id_state = extcon_get_cable_property_state(edev, EXTCON_USB, EXTCON_USB_PROP_ID);
> vbus_state = extcon_get_cable_property_state(edev, EXTCON_USB, EXTCON_USB_PROP_VUBS);

How one can receive notifications with this API?

Last time you wrote, at the end of discussion:
http://thread.gmane.org/gmane.linux.kernel/1923192/focus=1923193
> IMO, if some usb driver check both id and vbus pin at the same time,
> the usb driver can know the both id and vbus pin state through only
one notifier event.
>
> Also,
> If some usb driver want to know the state of id pin except of vbus state,
> when receiving following events, id pin is low.
> #define EXTCON_USB_ID_L_VBUS_L0
> #define EXTCON_USB_ID_L_VBUS_H1
> when receiving following events, id pin is high.
> #define EXTCON_USB_ID_H_VBUS_L2
> #define EXTCON_USB_ID_H_VBUS_H3
> Also, some usb driver would catch the vbus pin state with same method.
>
> But, it is just my opinion. We may use following notifier events for
each pin.
> We need to discuss it.
> #define EXTCON_USB_ID_LOW
> #define EXTCON_USB_ID_HIGH
> #define EXTCON_USB_VBUS_LOW
> #define EXTCON_USB_VBUS_HIGH

... all other participants agreed on that conclusion. So why change of
view point now?

Best regards,
Krzysztof

[Chanwoo Choi]

Regards,
Chanwoo Choi

[Chanwoo Choi]

Hi,

I think that the extcon don't support the notification only for property.
When USB or USB_HOST cable state is changed, the client driver
call the extcon_get_cable_property_state() to read the state of property.

Namely, the property depend on the specific external connector.

>
> Last time you wrote, at the end of discussion:
> http://thread.gmane.org/gmane.linux.kernel/1923192/focus=1923193
>> IMO, if some usb driver check both id and vbus pin at the same time,
>> the usb driver can know the both id and vbus pin state through only
> one notifier event.
>>
>> Also,
>> If some usb driver want to know the state of id pin except of vbus state,
>> when receiving following events, id pin is low.
>> #define EXTCON_USB_ID_L_VBUS_L0
>> #define EXTCON_USB_ID_L_VBUS_H1
>> when receiving following events, id pin is high.
>> #define EXTCON_USB_ID_H_VBUS_L2
>> #define EXTCON_USB_ID_H_VBUS_H3
>> Also, some usb driver would catch the vbus pin state with same method.
>>
>> But, it is just my opinion. We may use following notifier events for
> each pin.
>> We need to discuss it.
>> #define EXTCON_USB_ID_LOW
>> #define EXTCON_USB_ID_HIGH
>> #define EXTCON_USB_VBUS_LOW
>> #define EXTCON_USB_VBUS_HIGH
>
> ... all other participants agreed on that conclusion. So why change of
> view point now?

Unitl now, the extcon framework only handle the state of external connector(cable).
- The state of external connector is either attached or detached.

I think that ID and VBUS are not external connector(cable).
The ID and VBUS are more appropriate as property than new type of external connector.

Regards,
Chanwoo Choi

[Rob Herring]

On Wed, Jun 08, 2016 at 03:48:00PM +0200, Krzysztof Kozlowski wrote:
> From: Robert Baldyga <r.ba...@samsung.com>
>
> Add information about VBUS pin detection support, 'debounce' property
> and some other details.

The extcon bindings are a complete mess if you've seen my recent
comments. I'm inclined to NAK anything that amends broken bindings. This
one is headed in the right direction though...

> Signed-off-by: Robert Baldyga <r.ba...@samsung.com>
> Acked-by: Roger Quadros <rog...@ti.com>
> Signed-off-by: Krzysztof Kozlowski <k.koz...@samsung.com>
> ---
> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 28 ++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> index af0b903de293..7096f399b771 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -1,16 +1,40 @@
> USB GPIO Extcon device
>
> -This is a virtual device used to generate USB cable states from the USB ID pin
> -connected to a GPIO pin.
> +This is a virtual device used to generate USB cable states from the USB
> +ID and VBUS signals connected to GPIO pins.

It is not a virtual device, but a connector and connector states.

> +
> +The extcon cable states USB and USB_HOST are actually VBUS and !ID
> +pin states and do not indicate what mode the USB needs to operate in.
> +That decision is done by the USB stack.
> +
> +Some devices have only one of these GPIO pins, so we support cases when
> +only one of them is present. Hence properties 'id-gpio' and 'vbus-gpio'
> +are described as optional, but at least one of them has to be present
> +in extcon-usb-gpio node.
> +
> +In general we have three cases:
> +1. If VBUS and ID gpios are present we pass them as is
> + USB-HOST = !ID, USB = VBUS
> +2. If only VBUS gpio is present we assume that ID pin is always High.
> + USB-HOST = false, USB = VBUS.
> +3. If only ID pin is available we infer the VBUS pin states based on ID.
> + USB-HOST = !ID, USB = ID

USB and USB-HOST look like driver details. Shouldn't this just be in
terms of host and device?

>
> Required properties:
> - compatible: Should be "linux,extcon-usb-gpio"

I'd prefer to see this deprecated in favor of a string that defines the
type of connector (usb-a-connector, usb-microab-connector, etc.)

> +
> +Optional properties
> - id-gpio: gpio for USB ID pin. See gpio binding.
> +- vbus-gpio: gpio for USB VBUS pin. See gpio binding.

vbus-gpios

> +- debounce: gpio debounce time in milliseconds (u32).

debounce of which gpio? Needs a unit suffix.

[Tobias Jakobi]

Hello Krzysztof,

just wanted to ask on which kernel branch the patchset is based on. At
least for me the set doesn't apply cleanly to 4.7-rc4.

With best wishes,
Tobias

[Krzysztof Kozlowski]

On 06/26/2016 06:39 PM, Tobias Jakobi wrote:
> Hello Krzysztof,
>
> just wanted to ask on which kernel branch the patchset is based on. At
> least for me the set doesn't apply cleanly to 4.7-rc4.

Hi,

It was based on next-20160608.

Best regards,
Krzysztof

[Roger Quadros]

Hi,

Was there any conclusion on how we can support raw ID and VBUS events with extcon?

cheers,
-roger

[Chanwoo Choi]

Hi Roger,

The extcon will support the USB_ID and USB_VBUS as extcon property.
I'm sending the patches[1] for extcon property.

[1] https://lkml.org/lkml/2016/8/1/25
: [PATCH v2 0/6] extcon: Add the support for extcon type and property

Thanks,
Chanwoo Choi