From: Sakari Ailus <sakari.ailus@iki.fi>
To: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-staging@lists.linux.dev, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v2 2/2] media: staging: max96712: Add support for MAX96724
Date: Tue, 27 Aug 2024 13:32:43 +0000 [thread overview]
Message-ID: <Zs3Vey0NEdGJAyTE@valkosipuli.retiisi.eu> (raw)
In-Reply-To: <20240827131841.629920-3-niklas.soderlund+renesas@ragnatech.se>
Hejssan,
Tack för lappan!
On Tue, Aug 27, 2024 at 03:18:41PM +0200, Niklas Söderlund wrote:
> The MAX96724 is almost identical to the MAX96712 and can be supported by
> the same driver, add support for it.
>
> For the staging driver which only supports patter generation the big
> difference is that the datasheet (rev 4) for MAX96724 do not describe
> the DEBUG_EXTRA register, which is at offset 0x0009 on MAX96712. It's
> not clear if this register is removed or moved to a different offset.
> What is known is writing to register 0x0009 have no effect on MAX96724.
>
> This makes it impossible to increase the test pattern clock frequency
> from 25 MHz to 75Mhz on MAX96724. To be able to get a stable test
> pattern the DPLL frequency have to be increase instead to compensate for
> this. The frequency selected is found by experimentation as the MAX96724
> datasheet is much sparser then what's available for MAX96712.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> * Changes since v1
> - Group in series together with binding.
> ---
> drivers/staging/media/max96712/max96712.c | 26 ++++++++++++++++++-----
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/media/max96712/max96712.c b/drivers/staging/media/max96712/max96712.c
> index 6bdbccbee05a..6bd02276c413 100644
> --- a/drivers/staging/media/max96712/max96712.c
> +++ b/drivers/staging/media/max96712/max96712.c
> @@ -17,8 +17,10 @@
> #include <media/v4l2-subdev.h>
>
> #define MAX96712_ID 0x20
> +#define MAX96724_ID 0xA7
>
> #define MAX96712_DPLL_FREQ 1000
> +#define MAX96724_DPLL_FREQ 1200
>
> enum max96712_pattern {
> MAX96712_PATTERN_CHECKERBOARD = 0,
> @@ -31,6 +33,7 @@ struct max96712_priv {
> struct gpio_desc *gpiod_pwdn;
>
> bool cphy;
> + bool max96724;
> struct v4l2_mbus_config_mipi_csi2 mipi;
>
> struct v4l2_subdev sd;
> @@ -120,6 +123,7 @@ static void max96712_mipi_enable(struct max96712_priv *priv, bool enable)
>
> static void max96712_mipi_configure(struct max96712_priv *priv)
> {
> + unsigned int dpll_freq;
> unsigned int i;
> u8 phy5 = 0;
>
> @@ -152,10 +156,11 @@ static void max96712_mipi_configure(struct max96712_priv *priv)
> max96712_write(priv, 0x8a5, phy5);
>
> /* Set link frequency for PHY0 and PHY1. */
> + dpll_freq = priv->max96724 ? MAX96724_DPLL_FREQ : MAX96712_DPLL_FREQ;
> max96712_update_bits(priv, 0x415, 0x3f,
> - ((MAX96712_DPLL_FREQ / 100) & 0x1f) | BIT(5));
> + ((dpll_freq / 100) & 0x1f) | BIT(5));
> max96712_update_bits(priv, 0x418, 0x3f,
> - ((MAX96712_DPLL_FREQ / 100) & 0x1f) | BIT(5));
> + ((dpll_freq / 100) & 0x1f) | BIT(5));
>
> /* Enable PHY0 and PHY1 */
> max96712_update_bits(priv, 0x8a2, 0xf0, 0x30);
> @@ -181,7 +186,8 @@ static void max96712_pattern_enable(struct max96712_priv *priv, bool enable)
> }
>
> /* PCLK 75MHz. */
> - max96712_write(priv, 0x0009, 0x01);
> + if (!priv->max96724)
> + max96712_write(priv, 0x0009, 0x01);
It'd be nice to have a macro for this, espeically now that the driver
supports more than one chip.
>
> /* Configure Video Timing Generator for 1920x1080 @ 30 fps. */
> max96712_write_bulk_value(priv, 0x1052, 0, 3);
> @@ -303,6 +309,7 @@ static const struct v4l2_ctrl_ops max96712_ctrl_ops = {
>
> static int max96712_v4l2_register(struct max96712_priv *priv)
> {
> + unsigned int dpll_freq;
> long pixel_rate;
> int ret;
>
> @@ -317,7 +324,8 @@ static int max96712_v4l2_register(struct max96712_priv *priv)
> * TODO: Once V4L2_CID_LINK_FREQ is changed from a menu control to an
> * INT64 control it should be used here instead of V4L2_CID_PIXEL_RATE.
> */
> - pixel_rate = MAX96712_DPLL_FREQ / priv->mipi.num_data_lanes * 1000000;
> + dpll_freq = priv->max96724 ? MAX96724_DPLL_FREQ : MAX96712_DPLL_FREQ;
> + pixel_rate = dpll_freq / priv->mipi.num_data_lanes * 1000000;
> v4l2_ctrl_new_std(&priv->ctrl_handler, NULL, V4L2_CID_PIXEL_RATE,
> pixel_rate, pixel_rate, 1, pixel_rate);
>
> @@ -438,8 +446,15 @@ static int max96712_probe(struct i2c_client *client)
> if (priv->gpiod_pwdn)
> usleep_range(4000, 5000);
>
> - if (max96712_read(priv, 0x4a) != MAX96712_ID)
> + switch (max96712_read(priv, 0x4a)) {
> + case MAX96712_ID:
> + break;
> + case MAX96724_ID:
> + priv->max96724 = true;
> + break;
> + default:
> return -ENODEV;
> + }
>
> max96712_reset(priv);
>
> @@ -463,6 +478,7 @@ static void max96712_remove(struct i2c_client *client)
>
> static const struct of_device_id max96712_of_table[] = {
> { .compatible = "maxim,max96712" },
> + { .compatible = "maxim,max96724" },
How about adding compatible specific data to convey the model, instead of a
switch? See e.g. drivers/media/i2c/ccs/ccs-core.c for an example.
You could store the DPLL frequency there, too.
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, max96712_of_table);
>
--
Trevliga hälsningar,
Sakari Ailus
next prev parent reply other threads:[~2024-08-27 13:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 13:18 [PATCH v2 0/2] media: staging: max96712: Add support for MAX96724 Niklas Söderlund
2024-08-27 13:18 ` [PATCH v2 1/2] dt-bindings: i2c: maxim,max96712: Add compatible " Niklas Söderlund
2024-08-27 14:53 ` Krzysztof Kozlowski
2024-08-27 18:03 ` Niklas Söderlund
2024-08-28 5:45 ` Krzysztof Kozlowski
2024-08-27 13:18 ` [PATCH v2 2/2] media: staging: max96712: Add support " Niklas Söderlund
2024-08-27 13:32 ` Sakari Ailus [this message]
2024-08-27 17:57 ` Niklas Söderlund
2024-08-27 21:00 ` Sakari Ailus
2024-08-27 13:55 ` Tommaso Merciai
2024-08-28 10:02 ` Julien Massot
2024-09-04 12:45 ` Tommaso Merciai
2024-08-27 18:21 ` Dan Carpenter
2024-08-28 5:51 ` Biju Das
2024-08-28 9:41 ` Julien Massot
2024-08-28 10:00 ` Niklas Söderlund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zs3Vey0NEdGJAyTE@valkosipuli.retiisi.eu \
--to=sakari.ailus@iki.fi \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzk+dt@kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox