Re: MPC8240 EPIC Driver (Attached)

On Mon, Aug 13, 2001 at 10:56:09AM -0500, Andrew Johnson wrote:

Dan Malek wrote:

quoted

James F Dougherty wrote:

quoted

A while ago, I posted some questions on getting the OpenPIC driver working
correctly for the EPIC (Embedded Programmable Interrupt Controller) internal
to the MPC8240. After several attempts on open_pic.*, I gave up, and ported a
an existing driver.

Ummm, I'm confused.  The existing PowerPC OpenPIC works just fine with
the 8240/8245/MPC107 EPICs, at least on the Sandpoint.

Not quite - the Sandpoint has an i8259 as well, and the OpenPic code as
shipped with HHL-2.0 assumes that there is one present (at least you have
to link in the i8259 code, although you can arrange that it is never
called).  Not all 8240 systems have an 8259 such as the MVME2100, and I
had to #if out some stuff from OpenPic.c to be able to omit the i8259.

Then there's the problem of accessing the 8240's interrupts for I2C, 2 DMA
channels and Message Unit, which are highly dis-contiguous with the other
interrupts; these would appear at IRQs 129, 130, 131 and 134 in the
current scheme (needing a rather large and sparse interrupt senses
table).  Oh, and the 4 Global timer interrupts would have to appear at
negative IRQ numbers, so it's a good thing Linux doesn't need to use
these.

I haven't looked at James' code, but the OpenPIC stuff certainly does need
some changes to be truly universal.

There's a hack in the OpenPIC code for HHL 2.0 to allow for some of
the above situations.  The hack was rejected in the public tree in
favor of a not yet implemented clean way to handle this stuff.

If somebody has time to abstract the OpenPIC code for EPIC correctly,
it will get in the tree.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Matt Porter wrote:

On Mon, Aug 13, 2001 at 10:56:09AM -0500, Andrew Johnson wrote:

quoted

Then there's the problem of accessing the 8240's interrupts for I2C, 2 DMA
channels and Message Unit, which are highly dis-contiguous with the other
interrupts; these would appear at IRQs 129, 130, 131 and 134 in the
current scheme (needing a rather large and sparse interrupt senses
table).  Oh, and the 4 Global timer interrupts would have to appear at
negative IRQ numbers, so it's a good thing Linux doesn't need to use
these.

I haven't looked at James' code, but the OpenPIC stuff certainly does need
some changes to be truly universal.

There's a hack in the OpenPIC code for HHL 2.0 to allow for some of
the above situations.  The hack was rejected in the public tree in
favor of a not yet implemented clean way to handle this stuff.

If somebody has time to abstract the OpenPIC code for EPIC correctly,
it will get in the tree.

Yes, there should be better support for 8240/107 interrupt ctlrs in the openpic code.
However, as long as they are used in direct interrupt mode, the openpic code will work
as is for the most part (except for the negative irq's :).  Note that to use the
openpic_init()/initsenses table as it is, you need to skip the first 16 irq's no
matter what (i.e., even if you don't have an 8259).  DO NOT set the offset to anything
but 0 in the openpic_init() call.

The changes to the openpic code for supporting serial interrupt mode are very minor.

I sent out an email many moons ago about expanding the "initsenses" table but I never
really had to time to follow thru on it...I should have.  I still think that's the way
to go.

What I mean is a table where you specify the irq, the offset fo the regs from the base
address, the sensitivity, and the polarity all separately.  Also the appropriate
extensions to support serial interrupt mode (e.g., MVME2100 uses that).  With a table
format something like that, you can avoid the sparse and negative irq's on the
8240/107 and still keep things pretty clean looking.

Anyway, someone needs to take the time to do it...

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

"Mark A. Greer" wrote:

The changes to the openpic code for supporting serial interrupt mode are very minor.

Actually IIRC they're already present in the version shipped with
HHL-2.0.  I don't remember making any changes for that at all on the
MVME2100 support, but my memory has been known to be faulty.

What I mean is a table where you specify the irq, the offset fo the regs from the base
address, the sensitivity, and the polarity all separately.  Also the appropriate
extensions to support serial interrupt mode (e.g., MVME2100 uses that).  With a table
format something like that, you can avoid the sparse and negative irq's on the
8240/107 and still keep things pretty clean looking.

That sounds right.  It could also use the NIRQ field of the Feature
Reporting Register to cross-check that the table given is the correct size
for the chip it's controlling, and have some way of specifying the
presence or absensce of a cascaded i8259 (presumably with its own table).

- Andrew
--
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Andrew Johnson wrote:

"Mark A. Greer" wrote:

quoted

The changes to the openpic code for supporting serial interrupt mode are very minor.

Actually IIRC they're already present in the version shipped with
HHL-2.0.  I don't remember making any changes for that at all on the
MVME2100 support, but my memory has been known to be faulty.

Well, there is no _explicit_ support for serial mode but there was an 'if' stmt added that
adjusts NumSources if it is less than OpenPIC_NumInitSenses.  That let's you proceed with
an initsenses with more irq's than the pic tells you it has.  Its not a complete, long-term
solution.

Also, I'm trying to keep this discussion relative to 2_4_devel not hhlx.x

quoted

What I mean is a table where you specify the irq, the offset fo the regs from the base
address, the sensitivity, and the polarity all separately.  Also the appropriate
extensions to support serial interrupt mode (e.g., MVME2100 uses that).  With a table
format something like that, you can avoid the sparse and negative irq's on the
8240/107 and still keep things pretty clean looking.

That sounds right.  It could also use the NIRQ field of the Feature
Reporting Register to cross-check that the table given is the correct size
for the chip it's controlling, and have some way of specifying the
presence or absensce of a cascaded i8259 (presumably with its own table).

The NIRQ field is a part of the problem in serial mode.  You can have 16 lines hooked up in
serial mode and the NIRQ still tells you that there should only be 5, IIRC.

The table changes are intended to solve more than just epic serial mode.  They're intended
to make explicit--and flexible--all the assumptions that are currently buried in the
initsenses table (irq #, the offset of corresponding reg in pic, sensifivity and
polarity).  These aren't extensive changes, I should just do them, post a patch for review
& shut up...  :)

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

"Mark A. Greer" wrote:

Well, there is no _explicit_ support for serial mode but there was an 'if' stmt added that
adjusts NumSources if it is less than OpenPIC_NumInitSenses.  That let's you proceed with
an initsenses with more irq's than the pic tells you it has.  Its not a complete, long-term
solution.

There was something present that switches the chip between serial and
discrete mode.  Other than that and the actual location of the config
registers for each IRQ I don't think there's anything more needed to
distinguish the two in software.

Also, I'm trying to keep this discussion relative to 2_4_devel not hhlx.x

I'm only comparing to that as I'm not actively following 2_4_devel and
assume that those who need to know can relate hhl2.0 to some point in the
2_4_devel tree.

The NIRQ field is a part of the problem in serial mode.  You can have 16 lines hooked up in
serial mode and the NIRQ still tells you that there should only be 5, IIRC.

Actually it doesn't tell you that at all - from the EPIC documentation in
the 8240 manual, NIRQ provides the (fixed) maximum number of interrupt
sources supported by the EPIC.  On the 8240 the NIRQ value is 0x17=23
which corresponds to 24 interrupt sources (NIRQ=0 means 1 source),
comprising 16 serial IRQs, 4 timers, I2C, 2*DMA channels and the Mesage
Unit.  Nothing tells you where to find the config registers for those IRQs
though, hence the problems we're discussing.  The offset to the first
Serial or Direct IRQ config register is not accounted for in the NIRQ
number; it's only by chance that a discrete-mode EPIC works with the
OpenPic driver (check for off-by-1 errors BTW, see the above definition
for NIRQ).

The table changes are intended to solve more than just epic serial mode.  They're intended
to make explicit--and flexible--all the assumptions that are currently buried in the
initsenses table (irq #, the offset of corresponding reg in pic, sensifivity and
polarity).

As I understood, and I encourage you to implement them.  It looks like the
NIRQ check would have to be a maximum test only though, warn if the table
contains more than NIRQ-1 entries.

- Andrew
--
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Andrew Johnson wrote:

"Mark A. Greer" wrote:

quoted

Well, there is no _explicit_ support for serial mode but there was an 'if' stmt added that
adjusts NumSources if it is less than OpenPIC_NumInitSenses.  That let's you proceed with
an initsenses with more irq's than the pic tells you it has.  Its not a complete, long-term
solution.

There was something present that switches the chip between serial and
discrete mode.  Other than that and the actual location of the config
registers for each IRQ I don't think there's anything more needed to
distinguish the two in software.

That is correct in the code that I gave you.  Those particular pieces were not put in official
hhl2.0

quoted

The NIRQ field is a part of the problem in serial mode.  You can have 16 lines hooked up in
serial mode and the NIRQ still tells you that there should only be 5, IIRC.

Actually it doesn't tell you that at all - from the EPIC documentation in
the 8240 manual, NIRQ provides the (fixed) maximum number of interrupt
sources supported by the EPIC.  On the 8240 the NIRQ value is 0x17=23
which corresponds to 24 interrupt sources (NIRQ=0 means 1 source),

comprising 16 serial IRQs, 4 timers, I2C, 2*DMA channels and the Mesage
Unit.

All of this is correct, the problem is you have to put in 16 dummy entries at the beginning of
initsenses to get the registers to line up correctly.  When you add 16 serial external inputs to
the 16 dummies you end up with more than what NIRQ allows.

We're wasting bandwidth here, the real problem is that the current openpic_init interface isn't
quite flexible enough to suit the epic in anything but a vanilla, direct mode, external IRQ-only
set up.  That interface should be extended.

Mark

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/