best practise for ioremap / ioremap_nocache / MTRR

From: Markus Lidel
Date: Fri May 06 2005 - 11:37:29 EST


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@xxxxxxxxxxxxxxxxx
URL: http://www.shadowconnect.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/