When the minidriver receive data packet (by
StrMiniReceiveStreamDataPacket),
it will translate the address pSrb->CommandData.DataBufferArray->Data
to physical address to do hardware PCI video data DMA.
after DMA, it tirgger interrupt then DPC.
In the DPC, it will write some tags to the start of address pSrb-
>CommandData.DataBufferArray->Data
The error is I can't find the tags in the application (the application
is still 32bit ) call back function
although DMA is successful.
I can get clear video but I can't find the tag.
Is it because the data not flushed to the physical memory or other
system issue?
Does your DMA hardware actually handle 64-bit physical addresses? Lots of
older hardware did not.
>In the DPC, it will write some tags to the start of address pSrb-
>>CommandData.DataBufferArray->Data
>The error is I can't find the tags in the application (the application
>is still 32bit ) call back function
>although DMA is successful.
>I can get clear video but I can't find the tag.
>Is it because the data not flushed to the physical memory or other
>system issue?
As long as you aren't casting the pointer to a ULONG, this shouldn't be a
problem. Have you checked that the Data pointer is the same before and
after?
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
1. I am not casting the pointer, I use virtual 64-bit address to write
tag.
2. Actually the DMA hardware only support 32-bit physical addresses,
but the physical address tranlated from 64-bit virtual address
never above 32-bit.
I directly use the lower 32-bit physical address to do hardware
DMA and it works
under windows xp 64-bit with 8GB ram.
Thanks for your response.
yo...@nuuo.com
Use Windows DMA APIs properly to do this, do not handicraft such a code.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
But the chip (BT878) use hardware DMA,
so the driver use StreamClassGetPhysicalAddress() function to traslate
to physical address (never above 32-bit)
tell this address to BT878, BT878 will do DMA by itself (hardware)
I think I can't use Windows DMA APIs in this situation,
but I'm not sure, could you describe how to use Windows DMA APIs in
this situation more detail?
By the way, Is the phenomenon that I can't find the tags in the
application related to cache flushing?
(I think data is not flushing to physical memory, so can't be read in
application.)
I think for such a minidriver, these APIs are wrapped around by StreamClassGetPhysicalAddress, so, you're maybe OK.
Just tell stream.sys (in the init data structure) that you do not support 64bit DMA addresses, only 32bit.
Sorry I have searched HW_INITIALIZATION_DATA.
But I can't find the way how to tell stream.sys not to support 64bit
DMA address,
could you describe more detailly?
Thank you very much !
The Windows DMA APIs are also useful for bus master devices, like the
Bt878. Check out IoGetDmaAdapter and the routines it includes.
>By the way, Is the phenomenon that I can't find the tags in the
>application related to cache flushing?
>(I think data is not flushing to physical memory, so can't be read in
>application.)
Cache flushing is not an issue in x86 systems. The chipsets should ensure
cache coherency.
Now I already narrowed down the issue.
I can display video in graphedit.
1. If I connect Video Capture->Video Render (in the graphedit)
then I can see the tag that the device driver wrote in every image
2. If I connect Video Capture->Sample Grabber->Video Render (in the
graphedit)
The tag written by the driver is gone ! I guess can't wrote tag
in this situation !
But I still can see the video image.
Could anybody give me some suggestion?
Yoda
It's possible that the sample grabber is asking for a different format and
you're getting something like a color-space conversion. A lot of things
happen to frames on their way through a graph. You can't expect raw bytes
to pass through untouched.
When using windbg to do live debug, I found that:
I got address pointer from pSrb->CommandData.DataBufferArray->Data
for example,
1. pSrb->CommandData.DataBufferArray->Data = 0xfffff880`08600800
(the virtual address I got from data buffer)
2. next, I check the page frame number
0: kd> !pte 0xfffff880`08600800
I got
"pfn 1bfeef -G-DA--KWEV"
So the physical address is 0x1bfeef800
3. and then, I compare to the address got from
StreamClassGetPhysicalAddress
the physical address is 0xbf622800, it is different from the
address 0x1bfeef800
When I use 4GB RAM, these two addresses are the same, but when I use
8GB RAM,
these two addresses are different, Is this a bug of windows7 x64?
You NEVER start out explaining your own misunderstandings by blaming them
on a Windows bug.
>When using windbg to do live debug, I found that:
>I got address pointer from pSrb->CommandData.DataBufferArray->Data
>for example,
>
>1. pSrb->CommandData.DataBufferArray->Data = 0xfffff880`08600800
> (the virtual address I got from data buffer)
>
>2. next, I check the page frame number
> 0: kd> !pte 0xfffff880`08600800
> I got
> "pfn 1bfeef -G-DA--KWEV"
> So the physical address is 0x1bfeef800
The !pte command will show you both the address of the page table entry,
and the address of the page, which is stored IN the page table entry. Which
one are you looking at here?
>3. and then, I compare to the address got from
>StreamClassGetPhysicalAddress
> the physical address is 0xbf622800, it is different from the
>address 0x1bfeef800
>
>When I use 4GB RAM, these two addresses are the same, but when I use
>8GB RAM, these two addresses are different, Is this a bug of windows7 x64?
No. Is DMA involved? Perhaps you're seeing the address of the DMA bounce
buffers, which must live below 4GB.
Very sorry, I don't have any bad intension.
>
> >1. pSrb->CommandData.DataBufferArray->Data = 0xfffff880`08600800
> > (the virtual address I got from data buffer)
>
> >2. next, I check the page frame number
> > 0: kd> !pte 0xfffff880`08600800
> > I got
> > "pfn 1bfeef -G-DA--KWEV"
> > So the physical address is 0x1bfeef800
>
> The !pte command will show you both the address of the page table entry,
> and the address of the page, which is stored IN the page table entry. Which
> one are you looking at here?
here I want to find the address of the page.
> No. Is DMA involved? Perhaps you're seeing the address of the DMA bounce
> buffers, which must live below 4GB.
Thanks a lot, maybe it's why the both addresses are different.
You are right, it's DMA involved. Then my question becomes:
How do I write tags after DMA is finished in this situation?
PS: The procedure is as follows:
1. The driver got address pointer from pSrb-
>CommandData.DataBufferArray->Data
2. It translate this address to physical address by
StreamClassGetPhysicalAddress
3. use this physical address to do DMA
4. The driver need to write some tag in the position of this physical
address after DMA is complete , how do I write? Before It directly
writes tags in the address got from
pSrb->CommandData.DataBufferArray->Data, but It doesn't work now.
Best Regards,
Yoda
What does it mean "does not work"? a crash? or what?
Sorry for my unclear description.
"It doesn't work" means after the driver wrote tags in one frame of
video,
it calls StreamClassStreamNotification to return the data packet.
But when the application which use sample grabber to access the frame
it can't find the tags.
Best Regards,
Yoda
That's not what I meant. You should us one small part of the !pte output.
I'm suggesting you post the ENTIRE !pte output.