From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org,
Manivannan Sadhasivam <mani@kernel.org>,
Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: Re: [PATCH 03/19] media: i2c: imx290: Specify HMAX values in decimal
Date: Thu, 21 Jul 2022 13:54:18 +0200 [thread overview]
Message-ID: <3293452.QkHrqEjB74@steina-w> (raw)
In-Reply-To: <Ytk5LAizibrAraFd@pendragon.ideasonboard.com>
Hi Laurent,
Am Donnerstag, 21. Juli 2022, 13:31:56 CEST schrieb Laurent Pinchart:
> Hi Alexander,
>
> On Thu, Jul 21, 2022 at 11:18:24AM +0200, Alexander Stein wrote:
> > Hi Laurent,
> >
> > thanks for working on this, I've also some patches on top for imx327
> > support.
> I'm using an IMX327 with this driver without any need for additional
> patches :-) I'd be happy to test our patches though.
Same for me, but I feel unpleasent writing to reserved bits ;-)
> > Am Donnerstag, 21. Juli 2022, 10:35:24 CEST schrieb Laurent Pinchart:
> > > The HMAX value specifies the total line length in pixels. It's thus more
> > > readable in decimal than hexadecimal. Fix it.
> >
> > I understand the motivation, pixels are more natural in decimal numbers,
> > but e.g. what is 4400 pixels on this sensor? It is only mentioned
> > sparsely and 3300d is not mentioned at all, 0ce4h is instead.
>
> I'm not even sure if HMAX is expressed in pixels or in cycles of some
> internal clock different than the pixel clocks.
>
> > I also like to have the hexadecimal numbers here as you can find them
> > directly in the datasheet. To me this seems more sensible for
> > cross-checking. Just my opinion.
>
> It's a matter of readability of the driver code vs. matching with the
> datasheet. I have a preference for decimal numbers here, but I don't
> mind too much. What I would actually like is dropping the hmax value
> from the imx290_mode structure and computing it dynamically based on a
> hblank value set by userspace. Do you think you could help me doing so ?
Well, in my patch stack there is one adding vmax to this struct ;-)
It works without modification but this is essentially the so called 'long
exposure operation'.
Reducing vmax on 720p increases the FPS, so this is a sensible thing to do.
The exposure has to be recalculated from that (dynamic) vmax value.
But computing those values completely dynamically seems a sensible thing to
do. Until it is fully understood I would prefer keeping hexadecimal values.
I mean do you know why it is 4400 pixels for 1080p and 6600 for 720p on 2
lanes?
I know this is part of your [1] branch. So I'll post my patches once this
series is settled.
Best regards,
Alexander
[1] https://gitlab.com/ideasonboard/nxp/linux/-/commits/pinchartl/v5.19/
sensors/imx
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > ---
> > >
> > > drivers/media/i2c/imx290.c | 8 ++++----
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > > index 64bd43813dbf..f60a4135dc9c 100644
> > > --- a/drivers/media/i2c/imx290.c
> > > +++ b/drivers/media/i2c/imx290.c
> > > @@ -308,7 +308,7 @@ static const struct imx290_mode
> > > imx290_modes_2lanes[] =
> > > { {
> > >
> > > .width = 1920,
> > > .height = 1080,
> > >
> > > - .hmax = 0x1130,
> > > + .hmax = 4400,
> > >
> > > .link_freq_index = FREQ_INDEX_1080P,
> > > .data = imx290_1080p_settings,
> > > .data_size = ARRAY_SIZE(imx290_1080p_settings),
> > >
> > > @@ -316,7 +316,7 @@ static const struct imx290_mode
> > > imx290_modes_2lanes[] =
> > > { {
> > >
> > > .width = 1280,
> > > .height = 720,
> > >
> > > - .hmax = 0x19c8,
> > > + .hmax = 6600,
> > >
> > > .link_freq_index = FREQ_INDEX_720P,
> > > .data = imx290_720p_settings,
> > > .data_size = ARRAY_SIZE(imx290_720p_settings),
> > >
> > > @@ -327,7 +327,7 @@ static const struct imx290_mode
> > > imx290_modes_4lanes[] =
> > > { {
> > >
> > > .width = 1920,
> > > .height = 1080,
> > >
> > > - .hmax = 0x0898,
> > > + .hmax = 2200,
> > >
> > > .link_freq_index = FREQ_INDEX_1080P,
> > > .data = imx290_1080p_settings,
> > > .data_size = ARRAY_SIZE(imx290_1080p_settings),
> > >
> > > @@ -335,7 +335,7 @@ static const struct imx290_mode
> > > imx290_modes_4lanes[] =
> > > { {
> > >
> > > .width = 1280,
> > > .height = 720,
> > >
> > > - .hmax = 0x0ce4,
> > > + .hmax = 3300,
> > >
> > > .link_freq_index = FREQ_INDEX_720P,
> > > .data = imx290_720p_settings,
> > > .data_size = ARRAY_SIZE(imx290_720p_settings),
next prev parent reply other threads:[~2022-07-21 11:54 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-21 8:35 [PATCH 00/19] media: i2c: imx290: Miscellaneous improvements Laurent Pinchart
2022-07-21 8:35 ` [PATCH 01/19] media: i2c: imx290: Use device lock for the control handler Laurent Pinchart
2022-07-21 9:22 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 02/19] media: i2c: imx290: Print error code when I2C transfer fails Laurent Pinchart
2022-07-21 9:23 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 03/19] media: i2c: imx290: Specify HMAX values in decimal Laurent Pinchart
2022-07-21 9:18 ` Alexander Stein
2022-07-21 11:31 ` Laurent Pinchart
2022-07-21 11:54 ` Alexander Stein [this message]
2022-07-21 12:04 ` Laurent Pinchart
2022-07-21 8:35 ` [PATCH 04/19] media: i2c: imx290: Replace macro with explicit ARRAY_SIZE() Laurent Pinchart
2022-07-21 9:23 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 05/19] media: i2c: imx290: Drop imx290_write_buffered_reg() Laurent Pinchart
2022-07-21 9:24 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 06/19] media: i2c: imx290: Drop regmap cache Laurent Pinchart
2022-07-21 9:27 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 07/19] media: i2c: imx290: Support variable-sized registers Laurent Pinchart
2022-07-21 9:43 ` Alexander Stein
2022-07-21 10:54 ` Laurent Pinchart
2022-07-21 11:18 ` Alexander Stein
2022-07-21 11:25 ` Laurent Pinchart
2022-07-21 11:43 ` Alexander Stein
2022-07-22 14:37 ` Sakari Ailus
2022-07-23 23:06 ` Laurent Pinchart
2022-07-25 6:49 ` Alexander Stein
2022-08-23 1:08 ` Laurent Pinchart
2022-08-23 2:51 ` Laurent Pinchart
2022-08-23 7:19 ` Alexander Stein
2022-10-16 5:36 ` Laurent Pinchart
2022-07-21 8:35 ` [PATCH 08/19] media: i2c: imx290: Correct register sizes Laurent Pinchart
2022-07-21 8:35 ` [PATCH 09/19] media: i2c: imx290: Simplify error handling when writing registers Laurent Pinchart
2022-07-21 9:50 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 10/19] media: i2c: imx290: Define more register macros Laurent Pinchart
2022-07-21 10:00 ` Alexander Stein
2022-07-21 11:08 ` Laurent Pinchart
2022-07-21 11:28 ` Alexander Stein
2022-10-16 4:27 ` Laurent Pinchart
2022-07-21 8:35 ` [PATCH 11/19] media: i2c: imx290: Add exposure time control Laurent Pinchart
2022-07-21 10:01 ` Alexander Stein
2022-07-21 15:52 ` Dave Stevenson
2022-07-21 8:35 ` [PATCH 12/19] media: i2c: imx290: Fix max gain value Laurent Pinchart
2022-07-21 10:02 ` Alexander Stein
2022-07-21 16:08 ` Dave Stevenson
2022-10-16 4:51 ` Laurent Pinchart
2022-07-21 8:35 ` [PATCH 13/19] media: i2c: imx290: Split control initialization to separate function Laurent Pinchart
2022-07-21 10:03 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 14/19] media: i2c: imx290: Implement HBLANK and VBLANK controls Laurent Pinchart
2022-07-21 10:05 ` Alexander Stein
2022-07-21 11:17 ` Laurent Pinchart
2022-07-21 11:32 ` Alexander Stein
2022-07-21 16:37 ` Dave Stevenson
2022-10-16 6:10 ` Laurent Pinchart
2022-10-17 13:46 ` Dave Stevenson
2022-07-21 8:35 ` [PATCH 15/19] media: i2c: imx290: Create controls for fwnode properties Laurent Pinchart
2022-07-21 10:06 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 16/19] media: i2c: imx290: Move registers with fixed value to init array Laurent Pinchart
2022-07-21 10:08 ` Alexander Stein
2022-07-21 10:40 ` Laurent Pinchart
2022-07-21 11:08 ` Alexander Stein
2022-07-21 16:19 ` Dave Stevenson
2022-07-22 5:53 ` Alexander Stein
2022-07-22 9:10 ` Dave Stevenson
2022-07-21 8:35 ` [PATCH 17/19] media: i2c: imx290: Factor out format retrieval to separate function Laurent Pinchart
2022-07-21 10:11 ` Alexander Stein
2022-07-21 10:36 ` Laurent Pinchart
2022-07-21 11:12 ` Alexander Stein
2022-07-21 8:35 ` [PATCH 18/19] media: i2c: imx290: Add crop selection targets support Laurent Pinchart
2022-07-21 15:39 ` Dave Stevenson
2022-10-16 5:53 ` Laurent Pinchart
2022-07-21 8:35 ` [PATCH 19/19] media: i2c: imx290: Replace GAIN control with ANALOGUE_GAIN Laurent Pinchart
2022-07-21 10:11 ` Alexander Stein
2022-08-23 1:11 ` [PATCH 00/19] media: i2c: imx290: Miscellaneous improvements Laurent Pinchart
2022-10-10 10:31 ` Dave Stevenson
2022-10-16 5:37 ` Laurent Pinchart
2022-10-16 7:34 ` Dave Stevenson
2022-10-17 18:07 ` Dave Stevenson
2022-10-18 13:43 ` Dave Stevenson
2022-10-19 10:33 ` Sakari Ailus
2022-10-19 11:38 ` Dave Stevenson
2022-10-19 13:27 ` Sakari Ailus
2023-01-14 16:03 ` Laurent Pinchart
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=3293452.QkHrqEjB74@steina-w \
--to=alexander.stein@ew.tq-group.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=mani@kernel.org \
--cc=sakari.ailus@iki.fi \
/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