> fair enough... now that's a lot clearer. Did you design your own OTG > controller or did you license from someone else ?
Yes, we have designed our own OTG controller. I have spent a certain amount of time reading documentation, notably "Bootstrap Yourself with Linux-USB stack" which has been for me a very good point to start. I feel now more comfortable with linux stack: - controller driver - gadget driver - class driver and associated structures. I have already written a large part of my udc driver. The next step I aim to reach is to pass the enumeration successfully, which imply that the "probe()" and "usb_gadget_register_driver()" should be fine coded. It is why I need some clarifications, because I am entering the real part of the work: have my udc driver correctly communicating with the upper layers, in order to discuss with the host. So my first question was about the probe() function. I am registering the irq in my probe() function , with "request_irq()". (I have written a uart and ethernet drivers, so I have already play with request_irq) But, as I said early, what should I do with platform_get_ressource? (we can use IORESOURCE_MEM and IORESOURCE_IRQ as operand) I don't understand what these resources correspond to. Is IORESOURCE_MEM use for allocating transfert buffer? If so, is it the harware allocated buffer adress? I have seen in some udc drivers that "resource_get_irq()" is called before registering IRQ with "request_irq()". What is the purpose of this function? Thanks in advance for your explanations. 2013/1/30 Felipe Balbi <ba...@ti.com>: > Hi, > > On Wed, Jan 30, 2013 at 06:10:50PM +0100, stl wrote: >> > What does your device do? >> >> Ok, to clarify the situation, I have ported uClinux for a new architecture. >> We also have our own usb2.0 otg controller IP. >> Since our system is designed for embedded systems, we want a usb >> platform driver. >> (a UDC driver if I well understood) >> I really mean "device-side" , not "host-side" . >> I have included my platform driver in the usb/gadget directory, and I >> am at the moment >> using zero.c as gadget driver. > > fair enough... now that's a lot clearer. Did you design your own OTG > controller or did you license from someone else ? > > I ask because we don't want to accept duplicated code in mainline and if > there is already a driver available, it might make your life easier. > >> > > Some vendors use device_register(). What does it do? >> >> > which vendors ? which drivers use this ? >> >> For example, the drivers/usb/gadget/at91_udc.c driver use device_register. > > I'm cleaning all of that up. See the commits here: > > http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=shortlog;h=refs/heads/gadget-refactor-dev-registration > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
