- 22 Apr, 2021 9 commits
-
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/ttm/ttm_bo.c:293: warning: expecting prototype for function ttm_bo_cleanup_refs(). Prototype was for ttm_bo_cleanup_refs() instead Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by:
Lee Jones <lee.jones@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210416143725.2769053-24-lee.jones@linaro.orgReviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Beatriz Martins de Carvalho authored
Remove space and use tabs for indent the code to follow the Linux kernel coding conventions. Problem found by checkpatch Signed-off-by:
Beatriz Martins de Carvalho <martinsdecarvalhobeatriz@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/0200474fbdb1149856308bccb8e467415f0b3d99.1618828127.git.martinsdecarvalhobeatriz@gmail.com
-
Beatriz Martins de Carvalho authored
Remove space and use tabs for indent the code to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by:
-
Beatriz Martins de Carvalho authored
Remove space and use tabs for indent the code to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by:
-
Beatriz Martins de Carvalho authored
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by:
-
Beatriz Martins de Carvalho authored
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by:
-
Beatriz Martins de Carvalho authored
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by:
-
Beatriz Martins de Carvalho authored
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by:
-
Beatriz Martins de Carvalho authored
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by:
-
- 21 Apr, 2021 6 commits
-
-
Daniel Vetter authored
I always forget where it was, store it until this gets picked up by an internship again. Cc: Wambui Karuga <wambui.karugax@gmail.com> Cc: Melissa Wen <melissa.srw@gmail.com> Acked-by:
Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421152911.1871473-1-daniel.vetter@ffwll.ch
-
Krzysztof Kozlowski authored
Remove trailing whitespaces. No functional change. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Correct kerneldoc (remove wrong /** marker and adjust function name) to fix W=1 warnings: drivers/gpu/drm/gma500/cdv_intel_lvds.c:27: warning: expecting prototype for LVDS I2C backlight control macros(). Prototype was for BRIGHTNESS_MAX_LEVEL() instead drivers/gpu/drm/gma500/intel_gmbus.c:386: warning: expecting prototype for intel_gmbus_setup(). Prototype was for gma_intel_setup_gmbus() instead Signed-off-by: -
Phong LE authored
Add Neil Armstrong and myself as maintainers Signed-off-by:
Phong LE <ple@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210419071223.2673533-4-narmstrong@baylibre.com
-
Phong LE authored
This commit is a simple driver for bridge HMDI it66121. The input format is RBG and there is no color conversion. Audio, HDCP and CEC are not supported yet. Signed-off-by:
-
Phong LE authored
Add the ITE bridge HDMI it66121 bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210419071223.2673533-2-narmstrong@baylibre.com
-
- 20 Apr, 2021 11 commits
-
-
Douglas Anderson authored
Unpreparing and re-preparing a panel can be a really heavy operation. Panels datasheets often specify something on the order of 500ms as the delay you should insert after turning off the panel before turning it on again. In addition, turning on a panel can have delays on the order of 100ms - 200ms before the panel will assert HPD (AKA "panel ready"). The above means that we should avoid turning a panel off if we're going to turn it on again shortly. The above becomes a problem when we want to read the EDID of a panel. The way that ordering works is that userspace wants to read the EDID of the panel _before_ fully enabling it so that it can set the initial mode correctly. However, we can't read the EDID until we power it up. This leads to code that does this dance (like ps8640_bridge_get_edid()): 1. When userspace requests EDID / the panel modes (through an ioctl), we power on the panel just enough to read the EDID and then power it off. 2. Userspace then turns the panel on. There's likely not much time between step #1 and #2 and so we want to avoid powering the panel off and on again between those two steps. Let's use Runtime PM to help us. We'll move the existing prepare() and unprepare() to be runtime resume() and runtime suspend(). Now when we want to prepare() or unprepare() we just increment or decrement the refcount. We'll default to a 1 second autosuspend delay which seems sane given the typical delays we see for panels. A few notes: - It seems the existing unprepare() and prepare() are defined to be no-ops if called extra times. We'll preserve that behavior but may try to remove it in a future patch. - This is a slight change in the ABI of simple panel. If something was absolutely relying on the unprepare() to happen instantly that simply won't be the case anymore. I'm not aware of anyone relying on that behavior, but if there is someone then we'll need to figure out how to enable (or disable) this new delayed behavior selectively. - In order for this to work we now have a hard dependency on "PM". From memory this is a legit thing to assume these days and we don't have to find some fallback to keep working if someone wants to build their system without "PM". Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
Douglas Anderson authored
If we just leave the detect() function as NULL then the upper layers assume we're always connected. There's no reason for a stub. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
-
Douglas Anderson authored
We prepared the panel in pre_enable() so we should unprepare it in post_disable() to match. Signed-off-by:
-
Douglas Anderson authored
Let's make the remove() function strictly the reverse of the probe() function so it's easier to reason about. This patch was created by code inspection and should move us closer to a proper remove. Signed-off-by:
-
Douglas Anderson authored
A random comment inside a function had "/**" in front of it. That doesn't make sense. Remove. Signed-off-by:
-
Douglas Anderson authored
The clock framework makes it simple to deal with an optional clock. You can call clk_get_optional() and if the clock isn't specified it'll just return NULL without complaint. It's valid to pass NULL to enable/disable/prepare/unprepare. Let's make use of this to simplify things a tiny bit. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Douglas Anderson authored
The drm_bridge_chain_pre_enable() is not the proper opposite of drm_bridge_chain_post_disable(). It continues along the chain to _before_ the starting bridge. Let's fix that. Fixes: 05193dc3 ("drm/bridge: Make the bridge chain a double-linked list") Signed-off-by:
-
Neil Armstrong authored
On the Amlogic SoCs, the DW-HDMI HW support is here but the DW-HDMI CEC signal is not connected to a physical pin, leading to confusion when the dw-hdmi cec controller can't communicate on the bus. Disable it to avoid exposing a non-functinal bus. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://patchwork.freedesktop.org/patch/msgid/20210416092737.1971876-3-narmstrong@baylibre.com
-
Jernej Skrabec authored
This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver. On some SoCs, the CEC functionality is enabled in the IP config bits, but the CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set but the DW-HDMI CEC signal is not connected to a physical pin, leading to some confusion when the DW-HDMI CEC controller can't communicate on the bus. Reviewed-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Fabio M. De Francesco authored
Added a "break" in the default case of a switch select statement. GCC complains, although this "break" is not strictly necessary for the code to work as expected. Signed-off-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Since commit 890880dd Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Acked-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
- 19 Apr, 2021 6 commits
-
-
Robert Foss authored
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency on EXTCON, which causes issues when sii8620 is built as a builtin and EXTCON is built as a module. The symptoms are 'undefined reference' errors caused by the symbols in EXTCON not being available to the sii8620 driver. Fixes: 68883844 ("drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210419090124.153560-1-robert.foss@linaro.org
-
Christian König authored
Drop some ussage of mem in the code. Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Christian König authored
Change a couple of cases where it makes more sense to use the base size instead of the number of pages in the resource. Signed-off-by:
-
Christian König authored
So far we only warned when the BOs where pinned and not idle. Also warn if we see a pinned BO in general. Signed-off-by:
Leo Liu <leo.liu@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210415084730.2057-3-christian.koenig@amd.com
-
Christian König authored
We want to drop support in TTM for this. Signed-off-by:
-
Christian König authored
Releasing pinned BOs is illegal now. Signed-off-by:
-
- 15 Apr, 2021 4 commits
-
-
Daniel Vetter authored
Since commit 890880dd Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here for both dcss and imx-drm drivers. Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Daniel Vetter authored
Since commit 890880dd Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. Acked-by:
Maxime Ripard <maxime@cerno.tech> Signed-off-by:
-
Daniel Vetter authored
Since commit 890880dd Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Date: Fri Jan 4 09:56:10 2019 +0100 drm: Auto-set allow_fb_modifiers when given modifiers at plane init this is done automatically as part of plane init, if drivers set the modifier list correctly. Which is the case here. It was slightly inconsistently though, since planes with only linear modifier support haven't listed that explicitly. Fix that, and cc: stable to allow userspace to rely on this. Again don't backport further than where Paul's patch got added. Cc: stable@vger.kernel.org # v5.1 + Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Vivek Kasireddy authored
If support for Blob resources is available, then dumb BOs created by the driver can be considered as guest Blobs. v2: Don't skip transfer and flush commands as part of plane update as the device may have created a shared mapping. (Gerd) v3: Don't create dumb BOs as Guest blobs if Virgl is enabled. (Gurchetan) Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Acked-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210413052614.2486768-1-vivek.kasireddy@intel.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
- 14 Apr, 2021 4 commits
-
-
Felix Kuehling authored
Pages in SG BOs were not allocated by TTM. So don't count them against TTM's pages limit. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
Thomas Zimmermann authored
Fbdev's helpers for handling conflicting framebuffer drivers are related to framebuffer apertures, not console emulation. Therefore remove them from drm_fb_helper.h and inline them into the aperture helpers. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412131043.5787-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
Mass-convert all drivers from FB helpers to aperture interfaces. No functional changes besides checking for returned errno codes. Signed-off-by:
-
Thomas Zimmermann authored
Platform devices might operate on firmware framebuffers, such as VESA or EFI. Before a native driver for the graphics hardware can take over the device, it has to remove any platform driver that operates on the firmware framebuffer. Aperture helpers provide the infrastructure for native drivers to remove the generic ones. For now, this only concerns generic fbdev drivers. Code for removing these is provided by drm_fb_helper_remove_conflicting_framebuffers() et al. Simply wrap these functions for now. At a later point, code can be added for generic DRM drivers to acquire firmware framebuffers. v2: * fix docs for drm_aperture_remove_framebuffers() Signed-off-by:
-
