Re: 3c59x vortex_timer rt hack (was: rt20 patch question)

[Steven Rostedt]

On Fri, 12 May 2006, Andrew Morton wrote:

> Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >
> > On Fri, 12 May 2006, Andrew Morton wrote:
> >
> > > >
> > > > The vortex_timer is a timeout,
> > >
> > > err, it's actually a function.
> >
> > OK, I meant vp->timer
>
> That's a kernel timer.

:P

>
> > >
> > > > will it go off often?
> > >
> > > Every five seconds if the cable's unplugged.  Every 60 seconds otherwise.
> > >
> >
> > OK, so the function is a service and not a fixup (or both).  Hmm, so
> > latency is an issue.
>
> yup.  It's been five years, sorry - I'm struggling to remember why
> vortex_timer() needs to block the interrupt handler.
>
> The chip is fairly stateful - that EL3WINDOW() thing selects a particular
> register bank and needs protection against other register readers.  But we
> should avoid running EL3WINDOW() in the rx and tx interrupt handlers anyway
> - iirc the chip is designed to permit that.
>
> Is tricky.
>
> How come -rt cannot permit disable_irq() in there?

It's about having threaded interrupts soft and hard, and their
combinations.  disable_irq with threaded hardirqs can schedule, but we
still don't want a softirq to do so (when not threaded).

So it too is tricky.


>
> (I think the _reason_ it's disable_irq() is, yes, because it's infrequent
> and because it can hold off interrupts for a long time if we use
> spin_lock_irq())
>

Well, it seems that the spin_lock_irq for -rt is the answer for now, until
we sort out the dependencies of threaded interrupts.

Ingo,

Maybe it will be necessary to make hardirq threading dependent on softirq
threading.

Is it really that bad?  When would someone want Hardirq threading without
having softirq threading??

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/