All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu CASTET <matthieu.castet@parrot.com>
To: Brian Swetland <swetland@google.com>
Cc: David Brownell <david-b@pacbell.net>,
	Pavan Kondeti <pkondeti@codeaurora.org>,
	"greg@kroah.com" <greg@kroah.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	Mike Lockwood <lockwood@android.com>
Subject: Re: [PATCH v2] USB: Add MSM USB Device Controller driver
Date: Fri, 19 Nov 2010 18:16:16 +0100	[thread overview]
Message-ID: <4CE6B0E0.2030900@parrot.com> (raw)
In-Reply-To: <AANLkTikN4=cssosTu2=-LU3a2dJuCCQWhCjRsCyjxORy@mail.gmail.com>

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

Hi,

Brian Swetland a écrit :
> On Tue, Nov 9, 2010 at 6:54 PM, David Brownell <david-b@pacbell.net> wrote:
>>
>> --- On Tue, 11/9/10, Pavan Kondeti <pkondeti@codeaurora.org> wrote:
>>
>>>>> Hi Matthieu,
>>>>>
>>>>>> This look like the arc/chipidea/mips ehci otg
>>> core.
>>>>> Yes. It is chipidea core for ARM.
>>>>>> Why can't you reuse the ci13xxx_udc.c driver
>> That basic approach is FAR PREFERABLE.  Fix
>> the bugs once, tune once, and so forth, reuse
>> the ULPI support, etc.  Work on more
>> platforms, since the silicon IP is reused.
>>
>> You'll end up with more folk who can help
>> maintain the driver too, since the pool of
>> potential helpers won't be limited to those
>> who have/use MSM hardware.
>>
>> Just be sure to cleanly factor the bus
>> (PCI vs MSM-s ARM platform flavor and
>> SoC glues (bus-related).  That factoring
>> will likely be the hardest part; but there
>> are examples of similar stuff in Linux today.
> 
> The main headache is that this particular IP has different bugs in
> different instantiations (I know, for example, it exists in Tegra with
> a different set of issues around fetching descriptor heads and cache
> alignment, on MSM7201A after extensive testing we discovered there was
> no reliable way of adding a descriptor to a list of transactions once
> that queue was active, etc...), so things that work in one SoC may
> break another, etc, etc, but that's part of the adventure I suppose.
> I certainly agree that one unified driver is the way to go if you can
> make it all work.
> 
The best way to handle this is to introduce flags in the driver. For 
example look at drivers/mmc/host/sdhci.c (quirk flags).

But for now, let's make work msm version. We can add workaround for 
other controller later.

Now you should check if it is better to start on ci13xxx_udc or make 
generic your driver.

I had worked a bit on ci13xxx_udc, and the code is sometimes messy, hard 
to understand.
Also to making work on our core, we need to the attached patch.


Matthieu



[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1112 bytes --]

diff --git a/drivers/usb/gadget/ci13xxx_udc.c b/drivers/usb/gadget/ci13xxx_udc.c
index 0252bbc..5a65cda 100644
--- a/drivers/usb/gadget/ci13xxx_udc.c
+++ b/drivers/usb/gadget/ci13xxx_udc.c
@@ -2140,6 +2140,7 @@ static int ep_queue(struct usb_ep *ep, struct usb_request *req,
 	struct ci13xxx_req *mReq = container_of(req, struct ci13xxx_req, req);
 	int retval = 0;
 	unsigned long flags;
+	int empty;
 
 	trace("%p, %p, %X", ep, req, gfp_flags);
 
@@ -2170,15 +2171,18 @@ static int ep_queue(struct usb_ep *ep, struct usb_request *req,
 
 	dbg_queue(_usb_addr(mEp), req, retval);
 
+	empty = list_empty(&mEp->qh[mEp->dir].queue);
 	/* push request */
 	mReq->req.status = -EINPROGRESS;
 	mReq->req.actual = 0;
 	list_add_tail(&mReq->queue, &mEp->qh[mEp->dir].queue);
 
-	retval = _hardware_enqueue(mEp, mReq);
-	if (retval == -EALREADY || retval == -EBUSY) {
-		dbg_event(_usb_addr(mEp), "QUEUE", retval);
-		retval = 0;
+	if (empty) {
+		retval = _hardware_enqueue(mEp, mReq);
+		if (retval == -EALREADY || retval == -EBUSY) {
+			dbg_event(_usb_addr(mEp), "QUEUE", retval);
+			retval = 0;
+		}
 	}
 
  done:

  reply	other threads:[~2010-11-19 17:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-09 11:18 [PATCH v2] Add MSM USB Device Controller support Pavankumar Kondeti
2010-11-09 11:18 ` [PATCH v2] USB: Add MSM USB Device Controller driver Pavankumar Kondeti
2010-11-09 11:40   ` Matthieu CASTET
2010-11-09 12:16     ` Pavan Kondeti
2010-11-09 13:36       ` Matthieu CASTET
2010-11-10  2:12         ` Pavan Kondeti
2010-11-10  2:54           ` David Brownell
2010-11-10  6:22             ` Brian Swetland
2010-11-19 17:16               ` Matthieu CASTET [this message]
2010-11-27 14:00                 ` Pavan Kondeti
2010-11-28  6:30                   ` David Brownell
2010-11-28 12:09                     ` Pavan Kondeti
2010-12-07 12:44                 ` Pavan Kondeti
2010-11-09 13:25   ` Heikki Krogerus
2010-11-09 13:52   ` Matthieu CASTET
2010-11-09 15:36     ` Igor Grinberg
2010-11-10  2:19       ` Pavan Kondeti
2010-11-10  6:47         ` Igor Grinberg
2010-11-11  2:10           ` Pavan Kondeti
2010-11-19  5:50             ` Pavan Kondeti
2010-11-21  8:09               ` Igor Grinberg
2010-11-10  2:17     ` Pavan Kondeti
2010-11-09 11:18 ` [PATCH v2] USB: msm72k_udc: Add debugfs support Pavankumar Kondeti
2010-11-09 11:18 ` [PATCH v2] USB: msm72k_udc: Add Remote wakeup support Pavankumar Kondeti
2010-11-09 11:18 ` [PATCH v2] USB: msm72k_udc: Add Test Mode support Pavankumar Kondeti
2010-11-09 11:18 ` [PATCH] USB: msm72k_udc: Add charging notification support Pavankumar Kondeti

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=4CE6B0E0.2030900@parrot.com \
    --to=matthieu.castet@parrot.com \
    --cc=david-b@pacbell.net \
    --cc=greg@kroah.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lockwood@android.com \
    --cc=pkondeti@codeaurora.org \
    --cc=swetland@google.com \
    /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.