On Fri, 06 Jun 2008 18:27:41 -0500 James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2008-06-06 at 22:35 +0200, Krzysztof Helt wrote: > > What is you advise for this patch James? > > The more I look at this the more I doubt that it's a good thing. STI is > really a platform driver; it has to function for both GSC and PCI > busses. pci_map_rom() seems to be a bit of a minefield designed for x86 > centric video cards, which STI definitely isn't. The sticore driver is > also designed to operate on unmapped ranges ... at least this is the way > it's designed for the GSC, so the PCI part has to follow suit. > > Our simple base get and enabling transparently the driver currently has > says what we're doing; I don't really see why it needs to switch to > pci_map_rom. Additionally, I fear that switching to pci_map_rom will > cause us to break later on down the road. > I am forwarding it to the reporter of the bug 9425 as this bug should be closed without changing the code. A very similar case is for the bug 9424. I analyzed code for the Matrox framebuffers and it is not worth changing. The idea behind the pci_map_rom() is that it enables and maps the ROM area. The Matrox framebuffer has these two separated as the ROM may appear in the already mapped area. The ROM is always enabled but not always mapped. The only unification I see is to export pci_rom_enable/pci_rom_disable() and use them inside the Matrox and sticore drivers (so no ioremap() is done but the code is shorter). Regards, Krzysztof ---------------------------------------------------------------------- Tanie rozmowy! Sprawdz >>> http://link.interia.pl/f1e22 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
