- 02 Apr, 2020 7 commits
-
-
Thomas Zimmermann authored
The tda998x driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305155950.2705-8-tzimmermann@suse.de
-
Thomas Zimmermann authored
The kirin driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by:
-
Thomas Zimmermann authored
The gma500 driver uses empty implementations for some of its encoders. Replace the code with the generic simple encoder. As a side effect, the patch also removes an indirection in the encoder setup for Medfield. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200305155950.2705-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
The fsl-dcu driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by:
-
Thomas Zimmermann authored
The exynos driver uses empty implementations for its encoders. Replace the code with the generic simple encoder. Signed-off-by:
-
Thomas Zimmermann authored
The atmel-hlcdc driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by:
-
Laurent Pinchart authored
The example code showing how to use the managed resource API calls kfree() on the wrong pointer. Fix it. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
- 01 Apr, 2020 8 commits
-
-
Andrzej Pietrasiewicz authored
Some drivers (komeda, malidp) don't set anything in cpp. If that is the case the right value can be inferred from the format. Then the "bpp" member can be eliminated from struct drm_afbc_framebuffer. Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Acked-by:
-
Andrzej Pietrasiewicz authored
Use drm_dbg_kms() instead of DRM_DEBUG_KMS. Signed-off-by:
-
Christian König authored
Note if a buffer was imported using peer2peer. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/359296
-
Christian König authored
We should be able to do this now after checking all the prerequisites. v2: fix entrie count in the sgt v3: manually construct the sg Signed-off-by:
-
Christian König authored
Check if we can do peer2peer on the PCIe bus. Signed-off-by:
-
Christian König authored
Importing should work out of the box. Signed-off-by:
-
Christian König authored
Calling ttm_bo_cleanup_memtype_use() destroys the TT object which in turn could result in warnings without this. Signed-off-by:
-
Christian König authored
Add a peer2peer flag noting that the importer can deal with device resources which are not backed by pages. Signed-off-by:
-
- 31 Mar, 2020 4 commits
-
-
Maya Rashish authored
Nothing uses the always-0 return value. Signed-off-by:
Maya Rashish <coypu@sdf.org> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200321222959.GA1053@SDF.ORG
-
Huacai Chen authored
The command ring and cursor ring use different notify port addresses definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring and cursor ring. This doesn't cause any problems now, because QEMU's behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same. However, QEMU's behavior may be change in future, so let's fix it. P.S.: In the X.org QXL driver, the notify port address of cursor ring is correct. Signed-off-by:Huacai Chen <chenhc@lemote.com> Cc: <stable@vger.kernel.org> Link: http://patchwork.freedesktop.org/patch/msgid/1585635488-17507-1-git-send-email-chenhc@lemote.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Christian König authored
This reverts commit 7be1b9b8. The drm_mm is supposed to work in atomic context, so calling schedule() or in this case cond_resched() is illegal. Signed-off-by:
-
Simon Ser authored
This is a standard property attached to planes in drm_universal_plane_init when drm_mode_config.allow_fb_modifiers is true. Signed-off-by:
Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Signed-off-by:
-
- 30 Mar, 2020 5 commits
-
-
Daniel Vetter authored
I'm thinking this is the warning that fired in the 0day report, but I can't double-check yet since 0day didn't upload its source tree anywhere I can check. And all the drivers I can easily test don't use drm_dev_alloc anymore ... Also if I'm correct supreme amounts of bad luck because usually kslap (for bigger structures) gives us something quite a bit bigger than what we asked for. [0day uploaded tree, guess is correct] Reported-by:
kernel test robot <lkp@intel.com> Fixes: c6603c74 ("drm: add managed resources tied to drm_device") Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200328162358.18500-1-daniel.vetter@ffwll.ch
-
Sam Ravnborg authored
Fix following warnings: drm_framebuffer.h:342: warning: Function parameter or member 'block_width' not described in 'drm_afbc_framebuffer' drm_framebuffer.h:342: warning: Function parameter or member 'block_height' not described in 'drm_afbc_framebuffer' Trivial spelling mistakes. Signed-off-by:
-
Sam Ravnborg authored
Fix kernel-doc warnings for drm_dp_mst_port.fec_capable. This fixed the following warning: drm_dp_mst_helper.h:162: warning: Function parameter or member 'fec_capable' not described in 'drm_dp_mst_port' Signed-off-by:
-
Emil Velikov authored
As requested by Adam, provide different error message for when the device has an existing master. An audit of the following projects, shows that the errno is used only for printf() purposes. xorg/xserver xorg/drivers/xf86-video-ati xorg/drivers/xf86-video-amdgpu xorg/drivers/xf86-video-intel xorg/drivers/xf86-video-tegra xorg/drivers/xf86-video-freedreno xorg/drivers/xf86-video-nouveau xorg/drivers/xf86-video-vmwgfx qt/kwin/plasma gtk/mutter/gnomeshell efl/enlightment Cc: Adam Jackson <ajax@redhat.com> Suggested-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
-
Emil Velikov authored
This commit reworks the permission handling of the two ioctls. In particular it enforced the CAP_SYS_ADMIN check only, if: - we're issuing the ioctl from process other than the one which opened the node, and - we are, or were master in the past This ensures that we: - do not regress the systemd-logind style of DRM_MASTER arbitrator - allow applications which do not use systemd-logind to drop their master capabilities (and regain them at later point) ... w/o running as root. See the comment above drm_master_check_perm() for more details. v1: - Tweak wording, fixup all checks, add igt test v2: - Add a few more comments, grammar nitpicks. Cc: Adam Jackson <ajax@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Pekka Paalanen <ppaalanen@gmail.com> Testcase: igt/core_setmaster/master-drop-set-user Signed-off-by:
-
- 28 Mar, 2020 12 commits
-
-
Wolfram Sang authored
Move away from the deprecated API. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
-
Wolfram Sang authored
Move away from the deprecated API. Signed-off-by:
-
Harigovindan P authored
Add bindings for visionox rm69299 panel. Signed-off-by:
Harigovindan P <harigovi@codeaurora.org> Signed-off-by:
-
Fabio Estevam authored
Commit 52120e8c ("dt-bindings: display: fix panel warnings") removed the dsi unit name, but missed to remove the 'reg' property, which causes the following 'make dt_binding_check' warning: Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.example.dts:17.5-29.11: Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges property, but no unit name Fix it by removing the unneeded 'reg' property. Fixes: 52120e8c ("dt-bindings: display: fix panel warnings") Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Fabio Estevam authored
Commit 52120e8c ("dt-bindings: display: fix panel warnings") removed the dsi unit name, but missed to remove the 'reg' property, which causes the following 'make dt_binding_check' warning: Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.example.dts:17.5-29.11: Warning (unit_address_vs_reg): /example-0/dsi: node has a reg or ranges property, but no unit name Fix it by removing the unneeded 'reg' property. Fixes: 52120e8c ("dt-bindings: display: fix panel warnings") Signed-off-by:
-
Pascal Roeleven authored
The KR070PE2T is a 7" panel with a resolution of 800x480. KR070PE2T is the marking present on the ribbon cable. As this panel is probably available under different brands, this marking will catch most devices. As I can't find a datasheet for this panel, the bus_flags are instead from trial-and-error. The flags seem to be common for these kind of panels as well. Signed-off-by:
Pascal Roeleven <dev@pascalroeleven.nl> Signed-off-by:
-
Pascal Roeleven authored
Add the devicetree binding for Starry KR070PE2T Signed-off-by:
-
Martin Blumenstingl authored
Most platforms with a Mali-400 or Mali-450 GPU also have support for changing the GPU clock frequency. Add devfreq support so the GPU clock rate is updated based on the actual GPU usage when the "operating-points-v2" property is present in the board.dts. The actual devfreq code is taken from panfrost_devfreq.c and modified so it matches what the lima hardware needs: - a call to dev_pm_opp_set_clkname() during initialization because there are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks the GPU so we need to control it using devfreq. - locking when reading or writing the devfreq statistics because (unlike than panfrost) we have multiple PP and GP IRQs which may finish jobs concurrently. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200319203427.2259891-3-martin.blumenstingl@googlemail.com
-
- 27 Mar, 2020 4 commits
-
-
Sean Paul authored
Now that we can support multiple simultaneous replies, remove the restrictions placed on sending new tx msgs. This patch essentially just reverts commit 5a64967a ("drm/dp_mst: Have DP_Tx send one msg at a time") now that the problem is solved in a different way. Cc: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by:
Wayne Lin <waynelin@amd.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200213211523.156998-4-sean@poorly.run
-
Sean Paul authored
Currently we have one down reply message servicing the mst manager, so we need to serialize all tx msgs to ensure we only have one message in flight at a time. For obvious reasons this is suboptimal (but less suboptimal than the free-for-all we had before serialization). This patch removes the single down_rep_recv message from manager and adds 2 replies in the branch structure. The 2 replies mirrors the tx_slots which we use to rate-limit outgoing messages and correspond to seqno in the packet headers. Cc: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by:
-
Sean Paul authored
In preparation of per-branch device down message handling, separate header parsing from message building. This will allow us to peek at figure out which branch device the message is from before starting to parse the message contents. Reviewed-by:
-
Hans de Goede authored
Currently drivers using drm_fbdev_generic_setup() end up with a single empty aperture in their fb_info struct. Not having the proper info in the apertures list causes register_framebuffer to not remove conflicting framebuffers, which some drivers currently workaround by manually calling drm_fb_helper_remove_conflicting_pci_framebuffers(). Add a TODO as a reminder that we need to fix this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
