> 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