On Mon, 28 May 2012, [iso-8859-1] Jean-Fran�s Dagenais wrote:
>
> On 2012-05-25, at 22:09, Alan Stern wrote:
>
> > On Fri, 25 May 2012, [iso-8859-1] Jean-Fran�s Dagenais wrote:
> >
> >> ...
> >> I have my CP2112 eval kit with me and I'm ready to get started but I'd like
> >> some pointers to get on the right track ASAP.
> >>
> >> - as per device driver customs, which existing driver (patch or already merged)
> >> should be used as template?
> >
> > I don't really know. There are drivers that do roughly the same sort
> > of thing, but they may not be all that similar to what you want.
> Well, which driver has the least amount of very device specific hacks and best
> demonstrates the use of the HID interface? (I can probably figure that out
> myself too, just want an opinion here.)
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.
Maybe some of the files in drivers/usb/misc will be a closer match.
> >> - would I use the same internal APIs that the IOCTLs of hiddev use for example?
> >
> > Why would you want to? You're not writing an hiddev driver -- you're
> > writing a USB-i2c bridge driver.
> I'm just saying I want to make code that would have the same interactions with the
> hid device as if I were to code it in user-space on top of hiddev, that's why I
> said that. Basically I was thinking of inspecting hiddev.c to see where it turns to
> to implement all it's IOCTLs.
You don't want to do that. The HID drivers are general-purpose because
they have to manage all sorts of devices; most of the code is involved
with implementing this general-purpose approach (parsing arbitrary
reports and so on). You're only going to manage a single class of
devices.
> I am going through the HID spec right now so I don't fully understand all the
> concepts yet. This is why I want to get some directions so I can focus on the
> right APIs quicker. I have a very limited time budget for this (so says my
> employer), but I want to try to get this chip in the kernel.
You should not focus on HID-specific APIs, primarily because you aren't
going to be using these devices for Human Interaction. Just use the
regular USB core API.
> The chip spec (link above) says it has some control reports and interrupt
> reports.
That is meaningless. HID devices have input reports, output reports,
and feature reports. The "control" vs. "interrupt" stuff refers to the
way in which those reports are sent between the device and the host; it
is not inherent to the report.
> The GPIO set and get are said to be "control" reports.
There is no such thing as a "control" report. Every input or output
report is supposed to be usable via both an interrupt and the control
endpoint. (See section 8.1 of the HID spec.) However not all HID
devices are fully compliant with the spec, and they don't all have
interrupt-out endpoints.
> All the
> smbus/i2c reports are in/out interrupt reports. So basically to implement an
> interrupt controller feature using the GPIOs, I would need a callback when the
> control report 0x03 ("get GPIO") of the chip changes value so I can inspect if I
> need to invoke a nested interrupt handler, without burdening the CPU with
> polling the report of course.
I don't know what you mean by "nested interrupt handler".
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.
> I am told the host controller can provide such a
> service, is this true? If so, which API(s) must I use to get this
> functionality? (I don't need long explanations here, just keywords or API
> names, example code perhaps)
I'm not sure what service you're asking for. The main API you will
want to use is usb_submit_urb().
There's a lot of kerneldoc in include/linux/usb.h. There are also some
documents available on the web that give reasonably good introductions
to Linux USB device driver programming (although they are all out of
date to some extent). The "Linux Device Drivers, 3rd ed." book
(freely available) has a chapter on 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
