[PATCH] Fallback to PCI IRQs for TI bridges

[PATCH] Fallback to PCI IRQs for TI bridges

[Pavel Roskin]

Hi, David and all!

David, I understand from the Linux MAINTAINERS file that you also maintain
the PCMCIA code in the kernel.  It's quite strange for me, because the
kernel code is quite different from what I used to see in pcmcia-cs.

Anyway, the kernel driver for TI bridges in the 2.4 series really needs to
be fixed.  It's becoming a FAQ in all mailing lists dealing with PCMCIA
devices - "what happens with interrupts?"

The bridges I'm using are configured to use ISA interrupts by default, but
it's PCI devices, which are not connected to the ISA bus in any way.
Here's the record from lspci:

00:0d.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus
Controller (rev 01)

pcmcia-cs takes the half-manual approach - the existing routing is used
unless the user overrides it by setting irq_mode.  This is not a good idea
- some bridges are misconfigured, and the user may not have a chance to
set module parameters, e.g. during the installation.

Kernel's yenta_socket in 2.4 series is too primitive to take care of the
problem.  The default routing is used.  ISA interrupts are probed.  If no
ISA interrupts are detected, the driver tries to use the PCI interrupt,
but the low-level commands to change routing are not issued.

yenta_socket in 2.5.63 knows different models of the bridges and sets IRQ
routing to PCI for certain models.  I don't really like this approach.
The chip can be integrated into the motherboard, and we don't know if the
ISA IRQ lines are connected or not.  The architecture may not support ISA
bus (e.g. PowerPC), then there will be no ISA interrupts, no matter what
chip is used.

I believe using PCI interrupts should not be considered as an inferior
approach compared to ISA interrupts.  The only driver I know that had
problems with PCI interrupts was ide-cs, but it's now fixed in the Alan's
tree, and hopefully in 2.4.21-pre5 (I didn't have a chance to test it).

Anyway, for the sake of backward compatibility, let's consider using PCI
interrupts a fallback that we use only if ISA interrupts don't work.

I have made a patch against 2.4.21-pre4-ac7 (it should work with all 2.4.x
kernels) that enables routing to PCI interrupts on TI bridges if no ISA
interrupts were detected.  I want to post it to the Linux list, although
I'm almost sure that it won't be applied.  At least it could start a
useful discussion, and maybe some Linux distributors will pick it.
Similar patch is needed for Ricoh bridges, but let's start with TI.

In my opinion, the problem with IRQ routing on PCI-to-PCMCIA bridges is a
major problem that needs to be addressed in 2.4 series.  Linux
distributors who chose to use kernel PCMCIA (e.g. Red Hat) should be
interested in working PCMCIA support.  I cannot count how many times I
asked Red Hat users to recompile the kernel without PCMCIA support when
they wrote me about IRQ problems.

Here's the patch for 2.4.x kernels:

======================================
--- linux.orig/drivers/pcmcia/ti113x.h
+++ linux/drivers/pcmcia/ti113x.h
@@ -167,6 +167,27 @@
 		new |= I365_INTR_ENA;
 	if (new != reg)
 		exca_writeb(socket, I365_INTCTL, new);
+
+	/*
+	 * If ISA interrupts don't work, then fall back to routing card
+	 * interrupts to the PCI interrupt of the socket.
+	 */
+	if (!socket->cap.irq_mask) {
+		int irqmux, devctl;
+
+		printk (KERN_INFO "ti113x: Routing card interrupts to PCI\n");
+
+		devctl = config_readb(socket, TI113X_DEVICE_CONTROL);
+		devctl &= ~TI113X_DCR_IMODE_MASK;
+
+		irqmux = config_readl(socket, TI122X_IRQMUX);
+		irqmux = (irqmux & ~0x0f) | 0x02; /* route INTA */
+		irqmux = (irqmux & ~0xf0) | 0x20; /* route INTB */
+
+		config_writel(socket, TI122X_IRQMUX, irqmux);
+		config_writeb(socket, TI113X_DEVICE_CONTROL, devctl);
+	}
+
 	return 0;
 }

======================================

-- 
Regards,
Pavel Roskin

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[Jeff Garzik]

Hey, nifty.

I bet this sort of thing is useful on more than just the ti113x...

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[Alan Cox]

On Sat, 2003-03-01 at 01:30, Pavel Roskin wrote:
> In my opinion, the problem with IRQ routing on PCI-to-PCMCIA bridges is a
> major problem that needs to be addressed in 2.4 series.  Linux
> distributors who chose to use kernel PCMCIA (e.g. Red Hat) should be
> interested in working PCMCIA support.  I cannot count how many times I
> asked Red Hat users to recompile the kernel without PCMCIA support when
> they wrote me about IRQ problems.

Lets tyr it in -ac and see what cooks

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[Pavel Roskin]

On Fri, 1 Mar 2003, Alan Cox wrote:

> On Sat, 2003-03-01 at 01:30, Pavel Roskin wrote:
> > In my opinion, the problem with IRQ routing on PCI-to-PCMCIA bridges is a
> > major problem that needs to be addressed in 2.4 series.  Linux
> > distributors who chose to use kernel PCMCIA (e.g. Red Hat) should be
> > interested in working PCMCIA support.  I cannot count how many times I
> > asked Red Hat users to recompile the kernel without PCMCIA support when
> > they wrote me about IRQ problems.
>
> Lets tyr it in -ac and see what cooks

Excellent!  By the way, please remove printk from my patch.  It turns out
that the socket is initialized more often than I expected (every time a
card is inserted), so it creates too much noise on the console.

I have tested a Ricoh bridge (Ricoh Co Ltd RL5c476 II), and it works
already, so let's not fix what is not broken, although I know what to do
if the IRQ problems are reported by someone else.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[David Hinds]

On Fri, Feb 28, 2003 at 08:30:36PM -0500, Pavel Roskin wrote:
> 
> David, I understand from the Linux MAINTAINERS file that you also maintain
> the PCMCIA code in the kernel.  It's quite strange for me, because the
> kernel code is quite different from what I used to see in pcmcia-cs.

Well, I'd have to say that I feel a little squeemish about being
called the maintainer of the kernel code because I don't feel I can
devote the time to it that it needs.  If someone else is willing to
step up I'd happily cede the job to them.

> yenta_socket in 2.5.63 knows different models of the bridges and sets IRQ
> routing to PCI for certain models.  I don't really like this approach.

I have not looked at the most recent 2.5.* kernels but if that is true
then you're right, it is ill conceived.

> The chip can be integrated into the motherboard, and we don't know if the
> ISA IRQ lines are connected or not.  The architecture may not support ISA
> bus (e.g. PowerPC), then there will be no ISA interrupts, no matter what
> chip is used.

Which raises an issue I've been wondering about, how to tell when a
kernel is being built for a system with ISA bus capabilities.  The
current code checks CONFIG_ISA but that's probably a bad idea.

> I believe using PCI interrupts should not be considered as an inferior
> approach compared to ISA interrupts.  The only driver I know that had
> problems with PCI interrupts was ide-cs, but it's now fixed in the Alan's
> tree, and hopefully in 2.4.21-pre5 (I didn't have a chance to test it).
> 
> Anyway, for the sake of backward compatibility, let's consider using PCI
> interrupts a fallback that we use only if ISA interrupts don't work.

This sounds fine to me.  I'd be concerned about giving up ISA
interrupts completely, that some of the less used drivers have never
been tested for compatibility with shared interrupts.

-- Dave

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[Jeff Garzik]

David Hinds wrote:
> On Fri, Feb 28, 2003 at 08:30:36PM -0500, Pavel Roskin wrote:
> 
>>David, I understand from the Linux MAINTAINERS file that you also maintain
>>the PCMCIA code in the kernel.  It's quite strange for me, because the
>>kernel code is quite different from what I used to see in pcmcia-cs.
> 
> 
> Well, I'd have to say that I feel a little squeemish about being
> called the maintainer of the kernel code because I don't feel I can
> devote the time to it that it needs.  If someone else is willing to
> step up I'd happily cede the job to them.


I can certainly understand that.  However, I do see occasionally code 
updates and help from you, so I just wanted to say -- thanks, a bunch, 
for the help you provide.  Even if you're not officially dubbed 
"maintainer", your knowledge is invaluable.

Thanks!

	Jeff

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[Pavel Roskin]

Hi, David!

> > yenta_socket in 2.5.63 knows different models of the bridges and sets IRQ
> > routing to PCI for certain models.  I don't really like this approach.
>
> I have not looked at the most recent 2.5.* kernels but if that is true
> then you're right, it is ill conceived.

I'm not aware of the "political" situation around PCMCIA drivers, but I
think it's sad that the kernel drivers are pushed (e.g. by Red Hat) in the
hope that they will get more visibility and will be improved, but the
people who have the best expertize still use pcmcia-cs drivers and work on
improving them.

I just found that my patch for checking SOCKET_PRESENT flag in
access_configuration_register() and many other functions has not been
propagated to the kernel (I'll send a separate patch), so removing a card
using e.g. the HostAP driver still results in a kernel oops.

> > The chip can be integrated into the motherboard, and we don't know if the
> > ISA IRQ lines are connected or not.  The architecture may not support ISA
> > bus (e.g. PowerPC), then there will be no ISA interrupts, no matter what
> > chip is used.
>
> Which raises an issue I've been wondering about, how to tell when a
> kernel is being built for a system with ISA bus capabilities.  The
> current code checks CONFIG_ISA but that's probably a bad idea.

I think it CONFIG_ISA is meant to be that.  The "ISA support" is so
trivial from the kernel perspective, that the line between systems with
and without ISA is somewhat blurred.

I have an Geode-based embedded system that has no ISA slots, but it has
ISA devices (like serial ports) on the southbridge chip, and it also has
an integrated Ricoh Cardbus/PCMCIA controller, which can use both ISA and
PCI interrupts for cards.

If ISA is disabled, then the PCMCIA socket driver shouldn't even probe ISA
interrupts.  Also, the serial ports and probably the PS/2 keyboard should
be disabled.  This still leaves a working system if USB keyboard is used.
On the other hand, I don't know if it's such a good idea for an i386-based
system and whether it will save any significant amount of memory.

>From the practical point of view, ISA interrupts should be probed if there
are necessary functions for that.  Leave it to the architecture-specific
functions, like probe_irq_on() to decide whether they want to try
something for real or not.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[Jeff Garzik]

On Mon, Mar 03, 2003 at 12:26:54PM -0500, Pavel Roskin wrote:
> Hi, David!
> 
> > > yenta_socket in 2.5.63 knows different models of the bridges and sets IRQ
> > > routing to PCI for certain models.  I don't really like this approach.
> >
> > I have not looked at the most recent 2.5.* kernels but if that is true
> > then you're right, it is ill conceived.
> 
> I'm not aware of the "political" situation around PCMCIA drivers, but I
> think it's sad that the kernel drivers are pushed (e.g. by Red Hat) in the
> hope that they will get more visibility and will be improved, but the
> people who have the best expertize still use pcmcia-cs drivers and work on
> improving them.

Red Hat "pushes" exactly what the Linux community supports:

This is also called "tracking upstream" and/or "working with the Linux
community, and following the Linux community's decisions."  This is
_not_ a political situation at all.  We simply ship what the community
supports.  Red Hat would not be good "open source citizens" if they did
otherwise.

Taking off my Red hat, and donning my "personal opinion" hat, I think
the kernel cardbus support has been very effectively.  It allows drivers
such as tulip and 8139too and epic100 and 3c59x to Just Work(tm),
without any modification besides PCI id table updates.  Nothing external
required.  That's a huge boon to programmers and maintainers.

	Jeff

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[David Hinds]

On Mon, Mar 03, 2003 at 12:26:54PM -0500, Pavel Roskin wrote:
> 
> I'm not aware of the "political" situation around PCMCIA drivers, but I
> think it's sad that the kernel drivers are pushed (e.g. by Red Hat) in the
> hope that they will get more visibility and will be improved, but the
> people who have the best expertize still use pcmcia-cs drivers and work on
> improving them.

I don't think it is a political issue.  I think the kernel drivers
should be promoted and I've encourated other distributions to go that
route as well.  And I hope that this leads to better drivers.  I do
maintenance work on the pcmcia-cs drivers but don't intend to add any
new functionality.

I've tried to update the kernel tree with fixes from individual PCMCIA
client drivers in the pcmcia-cs package.  The divergence of the core
modules is pretty large, though, so it is not a simple "diff", and I
know I've missed things.

I do not have time to be a more active maintainer these days, either
of pcmcia-cs or of the kernel PCMCIA drivers.

> I think it CONFIG_ISA is meant to be that.  The "ISA support" is so
> trivial from the kernel perspective, that the line between systems with
> and without ISA is somewhat blurred.

I don't really know what the scope of CONFIG_ISA should be.  I think
now it is mainly used to show or hide drivers for ISA cards, rather
than describing a system capability.

-- Dave

Re: [PATCH] Fallback to PCI IRQs for TI bridges

[Russell King]

On Mon, Mar 03, 2003 at 12:56:20PM -0800, David Hinds wrote:
> > I think it CONFIG_ISA is meant to be that.  The "ISA support" is so
> > trivial from the kernel perspective, that the line between systems with
> > and without ISA is somewhat blurred.
> 
> I don't really know what the scope of CONFIG_ISA should be.  I think
> now it is mainly used to show or hide drivers for ISA cards, rather
> than describing a system capability.

In my bunch of PCMCIA/Cardbus/PCI changes, I have one patch which
decouples CONFIG_ISA from the PCMCIA subsystem, replacing it with
CONFIG_PCMCIA_PROBE - on statically mapped PCMCIA systems (eg, SA1110)
all the region probing, resource handling, and interrupt stuff is
rather heavy weight.  However, decoupling it from CONFIG_ISA would
allow all that supporting code to remain when required for some socket
drivers.

I'm working through getting stuff tested and in to Linus in a reasonable
way.  Of course, this won't help for 2.4 based kernels, although the
CONFIG_PCMCIA_PROBE has existed in the ARM tree for a fair while and
could, given someone with enough motivation, the relevant changes could
be dug out and submitted to Marcello.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html