[PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines
artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines
This makes the network adapter work fully, and reduces problems on high traffic (e.g kernel oopses on fsck run over USB 2.0 HDD) Many thanks for Peter Stuge for a lot of IRQ related help.
Signed-off-by: Mart Raudsepp mart.raudsepp@artecdesign.ee --- mainboard/artecgroup/dbe62/irq_tables.h | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mainboard/artecgroup/dbe62/irq_tables.h b/mainboard/artecgroup/dbe62/irq_tables.h index d8d64a6..0d1a4bb 100644 --- a/mainboard/artecgroup/dbe62/irq_tables.h +++ b/mainboard/artecgroup/dbe62/irq_tables.h @@ -23,10 +23,10 @@ #define IRQ_SLOT_COUNT 3
/* Platform IRQs */ -#define PIRQA 10 -#define PIRQB 11 -#define PIRQC 10 -#define PIRQD 11 +#define PIRQA 11 +#define PIRQB 10 +#define PIRQC 9 +#define PIRQD 5
/* Map */ #define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ @@ -60,6 +60,6 @@ const struct irq_routing_table intel_irq_routing_table = { /* chipset */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* ethernet */ - {0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, + {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, } };
On Sat, May 03, 2008 at 04:58:05AM +0300, Mart Raudsepp wrote:
???artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines
This makes the network adapter work fully, and reduces problems on high traffic (e.g kernel oopses on fsck run over USB 2.0 HDD) Many thanks for Peter Stuge for a lot of IRQ related help.
Signed-off-by: Mart Raudsepp mart.raudsepp@artecdesign.ee
Acked-by: Peter Stuge peter@stuge.se
mainboard/artecgroup/dbe62/irq_tables.h | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mainboard/artecgroup/dbe62/irq_tables.h b/mainboard/artecgroup/dbe62/irq_tables.h index d8d64a6..0d1a4bb 100644 --- a/mainboard/artecgroup/dbe62/irq_tables.h +++ b/mainboard/artecgroup/dbe62/irq_tables.h @@ -23,10 +23,10 @@ #define IRQ_SLOT_COUNT 3
/* Platform IRQs */ -#define PIRQA 10 -#define PIRQB 11 -#define PIRQC 10 -#define PIRQD 11 +#define PIRQA 11 +#define PIRQB 10 +#define PIRQC 9 +#define PIRQD 5
/* Map */ #define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ @@ -60,6 +60,6 @@ const struct irq_routing_table intel_irq_routing_table = { /* chipset */ {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* ethernet */
{0x00, (0x0D << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},
{0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},};
On Fri, May 2, 2008 at 6:59 PM, Peter Stuge peter@stuge.se wrote:
On Sat, May 03, 2008 at 04:58:05AM +0300, Mart Raudsepp wrote:
???artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines
This makes the network adapter work fully, and reduces problems on high traffic (e.g kernel oopses on fsck run over USB 2.0 HDD) Many thanks for Peter Stuge for a lot of IRQ related help.
Signed-off-by: Mart Raudsepp mart.raudsepp@artecdesign.ee
Acked-by: Peter Stuge peter@stuge.se
Enthusiastically-Acked-by:Ronald G. Minnich rminnich@gmail.com
(I'm hoping someone will do this :-)
One issue I'm having is that the hfcpci card (or driver) can't tolerate shared interrupts. But we have shared interrupts on the various cs5536 boards, since we put USB interrupt info in the table.
To allow us to have non-shared interrupts for all devices, we need to get the USB interrupts out of the PIR table. They are not really routed via the standard IRQ router anyway -- they are internal -- and don't need to share interrupt #s with the other devices that are actually routed via the interrupt routing hardware.
Put simply, having the USB f.3,4,5 devices in the PIR table works, but is really a bit of a mistake.
OK, where do we put the IRQ info for the USB devices? In the DTS for the cs5536.
SO in DTS for the cs5536 we need three more properties, usbf3 usbf4 usbf5
with reasonable settings for them. Then in the chipset init code, we need to see if these are set and, if so, set the IRQ line in the f.3, f.4, and f.5 devices.
If this is confusing I can explain in more detail, but later, I'm tired, and the ISDN card just locked up again. How can such a simple driver have so many failure modes? Oh, wait, it's not simple, sigh.
but, short form: on the cs5536, USB interrupts should not be described in the PIR table, but via settings derived from dts. They should be initialized in cs5536 setup code, no in the PIR setup code. That will allow us to have non-shared interrupts on the various PCI slots on, e.g., alix1c, and allow broken drivers like hfcpci to work.
ron
On Fri, May 02, 2008 at 09:46:41PM -0700, ron minnich wrote:
get the USB interrupts out of the PIR table. They are not really routed via the standard IRQ router anyway -- they are internal -- and don't need to share interrupt #s with the other devices that are actually routed via the interrupt routing hardware.
Are you sure? From the OS point of view they still need a 4-bit interrupt number, since they are supposed to be PCI devices. No?
Put simply, having the USB f.3,4,5 devices in the PIR table works, but is really a bit of a mistake.
USB is on the GLIU in 5536 and not on any external PCI bus.
But it still appears to be a PCI device, and it needs an interrupt.
but, short form: on the cs5536, USB interrupts should not be described in the PIR table, but via settings derived from dts. They should be initialized in cs5536 setup code, no in the PIR setup code. That will allow us to have non-shared interrupts on the various PCI slots on, e.g., alix1c, and allow broken drivers like hfcpci to work.
Yep. Is good.
//Peter
On Sun, May 04, 2008 at 03:11:02AM +0200, Peter Stuge wrote:
USB is on the GLIU in 5536 and not on any external PCI bus. But it still appears to be a PCI device, and it needs an interrupt.
32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB is always on INTD# IRQ11. This could be hardwired in LX/5536; GL packets from USB will always trigger IRQ11. Or worse they will always trigger PCI_INTD# meaning a well-designed board with 4 PCI slots, or a badly designed board with less slots will always need to share somewhere.
//Peter
On Sun, May 04, 2008 at 03:17:57AM +0200, Peter Stuge wrote:
On Sun, May 04, 2008 at 03:11:02AM +0200, Peter Stuge wrote:
USB is on the GLIU in 5536 and not on any external PCI bus. But it still appears to be a PCI device, and it needs an interrupt.
32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB is always on INTD# IRQ11. This could be hardwired in LX/5536;
It's not hardwired. Tinybios on the PCEngines boards puts USB (which is wired to INTD#) on interrupt 15.
GL packets from USB will always trigger IRQ11.
I _think_ this is set by the VSA blob. But what do I know :)
Or worse they will always trigger PCI_INTD# meaning a well-designed board with 4 PCI slots, or a badly designed board with less slots will always need to share somewhere.
I don't think so.
Thanks, Ward.
On Sun, May 04, 2008 at 10:49:22AM -0400, Ward Vandewege wrote:
32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB is always on INTD# IRQ11. This could be hardwired in LX/5536;
It's not hardwired.
You are correct.
I was reading the LX and 5536 databooks while Tom sent the last message so he has already covered some of this.
Architecture overviews describe 5536 connected to the LX via PCI but the LX has no PCI interrupt balls so that must only be a logical description. 5536 is connected to the LX via the companion connection GLD on one of the two GLIUs in the LX.
The 5536 has GPIO interrupts, which are used for the external PCI bus interrupt signals. That makes sense since the PCI_INTx signals connect to 5536 GPIO balls.
But what about the virtual PCI devices?
GL packets from USB will always trigger IRQ11.
I _think_ this is set by the VSA blob. But what do I know :)
I should have written that as a question. Anyway, you knew.
(And interrupts are not neccessarily connected with any other GL activity from the USB module.)
Or worse they will always trigger PCI_INTD# meaning a well-designed board with 4 PCI slots, or a badly designed board with less slots will always need to share somewhere.
I don't think so.
The 5536 databook does not mention interrupts at all in the USB module chapters, it's all in the interrupt controller chapters.
Ron got his way, he had it coming. Reading geode-vsa shows that you're spot on, Ward.
Hardwarewise, the USB module generates interrupts on what is called "Unrestricted Y Input 2" on the PIC. That input maps to one interrupt group between 1 and 15 per the PIC specific MSR at addr+20h bits 11:8.
The interrupt is OR:ed with any other interrupts mapped to the same group. The group number corresponds to the classic 8259 IRQ number. Interrupt group 10 generates IRQ 10. "Unrestricted" because the input can be mapped to any IRQ 1-15. MFGPT and GPIO interrupts are on the Unrestricted Z inputs.
Reset value for all interrupt group MSRs is 0, ie. disabled.
Simple enough.
Enter PCI emulation cr^W:
VSA allows writes to PCI register 0x3c bits 7:0 (interrupt line) but not bits 15:8 (interrupt pin) for all virtual devices. Since virtual devices are internal and not actually connected to any PCI interrupt pin (the external signals on GPIO balls) that makes sense.
sysmgr/pci_wr.c:Virtual_PCI_Write_Handler() handles writes to all PCI registers for virtual devices but the PIC specific MSR that controls the interrupt group mapping is not touched in this code path.
sysmgr/topology.c has a struct for each virtual device that lists all implemented registers. All devices have register 0x3c and it's value is initialized to the interrupt pin (1..4) in bits 15:8 and somewhat surprisingly the Unrestricted Y Input number (1..15) rather than the interrupt line (1..15) in bits 7:0. Both USB devices have 0x00000402.
legacy/cs5536.c:CS5536_Early_Init() goes through all 5536 functions and for those with non-zero bits 15:0 in register 0x3c the value is copied to the global Y_Sources array and cleared to 0 in the struct. Then a PCI trap is registered for writes to southbridge F0 register 0x5c-0x5d. (5530 PCI Interrupt Steering)
When someone writes to 0x5c, legacy/cs5536.c:PCI_Interrupt_Steering() is called. On the first write the specified GPIO balls are set up to handle PCI_INTx signals, as mentioned the other day. On all writes it calls SYS_MAP_IRQ() with the value saved in Y_Sources for each IRQ in the specified interrupt steering map (ie. each IRQ assigned to a PCI_INTx pin/ball by this write to 0x5c) and now the Y2->IG mapping for the USB module (and all others) is finally written to the PIC specific MSR.
VSA thus forces virtual PCI devices to only ever generate the same interrupts as external PCI devices.
Which of the four PCI_INTx IRQs a device uses is determined by bits 15:8 of the 0x3C value in the corresponding PCI_HEADER_ENTRY struct in sysmgr/topology.c at VSA blob compile time.
Dig out your hex editor if you want to change it.
Whatever is written to 0x3c for virtual devices has no effect on which IRQ is generated. The register value is purely for show.
//Peter
Peter, I owe you a beer next time we meet. That's some might nice detective work ...
ron
On Sun, May 11, 2008 at 12:33:01PM -0700, ron minnich wrote:
This is a first try at a program to grok lxirqs.
I love utilities that help automate ports!
I'll start with a recap of my summary:
On Mon, May 05, 2008 at 02:06:31AM +0200, Peter Stuge wrote:
The 5536 has GPIO interrupts, which are used for the external PCI bus interrupt signals. That makes sense since the PCI_INTx signals connect to 5536 GPIO balls.
..
Hardwarewise, the USB module generates interrupts on what is called "Unrestricted Y Input 2" on the PIC. That input maps to one interrupt group between 1 and 15 per the PIC specific MSR at addr+20h bits 11:8.
The interrupt is OR:ed with any other interrupts mapped to the same group. The group number corresponds to the classic 8259 IRQ number. Interrupt group 10 generates IRQ 10. "Unrestricted" because the input can be mapped to any IRQ 1-15. MFGPT and GPIO interrupts are on the Unrestricted Z inputs.
Reset value for all interrupt group MSRs is 0, ie. disabled.
Unrestricted Z inputs to the PIC are also mapped to one interrupt group between 1 and 15. Which GPIO interrupt input that goes to which interrupt group is controlled by the PIC specific MSRs at addr+22h and addr+23h.
Ok, back to Ron's message:
Sanity check first, I'm not signing this off yet. Are the enable and invert tests correct below?
Long term goal is a program that will follow the IRQ through the magic rabbit hole and up to the CPU.
Why? When will the program be used?
I don't know how to do vr reads in user mode, however.
VRs don't really matter. VRs _only_ purpose is to implement a compatibility layer for software that does not understand GeodeLink.
I think our utilities should and must do that. They don't have to care about VRs. The only caveat would be that if something is written to GeodeLink then perhaps a VR needs to be updated to reflect the change - but such changes may be taboo anyway because whoever is reading the VRs may not be able to handle someone else changing them. Another issue is that VRs are not guaranteed to be atomic.
Here's the current output on alix1c, which is strange looking to me. IRQ A, GPIO pin 0 Input Enabled and Not Inverted IRQ B, GPIO pin 7 Input Enabled and Inverted IRQ C, GPIO pin 12 Input Enabled and Inverted IRQ D, GPIO pin 13 Input Disabled and Not Inverted
This does not look correct. I would expect all pins to be set up the same way. Can you confirm using the MSR tool from the other day?
+char *irqnames[] = {"invalid", "A", "B", "C", "D"};
Please do not mix IRQ with INT;
INT is an instruction which generates a software interrupt.
IRQ is Interrupt Request Channel and refers to hardware generated interrupts, the number between 1 and 15. IRQs used to be equivalent to electrical signals, but that's no longer true. This is also called interrupt line, and is set in bits 7:0 in PCI register 0x3c.
PCI_INTA, PCI_INTB, PCI_INTC and PCI_INTD are names of the electrical signals in the PCI bus. The utility deals only with these so far. This is also called the interrupt pin, and is set in bits 15:8 in PCI register 0x3c.
+void irq(struct pci_dev *cs5536, int irqno, unsigned char gpiopin) +{
- /* Use GPIOBASE register to find where the GPIO is mapped. */
- gpiobar = pci_read_word(cs5536, 0x14) & 0xfffc;
- printf("IRQ %s, GPIO pin %d\n", irqnames[irqno], gpiopin);
+// enable = inl(gpiobar + 0x20); +// printf("input enable %08lx\n", enable);
- printf("Input %s and %s\n",
atomicval(0x20, gpiopin) ? "Enabled" : "Disabled",atomicval(0x24, gpiopin) ? "Inverted" : "Not Inverted");+}
..
+int main(int argc, char *argv[]) +{
..
- introute = strtoul(argv[1], 0, 0);
..
- irq(cs5536, 1, introute);
- irq(cs5536, 2, introute>>8);
- irq(cs5536, 3, introute>>16);
- irq(cs5536, 4, introute>>24);
I think this is backwards.
One, there is no need for PCI, please use MSRs directly instead.
Two, I would expect a utility to _output_ the correct GPIO pins, not require them as _input_.
If the current mapping of GPIO pins->PIC Unrestricted Z inputs is supposed to be specifed then that can and should always be read directly from MSRs PICbase+22h and +23h.
All GPIO settings are read with the generic MSR tool that was recently committed, and I think a shell script would be good enough to translate some bits to text.
I'm afraid I don't understand the motivation for this tool.
Please help me so I can contribute something more constructive! :)
//Peter
The motivation for this tool is simple. Given a working system, tell me what is hooked to what, IRQ- and PCI INT-wise. Or, given a non-working system, go into the system and try to find things that look wrong. At the very least, explain how the confusing thicket of LX interrupts is wired up, because I sure as hell can't figure it out most of the time. And, judging by our most recent fix, it even can confound the experts :-)
In the limit, we ought to be able to run this tool on a working system, compare it to a non-working system, and see what's different.
I don't actually see a difference from my end between an IRQ (Interrupt request in old-speak) and a PCI INT (interrupt request in old speak) but if you want to rename things, have at it. Code attached, do your worst!
I will rename them too but at present I'm a lot more concerned with tracking down whatever is set up wrong on the alix1c. Something is just flat out wrong! We need to find it and I'm running out of time with the Berlin show looming.
You have to talk to VRs because VSA talks VRs, and when you Do Certain Things, VSA gets involved. So I am not inclined to ignore the VRs.
Here's the latest version of the program together with alix1c output.
input enable 0f7af085 invert 0xcf7e3081 irqmap from vr is 0xd0c0700 4d1:4d0 0e00 Filter events: 0/00 1/00 2/00 3/00 4/00 5/00 6/00 7/00 IRQ A, GPIO pin 0 Input Enabled and Inverted IRQ B, GPIO pin 7 Input Enabled and Inverted IRQ C, GPIO pin 12 Input Enabled and Inverted IRQ D, GPIO pin 13 Input Enabled and Inverted
So notice that it appears when coreboot sets the VRs for INTAB and INTCD, VSA is setting up the GPIOs as enabled and inverted. Useful to know. Next steps are to see how the 22/23 registers are set up, and, with luck, trace it all the way through and maybe even find the problem. For now, however, the 3v PCI slot INTs are not working at all, as far as I can tell. They're almost acting edge-triggered. I think it's an artifact of sharing PCI INTs with the USB -- the ethernet, which is attached in the same way (with the same wire!) as the PCI slot, works just fine. It's very odd.
ron
ron
On Sun, May 11, 2008 at 09:51:10PM -0700, ron minnich wrote:
At the very least, explain how the confusing thicket of LX interrupts is wired up,
So decode the mapping and input condition MSRs.
In the limit, we ought to be able to run this tool on a working system, compare it to a non-working system, and see what's different.
A small number (4 or 6) of MSRs really have all the information that is needed. Just dump them.
I don't actually see a difference from my end between an IRQ (Interrupt request in old-speak) and a PCI INT (interrupt request in old speak) but if you want to rename things, have at it.
INTA etc are the names of the signals on the PCB and in the socket.
A card yanking (e.g.) INTA should lead to a CPU interrupt. But which IRQ this interrupt comes in on, depends on which 5536 GPIO ball that PCI INTA signal from the socket has been routed to, and what those MSRs have been set to.
Code attached, do your worst!
Will have a look.
I will rename them too but at present I'm a lot more concerned with tracking down whatever is set up wrong on the alix1c. Something is just flat out wrong! We need to find it and I'm running out of time with the Berlin show looming.
Oh but I'm not sure we have any PCI cards anyway. I don't, at least.
You have to talk to VRs because VSA talks VRs, and when you Do Certain Things, VSA gets involved. So I am not inclined to ignore the VRs.
My point is that VRs are only a translation mechanism and a proven black box. VRs should not cause the problem, and in this case it is far better to avoid software translation since there is enough hardware translation already to cause confusion.
Better look at the MSRs directly, see what is up, fix it, and then VSA should work as usual.
Here's the latest version of the program together with alix1c output.
input enable 0f7af085 invert 0xcf7e3081 irqmap from vr is 0xd0c0700 4d1:4d0 0e00 Filter events: 0/00 1/00 2/00 3/00 4/00 5/00 6/00 7/00 IRQ A, GPIO pin 0 Input Enabled and Inverted IRQ B, GPIO pin 7 Input Enabled and Inverted IRQ C, GPIO pin 12 Input Enabled and Inverted IRQ D, GPIO pin 13 Input Enabled and Inverted
This looks much more correct than the last one.
So notice that it appears when coreboot sets the VRs for INTAB and INTCD, VSA is setting up the GPIOs as enabled and inverted. Useful to know.
Yeah, I mentioned this after going through VSA.
Next steps are to see how the 22/23 registers are set up, and, with luck, trace it all the way through and maybe even find the problem. For now, however, the 3v PCI slot INTs are not working at all, as far as I can tell.
I will try to test. Maybe I can find a 3v wifi card.
They're almost acting edge-triggered. I think it's an artifact of sharing PCI INTs with the USB
USB is 5536-internal and does not cause interrupts in the same way that the actual (external) PCI bus does. 5536 modules interrupt on PIC Unrestricted Y inputs, while PCI INTA..INTD come in on PIC Unrestricted Z inputs. They have individual mappings.
-- the ethernet, which is attached in the same way (with the same wire!) as the PCI slot, works just fine. It's very odd.
Have you tested/asked Pascal if/how INTA..INTD are swizzled on the 1c?
//Peter
On Mon, May 12, 2008 at 3:08 AM, Peter Stuge peter@stuge.se wrote:
On Sun, May 11, 2008 at 09:51:10PM -0700, ron minnich wrote:
At the very least, explain how the confusing thicket of LX interrupts is wired up,
So decode the mapping and input condition MSRs.
that didn't help at all with the MFGPT problem.
In the limit, we ought to be able to run this tool on a working system, compare it to a non-working system, and see what's different.
A small number (4 or 6) of MSRs really have all the information that is needed. Just dump them.
No, I want it all. The GPIOs play in this game, as does 4d0/4d1; there are a lot of chances for things to go wrong.
I will rename them too but at present I'm a lot more concerned with tracking down whatever is set up wrong on the alix1c. Something is just flat out wrong! We need to find it and I'm running out of time with the Berlin show looming.
Oh but I'm not sure we have any PCI cards anyway. I don't, at least.
I do on the alix1c. And they don't work.
You have to talk to VRs because VSA talks VRs, and when you Do Certain Things, VSA gets involved. So I am not inclined to ignore the VRs.
My point is that VRs are only a translation mechanism and a proven black box. VRs should not cause the problem, and in this case it is far better to avoid software translation since there is enough hardware translation already to cause confusion.
Doesn't matter to me. coreboot uses them, I want to see what VSA's opinion is on their value.
I will try to test. Maybe I can find a 3v wifi card.
thanks
USB is 5536-internal and does not cause interrupts in the same way that the actual (external) PCI bus does. 5536 modules interrupt on PIC Unrestricted Y inputs, while PCI INTA..INTD come in on PIC Unrestricted Z inputs. They have individual mappings.
but the IRQ is shared. That's what makes this so much fun.
-- the ethernet, which is attached in the same way (with the same wire!) as the PCI slot, works just fine. It's very odd.
Have you tested/asked Pascal if/how INTA..INTD are swizzled on the 1c?
I've had schematics for months. I know how they're swizzled. They just don't work.
ron
On Mon, May 12, 2008 at 12:51 AM, ron minnich rminnich@gmail.com wrote:
I don't actually see a difference from my end between an IRQ (Interrupt request in old-speak) and a PCI INT (interrupt request in old speak) but if you want to rename things, have at it. Code attached, do your worst!
You do need to be careful about this. INTA could be hooked to IRQA (10 decimal). If you want to un-confuse yourself and others, you need to have the proper terminology.
So notice that it appears when coreboot sets the VRs for INTAB and INTCD, VSA is setting up the GPIOs as enabled and inverted. Useful to know. Next steps are to see how the 22/23 registers are set up, and, with luck, trace it all the way through and maybe even find the problem. For now, however, the 3v PCI slot INTs are not working at all, as far as I can tell. They're almost acting edge-triggered. I think it's an artifact of sharing PCI INTs with the USB -- the ethernet, which is attached in the same way (with the same wire!) as the PCI slot, works just fine. It's very odd.
From an earlier post, your USB card is using *3 INTs*. I would guess
your ethernet is using only one. For the USB to work, you probably need all three of INTA, INTB, and INTC working. properly. For ethernet, you only need the one hooked to the ethernet's INTA to work.
On Mon, May 12, 2008 at 12:51 AM, ron minnich rminnich@gmail.com wrote:
I don't actually see a difference from my end between an IRQ (Interrupt request in old-speak) and a PCI INT (interrupt request in old speak) but if you want to rename things, have at it. Code attached, do your worst!
This tool is a bit useful already. Can you run it on the alix1c's tinybios (or whatever works best on the alix)? Do all ports of your USB card work on alix with that BIOS? At a minumum, you need to check and make sure that INTs A-D are *really* GPIOs 0, 7, 12, and 13. (and as Peter said, you need to verify how they are hooked up to the slot)
I think Peter gets it, but the last piece missing from the tool is how the GPIOs (INTs) get mapped to the interrupts (IRQs). There are 2 pieces of this, the GPIO mappers and the IRQ mappers. The GPIO mapper selects which of the 7 interrupt outputs from the GPIO block are mapped to a specific GPIO pin. The registers are in GPIO space, offsets EO, E4, and E8. After that, those 7 outputs from the GPIO block can be mapped onto a particular IRQ number. That happens in the IRQ mapper register, which is MSR address 51400023 for the GPIO inputs.
On Mon, May 12, 2008 at 6:59 AM, Tom Sylla tsylla@gmail.com wrote:
This tool is a bit useful already. Can you run it on the alix1c's tinybios (or whatever works best on the alix)? Do all ports of your USB card work on alix with that BIOS? At a minumum, you need to check and make sure that INTs A-D are *really* GPIOs 0, 7, 12, and 13. (and as Peter said, you need to verify how they are hooked up to the slot)
verified. One bit of verification is that eth0 on schematic matches up with eth0 in the $PIR table.
i'd like to run under tinybios and will try this once I trust the tool. or someone can run it for me -- my FLASH on the LPC died.
I think Peter gets it, but the last piece missing from the tool is how the GPIOs (INTs) get mapped to the interrupts (IRQs). There are 2 pieces of this, the GPIO mappers and the IRQ mappers. The GPIO mapper selects which of the 7 interrupt outputs from the GPIO block are mapped to a specific GPIO pin. The registers are in GPIO space, offsets EO, E4, and E8. After that, those 7 outputs from the GPIO block can be mapped onto a particular IRQ number. That happens in the IRQ mapper register, which is MSR address 51400023 for the GPIO inputs.
yes, that's the last piece to put in, I ran out of time, if anyone wants to drop that code in I'd appreciate it.
thanks
ron
On 12.05.2008 17:04, ron minnich wrote:
On Mon, May 12, 2008 at 6:59 AM, Tom Sylla tsylla@gmail.com wrote:
This tool is a bit useful already. Can you run it on the alix1c's tinybios (or whatever works best on the alix)? Do all ports of your USB card work on alix with that BIOS? At a minumum, you need to check and make sure that INTs A-D are *really* GPIOs 0, 7, 12, and 13. (and as Peter said, you need to verify how they are hooked up to the slot)
verified. One bit of verification is that eth0 on schematic matches up with eth0 in the $PIR table.
i'd like to run under tinybios and will try this once I trust the tool. or someone can run it for me -- my FLASH on the LPC died.
In theory, the vendor BIOS can be loaded from the dongle. http://www.pcengines.ch/file/alixbio3.zip has the most recent alix.1c BIOS.
Regards, Carl-Daniel
On Mon, May 12, 2008 at 05:24:09PM +0200, Carl-Daniel Hailfinger wrote:
On 12.05.2008 17:04, ron minnich wrote:
On Mon, May 12, 2008 at 6:59 AM, Tom Sylla tsylla@gmail.com wrote:
This tool is a bit useful already. Can you run it on the alix1c's tinybios (or whatever works best on the alix)? Do all ports of your USB card work on alix with that BIOS? At a minumum, you need to check and make sure that INTs A-D are *really* GPIOs 0, 7, 12, and 13. (and as Peter said, you need to verify how they are hooked up to the slot)
verified. One bit of verification is that eth0 on schematic matches up with eth0 in the $PIR table.
i'd like to run under tinybios and will try this once I trust the tool. or someone can run it for me -- my FLASH on the LPC died.
In theory, the vendor BIOS can be loaded from the dongle.
Yeah, I'm pretty sure I succesfully tried doing that when I was testing my dongle cable.
Thanks, Ward.
Version latest: There may be a bug in the code but ... if not, the map for C and D looks wrong.
input enable 0f7af085 invert 0xcf7e3081 irqmap from vr is 0xd0c0700 4d1:4d0 0e00 GPIOmap (e0 to e8): 0/20000001 4/00430000 8/00000000 12/00000000 INTA, GPIO pin 0 Input Enabled and Inverted Interrupt:IG 1 INTB, GPIO pin 7 Input Enabled and Inverted Interrupt:IG 2 INTC, GPIO pin 12 Input Enabled and Inverted Interrupt:IG 0 INTD, GPIO pin 13 Input Enabled and Inverted Interrupt:IG 0
thanks
ron
On Mon, May 12, 2008 at 08:51:53AM -0700, ron minnich wrote:
INTC, GPIO pin 12 Input Enabled and Inverted Interrupt:IG 0 INTD, GPIO pin 13 Input Enabled and Inverted Interrupt:IG 0
IG 0 means that the interrupt source is disabled. Try setting that mapping to the same two numbers you've specified in the PIR table for INTC and INTD.
I think things will start working automagically if you write directly to that mapping MSR.
You can also try writing to VR 0x5d, but that's the same code as I suppose has run at least once already when coreboot wrote to 0x5d.
Strange that the mapping is not set. Does coreboot in fact write to 0x5d? It does seem so since inputs are not enabled by default.
Oh, wait. I just discovered something i VSA sysmgr/mapper.h:
Z_IRQ_INTA..D are always set to 9..12.
This means that external PCI interrupts will always trigger 9..12, and if 5536 modules are supposed to share the same lines then all LX PIR tables must also use 9..12.
As far as I can see, the SYS_MAP_IRQ call in legacy/cs5536.c PCI_Interrupt_Steering() will always change only the YLOW mapping MSR. Strange. I think I need to look through VSA another few hours.
There simply seems to be no call to IRQZ_Mapper in VSA that will set up interrupt mapping for the GPIOs, but obviously something is set up for two of the GPIO interrupts.
What about GPIO Mapper Y and Z (E4 or thereabout) and PIC mapping for Unrestricted inputs 8..15? (PIC MSR 23h)
//Peter
latest
/tmp/lxirq input enable 0f7af085 invert 0xcf7e3081 irqmap from vr is 0xd0c0700 4d1:4d0 0e00 GPIOmap (e0 to e8): 0/20000001 4/08051538 8/00000000 12/00000000 GPIO0: Interrupt:IG 1 GPIO7: Interrupt:IG 2 GPIO12: Interrupt:IG 3 GPIO13: Interrupt:IG 4 MSR 0x51400023: 0x9bab2
INTA, GPIO pin 0;Input Enabled and Inverted,Interrupt:GPIO BIT 1,IG 11, INTB, GPIO pin 7;Input Enabled and Inverted,Interrupt:GPIO BIT 2,IG 10, INTC, GPIO pin 12;Input Enabled and Inverted,Interrupt:GPIO BIT 3,IG 11, INTD, GPIO pin 13;Input Enabled and Inverted,Interrupt:GPIO BIT 4,IG 9,
well, so far, it looks ok. The 4d1/4d0 value says 9,10,11 are level, right?
i.e. I'm more confused than ever :-)
One of two bits left to plumb, but no obvious error so far.
If it's ok, why won't it work?
ron
Enough for one night. I'm also checking 51400024 for mask in this pass.
So, it's all wired right, eth0 works fine as it is swizzled to INTB, and it behaves as expected and as this program says it should. what doesn't work is PCI 3v slot to INTS C or D. And, they're shared with USB, and I'm convinced that's part of it.
But maybe somebody out there can see it; I can not yet.
Code attached; hack away.
ron
/tmp/lxirq input enable 0f7af085 invert 0xcf7e3081 irqmap from vr is 0xd0c0700 4d1:4d0 0e00 GPIOmap (e0 to e8): 0/20000001 4/08051538 8/14000e00 12/00000000 GPIO0: Interrupt:IG 1 GPIO7: Interrupt:IG 2 GPIO12: Interrupt:IG 3 GPIO13: Interrupt:IG 4 MSR 0x51400023: 0x9bab2
MSR 0x51400024: 0xffff
INTA, GPIO pin 0;Input Enabled and Inverted,Interrupt:GPIO BIT 1,IG 11,Not masked, INTB, GPIO pin 7;Input Enabled and Inverted,Interrupt:GPIO BIT 2,IG 10,Not masked, INTC, GPIO pin 12;Input Enabled and Inverted,Interrupt:GPIO BIT 3,IG 11,Not masked, INTD, GPIO pin 13;Input Enabled and Inverted,Interrupt:GPIO BIT 4,IG 9,Not masked,
Hmm. alix1c prod. bios is different: 1. ACPI tables. 2. input enable 0b7af485 invert 0xcf7e3081 irqmap from vr is 0xd0c0700 4d1:4d0 0e00 GPIOmap (e0 to e8): 0/20000001 4/08051340 8/61000e00 12/00000000 GPIO0: Interrupt:IG 1 GPIO7: Interrupt:IG 2 GPIO12: Interrupt:IG 3 GPIO13: Interrupt:IG 4 GPIO25: PME:IG 7 GPIO26: PME:IG 6 MSR 0x51400023: 0xbaba2
MSR 0x51400024: 0xffff
INTA, GPIO pin 0;Input Enabled and Inverted,Interrupt:GPIO BIT 1,IG 10,Not masked, INTB, GPIO pin 7;Input Enabled and Inverted,Interrupt:GPIO BIT 2,IG 11,Not masked, INTC, GPIO pin 12;Input Enabled and Inverted,Interrupt:GPIO BIT 3,IG 10,Not masked, INTD, GPIO pin 13;Input Enabled and Inverted,Interrupt:GPIO BIT 4,IG 11,Not masked,
They only use IRQs 11/10, not 9.
Also: 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31) 00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block 00:0c.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 00:0c.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 00:0c.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) 00:0d.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96) 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03) 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01) 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (re) 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02) 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02) pbx ~ # lspci -v -v -v | grep Int -v -v -v | grep Int Interrupt: pin A routed to IRQ 10 Interrupt: pin A routed to IRQ 10 Interrupt: pin A routed to IRQ 10 Interrupt: pin B routed to IRQ 11 Interrupt: pin C routed to IRQ 10 Interrupt: pin A routed to IRQ 11 Interrupt: pin B routed to IRQ 11 Interrupt: pin D routed to IRQ 11 Interrupt: pin D routed to IRQ 5
The last USB is IRQ 5 ...
OK, that is it for me.
ron
On 13.05.2008 07:01, ron minnich wrote:
Hmm. alix1c prod. bios is different:
- ACPI tables.
- input enable 0b7af485 invert 0xcf7e3081
irqmap from vr is 0xd0c0700 4d1:4d0 0e00 GPIOmap (e0 to e8): 0/20000001 4/08051340 8/61000e00 12/00000000 GPIO0: Interrupt:IG 1 GPIO7: Interrupt:IG 2 GPIO12: Interrupt:IG 3 GPIO13: Interrupt:IG 4 GPIO25: PME:IG 7 GPIO26: PME:IG 6 MSR 0x51400023: 0xbaba2
MSR 0x51400024: 0xffff
INTA, GPIO pin 0;Input Enabled and Inverted,Interrupt:GPIO BIT 1,IG 10,Not masked, INTB, GPIO pin 7;Input Enabled and Inverted,Interrupt:GPIO BIT 2,IG 11,Not masked, INTC, GPIO pin 12;Input Enabled and Inverted,Interrupt:GPIO BIT 3,IG 10,Not masked, INTD, GPIO pin 13;Input Enabled and Inverted,Interrupt:GPIO BIT 4,IG 11,Not masked,
They only use IRQs 11/10, not 9.
Also: 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31) 00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block 00:0c.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 00:0c.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 00:0c.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) 00:0d.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96) 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03) 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01) 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (re) 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02) 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02) pbx ~ # lspci -v -v -v | grep Int -v -v -v | grep Int Interrupt: pin A routed to IRQ 10 Interrupt: pin A routed to IRQ 10 Interrupt: pin A routed to IRQ 10 Interrupt: pin B routed to IRQ 11 Interrupt: pin C routed to IRQ 10 Interrupt: pin A routed to IRQ 11 Interrupt: pin B routed to IRQ 11 Interrupt: pin D routed to IRQ 11 Interrupt: pin D routed to IRQ 5
The last USB is IRQ 5 ...
OK, that is it for me.
How about we try to partially imitate the vendor BIOS? With the time constraints we have, getting it to work first, then understanding it so we can change it as we want is probably the way to go.
Patch follows. I'd be very interested in lxirq output of the alix1c with this patch applied.
Regards, Carl-Daniel
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: LinuxBIOSv3-alix1c/mainboard/pcengines/alix1c/irq_tables.h =================================================================== --- LinuxBIOSv3-alix1c/mainboard/pcengines/alix1c/irq_tables.h (Revision 682) +++ LinuxBIOSv3-alix1c/mainboard/pcengines/alix1c/irq_tables.h (Arbeitskopie) @@ -23,10 +23,10 @@ #define IRQ_SLOT_COUNT 5
/* Platform IRQs */ -#define PIRQA 11 -#define PIRQB 10 -#define PIRQC 11 -#define PIRQD 9 +#define PIRQA 10 +#define PIRQB 11 +#define PIRQC 10 +#define PIRQD 11
/* Map */ #define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */
It did not help. 4d1:4d0 0c00 GPIOmap (e0 to e8): 0/20000001 4/08051538 8/14000c00 12/00000000 GPIO0: Interrupt:IG 1 GPIO7: Interrupt:IG 2 GPIO12: Interrupt:IG 3 GPIO13: Interrupt:IG 4 MSR 0x51400023: 0xbaba2
MSR 0x51400024: 0xffff
INTA, GPIO pin 0;Input Enabled and Inverted,Interrupt:GPIO BIT 1,IG 10,Not masked, INTB, GPIO pin 7;Input Enabled and Inverted,Interrupt:GPIO BIT 2,IG 11,Not masked, INTC, GPIO pin 12;Input Enabled and Inverted,Interrupt:GPIO BIT 3,IG 10,Not masked, INTD, GPIO pin 13;Input Enabled and Inverted,Interrupt:GPIO BIT 4,IG 11,Not masked,
I suspect the issue is some conflict with the other routing. Note that the factory bios used IRQ 5 for the second USB device. This is not to be found in any PIR table.
However ... I just tried this USB card on factory bios. Lesson: never assume anything. I used to use this card to test PCI stuff and it just no longer works on this system. It did, but ... Linux problem? Who knows? So this card goes back on the shelf ... I'll try to find a non-ISDN PCI card to test with.
ron
I'm willing to call this one baked. I am getting all the same behavior on factory and coreboot. The isdn card won't work on factory either -- I was told it did, maybe I have a bad alix or a bad isdn card, or the isdn drivers are that fragile (I suspect this), who knows?
Modular ISDN Stack core version (1_2_0) revision ($Revision: 1.40 $) mISDNd: kernel daemon started (current:cf1bc000) mISDNd: test event done ACPI: PCI Interrupt Link [LNKC] BIOS reported IRQ 0, using IRQ 10 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 mISDN_hfcpci: found adapter CCD/Billion/Asuscom 2BD0 at 0000:00:0c.0 HFC card cf310000 dch cf31005c bch1 cf3101b0 bch2 cf310304 mISDN: HFC-PCI driver Rev. 1.50 HFC-PCI: defined at mem 0xd0052000 fifo 0xcf318000(0xf318000) IRQ 10 HZ 1000 reset_hfcpci: entered HFC_PCI: resetting HFC ChipId(30) HFC-PCI status(4) before reset HFC-PCI status(2) after reset HFC-PCI status(4) after 10us init_card: entered inithfcpci: entered ISDN L1 driver version 1.20 HFC PCI: IRQ 10 count 33 HFC 1 cards installed ISDN L2 driver version 1.32 mISDN: INTERNAL ERROR in /home/rminnich/src/bios/mISDN/drivers/isdn/hardware/mISDN/stack.c:1173 release_l1 id 100 mISDNd: addr(f0000) prim(f1980) failed err(-92) ttyS0: 1 input overrun(s)
thanks
ron
On 13.05.2008 17:59, ron minnich wrote:
I'm willing to call this one baked. I am getting all the same behavior on factory and coreboot. The isdn card won't work on factory either -- I was told it did, maybe I have a bad alix or a bad isdn card, or the isdn drivers are that fragile (I suspect this), who knows?
It would be interesting to know who got the card working on alix and what kernel/patches he used. If we manage to find a working kernel/hardware combination, we can continue analyzing the problem.
Regards, Carl-Daniel
I don't like the fact that my pci slot doesn't work at all any more. I'm not sure any testing I do makes sense. I'm worried about my hardware ....
I'm going to move to dbe61 for now until I can find a minipci or other to test.
So, dbe61 guys: SEND ME MEMORY SETTINGS!
ron
On Tue, May 13, 2008 at 6:18 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Patch follows. I'd be very interested in lxirq output of the alix1c with this patch applied.
Regards, Carl-Daniel
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Acked-by: Ronald G. Minnich rminnich@gmail.com
go ahead and commit, at the very least it does no harm.
ron
On 13.05.2008 18:00, ron minnich wrote:
On Tue, May 13, 2008 at 6:18 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Patch follows. I'd be very interested in lxirq output of the alix1c with this patch applied.
Regards, Carl-Daniel
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Acked-by: Ronald G. Minnich rminnich@gmail.com
go ahead and commit, at the very least it does no harm.
I'd like to hold back committing because you found out that the factory BIOS settings do not work better than our settings. Changing from one non-working setting to another is not helpful.
Regards, Carl-Daniel
Peter Stuge wrote:
32663C_lx_gx_pciconfig.pdf page 46-49 seems to suggest that USB is always on INTD# IRQ11. This could be hardwired in LX/5536; GL packets from USB will always trigger IRQ11. Or worse they will always trigger PCI_INTD# meaning a well-designed board with 4 PCI slots, or a badly designed board with less slots will always need to share somewhere.
Just to clear up a few confusions in this thread:
Nothing is hard-wired, not even the INTD for USB. All of the interrupt routing in 5536 is configured in the IRQ mapper in the MDD. See section 5.8 of the 5536 datasheet. USB is just input 2 to the unrestricted Y mapper. Lots of other southbridges have similar second-level PIC mappers (XPICs, etc) for their on-board devices.
The "linkage" to INTD is done in VSA:
http://dev.laptop.org/git?p=geode-vsa;a=blob;f=sysmgr/topology.c;h=71d1fe421...
(note the Int Line value in that code is a flag for later: http://dev.laptop.org/git?p=geode-vsa;a=blob;f=legacy/cs5536.c;h=0bcf5f61e60... )
As said later in this thread, USB needs to be a well-behaved PCI device and needs a Int Pin and Int Line. When the PCI config space for LX/5536 was defined, we had to pick a pin for the internal devices. VSA (config space) has to have something defined. That was INTD for USB (similarly INTB for audio). USB just gets stuck with whatever Int Line goes with INTD.
Tom
On 04.05.2008 03:11, Peter Stuge wrote:
On Fri, May 02, 2008 at 09:46:41PM -0700, ron minnich wrote:
get the USB interrupts out of the PIR table. They are not really routed via the standard IRQ router anyway -- they are internal -- and don't need to share interrupt #s with the other devices that are actually routed via the interrupt routing hardware.
Are you sure? From the OS point of view they still need a 4-bit interrupt number, since they are supposed to be PCI devices. No?
Put simply, having the USB f.3,4,5 devices in the PIR table works, but is really a bit of a mistake.
USB is on the GLIU in 5536 and not on any external PCI bus.
But it still appears to be a PCI device, and it needs an interrupt.
but, short form: on the cs5536, USB interrupts should not be described in the PIR table, but via settings derived from dts. They should be initialized in cs5536 setup code, no in the PIR setup code. That will allow us to have non-shared interrupts on the various PCI slots on, e.g., alix1c, and allow broken drivers like hfcpci to work.
Yep. Is good.
Can we store the USB interrupts settings in a separate struct/table in irq_tables.h? That would allow us to keep all interrupt stuff together in one file and avoid the problems we had with v2 where settings were scattered all over the tree in lots of different files.
Regards, Carl-Daniel
On Sun, May 04, 2008 at 03:35:49AM +0200, Carl-Daniel Hailfinger wrote:
but, short form: on the cs5536, USB interrupts should not be described in the PIR table,
Can we store the USB interrupts settings in a separate struct/table in irq_tables.h? That would allow us to keep all interrupt stuff together in one file
Thinking a bit more about this I'm not sure I agree anymore Ron.
Since the devices should look like PCI devices maybe they should be in the PIR table, and 5536 code shall instead know to handle some devices specially?
//Peter
On Sat, May 3, 2008 at 6:41 PM, Peter Stuge peter@stuge.se wrote:
On Sun, May 04, 2008 at 03:35:49AM +0200, Carl-Daniel Hailfinger wrote:
but, short form: on the cs5536, USB interrupts should not be described in the PIR table,
Can we store the USB interrupts settings in a separate struct/table in irq_tables.h? That would allow us to keep all interrupt stuff together in one file
Thinking a bit more about this I'm not sure I agree anymore Ron.
Since the devices should look like PCI devices maybe they should be in the PIR table, and 5536 code shall instead know to handle some devices specially?
thanks for looking up the IRQs in the manual.
The real problem is the broken ISDN driver. I think I'll focus on that code -- it's awful -- and see where I can get. Everything else "just works". I am fixing the wrong problem with this IRQ messing around. I have reverted my local changes and will focus on real, not imaginary problems.
One remaining real problem is MFGPT, which doesn't work on v2 either.
thanks
ron
On Sat, May 3, 2008 at 6:35 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Can we store the USB interrupts settings in a separate struct/table in irq_tables.h? That would allow us to keep all interrupt stuff together in one file and avoid the problems we had with v2 where settings were scattered all over the tree in lots of different files.
no, your earlier suggestion was better: store this stuff in dts, generate irq table at run time.
This has to get done, I just have not had time. If someone else gets it first, no harm done :-)
thanks! ron
ron minnich wrote:
(I'm hoping someone will do this :-)
One issue I'm having is that the hfcpci card (or driver) can't tolerate shared interrupts. But we have shared interrupts on the various cs5536 boards, since we put USB interrupt info in the table.
To allow us to have non-shared interrupts for all devices, we need to get the USB interrupts out of the PIR table. They are not really routed via the standard IRQ router anyway -- they are internal -- and don't need to share interrupt #s with the other devices that are actually routed via the interrupt routing hardware.
Put simply, having the USB f.3,4,5 devices in the PIR table works, but is really a bit of a mistake.
OK, where do we put the IRQ info for the USB devices? In the DTS for the cs5536.
SO in DTS for the cs5536 we need three more properties, usbf3 usbf4 usbf5
with reasonable settings for them. Then in the chipset init code, we need to see if these are set and, if so, set the IRQ line in the f.3, f.4, and f.5 devices.
If this is confusing I can explain in more detail, but later, I'm tired, and the ISDN card just locked up again. How can such a simple driver have so many failure modes? Oh, wait, it's not simple, sigh.
but, short form: on the cs5536, USB interrupts should not be described in the PIR table, but via settings derived from dts. They should be initialized in cs5536 setup code, no in the PIR setup code. That will allow us to have non-shared interrupts on the various PCI slots on, e.g., alix1c, and allow broken drivers like hfcpci to work.
ron
Ron,
I understand that you are addressing a problem but I have to disagree that the 5536 USB controllers shouldn't be in the PIR table. Even if you change the internal devices IRQs you should still put them in the table.
As for changing the IRQs. In PCI there is no interrupt contention. The interrupts are level triggered. You should be able to put them all on a single IRQ. It is easier to debug device driver issues if they are on separate IRQs but that should be the only advantage. If IRQs are not being serviced correctly and fast enough that is a Linux driver issue.
For your specific problems; Do you have a USB device plugged in? If not there should be little to no activity from USB. How can that be the problem? Since you do have a problem with that mainboard and card, I think that any changes you make should be only for that mainboard.
Marc
On Mon, May 5, 2008 at 10:06 AM, Marc Jones Marc.Jones@amd.com wrote:
I understand that you are addressing a problem but I have to disagree that the 5536 USB controllers shouldn't be in the PIR table. Even if you change the internal devices IRQs you should still put them in the table.
I think you are right as usual. I'm wrong.
For your specific problems; Do you have a USB device plugged in? If not there should be little to no activity from USB. How can that be the problem? Since you do have a problem with that mainboard and card, I think that any changes you make should be only for that mainboard.
agree.
The real issue anyway is that ISDN driver, I just can't stand to look at it :-) But I have to.
ron
-
Carl-Daniel Hailfinger -
Marc Jones -
Mart Raudsepp -
Peter Stuge -
ron minnich -
Tom Sylla -
Ward Vandewege