similar to: [PATCH v2 03/17] drm: Nuke mode->vrefresh

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Get rid of mode->vrefresh and just calculate it on demand. Saves a bit of space and avoids the cached value getting out of sync with reality. Mostly done with cocci, with the following manual fixups: - Remove the now empty loop in drm_helper_probe_single_connector_modes() - Fix __MODE() macro in ch7006_mode.c - Fix DRM_MODE_ARG()

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Get rid of mode->vrefresh and just calculate it on demand. Saves a bit of space and avoids the cached value getting out of sync with reality. Mostly done with cocci, with the following manual fixups: - Remove the now empty loop in drm_helper_probe_single_connector_modes() - Fix __MODE() macro in ch7006_mode.c - Fix DRM_MODE_ARG()

Hi Ville Thanks for the patch. One comment below. Thanks Abhinav On 2020-04-03 13:39, Ville Syrjala wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > Get rid of mode->vrefresh and just calculate it on demand. Saves > a bit of space and avoids the cached value getting out of sync > with reality. > > Mostly done with cocci, with the following

On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > On 19.02.2020 21:35, Ville Syrjala wrote: > > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > > > Get rid of mode->vrefresh and just calculate it on demand. Saves > > a bit of space and avoids the cached value getting out of sync > > with reality. > > > > Mostly done

On 19.02.2020 21:35, Ville Syrjala wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > Get rid of mode->vrefresh and just calculate it on demand. Saves > a bit of space and avoids the cached value getting out of sync > with reality. > > Mostly done with cocci, with the following manual fixups: > - Remove the now empty loop in

On 25.02.2020 12:21, Ville Syrj?l? wrote: > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: >> On 19.02.2020 21:35, Ville Syrjala wrote: >>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com> >>> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves >>> a bit of space and avoids the cached value getting out of

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

Higher layers tend to add a lot of modes not actually in the EDID, such as the standard DMT modes. Changing this would be extremely intrusive to everyone, so just force the scaler more often. There are no practical cases we're aware of where a LVDS/eDP panel has multiple resolutions exposed, and i915 already does it this way. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660

On Sun, 26 May 2019 at 08:41, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > Higher layers tend to add a lot of modes not actually in the EDID, such > as the standard DMT modes. Changing this would be extremely intrusive to > everyone, so just force the scaler more often. There are no practical > cases we're aware of where a LVDS/eDP panel has multiple resolutions >

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 3d1890ef8023e61934e070021b06cc9f417260c0 ] Under certain circumstances, encoder atomic_check() can be entered without adjusted_mode having been reset to the same as mode, which confuses the scaling logic and can lead to a misprogrammed display. Fix this by checking against the user-provided mode directly. Link:

On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote: > On 25.02.2020 12:21, Ville Syrj?l? wrote: > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > >> On 19.02.2020 21:35, Ville Syrjala wrote: > >>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > >>> > >>> Get rid of mode->vrefresh and just

On Fri, 03 Apr 2020, abhinavk at codeaurora.org wrote: > On 2020-04-03 13:39, Ville Syrjala wrote: >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c >> index fec1c33b3045..e3d5f011f7bd 100644 >> --- a/drivers/gpu/drm/drm_modes.c >> +++ b/drivers/gpu/drm/drm_modes.c >> @@ -759,9 +759,7 @@ int drm_mode_vrefresh(const struct drm_display_mode

http://bugs.freedesktop.org/show_bug.cgi?id=25258 Summary: [9400M] KMS and X do not use monitor's native resolution Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

The nv31m in bug 23212 claims its TV-out and LVDS are in the same connector. Ignore it completely as it's otherwise useless. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c

On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj?l? > <ville.syrjala at linux.intel.com> wrote: > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > I have long suspected that a whole bunch of the "simple" displays > > > are not simple but contains a display

Hi, Here I post these 2 misc patches. Best regards, Maxim Levitsky

This is an initial implementation of HDMI 3D mode support for the nouveau kernel driver. It works on all of the hardware that I have available to test at the moment, but I am unsure as to the overall approach taken for setting HDMI InfoFrames, there's no support for g84 or gf119 disps, and the criteria for enabling stereo support for an output seems a bit iffy. The first four patches arrange

I have had my "nv" driver lock up a number of times. I downloaded the "nvidia" drivers and they did not work at 1920x1080 resolution. I am looking for an updated driver for just "nv". I found some once for a different driver that you just update commonXXX and yourdriverXXX not the whole X recompile. Where can I find those drivers? THanks, Jerry --------------

In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Signed-off-by: Ma Ke <make_ruc2021 at 163.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c