similar to: [PATCH 04/12] 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

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

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

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

Hi, Here is my patch queue I accumulated over quite a long time. Patches 1-6 are bugfixes, and rest is mostly RFC. Comments are welcome. Best regards, Maxim Levitsky

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

On Mon, Feb 27, 2017 at 05:31:04PM -0800, Joe Perches wrote: > 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> I know this is pain, but can you pls split this into: - amd/radeon drivers - drm core (anything

Hi, these are two patches against the nouveau kms driver. The first patch makes sure that pageflip completion events get their vblank count and timestamp from the drm. The second patch from Lucas Stach, here included with his permission, makes sure that the timestamps of vblanks are calculated with high precision and robustness. Both patches together make sure that all timestamps returned by the

From: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Emit kms pageflip completion events with proper vblank count and timestamp for the vblank interval in which the pageflip completed. This makes the timestamps and counts consistent with what the OML_sync_control spec defines. v2 Lucas Stach: rebased on top of nouveau tree and resolved trivial conflict. Signed-off-by: Mario Kleiner

Hi Christian Am 11.05.20 um 19:17 schrieb Christian K?nig: > AGP is deprecated for 10+ years now and not used any more on modern hardware. > > Old hardware should continue to work in PCI mode. > > Signed-off-by: Christian K?nig <christian.koenig at amd.com> > --- > drivers/gpu/drm/radeon/Makefile | 4 +- > drivers/gpu/drm/radeon/evergreen.c | 7 -

Hi guys, Well let's face it AGP is a total headache to maintain and dead for at least 10+ years. We have a lot of x86 specific stuff in the architecture independent graphics memory management to get the caching right, abusing the DMA API on multiple occasions, need to distinct between AGP and driver specific page tables etc etc... So the idea here is to just go ahead and remove the support

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