linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kanoj Sarcar <kanoj@google.engr.sgi.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Roman Zippel <roman@augan.com>,
	linux-mm@kvack.org, linux-kernel@vger.rutgers.edu,
	rmk@arm.linux.org.uk, nico@cam.org, davem@redhat.com,
	davidm@hpl.hp.com, alan@lxorguk.ukuu.org.uk
Subject: Re: pte_pagenr/MAP_NR deleted in pre6
Date: Wed, 16 Aug 2000 11:47:49 -0700 (PDT)	[thread overview]
Message-ID: <200008161847.LAA84163@google.engr.sgi.com> (raw)
In-Reply-To: <20000816192012.K19260@redhat.com> from "Stephen C. Tweedie" at Aug 16, 2000 07:20:12 PM

> 
> Hi,
> 
> On Wed, Aug 16, 2000 at 10:13:21AM -0700, Kanoj Sarcar wrote:
> > 
> > FWIW, Linus was mildly suggesting I implement page_to_phys, to complement
> > virt_to_page.
> 
> It's part of what is necessary if we want to push kiobufs into the
> driver layers.  page_to_pfn is needed to for PAE36 support so that
> PCI64 or dual-address-cycle drivers can handle physical addresses
> longer than 32 bits long.
> 
> > BTW, I am not sure I understand when you say "some drivers need a virtual 
> > address, some need the physical address for dma and some of them might need
> > bounce buffers". I believe, the goal should be to pass in either a. struct
> > page or b. physical address
> 
> Yes, but different drivers have different requirements on those struct
> page *s.  Drivers which do programmed IO need to be able to turn the
> page into a kernel virtual address.  Drivers which can access >32-bit
> addresses need to turn the page into an index which fits inside 32
> bits.  Drivers which do DMA but only to <4GB addresses need bounce
> buffers.
> 
> That is irrelevant as far as the kiobuf data structure is concerned,
> but it is very important for the internals of the drivers, so this
> sort of functionality must be made available for drivers to use
> internally as needed.
> 
> Cheers, 
>  Stephen
> 

It might be easier all around if we could all agree to what drivers
need to do. As David Miller points out, whether a driver can dma into
>32-bit addresses etc is also a function of the architecture, so this
is best hidden under per architecture PCI-DMA layer. So, if the driver 
writer codes according to this, he will transparently get the best 
performance for any architecure ...

I guess finally, drivers will either get one or a list of

1. struct page or
2. pfn or
3. paddr_t (unsigned long long on PAE36, unsigned long on other platforms)

The PCI-DMA layer should be able to handle this type of input. The driver
must not attempt to convert this to PCI bus addresses. The driver must call
an arcitecture hook, like kmap(), to get a kernel virtual address for
the underlying page. It should be able to do without needing the physical
address of the page, the PCI-DMA routines will know how to do that.

kiobufs might need to get some hooks into PCI-DMA, but shouldn't this
suffice, mostly? Or is this being too restrictive for some drivers?

Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  parent reply	other threads:[~2000-08-16 18:47 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-10 17:18 Kanoj Sarcar
2000-08-11  2:24 ` David S. Miller
2000-08-14  0:34   ` Anton Blanchard
2000-08-11 11:50 ` Roman Zippel
2000-08-11 13:20   ` Russell King
2000-08-11 14:56     ` Roman Zippel
2000-08-12  9:18       ` Bjorn Wesen
2000-08-11 17:21     ` Kanoj Sarcar
2000-08-14  9:29       ` Roman Zippel
2000-08-15 16:19 ` Stephen C. Tweedie
2000-08-16  8:25   ` Roman Zippel
2000-08-16 17:13     ` Kanoj Sarcar
2000-08-16 18:20       ` Stephen C. Tweedie
2000-08-16 18:24         ` David S. Miller
2000-08-16 19:53           ` Stephen C. Tweedie
2000-08-16 18:47         ` Kanoj Sarcar [this message]
2000-08-16 18:39           ` David S. Miller
2000-08-16 19:30             ` Stephen C. Tweedie
2000-08-16 22:22         ` Kanoj Sarcar
2000-08-17  9:11           ` Stephen C. Tweedie
2000-08-17 19:07             ` Kanoj Sarcar
2000-08-17 19:01               ` David S. Miller
2000-08-17 19:19                 ` Alan Cox
2000-08-17 19:20                   ` David S. Miller
2000-08-17 19:33                     ` Alan Cox
2000-08-17 19:36                     ` Kanoj Sarcar
2000-09-07 14:31                       ` Ralf Baechle
2000-08-17 19:50                     ` Kanoj Sarcar
2000-08-17 19:41                       ` David S. Miller
2000-09-07 14:26                         ` Ralf Baechle
2000-08-17 19:56                       ` Alan Cox
2000-08-17 19:24                   ` Alan Cox
2000-08-17 19:32                 ` Kanoj Sarcar
2000-08-17 19:30                   ` David S. Miller
2000-08-17 20:00                     ` Kanoj Sarcar
2000-08-16 18:17     ` Stephen C. Tweedie

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=200008161847.LAA84163@google.engr.sgi.com \
    --to=kanoj@google.engr.sgi.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=nico@cam.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=roman@augan.com \
    --cc=sct@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox