this patch adds override functions for the ToPIC family of controllers.
also adds the device id for ToPIC100 and (untested) support for zoom
video for ToPIC97/100.
tested with start/stop and suspend/resume.
--- 1.3/drivers/pcmcia/topic.h Sat Oct 19 01:11:25 2002
+++ edited/drivers/pcmcia/topic.h Wed Aug 6 19:25:39 2003
@@ -93,4 +93,60 @@
#define TOPIC97_RCR_CAUDIO_OFF 0x00000002
#define TOPIC_RCR_CAUDIO_INVERT 0x00000001
+#define TOPIC97_ZOOM_VIDEO_CONTROL 0x009c /* 8 bit */
+#define TOPIC97_ZOOM_VIDEO_ENABLE 0x01
+
+/* general ToPIC stuff */
+static int topic_init(struct pcmcia_socket *sock)
+{
+ struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
+ u8 val;
+
+ yenta_init(sock);
+
+ /* enable CB, CB/PCCARD regs, lock ID */
+ val = config_readb(socket, TOPIC_SLOT_CONTROL);
+ val |= TOPIC_SLOT_SLOTON | TOPIC_SLOT_SLOTEN | TOPIC_SLOT_ID_LOCK |
+ TOPIC_SLOT_ID_WP;
+ config_writeb(socket, TOPIC_SLOT_CONTROL, val);
+
+ /* enable CB, HW change detect */
+ val = config_readb(socket, TOPIC_CARD_DETECT);
+ val |= TOPIC_CDR_MODE_PC32;
+ val &= ~TOPIC_CDR_SW_DETECT;
+ config_writeb(socket, TOPIC_CARD_DETECT, val);
+
+ return 0;
+}
+
+static int topic_override(struct yenta_socket *socket)
+{
+ socket->socket.ops->init = topic_init;
+ return 0;
+}
+
+/* ToPIC97/100 stuff */
+static void topic97_zoom_video(struct pcmcia_socket *sock, int onoff)
+{
+ struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
+ config_writeb(socket, TOPIC97_ZOOM_VIDEO_CONTROL,
+ onoff? TOPIC97_ZOOM_VIDEO_ENABLE: 0);
+}
+
+static int topic97_init(struct pcmcia_socket *sock)
+{
+ topic_init(sock);
+
+ /* ToPIC97/100 support ZV */
+ sock->zoom_video = topic97_zoom_video;
+
+ return 0;
+}
+
+static int topic97_override(struct yenta_socket *socket)
+{
+ socket->socket.ops->init = topic97_init;
+ return 0;
+}
+
#endif /* _LINUX_TOPIC_H */
--- 1.35/drivers/pcmcia/yenta_socket.c Sun Aug 3 17:05:56 2003
+++ edited/drivers/pcmcia/yenta_socket.c Wed Aug 6 17:27:24 2003
@@ -769,6 +769,7 @@
#include "ti113x.h"
#include "ricoh.h"
+#include "topic.h"
/*
* Different cardbus controllers have slightly different
@@ -809,6 +810,11 @@
{ PD(RICOH,RL5C475), &ricoh_override },
{ PD(RICOH,RL5C476), &ricoh_override },
{ PD(RICOH,RL5C478), &ricoh_override },
+
+ { PD(TOSHIBA,TOPIC95_A), &topic_override },
+ { PD(TOSHIBA,TOPIC95_B), &topic_override },
+ { PD(TOSHIBA,TOPIC97), &topic97_override },
+ { PD(TOSHIBA,TOPIC100), &topic97_override },
{ }, /* all zeroes */
};
--- 1.112/include/linux/pci_ids.h Wed Aug 6 00:37:33 2003
+++ edited/include/linux/pci_ids.h Wed Aug 6 16:55:04 2003
@@ -1310,6 +1310,7 @@
#define PCI_DEVICE_ID_TOSHIBA_601 0x0601
#define PCI_DEVICE_ID_TOSHIBA_TOPIC95 0x060a
#define PCI_DEVICE_ID_TOSHIBA_TOPIC97 0x060f
+#define PCI_DEVICE_ID_TOSHIBA_TOPIC100 0x0617
#define PCI_VENDOR_ID_TOSHIBA_2 0x102f
#define PCI_DEVICE_ID_TOSHIBA_TX3927 0x000a
On Wed, Aug 06, 2003 at 08:25:08PM +0200, Daniel Ritz wrote:
> this patch adds override functions for the ToPIC family of controllers.
> also adds the device id for ToPIC100 and (untested) support for zoom
> video for ToPIC97/100.
>
> tested with start/stop and suspend/resume.
We currently have some fairly serious IRQ problems with yenta at the
moment. I'm holding all patches until we get this problem resolved -
it seems to be caused by several bad changes over the past couple of
years accumulating throughout the 2.5 series.
Therefore, I don't want to add any further changes into the mix just
yet.
Also, assigning to socket->socket.ops->init modifies the global
yenta_socket_operations structure, which I'm far from happy about.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Wed, 6 Aug 2003, Russell King wrote:
> On Wed, Aug 06, 2003 at 08:25:08PM +0200, Daniel Ritz wrote:
> > this patch adds override functions for the ToPIC family of controllers.
> > also adds the device id for ToPIC100 and (untested) support for zoom
> > video for ToPIC97/100.
> >
> > tested with start/stop and suspend/resume.
>
> We currently have some fairly serious IRQ problems with yenta at the
> moment. I'm holding all patches until we get this problem resolved -
> it seems to be caused by several bad changes over the past couple of
> years accumulating throughout the 2.5 series.
I read the PCMCIA list, but not LKML, and I have no idea what problems you
are talking about. Could you please explain of give a pointer to a
previous post? I could cross-check the problem against plx9052 driver.
I'm sorry for asking you to spend some time and possibly repeat something
that was said before, but sometimes talking about the problem makes it
easier to understand it and find the best solution.
> Also, assigning to socket->socket.ops->init modifies the global
> yenta_socket_operations structure, which I'm far from happy about.
The same is done for TI and Ricoh bridges. Just search the sources for
"socket->socket.ops->init". You may have a good reason to be unhappy, but
coherent code is normally easier to fix than a bunch of different hacks.
--
Regards,
Pavel Roskin
On Wed, Aug 06, 2003 at 03:07:21PM -0400, Pavel Roskin wrote:
> I read the PCMCIA list, but not LKML, and I have no idea what problems you
> are talking about. Could you please explain of give a pointer to a
> previous post? I could cross-check the problem against plx9052 driver.
It's fairly complex. Let's just summerise it as "yenta texas instruments
IRQ routing fucked up" 8) The chip has a bunch of registers to control
what signals get routed to which physical pins, and it seems that between
June 2002 and today, some bad changes happened. I'm currently trying to
track down each one, but, as there have been several levels of patching
going on, it isn't simple.
> The same is done for TI and Ricoh bridges. Just search the sources for
> "socket->socket.ops->init". You may have a good reason to be unhappy, but
> coherent code is normally easier to fix than a bunch of different hacks.
Yep, and I'm going to fix them as part of my present work.
Think about what happens to ->init with the current system when you
have two different cardbus controllers in the same machine.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Wed, 6 Aug 2003, Russell King wrote:
> On Wed, Aug 06, 2003 at 03:07:21PM -0400, Pavel Roskin wrote:
> > I read the PCMCIA list, but not LKML, and I have no idea what problems
> > you are talking about. Could you please explain of give a pointer to
> > a previous post? I could cross-check the problem against plx9052
> > driver.
>
> It's fairly complex. Let's just summarize it as "yenta texas
> instruments IRQ routing fucked up" 8) The chip has a bunch of registers
> to control what signals get routed to which physical pins, and it seems
> that between June 2002 and today, some bad changes happened. I'm
> currently trying to track down each one, but, as there have been several
> levels of patching going on, it isn't simple.
I thought you mean something more fundamental. This problem really should
not stand in the way of changes unrelated to the TI bridges, such as the
ToPIC patch.
TI bridges have 3 different interrupt routing methods. The i82365 manual
from pcmcia-cs lists all three - PCI interrupts, ISA interrupts and ISA
interrupts routed via an external serial interrupt controller.
PCI cards without an additional ISA connector always use PCI interrupts.
PowerPC architecture also requires PCI interrupts. Laptops may use any of
three routing methods, but some of those methods may not work.
The i82365 driver from pcmcia-cs used the preexisting configuration by
default, which was OK for most laptops, but not for standalone PCI cards.
2.5 kernels introduced a device table to determine the interrupt delivery
method. I criticized this approach, and wrote a patch that would turn on
ISA interrupts if the PCI interrupt delivery failed. This patch was
applied by Alan Cox to the 2.4 tree.
Unfortunately, I forgot about bridges using external serial interrupt
controllers (I have no idea what it means). It was reported that such
bridges were also probed for PCI interrupts, and after failing that,
reconfigured to the normal ISA interrupt delivery, which didn't work
either.
Unfortunately I was to busy to respond and didn't have anything but a PCI
card. I saw some activity on the 2.4 branch to work around this problem.
My patch was also ported to the 2.5 branch.
The problem with TI bridges is that there are at least 3 types of them
that needs to be tested, and I only have one of them.
If there is a desire to do it right this time, and if the problem is
considered serious to spend some time on it, here's how I would do it.
- Never trust preexisting configuration. Always probe the interrupts.
- Use PCI ID only to disable access to unsupported registers, not to
find the best IRQ routing.
- Cache the probe results until yenta_socket is unloaded. Probe
interrupts once per socket (i.e. 2 times for two-socket cards).
- Probe PCI interrupts first.
- Probe ISA interrupts next, only if there are free interrupts and the
architecture allows ISA interrupts.
- Probe serial ISA interrupts under the same conditions.
- If all probes fail, deny interrupt requests from clients. This would
allow some memory cards.
I can write this code, but I only have a PCI card to test.
--
Regards,
Pavel Roskin
On Wed August 6 2003 20:44, Russell King wrote:
> On Wed, Aug 06, 2003 at 08:25:08PM +0200, Daniel Ritz wrote:
> > this patch adds override functions for the ToPIC family of controllers.
> > also adds the device id for ToPIC100 and (untested) support for zoom
> > video for ToPIC97/100.
> >
> > tested with start/stop and suspend/resume.
>
> We currently have some fairly serious IRQ problems with yenta at the
> moment. I'm holding all patches until we get this problem resolved -
> it seems to be caused by several bad changes over the past couple of
> years accumulating throughout the 2.5 series.
yep, i saw the mails on lkml...
>
> Therefore, I don't want to add any further changes into the mix just
> yet.
ok. the topic code is low-prio as these chips works mostly w/o the patch.
my craptop just fucks up in 1 of 30 boots or so.
>
> Also, assigning to socket->socket.ops->init modifies the global
> yenta_socket_operations structure, which I'm far from happy about.
yes, i saw that too, but copy-pasted from the other overrides to fix up
in the next patch...i think ->init should always point to yenta_init,
the additional init function should be called from inside there, before
activating the interrupts...wanna have a patch?
-daniel
ps: in a few days, when i get my other laptop back, i have access to one of
those TI chips with all the nice problems (ie. under FreeBigStinkyDaemon the
machine dies under an interrupt storm when activating the socket) so i could
also test the irq routing and other fixes a bit.
Pavel Roskin wrote:
>>It's fairly complex. Let's just summarize it as "yenta texas
>>instruments IRQ routing fucked up" 8) The chip has a bunch of registers
>>to control what signals get routed to which physical pins, and it seems
>>that between June 2002 and today, some bad changes happened. I'm
>>currently trying to track down each one, but, as there have been several
>>levels of patching going on, it isn't simple.
>>
>>
>
>I thought you mean something more fundamental. This problem really should
>not stand in the way of changes unrelated to the TI bridges, such as the
>ToPIC patch.
>
>TI bridges have 3 different interrupt routing methods. The i82365 manual
>from pcmcia-cs lists all three - PCI interrupts, ISA interrupts and ISA
>interrupts routed via an external serial interrupt controller.
>
>
>PCI cards without an additional ISA connector always use PCI interrupts.
>
>
>PowerPC architecture also requires PCI interrupts. Laptops may use any of
>three routing methods, but some of those methods may not work.
>
>The i82365 driver from pcmcia-cs used the preexisting configuration by
>default, which was OK for most laptops, but not for standalone PCI cards.
>
>2.5 kernels introduced a device table to determine the interrupt delivery
>method. I criticized this approach, and wrote a patch that would turn on
>ISA interrupts if the PCI interrupt delivery failed. This patch was
>applied by Alan Cox to the 2.4 tree.
>
>Unfortunately, I forgot about bridges using external serial interrupt
>controllers (I have no idea what it means). It was reported that such
>bridges were also probed for PCI interrupts, and after failing that,
>reconfigured to the normal ISA interrupt delivery, which didn't work
>either.
>
>
I think that the chip used on my card at least (TI PCI1031), has an
option of delivering ISA IRQs via the IRQSER (I think this is the same
as PCI SERRn/SERIRQ signals).
From what I can gather (I might be totally wrong), I think this is
likely to be used on some laptops, as the PCI SERRn/SERIRQ signal was a
proposed standard, and never actually made it's way onto a standard PCI
slot, however some pci host bridges implement this (e.g. Intel PIIX, I
think), so I'd guess quite a few laptops may have their PCI1xxx chips
wired to the PCI host bridge like this, as this would be the cheapest
and most flexible option if it is available ("parallel" ISA IRQ delivery
uses more PCB traces, and PCI interrupts pose driver compatibility
problems).
The alternative way of using IRQSER interrupts appears to be to have an
external TI PCI950 chip do the serial to parallel IRQ conversion,
although I've no idea why you'd want to bother with this, when the
PCI1xxx chips can do this already, with the caveat, that they can only
deliver ISA IRQs 3,4,5,7,9,10,11,12,14,15.
I'm willing to hack on this code a bit, as I got my PCI1031 PCI card
working under 2.4, with some patching. This card (SCM Microsystems
"Swapbox") implements PCI interrupts only, and has two slots.
Interestingly, this card seems to work OK under win9x, so I suppose they
figured out how to do it on that code base, but under w2k, you have to
tweak a registry setting to tell it to use PCI irqs...
>The problem with TI bridges is that there are at least 3 types of them
>that needs to be tested, and I only have one of them.
>
>
Well, I have a spare PCI1031 PCI card, which I can test, and hack on.
We could certainly use some more testers, but this is a start...
>If there is a desire to do it right this time, and if the problem is
>considered serious to spend some time on it, here's how I would do it.
>
>- Never trust preexisting configuration. Always probe the interrupts.
>- Use PCI ID only to disable access to unsupported registers, not to
> find the best IRQ routing.
>- Cache the probe results until yenta_socket is unloaded. Probe
> interrupts once per socket (i.e. 2 times for two-socket cards).
>- Probe PCI interrupts first.
>- Probe ISA interrupts next, only if there are free interrupts and the
> architecture allows ISA interrupts.
>- Probe serial ISA interrupts under the same conditions.
>- If all probes fail, deny interrupt requests from clients. This would
> allow some memory cards.
>
>I can write this code, but I only have a PCI card to test.
>
Sounds good... However, one possible gotcha might be that the physical
IRQ pins are shared, and operate differently in different modes so it
may be possible to make a mess if you configure the chip wrong:
e.g. PCI1031
pin function
154 IRQ3/PCI INTA
155 IRQ4/PCI INTB
157 IRQ7/PCDMAREQ
158 IRQ9/IRQSER
159 IRQ10/CLKRUN
160 IRQ11/PCDMAGNT
163 IRQ15/RI_OUT
So maybe (not sure) if you put the chip in PCI interrupt mode first, it
will spray the ISA interrupts pins, if the system is wired up this way
(I know nearly nothing about ISA and PCI from an electrical point of
view, so I've no idea if this would happen in practice, but it at least
seems possible)?
Maybe:
- Probe for parallel ISA IRQs first (maybe on non shared pins if poss -
on the PCI1031, IRQs 5,12,14 have their own dedicated pin)
- Next, probe for serial ISA IRQs
- Finally, probe for PCI IRQs
If probing seems impossible or unsafe, I suppose the only way to do it
would be module/kernel options.
There are some TI PCI1xxx data sheets here:
http://www.mit.edu/afs/sipb/contrib/doc/specs/ic/bridge/
my (unfinished, but WorksForMe (tm)) 2.4 / TI PCI1031 patch is here:
http://buttersideup.com/kernel_patches/ti-pci1031.patch
Some evidence for IRQSER / PIIX possiblity:
http://groups.google.com/groups?threadm=SGTxgPhJ9GA.185%40newsgroups.intel.com
Cheers,
Tim.
On Wed, 6 Aug 2003, Tim Small wrote:
> I think that the chip used on my card at least (TI PCI1031), has an
> option of delivering ISA IRQs via the IRQSER (I think this is the same
> as PCI SERRn/SERIRQ signals).
>
> From what I can gather (I might be totally wrong), I think this is
> likely to be used on some laptops, as the PCI SERRn/SERIRQ signal was a
> proposed standard, and never actually made it's way onto a standard PCI
> slot, however some pci host bridges implement this (e.g. Intel PIIX, I
> think), so I'd guess quite a few laptops may have their PCI1xxx chips
> wired to the PCI host bridge like this, as this would be the cheapest
> and most flexible option if it is available ("parallel" ISA IRQ delivery
> uses more PCB traces, and PCI interrupts pose driver compatibility
> problems).
Are you saying that you have a PCI card without any additional connectors,
but it can use "serial" ISA interrupts thanks to the chipset support? Or
is it a laptop?
> The alternative way of using IRQSER interrupts appears to be to have an
> external TI PCI950 chip do the serial to parallel IRQ conversion,
> although I've no idea why you'd want to bother with this, when the
> PCI1xxx chips can do this already, with the caveat, that they can only
> deliver ISA IRQs 3,4,5,7,9,10,11,12,14,15.
As I understand it, "serial ISA" interrupts are available to PCI cards
only on some chipsets. If the chipset support is missing, PCI950 would be
used on the motherboard.
> >I can write this code, but I only have a PCI card to test.
> >
> Sounds good... However, one possible gotcha might be that the physical
> IRQ pins are shared, and operate differently in different modes so it
> may be possible to make a mess if you configure the chip wrong:
>
> e.g. PCI1031
>
> pin function
> 154 IRQ3/PCI INTA
> 155 IRQ4/PCI INTB
> 157 IRQ7/PCDMAREQ
> 158 IRQ9/IRQSER
> 159 IRQ10/CLKRUN
> 160 IRQ11/PCDMAGNT
> 163 IRQ15/RI_OUT
>
> So maybe (not sure) if you put the chip in PCI interrupt mode first, it
> will spray the ISA interrupts pins, if the system is wired up this way
> (I know nearly nothing about ISA and PCI from an electrical point of
> view, so I've no idea if this would happen in practice, but it at least
> seems possible)?
I have no idea, but I think it's an important consideration. I wonder how
it's possible to put IRQ3 and INTA on the same pin? What if CSC uses INTA
and the PCMCIA card uses IRQ3? How does it get routed to different
places? I guess there should be some way to tell on the hardware level
what mode the chip uses.
> Maybe:
>
> - Probe for parallel ISA IRQs first (maybe on non shared pins if poss -
> on the PCI1031, IRQs 5,12,14 have their own dedicated pin)
> - Next, probe for serial ISA IRQs
> - Finally, probe for PCI IRQs
I think there are some questions we need to answer before we decide.
1) How important is it to provide the card with a non-shared ISA
interrupt? Shouldn't we rather update the drivers to deal with shared
interrupts? I can imagine that some old PCMCIA cards are designed without
interrupt sharing in mind, i.e. it's hard to say if the interrupt was
issued by that card or by some other device. But how critical is that?
Do we want to support really old hardware, broken by design? And what
exactly hardware is it?
2) There is a risk of taking an interrupt from an ISA device that
doesn't have its module loaded yet. Do we care about it?
3) What is the risk of disabling the system by probing for parallel ISA
interrupts?
4) What is the risk of disabling the system by probing for serial ISA
interrupts, especially on the motherboards without support for them?
> If probing seems impossible or unsafe, I suppose the only way to do it
> would be module/kernel options.
I hope we can avoid it.
> Some evidence for IRQSER / PIIX possibility:
>
> http://groups.google.com/groups?threadm=SGTxgPhJ9GA.185%40newsgroups.intel.com
Yes, but note this:
"The serial interrupt interrupt register, SERIRQC, in section 4.1.11 of
the PIIX4 datasheet has to be initialized before any of the serial
interrupts to work. I believe this is done through BIOS if the BIOS
supports it."
SERIRQC is described here:
http://www.intel.com/design/intarch/techinfo/440bx/bridgreg.htm
I don't know if we should change this register. It depends on how badly
we want to give ISA interrupt to the cards.
--
Regards,
Pavel Roskin
On Thu, Aug 07, 2003 at 12:01:06AM -0400, Pavel Roskin wrote:
> I have no idea, but I think it's an important consideration. I wonder how
> it's possible to put IRQ3 and INTA on the same pin?
It's not, and this is the whole point about why what we're currently
doing is *wrong*. The only people who know whether the pin has been
wired for INTA or IRQ3 are the _designers_ of the hardware, not the
Linux kernel.
Currently, the Linux kernel assumes a "greater than designers" approach
to fiddling with the registers which control the function of these pins,
and so far I've seen:
- changing the mode from serial PCI interrupts to parallel PCI interrupts
causes the machine to lock hard (since some cardbus controllers use the
same physical pins for both functions.)
- fiddling with the IRQMUX register changes the mapping between the card
IRQ selector register and the physical ISA IRQ on which the interrupt
appears, or even changes the function of the pin connected to a shared
ISA IRQ (IRQ3 and 4) to become the ZV status output.
In essense, when we find that a particular machine has not setup the
function of these multi-purpose signals, we need to find a way to
perform the fixup which is dependent on the machine not on the
cardbus controller type.
If we can't do that, then we can't fix up the problem automatically -
chances are applying the same "fix" across different machines will
break the cases which presently work.
So, to find a solution, as of last night, Linus has integrated changes
which completely disables the frobbing of the IRQMUX register on TI
chips, and disables the "select PCI only IRQ mode" code which was
recently merged from the -ac tree. The latter was rather bogus -
it disabled the ISA interrupts before we determined if we had any
to start with.
In addition, we display the slot and subsystem vendor and device IDs
at boot. Hopefully, this will allow us to gather sufficient information
to put together a reasonable picture of which machines are broken and
give us a way to perform the necessary fixups on a per-machine basis.
I'm hoping that those who need these machine specific registers frobbed
are going to be testing 2.6.0-test kernels.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Pavel Roskin wrote:
>On Wed, 6 Aug 2003, Tim Small wrote:
>
>
>>I think that the chip used on my card at least (TI PCI1031), has an
>>option of delivering ISA IRQs via the IRQSER (I think this is the same
>>as PCI SERRn/SERIRQ signals).
>>
>> From what I can gather (I might be totally wrong), I think this is
>>likely to be used on some laptops, as the PCI SERRn/SERIRQ signal was a
>>proposed standard, and never actually made it's way onto a standard PCI
>>slot, however some pci host bridges implement this (e.g. Intel PIIX, I
>>think), so I'd guess quite a few laptops may have their PCI1xxx chips
>>wired to the PCI host bridge like this, as this would be the cheapest
>>and most flexible option if it is available ("parallel" ISA IRQ delivery
>>uses more PCB traces, and PCI interrupts pose driver compatibility
>>problems).
>>
>>
>
>Are you saying that you have a PCI card without any additional connectors,
>but it can use "serial" ISA interrupts thanks to the chipset support? Or
>is it a laptop?
>
>
No, my card is wired up for PCI interrupts only, and the SERIRQ signal
is not available on a standard PCI slot, so no PCI add-in cards can use
SERIRQ. On a laptop (where the cardbus bridge is on the same PCB as the
PCI host bridge), it could be used. The SERIRQ pin can be used to
deliver *both* ISA, and PCI interrupts, but I don't know for sure if the
TI chips will do this. I suppose I could get my soldering iron out and
check for this, but perhaps I won't ;o).
>>The alternative way of using IRQSER interrupts appears to be to have an
>>external TI PCI950 chip do the serial to parallel IRQ conversion,
>>although I've no idea why you'd want to bother with this, when the
>>PCI1xxx chips can do this already, with the caveat, that they can only
>>deliver ISA IRQs 3,4,5,7,9,10,11,12,14,15.
>>
>>
>
>As I understand it, "serial ISA" interrupts are available to PCI cards
>only on some chipsets. If the chipset support is missing, PCI950 would be
>used on the motherboard.
>
>
Yes, alternatively you could just wire up the ISA IRQ lines instead. At
least on the PCI1031, however, this means that you can't deliver PCI
interrupts (as the physical pins are shared).
>>>I can write this code, but I only have a PCI card to test.
>>>
>>>
>>>
>>Sounds good... However, one possible gotcha might be that the physical
>>IRQ pins are shared, and operate differently in different modes so it
>>may be possible to make a mess if you configure the chip wrong:
>>
>>e.g. PCI1031
>>
>>pin function
>>154 IRQ3/PCI INTA
>>155 IRQ4/PCI INTB
>>157 IRQ7/PCDMAREQ
>>158 IRQ9/IRQSER
>>159 IRQ10/CLKRUN
>>160 IRQ11/PCDMAGNT
>>163 IRQ15/RI_OUT
>>
>>So maybe (not sure) if you put the chip in PCI interrupt mode first, it
>>will spray the ISA interrupts pins, if the system is wired up this way
>>(I know nearly nothing about ISA and PCI from an electrical point of
>>view, so I've no idea if this would happen in practice, but it at least
>>seems possible)?
>>
>>
>
>I have no idea, but I think it's an important consideration. I wonder how
>it's possible to put IRQ3 and INTA on the same pin? What if CSC uses INTA
>and the PCMCIA card uses IRQ3? How does it get routed to different
>places?
>
You can't, as far as I know. You must either wire this pin to PCI INTA,
(and program the bridge registers to deliver PCI interrupts) or to IRQ3
(and program the registers for ISA interrupts). This is just on my
bridge tho' (PCI1031), later bridges might not have this limitation..
> I guess there should be some way to tell on the hardware level
>what mode the chip uses.
>
As far as I can tell, no, there isn't (short of probing for
interrupts). Once you program the registers up, the chip will treat the
pins appropriately. You can however read the registers to see what mode
the BIOS has put the chip in, I suppose, of course, this is no good for
PCI add-in cards, where the BIOS doesn't know about the bridge chip.
>>Maybe:
>>
>>- Probe for parallel ISA IRQs first (maybe on non shared pins if poss -
>>on the PCI1031, IRQs 5,12,14 have their own dedicated pin)
>>- Next, probe for serial ISA IRQs
>>- Finally, probe for PCI IRQs
>>
>>
>
>I think there are some questions we need to answer before we decide.
>
>1) How important is it to provide the card with a non-shared ISA
>interrupt? Shouldn't we rather update the drivers to deal with shared
>interrupts? I can imagine that some old PCMCIA cards are designed without
>interrupt sharing in mind, i.e. it's hard to say if the interrupt was
>issued by that card or by some other device. But how critical is that?
>Do we want to support really old hardware, broken by design? And what
>exactly hardware is it?
>
Well, it's not really the card that would be broken by design, 16bit
card hardware designers have a right to assume that they have access to
ISA style interrupts, I think. These might not work where the bridge
chip is only wired for PCI interrupts. I can't remember which drivers
didn't work in this case (there was only one, I think).
>2) There is a risk of taking an interrupt from an ISA device that
>doesn't have its module loaded yet. Do we care about it?
>
>
Don't know enough about this, sorry!
>3) What is the risk of disabling the system by probing for parallel ISA
>interrupts?
>
Hmm, no risk if you only probe for IRQs which are on non-shared pins (5,
12, 14), not sure what the risk is if you start driving ISA IRQs down
lines which are wired up to the PCI bus, need to ask a hardware engineer
;-).
>4) What is the risk of disabling the system by probing for serial ISA
>interrupts, especially on the motherboards without support for them?
>
>
Should be no risk, I think, if you have established that the chip is not
wired for parallel interrupts.
>>Some evidence for IRQSER / PIIX possibility:
>>
>>http://groups.google.com/groups?threadm=SGTxgPhJ9GA.185%40newsgroups.intel.com
>>
>>
>
>Yes, but note this:
>
>"The serial interrupt interrupt register, SERIRQC, in section 4.1.11 of
>the PIIX4 datasheet has to be initialized before any of the serial
>interrupts to work. I believe this is done through BIOS if the BIOS
>supports it."
>
>SERIRQC is described here:
>http://www.intel.com/design/intarch/techinfo/440bx/bridgreg.htm
>
>I don't know if we should change this register. It depends on how badly
>we want to give ISA interrupt to the cards.
>
>
Well, I take it that as the card can only be wired this way if the
pcmcia/cardbus bridge is on the main system board, that we should assume
that the BIOS has already done this...
Tim.
On Iau, 2003-08-07 at 10:02, Russell King wrote:
> doing is *wrong*. The only people who know whether the pin has been
> wired for INTA or IRQ3 are the _designers_ of the hardware, not the
> Linux kernel.
That assumes the yenta controller isnt hotplugged.
> Currently, the Linux kernel assumes a "greater than designers" approach
> to fiddling with the registers which control the function of these pins,
> and so far I've seen:
>
> - changing the mode from serial PCI interrupts to parallel PCI interrupts
> causes the machine to lock hard (since some cardbus controllers use the
> same physical pins for both functions.)
Basically we got burned by changing the IRQMUX register rather than just
using it as an information source.
Alan Cox wrote:
>On Iau, 2003-08-07 at 10:02, Russell King wrote:
>
>
>>doing is *wrong*. The only people who know whether the pin has been
>>wired for INTA or IRQ3 are the _designers_ of the hardware, not the
>>Linux kernel.
>>
>>
>
>That assumes the yenta controller isnt hotplugged.
>
>
Some (all?) PCI add-in cards leave this up to the OS/driver as well.
The card I have has no firmware on board, and from a quick look at the
PCI1031 datasheet, I can't see any easy way of adding one. The default
power-on state (at least for the PCI1031) is to disable all interrupts.
>>Currently, the Linux kernel assumes a "greater than designers" approach
>>to fiddling with the registers which control the function of these pins,
>>and so far I've seen:
>>
>>- changing the mode from serial PCI interrupts to parallel PCI interrupts
>> causes the machine to lock hard (since some cardbus controllers use the
>> same physical pins for both functions.)
>>
>>
>
>Basically we got burned by changing the IRQMUX register rather than just
>using it as an information source.
>
>
I think it should be possible to use the IRQMUX, and other registers to
work out whether the bridge has been setup or not.. e.g.
"device control register bits2,1: R/W, Interrupt mode.
Bits 2 1 select the interrupt mode used by the PCI1031. Bits 2 1 are
encoded as: 00 = No interrupts enabled (default) 01 = ISA 10 =
Serialized IRQ type interrupt scheme 11 = Reserved"
If these bits are non-zero, I suppose we should probably leave the IRQ
routing registers alone, as it would seem to be a good indicator that
the BIOS has programmed these for us. This is just on the 1031,
however, I haven't checked any of the other datasheets...
Tim.
On Thu, Aug 07, 2003 at 02:02:22PM +0100, Tim Small wrote:
> "device control register bits2,1: R/W, Interrupt mode.
> Bits 2 1 select the interrupt mode used by the PCI1031. Bits 2 1 are
> encoded as: 00 = No interrupts enabled (default) 01 = ISA 10 =
> Serialized IRQ type interrupt scheme 11 = Reserved"
When you look at some other TI device, you'll notice that these bits
have a similar meaning, but, for instance 10 will be reserved (because
the device doesn't support Serialised ISA IRQs) but supports 11 (serial
PCI IRQs.) 00 means PCI IRQ mode only on some TI devices, and is a
valid setting.
You can do what you're suggesting as long as you take account of the
device itself. However, once you've decided the device isn't setup,
how can the kernel determine exactly what the _correct_ setup of the
device is? You can't say "well, its a PCI1031 device, therefore I'll
select ISA interrupt mode" because you don't know if it has been
wired up that way.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, Aug 07, 2003 at 01:18:15PM +0100, Alan Cox wrote:
> On Iau, 2003-08-07 at 10:02, Russell King wrote:
> > doing is *wrong*. The only people who know whether the pin has been
> > wired for INTA or IRQ3 are the _designers_ of the hardware, not the
> > Linux kernel.
>
> That assumes the yenta controller isnt hotplugged.
Even if it is hot plugged, the _kernel_ doesn't have the hardware
design information to make the correct decision about the value to
program into that register.
However, luckily, some devices load the IRQMUX register from an
EEPROM, so it should be correctly setup.
> > Currently, the Linux kernel assumes a "greater than designers" approach
> > to fiddling with the registers which control the function of these pins,
> > and so far I've seen:
> >
> > - changing the mode from serial PCI interrupts to parallel PCI interrupts
> > causes the machine to lock hard (since some cardbus controllers use the
> > same physical pins for both functions.)
>
> Basically we got burned by changing the IRQMUX register rather than just
> using it as an information source.
Different register - that was the device control register...
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Iau, 2003-08-07 at 14:16, Russell King wrote:
> You can do what you're suggesting as long as you take account of the
> device itself. However, once you've decided the device isn't setup,
> how can the kernel determine exactly what the _correct_ setup of the
> device is? You can't say "well, its a PCI1031 device, therefore I'll
> select ISA interrupt mode" because you don't know if it has been
> wired up that way.
Subvendor id I guess - and some kind of heuristic for uninitialized plugin
cards (my guess is "PCI" if it was hotplugged).
On Thu, Aug 07, 2003 at 03:00:23PM +0100, Alan Cox wrote:
> On Iau, 2003-08-07 at 14:16, Russell King wrote:
> > You can do what you're suggesting as long as you take account of the
> > device itself. However, once you've decided the device isn't setup,
> > how can the kernel determine exactly what the _correct_ setup of the
> > device is? You can't say "well, its a PCI1031 device, therefore I'll
> > select ISA interrupt mode" because you don't know if it has been
> > wired up that way.
>
> Subvendor id I guess - and some kind of heuristic for uninitialized plugin
> cards (my guess is "PCI" if it was hotplugged).
Hopefully, but I'm not holding out that much hope for the subvendor
stuff to be correctly initialised.
At least now we have a way to find out - as of last night, Linus'
kernel will now displaying the subvendor and subdevice information
while it probes the hardware, and it has the tweaks to IRQMUX and
the the other PCI only IRQ hack disabled. This, along with the
PNP fix from Adam should solve all the IRQ problems people have
been recently seeing.
Those which remain should be the result of missing or incorrect setup
of the multi-function pins on the cardbus bridge, and I'm hoping to
receive reports from people with cardbus sockets needing some kind of
fixing up - and these should come with the subvendor/device information
readily available. 8)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King wrote:
>On Thu, Aug 07, 2003 at 02:02:22PM +0100, Tim Small wrote:
>
>
>>"device control register bits2,1: R/W, Interrupt mode.
>>Bits 2 1 select the interrupt mode used by the PCI1031. Bits 2 1 are
>>encoded as: 00 = No interrupts enabled (default) 01 = ISA 10 =
>>Serialized IRQ type interrupt scheme 11 = Reserved"
>>
>>
>
>When you look at some other TI device, you'll notice that these bits
>have a similar meaning, but, for instance 10 will be reserved (because
>the device doesn't support Serialised ISA IRQs) but supports 11 (serial
>PCI IRQs.) 00 means PCI IRQ mode only on some TI devices, and is a
>valid setting.
>
OK, but you could check various registers to see if the device is in the
default power-on state, and only then probe. This will make sure that
it Just Works for devices which are already correctly configured - which
should be the majority. It may turn out to be possible to probe for the
correct settings on some bridge chips, and not others, but this would
still be better than nothing..
>You can do what you're suggesting as long as you take account of the
>device itself. However, once you've decided the device isn't setup,
>how can the kernel determine exactly what the _correct_ setup of the
>device is? You can't say "well, its a PCI1031 device, therefore I'll
>select ISA interrupt mode" because you don't know if it has been
>wired up that way.
>
>
I think you can assume that a parallel ISA interrupt wiring scheme, or
an IRQSER wiring scheme is not possible for an add-in device (i.e. one
that the system BIOS is unaware of), because there are no pins for these
signals on a standard PCI slot, making these schemes physically
impossible (unless an ISA 'paddle board', or similar was used - I've
never see such a device, but I suppose it would be possible to build
one). Does this also cover the hotplug cases? What about ACPI resume?
If not, you could probably probe for the valid method, by forcing card
status events, and seeing if the interrupts get delivered. Of course,
the trick is to do this in a way which will not cause trouble, and
potentially lock up the system by triggering incorrect interrupts etc.
. On the PCI1031, you'd need to do this:
. Set up the bridge for parallel ISA IRQ delivery, and see if IRQ
delivery works by generating a status event (skip this test and quit
here with a useful error message* with a warning if no safe IRQs
available for this test (5,12,14 - not a particularly hopeful list, I
grant you, but possibly, you could also probe IRQ3, IRQ4 in this manner,
and you'd get PCI interrupts generated if the bridge is wired for
parallel PCI IRQs))
- if this fails, it must be wired either IRQSER, or parallel PCI
interrupts:
. Set up the bridge for parallel PCI IRQ delivery, and see if IRQ
delivery works by generating a status event
- if this fails, it must be wired for IRQSER interrupts:
. Set up the bridge for IRQSER delivery, and see if IRQ delivery works
by generating a status event
- if this doesn't work, disable interrupts again, and print a message
stating that interrupts failed (you could still use memory devices, as
Pavel suggested).
* The error message could say that we were unable to probe interrupts
because no safe interrupts were available, and say which ones we wanted
so that the user could make them available by making sure the yenta
driver was loaded before other drivers and/or disabling devices which
are already on these IRQs and/or telling the BIOS to reserve them, or
maybe we could grab these interrupts if available, or tell the user to
load the module with the module option "yenta_ti_unsafeIRQprobe" enabled.
I am just brainstorming here, so please forgive me if I'm talking bollox ;-)
Tim.