WRITE_REGISTER_xxx to overlapped memory address

NTDEV
1

Hi all,

I’ve just started on the development of a windows driver to interface with my device thru PCI bus. I have questions regarding WRITE_REGISTER_xxx.

If I have the following consecutive of WRITE_REGISTER_xxx commands in my function, will the Value2 overwrite part of my first value, Value1?

WRITE_REGISTER_USHORT((PUSHORT) (pdx->portbase + 0), Value1);
WRITE_REGISTER_UCHAR((PUCHAR) (pdx->portbase + 1), Value2);

Thanks in advance.

Rgds,
ekoymis

2

Depends on your device logic. Your hardware is guaranteed to see 2 writes.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi all,
>
> I’ve just started on the development of a windows driver to interface with my
device thru PCI bus. I have questions regarding WRITE_REGISTER_xxx.
>
> If I have the following consecutive of WRITE_REGISTER_xxx commands in my
function, will the Value2 overwrite part of my first value, Value1?
>
> WRITE_REGISTER_USHORT((PUSHORT) (pdx->portbase + 0), Value1);
> WRITE_REGISTER_UCHAR((PUCHAR) (pdx->portbase + 1), Value2);
>
> Thanks in advance.
>
> Rgds,
> ekoymis
>

3

So, assuming (pdx->portbase) is 0x0010 and Value1 is 0xBF12. The first WRITE_REGISTER_USHORT will write 0x12 at address 0x0010 and 0xBF at address 0x0011.

Then my Value2 is 0x78. So, my second WRITE_REGISTER_UCHAR will overwrite the existing value,0xBF, at address 0x0011 with 0x78. Am i right with the scenario?

Btw, when a WRITE_REGISTER_xxx command is successfully executed, does this means the data is already transferred to target device? Does the WRITE_REGISTER_xx wait till the target device indicated the write transaction is completed then only it returned to the caller function?

Appreciate any advice you can provide.

4

> So, assuming (pdx->portbase) is 0x0010 and Value1 is 0xBF12. The first

WRITE_REGISTER_USHORT will write 0x12 at address 0x0010 and 0xBF at
address 0x0011.

No. You need WRITE_REGISTER_UCHAR for this.

Btw, when a WRITE_REGISTER_xxx command is successfully executed, does
this means the data is already transferred to target device? Does the
WRITE_REGISTER_xx wait till the target device indicated the write transaction
is
completed then only it returned to the caller function?

It imposes the memory barrier at least, so this CPU instruction will be surely
completely executed before return from WRITE_REGISTER_xx.

As about “write transaction is completed” - this depends on caching type of the
address range, which is governed by MmMapIoSpace parameter while mapping the
registers to virtual addresses.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

5

>> So, assuming (pdx->portbase) is 0x0010 and Value1 is 0xBF12. The first

>WRITE_REGISTER_USHORT will write 0x12 at address 0x0010 and 0xBF at
>address 0x0011.

No. You need WRITE_REGISTER_UCHAR for this.

Are you sure ? I think that the OP is right about value 0xBF at address 0x0011. The WRITE_REGISTER does not “stream” the bytes of
the USHORT to address 0x0010 . The WRITE_REGISTER_USHORT just translates at the end in a 2-byte “mov” assembly instruction. This
is a different behaveour from a WRITE_PORT_USHORT ( that transaltes into in / out assembly ) .

Christiaan

> Btw, when a WRITE_REGISTER_xxx command is successfully executed, does
>this means the data is already transferred to target device? Does the
>WRITE_REGISTER_xx wait till the target device indicated the write transaction
is
>completed then only it returned to the caller function?

It imposes the memory barrier at least, so this CPU instruction will be surely
completely executed before return from WRITE_REGISTER_xx.

As about “write transaction is completed” - this depends on caching type of the
address range, which is governed by MmMapIoSpace parameter while mapping the
registers to virtual addresses.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

> the USHORT to address 0x0010 . The WRITE_REGISTER_USHORT just

translates at the end in a 2-byte “mov” assembly instruction.

Correct, and this invokes a 16bit PCI transaction. To invoke 2 8bit
transactions, use 2 WRITE_REGISTER_UCHAR.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

7

xxxxx@yahoo.com wrote:

So, assuming (pdx->portbase) is 0x0010 and Value1 is 0xBF12. The first WRITE_REGISTER_USHORT will write 0x12 at address 0x0010 and 0xBF at address 0x0011.

Then my Value2 is 0x78. So, my second WRITE_REGISTER_UCHAR will overwrite the existing value,0xBF, at address 0x0011 with 0x78. Am i right with the scenario?

Again, it depends on your hardware. If that register address happens to
map to memory, then yes, that will happen. If that address happens to
be a register of some kind, then it is quite possible that your hardware
doesn’t allow byte addressing. In that case, it might be that neither
of these writes do anything at all, or it might be that the second write
overwrites the entire register. You have to ask the designers.

Btw, when a WRITE_REGISTER_xxx command is successfully executed, does this means the data is already transferred to target device? Does the WRITE_REGISTER_xx wait till the target device indicated the write transaction is completed then only it returned to the caller function?

This depends in part on the caching behavior you requested when you
mapped the memory. Normally, device addresses are mapped as uncached,
and in that case the CPU will not continue until the write has been
accepted by the device.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

>>>>>>
This depends in part on the caching behavior you requested when you
mapped the memory. Normally, device addresses are mapped as uncached,
and in that case the CPU will not continue until the write has been
accepted by the device.
<<<<<<
I’m not so sure about that. The actual write may take some time to get
through the PCI bridges.

Tim Roberts
Sent by: xxxxx@lists.osr.com
11/19/2007 01:12 PM
Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”
cc

Subject
Re: [ntdev] WRITE_REGISTER_xxx to overlapped memory address

xxxxx@yahoo.com wrote:
> So, assuming (pdx->portbase) is 0x0010 and Value1 is 0xBF12. The first
WRITE_REGISTER_USHORT will write 0x12 at address 0x0010 and 0xBF at
address 0x0011.
>
> Then my Value2 is 0x78. So, my second WRITE_REGISTER_UCHAR will
overwrite the existing value,0xBF, at address 0x0011 with 0x78. Am i right
with the scenario?
>

Again, it depends on your hardware. If that register address happens to
map to memory, then yes, that will happen. If that address happens to
be a register of some kind, then it is quite possible that your hardware
doesn’t allow byte addressing. In that case, it might be that neither
of these writes do anything at all, or it might be that the second write
overwrites the entire register. You have to ask the designers.

> Btw, when a WRITE_REGISTER_xxx command is successfully executed, does
this means the data is already transferred to target device? Does the
WRITE_REGISTER_xx wait till the target device indicated the write
transaction is completed then only it returned to the caller function?
>

This depends in part on the caching behavior you requested when you
mapped the memory. Normally, device addresses are mapped as uncached,
and in that case the CPU will not continue until the write has been
accepted by the device.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

Memory write order is guaranteed by the PCI spec, and the
WRITE_REGISTER_NNNN interfaces guarantee the device, not just the
bridge, have seen the write by adding in a locked OR of the target
location.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Monday, November 19, 2007 2:06 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WRITE_REGISTER_xxx to overlapped memory address

>>>>>
This depends in part on the caching behavior you requested when you
mapped the memory. Normally, device addresses are mapped as uncached,
and in that case the CPU will not continue until the write has been
accepted by the device.
<<<<<<
I’m not so sure about that. The actual write may take some time to
get through the PCI bridges.

Tim Roberts
Sent by: xxxxx@lists.osr.com

11/19/2007 01:12 PM

Please respond to
“Windows System Software Devs Interest List”

To

“Windows System Software Devs Interest List”

cc

Subject

Re: [ntdev] WRITE_REGISTER_xxx to overlapped memory address

xxxxx@yahoo.com wrote:
> So, assuming (pdx->portbase) is 0x0010 and Value1 is 0xBF12. The first
WRITE_REGISTER_USHORT will write 0x12 at address 0x0010 and 0xBF at
address 0x0011.
>
> Then my Value2 is 0x78. So, my second WRITE_REGISTER_UCHAR will
overwrite the existing value,0xBF, at address 0x0011 with 0x78. Am i
right with the scenario?
>

Again, it depends on your hardware. If that register address happens to
map to memory, then yes, that will happen. If that address happens to
be a register of some kind, then it is quite possible that your hardware
doesn’t allow byte addressing. In that case, it might be that neither
of these writes do anything at all, or it might be that the second write
overwrites the entire register. You have to ask the designers.

> Btw, when a WRITE_REGISTER_xxx command is successfully executed, does
this means the data is already transferred to target device? Does the
WRITE_REGISTER_xx wait till the target device indicated the write
transaction is completed then only it returned to the caller function?
>

This depends in part on the caching behavior you requested when you
mapped the memory. Normally, device addresses are mapped as uncached,
and in that case the CPU will not continue until the write has been
accepted by the device.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
and other seminars visit: http://www.osr.com/seminars To unsubscribe,
visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

10

Hi all,

Thanks for all those information. It really helps me a lot.
Now, I know that the WRITE_REGISTER_XXX function does guarantee that my device will see the write request before it return.
Furthermore, when I mapping the device memory using MmMapIoSpace , I will set it to uncached method.