From: Luca Ceresoli
tegra_channel_fmt_align() takes care of the size constraints, alignment and
rounding requirements of the Tegra210 VI peripheral. Tegra20 has different
constraints.
In preparation for adding Tegra20 support, move this function to a new op
in the soc-specific `struct tegra_vi_o
At present, the gpu thread crashes at times when grab_vma() attempts to
acquire a gem object lock when in a deadlock state.
Problems:
I identified the following 4 issues in the current code:
1. Since grab_vma() calls i915_gem_object_trylock(), which consequently
calls ww_mutex_trylock(), to acq
From: Luca Ceresoli
Tegra20 and other Tegra SoCs have a video input (VI) peripheral that can
receive from either MIPI CSI-2 or parallel video (called respectively "CSI"
and "VIP" in the documentation). The kernel currently has a staging driver
for Tegra210 CSI capture. This patch set adds support
From: Luca Ceresoli
Clarify what this function does.
Signed-off-by: Luca Ceresoli
---
drivers/staging/media/tegra-video/vi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/media/tegra-video/vi.c
b/drivers/staging/media/tegra-video/vi.c
index 0fe3c7f6d234..8a7512ce2273
From: Luca Ceresoli
VIP is the parallel video capture component within the video input
subsystem of Tegra20 (and other Tegra chips, apparently).
Signed-off-by: Luca Ceresoli
---
.../display/tegra/nvidia,tegra20-vip.yaml | 64 +++
MAINTAINERS
From: Luca Ceresoli
The .vidioc_enum_fmt_vid_cap (called tegra_channel_enum_format() here)
should return all the supported formats. Instead the current implementation
computes the intersection between the formats it supports and those
supported by the first subdev in the stream (typically the ima
From: Luca Ceresoli
Add "skip" in "so we can *skip* the current channel" or it doesn't make
sense.
Also add articles where appropriate to fix English grammar.
Signed-off-by: Luca Ceresoli
---
drivers/staging/media/tegra-video/vi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
d
From: Luca Ceresoli
In preparation to implement Tegra20 parallel video capture, add variables
to hold the required syncpt.
Signed-off-by: Luca Ceresoli
---
drivers/staging/media/tegra-video/vi.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/t
From: Luca Ceresoli
The Tegra20 VI needs an additional operation to enable the VI, add an
operation for that.
Signed-off-by: Luca Ceresoli
---
drivers/staging/media/tegra-video/vi.c | 7 +++
drivers/staging/media/tegra-video/vi.h | 4
2 files changed, 11 insertions(+)
diff --git a/dr
Hi Chris,
thanks for your patch!
On Fri, Oct 28, 2022 at 10:50 PM Chris Morgan wrote:
> From: Chris Morgan
>
> Support NewVision NV3051D panels as found on the Anbernic RG353P and
> RG353V. The underlying LCD part number for the RG353x devices is
> unknown, so the device name and a fallback fo
Hi Chris,
thanks for your patch! The following is just nitpicks so take it or
leave it.
On Fri, Oct 28, 2022 at 10:50 PM Chris Morgan wrote:
> From: Chris Morgan
>
> Add documentation for the NewVision NV3051D panel bindings.
> Note that for the two expected consumers of this panel binding
> t
Hi,
I have a few comments that are not really something for this patch. I'll
comment it here anyway to have them posted.
Am 06.11.22 um 00:27 schrieb Dmitry Osipenko:
DMA-buf core has its own refcounting of vmaps, use it instead of drm-shmem
counting. This change prepares drm-shmem for additi
Hi
Am 09.11.22 um 10:07 schrieb Chunyou Tang:
Hi,
drm_gem_object_init() will do these before failed:
void drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t
size) {
BUG_ON((size & (PAGE_SIZE - 1)) != 0);
o
Hi Dave, Daniel,
Some more fixes for the release candidate window.
Most important are the SG table handling fix for map_dma_buf import, the
userptr probe fixup after VMA iterator conversion and then a display/mouse
stuttering fix for PSR2. Last one only relates to discrete platforms, so
still beh
Hi,
On Mon, Nov 07, 2022 at 06:49:57PM +0100, Noralf Trønnes wrote:
> Den 07.11.2022 15.16, skrev Maxime Ripard:
> > The framework will get the drm_display_mode from the drm_cmdline_mode it
> > got by parsing the video command line argument by calling
> > drm_connector_pick_cmdline_mode().
> >
>
On 09/11/2022 17:46, John Harrison wrote:
On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wr
The mipi_dsi_device_register_full() returns an ERR_PTR() on failure,
we should use IS_ERR() to check the return value.
Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
panels")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 2 +-
1 fi
The msm_gem_get_vaddr() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 6a8bd08d0465 ("drm/msm: add sudo flag to submit ioctl")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
The of_icc_get() function returns NULL or error pointers on error path,
so we should use IS_ERR_OR_NULL() to check the return value.
Fixes: 5ccdcecaf8f7 ("drm/msm: lookup the ICC paths in both mdp5/dpu and mdss
devices")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/msm/msm_io_utils.c | 2 +-
The drm_atomic_get_new_private_obj_state() function returns NULL
on error path, drm_atomic_get_old_private_obj_state() function
returns NULL on error path, too, they does not return error pointers.
By the way, vc4_hvs_get_new/old_global_state() should return
ERR_PTR(-EINVAL), otherwise there will
This series contains a few fixup patches, to fix IS_ERR() vs NULL check
for drm, and avoid a potential null-ptr-defer issue, too. Thanks!
Gaosheng Cui (5):
drm/panel: Fix IS_ERR() vs NULL check in nt35950_probe()
drm/msm: Fix IS_ERR() vs NULL check in a5xx_submit_in_rb()
drm/msm: Fix IS_ERR_
The komeda_pipeline_get_state() returns an ERR_PTR() on failure, we should
use IS_ERR() to check the return value.
Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE")
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
1 file
This is a straight forward conversion. Note that fsl,imx-lcdc was picked
as the new name as this is the compatible that should supersede the
legacy fb binding.
Signed-off-by: Uwe Kleine-König
---
Hello,
the eventual goal is to add drm support for this hardware. That one will
use a different (and
On 09/11/2022 19:57, Michal Wajdeczko wrote:
[snip]
Is it really a problem to merge this patch now to get the process
started? And other sub-components get updated as and when people get the
time to do them? You could maybe even help rather than posting
completely conflicting patch sets that
Hi,
On 09/11/2022 18:03, Thomas Hellström wrote:
Hi, Andi,
This has been on the list before (three times I think) and at that
point it (the guard pages) was NAK'd by Daniel as yet another
complication, and a VT-d
scanout workaround was implemented and pushed using a different
approach, initia
From: Thierry Reding
On Thu, 20 Oct 2022 15:23:40 +0100, Robin Murphy wrote:
> Since commit c7e3ca515e78 ("iommu/tegra: gart: Do not register with
> bus") quite some time ago, the GART driver has effectively disabled
> itself to avoid issues with the GPU driver expecting it to work in ways
> that
Hi Thomas,
> This has been on the list before (three times I think) and at that
> point it (the guard pages) was NAK'd by Daniel as yet another
> complication, and a VT-d
> scanout workaround was implemented and pushed using a different
> approach, initially outlined by Daniel.
I reckon that this
On Wed, 09 Nov 2022, Michal Wajdeczko wrote:
> Instead of merging this patch now, oriented on GT only, I would rather
> wait until we discuss and plan solution for the all sub-components.
>
> Once that's done (with agreement on naming and output) we can start
> converting exiting messages.
>
> My
On 10.11.2022 10:55, Tvrtko Ursulin wrote:
>
> On 09/11/2022 19:57, Michal Wajdeczko wrote:
>
> [snip]
>
>>> Is it really a problem to merge this patch now to get the process
>>> started? And other sub-components get updated as and when people get the
>>> time to do them? You could maybe even
On Tue, Nov 08, 2022 at 10:40:07AM +0100, Noralf Trønnes wrote:
>
>
> Den 07.11.2022 18.49, skrev Noralf Trønnes:
> >
> >
> > Den 07.11.2022 15.16, skrev Maxime Ripard:
> >> The framework will get the drm_display_mode from the drm_cmdline_mode it
> >> got by parsing the video command line argum
On Wed, Nov 09, 2022 at 05:55:36PM +0100, Lukas Satin wrote:
> That's great, I will test it on Ubuntu + Nouveau x86_64 and Batocera-Linux.
>
> I'm not interested in Raspberry Pi. I see you have some commit in
> RaspberryPi/Linux. Will this go to some Nouveau driver, so I can test it on
> x86_64 ma
Hi!
On Wed, Nov 09, 2022 at 02:15:29AM +0100, Mateusz Kwiatkowski wrote:
> I ran your v7 patchset on my Pi with Xorg, and the mode switching, as well as
> the preferred mode handling, all work really well now!
Thanks again for all your help
> I just noted that the downstream version of the vc4 d
Hi,
Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.
The named modes support were initially introduced to allow to specify the
analog TV mode to be used.
However, this was causing multiple issues:
* The
As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.
Let's add a file meant to provide those kind of helpers to avoid
duplication.
Reviewed-by: No
The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.
Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usual
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Acked-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-
The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.
Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away
drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.
However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that fu
The drm_create_tv_properties() will create the TV mode property
unconditionally.
However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.
Acked-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-
The current named mode parsing relies only on the mode name, and doesn't
allow to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwi
The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.
The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Renamed the tests to follow DRM test namin
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v7:
- Add
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Reviewed-by: Noralf Trønnes
Tested-by: M
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.
Let's add some code to allow it, and some unit tests to exercise that code.
Reviewed-by:
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
drivers/gpu
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
Tes
Commit 3aeeb13d8996 ("drm/modes: Support modes names on the command
line") initially introduced the named modes support by essentially
matching the name passed on the command-line to the mode names defined
by the drivers.
This proved to be difficult to work with, since all drivers had to
provide p
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by: Mate
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-
On 09.11.2022 11:46, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
v2:
* Don't have struct drm_device as local. (Jani, Ville)
v3:
* Store gt, not i915, in workaround list. (
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV atomic_check
From: Noralf Trønnes
Most of the TV connectors will need a similar get_modes implementation
that will, depending on the drivers' capabilities, register the 480i and
576i modes.
That implementation will also need to set the preferred flag and order
the modes based on the driver and users preferre
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Convert to new get_modes helper
Changes in v5:
- Removed the count var
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
broadcas
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though, the
On Fri, 4 Nov 2022 at 14:32, Maxime Ripard wrote:
>
> The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent
> hook, but doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent of a clock. How
On Thu, Nov 10, 2022 at 12:29 PM Ulf Hansson wrote:
> On Fri, 4 Nov 2022 at 14:32, Maxime Ripard wrote:
> >
> > The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent
> > hook, but doesn't provide a determine_rate implementation.
> >
> > This is a bit odd, since set_parent() is t
On 10/11/2022 11:07, Andrzej Hajda wrote:
On 09.11.2022 11:46, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert some usages of legacy DRM logging macros into versions which tell
us on which device have the events occurred.
v2:
* Don't have struct drm_device as local. (Jani, Ville)
v3:
On Thu, 10 Nov 2022 17:44:45 +0800, Gaosheng Cui wrote:
> The drm_atomic_get_new_private_obj_state() function returns NULL
> on error path, drm_atomic_get_old_private_obj_state() function
> returns NULL on error path, too, they does not return error pointers.
>
> By the way, vc4_hvs_get_new/old_gl
From: Tvrtko Ursulin
Since we are now storing the GT backpointer in the wa list we can drop the
explicit struct intel_gt * argument to wa_list_apply.
Signed-off-by: Tvrtko Ursulin
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
1 file changed, 5 insertions(+
Return value of a function 'amdgpu_ras_find_obj' is dereferenced at
nbio_v7_4.c:325 without checking for null
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Arefev
---
drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 3 +++
1 file changed, 3 insertions(+)
diff
On Thu, 10 Nov 2022 at 12:39, Linus Walleij wrote:
>
> On Thu, Nov 10, 2022 at 12:29 PM Ulf Hansson wrote:
> > On Fri, 4 Nov 2022 at 14:32, Maxime Ripard wrote:
> > >
> > > The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent
> > > hook, but doesn't provide a determine_rate im
Check the availability of the audio capability and mode config before
going to the loop for avoiding the access to an unusable state. Also,
change the loop iterations over encoder instead of connector in order
to align with radeon_audio_enable().
Link: https://gitlab.freedesktop.org/drm/amd/-/iss
On 09/11/2022 06:10, Jason-JH Lin (林睿祥) wrote:
On Tue, 2022-11-08 at 18:46 +0100, Matthias Brugger wrote:
On 07/11/2022 08:22, Nancy.Lin wrote:
> Add vdosys1 mmsys compatible for MT8195 platform.
>
> For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding
> to
> 2 different powe
On 08/11/2022 20:43, Nícolas F. R. A. Prado wrote:
On Tue, Nov 08, 2022 at 06:37:19PM +0100, Matthias Brugger wrote:
On 07/11/2022 08:22, Nancy.Lin wrote:
Simplify code for update mmsys reg.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by
On 07.11.2022 16:30, Lucas De Marchi wrote:
> There were several updates in the driver on how the workarounds are
> handled since its documentation was written. Update the documentation to
> reflect the current reality.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_wor
On 11/8/22 16:54, Maíra Canal wrote:
This series introduces some changes to assure the correct resource release on
the V3D driver, especially the mutex. Currently, the V3D has no mutex_destroy()
calls, which means that a mutex is being instantiated, but it is not being
released by the end of it
Matthias Brugger 於 2022年11月9日 週三 晚上7:25寫道：
>
>
>
> On 27/09/2022 17:27, Jason-JH.Lin wrote:
> > After mmsys and drm change DITHER enum to DDP_COMPONENT_DITHER0,
> > mmsys header can remove the useless DDP_COMPONENT_DITHER enum.
> >
> > Signed-off-by: Jason-JH.Lin
> > Reviewed-by: AngeloGioacchino
v1 -> v2:
As suggested by Maxime, I simplified a bit vc4_hdmi_supports_scrambling()
making it receive a struct vc4_hdmi as argument instead of a struct
drm_encoder.
Also, variables are initialized close to where they are used in the
second patch.
José Expósito (2):
drm/vc4: hdmi: Pass vc4_hdmi
Commit 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") introduced
the vc4_hdmi_reset_link() function. This function dereferences the
"connector" pointer before checking whether it is NULL or not.
Rework variable assignment to avoid this issue.
Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link
Simplify vc4_hdmi_supports_scrambling() by changing its first parameter
from struct drm_encoder to struct vc4_hdmi.
Signed-off-by: José Expósito
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers
Move the dirty-fb update from the damage-worker callback into the
new helper drm_fb_helper_fb_dirty(), so that it can run outside the
damage worker. This change will help to remove the damage worker
entirely. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_help
The fbdev emulation runs a separate worker that collects all changes
to the framebuffer and runs DRM damage handling. But this can also be
performed by the worker of fbdev's deferred-I/O code. Move damage
handling there, remove the damage worker and reduce the latency.
I ran a simple benchmark wit
Call fb_dirty directly from drm_fb_helper_deferred_io() to avoid the
latency of running the damage worker.
The deferred-I/O helper drm_fb_helper_deferred_io() runs in a worker
thread at regular intervals as part of writing to mmaped framebuffer
memory. It used to schedule the fbdev damage worker t
The fbdev damage worker is unused, so remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 9 -
include/drm/drm_fb_helper.h | 2 --
2 files changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8cb6
Set the damage area in the new helper drm_fb_helper_add_damage_clip().
It can now be updated without scheduling the damage worker. This change
will help to remove the damage worker entirely. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 10
Schedule the deferred-I/O worker instead of the damage worker after
writing to the fbdev framebuffer. The deferred-I/O worker then performs
the dirty-fb update. The fbdev emulation will initialize deferred I/O
for all drivers that require damage updates. It is therefore a valid
assumption that the
On Thu, Nov 10, 2022 at 02:55:18PM +0100, Thomas Zimmermann wrote:
> Schedule the deferred-I/O worker instead of the damage worker after
> writing to the fbdev framebuffer. The deferred-I/O worker then performs
> the dirty-fb update. The fbdev emulation will initialize deferred I/O
> for all driver
When p->gang_size equals 0, amdgpu_cs_pass1() will return directly
without freeing chunk_array, which will cause a memory leak issue,
this patch fixes it.
Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6")
Signed-off-by: Dong Chenchen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +
Tvrtko Ursulin writes:
> From: Tvrtko Ursulin
>
> Since we are now storing the GT backpointer in the wa list we can drop the
> explicit struct intel_gt * argument to wa_list_apply.
There is room for more dropping, all the platform lists inits.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andrzej Ha
https://bugzilla.kernel.org/show_bug.cgi?id=216673
Michele Della Guardia (micheledellaguar...@yahoo.it) changed:
What|Removed |Added
CC||mic
On 10/11/2022 05:49, Niranjana Vishwanathapura wrote:
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM
buffer objects (BOs) or sections of a BOs
On 10/11/2022 05:31, Mani Milani wrote:
At present, the gpu thread crashes at times when grab_vma() attempts to
acquire a gem object lock when in a deadlock state.
Problems:
I identified the following 4 issues in the current code:
1. Since grab_vma() calls i915_gem_object_trylock(), which conseq
On 10/11/2022 14:47, Tvrtko Ursulin wrote:
On 10/11/2022 05:49, Niranjana Vishwanathapura wrote:
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GE
On Thu, 2022-11-10 at 14:49 +, Matthew Auld wrote:
> On 10/11/2022 05:31, Mani Milani wrote:
> > At present, the gpu thread crashes at times when grab_vma()
> > attempts to
> > acquire a gem object lock when in a deadlock state.
> >
> > Problems:
> > I identified the following 4 issues in the
On Mon, Nov 7, 2022 at 2:26 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Initialize on-stack modes with drm_mode_init() to guarantee
> no stack garbage in the list head, or that we aren't copying
> over another mode's list head.
>
> Based on the following cocci script, with manual fixups:
Applied. Thanks!
On Wed, Nov 9, 2022 at 8:51 AM Liu Jian wrote:
>
> Fix below sparse warning:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_optc.c:244:18:
> warning: Initializer entry defined twice
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_optc.c:257:18: also
> defi
Hi,
On Thu, Nov 10, 2022 at 5:13 AM Francesco Dolcini wrote:
>
> On Mon, Oct 17, 2022 at 04:18:13PM +0200, Francesco Dolcini wrote:
> > On Wed, Aug 31, 2022 at 04:16:22PM +0200, Francesco Dolcini wrote:
> > > From: Aishwarya Kothari
> > >
> > > In case bpc is not set for a panel it then throws a
On Mon 2022-11-07 15:22:31, John Ogness wrote:
> With commit 9e124fe16ff2("xen: Enable console tty by default in domU
> if it's not a dummy") a hack was implemented to make sure that the
> tty console remains the console behind the /dev/console device. The
> main problem with the hack is that, afte
Hi Sandor,
Am Mittwoch, 9. November 2022, 14:26:14 CET schrieb Sandor Yu:
> Thanks for your comments.
>
>
> > -Original Message-
> > From: Alexander Stein
> > Sent: 2022年11月8日 21:17
> > To: jo...@kwiboo.se; Sandor Yu
> > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org;
On Thu, Nov 10, 2022 at 8:09 AM Takashi Iwai wrote:
>
> Check the availability of the audio capability and mode config before
> going to the loop for avoiding the access to an unusable state. Also,
> change the loop iterations over encoder instead of connector in order
> to align with radeon_audi
Hi,
On Mon, Nov 7, 2022 at 1:34 PM Frieder Schrempf
wrote:
> I tested this on the Kontron DL i.MX8MM which uses a TI SN65DSI84 bridge
> and a Jenson 7" LVDS Display.
>
> Thanks for your work, Jagan!
>
> Tested-by: Frieder Schrempf # Kontron DL
> i.MX8MM
As this series has been successfully tes
On Wed, Nov 9, 2022 at 2:33 AM Paulo Miguel Almeida
wrote:
>
> One-element arrays are deprecated, and we are replacing them with
> flexible array members instead. So, replace one-element array with
> flexible-array member in structs _ATOM_CONNECTOR_DEVICE_TAG_RECORD,
> _ATOM_OBJECT_GPIO_CNTL_RECOR
On Thu, Nov 10, 2022 at 10:57 AM Alex Deucher wrote:
>
> On Wed, Nov 9, 2022 at 2:33 AM Paulo Miguel Almeida
> wrote:
> >
> > One-element arrays are deprecated, and we are replacing them with
> > flexible array members instead. So, replace one-element array with
> > flexible-array member in struc
On 2022-11-10, Petr Mladek wrote:
>> +void console_force_preferred_locked(struct console *con)
>> +{
>> +struct console *cur_pref_con;
>> +
>> +if (!console_is_registered_locked(con))
>> +return;
>> +
>> +cur_pref_con = console_first();
>> +
>> +/* Already preferred? */
On Thu, Nov 10, 2022 at 9:24 PM Fabio Estevam wrote:
>
> Hi,
>
> On Mon, Nov 7, 2022 at 1:34 PM Frieder Schrempf
> wrote:
>
> > I tested this on the Kontron DL i.MX8MM which uses a TI SN65DSI84 bridge
> > and a Jenson 7" LVDS Display.
> >
> > Thanks for your work, Jagan!
> >
> > Tested-by: Friede
Add support for AR30 and BA30 pixel formats to the Mediatek DRM driver.
Tested using "modetest -P" on an MT8195.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 29 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +++-
drivers/gpu/drm/mediatek
101 - 200 of 229 matches
Mail list logo
