Hi Matthieu, On 11/19/2010 10:46 PM, Matthieu CASTET wrote: > The best way to handle this is to introduce flags in the driver. For > example look at drivers/mmc/host/sdhci.c (quirk flags). > > But for now, let's make work msm version. We can add workaround for > other controller later. > > Now you should check if it is better to start on ci13xxx_udc or make > generic your driver. > > I had worked a bit on ci13xxx_udc, and the code is sometimes messy, hard > to understand. > Also to making work on our core, we need to the attached patch. > > ci13xxx_udc is working fine on MSM SoC without the attached patch. According to hardware doc, When endpoint is in primed state the corresponding bit of either ENDPTRPIME or ENDPTSTAT will be set. The driver is assuming the same. So I don't see a problem. The current driver, one dTD is given to the hardware at a time. We can improve it by adding hardware queuing functionality or adopt msm72k_udc algorithm. I have submitted patches to separate PCI stuff out of ci13xxx_udc. I have submitted MSM bus glue driver which makes use of ci13xxx_udc. I have tested it on MSM SoC. But I don't have ci13xxx PCI hardware. Can you help me in testing my patches (5-11 of [PATCH V3 00/11] Add MSM USB controller driver) Thanks in advance, Pavan -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
