Re: [PATCH and RFC] Remove request_8xxirq

Re: [PATCH and RFC] Remove request_8xxirq

[Benjamin Herrenschmidt]

>The other problem is the "namespace" of request_irq() usually assumes
>numbers 0 to 15 are an 8259, and many legacy devices are hardcoded to
>use these numbers.

Not that much actually. Look at pmac, I have nothing even close to
the 0..15 ISA namespace. Of course, a few crappy legacy ISA drivers
are broken, but we don't use them on PMAC, and you can eventually
hack them if you need them on embedded until a proper fix gets done.

BTW. At least serial.c is beeing redesigned by Russel King (ARM) ;)

Ben.


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

[PATCH and RFC] Remove request_8xxirq

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

The following two patches remove request_8xxirq and redesign how we
handle interrupts.  There's patches both against 2.5 (For inclusion
first, mainly for comment tho) and for 2.4 (which has been tested but is
intended for inclusion much later, probably 2.4.21 time-frame).

The new interrupt handling scheme allows all 8xx interrupt handlers to be
installed via the standard request_irq() function.  This required a
"flattened" representation of the interrupt vectors from all interrupt
controllers so that we can uniquely identify any interrupt source with a
single integer.  The interrupt vector numbers used by request_irq() are:

        request_irq vector      interrupt source
        ------------------      ----------------
        0 - 15                  SIU interrupt vectors 0 to 15
        16 - 47                 CPM interrupt vectors 0 to 31
        48 - 63                 8259 interrupt vectors 0 to 15 (MBX only)


In the 2.4 version of this patch, cpm_install_handler and request_8xxirq
still work as expected.   The 2.5 version removes both of bits of
backwards compatibility (since there will no doubt be numerous other
changes for drivers to take into consideration for 2.4.xx vs 2.6.xx).

The first benefit of all of these changes is that it gets PCI working on
MBX (and any other 8xx system with PCI).  The second benefit is that it
lets all of the otherwise properly written PCMCIA drivers just work
(such as orinoco_cs) which would previously panic() on request_irq().

The bulk of this work was done by Andy Lowe and then moved up to current
kernels and expanded slightly by myself.

Comments?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

[-- Attachment #2: 8xx_8260_irq-2.5.patch.gz --]
[-- Type: application/octet-stream, Size: 10434 bytes --]

[-- Attachment #3: 8xx_8260_irq.patch.gz --]
[-- Type: application/octet-stream, Size: 10103 bytes --]

Re: [PATCH and RFC] Remove request_8xxirq

[Dan Malek]

Tom Rini wrote:

> The first benefit of all of these changes is that it gets PCI working on
> MBX (and any other 8xx system with PCI).

No, it doesn't.  It just enables the 8259 to kinda work.  The PCI on MBX
does not work well, and this does nothing to improve it.  Does anyone have
a working MBX anymore?

> Comments?

There is more to these patches than just the interrupt change.  Why is
the CPM microcode, and so much of commproc.c changed?

Of course, I don't like it, but oh well.......It's just another hack that
doesn't do anything different.  Most importantly, I hate shit like this:

	request_irq(CPM_IRQ_OFFSET + CPMVEC_SMC2, ......

because you have to program the CPM with only the CPM vector number, not the
vector plus offset.  I want a real cascaded interrupt design, not just another
hack that opens the possibility to calling a generic PC function with the
wrong parameters.  The OpenPIC/EPIC are hacked just as badly, and there are
new integrated controllers coming that would benefit from a real design improvement
instead of just another hack.

I'm most concerned with the updates outside of just the interrupt stuff, and
I hope someone tests this.

Whatever you want......Have fun........


	-- Dan


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

Re: [PATCH and RFC] Remove request_8xxirq

[Wolfgang Denk]

In message <20020620203455.GG16052@opus.bloom.county> Tom Rini wrote:
>
> The following two patches remove request_8xxirq and redesign how we
> handle interrupts.  There's patches both against 2.5 (For inclusion
> first, mainly for comment tho) and for 2.4 (which has been tested but is
> intended for inclusion much later, probably 2.4.21 time-frame).
>
> The new interrupt handling scheme allows all 8xx interrupt handlers to be
> installed via the standard request_irq() function.  This required a
> "flattened" representation of the interrupt vectors from all interrupt
> controllers so that we can uniquely identify any interrupt source with a
> single integer.  The interrupt vector numbers used by request_irq() are:
>
>         request_irq vector      interrupt source
>         ------------------      ----------------
>         0 - 15                  SIU interrupt vectors 0 to 15
>         16 - 47                 CPM interrupt vectors 0 to 31
>         48 - 63                 8259 interrupt vectors 0 to 15 (MBX only)
...
> The bulk of this work was done by Andy Lowe and then moved up to current
> kernels and expanded slightly by myself.

Isn't this more or less  the  same  idea  as  presented  by  Wolfgang
Grandegger more than half a year ago? See

> Date: Sun, 28 Oct 2001 23:04:48 +0100
> From: Wolfgang Grandegger <wolfgang.grandegger@bluewin.ch>
> To: Tom Rini <trini@kernel.crashing.org>
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Multi-level CPM Interrupts

By then there was a common agreement that it was a bad idea from  the
beginning (although we need and use it for RTAI anyway).


It's amusing to see how ideas get recycled again and again.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A conservative is a man who believes that nothing should be done for
the first time.                                   - Alfred E. Wiggam

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

Re: [PATCH and RFC] Remove request_8xxirq

[Tom Rini]

On Thu, Jun 20, 2002 at 05:04:17PM -0400, Dan Malek wrote:
> Tom Rini wrote:
>
> >The first benefit of all of these changes is that it gets PCI working on
> >MBX (and any other 8xx system with PCI).
>
> No, it doesn't.  It just enables the 8259 to kinda work.  The PCI on MBX
> does not work well, and this does nothing to improve it.  Does anyone have
> a working MBX anymore?

Yes, Andy who did that part of the code and claims that PCI does indeed
work on it.

> >Comments?
>
> There is more to these patches than just the interrupt change.  Why is
> the CPM microcode, and so much of commproc.c changed?

I think I forgot to strip out a few things.  And so much of commproc.c
changed because the interrupt handling/assignment stuffs changed.  Aside
from the !CONFIG_UCODE_PATCH changes (which are seperate, I'll do those
later..) the rest is related to the changes themselves, or are updating
the callers to the new mechanisms (The old ones do still work and infact
did most of my testing that way).

> Of course, I don't like it, but oh well.......It's just another hack that
> doesn't do anything different.  Most importantly, I hate shit like this:
>
> 	request_irq(CPM_IRQ_OFFSET + CPMVEC_SMC2, ......
>
> because you have to program the CPM with only the CPM vector number, not the
> vector plus offset.

I don't follow you here.  Is this just another complaint about how the
normal way of handling cascades is ugly?

> I want a real cascaded interrupt design, not just
> another
> hack that opens the possibility to calling a generic PC function with the
> wrong parameters.

If a 'generic PC function' calls with the wrong parameters, fix the
function.  Right now we happily panic() on all of the correctly written
drivers as well as the broken ones.  This makes it possible to actually
test drivers to see which ones are broken and fix them.

> The OpenPIC/EPIC are hacked just as badly, and there are
> new integrated controllers coming that would benefit from a real design
> improvement instead of just another hack.

Perhaps sometime later in 2.5 a 'real design improvement' will happen.
But I also don't see what that has to do with this, other than the
8xx/8260 way of doing things is going.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: [PATCH and RFC] Remove request_8xxirq

[Wolfgang Denk]

In message <20020620214551.GI16052@opus.bloom.county> you wrote:
>
> > Isn't this more or less  the  same  idea  as  presented  by  Wolfgang
> > Grandegger more than half a year ago? See
>
> Pretty similar, yeap.
>
> > By then there was a common agreement that it was a bad idea from  the
> > beginning (although we need and use it for RTAI anyway).
>
> Well, Dan Malek didn't like it (and he doesn't like it again either).
> When you did this for RTAI, I assume (since I didn't look at the patch)

Grrrgh.. Why do we send a patch, when you don't even look at it?

> that in the end it was so RTAI wouldn't have to special-case 8xx things
> in the common code (ie request_irq() or cpm_install_handler()) ?

No. It's needed because otherwise you cannot register  a  RT  handler
for CPM interrupts.

> > It's amusing to see how ideas get recycled again and again.
>
> heh.

Well, actually my amusement is limited. This whole business how  some
patches  make  it  or  don't  make  it into some kernel tree is higly
frustrating.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Two wrongs don't make a right, but three rights make a left.

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

Re: [PATCH and RFC] Remove request_8xxirq

[Wolfgang Denk]

In message <3D124DF4.6060505@embeddededge.com> Dan Malek wrote:
>
> > Isn't this more or less  the  same  idea  as  presented  by  Wolfgang
> > Grandegger more than half a year ago? See
>
> Yes, it's very similar.  I thought this was just your stuff
> coming from someone else :-)

This is how I see it: we submit a patch, Tom Rini does not even  look
at  it,  it  gets rejected, and half a year later it pops up and "the
bulk of this work was done by" somebody else.

> it ever since :-)  All we get is one hack on top of another without the
> right solution (kinda like the PCI I/O accesses and mapping).

:-(

> > It's amusing to see how ideas get recycled again and again.
>
> Yeah, but the implementation is always slightly different :-)

Well, there is something needed to make "the bulk of this work".

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Technology is dominated by those who manage what they do  not  under-
stand.

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

Re: [PATCH and RFC] Remove request_8xxirq

[Dan Malek]

Tom Rini wrote:

> Yes, Andy who did that part of the code and claims that PCI does indeed
> work on it.

I know Andy is sitting on a ton of 82xx PCI changes that would be nice
to see checked in some day. :-)

> I don't follow you here.  Is this just another complaint about how the
> normal way of handling cascades is ugly?

Sort of.  The problem is you often have to program the CPM interrupt
vector for a particular device into the CPM.  For example, you may have
to tell the SCC2 device on the CPM what vector to use, which in turn
is also used to configure the interrupt controller.  Using this scheme
of this patch, these two numbers are different because you give request_irq()
a different number than you program into the CPM for this device.  There
are more and more integrated controllers that do this, and using hardcoded
values with offsets isn't going to work in those cases.

The other problem is the "namespace" of request_irq() usually assumes
numbers 0 to 15 are an 8259, and many legacy devices are hardcoded to
use these numbers.  Now, on the 8xx and 8260, you have changed what these
values mean.  I believe I saw a patch from Wolfgang that left request_irq()
alone (and left the other 8xx and CPM interrupt request functions as they were),
but in request_irq() he remapped the number to be something meaningful on 8xx.

I would kind of prefer his patches to this one.


> If a 'generic PC function' calls with the wrong parameters, fix the
> function.  Right now we happily panic() on all of the correctly written
> drivers as well as the broken ones.  This makes it possible to actually
> test drivers to see which ones are broken and fix them.

See Wolfgang's patches......

> Perhaps sometime later in 2.5 a 'real design improvement' will happen.
> But I also don't see what that has to do with this, other than the
> 8xx/8260 way of doing things is going.

The 8xx is more complicated due to its multiple cascaded interrupts.
The 8260 removed the CPM cascade, making it more simple to implement.
What do Andy's patches for 8260+PCI look like?  There has to be a
cascade in there someplace that isn't represented in any of these patches.


Thanks.


	-- Dan


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

Re: [PATCH and RFC] Remove request_8xxirq

[Tom Rini]

On Thu, Jun 20, 2002 at 06:03:42PM -0400, Dan Malek wrote:
>
> Tom Rini wrote:
>
> >Yes, Andy who did that part of the code and claims that PCI does indeed
> >work on it.
>
> I know Andy is sitting on a ton of 82xx PCI changes that would be nice
> to see checked in some day. :-)

Well, Andy says that to get PCI happy all he had to do was to stop using
request_8xxirq.  So that patch should make PCI nice 'n happy there, but
it's untested.

> >I don't follow you here.  Is this just another complaint about how the
> >normal way of handling cascades is ugly?
>
> Sort of.  The problem is you often have to program the CPM interrupt
> vector for a particular device into the CPM.  For example, you may have
> to tell the SCC2 device on the CPM what vector to use, which in turn
> is also used to configure the interrupt controller.  Using this scheme
> of this patch, these two numbers are different because you give
> request_irq()
> a different number than you program into the CPM for this device.  There
> are more and more integrated controllers that do this, and using hardcoded
> values with offsets isn't going to work in those cases.

'hardcoded == bad', mental note made.

> The other problem is the "namespace" of request_irq() usually assumes
> numbers 0 to 15 are an 8259, and many legacy devices are hardcoded to
> use these numbers.  Now, on the 8xx and 8260, you have changed what these
> values mean.  I believe I saw a patch from Wolfgang that left request_irq()
> alone (and left the other 8xx and CPM interrupt request functions as they
> were),
> but in request_irq() he remapped the number to be something meaningful on
> 8xx.
>
> I would kind of prefer his patches to this one.

I believe this is tied into the "let the good drivers actually work and
the bad ones give a 'meaningful' blow-up" part of the patch.

> >If a 'generic PC function' calls with the wrong parameters, fix the
> >function.  Right now we happily panic() on all of the correctly written
> >drivers as well as the broken ones.  This makes it possible to actually
> >test drivers to see which ones are broken and fix them.
>
> See Wolfgang's patches......

I don't see how that fixes the panic() in request_irq().

> >Perhaps sometime later in 2.5 a 'real design improvement' will happen.
> >But I also don't see what that has to do with this, other than the
> >8xx/8260 way of doing things is going.
>
> The 8xx is more complicated due to its multiple cascaded interrupts.
> The 8260 removed the CPM cascade, making it more simple to implement.
> What do Andy's patches for 8260+PCI look like?  There has to be a
> cascade in there someplace that isn't represented in any of these patches.

He says they just work.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: [PATCH and RFC] Remove request_8xxirq

[Andy Lowe]

I guess since my name keeps coming up in this thread I should weigh in.

Dan Malek wrote:
> There is more to these patches than just the interrupt change. Why is
> the CPM microcode, and so much of commproc.c changed?

As Tom already replied, the CPM microcode stuff was included by mistake.  I
wouldn't necessarily recommend submitting that stuff as a separate patch
either.  There are also a few other perfectly good bits and pieces of code
that found their way into the patch that aren't relevant:  the SPI stuff in
commproc.h, the PCI and PCMCIA stuff in mbx.h, and the Ethernet stuff in
rpxclassic.h.

Dan Malek wrote:
> The PCI on MBX does not work well, and this does nothing to improve it.
Does
> anyone have a working MBX anymore?

This patch does not fix PCI on the MBX because additional changes are
necessary to the qspan host bridge code.  However, it does facilitate making
PCI work on the MBX and other 8xx designs because it allows request_irq() to
work, which all PCI device drivers use to install their interrupt handlers.
I have a working MBX, and with these changes to the interrupt handling and a
few additional changes to the qspan host bridge support, PCI cards seem to
work in it just fine.  I have successfully tested a Matrox video card,
several different Ethernet cards, and an MPEG decoder.  I also used these
same interrupt handling changes on a custom 860 board with a qspan bridge
that had PCI interrupts pinned out to both SIU IRQs and CPM Port C
interrupts instead of an 8259, and that worked as well.

Dan Malek wrote:
> I know Andy is sitting on a ton of 82xx PCI changes that would be nice
> to see checked in some day. :-)

I did do some work once on a custom 8260 board with an external PCI host
bridge.  I didn't have to do anything to the 8260 interrupt handling other
than rename request_8xxirq to request_irq so that PCI device drivers would
work without modification.  Other than that, it was just a matter of
implementing the host bridge support and PCI interrupt routing table
similarly to the way it is done on, say, the 7xx board ports.

Wolfgang Denk wrote:
> Isn't this more or less the same idea as presented by Wolfgang Grandegger
more
> than half a year ago?

Yes, it is more or less the same idea.  There is an important difference
between our approaches, however.  Wolfgang's approach was to extend
request_8xxirq() so that it would handle CPM interrupts as well as SIU
interrupts.  My approach was to make request_irq() work for SIU interrupts,
CPM interrupts, and any other interrupt controller (like an 8259) you might
have on a particular board.  I also implemented it in a way that allows you
to simultaneously continue using request_8xxirq() and cpm_install_handler()
in the same manner as always without the need for any kernel configuration
options.  (Tom changed every instance of cpm_install_handler and
request_8xxirq to request_irq in his version of the patch, but that isn't
strictly necessary.)  My motivation for doing this in the first place was to
make request_irq() work for all interrupts on 8xx targets so that standard
PCI and PCMCIA device drivers will work without having to put #ifdef's in
each driver to change request_irq to request_8xxirq or cpm_install_handler.

Now as for the argument that this patch is fatally flawed because IRQ
vectors 0 to 15 aren't reserved for 8259 interrupts, I don't find that to be
compelling.  PCI cards work just fine on the MBX with no modifications to
the drivers when using IRQ vectors 48 to 63 for the 8259.  You just stick
the right IRQ vectors in the PCI interrupt routing table and all PCI device
drivers will happily use them without prejudice.  PCMCIA and IDE drivers
also work fine.  The only possible issue I see is with legacy ISA drivers
with hardcoded IRQ vectors in the range 0 to 15.  I've never had an occasion
to use such a driver on an 8xx target, but if it came down to it I would
prefer to stick a #ifdef in an ISA device driver to hardcode a different IRQ
vector than to stick a #ifdef in every PCI and PCMCIA device driver to make
them call request_8xxirq or cpm_install_handler instead of request_irq.

Andy


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

Re: [PATCH and RFC] Remove request_8xxirq

[Dan Malek]

Andy Lowe wrote:

> .... My motivation for doing this in the first place was to
> make request_irq() work ....

Any 8xx that included a PCI configuration had request_irq() defined.
One of the things Wolfgang did was to map callers of request_irq() to
interrupts that made sense on a particular hardware design.  That is
the only change that should have been necessary.  None of the other
changes, especially to change all of the other irq requests to call
request_irq() were necessary.

> ..... but if it came down to it I would
> prefer to stick a #ifdef in an ISA device driver to hardcode a different IRQ
> vector than to stick a #ifdef in every PCI and PCMCIA device driver to make
> them call request_8xxirq or cpm_install_handler instead of request_irq.

The proper solution is to implement a request_irq() function that will
map interrupts properly for the board design, not modify everything to use
that function.  You can have a board design that connects the PCI interrupt
lines to GPIOs or external interrupt lines, and in that case request_irq()
would have to know what PCI interrupt numbers are used and would map them
to a CPM interrupt.  Along with that comes other special SIU configuration,
so it's uniqueness is quite evident.

This patch works for exactly one board design like the MBX, that uses an 8259
connected in a particular way for PCI interrupts.  It isn't a general solution
and may not work properly for the example I mentioned above.

Thanks.


	-- Dan


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

RE: [PATCH and RFC] Remove request_8xxirq

[Andy Lowe]

Dan Malek wrote:
> Any 8xx that included a PCI configuration had request_irq() defined.
> One of the things Wolfgang did was to map callers of request_irq() to
> interrupts that made sense on a particular hardware design.  That is
> the only change that should have been necessary.  None of the other
> changes, especially to change all of the other irq requests to call
> request_irq() were necessary.

As I pointed out, it isn't necessary to change the existing request_8xxirq
and cpm_install_handler functions to request_irq.  You can continue to use
the old favorites if that is your preference, although frankly I don't
understand the attraction of request_8xxirq and cpm_install_handler.

> The proper solution is to implement a request_irq() function that will
> map interrupts properly for the board design, not modify everything to use
> that function.

You have it backwards.  Every Linux device driver in the known universe
except a few 8xx-specific drivers already use request_irq to install
interrupt handlers.  All the patch does is allow request_irq to work on 8xx
targets the same as on every other architecture supported by Linux.

> You can have a board design that connects the PCI interrupt
> lines to GPIOs or external interrupt lines, and in that case request_irq()
> would have to know what PCI interrupt numbers are used and would map them
> to a CPM interrupt.  Along with that comes other special SIU
> configuration, so it's uniqueness is quite evident.

Not only can you have such a design, but as I pointed out I have already
used this patch on an 8xx design with a qspan bridge that uses a mixture of
both SIU and CPM Port C interrupts for PCI interrupts instead of an 8259.
It fits beautifully into this scheme with absolutely no additional changes
to request_irq.  In the PCI interrupt routing table for the board, the PCI
interrupts that are routed to SIU IRQs have IRQ vectors in the range 0 to
15.  The PCI interrupts that are routed to CPM interrupts have IRQ vectors
in the range 16 to 47.  A PCI device driver will look up its assigned IRQ
vector via the normal method and will use it as the interrupt vector
argument to request_irq.  The interrupt handler installation works
regardless of whether the corresponding vector is mapped to the SIU or to
the CPM interrupt controller, and this detail is completely transparent to
the device driver.  Interrupt handler installation works properly in all
cases with no modifcations required to any existing PCI device driver.

> This patch works for exactly one board design like the MBX, that
> uses an 8259 connected in a particular way for PCI interrupts.

This same technique can work for all 8xx boards with any number of external
interrupt controllers cascaded in any fashion you please.  It works with no
modifcations whatsoever on every 8xx board that has no external interrupt
controllers.

Andy


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

RE: [PATCH and RFC] Remove request_8xxirq

[Stephan Linke]

Hi,

why not simply placing a new request_cascaded_irq() with an additional
controller/device identifier beside request_irq().

If you map the functionality to the original functions the rest of the code
could stay unchanged.
You can even map the old function calls using macros.
(If you like to you can use device 0 for a virtual mapping too. But I
wouldn't. :)

request_irq() could be left unchanged and new patches could use a single
registration function. So everyone should stay happy.

Stephan


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

Re: [PATCH and RFC] Remove request_8xxirq

[Tom Rini]

On Fri, Jun 21, 2002 at 11:48:23AM +0200, Wolfgang Grandegger wrote:
> Hello,
>
> I jump into the discussion as well.
>
> On 06/21/2002 12:10 AM, Tom Rini wrote:
>
> >Well, I looked at it (after I sent but before your mail) and it wasn't a
> >patch but some cut'n paste bits.  And to possibly Dan's dismay I don't
> >always agree with his opinions now :)
> >
>
> I first wanted to present my ideas ... before I prepare and send a
> patch.

For future reference, unified diffs are the preferred way to present
ideas which you've already implemented. :)

> >Well, having never used RTAI (and by looking at the 'patch' at
> >http://lists.linuxppc.org/linuxppc-embedded/200110/txt00002.txt) I don't
> >get it..
>
> RTAI and RTLinux actually use the "irq_desc[].handler" functions to
> handle the interrupts and with the previous cpm_* functions it was
> non-trivial to access CPM interrupts within RTAI because they are
> handled in a separate interface.

Ah, which is why you just expanded things the way you did..  Which works
for that context but still leaves the larger problem of request_irq()
panic()'ing on unknown interrupt numbers.

[snip]
> I understand DAN's argument, that the usage of an offset can be quite
> messy especially during driver development but I cannot see a simple
> way around it without breaking the (PC) "request_irq" function.

Well maybe Dan will get encouraged enough to try and properly fix
request_irq() and break some of the legacy PC drivers in 2.5 again. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: [PATCH and RFC] Remove request_8xxirq

[Dan Malek]

Tom Rini wrote:

> Ah, which is why you just expanded things the way you did..  Which works
> for that context but still leaves the larger problem of request_irq()
> panic()'ing on unknown interrupt numbers.

All you need to do is modify request_irq() to check/map the numbers that
are OK for you to use on your system.  The problem with request_irq() is
it is easy to pass a number you think is fine from some legacy perspective,
but it messes up the SIU due to "numberspace" overlap.  To trap these and
print out a message saves lots of traffic on this mailing list :-)


> Well maybe Dan will get encouraged enough to try and properly fix
> request_irq() and break some of the legacy PC drivers in 2.5 again. :)

I can't break it until I dredge up some of the stuff we did way back in 2.1.xx
and get it to stick.  Unless we have the underlying mechanism to manage
an arbitrary, cascaded interrupt controller, all we have are processor and
platform specific hacks with functions that behave differently.  I guess
I can do it for PPC only, and then hope this time it gets generally
integrated entirely.  In this case, there will be a different function name,
as request_irq() will be left as some macro or simple function for
legacy compatibility.

Thanks.


	-- Dan


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

Re: [PATCH and RFC] Remove request_8xxirq

[Tom Rini]

On Mon, Jun 24, 2002 at 01:49:28PM -0400, Dan Malek wrote:
> Tom Rini wrote:
>
> >Ah, which is why you just expanded things the way you did..  Which works
> >for that context but still leaves the larger problem of request_irq()
> >panic()'ing on unknown interrupt numbers.
>
> All you need to do is modify request_irq() to check/map the numbers that
> are OK for you to use on your system.  The problem with request_irq() is
> it is easy to pass a number you think is fine from some legacy perspective,
> but it messes up the SIU due to "numberspace" overlap.  To trap these and
> print out a message saves lots of traffic on this mailing list :-)

First, I'm not so sure that it does save a lot of traffic.  The number
of bad legacy drivers is rather small now, and the ones which _might_
ever be accidently enabled on 8xx are limited to CONFIG_SERIAL I would
think.
Second, if it does become a problem, we should look into grabbing the
ChangeSet from Andi Kleen (and a few others) that masks off legacy
drivers under CONFIG_ISA since they don't work on x86-64 (and probably
ia64).  So the x86 world is finally almost caring about this problem :)
Finally, it's not the 'linux way' to preemptivly shoot users in the head
in case they might do something bad to their machine.  (And the mapping
doesn't always work anyhow, the ne2k PCMCIA card I've got doesn't work
due to some actual driver issue that I'll look into sometime maybe..
:)).

> >Well maybe Dan will get encouraged enough to try and properly fix
> >request_irq() and break some of the legacy PC drivers in 2.5 again. :)
>
> I can't break it until I dredge up some of the stuff we did way back in
> 2.1.xx
> and get it to stick.  Unless we have the underlying mechanism to manage
> an arbitrary, cascaded interrupt controller, all we have are processor and
> platform specific hacks with functions that behave differently.  I guess
> I can do it for PPC only, and then hope this time it gets generally
> integrated entirely.  In this case, there will be a different function name,
> as request_irq() will be left as some macro or simple function for
> legacy compatibility.

Go for it...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: [PATCH and RFC] Remove request_8xxirq

[Dan Malek]

Tom Rini wrote:

> They're provided to keep compatibility.  I do want to see this get into
> 2.4, and breaking somebodys already working custom driver in 2.4 is bad.

Let's just do the minimal changes in 2.4 to make request_irq() work for
stuff like the PCMCIA drivers.  Forget about the 8259, as I think the only
board that uses it is the MBX, and if people really need it, they can hack
something in as it hasn't worked for years anyway.

> They're gone in the 2.5 version of the patch (since a driver supporting
> 2.5/2.6 will have all sorts of other compatibility macros anyhow).

I'm working on 2.5 now, and I'll implement something better/different
that may not ever make it into 2.4.  Also, you guys have removed all of
the intercepts for RTLinux and RTAI, so I need to put that back in
as well as create an interface for the interrupts.


	-- Dan


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