[PATCH v1 0/2] media: i2c: mt9m114: add support for Aptina MI1040

[PATCH v1 0/2] media: i2c: mt9m114: add support for Aptina MI1040

[Svyatoslav Ryhel]

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. Add support for MI1040 into MT9M114 driver and
document it in schema.

Svyatoslav Ryhel (2):
  dt-bindings: media: mt9m114: document MI1040 sensor
  media: i2c: mt9m114: add support for Aptina MI1040

 .../bindings/media/i2c/onnn,mt9m114.yaml      |  4 ++-
 drivers/media/i2c/mt9m114.c                   | 35 +++++++++++++++----
 2 files changed, 31 insertions(+), 8 deletions(-)

-- 
2.51.0

[PATCH v1 1/2] dt-bindings: media: mt9m114: document MI1040 sensor

[Svyatoslav Ryhel]

The Aptina MI1040 is a slightly different version of the MT9M114 camera
module. It is used in several devices, such as the ASUS Nexus 7 (2012) and
the ASUS Transformer Prime TF201. The compatible "onnn,mt9m114" is placed
first in the enum, as it is considered the default compatible value.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
index a89f740214f7..7c0a50759f4d 100644
--- a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
@@ -17,7 +17,9 @@ description: |-
 
 properties:
   compatible:
-    const: onnn,mt9m114
+    enum:
+      - onnn,mt9m114
+      - aptina,mi1040
 
   reg:
     description: I2C device address
-- 
2.51.0

[PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

[Svyatoslav Ryhel]

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
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@gmail.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;
+	}
 
 	if (sensor->bus_cfg.bus_type == V4L2_MBUS_PARALLEL) {
 		/*
@@ -2207,9 +2215,11 @@ static int mt9m114_power_on(struct mt9m114 *sensor)
 	 * reaches the standby mode (either initiated manually above in
 	 * parallel mode, or automatically after reset in MIPI mode).
 	 */
-	ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);
-	if (ret < 0)
-		goto error_clock;
+	if (sensor->info->polling) {
+		ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);
+		if (ret < 0)
+			goto error_clock;
+	}
 
 	return 0;
 
@@ -2421,6 +2431,8 @@ static int mt9m114_probe(struct i2c_client *client)
 	if (ret < 0)
 		return ret;
 
+	sensor->info = of_device_get_match_data(dev);
+
 	/* Acquire clocks, GPIOs and regulators. */
 	sensor->clk = devm_v4l2_sensor_clk_get(dev, NULL);
 	if (IS_ERR(sensor->clk)) {
@@ -2539,8 +2551,17 @@ static void mt9m114_remove(struct i2c_client *client)
 	pm_runtime_set_suspended(dev);
 }
 
+static const struct mt9m114_model_info mt9m114_models_default = {
+	.polling = true,
+};
+
+static const struct mt9m114_model_info mt9m114_models_aptina = {
+	.polling = false,
+};
+
 static const struct of_device_id mt9m114_of_ids[] = {
-	{ .compatible = "onnn,mt9m114" },
+	{ .compatible = "onnn,mt9m114", .data = &mt9m114_models_default },
+	{ .compatible = "aptina,mi1040", .data = &mt9m114_models_aptina },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, mt9m114_of_ids);
-- 
2.51.0

Re: [PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

[Sakari Ailus]

Hi Svyatoslav,

Thanks for the patchset.

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@gmail.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.

>  
>  	if (sensor->bus_cfg.bus_type == V4L2_MBUS_PARALLEL) {
>  		/*
> @@ -2207,9 +2215,11 @@ static int mt9m114_power_on(struct mt9m114 *sensor)
>  	 * reaches the standby mode (either initiated manually above in
>  	 * parallel mode, or automatically after reset in MIPI mode).
>  	 */
> -	ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);
> -	if (ret < 0)
> -		goto error_clock;
> +	if (sensor->info->polling) {
> +		ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);

Ditto.

> +		if (ret < 0)
> +			goto error_clock;
> +	}
>  
>  	return 0;
>  
> @@ -2421,6 +2431,8 @@ static int mt9m114_probe(struct i2c_client *client)
>  	if (ret < 0)
>  		return ret;
>  
> +	sensor->info = of_device_get_match_data(dev);

You can use device_get_match_data() here.

> +
>  	/* Acquire clocks, GPIOs and regulators. */
>  	sensor->clk = devm_v4l2_sensor_clk_get(dev, NULL);
>  	if (IS_ERR(sensor->clk)) {
> @@ -2539,8 +2551,17 @@ static void mt9m114_remove(struct i2c_client *client)
>  	pm_runtime_set_suspended(dev);
>  }
>  
> +static const struct mt9m114_model_info mt9m114_models_default = {
> +	.polling = true,
> +};
> +
> +static const struct mt9m114_model_info mt9m114_models_aptina = {
> +	.polling = false,
> +};
> +
>  static const struct of_device_id mt9m114_of_ids[] = {
> -	{ .compatible = "onnn,mt9m114" },
> +	{ .compatible = "onnn,mt9m114", .data = &mt9m114_models_default },
> +	{ .compatible = "aptina,mi1040", .data = &mt9m114_models_aptina },
>  	{ /* sentinel */ },

The sentinel entry shouldn't have a comma. Feel free to fix that while at
it.

>  };
>  MODULE_DEVICE_TABLE(of, mt9m114_of_ids);

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

[Svyatoslav Ryhel]

пн, 26 січ. 2026 р. о 11:35 Sakari Ailus <sakari.ailus@linux.intel.com> пише:
>
> Hi Svyatoslav,
>
> Thanks for the patchset.
>
> 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@gmail.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.

> >
> >       if (sensor->bus_cfg.bus_type == V4L2_MBUS_PARALLEL) {
> >               /*
> > @@ -2207,9 +2215,11 @@ static int mt9m114_power_on(struct mt9m114 *sensor)
> >        * reaches the standby mode (either initiated manually above in
> >        * parallel mode, or automatically after reset in MIPI mode).
> >        */
> > -     ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);
> > -     if (ret < 0)
> > -             goto error_clock;
> > +     if (sensor->info->polling) {
> > +             ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);
>
> Ditto.
>
> > +             if (ret < 0)
> > +                     goto error_clock;
> > +     }
> >
> >       return 0;
> >
> > @@ -2421,6 +2431,8 @@ static int mt9m114_probe(struct i2c_client *client)
> >       if (ret < 0)
> >               return ret;
> >
> > +     sensor->info = of_device_get_match_data(dev);
>
> You can use device_get_match_data() here.
>

noted

> > +
> >       /* Acquire clocks, GPIOs and regulators. */
> >       sensor->clk = devm_v4l2_sensor_clk_get(dev, NULL);
> >       if (IS_ERR(sensor->clk)) {
> > @@ -2539,8 +2551,17 @@ static void mt9m114_remove(struct i2c_client *client)
> >       pm_runtime_set_suspended(dev);
> >  }
> >
> > +static const struct mt9m114_model_info mt9m114_models_default = {
> > +     .polling = true,
> > +};
> > +
> > +static const struct mt9m114_model_info mt9m114_models_aptina = {
> > +     .polling = false,
> > +};
> > +
> >  static const struct of_device_id mt9m114_of_ids[] = {
> > -     { .compatible = "onnn,mt9m114" },
> > +     { .compatible = "onnn,mt9m114", .data = &mt9m114_models_default },
> > +     { .compatible = "aptina,mi1040", .data = &mt9m114_models_aptina },
> >       { /* sentinel */ },
>
> The sentinel entry shouldn't have a comma. Feel free to fix that while at
> it.
>

noted

> >  };
> >  MODULE_DEVICE_TABLE(of, mt9m114_of_ids);
>
> --
> Kind regards,
>
> Sakari Ailus

Re: [PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

[Laurent Pinchart]

On Mon, Jan 26, 2026 at 11:50:05AM +0200, Svyatoslav Ryhel wrote:
> пн, 26 січ. 2026 р. о 11:35 Sakari Ailus <sakari.ailus@linux.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@gmail.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) ?

> > >
> > >       if (sensor->bus_cfg.bus_type == V4L2_MBUS_PARALLEL) {
> > >               /*
> > > @@ -2207,9 +2215,11 @@ static int mt9m114_power_on(struct mt9m114 *sensor)
> > >        * reaches the standby mode (either initiated manually above in
> > >        * parallel mode, or automatically after reset in MIPI mode).
> > >        */
> > > -     ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);
> > > -     if (ret < 0)
> > > -             goto error_clock;
> > > +     if (sensor->info->polling) {
> > > +             ret = mt9m114_poll_state(sensor, MT9M114_SYS_STATE_STANDBY);
> >
> > Ditto.
> >
> > > +             if (ret < 0)
> > > +                     goto error_clock;
> > > +     }
> > >
> > >       return 0;
> > >
> > > @@ -2421,6 +2431,8 @@ static int mt9m114_probe(struct i2c_client *client)
> > >       if (ret < 0)
> > >               return ret;
> > >
> > > +     sensor->info = of_device_get_match_data(dev);
> >
> > You can use device_get_match_data() here.
> 
> noted
> 
> > > +
> > >       /* Acquire clocks, GPIOs and regulators. */
> > >       sensor->clk = devm_v4l2_sensor_clk_get(dev, NULL);
> > >       if (IS_ERR(sensor->clk)) {
> > > @@ -2539,8 +2551,17 @@ static void mt9m114_remove(struct i2c_client *client)
> > >       pm_runtime_set_suspended(dev);
> > >  }
> > >
> > > +static const struct mt9m114_model_info mt9m114_models_default = {
> > > +     .polling = true,
> > > +};
> > > +
> > > +static const struct mt9m114_model_info mt9m114_models_aptina = {
> > > +     .polling = false,
> > > +};
> > > +
> > >  static const struct of_device_id mt9m114_of_ids[] = {
> > > -     { .compatible = "onnn,mt9m114" },
> > > +     { .compatible = "onnn,mt9m114", .data = &mt9m114_models_default },
> > > +     { .compatible = "aptina,mi1040", .data = &mt9m114_models_aptina },
> > >       { /* sentinel */ },
> >
> > The sentinel entry shouldn't have a comma. Feel free to fix that while at
> > it.
> 
> noted
> 
> > >  };
> > >  MODULE_DEVICE_TABLE(of, mt9m114_of_ids);

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

[Svyatoslav Ryhel]

пн, 26 січ. 2026 р. о 12:05 Laurent Pinchart
<laurent.pinchart@ideasonboard.com> пише:
>
> On Mon, Jan 26, 2026 at 11:50:05AM +0200, Svyatoslav Ryhel wrote:
> > пн, 26 січ. 2026 р. о 11:35 Sakari Ailus <sakari.ailus@linux.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@gmail.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.


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?

Re: [PATCH v1 1/2] dt-bindings: media: mt9m114: document MI1040 sensor

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

[Laurent Pinchart]

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@linux.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@gmail.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.

> 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 ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1 2/2] media: i2c: mt9m114: add support for Aptina MI1040

[Svyatoslav Ryhel]

ср, 28 січ. 2026 р. о 15:40 Laurent Pinchart
<laurent.pinchart@ideasonboard.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@linux.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@gmail.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