[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240828-imx290-avail-v2-0-bd320ac8e8fa@skidata.com>
Date: Wed, 28 Aug 2024 20:13:06 +0200
From: Benjamin Bara <bbara93@...il.com>
To: Mauro Carvalho Chehab <mchehab@...nel.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: Hans de Goede <hdegoede@...hat.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Alexander Stein <alexander.stein@...tq-group.com>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
Benjamin Bara <benjamin.bara@...data.com>
Subject: [PATCH v2 0/2] media: i2c: imx290: check for availability in
probe()
Hi!
This series introduces i2c communication with the imx290 sensor during
probe s.t. the v4l2 subdev is not initialized when the chip is not
reachable.
The datasheets show that INCKSEL* registers have a different default
value after reset on imx290[1] and imx327[2], however I am not sure if
this is a sufficient identification option - therefore I just removed
the current CHIP_ID register for now.
thanks & regards
Benjamin
[1] https://static6.arrow.com/aropdfconversion/c0c7efde6571c768020a72f59b226308b9669e45/sony_imx290lqr-c_datasheet.pdf
[2] https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/IMX327LQR_2D00_C_5F00_TechnicalDatasheet_5F00_E_5F00_Rev0.2.pdf
---
Changes in v2:
- dropped 1/2 to ignore the read value in cci_read() (old 2/2 -> new 1/2)
- 1/2: read-back standby mode instead and ensure that it is really in standby
- new 2/2: drop chip_id register definition which seems to be incorrect
- Link to v1: https://lore.kernel.org/r/20240807-imx290-avail-v1-0-666c130c7601@skidata.com
---
Benjamin Bara (2):
media: i2c: imx290: Check for availability in probe()
media: i2c: imx290: Remove CHIP_ID reg definition
drivers/media/i2c/imx290.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
---
base-commit: eec5d86d5bac6b3e972eb9c1898af3c08303c52d
change-id: 20240807-imx290-avail-85795c27d988
Best regards,
--
Benjamin Bara <benjamin.bara@...data.com>
Powered by blists - more mailing lists