All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Cherian <george.cherian@ti.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
Cc: balbi@ti.com, myungjoo.ham@samsung.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, grant.likely@linaro.org,
	rob@landley.net, ian.campbell@citrix.com, swarren@wwwdotorg.org,
	mark.rutland@arm.com, pawel.moll@arm.com,
	rob.herring@calxeda.com, linux-omap@vger.kernel.org,
	linux-usb@vger.kernel.org, bcousson@baylibre.com,
	davidb@codeaurora.org, arnd@arndb.de, swarren@nvidia.com,
	popcornmix@gmail.com
Subject: Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Date: Thu, 29 Aug 2013 19:15:02 +0530	[thread overview]
Message-ID: <521F505E.8090607@ti.com> (raw)
In-Reply-To: <521F3AA2.9010707@samsung.com>

Hi Chanwoo,


On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
>>> I tested various development board based on Samsung Exynos series SoC.
>>> Although some gpio of Exynos series SoC set high state(non zero, 1) as default value,
>>> this gpio state could mean off state, disconnected or un-powered state according to gpio.
>>> Of course, above explanation about specific gpio don't include all gpios.
>>> This is meaning that there is possibility.
>> okay then how about adding a flag for inverted logic too.  something like this
>>
>> if(of_property_read_bool(np,"inverted_gpio))
>>      gpio_usbvid->gpio_inv = 1;
>> And always check on this before deciding?
Is this fine ?
>>
>>>>> Second,
>>>>> gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" cable state at same time
>>>>> in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think that other extcon devices
>>>>> would not control both "USB-HOST" and "USB" cable state at same time.
>>>>>
>>>>> Other extcon devices would support either "USB-HOST" or "USB" cable.
>>>> The driver has 2 configurations.
>>>> 1) supports implementations with both VBUS and ID pin are routed via gpio's for swicthing roles(compatible  gpio-usb-vid).
>>> As you explained about case 1, it is only used on dra7x SoC.
>> No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via gpio.
>>> Other SoC could not wish to control both "USB-HOST" and "USB" cable at same time.
I could'nt actually parse this. You meant since the id_irq_handler 
handles both USB and USB-HOST cable
its not proper?
> 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;
}
[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?
> 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?
>>> 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.
>

-- 
-George

WARNING: multiple messages have this Message-ID (diff)
From: George Cherian <george.cherian@ti.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
Cc: <balbi@ti.com>, <myungjoo.ham@samsung.com>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <grant.likely@linaro.org>,
	<rob@landley.net>, <ian.campbell@citrix.com>,
	<swarren@wwwdotorg.org>, <mark.rutland@arm.com>,
	<pawel.moll@arm.com>, <rob.herring@calxeda.com>,
	<linux-omap@vger.kernel.org>, <linux-usb@vger.kernel.org>,
	<bcousson@baylibre.com>, <davidb@codeaurora.org>, <arnd@arndb.de>,
	<swarren@nvidia.com>, <popcornmix@gmail.com>
Subject: Re: [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO
Date: Thu, 29 Aug 2013 19:15:02 +0530	[thread overview]
Message-ID: <521F505E.8090607@ti.com> (raw)
In-Reply-To: <521F3AA2.9010707@samsung.com>

Hi Chanwoo,


On 8/29/2013 5:42 PM, Chanwoo Choi wrote:
[big snip ]
>>> I tested various development board based on Samsung Exynos series SoC.
>>> Although some gpio of Exynos series SoC set high state(non zero, 1) as default value,
>>> this gpio state could mean off state, disconnected or un-powered state according to gpio.
>>> Of course, above explanation about specific gpio don't include all gpios.
>>> This is meaning that there is possibility.
>> okay then how about adding a flag for inverted logic too.  something like this
>>
>> if(of_property_read_bool(np,"inverted_gpio))
>>      gpio_usbvid->gpio_inv = 1;
>> And always check on this before deciding?
Is this fine ?
>>
>>>>> Second,
>>>>> gpio_usbvid_set_initial_state() dertermine both "USB-HOST" and "USB" cable state at same time
>>>>> in 'case ID_DETCT' according to 'gpio_usbvid->id_gpio'. But, I think that other extcon devices
>>>>> would not control both "USB-HOST" and "USB" cable state at same time.
>>>>>
>>>>> Other extcon devices would support either "USB-HOST" or "USB" cable.
>>>> The driver has 2 configurations.
>>>> 1) supports implementations with both VBUS and ID pin are routed via gpio's for swicthing roles(compatible  gpio-usb-vid).
>>> As you explained about case 1, it is only used on dra7x SoC.
>> No gpio-usb-id is used in dra7xx. dra7xx has got only ID pin routed via gpio.
>>> Other SoC could not wish to control both "USB-HOST" and "USB" cable at same time.
I could'nt actually parse this. You meant since the id_irq_handler 
handles both USB and USB-HOST cable
its not proper?
> 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;
}
[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?
> 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?
>>> 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.
>

-- 
-George


  reply	other threads:[~2013-08-29 13:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28 17:33 [PATCH v3 0/3] Add Generic USB VBUS/ID detection via GPIO using extcon George Cherian
2013-08-28 17:33 ` George Cherian
2013-08-28 17:33 ` [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO George Cherian
2013-08-28 17:33   ` George Cherian
2013-08-29  1:35   ` Chanwoo Choi
2013-08-29  2:21     ` George Cherian
2013-08-29  2:21       ` George Cherian
2013-08-29  6:23       ` Chanwoo Choi
2013-08-29  7:30         ` George Cherian
2013-08-29  7:30           ` George Cherian
2013-08-29 10:37           ` Chanwoo Choi
2013-08-29 11:48             ` George Cherian
2013-08-29 11:48               ` George Cherian
2013-08-29 12:12               ` Chanwoo Choi
2013-08-29 13:45                 ` George Cherian [this message]
2013-08-29 13:45                   ` George Cherian
2013-08-30  0:11                   ` Chanwoo Choi
2013-08-30  6:15                     ` George Cherian
2013-08-30  6:15                       ` George Cherian
2013-08-30  6:53                       ` Chanwoo Choi
2013-09-02  1:58                         ` George Cherian
2013-09-02  1:58                           ` George Cherian
2013-08-30  7:14                       ` Chanwoo Choi
2013-09-02  2:01                         ` George Cherian
2013-09-02  2:01                           ` George Cherian
2013-08-29 19:11               ` Stephen Warren
2013-08-29 19:19   ` Stephen Warren
     [not found] ` <1377711185-31238-1-git-send-email-george.cherian-l0cyMroinI0@public.gmane.org>
2013-08-28 17:33   ` [PATCH v3 2/3] drivers: Makefile: Extcon is a framework so bump it up George Cherian
2013-08-28 17:33     ` George Cherian
2013-08-28 17:33 ` [PATCH v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection George Cherian
2013-08-28 17:33   ` George Cherian
2013-08-28 17:54   ` Sergei Shtylyov
2013-08-29  2:53     ` George Cherian
2013-08-29  2:53       ` George Cherian
2013-08-29 19:21   ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=521F505E.8090607@ti.com \
    --to=george.cherian@ti.com \
    --cc=arnd@arndb.de \
    --cc=balbi@ti.com \
    --cc=bcousson@baylibre.com \
    --cc=cw00.choi@samsung.com \
    --cc=davidb@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=pawel.moll@arm.com \
    --cc=popcornmix@gmail.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.