- 30 Jan, 2020 8 commits
-
-
Thomas Zimmermann authored
The atomic helpers automatically send out fake VBLANK events if no vblanking has been initialized. Remove the sending code from the driver. v4: * separate commit from core vblank changes Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200129120531.6891-9-tzimmermann@suse.de
-
Thomas Zimmermann authored
The atomic helpers automatically send out fake VBLANK events if no vblanking has been initialized. Remove the sending code from the driver. v4: * separate commit from core vblank changes Signed-off-by:
-
Thomas Zimmermann authored
The atomic helpers automatically send out fake VBLANK events if no vblanking has been initialized. Remove the sending code from the driver. v4: * separate commit from core vblank changes Signed-off-by:
-
Thomas Zimmermann authored
The atomic helpers automatically send out fake VBLANK events if no vblanking has been initialized. Remove the sending code from the driver. v4: * separate commit from core vblank changes Signed-off-by:
-
Thomas Zimmermann authored
The atomic helpers automatically send out fake VBLANK events if no vblanking has been initialized. Remove the sending code from the driver. v4: * separate commit from core vblank changes Signed-off-by:
-
Thomas Zimmermann authored
As ast does not initialize vblanking, atomic helpers initialize the value of struct drm_crtc_state.no_vblank to be true. No need to set it from within the driver. Signed-off-by:
-
Thomas Zimmermann authored
The atomic helpers automatically send out fake VBLANK events if no vblanking has been initialized. Remove the sending code from the driver. v4: * separate commit from core vblank changes Signed-off-by:
-
Thomas Zimmermann authored
At the end of a commit, atomic helpers can generate a fake VBLANK event automatically. Originally implemented for writeback connectors, the functionality can be used by any driver and/or hardware without proper VBLANK interrupt. The patch updates the documentation to make this behaviour official: settings struct drm_crtc_state.no_vblank to true enables automatic generation of fake VBLANK events. The new interface drm_dev_has_vblank() returns true if vblanking has been initialized for a device, or false otherwise. Atomic helpers use this function when initializing no_vblank in the CRTC state in drm_atomic_helper_check_modeset(). If vblanking has been initialized for a device, no_blank is disabled. Otherwise it's enabled. Hence, atomic helpers will automatically send out fake VBLANK events with any driver that did not initialize vblanking. v5: * more precise documentation and commit message v4: * replace drm_crtc_has_vblank() with drm_dev_has_vblank() * add drm_dev_has_vblank() in this patch * move driver changes into separate patches v3: * squash all related changes patches into this patch Signed-off-by:
-
- 29 Jan, 2020 1 commit
-
-
Daniel Vetter authored
vmwgfx stopped using them. With the drm device model that we've slowly evolved over the past few years master status essentially controls access to display resources, and nothing else. Since that's a pure access permission check drivers should have no need at all to track additional state on a per file basis. Aside: For cleanup and restoring kernel-internal clients the grand plan is to move everyone over to drm_client and drm_master_internal_acquire/release, like the generic fbdev code already does. That should get rid of most ->lastclose implementations, and I think also subsumes any processing vmwgfx does in master_set/drop. Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Cc: "Thomas Hellström (VMware)" <thomas_os@shipmail.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200127100203.1299322-1-daniel.vetter@ffwll.ch
-
- 28 Jan, 2020 7 commits
-
-
Daniel Vetter authored
Oops. Fixes: 9edbf1fa ("drm: Add API for capturing frame CRCs") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821203835.18314-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Reviewed-by:
Rodrigo Siqueira <rodrigosiqueira@gmail.com> Tested-by:
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Reviewed-by:
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Daniel Vetter authored
Checking both is one too much, so wrap a WARN_ON around it to stope the copypasta. Acked-by:
-
Daniel Vetter authored
It's frankly a mess, and the confusion around plane_state->crtc/fb that I fixed up in this series is the least of the problems. Add a todo as a future note of how this could be done a lot better, and with a lot less driver confusion. Acked-by:
-
- 27 Jan, 2020 10 commits
-
-
Jyri Sarha authored
Add entry for tidss DRM driver. Version history: v2: no change v3: - Move tidss entry after omapdrm - Add "T: git git://anongit.freedesktop.org/drm/drm-misc" v4: no change v5: no change v6: no change v7: no change v8: - Add Reviewed-by: Benoit Parrot <bparrot@ti.com> v9: - Add Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:Jyri Sarha <jsarha@ti.com> Reviewed-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/c22f7aa31af09cd4adcca6b1a6b0721d9429f055.1580129724.git.jsarha@ti.com
-
Jyri Sarha authored
This patch adds a new DRM driver for Texas Instruments DSS IPs used on Texas Instruments Keystone K2G, AM65x, and J721e SoCs. The new DSS IP is a major change to the older DSS IP versions, which are supported by the omapdrm driver. While on higher level the Keystone DSS resembles the older DSS versions, the registers are completely different and the internal pipelines differ a lot. DSS IP found on K2G is an "ultra-light" version, and has only a single plane and a single output. The K3 DSS IPs are found on AM65x and J721E SoCs. AM65x DSS has two video ports, one full video plane, and another "lite" plane without scaling support. J721E has 4 video ports, 2 video planes and 2 lite planes. AM65x DSS has also an integrated OLDI (LVDS) output. Version history: v2: - rebased on top of drm-next-2019-11-27 - sort all include lines in all files - remove all include <drm/drmP.h> - remove select "select VIDEOMODE_HELPERS" - call dispc_vp_setup() later in tidss_crtc_atomic_flush() (there is no to call it in new modeset case as it is also called in vp_enable()) - change probe sequence and drm_device allocation (follow example in drm_drv.c) - use __maybe_unused instead of #ifdef for pm functions - remove "struct drm_fbdev_cma *fbdev;" from driver data - check panel connector type before connecting it v3: no change v4: no change v5: - remove fifo underflow irq handling, it is not an error and it should be used for debug purposes only - memory tuning, prefetch plane fifo up to high-threshold value to minimize possibility of underflows. v6: - Check CTM and gamma support from dispc_features when creating crtc - Implement CTM support for k2g and fix k3 CTM implementation - Remove gamma property persistence and always write color properties in a new modeset v7: - Fix checkpatch.pl --strict issues - Rebase on top of drm-misc-next-2020-01-10 v8: - Remove idle debug prints from dispc_init() - Add Reviewed-by: Benoit Parrot <bparrot@ti.com> v9: - Rename dispc_write_irqenable() to dispc_set_irqenable() to avoid conflict exported omapfb function with same name - Add Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Co-developed-by: -
Jyri Sarha authored
Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone Display SubSystem. Version history: v2: no change v3: - reg-names: "wp" -> "wb" - Add ports node - Add includes to dts example - reindent dts example v4: - Add descriptions to reg, clocks, and interrupts properties - Remove minItems when its value is the same as maxItems value v5: - itemize reg, clocks and interrupts properties' descriptions - there is no "vp" reg-name, only "wb" for write back v6: - Add Reviewed-by: from Rob Herring <robh@kernel.org> and Benoit Parrot <bparrot@ti.com> v7: no change v8: no change v9: no change Signed-off-by:Rob Herring <robh@kernel.org> Reviewed-by:
-
Jyri Sarha authored
Add dt-schema yaml bindig for AM65x DSS, AM65x version TI Keystone Display SubSystem. Version history: v2: no change v3: - Add ports node - use allOf in ti,am65x-oldi-io-ctrl to add both $ref and maxItems - Add includes to dts example - reindent dts example v4: - Add descriptions to reg and clocks properties - Remove minItems when its value is the same as maxItems value v5: - itemize reg and clocks properties' descriptions v6: - Add Reviewed-by: from Rob Herring <robh@kernel.org> and Benoit Parrot <bparrot@ti.com> v7: no change v8: no change Signed-off-by: -
Jyri Sarha authored
Add dt-schema yaml bindig for K2G DSS, an ultra-light version of TI Keystone Display SubSystem. Version history: v2: no change v3: - Add ports node - Add includes to dts example - reindent dts example v4: - Add descriptions to reg and clocks properties - Remove minItems when its value is the same as maxItems value - Remove ports node v5: - itemize reg and clocks properties' descriptions v6: - Add Reviewed-by: from Rob Herring <robh@kernel.org> and Benoit Parrot <bparrot@ti.com> v7: no change v8: no change v9: - Remove ports-node from the dts example Signed-off-by: -
Qiang Yu authored
Increase driver version for mesa driver to identify the support of new heap buffer interface. Reviewed-by:
Vasily Khoruzhick <anarsoul@gmail.com> Tested-by:
Andreas Baierl <ichgeh@imkreisrum.de> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116131157.13346-6-yuq825@gmail.com
-
Qiang Yu authored
Increase heap buffer backup memory when GP receive PLBU out of memory interrupt, then resume the task. Reviewed-by:
-
Qiang Yu authored
heap buffer is used as output of GP and input of PP for Mali Utgard GPU. Size of heap buffer depends on the task so is a runtime variable. Previously we just create a large enough buffer as heap buffer. Now we add a heap buffer type to be able to increase the backup memory dynamically when GP fail due to lack of heap memory. Reviewed-by:
-
Qiang Yu authored
For dynamically mapping added backup memory of lima_bo to vm. This is a preparation for adding heap buffer support. Reviewed-by:
-
Qiang Yu authored
From Mali r10p0 kernel driver source code. Reviewed-by:
-
- 25 Jan, 2020 3 commits
-
-
Jani Nikula authored
Use drm_core_check_all_features() to ensure both the driver features and the per-device driver features are taken into account when registering debugfs files. v3: - files[i].driver_features == 0 actually means "don't care" v2: - use drm_core_check_all_features() Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123124801.14958-2-jani.nikula@intel.com
-
Jani Nikula authored
Add new drm_core_check_all_features() function to check for a mask of features. All features in the mask are required. Redefine existing drm_core_check_feature() in terms of this function, using the drm_driver_feature enum for the parameter. v3: - add drm_core_check_all_features() (Thomas) v2: - fix kernel-doc (Ville) - add an extra variable for clarity (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Nicolas Boichat authored
The datasheet suggests 60 for tHFP, so let's adjust the number accordingly. This also makes the framerate be 60Hz as intended: 159916.0 * 1000 / ((1200 + 80 + 24 + 60)*(1920 + 20 + 4 + 10)) => 60.00 Hz Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> Fixes: e6d020ee ("drm/panel: support for boe, tv101wum-n53 wuxga dsi video mode panel") Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [added fixes tag] Link: https://patchwork.freedesktop.org/patch/msgid/20200125050256.107404-1-drinkcat@chromium.org
-
- 24 Jan, 2020 2 commits
-
-
Chris Wilson authored
Since drm_global_mutex is a true global mutex across devices, we don't want to acquire it unless absolutely necessary. For maintaining the device local open_count, we can use atomic operations on the counter itself, except when making the transition to/from 0. Here, we tackle the easy portion of delaying acquiring the drm_global_mutex for the final release by using atomic_dec_and_mutex_lock(), leaving the global serialisation across the device opens. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by:
-
Chris Wilson authored
The file is not part of the global drm resource and can be released prior to take the global mutex to drop the open_count (and potentially close) the drm device. As the global mutex is indeed global, not only within the device but across devices, a slow file release mechanism can bottleneck the entire system. However, inside drm_close_helper() there are a number of dev->driver callbacks that take the drm_device as the first parameter... Worryingly some of those callbacks may be (implicitly) depending on the global mutex. v2: Drop the debug message for the open-count, it's included with the drm_file_free() debug message -- and for good measure make that up as reading outside of the mutex. v3: Separate the calling of the filp cleanup outside of drm_global_mutex into a new drm_release_noglobal() hook, so that we can phase the transition. drm/savage relies on the global mutex, and there may be more, so be cautious. Signed-off-by:
Thomas Hellström (VMware) <thomas_os@shipmail.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200124125627.125042-1-chris@chris-wilson.co.uk
-
- 23 Jan, 2020 7 commits
-
-
Sam Ravnborg authored
David Lechner noticed (paraphrased): - not all properties from panel-common are applicable. - missing optional rotation and backlight properties Fix this by listing all allowed properties, and do not allow other properties. Fixes: abdd9e37 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema") Reported-by:
David Lechner <david@lechnology.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Marcel Ziswiler authored
Add display timings for the following 3 display panels manufactured by Logic Technologies Limited: - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display 7" Parallel [1] - LT161010-2NHR e.g. as found in the Toradex Resistive Touch Display 7" Parallel [2] - LT170410-2WHC e.g. as found in the Toradex Capacitive Touch Display 10.1" LVDS [3] Those panels may also be distributed by Endrich Bauelemente Vertriebs GmbH [4]. [1] https://docs.toradex.com/104497-7-inch-parallel-capacitive-touch-display-800x480-datasheet.pdf [2] https://docs.toradex.com/104498-7-inch-parallel-resistive-touch-display-800x480.pdf [3] https://docs.toradex.com/105952-10-1-inch-lvds-capacitive-touch-display-1280x800-datasheet.pdf [4] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by:
Philippe Schenker <philippe.schenker@toradex.com> Reviewed-by:
Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Signed-off-by:
-
Marcel Ziswiler authored
Add bindings for the following 3 to be added display panels manufactured by Logic Technologies Limited: - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display 7" Parallel [1] - LT161010-2NHR e.g. as found in the Toradex Resistive Touch Display 7" Parallel [2] - LT170410-2WHC e.g. as found in the Toradex Capacitive Touch Display 10.1" LVDS [3] Those panels may also be distributed by Endrich Bauelemente Vertriebs GmbH [4]. [1] https://docs.toradex.com/104497-7-inch-parallel-capacitive-touch-display-800x480-datasheet.pdf [2] https://docs.toradex.com/104498-7-inch-parallel-resistive-touch-display-800x480.pdf [3] https://docs.toradex.com/105952-10-1-inch-lvds-capacitive-touch-display-1280x800-datasheet.pdf [4] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30Signed-off-by:
-
Marcel Ziswiler authored
Add vendor prefix for Logic Technologies Limited [1] which is a Chinese display manufacturer e.g. distributed by German Endrich Bauelemente Vertriebs GmbH [2]. [1] https://logictechno.com/contact-us/ [2] https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30Signed-off-by:
-
Rob Herring authored
Convert all the 'simple' panels which match the constraints of the common panel-simple.yaml schema. This conversion is based on how the panels are documented. Some may turn out to be more complex once the schema is applied to actual dts files. Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by:
-
Maxime Ripard authored
Merge tag 'topic/drm-warn-2020-01-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next struct drm_device based drm_WARN* macros Signed-off-by:
Maxime Ripard <maxime@cerno.tech> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87eevrecnf.fsf@intel.com
-
Lyude Paul authored
Mention that the size of these two structs is determined by max_payloads. Suggested by Ville Syrjälä. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 22 Jan, 2020 2 commits
-
-
Lyude Paul authored
The issues caused by: commit 64e62bdf ("drm/dp_mst: Remove VCPI while disabling topology mgr") Prompted me to take a closer look at how we clear the payload state in general when disabling the topology, and it turns out there's actually two subtle issues here. The first is that we're not grabbing &mgr.payload_lock when clearing the payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical lock order is &mgr.payload_lock -> &mgr.lock (because we always want &mgr.lock to be the inner-most lock so topology validation always works), this makes perfect sense. It also means that -technically- there could be racing between someone calling drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a modeset occurring that's modifying the payload state at the same time. The second is the more obvious issue that Wayne Lin discovered, that we're not clearing proposed_payloads when disabling the topology. I actually can't see any obvious places where the racing caused by the first issue would break something, and it could be that some of our higher-level locks already prevent this by happenstance, but better safe then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst() first grabs &mgr.payload_lock followed by &mgr.lock so that we never race when modifying the payload state. Then, we also clear proposed_payloads to fix the original issue of enabling a new topology with a dirty payload state. This doesn't clear any of the drm_dp_vcpi structures, but those are getting destroyed along with the ports anyway. Changes since v1: * Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead - vsyrjala Cc: Sean Paul <sean@poorly.run> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Lyude Paul authored
This has always bugged me but somehow I've never remembered to actually fix it. So let's do that. Signed-off-by:
-
