All of lore.kernel.org
 help / color / mirror / Atom feed
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/4] phy: add phy-hi6220-usb
Date: Fri, 20 Feb 2015 10:06:10 -0600	[thread overview]
Message-ID: <20150220160610.GB6430@saruman.tx.rr.com> (raw)
In-Reply-To: <54E75665.6050205@linaro.org>

Hi,

On Fri, Feb 20, 2015 at 11:44:37PM +0800, zhangfei wrote:
> Hi, Balbi
> 
> On 02/20/2015 10:41 PM, Felipe Balbi wrote:
> 
> >>+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> >>+{
> >>+	struct usb_otg *otg = priv->phy.otg;
> >>+
> >>+	if (!otg->gadget)
> >>+		return;
> >>+
> >>+	if (on)
> >>+		usb_gadget_connect(otg->gadget);
> >>+	else
> >>+		usb_gadget_disconnect(otg->gadget);
> >
> >why is the PHY fiddling with pullups ?
> 
> We use this to enable/disable otg gadget mode.

I got that, but the pullups don't belong to the PHY, they belong to the
gadget.

> The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> host mode.
> When micro usb or otg device attached to otg, gpio_vbus falling down.
> And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.

all of that I understood clearly :-)

> So when micro usb attached, we enable gadget mode; while micro usb
> detached, we disable gadget mode, and dwc2 will automatically set to
> host mode.

that's all fine, I'm concerned about letting the PHY fiddle with
something it doesn't own. If I am to change pullups rules in udc-core,
this is likely to break down miserably and I don't want to have to go
through that.

> >>+static void hi6220_detect_work(struct work_struct *work)
> >>+{
> >>+	struct hi6220_priv *priv =
> >>+		container_of(work, struct hi6220_priv, work.work);
> >>+	int gpio_id, gpio_vbus;
> >>+	enum usb_otg_state state;
> >>+
> >>+	if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
> >>+		return;
> >>+
> >>+	gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> >>+	gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >
> >looks like this should be using extcon
> Not used extcon before.
> However, we need gpio_vbus interrupt.
> Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> interrupt.
> Will investigate tomorrow.

drivers/extcon/extcon-gpio.c

> >>+	if (gpio_vbus == 0) {
> >>+		if (gpio_id == 1)
> >>+			state = OTG_STATE_B_PERIPHERAL;
> >>+		else
> >>+			state = OTG_STATE_A_HOST;
> >>+	} else {
> >>+		state = OTG_STATE_A_HOST;
> >>+	}
> >>+
> >>+	if (priv->state != state) {
> >>+		hi6220_start_peripheral(priv, state == OTG_STATE_B_PERIPHERAL);
> >>+		priv->state = state;
> >>+	}
> >>+}
> >>+
> >>+static irqreturn_t hiusb_gpio_intr(int irq, void *data)
> >>+{
> >>+	struct hi6220_priv *priv = (struct hi6220_priv *)data;
> >>+
> >>+	/* add debounce time */
> >>+	schedule_delayed_work(&priv->work, msecs_to_jiffies(100));
> >
> >this is really bad. We have threaded interrupt support, right ?
> 
> Since we use two gpio to distinguish gadget mode or host mode.
> Debounce time can introduce more accuracy.

gpio_set_debounce() ?

> I think threaded interrupt can not be used for adding debounce time.
> Here add debounce is just for safety.

add the debounce to the gpio itself.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150220/355bfe35/attachment-0001.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: zhangfei <zhangfei.gao@linaro.org>
Cc: balbi@ti.com, Kishon Vijay Abraham I <kishon@ti.com>,
	mark.rutland@arm.com, Peter Chen <peter.chen@freescale.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	"dan . zhao" <dan.zhao@hisilicon.com>,
	Wangbinghui <wangbinghui@hisilicon.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH v4 4/4] phy: add phy-hi6220-usb
Date: Fri, 20 Feb 2015 10:06:10 -0600	[thread overview]
Message-ID: <20150220160610.GB6430@saruman.tx.rr.com> (raw)
In-Reply-To: <54E75665.6050205@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]

Hi,

On Fri, Feb 20, 2015 at 11:44:37PM +0800, zhangfei wrote:
> Hi, Balbi
> 
> On 02/20/2015 10:41 PM, Felipe Balbi wrote:
> 
> >>+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> >>+{
> >>+	struct usb_otg *otg = priv->phy.otg;
> >>+
> >>+	if (!otg->gadget)
> >>+		return;
> >>+
> >>+	if (on)
> >>+		usb_gadget_connect(otg->gadget);
> >>+	else
> >>+		usb_gadget_disconnect(otg->gadget);
> >
> >why is the PHY fiddling with pullups ?
> 
> We use this to enable/disable otg gadget mode.

I got that, but the pullups don't belong to the PHY, they belong to the
gadget.

> The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> host mode.
> When micro usb or otg device attached to otg, gpio_vbus falling down.
> And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.

all of that I understood clearly :-)

> So when micro usb attached, we enable gadget mode; while micro usb
> detached, we disable gadget mode, and dwc2 will automatically set to
> host mode.

that's all fine, I'm concerned about letting the PHY fiddle with
something it doesn't own. If I am to change pullups rules in udc-core,
this is likely to break down miserably and I don't want to have to go
through that.

> >>+static void hi6220_detect_work(struct work_struct *work)
> >>+{
> >>+	struct hi6220_priv *priv =
> >>+		container_of(work, struct hi6220_priv, work.work);
> >>+	int gpio_id, gpio_vbus;
> >>+	enum usb_otg_state state;
> >>+
> >>+	if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
> >>+		return;
> >>+
> >>+	gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> >>+	gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >
> >looks like this should be using extcon
> Not used extcon before.
> However, we need gpio_vbus interrupt.
> Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> interrupt.
> Will investigate tomorrow.

drivers/extcon/extcon-gpio.c

> >>+	if (gpio_vbus == 0) {
> >>+		if (gpio_id == 1)
> >>+			state = OTG_STATE_B_PERIPHERAL;
> >>+		else
> >>+			state = OTG_STATE_A_HOST;
> >>+	} else {
> >>+		state = OTG_STATE_A_HOST;
> >>+	}
> >>+
> >>+	if (priv->state != state) {
> >>+		hi6220_start_peripheral(priv, state == OTG_STATE_B_PERIPHERAL);
> >>+		priv->state = state;
> >>+	}
> >>+}
> >>+
> >>+static irqreturn_t hiusb_gpio_intr(int irq, void *data)
> >>+{
> >>+	struct hi6220_priv *priv = (struct hi6220_priv *)data;
> >>+
> >>+	/* add debounce time */
> >>+	schedule_delayed_work(&priv->work, msecs_to_jiffies(100));
> >
> >this is really bad. We have threaded interrupt support, right ?
> 
> Since we use two gpio to distinguish gadget mode or host mode.
> Debounce time can introduce more accuracy.

gpio_set_debounce() ?

> I think threaded interrupt can not be used for adding debounce time.
> Here add debounce is just for safety.

add the debounce to the gpio itself.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: zhangfei <zhangfei.gao@linaro.org>
Cc: <balbi@ti.com>, Kishon Vijay Abraham I <kishon@ti.com>,
	<mark.rutland@arm.com>, Peter Chen <peter.chen@freescale.com>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	"dan . zhao" <dan.zhao@hisilicon.com>,
	Wangbinghui <wangbinghui@hisilicon.com>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v4 4/4] phy: add phy-hi6220-usb
Date: Fri, 20 Feb 2015 10:06:10 -0600	[thread overview]
Message-ID: <20150220160610.GB6430@saruman.tx.rr.com> (raw)
In-Reply-To: <54E75665.6050205@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]

Hi,

On Fri, Feb 20, 2015 at 11:44:37PM +0800, zhangfei wrote:
> Hi, Balbi
> 
> On 02/20/2015 10:41 PM, Felipe Balbi wrote:
> 
> >>+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> >>+{
> >>+	struct usb_otg *otg = priv->phy.otg;
> >>+
> >>+	if (!otg->gadget)
> >>+		return;
> >>+
> >>+	if (on)
> >>+		usb_gadget_connect(otg->gadget);
> >>+	else
> >>+		usb_gadget_disconnect(otg->gadget);
> >
> >why is the PHY fiddling with pullups ?
> 
> We use this to enable/disable otg gadget mode.

I got that, but the pullups don't belong to the PHY, they belong to the
gadget.

> The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> host mode.
> When micro usb or otg device attached to otg, gpio_vbus falling down.
> And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.

all of that I understood clearly :-)

> So when micro usb attached, we enable gadget mode; while micro usb
> detached, we disable gadget mode, and dwc2 will automatically set to
> host mode.

that's all fine, I'm concerned about letting the PHY fiddle with
something it doesn't own. If I am to change pullups rules in udc-core,
this is likely to break down miserably and I don't want to have to go
through that.

> >>+static void hi6220_detect_work(struct work_struct *work)
> >>+{
> >>+	struct hi6220_priv *priv =
> >>+		container_of(work, struct hi6220_priv, work.work);
> >>+	int gpio_id, gpio_vbus;
> >>+	enum usb_otg_state state;
> >>+
> >>+	if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
> >>+		return;
> >>+
> >>+	gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> >>+	gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >
> >looks like this should be using extcon
> Not used extcon before.
> However, we need gpio_vbus interrupt.
> Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> interrupt.
> Will investigate tomorrow.

drivers/extcon/extcon-gpio.c

> >>+	if (gpio_vbus == 0) {
> >>+		if (gpio_id == 1)
> >>+			state = OTG_STATE_B_PERIPHERAL;
> >>+		else
> >>+			state = OTG_STATE_A_HOST;
> >>+	} else {
> >>+		state = OTG_STATE_A_HOST;
> >>+	}
> >>+
> >>+	if (priv->state != state) {
> >>+		hi6220_start_peripheral(priv, state == OTG_STATE_B_PERIPHERAL);
> >>+		priv->state = state;
> >>+	}
> >>+}
> >>+
> >>+static irqreturn_t hiusb_gpio_intr(int irq, void *data)
> >>+{
> >>+	struct hi6220_priv *priv = (struct hi6220_priv *)data;
> >>+
> >>+	/* add debounce time */
> >>+	schedule_delayed_work(&priv->work, msecs_to_jiffies(100));
> >
> >this is really bad. We have threaded interrupt support, right ?
> 
> Since we use two gpio to distinguish gadget mode or host mode.
> Debounce time can introduce more accuracy.

gpio_set_debounce() ?

> I think threaded interrupt can not be used for adding debounce time.
> Here add debounce is just for safety.

add the debounce to the gpio itself.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-02-20 16:06 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  7:37 [PATCH v4 0/4] add usb support for hi6220 Zhangfei Gao
2015-02-12  7:37 ` Zhangfei Gao
2015-02-12  7:37 ` [PATCH v4 1/4] Documentation: dt-bindings: add dt binding info for hi6220 dwc2 Zhangfei Gao
2015-02-12  7:37   ` Zhangfei Gao
2015-02-12  7:37 ` [PATCH v4 2/4] Documentation: dt-bindings: add dt binding info for hi6220 Zhangfei Gao
2015-02-12  7:37   ` Zhangfei Gao
2015-02-12  7:37 ` [PATCH v4 3/4] usb: dwc2: platform: add hi6220 support Zhangfei Gao
2015-02-12  7:37   ` Zhangfei Gao
2015-02-12  7:37 ` [PATCH v4 4/4] phy: add phy-hi6220-usb Zhangfei Gao
2015-02-12  7:37   ` Zhangfei Gao
2015-02-18  5:35   ` Kishon Vijay Abraham I
2015-02-18  5:35     ` Kishon Vijay Abraham I
2015-02-18  5:35     ` Kishon Vijay Abraham I
2015-02-18  5:44     ` zhangfei
2015-02-18  5:44       ` zhangfei
2015-02-18 14:35       ` Felipe Balbi
2015-02-18 14:35         ` Felipe Balbi
2015-02-18 14:35         ` Felipe Balbi
2015-02-20  3:07         ` zhangfei
2015-02-20  3:07           ` zhangfei
2015-02-20  4:38           ` Felipe Balbi
2015-02-20  4:38             ` Felipe Balbi
2015-02-20  4:38             ` Felipe Balbi
2015-02-20 10:27             ` zhangfei
2015-02-20 10:27               ` zhangfei
2015-02-20 10:27               ` zhangfei
2015-02-20 14:41   ` Felipe Balbi
2015-02-20 14:41     ` Felipe Balbi
2015-02-20 14:41     ` Felipe Balbi
2015-02-20 15:44     ` zhangfei
2015-02-20 15:44       ` zhangfei
2015-02-20 15:44       ` zhangfei
2015-02-20 16:06       ` Felipe Balbi [this message]
2015-02-20 16:06         ` Felipe Balbi
2015-02-20 16:06         ` Felipe Balbi
2015-02-21 15:03         ` zhangfei
2015-02-21 15:03           ` zhangfei
2015-02-21 16:21           ` Felipe Balbi
2015-02-21 16:21             ` Felipe Balbi
2015-02-21 16:21             ` Felipe Balbi
2015-02-22  3:10             ` zhangfei
2015-02-22  3:10               ` zhangfei
2015-02-23 15:36               ` Felipe Balbi
2015-02-23 15:36                 ` Felipe Balbi
2015-02-23 15:36                 ` Felipe Balbi
2015-02-25 13:28                 ` zhangfei
2015-02-25 13:28                   ` zhangfei
2015-02-25 16:32                   ` Felipe Balbi
2015-02-25 16:32                     ` Felipe Balbi
2015-02-25 16:32                     ` Felipe Balbi
2015-02-24 10:13               ` Roger Quadros
2015-02-24 10:13                 ` Roger Quadros
2015-02-24 10:13                 ` Roger Quadros
2015-02-26  8:48                 ` zhangfei
2015-02-26  8:48                   ` zhangfei
2015-02-26  8:48                   ` zhangfei
2015-02-26  9:36                   ` Roger Quadros
2015-02-26  9:36                     ` Roger Quadros
2015-02-26  9:36                     ` Roger Quadros
2015-02-27  2:07                   ` Peter Chen
2015-02-27  2:07                     ` Peter Chen
2015-02-27  2:07                     ` Peter Chen

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=20150220160610.GB6430@saruman.tx.rr.com \
    --to=balbi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.