| Message ID | 20190306232345.23052-5-laurent.pinchart+renesas@ideasonboard.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | R-Car DU: LVDS dual-link mode support | expand |
Hi Laurent, On 06/03/2019 23:23, Laurent Pinchart wrote: > Extend the drm_bridge_timings structure with a new dual_link field to > indicate that the bridge's input bus carries data on two separate > physical links. The first use case is LVDS dual-link mode where even- > and odd-numbered pixels are transferred on separate LVDS links. Do you foresee this becoming a bitfield in the future if there are more options? I don't think that affects this right now though, and it's fine as a bool. > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > --- > include/drm/drm_bridge.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > index d4428913a4e1..aea1fcfd92a7 100644 > --- a/include/drm/drm_bridge.h > +++ b/include/drm/drm_bridge.h > @@ -265,6 +265,14 @@ struct drm_bridge_timings { > * input signal after the clock edge. > */ > u32 hold_time_ps; > + /** > + * @dual_link: > + * > + * True if the bus operates in dual-link mode. The exact meaning is > + * dependent on the bus type. For LVDS buses, this indicates that even- > + * and odd-numbered pixels are received on separate links. > + */ > + bool dual_link; > }; > > /** >
Hi Kieran, On Wed, Apr 24, 2019 at 09:12:48AM +0100, Kieran Bingham wrote: > On 06/03/2019 23:23, Laurent Pinchart wrote: > > Extend the drm_bridge_timings structure with a new dual_link field to > > indicate that the bridge's input bus carries data on two separate > > physical links. The first use case is LVDS dual-link mode where even- > > and odd-numbered pixels are transferred on separate LVDS links. > > Do you foresee this becoming a bitfield in the future if there are more > options? > > I don't think that affects this right now though, and it's fine as a bool. I don't know yet. Maybe we'll combine this with other flags, maybe not. It's a bit of a ad-hoc parameter, if/when other link types require a similar feature, we'll likely refactor this. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > > Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> > > > --- > > include/drm/drm_bridge.h | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > > index d4428913a4e1..aea1fcfd92a7 100644 > > --- a/include/drm/drm_bridge.h > > +++ b/include/drm/drm_bridge.h > > @@ -265,6 +265,14 @@ struct drm_bridge_timings { > > * input signal after the clock edge. > > */ > > u32 hold_time_ps; > > + /** > > + * @dual_link: > > + * > > + * True if the bus operates in dual-link mode. The exact meaning is > > + * dependent on the bus type. For LVDS buses, this indicates that even- > > + * and odd-numbered pixels are received on separate links. > > + */ > > + bool dual_link; > > }; > > > > /**
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index d4428913a4e1..aea1fcfd92a7 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -265,6 +265,14 @@ struct drm_bridge_timings { * input signal after the clock edge. */ u32 hold_time_ps; + /** + * @dual_link: + * + * True if the bus operates in dual-link mode. The exact meaning is + * dependent on the bus type. For LVDS buses, this indicates that even- + * and odd-numbered pixels are received on separate links. + */ + bool dual_link; }; /**
Extend the drm_bridge_timings structure with a new dual_link field to indicate that the bridge's input bus carries data on two separate physical links. The first use case is LVDS dual-link mode where even- and odd-numbered pixels are transferred on separate LVDS links. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> --- include/drm/drm_bridge.h | 8 ++++++++ 1 file changed, 8 insertions(+)