[UPDATE] 2.4.10-pre2 PCI64, API changes README

[UPDATE] 2.4.10-pre2 PCI64, API changes README

[David S. Miller]

Ok, new patch up on kernel.org against 2.4.10-pre2:

ftp.kernel.org:/pub/linux/kernel/davem/PCI64/pci64-2.4.10p2-1.patch.gz

The major change in this release is that the API has been redone.
After considering feedback on this list, and in particular feedback
from David Mosberger in private emails, I redid things to match the
simplifications suggested without losing sight of the goals I had.

Basically, what has changed is that nothing changes :-)  There are no
longer pci64_foo() interfaces, a normal drivers use dma_addr_t and
pci_foo() for 32-bit and 64-bit drivers.

If you have a "weird device" which requires a large DMA address space,
the solution is provided in a set of pci_dac_*() interfaces.  These
are like "virt_to_bus()" for PCI DAC but with cache coherency,
HIGHMEM, and other portability issues kept in mind.

I could just regurgitate the DMA-mapping.txt changes, but I think it's
better for folks to just go look at what is written there.

Also, I integrated the Alpha bits from Richard.  He wrote his stuff
against the old API, so I had to whack it into the new stuff.  So if
there are any build problems or bugs, they are mine and mine alone.

If you look at the driver changes now, they are more about
initialization changes and using dma_addr_t more consistently.
But that's about it.

Jens should be making a nobounce patch relative to this some time
soon.

Enjoy, and please send feedback and success/failure reports.  Thanks.

Later,
David S. Miller
davem@redhat.com

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[Gerd Knorr]

David S. Miller wrote:
>  
>  Ok, new patch up on kernel.org against 2.4.10-pre2:
>  
>  ftp.kernel.org:/pub/linux/kernel/davem/PCI64/pci64-2.4.10p2-1.patch.gz
>  
>  The major change in this release is that the API has been redone.

A maybe related issue:

My current bttv does zerocopy capture if you ask it for a video frame
using read():  locks memory with kiobufs, builds a scatterlist for the
locked pages, asks for bus addresses using pci_map_sg, then kick DMA.

These days I tried what happens if I start a PCI->PCI transfer this way:
Open the framebuffer device, mmap the framebuffer memory, then ask bttv
to blit one video frame to the framebuffer by passing the pointer of the
fb mapping to bttv's read() function.

Didn't work, looks like map_user_buf can deal with main memory only, but
not with I/O memory.  It gave me NULL pointers in the iobuf page list.

Is there any way (portable) way to deal with this situation?  I'd expect
I can get the physical address for the I/O memory by walking the page
tables, but then I'd have to translate that to a bus address somehow.
How PCI->PCI transfers are handled on architectures with a iommu?  Do I
need a iommu entry for them?

  Gerd

-- 
Damn lot people confuse usability and eye-candy.

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[David S. Miller]

   From: Gerd Knorr <kraxel@bytesex.org>
   Date: 30 Aug 2001 12:34:11 GMT

   These days I tried what happens if I start a PCI->PCI transfer this way:
   Open the framebuffer device, mmap the framebuffer memory, then ask bttv
   to blit one video frame to the framebuffer by passing the pointer of the
   fb mapping to bttv's read() function.
   
   Didn't work, looks like map_user_buf can deal with main memory only, but
   not with I/O memory.  It gave me NULL pointers in the iobuf page list.

Right.
   
   Is there any way (portable) way to deal with this situation?  I'd expect
   I can get the physical address for the I/O memory by walking the page
   tables, but then I'd have to translate that to a bus address somehow.
   How PCI->PCI transfers are handled on architectures with a iommu?  Do I
   need a iommu entry for them?

Not currently.  Note that just using that physical address you'd find
in the page tables might not even work on many platforms.  And
anyways, the DMA-mapping.txt document is pretty clear that of what
types of memory can be passed in to get DMA mappings for.

You _REALLY_ need to know the PCI device in question before you can
properly and portably set up a PCI peer to peer transfer.  We have no
API for this yet though.

When such an API would be created, it would take two PCI_DEV structs,
and it would possibly fail.  On sparc64 for example, it is not
possible to PCI peer-to-peer DMA between two PCI devices behind
different PCI controllers, it simply doesn't work.

Later,
David S. Miller
davem@redhat.com

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[Alan Cox]

> When such an API would be created, it would take two PCI_DEV structs,
> and it would possibly fail.  On sparc64 for example, it is not
> possible to PCI peer-to-peer DMA between two PCI devices behind
> different PCI controllers, it simply doesn't work.

Thats an API video overlay really really needs of course - because DMA from
the capture card into the video memory is precisely how its done.

Alan

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Fri, 31 Aug 2001 00:14:22 +0100 (BST)
   
   Thats an API video overlay really really needs of course - because DMA from
   the capture card into the video memory is precisely how its done.

Ok, then it is important to figure out if there is going to be a
suitable way to get at the two pci_dev's.

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.

Later,
David S. Miller
davem@redhat.com

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[Alan Cox]

> 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

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[David S. Miller]

   From: Alan Cox <alan@lxorguk.ukuu.org.uk>
   Date: Fri, 31 Aug 2001 00:30:34 +0100 (BST)

   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

We could do something interesting with /proc/bus/pci/bus/devfn nodes
I suspect.

You open the target fb pci dev, and part of the argument to the video
ioctl is:

	int pci_dev_fd;
	int resource_num;
	u64 offset;
	u64 len;

Something like that.

Later,
David S. Miller
davem@redhat.com

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[Gerd Knorr]

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;
}

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[David S. Miller]

   From: Gerd Knorr <kraxel@bytesex.org>
   Date: 31 Aug 2001 07:22:11 GMT
   
   What addresses are in dev->resource?  Physical?  Bus address?  Are they
   unique?

They are implementation dependent values, they may be anything and
cannot be interpreted generically.

You must make portable interfaces for these kinds of things.

Later,
David S. Miller
davem@redhat.com

Re: [UPDATE] 2.4.10-pre2 PCI64, API changes README

[Alan Cox]

> What addresses are in dev->resource?  Physical?  Bus address?  Are they
> unique?

Basically its an arbitary cookie suitable only for passing to ioremap. In
practice its likely to be a bus address but not always since it may be a
combined ident (controller id<<lots|offset) or even a pointer to a struct
private to the platform

Currently I think everyone mainstrem except the pa-risc has either a bus
address or physical address in the registers. For pa the I/O port map used
to be (and might still be) a controller/offset pair.

Alan