dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Andrzej Hajda <a.hajda@samsung.com>,
	Sean Paul <seanpaul@chromium.org>,
	dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH 01/10] drm/panel: Keep track of enabled/prepared
Date: Fri, 22 Sep 2017 10:47:52 -0700	[thread overview]
Message-ID: <87d16id3qv.fsf@anholt.net> (raw)
In-Reply-To: <a22d36c9-8018-b2bd-f0d5-59793f7eb433@samsung.com>


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

Andrzej Hajda <a.hajda@samsung.com> writes:

> On 21.09.2017 19:06, Sean Paul wrote:
>> This patch adds state tracking to the drm_panel functions which keep
>> track of enabled and prepared. If the calls are unbalanced, a WARNING is
>> issued.
>>
>> The motivation for this change is that a number of panel drivers
>> (including panel-simple) all do this to protect their regulator
>> refcounts. The atomic framework ensures the calls are balanced, and
>> there  aren't any panel drivers being used by legacy drivers. As such,
>> these checks are useless, but let's add a WARNING just in case something
>> crazy happens (like a legacy driver using a panel).
>>
>> Less code == better.
>>
>> Signed-off-by: Sean Paul <seanpaul@chromium.org>
>
> I wonder if the tracking is needed at all, panels power states are
> usually the same as states of encoders they are connected to.
> But it is just remark to consider, no strong opposition :)
>
>> ---
>>  drivers/gpu/drm/drm_panel.c |  2 ++
>>  include/drm/drm_panel.h     | 38 ++++++++++++++++++++++++++++++++++----
>>  2 files changed, 36 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
>> index 308d442a531b..9515219d3d2c 100644
>> --- a/drivers/gpu/drm/drm_panel.c
>> +++ b/drivers/gpu/drm/drm_panel.c
>> @@ -48,6 +48,8 @@ static LIST_HEAD(panel_list);
>>  void drm_panel_init(struct drm_panel *panel)
>>  {
>>  	INIT_LIST_HEAD(&panel->list);
>> +	panel->enabled = false;
>> +	panel->prepared = false;
>>  }
>>  EXPORT_SYMBOL(drm_panel_init);
>>  
>> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
>> index 14ac240a1f64..b9a86a4cf29c 100644
>> --- a/include/drm/drm_panel.h
>> +++ b/include/drm/drm_panel.h
>> @@ -24,6 +24,7 @@
>>  #ifndef __DRM_PANEL_H__
>>  #define __DRM_PANEL_H__
>>  
>> +#include <linux/bug.h>
>>  #include <linux/errno.h>
>>  #include <linux/list.h>
>>  
>> @@ -84,6 +85,8 @@ struct drm_panel_funcs {
>>   * @dev: parent device of the panel
>>   * @funcs: operations that can be performed on the panel
>>   * @list: panel entry in registry
>> + * @enabled: keeps track of the panel enabled status
>> + * @prepared: keeps track of the panel prepared status
>>   */
>>  struct drm_panel {
>>  	struct drm_device *drm;
>> @@ -93,6 +96,9 @@ struct drm_panel {
>>  	const struct drm_panel_funcs *funcs;
>>  
>>  	struct list_head list;
>> +
>> +	bool enabled;
>> +	bool prepared;
>>  };
>>  
>>  /**
>> @@ -104,12 +110,18 @@ struct drm_panel {
>>   * is usually no longer possible to communicate with the panel until another
>>   * call to drm_panel_prepare().
>>   *
>> + * Atomic framework should ensure that prepare/unprepare are properly balanced.
>> + * If this is not the case, a WARNING will be issued.
>> + *
>>   * Return: 0 on success or a negative error code on failure.
>>   */
>>  static inline int drm_panel_unprepare(struct drm_panel *panel)
>>  {
>> -	if (panel && panel->funcs && panel->funcs->unprepare)
>> +	if (panel && panel->funcs && panel->funcs->unprepare) {
>> +		WARN_ON(!panel->prepared);
>
> WARN_ON(!panel->prepared || panel->enabled);
>
> Similar double checks should be used in other places.

I like this idea!  I feel like I've seen enough drivers that didn't
balance prepare/unprepare and enable/disable because for their one panel
they supported it didn't matter.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 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:[~2017-09-22 17:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21 17:06 [PATCH 00/10] drm/panel: Remove unnecessary enabled/prepared state Sean Paul
2017-09-21 17:06 ` [PATCH 01/10] drm/panel: Keep track of enabled/prepared Sean Paul
2017-09-22  7:13   ` Andrzej Hajda
2017-09-22  7:22     ` Andrzej Hajda
2017-09-22 17:47     ` Eric Anholt [this message]
2017-09-26  5:16     ` Daniel Vetter
2017-09-21 17:06 ` [PATCH 02/10] drm/panel: vvx10f034n00: Remove enabled/prepared state Sean Paul
2017-09-21 17:06 ` [PATCH 03/10] drm/panel: lt070me05000: " Sean Paul
2017-09-21 17:06 ` [PATCH 04/10] drm/panel: lq101r1sx01: " Sean Paul
2017-09-21 17:06 ` [PATCH 05/10] drm/panel: otm8009a: Remove enabled state Sean Paul
2017-09-21 17:06 ` [PATCH 06/10] drm/panel: otm8009a: Properly sequence [un]prepare with backlight Sean Paul
2017-09-21 17:06 ` [PATCH 07/10] drm/panel: 43wvf1g: Remove enabled/prepared state Sean Paul
2017-09-21 17:06 ` [PATCH 08/10] drm/panel: simple: " Sean Paul
2017-09-21 17:06 ` [PATCH 09/10] drm/panel: p079zca: " Sean Paul
2017-09-21 17:06 ` [PATCH 10/10] drm/panel: ls043t1le01: " Sean Paul

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=87d16id3qv.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=a.hajda@samsung.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=seanpaul@chromium.org \
    --cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox