All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Boichat <drinkcat@chromium.org>
To: Xin Ji <xji@analogixsemi.com>
Cc: devel@driverdev.osuosl.org,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	lkml <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Sheng Pan <span@analogixsemi.com>
Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Date: Thu, 23 Apr 2020 19:55:15 +0800	[thread overview]
Message-ID: <CANMq1KBfB6tXFqYGvr=8fV_bpCV5GbVHeEbRs+fuaZba65-OPw@mail.gmail.com> (raw)
In-Reply-To: <a81adcf2e79d440edcb7b3989f31efcb80a6e9ff.1582529411.git.xji@analogixsemi.com>

Hi,

Just commenting on the mode_fixup function that was added in v7.

On Tue, Feb 25, 2020 at 2:15 PM Xin Ji <xji@analogixsemi.com> wrote:
>
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
> to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
>
> Signed-off-by: Xin Ji <xji@analogixsemi.com>
> ---
>  drivers/gpu/drm/bridge/Makefile           |    2 +-
>  drivers/gpu/drm/bridge/analogix/Kconfig   |    6 +
>  drivers/gpu/drm/bridge/analogix/Makefile  |    1 +
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 2172 +++++++++++++++++++++++++++++
>  drivers/gpu/drm/bridge/analogix/anx7625.h |  410 ++++++
>  5 files changed, 2590 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
>
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf..bcd388a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
[snip]
> +static bool anx7625_bridge_mode_fixup(struct drm_bridge *bridge,
> +                                     const struct drm_display_mode *mode,
> +                                     struct drm_display_mode *adj)
> +{
> +       struct anx7625_data *ctx = bridge_to_anx7625(bridge);
> +       struct device *dev = &ctx->client->dev;
> +       u32 hsync, hfp, hbp, hactive, hblanking;
> +       u32 adj_hsync, adj_hfp, adj_hbp, adj_hblanking, delta_adj;
> +       u32 vref, adj_clock;
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "drm mode fixup set\n");
> +
> +       mutex_lock(&ctx->lock);

Why do you need this lock?

> +
> +       hactive = mode->hdisplay;

This is never used, drop it?

> +       hsync = mode->hsync_end - mode->hsync_start;
> +       hfp = mode->hsync_start - mode->hdisplay;
> +       hbp = mode->htotal - mode->hsync_end;
> +       hblanking = mode->htotal - mode->hdisplay;
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "before mode fixup\n");
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync(%d),hfp(%d),hbp(%d),clock(%d)\n",
> +                            hsync,
> +                            hfp,
> +                            hbp,
> +                            adj->clock);
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync_start(%d),hsync_end(%d),htotal(%d)\n",
> +                            adj->hsync_start,
> +                            adj->hsync_end,
> +                            adj->htotal);
> +
> +       adj_hfp = hfp;
> +       adj_hsync = hsync;
> +       adj_hbp = hbp;
> +       adj_hblanking = hblanking;
> +
> +       /* plus 1 if hfp is odd */

A better way to word these comments is to say "hfp needs to be even",
otherwise, you're just repeating what we can already see in the code.

> +       if (hfp & 0x1) {
> +               adj_hfp = hfp + 1;

adj_hfp -= 1 for consistency?

> +               adj_hblanking += 1;
> +       }
> +
> +       /* minus 1 if hbp is odd */
> +       if (hbp & 0x1) {
> +               adj_hbp = hbp - 1;

ditto, adj_hbp -= 1;

> +               adj_hblanking -= 1;
> +       }
> +
> +       /* plus 1 if hsync is odd */
> +       if (hsync & 0x1) {
> +               if (adj_hblanking < hblanking)
> +                       adj_hsync = hsync + 1;

ditto

> +               else
> +                       adj_hsync = hsync - 1;

ditto

> +       }
> +
> +       /*
> +        * once illegal timing detected, use default HFP, HSYNC, HBP
> +        */
> +       if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) {

should this be adj_hblanking/adj_hfp/adj_hbp?

> +               adj_hsync = SYNC_LEN_DEF;
> +               adj_hfp = HFP_HBP_DEF;
> +               adj_hbp = HFP_HBP_DEF;
> +               vref = adj->clock * 1000 / (adj->htotal * adj->vtotal);
> +               if (hblanking < HBLANKING_MIN) {
> +                       delta_adj = HBLANKING_MIN - hblanking;
> +                       adj_clock = vref * delta_adj * adj->vtotal;
> +                       adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> +               } else {
> +                       delta_adj = hblanking - HBLANKING_MIN;
> +                       adj_clock = vref * delta_adj * adj->vtotal;
> +                       adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> +               }
> +
> +               DRM_WARN("illegal hblanking timing, use default.\n");
> +               DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync);

How likely is it that this mode is going to work? Can you just return
false here to reject the mode?

> +       } else if (adj_hfp < HP_MIN) {
> +               /* adjust hfp if hfp less than HP_MIN */
> +               delta_adj = HP_MIN - adj_hfp;
> +               adj_hfp = HP_MIN;
> +
> +               /*
> +                * balance total HBlanking pixel, if HBP hasn't enough space,

"does not have enough space"

> +                * adjust HSYNC length, otherwize adjust HBP

otherwise

> +                */
> +               if ((adj_hbp - delta_adj) < HP_MIN)
> +                       /* hbp not enough space */
> +                       adj_hsync -= delta_adj;
> +               else
> +                       adj_hbp -= delta_adj;
> +       } else if (adj_hbp < HP_MIN) {
> +               delta_adj = HP_MIN - adj_hbp;
> +               adj_hbp = HP_MIN;
> +
> +               /*
> +                * balance total HBlanking pixel, if HBP hasn't enough space,
> +                * adjust HSYNC length, otherwize adjust HBP
> +                */
> +               if ((adj_hfp - delta_adj) < HP_MIN)
> +                       /* hbp not enough space */
> +                       adj_hsync -= delta_adj;
> +               else
> +                       adj_hfp -= delta_adj;
> +       }
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "after mode fixup\n");
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync(%d),hfp(%d),hbp(%d),clock(%d)\n",

Add spaces after commas in your debug strings (same above and below).

> +                            adj_hsync,
> +                            adj_hfp,
> +                            adj_hbp,
> +                            adj->clock);

Put these 4 on a single line.

> +
> +       /* reconstruct timing */
> +       adj->hsync_start = adj->hdisplay + adj_hfp;
> +       adj->hsync_end = adj->hsync_start + adj_hsync;
> +       adj->htotal = adj->hsync_end + adj_hbp;
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync_start(%d),hsync_end(%d),htotal(%d)\n",
> +                            adj->hsync_start,
> +                            adj->hsync_end,
> +                            adj->htotal);
> +
> +       mutex_unlock(&ctx->lock);
> +
> +       return true;
> +}
> +
> [snip]

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org>
To: Xin Ji <xji@analogixsemi.com>
Cc: devel@driverdev.osuosl.org,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Jonas Karlman <jonas@kwiboo.se>, David Airlie <airlied@linux.ie>,
	Neil Armstrong <narmstrong@baylibre.com>,
	lkml <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Sheng Pan <span@analogixsemi.com>
Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Date: Thu, 23 Apr 2020 19:55:15 +0800	[thread overview]
Message-ID: <CANMq1KBfB6tXFqYGvr=8fV_bpCV5GbVHeEbRs+fuaZba65-OPw@mail.gmail.com> (raw)
In-Reply-To: <a81adcf2e79d440edcb7b3989f31efcb80a6e9ff.1582529411.git.xji@analogixsemi.com>

Hi,

Just commenting on the mode_fixup function that was added in v7.

On Tue, Feb 25, 2020 at 2:15 PM Xin Ji <xji@analogixsemi.com> wrote:
>
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
> to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
>
> Signed-off-by: Xin Ji <xji@analogixsemi.com>
> ---
>  drivers/gpu/drm/bridge/Makefile           |    2 +-
>  drivers/gpu/drm/bridge/analogix/Kconfig   |    6 +
>  drivers/gpu/drm/bridge/analogix/Makefile  |    1 +
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 2172 +++++++++++++++++++++++++++++
>  drivers/gpu/drm/bridge/analogix/anx7625.h |  410 ++++++
>  5 files changed, 2590 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
>
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf..bcd388a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
[snip]
> +static bool anx7625_bridge_mode_fixup(struct drm_bridge *bridge,
> +                                     const struct drm_display_mode *mode,
> +                                     struct drm_display_mode *adj)
> +{
> +       struct anx7625_data *ctx = bridge_to_anx7625(bridge);
> +       struct device *dev = &ctx->client->dev;
> +       u32 hsync, hfp, hbp, hactive, hblanking;
> +       u32 adj_hsync, adj_hfp, adj_hbp, adj_hblanking, delta_adj;
> +       u32 vref, adj_clock;
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "drm mode fixup set\n");
> +
> +       mutex_lock(&ctx->lock);

Why do you need this lock?

> +
> +       hactive = mode->hdisplay;

This is never used, drop it?

> +       hsync = mode->hsync_end - mode->hsync_start;
> +       hfp = mode->hsync_start - mode->hdisplay;
> +       hbp = mode->htotal - mode->hsync_end;
> +       hblanking = mode->htotal - mode->hdisplay;
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "before mode fixup\n");
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync(%d),hfp(%d),hbp(%d),clock(%d)\n",
> +                            hsync,
> +                            hfp,
> +                            hbp,
> +                            adj->clock);
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync_start(%d),hsync_end(%d),htotal(%d)\n",
> +                            adj->hsync_start,
> +                            adj->hsync_end,
> +                            adj->htotal);
> +
> +       adj_hfp = hfp;
> +       adj_hsync = hsync;
> +       adj_hbp = hbp;
> +       adj_hblanking = hblanking;
> +
> +       /* plus 1 if hfp is odd */

A better way to word these comments is to say "hfp needs to be even",
otherwise, you're just repeating what we can already see in the code.

> +       if (hfp & 0x1) {
> +               adj_hfp = hfp + 1;

adj_hfp -= 1 for consistency?

> +               adj_hblanking += 1;
> +       }
> +
> +       /* minus 1 if hbp is odd */
> +       if (hbp & 0x1) {
> +               adj_hbp = hbp - 1;

ditto, adj_hbp -= 1;

> +               adj_hblanking -= 1;
> +       }
> +
> +       /* plus 1 if hsync is odd */
> +       if (hsync & 0x1) {
> +               if (adj_hblanking < hblanking)
> +                       adj_hsync = hsync + 1;

ditto

> +               else
> +                       adj_hsync = hsync - 1;

ditto

> +       }
> +
> +       /*
> +        * once illegal timing detected, use default HFP, HSYNC, HBP
> +        */
> +       if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) {

should this be adj_hblanking/adj_hfp/adj_hbp?

> +               adj_hsync = SYNC_LEN_DEF;
> +               adj_hfp = HFP_HBP_DEF;
> +               adj_hbp = HFP_HBP_DEF;
> +               vref = adj->clock * 1000 / (adj->htotal * adj->vtotal);
> +               if (hblanking < HBLANKING_MIN) {
> +                       delta_adj = HBLANKING_MIN - hblanking;
> +                       adj_clock = vref * delta_adj * adj->vtotal;
> +                       adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> +               } else {
> +                       delta_adj = hblanking - HBLANKING_MIN;
> +                       adj_clock = vref * delta_adj * adj->vtotal;
> +                       adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> +               }
> +
> +               DRM_WARN("illegal hblanking timing, use default.\n");
> +               DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync);

How likely is it that this mode is going to work? Can you just return
false here to reject the mode?

> +       } else if (adj_hfp < HP_MIN) {
> +               /* adjust hfp if hfp less than HP_MIN */
> +               delta_adj = HP_MIN - adj_hfp;
> +               adj_hfp = HP_MIN;
> +
> +               /*
> +                * balance total HBlanking pixel, if HBP hasn't enough space,

"does not have enough space"

> +                * adjust HSYNC length, otherwize adjust HBP

otherwise

> +                */
> +               if ((adj_hbp - delta_adj) < HP_MIN)
> +                       /* hbp not enough space */
> +                       adj_hsync -= delta_adj;
> +               else
> +                       adj_hbp -= delta_adj;
> +       } else if (adj_hbp < HP_MIN) {
> +               delta_adj = HP_MIN - adj_hbp;
> +               adj_hbp = HP_MIN;
> +
> +               /*
> +                * balance total HBlanking pixel, if HBP hasn't enough space,
> +                * adjust HSYNC length, otherwize adjust HBP
> +                */
> +               if ((adj_hfp - delta_adj) < HP_MIN)
> +                       /* hbp not enough space */
> +                       adj_hsync -= delta_adj;
> +               else
> +                       adj_hfp -= delta_adj;
> +       }
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "after mode fixup\n");
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync(%d),hfp(%d),hbp(%d),clock(%d)\n",

Add spaces after commas in your debug strings (same above and below).

> +                            adj_hsync,
> +                            adj_hfp,
> +                            adj_hbp,
> +                            adj->clock);

Put these 4 on a single line.

> +
> +       /* reconstruct timing */
> +       adj->hsync_start = adj->hdisplay + adj_hfp;
> +       adj->hsync_end = adj->hsync_start + adj_hsync;
> +       adj->htotal = adj->hsync_end + adj_hbp;
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync_start(%d),hsync_end(%d),htotal(%d)\n",
> +                            adj->hsync_start,
> +                            adj->hsync_end,
> +                            adj->htotal);
> +
> +       mutex_unlock(&ctx->lock);
> +
> +       return true;
> +}
> +
> [snip]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org>
To: Xin Ji <xji@analogixsemi.com>
Cc: devel@driverdev.osuosl.org,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Jonas Karlman <jonas@kwiboo.se>, David Airlie <airlied@linux.ie>,
	Neil Armstrong <narmstrong@baylibre.com>,
	lkml <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Sheng Pan <span@analogixsemi.com>
Subject: Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Date: Thu, 23 Apr 2020 19:55:15 +0800	[thread overview]
Message-ID: <CANMq1KBfB6tXFqYGvr=8fV_bpCV5GbVHeEbRs+fuaZba65-OPw@mail.gmail.com> (raw)
In-Reply-To: <a81adcf2e79d440edcb7b3989f31efcb80a6e9ff.1582529411.git.xji@analogixsemi.com>

Hi,

Just commenting on the mode_fixup function that was added in v7.

On Tue, Feb 25, 2020 at 2:15 PM Xin Ji <xji@analogixsemi.com> wrote:
>
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
> to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
>
> Signed-off-by: Xin Ji <xji@analogixsemi.com>
> ---
>  drivers/gpu/drm/bridge/Makefile           |    2 +-
>  drivers/gpu/drm/bridge/analogix/Kconfig   |    6 +
>  drivers/gpu/drm/bridge/analogix/Makefile  |    1 +
>  drivers/gpu/drm/bridge/analogix/anx7625.c | 2172 +++++++++++++++++++++++++++++
>  drivers/gpu/drm/bridge/analogix/anx7625.h |  410 ++++++
>  5 files changed, 2590 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
>  create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
>
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf..bcd388a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
[snip]
> +static bool anx7625_bridge_mode_fixup(struct drm_bridge *bridge,
> +                                     const struct drm_display_mode *mode,
> +                                     struct drm_display_mode *adj)
> +{
> +       struct anx7625_data *ctx = bridge_to_anx7625(bridge);
> +       struct device *dev = &ctx->client->dev;
> +       u32 hsync, hfp, hbp, hactive, hblanking;
> +       u32 adj_hsync, adj_hfp, adj_hbp, adj_hblanking, delta_adj;
> +       u32 vref, adj_clock;
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "drm mode fixup set\n");
> +
> +       mutex_lock(&ctx->lock);

Why do you need this lock?

> +
> +       hactive = mode->hdisplay;

This is never used, drop it?

> +       hsync = mode->hsync_end - mode->hsync_start;
> +       hfp = mode->hsync_start - mode->hdisplay;
> +       hbp = mode->htotal - mode->hsync_end;
> +       hblanking = mode->htotal - mode->hdisplay;
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "before mode fixup\n");
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync(%d),hfp(%d),hbp(%d),clock(%d)\n",
> +                            hsync,
> +                            hfp,
> +                            hbp,
> +                            adj->clock);
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync_start(%d),hsync_end(%d),htotal(%d)\n",
> +                            adj->hsync_start,
> +                            adj->hsync_end,
> +                            adj->htotal);
> +
> +       adj_hfp = hfp;
> +       adj_hsync = hsync;
> +       adj_hbp = hbp;
> +       adj_hblanking = hblanking;
> +
> +       /* plus 1 if hfp is odd */

A better way to word these comments is to say "hfp needs to be even",
otherwise, you're just repeating what we can already see in the code.

> +       if (hfp & 0x1) {
> +               adj_hfp = hfp + 1;

adj_hfp -= 1 for consistency?

> +               adj_hblanking += 1;
> +       }
> +
> +       /* minus 1 if hbp is odd */
> +       if (hbp & 0x1) {
> +               adj_hbp = hbp - 1;

ditto, adj_hbp -= 1;

> +               adj_hblanking -= 1;
> +       }
> +
> +       /* plus 1 if hsync is odd */
> +       if (hsync & 0x1) {
> +               if (adj_hblanking < hblanking)
> +                       adj_hsync = hsync + 1;

ditto

> +               else
> +                       adj_hsync = hsync - 1;

ditto

> +       }
> +
> +       /*
> +        * once illegal timing detected, use default HFP, HSYNC, HBP
> +        */
> +       if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp < HP_MIN)) {

should this be adj_hblanking/adj_hfp/adj_hbp?

> +               adj_hsync = SYNC_LEN_DEF;
> +               adj_hfp = HFP_HBP_DEF;
> +               adj_hbp = HFP_HBP_DEF;
> +               vref = adj->clock * 1000 / (adj->htotal * adj->vtotal);
> +               if (hblanking < HBLANKING_MIN) {
> +                       delta_adj = HBLANKING_MIN - hblanking;
> +                       adj_clock = vref * delta_adj * adj->vtotal;
> +                       adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> +               } else {
> +                       delta_adj = hblanking - HBLANKING_MIN;
> +                       adj_clock = vref * delta_adj * adj->vtotal;
> +                       adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> +               }
> +
> +               DRM_WARN("illegal hblanking timing, use default.\n");
> +               DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp, hsync);

How likely is it that this mode is going to work? Can you just return
false here to reject the mode?

> +       } else if (adj_hfp < HP_MIN) {
> +               /* adjust hfp if hfp less than HP_MIN */
> +               delta_adj = HP_MIN - adj_hfp;
> +               adj_hfp = HP_MIN;
> +
> +               /*
> +                * balance total HBlanking pixel, if HBP hasn't enough space,

"does not have enough space"

> +                * adjust HSYNC length, otherwize adjust HBP

otherwise

> +                */
> +               if ((adj_hbp - delta_adj) < HP_MIN)
> +                       /* hbp not enough space */
> +                       adj_hsync -= delta_adj;
> +               else
> +                       adj_hbp -= delta_adj;
> +       } else if (adj_hbp < HP_MIN) {
> +               delta_adj = HP_MIN - adj_hbp;
> +               adj_hbp = HP_MIN;
> +
> +               /*
> +                * balance total HBlanking pixel, if HBP hasn't enough space,
> +                * adjust HSYNC length, otherwize adjust HBP
> +                */
> +               if ((adj_hfp - delta_adj) < HP_MIN)
> +                       /* hbp not enough space */
> +                       adj_hsync -= delta_adj;
> +               else
> +                       adj_hfp -= delta_adj;
> +       }
> +
> +       DRM_DEV_DEBUG_DRIVER(dev, "after mode fixup\n");
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync(%d),hfp(%d),hbp(%d),clock(%d)\n",

Add spaces after commas in your debug strings (same above and below).

> +                            adj_hsync,
> +                            adj_hfp,
> +                            adj_hbp,
> +                            adj->clock);

Put these 4 on a single line.

> +
> +       /* reconstruct timing */
> +       adj->hsync_start = adj->hdisplay + adj_hfp;
> +       adj->hsync_end = adj->hsync_start + adj_hsync;
> +       adj->htotal = adj->hsync_end + adj_hbp;
> +       DRM_DEV_DEBUG_DRIVER(dev, "hsync_start(%d),hsync_end(%d),htotal(%d)\n",
> +                            adj->hsync_start,
> +                            adj->hsync_end,
> +                            adj->htotal);
> +
> +       mutex_unlock(&ctx->lock);
> +
> +       return true;
> +}
> +
> [snip]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-04-23 11:55 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-25  6:11 [PATCH v7 0/2] Add initial support for slimport anx7625 Xin Ji
2020-02-25  8:20 ` Xin Ji
2020-02-25  8:20 ` Xin Ji
2020-02-25  8:20 ` Xin Ji
2020-02-25  6:11 ` Xin Ji
2020-02-25  6:11 ` Xin Ji
2020-02-25  6:14 ` [PATCH v7 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding Xin Ji
2020-02-25  6:14   ` Xin Ji
2020-02-25  6:14   ` Xin Ji
2020-02-25  6:15 ` [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver Xin Ji
2020-02-25  6:15   ` Xin Ji
2020-02-25  6:15   ` Xin Ji
2020-04-23 11:55   ` Nicolas Boichat [this message]
2020-04-23 11:55     ` Nicolas Boichat
2020-04-23 11:55     ` Nicolas Boichat
2020-04-24  6:51     ` Xin Ji
2020-04-24  6:51       ` Xin Ji
2020-04-24  6:51       ` Xin Ji
2020-04-24 12:12       ` Nicolas Boichat
2020-04-24 12:12         ` Nicolas Boichat
2020-04-24 12:12         ` Nicolas Boichat
2020-04-28 10:05         ` Daniel Vetter
2020-04-28 10:05           ` Daniel Vetter
2020-04-28 10:05           ` Daniel Vetter
2020-04-30  3:36           ` Xin Ji
2020-04-30  3:36             ` Xin Ji
2020-04-30  3:36             ` Xin Ji
2020-04-30 13:37             ` Daniel Vetter
2020-04-30 13:37               ` Daniel Vetter
2020-04-30 13:37               ` Daniel Vetter
2020-04-30 13:38               ` Daniel Vetter
2020-04-30 13:38                 ` Daniel Vetter
2020-04-30 13:38                 ` Daniel Vetter
2020-04-30 13:47                 ` Xin Ji
2020-04-30 13:47                   ` Xin Ji
2020-04-30 13:54                   ` Daniel Vetter
2020-04-30 13:54                     ` Daniel Vetter
2020-04-30 13:58                     ` Xin Ji
2020-04-30 13:58                       ` Xin Ji
2020-02-25  7:42 ` [PATCH v7 0/2] Add initial support for slimport anx7625 Dan Carpenter
2020-02-25  7:42   ` Dan Carpenter
2020-02-25  7:42   ` Dan Carpenter
2020-02-25  8:11   ` Xin Ji
2020-02-25  8:11     ` Xin Ji
2020-02-25  8:11     ` Xin Ji

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='CANMq1KBfB6tXFqYGvr=8fV_bpCV5GbVHeEbRs+fuaZba65-OPw@mail.gmail.com' \
    --to=drinkcat@chromium.org \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel@ffwll.ch \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=pihsun@chromium.org \
    --cc=span@analogixsemi.com \
    --cc=xji@analogixsemi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.