Re: IMX274 driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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






[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux