linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liu Ying <Ying.Liu@freescale.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: <stefan.wahren@i2se.com>, <devicetree@vger.kernel.org>,
	<linux@arm.linux.org.uk>, <andyshrk@gmail.com>,
	<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<a.hajda@samsung.com>, <kernel@pengutronix.de>,
	<mturquette@linaro.org>, <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH RFC v8 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver
Date: Wed, 11 Feb 2015 15:21:46 +0800	[thread overview]
Message-ID: <20150211072128.GA13301@victor> (raw)
In-Reply-To: <20150206081318.GA15088@victor>

Hi Philipp,

On Fri, Feb 06, 2015 at 04:13:20PM +0800, Liu Ying wrote:
> On Thu, Feb 05, 2015 at 11:10:04AM +0100, Philipp Zabel wrote:
> > Am Mittwoch, den 31.12.2014, 16:23 +0800 schrieb Liu Ying:
> > > This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
> > > host controller DRM bridge driver.
> > > 
> > > Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> > > ---
> > > v7->v8:
> > >  * None.
> > > 
> > > v6->v7:
> > >  * None.
> > > 
> > > v5->v6:
> > >  * Add the #address-cells and #size-cells properties in the example 'ports'
> > >    node.
> > >  * Remove the useless input-port properties from the example port@0 and port@1
> > >    nodes.
> > > 
> > > v4->v5:
> > >  * None.
> > > 
> > > v3->v4:
> > >  * Newly introduced in v4.  This is separated from the relevant driver patch
> > >    in v3 to address Stefan Wahren's comment.
> > > 
> > >  .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 ++++++++++++++++++++++
> > >  1 file changed, 73 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> > > new file mode 100644
> > > index 0000000..f88a8d6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> > > @@ -0,0 +1,73 @@
> > > +Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
> > > +
> > > +The controller is a digital core that implements all protocol functions
> > > +defined in the MIPI DSI specification, providing an interface between
> > > +the system and the MIPI DPHY, and allowing communication with a MIPI DSI
> > > +compliant display.
> > > +
> > > +Required properties:
> > > + - #address-cells: Should be <1>.
> > > + - #size-cells: Should be <0>.
> > > + - compatible: The compatible string should be "fsl,imx6q-mipi-dsi" for
> > > +   i.MX6q/sdl SoCs.  For other SoCs, please refer to their specific
> > > +   device tree binding documentations.
> > 
> > I think the compatible property should additionally contain
> > "snps,dw-mipi-dsi". Also I think other SoCs using the same IP core
> > should eventually list their compatibles here, but that's for later.
> > 
> > How about:
> > + - compatible: The compatible string contain "fsl,imx6q-mipi-dsi" for
> > +   i.MX6q/sdl SoCs.  For other SoCs, please refer to their specific
> > +   device tree binding documentations. A common compatible string
> > +   "snps,dw-mipi-dsi" should be appended for all SoCs.
> 
> I'm not sure if "snps,dw-mipi-dsi" should be appended.
> 
> Is it a compatible string that SoC specific drivers should actually use to
> bind a device?
> 
> As Andy mentioned in [1], DW MIPI DSI embedded in RK618 is configured via I2C
> bus, while i.MX6Q/DL is configured via ARM bus...
> 
> Another concern is that if users only specify "snps,dw-mipi-dsi" in their
> device tree sources and use a kernel which supports multiple platforms,
> say ARM multi v7 platforms, could several enabled SoC specific drivers be
> probed for a single DW MIPI DSI device?
> 
> [1] http://lists.freedesktop.org/archives/dri-devel/2014-December/074344.html
> 
> > 
> > > + - reg: Represent the physical address range of the controller.
> > > + - interrupts: Represent the controller's interrupt to the CPU(s).
> > > + - clocks, clock-names: Phandles to the controller pll reference and
> > > +   core configuration clocks, as described in [1].
> > 
> > From the MIPI CSI-2 datasheets it looks like the D-PHY has a refclk and
> > a cfg_clk input. So I suspect from the name of the "core_cfg" clock,
> > that it actually represents two clock inputs, the "cfg_clk" wired to the
> > D-PHY and a core clock wired to the MIPI DSI host controller. I am not
> > sure if there are designs that control those clocks separately, but I
> > think it'd be safer to split this into two clocks in the device tree.
> 

Our internal MIPI DSI SoC owner gave me some feedbacks on the clock sources.
According to him, the Synopsys DesignWare MIPI DSI host controller needs four
clock sources from an application platform - pclk, refclk, cfg_clk and dpipclk.
These clocks are mentioned in the "DesignWare Cores MIPI DSI Host Controller
Databook, 1.01a1.30a.pdf" documentation.

Quote some words from the documentation:
pclk    - APB clock signal.
refclk  - D-PHY reference clock used for Master-side serial clock generation in
          clock multiplying unit(PLL).
cfg_clk - D-PHY Configuration clock used for the initialization of the PHY. It
          is also used for exiting ULPS state.
dpipclk - Input Pixel clock signal.

The below table reflects how does i.MX6Q/DL provide the pclk, refclk and cfg_clk
for the DesignWare MIPI DSI host controller, according to the SoC owner.
 ----------------------------------------------------------------------------
| Synopsys      |                     i.MX6Q/DL MIPI DSI                     |
| DesignWare    |------------------------------------------------------------|
| documentation |    clock   |     clock root     |       CCM_CCGR bits      |
|---------------|------------|--------------------|--------------------------|
|     pclk      |   ips_clk  |    ipg_clk_root    | mipi_core_cfg_clk_enable |
|---------------|------------|--------------------|--------------------------|
|    refclk     | pll_refclk | video_27m_clk_root | mipi_core_cfg_clk_enable |
|---------------|------------|--------------------|--------------------------|
|    cfg_clk    |   cfg_clk  | video_27m_clk_root | mipi_core_cfg_clk_enable |
 ----------------------------------------------------------------------------

I think we should add a new clock "IMX6QDL_CLK_MIPI_IPG" as a shared clock gate
clock.  And, the clock-names property should exactly contain "pclk", "refclk"
and "cfg_clk", right?

Let me know your thoughts.  Thanks.

> What MIPI CSI-2 datasheets do you refer to?
> I don't find the refclk and cfg_clk in the MIPI CSI chapter of the i.MX6DQ
> Reference Manual v2[2].
> 
> I think we need to know the design philosophy of DW MIPI DSI clock sources
> to settle down the documentation here.  I've asked our internal MIPI DSI
> SoC owner for ideas.  But, someone from Synopsys might be the right
> person, perhaps.
> 
> [2] http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf?fasp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf
> 
> > 
> > Also I am not sure which input to the MIPI DSI host controller the core
> > clock represents. The i.MX6DQ Reference Manual v2 calls the remaining
> > clock inputs gated by mipi_core_cfg_clk_enable "ac_clk_125m" and
> > "ips_clk" (I think the latter is the ABP clock driving the register
> > bank, just called "pclk" in the MIPI CSI-2 documentation).

Yes, the "ips_clk" clock is the "pclk" clock.  The "ac_clk_125m" clock is
designed for test and should not be used by software development, according to
the SoC owner.

Regards,
Liu Ying

> 
> The same MIPI CSI-2 documentation you mentioned above?
> 
> I'm also puzzled about the clocks.
> 
> Regards,
> Liu Ying
> 
> > 
> > regards
> > Philipp
> > 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-02-11  7:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-31  8:23 [PATCH RFC v8 00/21] Add support for i.MX MIPI DSI DRM driver Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 01/21] clk: divider: Correct parent clk round rate if no bestdiv is normally found Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 02/21] of: Add vendor prefix for Himax Technologies Inc Liu Ying
2015-02-04 16:02   ` Rob Herring
2015-02-05  2:20     ` Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 03/21] of: Add vendor prefix for Truly Semiconductors Limited Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 04/21] ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 05/21] ARM: imx6q: clk: Add the video_27m clock Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 06/21] ARM: imx6q: clk: Change hdmi_isfr clock's parent to be " Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 07/21] ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 08/21] ARM: imx6q: clk: Add support for mipi_core_cfg clock as " Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 09/21] ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 10/21] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver Liu Ying
2015-02-05 10:10   ` Philipp Zabel
2015-02-06  8:13     ` Liu Ying
2015-02-11  7:21       ` Liu Ying [this message]
2015-02-11 13:00         ` Philipp Zabel
2015-02-11 14:09           ` Liu Ying
2015-02-11 15:23             ` Philipp Zabel
2015-02-12  2:14               ` Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 12/21] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 13/21] Documentation: dt-bindings: Add bindings for i.MX specific Synopsys DW MIPI DSI driver Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 14/21] drm: imx: Support Synopsys DesignWare MIPI DSI host controller Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 15/21] Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel driver Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 16/21] drm: panel: Add support for Himax HX8369A MIPI DSI panel Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 17/21] ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 18/21] ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 19/21] ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 20/21] ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller Liu Ying
2014-12-31  8:23 ` [PATCH RFC v8 21/21] ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel Liu Ying
2015-02-02  2:17 ` [PATCH RFC v8 00/21] Add support for i.MX MIPI DSI DRM driver Liu Ying
2015-02-02  5:34   ` Liu Ying

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=20150211072128.GA13301@victor \
    --to=ying.liu@freescale.com \
    --cc=a.hajda@samsung.com \
    --cc=andyshrk@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mturquette@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=stefan.wahren@i2se.com \
    /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;
as well as URLs for NNTP newsgroup(s).