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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.