All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Vinson <rvinson@mvista.com>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: [RFC] 85XX: Allow 8259 cascade to share an MPIC interrupt line.
Date: Thu, 07 Jun 2007 12:54:50 -0700	[thread overview]
Message-ID: <4668628A.30401@mvista.com> (raw)
In-Reply-To: <46685F77.7050901@ru.mvista.com>

Sergei Shtylyov wrote:
[snippage]
>> The threaded interrupt system has threaded routines for the 4 standard
>> interrupts types used by the generic IRQ system (fasteoi, edge, level
>> and simple), plus a handler for non-generic interrupts (the ones that
>> still use __do_IRQ.) When interrupts are being threaded and a
>> non-cascaded MPIC interrupt occurs, desc->handler normally points to
>> handle_fasteoi_irq which masks the interrupt source, schedules the
>> corresponding IRQ thread, issues an EOI and returns to the interrupted
>> context. At a later time, the scheduler dispatches the IRQ thread which
>> calls a threaded version of the fasteoi handler. The threaded fasteoi
>> routine processes the action chain and calls .unmask to re-enable the
>> interrupt before returning to the calling thread. Once the interrupt has
>> been unmasked, the entire process is free to repeat as needed.
> 
>    Oh, you could have really skipped the basics. ;-)
Maybe not. See below.

> 
>> After processing a possible 8259 interrupt, the 8259 cascade handler
>> calls handle_fasteoi_irq to perform the actions noted above. However,
>> with the 8259 cascade handler hooked to the interrupt, the threaded IRQ
>> handler doesn't recognize it as one of the 4 standard generic IRQ types
>> and calls the threaded version of do_irq instead of the threaded fasteoi
>> handler.
> 
>    Ah, that's it!
> 
>> Once the threaded do_irq handler completes the action list, it
>> uses the .end routine to restart the interrupt flow. Pointing .end to
>> the standard MPIC unmask routine allows it to balance the interrupt mask
>> operation performed by handle_fasteoi_irq before it scheduled the IRQ
>> thread.
> 
>    Well, but when MPIC's eoi() method is called then? :-O
It's called from handle_fasteoi_irq as I described in the "basics" ;)

Randy V.

  reply	other threads:[~2007-06-07 19:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-07  0:47 [RFC] 85XX: Allow 8259 cascade to share an MPIC interrupt line Randy Vinson
2007-06-07 15:30 ` Jon Loeliger
2007-06-07 18:04   ` Randy Vinson
2007-06-07 17:14 ` Sergei Shtylyov
2007-06-07 19:25   ` Randy Vinson
2007-06-07 19:41     ` Sergei Shtylyov
2007-06-07 19:54       ` Randy Vinson [this message]
2007-06-07 20:04         ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4668628A.30401@mvista.com \
    --to=rvinson@mvista.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=sshtylyov@ru.mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.