The pin muxing and clock definitions for the MUSB controller are
not done through the same registers/pin mux options, so this
explicitly configures the registers and pin-mux options for MUSB
on AM3517-EVM
Signed-off-by: Adam Ford
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-o
The glue that connects the AM35xx is not the same as the OMAP3.
With the AM35xx-MUSB now available in device tree, point to that
glue instead of omap3.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index ca294914bbb1..c17cfe6a2132 100644
---
There are two clocks that fail when attempting to use them. This
patch patches the clock names to match those in hwmods.
Signed-off-by: Adam Ford
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index a55db15a8457..56f8e13f4c1b 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers
With AM35x now supported in device tree and the pdata-quirks
configuring the AM3517 clocks and some of the pin-mux,
this patch enables the MUSB and configures the rest of the pin-
mux options
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/am3517-evm.dts b/arch/arm/boot/dts/am3517-evm.dt
The AM35x glue doesn't yet support device tree, so this patch
adds the basics hooks so it doesn't haven't use pdata-quirks.c
Signed-off-by: Adam Ford
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 660641ab1545..a55db15a8457 100644
--- a/drivers/usb/musb/am35x.c
+++ b/driv
Currently, the AM3517.dtsi uses the omap2430 glue to connect
the MUSB controller when it should use the AM35x glue. This
series attempts to convert the AM35x glue to device tree,
fix the clock references to the AM35X can enable/disable
them correctly, and then use pdata-quirks.c to enable the
regi
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
From: John Ogness
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The call
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
From: John Ogness
wa_urb_dequeue() locks multiple spinlocks while disabling interrupts:
spin_lock_irqsave(&lock1, flags);
spin_lock_irqsave(&lock2, flags2);
Obviously there is no need for the second irqsave and "flags2" variable
since interrupts are disabled at that point. Remove the seco
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
The intr_idx_lock lock is acquired only in the completion callback of
the ->int_in_urb (iowarrior_callback()). There is only one URB that is
scheduled / completed so there can't be more than one user of the lock.
The comment says that it protects ->intr_idx and the callback is the
only place in dri
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
This is about using _irqsave() primitives in the completion callback in
order to get rid of local_irq_save() in __usb_hcd_giveback_urb(). This is the
last series.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.or
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked
Hi Alan Stern,
On Wed, Mar 14, 2018 at 04:52:13PM -0400, Alan Stern wrote:
> This should not be needed; it indicates that something is wrong with
> the way interrupt requests are handled on this platform.
>
> Are you using threaded interrupts at all? If you are, you have to
> change the spin_l
Hi people,
as I am working with a PL2303-based USB-to-serial converter I discovered
that the SW-based flow control was unsupported for all kernels till the
upcoming 4.18 release. Thanks to the patch by Florian Zumbiehl this
deficit was finally resolved and also my tests showed that now the flow
ch
On Sun, Jun 24, 2018 at 05:23:26PM +0400, safocl wrote:
> By the way, with the patch
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=0dc68cabdb626e33d02561529e6a4c681b72a784
> everything is fine with the allocated memory for data in 1 byte.
> so I think the bu
By the way, with the patch
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=0dc68cabdb626e33d02561529e6a4c681b72a784
everything is fine with the allocated memory for data in 1 byte.
so I think the bug is resolved, it remains only to wait for inclusion in the
rea
23 matches
Mail list logo
