- 12 12月, 2011 2 次提交
-
-
由 Felipe Balbi 提交于
if we want to support situations where we have both SoC and PCIe versions of the IP on the same platform, we need to have sequential numbers between them, otherwise we will still have name collisions. Because of that, we need to move dwc3_get/put_device_id() to core.c and export that symbol to be used by glue layers. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Felipe Balbi 提交于
There's no need to add driver_data for something we can fetch from HW. This also makes our id_table unnecessary - at least for now -, so we also remove it on the same patch. Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 05 10月, 2011 1 次提交
-
-
Some people think that this line is not compatible with the GPL. The statement was required due to the Buenos Aires Convention and is now deprecated. I remove it because it is said that it is pointless nowdays. Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 24 8月, 2011 1 次提交
-
-
由 Stephen Rothwell 提交于
Fixes this build error: drivers/usb/dwc3/dwc3-pci.c: In function 'dwc3_pci_init': drivers/usb/dwc3/dwc3-pci.c:211:9: error: 'THIS_MODULE' undeclared (first use in this function) Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 8月, 2011 1 次提交
-
-
由 Felipe Balbi 提交于
The DesignWare USB3 is a highly configurable IP Core which can be instantiated as Dual-Role Device (DRD), Peripheral Only and Host Only (XHCI) configurations. Several other parameters can be configured like amount of FIFO space, amount of TX and RX endpoints, amount of Host Interrupters, etc. The current driver has been validated with a virtual model of version 1.73a of that core and with an FPGA burned with version 1.83a of the DRD core. We have support for PCIe bus, which is used on FPGA prototyping, and for the OMAP5, more adaptation (or glue) layers can be easily added and the driver is half prepared to handle any possible configuration the HW engineer has chosen considering we have the information on one of the GHWPARAMS registers to do runtime checking of certain features. More runtime checks can, and should, be added in order to make this driver even more flexible with regards to number of endpoints, FIFO sizes, transfer types, etc. While this supports only the device side, for now, we will add support for Host side (xHCI - see the updated series Sebastian has sent [1]) and OTG after we have it all stabilized. [1] http://marc.info/?l=linux-usb&m=131341992020339&w=2Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-