public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
To: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Frank Li <Frank.Li@nxp.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Martin Kepplinger-Novakovic <martink@posteo.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil@kernel.org>,
	Pengyu Luo <mitltlatltl@gmail.com>
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	Pengyu Luo <mitltlatltl@gmail.com>
Subject: Re: [PATCH v2 3/4] media: hi846: Add 6MP and 8MP modes support
Date: Wed, 06 May 2026 14:51:08 +0200	[thread overview]
Message-ID: <OmTXoHZJTSGePymL9I-1Cw@puri.sm> (raw)
In-Reply-To: <20260501095433.1609309-4-mitltlatltl@gmail.com>

On piątek, 1 maja 2026 11:54:32 czas środkowoeuropejski letni Pengyu Luo 
wrote:
> Hi846 is an 8MP sensor, but the upstream driver has only supported 2MP
> mode for years. This patch adds 6MP and 8MP modes to maximize sensor
> utilization.
> 
> Note that these modes require 4-lane MIPI CSI-2, as the downstream
> driver only exposes 2MP, 6MP, and 8MP configurations in 4-lane
> operation on the target device. The register sequences are extracted
> from the downstream Windows driver.

Has this been tested in this form at all? I tried, failed and looking at the 
driver I don't see how could it ever end up using these modes in its current 
state. It can only cause troubles when used with 2 lanes, while 4 lanes are 
completely broken.

The driver defaults to its first supported mode, which happens to be a 640x480 
mode that only defines its register list for 2 lanes. hi846_set_format was 
supposedly meant to check whether the mode returned by v4l2_find_nearest_size 
is compatible with the used lane count, but it does so too early - it actually 
checks it against the already set mode rather than the one it's about to set. 
This means that you're never going to be able to set any valid mode when using 
4 lanes without fixing this first.

And even if this was fixed, with 2 lanes this makes some calls from userspace 
that previously succeeded now fail when v4l2_find_nearest_size happens to match 
a mode that's only supported with 4 lanes. v4l2_find_nearest_size would have to 
be fed with already filtered list of modes to fix that (which would actually 
make the check mentioned above unnecessary).

Of course these are preexisting issues in the driver, but they make it 
impossible to actually use what's being added in this patch and to add these 
modes without causing regressions. So far these didn't matter as this driver 
was only ever used with 2 lanes, but they have to be fixed first before adding 
any actual 4 lane usage or modes that require 4 lanes.

S.



  reply	other threads:[~2026-05-06 12:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-01  9:54 [PATCH v2 0/4] fix and improve for Hi846 Pengyu Luo
2026-05-01  9:54 ` [PATCH v2 1/4] media: hi846: fix hi846_write_reg_16 handling Pengyu Luo
2026-05-01  9:54 ` [PATCH v2 2/4] media: hi846: fix link frequency handling Pengyu Luo
2026-05-01  9:54 ` [PATCH v2 3/4] media: hi846: Add 6MP and 8MP modes support Pengyu Luo
2026-05-06 12:51   ` Sebastian Krzyszkowiak [this message]
2026-05-06 14:01     ` Pengyu Luo
2026-05-01  9:54 ` [PATCH v2 4/4] arm64: dts: imx8mq-librem5: Correct link frequency list Pengyu Luo

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=OmTXoHZJTSGePymL9I-1Cw@puri.sm \
    --to=sebastian.krzyszkowiak@puri.sm \
    --cc=Frank.Li@nxp.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=hverkuil@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=martink@posteo.de \
    --cc=mchehab@kernel.org \
    --cc=mitltlatltl@gmail.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=sakari.ailus@linux.intel.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