- 09 3月, 2015 3 次提交
-
-
由 Sudeep Holla 提交于
As per the SAF1761 data sheet[0], the DcChipID register represents the hardware version number (0001h) and the chip ID (1582h) for the Peripheral Controller. However as per the ISP1761 data sheet[1], the DcChipID register represents the hardware version number (0015h) and the chip ID (8210h) for the Peripheral Controller. This patch adds support for both the chip ID values. [0] http://www.nxp.com/documents/data_sheet/SAF1761.pdf [1] http://pdf.datasheetcatalog.com/datasheets2/74/742102_1.pdfAcked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NSudeep Holla <sudeep.holla@arm.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Valentin Rothberg 提交于
The IRQF_DISABLED is a NOOP and scheduled to be removed. According to commit e58aa3d2 ("genirq: Run irq handlers with interrupts disabled") running IRQ handlers with interrupts enabled can cause stack overflows when the interrupt line of the issuing device is still active. This patch removes using this deprecated flag and additionally removes redundantly setting IRQF_SHARED for isp1760_udc_register(). Signed-off-by: NValentin Rothberg <Valentin.Rothberg@lip6.fr> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Sudeep Holla 提交于
Use spin_{un,}lock_irq{save,restore} in isp1760_udc_{start,stop} to prevent following potentially deadlock scenario between isp1760_udc_{start,stop} and isp1760_udc_irq : ================================= [ INFO: inconsistent lock state ] 4.0.0-rc2-00004-gf7bb2ef60173 #51 Not tainted --------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. in:imklog/2118 [HC1[1]:SC0[0]:HE0:SE1] takes: (&(&udc->lock)->rlock){?.+...}, at: [<c0397a93>] isp1760_udc_irq+0x367/0x9dc {HARDIRQ-ON-W} state was registered at: [<c05135b3>] _raw_spin_lock+0x23/0x30 [<c0396b87>] isp1760_udc_start+0x23/0xf8 [<c039dc21>] udc_bind_to_driver+0x71/0xb0 [<c039de4f>] usb_gadget_probe_driver+0x53/0x9c [<bf80d0df>] usb_composite_probe+0x8a/0xa4 [libcomposite] [<bf8311a7>] 0xbf8311a7 [<c00088c5>] do_one_initcall+0x8d/0x17c [<c050b92d>] do_init_module+0x49/0x148 [<c0087323>] load_module+0xb7f/0xbc4 [<c0087471>] SyS_finit_module+0x51/0x74 [<c000d8c1>] ret_fast_syscall+0x1/0x68 irq event stamp: 4966 hardirqs last enabled at (4965): [<c05137df>] _raw_spin_unlock_irq+0x1f/0x24 hardirqs last disabled at (4966): [<c00110b3>] __irq_svc+0x33/0x64 softirqs last enabled at (4458): [<c0023475>] __do_softirq+0x23d/0x2d0 softirqs last disabled at (4389): [<c002380b>] irq_exit+0xef/0x15c other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&udc->lock)->rlock); <Interrupt> lock(&(&udc->lock)->rlock); *** DEADLOCK *** 1 lock held by in:imklog/2118: #0: (&f->f_pos_lock){+.+.+.}, at: [<c010a101>] __fdget_pos+0x31/0x34 Signed-off-by: NSudeep Holla <sudeep.holla@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 27 1月, 2015 3 次提交
-
-
由 Laurent Pinchart 提交于
The isp1760 driver registration function returns an error if USB is disabled. This made sense when the driver only supported host controllers, but now that it supports peripheral controllers host support isn't mandatory anymore. Fix this by returning an error only when both the HCD and UDC functions are disabled, either through the kernel configuration or at runtime. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Laurent Pinchart 提交于
Now that this is DRD, it doesn't make sense to keep it under drivers/usb/host. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Laurent Pinchart 提交于
The ISP1761 is a dual-mode host and device controller backward compatible on the host side with the ISP1760. Add support for the device controller. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-