On Mon, 28 May 2012, [iso-8859-1] Jean-Fran�s Dagenais wrote: > On 2012-05-28, at 11:55 AM, Alan Stern wrote: > > > > > As far as I know, the only driver that uses the HID interface is > > usbhid. It probably isn't a good model for what you want to do. > Really? No freebies in there? Not even usbhid_submit_report? Nope. That routine is concerned almost entirely with managing I/O queues, doing runtime PM, handling timeouts, and other similar higher-level things. Practically none of it is involved in actually communicating with the device. > > Maybe some of the files in drivers/usb/misc will be a closer match. > found drivers/i2c/busses/i2c-diolan-u2c.c as a good starting point, do you > agree? No idea. > > I don't know what you mean by "nested interrupt handler". > > For example the gpio-adp5588 driver has a threaded ISR callback which fetches > the GPIO state of the chip through i2c, then maps each GPIO pin to it's related > system IRQ number and calls handle_nested_irq() if it applies. This makes any > pin of this gpio chip a source of interrupt to the system, it's "nested" because > the irq client for a given pin will get it's threaded ISR handler through the > handler of the 5588. Well, maybe you'll be able to use a similar approach. However it shouldn't be your primary concern; you need to get your driver working with the device first. > > If an input report is not available over the interrupt-in endpoint > > (which would be a violantion of the HID spec) then you have no choice > > but to poll it. > > Which seems to be the case based on the fact it's "feature request in". So that > would mean I would have to "CPU-poll-it" to see if it changes, right? This > pretty much kills the idea of declaring the GPIOs as source of interrupts then. Seems that way. Unless there's also an input report that tells you when a GPIO changes state. > So for example, if you take a look at the an495 pdf, once I have submitted > report 0x10 (interrupt out) "Data read request" to the cp2112 to read data from > an i2c slave, and I want to block until the data is ready, I understand that the > returned data will come from report 0x13 (interrupt in) "data read response", > and the chip send that on the USB wire spontaneously when it's got a token or > something, right? If so, does the chip only get this "token" only if the device > driver does something? Like actually asking for this report You really need to learn how USB works before you try writing a USB driver. USB is driven almost entirely by the host. The device never sends anything unless the host asks it to. (There are a few exceptions but they are very minor and don't apply here.) And of course, the host controller won't send anything unless a driver tells it to. > In any case, how do > I block until this report has been fired by the chip? Using > usb_interrupt_msg(usb_dev, usb_rcvintpipe(usb_dev,), ...) ?? Yes, that's the easiest way. > I assume I'll want > to do all my interactions with the chip synchronously, hence using > usb_xyz_msg(dev, pipe, ). Does the host controller buffer the report if I am late > getting the response? The host controller doesn't buffer anything. Remember, the device doesn't send the data until the host asks for it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
