Re: IMX274 driver

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

 



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




[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