> 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.
I'm not an IDE expert, but it seems to me that enabling the expansion ROM is
not going to make things any better since you don't use the expansion ROM
anywhere, but enabling it can make things worse: Most BIOSes unmap the ROMs
after using them and it's highly probable that some of them re-use the
corresponding addresses for other devices. For example, it's completely
legitimate to map all the ROMs to the same location since you don't need to
have all of them mapped at once.
> 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.
Yes, it could be enabled, but will then appear at address 0x00000000 which
is probably not sane at all and it's going to collide with other devices.
> Expansion ROM at 00000000
This is a typical example of expansion ROM address not assigned at all,
better say assigned during initialization of the card and unassigned later
by the BIOS.
> 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 */
Are there any cases where the IRQs are different? I didn't see the card
nor the chip specs, but it looks as an extremely kludgy hardware -- someone
was too lazy to implement the controller as a multi-function device and
he therefore decided to do this nasty config space split, making it impossible
to configure the devices in normal ways. Can you send me 'lspci -vvxx'
for this one?
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Disc space, the final frontier!"- 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