[PATCH v2 3/3] Revert "drm/amd/display: Expose connector VRR range via debugfs"

2020-06-24 Thread Manasi Navare
Modem Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Alex Deucher Cc: Manasi Navare Cc: AMD gfx Reviewed-by: Nicholas Kazlauskas --- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 20 --- 1 file changed, 20 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm

[PATCH v4] Revert "drm/amd/display: Expose connector VRR range via debugfs"

2020-06-26 Thread Manasi Navare
-off-by: Bhanuprakash Modem Cc: Nicholas Kazlauskas Cc: Harry Wentland Cc: Alex Deucher Cc: Manasi Navare Cc: AMD gfx Reviewed-by: Nicholas Kazlauskas --- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 20 --- 1 file changed, 20 deletions(-) diff --git a/drivers/gpu/drm/amd

Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support

2018-10-03 Thread Manasi Navare
On Wed, Oct 03, 2018 at 10:41:20AM +0200, Daniel Vetter wrote: > On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote: > > > > > > On 2018-10-01 03:15 AM, Daniel Vetter wrote: > > > On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote: > > >> These patches are part of a p

Re: [PATCH v3 1/4] drm: Add vrr_capable property to the drm connector

2018-10-05 Thread Manasi Navare
variable refresh rate capability for a connector. > + * > + * The value from &drm_connector_state.vrr_capable will reads > + * The sentence above looks incomplete. Other than that this patch looks good to me. So with the kernel doc fixes: Reviewed-by: Manasi Navare Manasi

Re: [PATCH v4 3/4] drm: Document variable refresh properties

2018-10-26 Thread Manasi Navare
On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: > On 10/26/18 10:53 AM, Ville Syrjälä wrote: > > On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote: > >> On 10/26/18 7:37 AM, Pekka Paalanen wrote: > >>> On Thu, 11 Oct 2018 12:39:41 -0400 > >>> Nicholas Kazlau

Re: [PATCH v4 3/4] drm: Document variable refresh properties

2018-10-26 Thread Manasi Navare
On Fri, Oct 26, 2018 at 08:06:11PM +, Kazlauskas, Nicholas wrote: > On 10/26/18 3:13 PM, Manasi Navare wrote: > > On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: > >> On 10/26/18 10:53 AM, Ville Syrjälä wrote: > >>> On Fri, Oct 26, 2018 a

Re: [PATCH v2 3/3] drm/dsc: Split DSC PPS and SDP header initialisations

2019-02-25 Thread Manasi Navare
omponents they operate on, not drm_dsc_pps_infoframe, > > Signed-off-by: David Francis The corresponding changes for the header init and payload init now look good to me. Reviewed-by: Manasi Navare Manasi > --- > drivers/gpu/drm/drm_dsc.c | 117 +++---

Re: [PATCH 1/9] drm: Add variable refresh rate properties to DRM connector

2018-09-11 Thread Manasi Navare
Thanks for the patch, I have meant to send these patches out sitting in my internal tree but never got to it. Find my comments below: On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote: > Modern monitor hardware is capable of supporting variable refresh rates > and adaptive sync

Re: [PATCH 1/9] drm: Add variable refresh rate properties to DRM connector

2018-09-11 Thread Manasi Navare
On Tue, Sep 11, 2018 at 07:22:43PM +0300, Ville Syrjälä wrote: > On Tue, Sep 11, 2018 at 12:13:25PM -0400, Nicholas Kazlauskas wrote: > > Modern monitor hardware is capable of supporting variable refresh rates > > and adaptive sync technologies. The properties for querying and > > controlling these

Re: RFC for a render API to support adaptive sync and VRR

2018-04-09 Thread Manasi Navare
Thanks for initiating the discussion. Find my comments below: On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote: > Adding dri-devel, which I should've included from the start. > > On 2018-04-09 03:56 PM, Harry Wentland wrote: > > === What is adaptive sync and VRR? === > > > > Adapti

Re: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Manasi Navare
On Tue, Apr 10, 2018 at 11:03:02AM -0400, Harry Wentland wrote: > Adding Anthony and Aric who've been working on Freesync with DC on other OSes > for a while. > > On 2018-04-09 05:45 PM, Manasi Navare wrote: > > Thanks for initiating the discussion. Find my comments belo

Re: RFC for a render API to support adaptive sync and VRR

2018-04-20 Thread Manasi Navare
On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: > On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: > > Michel Dänzer writes: > >> Time-based presentation seems to be the right approach for preventing > >> micro-stutter in games as well, Croteam developers have been researching

Re: RFC for a render API to support adaptive sync and VRR

2018-04-23 Thread Manasi Navare
On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote: > On 2018-04-20 04:32 PM, Manasi Navare wrote: > > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: > >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: > >>> Michel Dänzer writes:

Re: [PATCH 1/3] drm/i915: Move dsc rate params compute into drm

2019-02-13 Thread Manasi Navare via amd-gfx
On Wed, Feb 13, 2019 at 09:45:34AM -0500, David Francis wrote: > The function intel_compute_rc_parameters is part of the dsc spec > and is not driver-specific. Other drm drivers might like to use > it. The function is not changed; just moved and renamed. > Yes this sounds fair since its DSC spec

Re: [PATCH 2/3] drm/dsc: Add native 420 and 422 support to compute_rc_params

2019-02-13 Thread Manasi Navare via amd-gfx
eviously called enable422 is renamed to simple_422 to avoid > confusion > > Signed-off-by: David Francis This looks good and verified that the DSC 1.2 spec actually renames it as simple_422. Reviewed-by: Manasi Navare Manasi > --- > drivers/gpu/drm/drm_dsc.c | 31 +

Re: [PATCH 3/3] drm/dsc: Change infoframe_pack to payload_pack

2019-02-13 Thread Manasi Navare via amd-gfx
On Wed, Feb 13, 2019 at 09:45:36AM -0500, David Francis wrote: > The function drm_dsc_pps_infoframe_pack only > packed the payload portion of the infoframe. > Change the input struct to the PPS payload > to clarify the function's purpose and allow > for drivers with their own handling of sdp. > (e.