about dm355_aew driver's black row

Did you ever get a solution to your problem. The version of dm355_aew.c (kernel 2.6.18_pro500-davinci_dm355-arm_v5t_le) that I have is exactly the same as yours, but I still think that there is black row data in the buffer returned by the driver.

By the way, my problem is little different. I don't want any black rows and the configuration doesn't allows a zero height for black window. I feel the black- row-data is getting mixed up with the regular rows.

The way I am able to detect that my regular-window-data is incorrect is through the accumulator values. They are far exceeding the expected maximum, which I calculate by multiplying the (number of pixels / sub-sample / color-channel) with 1023 (assuming 10 bit data). I would appreciate any ideas on why the regular-row-data is not making sense?

In lsp 1.2, in driver/media/video/dm355_aew.c open() function

        /*Allocat the buffers as per the new buffer size */
        /*Allocate memory for old buffer */
        buff_size = (aew_dev_configptr->config->window_config.hz_cnt)
            * (aew_dev_configptr->config->window_config.vt_cnt) *
            AEW_WINDOW_SIZE;

I found buff_size not include black row window (use to estimate dc sub).

even in PSP 3.xx its pretty the same code there.

and it is not working that good as it should since there is a noticeable discrepancy compared to the the silicon frozen "AE" hardware unit.

the data sheet for this unit does need update for this highly critical aspect for enabling people to code a truely stable driver.

without such a (hopefully peer reviewed) even the TIs FAE team might not be able to hint you for the right solution.

I have a similar issue.

For those running into this issue, here is a link in case there is a positive outcome in the quest for a solution of "The Problem".

http://e2e.ti.com/support/embedded/f/354/t/125860.aspx