I need your answer about above my opinion for other SoC.
So how about this, I have removed the dra7x specific stuffs (gpio-usb-id)
static void gpio_usbvid_set_initial_state(struct gpio_usbvid *gpio_usbvid)
{
int id_current, vbus_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (!!id_current == ID_FLOAT)
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", false);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", true);
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (!!vbus_current == VBUS_ON)
extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
}
and the irq handlers like this
static irqreturn_t id_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int id_current;
id_current = gpio_get_value_cansleep(gpio_usbvid->id_gpio);
if (id_current == ID_GND)
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", true);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB-HOST", false);
return IRQ_HANDLED;
}
static irqreturn_t vbus_irq_handler(int irq, void *data)
{
struct gpio_usbvid *gpio_usbvid = (struct gpio_usbvid *)data;
int vbus_current;
vbus_current = gpio_get_value_cansleep(gpio_usbvid->vbus_gpio);
if (vbus_current == VBUS_OFF)
extcon_set_cable_state(&gpio_usbvid->edev, "USB", false);
else
extcon_set_cable_state(&gpio_usbvid->edev, "USB", true);
return IRQ_HANDLED;
}
I know your intention dividing interrupt handler for each cable.
But I don't think this driver must guarantee all of extcon device using gpio.
For example,
below three SoC wish to detect USB/USB-HOST cable with each different methods.
"SoC A" wish to detect USB/USB-HOST cable through only one gpio pin.
You mean to say that both USB ID pin and VBUS are connected to same gpio?
If so that is a really bad h/w design and it will not fly.
Or, you meant that only USB ID pin is connected to single gpio and it controls the state of the USB/USB-HOST cables?
If so thats what exactly the v3 driver did with compatible gpio-usb-id.
"SoC B" wish to detect USB/USB-HOST cable through ADC value instead of gpio pin.
Via ADC this driver should never be used , it should be extcon-adc-usbvid driver and not extcon-gpio-usbvid driver.
"SoC C" wish to detect USB/USB-HOST cable through two gpio pin because USB connected on gpio an USB-HOST connected on another.
Whatever modifications above should meet this need in combination with named gpios (id_gpio and vbus_gpio in dt)as stephen pointed.
But still i feel the above modification would even support Soc A provided the code registered for the notifier could handle it properly.
In addition,
if "SoC A/C" wish to write some data to own specific registers for proper opeating,
Could we write some data to register on generic driver?
Yes definitely, those register configuration should not be part of this driver and it should be done in the notifier handler.
Finally,
"SoC D" wish to detect USB/USB-HOST/JIG cable through two gpio pin
Correct me If I am wrong, USB JIG is not a standard cable. so for supporting that anyways you need to have
a different driver.
- one gpio may detect either USB or USB-HOST and another may detect JIG cable
I assume u meant the USB ID pin is connected to one gpio and based on it value USB/USB-HOST is detected.
or one gpio may detect either USb or JIG and another may detect USB-HOST cable.
As I mentioned earlier these are gpios configured as input and if you try to drive with 2 sources (USB and JIG or USB and USB-HOST etc)
then its a potentially bad design . If at all we need to identify all 3 then there should be 3 dedicated gpios.
That way, there are many cases we cannot guarantee all of extcon devices.
I think this driver could support dra7x series SoC but as I mentioned,
this driver may not guarantee all of cases.
I am sorry, I feel it supports all standard cases except for something like a JIG cable which is not standard.
[snip]
I have some confusion. I need additional your explanation.
Could this driver register only one interrupt handler either id_irq_handler() or vbus_irq_handler()?
If compatible == ID_DETECT, only one handler --> id_irq_handler() and it will handle both USB and USB-HOST
or
Could this driver register two interrupt handler both id_irq_handler() or vbus_irq_handler()?
If compatible == VBUS_ID_DETECT, 2 handlers --> id_irq_handler() will handle USB-HOST and vbus_irq_handler will handle USB.
As you mentioned, we cannot only control either USB or USB-HOST cable on this extcon driver.
This extcon driver is only suitable dra7x SoC.
Do you still feel its dra7x specific if i modify it as above?
I commented above about your modification.
Because id_irq_handler() control both "USB-HOST" and "USB" cable at same time,
you need this setting order between "USB-HOST" and "USB" cable.
yes
I think that the setting order between cables isn't general. It is specific method for dra7x SoC.
So if i remove that part then?
The setting order should be removed in generic driver.
Yes I agree and should be done by the subscriber to the notifier.
Did you think that SoC should always connect either "USB-HOST" cable or "USB" cable?
No, even if a physical cable is not connected it should default to either USB-HOST or USB
It isn't general.
If physical cable isn't connected to extcon device, the state both USB-HOST and USB cable
should certainly be zero. Because The extcon consumer driver could set proper operation
according to cable state.
okay
I don't know this case except for dra7x SoC. So, I think it has dependency on specific SoC.
I need your answer about above my opinion.
Hope i could answer you :-)
and can't agree as generic extcon gpio driver.
Thanks,
Chanwoo Choi
