IMX274 driver

IMX274 driver

[Sowjanya Komatineni]

Hi Luca,

Quick question regarding IMX274 driver that was up streamed by you.

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 
related to this with IMX274 driver.

Appreciate your response.

Thanks & Regards,

Sowjanya

Re: IMX274 driver

[Luca Ceresoli]

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.

Regards,
-- 
Luca

Re: IMX274 driver

[Hans Verkuil]

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?

Regards,

	Hans

Re: IMX274 driver

[Hans Verkuil]

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.

Knowing with which bridge driver this was tested will definitely be helpful.

Regards,

	Hans

Re: IMX274 driver

[Luca Ceresoli]

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

Re: IMX274 driver

[Sowjanya Komatineni]

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..

Re: IMX274 driver

[Sowjanya Komatineni]

On 6/2/20 7:17 AM, Sowjanya Komatineni wrote:
>
> 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..
>
Hi Luca,

Can you please provide exact set-fmt and crop settings you used for 
imx274 pipeline for 3840X2160 mode1 testing?

Would like to try same just in case..

Thanks

Sowjanya

Re: IMX274 driver

[Luca Ceresoli]

Hi,

On 02/06/20 18:16, Sowjanya Komatineni wrote:
> 
> On 6/2/20 7:17 AM, Sowjanya Komatineni wrote:
>>
>> 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..
>>
> Hi Luca,
> 
> Can you please provide exact set-fmt and crop settings you used for
> imx274 pipeline for 3840X2160 mode1 testing?

I don't remember much anymore. But I forgot to mention I [almost] always
worked with 1920x1080 capture, either with binning or with cropping. I
don't think the will change much, as the '+14' is equal in readout modes
1 and 3 (1920p and 3840p modes at 10 bits). Can you try that nevertheless?

-- 
Luca

Re: IMX274 driver

[Sowjanya Komatineni]

On 6/2/20 1:08 PM, Luca Ceresoli wrote:
> Hi,
>
> On 02/06/20 18:16, Sowjanya Komatineni wrote:
>> On 6/2/20 7:17 AM, Sowjanya Komatineni wrote:
>>> 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..
>>>
>> Hi Luca,
>>
>> Can you please provide exact set-fmt and crop settings you used for
>> imx274 pipeline for 3840X2160 mode1 testing?
> I don't remember much anymore. But I forgot to mention I [almost] always
> worked with 1920x1080 capture, either with binning or with cropping. I
> don't think the will change much, as the '+14' is equal in readout modes
> 1 and 3 (1920p and 3840p modes at 10 bits). Can you try that nevertheless?

Just to update, discussed on this issue with Sony.

Sony confirmed Y_OUT_SIZE should be the height of effective image output 
from sensor which are actually the total lines sent over CSI to receiver.

Receiver expected height should match this. So, Y_OUT_SIZE = crop height.

Regarding WRITE_VSIZE Sony mentioned, it includes Vertical OB where OB 
is a shaded pixel for black level adjustment. When using this, it is 
highly recommended that ISP use the OB value to make black level 
adjustments.

WRITE_VSIZE should be set to height + 8.

Using height + 22 will not have any impact if we dont use ISP and this 
VOB is shaded pixel for black level adjustment where ISP need to use to 
make black level adjustment.

I tried by changing driver to set WRITE_VSIZE = crop.height + 8 and 
Y_OUT_SIZE = crop.height for all supported resolutions and capture works 
fine without any issues.

Thanks

Sowjanya