All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Doug Anderson <dianders@chromium.org>, Maxime Ripard <maxime@cerno.tech>
Cc: Sankeerth Billakanti <quic_sbillaka@quicinc.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	freedreno <freedreno@lists.freedesktop.org>
Subject: Re: [RFC PATCH] drm/edid: Make 144 Hz not preferred on Sharp LQ140M1JW46
Date: Thu, 18 Aug 2022 13:31:21 +0300	[thread overview]
Message-ID: <8735dtq1vq.fsf@intel.com> (raw)
In-Reply-To: <CAD=FV=W9sK2dKMnDZmW_ipLGZJFrrvNHz6zHsXVaSCD_u4JpiA@mail.gmail.com>

On Wed, 17 Aug 2022, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Sun, Aug 14, 2022 at 11:46 PM Maxime Ripard <maxime@cerno.tech> wrote:
>>
>> On Fri, Jul 29, 2022 at 12:57:40PM -0700, Doug Anderson wrote:
>> > Hi,
>> >
>> > On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard <maxime@cerno.tech> wrote:
>> > > You raise some good points, but most of the discussion around that patch
>> > > were mostly around performances, power consumption and so on.
>> > >
>> > > This is very much a policy decision, and if there is some panel where
>> > > the EDID reports 60Hz but is broken, then that panel should be the
>> > > exception to the policy
>> > >
>> > > But doing it for a single panel is just odd
>> >
>> > OK, fair enough. I'll abandon this patch at least as far as mainline
>> > is concerned, then.
>>
>> That wasn't really my point though :)
>>
>> If you think that this change is needed, then we should totally discuss
>> it and I'm not opposed to it.
>>
>> What I don't really like about this patch is that it's about a single
>> panel: if we're doing it we should do it for all the panels.
>>
>> Where we do it can also be discussed, but we should remain consistent
>> there.
>
> I was never massively confident about it, which is why I added the
> "RFC" tag to begin with. ;-) In general I suspect that either change
> will make people upset. In other words, if we programmatically always
> try to put the "high refresh rate" first for all displays then people
> will be upset and if we programmatically always try to put the "60 Hz
> rate" first then people will be upset. Unless someone wants to stand
> up and say that one side or the other is wrong, I think we're going to
> simply leave this up to the whim of individual panels. Someone could
> stand up and demand that it go one way or the other, but I certainly
> don't have that clout.
>
> The spec, as far as I can tell, says that it's up to the panel vendor
> to use whatever means they want to decide on the "preferred" refresh
> rate. Thus, as far as the spec is concerned this decision is made on
> an individual panel basis. ;-) This was really the justification for
> why my patch was just on one panel.
>
> In any case, as I said I'm OK w/ dropping this. We'll find other ways
> to work around the issue.

FWIW, if the EDID reported preferred mode works, I also think that's
what we should prefer.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Doug Anderson <dianders@chromium.org>, Maxime Ripard <maxime@cerno.tech>
Cc: Sankeerth Billakanti <quic_sbillaka@quicinc.com>,
	David Airlie <airlied@linux.ie>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	freedreno <freedreno@lists.freedesktop.org>
Subject: Re: [RFC PATCH] drm/edid: Make 144 Hz not preferred on Sharp LQ140M1JW46
Date: Thu, 18 Aug 2022 13:31:21 +0300	[thread overview]
Message-ID: <8735dtq1vq.fsf@intel.com> (raw)
In-Reply-To: <CAD=FV=W9sK2dKMnDZmW_ipLGZJFrrvNHz6zHsXVaSCD_u4JpiA@mail.gmail.com>

On Wed, 17 Aug 2022, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Sun, Aug 14, 2022 at 11:46 PM Maxime Ripard <maxime@cerno.tech> wrote:
>>
>> On Fri, Jul 29, 2022 at 12:57:40PM -0700, Doug Anderson wrote:
>> > Hi,
>> >
>> > On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard <maxime@cerno.tech> wrote:
>> > > You raise some good points, but most of the discussion around that patch
>> > > were mostly around performances, power consumption and so on.
>> > >
>> > > This is very much a policy decision, and if there is some panel where
>> > > the EDID reports 60Hz but is broken, then that panel should be the
>> > > exception to the policy
>> > >
>> > > But doing it for a single panel is just odd
>> >
>> > OK, fair enough. I'll abandon this patch at least as far as mainline
>> > is concerned, then.
>>
>> That wasn't really my point though :)
>>
>> If you think that this change is needed, then we should totally discuss
>> it and I'm not opposed to it.
>>
>> What I don't really like about this patch is that it's about a single
>> panel: if we're doing it we should do it for all the panels.
>>
>> Where we do it can also be discussed, but we should remain consistent
>> there.
>
> I was never massively confident about it, which is why I added the
> "RFC" tag to begin with. ;-) In general I suspect that either change
> will make people upset. In other words, if we programmatically always
> try to put the "high refresh rate" first for all displays then people
> will be upset and if we programmatically always try to put the "60 Hz
> rate" first then people will be upset. Unless someone wants to stand
> up and say that one side or the other is wrong, I think we're going to
> simply leave this up to the whim of individual panels. Someone could
> stand up and demand that it go one way or the other, but I certainly
> don't have that clout.
>
> The spec, as far as I can tell, says that it's up to the panel vendor
> to use whatever means they want to decide on the "preferred" refresh
> rate. Thus, as far as the spec is concerned this decision is made on
> an individual panel basis. ;-) This was really the justification for
> why my patch was just on one panel.
>
> In any case, as I said I'm OK w/ dropping this. We'll find other ways
> to work around the issue.

FWIW, if the EDID reported preferred mode works, I also think that's
what we should prefer.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-08-18 10:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 22:23 [RFC PATCH] drm/edid: Make 144 Hz not preferred on Sharp LQ140M1JW46 Douglas Anderson
2022-07-21 22:23 ` Douglas Anderson
2022-07-22 16:37 ` Abhinav Kumar
2022-07-22 16:37   ` Abhinav Kumar
2022-07-22 16:48   ` Doug Anderson
2022-07-22 16:48     ` Doug Anderson
2022-07-22 17:36     ` Rob Clark
2022-07-22 17:36       ` Rob Clark
2022-07-28 17:34       ` Abhinav Kumar
2022-07-28 17:34         ` Abhinav Kumar
2022-07-28 21:18         ` Doug Anderson
2022-07-28 21:18           ` Doug Anderson
2022-07-29  7:51           ` Maxime Ripard
2022-07-29  7:51             ` Maxime Ripard
2022-07-29 14:50             ` Doug Anderson
2022-07-29 14:50               ` Doug Anderson
2022-07-29 16:41               ` Maxime Ripard
2022-07-29 16:41                 ` Maxime Ripard
2022-07-29 19:57                 ` Doug Anderson
2022-07-29 19:57                   ` Doug Anderson
2022-08-15  6:45                   ` Maxime Ripard
2022-08-15  6:45                     ` Maxime Ripard
2022-08-17 23:45                     ` Doug Anderson
2022-08-17 23:45                       ` Doug Anderson
2022-08-18 10:31                       ` Jani Nikula [this message]
2022-08-18 10:31                         ` Jani Nikula

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=8735dtq1vq.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime@cerno.tech \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_sbillaka@quicinc.com \
    --cc=tzimmermann@suse.de \
    /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.