Re: IMX274 driver

[Luca Ceresoli <luca@lucaceresoli.net>]

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.

-- 
Luca