From: Gerd Knorr <kraxel@bytesex.org>
To: linux-kernel@vger.kernel.org
Subject: Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README
Date: 31 Aug 2001 07:22:11 GMT [thread overview]
Message-ID: <slrn9ouep3.4d6.kraxel@bytesex.org> (raw)
In-Reply-To: <20010830.161453.130817352.davem@redhat.com> from "David S. Miller" at Aug 30, 2001 04:14:53 PM <E15cbGc-00027M-00@the-village.bc.nu>
Alan Cox wrote:
> > If mmap()'ing the frame buffer and passing this into read() is how
> > this will be done, it simply won't work. That's the point I'm trying
> > to make.
>
> That isnt done anyway - the card executes a risc instruction set for the
> DMA engine specifying which to skip and draw. So you feed it a base
> physical address for the fb via ioctl (yes this needs to be a pci device
> bar and offset I suspect) and then tell it about the fb layout and the like
current bttv tries to find a PCI device for the given physical address by
walking all PCI devices, then check whenever the address falls into one of the
dev->resource memory ranges. Works fine on i386, but I'm not sure whenever
this works on other platforms, where phys == bus isn't true.
Right now it only sanity-checks the given physical address this way (see
below), but of course I could also pass the found pci_dev to some pci->pci
API.
What addresses are in dev->resource? Physical? Bus address? Are they
unique?
Gerd
---------------------------- cut here -------------------------
static int
find_videomem(unsigned long from, unsigned long to)
{
struct pci_dev *dev = NULL;
int i,match,found;
found = 0;
dprintk(KERN_DEBUG "bttv: checking video framebuffer address"
" (%lx-%lx)\n",from,to);
pci_for_each_dev(dev) {
if (dev->class != PCI_CLASS_NOT_DEFINED_VGA &&
dev->class >> 16 != PCI_BASE_CLASS_DISPLAY)
continue;
dprintk(KERN_DEBUG
" pci display adapter %04x:%04x at %02x:%02x.%x\n",
dev->vendor,dev->device,dev->bus->number,
PCI_SLOT(dev->devfn),PCI_FUNC(dev->devfn));
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
if (!(dev->resource[i].flags & IORESOURCE_MEM))
continue;
if (dev->resource[i].flags & IORESOURCE_READONLY)
continue;
match = (from >= dev->resource[i].start) &&
(to-1 <= dev->resource[i].end);
if (match)
found = 1;
dprintk(KERN_DEBUG " memory at %08lx-%08lx%s\n",
dev->resource[i].start,
dev->resource[i].end,
match ? " (check passed)" : "");
}
}
return found;
}
next prev parent reply other threads:[~2001-08-31 8:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-30 1:18 [UPDATE] 2.4.10-pre2 PCI64, API changes README David S. Miller
2001-08-30 12:34 ` Gerd Knorr
2001-08-30 23:06 ` David S. Miller
2001-08-30 23:14 ` Alan Cox
2001-08-30 23:14 ` David S. Miller
2001-08-30 23:30 ` Alan Cox
2001-08-30 23:31 ` David S. Miller
2001-08-31 7:22 ` Gerd Knorr [this message]
2001-08-31 8:58 ` David S. Miller
2001-08-31 14:12 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=slrn9ouep3.4d6.kraxel@bytesex.org \
--to=kraxel@bytesex.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.