Thomas Zimmermann [Tue, 8 Mar 2022 19:52:14 +0000 (20:52 +0100)]
drm/gma500: Remove struct psb_gtt.sem sempahore
The semaphore at struct psb_mmu_driver.sem protects access to the MMU
fields. Additional locking with struct psb_gtt.sem is unnecessary. Remove
the field and related code.
Thomas Zimmermann [Tue, 8 Mar 2022 19:52:13 +0000 (20:52 +0100)]
drm/gma500: Move GTT locking into GTT helpers
Acquire the GTT mutex in psb_gtt_{insert,remove}_pages(). Remove
locking from callers. Also remove the GTT locking around the resume
code. Resume does not run concurrently with other GTT operations.
Thomas Zimmermann [Tue, 8 Mar 2022 19:52:12 +0000 (20:52 +0100)]
drm/gma500: Acquire reservation lock for GEM objects
Protect concurrent access to struct psb_gem_object by acquiring
the GEM object's reservation lock; as it's supposed to be. The
use of the GTT mutex can now be moved into GTT code.
Dmitry Baryshkov [Wed, 16 Mar 2022 07:46:48 +0000 (10:46 +0300)]
drm/blend: fix typo in the comment
The documentation for drm_rotation_simplify() uses DRM_MODE_ROTATE_X,
while it's clear the comment should mention DRM_MODE_REFLECT_X
instead. The example passes all flags except the DRM_MODE_REFLECT_X as
supported and expects to eliminate this flag.
Ville Syrjälä [Fri, 18 Feb 2022 10:03:47 +0000 (12:03 +0200)]
drm/bridge: Use drm_mode_copy()
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.
Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.
@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}
@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, &E)
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)
@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(&mode, &E)
|
- memcpy(&mode, E, S)
+ drm_mode_copy(&mode, E)
)
Ville Syrjälä [Fri, 18 Feb 2022 10:03:42 +0000 (12:03 +0200)]
drm: Add drm_mode_init()
Add a variant of drm_mode_copy() that explicitly clears out
the list head of the destination mode. Helpful to guarantee
we don't have stack garbage left in there for on-stack modes.
Zack Rusin [Wed, 2 Mar 2022 15:24:26 +0000 (10:24 -0500)]
drm/vmwgfx: Stop using surface dma commands on most configurations
Initial version of guest backed objects in the host had some performance
issues that made using surface-dma's instead of direct copies faster.
Surface dma's force a migration to vram which at best is slow and at
worst is impossible (e.g. on svga3 where there's not enough vram
to migrate fb's to it).
Slowly migrate away from surface dma's to direct copies by limiting
their usage to systems with more than 32MB of vram.
Zack Rusin [Mon, 7 Mar 2022 16:24:12 +0000 (11:24 -0500)]
drm/vmwgfx: Implement MSI/MSI-X support for IRQs
SVGAv3 deprecates legacy interrupts and adds support for MSI/MSI-X. With
MSI the driver visible side remains largely unchanged but with MSI-X
each interrupt gets delivered on its own vector.
Add support for MSI/MSI-X while preserving the old functionality for
SVGAv2. Code between the SVGAv2 and SVGAv3 is exactly the same, only
the number of available vectors changes, in particular between legacy
and MSI-X interrupts.
Zack Rusin [Wed, 2 Mar 2022 15:24:24 +0000 (10:24 -0500)]
drm/vmwgfx: Initialize drm_mode_fb_cmd2
Transition to drm_mode_fb_cmd2 from drm_mode_fb_cmd left the structure
unitialized. drm_mode_fb_cmd2 adds a few additional members, e.g. flags
and modifiers which were never initialized. Garbage in those members
can cause random failures during the bringup of the fbcon.
Initializing the structure fixes random blank screens after bootup due
to flags/modifiers mismatches during the fbcon bring up.
Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2") Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: <stable@vger.kernel.org> # v4.10+ Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-7-zack@kde.org
Zack Rusin [Wed, 2 Mar 2022 15:24:23 +0000 (10:24 -0500)]
drm/vmwgfx: Allow querying of the SVGA PCI id from the userspace
Mesa3D loaders require knowledge of the devices PCI id. SVGAv2 and v3
have different PCI id's, but the same driver is used to handle them both.
To allow Mesa3D svga driver to be loaded automatically for both SVGAv2
and SVGAv3 make the kernel return the PCI id of the currently running
device.
Zack Rusin [Wed, 2 Mar 2022 15:24:22 +0000 (10:24 -0500)]
drm/vmwgfx: Fix fencing on SVGAv3
Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed
FIFO's and replaced them with command buffers and extra registers.
The initial version of SVGAv3 lacked support for most advanced features
(e.g. 3D) which made fences unnecessary. That is no longer the case,
especially as 3D support is being turned on.
Switch from FIFO commands and capabilities to command buffers and extra
registers to enable fences on SVGAv3.
Zack Rusin [Wed, 2 Mar 2022 15:24:21 +0000 (10:24 -0500)]
drm/vmwgfx: Print capabilities early during the initialization
Capabilities were logged at the end of initialization so any early errors
would make them not appear in the logs. Which is also when they're needed
the most.
Print the the capabilities right after fetching them, before the init
code starts using them to make sure they always show up in the logs.
Zack Rusin [Wed, 2 Mar 2022 15:24:20 +0000 (10:24 -0500)]
drm/vmwgfx: Cleanup multimon initialization code
The results of the legacy display unit initialization were being silently
ignored. Unifying the selection of number of display units based
on whether the underlying device supports multimon makes it easier
to add error checking to all paths.
This makes the driver report the errors in ldu initialization paths
and try to recover from them.
Martin Krastev [Wed, 2 Mar 2022 15:24:19 +0000 (10:24 -0500)]
drm/vmwgfx: Add support for CursorMob and CursorBypass 4
* Add support for CursorMob
* Add support for CursorBypass 4
* Refactor vmw_du_cursor_plane_atomic_update to be kms-helper-atomic
-- move BO mappings to vmw_du_cursor_plane_prepare_fb
-- move BO unmappings to vmw_du_cursor_plane_cleanup_fb
Cursor mobs are a new svga feature which enables support for large
cursors, e.g. large accessibility cursor on platforms with vmwgfx. It
also cleans up the cursor code and makes it more uniform with the rest
of modern guest backed objects support.
Brian Norris [Wed, 2 Mar 2022 02:11:38 +0000 (18:11 -0800)]
drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX
If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
Let's get a runtime PM reference, and check that we "see" the panel.
Don't force any panel power-up, etc., because that can be intrusive, and
that's not what other drivers do (see
drivers/gpu/drm/bridge/ti-sn65dsi86.c and
drivers/gpu/drm/bridge/parade-ps8640.c.)
Douglas Anderson [Tue, 8 Mar 2022 19:06:59 +0000 (11:06 -0800)]
drm/bridge: Add myself as a reviewer for the Parade PS8640 bridge chip
Though the parade bridge chip is a little bit of a black box, I'm at
least interested in hearing about changes to the driver since this
bridge chip is used on some Chromebooks that I'm involved with.
Douglas Anderson [Tue, 8 Mar 2022 19:06:58 +0000 (11:06 -0800)]
drm/bridge: Add myself as a reviewer for the TI SN65DSI86 bridge chip
I've spent quite a bit of time poking at this driver and it's used on
several Chromebooks I'm involved with. I'd like to get notified about
patches. Add myself as a reviewer. It's expected that changes will
still be landed through drm-misc as they always have been.
Chen-Yu Tsai [Tue, 8 Mar 2022 16:07:58 +0000 (00:07 +0800)]
drm: ssd130x: Always apply segment remap setting
Currently the ssd130x driver only sets the segment remap setting when
the device tree requests it; it however does not clear the setting if
it is not requested. This leads to the setting incorrectly persisting
if the hardware is always on and has no reset GPIO wired. This might
happen when a developer is trying to find the correct settings for an
unknown module, and cause the developer to get confused because the
settings from the device tree are not consistently applied.
Make the driver apply the segment remap setting consistently, setting
the value correctly based on the device tree setting. This also makes
this setting's behavior consistent with the other settings, which are
always applied.
Chen-Yu Tsai [Tue, 8 Mar 2022 16:07:57 +0000 (00:07 +0800)]
drm: ssd130x: Fix COM scan direction register mask
The SSD130x's command to toggle COM scan direction uses bit 3 and only
bit 3 to set the direction of the scanout. The driver has an incorrect
GENMASK(3, 2), causing the setting to be set on bit 2, rendering it
ineffective.
Fix the mask to only bit 3, so that the requested setting is applied
correctly.
Rex-BC Chen [Wed, 9 Mar 2022 07:36:37 +0000 (15:36 +0800)]
drm/bridge: anx7625: config hs packets end aligned to avoid screen shift
This device requires the packets on lanes aligned at the end to fix
screen shift or scroll.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Xin Ji <xji@analogixsemi.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220309073637.3591-4-rex-bc.chen@mediatek.com
Rex-BC Chen [Wed, 9 Mar 2022 07:36:36 +0000 (15:36 +0800)]
drm/mediatek: implement the DSI HS packets aligned
Some DSI RX devices (for example, anx7625) require last alignment of
packets on all lanes after each row of data is sent.
Otherwise, there will be some issues of shift or scroll for screen.
Take horizontal_sync_active_byte for a example,
we roundup the HSA packet data to lane number, and the subtraction of 2
is the packet data value added by the roundup operation, making the
long packets are integer multiples of lane number.
This value (2) varies with the lane number, and that is the reason we
do this operation when the lane number is 4.
In the previous operation of function "mtk_dsi_config_vdo_timing",
the length of HSA and HFP data packets has been adjusted to an
integration multiple of lane number.
Since the number of RGB data packets cannot be guaranteed to be an
integer multiple of lane number, we modify the data packet length of
HBP so that the number of HBP + RGB is equal to the lane number.
So after sending a line of data (HSA + HBP + RGB + HFP), the data
lanes are aligned.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220309073637.3591-3-rex-bc.chen@mediatek.com
Rex-BC Chen [Wed, 9 Mar 2022 07:36:35 +0000 (15:36 +0800)]
drm/dsi: transfer DSI HS packets ending at the same time
Since a HS transmission is composed of an arbitrary number
of bytes that may not be an integer multiple of lanes, some
lanes may run out of data before others.
(Defined in 6.1.3 of mipi_DSI_specification_v.01-02-00)
However, for some DSI RX devices (for example, anx7625),
there is a limitation that packet number should be the same
on all DSI lanes. In other words, they need to end a HS at
the same time.
Because this limitation is for some specific DSI RX devices,
it is more reasonable to put the enable control in these
DSI RX drivers. If DSI TX driver knows the information,
they can adjust the setting for this situation.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220309073637.3591-2-rex-bc.chen@mediatek.com
The datasheet lists the minimum Serial clock cycle (Write) as 66ns which is
15MHz. Mostly it can do much better than that and is in fact often run at
32MHz. With a clever driver that runs configuration commands at a low speed
and only the pixel data at the maximum speed the configuration can't be
messed up by transfer errors and the speed is only limited by the amount of
pixel glitches that one is able to tolerate.
Noralf Trønnes [Wed, 24 Nov 2021 15:07:52 +0000 (16:07 +0100)]
dt-bindings: display: sitronix, st7735r: Fix backlight in example
The backlight property was lost during conversion to yaml in commit abdd9e3705c8 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema").
Put it back.
Fixes: abdd9e3705c8 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema") Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-2-noralf@tronnes.org
Matthew Auld [Tue, 8 Feb 2022 15:12:28 +0000 (15:12 +0000)]
drm/doc: pull in drm_buddy.c
Make sure we pull in the kernel-doc for this.
Reported-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220208151228.344997-1-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
Maxime Ripard [Mon, 21 Feb 2022 09:59:15 +0000 (10:59 +0100)]
drm/komeda: plane: Remove redundant color encoding and range initialisation
The komeda KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Limited Range,
respectively.
Since the initial value wasn't carried over in the state, the driver had
to set it again in komeda_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.
Cc: Brian Starkey <brian.starkey@arm.com> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-20-maxime@cerno.tech
The komeda KMS driver will call drm_plane_create_zpos_property() with an
init value of the plane index.
Since the initial value wasn't carried over in the state, the driver had
to set it again in komeda_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.
Cc: Brian Starkey <brian.starkey@arm.com> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-10-maxime@cerno.tech
Maxime Ripard [Mon, 21 Feb 2022 09:58:57 +0000 (10:58 +0100)]
drm/komeda: plane: switch to plane reset helper
komeda_plane_reset() does the state initialisation by copying a lot of
the code found in the __drm_atomic_helper_plane_reset(). Let's switch to
that helper and reduce the boilerplate.
Cc: Brian Starkey <brian.starkey@arm.com> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-2-maxime@cerno.tech
Michal Suchanek [Fri, 25 Feb 2022 20:51:34 +0000 (21:51 +0100)]
sysfb: Enable boot time VESA graphic mode selection
Since switch to simplefb/simpledrm VESA graphic mode selection with vga=
kernel parameter is no longer available with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
This option is selected by vesafb but not simplefb/simpledrm.
To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
dependency of BOOT_VESA_SUPPORT on FB, also drop the FB_ prefix. Select
the option from sysfb rather than the drivers that depend on it.
The BOOT_VESA_SUPPORT is not specific to framebuffer but rather to x86
platform, move it from fbdev to x86 Kconfig.
Nikita Yushchenko [Sat, 25 Dec 2021 06:31:51 +0000 (09:31 +0300)]
drm/bridge_connector: enable HPD by default if supported
Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
get ignored unless somebody calls drm_bridge_hpd_enable(). When the
connector for the bridge is bridge_connector, such a call is done from
drm_bridge_connector_enable_hpd().
However drm_bridge_connector_enable_hpd() is never called on init paths,
documentation suggests that it is intended for suspend/resume paths.
In result, once encoders are switched to bridge_connector,
bridge-detected HPD stops working.
This patch adds a call to that API on init path.
This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD
events via interrupts.
Fix following coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c:316:11-12:
WARNING this kind of initialization is deprecated.
`void *map = map` has the same form of
uninitialized_var() macro. I remove the redundant assignement. It has
been tested with gcc (Debian 8.3.0-6) 8.3.0.
The patch which removed uninitialized_var() is:
https://lore.kernel.org/all/20121028102007.GA7547@gmail.com/
And there is very few "/* GCC */" comments in the Linux kernel code now.
Colin Ian King [Wed, 2 Mar 2022 17:53:09 +0000 (17:53 +0000)]
drm/ssd130x: remove redundant initialization of pointer mode
Pointer mode is being assigned a value that is never read, it is
being re-assigned later with a new value. The initialization is
redundant and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/solomon/ssd130x.c:582:27: warning: Value stored
to 'mode' during its initialization is never read [deadcode.DeadStores]
Thomas Zimmermann [Wed, 23 Feb 2022 19:38:03 +0000 (20:38 +0100)]
fbdev: Improve performance of cfb_imageblit()
Improve the performance of cfb_imageblit() by manually unrolling
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically. This change keeps cfb_imageblit()
in sync with sys_imagebit().
A microbenchmark measures the average number of CPU cycles
for cfb_imageblit() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging).
Thomas Zimmermann [Wed, 23 Feb 2022 19:38:01 +0000 (20:38 +0100)]
fbdev: Improve performance of sys_imageblit()
Improve the performance of sys_imageblit() by manually unrolling
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically. The resulting binary code was even
slower than the cfb_imageblit() helper, which uses the same algorithm,
but operates on I/O memory.
A microbenchmark measures the average number of CPU cycles
for sys_imageblit() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging). The value
for CFB is given as a reference.
Thomas Zimmermann [Wed, 23 Feb 2022 19:38:00 +0000 (20:38 +0100)]
fbdev: Improve performance of sys_fillrect()
Improve the performance of sys_fillrect() by using word-aligned
32/64-bit mov instructions. While the code tried to implement this,
the compiler failed to create fast instructions. The resulting
binary instructions were even slower than cfb_fillrect(), which
uses the same algorithm, but operates on I/O memory.
A microbenchmark measures the average number of CPU cycles
for sys_fillrect() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging). The value
for CFB is given as a reference.
Hsin-Yi Wang [Thu, 17 Feb 2022 08:22:25 +0000 (16:22 +0800)]
drm/bridge: Clear the DP_AUX_I2C_MOT bit passed in aux read command.
If the previous transfer didn't end with a command without DP_AUX_I2C_MOT,
the next read trasnfer will miss the first byte. But if the command in
previous transfer is requested with length 0, it's a no-op to anx7625
since it can't process this command. anx7625 requires the last command
to be read command with length > 0.
It's observed that if we clear the DP_AUX_I2C_MOT in read transfer, we
can still get correct data. Clear the read commands with DP_AUX_I2C_MOT
bit to fix this issue.
Melissa Wen [Mon, 28 Feb 2022 18:16:47 +0000 (17:16 -0100)]
drm/v3d: centralize error handling when init scheduler fails
Remove redundant error message (since now it is very similar to what
we do in drm_sched_init) and centralize all error handling in a
unique place, as we follow the same steps in any case of failure.
Hsin-Yi Wang [Mon, 28 Feb 2022 08:14:21 +0000 (16:14 +0800)]
drm/bridge: it6505: Fix the read buffer array bound
The size of read_buf is READ_BUFFER_SIZE (200), so we can't access it
with read_buf + PAGE_SIZE (4096). Extend the READ_BUFFER_SIZE to 400 and
set the end position to read_buf + READ_BUFFER_SIZE.
Noralf Trønnes [Sun, 27 Feb 2022 12:47:13 +0000 (13:47 +0100)]
drm/tiny: Add MIPI DBI compatible SPI driver
Add a driver that will work with most MIPI DBI compatible SPI panels.
This avoids adding a driver for every new MIPI DBI compatible controller
that is to be used by Linux. The 'compatible' Device Tree property with
a '.bin' suffix will be used to load a firmware file that contains the
controller configuration.
v5:
- kconfig: s/DRM_KMS_CMA_HELPER/DRM_GEM_CMA_HELPER/ (Sam)
- kconfig: Add select VIDEOMODE_HELPERS (Sam)
- kconfig: Add wiki url in the description (Sam)
- Split out and use of_get_drm_panel_display_mode()(Sam)
- Only use the first compatible to look for a firmware file since the
binding mandates 2 compatibles.
- Make having a firmware file mandatory so we can print an error
message if it's missing to improve the user experience. It's very
unlikely that a controller doesn't need to be initialized and if
it doesn't, it's possible to have a firmware file containing only
a DCS NOP.
v4:
- Move driver to drm/tiny where the other drivers of its kind are located.
The driver module will not be shared with a future DPI driver after all.
v3:
- Move properties to DT (Maxime)
- The MIPI DPI spec has optional support for DPI where the controller is
configured over DBI. Rework the command functions so they can be moved
to drm_mipi_dbi and shared with a future panel-mipi-dpi-spi driver
v2:
- Drop model property and use compatible instead (Rob)
- Add wiki entry in MAINTAINERS
Noralf Trønnes [Sun, 27 Feb 2022 12:47:12 +0000 (13:47 +0100)]
drm/mipi-dbi: Add driver_private member to struct mipi_dbi_dev
devm_drm_dev_alloc() can't allocate structures that embed a structure
which then again embeds drm_device. Workaround this by adding a
driver_private pointer to struct mipi_dbi_dev which the driver can use for
its additional state.
Maxime Ripard [Mon, 21 Feb 2022 09:59:18 +0000 (10:59 +0100)]
drm/omap: plane: Remove redundant color encoding and range initialisation
The omap KMS driver will call drm_plane_create_color_properties() with
a default encoding and range values of BT601 and Full Range,
respectively.
Since the initial value wasn't carried over in the state, the driver had
to set it again in omap_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.
Dave Stevenson [Mon, 21 Feb 2022 09:59:14 +0000 (10:59 +0100)]
drm/object: Add default color encoding and range value at reset
The drm_plane_create_color_properties() function asks for an initial
value for the color encoding and range, and will set the associated
plane state variable with that value if a state is present.
However, that function is usually called at a time where there's no
state yet. Since the drm_plane_state reset helper doesn't take care of
reading that value when it's called, it means that in most cases the
initial value will be 0 (so DRM_COLOR_YCBCR_BT601 and
DRM_COLOR_YCBCR_LIMITED_RANGE, respectively), or the drivers will have
to work around it.
Let's add some code in __drm_atomic_helper_plane_state_reset() to get
the initial encoding and range value if the property has been attached
in order to fix this.
The sun4i KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in sun4i_backend_layer_reset().
However, the helpers have been adjusted to set it properly at reset, so
this is not needed anymore.
The sti KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in sti_plane_reset().
However, the helpers have been adjusted to set it properly at reset, so
this is not needed anymore.
The rcar-du KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in rcar_du_plane_reset() and rcar_du_vsp_plane_reset().
However, the helpers have been adjusted to set it properly at reset, so
this is not needed anymore.
The omap KMS driver will call drm_plane_create_zpos_property() with an
init value of the plane index and the plane type.
Since the initial value wasn't carried over in the state, the driver had
to set it again in omap_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.
The nouveau KMS driver will call drm_plane_create_zpos_property() with
an init value depending on the plane purpose.
Since the initial value wasn't carried over in the state, the driver had
to set it again in nv50_wndw_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.
Cc: nouveau@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-14-maxime@cerno.tech
The mdp KMS driver will call drm_plane_create_zpos_property() with an
init value depending on the plane purpose.
Since the initial value wasn't carried over in the state, the driver had
to set it again in mdp5_plane_reset(). However, the helpers have been
adjusted to set it properly at reset, so this is not needed anymore.
Cc: freedreno@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-13-maxime@cerno.tech
Dave Stevenson [Mon, 21 Feb 2022 09:59:03 +0000 (10:59 +0100)]
drm/object: Add default zpos value at reset
The drm_plane_create_zpos_property() function asks for an initial value,
and will set the associated plane state variable with that value if a
state is present.
However, that function is usually called at a time where there's no
state yet. Since the drm_plane_state reset helper doesn't take care of
reading that value when it's called, it means that in most cases the
initial value will be 0, or the drivers will have to work around it.
Let's add some code in __drm_atomic_helper_plane_state_reset() to get
the initial zpos value if the property has been attached in order to fix
this.
Dave Stevenson [Mon, 21 Feb 2022 09:59:02 +0000 (10:59 +0100)]
drm/object: Add drm_object_property_get_default_value() function
Some functions to create properties (drm_plane_create_zpos_property or
drm_plane_create_color_properties for example) will ask for a range of
acceptable value and an initial one.
This initial value is then stored in the values array for that property.
Maxime Ripard [Mon, 21 Feb 2022 09:59:00 +0000 (10:59 +0100)]
drm/omap: plane: Fix zpos initial value mismatch
While the omap_plane_init() function calls
drm_plane_create_zpos_property() with an initial value of 0,
omap_plane_reset() will force it to another value depending on the plane
type.
Fix the discrepancy by setting the initial zpos value to the same value
in the drm_plane_create_zpos_property() call.
Jagan Teki [Wed, 2 Feb 2022 16:04:14 +0000 (21:34 +0530)]
drm: of: Lookup if child node has panel or bridge
Devices can also be child nodes when we also control that device
through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
drm_of_find_panel_or_bridge can lookup panel or bridge for a given
device has port and endpoint and it fails to lookup if the device
has a child nodes.
This patch add support to lookup for a child node of the given parent
that isn't either port or ports.
Example OF graph representation of DSI host, which has port but
not has ports and has child panel node.
Raphael Gallais-Pou [Fri, 11 Feb 2022 10:46:20 +0000 (11:46 +0100)]
drm/stm: ltdc: add support for CRC hashing feature
This patch adds the CRC hashing feature supported by some recent hardware
versions of the LTDC. This is useful for test suite such as IGT-GPU-tools
[1] where a CRTC output frame can be compared to a test reference frame
thanks to their respective CRC hash.
Nathan Chancellor [Tue, 22 Feb 2022 15:20:46 +0000 (08:20 -0700)]
drm/stm: Avoid using val uninitialized in ltdc_set_ycbcr_config()
Clang warns:
drivers/gpu/drm/stm/ltdc.c:625:2: warning: variable 'val' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default:
^~~~~~~
drivers/gpu/drm/stm/ltdc.c:635:2: note: uninitialized use occurs here
val |= LxPCR_YCEN;
^~~
drivers/gpu/drm/stm/ltdc.c:600:9: note: initialize the variable 'val' to silence this warning
u32 val;
^
= 0
1 warning generated.
Use a return instead of break in the default case to fix the warning.
Add an error message so that this return is not silent, which could hide
issues in the future.
Kees Cook [Fri, 25 Feb 2022 03:56:10 +0000 (19:56 -0800)]
drm/dp: Fix OOB read when handling Post Cursor2 register
The link_status array was not large enough to read the Adjust Request
Post Cursor2 register, so remove the common helper function to avoid
an OOB read, found with a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor':
drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds]
59 | return link_status[r - DP_LANE0_1_STATUS];
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replace the only user of the helper with an open-coded fetch and decode,
similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
Cc: Daniel Vetter <daniel@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: dri-devel@lists.freedesktop.org Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments") Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20220105173507.2420910-1-keescook@chromium.org Signed-off-by: Thierry Reding <treding@nvidia.com>
Hans de Goede [Mon, 21 Feb 2022 22:00:45 +0000 (23:00 +0100)]
drm/simpledrm: Add "panel orientation" property on non-upright mounted LCD panels
Some devices use e.g. a portrait panel in a standard laptop casing made
for landscape panels. efifb calls drm_get_panel_orientation_quirk() and
sets fb_info.fbcon_rotate_hint to make fbcon rotate the console so that
it shows up-right instead of on its side.
When switching to simpledrm the fbcon renders on its side. Call the
drm_connector_set_panel_orientation_with_quirk() helper to add
a "panel orientation" property on devices listed in the quirk table,
to make the fbcon (and aware userspace apps) rotate the image to
display properly.
create a pot-sized mm, then allocate one of each possible
order within. This should leave the mm with exactly one
page left. Free the largest block, then whittle down again.
Eventually we will have a fully 50% fragmented mm.
v2(Matthew Auld):
- removed unnecessary test succeeded print
- replace list_del()/list_add_tail() with list_move_tail()
projects / users / jedix / linux-maple.git / log