[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140415171830.GB16002@saruman.home>
Date: Tue, 15 Apr 2014 12:18:30 -0500
From: Felipe Balbi <balbi@...com>
To: sundeep subbaraya <sundeep.lkml@...il.com>
CC: <balbi@...com>,
Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@...inx.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Michal Simek <michals@...inx.com>,
Subbaraya Sundeep Bhatta <sbhatta@...inx.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH RFC] usb: gadget: Add xilinx axi usb2 device support
Hi,
On Wed, Mar 26, 2014 at 03:37:52PM +0530, sundeep subbaraya wrote:
> >> + INIT_LIST_HEAD(&req->queue);
> >
> > remove this INIT_LIST_HEAD();
> >
> > also, before returning, I suppose you probably want to link the request
> > to the endpoint somehow. Usually people save the endpoint pointer inside
> > the private request structure (iow: req->ep = ep;)
> >
>
> in ep_queue (say,for IN transaction) the driver copies the gadget
> driver buffer to HW endpoint buffer and if whole data
> has been transferred successfully then request is not added to
> endpoint request list. Hence INIT_LIST_HEAD(&req->queue)
> is required since list_add_tail is not done every time in ep_queue. Is
> it ok to let this be here?o
my bad, you _do_ need this INIT_LIST_HEAD() here. When I first read, I
thought you were initializing struct usb_request list_head, and that is
not necessary ;-)
> >> + if (req != NULL)
> >> + list_add_tail(&req->queue, &ep->queue);
> Here. INIT_LIST_HEAD(&req->queue) is required in alloc_req since
> list_add_tail is not executed every time.
>
> Could you please clarify my questions regarding requests queuing.
> 1. If Device need to send 5120 bytes to host and
> ep->desc->wMaxPacketSize is 512 then single request with length 5120
> is issued or 10 requests are issued?
single request.
> 2. Does device need to know OUT transactions before hand so that OUT
> requests are queued for endpoint before packets are received
> from host?
well, no. Gadget driver shouldn't depend on that. That's UDC driver's
responsability to manage that. I mean, if host sends OUT token and
there's nothing in the out queue, then UDC need to start transfer as
soon as gadget driver queues the request. If, on the other hand, gadget
driver queues packet before host has sent OUT token then you have two
choices:
1) start the transfer - most HW will wait for OUT token
2) wait for out token
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists