Re: dual TT C-1501 on a single PCI riser
On 03/15/2010 01:50 PM, Martin van Es wrote: > When I look at the pci layout, pci device 05 is connected to bridge 1e.0: > -[:00]-+-00.0 >+-1e.0-[05]--+-00.0 Philips Semiconductors SAA7146 >|\-0c.0 Philips Semiconductors SAA7146 No, this means bridge 1e.0 connects to bus number 05. > So I started to suspect that the motherboard had no way to know what > PCI int's were used behind the bridge if both cards were detected to serve > INTA (i.e. 05.0x = INTA in lspci -v) and would thus (quite stupidly?) > route any int for this slot to INTA? I don't get that sentence.. Every slot has INTA/B/C/D and each PCI function announces which one of these it uses. In most cases INTA is used. The board manufacturer for bus 05 only knows how INTx maps to APIC inputs for slot 00. He knows there are people who use riser cards, so he adds mappings for non-existent slots by permuting those interrupts available to slot 00. > Last change was to cut the original slot2 connection to INTD and gone were my > extra interrupts! It might be INTD isn't connected to the APIC. It is rarely used on cards. > So now I have two correctly recognised cards, both using int 20 and PCI INTA. > Now I wonder if this will harm the performance if both cards are recording > streams, let alone if they work, because that's the next test I still have to > do. It should work. On interrupt the driver will be called once for each card to check if the card in question caused the interrupt. As long as we are not talking about thousands of interrupts per second, this shouldn't harm performance. Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - your embedded linux partner -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dual TT C-1501 on a single PCI riser
Hi Daniel, Thx for your answer. It put me on the right track because I have finally solved the puzzle! Here's how: I did some testing with the IDSEL jumpers and saw the following pattern: IDSEL GSI/IRQ reported by kernel. 24 17 25 20 26 no route -> 1 27 no route -> 1 28 17 29 20 30 no route -> 1 31 no device present But none of these settings resulted in a response to interrupts. Also I had measured that INTA of slot2 was wired to INTD of the riser connector, which I thought strange, because I'd expect a forward rotation for slot2 (A>B)? When I look at the pci layout, pci device 05 is connected to bridge 1e.0: -[:00]-+-00.0 +-02.0 +-02.1 +-1b.0 +-1c.0-[01]00.0 +-1c.1-[02]-- +-1c.2-[03]-- +-1c.3-[04]-- +-1d.0 +-1d.1 +-1d.2 +-1d.3 +-1d.7 +-1e.0-[05]--+-00.0 Philips Semiconductors SAA7146 |\-0c.0 Philips Semiconductors SAA7146 +-1f.0 +-1f.1 +-1f.2 \-1f.3 Then I wondered if device 05 would still be present if I removed the riser and it was. So I started to suspect that the motherboard had no way to know what PCI int's were used behind the bridge if both cards were detected to serve INTA (i.e. 05.0x = INTA in lspci -v) and would thus (quite stupidly?) route any int for this slot to INTA? So, when I hard-wired the 2nd slot INTA to riser INTA together and used IDSEL 29 I had a succesful initialisation of the DVB card (the other IDSELs didn't work, even on different PCI INTs), but way too many interrupts on int 20. Then I tried both cards and that worked as well, but again far too many interrupts on int 20. Last change was to cut the original slot2 connection to INTD and gone were my extra interrupts! So now I have two correctly recognised cards, both using int 20 and PCI INTA. Now I wonder if this will harm the performance if both cards are recording streams, let alone if they work, because that's the next test I still have to do. Regards, Martin van Es On Sun, Mar 14, 2010 at 22:52, Daniel Glöckner wrote: > Hi, > > On Sun, Mar 14, 2010 at 05:14:33PM +0100, Martin van Es wrote: >> ? Pin A11: additional 33 MHz PCI clock >> ? Pin B10: additional PCI request signal (i.e., PREQ#2) >> ? Pin B14: additional PCI Grant signal (i.e., GNT#2) >> - >> >> I'm 100% sure the Tranquil riser does not support this suggestion >> since the A11/B10 and B14 leads are not used on the riser. > > Your riser card doesn't need these signals thanks to the IT8209R. > The drawback is that the cards will be granted less bus time when > competing with on board PCI peripherals. > >> On the other hand, my guess would be that an ordinary >> riser with arbiter and the correct wiring should do the trick. My >> question is more or less the same as Udo's in the thread I posted: how >> do I check if int 17 of the second card is correctly connected to int >> A of the second slot and if not, where to start changing things? > > PCI slots have four interrupts, INTA, INTB, INTC, and INTC. Riser cards > usually permute these for the second and following slots to avoid > interrupt sharing. The BIOS has a built-in table that tells Linux for > every slot which pin of the interrupt controller is connected to these > four interrupt lines. So we need to make the second slot appear to the > BIOS to be one where INTA is same interrupt as (probably) INTB of the > first slot. > > Slots are addressed using the IDSEL line. Every slot has its own line. > To reduce the number of signals (and to allow riser cards) the PCI > standards suggests reusing the upper AD lines as IDSEL lines for the > slots. So by changing the AD line connected to the IDSEL line of the > second slot with the jumper on the riser card, the slot will get another > number and thus another interrupt mapping. > > According to the ICH7 datasheet you should currently have selected > AD24, as your card is 08.0 on the bus (strange... at that position > should have been the intel ethernet controller..). Just subtract > 16 from the AD number to get the slot number. Now try all of them > until you find one where interrupts work. Avoid those already in > use on the same bus as listed by "lspci -tv". > > Good luck! > > Daniel > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dual TT C-1501 on a single PCI riser
Hi, On Sun, Mar 14, 2010 at 05:14:33PM +0100, Martin van Es wrote: > ? Pin A11: additional 33 MHz PCI clock > ? Pin B10: additional PCI request signal (i.e., PREQ#2) > ? Pin B14: additional PCI Grant signal (i.e., GNT#2) > - > > I'm 100% sure the Tranquil riser does not support this suggestion > since the A11/B10 and B14 leads are not used on the riser. Your riser card doesn't need these signals thanks to the IT8209R. The drawback is that the cards will be granted less bus time when competing with on board PCI peripherals. > On the other hand, my guess would be that an ordinary > riser with arbiter and the correct wiring should do the trick. My > question is more or less the same as Udo's in the thread I posted: how > do I check if int 17 of the second card is correctly connected to int > A of the second slot and if not, where to start changing things? PCI slots have four interrupts, INTA, INTB, INTC, and INTC. Riser cards usually permute these for the second and following slots to avoid interrupt sharing. The BIOS has a built-in table that tells Linux for every slot which pin of the interrupt controller is connected to these four interrupt lines. So we need to make the second slot appear to the BIOS to be one where INTA is same interrupt as (probably) INTB of the first slot. Slots are addressed using the IDSEL line. Every slot has its own line. To reduce the number of signals (and to allow riser cards) the PCI standards suggests reusing the upper AD lines as IDSEL lines for the slots. So by changing the AD line connected to the IDSEL line of the second slot with the jumper on the riser card, the slot will get another number and thus another interrupt mapping. According to the ICH7 datasheet you should currently have selected AD24, as your card is 08.0 on the bus (strange... at that position should have been the intel ethernet controller..). Just subtract 16 from the AD number to get the slot number. Now try all of them until you find one where interrupts work. Avoid those already in use on the same bus as listed by "lspci -tv". Good luck! Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dual TT C-1501 on a single PCI riser
Reply to myself with some extra information: Just found this thread about the same problem, but different MB: http://kerneltrap.org/mailarchive/linux-kernel/2007/2/18/56447 Have to study all the replies in more depth to see if there's a solution hidden in there for me. Another thing to remark is that the D945GSEJT does support a dual riser card as it's described in the manual: - The PCI bus connector also supports single-slot and dual-slot riser cards for use of up to two bus master PCI expansion cards. In order to support two PCI bus master expansion cards, the riser card must support the following PCI signal routing: • Pin A11: additional 33 MHz PCI clock • Pin B10: additional PCI request signal (i.e., PREQ#2) • Pin B14: additional PCI Grant signal (i.e., GNT#2) - I'm 100% sure the Tranquil riser does not support this suggestion since the A11/B10 and B14 leads are not used on the riser. So I'm doubting the remark that this riser is specifically made for the D945GSEJT. On the other hand, my guess would be that an ordinary riser with arbiter and the correct wiring should do the trick. My question is more or less the same as Udo's in the thread I posted: how do I check if int 17 of the second card is correctly connected to int A of the second slot and if not, where to start changing things? Regards Martin On Sun, Mar 14, 2010 at 13:21, Martin van Es wrote: > Hi, > > My name is Martin van Es and I just subscribed to the DVB mailinglist > because I'm currently facing a challenge that's beyond my knowledge so > I hope to find some cooperative minds in the list who could point me > in the right direction. > > My problem is that I try to build a dual DVB-C tuner HTPC, based on an > Intel D945GSEJT mini-itx motherboard. This board is equipped with only > 1 PCI slot, so a PCI riser is the only solution (no single board dual > DVB-C solutions exist today). > > The case I've bought came with a riser but that didn't work so my > first attempt was to order this riser, which, they say is specifically > designed for the D945GSEJT: > http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html (top one, > it's based on a IT8209R PCI Arbiter). > When that didn't work I suspected there's more to this than correct > hardware and started looking for solutions, including mailing a > knowledgable PCI expert but even that didn't bring much relief. I must > add that I'm technically inclined, just lack a background in low-level > (PC) hardware programming. > > So far my quest has revealed the following: > My 2 tunercards both get assigned a unique GSI on PCI interrupt A. > Both cards get detected correctly, but as soon as the second card > starts initialising the front-end it fails due to read/write timeouts > on the saa7146 (i2c). > The interrupt counter assigned to the second card never shows any > activity (cat /proc/interrupts counter for irq 17 is 0). > > Here are the (most) relevant pieces of dmesg output: > First the PCI initialisation. Mind the mentioning of both :05:* > devices (the riser slots): > > [ 0.234259] ACPI: PCI Root Bridge [PCI0] (:00) > [ 0.234500] pci :00:02.0: reg 10 32bit mmio: [0xdfe8-0xdfef] > [ 0.234520] pci :00:02.0: reg 14 io port: [0xf150-0xf157] > [ 0.234537] pci :00:02.0: reg 18 32bit mmio pref: > [0xc000-0xcfff] > [ 0.234555] pci :00:02.0: reg 1c 32bit mmio: [0xdff0-0xdff3] > [ 0.234641] pci :00:02.1: reg 10 32bit mmio: [0xdfe0-0xdfe7] > [ 0.234799] pci :00:1b.0: reg 10 64bit mmio: [0xffe0-0xffe03fff] > [ 0.234875] pci :00:1b.0: PME# supported from D0 D3hot D3cold > [ 0.234889] pci :00:1b.0: PME# disabled > [ 0.235003] pci :00:1c.0: PME# supported from D0 D3hot D3cold > [ 0.235016] pci :00:1c.0: PME# disabled > [ 0.235131] pci :00:1c.1: PME# supported from D0 D3hot D3cold > [ 0.235144] pci :00:1c.1: PME# disabled > [ 0.235259] pci :00:1c.2: PME# supported from D0 D3hot D3cold > [ 0.235272] pci :00:1c.2: PME# disabled > [ 0.235387] pci :00:1c.3: PME# supported from D0 D3hot D3cold > [ 0.235400] pci :00:1c.3: PME# disabled > [ 0.235488] pci :00:1d.0: reg 20 io port: [0xf0a0-0xf0bf] > [ 0.235578] pci :00:1d.1: reg 20 io port: [0xf080-0xf09f] > [ 0.235669] pci :00:1d.2: reg 20 io port: [0xf060-0xf07f] > [ 0.235759] pci :00:1d.3: reg 20 io port: [0xf040-0xf05f] > [ 0.235856] pci :00:1d.7: reg 10 32bit mmio: [0xdff41000-0xdff413ff] > [ 0.235940] pci :00:1d.7: PME# supported from D0 D3hot D3cold > [ 0.235954] pci :00:1d.7: PME# disabled > [ 0.236202] pci :00:1f.0: Force enabled HPET at 0xfed0 > [ 0.236221] pci :00:1f.0: quirk: region 0400-047f claimed by > ICH6 ACPI/GPIO/TCO > [ 0.236236] pci :00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO > [ 0.236251] pci :00:1f.0: ICH7 LPC Generic IO decode 1 PIO at > 0a00 (mask 007f) > [ 0.236265] pci :
dual TT C-1501 on a single PCI riser
Hi, My name is Martin van Es and I just subscribed to the DVB mailinglist because I'm currently facing a challenge that's beyond my knowledge so I hope to find some cooperative minds in the list who could point me in the right direction. My problem is that I try to build a dual DVB-C tuner HTPC, based on an Intel D945GSEJT mini-itx motherboard. This board is equipped with only 1 PCI slot, so a PCI riser is the only solution (no single board dual DVB-C solutions exist today). The case I've bought came with a riser but that didn't work so my first attempt was to order this riser, which, they say is specifically designed for the D945GSEJT: http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html (top one, it's based on a IT8209R PCI Arbiter). When that didn't work I suspected there's more to this than correct hardware and started looking for solutions, including mailing a knowledgable PCI expert but even that didn't bring much relief. I must add that I'm technically inclined, just lack a background in low-level (PC) hardware programming. So far my quest has revealed the following: My 2 tunercards both get assigned a unique GSI on PCI interrupt A. Both cards get detected correctly, but as soon as the second card starts initialising the front-end it fails due to read/write timeouts on the saa7146 (i2c). The interrupt counter assigned to the second card never shows any activity (cat /proc/interrupts counter for irq 17 is 0). Here are the (most) relevant pieces of dmesg output: First the PCI initialisation. Mind the mentioning of both :05:* devices (the riser slots): [0.234259] ACPI: PCI Root Bridge [PCI0] (:00) [0.234500] pci :00:02.0: reg 10 32bit mmio: [0xdfe8-0xdfef] [0.234520] pci :00:02.0: reg 14 io port: [0xf150-0xf157] [0.234537] pci :00:02.0: reg 18 32bit mmio pref: [0xc000-0xcfff] [0.234555] pci :00:02.0: reg 1c 32bit mmio: [0xdff0-0xdff3] [0.234641] pci :00:02.1: reg 10 32bit mmio: [0xdfe0-0xdfe7] [0.234799] pci :00:1b.0: reg 10 64bit mmio: [0xffe0-0xffe03fff] [0.234875] pci :00:1b.0: PME# supported from D0 D3hot D3cold [0.234889] pci :00:1b.0: PME# disabled [0.235003] pci :00:1c.0: PME# supported from D0 D3hot D3cold [0.235016] pci :00:1c.0: PME# disabled [0.235131] pci :00:1c.1: PME# supported from D0 D3hot D3cold [0.235144] pci :00:1c.1: PME# disabled [0.235259] pci :00:1c.2: PME# supported from D0 D3hot D3cold [0.235272] pci :00:1c.2: PME# disabled [0.235387] pci :00:1c.3: PME# supported from D0 D3hot D3cold [0.235400] pci :00:1c.3: PME# disabled [0.235488] pci :00:1d.0: reg 20 io port: [0xf0a0-0xf0bf] [0.235578] pci :00:1d.1: reg 20 io port: [0xf080-0xf09f] [0.235669] pci :00:1d.2: reg 20 io port: [0xf060-0xf07f] [0.235759] pci :00:1d.3: reg 20 io port: [0xf040-0xf05f] [0.235856] pci :00:1d.7: reg 10 32bit mmio: [0xdff41000-0xdff413ff] [0.235940] pci :00:1d.7: PME# supported from D0 D3hot D3cold [0.235954] pci :00:1d.7: PME# disabled [0.236202] pci :00:1f.0: Force enabled HPET at 0xfed0 [0.236221] pci :00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO [0.236236] pci :00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO [0.236251] pci :00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0a00 (mask 007f) [0.236265] pci :00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 1640 (mask 000f) [0.236352] pci :00:1f.1: reg 10 io port: [0xf140-0xf147] [0.236371] pci :00:1f.1: reg 14 io port: [0xf130-0xf133] [0.236390] pci :00:1f.1: reg 18 io port: [0xf120-0xf127] [0.236408] pci :00:1f.1: reg 1c io port: [0xf110-0xf113] [0.236426] pci :00:1f.1: reg 20 io port: [0xf100-0xf10f] [0.236524] pci :00:1f.2: reg 10 io port: [0xf0f0-0xf0f7] [0.236542] pci :00:1f.2: reg 14 io port: [0xf0e0-0xf0e3] [0.236560] pci :00:1f.2: reg 18 io port: [0xf0d0-0xf0d7] [0.236578] pci :00:1f.2: reg 1c io port: [0xf0c0-0xf0c3] [0.236595] pci :00:1f.2: reg 20 io port: [0xf020-0xf03f] [0.236614] pci :00:1f.2: reg 24 32bit mmio: [0xdff4-0xdff403ff] [0.236668] pci :00:1f.2: PME# supported from D3hot [0.236681] pci :00:1f.2: PME# disabled [0.236765] pci :00:1f.3: reg 20 io port: [0x1180-0x119f] [0.236891] pci :01:00.0: reg 10 io port: [0xe000-0xe0ff] [0.236929] pci :01:00.0: reg 18 64bit mmio pref: [0xffd04000-0xffd04fff] [0.236959] pci :01:00.0: reg 20 64bit mmio pref: [0xffd0-0xffd03fff] [0.236980] pci :01:00.0: reg 30 32bit mmio pref: [0xdfd0-0xdfd1] [0.237045] pci :01:00.0: supports D1 D2 [0.237055] pci :01:00.0: PME# supported from D0 D1 D2 D3hot D3cold [0.237069] pci :01:00.0: PME# disabled [0.237163] pci :00:1c.0: bridge io port: [0xe000-0xefff] [0.237178] pci 00
