linux-kernel - [PATCH 00/16] media: i2c: GMSL reliability improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20210216173943.106475-1-jacopo+renesas@jmondi.org>
Date:   Tue, 16 Feb 2021 18:39:27 +0100
From:   Jacopo Mondi <jacopo+renesas@...ndi.org>
To:     kieran.bingham+renesas@...asonboard.com,
        laurent.pinchart+renesas@...asonboard.com,
        niklas.soderlund+renesas@...natech.se, geert@...ux-m68k.org
Cc:     Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH 00/16] media: i2c: GMSL reliability improvements

Hello,
  this series is based on the most recent media-master with the following
patch applied on top: "media: i2c: rdamc21: Fix warning on u8 cast"

The series contains multiple changes:

- patches from [1-8] contain enhancements to the existing camera module
  drivers. The first 7 patches apply to RDACM20 the same style comments
  received on RDACM21. Nothing controversial should be there.
  A cosmetic fix for the max9286 driver follows.

- patch [9/16] contains a fixup for the RDACM21 camera module that is required
  to avoid sporadic failures during the system initialization.

- From patches [10/16] a rework of the GMSL camera initialization procedure
  starts with 3 patches that prepare for the most substantial change on the
  series.

  The current initialization procedure for a GMSL chip looks like

	MAX9282				RDACM2x

	- probe()
	- init()
	- mux initialize()
		- probe camera 1	- probe()
					- init max9271
					- init image sensor/ISP
					- enable noise immunity
		...

	- camera 1 bound

		- probe camera n	- probe()
					- init max9271
					- init image sensor/ISP
					- enable noise immunity
	- camera n bound
	- all camera have probed
		- Increase channel amplitude

  This implies that all the initial configuration of the camera modules
  which requires several I2C transactions to configure the image sensor and
  the embedded ISP are run without noise immunity enabled.

  On a test of 50 boot cycle the failure rate for the RDACM21 camera module
  is around ~20% which is considerably bad.

  This series implements a different mechanism that allows to run the
  initialization of the camera module with noise immunity enabled, by splitting
  the operations between the usual probe() method and the .init() subdev
  core operation [1]

  The new procedure looks like

	MAX9282				RDACM2x

	- probe()
	- init()
	- mux initialize()
		- probe camera 1	- probe()
					- init max9271
					- enable noise immunity
	- camera 1 bound
	- increase channel amplitude
	- camera 1.init()
					- init image sensor/ISP
	- restore initial channel amplitude

		...
		- probe camera n	- probe()
					- init max9271
					- enable noise immunity
	- camera n bound
	- increase channel amplitude
	- camera n.init()
					- init image sensor/ISP
	- all camera have probed

  This allows to run the image sensor/ISP initialization with noise immunity
  enabled, as that's the part that requires the most I2C writes, being the
  components programmed with register-value tables.

  The same boot tests shows a failure percentage of 13%, considerably lower
  than the current version. It also allows to increase the I2C bit rate to the
  default 339 Kbps for which the setup/hold time are calibrated.

  Bouns points: this helps isolating the MAX9271 initialization and will make
  it easier making the max9271 a self-contained driver as suggested by Mauro.

  [1] All good and glorious BUT: all of this relies on the usage of a subdev
  operation that is considered deprecated. Is it an hard limitation ?

  GMSL is kind of different beast compared to usual subdevices, so it might
  make sense to make an exception in this case ?

Thanks
   j

Jacopo Mondi (16):
  media: i2c: rdacm20: Enable noise immunity
  media: i2c: rdacm20: Embedded 'serializer' field
  media: i2c: rdacm20: Replace goto with a loop
  media: i2c: rdacm20: Report camera module name
  media: i2c: rdacm20: Check return values
  media: i2c: rdacm20: Re-work ov10635 reset
  media: i2c: rdacm2x: Fix wake up delay
  media: i2c: max9286: Adjust parameters indent
  media: i2c: rdacm21: Re-work OV10640 initialization
  media: i2c: max9286: Rename reverse_channel_mv
  media: i2c: max9286: Cache channel amplitude
  media: i2c: max9286: Define high channel amplitude
  media: i2c: rdacm2x: Implement .init() subdev op
  media: i2c: max9286: Initialize remotes when bound
  media: i2c: max9286: Rework comments in .bound()
  media: i2c: gmsl: Use 339Kbps I2C bit-rate

 drivers/media/i2c/max9286.c |  67 ++++++++++------
 drivers/media/i2c/rdacm20.c | 153 +++++++++++++++++++-----------------
 drivers/media/i2c/rdacm21.c |  73 ++++++++++-------
 3 files changed, 167 insertions(+), 126 deletions(-)

--
2.30.0