devicetree.vger.kernel.org archive mirror
 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

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

Thread overview: 23+ 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 ` [PATCH v3 1/3] extcon: extcon-gpio-usbvid: Generic USB VBUS/ID detection via GPIO George Cherian
2013-08-29  1:35   ` Chanwoo Choi
2013-08-29  2:21     ` George Cherian
2013-08-29  6:23       ` Chanwoo Choi
2013-08-29  7:30         ` George Cherian
2013-08-29 10:37           ` Chanwoo Choi
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-30  0:11                   ` Chanwoo Choi
2013-08-30  6:15                     ` George Cherian
2013-08-30  6:53                       ` Chanwoo Choi
2013-09-02  1:58                         ` George Cherian
2013-08-30  7:14                       ` Chanwoo Choi
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 ` [PATCH v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection George Cherian
2013-08-28 17:54   ` Sergei Shtylyov
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).