[PATCH 2.6] ToPIC specific init for yenta_socket

[PATCH 2.6] ToPIC specific init for yenta_socket

[Daniel Ritz]

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

Re: [PATCH 2.6] ToPIC specific init for yenta_socket

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH 2.6] ToPIC specific init for yenta_socket

[Pavel Roskin]

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

Re: [PATCH 2.6] ToPIC specific init for yenta_socket

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH 2.6] ToPIC specific init for yenta_socket

[Pavel Roskin]

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

TI yenta-alikes (was: ToPIC specific init for yenta_socket)

[Tim Small]

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.

Re: TI yenta-alikes (was: ToPIC specific init for yenta_socket)

[Pavel Roskin]

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

Re: TI yenta-alikes (was: ToPIC specific init for yenta_socket)

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: TI yenta-alikes (was: ToPIC specific init for yenta_socket)

[Alan Cox]

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.

Re: TI yenta-alikes

[Tim Small]

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.

Re: TI yenta-alikes

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: TI yenta-alikes

[Alan Cox]

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). 

Re: TI yenta-alikes

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: TI yenta-alikes

[Tim Small]

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.

Re: TI yenta-alikes (was: ToPIC specific init for yenta_socket)

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: TI yenta-alikes

[Tim Small]

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.

Re: [PATCH 2.6] ToPIC specific init for yenta_socket

[Daniel Ritz]

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.