From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Prosyak, Vitaly" <Vitaly.Prosyak@amd.com>,
Daniel Vetter <daniel@ffwll.ch>,
"ajackson@redhat.com" <ajackson@redhat.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: RE: [PATCH] drm/edid : cache edid range limits in drm connector
Date: Wed, 04 May 2016 10:10:39 +0300 [thread overview]
Message-ID: <87futyfgcw.fsf@intel.com> (raw)
In-Reply-To: <CY1PR12MB00287839BF759A5936038190817A0@CY1PR12MB0028.namprd12.prod.outlook.com>
On Wed, 04 May 2016, "Prosyak, Vitaly" <Vitaly.Prosyak@amd.com> wrote:
> We are going to use min/max vertical refresh rate when enter/exit to
> the dynamic refresh rate mode ,it is known as 'freesync', enter/exit
> to full screen games.
As Daniel said, we should see the patch using them too. It's hard to say
whether this is the right thing to do otherwise.
BR,
Jani.
> Right , we may have a helper function which extracts these properties and store wherever need it.
> But this an alternative solution with additional helper adds some code duplication into drm_edid.c since the case already present in the code:
> case 0x01: /* just the ranges, no formula */ Also these values are parsed during each mode enumeration.
>
> Why I put into connector:
> Drm connector have already similar items from EDID: drm_tile_group ,etc...
>
> Vitaly
> -----Original Message-----.
>
> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, May 03, 2016 4:24 PM
> To: Prosyak, Vitaly
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] drm/edid : cache edid range limits in drm connector
>
> On Tue, May 03, 2016 at 11:05:24AM -0400, Vitaly Prosyak wrote:
>> Cache in drm connector the edid range limits properties:
>> min/max vertical refresh rates and max pixel clock.
>> It would be used when enter to drr mode.
>>
>> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
>
> Where's the patches that will use this? It might make sense to instead have some helper functions to compute these values, so that drivers can store them wherever they want/need. But impossible to tell without the users of this stuff.
> -Daniel
>
>> ---
>> drivers/gpu/drm/drm_edid.c | 11 +++++++++++
>> include/drm/drm_crtc.h | 5 +++++
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 04cb487..7e49962 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2190,6 +2190,17 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
>> timing);
>> break;
>> case 0x01: /* just the ranges, no formula */
>> + closure->connector->min_vfreq = range->min_vfreq;
>> + closure->connector->max_vfreq = range->max_vfreq;
>> + if (closure->edid->revision >= 4) {
>> + if ((range->flags & 0x03) == 0x3)
>> + closure->connector->min_vfreq += 255;
>> + if (range->flags & 0x02)
>> + closure->connector->max_vfreq += 255;
>> + }
>> + closure->connector->max_pixel_clock_khz =
>> + range_pixel_clock(closure->edid, (u8 *)timing);
>> + break;
>> default:
>> break;
>> }
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
>> c5b4b81..85fc554 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -1230,6 +1230,11 @@ struct drm_connector {
>> uint8_t num_h_tile, num_v_tile;
>> uint8_t tile_h_loc, tile_v_loc;
>> uint16_t tile_h_size, tile_v_size;
>> +
>> + /*EDID range limits for drr*/
>> + int min_vfreq ;
>> + int max_vfreq ;
>> + int max_pixel_clock_khz;
>> };
>>
>> /**
>> --
>> 1.9.1
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2016-05-04 7:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-03 15:05 [PATCH] drm/edid : cache edid range limits in drm connector Vitaly Prosyak
2016-05-03 15:05 ` [PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4 Vitaly Prosyak
2016-05-03 20:26 ` Daniel Vetter
2016-05-04 13:42 ` Prosyak, Vitaly
2016-05-03 20:26 ` Daniel Vetter
2016-05-04 14:31 ` Jani Nikula
2016-05-03 20:23 ` [PATCH] drm/edid : cache edid range limits in drm connector Daniel Vetter
2016-05-03 20:45 ` Prosyak, Vitaly
2016-05-03 21:01 ` Prosyak, Vitaly
2016-05-04 7:10 ` Jani Nikula [this message]
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=87futyfgcw.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=Alexander.Deucher@amd.com \
--cc=Vitaly.Prosyak@amd.com \
--cc=ajackson@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.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 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.