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

2016-08-01 Thread Chanwoo Choi
Hi Roger,

2016-08-01 21:23 GMT+09:00 Roger Quadros :
> Hi,
>
> On 09/06/16 12:32, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016년 06월 09일 17:39, Krzysztof Kozlowski wrote:
>>>
>>> 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?
>>
>> 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.
>>
>
> Was there any conclusion on how we can support raw ID and VBUS events with 
> extcon?

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


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

2016-08-01 Thread Chanwoo Choi
Hi Roger,

2016-08-01 21:23 GMT+09:00 Roger Quadros :
> Hi,
>
> On 09/06/16 12:32, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016년 06월 09일 17:39, Krzysztof Kozlowski wrote:
>>>
>>> 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?
>>
>> 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.
>>
>
> Was there any conclusion on how we can support raw ID and VBUS events with 
> extcon?

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


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

2016-08-01 Thread Roger Quadros
Hi,

On 09/06/16 12:32, Chanwoo Choi wrote:
> Hi,
> 
> On 2016년 06월 09일 17:39, Krzysztof Kozlowski wrote:
>>
>> 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?
> 
> 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.
> 

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

cheers,
-roger


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

2016-08-01 Thread Roger Quadros
Hi,

On 09/06/16 12:32, Chanwoo Choi wrote:
> Hi,
> 
> On 2016년 06월 09일 17:39, Krzysztof Kozlowski wrote:
>>
>> 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?
> 
> 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.
> 

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

cheers,
-roger


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

2016-06-26 Thread 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



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

2016-06-26 Thread 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



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

2016-06-26 Thread 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 wrote:
> 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(-)
> 



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

2016-06-26 Thread 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 wrote:
> 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(-)
> 



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

2016-06-09 Thread Chanwoo Choi
Hi,

On 2016년 06월 09일 17:39, Krzysztof Kozlowski wrote:
> 
> 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?

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




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

2016-06-09 Thread Chanwoo Choi
Hi,

On 2016년 06월 09일 17:39, Krzysztof Kozlowski wrote:
> 
> 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?

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




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

2016-06-09 Thread 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


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

2016-06-09 Thread 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


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

2016-06-09 Thread Chanwoo Choi
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);

Regards,
Chanwoo Choi


On 2016년 06월 08일 22:47, Krzysztof Kozlowski wrote:
> 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(-)
> 



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

2016-06-09 Thread Chanwoo Choi
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);

Regards,
Chanwoo Choi


On 2016년 06월 08일 22:47, Krzysztof Kozlowski wrote:
> 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(-)
> 



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

2016-06-08 Thread 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



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

2016-06-08 Thread 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