2009-08-12 21:17:37     Framebuffer not always updating

Document created by Aaronwu Employee on Aug 16, 2013
Version 1Show Document
  • View in full screen mode

2009-08-12 21:17:37     Framebuffer not always updating

Adam Dershowitz (UNITED STATES)

Message: 78794   


I have written a Framebuffer driver.  It uses dma_alloc_coherent to grab the necessary memory.  It then uses DMA to send the frame buffer information out the PPI.


I then mmap that memory in from user space and write to it from there.  The problem that I have run into is that I preload certain parts of that memory from use space, and then I start adding information as necessary, from user space.  But, it seems that in some cases the stuff that I am preloading from user space is not going out the PPI.  But, if I try to read that memory from user space to confirm the values that I have written, it does have the expected values.

So, I don't really understand how I could write a value, be able to read it back, yet not have it have the expected values going out the driver.

So, one thought I had was that the memory that I am writing from user space is being held in cache and not being written to the actual memory that is being accessed from DMA.  But, shouldn't using alloc_coherent prevent this problem?

Is there something else that could be causing this problem?

Is there something else that I need to do to force the memory that I write from user space to be coherent with the memory that the DMA is reading?  Is a memory flush of some kind necessary?  If so, what would that be?








2009-08-12 22:11:52     Re: Framebuffer not always updating

Mike Frysinger (UNITED STATES)

Message: 78795   


have you double checked the pointers returned from dma_alloc_coherent() and mmap() are in the DMA range ?  when the kernel boots up, it prints out the memory map including the DMA area that is not cached.  if using that memory range, then there should be no need to force flush/invalidates.




2009-08-13 11:53:02     Re: Framebuffer not always updating

Adam Dershowitz (UNITED STATES)

Message: 78856   


I just checked and mmap returns a value that is in the range shown at boot as:


DMA Zone  = 0x03f00000-0x04000000




2009-08-13 14:56:40     Re: Framebuffer not always updating

Mike Frysinger (UNITED STATES)

Message: 78862   


can you describe the failing behavior a bit more ?  does it update normal and then stop ?  or does it update normally, stop for a while, start working, all without poking the hardware ?


on the off chance, you could try calling __builtin_bfin_ssync() in your userspace app after doing the write to see if it makes any difference




2009-08-13 16:23:48     Re: Framebuffer not always updating

Adam Dershowitz (UNITED STATES)

Message: 78863   


The framebuffer holds a bunch of packets.  In this case the data actually represents video in an odd format with headers and such.


In one case I want a black border that will remain during the whole run of the code.  So, I added some code that loads a bunch of the values that represent black into the appropriate parts of the buffer.


Then, later, in my code, I update all the other values as necessary, but I don't go near those initial values again.  My framebuffer driver reads out that whole frame buffer and sends it out the PPI port.  But I am not getting appropriate values in that area that I had pre-set to be black.  But my other values, that are updated later are changing as expected.  So those initial values never show up on the PPI.


As a test I changed my code to actually write those "black" values every time that I write my other values and then I do get the correct values.


The reason that I was suspicious about it being a cache issue is that if I go ahead and read out my whole frame buffer and save the data to a file then it does have the expected value in it that I have preloaded.  So that confirms that I am writing what I expect and can then read it.  So it seems that if I write some values, but then never change them, and never write near those values, that they never get updated for the driver to be able to read them.