Message-ID: <13572841.uLZWGnKmhe@steina-w>
Date: Wed, 07 Aug 2024 14:40:56 +0200
From: Alexander Stein <alexander.stein@...tq-group.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Benjamin Bara <bbara93@...il.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, Hans de Goede <hdegoede@...hat.com>, linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, Benjamin Bara <benjamin.bara@...data.com>, arne.caspari@...imagingsource.com
Subject: Re: [PATCH 2/2] media: i2c: imx290: Check for availability in probe()

Am Mittwoch, 7. August 2024, 14:39:01 CEST schrieb Alexander Stein:
> ********************
> Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie wissen, dass diese aus einer sicheren Quelle stammen und sicher sind. Leiten Sie die E-Mail im Zweifelsfall zur Prüfung an den IT-Helpdesk weiter.
> Attention external email: Open attachments and links only if you know that they are from a secure source and are safe. In doubt forward the email to the IT-Helpdesk to check it.
> ********************
> 
> Am Mittwoch, 7. August 2024, 14:16:48 CEST schrieb Laurent Pinchart:
> > ********************
> > Achtung externe E-Mail: Öffnen Sie Anhänge und Links nur, wenn Sie wissen, dass diese aus einer sicheren Quelle stammen und sicher sind. Leiten Sie die E-Mail im Zweifelsfall zur Prüfung an den IT-Helpdesk weiter.
> > Attention external email: Open attachments and links only if you know that they are from a secure source and are safe. In doubt forward the email to the IT-Helpdesk to check it.
> > ********************
> > 
> > On Wed, Aug 07, 2024 at 02:12:04PM +0200, Alexander Stein wrote:
> > > Am Mittwoch, 7. August 2024, 13:07:24 CEST schrieb Benjamin Bara:
> > > > On Wed, 7 Aug 2024 at 11:50, Laurent Pinchart wrote:
> > > > > On Wed, Aug 07, 2024 at 10:47:39AM +0200, Benjamin Bara wrote:
> > > > > > On Wed, 7 Aug 2024 at 10:33, Alexander Stein wrote:
> > > > > > > Am Mittwoch, 7. August 2024, 10:10:28 CEST schrieb Benjamin Bara:
> > > > > > > > Currently, the V4L2 subdevice is also created when the device is not
> > > > > > > > available/connected. In this case, dmesg shows the following:
> > > > > > > >
> > > > > > > > [   10.419510] imx290 7-001a: Error writing reg 0x301c: -6
> > > > > > > > [   10.428981] imx290 7-001a: Error writing reg 0x3020: -6
> > > > > > > > [   10.442712] imx290 7-001a: Error writing reg 0x3018: -6
> > > > > > > > [   10.454018] imx290 7-001a: Error writing reg 0x3020: -6
> > > > > > > >
> > > > > > > > which seems to come from imx290_ctrl_update() after the subdev init is
> > > > > > > > finished. However, as the errors are ignored, the subdev is initialized
> > > > > > > > but simply does not work. From userspace perspective, there is no
> > > > > > > > visible difference between a working and not-working subdevice (except
> > > > > > > > when trying it out or watching for the error message).
> > > > > > > >
> > > > > > > > This commit adds a simple availability check before starting with the
> > > > > > > > subdev initialization to error out instead.
> > > > > > >
> > > > > > > There is already a patch reading the ID register at [1]. This also reads the
> > > > > > > ID register. But I don't have any documentation regarding that register,
> > > > > > > neither address nor values definitions. If there is known information about
> > > > > > > that I would prefer reading the ID and compare it to expected values.
> > > > > >
> > > > > > Thanks for the link - it seems like Laurent has dropped the patch for
> > > > > > the more recent kernel versions on their GitLab.
> > > > >
> > > > > It was a patch that I wrote as a test, and I decided not to upstream it
> > > > > as it had limited value to me. The downside with reading registers at
> > > > > probe time is that you have to power up the sensor. This can have
> > > > > undesired side effects, such as flashing a privacy LED on at boot time
> > > > > in devices that have one. There's also the increase in boot time due to
> > > > > the power up sequence, which one may want to avoid.
> > > > >
> > > > > The imx290 driver already powers up the device unconditionally at probe
> > > > > time, so reading the version register wouldn't be much of an issue I
> > > > > suppose. I would be fine merging that patch.
> > > > >
> > > > > > This was also my initial intention, but similar to you, I don't have a
> > > > > > docu describing this register, so I am not sure where the info is coming
> > > > > > from and if it really contains the identification/type info. Probably
> > > > > > Laurent has more infos on that.
> > > > >
> > > > > That's a good question. I don't see a mention of that register in the
> > > > > IMX290 datasheet I've found online
> > > > > (https://static6.arrow.com/aropdfconversion/c0c7efde6571c768020a72f59b226308b9669e45/sony_imx290lqr-c_datasheet.pdf).
> > > > > Looking at the git history, the IMX290_CHIP_ID register macro was
> > > > > introduced in an unrelated commit, without an explanation. I don't
> > > > > recall where it comes from, but I don't think I've added it randomly. It
> > > > > may have come from an out-of-tree driver.
> > > > 
> > > > Thanks for the info!
> > > > 
> > > > > I don't have an IMX290 plugged in at the moment, what's the value of the
> > > > > register ?
> > > > 
> > > > I currently have an imx462 available, which is not "officially supported" yet,
> > > > but basically an imx290 derivative. With your patch applied:
> > > > 
> > > > [   10.424187] imx290 7-001a: chip ID 0x07d0
> > > 
> > > Okay, this is from a imx327lqr:
> > > 
> > > [   15.265086] imx290 3-001a: chip ID 0x07d0
> > > 
> > > Doesn't look like an ID register to me.
> > 
> > Indeed, it's quite suspicious.
> > 
> > I wonder if we could find a more applicable register. Chip ID registers
> > are usually located at the beginning or end of the register space, we
> > could have a look there.
> 
> Dumping all registers (8-Bit reads) from 0x3001 till 0x3480 only has a few
> non-zero registers:
> > # cat /sys/kernel/debug/regmap/3-001a/range
> > 3000-3480
> > # cat /sys/kernel/debug/regmap/3-001a/registers  | grep -v ": 00"
> > 3000: 01
> > 3020: 01
> > 303c: 08
> > 303e: 38
> > 303f: 04
> > 3040: 08
> > 3042: 80
> > 3043: 07
> > 319a: d0
> > 319b: 07
> > 3418: 38
> > 3419: 04
> > 3472: 80
> > 3473: 07
> 
> Note I am on a Vision Components imx327, which might block some reads.
> Laurent is also aware of that behaviour. But maybe this list gives an
> indicator.

Ah, just for the records. I hacked the kernel to get these debugfs entries
for cci regmaps. They are not available by default.

Cheers
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Powered by blists - more mailing lists