All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: kraxel@bytesex.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] zero-bounce highmem I/O
Date: Thu, 16 Aug 2001 07:15:19 -0700 (PDT)	[thread overview]
Message-ID: <20010816.071519.66059870.davem@redhat.com> (raw)
In-Reply-To: <20010816153541.A9265@bytesex.org>
In-Reply-To: <20010816.053415.10296707.davem@redhat.com> <20010816153541.A9265@bytesex.org>

   From: Gerd Knorr <kraxel@bytesex.org>
   Date: Thu, 16 Aug 2001 15:35:41 +0200

   > To be honest, you really shouldn't care about this.  If you are
   > writing a block device, the block/scsi/ide/whatever layer should take
   > care to only give you memory that can be DMA'd to/from.
   > 
   > Same goes for the networking layer.
   
   bttv is neither blkdev nor networking ...
   
It is video layer, and the video layer should be helping along with
these sorts of issues.

The video layer should provide PCI device helpers which allow the
drivers to just do something like:

struct scatterlist *video_pci_get_user_pages(struct pci_dev *pdev,
					     int npages);

void video_pci_put_user_pages(struct pci_dev *pdev,
			      struct scatterlist *sg,
			      int npages);

The scatter list returned (NULL indicates failure, ala -ENOMEM)
will tell the driver everything it needs to know.  Let us define
it as follows:

SG entry 0
	address == base of vmalloc()'d area

SG entry 0 ... NPAGES
	sg_dma_address(sg) = dma_address for that page
	sg_dma_len(sg) = dma_length, usually PAGE_SIZE

sg_dma_len could be something larger than PAGE_SIZE if the
platform has a way of using virtual mappings in PCI space.
You would simply give the device DMA address/len pairs from
the SG array until you either hit the NPAGES entry or you
see a dma_len of zero.

I realize this does not address the kiovec based scheme you
are experimenting with now, but this does deal with the biggest
problem the video layer has right now wrt. portability.

In fact, this isn't even a video layer issue, and the kernel
ought to provide my suggested interfaces in some generic
place.

Later,
David S. Miller
davem@redhat.com

  reply	other threads:[~2001-08-16 14:15 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-15  7:50 [patch] zero-bounce highmem I/O Jens Axboe
2001-08-15  9:11 ` David S. Miller
2001-08-15  9:17   ` Jens Axboe
2001-08-15  9:26   ` Jens Axboe
2001-08-15 10:22     ` David S. Miller
2001-08-15 11:13       ` Jens Axboe
2001-08-15 11:47         ` David S. Miller
2001-08-15 12:07           ` Jens Axboe
2001-08-15 12:35             ` David S. Miller
2001-08-15 13:10               ` Jens Axboe
2001-08-15 14:02                 ` David S. Miller
2001-08-15 14:25                   ` David S. Miller
2001-08-16 11:51                     ` Jens Axboe
2001-08-16 11:56                       ` David S. Miller
2001-08-16 12:03                         ` Jens Axboe
2001-08-16 12:27                           ` David S. Miller
2001-08-16 12:48                             ` Jens Axboe
2001-08-16 12:56                             ` Jens Axboe
2001-08-16 13:08                               ` David S. Miller
2001-08-16 12:14                         ` Gerd Knorr
2001-08-16 12:34                           ` David S. Miller
2001-08-16 13:35                             ` Gerd Knorr
2001-08-16 14:15                               ` David S. Miller [this message]
2001-08-16 12:28                       ` kill alt_address (Re: [patch] zero-bounce highmem I/O) David S. Miller
2001-08-16  5:52                   ` [patch] zero-bounce highmem I/O Jens Axboe
2001-08-15 19:20       ` Gérard Roudier
2001-08-16  8:12         ` David S. Miller
     [not found] <no.id>
2001-08-16 14:56 ` Alan Cox
2001-08-17 10:18   ` Gerd Knorr

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=20010816.071519.66059870.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=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.