[PATCH 0/4] drm: Fix MST oopses in fbdev restore

From: Ville Syrjälä <ville.syrj...@linux.intel.com> This series would appear to be enough to avoid kernel oopses when trying to restore the fbdev setup after a MST device has been yanked. Apparently we still have some problems left in actually reacting properly to the changed sit

[PATCH 1/4] drm/fb-helper: Fix connector ref leak on error

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We need to drop the connector references already taken when we abort in the middle of drm_fb_helper_single_add_all_connectors() Cc: stable at vger.kernel.org Cc: Carlos Santa Cc: Kirill A. Shutemov Tested-by: Carlos Santa Tested-by:

[PATCH 2/4] drm/fb-helper: Keep references for the current set of used connectors

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively bein

[PATCH 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The i2c adapter is only relevant for some peer device types, so let's clear the pdt if it's still the same as the old_pdt when we tear down the i2c adapter. I don't really like this design pattern of updating port->whatever bef

[PATCH 4/4] drm/dp/mst: Check peer device type before attempting EDID read

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Only certain types of pdts have the DDC bus registered, so check for that before we attempt the EDID read. Othwewise we risk playing around with an i2c adapter that doesn't actually exist. Cc: stable at vger.kernel.org Cc: Carlos San

[PATCH v2 3/4] drm/dp/mst: Clear port->pdt when tearing down the i2c adapter

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The i2c adapter is only relevant for some peer device types, so let's clear the pdt if it's still the same as the old_pdt when we tear down the i2c adapter. I don't really like this design pattern of updating port->whatever bef

[PATCH v2 2/4] drm/fb-helper: Keep references for the current set of used connectors

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively bein

[PATCH v3 2/4] drm/fb-helper: Keep references for the current set of used connectors

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The fbdev helper code keeps around two lists of connectors. One is the list of all connectors it could use, and that list already holds references for all the connectors. However the other list, or rather lists, is the one actively bein

[PATCH 00/14] drm: Fix a bunch of sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> I got a bit fed up from the sparse noise during a full build, so I tried to shut some of it up. Mostly missing statics or function declarations. I didn't touch the main offender (radeon/amdgpu) since there was enough of this

[PATCH 01/14] drm/atomic-helper: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/drm_atomic_helper.c:1696:6: warning: symbol 'plane_crtc_active' was not declared. Should it be static? Cc: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 2 +- 1 file changed, 1 insertion

[PATCH 02/14] drm/blend: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/drm_blend.c:207:5: warning: symbol 'drm_atomic_normalize_zpos' was not declared. Should it be static? Cc: Marek Szyprowski Cc: Benjamin Gaignard Cc: Laurent Pinchart Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_blend

[PATCH 05/14] drm/ast: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/ast/ast_drv.c:36:5: warning: symbol 'ast_modeset' was not declared. Should it be static? drm/ast/ast_ttm.c:227:22: warning: symbol 'ast_bo_driver' was not declared. Should it be static? Cc: Dave Airlie Signed-off-by: Ville Sy

[PATCH 10/14] drm/nouveau: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/nouveau/dispnv04/overlay.c:496:1: warning: symbol 'nouveau_overlay_init' was not declared. Should it be static? drm/nouveau/nouveau_connector.c:63:5: warning: symbol 'nouveau_hdmimhz' was not declared. Should it be static? drm/n

[PATCH 03/14] drm/fb-helper: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/drm_fb_helper.c:2306:12: warning: symbol 'drm_fb_helper_modinit' was not declared. Should it be static? While at it, move the lefover static inline to the right place. Cc: Daniel Vetter Cc: Sean Paul Signed-off-by: Ville Sy

[PATCH 06/14] drm/bochs: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/bochs/bochs_mm.c:196:22: warning: symbol 'bochs_bo_driver' was not declared. Should it be static? drm/bochs/bochs_kms.c:181:5: warning: symbol 'bochs_connector_get_modes' was not declared. Should it be static? Cc: Gerd Hoffmann

[PATCH 07/14] drm/cirrus: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/cirrus/cirrus_drv.c:18:5: warning: symbol 'cirrus_modeset' was not declared. Should it be static? drm/cirrus/cirrus_ttm.c:227:22: warning: symbol 'cirrus_bo_driver' was not declared. Should it be static? Cc: Dave Airlie Sign

[PATCH 08/14] drm/mgag200: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/mgag200/mgag200_drv.c:24:5: warning: symbol 'mgag200_modeset' was not declared. Should it be static? drm/mgag200/mgag200_ttm.c:227:22: warning: symbol 'mgag200_bo_driver' was not declared. Should it be static? Cc: Dave Airlie

[PATCH 09/14] drm/msm: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c:96:22: warning: symbol 'get_connector' was not declared. Should it be static? drm/msm/mdp/mdp4/mdp4_plane.c:84:5: warning: symbol 'mdp4_plane_set_property' was not declared. Should it be static? d

[PATCH 11/14] drm/rockchip: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/rockchip/rockchip_drm_drv.c:312:6: warning: symbol 'rockchip_drm_fb_suspend' was not declared. Should it be static? drm/rockchip/rockchip_drm_drv.c:321:6: warning: symbol 'rockchip_drm_fb_resume' was not declared. Should it be

[PATCH 12/14] drm/sti: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/sti/sti_mixer.c:361:6: warning: symbol 'sti_mixer_set_matrix' was not declared. Should it be static? drm/sti/sti_gdp.c:476:5: warning: symbol 'sti_gdp_field_cb' was not declared. Should it be static? drm/sti/sti_gdp.c:885:24: w

[PATCH 13/14] drm/sun4i: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/sun4i/sun4i_tv.c:181:21: warning: symbol 'ntsc_video_levels' was not declared. Should it be static? drm/sun4i/sun4i_tv.c:185:21: warning: symbol 'pal_video_levels' was not declared. Should it be static? drm/sun4i/sun4i_tv.c:

[PATCH 14/14] drm/tilcdc: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/tilcdc/tilcdc_tfp410.c:385:24: warning: symbol 'tfp410_driver' was not declared. Should it be static? drm/tilcdc/tilcdc_tfp410.c:395:12: warning: symbol 'tilcdc_tfp410_init' was not declared. Should it be static? drm/tilcdc/tilcdc_

[PATCH 04/14] drm/arm: Fix sparse warnings

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm/arm/malidp_planes.c:49:24: warning: symbol 'malidp_duplicate_plane_state' was not declared. Should it be static? drm/arm/malidp_planes.c:66:6: warning: symbol 'malidp_destroy_plane_state' was not declared. Should it be static? Cc:

[PATCH] drm: Don't force all planes to be added to the state due to zpos

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We don't want all planes to be added to the state whenever a plane with fixed zpos gets enabled/disabled. This is true especially for eg. cursor planes on i915, as we want cursor updates to go through w/o throttling. Same holds for d

[PATCH v2] drm: Don't force all planes to be added to the state due to zpos

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We don't want all planes to be added to the state whenever a plane with fixed zpos gets enabled/disabled. This is true especially for eg. cursor planes on i915, as we want cursor updates to go through w/o throttling. Same holds for d

[PATCH v3 0/6] drm: Per-plane rotation etc.

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Remainder of the patches from the per-plane rotation series [1]. Rebased and also Rob's r-b picked up from [2]. [1] https://lists.freedesktop.org/archives/dri-devel/2016-September/119451.html [2] https://lists.freedesktop.org/archiv

[PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Rob Clark Cc: Jilai Wang Cc: Archit Taneja Signed-off-by: Ville Syrjälä Reviewed-by: Rob Clark --- drive

[PATCH v2 2/6] drm/msm/mdp5: Advertize 180 degree rotation

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Since the hardware can apparently do both X and Y reflection, we can advertize also 180 degree rotation as thats just X+Y reflection. v2: Drop the BIT() Cc: Rob Clark Cc: Jilai Wang Cc: Archit Taneja Signed-off-by: Ville Sy

[PATCH v2 4/6] drm/i915: Use & instead if == to check for rotations

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Using == to check for 180 degree rotation only works as long as the reflection bits aren't set. That will change soon enough for CHV, so let's stop doing things the wrong way. v2: Drop the BIT() Signed-off-by: Ville Syrjälä Re

[PATCH v3 6/6] drm/i915: Add horizontal mirroring support for CHV pipe B planes

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The primary and sprite planes on CHV pipe B support horizontal mirroring. Expose it to the world. Sadly the hardware ignores the mirror bit when the rotate bit is set, so we'll have to reject the 180+X case. v2: Drop the BIT() v3

[PATCH v2 5/6] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Move the plane control register rotation setup away from the coordinate munging code. This will result in neater looking code once we add reflection support for CHV. v2: Drop the BIT(), drop some usless parens, Signed-off-by: Ville Sy

[PATCH v2 3/6] drm: RIP mode_config->rotation_property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Now that all drivers have been converted over to the per-plane rotation property, we can just nuke the global rotation property. v2: Rebase due to BIT(),__builtin_ffs() & co. Deal with superfluous code shuffling Signed-off

[PATCH v2 00/16] drm: drm: Per-plane rotation etc.

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Another, rebased, version of my earlier series [1] to add the per-plane rotation property. One thing holding back the previous version was the weird regression on omap, but apparently I managed to fix it (see [2]). msm and omap still

[PATCH v2 01/15] drm: Add drm_rotation_90_or_270()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We have intel_rotation_90_or_270() in i915 to check if the rotation is 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move the helper into a central place and use it everwhere. v2: Drop the BIT() Convert a

[PATCH v3 03/15] drm: Add support for optional per-plane rotation property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Not all planes on the system may support the same rotations/reflections, so make it possible to create a separate property for each plane. This way userspace gets told exactly which rotations/reflections are possible for each plane. v

[PATCH v2 04/15] drm/arm: Use per-plane rotation property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers Signed-off-by: Ville Syrjälä Acked-by: Brian S

[PATCH v2 06/15] drm/omap: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

From: Ville Syrjälä <ville.syrj...@linux.intel.com> 0 isn't a valid rotation property value, so let's set the initial value of the property to BIT(DRM_ROTATE_0) instead. v2: Drop the BIT() Cc: Tomi Valkeinen Cc: Rob Clark Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/o

[PATCH v3 05/15] drm/atmel-hlcdc: Use per-plane rotation property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Propagate error upwards (Boris) v3: Drop the BIT() Cc: Boris Brezillon Signed-off-by: Ville Syrjälä Acked-by: Boris Bre

[PATCH 02/15] drm/atomic: Reject attempts to use multiple rotation angles at once

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The rotation property should only accept exactly one rotation angle at once. Let's reject attempts to set none or multiple angles. Testcase: igt/kms_rotation_crc/bad-rotation Signed-off-by: Ville Syrjälä Reviewed-by: Joonas La

[PATCH v2 08/15] drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

From: Ville Syrjälä <ville.syrj...@linux.intel.com> 0 isn't a valid rotation property value, so let's set the initial value of the property to BIT(DRM_ROTATE_0) instead. In the same vein, we must always have at leat one angle as part of set of supported rotation bits, so let's i

[PATCH v2 09/15] drm/msm/mdp5: Use per-plane rotation property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Rob Clark Cc: Jilai Wang Cc: Archit Taneja Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/msm/md

[PATCH v2 07/15] drm/omap: Use per-plane rotation property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Not sure I got the annoying crtc rotation_property handling right. Might work, or migth not. v2: Drop the BIT() Don't create ro

[PATCH v3 11/15] drm/i915: Use the per-plane rotation property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> On certain platforms not all planes support the same set of rotations/reflections, so let's use the per-plane property for this. This is already a problem on SKL when we use the legay cursor plane as it only supports 0|180 w

[PATCH v2 14/15] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Move the plane control register rotation setup away from the coordinate munging code. This will result in neater looking code once we add reflection support for CHV. v2: Drop the BIT(), drop some usless parens, Signed-off-by: Ville Sy

[PATCH v2 10/15] drm/msm/mdp5: Advertize 180 degree rotation

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Since the hardware can apparently do both X and Y reflection, we can advertize also 180 degree rotation as thats just X+Y reflection. v2: Drop the BIT() Cc: Rob Clark Cc: Jilai Wang Cc: Archit Taneja Signed-off-by: Ville Sy

[PATCH v2 15/15] drm/i915: Add horizontal mirroring support for CHV pipe B planes

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The primary and sprite planes on CHV pipe B support horizontal mirroring. Expose it to the world. Sadly the hardware ignores the mirror bit when the rotate bit is set, so we'll have to reject the 180+X case. v2: Drop the BIT() Sign

[PATCH v2 13/15] drm/i915: Use & instead if == to check for rotations

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Using == to check for 180 degree rotation only works as long as the reflection bits aren't set. That will change soon enough for CHV, so let's stop doing things the wrong way. v2: Drop the BIT() Signed-off-by: Ville Syrjälä Re

[PATCH v2 12/15] drm: RIP mode_config->rotation_property

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Now that all drivers have been converted over to the per-plane rotation property, we can just nuke the global rotation property. v2: Rebase due to BIT(),__builtin_ffs() & co. Deal with superfluous code shuffling Signed-off

[PATCH v2 00/10] drm/edid: Clean up display_info stuff

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Rebased the series (previous version [1]) mostly due to code shuffling. i915 specific bits still need to be eyeballed by someone. Series available here: git://github.com/vsyrjala/linux.git hdmi_sink_tmds_limit_4 [1]

[PATCH 01/10] drm/edid: Clear old audio latency values before parsing the new EDID

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Clear out stale audio latency information (potentially from a previous EDID) before constructing the ELD from the EDID. Signed-off-by: Ville Syrjälä Acked-by: Christian König --- drivers/gpu/drm/drm_edid.c | 7 +++ 1 file chan

[PATCH v2 03/10] drm/edid: Make max_tmds_clock kHz instead of MHz

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We generally store clocks in kHz, so let's do that for the HDMI max TMDS clock value as well. Less surpising. v2: Deal with superfluous code shuffling Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syr

[PATCH 05/10] drm/edid: Don't pass around drm_display_info needlessly

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We already pass the connector to drm_add_display_info() and drm_assign_hdmi_deep_color_info(), so passing the connector->display_info also is pointless. Signed-off-by: Ville Syrjälä Acked-by: Christian König --- driver

[PATCH 02/10] drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Clear out old max_tmds_clock and dvi_dual information (possibly from a previous EDID) before parsing the current EDID. Tne current EDID might not even have these in its HDMI VSDB, which would mean that we'd leave the old stale values in

[PATCH v2 04/10] drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We have the drm_display_info for storing information about the sink, so let's move dvi_dual and max_tmds_clock in there. v2: Deal with superfluous code shuffling Document dvi_dual and max_tmds_clock too Cc: Alex Deucher Cc: &quo

[PATCH 07/10] drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID

From: Ville Syrjälä <ville.syrj...@linux.intel.com> It's not a good idea to leave stale cea_rev in the drm_display_info. The current EDID might not even have a CEA ext block in which case we'd end up leaving the stale value in place. Signed-off-by: Ville Syrjälä Acked-by: Christian

[PATCH 08/10] drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm_edid_to_eld() is just mean to cook up the ELD for the audio driver, so having it parse non-audio related stuff seems just wrong, and potentially could lead to that information not being even filled out if the function doesn't ev

[PATCH 10/10] drm/i915: Account for sink max TMDS clock when checking the port clock

From: Ville Syrjälä <ville.syrj...@linux.intel.com> It's perfectly legal for the sink to support 12bpc only for some lower resolution modes, while the higher resolution modes can only be used with 8bpc. So let's take the sink's max TMDS clock into account before we go and

[PATCH 06/10] drm/edid: Reduce the number of times we parse the CEA extension block

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Instead of parsing parts of the CEA extension block in two places to determine supported color formats and whatnot, let's just consolidate it to one function. This also makes it possible to neatly flatten drm_assign_hdmi_deep_colo

[PATCH 09/10] drm/i915: Replace a bunch of connector->base.display_info with a local variable

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Reduce the eyesore with a local variable. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_displa

[PATCH libdrm] modetest: Allow the user to specify the plane ID

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Devices can have multiple planes, so allow the user to choose between them. Signed-off-by: Ville Syrjälä --- tests/modetest/modetest.c | 28 ++-- 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a

[PATCH 0/9] drm/i915: SKL+ render decompression support

From: Ville Syrjälä <ville.syrj...@linux.intel.com> This series enables the SKL+ display engine render decompression support. Some bits and pieces of the i915 code are based on work from various people, but I just put my name on it since it would be hard to figure out which parts cam

[PATCH 1/9] drm: Add mode_config .get_format_info() hook

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Allow drivers to return a custom drm_format_info structure for special fb layouts. We'll use this for the compression control surface in i915. v2: Fix drm_get_format_info() kernel doc (Laurent) Don't pass 'dev' to the new hook (L

[PATCH 2/9] drm/i915: Plumb drm_framebuffer into more places

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Now that framebuffers can be used even before calling drm_framebuffer_init() we can start to plumb them into more places, instead of passing individual pieces for fb metadata. Signed-off-by: Ville Syrjälä --- drivers/gpu/dr

[PATCH 3/9] drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Let's try to keep the alignment requirements in one place, and so towards that end let's move the AUX_DIST alignment handling into intel_surf_alignment() alongside the main surface alignment stuff. Signed-off-by: Ville Syrjälä --- d

[PATCH 6/9] drm/i915: Pass the correct plane index to _intel_compute_tile_offset()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> intel_fill_fb_info() should pass the correct plane index to _intel_compute_tile_offset() once we start to care about the AUX surface. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file chan

[PATCH 5/9] drm/i915: Fix Yf tile width

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Based on empirical evidence the display engine (at least) always treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions change based on the pixel format. Let's adjust our code to match the hardware. Signed-off-by:

[PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS

From: Ville Syrjälä <ville.syrj...@linux.intel.com> SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main s

[PATCH 4/9] drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane

From: Ville Syrjälä <ville.syrj...@linux.intel.com> To make life easier let's allow skl_plane_stride() to be called for the AUX surface even when there is no AUX surface. Avoids special cases in the callers. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display

[PATCH 7/9] drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages

From: Ville Syrjälä <ville.syrj...@linux.intel.com> DRM_UT_CORE generates way too much noise usually, so having the framebuffer init failures use DRM_UT_CORE is a pain when trying to find out the reason why you failed in creating a framebuffer. Let's use DRM_UT_KMS for these debug me

[PATCH 9/9] drm/i915: Add render decompression support

From: Ville Syrjälä <ville.syrj...@linux.intel.com> SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main s

[PATCH v2 9/9] drm/i915: Add render decompression support

From: Ville Syrjälä <ville.syrj...@linux.intel.com> SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main s

[PATCH] drm/dp: Allow signals to interrupt drm_aux-dev reads/writes

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Let's be nice and interrupt the dpcd aux-dev reads/writes when there's a signal pending. Much nicer if the user can hit ^C instead of having to sit around waiting for the read/write to finish. time dd if=/dev/drm_dp_aux0 bs=$((1024*102

[PATCH 00/10] drm/edid: Clean up display_info stuff

From: Ville Syrjälä <ville.syrj...@linux.intel.com> This series aims to clean up the way we fill out the display_info structure a bit. Mainly doing a clean separation of the audio and video related bits. My aim is getting i915 to respect the HDMI sink TMDS clock limit (currently we r

[PATCH 01/10] drm/edid: Clear old audio latency values before parsing the new EDID

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Clear out stale audio latency information (potentially from a previous EDID) before constructing the ELD from the EDID. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 7 +++ 1 file changed, 7 insertions(+) diff

[PATCH 02/10] drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Clear out old max_tmds_clock and dvi_dual information (possibly from a previous EDID) before parsing the current EDID. Tne current EDID might not even have these in its HDMI VSDB, which would mean that we'd leave the old stale values in

[PATCH 03/10] drm/edid: Make max_tmds_clock kHz instead of MHz

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We generally store clocks in kHz, so let's do that for the HDMI max TMDS clock value as well. Less surpising. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/amd/amdgpu/amdgpu_

[PATCH 06/10] drm/edid: Reduce the number of times we parse the CEA extension block

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Instead of parsing parts of the CEA extension block in two places to determine supported color formats and whatnot, let's just consolidate it to one function. This also makes it possible to neatly flatten drm_assign_hdmi_deep_colo

[PATCH 04/10] drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We have the drm_display_info for storing information about the sink, so let's move dvi_dual and max_tmds_clock in there. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syrjälä --- drivers/gp

[PATCH 07/10] drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID

From: Ville Syrjälä <ville.syrj...@linux.intel.com> It's not a good idea to leave stale cea_rev in the drm_display_info. The current EDID might not even have a CEA ext block in which case we'd end up leaving the stale value in place. Signed-off-by: Ville Syrjälä --- drivers/g

[PATCH 08/10] drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> drm_edid_to_eld() is just mean to cook up the ELD for the audio driver, so having it parse non-audio related stuff seems just wrong, and potentially could lead to that information not being even filled out if the function doesn't ev

[PATCH 05/10] drm/edid: Don't pass around drm_display_info needlessly

From: Ville Syrjälä <ville.syrj...@linux.intel.com> We already pass the connector to drm_add_display_info() and drm_assign_hdmi_deep_color_info(), so passing the connector->display_info also is pointless. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 11 --

[PATCH 09/10] drm/i915: Replace a bunch of connector->base.display_info with a local variable

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Reduce the eyesore with a local variable. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_displa

[PATCH 10/10] drm/i915: Account for sink max TMDS clock when checking the port clock

From: Ville Syrjälä <ville.syrj...@linux.intel.com> It's perfectly legal for the sink to support 12bpc only for some lower resolution modes, while the higher resolution modes can only be used with 8bpc. So let's take the sink's max TMDS clock into account before we go and

[PATCH v3 3/9] drm/plane-helper: Add drm_plane_helper_check_state()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Add a version of drm_plane_helper_check_update() which takes a plane state instead of having the caller pass in everything. And to reduce code duplication, let's reimplement drm_plane_helper_check_update() in terms of the new fu

[PATCH 0/6] drm/i915: Remaining PSR fixes

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Here's a repost of my PSR fixes, and one straggler from Daniel. One interesting thing I noticed is that my SKL actually hits the PSR setup time vs. vblank length check, so after these patches that machine won't actually use PSR. The

[PATCH v2 1/6] drm/dp: Add drm_dp_psr_setup_time()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Add a small helper to parse the PSR setup time from the DPCD PSR capabilities and return the value in microseconds. v2: Don't waste so many bytes on the psr_setup_time_us[] table Cc: Daniel Vetter Reviewed-by: Daniel Vetter Sign

[PATCH v2 2/6] drm/dp: Add drm_dp_psr_need_train_on_exit()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Add a small helper to parse from the DPCD whether link training is required when exiting PSR main-link off mode. v2: Rebased Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_dp_he

[PATCH 3/6] drm/i915: Check PSR setup time vs. vblank length

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Bspec says: "Restriction : SRD must not be enabled when the PSR Setup time from DPCD 00071h is greater than the time for vertical blank minus one line." Let's check for that and disallow PSR if we exceed the limit. C

[PATCH 4/6] drm/i915/psr: Skip aux handeshake if the vbt tells us to

From: Daniel Vetter Not sure we can trust VBT on this one, but let's try. Cc: Rodrigo Vivi Cc: Sonika Jindal Cc: Durgadoss R Signed-off-by: Daniel Vetter Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_psr.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH 5/6] drm/i915: Ask the sink whether training is required when exiting PSR main-link off mode

From: Ville Syrjälä <ville.syrj...@linux.intel.com> The sink can tell us if link training needs to be performed when exiting PSR main-link off mode. Currently we get that information from the VBT, but at least on my HSW the VBT says one thing, the sink another. And in practice the sink d

[PATCH 6/6] drm/i915: Move psr.link_standby setup to intel_psr_match_conditions()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Determine the value of psr.link_standby at runtime rather than at init time. This helps in testing since you can change between link-off and link-standby at runtime. Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drive

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

From: Ville Syrjälä <ville.syrj...@linux.intel.com> This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135. Adding new mode flags willy nilly breaks existing userspace. We need to coordinate this better, potentially with a new client cap that only exposes the aspect ratio flag

[PATCH 2/2] Revert "drm: Add aspect ratio parsing in DRM layer"

From: Ville Syrjälä <ville.syrj...@linux.intel.com> This reverts commit 6dffd431e2296cda08e7e4f0242e02df1d1698cd. Adding new mode flags willy nilly breaks existing userspace. We need to coordinate this better, potentially with a new client cap that only exposes the aspect ratio flag

[PATCH 1/2] drm/edid: Add the missing "Hz" to VIC 58,59 comment

From: Ville Syrjälä <ville.syrj...@linux.intel.com> All the VICs apart from 58 and 59 have the word "Hz" included in the comment. Include it for 59 and 59 as well. Cc: Shashank Sharma Cc: Andrzej Hajda Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 4 ++--

[PATCH 2/2] drm/edid: Consider alternate cea timings to be the same VIC

From: Ville Syrjälä <ville.syrj...@linux.intel.com> CEA-861 specifies that the vertical front porch may vary by one or two lines for specific VICs. Up to now we've only considered a mode to match the VIC if it matched the shortest possible vertical front porch length (as that is the vari

[PATCH] drm/uapi: Add a warning that mode flags must match the xrandr definitions

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Existing userspace expected the mode flags to match the xrandr definitions 1:1, and even adding new flags in he previously unused bits is likely to break existing userspace. Add a comment warning people about this potential trap. Cc: Sh

[RFC][PATCH] drm: Nuke modifier[1-3]

From: Ville Syrjälä <ville.syrj...@linux.intel.com> It has been suggested that having per-plane modifiers is making life more difficult for userspace, so let's just retire modifier[1-3] and use modifier[0] to apply to the entire framebuffer. Obviosuly this means that if individual plane

[PATCH 00/32] drm: Deduplicate fb format information

From: Ville Syrjälä <ville.syrj...@linux.intel.com> This series aims to remove the duplicated format information stored under drm_framebuffer (depth,bits_per_pixel,pixel_format), and instead we just use the drm_format_info structure. And we store a pointer to the approriate drm_forma

[PATCH 01/32] drm/i915: Add local 'fb' variables

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Add a local 'fb' variable to a few places to get rid of the 'crtc->primary->fb' stuff. Looks neater and helps me with my poor coccinelle skills later. While at it switch over to using the pixel format rather than depth+bpp. C

[PATCH 03/32] drm/radeon: Use DIV_ROUND_UP()

From: Ville Syrjälä <ville.syrj...@linux.intel.com> Use DIV_ROUND_UP() instead of hand rolling it. Just a drive-by change. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 5 ++--- 1 file changed, 2

  1   2   3   4   5   6   7   8   9   10   >