Devicetree
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Richard Leitner <richard.leitner@linux.dev>
Cc: Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Alexander Stein <alexander.stein@ew.tq-group.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	driver-core@lists.linux.dev
Subject: Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read
Date: Wed, 22 Jul 2026 23:16:22 +0300	[thread overview]
Message-ID: <20260722201622.GD648629@killaraus.ideasonboard.com> (raw)
In-Reply-To: <amD_vkMOrtKq5NvX@bombadil>

On Wed, Jul 22, 2026 at 08:24:37PM +0200, Richard Leitner wrote:
> On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:
> > On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> > > Introduce a common regmap dt-binding schema with an optional boolean
> > > property no-sequential-read to describe hardware integrations where
> > > reading multiple consecutive registers in a single operation is not
> > > reliable and registers must be read individually.
> > 
> > > A typical case are imaging sensors used on vendor-provided camera
> > > modules whose bus integration does not support reads that advance across
> > > consecutive register addresses. In such cases, single-register reads
> > > work, but bulk reads do not. This restriction is a property of the
> > > concrete hardware integration, not of the chip itself. It therefore
> > > cannot be identified from the device driver and duplicating firmware
> > > parsing in each affected driver does not scale.
> > 
> > No, this should not be a DT property.  We should discover this through
> > the bus, just like we do currently for the various I2C quirks that are
> > advertied by the I2C subsystem.
> 
> What do you mean "discover this through the bus"? As mentioned in the
> commit message there is no possibility to detect that within the affected
> I2C device drivers.
> 
> Or do you mean that it should be "discovered" by modelling the MCU which
> "proxies" the I2C traffic between the host and the sensor/device as some
> kind of "parent" device of the sensor?

Mark's comment wasn't totally clear to me. I think this is what he
meant.

Richard, do you know if the MCU (which is actually an FPGA if I'm not
mistaken) intercepts the I2C signals (i.e. is interposed between the
host and the image sensor), or is "just" connected on the same I2C bus
and messes up the I2C transfer when it detects a condition it dislikes
(for instance by pulling the SDA line down when it detects a read from a
protected register) ?

> Or something other?
> 
> Sorry, if I don't get it, but currently I see no other option than
> providing this information somehow via device-tree. No matter if it's in
> regmap or I2C.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2026-07-22 20:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22  8:42 [PATCH RFC 0/2] regmap: support firmware-described non-sequential register reads Richard Leitner
2026-07-22  8:42 ` [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read Richard Leitner
2026-07-22  8:49   ` sashiko-bot
2026-07-22 13:59   ` Mark Brown
2026-07-22 18:24     ` Richard Leitner
2026-07-22 20:16       ` Laurent Pinchart [this message]
2026-07-22 21:58         ` Richard Leitner
2026-07-22 22:03           ` Mark Brown
2026-07-22 20:20       ` Mark Brown
2026-07-22  8:42 ` [PATCH RFC 2/2] regmap: implement no-sequential-read firmware property Richard Leitner

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=20260722201622.GD648629@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=dakr@kernel.org \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=devicetree@vger.kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=richard.leitner@linux.dev \
    --cc=robh@kernel.org \
    /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