[PATCH v2 14/17] drm/i915: Replace I915_MODE_FLAG_INHERITED with a boolean

From: Ville Syrjälä There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag anymore. Just make it a boolean. CC: Sam Ravnborg Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_atomic.c | 2 +- drivers/gpu/drm/i915/display

[PATCH v2 16/17] drm: Nuke mode->private_flags

From: Ville Syrjälä The last two uses of mode->private_flags (in i915 and gma500) are now gone. So let's remove mode->private_flags entirely. CC: Sam Ravnborg Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h | 10 -- 1 file changed, 10 dele

[PATCH v2 15/17] drm/gma500: Stop using mode->private_flags

From: Ville Syrjälä gma500 only uses mode->private_flags to convey the sdvo pixel multiplier from the encoder .mode_fixup() hook to the encoder .mode_set() hook. Those always seems get called as a pair so let's just stuff the pixel multiplier into the encoder itself as there are no state objects

[PATCH v2 17/17] drm: Replace mode->export_head with a boolean

From: Ville Syrjälä In order to shrink drm_display_mode below the magic two cacheline mark in 64bit we need to shrink it by another 8 bytes. The easiest thing to eliminate is the 'export_head' list head which is only used during the getconnector ioctl to temporarly track which modes on the connec

[PATCH v2 11/17] drm: pahole struct drm_display_mode

From: Ville Syrjälä Reorganize drm_display_mode to eliminate all the holes. We'll put all the actual timings to the start of the struct and all the extra junk to the end. Gets the size down to 136 bytes on 64bit and 120 bytes on 32bit. With a bit more work we should be able to get this below the

[PATCH v2 04/17] drm/msm/dpu: Stop copying around mode->private_flags

From: Ville Syrjälä The driver never sets mode->private_flags so copying it back and forth is entirely pointless. Stop doing it. Also drop private_flags from the tracepoint. Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Reviewed-by: Emil Vel

[PATCH v2 06/17] drm: Shrink mode->type to u8

From: Ville Syrjälä We only have 7 bits defined for mode->type. Shrink the storage to u8. Reviewed-by: Emil Velikov Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_modes.h

[PATCH v2 08/17] drm: Shrink drm_display_mode timings

From: Ville Syrjälä Store the timings (apart from the clock) as u16. The uapi mode struct already uses u16 for everything so using something bigger internally doesn't really help us. Reviewed-by: Emil Velikov Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_mod

[PATCH v2 13/17] drm/i915: Stop using mode->private_flags

From: Ville Syrjälä Replace the use of mode->private_flags with a truly private bitmaks in our own crtc state. We also need a copy in the crtc itself so the vblank code can get at it. We already have scanline_offset in there for a similar reason, as well as the vblank->hwmode which is assigned vi

[PATCH v2 09/17] drm: Flatten drm_mode_vrefresh()

From: Ville Syrjälä Remove the pointless whole-function indentation. Also don't need to worry about negative values anymore since we switched everything to u16. Reviewed-by: Emil Velikov Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 26 -- 1 file chang

[PATCH v2 07/17] drm: Make mode->flags u32

From: Ville Syrjälä The mode flags are direclty exposed in the uapi as u32. Use the same size type to store them internally. Reviewed-by: Emil Velikov Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_m

[PATCH v2 12/17] drm/mcde: Use mode->clock instead of reverse calculating it from the vrefresh

From: Ville Syrjälä htotal*vtotal*vrefresh ~= clock. So just say "clock" when we mean it. Cc: Linus Walleij Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/mcde/mcde_dsi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c

[PATCH v2 01/17] drm: Nuke mode->hsync

From: Ville Syrjälä Let's just calculate the hsync rate on demand. No point in wasting space storing it and risking the cached value getting out of sync with reality. v2: Move drm_mode_hsync() next to its only users Drop the TODO Reviewed-by: Emil Velikov #v1 Signed-off-by: Ville Syrjälä

[PATCH v2 10/17] drm: Shrink mode->private_flags

From: Ville Syrjälä gma500 needs 4 bits (to store a pixel multiplier) in the mode->private_flags, i915 currently has three bits defined. No one else uses this. Reduce the size to u8. Reviewed-by: Emil Velikov Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h | 2 +- 1 file changed, 1 i

[PATCH v2 02/17] drm/i915: Introduce some local intel_dp variables

From: Ville Syrjälä The drrs code dereferences mode->vrefresh via some really long chain of structures/pointers. Couldn't get coccinelle to see through all that so let's add some local variables to help it. Reviewed-by: Emil Velikov Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/displa

[PATCH v2 00/17] drm: Put drm_display_mode on diet

From: Ville Syrjälä Refreshed version of the mode diet. New unseen stuff at the end: - Nuke private_flags entirely - Replace export_head with a bool to shrink the struct below the magic two cachelines I kept the intermediate "shrink private_flags to u8" step because I didn't want to redo the

[PATCH v2 05/17] drm: Shrink {width,height}_mm to u16

From: Ville Syrjälä Instead of supporting ~2000km wide displayes let's limit ourselves to ~65m. That seems plenty big enough to me. Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to 10*0xfff which fits into the 16 bits. Reviewed-by: Emil Velikov Signed-off-by: Ville Syrjälä ---

[PATCH] drm: Skip drm_mode_config_validate() for !modeset

From: Ville Syrjälä drm_mode_config_init() may not have been called when the driver/device doesn't support modeset. That will cause drm_mode_config_validate() to oops. Skip the validation for !modeset. TODO: We may want to consider calling drm_mode_config_init() unconditionally to avoid similar

[PATCH] drm: Reject dumb buffers when driver/device doesn't support modesetting

From: Ville Syrjälä Currently a driver must not provide a .dumb_create() hook in the drm_driver structure if it wants to declare dumb buffers as not supported. So if the same driver wants to support both modeset and non-modeset devices it would require two distinct drm_driver structures in order

[PATCH 1/9] drm: Constify topology id

From: Ville Syrjälä Make the topology id const since we don't want to change it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_connector.c | 4 ++-- include/drm/drm_connector.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b

[PATCH 2/9] drm/edid: Swap some operands in for_each_displayid_db()

From: Ville Syrjälä A+B on the previous line, B+A on the next line. Brain hurts. Signed-off-by: Ville Syrjälä --- include/drm/drm_displayid.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h index 9d3b745c3107..27bdd2

[PATCH 7/9] drm/edid: Don't include ext block csum in DispID size

From: Ville Syrjälä The EDID extension block checksum byte is not part of the actual DispID data, so don't use it in validate_displayid(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_edid.

[PATCH 9/9] drm/edid: Fix DispID tile parsing for override EDID

From: Ville Syrjälä Currently the DispID tile block gets parsed in drm_get_edid(), which is an odd place for it considering we parse nothing else there. Also this doesn't work for override EDIDs since drm_connector_update_edid_property() refuses to do its job twice in such cases. Thus we never up

[PATCH 5/9] drm/edid: Move validate_displayid() drm_find_displayid_extension()

From: Ville Syrjälä Instead of everyone having to call validate_displayid() let's just have drm_find_displayid_extension() do it for them. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/driver

[PATCH 3/9] drm/edid: Remove idx==1 assumptions from all over the DispID parsing

From: Ville Syrjälä The fact that the DispID starts at byte offset 1 is due to the DispID coming from and EDID extension block (the first byte being the extesion block tag). Instead of hadrdocoding that idx==1 assumptions all over let's just have drm_find_displayid_extension() return it since it

[PATCH 0/9] drm/edid: DisplayID parser fixes

From: Ville Syrjälä I was playing around with the tile stuff a bit and noticed a bunch of issues in the DisplayID parser. This series aims to fix what I found. Ville Syrjälä (9): drm: Constify topology id drm/edid: Swap some operands in for_each_displayid_db() drm/edid: Remove idx==1 assum

[PATCH 4/9] drm/edid: Return DispID length from drm_find_displayid_extension()

From: Ville Syrjälä As with the byte offset (idx) drm_find_displayid_extension() is the only one who actually knows how much data the resulting DispID block can contain. So return the length from therein instead of assuming it's the EDID block length all over. Signed-off-by: Ville Syrjälä ---

[PATCH 8/9] drm/edid: Clarify validate_displayid()

From: Ville Syrjälä Throw out the magic '5' from validate_displayid() and replace with the actual thing we mean sizeof(header)+checksum. Also rewrite the checksum loop to be less hard to parse for mere mortals. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 13 - 1 f

[PATCH 6/9] drm/edid: Don't parse garbage as DispID blocks

From: Ville Syrjälä Currently the code assumes that the entire EDID extesion block can be taken up by the DispID blocks. That is not true. There is at least always the DispID checksum, and potentially fill bytes if the extension block uses the interior fill scheme to pad out to fill EDID block si

[PATCH v2 04/33] drm/panel-ilitek-ili9322: Fix dotclocks

From: Ville Syrjälä The listed dotclocks are two orders of mangnitude out. Fix them. v2: Just divide everything by 100 (Linus) Cc: Linus Walleij Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 +++--- 1 file changed, 7 insertions

[PATCH v2 01/33] drm/panel-novatek-nt35510: Fix dotclock

From: Ville Syrjälä The dotclock is three orders of magnitude out. Fix it. v2: Just set it to 20MHz (Linus) Cc: Linus Walleij Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/d

[PATCH 28/33] drm/panel-simple: Fix dotclock for Sharp LQ150X1LG11

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Gustaf Lindström Cc: Peter Rosin Cc: Thierry Reding Signed-off-by: Vill

[PATCH 30/33] drm/panel-simple: Fix dotclock for TPK U.S.A. LLC Fusion

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Bhuvanchandra DV Cc: Rob Herring Cc: Thierry Reding Signed-off-by: Vill

[PATCH 31/33] drm/panel-simple: Fix dotclock for XT VL050-8048NT-C01

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Fabio Estevam Cc: Sam Ravnborg Cc: Thierry Reding Signed-off-by: Ville

[PATCH 21/33] drm/panel-simple: Fix dotclock for Logic PD Type 28

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Adam Ford Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- drivers/gp

[PATCH 24/33] drm/panel-simple: Fix dotclock for Ortustech COM37H3M

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: H. Nikolaus Schaller Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä ---

[PATCH 25/33] drm/panel-simple: Fix dotclock for PDA 91-00156-A0

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Eugen Hristev Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- driv

[PATCH 19/33] drm/panel-simple: Fix dotclock for Innolux AT070TN92

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Riccardo Bortolato Cc: Boris Brezillon Cc: Thierry Reding Signed-off-by

[PATCH 32/33] drm/panel-simple: Fix dotclock for LG LH500WX1-SD03

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Alexandre Courbot Cc: Thierry Reding Signed-off-by: Ville Syrjälä ---

[PATCH 22/33] drm/panel-simple: Fix dotclock for Netron DY E231732

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Maxime Ripard Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- driv

[PATCH 23/33] drm/panel-simple: Fix dotclock for On Tat Industrial Company 7" DPI TFT

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Eric Anholt Cc: Rob Herring Cc: Thierry Reding Signed-off-by: Ville Syr

[PATCH 27/33] drm/panel-simple: Fix dotclock for Sharp LQ035Q7DB03

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Vladimir Zapolskiy Cc: Rob Herring Cc: Thierry Reding Signed-off-by: Vi

[PATCH 33/33] drm/panel-simple: Fix dotclock for LG ACX467AKM-7

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Jonathan Marek Cc: Brian Masney Cc: Linus Walleij Signed-off-by: Ville

[PATCH 29/33] drm/panel-simple: Fix dotclock for Shelly SCA07010-BFN-LNN

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Boris Brezillon Cc: Nicolas Ferre Cc: Thierry Reding Signed-off-by: Vil

[PATCH 26/33] drm/panel-simple: Fix dotclock for QiaoDian qd43003c0-40

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Josh Wu Cc: Alexandre Belloni Cc: Thierry Reding Signed-off-by: Ville S

[PATCH 04/33] drm/panel-ilitek-ili9322: Fix dotclocks

From: Ville Syrjälä The currently listed dotclocks disagree with the currently listed vrefresh rates. Change the dotclocks to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Linus Walleij Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- dr

[PATCH 10/33] drm/panel-simple: Fix dotclock for AUO G104SN02 V2

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Christoph Fritz Cc: Stefan Riedmueller Cc: Rob Herring Cc: Thierry Redi

[PATCH 18/33] drm/panel-simple: Fix dotclock for Giantplus GPG482739QS5

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Philipp Zabel Cc: Lucas Stach Cc: Thierry Reding Signed-off-by: Ville S

[PATCH 20/33] drm/panel-simple: Fix dotclock for LeMaker BL035-RGB-002 3.5" LCD

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Paul Kocialkowski Cc: Thierry Reding Signed-off-by: Ville Syrjälä ---

[PATCH 05/33] drm/panel-leadtek-ltk500hd1829: Fix dotclock

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Heiko Stuebner Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- drive

[PATCH 08/33] drm/panel-sony-acx424akp: Fix dotclocks

From: Ville Syrjälä The currently listed dotclocks disagree with the currently listed vrefresh rates. Change the dotclocks to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Linus Walleij Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- driv

[PATCH 15/33] drm/panel-simple: Fix dotclock for EDT ET035012DM6

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Andreas Pretzsch Cc: Marco Felsch Cc: Thierry Reding Signed-off-by: Vil

[PATCH 11/33] drm/panel-simple: Fix dotclock for CDTech S043WQ26H-CT7

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Giulio Benetti Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- dri

[PATCH 02/33] drm/panel-arm-versatile: Fix dotclock

From: Ville Syrjälä The currently listed dotclocks disagree with the currently listed vrefresh rates. Change the dotclocks to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Linus Walleij Cc: Eric Anholt Signed-off-by: Ville Syrjälä --- drive

[PATCH 03/33] drm/panel-feixin-k101-im2ba02: Fix dotclock

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Icenowy Zheng Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- driver

[PATCH 12/33] drm/panel-simple: Fix dotclock for CDTech S070WV95-CT16

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Giulio Benetti Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- dri

[PATCH 17/33] drm/panel-simple: Fix dotclock for Foxlink FL500WVR00-A0T

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Boris Brezillon Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- dr

[PATCH 07/33] drm/panel-sitronix-st7789v: Fix dotclock

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Maxime Ripard Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- driv

[PATCH 09/33] drm/panel-simple: Fix dotclock for AUO G101EVN010

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Alex Gonzalez Cc: Rob Herring Cc: Thierry Reding Signed-off-by: Ville S

[PATCH 13/33] drm/panel-simple: Fix dotclock for Chunghwa CLAA070WP03XG

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Randy Li Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- drivers/g

[PATCH 06/33] drm/panel-lg-lg4573: Fix dotclock

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Heiko Schocher Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- dri

[PATCH 00/33] drm/panel: Fix dotclocks

From: Ville Syrjälä A lot of the panel drivers put bogus looking values into mode.clock. This series replaces the bogus values with mode.vrefresh*mode.htotal*mode.vtotal. Now, that may not be the right choice in all cases. There are quite a few cases where the error looks very minor and it may b

[PATCH 16/33] drm/panel-simple: Fix dotclock for EDT ET043080DH6-GP

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Marian-Cristian Rotariu Cc: Lad Prabhakar Cc: Sam Ravnborg Signed-off-b

[PATCH 14/33] drm/panel-simple: Fix dotclock for Chunghwa Picture Tubes 10.1" WXGA

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Thierry Reding Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/panel/p

[PATCH 01/33] drm/panel-novatek-nt35510: Fix dotclock

From: Ville Syrjälä The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Linus Walleij Cc: Sam Ravnborg Signed-off-by: Ville Syrjälä --- driver

[PATCH 11/12] drm: Shrink mode->private_flags

From: Ville Syrjälä gma500 needs 4 bits (to store a pixel multiplier) in the mode->private_flags, i915 currently has three bits defined. No one else uses this. Reduce the size to u8. Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 10/12] drm: Flatten drm_mode_vrefresh()

From: Ville Syrjälä Remove the pointless whole-function indentation. Also don't need to worry about negative values anymore since we switched everything to u16. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 26 -- 1 file changed, 12 insertions(+), 14 de

[PATCH 06/12] drm: Shrink {width,height}_mm to u16

From: Ville Syrjälä Instead of supporting ~2000km wide displayes let's limit ourselves to ~65m. That seems plenty big enough to me. Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to 10*0xfff which fits into the 16 bits. Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h |

[PATCH 08/12] drm: Make mode->flags u32

From: Ville Syrjälä The mode flags are direclty exposed in the uapi as u32. Use the same size type to store them internally. Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_modes.h b/include/drm/drm_mo

[PATCH 12/12] drm: pahole struct drm_display_mode

From: Ville Syrjälä Reorganize drm_display_mode to eliminate all the holes. We'll put all the actual timings to the start of the struct and all the extra junk to the end. Gets the size down to 136 bytes on 64bit and 120 bytes on 32bit. With a bit more work we should be able to get this below the

[PATCH 07/12] drm: Shrink mode->type to u8

From: Ville Syrjälä We only have 7 bits defined for mode->type. Shrink the storage to u8. Signed-off-by: Ville Syrjälä --- include/drm/drm_modes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h index 2bb2b1a8592a..5c20285cc

[PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags

From: Ville Syrjälä The driver never sets mode->private_flags so copying it back and forth is entirely pointless. Stop doing it. Also drop private_flags from the tracepoint. Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Ville

[PATCH 09/12] drm: Shrink drm_display_mode timings

From: Ville Syrjälä Store the timings (apart from the clock) as u16. The uapi mode struct already uses u16 for everything so using something bigger internally doesn't really help us. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 7 -- include/drm/drm_modes.h | 46

[PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh

From: Ville Syrjälä htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it. Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-

[PATCH 01/12] drm: Nuke mode->hsync

From: Ville Syrjälä Let's just calculate the hsync rate on demand. No point in wasting space storing it and risking the cached value getting out of sync with reality. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 14 ++ drivers/gpu/drm/i915/display

[PATCH 03/12] drm/i915: Introduce some local intel_dp variables

From: Ville Syrjälä The drrs code dereferences mode->vrefresh via some really long chain of structures/pointers. Couldn't get coccinelle to see through all that so let's add some local variables to help it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 18 +

[PATCH 00/12] drm: Put drm_display_mode on diet

From: Ville Syrjälä struct drm_display_mode is extremely fat. Put it on diet. Some stats for the whole series: 64bit sizeof(struct drm_display_mode): 200 -> 136 bytes (-32%) 64bit bloat-o-meter -c drm.ko: add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) Function

[PATCH v3 7/7] drm: Allow drivers to leave encoder->possible_crtcs==0

From: Ville Syrjälä Let's simplify life of driver by allowing them to leave encoder->possible_crtcs unset if they have no restrictions in crtc<->encoder linkage. We'll just populate possible_crtcs with the full crtc mask when registering the encoder so that userspace doesn't have to deal with dri

[PATCH v3 6/7] drm: Validate encoder->possible_crtcs

From: Ville Syrjälä WARN if the encoder possible_crtcs is effectively empty or contains bits for non-existing crtcs. v2: Move to drm_mode_config_validate() (Daniel) Make the docs say we WARN when this is wrong (Daniel) Extract full_crtc_mask() Cc: Thomas Zimmermann Cc: Daniel Vetter S

[PATCH v3 5/7] drm: Validate encoder->possible_clones

From: Ville Syrjälä Many drivers are populating encoder->possible_clones wrong. Let's persuade them to get it right by adding some loud WARNs. We'll cross check the bits between any two encoders. So either both encoders can clone with the other, or neither can. We'll also complain about effecti

[PATCH v3 3/7] drm/exynos: Use drm_encoder_mask()

From: Ville Syrjälä Replace the hand rolled encoder bitmask thing with drm_encoder_mask() Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Acked-by: Thomas Zimmermann Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++--- 1 file changed, 2 i

[PATCH v3 0/7] drm: Try to fix encoder possible_clones/crtc

From: Ville Syrjälä Another respin of the possible_clones/crtcs fixing. Changes based on v2 review: - introduce drm_mode_config_validate() - WARN for possible_clones!=0 when the encoder itself isn't in the mask - update the documentation to match the code Other changes: - sligth refactoring o

[PATCH v3 2/7] drm/gma500: Sanitize possible_clones

From: Ville Syrjälä I doubt the DP+DP and SDVO+SDVO cloning works for this driver. i915 at least doesn't do those. Truthfully there could be some very specific circumstances where some of them would do doable, but genereally it's too much pain to deal with so we've chose not to bother. Let's use

[PATCH v3 4/7] drm/imx: Remove the bogus possible_clones setup

From: Ville Syrjälä It's not at all clear what cloning options this driver supports. So let's just clear possible_clones instead of setting it to some bogus value. v2: Adjust the FIXME (Daniel) Cc: Philipp Zabel Acked-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/imx/im

[PATCH v3 1/7] drm: Include the encoder itself in possible_clones

From: Ville Syrjälä The docs say possible_clones should always include the encoder itself. Since most drivers don't want to deal with the complexities of cloning let's allow them to set possible_clones=0 and instead we'll fix that up in the core. We can't put this special case into drm_encoder_i

[PATCH v2 1/6] drm: Include the encoder itself in possible_clones

From: Ville Syrjälä The docs say possible_clones should always include the encoder itself. Since most drivers don't want to deal with the complexities of cloning let's allow them to set possible_clones=0 and instead we'll fix that up in the core. We can't put this special case into drm_encoder_i

[PATCH v2 5/6] drm: Validate encoder->possible_clones

From: Ville Syrjälä Many drivers are populating encoder->possible_clones wrong. Let's persuade them to get it right by adding some loud WARNs. We'll cross check the bits between any two encoders. So either both encoders can clone with the other, or neither can. We'll also complain about effecti

[PATCH v2 0/6] drm: Try to fix encoder possible_clones/crtc

From: Ville Syrjälä Remainder of my possible_clones/crtcs cleanup. All the i915 bits and a few other driver bits got merged already. Ville Syrjälä (6): drm: Include the encoder itself in possible_clones drm/gma500: Sanitize possible_clones drm/exynos: Use drm_encoder_mask() drm/imx: Remo

[PATCH v2 2/6] drm/gma500: Sanitize possible_clones

From: Ville Syrjälä I doubt the DP+DP and SDVO+SDVO cloning works for this driver. i915 at least doesn't do those. Truthfully there could be some very specific circumstances where some of them would do doable, but genereally it's too much pain to deal with so we've chose not to bother. Let's use

[PATCH v2 6/6] drm: Validate encoder->possible_crtcs

From: Ville Syrjälä WARN if the encoder possible_crtcs is effectively empty or contains bits for non-existing crtcs. TODO: Or should we perhapst just filter out any bit for a non-exisiting crtc? Cc: Thomas Zimmermann Cc: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_enc

[PATCH v2 4/6] drm/imx: Remove the bogus possible_clones setup

From: Ville Syrjälä It's not at all clear what cloning options this driver supports. So let's just clear possible_clones instead of setting it to some bogus value. Cc: Philipp Zabel Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/imx/imx-drm-core.c | 2 +- 1 file changed, 1 insertion(+), 1 d

[PATCH v2 3/6] drm/exynos: Use drm_encoder_mask()

From: Ville Syrjälä Replace the hand rolled encoder bitmask thing with drm_encoder_mask() Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)

[PATCH 21/26] drm/i915: DP->HDMI TMDS clock limits vs. deep color

From: Ville Syrjälä Account for the TMDS clock limits declared by the DFP/DP++ dongle when determining what color depth we're going to use. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 67 --- drivers/gpu/drm/i915/display/intel_hdmi.c | 50 ++

[PATCH 09/26] drm/i915: Reworkd DFP max bpc handling

From: Ville Syrjälä Stash the downstream facing port max bpc away during intel_dp_set_edid(). We'll soon need the EDID in there so we can't figure this out so easily during .compute_config() anymore. Signed-off-by: Ville Syrjälä --- .../drm/i915/display/intel_display_types.h| 5 + dri

[PATCH 01/26] drm/i915: Nuke pre-production GLK HDMI w/a 1139

From: Ville Syrjälä w/a #1139 is only needed for pre-production GLK. Nuke it. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_hdmi.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.

[PATCH 17/26] drm/i915: Configure DP 1.3+ protocol converted HDMI mode

From: Ville Syrjälä DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion. Let's use that to configure the "HDMI mode" (ie. infoframes vs. not) based on the capabilities of the sink. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + drivers/gpu/d

[PATCH 22/26] drm/dp: Add helpers for DFP YCbCr 4:2:0 handling

From: Ville Syrjälä Add helpers to determine whether the DFP supports YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_dp_helper.c | 44 + include/drm/drm_dp_helper.h | 8 ++ 2 files changed,

[PATCH 18/26] drm/dp: Add drm_dp_downstream_mode()

From: Ville Syrjälä The downstream facing port caps in the DPCD can give us a hint as to what kind of display mode the sink can use if it doesn't have an EDID. Use that information to pick a suitable mode. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_dp_helper.c | 54 ++

[PATCH 24/26] drm/i915: Decouple DP++ from the HDMI code

From: Ville Syrjälä Decouple the DP dual mode adaptor stuff from the HDMI code so that we can try to use it for DP branch downstream facing HDMI ports as well. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- .../drm/i915/display/intel_display_types.h

[PATCH 19/26] drm/i915: Handle downstream facing ports w/o EDID

From: Ville Syrjälä Use drm_dp_downstream_mode() to get a suitable mode for downstream facing ports which don't have an EDID. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu

<    1   2   3   4   5   6   7   8   9   10   >