Re: IMX274 driver

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

 




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





[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