Hello all,
there is some problem i am facing on DM368 Flip-ON MIRROOR-ON ( On DM365 i don't face the same problem at same condition )
If my video Display out put is enabeled with Flip ON - Mirror ON then my Analog Display output for moving objects looks to be cracked .
If i make a delay of 5ms in the postpone buffer the display out put is ok.
Its very strange . Normal case my Analog Video Display output is ok with out addition of any delay.
I can not afford a 5ms delay.
Following is my Kernel Flip/Mirror Modified source : ( As the original Source Flip Mirror don't work properly , it continiously flips between flip and mirror condition if both on)
Inside Dm365_ipipe_hw.c , rsz_set_rsz_regs()
//Fix FLIP/MIRROR Bug Modified Source if ((get_device_type() == 7)||(get_device_type() == 8)){ if (rsc_params->h_flip) utemp |= rsc_params->h_flip << RSZA_H_FLIP_SHIFT; else utemp &= ~(1 << RSZA_H_FLIP_SHIFT); if (rsc_params->v_flip) utemp |= rsc_params->v_flip << RSZA_V_FLIP_SHIFT; else utemp &= ~(1 << RSZA_V_FLIP_SHIFT); }else {
//Orginal Source utemp = rsc_params->h_flip << RSZA_H_FLIP_SHIFT; utemp |= rsc_params->v_flip << RSZA_V_FLIP_SHIFT; } reg_base = RSZ_EN_A;
} else { rsc_params = ¶ms->rsz_rsc_param[RSZ_B]; rgb = ¶ms->rsz2rgb[RSZ_B]; ext_mem = ¶ms->ext_mem_param[RSZ_B];
//Fix FLIP/MIRROR Bug Modified Source if ((get_device_type() == 7)||(get_device_type() == 8)){ if (rsc_params->h_flip) utemp |= rsc_params->h_flip << RSZB_H_FLIP_SHIFT; else utemp &= ~(1 << RSZB_H_FLIP_SHIFT); if (rsc_params->v_flip) utemp |= rsc_params->v_flip << RSZB_V_FLIP_SHIFT; else utemp &= ~(1 << RSZB_V_FLIP_SHIFT); }else {
//Original Source utemp = rsc_params->h_flip << RSZB_H_FLIP_SHIFT; utemp |= rsc_params->v_flip << RSZB_V_FLIP_SHIFT; } reg_base = RSZ_EN_B;
Hi Sujit,
Are you using RSZ in ISIF input mode or DDR input mode? Actually, with flip or mirror feature, the RSZ needs little additional DDR bandwidth. If you have kept the resizer clock to be marginal for your non-flip usecase, then it is expected that the RSZ operation might not complete successfully when setting flip mode ON. So i recommend you to reduce resizer clock. I hope you are already aware of the ways you can slow down resizer (using clkM, clkN of IPIPEIF or LPFR, PPLN of IPIPEIF in DDR input mode).
Regards,
Anshuman
Anshuman,
various combination of PPLN, LPFR values are not helping out.
my current setting for PPLN, LPFR is
rszSSConfig.input.ppln = rszSSConfig.input.image_width + 8; rszSSConfig.input.lpfr = rszSSConfig.input.image_height + 100;
I saw following post you had suggested for checking the enable bit of ipipeif, Resizer A and Resizer B before the RSZ_RESIZE ioctl call.
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/111526.aspx
But i am not sure how to check in user side the IPIPEIF, RSZ-A,RSZ-B enable bits.
confused with the above statement. As per vpfe user guide it should be
RSZ in ISIF input mode - i.e IPIPEIF INPSRCx = 0 0r 2 - LPFR, PPLN of IPIPEIF ( Pixel clock)
RSZ in DDR input mode - i.e IPIPEIF INPSRCx = 1 0r 3 - clkM, clkN of IPIPEIF (SDRAM Clock as per clk_div.m and clk_div.n )
Sujit,
sujit mahapatro RSZ in ISIF input mode - i.e IPIPEIF INPSRCx = 0 0r 2 - LPFR, PPLN of IPIPEIF ( Pixel clock)
In ISIF input mode, the IPIPEIF configuration of LPFR and PPLN does not control pixel clock. Pixel clock is controlled by the sensor input in this case.
For DDR mode, pixel clock to resizer can be controlled by using either the clock dividers that you mentioned or using LPFR and PPLN of IPIPEIF.
PS: Please mark this post as verified, if you think it has answered your question. Thanks.
Thanks Anshuman,
in my case RSZ in ISIF input mode, so as you said various combination of PPLN and LPFR of IPEPEIF will not help me to solve this problem remains.
Do you think in some of your post what ever you had mentioned to check the enable bit of IPIPEIF, RSZA,RSZB before the RSZ_RESIZE ioctl clock, which will make sure that the previous resize operation finished, will help ?
If so please let me know how can i check the enable bits of IPIPEIF, RSZA,RSZB before RSZ_RESIZE ioctl call , is there any api or ioctl function available for checking this from user side.
Hi Anshuman,
let me know how can i check the enable bits of IPIPEIF, RSZA,RSZB before RSZ_RESIZE ioctl call , is there any api or ioctl function available for checking this from user side.
Please let me know.
I dont remember any IOCTL to print the enable bits. You might want to add this in the kernel code of the RSZ_RESIZE ioctl.
But i dont think in this case, we would have such problem. You should instead try to see if you can increase the blanking from your input source.
for blanking we need to very the ppln and lpfr, right ? if yes
currently my ppln and lpfr is as like below..
i tried increasing lpfr but still i couldn't get any improvement.
rszSSConfig refers to single shot config where DDR input mode is used. Are you using this mode or are you using continuous mode (ISIF input mode)?
regards,
i use ISIF and DDR input mode both which changes at run time.
Where as this problem happens in DDR mode. (rszSSConfig.input.clk_div.m = 10; rszSSConfig.input.clk_div.n = 80; rszSSConfig.input.ppln = rszSSConfig.input.image_width + 8; rszSSConfig.input.lpfr = rszSSConfig.input.image_height + 100; )
my Sensor is RawBayer Sensor and my CFG1.INPSRC1/2 both are configured as 2 ( FROM ISIF & SDRAM(darkframe))
and my resizer input is from IPIPE i.e SRC_FMT0 is 0 .
please let me know what shoud i try for resolving this issue.
Hi All,
This issue has been resolved by slowing down the resizer in Flip/Mirror Mode enabeled case.
Mainly in Mirror case Resizer clock needs to be slower down to meet the bandwidth.
But we found that when IPIPEIF SRC1 data source is from SDRAM_RAW in RAW BAYER sensor case the clock divider is
getting updated via previewer configuration only. So we have we have added clock devider update in SDRAM_RAW case which will take
the setting from user very similarlike SDRAM_RAW case.
There is no fixed value of clock setting, so various combination has to be tried. My current setting for DM368 is div.m = 10 and div.n = 120 in which i don't have any problem.
Thanks to Raghu, Anshuman,Kedar.