lkml.org 
[lkml]   [2003]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Fri, Oct 24, 2003 at 09:44:38AM -0700, Linus Torvalds wrote:
>
> On Thu, 23 Oct 2003, Jeff Garzik wrote:
>
> > /* Assign space for ROM resource if not already assigned. Ugly. */
> > if (!pci_resource_start(dev, PCI_ROM_RESOURCE))
> > if (pci_assign_resource(dev, PCI_ROM_RESOURCE) < 0)
> > return -ENOMEM;
> >
> > /* Enable it. This is too ugly */
> > if (!(pci_resource_flags(dev, PCI_ROM_RESOURCE) & PCI_ROM_ADDRESS_ENABLE)) {
> > u32 val;
> > pci_read_config_dword(dev, PCI_ROM_ADDRESS, &val);
> > val |= PCI_ROM_ADDRESS_ENABLE;
> > pci_write_config_dword(dev, PCI_ROM_ADDRESS, val);
> > pci_resource_flags(dev, PCI_ROM_RESOURCE) |= PCI_ROM_ADDRESS_ENABLE;
> > }
>
> over and over again _is_ going to cause us problems later. Either we'll
> change some interface slightly (and have to fix up the drivers), or a

We need something more sophisticated. Matrox's hardware has bits
31-16 readable/writable only if bit 0 is set to 1 (ROM enabled; you can
(obviously) set bits 31-16 & 0 in one write). When ROM is disabled,
bits 31-1 are always read as 0.

> So wouldn't it be nice if we just had those ten lines as a generic
> function like
>
> int pci_enable_rom(struct pci_device *dev)
> {
> ...
>
> int pci_disable_rom(..);

It would be nice if it works... For matrox hardware I have to map ROM
over framebuffer (it is solution recommended by datasheet), as there is
no way to get memory range allocated for ROM unless ROM was left enabled
all the time.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.939 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site