From: Linus Walleij <linus.walleij@linaro.org>
To: Stefan Agner <stefan@agner.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Dave Airlie <airlied@linux.ie>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Philipp Zabel <p.zabel@pengutronix.de>,
Sascha Hauer <kernel@pengutronix.de>,
Fabio Estevam <fabio.estevam@nxp.com>,
NXP Linux Team <linux-imx@nxp.com>,
Archit Taneja <architt@codeaurora.org>,
Andrzej Hajda <a.hajda@samsung.com>,
Gustavo Padovan <gustavo@padovan.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
sean@poorly.run, Marcel Ziswiler <marcel.ziswiler@toradex.com>,
max.krummenacher@toradex.com,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/6] drm/bridge: use bus flags in bridge timings
Date: Thu, 6 Sep 2018 13:07:41 +0200 [thread overview]
Message-ID: <CACRpkdbw0VjkHYcUpox+DorRG0oRdPARL4ShgPfV2eFaUF_w0g@mail.gmail.com> (raw)
In-Reply-To: <a00c1650b69ba85bed7ae39b81a0c40f@agner.ch>
On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner <stefan@agner.ch> wrote:
> On 05.09.2018 00:44, Laurent Pinchart wrote:
> Good point! I actually really don't like that we use the same flags here
> but from a different perspective. Especially since the flags defines
> document things differently:
>
> /* drive data on pos. edge */
> #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
> /* drive data on neg. edge */
> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3)
Maybe a stupid comment from my side, but can't we just change the
documentation to match the usecases?
/* Trigger pixel data latch on positive edge */
#define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
> Using the opposite perspective would also need translation in crtc
> drivers... So far no driver uses sampling_edge.
>
> I would prefer if we always use the meaning as documented by the flags.
>
> I guess we would need to convert DRM_BUS_FLAG_PIXDATA_POSEDGE ->
> DRM_BUS_FLAG_PIXDATA_NEGEDGE.
>
> Linus Walleij, you added sampling edge, any thoughts?
I just thought it was generally useful to have triggering edge encoded
into the bridge as it makes it clear that this edge is something
that is a delayed version of the driving edge which is subject to
clock skew caused by the speed of electrons in silicon and
copper and slew rate caused by parasitic capacitance.
Yours,
Linus Walleij
next prev parent reply other threads:[~2018-09-06 11:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 5:21 [PATCH 1/6] drm/bridge: use bus flags in bridge timings Stefan Agner
2018-09-05 5:21 ` [PATCH 2/6] drm/bridge: allow to specify data-enable polarity Stefan Agner
2018-09-05 5:21 ` [PATCH 3/6] dt-bindings: display: add data-enable polarity property Stefan Agner
2018-09-05 7:07 ` Laurent Pinchart
2018-09-05 18:10 ` Stefan Agner
2018-09-05 20:50 ` Laurent Pinchart
2018-09-05 5:21 ` [PATCH 4/6] drm/imx: support handling bridge timings bus flags Stefan Agner
2018-09-05 5:21 ` [PATCH 5/6] ARM: dts: imx6qdl-apalis: add VGA support Stefan Agner
2018-09-05 5:21 ` [PATCH 6/6] ARM: dts: imx6qdl-apalis: add GPIO I2C node for DDC Stefan Agner
2018-09-05 7:06 ` [PATCH 1/6] drm/bridge: use bus flags in bridge timings Laurent Pinchart
2018-09-05 7:44 ` Laurent Pinchart
2018-09-05 18:32 ` Stefan Agner
2018-09-06 11:07 ` Linus Walleij [this message]
2018-09-06 12:25 ` Laurent Pinchart
2018-09-06 16:48 ` Stefan Agner
2018-09-06 16:54 ` Laurent Pinchart
2018-09-06 17:27 ` Stefan Agner
2018-09-06 20:25 ` Stefan Agner
2018-09-07 7:10 ` Linus Walleij
2018-09-07 18:25 ` Stefan Agner
2018-09-14 9:55 ` Laurent Pinchart
2018-09-14 9:49 ` Laurent Pinchart
2018-09-14 9:57 ` Laurent Pinchart
2018-09-19 7:03 ` Stefan Agner
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=CACRpkdbw0VjkHYcUpox+DorRG0oRdPARL4ShgPfV2eFaUF_w0g@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=architt@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=fabio.estevam@nxp.com \
--cc=gustavo@padovan.org \
--cc=kernel@pengutronix.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marcel.ziswiler@toradex.com \
--cc=mark.rutland@arm.com \
--cc=max.krummenacher@toradex.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=sean@poorly.run \
--cc=shawnguo@kernel.org \
--cc=stefan@agner.ch \
/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).