summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-01-11drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friendsLyude Paul1-52/+62
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/ s/drm_dp_put_port/drm_dp_mst_topology_put_port/ s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/ s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/ This is a much more consistent naming scheme, and will make even more sense once we redesign how the current refcounting scheme here works. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-6-lyude@redhat.com
2019-01-11drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()Lyude Paul1-1/+2
Split some stuff across multiple lines Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-5-lyude@redhat.com
2019-01-11drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi()Lyude Paul1-3/+4
Fix some indenting, split some stuff across multiple lines. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-4-lyude@redhat.com
2019-01-11drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg()Lyude Paul1-6/+8
Split some stuff across multiple lines, remove some unnecessary braces Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-3-lyude@redhat.com
2019-01-11drm/dp_mst: Fix some formatting in drm_dp_add_port()Lyude Paul1-6/+12
Reindent some stuff, and split some stuff across multiple lines so we aren't going over the text width limit. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111005343.17443-2-lyude@redhat.com
2019-01-11drm/rockchip: Add reflection propertiesDaniele Castagna3-0/+38
Add the KMS plane rotation property to the DRM rockchip driver, for SoCs RK3328, RK3368 and RK3399. RK3288 only supports rotation at the display level (i.e. CRTC), but for now we are only interested in plane rotation. This commit only adds support for the value of reflect-y and reflect-x (i.e. mirroring). Note that y-mirroring is not compatible with YUV. The following modetest commands would test this feature, where 30 is the plane ID, and 49 = rotate_0 + relect_y + reflect_x. X mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:17 Y mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:33 XY mirror: modetest -s 43@33:1920x1080@XR24 -w 30:rotation:49 Signed-off-by: Daniele Castagna <dcastagna@chromium.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190109185639.5093-4-ezequiel@collabora.com
2019-01-11drm/rockchip: Separate RK3288 from RK3368 win01 registersEzequiel Garcia1-6/+25
This commit splits the registers for RK3288 from those for RK3328, RK3368 and RK3399. It seems RK3288 does not support plane x-y-mirroring, and so in order to support this for the other SoCs, we need to have separate set of registers for win0 and win1. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190109185639.5093-3-ezequiel@collabora.com
2019-01-11drm/rockchip: Fix typo in VOP macros argumentEzequiel Garcia1-7/+7
Fix a small typo in the macros VOP argument. The macro argument is currently wrongly named "x", and then never used. The code built fine almost by accident, as the macros are always used in a context where a proper "vop" symbol exists. This fix is almost cosmetic, as the resulting code shouldn't change. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190109185639.5093-2-ezequiel@collabora.com
2019-01-11drm/rockchip: Fix YUV buffers color renderingDaniele Castagna3-1/+88
Currently, YUV hardware overlays are converted to RGB using a color space conversion different than BT.601. The result is that colors of e.g. NV12 buffers don't match colors of YUV hardware overlays. In order to fix this, enable YUV2YUV and set appropriate coefficients for formats such as NV12 to be displayed correctly. This commit was tested using modetest, gstreamer and chromeos (hardware accelerated video playback). Before the commit, tests rendering with NV12 format resulted in colors not displayed correctly. Test examples (Tested on RK3399 and RK3288 boards connected to HDMI monitor): $ modetest 39@32:1920x1080@NV12 $ gst-launch-1.0 videotestrc ! video/x-raw,format=NV12 ! kmssink Signed-off-by: Daniele Castagna <dcastagna@chromium.org> [ezequiel: rebase on linux-next and massage commit log] Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190108214659.28794-1-ezequiel@collabora.com
2019-01-11drm/rockchip: update cursors asynchronously through atomic.Enric Balletbo i Serra4-36/+114
Add support to async updates of cursors by using the new atomic interface for that. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [updated for upstream] Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20181205123310.7965-1-helen.koike@collabora.com
2019-01-10Merge tag 'tilcdc-4.22' of https://github.com/jsarha/linux into drm-nextDave Airlie1-17/+17
tilcdc pull request for Linux v4.22 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jyri Sarha <jsarha@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/cdf82a00-4e40-20a6-cc7d-3278dc23473e@ti.com
2019-01-10drm: msm: Cleanup drm_display_mode print strShayenne Moura9-72/+10
This patch adjust the print string of drm_display_mode object to remove drm_mode_object dependency in msm files. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Shayenne Moura <shayenneluzmoura@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/3e2dcd38c964061f245b0ae22186c71da06e9742.1547143069.git.shayenneluzmoura@gmail.com
2019-01-10drm/fb-helper: Scale back depth to supported maximumLinus Walleij1-1/+54
The following happened when migrating an old fbdev driver to DRM: The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555 or XRGB1555/XBGR1555 i.e. the maximum depth is 15. This makes the initialization of the framebuffer fail since the code in drm_fb_helper_single_fb_probe() assigns the same value to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes a 1-to-1 mapping between BPP and depth, which is true in most cases but not for this hardware that only support odd formats. To support the odd case of a driver supporting 16BPP with only 15 bits of depth, this patch will make the code loop over the formats supported on the primary plane on each CRTC managed by the FB helper and cap the depth to the maximum supported on any primary plane. On the PL110 Integrator, this makes drm_mode_legacy_fb_format() select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and thus we get framebuffer, penguin and console on the Integrator/CP. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190110114049.10618-1-linus.walleij@linaro.org
2019-01-10drm/edid: Add display_info.rgb_quant_range_selectableVille Syrjälä9-68/+43
Move the CEA-861 QS bit handling entirely into the edid code. No need to bother the drivers with this. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: Eric Anholt <eric@anholt.net> (supporter:DRM DRIVERS FOR VC4) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-4-ville.syrjala@linux.intel.com
2019-01-10drm/radeon: Use drm_hdmi_avi_infoframe_quant_range()Ville Syrjälä1-8/+5
Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() instead of hand rolling it. This changes the behaviour slightly as drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit even when QS==0 iff the Q bit matched the default quantization range for the given mode. This matches the recommendation in HDMI 2.0 and is allowed even before that. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-3-ville.syrjala@linux.intel.com
2019-01-10drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as wellVille Syrjälä1-9/+10
Fill out the AVI infoframe quantization range bits using drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as well. This changes the behaviour slightly as drm_hdmi_avi_infoframe_quant_range() will set a non-zero Q bit even when QS==0 iff the Q bit matched the default quantization range for the given mode. This matches the recommendation in HDMI 2.0 and is allowed even before that. v2: Pimp commit msg (DK) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-2-ville.syrjala@linux.intel.com
2019-01-10drm/edid: Pass connector to AVI infoframe functionsVille Syrjälä27-66/+91
Make life easier for drivers by simply passing the connector to drm_hdmi_avi_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range(). That way drivers don't need to worry about is_hdmi2_sink mess. v2: Make is_hdmi2_sink() return true for sil-sii8620 Adapt to omap/vc4 changes Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Russell King <linux@armlinux.org.uk> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: amd-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108172828.15184-1-ville.syrjala@linux.intel.com
2019-01-10drm/crtc-helpers: WARN when used with atomic driversDaniel Vetter1-4/+14
Motivated by an oversight of mine when looking at the atomic bochs conversion. For consistency also switch over to the same style as used elsewhere (e.g. in drm_mode_set_config_internal). Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190110103045.26821-1-daniel.vetter@ffwll.ch
2019-01-10drm: remove drmP.h from drm_gem_cma_helper.hSam Ravnborg1-1/+4
With all dependencies fixed we can now remove drmP.h from drm_gem_cma_helper.h. It is replaced by the include files required, or forward declarations as appropritate. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-13-sam@ravnborg.org
2019-01-10drm/tinydrm: do not reply on drmP.h from drm_gem_cma_helper.hSam Ravnborg10-0/+17
drmP.h was the only header file in the past and a lot of files rely on that drmP.h defines everything. The goal is to one day to delete drmP.h and as a step towards this it will no longer be included in the headers files in include/drm/ To prepare tinydrm/ for this add dependencies that othwewise was pulled in by drmP.h from drm_gem_cma_helper.h To avoid that tinydrm.h became "include everything", push include files to the individual drivers. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: David Lechner <david@lechnology.com> Cc: David Airlie <airlied@linux.ie> Cc: Eric Anholt <eric@anholt.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-12-sam@ravnborg.org
2019-01-10drm/arc: do not rely on drmP.h from drm_gem_cma_helper.hSam Ravnborg2-0/+8
drmP.h was the only header file in the past and a lot of files rely on that drmP.h defines everything. The goal is to one day to delete drmP.h and as a step towards this it will no longer be included in the headers files in include/drm/ To prepare arc/ for this add dependencies that othwewise was pulled in by drmP.h from drm_gem_cma_helper.h Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> [danvet: Fix typo in commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-10-sam@ravnborg.org
2019-01-10drm: remove include of drmP.h from drm_encoder_slave.hSam Ravnborg1-1/+0
No further changes required. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-8-sam@ravnborg.org
2019-01-10drm: remove include of drmP.h from bridge/dw_hdmi.hSam Ravnborg3-2/+9
drmP.h is an relic from the days when there was a single header file. To enable the removal of drmP.h from all users drop include of drmP.h from bridge/dw_hdmi.h. A few files relied on the file included in drmP.h - add explicit include statements or forward declarations to these files. Build tested with arm and x86. v2: - prefer forward declarations when possible (Laurent Pinchart) - sort include files (Laurent Pinchart) Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-7-sam@ravnborg.org
2019-01-10drm/gem: Mark pinned pages as unevictableKuo-Hsin Yang1-3/+33
The gem drivers use shmemfs to allocate backing storage for gem objects. On Samsung Chromebook Plus, the drm/rockchip driver may call rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page to pin a lot of pages, breaking the page reclaim mechanism and causing oom-killer invocation. E.g. when the size of a zone is 3.9 GiB, the inactive_ratio is 5. If active_anon / inactive_anon < 5 and all pages in the inactive_anon lru are pinned, page reclaim would keep scanning inactive_anon lru without reclaiming memory. It breaks page reclaim when the rockchip driver only pins about 1/6 of the anon lru pages. Mark these pinned pages as unevictable to avoid the premature oom-killer invocation. See also similar patch on i915 driver [1]. [1]: https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-chris@chris-wilson.co.uk Signed-off-by: Kuo-Hsin Yang <vovoy@chromium.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190108074517.209860-1-vovoy@chromium.org
2019-01-10drm: make drm_framebuffer.h self containedSam Ravnborg1-3/+7
Add forward declaration and pull in include file to make drm_framebuffer.h self contained. While add it order include files alphabetically. The use of TASK_COMM_LEN is the reason for including sched.h. I could not see any good way to avoid this dependency, and users of drm_framebuffer.comm already use TASK_COMM_LEN to check for length etc. v2: - Added forward declaration of drm_gem_object (Noralf) - Added ack from Noralf Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-4-sam@ravnborg.org
2019-01-10drm: move DRM_SWITCH_POWER defines to drm_device.hSam Ravnborg2-6/+28
Move DRM_SWITCH_POWER out of drmP.h to allow users to get rid of the drmP include. Moved to drm_device.h because drm_device.switch_power_state is the only user. Converted to enum and added sparse kerneldoc comments. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-3-sam@ravnborg.org
2019-01-10drm: drm_device.h: update comments to kernel-doc styleSam Ravnborg1-65/+134
Updated comment style to kernel-doc format in drm_device.h In struct drm_device there are 12 struct members without doc: - registered - filelist_mutex - filelist - irq - vbl_lock - event_lock - hose - sigdata - sigdata.context - sigdata.lock - agp_buffer_map - agp_buffer_token They all need proper documentation, a task left for someone that knows their usage. drm_device is not plugged into Documentation/gpu/drm-internals.rst as this would create a new load of warnings. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190108192939.15255-2-sam@ravnborg.org
2019-01-10drm: i915: Cleanup drm_display_mode print strShayenne Moura1-8/+1
This patch adjust the print string of drm_display_mode object to remove drm_mode_object dependency in i915 files. It modifies the print style to standardize the use of DRM_MODE_FMT. Signed-off-by: Shayenne Moura <shayenneluzmoura@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/087e07a388c7c65b6d0ec50db069640e4eb32fdf.1545308167.git.shayenneluzmoura@gmail.com
2019-01-10drm: sti: Cleanup drm_display_mode print strShayenne Moura1-12/+4
This patch adjust the print string of drm_display_mode object to remove drm_mode_object dependency in sti files. Signed-off-by: Shayenne Moura <shayenneluzmoura@gmail.com> Acked-by: Benjamin Gaignard <benjamin;gaignard@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/c079f461575aece9d598784da25aaadc711a2729.1545308167.git.shayenneluzmoura@gmail.com
2019-01-10drm: meson: Cleanup on drm_display_mode print strShayenne Moura1-9/+3
This patch adjust the print string of drm_display_mode object to remove drm_mode_object dependency in meson files. Signed-off-by: Shayenne Moura <shayenneluzmoura@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/7017942bbbb3e0e6c1e2bd854ea5a5f461784ac4.1545308167.git.shayenneluzmoura@gmail.com
2019-01-10drm: omapdrm: Cleanup drm_display_mode print strShayenne Moura2-13/+4
This patch adjust the print string of drm_display_mode object to remove drm_mode_object dependency in omapdrm files. Signed-off-by: Shayenne Moura <shayenneluzmoura@gmail.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/cb6079fa6de6fda8d865a1d2a61d7cf10019ae88.1545308167.git.shayenneluzmoura@gmail.com
2019-01-09drm/msm: fix build warning for 64-bit seqnoDave Airlie1-1/+1
Fixes: b312d8ca3a7c ("dma-buf: make fence sequence numbers 64 bit v2") Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-01-09Merge tag 'drm-misc-next-2019-01-07-1' of ↵Dave Airlie69-580/+580
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.1: UAPI Changes: Cross-subsystem Changes: - Turn dma-buf fence sequence numbers into 64 bit numbers Core Changes: - Move to a common helper for the DP MST hotplug for radeon, i915 and amdgpu - i2c improvements for drm_dp_mst - Removal of drm_syncobj_cb - Introduction of an helper to create and attach the TV margin properties Driver Changes: - Improve cache flushes for v3d - Reflection support for vc4 - HDMI overscan support for vc4 - Add implicit fencing support for rockchip and sun4i - Switch to generic fbdev emulation for virtio Signed-off-by: Dave Airlie <airlied@redhat.com> [airlied: applied amdgpu merge fixup] From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107180333.amklwycudbsub3s5@flea
2019-01-09qxl: Use struct_size() in kzalloc()Gustavo A. R. Silva1-2/+2
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190108162152.GA25361@embeddedor Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-01-09drm/virtio: Drop deprecated load/unload initializationEzequiel Garcia6-122/+83
Move the code around so the driver is probed the bus .probe and removed from the bus .remove callbacks. This commit is just a cleanup and shouldn't affect functionality. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190108145930.15080-1-ezequiel@collabora.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-01-08drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setupPeter Wu1-1/+1
After drm_fb_helper_fbdev_setup calls drm_fb_helper_init, "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will have some effect). After that, drm_fb_helper_initial_config is called which may call the "fb_probe" driver callback. This driver callback may call drm_fb_helper_defio_init (as is done by drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs) as documented. These are normally cleaned up on exit by drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini. If an error occurs after "fb_probe", but before setup is complete, then calling just drm_fb_helper_fini will leak resources. This was triggered by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"): [ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this framebuffer [ 50.009436] bochs-drm 0000:00:02.0: [drm:drm_fb_helper_fbdev_setup] *ERROR* fbdev: Failed to set configuration (ret=-38) [ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 2 [ 50.013604] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0 [ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 4.20.0-rc7 #1 [ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0 ... [ 50.023155] Call Trace: [ 50.023155] ? bochs_kms_fini+0x1e/0x30 [ 50.023155] ? bochs_unload+0x18/0x40 This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n. Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian Link: https://lkml.kernel.org/r/20181223004315.GA11455@al Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()") Reported-by: kernel test robot <rong.a.chen@intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181223005507.28328-1-peter@lekensteyn.nl
2019-01-08drm/fb-helper: generic: Fix setup error pathNoralf Trønnes1-40/+58
If register_framebuffer() fails during fbdev setup we will leak the framebuffer, the GEM buffer and the shadow buffer for defio. This is because drm_fb_helper_fbdev_setup() just calls drm_fb_helper_fini() on error not taking into account that register_framebuffer() can fail. Since the generic emulation uses DRM client for its framebuffer and backing buffer in addition to a shadow buffer, it's necessary to open code drm_fb_helper_fbdev_setup() to properly handle the error path. Error cleanup is removed from .fb_probe and is handled by one function for all paths. Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation") Reported-by: Peter Wu <peter@lekensteyn.nl> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190105181846.26495-1-noralf@tronnes.org
2019-01-08drm/virtio: drop virtio_gpu_fence_cleanup()Gerd Hoffmann4-12/+5
Just call drm_fence_put directly instead. Also set vgfb->fence to NULL after dropping the reference. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181219122708.4586-4-kraxel@redhat.com
2019-01-08drm/virtio: fix pageflip flushGerd Hoffmann1-5/+6
Sending the flush command only makes sense if we actually have a framebuffer attached to the scanout (handle != 0). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181219122708.4586-3-kraxel@redhat.com
2019-01-08drm/virtio: log error responsesGerd Hoffmann1-2/+10
If we got an error response code from the host, print it to the log. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181219122708.4586-2-kraxel@redhat.com
2019-01-08drm/virtio: Add missing virtqueue resetEzequiel Garcia1-0/+1
As per the VirtIO spec, the virtqueues must be reset during cleanup (see "3.3.1 Driver Requirements: Device Cleanup"). Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190102175507.4653-2-ezequiel@collabora.com
2019-01-08drm/virtio: Remove incorrect kfree()Ezequiel Garcia1-4/+0
The virtio_gpu_output is a member of struct virtio_gpu_device and is not a dynamically-allocated chunk, so it's wrong to kfree() it. Removing it fixes a memory corruption BUG() that can be triggered when the virtio-gpu driver is removed. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190102175507.4653-1-ezequiel@collabora.com
2019-01-08drm/todo: Better defio support in the generic fbdev emulationDaniel Vetter1-0/+30
The current one essentially means you need CMA or a vmalloc backed object, which makes fbdev emulation a special case. Since implementing this will be quite a bit of work, capture the idea in a TODO. Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190107102238.7789-1-daniel.vetter@ffwll.ch
2019-01-07Merge tag 'topic/drmp-cleanup-2019-01-02' of ↵Maxime Ripard6-11/+24
git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next Make some drm headers self-contained with includes and forward declarations Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> # gpg: Signature made Wed 02 Jan 2019 10:47:51 AM CET # gpg: using RSA key 1565A65B77B0632E1124E59CD398079D26ABEE6F # gpg: Can't check signature: No public key From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87pntfl6pa.fsf@intel.com
2019-01-07drm: Fix error handling in drm_legacy_addctxYueHaibing1-6/+9
'ctx->handle' is unsigned, it never less than zero. This patch use int 'tmp_handle' to handle the err condition. Fixes: 62968144e673 ("drm: convert drm context code to use Linux idr") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181229024907.12852-1-yuehaibing@huawei.com
2019-01-07Linux 5.0-rc1Linus Torvalds1-3/+3
2019-01-07Merge tag 'kbuild-v4.21-3' of ↵Linus Torvalds94-694/+150
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull more Kbuild updates from Masahiro Yamada: - improve boolinit.cocci and use_after_iter.cocci semantic patches - fix alignment for kallsyms - move 'asm goto' compiler test to Kconfig and clean up jump_label CONFIG option - generate asm-generic wrappers automatically if arch does not implement mandatory UAPI headers - remove redundant generic-y defines - misc cleanups * tag 'kbuild-v4.21-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kconfig: rename generated .*conf-cfg to *conf-cfg kbuild: remove unnecessary stubs for archheader and archscripts kbuild: use assignment instead of define ... endef for filechk_* rules arch: remove redundant UAPI generic-y defines kbuild: generate asm-generic wrappers if mandatory headers are missing arch: remove stale comments "UAPI Header export list" riscv: remove redundant kernel-space generic-y kbuild: change filechk to surround the given command with { } kbuild: remove redundant target cleaning on failure kbuild: clean up rule_dtc_dt_yaml kbuild: remove UIMAGE_IN and UIMAGE_OUT jump_label: move 'asm goto' support test to Kconfig kallsyms: lower alignment on ARM scripts: coccinelle: boolinit: drop warnings on named constants scripts: coccinelle: check for redeclaration kconfig: remove unused "file" field of yylval union nds32: remove redundant kernel-space generic-y nios2: remove unneeded HAS_DMA define
2019-01-07Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds27-166/+620
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf tooling updates form Ingo Molnar: "A final batch of perf tooling changes: mostly fixes and small improvements" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (29 commits) perf session: Add comment for perf_session__register_idle_thread() perf thread-stack: Fix thread stack processing for the idle task perf thread-stack: Allocate an array of thread stacks perf thread-stack: Factor out thread_stack__init() perf thread-stack: Allow for a thread stack array perf thread-stack: Avoid direct reference to the thread's stack perf thread-stack: Tidy thread_stack__bottom() usage perf thread-stack: Simplify some code in thread_stack__process() tools gpio: Allow overriding CFLAGS tools power turbostat: Override CFLAGS assignments and add LDFLAGS to build command tools thermal tmon: Allow overriding CFLAGS assignments tools power x86_energy_perf_policy: Override CFLAGS assignments and add LDFLAGS to build command perf c2c: Increase the HITM ratio limit for displayed cachelines perf c2c: Change the default coalesce setup perf trace beauty ioctl: Beautify USBDEVFS_ commands perf trace beauty: Export function to get the files for a thread perf trace: Wire up ioctl's USBDEBFS_ cmd table generator perf beauty ioctl: Add generator for USBDEVFS_ ioctl commands tools headers uapi: Grab a copy of usbdevice_fs.h perf trace: Store the major number for a file when storing its pathname ...
2019-01-07Change mincore() to count "mapped" pages rather than "cached" pagesLinus Torvalds1-81/+13
The semantics of what "in core" means for the mincore() system call are somewhat unclear, but Linux has always (since 2.3.52, which is when mincore() was initially done) treated it as "page is available in page cache" rather than "page is mapped in the mapping". The problem with that traditional semantic is that it exposes a lot of system cache state that it really probably shouldn't, and that users shouldn't really even care about. So let's try to avoid that information leak by simply changing the semantics to be that mincore() counts actual mapped pages, not pages that might be cheaply mapped if they were faulted (note the "might be" part of the old semantics: being in the cache doesn't actually guarantee that you can access them without IO anyway, since things like network filesystems may have to revalidate the cache before use). In many ways the old semantics were somewhat insane even aside from the information leak issue. From the very beginning (and that beginning is a long time ago: 2.3.52 was released in March 2000, I think), the code had a comment saying Later we can get more picky about what "in core" means precisely. and this is that "later". Admittedly it is much later than is really comfortable. NOTE! This is a real semantic change, and it is for example known to change the output of "fincore", since that program literally does a mmmap without populating it, and then doing "mincore()" on that mapping that doesn't actually have any pages in it. I'm hoping that nobody actually has any workflow that cares, and the info leak is real. We may have to do something different if it turns out that people have valid reasons to want the old semantics, and if we can limit the information leak sanely. Cc: Kevin Easton <kevin@guarana.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Masatake YAMATO <yamato@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-07Fix 'acccess_ok()' on alpha and SHLinus Torvalds2-5/+10
Commit 594cc251fdd0 ("make 'user_access_begin()' do 'access_ok()'") broke both alpha and SH booting in qemu, as noticed by Guenter Roeck. It turns out that the bug wasn't actually in that commit itself (which would have been surprising: it was mostly a no-op), but in how the addition of access_ok() to the strncpy_from_user() and strnlen_user() functions now triggered the case where those functions would test the access of the very last byte of the user address space. The string functions actually did that user range test before too, but they did it manually by just comparing against user_addr_max(). But with user_access_begin() doing the check (using "access_ok()"), it now exposed problems in the architecture implementations of that function. For example, on alpha, the access_ok() helper macro looked like this: #define __access_ok(addr, size) \ ((get_fs().seg & (addr | size | (addr+size))) == 0) and what it basically tests is of any of the high bits get set (the USER_DS masking value is 0xfffffc0000000000). And that's completely wrong for the "addr+size" check. Because it's off-by-one for the case where we check to the very end of the user address space, which is exactly what the strn*_user() functions do. Why? Because "addr+size" will be exactly the size of the address space, so trying to access the last byte of the user address space will fail the __access_ok() check, even though it shouldn't. As a result, the user string accessor functions failed consistently - because they literally don't know how long the string is going to be, and the max access is going to be that last byte of the user address space. Side note: that alpha macro is buggy for another reason too - it re-uses the arguments twice. And SH has another version of almost the exact same bug: #define __addr_ok(addr) \ ((unsigned long __force)(addr) < current_thread_info()->addr_limit.seg) so far so good: yes, a user address must be below the limit. But then: #define __access_ok(addr, size) \ (__addr_ok((addr) + (size))) is wrong with the exact same off-by-one case: the case when "addr+size" is exactly _equal_ to the limit is actually perfectly fine (think "one byte access at the last address of the user address space") The SH version is actually seriously buggy in another way: it doesn't actually check for overflow, even though it did copy the _comment_ that talks about overflow. So it turns out that both SH and alpha actually have completely buggy implementations of access_ok(), but they happened to work in practice (although the SH overflow one is a serious serious security bug, not that anybody likely cares about SH security). This fixes the problems by using a similar macro on both alpha and SH. It isn't trying to be clever, the end address is based on this logic: unsigned long __ao_end = __ao_a + __ao_b - !!__ao_b; which basically says "add start and length, and then subtract one unless the length was zero". We can't subtract one for a zero length, or we'd just hit an underflow instead. For a lot of access_ok() users the length is a constant, so this isn't actually as expensive as it initially looks. Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net> Cc: Matt Turner <mattst88@gmail.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>