ToPIC specific init for yenta_socket

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.

@@ -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 */

@@ -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 */
 };

@@ -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

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

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.

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

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.

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

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

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

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

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.

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?

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

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?

I hope we can avoid it.

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

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

That assumes the yenta controller isnt hotplugged.

Basically we got burned by changing the IRQMUX register rather than just using it as an information source.

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.

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.

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

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

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

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.

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.

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

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

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

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

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.

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

Don't know enough about this, sorry!

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

Should be no risk, I think, if you have established that the chip is not wired for parallel interrupts.

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.

yep, i saw the mails on lkml...

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.

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.