Re: IMX274 driver

[Sowjanya Komatineni <skomatineni@nvidia.com>]

On 6/2/20 1:51 AM, Luca Ceresoli wrote:
> Hi,
>
> [adding Leon Luo in Cc:, the maintainer and original driver author]
>
> On 01/06/20 10:47, Hans Verkuil wrote:
>> On 01/06/2020 10:31, Hans Verkuil wrote:
>>> Hi Luca,
>>>
>>> On 31/05/2020 23:56, Luca Ceresoli wrote:
>>>> Hi Sowjanya,
>>>>
>>>> On 29/05/20 04:07, Sowjanya Komatineni wrote:
>>>>> Hi Luca,
>>>>>
>>>>> Quick question regarding IMX274 driver that was up streamed by you.
>>>> Well, to be fair I only added cropping and made some improvements.
>>>>
>>>>> Upstream IMX274 driver programs Y_OUT_SIZE correctly based on IMX274
>>>>> datasheet and register mode table for Y_OUT_SIZE where it includes 6
>>>>> ignored area of effective pixels + 8 effective margin for color
>>>>> processing pixels.
>>>>>
>>>>> So, Y_OUT_SIZE register value = height + 14
>>>>>
>>>>> But somehow with this we are not seeing full frame on CSI.
>>>>>
>>>>> In our internal NVIDIA IMX274 driver, we are programming Y_OUT_SIZE to
>>>>> exact height  Y_OUT_SIZE = height
>>>>>
>>>>> So for debug, followed the same and updated upstream IMX274 driver to
>>>>> program Y_OUT_SIZE = crop.height locally and I see all resolutions
>>>>> working fine with this.
>>>>>
>>>>> Checking with Sony on whats causing sensor not to send full frame when
>>>>> Y_OUT_SIZE is set to height + 14.
>>>>>
>>>>> But thought to check with you in parallel if there are any known issues
>>>> That's strange. Unfortunately I'm not using imx274 anymore since a long
>>>> time and don't remember the details, but definitely I did test it and if
>>>> there had been 14 missing lines I'm pretty sure I would have noticed.
>>>>
>>>> I'll see if I can remember anything useful, and in case I'll update you.
>>>> I would be glad if you can update me on any findings too, maybe they
>>>> will help in understanding the problem better.
>>> The '+ 14' makes no sense. I wonder if this was perhaps to compensate for
>>> some problem in the bridge driver that this sensor was connected to.
>>> Which bridge driver did you use for testing? Do you remember where you got
>>> the '+ 14' from?
>> Hmm, this comes from the first version of this driver where Y_OUT_SIZE
>> was set to 0x87e (2160 + 14). This in turn comes from the datasheet ('Register
>> Setting for Each Readout Drive Mode').
>>
>> Looking at the "Detailed Specification of Each Mode" (page 63 in my copy of
>> the datasheet) I see three additional parameters: "Front ignore area of
>> effective pixel", "Front effective margin for color processing" and "Rear
>> effective margin for color processing", these are 6, 4 and 4, which is a
>> total of 14.
>>
>> So I guess that's where the 14 comes from.
> Double-checked, and I agree.
>
>> Knowing with which bridge driver this was tested will definitely be helpful.
> The design was based on a Xilinx zcu106 and the sensor output went into
> the Xilinx MIPI CSI-2 RX subsystem IP (currently being mainlined), an
> ISP IP and a Xilinx video DMA IP block, I think it was the "Video Frame
> Buffer Writer" IP. I did several experiments with similar setups, even
> with basic a Xilinx debayer+CCM in place of the ISP, and don't remember
> any problems with wrong lines.
>
> Wild guess: Sowjanya, are you using VFLIP? I never used that, but it
> might influence the order of lines processing somehow.

No I am not using VFLIP.

Did quick experiment of keeping buffer as valid even in case of frame 
buffer write timeout to see so far captured image and I see full 
3840x2160 image capture with both cases where Y_OUT_SIZE = height and 
also with Y_OUT_SIZE = height + 14

Could be something during end of frame when using Y_OUT_SIZE = height + 14

Provided all register settings being used to Sony and explained this 
observation. Will update when I hear from them.

Also will check how these 14 lines (ignore + color processing effective 
margin) translates to CSI frame sent out..