linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
To: Luca Ceresoli <luca@lucaceresoli.net>,
	Sowjanya Komatineni <skomatineni@nvidia.com>,
	Frank Chen <frankc@nvidia.com>,
	Thierry Reding <treding@nvidia.com>,
	linux-media@vger.kernel.org
Subject: Re: IMX274 driver
Date: Mon, 1 Jun 2020 10:31:37 +0200	[thread overview]
Message-ID: <d81c6fec-e7de-1282-9e17-1fc0f5dea9eb@xs4all.nl> (raw)
In-Reply-To: <afd8fdb8-e359-5aee-ba3e-54a5217b2aee@lucaceresoli.net>

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

  reply	other threads:[~2020-06-01  8:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29  2:07 IMX274 driver Sowjanya Komatineni
2020-05-31 21:56 ` Luca Ceresoli
2020-06-01  8:31   ` Hans Verkuil [this message]
2020-06-01  8:47     ` Hans Verkuil
2020-06-02  8:51       ` Luca Ceresoli
2020-06-02 14:17         ` Sowjanya Komatineni
2020-06-02 16:16           ` Sowjanya Komatineni
2020-06-02 20:08             ` Luca Ceresoli
2020-06-23 17:25               ` Sowjanya Komatineni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d81c6fec-e7de-1282-9e17-1fc0f5dea9eb@xs4all.nl \
    --to=hverkuil-cisco@xs4all.nl \
    --cc=frankc@nvidia.com \
    --cc=linux-media@vger.kernel.org \
    --cc=luca@lucaceresoli.net \
    --cc=skomatineni@nvidia.com \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).