No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:1199: warning:
expecting prototype for dc_link_detect_connection_type(). Prototype was for
link_detect_connection_type() instead.
Reported-by: Abaci Robot
Link:
With all previous preparations done to make it possible for the
single LCDIF embedded in i.MX93 SoC to drive multiple displays
simultaneously, add i.MX93 LCDIF compatible string as the last
step of adding i.MX93 LCDIF support.
Reviewed-by: Alexander Stein
Signed-off-by: Liu Ying
---
v3->v4:
*
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Look at LCDIF output port's remote port parents to
find all enabled first bridges. Add an encoder for each found bridge
and attach the bridge to the encoder. This is a preparation for
adding i.MX93 LCDIF
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Check bus format and flags across first bridges in
->atomic_check() to ensure they are consistent. This is a preparation
for adding i.MX93 LCDIF support.
Signed-off-by: Liu Ying
---
v3->v4:
* No change.
Instead of determining LCDIF output bus format and bus flags in
->atomic_enable(), do that in ->atomic_check(). This is a
preparation for the upcoming patch to check consistent bus format
and bus flags across all first downstream bridges in ->atomic_check().
New lcdif_crtc_state structure is
A valid bridge is already found in lcdif_attach_bridge() and set
to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
the unnecessary NULL pointer check in KMS stage.
Reviewed-by: Alexander Stein
Signed-off-by: Liu Ying
---
v3->v4:
* Add Alexander's R-b tag.
v2->v3:
* No change.
There is one LCDIF embedded in i.MX93 SoC to connect with
MIPI DSI controller through LCDIF cross line pattern(controlled
by mediamix blk-ctrl) or connect with LVDS display bridge(LDB)
directly or connect with a parallel display through parallel
display format(also controlled by mediamix
Hi,
This patch set aims to add i.MX93 LCDIF display controller support
in the existing LCDIF DRM driver. The LCDIF embedded in i.MX93 SoC
is essentially the same to those embedded in i.MX8mp SoC. Through
internal bridges, i.MX93 LCDIF may drive a MIPI DSI display or a LVDS
display or a parallel
These functions are not used outside the file device.c, so the
modification is defined as static.
drivers/accel/habanalabs/common/device.c:2641:6: warning: no previous prototype
for ‘hl_capture_fw_err’.
drivers/accel/habanalabs/common/device.c:2619:6: warning: no previous prototype
for
The pull request you sent on Fri, 17 Feb 2023 12:16:34 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-02-17
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ec35307e18ba8174e2a3f701956059f6a36f22fb
Thank you!
--
Deet-doot-dot, I am a bot.
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definition to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
On Tue, 2023-02-14 at 13:38 -0800, Teres Alexis, Alan Previn wrote:
> Add MTL's function for ARB session creation using PXP firmware
> version 4.3 ABI structure format.
>
> Also add MTL's function for ARB session invalidation but this
> reuses PXP firmware version 4.2 ABI structure format.
>
>
From: John Harrison
Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two ring state
registers. Unfortunately, the register state being used is only valid
From: John Harrison
The comparison in the search for a matching register capture node was
not the most readable. It was also assuming that a zero GuC id means
invalid, which it does not. So remove one invalid term, one redundant
term and re-format to keep each term on a single line, and only one
From: John Harrison
Ecodes got lost with the switch to GuC based register lists. Put them
back.
Seqno values got lost with the switch to per context timelines. Put
those back too.
v2: Rework the timeline patch to just read the single seqno value
rather than copying the entire object.
From: John Harrison
The seqno value actually written out to memory is no longer in the
regular HWSP. Instead, it is now in its own private timeline buffer.
Thus, it is no longer visible in an error capture. So, explicitly read
the value and include that in the capture.
Signed-off-by: John
Hi Linus,
Just a final collection of misc fixes, the biggest disables the
recently added dynamic debugging support, it has a regression that
needs some bigger fixes. Otherwise a bunch of fixes across the board,
vc4, amdgpu and vmwgfx mostly, with some smaller i915 and ast fixes.
Dave.
On 2023.02.14 20:45:33 -0800, Randy Dunlap wrote:
> Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
> into a list of other symbols that do have a dependency (on DRM_I915)
> breaks the driver menu presentation in 'make *config'.
>
I'm not sure what's the actual failure in
On 2023-01-25 14:53, Jonathan Kim wrote:
Add missing debug trap registers references and initialize all debug
registers on boot by clearing the hardware exception overrides and the
wave allocation ID index.
The debugger requires that TTMPs 6 & 7 save the dispatch ID to map
waves onto dispatch
On 2023-01-25 14:53, Jonathan Kim wrote:
The ROCm debugger will attach to a process to debug by PTRACE and will
expect the KFD to prepare a process for the target PID, whether the
target PID has opened the KFD device or not.
This patch is to explicity handle this requirement. Further HW mode
On 2023-01-25 14:53, Jonathan Kim wrote:
Similar to GFX9 debug devices, set the hardware debug mode by draining
the SPI appropriately prior the mode setting request.
Because GFX10 has waves allocated by the work group boundaray and each
Typo: boundary?
SE's SPI instances do not
On 2023-01-25 14:53, Jonathan Kim wrote:
GFX9.4.2 now supports per-VMID debug mode controls registers
(SPI_GDBG_PER_VMID_CNTL).
Because the KFD lets the HWS handle PASID-VMID mapping, the KFD will
forward all debug mode setting register writes to the HWS scheduler
using a new MAP_PROCESS API,
On 2023-01-25 14:53, Jonathan Kim wrote:
On GFX9.4.1, the implicit wait count instruction on s_barrier is
disabled by default in the driver during normal operation for
performance requirements.
There is a hardware bug in GFX9.4.1 where if the implicit wait count
instruction after an s_barrier
On 2023-01-25 14:53, Jonathan Kim wrote:
Implement the per-device calls to enable or disable HW debug mode
for GFX11.
Signed-off-by: Jonathan Kim
---
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c| 39 +++
1 file changed, 39 insertions(+)
diff --git
On 2023-01-25 14:53, Jonathan Kim wrote:
Expose debug capabilities in the KFD topology node's HSA capabilities and
debug properties flags.
Ensure correct capabilities are exposed based on firmware support.
Flag definitions can be referenced in uapi/linux/kfd_sysfs.h.
v2: v1 was reviewed but
On 2023-01-25 14:53, Jonathan Kim wrote:
Implement the per-device calls to enable or disable HW debug mode for
GFX9 prior to GFX9.4.1.
GFX9.4.1 and onward will require their own enable/disable sequence as
follow on patches.
When hardware debug mode setting is requested, waves will inherit
On 2023-01-25 14:53, Jonathan Kim wrote:
Introduce the GPU debug operations interface.
For ROCm-GDB to extend the GNU Debugger's ability to inspect the AMD GPU
instruction set, provide the necessary interface to allow the debugger
to HW debug-mode set and query exceptions per HSA queue,
https://bugzilla.kernel.org/show_bug.cgi?id=216143
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|REOPENED|RESOLVED
On Thu, 16 Feb 2023 09:52:57 -0500
Alex Deucher wrote:
> On Thu, Feb 16, 2023 at 8:45 AM Orlando Chamberlain
> wrote:
> >
> > Commit 3840c5bcc245 ("drm/amdgpu: disentangle runtime pm and
> > vga_switcheroo") made amdgpu only register a vga_switcheroo client
> > for GPU's with PX, however AMD
Hi,
On Mon, Jan 16, 2023 at 03:22:34PM +0800, Chen-Yu Tsai wrote:
> The device lock is used to serialize the low level power sequencing
> operations. Since drm_helper_hpd_irq_event() could end up calling
> .atomic_enable, which also calls power sequencing functions through
> runtime PM, this
On Mon, Jan 16, 2023 at 03:24:06PM +0800, Chen-Yu Tsai wrote:
> The DRM DP code has macros for the DP power sequencing commands. Use
> them in the anx7625 driver instead of raw numbers.
>
> Fixes: 548b512e144f ("drm/bridge: anx7625: send DPCD command to downstream")
> Fixes: 27f26359de9b
On Thu, Feb 16, 2023 at 11:43:38PM +0300, Dmitry Osipenko wrote:
> On 2/16/23 15:15, Daniel Vetter wrote:
> > On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote:
> >> On 1/27/23 11:13, Gerd Hoffmann wrote:
> >>> On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote:
>
On Thu, Feb 16, 2023 at 08:49:42AM -0800, Ashutosh Dixit wrote:
> Previous PL1 power limit implementation assumed that the PL1 limit is
> always enabled in HW. However we now find this not to be the case on ATSM
> where the PL1 limit is disabled at power up. This requires changes in the
> previous
On 2023-02-16 18:34:43, Dmitry Baryshkov wrote:
> On 16/02/2023 10:31, Marijn Suijten wrote:
> > On 2023-02-16 04:22:13, Dmitry Baryshkov wrote:
> >> On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
> >> wrote:
> >>>
> >>> DPU's catalog never assigned dpu_scaler_blk::version leading to
> >>>
On 2/8/23 03:56, Pekka Paalanen wrote:
> On Fri, 3 Feb 2023 02:07:43 +
> Joshua Ashton wrote:
>
>> To match the other enums, and add more information about these values.
>>
>> Signed-off-by: Joshua Ashton
>>
>> Cc: Pekka Paalanen
>> Cc: Sebastian Wick
>> Cc: vitaly.pros...@amd.com
>>
Commit 3840c5bcc245 ("drm/amdgpu: disentangle runtime pm and
vga_switcheroo") made amdgpu only register a vga_switcheroo client for
GPU's with PX, however AMD GPUs in dual gpu Apple Macbooks do need to
register, but don't have PX. Instead of AMD's PX, they use apple-gmux.
Use apple_gmux_detect()
On Thu, 16 Feb 2023, Dmitry Osipenko wrote:
> On 2/16/23 21:26, Iaroslav Boliukin wrote:
>> On 2/14/23 12:50, Dmitry Osipenko wrote:
>>> On 2/13/23 14:50, Jani Nikula wrote:
On Mon, 13 Feb 2023, Dmitry Osipenko
wrote:
> On 2/13/23 12:56, Jani Nikula wrote:
>> On Sun, 12 Feb
Use the DisplayID 2.0 primary use case information to deduce whether
this is a head-mounted display, and should not be used for desktop.
Cc: Iaroslav Boliukin
Cc: Dmitry Osipenko
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +
1 file changed, 25
The DisplayID structure version and primary use case are stored in the
DisplayID Base Section. We should be checking them in a number of places
when parsing the DisplayID blocks. Currently, we completely ignore the
primary use case, and just look at the block tags without cross-checking
against
Avoid figuring out the header pointer multiple times.
Cc: Iaroslav Boliukin
Cc: Dmitry Osipenko
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c
Add a helper to get a pointer to struct displayid_header. To be
pedantic, add buffer overflow checks to not touch the base if that
itself would overflow.
Cc: Iaroslav Boliukin
Cc: Dmitry Osipenko
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 17 -
1 file
Mostly this is prep work and plumbing for easier use of displayid
structure version and primary use case for parsing the displayid blocks,
but it can be nicely used for figuring out non-desktop too.
Completely untested. :)
BR,
Jani.
Cc: Iaroslav Boliukin
Cc: Dmitry Osipenko
Jani Nikula (4):
On 2/16/23 15:15, Daniel Vetter wrote:
> On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote:
>> On 1/27/23 11:13, Gerd Hoffmann wrote:
>>> On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote:
Hello Thomas and Gerd,
On 1/9/23 00:04, Dmitry Osipenko wrote:
On Thu, Feb 16, 2023 at 01:49:23PM +0100, Daniel Vetter wrote:
> On Thu, 16 Feb 2023 at 13:47, Neil Armstrong
> wrote:
> >
> > On 16/02/2023 13:32, Daniel Vetter wrote:
> > > On Thu, 16 Feb 2023 at 12:59, Konrad Dybcio
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 19.01.2023 17:32, Konrad Dybcio
On Thu, Feb 16, 2023 at 01:32:22PM +0100, Daniel Vetter wrote:
> On Thu, 16 Feb 2023 at 12:59, Konrad Dybcio wrote:
> >
> >
> >
> > On 19.01.2023 17:32, Konrad Dybcio wrote:
> > > From: Konrad Dybcio
> > >
> > > Add support for the Sony TD4353 JDI 2160x1080 display panel used in
> > > some Sony
On Thu, Feb 16, 2023 at 05:27:28PM +0100, Thomas Hellström wrote:
> A slightly unusual cover letter for a single patch.
>
> The page table walker is currently used by the xe driver only,
> but the code is generic so we can be good citizens and add it to drm
> as a helper, for possible use by
On Thu, Feb 16, 2023 at 11:25:50AM -0800, Guenter Roeck wrote:
> On 2/16/23 10:57, Rodrigo Vivi wrote:
> > On Tue, Feb 14, 2023 at 07:11:16PM -0800, Dixit, Ashutosh wrote:
> > > On Mon, 13 Feb 2023 22:16:44 -0800, Guenter Roeck wrote:
> > > >
> > >
> > > Hi Guenter,
> > >
> > > > On 2/13/23
On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
> Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> calling fbdev implementation. Avoids a possible stale mutex with
> generic fbdev code.
>
> As indicated by its name, drm_fb_helper_prepare() prepares struct
>
On Thu, Feb 16, 2023 at 10:20 AM Rodrigo Vivi wrote:
>
> On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote:
> > On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
> > wrote:
> > >
> > > From: Tvrtko Ursulin
> > >
> > > In i915 we have this concept of "wait boosting" where we give a priority
On Thu, Feb 16, 2023 at 05:31:50PM +0100, Christian König wrote:
>
>
> Am 16.02.23 um 12:34 schrieb Daniel Vetter:
> > On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote:
> > > Am 09.02.23 um 14:06 schrieb Maíra Canal:
> > > > On 2/9/23 09:13, Christian König wrote:
> > > > > Am
On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2023, Stanislaw Gruszka
> wrote:
> > On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> >> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> >> > The mutex was completely pointless in the
On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2023, Christian König wrote:
> > Am 16.02.23 um 17:46 schrieb Jani Nikula:
> >> On Thu, 16 Feb 2023, Christian König wrote:
> >>> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
> On Thu, Feb 09, 2023 at 09:18:38AM
On Thu, Feb 16, 2023 at 01:09:45PM +, Simon Ser wrote:
> This is a bit tricky, because of the ref'counting considerations.
> See also [1] for more discussion about this topic. Since this is
> kernel docs, I've decided to elaborate a bit less on the user-space
> details.
>
> [1]:
On Thu, Feb 16, 2023 at 01:09:41PM +, Simon Ser wrote:
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> ---
> include/uapi/drm/drm.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/include/uapi/drm/drm.h
On 2/16/23 10:57, Rodrigo Vivi wrote:
On Tue, Feb 14, 2023 at 07:11:16PM -0800, Dixit, Ashutosh wrote:
On Mon, 13 Feb 2023 22:16:44 -0800, Guenter Roeck wrote:
Hi Guenter,
On 2/13/23 21:33, Ashutosh Dixit wrote:
On ATSM the PL1 power limit is disabled at power up. The previous uapi
On 2/16/23 21:26, Iaroslav Boliukin wrote:
> On 2/14/23 12:50, Dmitry Osipenko wrote:
>> On 2/13/23 14:50, Jani Nikula wrote:
>>> On Mon, 13 Feb 2023, Dmitry Osipenko
>>> wrote:
On 2/13/23 12:56, Jani Nikula wrote:
> On Sun, 12 Feb 2023, Dmitry Osipenko
> wrote:
>> Hi,
>>
On Tue, Feb 14, 2023 at 07:11:16PM -0800, Dixit, Ashutosh wrote:
> On Mon, 13 Feb 2023 22:16:44 -0800, Guenter Roeck wrote:
> >
>
> Hi Guenter,
>
> > On 2/13/23 21:33, Ashutosh Dixit wrote:
> > > On ATSM the PL1 power limit is disabled at power up. The previous uapi
> > > assumed that the PL1
On 2/14/23 12:50, Dmitry Osipenko wrote:
On 2/13/23 14:50, Jani Nikula wrote:
On Mon, 13 Feb 2023, Dmitry Osipenko wrote:
On 2/13/23 12:56, Jani Nikula wrote:
On Sun, 12 Feb 2023, Dmitry Osipenko wrote:
Hi,
On 1/18/22 20:00, Yaroslav Bolyukin wrote:
Add a brief commit message, describing
On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote:
> On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
> wrote:
> >
> > From: Tvrtko Ursulin
> >
> > In i915 we have this concept of "wait boosting" where we give a priority
> > boost
> > for instance to fences which are actively waited upon
On 1/17/23 6:57 AM, Peter Zijlstra wrote:
On Fri, Jan 13, 2023 at 12:30:16PM -0700, Jim Cromie wrote:
__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected. ISTM this overly harsh; it doesn't
distinguish between "alternate/opposite" state, and truly
Zhao Liu wrote:
> On Tue, Feb 14, 2023 at 08:25:08PM -0800, Ira Weiny wrote:
> > Date: Tue, 14 Feb 2023 20:25:08 -0800
> > From: Ira Weiny
> > Subject: Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with
> > kmap_local_page()
> >
> > Zhao Liu wrote:
> > > From: Zhao Liu
> > >
> > > The use
On Thu, Feb 16, 2023 at 02:21:43PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 16.02.23 um 13:52 schrieb Ville Syrjälä:
> > On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote:
> >> Hi,
> >>
> >> thanks for taking a look at the patches.
> >>
> >> Am 16.02.23 um 12:33 schrieb Gerd
On 2/16/23 02:50, Rob Clark wrote:
> From: Rob Clark
>
> The error path cleanup expects that chain and syncobj are either NULL or
> valid pointers. But post_deps was not allocated with __GFP_ZERO.
>
> Fixes: ab723b7a992a ("drm/msm: Add syncobj support.")
> Signed-off-by: Rob Clark
> ---
>
On Thu, 16 Feb 2023, Stanislaw Gruszka
wrote:
> On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
>> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
>> > The mutex was completely pointless in the first place since any
>> > parallel adding of files to this list would
On Thu, 16 Feb 2023, Christian König wrote:
> Am 16.02.23 um 17:46 schrieb Jani Nikula:
>> On Thu, 16 Feb 2023, Christian König wrote:
>>> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> The mutex was completely pointless in
Am 16.02.23 um 17:46 schrieb Jani Nikula:
On Thu, 16 Feb 2023, Christian König wrote:
Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
The mutex was completely pointless in the first place since any
parallel adding of files to this
Previous documentation suggested that the PL1 power limit is always enabled
in HW. However we now find this not to be the case on some platforms (such
as ATSM). Therefore enable the PL1 power limit (by setting the enable bit)
when writing the PL1 limit value to HW.
Bspec: 51864
Signed-off-by:
hwm_field_scale_and_write has a single caller hwm_power_write and is
specific to hwm_power_write but makes it appear that it is a general
function which can have multiple callers. Replace the function with
hwm_power_max_write which is specific to hwm_power_write and use that in
future patches
Previous PL1 power limit implementation assumed that the PL1 limit is
always enabled in HW. However we now find this not to be the case on ATSM
where the PL1 limit is disabled at power up. This requires changes in the
previous PL1 limit implementation.
v2: Dropping Patch 3 (since it is NAK'd by
On 06/02/2023 21:07, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Now as all accesses to pipe_cfg and pstate have been cleaned, re-add
struct dpu_hw_pipe_cfg back to dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to
On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > The mutex was completely pointless in the first place since any
> > parallel adding of files to this list would result in random
> > behavior since the list is
On Thu, 16 Feb 2023, Christian König wrote:
> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
>> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
>>> The mutex was completely pointless in the first place since any
>>> parallel adding of files to this list would result in random
>>>
On 16/02/2023 01:50, Rob Clark wrote:
From: Rob Clark
The error path cleanup expects that chain and syncobj are either NULL or
valid pointers. But post_deps was not allocated with __GFP_ZERO.
Fixes: ab723b7a992a ("drm/msm: Add syncobj support.")
Signed-off-by: Rob Clark
Reviewed-by:
On 16/02/2023 10:31, Marijn Suijten wrote:
On 2023-02-16 04:22:13, Dmitry Baryshkov wrote:
On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
wrote:
DPU's catalog never assigned dpu_scaler_blk::version leading to
initialization code in dpu_hw_setup_scaler3 to wander the wrong
codepaths. Instead
Am 16.02.23 um 12:34 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote:
Am 09.02.23 um 14:06 schrieb Maíra Canal:
On 2/9/23 09:13, Christian König wrote:
Am 09.02.23 um 12:23 schrieb Maíra Canal:
On 2/9/23 05:18, Christian König wrote:
Hello everyone,
Add a gpu page table walker similar in functionality to the cpu page-table
walker in mm/pagewalk.c. This is made a drm helper in the hope that it
might prove useful to other drivers, but we could of course make it
single-driver only and rename the functions initially.
Also if remaining a DRM
A slightly unusual cover letter for a single patch.
The page table walker is currently used by the xe driver only,
but the code is generic so we can be good citizens and add it to drm
as a helper, for possible use by other drivers,
If so we can merge the commit when we merge the xe driver.
The
Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple
On Thu, Feb 16, 2023 at 3:19 AM Tvrtko Ursulin
wrote:
>
>
> On 14/02/2023 19:14, Rob Clark wrote:
> > On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> In i915 we have this concept of "wait boosting" where we give a priority
> >> boost
> >> for
On Thu, Feb 16, 2023 at 09:21:23AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> As the logic for selecting the register and corresponsing values grew, the
> code become a bit unsightly. Consolidate by storing the required values at
> engine init time in the engine itself, and by doing
On Sun, Jan 8, 2023 at 1:13 PM Dmitry Osipenko
wrote:
>
> drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
> in the dma-buf shmem GEM object getting prematurely freed leading to a
> later use-after-free.
>
> Fixes: f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap
On 2/16/2023 7:18 AM, Jacek Lawrynowicz wrote:
Hi,
On 15.02.2023 16:41, Jeffrey Hugo wrote:
On 2/14/2023 4:08 AM, Jacek Lawrynowicz wrote:
Hi,
Thank you for the review.
On 06.02.2023 16:41, Jeffrey Hugo wrote:
The Qualcomm Cloud AI 100 (AIC100) device is an Artificial Intelligence
On Thu, Feb 16, 2023 at 04:21:48PM +0200, Oded Gabbay wrote:
> On Thu, Feb 16, 2023 at 2:25 PM Stanislaw Gruszka
> wrote:
> >
> > On Sun, Feb 12, 2023 at 10:44:35PM +0200, Oded Gabbay wrote:
> > > From: Tomer Tayar
> > >
> > > When user closes the device file descriptor, it is checked whether
On Thu, Feb 16, 2023 at 8:45 AM Orlando Chamberlain
wrote:
>
> Commit 3840c5bcc245 ("drm/amdgpu: disentangle runtime pm and
> vga_switcheroo") made amdgpu only register a vga_switcheroo client for
> GPU's with PX, however AMD GPUs in dual gpu Apple Macbooks do need to
> register, but don't have
From: Maarten Lankhorst
Use the generic suballocation helper.
Note that the generic suballocator only allows a single alignment,
so we may waste a few more bytes for radeon_semaphore, shouldn't
be a big deal, could be re-added if needed. Also, similar to amdgpu,
debug output changes slightly and
From: Maarten Lankhorst
Now that we have a generic suballocation helper, Use it in amdgpu.
The debug output is slightly different and suballocation may be
slightly more cpu-hungry.
Signed-off-by: Maarten Lankhorst
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
Initially we tried to leverage the amdgpu suballocation manager.
It turnes out, however, that it tries extremely hard not to enable
signalling on the fences that hold the memory up for freeing, which makes
it hard to understand and to fix potential issues with it.
So in a simplification effort,
This series (or at least the suballocator helper) is a prerequisite
for the new Xe driver.
A variant of the series has been on review before, making the
suballocator used by the amdgpu driver the generic one. However we
ran into a number of issues on Xe when using it for context-less
On Wed, Feb 15, 2023 at 6:38 AM Hans de Goede wrote:
>
> The parent for the backlight device should be the drm-connector object,
> not the PCI device.
>
> Userspace relies on this to be able to detect which backlight class device
> to use on hybrid gfx devices where there may be multiple native
On Mon, Feb 13, 2023 at 4:48 PM Tom Rix wrote:
>
> smatch reports
> drivers/accel/habanalabs/common/device.c:2619:6: warning:
> symbol 'hl_capture_hw_err' was not declared. Should it be static?
> drivers/accel/habanalabs/common/device.c:2641:6: warning:
> symbol 'hl_capture_fw_err' was not
On Mon, Feb 13, 2023 at 10:57 AM Colin Ian King wrote:
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/accel/habanalabs/common/command_submission.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Mon, Feb 13, 2023 at 9:12 AM Stanislaw Gruszka
wrote:
>
> On Wed, Feb 08, 2023 at 07:54:50AM -0800, Tom Rix wrote:
> > Building with clang W=2 has several similar warnings
> > drivers/accel/habanalabs/common/decoder.c:46:51: error: declaration shadows
> > a variable in the global scope
On Thu, Feb 16, 2023 at 02:26:50PM +, Tomer Tayar wrote:
> > This looks suspicious, I think hnode can be not-NULL here and has
> > hnode->vaddr different than searched addr, in case there is
> > hash collision and we iterate over hlist where there is no
> > searched addr. Not 100% sure about
On Sun, Feb 12, 2023 at 10:44:46PM +0200, Oded Gabbay wrote:
> From: Ofir Bitton
>
> In order for interrupt timestamp to be more accurate we should
> capture it during the interrupt handling rather than in threaded
> irq context.
Why this is important to have this timestamp more accurate ?
On Thu, Jan 26, 2023 at 03:30:31PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 26.01.23 um 11:28 schrieb Christian König:
> > We reference dump buffers both by their handle as well as their
> > object. The problem is now that when anybody iterates over the DRM
> > framebuffers and exports the
On Thu, Feb 16, 2023 at 03:47:44PM +0200, Oded Gabbay wrote:
> On Thu, Feb 16, 2023 at 12:28 PM Stanislaw Gruszka
> wrote:
> >
> > Hi
> >
> > On Sun, Feb 12, 2023 at 10:44:45PM +0200, Oded Gabbay wrote:
> >
> > > irqreturn_t hl_irq_handler_user_interrupt(int irq, void *arg)
> > > +{
> > > +
On Thu, Feb 16, 2023 at 13:48 Stanislaw Gruszka
wrote:
> > The same mutex lock/unlock and counter decrementing in
> > hl_release_dmabuf() is already done in the memhash_node_export_put()
> > helper function.
> >
> > Signed-off-by: Tomer Tayar
> > Reviewed-by: Oded Gabbay
> > Signed-off-by:
On Thu, Feb 16, 2023 at 12:53 PM Stanislaw Gruszka
wrote:
>
> On Sun, Feb 12, 2023 at 10:44:28PM +0200, Oded Gabbay wrote:
> > @@ -3178,11 +3181,12 @@ static int ts_buff_get_kernel_ts_record(struct
> > hl_mmap_mem_buf *buf,
> >
> > /* irq handling in the middle give it time
On Thu, Feb 16, 2023 at 2:25 PM Stanislaw Gruszka
wrote:
>
> On Sun, Feb 12, 2023 at 10:44:35PM +0200, Oded Gabbay wrote:
> > From: Tomer Tayar
> >
> > When user closes the device file descriptor, it is checked whether the
> > device is still in use, and a message is printed if it is.
>
> I
Hi Dave and Daniel,
Only 1 gen11 workaround fix.
Here goes drm-intel-fixes-2023-02-16:
- Moving gen11 hw wa to the right place. (Matt)
Thanks,
Rodrigo.
The following changes since commit ceaa837f96adb69c0df0397937cd74991d5d821a:
Linux 6.2-rc8 (2023-02-12 14:10:17 -0800)
are available in
1 - 100 of 169 matches
Mail list logo
