All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Lidel <Markus.Lidel@shadowconnect.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: best practise for ioremap / ioremap_nocache / MTRR
Date: Fri, 06 May 2005 18:39:55 +0200	[thread overview]
Message-ID: <427B9DDB.7030307@shadowconnect.com> (raw)

Hello,

first of all some background information to the hardware itself.

In my special case (the I2O driver see also drivers/message/i2o/* for 
further information) the hardware uses a memory mapped I/O region of 
around 128kb. This memory region contains 3 control ports which IMHO 
don't make send to be cached.

The remaining memory is divided into 512 byte sized message frames. The 
driver have to request one of the 512 byte message frames by reading on 
one of the control ports, and gets back an address of the message frame 
which he could use to write data into it. After finishing the address of 
the message frame must be written back to the control register.

At the moment the driver writes each 32-bit word directly into the I/O 
memory region.


My questions now are:

1) does the ioremap() have any advantage over ioremap_nocache() in this 
case, because the memory is only written once, and not read by the driver 
again?

2) does it make sense to prepare the message in kernel using a mempool, 
and then copy over to the I/O memory at once using memcpy_toio instead of 
writing each 32-bit word directly to the I/O memory?

3) at the moment MTRR is used for the messages (but not for the control 
registers), does this have an advantage because each 32-bit word is 
written separately? Or is it better to not use MTRR, and use the approach 
described in 2)?

Any advice would be appreciated! Thank you very much in advance!



Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

                 reply	other threads:[~2005-05-06 16:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=427B9DDB.7030307@shadowconnect.com \
    --to=markus.lidel@shadowconnect.com \
    --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.