extcon : callback function to read cable property

Quoted 10 lines

Subject: Re: [PATCH] extcon : callback function to read cable property

On 10/19/2012 12:13 PM, Tc, Jenny wrote:
The rold of extcon inform only attached/detached state of extcon consumer driver from extcon provider driver. After extcon consumer driver detect the state of cable through extcon, extcon consumer driver or framework should get the additional information of cable from other device driver except of extcon.

Quoted 4 lines

Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG- USB-OFF, Dock) What are common properties among many cables expect attached or detached state?

For charger cable the current each cable can provide will be common. But may not be relevant for other cables.

I understand your point on extcon role. But my concern is, when the consumer driver gets a notification on cable state change, how does the consumer query the cable properties in a generic way. Do you have any suggestions for this?

A use case can be as below

When a USB host cable (SDP) connected to the platform, without USB enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging spec). Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver need to configure the charger chip, it need to know the charger cable capabilities. For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver OTG1. But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How
CHGR1 driver can detect the cable properties without having any platform layer hooks? The platform layer hooks (using platform data)will work only if the consumer is a platform driver. What if it's a framework which will have the same flow in all platforms?

Subject: Re: RE: [PATCH] extcon : callback function to read cable property

Quoted 6 lines

For charger cable the current each cable can provide will be common. But may not be relevant for other cables.

I understand your point on extcon role. But my concern is, when the consumer driver gets a notification on cable state change, how does the consumer query the cable properties in a generic way. Do you have any

suggestions for this?

Quoted 5 lines

A use case can be as below

When a USB host cable (SDP) connected to the platform, without USB enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As

per USB charging spec).

Quoted 2 lines

Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver need to configure the charger chip, it need to know the

charger cable capabilities.

Quoted 1 line

For example a platform PLAT1 may have charger driver CHRGR1 and OTG

driver OTG1.

Quoted 4 lines

But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How CHGR1 driver can detect the cable properties without having any platform layer hooks? The platform layer hooks (using platform data)will work only if the consumer is a platform driver. What if it's a

framework which will have the same flow in all platforms?

In general,
an extcon user (extcon notifee) knows who's the extcon notifier; the user is supposed to know the name of the notifier.

Thus, the extcon user should be able to get the appropriate object; i.e., a regulator struct in this case. Then, according to the USB state, the current limit of the USB can be changed by the notifier; which may notify (regulator subsystem has one) the extcon user to react (change current limit of charger?)

Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator controlling the charger current and if the OTG2 regulator affects the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the consumer- supplier chain should be setup (if the BSP is ideal).

OR

If it is impossible to have any objects of OTG2 (looks strange, but..), you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB), where Fast-charger.04 is enabled when USB2 enumeration is done with 5

However, the following callback might be considered if there are cases where an extcon user has information of extcon_name and cable_name while the user CANNOT get any information on which device or object is related with the specific cable; in struct extcon, with optional user initializing data section:

(quoted diff) +1 -0

+	struct device **cable_device;

OR

(quoted diff) +1 -0

+	char **cable_device_name;

With any relevant changes in the status with cable_device, we may notify any notifier-block that are interested in the specific cable. Then, the notifier- block (for register_interest) is going to handle extcon-state changes and cable_device notifications.

Currently, the user's nb is for cable attach/detach events with true/false value in the place of 32bit value (val). However, if we add the third possible value for that parameter
(0: cable detached, 1: cable attached, 2: cable status changed; go find out what's going on), it is still compatible.

I considered using a void pointer instead of cable_device, too. However, that would spoil the subsystem too much; we'll be creating a total
chaos: "USB-A driver uses struct regulator", "USB-B driver uses struct device", "USB-C driver uses true/false", and so on.

-----Original Message-----
From: Tc, Jenny
Sent: Thursday, October 25, 2012 2:55 PM
To: [email protected]; ???
Cc: [email protected]; anish kumar
Subject: RE: RE: [PATCH] extcon : callback function to read cable property

Quoted 34 lines

Subject: Re: RE: [PATCH] extcon : callback function to read cable property

Quoted 7 lines

For charger cable the current each cable can provide will be common. But may not be relevant for other cables.

I understand your point on extcon role. But my concern is, when the consumer driver gets a notification on cable state change, how does the consumer query the cable properties in a generic way. Do you have any

suggestions for this?

Quoted 6 lines

A use case can be as below

When a USB host cable (SDP) connected to the platform, without USB enumeration it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As

per USB charging spec).

Quoted 3 lines

Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver need to configure the charger chip, it need to know the

charger cable capabilities.

Quoted 1 line

For example a platform PLAT1 may have charger driver CHRGR1 and OTG

driver OTG1.

Quoted 5 lines

But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How CHGR1 driver can detect the cable properties without having any platform layer hooks? The platform layer hooks (using platform data)will work only if the consumer is a platform driver. What if it's a

framework which will have the same flow in all platforms?

In general,
an extcon user (extcon notifee) knows who's the extcon notifier; the user is supposed to know the name of the notifier.

Quoted 6 lines

Thus, the extcon user should be able to get the appropriate object; i.e., a regulator struct in this case. Then, according to the USB state, the current limit of the USB can be changed by the notifier; which may notify (regulator subsystem has one) the extcon user to react (change current limit of
charger?)

The flow we have is "notifier (OTG driver/cable notifier driver) -> extcon-> charging framework->charger driver"

When the framework gets notification from the extcon, it just know cable is connected/disconnected

For a USB charging the state machine can be

For USB2.0
1) CONNECT (100mA)->UPDATE(500mA)->DISCONNECT(0mA) 2)CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)-

Quoted 1 line

DISCONNECT(0mA)

3) CONNECT (100mA)->UPDATE(500mA)->HOST SUSPEND(2.5mA/500mA)-

Quoted 1 line

HOST RESUME(500mA)->DISCONNECT(0mA)

For USB 3.0
4) CONNECT (150mA)->UPDATE(900mA)->DISCONNECT(0mA)
5) CONNECT (150mA)->UPDATE(900mA)-> HOST SUSPEND(2.5mA/900mA)-

Quoted 1 line

DISCONNECT(0mA)

6) CONNECT (100mA)->UPDATE(900mA)->HOST SUSPEND(2.5mA/900mA)-

Quoted 8 lines

HOST RESUME(900mA)->DISCONNECT(0mA)

Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator controlling the charger current and if the OTG2 regulator affects the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg) the consumer- supplier chain should be setup (if the BSP is ideal).

Quoted 5 lines

OR

If it is impossible to have any objects of OTG2 (looks strange, but..), you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB), where Fast-charger.04 is enabled when USB2

enumeration

Quoted 1 line

is done with 5

I got your point. It's not just 2 cables we may need 4 cables to support USB2.0 and USB3.0 since the charge current can be 100/500 for USB2.0 and 150/900 for USB 3.0. But what about the states?

.

Quoted 24 lines

However, the following callback might be considered if there are cases where an extcon user has information of extcon_name and cable_name while the user CANNOT get any information on which device or object is related with the specific cable; in struct extcon, with optional user initializing data section:

(quoted diff) +1 -0

+	struct device **cable_device;

OR

(quoted diff) +1 -0

+	char **cable_device_name;

With any relevant changes in the status with cable_device, we may notify any notifier-block that are interested in the specific cable. Then, the notifier- block (for register_interest) is going to handle extcon-state changes and cable_device notifications.

Currently, the user's nb is for cable attach/detach events with true/false value in the place of 32bit value (val). However, if we add the third possible value for that parameter
(0: cable detached, 1: cable attached, 2: cable status changed; go find out what's going on), it is still compatible.

Quoted 5 lines

I considered using a void pointer instead of cable_device, too. However, that would spoil the subsystem too much; we'll be creating a total
chaos: "USB-A driver uses struct regulator", "USB-B driver uses struct device", "USB-C driver uses true/false", and so on.

But just by getting the device instance how do we extract the cable properties like cable state and the charge current in a generic way?