[03/10] phy: Add MIPI D-PHY configuration options

Commit Message

Maxime Ripard Sept. 5, 2018, 9:16 a.m. UTC

Now that we have some infrastructure for it, allow the MIPI D-PHY phy's to
be configured through the generic functions through a custom structure
added to the generic union.

The parameters added here are the one defined in the MIPI D-PHY spec, plus
some parameters that were used by a number of PHY drivers currently found
in the linux kernel. The current set of parameters should cover all the
potential users.

Signed-off-by: Maxime Ripard <[e-mail]>
---
 include/linux/phy/phy-mipi-dphy.h | 241 +++++++++++++++++++++++++++++++-
 include/linux/phy/phy.h           |   6 +-
 2 files changed, 247 insertions(+)
 create mode 100644 include/linux/phy/phy-mipi-dphy.h

Comments

Laurent Pinchart Sept. 5, 2018, 1:43 p.m. UTC | #1

Hi Maxime,

Thank you for the patch.

On Wednesday, 5 September 2018 12:16:34 EEST Maxime Ripard wrote:
> Now that we have some infrastructure for it, allow the MIPI D-PHY phy's to
> be configured through the generic functions through a custom structure
> added to the generic union.
> 
> The parameters added here are the one defined in the MIPI D-PHY spec, plus

s/one/ones/

> some parameters that were used by a number of PHY drivers currently found
> in the linux kernel.

It would be useful to document which parameters are from the spec and which 
are not.

> The current set of parameters should cover all the potential users.
> 
> Signed-off-by: Maxime Ripard <[e-mail]>
> ---
>  include/linux/phy/phy-mipi-dphy.h | 241 +++++++++++++++++++++++++++++++-
>  include/linux/phy/phy.h           |   6 +-
>  2 files changed, 247 insertions(+)
>  create mode 100644 include/linux/phy/phy-mipi-dphy.h
> 
> diff --git a/include/linux/phy/phy-mipi-dphy.h
> b/include/linux/phy/phy-mipi-dphy.h new file mode 100644
> index 000000000000..792724145290
> --- /dev/null
> +++ b/include/linux/phy/phy-mipi-dphy.h
> @@ -0,0 +1,241 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2018 Cadence Design Systems Inc.
> + */
> +
> +#ifndef __PHY_MIPI_DPHY_H_
> +#define __PHY_MIPI_DPHY_H_
> +
> +#include <video/videomode.h>
> +
> +/**
> + * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> + *
> + * This structure is used to represent the configuration state of a
> + * MIPI D-PHY phy.

Shouldn't we split the RX and TX parameters in two structures ?

> + */
> +struct phy_configure_opts_mipi_dphy {
> +	/**
> +	 * @clk_miss:
> +	 *
> +	 * Timeout, in nanoseconds, for receiver to detect absence of
> +	 * Clock transitions and disable the Clock Lane HS-RX.
> +	 */
> +	unsigned int		clk_miss;
> +
> +	/**
> +	 * @clk_post:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter continues to
> +	 * send HS clock after the last associated Data Lane has
> +	 * transitioned to LP Mode. Interval is defined as the period
> +	 * from the end of @hs_trail to the beginning of @clk_trail.
> +	 */
> +	unsigned int		clk_post;
> +
> +	/**
> +	 * @clk_pre:
> +	 *
> +	 * Time, in nanoseconds, that the HS clock shall be driven by
> +	 * the transmitter prior to any associated Data Lane beginning
> +	 * the transition from LP to HS mode.
> +	 */
> +	unsigned int		clk_pre;
> +
> +	/**
> +	 * @clk_prepare:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives the Clock
> +	 * Lane LP-00 Line state immediately before the HS-0 Line
> +	 * state starting the HS transmission.
> +	 */
> +	unsigned int		clk_prepare;
> +
> +	/**
> +	 * @clk_settle:
> +	 *
> +	 * Time interval, in nanoseconds, during which the HS receiver
> +	 * should ignore any Clock Lane HS transitions, starting from
> +	 * the beginning of @clk_prepare.
> +	 */
> +	unsigned int		clk_settle;
> +
> +	/**
> +	 * @clk_term_en:
> +	 *
> +	 * Time, in nanoseconds, for the Clock Lane receiver to enable
> +	 * the HS line termination.
> +	 */
> +	unsigned int		clk_term_en;
> +
> +	/**
> +	 * @clk_trail:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives the HS-0
> +	 * state after the last payload clock bit of a HS transmission
> +	 * burst.
> +	 */
> +	unsigned int		clk_trail;
> +
> +	/**
> +	 * @clk_zero:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives the HS-0
> +	 * state prior to starting the Clock.
> +	 */
> +	unsigned int		clk_zero;
> +
> +	/**
> +	 * @d_term_en:
> +	 *
> +	 * Time, in nanoseconds, for the Data Lane receiver to enable
> +	 * the HS line termination.
> +	 */
> +	unsigned int		d_term_en;
> +
> +	/**
> +	 * @eot:
> +	 *
> +	 * Transmitted time interval, in nanoseconds, from the start
> +	 * of @hs_trail or @clk_trail, to the start of the LP- 11
> +	 * state following a HS burst.
> +	 */
> +	unsigned int		eot;
> +
> +	/**
> +	 * @hs_exit:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives LP-11
> +	 * following a HS burst.
> +	 */
> +	unsigned int		hs_exit;
> +
> +	/**
> +	 * @hs_prepare:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives the Data
> +	 * Lane LP-00 Line state immediately before the HS-0 Line
> +	 * state starting the HS transmission
> +	 */
> +	unsigned int		hs_prepare;
> +
> +	/**
> +	 * @hs_settle:
> +	 *
> +	 * Time interval, in nanoseconds, during which the HS receiver
> +	 * shall ignore any Data Lane HS transitions, starting from
> +	 * the beginning of @hs_prepare.
> +	 */
> +	unsigned int		hs_settle;
> +
> +	/**
> +	 * @hs_skip:
> +	 *
> +	 * Time interval, in nanoseconds, during which the HS-RX
> +	 * should ignore any transitions on the Data Lane, following a
> +	 * HS burst. The end point of the interval is defined as the
> +	 * beginning of the LP-11 state following the HS burst.
> +	 */
> +	unsigned int		hs_skip;
> +
> +	/**
> +	 * @hs_trail:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives the
> +	 * flipped differential state after last payload data bit of a
> +	 * HS transmission burst
> +	 */
> +	unsigned int		hs_trail;
> +
> +	/**
> +	 * @hs_zero:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives the HS-0
> +	 * state prior to transmitting the Sync sequence.
> +	 */
> +	unsigned int		hs_zero;
> +
> +	/**
> +	 * @lpx:
> +	 *
> +	 * Transmitted length, in nanoseconds, of any Low-Power state
> +	 * period.
> +	 */
> +	unsigned int		lpx;
> +
> +	/**
> +	 * @ta_get:
> +	 *
> +	 * Time, in nanoseconds, that the new transmitter drives the
> +	 * Bridge state (LP-00) after accepting control during a Link
> +	 * Turnaround.
> +	 */
> +	unsigned int		ta_get;
> +
> +	/**
> +	 * @ta_go:
> +	 *
> +	 * Time, in nanoseconds, that the transmitter drives the
> +	 * Bridge state (LP-00) before releasing control during a Link
> +	 * Turnaround.
> +	 */
> +	unsigned int		ta_go;
> +
> +	/**
> +	 * @ta_sure:
> +	 *
> +	 * Time, in nanoseconds, that the new transmitter waits after
> +	 * the LP-10 state before transmitting the Bridge state
> +	 * (LP-00) during a Link Turnaround.
> +	 */
> +	unsigned int		ta_sure;
> +
> +	/**
> +	 * @wakeup:
> +	 *
> +	 * Time, in nanoseconds, that a transmitter drives a Mark-1
> +	 * state prior to a Stop state in order to initiate an exit
> +	 * from ULPS.
> +	 */
> +	unsigned int		wakeup;
> +
> +	/**
> +	 * @hs_clk_rate:
> +	 *
> +	 * Clock rate, in Hertz, of the high-speed clock.
> +	 */
> +	unsigned long		hs_clk_rate;
> +
> +	/**
> +	 * @lp_clk_rate:
> +	 *
> +	 * Clock rate, in Hertz, of the low-power clock.
> +	 */
> +	unsigned long		lp_clk_rate;
> +
> +	/**
> +	 * @lanes:
> +	 *
> +	 * Number of lanes used for the transmissions.
> +	 */
> +	unsigned char		lanes;
> +
> +	/**
> +	 * @modes:
> +	 *
> +	 * transmission operation mode flags
> +	 */
> +	u32			modes;

Where are those flags defined ?

> +	/**
> +	 * @timings:
> +	 *
> +	 * Video timings associated with the transmission.

That's a pretty vague description...

> +	 */
> +	struct videomode	timings;
> +};
> +
> +/* TODO: Add other modes (burst, commands, etc) */
> +#define MIPI_DPHY_MODE_VIDEO_SYNC_PULSE		BIT(0)
> +
> +#endif /* __PHY_MIPI_DPHY_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 3cc315dcfcd0..2b7a72f98428 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -20,6 +20,8 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/regulator/consumer.h>
> 
> +#include <linux/phy/phy-mipi-dphy.h>

You can move this within the existing list of #include's.

> +
>  struct phy;
> 
>  enum phy_mode {
> @@ -45,8 +47,12 @@ enum phy_mode {
> 
>  /**
>   * union phy_configure_opts - Opaque generic phy configuration
> + *
> + * @mipi_dphy:	Configuration set applicable for phys supporting
> + *		the MIPI_DPHY phy mode.
>   */
>  union phy_configure_opts {
> +	struct phy_configure_opts_mipi_dphy	mipi_dphy;
>  };
> 
>  /**

Maxime Ripard Sept. 7, 2018, 8:56 a.m. UTC | #2

Hi,

On Wed, Sep 05, 2018 at 04:43:57PM +0300, Laurent Pinchart wrote:
> > The current set of parameters should cover all the potential users.
> > 
> > Signed-off-by: Maxime Ripard <[e-mail]>
> > ---
> >  include/linux/phy/phy-mipi-dphy.h | 241 +++++++++++++++++++++++++++++++-
> >  include/linux/phy/phy.h           |   6 +-
> >  2 files changed, 247 insertions(+)
> >  create mode 100644 include/linux/phy/phy-mipi-dphy.h
> > 
> > diff --git a/include/linux/phy/phy-mipi-dphy.h
> > b/include/linux/phy/phy-mipi-dphy.h new file mode 100644
> > index 000000000000..792724145290
> > --- /dev/null
> > +++ b/include/linux/phy/phy-mipi-dphy.h
> > @@ -0,0 +1,241 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2018 Cadence Design Systems Inc.
> > + */
> > +
> > +#ifndef __PHY_MIPI_DPHY_H_
> > +#define __PHY_MIPI_DPHY_H_
> > +
> > +#include <video/videomode.h>
> > +
> > +/**
> > + * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> > + *
> > + * This structure is used to represent the configuration state of a
> > + * MIPI D-PHY phy.
> 
> Shouldn't we split the RX and TX parameters in two structures ?

Are they different? As far as I understood it, both were having the
same parameters.



> > +	/**
> > +	 * @modes:
> > +	 *
> > +	 * transmission operation mode flags
> > +	 */
> > +	u32			modes;
> 
> Where are those flags defined ?

goto label;

> > +	/**
> > +	 * @timings:
> > +	 *
> > +	 * Video timings associated with the transmission.
> 
> That's a pretty vague description...

I'll try to improve it then

> > +	 */
> > +	struct videomode	timings;
> > +};
> > +

label:
> > +/* TODO: Add other modes (burst, commands, etc) */
> > +#define MIPI_DPHY_MODE_VIDEO_SYNC_PULSE		BIT(0)

But maybe I should reorganize it to make it more obvious.

Maxime

Laurent Pinchart Sept. 7, 2018, 2:50 p.m. UTC | #3

Hi Maxime,

On Friday, 7 September 2018 11:56:23 EEST Maxime Ripard wrote:
> On Wed, Sep 05, 2018 at 04:43:57PM +0300, Laurent Pinchart wrote:
> >> The current set of parameters should cover all the potential users.
> >> 
> >> Signed-off-by: Maxime Ripard <[e-mail]>
> >> ---
> >> 
> >>  include/linux/phy/phy-mipi-dphy.h | 241 ++++++++++++++++++++++++++++++-
> >>  include/linux/phy/phy.h           |   6 +-
> >>  2 files changed, 247 insertions(+)
> >>  create mode 100644 include/linux/phy/phy-mipi-dphy.h
> >> 
> >> diff --git a/include/linux/phy/phy-mipi-dphy.h
> >> b/include/linux/phy/phy-mipi-dphy.h new file mode 100644
> >> index 000000000000..792724145290
> >> --- /dev/null
> >> +++ b/include/linux/phy/phy-mipi-dphy.h
> >> @@ -0,0 +1,241 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +/*
> >> + * Copyright (C) 2018 Cadence Design Systems Inc.
> >> + */
> >> +
> >> +#ifndef __PHY_MIPI_DPHY_H_
> >> +#define __PHY_MIPI_DPHY_H_
> >> +
> >> +#include <video/videomode.h>
> >> +
> >> +/**
> >> + * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> >> + *
> >> + * This structure is used to represent the configuration state of a
> >> + * MIPI D-PHY phy.
> > 
> > Shouldn't we split the RX and TX parameters in two structures ?
> 
> Are they different? As far as I understood it, both were having the
> same parameters.

clk_miss, for instance, is a receiver parameter, while clk_post is a 
transmitter parameter. There are relationships between the transmitter and 
receiver parameters in the sense that they have to be compatible, and we may 
want to compute one set of parameters based on the other one, but I think they 
target RX and TX separately.

> >> +	/**
> >> +	 * @modes:
> >> +	 *
> >> +	 * transmission operation mode flags
> >> +	 */
> >> +	u32			modes;
> > 
> > Where are those flags defined ?
> 
> goto label;
> 
> >> +	/**
> >> +	 * @timings:
> >> +	 *
> >> +	 * Video timings associated with the transmission.
> > 
> > That's a pretty vague description...
> 
> I'll try to improve it then
> 
> >> +	 */
> >> +	struct videomode	timings;
> >> +};
> >> +
> 
> label:
> > > +/* TODO: Add other modes (burst, commands, etc) */
> > > +#define MIPI_DPHY_MODE_VIDEO_SYNC_PULSE		BIT(0)
> 
> But maybe I should reorganize it to make it more obvious.

Maxime Ripard Sept. 10, 2018, 2:18 p.m. UTC | #4

On Fri, Sep 07, 2018 at 05:50:52PM +0300, Laurent Pinchart wrote:
> On Friday, 7 September 2018 11:56:23 EEST Maxime Ripard wrote:
> > On Wed, Sep 05, 2018 at 04:43:57PM +0300, Laurent Pinchart wrote:
> > >> The current set of parameters should cover all the potential users.
> > >> 
> > >> Signed-off-by: Maxime Ripard <[e-mail]>
> > >> ---
> > >> 
> > >>  include/linux/phy/phy-mipi-dphy.h | 241 ++++++++++++++++++++++++++++++-
> > >>  include/linux/phy/phy.h           |   6 +-
> > >>  2 files changed, 247 insertions(+)
> > >>  create mode 100644 include/linux/phy/phy-mipi-dphy.h
> > >> 
> > >> diff --git a/include/linux/phy/phy-mipi-dphy.h
> > >> b/include/linux/phy/phy-mipi-dphy.h new file mode 100644
> > >> index 000000000000..792724145290
> > >> --- /dev/null
> > >> +++ b/include/linux/phy/phy-mipi-dphy.h
> > >> @@ -0,0 +1,241 @@
> > >> +/* SPDX-License-Identifier: GPL-2.0 */
> > >> +/*
> > >> + * Copyright (C) 2018 Cadence Design Systems Inc.
> > >> + */
> > >> +
> > >> +#ifndef __PHY_MIPI_DPHY_H_
> > >> +#define __PHY_MIPI_DPHY_H_
> > >> +
> > >> +#include <video/videomode.h>
> > >> +
> > >> +/**
> > >> + * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
> > >> + *
> > >> + * This structure is used to represent the configuration state of a
> > >> + * MIPI D-PHY phy.
> > > 
> > > Shouldn't we split the RX and TX parameters in two structures ?
> > 
> > Are they different? As far as I understood it, both were having the
> > same parameters.
> 
> clk_miss, for instance, is a receiver parameter, while clk_post is a 
> transmitter parameter. There are relationships between the transmitter and 
> receiver parameters in the sense that they have to be compatible, and we may 
> want to compute one set of parameters based on the other one, but I think they 
> target RX and TX separately.

That would require however to have to fill a structure in the consumer
whose sole purpose would be to validate things in the phy
framework. That looks quite weird from an API point-of-view.

Maxime

Patch

diff --git a/include/linux/phy/phy-mipi-dphy.h b/include/linux/phy/phy-mipi-dphy.h
new file mode 100644
index 000000000000..792724145290
--- /dev/null
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -0,0 +1,241 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ */
+
+#ifndef __PHY_MIPI_DPHY_H_
+#define __PHY_MIPI_DPHY_H_
+
+#include <video/videomode.h>
+
+/**
+ * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
+ *
+ * This structure is used to represent the configuration state of a
+ * MIPI D-PHY phy.
+ */
+struct phy_configure_opts_mipi_dphy {
+	/**
+	 * @clk_miss:
+	 *
+	 * Timeout, in nanoseconds, for receiver to detect absence of
+	 * Clock transitions and disable the Clock Lane HS-RX.
+	 */
+	unsigned int		clk_miss;
+
+	/**
+	 * @clk_post:
+	 *
+	 * Time, in nanoseconds, that the transmitter continues to
+	 * send HS clock after the last associated Data Lane has
+	 * transitioned to LP Mode. Interval is defined as the period
+	 * from the end of @hs_trail to the beginning of @clk_trail.
+	 */
+	unsigned int		clk_post;
+
+	/**
+	 * @clk_pre:
+	 *
+	 * Time, in nanoseconds, that the HS clock shall be driven by
+	 * the transmitter prior to any associated Data Lane beginning
+	 * the transition from LP to HS mode.
+	 */
+	unsigned int		clk_pre;
+
+	/**
+	 * @clk_prepare:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives the Clock
+	 * Lane LP-00 Line state immediately before the HS-0 Line
+	 * state starting the HS transmission.
+	 */
+	unsigned int		clk_prepare;
+
+	/**
+	 * @clk_settle:
+	 *
+	 * Time interval, in nanoseconds, during which the HS receiver
+	 * should ignore any Clock Lane HS transitions, starting from
+	 * the beginning of @clk_prepare.
+	 */
+	unsigned int		clk_settle;
+
+	/**
+	 * @clk_term_en:
+	 *
+	 * Time, in nanoseconds, for the Clock Lane receiver to enable
+	 * the HS line termination.
+	 */
+	unsigned int		clk_term_en;
+
+	/**
+	 * @clk_trail:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives the HS-0
+	 * state after the last payload clock bit of a HS transmission
+	 * burst.
+	 */
+	unsigned int		clk_trail;
+
+	/**
+	 * @clk_zero:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives the HS-0
+	 * state prior to starting the Clock.
+	 */
+	unsigned int		clk_zero;
+
+	/**
+	 * @d_term_en:
+	 *
+	 * Time, in nanoseconds, for the Data Lane receiver to enable
+	 * the HS line termination.
+	 */
+	unsigned int		d_term_en;
+
+	/**
+	 * @eot:
+	 *
+	 * Transmitted time interval, in nanoseconds, from the start
+	 * of @hs_trail or @clk_trail, to the start of the LP- 11
+	 * state following a HS burst.
+	 */
+	unsigned int		eot;
+
+	/**
+	 * @hs_exit:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives LP-11
+	 * following a HS burst.
+	 */
+	unsigned int		hs_exit;
+
+	/**
+	 * @hs_prepare:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives the Data
+	 * Lane LP-00 Line state immediately before the HS-0 Line
+	 * state starting the HS transmission
+	 */
+	unsigned int		hs_prepare;
+
+	/**
+	 * @hs_settle:
+	 *
+	 * Time interval, in nanoseconds, during which the HS receiver
+	 * shall ignore any Data Lane HS transitions, starting from
+	 * the beginning of @hs_prepare.
+	 */
+	unsigned int		hs_settle;
+
+	/**
+	 * @hs_skip:
+	 *
+	 * Time interval, in nanoseconds, during which the HS-RX
+	 * should ignore any transitions on the Data Lane, following a
+	 * HS burst. The end point of the interval is defined as the
+	 * beginning of the LP-11 state following the HS burst.
+	 */
+	unsigned int		hs_skip;
+
+	/**
+	 * @hs_trail:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives the
+	 * flipped differential state after last payload data bit of a
+	 * HS transmission burst
+	 */
+	unsigned int		hs_trail;
+
+	/**
+	 * @hs_zero:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives the HS-0
+	 * state prior to transmitting the Sync sequence.
+	 */
+	unsigned int		hs_zero;
+
+	/**
+	 * @lpx:
+	 *
+	 * Transmitted length, in nanoseconds, of any Low-Power state
+	 * period.
+	 */
+	unsigned int		lpx;
+
+	/**
+	 * @ta_get:
+	 *
+	 * Time, in nanoseconds, that the new transmitter drives the
+	 * Bridge state (LP-00) after accepting control during a Link
+	 * Turnaround.
+	 */
+	unsigned int		ta_get;
+
+	/**
+	 * @ta_go:
+	 *
+	 * Time, in nanoseconds, that the transmitter drives the
+	 * Bridge state (LP-00) before releasing control during a Link
+	 * Turnaround.
+	 */
+	unsigned int		ta_go;
+
+	/**
+	 * @ta_sure:
+	 *
+	 * Time, in nanoseconds, that the new transmitter waits after
+	 * the LP-10 state before transmitting the Bridge state
+	 * (LP-00) during a Link Turnaround.
+	 */
+	unsigned int		ta_sure;
+
+	/**
+	 * @wakeup:
+	 *
+	 * Time, in nanoseconds, that a transmitter drives a Mark-1
+	 * state prior to a Stop state in order to initiate an exit
+	 * from ULPS.
+	 */
+	unsigned int		wakeup;
+
+	/**
+	 * @hs_clk_rate:
+	 *
+	 * Clock rate, in Hertz, of the high-speed clock.
+	 */
+	unsigned long		hs_clk_rate;
+
+	/**
+	 * @lp_clk_rate:
+	 *
+	 * Clock rate, in Hertz, of the low-power clock.
+	 */
+	unsigned long		lp_clk_rate;
+
+	/**
+	 * @lanes:
+	 *
+	 * Number of lanes used for the transmissions.
+	 */
+	unsigned char		lanes;
+
+	/**
+	 * @modes:
+	 *
+	 * transmission operation mode flags
+	 */
+	u32			modes;
+
+	/**
+	 * @timings:
+	 *
+	 * Video timings associated with the transmission.
+	 */
+	struct videomode	timings;
+};
+
+/* TODO: Add other modes (burst, commands, etc) */
+#define MIPI_DPHY_MODE_VIDEO_SYNC_PULSE		BIT(0)
+
+#endif /* __PHY_MIPI_DPHY_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 3cc315dcfcd0..2b7a72f98428 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -20,6 +20,8 @@ 
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
 
+#include <linux/phy/phy-mipi-dphy.h>
+
 struct phy;
 
 enum phy_mode {
@@ -45,8 +47,12 @@  enum phy_mode {
 
 /**
  * union phy_configure_opts - Opaque generic phy configuration
+ *
+ * @mipi_dphy:	Configuration set applicable for phys supporting
+ *		the MIPI_DPHY phy mode.
  */
 union phy_configure_opts {
+	struct phy_configure_opts_mipi_dphy	mipi_dphy;
 };
 
 /**