- 12 Mar, 2021 2 commits
-
-
Matthew Wilcox (Oracle) authored
There's no need to give the page an address_space. Leaving the page->mapping as NULL will cause the VM to handle set_page_dirty() the same way that it's handled now, and that was the only reason to set the address_space in the first place. Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
William Kucharski <william.kucharski@oracle.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210310185530.1053320-1-willy@infradead.org
-
Daniel Vetter authored
Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. This documentation section explains what's the potential problem, and the remedies we've discussed, roughly ordered from best to worst. v2: Linus -> Linux typoe (Dave) v3: - Make it clear drivers only need to implement one option (Christian) - Make it clearer that implicit sync is out the window with exclusive fences (Christian) - Add the fairly theoretical option of segementing the memory (either statically or through dynamic checks at runtime for which piece of memory is managed how) and explain why it's not a great idea (Felix) References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-Felix.Kuehling@amd.com/Reviewed-by:
Christian König <christian.koenig@amd.com> Acked-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> c: Dave Airlie <airlied@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210203152921.2429937-1-daniel.vetter@ffwll.ch
-
- 11 Mar, 2021 7 commits
-
-
Douglas Anderson authored
Panel power sequence says timing T8 (time from link idle to turn on the backlight) should be at least 50 ms. This is what the .enable delay in simple-panel is for, so set it. NOTE: this overlaps with the 80 ms .prepare_to_enable delay on purpose. The data sheet says that at least 80 ms needs to pass between HPD going high and turning on the backlight and that at least 50 ms needs to pass between the link idle and the backlight going on. Thus it works like this on the system in front of me: * In bridge chip pre_enable call drm_panel_prepare() * drm_panel_prepare() -> panel_simple_prepare() * Wait for HPD GPIO to go high. * Start counting for 80 ms (store in prepared_time) * In bridge chip enable, train link then call drm_panel_enable() * drm_panel_enable() -> panel_simple_enable() * panel_simple_enable() does hardcoded 50 ms delay then enforces 80 ms from HPD going high (in case the bridge took less than 30 ms to enable / link train). * drm_panel_enable() -> backlight_enable(). Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210222081716.1.I1a45aece5d2ac6a2e73bbec50da2086e43e0862b@changeid
-
Douglas Anderson authored
This panel is quite similar to the similarly named N116BGE panel (the nominal timings are, in fact identical). However, let's add a new entry because the full range of clocks listed for N116BGE aren't supported for N116BCA-EA1, at least according to the datasheet. Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Douglas Anderson authored
Another simple eDP panel. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Douglas Anderson authored
On an Innolux N116BCA panel that I have in front of me, sometimes HPD simply doesn't assert no matter how long you wait for it. As per the very wise advice of The IT Crowd ("Have you tried turning it off and on again?") it appears that power cycling is enough to kick this panel back into a sane state. >From tests on this panel, it appears that leaving it powered off for a while stimulates the problem. Adding a 6 second sleep at the start of panel_simple_prepare_once() makes it happen fairly reliably and, with this delay, I saw up to 3 retries needed sometimes. Without the 6 second sleep, however, the panel came up much more reliably the first time or after only 1 retry. While it's unknown what the problems are with this panel (and probably the hardware should be debugged), adding a few retries to the power on routine doesn't seem insane. Even if this panel's problems are attributed to the fact that it's pre-production and/or can be fixed, retries clearly can help in some cases and really don't hurt. Signed-off-by: -
Douglas Anderson authored
If a panel has an hpd_absent_delay specified then we know exactly how long the maximum time is before HPD must be asserted. That means we can use it as a timeout for polling the HPD pin instead of using an arbitrary timeout. This is especially useful for dealing with panels that periodically fail to power on and need to be retried. We can detect the problem sooner. Signed-off-by:
-
Douglas Anderson authored
If the HPD signal never asserts in panel_simple_prepare() and we return an error, we should unset the enable GPIO and disable the regulator to make it consistent for the caller. At the moment I have some hardware where HPD sometimes doesn't assert. Obviously that needs to be debugged, but this patch makes it so that if I add a retry that I can make things work. Fixes: 48834e60 ("drm/panel-simple: Support hpd-gpios for delaying prepare()") Signed-off-by:
-
Tian Tao authored
updated to use drmm_vram_helper_init(). Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 09 Mar, 2021 2 commits
-
-
Simon Ser authored
Document all of the DRM_CAP_* defines. v2 (Pekka): - Describe what the bit depth is - Expand on preferred dumb buffer memory access patterns - Explain what a PRIME buffer is - Mention DRM_IOCTL_PRIME_FD_TO_HANDLE and DRM_IOCTL_PRIME_HANDLE_TO_FD - Explicitly reference CLOCK_REALTIME and CLOCK_MONOTONIC - Make it clear DRM_CAP_CRTC_IN_VBLANK_EVENT applies to both DRM_EVENT_VBLANK and DRM_EVENT_FLIP_COMPLETE v3 (Daniel): - Specify kernel versions for caps that don't depend on drivers - Make it clear dumb buffers caps are only about dumb buffers Signed-off-by:
Simon Ser <contact@emersion.fr> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210308123421.747836-1-contact@emersion.fr
-
xndcn authored
virtio_gpu_object array is not freed or unlocked in some failed cases. Signed-off-by:
xndcn <xndchn@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210305151819.14330-1-xndchn@gmail.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
- 08 Mar, 2021 4 commits
-
-
Yannick Fertre authored
Don't print error when probe deferred error is returned. Signed-off-by:
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by:
Yannick Fertre <yannick.fertre@foss.st.com> Tested-by:
Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210222092205.32086-2-raphael.gallais-pou@foss.st.com
-
Christian König authored
This is necessary when changing priorities of an entity. v2: test the sched_list instead of num_sched. v3: set the sched_list to NULL when there is only one entry Signed-off-by:
Sonny Jiang <sonny.jiang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210305125155.2312-1-christian.koenig@amd.com
-
Jagan Teki authored
STM ltdc driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
-
Jianhui Zhao authored
Signed-off-by:
Jianhui Zhao <zhaojh329@gmail.com> Signed-off-by:
-
- 07 Mar, 2021 1 commit
-
-
Paul Cercueil authored
Even though the JZ4740 did not have the OSD mode, it had (according to the documentation) two DMA channels, but there is absolutely no information about how to select the second DMA channel. Make the ingenic-drm driver work in non-OSD mode by using the foreground0 plane (which is bound to the DMA0 channel) as the primary plane, instead of the foreground1 plane, which is the primary plane when in OSD mode. Fixes: 3c9bea4e ("drm/ingenic: Add support for OSD mode") Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Acked-by:
H. Nikolaus Schaller <hns@goldelico.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210124085552.29146-5-paul@crapouillou.net
-
- 04 Mar, 2021 1 commit
-
-
Linus Walleij authored
A recent patch renaming MIPI_DSI_MODE_EOT_PACKET to MIPI_DSI_MODE_NO_EOT_PACKET brought to light the misunderstanding in the current MCDE driver and all its associated panel drivers that MIPI_DSI_MODE_EOT_PACKET would mean "use EOT packet" when in fact it means the reverse. Fix it up by implementing the flag right in the MCDE DSI driver and remove the flag from panels that actually want the EOT packet. Suggested-by:
Nicolas Boichat <drinkcat@chromium.org> Signed-off-by:
-
- 02 Mar, 2021 2 commits
-
-
Lionel Landwerlin authored
Just a silly mistake Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Suggested-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Daniel Vetter authored
Somehow this got forgotten when I applied the patch in commit e2c406ea Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jan 12 09:43:54 2021 +0100 drm/arc: Inline arcpgu_crtc.c Fixes: e2c406ea ("drm/arc: Inline arcpgu_crtc.c") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
-
- 01 Mar, 2021 1 commit
-
-
Jan Beulich authored
By having selected DRM_XEN, I was assuming I would build the frontend driver. As it turns out this is a dummy option, and I have really not been building this (because I had DRM disabled). Make it a promptless one, moving the "depends on" to the other, real option, and "select"ing the dummy one. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by:
-
- 26 Feb, 2021 3 commits
-
-
Zack Rusin authored
We should advertise the reworked fifo/cmd handling and huge pages support. Also while bumping the version number lets cleanup the logging, there's no point in logging whether we're atomic (we always are) or what repo we use (it's always in kernel now). Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Roland Scheidegger <sroland@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210224163034.918430-1-zackr@vmware.com
-
Daniel Vetter authored
drm_noop really doesn't do much, and who cares about the permission checks. So let's delete some code. Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Daniel Vetter authored
Some of them have gaps, or fields we don't clear. Native ioctl code does full copies plus zero-extends on size mismatch, so nothing can leak. But compat is more hand-rolled so need to be careful. None of these matter for performance, so just memset. Also I didn't fix up the CONFIG_DRM_LEGACY or CONFIG_DRM_AGP ioctl, those are security holes anyway. Acked-by:
-
- 25 Feb, 2021 17 commits
-
-
Rikard Falkeborn authored
The only usage of nouveau_ttm_vm_ops is to assign its address to the vm_ops field in the vm_area_struct struct. Make it const to allow the compiler to put it in read-only memory Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Reviewed-by:
-
Rikard Falkeborn authored
The only usage of radeon_ttm_vm_ops is to assign its address to the vm_ops field in the vm_area_struct struct. Make it const to allow the compiler to put it in read-only memory Signed-off-by:
-
Rikard Falkeborn authored
The only usage of amdgpu_ttm_vm_ops is to assign its address to the vm_ops field in the vm_area_struct struct. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
-
John Stultz authored
By default dma_buf_export() sets the exporter name to be KBUILD_MODNAME. Unfortunately this may not be identical to the string used as the heap name (ie: "system" vs "system_heap"). This can cause some minor confusion with tooling, and there is the future potential where multiple heap types may be exported by the same module (but would all have the same name). So to avoid all this, set the exporter exp_name to the heap name. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Liam Mark <lmark@codeaurora.org> Cc: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: Laura Abbott <labbott@kernel.org> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Hridya Valsaraju <hridya@google.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Sandeep Patil <sspatil@google.com> Cc: Daniel Mentz <danielmentz@google.com> Cc: Ørjan Eide <orjan.eide@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Ezequiel Garcia <ezequiel@collabora.com> Cc: Simon Ser <contact@emersion.fr> Cc: James Jones <jajones@nvidia.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
John Stultz <john.stultz@linaro.org> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210209194818.2459062-2-john.stultz@linaro.org
-
John Stultz authored
It can be useful to access the name for the heap, so provide an accessor to do so. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Liam Mark <lmark@codeaurora.org> Cc: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: Laura Abbott <labbott@kernel.org> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Hridya Valsaraju <hridya@google.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Sandeep Patil <sspatil@google.com> Cc: Daniel Mentz <danielmentz@google.com> Cc: Ørjan Eide <orjan.eide@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Ezequiel Garcia <ezequiel@collabora.com> Cc: Simon Ser <contact@emersion.fr> Cc: James Jones <jajones@nvidia.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
xinhui pan authored
BO would be added into swap list if it is validated into system domain. If BO is validated again into non-system domain, say, VRAM domain. It actually should not be in the swap list. Signed-off-by:
xinhui pan <xinhui.pan@amd.com> Acked-by:
Guchun Chen <guchun.chen@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Daniel Vetter authored
Because it is. v2: Delete now unused crtc funcs (0day) Acked-by:
-
Daniel Vetter authored
That way we can get rid of this final piece of init code, and use the simple pipe helpers as intended. v2: Fix indent (Sam) Acked-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by:
-
Daniel Vetter authored
At less than 500 lines total feels like the right thing to do. Also noticed that the simple wrapper around drm_connector_cleanup can be dropped. Acked-by:
-
Daniel Vetter authored
Really not worth the function, much less the separate file now that almost all the code is gone. Acked-by:
-
Daniel Vetter authored
Really not big anymore. Note that we no longer clamp all errors to ENODEV, highlighted by Sam. v2: Fixup update function, bug reported by Eugeniy v3: Delete now unused crtc funcs (0day) v4: Move encoder removal to right patch (Sam). Acked-by:
-
Daniel Vetter authored
It's redundant, drm core guarantees that state->fb is set iff state->crtc is set. v2: I had a misconception about simple helpers here and thought they filter this out. They don't. Issue reported by Eugeniy. Acked-by:
-
Daniel Vetter authored
Really straighforward, only slight issue is that the sim connector is created after the pipe is set up, so can't use the helpers perfectly yet. Subsequent patches will fix that. Aside from lots of deleting code no functional changes in here. v2: Delete now unused crtc funcs (0day) v3: Move endcoder setup removal to right patch (Sam) Acked-by:
-
Daniel Vetter authored
Simple pipe helpers only have an enable and disable hook, no more mode_set_nofb. Call it from our enable hook to align with that conversions. Atomic helpers always call mode_set_nofb and enable together, so there's no functional change here. Acked-by:
-
Daniel Vetter authored
With autocleanup through drm_device management we can delete all the code. Possible now that there's no confusion against devm_kzalloc'ed structures anymore. I inlined arcpgu_setup_mode_config because it's tiny and the newly needed return value handling would have been more ... Acked-by:
-
Daniel Vetter authored
drm_connector_register does nothing before drm_dev_register(), it is meant for hotpluggable connectors only. Same for the unregister side. Acked-by:
-
Daniel Vetter authored
Removes the last devm_kzalloc, which means we're now prepared to use drmm_mode_config_cleanup! Acked-by:
-
