Melissa Wen [Tue, 1 Feb 2022 21:26:51 +0000 (20:26 -0100)]
drm/vc4: add tracepoints for CL submissions
Trace submit_cl_ioctl and related IRQs for CL submission and bin/render
jobs execution. It might be helpful to get a rendering timeline and
track job throttling.
Geert Uytterhoeven [Thu, 17 Mar 2022 08:18:29 +0000 (09:18 +0100)]
drm/ssd130x: Reduce temporary buffer sizes
ssd130x_clear_screen() allocates a temporary buffer sized to hold one
byte per pixel, while it only needs to hold one bit per pixel.
ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
byte per pixel for the whole frame buffer, while it only needs to hold
one bit per pixel for the part that is to be updated.
Pass dst_pitch to drm_fb_xrgb8888_to_mono(), as we have already
calculated it anyway.
Geert Uytterhoeven [Thu, 17 Mar 2022 08:18:28 +0000 (09:18 +0100)]
drm/ssd130x: Fix rectangle updates
The rectangle update functions ssd130x_fb_blit_rect() and
ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 !=
0, or when y1 or y2 are not aligned to display page boundaries.
E.g. when used as a text console, only the first line of text is shown
on the display.
1. The buffer passed by ssd130x_fb_blit_rect() points to the first
byte of monochrome bitmap data, and thus has its origin at (x1,
y1), while ssd130x_update_rect() assumes it is at (0, 0).
Fix ssd130x_update_rect() by changing the vertical and horizontal
loop ranges, and adding the offsets only when needed.
2. In ssd130x_fb_blit_rect(), align y1 and y2 to the display page
boundaries before doing the color conversion, so the full page
is converted and updated.
Remove the correction for an unaligned y1 from
ssd130x_update_rect(), and add a check to make sure y1 is aligned.
Geert Uytterhoeven [Thu, 17 Mar 2022 08:18:27 +0000 (09:18 +0100)]
drm/format-helper: Fix XRGB888 to monochrome conversion
The conversion functions drm_fb_xrgb8888_to_mono() and
drm_fb_gray8_to_mono_line() do not behave correctly when the
horizontal boundaries of the clip rectangle are not multiples of 8:
a. When x1 % 8 != 0, the calculated pitch is not correct,
b. When x2 % 8 != 0, the pixel data for the last byte is wrong.
Simplify the code and fix (a) by:
1. Removing start_offset, and always storing the first pixel in the
first bit of the monochrome destination buffer.
Drivers that require the first pixel in a byte to be located at an
x-coordinate that is a multiple of 8 can always align the clip
rectangle before calling drm_fb_xrgb8888_to_mono().
Note that:
- The ssd130x driver does not need the alignment, as the
monochrome buffer is a temporary format,
- The repaper driver always updates the full screen, so the clip
rectangle is always aligned.
2. Passing the number of pixels to drm_fb_gray8_to_mono_line(),
instead of the number of bytes, and the number of pixels in the
last byte.
Fix (b) by explicitly setting the target bit, instead of always setting
bit 7 and shifting the value in each loop iteration.
Remove the bogus pitch check, which operates on bytes instead of pixels,
and triggers when e.g. flashing the cursor on a text console with a font
that is 8 pixels wide.
Drop the confusing comment about scanlines, as a pitch in bytes always
contains a multiple of 8 pixels.
While at it, use the drm_rect_height() helper instead of open-coding the
same operation.
Update the comments accordingly.
Fixes: bcf8b616deb87941 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-3-geert@linux-m68k.org
There is no "reversed" handling in drm_fb_xrgb8888_to_mono_reversed():
the function just converts from color to grayscale, and reduces the
number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
mapped to 0, 128-255 to 1). All "reversed" handling is done in the
repaper driver, where this function originated.
Hence make this clear by renaming drm_fb_xrgb8888_to_mono_reversed() to
drm_fb_xrgb8888_to_mono(), and documenting the black/white pixel
mapping.
Fixes: bcf8b616deb87941 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-2-geert@linux-m68k.org
Jeffrey Hugo [Mon, 7 Mar 2022 15:32:36 +0000 (08:32 -0700)]
drm/doc: Clarify what ioctls can be used on render nodes
The documentation for render nodes indicates that only "PRIME-related"
ioctls are valid on render nodes, but the documentation does not clarify
what that means. If the reader is not familiar with PRIME, they may
beleive this to be only the ioctls with "PRIME" in the name and not other
ioctls such as set of syncobj ioctls. Clarify the situation for the
reader by referencing where the reader will find a current list of valid
ioctls.
Thomas Zimmermann [Tue, 8 Mar 2022 19:52:22 +0000 (20:52 +0100)]
drm/gma500: Move GTT memory-range setup into helper
Move the setup code for GTT/GATT memory ranges into a new helper and
call the function from psb_gtt_init() and psb_gtt_resume(). Removes
code duplication.
Thomas Zimmermann [Tue, 8 Mar 2022 19:52:21 +0000 (20:52 +0100)]
drm/gma500: Move GTT enable and disable code into helpers
Move the code for enabling and disabling the GTT into helpers and call
the functions in psb_gtt_init(), psb_gtt_fini() and psb_gtt_resume().
Removes code duplication.
Thomas Zimmermann [Tue, 8 Mar 2022 19:52:18 +0000 (20:52 +0100)]
drm/gma500: Split GTT init/resume/fini into GTT and GEM functions
The GTT init, fini and resume functions contain both, GTT and GEM,
code. Split each into a separate GTT and a GEM function. The GEM
code is responsible for mmap_mutex and the stolen memory area. The
rest of the functionality is left in GTT functions.
Thomas Zimmermann [Tue, 8 Mar 2022 19:52:17 +0000 (20:52 +0100)]
drm/gma500: Cleanup GTT uninit and error handling
Replace psb_gtt_takedown() with finalizer function that is only called
for unloading the driver. Use roll-back pattern for error handling in
psb_gtt_init() and _resume(). Also fixes a bug where vmap_addr was never
unmapped.
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
projects / users / dwmw2 / linux.git / log