linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH/RFC 01/15] drm: Clarify definition of the DRM_BUS_FLAG_(PIXDATA|SYNC)_* macros
Date: Wed, 24 Apr 2019 09:15:43 +0100	[thread overview]
Message-ID: <827c40e2-5c1f-4a13-4d97-1c4368809c79@ideasonboard.com> (raw)
In-Reply-To: <20190306232345.23052-2-laurent.pinchart+renesas@ideasonboard.com>

Hi Laurent,

Thank you for the patch,

On 06/03/2019 23:23, Laurent Pinchart wrote:
> The DRM_BUS_FLAG_PIXDATA_POSEDGE and DRM_BUS_FLAG_PIXDATA_NEGEDGE macros
> and their DRM_BUS_FLAG_SYNC_* counterparts define on which pixel clock
> edge data and sync signals are driven. They are however used in some
> drivers to define on which pixel clock edge data and sync signals are
> sampled, which should usually (but not always) be the opposite edge of
> the driving edge. This creates confusion.
> 
> Create four new macros for both PIXDATA and SYNC that explicitly state
> the driving and sampling edge in their name to remove the confusion. The
> driving macros are defined as the opposite of the sampling macros to
> made code simpler based on the assumption that the driving and sampling

s/made/make/

> edges are opposite.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>



> ---
>  include/drm/drm_connector.h | 36 ++++++++++++++++++++++++++++++++----
>  1 file changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 8fe22abb1e10..411c0eb4c00e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -330,19 +330,47 @@ struct drm_display_info {
>  
>  #define DRM_BUS_FLAG_DE_LOW		(1<<0)
>  #define DRM_BUS_FLAG_DE_HIGH		(1<<1)
> -/* drive data on pos. edge */
> +
> +/*
> + * Don't use those two flags directly, use the DRM_BUS_FLAG_PIXDATA_DRIVE_*
> + * and DRM_BUS_FLAG_PIXDATA_SAMPLE_* variants to qualify the flags explicitly.
> + * The DRM_BUS_FLAG_PIXDATA_SAMPLE_* flags are defined as the opposite of the
> + * DRM_BUS_FLAG_PIXDATA_DRIVE_* flags to make code simpler, as signals are
> + * usually to be sampled on the opposite edge of the driving edge.
> + */
>  #define DRM_BUS_FLAG_PIXDATA_POSEDGE	(1<<2)
> -/* drive data on neg. edge */
>  #define DRM_BUS_FLAG_PIXDATA_NEGEDGE	(1<<3)
> +
> +/* Drive data on rising edge */
> +#define DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE	DRM_BUS_FLAG_PIXDATA_POSEDGE
> +/* Drive data on falling edge */
> +#define DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE	DRM_BUS_FLAG_PIXDATA_NEGEDGE
> +/* Sample data on rising edge */
> +#define DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE	DRM_BUS_FLAG_PIXDATA_NEGEDGE
> +/* Sample data on falling edge */
> +#define DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE	DRM_BUS_FLAG_PIXDATA_POSEDGE
> +
>  /* data is transmitted MSB to LSB on the bus */
>  #define DRM_BUS_FLAG_DATA_MSB_TO_LSB	(1<<4)
>  /* data is transmitted LSB to MSB on the bus */
>  #define DRM_BUS_FLAG_DATA_LSB_TO_MSB	(1<<5)
> -/* drive sync on pos. edge */
> +
> +/*
> + * Similarly to the DRM_BUS_FLAG_PIXDATA_* flags, don't use these two flags
> + * directly, use one of the DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_* instead.
> + */
>  #define DRM_BUS_FLAG_SYNC_POSEDGE	(1<<6)
> -/* drive sync on neg. edge */
>  #define DRM_BUS_FLAG_SYNC_NEGEDGE	(1<<7)
>  
> +/* Drive sync on rising edge */
> +#define DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE		DRM_BUS_FLAG_SYNC_POSEDGE
> +/* Drive sync on falling edge */
> +#define DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE		DRM_BUS_FLAG_SYNC_NEGEDGE
> +/* Sample sync on rising edge */
> +#define DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE	DRM_BUS_FLAG_SYNC_NEGEDGE
> +/* Sample sync on falling edge */
> +#define DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE	DRM_BUS_FLAG_SYNC_POSEDGE
> +
>  	/**
>  	 * @bus_flags: Additional information (like pixel signal polarity) for
>  	 * the pixel data on the bus, using DRM_BUS_FLAGS\_ defines.
> 

-- 
Regards
--
Kieran

  reply	other threads:[~2019-04-24  8:15 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 23:23 [PATCH/RFC 00/15] R-Car DU: LVDS dual-link mode support Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 01/15] drm: Clarify definition of the DRM_BUS_FLAG_(PIXDATA|SYNC)_* macros Laurent Pinchart
2019-04-24  8:15   ` Kieran Bingham [this message]
2019-03-06 23:23 ` [PATCH/RFC 02/15] drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags Laurent Pinchart
2019-04-24  8:15   ` Kieran Bingham
2019-05-11 20:44     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 03/15] drm/bridge: use bus flags in bridge timings Laurent Pinchart
2019-04-24  8:13   ` Kieran Bingham
2019-03-06 23:23 ` [PATCH/RFC 04/15] drm: bridge: Add dual_link field to the drm_bridge_timings structure Laurent Pinchart
2019-04-24  8:12   ` Kieran Bingham
2019-05-11 20:36     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 05/15] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
2019-03-08 16:49   ` Jacopo Mondi
2019-03-08 17:57     ` Laurent Pinchart
2019-03-09 11:23       ` Jacopo Mondi
2019-03-09 11:51         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 06/15] drm: bridge: thc63: Report input bus mode through bridge timings Laurent Pinchart
2019-03-08 17:32   ` Jacopo Mondi
2019-03-08 18:00     ` Laurent Pinchart
2019-03-09 11:24       ` Jacopo Mondi
2019-03-09 11:45         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 07/15] dt-bindings: display: renesas: lvds: Add renesas,companion property Laurent Pinchart
2019-03-18 10:21   ` Geert Uytterhoeven
2019-03-18 14:22     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 08/15] drm: rcar-du: lvds: Remove LVDS double-enable checks Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 09/15] drm: rcar-du: lvds: Adjust operating frequency for D3 and E3 Laurent Pinchart
2019-03-08 16:28   ` Jacopo Mondi
2019-03-06 23:23 ` [PATCH/RFC 10/15] drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3 Laurent Pinchart
2019-03-08 16:25   ` Jacopo Mondi
2019-03-08 18:07     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 11/15] drm: rcar-du: lvds: Add support for dual-link mode Laurent Pinchart
2019-03-08 17:20   ` Jacopo Mondi
2019-03-08 18:12     ` Laurent Pinchart
2019-03-09 11:11       ` Jacopo Mondi
2019-03-09 11:25         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 12/15] drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 13/15] arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1 Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 14/15] [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 15/15] [HACK] arm64: dts: renesas: ebisu: " Laurent Pinchart

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=827c40e2-5c1f-4a13-4d97-1c4368809c79@ideasonboard.com \
    --to=kieran.bingham@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    /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).