| Message ID | 1383909539-29929-17-git-send-email-paul.burton@imgtec.com |
|---|---|
| State | Accepted |
| Delegated to: | Daniel Schwierzeck |
| Headers | show |
Dear Paul Burton, > Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will > be left disabled. Linux does not set up this routing but relies upon it > having been set up by the bootloader, reading back the IRQ lines which > the PIRQ[A:D] signals have been routed to. Did you also submit a fix to Linux guys? Best regards, Marek Vasut
On 10/11/13 20:09, Marek Vasut wrote: > Dear Paul Burton, > >> Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will >> be left disabled. Linux does not set up this routing but relies upon it >> having been set up by the bootloader, reading back the IRQ lines which >> the PIRQ[A:D] signals have been routed to. > > Did you also submit a fix to Linux guys? > > Best regards, > Marek Vasut > No, I haven't. Although Linux is reliant upon these values having been programmed it's quite clear from reading its code that that depence is intentional. It explicitely reads the route setup by the bootloader rather than clobbering it, and to me that does make sense in this case. However the pcnet32 ethernet driver seems to be reliant upon the interrupt and doesn't handle the case of a PCI device with no assigned interrupt, so I'll send a patch to fail its probe in that case shortly. Thanks, Paul
Dear Paul Burton, > On 10/11/13 20:09, Marek Vasut wrote: > > Dear Paul Burton, > > > >> Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will > >> be left disabled. Linux does not set up this routing but relies upon it > >> having been set up by the bootloader, reading back the IRQ lines which > >> the PIRQ[A:D] signals have been routed to. > > > > Did you also submit a fix to Linux guys? > > > > Best regards, > > Marek Vasut > > No, I haven't. Although Linux is reliant upon these values having been > programmed it's quite clear from reading its code that that depence is > intentional. It explicitely reads the route setup by the bootloader > rather than clobbering it, and to me that does make sense in this case. Can this setup not be passed via a well-designed DT binding then? > However the pcnet32 ethernet driver seems to be reliant upon the > interrupt and doesn't handle the case of a PCI device with no assigned > interrupt, so I'll send a patch to fail its probe in that case shortly. Thanks! Best regards, Marek Vasut
On 11/11/13 13:33, Marek Vasut wrote: > Dear Paul Burton, > >> On 10/11/13 20:09, Marek Vasut wrote: >>> Dear Paul Burton, >>> >>>> Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will >>>> be left disabled. Linux does not set up this routing but relies upon it >>>> having been set up by the bootloader, reading back the IRQ lines which >>>> the PIRQ[A:D] signals have been routed to. >>> >>> Did you also submit a fix to Linux guys? >>> >>> Best regards, >>> Marek Vasut >> >> No, I haven't. Although Linux is reliant upon these values having been >> programmed it's quite clear from reading its code that that depence is >> intentional. It explicitely reads the route setup by the bootloader >> rather than clobbering it, and to me that does make sense in this case. > > Can this setup not be passed via a well-designed DT binding then? I'm sure the information could be passed via DT but the Malta board currently doesn't use DT at all either in Linux or U-boot, and I don't have the time right now to convert them both to DT. > >> However the pcnet32 ethernet driver seems to be reliant upon the >> interrupt and doesn't handle the case of a PCI device with no assigned >> interrupt, so I'll send a patch to fail its probe in that case shortly. > > Thanks! > > Best regards, > Marek Vasut > Thanks, Paul
Dear Paul Burton, > On 11/11/13 13:33, Marek Vasut wrote: > > Dear Paul Burton, > > > >> On 10/11/13 20:09, Marek Vasut wrote: > >>> Dear Paul Burton, > >>> > >>>> Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will > >>>> be left disabled. Linux does not set up this routing but relies upon > >>>> it having been set up by the bootloader, reading back the IRQ lines > >>>> which the PIRQ[A:D] signals have been routed to. > >>> > >>> Did you also submit a fix to Linux guys? > >>> > >>> Best regards, > >>> Marek Vasut > >> > >> No, I haven't. Although Linux is reliant upon these values having been > >> programmed it's quite clear from reading its code that that depence is > >> intentional. It explicitely reads the route setup by the bootloader > >> rather than clobbering it, and to me that does make sense in this case. > > > > Can this setup not be passed via a well-designed DT binding then? > > I'm sure the information could be passed via DT but the Malta board > currently doesn't use DT at all either in Linux or U-boot, and I don't > have the time right now to convert them both to DT. That's unfortunate, but OK. Best regards, Marek Vasut
diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index d8ec57c..e141eb0 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h @@ -53,4 +53,9 @@ #define MALTA_REVISION_CORID_CORE_LV 1 #define MALTA_REVISION_CORID_CORE_FPGA6 14 +#define PCI_CFG_PIIX4_PIRQRCA 0x60 +#define PCI_CFG_PIIX4_PIRQRCB 0x61 +#define PCI_CFG_PIIX4_PIRQRCC 0x62 +#define PCI_CFG_PIIX4_PIRQRCD 0x63 + #endif /* _MIPS_ASM_MALTA_H */ diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c index 2f92259..a1a4c01 100644 --- a/board/imgtec/malta/malta.c +++ b/board/imgtec/malta/malta.c @@ -7,6 +7,7 @@ #include <common.h> #include <netdev.h> +#include <pci.h> #include <pci_gt64120.h> #include <pci_msc01.h> #include <rtc.h> @@ -169,6 +170,8 @@ struct serial_device *default_serial_console(void) void pci_init_board(void) { + pci_dev_t bdf; + switch (malta_sys_con()) { case SYSCON_GT64120: set_io_port_base(CKSEG1ADDR(MALTA_GT_PCIIO_BASE)); @@ -191,4 +194,15 @@ void pci_init_board(void) 0x00000000, MALTA_MSC01_PCIIO_SIZE); break; } + + bdf = pci_find_device(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82371AB_0, 0); + if (bdf == -1) + panic("Failed to find PIIX4 PCI bridge\n"); + + /* setup PCI interrupt routing */ + pci_write_config_byte(bdf, PCI_CFG_PIIX4_PIRQRCA, 10); + pci_write_config_byte(bdf, PCI_CFG_PIIX4_PIRQRCB, 10); + pci_write_config_byte(bdf, PCI_CFG_PIIX4_PIRQRCC, 11); + pci_write_config_byte(bdf, PCI_CFG_PIIX4_PIRQRCD, 11); }
Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will be left disabled. Linux does not set up this routing but relies upon it having been set up by the bootloader, reading back the IRQ lines which the PIRQ[A:D] signals have been routed to. This patch routes PIRQA & PIRQB to IRQ 10, and PIRQC & PIRQD to IRQ 11. This matches the setup used by YAMON. Signed-off-by: Paul Burton <paul.burton@imgtec.com> --- arch/mips/include/asm/malta.h | 5 +++++ board/imgtec/malta/malta.c | 14 ++++++++++++++ 2 files changed, 19 insertions(+)