- 30 Mar, 2020 4 commits
-
-
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 <sam@ravnborg.org> Acked-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Fixes: 55f7f727 ("drm/core: Add drm_afbc_framebuffer and a corresponding helper") Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: James Qian Wang <james.qian.wang@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200328132025.19910-3-sam@ravnborg.org
-
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:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200328132025.19910-6-sam@ravnborg.org
-
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 5 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:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200326151009.102377-1-hdegoede@redhat.com
-
Marek Szyprowski authored
Don't confuse user with meaningless warning about failure in getting regulators in case of deferred probe. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226101307.16708-1-m.szyprowski@samsung.com
-
- 26 Mar, 2020 19 commits
-
-
Daniel Vetter authored
All collected together to provide a consistent story in one patch, instead of the somewhat bumpy refactor-evolution leading to this. Also some thoughts on what the next steps could be: - Create a macro called devm_drm_dev_alloc() which essentially wraps the kzalloc(); devm_drm_dev_init(); drmm_add_final_kfree() combo. Needs to be a macro since we'll have to do some typeof trickery and casting to make this fully generic for all drivers that embed struct drm_device into their own thing. - A lot of the simple drivers now have essentially just drm_dev_unplug(); drm_atomic_helper_shutdown(); as their $bus_driver->remove hook. We could create a devm_mode_config_reset which sets drm_atomic_helper_shutdown as it's cleanup action, and a devm_drm_dev_register with drm_dev_unplug as it's cleanup action, and simple drivers wouldn't have a need for a ->remove function at all, and we could delete them. - For more complicated drivers we need drmm_ versions of a _lot_ more things. All the userspace visible objects (crtc, plane, encoder, crtc), anything else hanging of those (maybe a drmm_get_edid, at least for panels and other built-in stuff). Also some more thoughts on why we're not reusing devm_ with maybe a fake struct device embedded into the drm_device (we can't use the kdev, since that's in each drm_minor). - Code review gets extremely tricky, since every time you see a devm_ you need to carefully check whether the fake device (with the drm_device lifetim) or the real device (with the lifetim of the underlying physical device and driver binding) are used. That's not going to help at all, and we have enormous amounts of drivers who use devm_ where they really shouldn't. Having different types makes sure the compiler type checks this for us and ensures correctness. - The set of functions are very much non-overlapping. E.g. devm_ioremap makes total sense, drmm_ioremap has the wrong lifetime, since hw resources need to be cleaned out at driver unbind and wont outlive that like a drm_device. Similar, but other way round for drmm_connector_init (which is the only correct version, devm_ for drm_connector is just buggy). Simply not having the wrong version again prevents bugs. Finally I guess this opens a huge todo for all the drivers. I'm semi-tempted to do a tree-wide s/devm_kzalloc/drmm_kzalloc/ since most likely that'll fix an enormous amount of bugs and most likely not cause any issues at all (aside from maybe holding onto memory slightly too long). v2: - Doc improvements from Laurent. - Also add kerneldoc for the new drmm_add_action_or_reset. v3: - Remove kerneldoc for drmm_remove_action. Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> fixup docs Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-52-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
There's only two functions called from that: drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are also called from the ubs_driver->disconnect hook, so entirely pointless to do the same again in the ->release hook. Furthermore by the time we clean up the drm_driver we really shouldn't be touching hardware anymore, so stopping the poll worker and freeing the urb allocations in ->disconnect is the right thing to do. Now disconnect still cleans things up before unregistering the driver, but that's a different issue. v2: Use _fini, not _disable in unplug, motivated by discussions with Thomas. _disable/_enable are for suspend/resume. Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This allows us to delete a bit of onion unwinding in udl_modeset_init(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by:
-
Daniel Vetter authored
Allows us to drop the drm_driver.release callback from all drivers, and remove the mipi_dbi_release() function. This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
Daniel Vetter authored
7/7 drivers agree that's the right choice, let's do this. This avoids duplicating the same old error checking code over all 7 drivers, which is the motivation here. Acked-by:
-
Daniel Vetter authored
Allows us to drop the drm_driver.release callback. This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) I also noticed that I've failed to add the error checking, __must_check caught that. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> (v2) Signed-off-by:
-
Daniel Vetter authored
Instead of having a work item that never stops (which really should be a kthread), with a dedicated workqueue to not upset anyone else, use a delayed work. A bunch of changes: - We can throw out all the custom wakeup and requeue logic and state tracking. If we schedule the work with a 0 delay it'll get scheduled immediately. - Persistent state (frame & draw_status_timeout) need to be moved out of the work. - diff is bigger than the changes, biggest chunk is reindenting the work fn because it lost its while loop. Lots of code deleting as consequence all over. Specifically we can delete the drm_driver.release code now! v2: Review from Hans: - Use mod_delayed_work in the plane update path to make sure we do actually schedule immediately). In the worker we still want queue_delayed_work, which won't modify the timeout when the work is already scheduled. Which is exactly what we want if the work races with a plane update. - Switch to system_long_wq, Hans says on usb2 a plane upload can take 80 ms. Reviewed-by:
-
Daniel Vetter authored
Also there's a race in the disconnect implemenation. First shut down, then unplug, leaves a window where userspace could sneak in and restart the entire machinery. With this we can also delete the very un-atomic global pipe_enabled tracking. Reviewed-by:
-
Daniel Vetter authored
Only drops the drm_dev_put, but hey a few lines! Reviewed-by:
-
Daniel Vetter authored
The drm_mode_config_cleanup call we can drop, and all the allocations we can switch over to drmm_kzalloc. Unfortunately the work queue is still present, so can't get rid of the drm_driver->release function outright. v2: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> (v1) Signed-off-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... I'm pretty sure this one blows up already under KASAN because it's using devm_drm_dev_init, and later on devm_kzalloc. Hence the memory will get freed before the final drm_dev_put (all from the devres code), but the cleanup in that final drm_dev_put will access the just freed memory. Unfortunately fixing this properly needs slightly more work, namely drmm_ versions for all the drm objects (planes, crtc, ...), so that the cleanup actually happens before even drmm_kzalloc would release the underlying memory. Not quite there yet. v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Acked-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v2) Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Philippe Cornu <philippe.cornu@st.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
It's (almost, there's some iommu stuff without significance) right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... v2: Explain why this cleanup is possible (Laurent). v3: Jump out at the right label (Francesco) v4: Try again, kbuild caught that I didn't build test this properly ... v5: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: Another driver with a bit much devm_kzalloc, which should probably use drmm_kzalloc instead ... v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v2) Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: This driver gets its devm_ stuff all wrong wrt drm_device and anything hanging off that. Not the only one unfortunately. v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Acked-by:
-
Daniel Vetter authored
It's right above the drm_dev_put(). This is made possible by a preceeding patch which added a drmm_ cleanup action to drm_mode_config_init(), hence all we need to do to ensure that drm_mode_config_cleanup() is run on final drm_device cleanup is check the new error code for _init(). Aside: This driver gets its devm_ stuff all wrong wrt drm_device and anything hanging off that. Not the only one unfortunately. v2: Explain why this cleanup is possible (Laurent). v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> (v2) Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
Auto-unwind ftw, now possible with the fixed drm_device related management. Aside, clk/regulator seem to be missing devm versions for a bunch of functions, preventing a pile of these simpler drivers from outright losing their ->remove hook. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
