[PATCH 0/6] fbdevhw cleanup and pciaccess free

Vignatti Tiago (Nokia-D/Helsinki) tiago.vignatti at nokia.com
Mon May 31 08:06:02 PDT 2010


On Mon, May 31, 2010 at 05:04:37PM +0200, ext Mark Kettenis wrote:
> > Date: Mon, 31 May 2010 17:42:51 +0300
> > From: "Vignatti Tiago (Nokia-D/Helsinki)" <tiago.vignatti at nokia.com>
> > 
> > On Mon, May 31, 2010 at 04:29:11PM +0200, ext Mark Kettenis wrote:
> > > > From: Tiago Vignatti <tiago.vignatti at nokia.com>
> > > > 
> > > > [0] I'm wondering if it doesn't make sense for someone to free modules from
> > > > PCI code? For me it's pretty clear but I'll explain the machiavellian plan
> > > > anyway in the next series that I'll send today.
> > > 
> > > So instead you decide to pollute the generic PCI code with
> > > Linux-specific cra^H^H^Hcode?
> > 
> > can you please point exactly where I'm polluting generic PCI code with Linux
> > specific? I found your commentary pretty interesting because this is one of
> > the problems I'm trying to address with the cleaning up patches I've been
> > sending.
> 
> The bit below.

the reason for that is on the commit message. Or maybe I should be more clear?

 
> --- a/hw/xfree86/os-support/bus/Pci.c
> +++ b/hw/xfree86/os-support/bus/Pci.c
> @@ -134,6 +134,7 @@
>  #include "Pci.h"
>  
>  #include <pciaccess.h>
> +#include <fcntl.h>
>  
>  /* Global data */
>  
> @@ -155,3 +156,24 @@ xf86scanpci(void)
>  
>      return success;
>  }
> +
> +int
> +xf86PciOpenFbDev(struct pci_device *pPci, int num)
> +{
> +    char filename[256];
> +    int fd;
> +
> +    sprintf(filename,
> +        "/sys/bus/pci/devices/%04x:%02x:%02x.%d/graphics/fb%d",
> +        pPci->domain, pPci->bus, pPci->dev, pPci->func, num);
> +
> +    fd = open(filename, O_RDONLY, 0);
> +    if (fd < 0) {
> +        sprintf(filename,
> +            "/sys/bus/pci/devices/%04x:%02x:%02x.%d/graphics:fb%d",
> +            pPci->domain, pPci->bus, pPci->dev, pPci->func, num);
> +        fd = open(filename, O_RDONLY, 0);
> +    }
> +
> +    return fd;
> +}
             Tiago


More information about the xorg-devel mailing list