| Message ID | 20200410071723.19720-1-louis.kuo@mediatek.com |
|---|---|
| Headers | show |
| Series | media: support Mediatek sensor interface driver | expand |
Hi, Chun-Kuang: l had took mipi csi dphy part as a phy device and upstream RFC patch V7. Please kindly review it. BRs Louis -----Original Message----- From: Chun-Kuang Hu [mailto:chunkuang.hu@kernel.org] Sent: Sunday, June 21, 2020 11:41 PM To: Louis Kuo (郭德寧) Cc: Chun-Kuang Hu; hans.verkuil@cisco.com; laurent.pinchart+renesas@ideasonboard.com; tfiga@chromium.org; keiichiw@chromium.org; Matthias Brugger; Mauro Carvalho Chehab; devicetree@vger.kernel.org; Sean Cheng (鄭昇弘); srv_heupstream; Jerry-ch Chen (陳敬憲); Jungo Lin (林明俊); Sj Huang (黃信璋); yuzhao@chromium.org; moderated list:ARM/Mediatek SoC support; zwisler@chromium.org; Christie Yu (游雅惠); Frederic Chen (陳俊元); Linux ARM; linux-media@vger.kernel.org Subject: Re: [RFC PATCH V6 1/3] media: platform: mtk-isp: Add Mediatek sensor interface driver Hi, Louis: Louis Kuo (郭德寧) <louis.kuo@mediatek.com> 於 2020年6月21日 週日 下午3:41寫道： > > Hi Chun-Kuang, > > From phy doc, phy framework is only used to devices that use "external PHY". > > But for MTK MT8183, all the modules, include mipi csi dphy(in sensor > interface module), image processor, video codec, modem, etc., are embedded in one chip. > > Namely, for MT8183, PHY functionality is embedded within controller, > so I think it's not suitable to regard MTK MTK8183 mipi csi dphy as an independent phy device. > > What is your advice? You think this SoC is only one device which has multiple functions including csi dphy, image processor, video codec, etc., but I don't think we should treat this SoC is just one device. In device tree, we have define many devices in this SoC. We may have a sensor interface device (the phy controller) and csi dphy device (the phy provider). I think the register defined in mtk_seninf_rx_reg.h is controlled by csi dphy device. Is it only about phy? If so, I think phy is independent and not embedded. If not, please explain what's the other function in mtk_seninf_rx_reg.h. Regards, Chun-Kuang. > > ========================= > | MT8183 phone SOC | > | ================= | > | | MTK sensor | | > | | interface module | | > | | Internal PHY | | > | ================= | > ========================= > ^ ^ ^ ^ > | | | | > =========== > | sensor | > =========== > > In https://www.kernel.org/doc/Documentation/phy.txt > This framework will be of use only to devices that use external PHY > (PHY functionality is not embedded within the controller). > > > BRs > Louis > > > > > -----Original Message----- > From: Louis Kuo (郭德寧) > Sent: Monday, April 13, 2020 9:40 PM > To: Chun-Kuang Hu > Cc: hans.verkuil@cisco.com; laurent.pinchart+renesas@ideasonboard.com; > tfiga@chromium.org; keiichiw@chromium.org; Matthias Brugger; Mauro > Carvalho Chehab; devicetree@vger.kernel.org; Sean Cheng (鄭昇弘); > srv_heupstream; Jerry-ch Chen (陳敬憲); Jungo Lin (林明俊); Sj Huang (黃信璋); > yuzhao@chromium.org; moderated list:ARM/Mediatek SoC support; > zwisler@chromium.org; Christie Yu (游雅惠); Frederic Chen (陳俊元); Linux > ARM; linux-media@vger.kernel.org > Subject: RE: [RFC PATCH V6 1/3] media: platform: mtk-isp: Add Mediatek > sensor interface driver > > Hi Chun-Kuang, > > You wrote: > > I think the phy control part should be placed in drivers/phy/mediatek/. In [1], device csis point to a device mipi_phy. > > csis' driver is in [2], and mipi_phy's driver is in [3] > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t > > re > > e/arch/arm/boot/dts/exynos4.dtsi?h=v5.6 > > [2] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t > > re > > e/drivers/media/platform/exynos4-is/mipi-csis.c?h=v5.6 > > [3] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t > > re > > e/drivers/phy/samsung/phy-exynos-mipi-video.c?h=v5.6 > > I understood your suggestion to let mipi-csi phy control part as a phy device and use devm_phy_get/phy_configure/phy_power_on/phy_power_off phy API to control it. > > I will try to revise it if feasible. > > BRs > Louis > > > -----Original Message----- > From: Chun-Kuang Hu [mailto:chunkuang.hu@kernel.org] > Sent: Monday, April 13, 2020 5:27 PM > To: Louis Kuo (郭德寧) <louis.kuo@mediatek.com> > Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>; hans.verkuil@cisco.com; > laurent.pinchart+renesas@ideasonboard.com; tfiga@chromium.org; > keiichiw@chromium.org; Matthias Brugger <matthias.bgg@gmail.com>; > Mauro Carvalho Chehab <mchehab@kernel.org>; > devicetree@vger.kernel.org; Sean Cheng (鄭昇弘) > <Sean.Cheng@mediatek.com>; srv_heupstream > <srv_heupstream@mediatek.com>; Jerry-ch Chen (陳敬憲) > <Jerry-ch.Chen@mediatek.com>; Jungo Lin (林明俊) > <jungo.lin@mediatek.com>; Sj Huang (黃信璋) <sj.huang@mediatek.com>; > yuzhao@chromium.org; moderated list:ARM/Mediatek SoC support > <linux-mediatek@lists.infradead.org>; zwisler@chromium.org; Christie > Yu (游雅惠) <christie.yu@mediatek.com>; Frederic Chen (陳俊元) > <Frederic.Chen@mediatek.com>; Linux ARM > <linux-arm-kernel@lists.infradead.org>; linux-media@vger.kernel.org > Subject: Re: [RFC PATCH V6 1/3] media: platform: mtk-isp: Add Mediatek > sensor interface driver > > Hi, Louis: > > Louis Kuo (郭德寧) <louis.kuo@mediatek.com> 於 2020年4月13日 週一 上午10:04寫道： > > > > Hi Chun-Kuang, > > > > The comment you mentioned, > > I think the phy control part should be placed in drivers/phy/mediatek/. In [1], device csis point to a device mipi_phy. > > csis' driver is in [2], and mipi_phy's driver is in [3] > > > > I reply as below, > > => > > Since Seninf module includes mipi-csi phy, top mux, mux ctrl parts, > > combine all together into a v4l2-subdev linking with v4l2 sensor drivers and v4l2 ISP driver backward and forward to transmit and process image. > > > > It seems that seninf is a mfd or syscon device. MMSYS [1] is a system controller which control multiple functions. Its major driver is placed in [2], and its clock control function is placed in [3]. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr > ee/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt?h > =next-20200413 [2] > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr > ee/drivers/soc/mediatek/mtk-mmsys.c?h=next-20200413 > [3] > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr > ee/drivers/clk/mediatek/clk-mt8173-mm.c?h=next-20200413 > > > The data lanes and port settings is configured by v4l2 sensor > > drivers, For control reason, it's a better way to let seninf > > mipi-csi part inside seninf v4l2-subdev rather than an independent > > phy device in drivers/phy/mediatek > > > > There have similar design in omap4iss and Rkisp1-isp driver, they all in staging step. > > https://elixir.bootlin.com/linux/v5.6/source/drivers/staging/media/r > > ki > > sp1 > > https://elixir.bootlin.com/linux/v5.6/source/drivers/staging/media/o > > ma > > p4iss > > Staging driver means there are some things need to modify to move out of staging folder, so I think this is not a strong reason to keep phy control in drivers/media/ folder. You could move this driver to drivers/staging/media/ folder and I would have no comment about this. > > Regards, > Chun-Kuang. > > > > > BRs > > Louis > > > > -----Original Message----- > > From: Chun-Kuang Hu [mailto:chunkuang.hu@kernel.org] > > Sent: Saturday, April 11, 2020 8:17 AM > > To: Louis Kuo (郭德寧) <louis.kuo@mediatek.com> > > Cc: hans.verkuil@cisco.com; > > laurent.pinchart+renesas@ideasonboard.com; > > tfiga@chromium.org; keiichiw@chromium.org; Matthias Brugger > > <matthias.bgg@gmail.com>; Mauro Carvalho Chehab > > <mchehab@kernel.org>; devicetree@vger.kernel.org; Sean Cheng (鄭昇弘) > > <Sean.Cheng@mediatek.com>; srv_heupstream > > <srv_heupstream@mediatek.com>; Jerry-ch Chen (陳敬憲) > > <Jerry-ch.Chen@mediatek.com>; Jungo Lin (林明俊) > > <jungo.lin@mediatek.com>; Sj Huang (黃信璋) <sj.huang@mediatek.com>; > > yuzhao@chromium.org; moderated list:ARM/Mediatek SoC support > > <linux-mediatek@lists.infradead.org>; zwisler@chromium.org; Christie > > Yu (游雅惠) <christie.yu@mediatek.com>; Frederic Chen (陳俊元) > > <Frederic.Chen@mediatek.com>; Linux ARM > > <linux-arm-kernel@lists.infradead.org>; linux-media@vger.kernel.org > > Subject: Re: [RFC PATCH V6 1/3] media: platform: mtk-isp: Add > > Mediatek sensor interface driver > > > > Hi, Louis: > > > > Louis Kuo <louis.kuo@mediatek.com> 於 2020年4月10日 週五 下午3:18寫道： > > > > > > This patch adds Mediatek's sensor interface driver. Sensor > > > interface driver is a MIPI-CSI2 host driver, namely, a HW camera > > > interface controller. It support a widely adopted, simple, > > > high-speed protocol primarily intended for point-to-point image > > > and video transmission between cameras and host devices. The > > > mtk-isp directory will contain drivers for multiple IP blocks > > > found in Mediatek ISP system. It will include ISP Pass 1 driver, sensor interface driver, DIP driver and face detection driver. > > > > > > Signed-off-by: Louis Kuo <louis.kuo@mediatek.com> > > > --- > > > drivers/media/platform/Makefile | 1 + > > > drivers/media/platform/mtk-isp/Kconfig | 18 + > > > drivers/media/platform/mtk-isp/Makefile | 3 + > > > .../media/platform/mtk-isp/seninf/Makefile | 5 + > > > drivers/media/platform/mtk-isp/seninf/TODO | 18 + > > > .../platform/mtk-isp/seninf/mtk_seninf.c | 1173 +++++++++++++ > > > .../platform/mtk-isp/seninf/mtk_seninf_reg.h | 1491 +++++++++++++++++ > > > .../mtk-isp/seninf/mtk_seninf_rx_reg.h | 1398 ++++++++++++++++ > > > 8 files changed, 4107 insertions(+) create mode 100644 > > > drivers/media/platform/mtk-isp/Kconfig > > > create mode 100644 drivers/media/platform/mtk-isp/Makefile > > > create mode 100644 drivers/media/platform/mtk-isp/seninf/Makefile > > > create mode 100644 drivers/media/platform/mtk-isp/seninf/TODO > > > create mode 100644 > > > drivers/media/platform/mtk-isp/seninf/mtk_seninf.c > > > create mode 100644 > > > drivers/media/platform/mtk-isp/seninf/mtk_seninf_reg.h > > > create mode 100644 > > > drivers/media/platform/mtk-isp/seninf/mtk_seninf_rx_reg.h > > > > > > > [snip] > > > > > + > > > +static void mtk_seninf_set_dphy(struct mtk_seninf *priv, unsigned > > > +int > > > +seninf) { > > > + void __iomem *pmipi_rx_base = priv->csi2_rx[CFG_CSI_PORT_0]; > > > + unsigned int port = priv->port; > > > + void __iomem *pmipi_rx = priv->csi2_rx[port]; > > > + void __iomem *pmipi_rx_conf = priv->base + 0x1000 * > > > +seninf; > > > + > > > + /* Set analog phy mode to DPHY */ > > > + if (is_cdphy_combo(port)) > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, RG_CSI0A_CPHY_EN, 0); > > > + /* 4D1C: MIPIRX_ANALOG_A_BASE = 0x00001A42 */ > > > + if (is_4d1c(port)) { > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L0_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L0_CKSEL, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L1_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L1_CKSEL, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L2_CKMODE_EN, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L2_CKSEL, 1); > > > + } else {/* MIPIRX_ANALOG_BASE = 0x102 */ > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L0_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L0_CKSEL, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L1_CKMODE_EN, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L1_CKSEL, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L2_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_DPHY_L2_CKSEL, 0); > > > + } > > > + if (is_cdphy_combo(port)) > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_CPHY_EN, 0); > > > + > > > + /* Only 4d1c need set CSIB: MIPIRX_ANALOG_B_BASE = 0x00001242 */ > > > + if (is_4d1c(port)) { > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L0_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L0_CKSEL, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L1_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L1_CKSEL, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L2_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L2_CKSEL, 1); > > > + } else {/* MIPIRX_ANALOG_BASE = 0x102 */ > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L0_CKSEL, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L1_CKMODE_EN, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L1_CKSEL, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L2_CKMODE_EN, 0); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_DPHY_L2_CKSEL, 0); > > > + } > > > + /* Byte clock invert */ > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANAA8_CSI0A, > > > + RG_CSI0A_CDPHY_L0_T0_BYTECK_INVERT, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANAA8_CSI0A, > > > + RG_CSI0A_DPHY_L1_BYTECK_INVERT, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANAA8_CSI0A, > > > + RG_CSI0A_CDPHY_L2_T1_BYTECK_INVERT, 1); > > > + > > > + if (is_4d1c(port)) { > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANAA8_CSI0B, > > > + RG_CSI0B_CDPHY_L0_T0_BYTECK_INVERT, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANAA8_CSI0B, > > > + RG_CSI0B_DPHY_L1_BYTECK_INVERT, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANAA8_CSI0B, > > > + RG_CSI0B_CDPHY_L2_T1_BYTECK_INVERT, 1); > > > + } > > > + > > > + /* Start ANA EQ tuning */ > > > + if (is_cdphy_combo(port)) { > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI0A, > > > + RG_CSI0A_L0_T0AB_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI0A, > > > + RG_CSI0A_L0_T0AB_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI0A, > > > + RG_CSI0A_L1_T1AB_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI0A, > > > + RG_CSI0A_L1_T1AB_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA20_CSI0A, > > > + RG_CSI0A_L2_T1BC_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA20_CSI0A, > > > + RG_CSI0A_L2_T1BC_EQ_BW, 1); > > > + > > > + if (is_4d1c(port)) { /* 4d1c */ > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI0B, > > > + RG_CSI0B_L0_T0AB_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI0B, > > > + RG_CSI0B_L0_T0AB_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI0B, > > > + RG_CSI0B_L1_T1AB_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI0B, > > > + RG_CSI0B_L1_T1AB_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA20_CSI0B, > > > + RG_CSI0B_L2_T1BC_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA20_CSI0B, > > > + RG_CSI0B_L2_T1BC_EQ_BW, 1); > > > + } > > > + } else { > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1A, > > > + RG_CSI1A_L0_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1A, > > > + RG_CSI1A_L0_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1A, > > > + RG_CSI1A_L1_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1A, > > > + RG_CSI1A_L1_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI1A, > > > + RG_CSI1A_L2_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI1A, > > > + RG_CSI1A_L2_EQ_BW, 1); > > > + > > > + if (is_4d1c(port)) { /* 4d1c */ > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1B, > > > + RG_CSI1B_L0_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1B, > > > + RG_CSI1B_L0_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1B, > > > + RG_CSI1B_L1_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA18_CSI1B, > > > + RG_CSI1B_L1_EQ_BW, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI1B, > > > + RG_CSI1B_L2_EQ_IS, 1); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA1C_CSI1B, > > > + RG_CSI1B_L2_EQ_BW, 1); > > > + } > > > + } > > > + > > > + /* End ANA EQ tuning */ > > > + writel(0x90, pmipi_rx_base + MIPI_RX_ANA40_CSI0A); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA24_CSI0A, > > > + RG_CSI0A_RESERVE, 0x40); > > > + if (is_4d1c(port)) > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA24_CSI0B, > > > + RG_CSI0B_RESERVE, 0x40); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_WRAPPER80_CSI0A, > > > + CSR_CSI_RST_MODE, 0); > > > + if (is_4d1c(port)) > > > + SENINF_BITS(pmipi_rx, MIPI_RX_WRAPPER80_CSI0B, > > > + CSR_CSI_RST_MODE, 0); > > > + /* ANA power on */ > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_BG_CORE_EN, 1); > > > + if (is_4d1c(port)) > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_BG_CORE_EN, 1); > > > + usleep_range(20, 40); > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0A, > > > + RG_CSI0A_BG_LPF_EN, 1); > > > + if (is_4d1c(port)) > > > + SENINF_BITS(pmipi_rx, MIPI_RX_ANA00_CSI0B, > > > + RG_CSI0B_BG_LPF_EN, 1); > > > + > > > + udelay(1); > > > + /* 4d1c: MIPIRX_CONFIG_CSI_BASE = 0xC9000000; */ > > > + if (is_4d1c(port)) { > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN0_MUX, 1); > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN1_MUX, 2); > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN2_MUX, 0); > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN3_MUX, 3); > > > + } else { /* 2d1c: MIPIRX_CONFIG_CSI_BASE = 0xE4000000; */ > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN0_MUX, 0); > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN1_MUX, 1); > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN2_MUX, 2); > > > + SENINF_BITS(pmipi_rx_conf, MIPI_RX_CON24_CSI0, > > > + CSI0_BIST_LN3_MUX, 3); > > > + } > > > +} > > > > I think the phy control part should be placed in drivers/phy/mediatek/. In [1], device csis point to a device mipi_phy. > > csis' driver is in [2], and mipi_phy's driver is in [3] > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t > > re > > e/arch/arm/boot/dts/exynos4.dtsi?h=v5.6 > > [2] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t > > re > > e/drivers/media/platform/exynos4-is/mipi-csis.c?h=v5.6 > > [3] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t > > re > > e/drivers/phy/samsung/phy-exynos-mipi-video.c?h=v5.6 > > > > Regards, > > Chun-Kuang.