similar to: [PATCH v3 03/16] drm: Nuke mode->vrefresh

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

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()

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

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

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

On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrj?l? wrote: > 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

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 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:

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

Use a more common logging style. Miscellanea: o Coalesce formats and realign arguments o Neaten a few macros now using pr_<level> Signed-off-by: Joe Perches <joe at perches.com> --- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 ++++----- drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++++++++--------- drivers/gpu/drm/gma500/psb_drv.h | 5 ++---

This patch implements the drivers hooks needed for precise vblank timestamping. This is a complementary patch to Mario Kleiner's patches to to improve swap scheduling. With the complete patchset applied nouveau will be able to provide correct and precise pageflip timestamps (compliant to OML_sync_control spec) Kudos to Mario for his many helpful comments and testing. Signed-off-by: Lucas

I am using xorg-git,mesa-git and xf86-nouveau-git. I noticed that when I turn on compositions (kwin4) there are some problems with screen update, windows,menus are flashing.When I leave from kde to console I got crash.Here is xorg.0.log with crash and the end. [ 4324.923] 1 XSELINUXs still allocated at reset [ 4324.923] TOTAL: 0 objects, 0 bytes, 0 allocs [ 4324.924] 1 CLIENTs still

Hi Ville, Thank you for the patch. On Fri, Apr 03, 2020 at 11:39:54PM +0300, 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:

Hello, I'm new here, and I hope I can get any help. At first I thought this is a support mailing list, but it looks more like one for developers. I'm using Nouveau in ubuntu bionic. My problem is, when I connect a second Monitor to my Laptop on DVI-D connector, the monitor is not detected, Nouveau reports it as "disconnected". The Hardware works, because the BIOS uses the

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

HDMI specification 1.4a, table 8-15 is very explicitly a "must support at least one of" table, not a "must support all of" table. It is not hard to find hardware that does not support some of the so-called "mandatory" modes. More seriously, this code generates invalid display modes for both of the 3D-capable panels that I have (a 42-inch LG TV and a Sony PlayStation