dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Sean Paul <seanpaul@chromium.org>
Cc: devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
	"Jeffy Chen" <jeffy.chen@rock-chips.com>,
	"Doug Anderson" <dianders@chromium.org>,
	dri-devel@lists.freedesktop.org,
	"Rob Herring" <robh+dt@kernel.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>
Subject: Re: [PATCH v3 4/6] drm/panel: simple: Add ability to override typical timing
Date: Mon, 19 Feb 2018 16:25:55 +0100	[thread overview]
Message-ID: <20180219152555.GN11455@ulmo> (raw)
In-Reply-To: <20180208174855.55620-5-seanpaul@chromium.org>


[-- Attachment #1.1: Type: text/plain, Size: 6775 bytes --]

On Thu, Feb 08, 2018 at 12:48:51PM -0500, Sean Paul wrote:
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
> 
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
> 
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
> 
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Stéphane Marchesin <marcheu@chromium.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 67 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 66 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 5591984a392b..87488392bca1 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -34,6 +34,7 @@
>  #include <drm/drm_panel.h>
>  
>  #include <video/display_timing.h>
> +#include <video/of_display_timing.h>
>  #include <video/videomode.h>
>  
>  struct panel_desc {
> @@ -87,6 +88,8 @@ struct panel_simple {
>  	struct i2c_adapter *ddc;
>  
>  	struct gpio_desc *enable_gpio;
> +
> +	struct drm_display_mode override_mode;
>  };
>  
>  static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> @@ -99,11 +102,22 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  	struct drm_connector *connector = panel->base.connector;
>  	struct drm_device *drm = panel->base.drm;
>  	struct drm_display_mode *mode;
> +	bool has_override = panel->override_mode.type;
>  	unsigned int i, num = 0;
>  
>  	if (!panel->desc)
>  		return 0;
>  
> +	if (has_override) {
> +		mode = drm_mode_duplicate(drm, &panel->override_mode);
> +		if (mode) {
> +			drm_mode_probed_add(connector, mode);
> +			num++;
> +		} else {
> +			dev_err(drm->dev, "failed to add override mode\n");
> +		}
> +	}

Do we really want to continue after this? Shouldn't the override mode
simply override everything else? That is, if users do override the mode,
do we want to give them additional modes to potentially choose from?
Presumably the reason why the user had to override is because the fixed
one didn't work.

Actually, we should only ever have either the display timings specified
or a fixed mode. Anything else is rather bogus.

> +
>  	for (i = 0; i < panel->desc->num_timings; i++) {
>  		const struct display_timing *dt = &panel->desc->timings[i];
>  		struct videomode vm;
> @@ -120,7 +134,7 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  
>  		mode->type |= DRM_MODE_TYPE_DRIVER;
>  
> -		if (panel->desc->num_timings == 1)
> +		if (panel->desc->num_timings == 1 && !has_override)
>  			mode->type |= DRM_MODE_TYPE_PREFERRED;
>  
>  		drm_mode_probed_add(connector, mode);
> @@ -291,10 +305,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
>  	.get_timings = panel_simple_get_timings,
>  };
>  
> +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> +	(to_check->field.typ >= bounds->field.min && \
> +	 to_check->field.typ <= bounds->field.max)
> +static void panel_simple_add_override_mode(struct device *dev,
> +					   struct panel_simple *panel,
> +					   const struct display_timing *ot)
> +{
> +	const struct panel_desc *desc = panel->desc;
> +	struct videomode vm;
> +	int i;

unsigned int, please.

> +
> +	if (desc->num_modes) {
> +		dev_err(dev, "Reject override mode: panel has a fixed mode\n");
> +		return;
> +	}
> +	if (!desc->num_timings) {
> +		dev_err(dev, "Reject override mode: no timings specified\n");
> +		return;
> +	}

Perhaps these should be WARN_ON() to be annoying, but let the driver
continue with the override mode? Again, this is something that we should
catch during review (when a new compatible is added, or a new driver, we
should make sure that it always comes with a timing).

WARN_ON() is probably enough to let people know when they test that they
forgot something.

> +
> +	for (i = 0; i < panel->desc->num_timings; i++) {
> +		const struct display_timing *dt = &panel->desc->timings[i];
> +
> +		if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
> +			continue;
> +
> +		if (ot->flags != dt->flags)
> +			continue;
> +
> +		videomode_from_timing(ot, &vm);
> +		drm_display_mode_from_videomode(&vm, &panel->override_mode);
> +		panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
> +					     DRM_MODE_TYPE_PREFERRED;
> +		return;
> +	}
> +
> +	dev_err(dev, "Reject override mode: No display_timing found\n");

Perhaps something like this, to simplify the code flow:

	if (!panel->override_mode.type)
		dev_err(dev, ...);

Then turn the above return into a break and leave out the below return.

> +	return;
> +}
> +
>  static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  {
>  	struct device_node *backlight, *ddc;
>  	struct panel_simple *panel;
> +	struct display_timing dt;
>  	int err;
>  
>  	panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> @@ -338,6 +400,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  		}
>  	}
>  
> +	if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
> +		panel_simple_add_override_mode(dev, panel, &dt);

Perahps "panel_simple_parse_override_mode()"? To clarify what exactly
this does. This doesn't actually "add" the mode yet, that's only done
in panel_simple_get_fixed_modes().

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-02-19 15:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08 17:48 [PATCH v3 0/6] drm/panel: simple: Add mode support to devicetree Sean Paul
2018-02-08 17:48 ` [PATCH v3 1/6] dt-bindings: Clarify timing subnode use as panel-timing Sean Paul
2018-02-08 18:43   ` Rob Herring
2018-02-19 14:59   ` Thierry Reding
     [not found] ` <20180208174855.55620-1-seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2018-02-08 17:48   ` [PATCH v3 2/6] dt-bindings: Add headings to simple-panel bindings Sean Paul
     [not found]     ` <20180208174855.55620-3-seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2018-02-08 18:44       ` Rob Herring
2018-02-08 17:48   ` [PATCH v3 3/6] dt-bindings: Add panel-timing subnode to simple-panel Sean Paul
     [not found]     ` <20180208174855.55620-4-seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2018-02-08 18:45       ` Rob Herring
2018-02-19 15:09     ` Thierry Reding
2018-03-01 18:47     ` Laurent Pinchart
2018-02-08 17:48   ` [PATCH v3 4/6] drm/panel: simple: Add ability to override typical timing Sean Paul
2018-02-19 14:33     ` Enric Balletbo Serra
2018-02-19 15:25     ` Thierry Reding [this message]
2018-02-08 17:48 ` [PATCH v3 5/6] drm/panel: simple: Use display_timing for lq123p1jx31 Sean Paul
2018-02-19 14:34   ` Enric Balletbo Serra
2018-02-08 17:48 ` [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel Sean Paul
2018-02-19 14:34   ` Enric Balletbo Serra
2018-02-26 18:23   ` Doug Anderson
2018-04-24 14:31     ` Ezequiel Garcia
2018-04-24 23:02       ` Stéphane Marchesin
2018-04-25  4:29       ` Doug Anderson
2018-04-25 12:36         ` Ezequiel Garcia
2018-04-26 12:05     ` Thierry Reding
2018-04-26 15:29       ` Doug Anderson
2018-03-12  8:35 ` [PATCH v3 0/6] drm/panel: simple: Add mode support to devicetree Thierry Reding
2019-03-28 17:28   ` Doug Anderson

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=20180219152555.GN11455@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jeffy.chen@rock-chips.com \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=marcheu@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=seanpaul@chromium.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).