From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [PATCH RFC] usb: gadget: Add xilinx axi usb2 device support Date: Tue, 15 Apr 2014 23:39:23 -0500 Message-ID: <20140416043922.GC15056@saruman.home> References: <20140415171830.GB16002@saruman.home> Reply-To: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2JFBq9zoW8cOFH7v" Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alan Stern Cc: Felipe Balbi , sundeep subbaraya , Subbaraya Sundeep Bhatta , Greg Kroah-Hartman , "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Michal Simek , Subbaraya Sundeep Bhatta , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Apr 15, 2014 at 01:55:38PM -0400, Alan Stern wrote: > On Tue, 15 Apr 2014, Felipe Balbi wrote: >=20 > > > 2. Does device need to know OUT transactions before hand so that OUT > > > requests are queued for endpoint before packets are received > > > from host? > >=20 > > 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: > >=20 > > 1) start the transfer - most HW will wait for OUT token > > 2) wait for out token >=20 > I'm not familiar with the variations in all the different UDC hardware. = =20 > Nevertheless, I wouldn't describe the situation in those terms. OK, I've oversimplified... what I meant was that even if you start a transfer at the UDC level, nothing will happen on the bus until HW sees an OUT token. The buffer pointed to by req->buf won't get any writes, DMA won't do anything. On (2) I meant that some HW (e.g. dwc3) will assert the IRQ line once they see a token for which they have to transfer descriptors in the internal controller's cache. > If an OUT transaction occurs and the gadget driver hasn't queued a > request, the UDC hardware could store the incoming data in an internal > buffer or it could NAK the transaction. There aren't any other > choices. If there isn't enough space available in an internal buffer, > the only possible action is NAK. in HS there's also NYET > Regardless, gadget drivers do not need to queue requests for OUT > endpoints before the host starts sending data. When the request does they're not required, but they can. It's UDC driver's responsability to start consuming the queue at the proper time. > get queued, the UDC driver will make sure that the transfer takes > place. correct. --=20 balbi --2JFBq9zoW8cOFH7v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTTgl6AAoJEIaOsuA1yqREuP8P/iGR8dgxDlZyDWcLF5MFP7il UML0YN3vmzN5k7XUcWQ7VP4fORyNoPgzDkXkLzZavOQbTR2wuw5JKgF2xpi6nP4J hKoOSjoyvX9IRQOoQHaT+aqD9OlTVNNWFTgpOwqcsCsWLY8YOCkcYXJKrwdYaJXA o1GafbCtBexY6g0Aa0CcGFSOfjQiFQIPjGm1z6USz+67w072kdeG9/Dkep6Po7jN udEW1b0IZK8HPVBo1IQClSlqnQh/LGU5P4xYKshBV7SqG/OjAKiBNE7zvcNUpU35 9xjOf0hrD/M3tX3oJCYF657MoPh5NfHN6a4a1gp6XxIk8nPxCQ7lvvCztqiBImBZ Ve6UNPP2HY7O/+V8fwLFqnsv67FTWbW7kPMwCS48fYNyB9II+MCD8XwM9B2QRkZi 1vA9duYOodqiAQ9C2d6Gh3wGGs0iNUYjC9HPzhbQPWWn0/XfobmRUuxqqUwcsV82 tOS+zmcb874NGPGvaljFe7FtBoDfMetJCklcMzv/fqjTjsgKbVj5J3huh9ytBiEQ Nt4yGHJ3Ide9fteYeWf1WvnLkAe/E1f3XQfLgFcro2+mWXuL9t1WnubDwutw3J4r wOYlkkvkUDr6sZ1q+Ul/sWWVCraAFx5kBAfM6HnRl74CRpqWUBQmWF6BKeiDyBYC 3qpB6c4dmcwpXZwn35e8 =CFFn -----END PGP SIGNATURE----- --2JFBq9zoW8cOFH7v-- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html