dm36x face detect driver port

Hi Randy,

Thanks for the confirmation. I was suspecting the PICADDR and WKADDR but then i thought, these are the addresses that you would have set.

Any other specific changes you were stuck with when you moved from DVSDK 2.1x to DVSDK 4.x? I dont expect any major hindrances, but was wondering if you saw some problems.

Regards,

Anshuman

Hi Anshuman,

The driver port from the 2.10 SDK to the 4.02 SDK was actually pretty straightforward.  I think the only thing I have left to clean up is the allocation of the VPFE interrupt.  If I remember correctly, the VPFE has 5 or 6 irq's and in the ported driver I just picked one that wasn't being used.  I think the old driver had a vpfe_request_irq API that was a bit more intelligent about picking a free irq at runtime.  In order to call it finished, I would want to port some of these smarts into my ported driver.

Also, I think I would want to clean a few things up in the driver.  The driver just hung when I sent it an invalid PICADDR and WKADDR values so I would probably want to create some sort of timeout watchdog on that interrupt.  Also, there are multiple places in the driver that ignore return values that should probably be cleaned up.

Thanks,
Randy

Randy/Anshuman,

I'm also trying to implement a Face Detection Module for the DM365 using the DVSDK 4.xx. From this post I understand that I will need to port the DVSDK 2.10 Face Detection driver so I've downloaded that DVSDK but cannot identify a candidate drive.  Can someone provide the name of the driver or send me a link?

Thanks,

-Chuck

Randy/Anshuman/All,

Never mind, I finally located the Face Detection Module driver in LSP 2.10 specifically in the following directories:

   ~/mv_pro_5.0.0/montavista/pro/devkit/lsp/ti-davinci/linux-2.6.18_pro500/drivers/char/... for dm365_facedetect.c, dm365_facedetect_hw.c, and dm365_facedetect_hw.h 

   ~/home/cimarron/mv_pro_5.0.0/montavista/pro/devkit/lsp/ti-davinci/linux-2.6.18_pro500/include/asm-arm/arch-davinci/... for dm365_facedetect.h

I assume that these are all I need for a port to DVSDK 4.xx?

Now for a "design philosophy" question: for a robust (i.e., one that is fast and accurate) face/object detection and tracking algorithm, is it better to use the DM36x Face Detection Module (HW assisted) or the ROI facility of the H.264 (also HW assisted) or some combination of the two?

Does anyone have experience with either or both of these approaches?

Thanks,

-Chuck

Hi Chuck,

Yes, all you have to do is port the driver to the DVSDK 4.xx and it should work.  More accuratly speaking, porting the driver to the new kernel that is included with the DVSDK 4.xx.  Some API's were changed between the montavista kernel and the updated kernel and it was a pretty straightforward process to get it ported.

As far as the design philosophy question goes, I've only used the face detection hardware for identification and not tracking.  The face detect module does have an ROI feature, so you may want to look at that before you try and use the ROI on the H.264.

-Randy

Randy,

Thanks for your reply: I will give the Face Detection drive port a try - it's good to know that you were able to get it done without a lot of trouble.

As to the best design approach: it does seem that using the Face Detection Module hardware along with some of the available OpenCV or VLIB libraries may work well.

Thanks again,

-Chuck

Randy,

I cannot locate 'face detect_example.c' in either DVSDK 2.10 or in LSP 2.10 for the DM365: I assume that this example came with some version of DVSDK 2.xx can you point me to which version and for which SoC the sample application was written?

Thanks,

-Chuck

Chuck,

The face detection example was written for the DM365 SoC.  You can find the source files at the following link and downloading the LSP 02_10_00_14 Collateral package.

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_10/latest/index_FDS.html

-Randy

Randy,

I have it now...

Thanks,

-Chuck

Anshuman / Randy,

As I get into the process of porting the Face Detection Module driver from DVSDK 2.10 to DVSDK 4.xx, I have several questions regarding how to organization the driver files within the Linux Kernel file structure and other possible changes:

1. From DVSDK 2.10 I have 4 driver files, i.e., dm365_facedetect.h, dm365_facedetect.c, dm365_facedetect_hw.h, and dm365_facedetect_hw.c that were written and organized into the kernel file structure as a "char driver" so  should I organize my driver files in the same way?

2. If so, this would mean that dm365_facedetect.c, dm365_facedetect_hw.h, and dm365_facedetect_hw.c would be placed in -> ...<linux>/drivers/char and dm365_facedetect.h would be placed in -> ...<linux>/include/media/davinci (recall that this is a different location from that used in DVSDK 2.10). Does this make sense or is there a better way?

3. Currently, my plan is to use the driver files essentially unmodified except for #include files: does this make sense?

4. Are there #include or other files that need to be changed?

5. Are there any other changes that I need to make?

Thanks,

-Chuck

Hi Chuck,

You can organize the driver files the same way as in the DVSDK 2.10 kernel.  You could really put the drivers anywhere in the tree, but unless there is a good reason to move them keeping them in the same place is probably the best idea.

The only changes that I made to the driver were to update some of the linux API calls.  If I remember correctly, I compiled, fixed compile errors, and repeated until finished.  Since the 2.10 kernel was based on a much older kernel, some of the linux API's have changed.  I think one of the problem API's was the request IRQ API.  That has since changed so you'll just have to find what functions changed between the kernels and substitue the newer version of the same function.

-Randy

Randy,

Thank you for your tips: I have indeed found that the driver APIs have changed significantly from the previous kernel version; therefore, my current approach is to pattern my new driver after the AF and AEW drivers with some obvious changes. And you are correct about the way the interrupt request and interrupt service routines need to be formed.

Thanks again for your advise,

-Chuck

Hi all

I encountered the problem with face detector on dm368 processor.

It works perfectly when takes a image from memory.

But when I try to connect it to vpss and resizer to operate with video stream from a camera it stops detecting faces.

He stops working as soon as I enable vpss by writing 1 to ISIF_SYNCEN (0x01c71000) address.

Сan anyone answer the question: can facedetector work simultaneously with the VPSS and resizer or it works from memory only?

Sergey,

As far as I know, the Face Detection Module can only operate on monochrome images that are in system memory (DRAM) in the 4-bits/pixel as specified in the DM36x Face Detection User's Guide page 22:

"The target image for processing must be stored by the system side in the input image area before the start of processing. The storage format should be 1 word per 4 pixels in order of the coordinates as shown in Figure 6 . In this device, the default data output format is the same data format as expected by the face detection hardware."

I developed a Face Detection Module device driver for DVSDK 4.xx until I realized that - again, as far as I can determine - the Face Detection Module does not play well with my application, i.e., real time streaming H.264 encoded video.

-Chuck

Chuck

I mean whether the FD works  with video port (ISIF-resizer)  together? I have it only works when I load image to memory from disk file.

Sergey

Chuck

Format for FaceDetector is 8-bit/pixel, not 4. There are 4 pixels in 1 word.

Sergey

Sergey,

According to the documentation, the monochrome window image must be written to DRAM before the Face Detection Module can search for faces within the window. And yes, you are correct, the monochrome image pixel format is 8-bit pixels as 4-pixels per 32-bit word.

-Chuck

Hello,

I am also working on porting driver from DVSDK-2. In my case, there is no start of work:

static void regs_dump() {
    printk("---\n");
    printk("%08X %08X\n", 0x000, regr_if(0x000));
    printk("%08X %08X\n", 0x008, regr_if(0x008));
    printk("%08X %08X\n", 0x00C, regr_if(0x00C));
    printk("%08X %08X\n", 0x010, regr_if(0x010));
    printk("%08X %08X\n", 0x020, regr_if(0x020));
    printk("%08X %08X\n", 0x024, regr_if(0x024));
    printk("%08X %08X\n", 0x028, regr_if(0x028));
    printk("%08X %08X\n", 0x02C, regr_if(0x02C));
    printk("%08X %08X\n", 0x030, regr_if(0x030));
    printk("%08X %08X\n", 0x034, regr_if(0x034));
    printk("%08X %08X\n", 0x038, regr_if(0x038));
    printk("%08X %08X\n", 0x03C, regr_if(0x03C));
}

int facedetect_execute(struct facedetect_params_t *config)
{
        volatile int cnt = 0;

        /* Enable Face Detection */

        regs_dump(); /* Dump registers before reset */
   
        regw_if(1, FDIF_INTEN);

        regw_if(1 << SRST_CONTROL, FD_CTRL);

        /* Delay between SW Reset and Run. Need Tuning */
        for (cnt = 0; cnt < 20000; cnt++);

        regw_if(1 << RUN_CONTROL, FD_CTRL);
        regs_dump(); /* Dump after reset and start run */

        for (cnt = 0; cnt < 20000; cnt++);
        regs_dump(); /* Dump - May be finished? */

        facedetect_int_wait(1);

        facedetect_int_clear(1);

        regw_if(0, FDIF_INTEN);

        facedetect_get_num_faces(config);
        facedetect_get_all_face_detect_positions(config);

        return 0;
}

Out:

---
00000000 00000000
00000008 00000000
0000000C 42D45000
00000010 42D51000
00000020 00000000
00000024 00000000
00000028 00000000
0000002C 00000000
00000030 00000000
00000034 00000140
00000038 000000C0
0000003C 00000004
---
00000000 00000000
00000008 00000001
0000000C 42D45000
00000010 42D51000
00000020 00000002
00000024 00000000
00000028 00000000
0000002C 00000000
00000030 00000000
00000034 00000140
00000038 000000C0
0000003C 00000004
---
00000000 00000000
00000008 00000001
0000000C 42D45000
00000010 42D51000
00000020 00000002
00000024 00000000
00000028 00000000
0000002C 00000000
00000030 00000000
00000034 00000140
00000038 000000C0
0000003C 00000004

The state of the register FD_CTRL is not changed and therefore there is no interruption. In what may be the problem?

Oleg,

I would ask a couple of big picture questions:

   1. Have you written your face detection image into the correct memory location and format, i.e., 8 bits/pixel monochrome?

   2. Does your new face detection driver work with the 'facedetect_example.c' found in LSP 02_10_00_14 Collateral at

       http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_10/latest/index_FDS.html?      

-Chuck

P.S.

I also assume that you are developing with a DM365 SoC that has a "F" in the suffix, if not, all bets are off.

Chuck,

1. Engine _should_ start no matter whether have or have not a picture in buffer. Buffers is allocated successfully

2. I took the code from this example. I modified it to allocate memory through CMEM

 I use DVR reference design with DM368. And yes - with "F"

Oleg,

Hum...  It sounds like you have everything set up properly - I'm at a lose to provide additional help.

-Chuck