Hi Animesh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Animesh-Manna/drm-panelreplay-dpcd-register-definition-for-panelreplay/20230905-154811
base: git://anongit.freedesktop.org
Hi, Maxime
On 9/5/23 15:16, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 02:32:38PM +0200, Thomas Hellström wrote:
Hi,
On 9/5/23 14:05, Maxime Ripard wrote:
Hi,
On Tue, Sep 05, 2023 at 10:58:31AM +0200, Thomas Hellström wrote:
Check that object freeing from within drm_exec_fini() works as
Color caps changed between HW versions which caused DCN10 color state
sections on DTN log no longer fit DCN3.0 versions. Create a
DCN3.0-specific color state logging and hook it to drivers of DCN3.0
family.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 5 +-
Add color caps information for DPP and MPC block to show HW color caps.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 23 +++
.../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 23 +++
2 files changed, 46 insertions(+)
diff --git
Hi,
I'm updating the color state part of DTN log to match DCN3.0 HW better.
Currently, the DTN log considers the DCN10 color pipeline, which is
useless for DCN3.0 because of all the differences in color caps between
DCN versions. In addition to new color blocks and caps, some semantic
differences
Prepare to hook color state logging according to DCN version.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 27 +--
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
DCN3 DPP color state was uncollected and some state elements from DCN1
doesn't fit DCN3. Create new elements according to DCN3 color caps and
fill them up for DTN log output.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 28 +--
Logging DCN3 MPC state was following DCN1 implementation that doesn't
consider new DCN3 MPC color blocks. Create new elements according to
DCN3 MPC color caps and a new DCN3-specific function for reading MPC
data.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 55
On 8/29/23 19:37, Danilo Krummrich wrote:
On 8/11/23 04:31, Matthew Brost wrote:
DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
scheduler and entity. No priorities or run queue used in this mode.
Intended for devices with firmware schedulers.
v2:
- Drop sched / rq
On Tue, 5 Sept 2023 at 14:00, Maxime Ripard wrote:
>
> On Tue, Sep 05, 2023 at 03:39:33PM +0530, Vignesh Raman wrote:
> > Hi Dmitry, Maxime,
> >
> > On 05/09/23 14:13, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Mon, Sep 04, 2023 at 07:59:26PM +0300, Dmitry Baryshkov wrote:
> > > > On Mon, 4
Hi all,
Sorry for the late update of the v4 patches on Qemu side:
https://lore.kernel.org/qemu-devel/20230720120816.8751-1-jiqian.c...@amd.com/ .
And I have created an "issue" in the Qemu gitlab for tracing this problem:
https://gitlab.com/qemu-project/qemu/-/issues/1860.
Do you have any other
On Tue, Sep 05, 2023 at 02:32:38PM +0200, Thomas Hellström wrote:
> Hi,
>
> On 9/5/23 14:05, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, Sep 05, 2023 at 10:58:31AM +0200, Thomas Hellström wrote:
> > > Check that object freeing from within drm_exec_fini() works as expected
> > > and doesn't
Am 05.09.23 um 12:38 schrieb Jani Nikula:
On Tue, 05 Sep 2023, Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary()
On 09/05, Melissa Wen wrote:
> Hi,
>
> I'm updating the color state part of DTN log to match DCN3.0 HW better.
> Currently, the DTN log considers the DCN10 color pipeline, which is
> useless for DCN3.0 because of all the differences in color caps between
> DCN versions. In addition to new color
On Mon, 4 Sep 2023 14:29:56 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Sebastian Wick
> > Sent: Thursday, August 31, 2023 2:46 AM
> > To: Shankar, Uma
> > Cc: Harry Wentland ; intel-
> > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; wayland-
> >
On Mon, 4 Sep 2023 13:44:49 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Wednesday, August 30, 2023 5:59 PM
> > To: Shankar, Uma
> > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> > ;
On Mon, 4 Sep 2023 14:10:05 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Wednesday, August 30, 2023 6:30 PM
> > To: Shankar, Uma
> > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> > ;
Hi
Am 05.09.23 um 04:47 schrieb Michael Ellerman:
Thomas Zimmermann writes:
Refactor fb_pgprotect() in PowerPC to work without struct file. Then
clean up and rename fb_pgprotect(). This change has been discussed at
[1] in the context of refactoring fbdev's mmap code.
The first three patches
On Fri, 18 Aug 2023 20:18:15 +0100, Biju Das wrote:
> This patch series aims to add match data improvements for it66121 driver.
>
> v2->v3:
> * Removed fixes tag from patch#1 as nothing broken.
> * Added Rb tag from Andy.
> v1->v2:
> * Split the patch into two.
> * patch#1 extend match
On Fri, 1 Sep 2023 15:01:23 +0530, Jai Luthra wrote:
> Fix the NULL pointer dereference when no monitor is connected, and the
> sound card is opened from userspace.
>
> Instead return an empty buffer (of zeroes) as the EDID information to
> the sound framework if there is no connector attached.
>
On Tue, 05 Sep 2023, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> On a machine with multiple GPUs, a Linux user has no control over which
> one is primary at boot time. This series tries to solve above mentioned
> problem by introduced the ->be_primary() function stub. The specific
> device
On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote:
> On Mon, 4 Sep 2023 14:29:56 +
> "Shankar, Uma" wrote:
>
> > > -Original Message-
> > > From: Sebastian Wick
> > > Sent: Thursday, August 31, 2023 2:46 AM
> > > To: Shankar, Uma
> > > Cc: Harry Wentland ; intel-
> > >
Hi,
On 9/5/23 14:05, Maxime Ripard wrote:
Hi,
On Tue, Sep 05, 2023 at 10:58:31AM +0200, Thomas Hellström wrote:
Check that object freeing from within drm_exec_fini() works as expected
and doesn't generate any warnings.
Cc: Christian König
Cc: dri-devel@lists.freedesktop.org
Signed-off-by:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
If anything, the primary
Hi, Christian
On 9/5/23 15:14, Christian König wrote:
Am 05.09.23 um 10:58 schrieb Thomas Hellström:
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that class as locked. Also the lock allocation
tracking code will apparently register only the
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> On a machine with multiple GPUs, a Linux user has no control over which
> one is primary at boot time. This series tries to solve above mentioned
> problem by introduced the ->be_primary() function stub. The
On 9/5/23 10:58, Thomas Hellström wrote:
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that class as locked. Also the lock allocation
tracking code will apparently register only the address of the first
mutex locked in a sequence.
This has the odd
On Tue, Sep 05, 2023 at 03:39:33PM +0530, Vignesh Raman wrote:
> Hi Dmitry, Maxime,
>
> On 05/09/23 14:13, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Sep 04, 2023 at 07:59:26PM +0300, Dmitry Baryshkov wrote:
> > > On Mon, 4 Sept 2023 at 19:16, Vignesh Raman
> > > wrote:
> > > >
> > > >
On Tue, Sep 05, 2023 at 02:33:04PM +0200, Sebastian Wick wrote:
> On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote:
> > On Mon, 4 Sep 2023 14:29:56 +
> > "Shankar, Uma" wrote:
> >
> > > > -Original Message-
> > > > From: Sebastian Wick
> > > > Sent: Thursday, August
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
If anything, the primary graphics adapter is the one initialized by the
firmware.
On Tue, Sep 05, 2023 at 05:11:43PM +0530, Vignesh Raman wrote:
> > > Also, that node actually has a label ("usb"), defined here:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/msm8916.dtsi#n2322
> > >
> > > So you can end up with
> > >
> >
https://bugzilla.kernel.org/show_bug.cgi?id=217872
Bug ID: 217872
Summary: RIP: 0010:amdgpu_vm_pde_update [amdgpu]
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: high
Hi,
On 2023/9/5 21:28, Christian König wrote:
2) Typically, those non-86 machines don't have a good UEFI firmware
support, which doesn't support select primary GPU as firmware
stage.
Even on x86, there are old UEFI firmwares which already made
undesired
decision for you.
3)
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve
Hi,
On 2023/9/5 22:52, Alex Williamson wrote:
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the ->be_primary() function stub. The specific
device drivers
Hi Animesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Animesh-Manna/drm-panelreplay-dpcd-register-definition-for-panelreplay/20230905-154811
base: git://anongit.freedesktop.org/drm
Hi,
On 05/09/23 16:40, Dmitry Baryshkov wrote:
On Tue, 5 Sept 2023 at 14:00, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 03:39:33PM +0530, Vignesh Raman wrote:
Hi Dmitry, Maxime,
On 05/09/23 14:13, Maxime Ripard wrote:
Hi,
On Mon, Sep 04, 2023 at 07:59:26PM +0300, Dmitry Baryshkov
Hi,
On Sun, Sep 3, 2023 at 8:53 AM Russell King (Oracle)
wrote:
>
> On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown
> > time. Among
On Tue, Sep 05, 2023 at 10:58:30AM +0200, Thomas Hellström wrote:
> when using __drm_kunit_helper_alloc_drm_device() the driver may be
> dereferenced by device-managed resources up until the device is
> freed, which is typically later than the kunit-managed resource code
> frees it.
I'd like to
Hi Maxime,
On 05/09/23 17:27, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 05:11:43PM +0530, Vignesh Raman wrote:
Also, that node actually has a label ("usb"), defined here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/msm8916.dtsi#n2322
So
On Tue, Sep 05, 2023 at 07:06:43PM +0530, Vignesh Raman wrote:
> Hi Maxime,
>
> On 05/09/23 17:27, Maxime Ripard wrote:
> > On Tue, Sep 05, 2023 at 05:11:43PM +0530, Vignesh Raman wrote:
> > > > > Also, that node actually has a label ("usb"), defined here:
> > > > >
On 04/09/2023 16:29, Thomas Zimmermann wrote:
Hi Jocelyn,
thanks for moving this effort forward. It's much appreciated. I looked
through the patches and tried the patchset on my test machine.
Thanks for taking the time to review and test it.
Am 09.08.23 um 21:17 schrieb Jocelyn Falempe:
Hi Heikki,
On Tue, 5 Sept 2023 at 11:50, Heikki Krogerus
wrote:
>
> Hi Dmitry,
>
> On Mon, Sep 04, 2023 at 12:41:39AM +0300, Dmitry Baryshkov wrote:
> > The kdev->fwnode pointer is never set in drm_sysfs_connector_add(), so
> > dev_fwnode() checks never succeed, making the respective commit NOP.
Hi,
On Tue, Sep 05, 2023 at 10:58:31AM +0200, Thomas Hellström wrote:
> Check that object freeing from within drm_exec_fini() works as expected
> and doesn't generate any warnings.
>
> Cc: Christian König
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Thomas Hellström
> ---
>
On Mon, Sep 04, 2023 at 09:18:36PM +0200, Christophe JAILLET wrote:
> snprintf() returns the "number of characters which *would* be generated for
> the given input", not the size *really* generated.
>
> In order to avoid too large values for 'str_size' (and potential negative
> values for
Hi maxime,
On 9/5/23 14:06, Maxime Ripard wrote:
On Tue, Sep 05, 2023 at 10:58:30AM +0200, Thomas Hellström wrote:
when using __drm_kunit_helper_alloc_drm_device() the driver may be
dereferenced by device-managed resources up until the device is
freed, which is typically later than the
Am 05.09.23 um 10:58 schrieb Thomas Hellström:
If *any* object of a certain WW mutex class is locked, lockdep will
consider *all* mutexes of that class as locked. Also the lock allocation
tracking code will apparently register only the address of the first
mutex locked in a sequence.
This has
On Fri, 04 Aug 2023 13:48:09 +0300, Tomi Valkeinen wrote:
> Fix various issues in lt8912b driver.
>
> Tomi
>
>
Fixed the mentioned commit message typos, and an incorrect has
for a "Fixes" tag.
Applied, thanks!
[1/4] drm/bridge: lt8912b: Fix bridge_detach
On 2023/9/5 18:49, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over which
one is primary at boot time. This series tries to solve above mentioned
problem by introduced the
Hi,
On Mon, Sep 4, 2023 at 8:33 AM Maxime Ripard wrote:
>
> > I don't understand the benefit of switching to refcounting, though. We
> > don't ever expect the "prepare" or "enable" function to be called more
> > than once and all we're guarding against is a double-unprepare and a
> >
Paul,
On Mon, Sep 4, 2023 at 2:15 AM Paul Cercueil wrote:
>
> Hi Douglas,
>
> Le vendredi 01 septembre 2023 à 16:41 -0700, Douglas Anderson a écrit :
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown
> >
Quoting Dmitry Baryshkov (2023-09-03 15:40:49)
> On 29/08/2023 21:47, Stephen Boyd wrote:
> > This function is simply drm_dp_is_branch() so use that instead of
> > open-coding it.
> >
> > Cc: Vinod Polimera
> > Cc: Kuogee Hsieh
> > Signed-off-by: Stephen Boyd
> > ---
> >
Hi Paul,
On Wed, 2023-08-16 at 12:56 +0200, Paul Cercueil wrote:
> Hi Sarah,
>
> Le mercredi 16 août 2023 à 09:25 +0100, Sarah Walker a écrit :
> > Add power management to the driver, using runtime pm. The power off
> > sequence depends on firmware commands which are not implemented in
> > this
Applied and dropped the printk.
Alex
On Fri, Sep 1, 2023 at 3:40 AM Christian König wrote:
>
> Am 01.09.23 um 09:02 schrieb Jiapeng Chong:
> > No functional modification involved.
> >
> > drivers/gpu/drm/amd/amdgpu/nbio_v7_11.c:34 nbio_v7_11_get_rev_id() warn:
> > inconsistent indenting.
>
>
>
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions are a part of the parent, MDSS device. Add support for
handling this binding differences.
Signed-off-by: Dmitry Baryshkov
---
Older (mdp5) platforms do not use per-SoC compatible strings. Instead
they use a single compat entry 'qcom,mdss'. To facilitate migrating
these platforms to the DPU driver provide a way to generate the MDSS /
UBWC data at runtime, when the DPU driver asks for it.
It is not possible to generate
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.
All platforms supported by both drivers are by default handled
Bring in hardware support for the SDM660 and SDM630 platforms, which
belong to the same DPU generation as MSM8998.
Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.
Co-developed-by: Konrad Dybcio
Signed-off-by: Konrad
According to the vendor DT files, msm8998 has highest-bank-bit equal to
2. Update the data accordingly.
Fixes: 6f410b246209 ("drm/msm/mdss: populate missing data")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Konrad Dybcio
Add support for MSM8996, which - fun fact - was the SoC that this driver
(or rather SDE, its downstream origin) was meant for and first tested on.
It has some hardware that differs from the modern SoCs, so not a lot of
current structs could have been reused. It's also
Over the last several years the DPU driver has been actively developed,
while the MDP5 is mostly in the maintenance mode. This results in some
features being available only in the DPU driver. For example, bandwidth
scaling, writeback support, properly supported bonded DSI aka dual DSI
support.
Add a call to drm_fb_blit() on existing format conversion tests that
has support.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 142 +
1 file changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
To fully cover drm_fb_blit(), add format conversion tests that are only
supported through drm_fb_blit().
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 142 +
1 file changed, 142 insertions(+)
diff --git
This patchset tests the drm_fb_blit() function.
As this function can be used with already tested formats, the first
patch adds calls to drm_fb_blit() on the tests of supported formats.
Some supported formats were not yet covered by the existing tests
because they are only supported by
Hi,
On Mon, Sep 4, 2023 at 12:55 AM Maxime Ripard wrote:
>
> On Fri, 1 Sep 2023 16:39:52 -0700, Douglas Anderson wrote:
> > As with other places in the Linux kernel--kfree(NULL) being the most
> > famous example--it's convenient to treat being passed a NULL argument
> > as a noop in cleanup
This patch exposes the accumulated amount of active time per client
through the fdinfo infrastructure. The amount of active time is exposed
for each V3D queue: BIN, RENDER, CSD, TFU and CACHE_CLEAN.
In order to calculate the amount of active time per client, a CPU clock
is used through the
This patchset exposes GPU usages stats both globally and per-file
descriptor.
The first patch exposes the accumulated amount of active time per client
through the fdinfo infrastructure. The amount of active time is exposed
for each V3D queue. Moreover, it exposes the number of jobs submitted to
The previous patch exposed the accumulated amount of active time per
client for each V3D queue. But this doesn't provide a global notion of
the GPU usage.
Therefore, provide the accumulated amount of active time for each V3D
queue (BIN, RENDER, CSD, TFU and CACHE_CLEAN), considering all the jobs
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary at boot time.
Question is why is that useful? Should we give users the ability to
control
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_hwseq.c: clk_mgr.h is included
> more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_hwseq.c | 1 -
> 1 file changed, 1 deletion(-)
>
>
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c:
> dcn35_clk_mgr.h is included more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 1 -
> 1 file
Hi,
On Mon, Sep 4, 2023 at 1:30 AM Philipp Zabel wrote:
>
> On Fr, 2023-09-01 at 16:41 -0700, Douglas Anderson wrote:
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown time
> > and at driver unbind time.
Dne sobota, 02. september 2023 ob 01:39:53 CEST je Douglas Anderson
napisal(a):
> Based on grepping through the source code these drivers appear to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
>
Hi,
On Mon, Sep 4, 2023 at 12:28 AM Geert Uytterhoeven wrote:
>
> Hi Douglas,
>
> On Sat, Sep 2, 2023 at 1:42 AM Douglas Anderson wrote:
> > Based on grepping through the source code, this driver appears to be
> > missing a call to drm_atomic_helper_shutdown(), or in this case the
> >
On Wed, 6 Sep 2023 00:21:09 +0800
suijingfeng wrote:
> Hi,
>
> On 2023/9/5 22:52, Alex Williamson wrote:
> > On Tue, 5 Sep 2023 03:57:15 +0800
> > Sui Jingfeng wrote:
> >
> >> From: Sui Jingfeng
> >>
> >> On a machine with multiple GPUs, a Linux user has no control over which
> >> one is
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_resource.c:
> dcn31/dcn31_dio_link_encoder.h is included more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_resource.c | 1 -
> 1 file
Applied. Thanks!
On Thu, Aug 31, 2023 at 8:52 PM Yang Li wrote:
>
> ./drivers/gpu/drm/amd/display/dc/dcn35/dcn35_optc.c: dcn35_optc.h is included
> more than once.
>
> Signed-off-by: Yang Li
> ---
> drivers/gpu/drm/amd/display/dc/dcn35/dcn35_optc.c | 1 -
> 1 file changed, 1 deletion(-)
>
>
Applied the series. Thanks!
Alex
On Thu, Aug 31, 2023 at 9:29 PM Yang Li wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn35/dcn35_fpu.c:260
> dcn35_update_bw_bounding_box_fpu() warn: inconsistent indenting
>
> Signed-off-by: Yang Li
> ---
>
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: f45acf7acf75921c0409d452f0165f51a19a74fd
commit: 8e455145d8f163aefa6b9cc29478e0a9f82276e6 [3/3] drm/debugfs: rework
drm_debugfs_create_files implementation v2
config: openrisc-randconfig-r015-20230906
Hi Elmar,
Just had a few minor comments:
Looking at past panel-simple changes, I think the prefix here should be
"drm/panel: simple:"
On 8/28/2023 2:49 AM, Elmar Albert wrote:
From: Elmar Albert
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a
On Wed, Aug 30, 2023 at 8:51 AM Adrián Larumbe
wrote:
>
> >> The current implementation will try to pick the highest available
> >> unit. This is rather unflexible, and allowing drivers to display BO size
> >> statistics through fdinfo in units of their choice might be desirable.
> >>
> >> The
Hi Linus,
Thank you for your feedback (comments below).
On Fri, 2023-08-18 at 11:36 +0200, Linus Walleij wrote:
> Hi Sarah,
>
> thanks for your patch!
>
> Patches adding device tree bindings need to be CC:ed to
> devicet...@vger.kernel.org
> and the DT binding maintainers, I have added it for
There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637
Fixes:
Hi,
On Thu, Aug 10, 2023 at 1:23 AM Linus Walleij wrote:
>
> On Fri, Aug 4, 2023 at 11:07 PM Douglas Anderson
> wrote:
>
> > As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> > prepared/enabled in drm_panel"), we want to remove needless code from
> > panel drivers that
Meteorlake has been very usable for a while now, all of uapi changes
related to fundamental platform usage have been finalized and all
required firmware blobs are available. Recent CI results have also
been healthy, so we're ready to drop the force_probe requirement and
enable the platform by
[WHY]
edid_override and drm_edid_override_connector_update, according to drm
documentation, should not be referred outside drm_edid.
[HOW]
Remove and replace them accordingly.
Signed-off-by: Alex Hung
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
1 file changed, 2
The drm-stats fdinfo tags made available to user space are drm-engine,
drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
This deviates from standard practice in other DRM drivers, where a single
set of key:value pairs is provided for the whole render engine. However,
Panfrost has
In a future development, we will want to keep track of the number of GPU
cycles spent on a given job. That means we should enable it only when the
GPU has work to do, and switch it off whenever it is idle to avoid power
waste.
To avoid race conditions during enablement/disabling, a reference
A new DRM GEM object function is added so that drm_show_memory_stats can
provide more accurate memory usage numbers.
Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
after locking the driver's shrinker mutex, but drm_show_memory_stats takes
over the drm file's object
These GPU registers will be used when programming the cycle counter, which
we need for providing accurate fdinfo drm-cycles values to user space.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_regs.h | 5 +
1 file
This patch series adds fdinfo support to the Panfrost DRM driver. It will
display a series of key:value pairs under /proc/pid/fdinfo/fd for render
processes that open the Panfrost DRM file.
The pairs contain basic drm gpu engine and memory region information that
can either be cat by a privileged
Allow user space to decide whether the cycle counting register should be
enabled. The main goal is letting tools like nvtop or IGT's gputop access
this information in debug builds to obtain engine utilisation numbers.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/Makefile
BO's RSS is updated every time new pages are allocated on demand and mapped
for the object at GPU page fault's IRQ handler, but only for heap buffers.
The reason this is unnecessary for non-heap buffers is that they are mapped
onto the GPU's VA space and backed by physical memory in their entirety
Some BO's might be mapped onto physical memory chunkwise and on demand,
like Panfrost's tiler heap. In this case, even though the
drm_gem_shmem_object page array might already be allocated, only a very
small fraction of the BO is currently backed by system memory, but
drm_show_memory_stats will
The current implementation will try to pick the highest available size
display unit as soon as the BO size exceeds that of the previous
multiplier.
By selecting a higher threshold, we could show more accurate size numbers.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/drm_file.c | 2 +-
1
Hi,
On Tue, Sep 5, 2023 at 9:45 AM Doug Anderson wrote:
>
> As per our discussion, in V2 we will make drm_panel_remove() actually
> unprepare / disable a panel if it was left enabled. This would
> essentially fold in the drm_panel_helper_shutdown() from my RFC patch.
> This would make
On 2023-09-05 14:53, Hamza Mahfooz wrote:
There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.
Cc: sta...@vger.kernel.org
Link:
Hi Dmitry,
On 8/31/2023 3:51 PM, Dmitry Osipenko wrote:
On 8/24/23 20:58, Kim, Dongwon wrote:
...
You can do fence-wait in the guest userspace/Mesa after blitting/drawing
to the udmabuf.
There is already synchronization between QEMU and virtio-gpu driver on
the guest. Upon resource flush,
On Wed, Aug 16, 2023 at 11:15:47AM +0200, Thomas Hellström wrote:
> Add the first version of the VM_BIND locking document which is
> intended to be part of the xe driver upstreaming agreement.
>
> The document describes and discuss the locking used during exec-
> functions, evicton and for
1 - 100 of 153 matches
Mail list logo
