Messages in this thread | | | Date | Mon, 24 Aug 1998 11:50:59 -0500 (CDT) | From | "Andre M. Hedrick" <> | Subject | Re: IDE-Driver Update :: Testing Requested |
| |
On Sun, 23 Aug 1998, Martin Mares wrote:
> Hello, > > > +/* > > + * This allows offboard ide-pci cards the enable a BIOS, verify interrupt > > Is there any reason for enabling the expansion ROM? I don't see the > addressbios variable being access anywhere else. Anyway, if the expansion ROM
I made the assumption that if the onboard bios configures the chipset for transfer rates. Since the card reports that the BIOS is reported and enabled, it seems reasonable to stroke/set bios on/enable bit.
> has been enabled by the BIOS, its address is already present in
I agree that I have yet to find a case anywhere in the kernel code that does this in plain site, and it may not be done at all. However under DOS and Win95 (using MicroSoft's PCI probe tool), I have seen this enabled. Yes, this is a very weak case to base the need for this action, but I have had no errors.
As a test case, I will make a mirror of my system on another drive and boot without this bit being set. However, in the beginning of playing and testing these two cards in question, enabling this bit was not done by default. I wish I could find my notes on why I determined the need for such an action. Trust that this was done for a valid reason/need.
> dev->rom_address. If it hasn't been, you can't rely on a valid address assigned > to it.
I questioned this assuption of my in the beginning, but with imperical tests on two machines (one that reports the bios and another that doesn't) using the same model and revision of the pci-card, I did determine that it could be enabled even if it reported w/ and address location of 0x00000000.
lspci -bvvs 00:14.0 00:14.0 SCSI storage controller: Artop Electronic Corp ATP850UF (rev 01) Subsystem: Unknown device 1191:0005 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 254 set Interrupt: pin A routed to IRQ 15 Region 0: I/O ports at 6300 Region 1: I/O ports at 6400 Region 2: I/O ports at 6500 Region 3: I/O ports at 6600 Region 4: I/O ports at 6700 Expansion ROM at 00000000
cat /proc/ioports 6300-6307 : ide0 6402-6402 : ide0 6500-6507 : ide1 6602-6602 : ide1 6700-6707 : ide0 6708-670f : ide1
> > + pci_write_config_byte(dev, 0x30, 0x01); > > + pci_read_config_byte(dev, 0x3c, &irq1);
Note that the PDC20246 has a mirrored pci-config space. Since I believe that 0x3c is the interrupt-pci-config space for the first hwif (ide1 on the card) with chip PDC20247, and that 0xbc is the interrupt-pci-config space for the second hwif (ide2 on the card) with chip PDC20246,
> Please use the PCI_* macros in <linux/pci.h> for accessing standard > configuration registers. Also, use of PCI_BASE_ADDRESS_{MEM,IO}_MASK instead > of explicit masks is welcome.
I will make these change requests. I did this in the beginning when IO-APIC interrupts appeared around 2.1.85 (I think this is right). I needed to work around SMP level/edge that was not handled correctly by the driver until 2.1.94/5/6.
I know that the first line is acceptable, but the second is fuzzy, right?
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq1); pci_read_config_byte(dev, (PCI_INTERRUPT_LINE)|0x80, &irq2); /* 0xbc */
Cheers, Andre
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |