Thomas Zimmermann [Wed, 1 Dec 2021 11:46:41 +0000 (12:46 +0100)]
agp: Documentation fixes
Fix compiler warnings
drivers/char/agp/backend.c:68: warning: Function parameter or member 'pdev' not described in 'agp_backend_acquire'
drivers/char/agp/backend.c:93: warning: Function parameter or member 'bridge' not described in 'agp_backend_release'
Yannick Fertre [Wed, 15 Dec 2021 21:48:35 +0000 (22:48 +0100)]
drm/stm: ltdc: add support of flexible pixel formats
This feature allows the generation of any RGB pixel format.
The list of supported formats is no longer linked to the
register LXPFCR_PF, that the reason why a list of drm formats is
defined for each display controller version.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Reviewed-by: Philippe Cornu <philippe.cornu@foss.st.com> Reviewed-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Tested-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215214835.20593-1-yannick.fertre@foss.st.com
Yannick Fertre [Wed, 15 Dec 2021 21:48:17 +0000 (22:48 +0100)]
drm/stm: ltdc: add per plane update support
Recent ltdc hardware versions offer the ability
to update a plane independently of others planes.
This is could be useful especially if a plane is
assigned to another OS.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Reviewed-by: Philippe Cornu <philippe.cornu@foss.st.com> Reviewed-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215214817.20310-1-yannick.fertre@foss.st.com
Yannick Fertre [Wed, 15 Dec 2021 21:47:50 +0000 (22:47 +0100)]
drm/stm: ltdc: add YCbCr 422 output support
LTDC 40100 hw version supports the YCbCr 422 output,
reducing the output pins from 24 to 16. This feature
is useful for some external devices like HDMI bridges.
Both ITU-R BT.601 & ITU-R BT.709 are supported.
It is also possible to choose the chrominance order between
* Cb is output first (Y0Cb, then Y1Cr, Y2Cb and so on).
* Cr is output first (Y0Cr, then Y1Cb, Y2Cr and so on).
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Reviewed-by: Philippe Cornu <philippe.cornu@foss.st.com> Reviewed-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215214750.20105-1-yannick.fertre@foss.st.com
Alyssa Rosenzweig [Sun, 9 Jan 2022 17:09:19 +0000 (12:09 -0500)]
drm/panfrost: Merge some feature lists
Now that we only list features of interest to kernel space, lots of GPUs
have the same feature bits. To cut down on the repetition in the file,
merge feature lists that are identical between similar GPUs.
Note that this leaves some unmerged identical Bifrost feature lists, as
there are more features affecting Bifrost kernel space that we do not
yet handle.
Alyssa Rosenzweig [Sun, 9 Jan 2022 17:09:18 +0000 (12:09 -0500)]
drm/panfrost: Remove features meant for userspace
Early versions of the legacy kernel driver included comprehensive
feature lists for every GPU, even though most of the enumerated features
only matter to userspace. For example, HW_FEATURE_INTERPIPE_REG_ALIASING
was a feature bit indicating that a GPU had "interpipe register
aliasing": arithmetic, load/store, and texture instruction all use
common general-purpose registers. GPUs without this feature bit have
dedicated load/store and texture "registers". Whether a GPU has this
feature or not is irrelevant to the kernel; it only matters in the
userspace compiler's register allocator. It's silly to enumerate it in
kernel space, and the information is understandably unused. To
underscore the point, this feature only makes sense in the context of
the Midgard instruction set. Bifrost never had dedicated load/store or
texture registers, so the feature bit was vacuously set for all Bifrost
hardware, even though this conveys no useful information.
To clean up the feature list, delete feature bits which could not
possibly matter to the kernel, leaving only those which do affect the
register-level operation of the chip.
Jiasheng Jiang [Thu, 6 Jan 2022 03:03:26 +0000 (11:03 +0800)]
drm/panfrost: Check for error num after setting mask
Because of the possible failure of the dma_supported(), the
dma_set_mask_and_coherent() may return error num.
Therefore, it should be better to check it and return the error if
fails.
Javier Martinez Canillas [Mon, 10 Jan 2022 09:56:24 +0000 (10:56 +0100)]
video: vga16fb: Fix logic that checks for the display standard
The vga16fb framebuffer driver supports both Enhanced Graphics Adapter
(EGA) and Video Graphics Array (VGA) 16 color graphic cards.
But the logic to check whether the EGA or VGA standard are used is not
correct. It just checks if screen_info.orig_video_isVGA is set, but it
should check if is set to VIDEO_TYPE_VGAC instead.
This means that it assumes to be VGA even if is set to VIDEO_TYPE_EGAC.
All non-x86 architectures though treat orig_video_isVGA as a boolean so
only do the change for x86 and keep the old logic for the other arches.
Jiasheng Jiang [Mon, 10 Jan 2022 01:38:07 +0000 (09:38 +0800)]
drm/v3d/v3d_drv: Check for error num after setting mask
Because of the possible failure of the dma_supported(), the
dma_set_mask_and_coherent() may return error num.
Therefore, it should be better to check it and return the error if
fails.
Also, we can create a variable for the mask to solve the
alignment issue.
Maxime Ripard [Wed, 15 Dec 2021 09:51:17 +0000 (10:51 +0100)]
drm/vc4: Notify the firmware when DRM is in charge
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has
been made, simplefb has been unregistered and the KMS driver is entirely
in charge of the display.
Thus, we can notify the firmware it can free whatever resource it was
using to maintain simplefb functional.
Maxime Ripard [Wed, 15 Dec 2021 09:51:16 +0000 (10:51 +0100)]
drm/vc4: Remove conflicting framebuffers before callind bind_all
The bind hooks will modify their controller registers, so simplefb is
going to be unusable anyway. Let's avoid any transient state where it
could still be in the system but no longer functionnal.
Maxime Ripard [Wed, 15 Dec 2021 09:51:15 +0000 (10:51 +0100)]
drm/vc4: Support nomodeset
If we have nomodeset on the kernel command line we should have the
firmware framebuffer driver kept as is and not try to load the
full-blown KMS driver.
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the
firmware the kernel is in charge of the display now and the firmware can
free whatever resources it was using.
Rajat Jain [Fri, 7 Jan 2022 19:02:08 +0000 (11:02 -0800)]
drm/privacy_screen_x86: Add entry for ChromeOS privacy-screen
Add a static entry in the x86 table, to detect and wait for
privacy-screen on some ChromeOS platforms.
Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
shall return EPROBE_DEFER until a platform driver actually registers the
privacy-screen: https://hansdegoede.livejournal.com/25948.html
Rajat Jain [Fri, 7 Jan 2022 19:02:07 +0000 (11:02 -0800)]
platform/chrome: Add driver for ChromeOS privacy-screen
This adds the ACPI driver for the ChromeOS privacy screen that is
present on some chromeos devices.
Note that ideally, we'd want this privacy screen driver to be probed
BEFORE the drm probe in order to avoid a drm probe deferral:
https://hansdegoede.livejournal.com/25948.html
In practise, I found that ACPI drivers are bound to their devices AFTER
the drm probe on chromebooks. So on chromebooks with privacy-screen,
this patch along with the other one in this series results in a probe
deferral of about 250ms for i915 driver. However, it did not result in
any user noticeable delay of splash screen in my personal experience.
In future if this probe deferral turns out to be an issue, we can
consider turning this ACPI driver into something that is probed
earlier than the drm drivers.
Rajat Jain [Fri, 7 Jan 2022 19:02:06 +0000 (11:02 -0800)]
drm/privacy_screen: Add drvdata in drm_privacy_screen
Allow a privacy screen provider to stash its private data pointer in the
drm_privacy_screen, and update the drm_privacy_screen_register() call to
accept that. Also introduce a *_get_drvdata() so that it can retrieved
back when needed.
This also touches the IBM Thinkpad platform driver, the only user of
privacy screen today, to pass NULL for now to the updated API.
Ivaylo Dimitrov [Wed, 5 Jan 2022 15:36:58 +0000 (17:36 +0200)]
drm: omapdrm: Fix implicit dma_buf fencing
Currently omapdrm driver does not initialize dma_buf_export_info resv
member, which leads to a new dma_resv being allocated and attached to
the exported dma_buf. This leads to the issue that fences created on
dma_buf objects imported by other drivers are ignored by omapdrm, as only
fences in gem object resv are waited on. This leads to various issues like
displaying incomplete frames.
Fix that by initializing dma_buf resv to the resv of the gem object being
exported.
yangcong [Fri, 31 Dec 2021 04:50:56 +0000 (12:50 +0800)]
drm/panel: Update Boe-tv110c9m initial code
Optimize two problems
a)Turn off low voltage detection register.During the esd test,
the low-voltage detection ic may be triggered to enter the slpin state,
so a black screen occurs on the panel.
b)Optimize CMD2 page1 gamma.
José Expósito [Sun, 26 Dec 2021 11:24:58 +0000 (12:24 +0100)]
drm/plane: Make format_mod_supported truly optional
The documentation for "drm_plane_funcs.format_mod_supported" reads:
This *optional* hook is used for the DRM to determine if the given
format/modifier combination is valid for the plane. This allows the
DRM to generate the correct format bitmask (which formats apply to
which modifier), and to validate modifiers at atomic_check time.
*If not present*, then any modifier in the plane's modifier
list is allowed with any of the plane's formats.
However, where the function is not present, an invalid IN_FORMATS blob
property with modifiers but no formats is exposed to user-space.
This breaks the latest Weston [1]. For testing purposes, I extracted the
affected code to a standalone program [2].
Make "create_in_format_blob" behave as documented.
Miaoqian Lin [Wed, 5 Jan 2022 10:48:26 +0000 (10:48 +0000)]
drm/bridge: nwl-dsi: Fix PM disable depth imbalance in nwl_dsi_probe
The pm_runtime_enable will increase power disable depth.
Thus a pairing decrement is needed on the error handling
path to keep it balanced according to context.
AngeloGioacchino Del Regno [Wed, 5 Jan 2022 09:08:02 +0000 (10:08 +0100)]
drm/bridge: parade-ps8640: Link device to ensure suspend/resume order
Entering suspend while the display attached to this bridge is still on
makes the resume sequence to resume the bridge first, display last:
when this happens, we get a timeout while resuming the bridge, as its
MCU will get stuck due to the display being unpowered.
On the other hand, on mt8173-elm, closing the lid makes the display to
get powered off first, bridge last, so at resume time the sequence is
swapped (compared to the first example) and everything just works
as expected.
Add a stateless device link to the DRM device that this bridge belongs
to, ensuring a correct resume sequence and solving the unability to
correctly resume bridge operation in the first mentioned example.
Miaoqian Lin [Wed, 22 Dec 2021 08:33:48 +0000 (08:33 +0000)]
drm/bridge: anx7625: Fix null vs IS_ERR() checking in anx7625_register_i2c_dummy_clients
Since i2c_new_client_device() function return error pointers.
The i2c_new_dummy_device() function does not return NULL, It returns error
pointers too. Using IS_ERR() to check the return value to fix this.
Miaoqian Lin [Mon, 27 Dec 2021 09:25:22 +0000 (09:25 +0000)]
drm/bridge: Fix free wrong object in sii8620_init_rcp_input_dev
rc_dev is allocated by rc_allocate_device(), and doesn't assigned to
ctx->rc_dev before calling rc_free_device(ctx->rc_dev).
So it should call rc_free_device(rc_dev);
Antonio Borneo [Sat, 18 Dec 2021 21:50:54 +0000 (22:50 +0100)]
drm/stm: dsi: provide the implementation of mode_valid()
The dsi has several constraints on the video modes it can support,
mainly due to the frequencies that can be generated by the PLL
integrated in the DSI device.
Verify that the required HS clock can be generated by the PLL.
The dsi clock from the dsi PLL and the ltdc pixel clock are
asynchronous. The dsi needs to return in LP mode during HFP or HBP
to re-synchronize at each video line.
Verify that the duration of HFP and HBP allows the dsi to enter in
LP mode.
Antonio Borneo [Sat, 18 Dec 2021 21:50:52 +0000 (22:50 +0100)]
drm/stm: dsi: move lane capability detection in probe()
There is no need to re-compute the dsi lane capability because it
only depends on dsi hw version.
Since dsi hw version is detected at probe(), move there also the
assignment of dsi lane capability.
Martin Blumenstingl [Thu, 30 Dec 2021 23:55:15 +0000 (00:55 +0100)]
drm/meson: Fix error handling when afbcd.ops->init fails
When afbcd.ops->init fails we need to free the struct drm_device. Also
all errors which come after afbcd.ops->init was successful need to exit
the AFBCD, just like meson_drv_unbind() does.
Christophe JAILLET [Wed, 29 Dec 2021 08:58:44 +0000 (09:58 +0100)]
drm/bridge: sn65dsi83: Fix an error handling path in sn65dsi83_probe()
sn65dsi83_parse_dt() takes a reference on 'ctx->host_node' that must be
released in the error handling path of this function and of the probe.
This is only done in the remove function up to now.
Alexander Stein [Mon, 13 Dec 2021 13:36:24 +0000 (14:36 +0100)]
drm/bridge: ti-sn65dsi83: Make enable GPIO optional
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Claudio Suarez [Thu, 2 Dec 2021 09:51:12 +0000 (10:51 +0100)]
drm: fix error found in some cases after the patch d1af5cd86997
The patch d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log
calls in drm core, files drm_a*.c") fails when the drm_device
cannot be found in the parameter plane_state->crtc.
Fix it using plane_state->plane.
Reported-by: kernel test robot <oliver.sang@intel.com> Fixes: 6e22dc358377 ("drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c") Signed-off-by: Claudio Suarez <cssk@net-c.es>
[danvet: fix Fixes: line] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/YaiXEARd8z2C463h@gineta.localdomain
Claudio Suarez [Thu, 2 Dec 2021 09:49:49 +0000 (10:49 +0100)]
mock a drm_plane in igt_check_plane_state to make the test more robust
igt_check_plane_state test crashes in drm_atomic_helper_check_plane_state
when trying to de-reference drm_plane_state->plane->dev
due to the lack of a struct drm_plane in the mock struct drm_plane_state.
Since drm_plane_state always should contain a plane, the mock also
needs a plane to be the test more robust and realistic. Add it.
Ben Skeggs [Tue, 23 Nov 2021 08:18:00 +0000 (18:18 +1000)]
drm/nouveau/disp/dp: add support for lttprs
Add support for Link-Training Tunable PHY Repeaters, required to support
higher bit rates on longer cables, as well as USB-C on certain docks and
laptops.
Zack Rusin [Wed, 15 Dec 2021 20:02:24 +0000 (15:02 -0500)]
drm/vmwgfx: Fix possible usage of an uninitialized variable
vmw_user_bo_lookup can fail to lookup user buffers, especially because
the buffer handles come from the userspace. The return value has
to be checked before the buffers are put back.
This was spotted by Dan's Smatch statick checker:
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release()
error: uninitialized symbol 'vmw_bo'.
Zack Rusin [Wed, 15 Dec 2021 18:41:47 +0000 (13:41 -0500)]
drm/vmwgfx: Remove unused compile options
Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since the implementation of screen targets landed there hasn't been a
reason to explicitly disable it and the options were never used.
Remove of all that unused code.
Zack Rusin [Wed, 15 Dec 2021 18:41:46 +0000 (13:41 -0500)]
drm/vmwgfx: Remove explicit transparent hugepages support
Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only very
old devices (OpenGL 2.1 support and earlier) used this code and at this
point performance differences are negligible.
Because the code requires very old hardware versions to run it has
been largely untested and unused for a long time.
Furthermore removal of the ttm hugepages support in:
commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
broke the coherency mode in vmwgfx when running with hugepages.
Fixes: 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()") Signed-off-by: Zack Rusin <zackr@vmware.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org
Zack Rusin [Wed, 15 Dec 2021 18:41:45 +0000 (13:41 -0500)]
drm/vmwgfx: Fix a size_t/long int format specifier mismatch
On i386 size_t is of course 32bits and using long int throws warnings,
trivially fix it by using the dedicated size_t format.
This is enough to fix the following warning found by the kernel test
robot:
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c: In function 'vmw_bo_print_info':
>> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c:230:33: warning: format '%ld'
expects argument of type 'long int', but argument 4 has type 'size_t'
{aka 'unsigned int'} [-Wformat=]
230 | seq_printf(m, "\t\t0x%08x: %12ld bytes %s, type = %s",
| ~~~~^
| |
| long int
| %12d
231 | id, bo->base.base.size, placement, type);
| ~~~~~~~~~~~~~~~~~~
| |
Paul Boddie [Thu, 2 Dec 2021 18:39:47 +0000 (19:39 +0100)]
drm/ingenic: Add support for JZ4780 and HDMI output
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Stephen Boyd [Wed, 15 Dec 2021 00:25:29 +0000 (16:25 -0800)]
drm/bridge: ti-sn65dsi86: Set max register for regmap
Set the maximum register to 0xff so we can dump the registers for this
device in debugfs.
Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver") Cc: Rob Clark <robdclark@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211215002529.382383-1-swboyd@chromium.org
projects / users / jedix / linux-maple.git / log