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 10:47:03
Also in:
linux-devicetree, linux-media, linux-staging, lkml, phone-devel
Am Freitag, dem 16.07.2021 um 13:47 +0300 schrieb Laurent Pinchart:
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.cdiff --git a/drivers/staging/media/imx/Makefileb/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(structcsi_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(structcsi_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-
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; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel