Thread (16 messages) 16 messages, 3 authors, 2021-07-19

Re: [PATCH v6 2/3] media: imx: add a driver for i.MX8MQ mipi csi rx phy and controller

From: Martin Kepplinger <hidden>
Date: 2021-07-19 14:21:35
Also in: linux-devicetree, linux-media, linux-staging, lkml, phone-devel

Am Montag, dem 19.07.2021 um 12:46 +0200 schrieb Martin Kepplinger:
quoted hunk ↗ jump to hunk
Am Freitag, dem 16.07.2021 um 13:47 +0300 schrieb Laurent Pinchart:
quoted
Hi Martin,

On Fri, Jul 16, 2021 at 10:47:14AM +0200, Martin Kepplinger wrote:
quoted
Am Freitag, dem 16.07.2021 um 00:52 +0300 schrieb Laurent
Pinchart:
quoted
On Thu, Jul 15, 2021 at 09:37:24AM +0200, Martin Kepplinger
wrote:
quoted
Am Mittwoch, dem 14.07.2021 um 21:24 +0300 schrieb Laurent
Pinchart:
quoted
On Wed, Jul 14, 2021 at 01:19:30PM +0200, Martin Kepplinger
wrote:
quoted
Add a driver to support the i.MX8MQ MIPI CSI receiver.
The
hardware side
is based on
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/media/platform/imx8/mxc-mipi-csi2_yav.c?h=imx_5.4.70_2.3.0

It's built as part of VIDEO_IMX7_CSI because that's
documented to support
i.MX8M platforms. This driver adds i.MX8MQ support where
currently only the
i.MX8MM platform has been supported.

Signed-off-by: Martin Kepplinger
[off-list ref]
---
 drivers/staging/media/imx/Makefile           |   1 +
 drivers/staging/media/imx/imx8mq-mipi-csi2.c | 949
+++++++++++++++++++
 2 files changed, 950 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx8mq-
mipi-
csi2.c
diff --git a/drivers/staging/media/imx/Makefile
b/drivers/staging/media/imx/Makefile
index 6ac33275cc97..19c2fc54d424 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-
mipi-
csi2.o
[snip]
quoted
quoted
quoted
+static int imx8mq_mipi_csi_calc_hs_settle(struct
csi_state
*state)
+{
+       u32 width = state-
quoted
format_mbus[MIPI_CSI2_PAD_SINK].width;
+       u32 height = state-
quoted
format_mbus[MIPI_CSI2_PAD_SINK].height;
+       s64 link_freq;
+       u32 lane_rate;
+
+       /* Calculate the line rate from the pixel rate.
*/
+       link_freq = v4l2_get_link_freq(state->src_sd-
quoted
ctrl_handler,
+                                      state->csi2_fmt-
quoted
width,
+                                      state-
quoted
bus.num_data_lanes * 2);
+       if (link_freq < 0) {
+               dev_err(state->dev, "Unable to obtain
link
frequency: %d\n",
+                       (int)link_freq);
+               return link_freq;
+       }
+
+       lane_rate = link_freq * 2;
+       if (lane_rate < 80000000 || lane_rate >
1500000000)
{
+               dev_dbg(state->dev, "Out-of-bound lane
rate
%u\n", lane_rate);
+               return -EINVAL;
+       }
+
+       /*
https://community.nxp.com/t5/i-MX-Processors/Explenation-for-HS-SETTLE-parameter-in-MIPI-CSI-D-PHY-registers/m-p/764275/highlight/true#M118744
 */
+       if (lane_rate < 250000000)
+               state->hs_settle = 0xb;
+       else if (lane_rate < 500000000)
+               state->hs_settle = 0x8;
+       else
+               state->hs_settle = 0x6;
We could possibly compute this value based on the formula
from the table
in that page, but maybe that's overkill ? If you want to
give
it a try,
it would be along those lines.

        /*
         * The D-PHY specification requires Ths-settle to
be
in the range
         * 85ns + 6*UI to 140ns + 10*UI, with the unit
interval UI being half
         * the clock period.
         *
         * The Ths-settle value is expressed in the
hardware
as a multiple of
         * the Esc clock period:
         *
         * Ths-settle = (PRG_RXHS_SETTLE + 1) * Tperiod of
RxClkInEsc
         *
         * Due to the one cycle inaccuracy introduced by
rounding, the
         * documentation recommends picking a value away
from
the boundaries.
         * Let's pick the average.
         */
        esc_clk_rate = clk_get_rate(...);

        min_ths_settle = 85 + 6 * 1000000 / (lane_rate /
1000);
        max_ths_settle = 140 + 10 * 1000000 / (lane_rate /
1000);
        ths_settle = (min_ths_settle + max_ths_settle) / 2;

        state->hs_settle = ths_settle * esc_clk_rate /
1000000000 - 1;
I experimented a bit but would like to leave this as a task
for
later
if that's ok. it's correct and simple now. also, using
clks[i].clk
based on the name string would feel better to submit
seperately
later.
That's OK with me, but I may then submit a patch on top fairly
soon :-)
Have you been able to test if this code works on your device ?
The main
reason why I think it's better is that it doesn't hardcode a
specific
escape clock frequency assumption, so it should be able to
accommodate a
wider range of use cases. If we change it later, there's always
a
risk
of regressions, while if we do this from the start, we'll
figure
out
quickly if it doesn't work in some cases.
taking your code basically as-is doesn't yet work, but it helps a
bit.
Thanks for testing.
quoted
tbh I don't even know how to correctly read that table /
calculation:
what is the exact relation of the calculated Ths_settle time
inverval
to the hs_settle register bits?
The PRG_RXHS_SETTLE field stores a number of timer ticks to cover
the
Ths-settle internal. The D-PHY arms the timer when it detects the
transition to LP-00, and ignores transitions on the lane until the
timer
expires. The timer is clocked by the escape clock.

What hs_settle value do you currently use, and what value does my
code
produce ?
quoted
if the 2 of us can't quickly figure it out I can ask NXP via that
community forum issue and I created
https://source.puri.sm/Librem5/linux-next/-/issues/340 so I won't
forget about it.
hi Laurent,

the below patch for hs_settle works (and calculates either the same
or
+/- 1 for the hs_settle value, compared to the table), but getting
the
esc clock looks really scary how I do it: how would you do that?

@@ -284,6 +285,9 @@ static int imx8mq_mipi_csi_calc_hs_settle(struct
csi_state *state)
 {
        s64 link_freq;
        u32 lane_rate;
+       u32 esc_clk_rate = 0;
+       u32 i, min_ths_settle, max_ths_settle, ths_settle_ns,
esc_clk_period_ns;
+       char *p;
 
        /* Calculate the line rate from the pixel rate. */
        link_freq = v4l2_get_link_freq(state->src_sd->ctrl_handler,
@@ -302,20 +306,44 @@ static int
imx8mq_mipi_csi_calc_hs_settle(struct
csi_state *state)
        }
 
        /*
-        * The following table is the source for this:
-        *
https://community.nxp.com/t5/i-MX-Processors/Explenation-for-HS-SETTLE-parameter-in-MIPI-CSI-D-PHY-registers/m-p/764275/highlight/true#M118744
-        * but it would be even better to calculate the value for any
-        * given datarate.
+        * The D-PHY specification requires Ths-settle to be in the
range
+        * 85ns + 6*UI to 140ns + 10*UI, with the unit interval UI
being half
+        * the clock period.
+        *
+        * The Ths-settle value is expressed in the hardware as a
multiple of
+        * the Esc clock period:
+        *
+        * Ths-settle = (PRG_RXHS_SETTLE + 1) * Tperiod of RxClkInEsc
+        *
+        * Due to the one cycle inaccuracy introduced by rounding,
the
+        * documentation recommends picking a value away from the
boundaries.
+        * Let's pick the average.
         */
-       if (lane_rate < 250000000)
-               state->hs_settle = 0xb;
-       else if (lane_rate < 500000000)
-               state->hs_settle = 0x8;
-       else
-               state->hs_settle = 0x6;
-
-       dev_dbg(state->dev, "start stream: lane rate %u hs_settle
%u\n",
-               lane_rate, state->hs_settle);
+       for (i = 0; i < CSI2_NUM_CLKS; i++) {
+               p = (char *)__clk_get_name(state->clks[i].clk);
+               /* we're getting csi1_esc here */
+               if (strlen(p) > 7)
+                       p += 5;
+
+               dev_dbg(state->dev, "comparing: %s to esc\n", p);
+               if (!strcmp(p, "esc"))
+                       esc_clk_rate = clk_get_rate(state-
quoted
clks[i].clk);
+       }
+
+       if (!esc_clk_rate)
+               dev_err(state->dev, "Could not get esc clock
rate\n");
+
+       dev_dbg(state->dev, "esc clk rate: %u\n", esc_clk_rate);
+       esc_clk_period_ns = 1000000000 / esc_clk_rate;
+
+       min_ths_settle = 85 + 6 * 1000000 / (lane_rate / 1000);
+       max_ths_settle = 140 + 10 * 1000000 / (lane_rate / 1000);
+       ths_settle_ns = (min_ths_settle + max_ths_settle) / 2;
+
+       state->hs_settle = ths_settle_ns / esc_clk_period_ns - 1;
+
+       dev_dbg(state->dev, "lane rate %u Ths_settle %u hs_settle
%u\n",
+               lane_rate, ths_settle_ns, state->hs_settle);
 
        return 0;
the below code works too and looks better to me. Other drivers do it
similarly when looking for a clock:


	for (i = 0; i < CSI2_NUM_CLKS; i++) {
		p = (char *)__clk_get_name(state->clks[i].clk);

		dev_dbg(state->dev, "looking for esc clock: %s\n", p);

		if (!strcmp(p, "esc") || !strcmp(p, "csi1_esc") ||
		    !strcmp(p, "csi2_esc"))
			esc_clk_rate = clk_get_rate(state-
clks[i].clk);
	}

	if (!esc_clk_rate) {
		dev_err(state->dev, "Could not find esc clock.\n");
		return -EINVAL;
	}

	dev_dbg(state->dev, "esc clk rate: %u\n", esc_clk_rate);
	esc_clk_period_ns = 1000000000 / esc_clk_rate;

	min_ths_settle = 85 + 6 * 1000000 / (lane_rate / 1000);
	max_ths_settle = 140 + 10 * 1000000 / (lane_rate / 1000);
	ths_settle_ns = (min_ths_settle + max_ths_settle) / 2;

	state->hs_settle = ths_settle_ns / esc_clk_period_ns - 1;


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help