Dan Carpenter [Wed, 21 Apr 2021 10:18:03 +0000 (13:18 +0300)]
drm/vc4: fix argument ordering in vc4_crtc_get_margins()
Cppcheck complains that the declaration doesn't match the function
definition. Obviously "left" should come before "right". The caller
and the function implementation are done this way, it's just the
declaration which is wrong so this doesn't affect runtime.
Lyude Paul [Fri, 23 Apr 2021 18:43:09 +0000 (14:43 -0400)]
drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_check_mstb_bw_limit()
Lyude Paul [Fri, 23 Apr 2021 18:43:08 +0000 (14:43 -0400)]
drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms()
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
Lyude Paul [Fri, 23 Apr 2021 18:43:07 +0000 (14:43 -0400)]
drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over to using drm_err() and drm_dbg_*().
This was done by using the following cocci script:
Lyude Paul [Fri, 23 Apr 2021 18:43:06 +0000 (14:43 -0400)]
drm/print: Handle potentially NULL drm_devices in drm_dbg_*
While this shouldn't really be something that happens all that often, since
we're going to be using the drm_dbg_* log helpers in DRM helpers it's
technically possible that a driver could use an AUX adapter before it's
been associated with it's respective drm_device. While drivers should take
care to avoid this, there's likely going to be situations where it's
difficult to workaround. And since other logging helpers in the kernel tend
to be OK with NULL pointers (for instance, passing a NULL pointer to a "%s"
argument for a printk-like function in the kernel doesn't break anything),
we should do the same for ours.
Lyude Paul [Fri, 23 Apr 2021 18:43:05 +0000 (14:43 -0400)]
drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Lyude Paul [Fri, 23 Apr 2021 18:43:00 +0000 (14:43 -0400)]
drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
the drm_device to these functions instead of using drm_dp_aux.
Lyude Paul [Fri, 23 Apr 2021 18:42:59 +0000 (14:42 -0400)]
drm/dp: Always print aux channel name in logs
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Lyude Paul [Fri, 23 Apr 2021 18:42:56 +0000 (14:42 -0400)]
drm/dp: Clarify DP AUX registration time
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display bridges. So, let's fix this documentation to clarify when the right
time to use drm_dp_aux_init() or drm_dp_aux_register() is.
Lyude Paul [Fri, 23 Apr 2021 18:42:55 +0000 (14:42 -0400)]
drm/dp: Add backpointer to drm_device in drm_dp_aux
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for doing so.
Note that there is one limitation with this - because some DP AUX adapters
exist as platform devices which are initialized independently of their
respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be
non-NULL until drm_dp_aux_register() has been called. We make sure to point
this out in the documentation for struct drm_dp_aux.
v3:
* Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out
On bochs DRM driver, the execution of "setterm --blank force" results
in a frozen screen instead of a blank screen. It's due to the lack of
the screen blanking support in its code.
Actually, the QEMU bochs vga side can switch to the blanking mode when
the bit 0x20 is cleared on VGA_ATT_IW register (0x3c0), which updates
ar_index in QEMU side. So, essentially, we'd just need to clear the
bit at pipe disable callback; that's what this patch does essentially.
However, a tricky part is that the access via VGA_ATT_IW is done in
"flip-flop"; the first write is for index and the second write is for
the data like palette. Meanwhile, in the current bochs DRM driver,
the flip-flop wasn't considered, and it calls only the register update
once with the value 0x20.
The spec and the actual VGA implementation in QEMU suggests that the
flip flop flag is discarded by reading the CRTC index register
(VGA_IS1_RC, 0x3da). So, in this patch, we add the helper to read a
byte and the call to clear the flip flop flag before changing the
blank / unblank setup via VGA_ATT_IW register.
v1->v2:
* discard ar_flip_flop by reading 0x3da, add bochs_vga_readb()
* include video/vga.h for VGA register definitions
* move the blank/unblank code to bochs_hw_blank()
[Bug][DP501]
If ASPEED P2A (PCI to AHB) bridge is disabled and disallowed for
CVE_2019_6260 item3, and then the monitor's EDID is unable read through
Parade DP501.
The reason is the DP501's FW is mapped to BMC addressing space rather
than Host addressing space.
The resolution is that using "pci_iomap_range()" maps to DP501's FW that
stored on the end of FB (Frame Buffer).
In this case, FrameBuffer reserves the last 2MB used for the image of
DP501.
Andy Shevchenko [Wed, 21 Apr 2021 16:31:57 +0000 (19:31 +0300)]
drm/hx8357d: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Andy Shevchenko [Wed, 21 Apr 2021 16:31:56 +0000 (19:31 +0300)]
drm/ili9225: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Andy Shevchenko [Wed, 21 Apr 2021 16:31:55 +0000 (19:31 +0300)]
drm/ili9341: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Andy Shevchenko [Wed, 21 Apr 2021 16:31:54 +0000 (19:31 +0300)]
drm/ili9486: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Andy Shevchenko [Wed, 21 Apr 2021 16:31:53 +0000 (19:31 +0300)]
drm/mi0283qt: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Andy Shevchenko [Wed, 21 Apr 2021 16:31:52 +0000 (19:31 +0300)]
drm/st7586: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Andy Shevchenko [Wed, 21 Apr 2021 16:31:51 +0000 (19:31 +0300)]
drm/st7735r: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
The commit 7cbb93d89838 ("drm/ast: Use managed pci functions")
converted a few PCI accessors to the managed API and dropped the
manual pci_iounmap() calls, but it seems to have forgotten converting
pci_iomap() to the managed one. It resulted in the leftover resources
after the driver unbind. Let's fix them.
Thomas Zimmermann [Thu, 15 Apr 2021 11:00:37 +0000 (13:00 +0200)]
drm/vmwgfx: Make console emulation depend on DRM_FBDEV_EMULATION
Respect DRM's kconfig setting for fbdev console emulation. If enabled,
it will select all required config options. So remove them from vmwgfx's
Kconfig file.
Dave Airlie [Fri, 23 Apr 2021 02:56:21 +0000 (12:56 +1000)]
Merge tag 'drm-misc-next-fixes-2021-04-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
A few fixes for the next merge window, with some build fixes for anx7625
and lt8912b bridges, incorrect error handling for lt8912b and TTM, and
one fix for TTM page limit accounting.
Lee Jones [Fri, 16 Apr 2021 14:37:12 +0000 (15:37 +0100)]
drm/ttm/ttm_device: Demote kernel-doc abuses
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_device.c:42: warning: Function parameter or member 'ttm_global_mutex' not described in 'DEFINE_MUTEX'
drivers/gpu/drm/ttm/ttm_device.c:42: warning: expecting prototype for ttm_global_mutex(). Prototype was for DEFINE_MUTEX() instead
drivers/gpu/drm/ttm/ttm_device.c:112: warning: Function parameter or member 'ctx' not described in 'ttm_global_swapout'
drivers/gpu/drm/ttm/ttm_device.c:112: warning: Function parameter or member 'gfp_flags' not described in 'ttm_global_swapout'
drivers/gpu/drm/ttm/ttm_device.c:112: warning: expecting prototype for A buffer object shrink method that tries to swap out the first(). Prototype was for ttm_global_swapout() 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: dri-devel@lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210416143725.2769053-28-lee.jones@linaro.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
Lee Jones [Fri, 16 Apr 2021 14:37:09 +0000 (15:37 +0100)]
drm/scheduler/sched_entity: Fix some function name disparity
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/scheduler/sched_entity.c:204: warning: expecting prototype for drm_sched_entity_kill_jobs(). Prototype was for drm_sched_entity_kill_jobs_cb() instead
drivers/gpu/drm/scheduler/sched_entity.c:262: warning: expecting prototype for drm_sched_entity_cleanup(). Prototype was for drm_sched_entity_fini() instead
drivers/gpu/drm/scheduler/sched_entity.c:305: warning: expecting prototype for drm_sched_entity_fini(). Prototype was for drm_sched_entity_destroy() instead
Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> 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-25-lee.jones@linaro.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
Lee Jones [Fri, 16 Apr 2021 14:37:08 +0000 (15:37 +0100)]
drm/ttm/ttm_bo: Fix incorrectly documented function 'ttm_bo_cleanup_refs'
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.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
Krzysztof Kozlowski [Mon, 19 Apr 2021 08:18:06 +0000 (10:18 +0200)]
drm/gma500: correct kerneldoc
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
Phong LE [Mon, 19 Apr 2021 07:12:22 +0000 (09:12 +0200)]
drm: bridge: add it66121 driver
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.
Douglas Anderson [Fri, 16 Apr 2021 22:39:30 +0000 (15:39 -0700)]
drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare
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".
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.
Douglas Anderson [Fri, 16 Apr 2021 22:39:24 +0000 (15:39 -0700)]
drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable()
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.
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.
drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver
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.
Fabio M. De Francesco [Sat, 17 Apr 2021 16:15:52 +0000 (18:15 +0200)]
drm/drm_bufs.c: In switch, add break in default case
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.
Robert Foss [Mon, 19 Apr 2021 09:01:24 +0000 (11:01 +0200)]
drm/bridge/sii8620: fix dependency on extcon
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.
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 <daniel.vetter@intel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20210413094904.3736372-5-daniel.vetter@ffwll.ch
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: Daniel Vetter <daniel.vetter@intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210413094904.3736372-10-daniel.vetter@ffwll.ch
Thomas Zimmermann [Mon, 12 Apr 2021 13:10:43 +0000 (15:10 +0200)]
drm/aperture: Inline fbdev conflict helpers into aperture helpers
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.
Thomas Zimmermann [Mon, 12 Apr 2021 13:10:41 +0000 (15:10 +0200)]
drm/aperture: Add infrastructure for aperture ownership
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()
Daniel Vetter [Tue, 13 Apr 2021 21:33:41 +0000 (23:33 +0200)]
Merge tag 'drm-msm-next-2021-04-11' of https://gitlab.freedesktop.org/drm/msm into drm-next
msm-next from Rob:
* Big DSI phy/pll cleanup. Includes some clk patches, acked by
maintainer
* Initial support for sc7280
* compatibles fixes for sm8150/sm8250
* cleanups for all dpu gens to use same bandwidth scaling paths (\o/)
* various shrinker path lock contention optimizations
* unpin/swap support for GEM objects (disabled by default, enable with
msm.enable_eviction=1 .. due to various combinations of iommu drivers
with older gens I want to get more testing on hw I don't have in front
of me before enabling by default)
* The usual assortment of misc fixes and cleanups
projects / users / jedix / linux-maple.git / log