How to get the raw data from CMOS sensor in DM6446 ?

Just a couple of thoughts on this, even if not a full answer. The first thought would be cache if you are using custom driver software, if it looks like the buffer does not change it is possible you are just looking at cached data and need to perform a cache invalidate. As to the latter question you should not have to configure any DMA to capture from the VPFE, the VPFE itself is capible of initiating transfers.

Thanks for your reply!

I found this comment in sprue14b.pdf (DM6446 ARM Subsystem), page 72:

VPSS (master)  Default States is Disable !!!

But when I check the Module Status n Register, it seems ok:

VPSSMSTR=0x00001F03
VPSSSLV=0x00001F03
UART0=0x00001F03

Could you please tell me how to perform a cache invalidate ?

I found the "sync" command in console only, but I don't know how to  perform a cache invalidate in my driver.

Thanks.

I'm sorry, it is my mistake!

I sent a virt addr to ccdc_setfbaddr,  but it need the phy addr!

I can get the raw data with those code:

phy_addr = virt_to_phys(buffer);

ccdc_setfbaddr(phy_addr);

Hi,

I also want to do the same .

I have been able to capture data from CCDC , If i am not wrong.

I have used ipipe example and disabled ipipe and display code lines.By doing this and applying continuous clocks ( pixel clock, H Sync, V Sync).

I am getting buffer 0 --> buffer 1 --> buffer2 --->buffer 0 --> buffer 1 --> buffer2 ---> ...in captureframe function's infinite loop's

printf ("buffer%d",index);

Plus I have checked following proc enteries,

#1.VPFE_STATS

root@192.168.2.52:/proc/vpfe_stats# cat stats
qbuf_count = 82, dqbuf_count = 82

#2.INTERRUPTS

root@192.168.2.52:/proc# cat /proc/interrupts
           CPU0
  0:        123       AINTC  vpfe_capture
  1:        124       AINTC  vpfe_capture
  8:     505853       AINTC  davinci_osd
 12:          1       AINTC  musb_hdrc
 16:          1       AINTC  EDMA Completion
 17:          0       AINTC  EDMA CC Err
 18:          0       AINTC  EDMA TC0 Error
 19:          0       AINTC  EDMA TC1 Error
 26:      16876       AINTC  davinci-mmc
 27:       8460       AINTC  davinci-mmc
 32:     844221       AINTC  clockevent
 33:         47       AINTC  free-run counter
 39:          0       AINTC  i2c_davinci
 40:        162       AINTC  serial
 42:          0       AINTC  dm_spi
 45:     140543       AINTC  eth0
Err:          0

Now from all this can I conclude my VPFE is capturing data and putting it into buffer ??& if it is doing so how can I check the buffer data ???Can I save the buffer as RAW file as they did in LEOPARD ???

I am using DM355 EVM & MV5 linux with PSP 2.0.0.14

Digant Desai said:

Now from all this can I conclude my VPFE is capturing data and putting it into buffer ??& if it is doing so how can I check the buffer data ???Can I save the buffer as RAW file as they did in LEOPARD ??? 

I am using DM355 EVM & MV5 linux with PSP 2.0.0.14

This is certainly possible buy you may have to go to the driver layer as I do not believe there is an option for disabling the previewer hardware block (does the color space conversion from RAW to YCbCr 422) at the user space level.  The DMAI examples in the DVSDK are usually easier to work with so I would start with those and see if there is an option for disabling previewer; otherwise, you will need to modify V4L2 capture driver to accomplish true RAW Bayer Pattern capture (not the more common YCbCr).  By the way, are you sure you want RAW Bayer Pattern data as opposed to un-compressed YCbCr?

Yes I agree with you but I think I have used the RAW word inappropriately :(

By Raw I meant what ever I receive from CCDC - from hardware pins directly should be saved as a array to memory and can be stored to file.I have checked leopard codes

but I am little confused between virtual and physical memory !!
if you can help than nothing like that !!
thank you very much for your reply !!! 

In RAW capture mode, DM6446 will take whatever is at the video input pins (normally CCDs provide raw bayer pattern data) and writes it to DDR2 memory; so we should be good to go here.

With regards to the leopard codes, I am not familiar with this software.  So I am afraid you will need to go to thrid party where you bought the hardware kit from.

With regards to virtual vs physical memory, In Linux normally only the kernel space drivers have access to physical memory.  User space application access memory via virtual memory pointers.  This is all handled underneth by the Linux OS, as a programmer, you need to be aware that user space applications only have access to virtual memory so that when you are debugging, you do not think you are writing to a video buffer's physical memory and then wondering why you do not see any changed in the display.

Based on what you want to accomplish, you will need to go to the kernel driver level and disable previewer hardware block in V4L2 driver.  This is normally found under

   .../YOUR_KERNEL_DIR/drivers/media/video  

The following free online book is a good source for understanding how to work with kernel drivers: http://lwn.net/Kernel/LDD3/

thax juan , I will try & get back to you ASAP

Hi,

I have kept continuous test pattern @ CCDC pins. I am using latest Linux 's PSP and they have used mmap() for user space access to the data.

Writing that received buffer to memory and reading it , I am getting expected output for only one test pattern 0xAA.

Can you tell me how can I check where in virual / physical memory my data is written by CCDC ???

& if I kept all data lines high than I should get FF in all bits ?? I have kept data size 8 & A -Law disabled !!!

Thank you .

From a hardware perspective, if you have programmed your data-path correctly such that your CCD input is configured to go to SDRAM (Table 36 and 37 in VPFE UG are helpful), then it will be written at the physical SDRAM address programmen into SDR_ADDR register. 

From a software perspective, it is the role of the driver to program the physical address corresponding to the video capture buffer(s) managed by V4L2 capture driver into this register.  Therefore, when the application asks the driver for the next capture frame (via VIDIOC_QBUF and VIDIOC_DQBUF ioctl requests) the driver will pass the appropriate captured data back to the application.  Please note that depending on how the application is written, it accesses a copy of the buffer in user space or it can indirectly access the driver buffer via mmap; in both cases, the user space application does not have access to the physical memory address of the capture buffer programmed into SDR_ADDR hardware register.  In the mmap case, mmap simply returns a virtual address which that application can use to access the capture buffer indirectly, but the VMM (Virtual Memory Manager) is still involved in translating that virtual address into its corresponding physical address.   However, this is ok because at the application level, all you really want is access to the data; therefore if you are not seeing the data expected, I would focus on the proper configuration of the hardware (see Table 36 and 37 in VPFE UG )

Hope this helps.

Hi Juan,

Thx for your help.

Here is the matter.

I am applying 0xAAAA repeatedly on VPFE.

With 8bit A-LAW ON mode I am getting 0x0A0A.

& with 12 data bits and A-LAW disabled I am getting 0x000A.

& I apply any thing other than AAAA I am not able to get anything , all ZEROS.

I will try the way you have suggested and get back to you.

Hi juan ,

thx a lot for your help.

I have been able to get images :)

but the only problem now is I am getting a particular kind of noise here.I have attached the Images.

Hope u can tell me the cause for this !!!The other samples are..

.

In all three Images the back ground (white, grey and stripped ) is as per expectation.

how many bits of data input are you using?  are you using pack8?  seems like perhaps more data than the pixel data is being displayed.

I am asking this Just for my knowledge,

In the case where we are applying all the sync pulsed from out side , if my sensor spec are fr eg 1000 x 1000 active pixels and 1010 x 1010 total pixels than How much buffer size should I keep ?? i know this is silly , I have kept 1000 x 1000 buffer ! just asking for conformation !!

Thanks Juan for your help,I think I will solve the problem, my HSYNC and Pixel CLK are little misaligned, so data is getting over written or jusk is being captured !!

The buffer size needs to be large enough to accomodate only the active pixel data; therefore, 1000 x 1000 should be ok.

yeah thats it , thank you !!!