All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Vadivelan Mani <daff_vadi@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: pci_alloc_consistent() usage
Date: Tue, 13 Jul 2004 21:29:23 +0200	[thread overview]
Message-ID: <20040713192923.GA17250@linux-mips.org> (raw)
In-Reply-To: <BAY15-F223KfTpfpYea00005ca9@hotmail.com>

On Tue, Jul 13, 2004 at 06:31:01PM +0530, Vadivelan Mani wrote:

>   I'm writing a wireless driver which requires 8 transmit and 8 receive 
> buffers each of size 3KB approx.

I hope this device isn't really as simplistic as you make it sound ...

> These buffers should be in dma capable space.
> 
> I've allocated them using pci_alloc_consistent().
> 
> I've allocated 128KBytes just to make more space. I've got few doubts.
> 
>   1. Can pci_alloc_consistent() be used to allocate memory upto 128KBytes?

Yes.  For MIPS MAX_ORDER defaults to 11 so you even do alloc_page (which
is the underlying allocator of pci_alloc_consistent) upto 2^11 page that
is 8MB.  Downside - memory allocation is making such large allocations
unreliable; the more unreliable the larger the allocation.  In general
try to stick to allocations of order 0 that is PAGE_SIZE which atm is
4k on MIPS.  They're ok for permanent allocations such as rx/tx rings
which only happen rarely.

> 2.)   I would also like to know the exact use of this allocated space to 
> transmit or receive a packet.

pci_alloc_consistent() is meant to be used for permanent allocations
such as rx/tx rings.  It's not suitable for allocating skbufs; there are
other mechanisms available for that.

> During transmission i do the following. Plz correct me if i'm wrong because 
> i'm new to driver writing.
> 
> The device has a register which should be loaded with the transmit buffers 
> starting address.
> 
> I copy the packet coming from the Kernel in the form of sk_buff structure 
> into one of the transmit buffers that i've allocated using memcpy().

That's usually an idea only for very small packets.  pci_alloc_consistent
allocates uncached memory on a system withour hardware coherency so this
copy operation would be very slow.  In any case you should experiment to
find the breakeven point.

For larger packets you should use pci_map_single() in the start_xmit()
method of the driver, then pci_unmap_single() later when cleaning that is
typically in an interrupt handler.  Reception of packets would work
fairly similar.

> And i set the register in the device to initiate transmission of the packet.
> 
> Where does the dma transfer concept come in this?
> There is no mention of the direction of data transfer in 
> pci_alloc_consistent().

pci_alloc_consistent will allocate consistent memory that is it's suitable
for transfers in both directions.  On the typical MIPS processor which
doesn't maintain coherency in hardware this means it will return
uncached memory.  Obviously that will work for any direction of transfer.
But: uncached memory is slow - so avoid copying packets there.

> I also assumed that allocating buffer in dma capable space was itself 
> enough to start dma transfers.

No.  DMA capable space means some memory that can be accessed somehow by
a DMA engine.  You still have to tell the device to start the operation.

> Since i do not have the device now i'm not able to test the code. But i 
> would like to write the code before i get the device.

  Ralf

  reply	other threads:[~2004-07-13 19:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-13 13:01 pci_alloc_consistent() usage Vadivelan Mani
2004-07-13 19:29 ` Ralf Baechle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-23 21:59 pci_alloc_consistent usage Wayne Gowcher
2003-05-27  9:17 ` Ralf Baechle
2003-05-27 10:07   ` Atsushi Nemoto
2003-05-27 10:53     ` Christoph Hellwig
2003-05-27 11:22       ` Ralf Baechle
2003-05-27 11:33         ` Christoph Hellwig
2003-05-27 11:45           ` Ralf Baechle
2003-05-28  1:30         ` Atsushi Nemoto

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=20040713192923.GA17250@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=daff_vadi@hotmail.com \
    --cc=linux-mips@linux-mips.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.