VPFE Interrupts

Randy, I can't say too much about what the Linux drivers are doing in terms of setting up the VPSS and Arm interrupt controller as I'm not too familiar with that. I can comment on a few things to check from a device standpoint. If you have JTAG access and can connect to your target using CCS, there are some registers we can check.

There are a few documents we need to reference:

• The datasheet: tms32dm368.pdf
• VPFE User's Guide: prufg8c.pdf
• Arm Subsystem Users Guide: sprufg5a.pdf

 Here's a list of things I would check:

• Is the VPSS module enabled? This is the first thing I always check. The MDSTATn register in the power-sleep controller (PSC) will denote the state of the VPSS module, in other words, is it clock gates? In the Arm Subsystem User's Guide, table 39 lists the module number for the VPSSMASTER as module number 47. That means we need to check the MDSTAT47 register. It has an address offset of 0x800 + 47*4 =  0x8BC, the PSC has a base of 0x01C41000 so the address of MDSTAT47 is 0x01C418BC. Read this register and make sure the VPSS is enabled, see table 52 of the Arm Subsyste Users Guide. The key thing to look for is the module clock enable, MCKOUT bit (bit 12) of MDSTAT47.
• Is the pin muxing correct? Check PINMUX0 register at address 0x01C40000. The HD (HSYNC) and VD (VSYNC) pins can be muxed with other functions, make sure the value of this register reflects HD and VD being the mode selected for these pins. Refer to section "2.6.7 Pin Mux 0 Register (PINMUX0)" of the VPFE users guide.
• Is the correct hardware request mux'ed to the interrupt you want? The VPSS itself can generate 9 interrupts to the Arm, VPSS_INT0 through VPSS_INT8. However, the VPSS can generate 25 different hardware requests so a mux'ing scheme is in place that allows you to map hardware requests to each of the 9 interrupts. See table 3-2 of the VPSS users guide. It sounds like you may want ISIF_INT0 which is event 0 (VDINT0) which will trigger after a designated number of lines in a frame. If you want this mapped to VPSS_INT0, check the INTSEL0 field of the INTSEL1 register, see section 6.6.5, and see if it has a value of 0 (ISIF_INT0). The register has an address of 0x01C70010.
• Does the VPSS think its getting the interrupt? You can check the interrupt status register (local to the VPSS module) to see what if any interrupts have occured. The INTSTAT register is at address 0x01C7000C. See section 6.6.4.
• Is the interrupt mux'ed properly in the Arm? Not only does the VPSS module have its own internal interrupt muxing, the Arm itself has a mux and it turns out VPSS_INT0, VPSS_INT7, and VPSS_INT8 are muxed with other interrupts. You need to check the Arm's INTMUX (ARM_INTMUX) register to make sure the VPSS interrupts are selected or at least the one you want which I assume if VPSS_INT0. Read the value of ARM_INTMUX at address 0x01C40018, bit 31 INT0 VPSS_INT0. See section 9.12.8 of the Arm subsystem users guide. You want to make sure bit 31 has a value of 0.
• Is the Arm interrupt itself enabled? The Arm interrupt controller AINTC can handle 64 interrupts, see chapter 8 of the Arm subsystem users guide. Interrupt number 0 is VPSS_INT0. The best thing to check is if the interrupt is enabled, check the EINT0 register and see if bit 0 is set or not, a 1 means enabled. The address of EINT0 is 0x01C48018.
• There are probably other things I haven't mentioned like clock control and clock mux'ing but I'd first go though the checklist above and see if any of those don't look right and if they don't, then we'd need to figure out why the driver is not setting them up correctly.

Regards,

-Brad

Hi Brad,

Thanks for the reply!  I went ahead and checked everything that you mentioned in your post and everything seems to be set up correctly.

* The VPSS module is enabled.  The value of MDSTAT47 is 0x1F03.

* The pin muxing is correct (I acutally had already checked this to make sure it was the case)

* The INTSEL1 register has a value of 0xB1F0100.

* The VPSS does not thing it is getting any interrupts.  I read the INTSTAT register and it was 0x300000.

* The ARM_INTMUX register read a value back of 0x3C404.

* The ARM interrupt itself was enabled, the value of EINT0 is 0x4831169.

The values above were taken from our custom hardware.  We do have an evaluation board for the decoder chip connected into the DM368 EVK and that is working fine.  We are focusing on differences between our board and the two EVK's.  The decoder chip seems happy on our custom board (outputting PCLK at correct frequency, LOCK status bit is high which means it is locked on the input, data output bits are toggling along with HSYNC and VSYNC...).  Since I am running an almost identical kernel on the DM368 EVK and our custom hardware, I wouldn't think it is a DM368 setup issue either.

If you have any other ideas and/or registers to check, please let me know and I will make sure they are as expected.

Thanks,

Randy

Are you using a different image sensor? Do your HD/VD signals meet those blanking requirements?

Hi Hongfeng,

I am using a SDI decoder chip (GS2971A) that I had working with an EVK for that decoder chip and the DM368 EVM.  The processor is set up in the BT.1120 mode and I believe it is looking for the SAV and EAV signals in the data stream.  As stated, this was working with the two EVK's but with our custom hardware the VPFE does not report any interrupts.  My guess is somehow it's not reading the SAV and EAV signals properly, which to my understanding, generate the internal interrupt signals in the DM368.

I don't know enough about analyzing the output to tell if there are valid SAV and EAV signals.  Does anyone have experience with this?

Thanks!

Randy

Hi, there!

I am using DVSDK4.02 for dm368 on our customer board, we do not chained CCDC with the imp, and get 8-bit raw image from /dev/vidoe0, we designed the board can capture one frame after the software writing a trigger cmd to hardware(FPGA), but we found that after the trigger cmd is sent, we can enter VDINT0 isr first and then VDINT1 isr,  in VDINT1 isr, the new frame is put in the que, and  in VDINT0 isr the frame is processed and notify the driver a new frame is ready, so in the order we can't got the first frame until we receive another VDINT0; 

After checking the driver code, I found, in "dm365_ccdc.c", function "void ccdc_setwin(struct v4l2_rect *image_win, enum ccdc_frmfmt frm_fmt, int ppc, int mode)", line 333, it set VINT0 trigger condition as following: 

if (!mode)
    regw(0, VDINT0);
else
    regw(vert_nr_lines, VDINT0);

so for imp not chained mode, VDINT0 must be triggered at the beginning of a frame, if I committed the first 3 lines, just set  regw(vert_nr_lines, VDINT0); then VDINT1 will triggered before VDINT0, and we can get one frame after one trigger command, and the image recieved is ok. Because there is no comment at all, I just wondering why the orignal programming want the VDINT0 happened at the beginning of a frame, is there any hardware limitations for IMP unchained mode?

Looking for your reply.

Best Regards!

Eric Sun