On Mon, Apr 17, 2023 at 01:06:56PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Fix a couple missing ':'s.
>
> Signed-off-by: Rob Clark
Reviewed-by: Rodrigo Vivi
> ---
> Documentation/gpu/drm-usage-stats.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
>
> From: Sean Paul
>
> Instead of forcing a modeset in the hdcp atomic check, rename to
> drm_hdcp_has_changed and return true if the content protection value is
> changing and let the driver decide whether a modeset is required or not.
>
> Acked-by: Jani Nikula
> Reviewed-by: Rodrigo Vivi
On Mon, Apr 10, 2023 at 03:35:09PM -0700, Ashutosh Dixit wrote:
> Instead of erroring out when GuC reset is in progress, block waiting for
> GuC reset to complete which is a more reasonable uapi behavior.
>
> v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
>
> Signed-off-by:
Yacoub
> ; linux-ker...@vger.kernel.org
> Subject: [PATCH v9 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
>
> From: Sean Paul
>
> Move the hdcp atomic check from i915 to drm_hdcp so other drivers can use
> it. No functional changes, just cleaned up some of the code when moving it
> over.
>
>
On Mon, Apr 17, 2023 at 6:53 AM Adam Ford wrote:
>
> On Mon, Apr 17, 2023 at 3:38 AM Lucas Stach wrote:
> >
> > Hi Adam,
> >
> > Am Samstag, dem 15.04.2023 um 05:41 -0500 schrieb Adam Ford:
> > > NXP uses a lookup table to determine the various values for
> > > the PHY Timing based on the clock
On Sun, Apr 16, 2023 at 5:08 PM Marek Vasut wrote:
>
> On 4/15/23 12:41, Adam Ford wrote:
> > Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> > having an entry in the device tree for samsung,pll-clock-frequency.
> >
> > Signed-off-by: Adam Ford
> > ---
> >
On 4/17/2023 4:14 PM, Marijn Suijten wrote:
Some of these members were initialized while never read, while others
were not even assigned any value at all. Drop them to save some space,
and above all confusion when looking at these members.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU
On 17/04/23 13:19, Maíra Canal wrote:
> On 4/6/23 08:53, Arthur Grillo wrote:
>> Insert parameterized test for the drm_rect_calc_vscale() to ensure
>> correctness and prevent future regressions. Besides the test for the
>> usual case, tests the exceptions.
>>
>> It uses the same struct from
Hi Vinay,
Looks good, just few minor comments below,
[...]
> @@ -267,13 +267,11 @@ static int run_test(struct intel_gt *gt, int test_type)
> }
>
> /*
> - * Set min frequency to RPn so that we can test the whole
> - * range of RPn-RP0. This also turns off efficient freq
>
On 17/04/23 09:10, Maíra Canal wrote:
> Currently, the pixel conversion functions repeat the same loop to
> iterate the rows. Instead of repeating the same code for each pixel
> format, create a function to wrap the loop and isolate the pixel
> conversion functionality.
>
> Suggested-by:
Hi Thomas,
The Intel(x86) CPUs have a separate address space for "IO", but the ARM
architecture only has "memory", so all IO devices are accessed as if
they were memory. Which means ARM does not support isolated IO. Here is
a related discussion on ARM's forum.
On Thu, Apr 13, 2023 at 10:52:28AM +0200, Matthias Brugger wrote:
>
>
> On 12/04/2023 23:03, Rob Herring wrote:
> >
> > On Wed, 12 Apr 2023 13:27:13 +0200, AngeloGioacchino Del Regno wrote:
> > > Add a compatible string for MediaTek Helio X10 MT6795's display PWM
> > > block: this is the same
Hi Thomas,
The Intel(x86) CPUs have a separate address space for "IO", but the ARM
architecture only has "memory", so all IO devices are accessed as if
they were memory. Which means ARM does not support isolated IO. Here is
a related discussion on ARM's forum.
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it
In multi-gt systems IRQs need to be reset and enabled per GT.
This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Reviewed-by: Matt Roper
On 4/14/2023 4:49 PM, Dixit, Ashutosh wrote:
On Fri, 14 Apr 2023 15:34:15 -0700, Vinay Belgaumkar wrote:
@@ -457,6 +458,34 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc
*slpc, u32 *val)
return ret;
}
+int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc,
On Tue, Apr 18, 2023 at 12:34:43AM +0200, Andi Shyti wrote:
> In multi-gt systems IRQs need to be reset and enabled per GT.
>
> This might add some redundancy when handling interrupts for
> engines that might not exist in every tile, but helps to keep the
> code cleaner and more understandable.
>
On 4/18/23 00:24, Adam Ford wrote:
On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut wrote:
On 4/17/23 13:57, Adam Ford wrote:
On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut wrote:
On 4/15/23 12:41, Adam Ford wrote:
The high-speed clock is hard-coded to the burst-clock
frequency specified in the
On Sun, Apr 16, 2023 at 4:53 AM Dmitry Osipenko <
dmitry.osipe...@collabora.com> wrote:
> We have multiple Vulkan context types that are awaiting for the addition
> of the sync object DRM UAPI support to the VirtIO-GPU kernel driver:
>
> 1. Venus context
> 2. Native contexts (virtio-freedreno,
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the block with, fallible error
handling and all.
The WB debug log mask ended up never being assigned, leading to writes
to this block to never be logged even if the mask is enabled in
dpu_hw_util_log_mask via sysfs.
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback
blocks")
Signed-off-by: Marijn Suijten
---
Some of these members were initialized while never read, while others
were not even assigned any value at all. Drop them to save some space,
and above all confusion when looking at these members.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Fixes: 84a33d0fd921 ("drm/msm/dpu: add
Doing a for loop in every DPU HW block driver init to find a catalog
entry matching the given ID is rather useless if the init function
called by RM already has that catalog entry pointer, and uses exactly
its ID to drive this init and for loop. Remove all that machinery to
drop quite some lines
From: Rob Clark
This is something that can block for arbitrary amounts of time as
userspace consumes from the FIFO. So we don't really want this to
be in the fence signaling path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c
From: Rob Clark
Commit d6ae7d1cd58e ("drm/msm/gem: Simplify vmap vs LRU tracking")
introduced a splat in the pin_pages_locked() path for buffers that
had been MADV_DONTNEED.
[ cut here ]
msm_obj->madv != 0
WARNING: CPU: 1 PID: 144 at
On Tue, Mar 28, 2023 at 6:45 PM Won Chung wrote:
>
> Expose DRM connector id in device sysfs so that we can map the connector
> id to the connector syspath. Currently, even if we can derive the
> connector id from modeset, we do not have a way to find the
> corresponding connector's syspath.
>
>
In multi-gt systems IRQs need to be reset and enabled per GT.
This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
---
Hi,
The rsults of
On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut wrote:
>
> On 4/17/23 13:57, Adam Ford wrote:
> > On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut wrote:
> >>
> >> On 4/15/23 12:41, Adam Ford wrote:
> >>> The high-speed clock is hard-coded to the burst-clock
> >>> frequency specified in the device tree.
On Mon, Apr 17, 2023, at 23:17, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> Three functions in the amdgpu display driver cause -Wmissing-prototype
>> warnings:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error:
>> no
From: Arnd Bergmann
Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
is_timing_changed() is actually meant to
On Mon, 17 Apr 2023 14:37:47 +0200, Sascha Hauer wrote:
> afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume") uses
> regmap_reinit_cache() to fix the suspend/resume issue with the VOP2
> driver. During discussion it came up that we should rather use
> regcache_sync() instead. As the original
It is likely p1_min_meta_chunk_bytes was expected here, instead of
min_meta_chunk_bytes.
Test the correct variable.
Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321")
Signed-off-by: Christophe JAILLET
---
.../gpu/drm/amd/display/dc/dml/dcn32/display_rq_dlg_calc_32.c | 2 +-
1
On 4/15/2023 10:19 AM, Dmitry Baryshkov wrote:
MSM8998 and the older Qualcomm platforms support HDMI outputs. Now as
DPU encoder is ready, add support for using INTF_HDMI.
From what I see, encoder was always ready but just HDMI case was not
handled? Or are you saying this because of the
It is likely Height was expected here, instead of Width.
Test the correct variable.
Fixes: 17529ea2acfa ("drm/amd/display: Optimizations for DML math")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 2 +-
1 file changed, 1 insertion(+), 1
On 4/17/23 17:05, Arnd Bergmann wrote:
From: Arnd Bergmann
Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
On Mon, Apr 17, 2023, at 23:12, Hamza Mahfooz wrote:
> On 4/17/23 17:05, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> The newly introduced global function is not declared in a header or
>> called from another file, causing a harmless warning with sparse
>> or W=1 builds:
>>
>>
On 4/17/23 17:05, Arnd Bergmann wrote:
From: Arnd Bergmann
The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no
From: Arnd Bergmann
Three functions in the amdgpu display driver cause -Wmissing-prototype
warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1858:6: error: no
previous prototype for 'is_timing_changed' [-Werror=missing-prototypes]
From: Arnd Bergmann
The newly introduced global function is not declared in a header or
called from another file, causing a harmless warning with sparse
or W=1 builds:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_dccg.c:277:6: error: no
previous prototype for 'dccg314_init'
From: Arnd Bergmann
Global functions in radeon_atpx_handler.c are not declared in a header
but instead in each file using them. This risks the types getting out
of sync and causes warnings:
drivers/gpu/drm/radeon/radeon_atpx_handler.c:64:6: error: no previous prototype
for 'radeon_has_atpx'
From: Arnd Bergmann
The empty stub functions are defined as global functions, which
causes a warning because of missing prototypes:
drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype for
'g2d_open'
drivers/gpu/drm/exynos/exynos_drm_g2d.h:42:5: error: no previous
From: Arnd Bergmann
nv50_display_create() is declared in another header, along with
a couple of declarations that are now outdated:
drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype
for 'nv50_display_create'
Fixes: ba801ef068c1 ("drm/nouveau/kms: display
From: Arnd Bergmann
tu102_gr_load() is completely unused and can be removed to address
this warning:
drivers/gpu/drm/nouveau/dispnv50/disp.c:2517:1: error: no previous prototype
for 'nv50_display_create'
Fixes: 1cd97b5490c8 ("drm/nouveau/gr/tu102-: use sw_veid_bundle_init from
firmware")
From: Arnd Bergmann
The corgi_lcd_limit_intensity() function is called from platform
and defined in a driver, but the driver does not see the declaration:
drivers/video/backlight/corgi_lcd.c:434:6: error: no previous prototype for
'corgi_lcd_limit_intensity' [-Werror=missing-prototypes]
434
Currently, on a handful of ASICs. We allow the framebuffer for a given
plane to exist in either VRAM or GTT. However, if the plane's new
framebuffer is in a different memory domain than it's previous
framebuffer, flipping between them can cause the screen to flicker. So,
to fix this, don't perform
On Mon, Apr 17, 2023 at 1:12 PM Rob Clark wrote:
>
> From: Rob Clark
>
> When many of the things using the GPU are processes in a VM guest, the
> actual client process is just a proxy. The msm driver has a way to let
> the proxy tell the kernel the actual VM client process's executable name
>
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG blocks used by hardware prior
to 5.0.0.
The
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF TE support. To clean this
up, move the logic
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted downstream via the
DPU/SDE_MDP_VSYNC_SEL feature
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up these interrupts
and IRQ masks on all supported hardware.
Signed-off-by: Marijn Suijten
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 12 ++
This callback was migrated from downstream when DPU1 was first
introduced to mainline, but never used by any component. Drop it to
save some lines and unnecessary confusion.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 18
A bunch of registers were appended at the end in e.g. 91143873a05d
("drm/msm/dpu: Add MISR register support for interface") rather than
being inserted in a place that maintains numerical sorting. Restore
that.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12
These functions are always called consecutively and are best bundled
together for simplicity, especially when the same structure of callbacks
will be replicated later on the interface block for INTF TE support.
The enable_tearcheck(false) case is now replaced with a more obvious
Now that newer DPU platforms use a readpointer-done interrupt on the
INTF block, stop providing the unused interrupt on the PINGPONG block.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 8
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.
Signed-off-by: Marijn Suijten
---
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero. However, the PP_BLK macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-off-by: Marijn Suijten
---
From: Konrad Dybcio
Now that newer SoCs since DPU 5.0.0 manage tearcheck in the INTF instead
of PINGPONG block, move the struct definition to a common file. Also,
bring in documentation from msm-4.19 techpack while at it.
Signed-off-by: Konrad Dybcio
[Marijn: Also move dpu_hw_pp_vsync_info]
As the INTF block is going to attain more interrupts that don't share
the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
the caller to construct the right interrupt index (register and bit
index) to not make the interrupt bit arguments depend on one of multiple
interrupt
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 5 -
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and the #define keyword.
Signed-off-by: Marijn
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent confusion.
Note that downstream enables the
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
Signed-off-by: Marijn Suijten
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts. Additionally, disable previous register writes and remove
unused
From: Rob Clark
Normally this would be the same information that can be obtained in
other ways. But in some cases the process opening the drm fd is merely
a sort of proxy for the actual process using the GPU. This is the case
for guest VM processes using the GPU via virglrenderer, in which
From: Rob Clark
Make it work in terms of ctx so that it can be re-used for fdinfo.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c | 13 ++---
From: Rob Clark
The restriction about no whitespace, etc, really only applies to the
usage of strings in keys. Values can contain anything (other than
newline).
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 29 ++-
1 file changed, 15
From: Rob Clark
When many of the things using the GPU are processes in a VM guest, the
actual client process is just a proxy. The msm driver has a way to let
the proxy tell the kernel the actual VM client process's executable name
and command-line, which has until now been used simply for GPU
On 4/17/23 13:57, Adam Ford wrote:
On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut wrote:
On 4/15/23 12:41, Adam Ford wrote:
The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree. However, when
using devices like certain bridge chips without burst mode
and
From: Rob Clark
Fix a couple missing ':'s.
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..72d069e5dacb
On Tue, Feb 28, 2023 at 12:59:41PM -0800, T.J. Mercier wrote:
> On Sat, Jan 21, 2023 at 7:03 AM Jason Gunthorpe wrote:
> >
> > I would like to have a session at LSF to talk about Matthew's
> > physr discussion starter:
> >
> >
On 4/17/2023 12:41 PM, Marijn Suijten wrote:
On 2023-02-14 09:54:57, Abhinav Kumar wrote:
[..]
Just wondering, how were the lengths calculated for the INTF blocks?
The values in general seem a little off to me.
These (for MSM8998) have been taken from downstream specifically; my
series
On 2023-02-14 09:54:57, Abhinav Kumar wrote:
[..]
> Just wondering, how were the lengths calculated for the INTF blocks?
> The values in general seem a little off to me.
> >
> > These (for MSM8998) have been taken from downstream specifically; my
> > series starts using INTF_STATUS at
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Add support to dump GEM stats to fdinfo.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> Documentation/gpu/drm-usage-stats.rst | 12 +++
> drivers/gpu/drm/drm_file.c| 52 +++
>
Thanks. Applied!
Alex
On Thu, Apr 13, 2023 at 11:12 AM Nikita Zhandarovich
wrote:
>
> Several calls to ci_dpm_fini() will attempt to free resources that
> either have been freed before or haven't been allocated yet. This
> may lead to undefined or dangerous behaviour.
>
> For instance, if
Applied. Thanks!
On Fri, Apr 14, 2023 at 11:08 AM Tom Rix wrote:
>
> cpp_check reports
> drivers/gpu/drm/amd/display/modules/freesync/freesync.c:1143:17: style:
> Variable
> 'oldest_index' is assigned a value that is never used. [unreadVariable]
>oldest_index = 0;
> ^
>
>
On Mon, 2023-04-17 at 12:15 -0700, Ceraolo Spurio, Daniele wrote:
> On 4/17/2023 11:21 AM, Teres Alexis, Alan Previn wrote:
> > On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
> > > > @@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
> > > > if
Applied. Thanks!
Alex
On Mon, Apr 17, 2023 at 1:42 PM Colin Ian King wrote:
>
> There is a spelling mistake in the smu_i2c_bus_access prototype. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 2 +-
> 1 file changed, 1 insertion(+), 1
On 4/15/2023 10:19 AM, Dmitry Baryshkov wrote:
Rather than passing DRM_MODE_ENCODER_* and letting dpu_encoder to guess,
which intf type we mean, pass INTF_DSI/INTF_DP directly. This is
required to support HDMI output in DPU, as both DP and HDMI encoders are
DRM_MODE_ENCODER_TMDS. Thus
On 4/17/2023 11:21 AM, Teres Alexis, Alan Previn wrote:
On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
alan:snip
@@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if
On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
>
>
>
alan:snip
> > @@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
> > if (!intel_pxp_is_enabled(pxp))
> > return -ENODEV;
> >
> > - if (wait_for(pxp_component_bound(pxp), 250))
> > -
On Mon, 2023-04-10 at 09:28 -0700, Ceraolo Spurio, Daniele wrote:
>
alan:snip
> > #define GSC_OUTFLAG_MSG_PENDING 1
> > +#define GSC_INFLAG_MSG_CLEANUP BIT(1)
>
> For consistency those should all be BIT() defines
alan: will do.
>
> With the define fixed:
>
> Reviewed-by: Daniele Ceraolo
On Mon, 2023-04-10 at 09:10 -0700, Ceraolo Spurio, Daniele wrote:
>
alan:snip
> > +int
> > +intel_gsc_uc_heci_cmd_submit_nonpriv(struct intel_gsc_uc *gsc,
> > +struct intel_context *ce,
> > +struct intel_gsc_heci_non_priv_pkt *pkt,
There is a spelling mistake in the smu_i2c_bus_access prototype. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h
Hi Lucas
>
> gpu->mmu_context is the MMU context of the last job in the HW queue, which
> isn't necessarily the same as the context from the bad job. Dump the MMU
> context from the scheduler determined bad submit to make it work as intended.
>
Good catch!
> Fixes: 17e4660ae3d7 ("drm/etnaviv:
On Mon, Apr 17, 2023 at 1:59 AM Christian König
wrote:
>
> Am 14.04.23 um 21:33 schrieb Hamza Mahfooz:
> > Currently, we allow the framebuffer for a given plane to move between
> > memory domains, however when that happens it causes the screen to
> > flicker, it is even possible for the
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170848Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170311Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
Signed up will only attend virtually Online however just fyi
On Mon, Apr 17, 2023 at 1:41 PM Samuel Iglesias Gonsálvez
wrote:
>
> Hello!
>
> Registration & Call for Proposals are now open for XDC 2023, which will
> take place on October 17-19, 2023.
>
> https://xdc2023.x.org
>
> As usual, the
On 4/17/23 11:41, Wu, Hersen wrote:
[AMD Official Use Only - General]
Hi,
The change applies to all AMD GPU ASIC.
Please communicate with issue reporter to see if the issue could be reproduced
older ASIC, like Mendocino, CZN.
From the community reports, it can be reproduced on as far back
On Sun, Apr 16, 2023 at 11:30 AM Markus Elfring wrote:
>
> Date: Sun, 16 Apr 2023 11:22:23 +0200
>
> Several update suggestions were taken into account
> from static source code analysis.
>
Reviewed-by: Karol Herbst
> Markus Elfring (9):
> debugfs: Move an expression into a function call
On 4/6/23 08:53, Arthur Grillo wrote:
Insert a parameterized test for the drm_rect_rotate_inv() to ensure its
correctness and prevent future regressions. The test covers all rotation
modes.
It uses the same test cases from drm_test_rect_rotate().
Signed-off-by: Arthur Grillo
Thanks for the
On 4/6/23 08:53, Arthur Grillo wrote:
Insert a parameterized test for the drm_rect_rotate() to ensure
correctness and prevent future regressions.
All possible rotation modes are covered by the test.
Signed-off-by: Arthur Grillo
Thanks for the patch!
Reviewed-by: Maíra Canal
Best Regards,
Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c| 52 +++
On 4/6/23 08:53, Arthur Grillo wrote:
Insert parameterized test for the drm_rect_calc_vscale() to ensure
correctness and prevent future regressions. Besides the test for the
usual case, tests the exceptions.
It uses the same struct from drm_rect_calc_hscale().
Signed-off-by: Arthur Grillo
---
On 4/6/23 08:53, Arthur Grillo wrote:
Insert parameterized tests for the drm_rect_intersect() to ensure
correctness and prevent future regressions.
Also, create a helper for testing if two drm_rects are equal.
Signed-off-by: Arthur Grillo
Thanks for the patch!
Reviewed-by: Maíra Canal
On Mon, Apr 17, 2023 at 7:20 AM Tvrtko Ursulin
wrote:
>
>
> On 17/04/2023 14:42, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 4:10 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 16/04/2023 08:48, Daniel Vetter wrote:
> >>> On Fri, Apr 14, 2023 at 06:40:27AM -0700, Rob Clark wrote:
> On Fri,
From: Tvrtko Ursulin
Use DRM helpers for implementing basic memory stats.
Signed-off-by: Tvrtko Ursulin
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index
From: Tvrtko Ursulin
Show how more driver specific set of memory stats could be shown,
more specifically where object can reside in multiple regions, showing all
the supported stats, and where there is more to show than just user visible
objects.
WIP...
Signed-off-by: Tvrtko Ursulin
---
From: Tvrtko Ursulin
Use the common fdinfo helper for printing the basics. Remove now unused
client id allocation code.
Signed-off-by: Tvrtko Ursulin
Cc: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 6 +--
drivers/gpu/drm/i915/i915_drm_client.c | 65 --
1 - 100 of 291 matches
Mail list logo
