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
next prev parent 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).