About READ_PORT_UCHAR and READ_PORT_ULONG

Dear all,
I am coding a driver that should access IO port. I have some question on
IO port access,
anyone can help me?
1: Can READ_PORT_ULONG read from non DWORD aligned boundary? If we can, is
the value right?
2: If use READ_PORT_UCHAR four times and combined the four BYTEs into a
DWORD value, and then
I use READ_PORT_ULONG at the same address, are these two values same?
Thanks.
BR
Volition2k

> 1: Can READ_PORT_ULONG read from non DWORD aligned boundary? If we can, is

the value right?
2: If use READ_PORT_UCHAR four times and combined the four BYTEs into a
DWORD value, and then
I use READ_PORT_ULONG at the same address, are these two values same?
Thanks.

I’ll give the famous driver writer’s answer, it depends.

At least some I/O buses (like PCI) can’t do a 32-bit transfer on an
unaligned address. Such a transfer will get broken into multiple transfer
cycles with appropriate byte enables set. The DWORD transfer may still
happen in a single burst (with multiple data phases).

There is no guarantee that four READ_PORT_UCHAR will happen on back to back
bus cycles. You might get the first one, and then a big bus master
transfer, and then the following three, all in different bursts You’de have
to look at the bus spec to decided if an unaligned DWORD request is
guaranteed to be executed in a single burst. My guess is, it’s
implementation (chipset) dependent. An aligned read DWORD read may or may
not be guaranteed to be a single burst. Again, I’d have to look at the bus
spec to decide who controls the byte enables, the master or target or both.

One difference between a single DWORD read and 4 BYTE reads is the timing
and how the signals influence the hardware. For example, on a PCI bus, if
you do a single DWORD reads, the hardware may be designed to change state
when an address is read. Four byte reads will address the same address four
times, but with different byte enables set, so may interact with the
hardware different that a single DWORD read.

I think the point I’m trying to make here is to REALLY determine what
happens at a bus level when you execute a variety of processor
instructions, you need a bus analyzer. And even then, behavior may vary
based in things like chipset. The device hardware specs will often say what
size of transfers are required, and any alignment requirements.

Seems like I remember some hardware that would act badly (as in lockup the
bus) if you didn’t do transfers on DWORD size and aligned on a DWORD. Part
of the issue was generation of correct PCI bus parity.

Transfer alignment can also have a huge impact on performance. For example,
I worked on one PCI bus master network device that was unable to
efficiently rotate the data between it’s internal buffers, and the buffers
in main memory. This was really ugly, as some of the network headers were
not exactly nice even sizes. The goal was to look at the packet header, and
then arrange for the bus master transfer of the data body into some
buffers. Unfortunately, the alignment of these buffers did not match the
alignment of the data internally in the network card. The end result was a
LOT more bus cycles were required to transfer the data than expected (like
4 bytes transfers, which made a PCI bus only do 33 MBytes/sec).

  • Jan