Message-ID: <CAPVz0n17H5vhWZm9WyamjoRcO1J8H9O35Y2GReOT1kCrAaymqA@mail.gmail.com>
Date: Wed, 28 Jan 2026 16:56:08 +0200
From: Svyatoslav Ryhel <clamor95@...il.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>, 
	Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-media@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

ср, 28 січ. 2026 р. о 15:40 Laurent Pinchart
<laurent.pinchart@...asonboard.com> пише:
>
> On Mon, Jan 26, 2026 at 01:50:13PM +0200, Svyatoslav Ryhel wrote:
> > пн, 26 січ. 2026 р. о 12:05 Laurent Pinchart name:
> > > On Mon, Jan 26, 2026 at 11:50:05AM +0200, Svyatoslav Ryhel wrote:
> > > > пн, 26 січ. 2026 р. о 11:35 Sakari Ailus <sakari.ailus@...ux.intel.com> пише:
> > > > > On Mon, Jan 26, 2026 at 10:34:30AM +0200, Svyatoslav Ryhel wrote:
> > > > > > Slightly different version of MT9M114 camera module is used in a several
> > > > > > devices like ASUS Nexus 7 (2012) or ASUS Transformer Prime TF201 and is
> > > > > > called Aptina MI1040. Only difference found so far is lacking ability to
> > > > >
> > > > > s/Only/The only/
> > > > >
> > > > > > poll STATUS and COMMAND registers during power on sequence, which causes
> > > > > > driver to fail with time out error. Add polling flag to diverge models and
> > > > > > address quirk found in MI1040.
> > > > > >
> > > > > > Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
> > > > > > ---
> > > > > >  drivers/media/i2c/mt9m114.c | 35 ++++++++++++++++++++++++++++-------
> > > > > >  1 file changed, 28 insertions(+), 7 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c
> > > > > > index 4ec033c0ee84..d96a57ebcad4 100644
> > > > > > --- a/drivers/media/i2c/mt9m114.c
> > > > > > +++ b/drivers/media/i2c/mt9m114.c
> > > > > > @@ -368,6 +368,10 @@ enum {
> > > > > >   * Data Structures
> > > > > >   */
> > > > > >
> > > > > > +struct mt9m114_model_info {
> > > > > > +     bool polling;
> > > > > > +};
> > > > > > +
> > > > > >  enum mt9m114_format_flag {
> > > > > >       MT9M114_FMT_FLAG_PARALLEL = BIT(0),
> > > > > >       MT9M114_FMT_FLAG_CSI2 = BIT(1),
> > > > > > @@ -421,6 +425,8 @@ struct mt9m114 {
> > > > > >
> > > > > >               struct v4l2_ctrl *tpg[4];
> > > > > >       } ifp;
> > > > > > +
> > > > > > +     const struct mt9m114_model_info *info;
> > > > > >  };
> > > > > >
> > > > > >  /* -----------------------------------------------------------------------------
> > > > > > @@ -2186,9 +2192,11 @@ static int mt9m114_power_on(struct mt9m114 *sensor)
> > > > > >        */
> > > > > >       usleep_range(44500, 50000);
> > > > > >
> > > > > > -     ret = mt9m114_poll_command(sensor, MT9M114_COMMAND_REGISTER_SET_STATE);
> > > > > > -     if (ret < 0)
> > > > > > -             goto error_clock;
> > > > > > +     if (sensor->info->polling) {
> > > > > > +             ret = mt9m114_poll_command(sensor, MT9M114_COMMAND_REGISTER_SET_STATE);
> > > > > > +             if (ret < 0)
> > > > > > +                     goto error_clock;
> > > > > > +     }
> > > > >
> > > > > What does the datasheet say, is there a need to do something else instead?
> > > > > As the polling is there to ensure firmware has done its job, the need
> > > > > appears to still be there.
> > > >
> > > > MI1040 has no datasheet available and downstream code does not do this
> > > > polling. I have tested on Nexus 7 which has this camera and it seems
> > > > to be fully operational without this poling, but as soon it is enabled
> > > > camera fails will timeout. I suspect that this camera version has some
> > > > quirk regarding early access, but I cannot back it up by any
> > > > documentation or additional data.
> > > >
> > > > I have a device with proper version of mt9m114 too and it works with
> > > > his driver without any major issues.
> > >
> > > Does the device reply to reads of the MT9M114_COMMAND_REGISTER register
> > > but never shows the MT9M114_COMMAND_REGISTER_SET_STATE bit being set, or
> > > does it not reply to reads at all (timeouts on the I2C bus) ?
> >
> > I have re-run check on Nexus 7 and TF201 which both have mi1040 cam.
> >
> > From data I have got:
> >
> > "mt9m114_poll_command(sensor, MT9M114_COMMAND_REGISTER_SET_STATE);"
> >
> > passes fine, which is good. Previous time if failed with Timeout
> > waiting for state and -ETIMEDOUT. But
> >
> > "mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);"
> >
> > still gives:
> >
> > [    2.921791] mt9m114 2-0048: Timeout waiting for state 0x52
> > [    2.922777] mt9m114 2-0048: error -ETIMEDOUT: Could not power on the device
> >
> > commenting mt9m114_poll_state made camera work, I was able to take pictures.
> >
> > If you have any suggestions for testing, let me know.
>
> Does increasing the timeout help ? I'm wondering if this patch could
> just work by luck, with the sensor no being ready quickly enough for the
> timeout used by mt9m114_poll_command(), but hvaing time to get ready
> after power on because the driver doesn't start streaming immediately.
>

No, increasing polling duration x10 and x100 results in the same issue
as if not touching it at all

[   26.613606] mt9m114 2-0048: Timeout waiting for state 0x52
[   26.614702] mt9m114 2-0048: error -ETIMEDOUT: Could not power on the device

> > Additionally, not related to this patch but to mt9m114 device tree
> > reflection. The MT9M114 driver exposes the IFP device's sink pad
> > first, which causes issues for external devices that rely on the OF
> > graph to get the correct pad information. Laurent, may you consider
> > swapping sink and source pads of IFP so that source pad is set first
> > and correspond to device tree port or at least if you and media
> > subsystem maintainers are fine with such change?
>
> That risks breaking existing userspace applications.
>
> The issue may be that the IFP entity doesn't implement the
> .get_fwnode_pad() operation. You will also need to make sure that the
> downstream driver calls media_entity_get_fwnode_pad() instead of
> assuming the pad number to be 0. Could you give that a try ?
>

No, and I am not the only one having issues with this driver

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/staging/media/atomisp/pci/atomisp_v4l2.c?h=next-20260127#n1022

> --
> Regards,
>
> Laurent Pinchart

Powered by blists - more mailing lists