On Friday 06 July 2007, Alan Stern wrote:
> On Fri, 6 Jul 2007, David Brownell wrote:
>
> > On Monday 02 July 2007, Alan Cox wrote:
> >
> > > Why not just bite the bullet and change the callback convention. ...
> >
> > On the other hand, that *could* dovetail nicely with the proposed
> > change o
On Fri, 6 Jul 2007, David Brownell wrote:
> On Monday 02 July 2007, Alan Cox wrote:
>
> > Why not just bite the bullet and change the callback convention. The lock
> > verification code should catch the cases that matter and which are
> > overlooked on a code scan. You could also change the name
On Monday 02 July 2007, Alan Cox wrote:
> Why not just bite the bullet and change the callback convention. The lock
> verification code should catch the cases that matter and which are
> overlooked on a code scan. You could also change the name of the callback
> to be sure it breaks anything out o
Alan Stern wrote:
> On Tue, 3 Jul 2007, Steven Rostedt wrote:
>
> You never answered my second question. Is this sort of thing
> acceptable?
Doh! I never noticed your second question. Sorry about that.
>
> DECLARE_SPINLOCK(lock);
>
> static void irq_handler()
> {
> spin_lock_irqsave(&l
On Tue, 3 Jul 2007, Steven Rostedt wrote:
> The problem that we are facing in this thread is that the RT patch
> doesn't touch local_irq_save and restore. These still turn off
> interrupts, and can be a problem with the RT patch. We need a tight
> coupling between spin_lock and irq disable. Th
Jiri Kosina wrote:
> On Tue, 3 Jul 2007, Steven Rostedt wrote:
>
>> Unfortunately that would not work in the RT case either. Because in RT,
>> that spin_lock can schedule, and we are not allowed to schedule with
>> interrupts disabled.
>
> So how do you handle in RT all the current code everywh
Jiri Kosina wrote:
> On Tue, 3 Jul 2007, Felipe Balbi wrote:
>
>> So looks like we don't have (yet) a way to make it work nicely in both
>> cases... does anyone has a clue about how to implement this one??
>
> You of course still can
>
> local_irq_save(flags);
> spin_lock(&some_lock
On Tue, 3 Jul 2007, Steven Rostedt wrote:
> Unfortunately that would not work in the RT case either. Because in RT,
> that spin_lock can schedule, and we are not allowed to schedule with
> interrupts disabled.
So how do you handle in RT all the current code everywhere in the tree,
which does p
On Tue, 3 Jul 2007, Felipe Balbi wrote:
> So looks like we don't have (yet) a way to make it work nicely in both
> cases... does anyone has a clue about how to implement this one??
You of course still can
local_irq_save(flags);
spin_lock(&some_lock);
...
spin_unl
On 7/3/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Mon, 2 Jul 2007, Alan Cox wrote:
>
> > > spin_lock_irqsave(&some_lock, flags);
> > > ...
> > > spin_unlock(&some_lock);
> > > usb_hcd_giveback_urb(hcd, urb);
> > > local_irq_restore(flags);
> > > or is there a better approac
On Mon, 2 Jul 2007, Alan Cox wrote:
> > spin_lock_irqsave(&some_lock, flags);
> > ...
> > spin_unlock(&some_lock);
> > usb_hcd_giveback_urb(hcd, urb);
> > local_irq_restore(flags);
> > or is there a better approach?
> Why not just bite the bullet and change the callback convent
Alan Cox wrote:
>> The reason for doing this is historical; usb_hcd_giveback_urb() is
>> documented as running with local IRQs disabled, and many drivers depend
>> on that. For example, their callback routines invoked by
>> usb_hcd_giveback_urb do spin_lock() instead of spin_lock_irqsave().
>
>
> The reason for doing this is historical; usb_hcd_giveback_urb() is
> documented as running with local IRQs disabled, and many drivers depend
> on that. For example, their callback routines invoked by
> usb_hcd_giveback_urb do spin_lock() instead of spin_lock_irqsave().
>
> So what's the best
Steven:
At OSL you mentioned that local_irq_{save,disable} is unfriendly for RT
and spin_lock_irq[save] is greatly preferred. As it happens, the USB
core contains several instances of this code pattern:
local_irq_save(flags);
spin_lock(&some_lock);
...
spin_unlock
14 matches
Mail list logo
