Reviewed-by: Alan Previn
On Thu, 2023-02-02 at 17:10 -0800, Harrison, John C wrote:
> 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 comb
I see you are inferring that a guc-id of zero can be valid.
I am guessing that might have contributed to some lost captures?
Thanks for catching this.
Reviewed-by: Alan Previn
On Thu, 2023-02-02 at 17:10 -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The comparison in the se
On 2/3/23 19:34, Ville Syrjälä wrote:
On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote:
On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
On 2/3/23 11:00, Ville Syrjälä wrote:
On Fri, Feb 03, 2023 a
MESA driver is creating protected context on every driver handle
creation to query caps bits for app. So when running CI tests,
they are observing hundreds of drm_errors when enabling PXP
in .config but using SOC fusing or BIOS configuration that cannot
support PXP sessions.
The fixes tag referenc
On 2/3/2023 8:10 PM, Dmitry Baryshkov wrote:
On 04/02/2023 04:43, Abhinav Kumar wrote:
On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->ca
On 04/02/2023 04:43, Abhinav Kumar wrote:
On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the sup
The path for the "mod_info_packet.h" header file is
incomplete, so add its location to the header search path
in the amdgpu Makefile.
See on ARCH=alpha (275 times in one build).
In file included from ../drivers/gpu/drm/amd/amdgpu/amdgpu.h:90,
from ../drivers/gpu/drm/amd/amdgpu/am
On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver d
On 04/02/2023 01:35, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not
On 2/3/23 18:27, Lucas Stach wrote:
> Thanks, I've added this to the etnaviv tree.
>
> Since the commit is only in -next and not a non-rebase tree yet, I
> might be tempted to squash the fix into the offending commit. What
> would be the right way to credit you for the fix in that case?
>
On SoB
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enbaling setup_multirect callback. Add cor
On 04/02/2023 01:07, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
Noth
From: Bjorn Helgaas
This reverts commit 145eed48de278007f646b908fd70ac59d24ed81a.
Zeno Davatz reported that 145eed48de27 ("fbdev: Remove conflicting devices
on PCI bus") caused a console hang. The machine was actually still usable
via ssh, etc., but there was no activity on the console.
Revert
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
Nothing wrong with the change as such but why
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Signed-
On 04/02/2023 00:44, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/di
Hi Dave, Daniel,
More stuff for 6.3. Mostly bug fixes.
The following changes since commit aebd8f0c6f8280ba35bc989f4a9ea47469d3589a:
Merge v6.2-rc6 into drm-next (2023-01-31 12:23:23 +0100)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Signed
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
Now with the prev change, this is
Reviewed-by: Abhinav Kumar
--
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Signed-off-by: Dmitry Baryshkov
I am yet to confirm with HW team if programming 0 stride and 0 address
is absolutely
On 2/3/23 14:34, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote:
>> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
>>> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
On 2/3/23 11:00, Ville Syrjälä wrote:
>
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
LGTM now,
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.
On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
> > >
> > >
> > > On 2/3/23 11:00, Ville Syrjälä wrote:
> > > > On Fri, Feb 03, 2023 at 10:24:52AM -0
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be
On 2/3/23 14:25, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
>> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>>>
>>>
>>> On 2/3/23 11:00, Ville Syrjälä wrote:
On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>
>
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Signed-off-by: Dmitry Baryshkov
The macro definition of gen6_for_all_pdes() expands to a for loop such
that it breaks when the page table is null. Hence there is no need to
again test validity of the page table entry pointers in the pde list.
This change is identified using itnull.cocci semantic patch.
Signed-off-by: Deepak R Va
On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
> >
> >
> > On 2/3/23 11:00, Ville Syrjälä wrote:
> > > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> > >>
> > >>
> > >> On 2/3/23 10:19, Ville Syrj
On Wed, 18 Jan 2023 05:17:15 +0200, Dmitry Baryshkov wrote:
> Add qcom,sc8280xp-edp to the list of eDP devices, unblocking `aux-bus'
> property and fobidding `#sound-dai-cells' property. Also since
> sc8280xp-edp, overriding sc8280xp-dp, will contain 5 reg resources, drop
> the reg contraint (as
On Wed, 18 Jan 2023 05:20:24 +0200, Dmitry Baryshkov wrote:
> Add the per-SoC (qcom,sm8350-dsi-ctrl) compatible strings to DSI nodes
> to follow the pending DSI bindings changes.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sm8350: use qcom,sm8350-dsi-ctrl compatibles
commit: d7133d6d25
On 2/3/23 13:56, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>>
>>
>> On 2/3/23 11:00, Ville Syrjälä wrote:
>>> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
On 2/3/23 10:19, Ville Syrjälä wrote:
> On Fri, Feb 03, 20
On 2/3/23 19:21, Rob Herring wrote:
> On Thu, Dec 22, 2022 at 03:22:14PM +0100, Johan Jonker wrote:
>> Convert rockchip-lvds.txt to YAML.
>>
>> Changed:
>> Add power-domains property.
>> Requirements between PX30 and RK3288
>>
>> Signed-off-by: Johan Jonker
>> Reviewed-by: Rob Herring
>> -
Hi Lucas,
On 2/3/2023 7:56 PM, Lucas De Marchi wrote:
On Thu, Feb 02, 2023 at 07:02:43PM +0100, Nirmoy Das wrote:
DSM granularity is 1MB so make sure we stick to that.
I think we need to be a bit more verbose here, because in future we may
need to refer to this commit if/when things change (e
On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote:
>
>
> On 2/3/23 11:00, Ville Syrjälä wrote:
> > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
> >>
> >>
> >> On 2/3/23 10:19, Ville Syrjälä wrote:
> >>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote
On Thu, Feb 02, 2023 at 07:02:43PM +0100, Nirmoy Das wrote:
DSM granularity is 1MB so make sure we stick to that.
I think we need to be a bit more verbose here, because in future we may
need to refer to this commit if/when things change (e.g. the granularity
or the additional size needed on top
On Fri, Feb 03, 2023 at 10:03:49AM -0800, Lucas De Marchi wrote:
> On Thu, Feb 02, 2023 at 05:12:10PM -0800, Matt Roper wrote:
> > On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
> > > Register 0x9424 is not replicated on any platform, so it shouldn't be
> > > declared with REG_MCR
The pull request you sent on Fri, 3 Feb 2023 13:59:18 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-02-03
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bffede38f82c27cf5e203a2c659fcc9b581dd7b8
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On 2/3/23 11:00, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>>
>>
>> On 2/3/23 10:19, Ville Syrjälä wrote:
>>> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
On 2/3/23 07:59, Sebastian Wick wrote:
> On Fri, Feb 3, 20
On 03/02/2023 20:21, Dmitry Baryshkov wrote:
The review of the first half of v2 took more than a month. Let's update
the reviewed patches in attempt to get the first half of the series into
the acked and mergeable state. This would allow us to lower the impact
(and the patch count). At 27 patches
Rework the code flushing CSC settings for the plane. Separate out the
pipe and pipe_cfg as a preparation for r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +--
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a
Typically SSPP can support rectangle with width up to 2560. However it's
possible to use multirect feature and split source to use the SSPP to
output two consecutive rectangles. This commit brings in this capability
to support wider screen resolutions.
Signed-off-by: Dmitry Baryshkov
---
drivers
Rework static color fill code to separate the pipe / pipe_cfg handling.
This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 70 +--
1 file changed, 41 insertions(+), 29 deletions(-)
diff --git a/driver
Rework _dpu_crtc_blend_setup_mixer() to split away pipe handling to a
separate functon. This is a preparation for the r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 86 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 10 ++-
2
Split pipe-dependent code from dpu_plane_sspp_atomic_update() into the
separate function dpu_plane_sspp_update_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 113 --
1 file chan
Split pipe-dependent code from dpu_plane_atomic_check() into the
separate function dpu_plane_atomic_check_pipe(). This is one of
preparational steps to add r_pipe support.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 88 ++-
1 file changed,
Since the driver uses clipped src coordinates, there is no need to check
against the fb coordinates. Remove corresponding checks and inline
dpu_plane_validate_src().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 30 ---
1 file changed, 10 ins
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 disagree about src/dst rectangles (currently
dpu_plane_atomic_check() uses unclipped rectangles
Rework bandwidth/clock calculation functions to use mode directly rather
than fetching it through the plane data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 39 ++-
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/gp
Neither source split nor multirect are properly supported at this
moment. Both of these checks depend on normalized_zpos being equal for
several planes (which is never the case for normalized zpos).
Drop these checks to simplify dpu_crtc_atomic_check(). The actual
support for either of these featur
Move plane state updates from dpu_crtc_atomic_check() to the function
where they belong: to dpu_plane_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 18 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 18 ++
drivers/
Remove dpu_hw_fmt_layout instance from struct dpu_hw_sspp_cfg, leaving
only src_rect and dst_rect. This way all the pipes used by the plane
will have a common layout instance (as the framebuffer is shared between
them), while still keeping a separate src/dst rectangle configuration
for each pipe.
Downstream driver uses dpu->caps->smart_dma_rev to update
sspp->cap->features with the bit corresponding to the supported SmartDMA
version. Upstream driver does not do this, resulting in SSPP subdriver
not enbaling setup_multirect callback. Add corresponding SmartDMA SSPP
feature bits to dpu hw cat
Rewrite dpu_plane's QoS related functions to take struct dpu_sw_pipe and
struct dpu_format as arguments rather than fetching them from the
pstate or drm_framebuffer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 98 +++
1 file changed, 47 ins
The dpu_crtc_atomic_check() compares blending stage with DPU_STAGE_MAX
(maximum amount of blending stages supported by the driver), however we
should compare it against .max_mixer_blendstages, the maximum blend
stage supported by the mixer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
1 file changed, 29 insertions(+), 28 deleti
Where feasible, use dpu_sw_pipe rather than a combo of dpu_hw_sspp and
multirect_index/_mode arguments.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 59 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 46 +--
The helper drm_atomic_helper_check_plane_state() already checks whether
the scaled and clipped plane falls into the CRTC visible region (and
clears plane_state->visible if it doesn't). Drop the redundant check
from dpu_crtc_atomic_check().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/
Set SSPP_SRCn_ADDR registers to 0 while setting up solid fill, as we can
not be sure that the previous address is still valid.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dp
There is no need to pass full dpu_hw_sspp_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 9 -
drivers/gpu/drm/msm
Wrap SSPP and multirect index/mode into a single structure that
represents software view on the pipe used.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 16 ++-
drivers/gpu/drm/
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
drivers/gpu/drm/msm/di
The pipe's layout is not cached, corresponding data structure is zeroed
out each time in the dpu_plane_sspp_atomic_update(), right before the
call to _dpu_plane_set_scanout() -> dpu_format_populate_layout().
Drop plane_addr comparison against previous layout and corresponding
EAGAIN handling.
Rev
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (variable, changes during runtime) rather
than part of a plane (ideally should be statically allocated during boot).
The sspp point
Follow the example of all other hw blocks and initialize SSPP blocks in
Resource Manager.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 22 ++
drive
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms. We are going to break
the 1:1 correspondence between planes and SSPPs, so it makes no sense
anymore to create SSPP debugfs entries in dpu_plane.c
Reviewed-by: Abhinav Kumar
Signed
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Also rename struct dpu_hw_pipe_cfg to dpu_hw_sspp_cfg to follow this
change.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
The review of the first half of v2 took more than a month. Let's update
the reviewed patches in attempt to get the first half of the series into
the acked and mergeable state. This would allow us to lower the impact
(and the patch count). At 27 patches this series is approaching the
limits of manag
On Thu, Dec 22, 2022 at 03:22:14PM +0100, Johan Jonker wrote:
> Convert rockchip-lvds.txt to YAML.
>
> Changed:
> Add power-domains property.
> Requirements between PX30 and RK3288
>
> Signed-off-by: Johan Jonker
> Reviewed-by: Rob Herring
> ---
>
> Changed V3:
> Filename matching compat
On Fri, Feb 3, 2023 at 8:49 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Because eb_composite_fence_create() drops the fence_array reference
> after creation of the sync_file, only the sync_file holds a ref to the
> fence. But fd_install() makes that reference visable to userspace, so
> it must b
When any of the components in the mdss hierarchy fails to bind,
previously bound components are being unbound again.
One such case happens when the DP controller fails to find its bridge or
panel, where adreno_unbind() will be invoked without adreno_load_gpu()
being called to invoke pm_runtime_ena
From: Rob Clark
If userspace calls the AMDGPU_CS ioctl from multiple threads, because
the vm is global to the drm_file, you can end up with multiple threads
racing in amdgpu_vm_clear_freed(). So the freed list should be
protected with the status_lock, similar to other vm lists.
Fixes: d38ceaf99
On Thu, Feb 02, 2023 at 05:12:10PM -0800, Matt Roper wrote:
On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
Register 0x9424 is not replicated on any platform, so it shouldn't be
declared with REG_MCR(). Declaring it with _MMIO() is basically
duplicate of the GEN7 version, so jus
On Thu, 2023-02-02 at 19:27 -0600, Gustavo A. R. Silva 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 struct vmw_view.
>
> This helps with the ongoing efforts to tighten the
> > > +struct drm_pancsf_gpu_info {
> > > +#define DRM_PANCSF_ARCH_MAJOR(x) ((x) >> 28)
> > > +#define DRM_PANCSF_ARCH_MINOR(x) (((x) >> 24) & 0xf)
> > > +#define DRM_PANCSF_ARCH_REV(x) (((x) >> 20) & 0xf)
> > > +#define DRM_PANCSF_PRODUCT_MAJOR(x) (((
On Thu, Feb 02, 2023 at 07:27:10PM -0600, Gustavo A. R. Silva 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 struct vmw_view.
>
> This helps with the ongoing efforts to tight
On 2/3/2023 6:09 AM, Dmitry Baryshkov wrote:
On 02/02/2023 22:14, Abhinav Kumar wrote:
On 2/2/2023 12:10 PM, Dmitry Baryshkov wrote:
On 02/02/2023 21:54, Abhinav Kumar wrote:
On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote:
On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar
wrote:
On 12/29/2
On 2/3/2023 01:54, Michal Wajdeczko wrote:
On 03.02.2023 01:11, john.c.harri...@intel.com wrote:
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 35 ++-
..
On Wed, Jan 18, 2023 at 07:12:45AM +0100, Danilo Krummrich wrote:
> This adds the infrastructure for a manager implementation to keep track
> of GPU virtual address (VA) mappings.
>
> New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
> start implementing, allow userspace appli
On 2/3/2023 6:16 AM, Dmitry Baryshkov wrote:
On 28/01/2023 01:59, Abhinav Kumar wrote:
On 1/26/2023 10:05 PM, Dmitry Baryshkov wrote:
On Fri, 27 Jan 2023 at 02:52, Abhinav Kumar
wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
The pipe's layout is not cached, corresponding data
Hi Steven,
On Fri, 3 Feb 2023 15:41:38 +
Steven Price wrote:
> Hi Boris,
>
> Thanks for the post - it's great to see the progress!
Thanks for chiming in!
>
> On 01/02/2023 08:48, Boris Brezillon wrote:
> > Mali v10 (second Valhal iteration) and later GPUs replaced the Job
> > Manager blo
Hi,
On 2023-02-03 14:09, Sascha Hauer wrote:
> Hi,
>
> On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote:
>> hi,
>>
>> I'm trying this patch series with 6.1.x kernel. it works fine on rk356x
>> based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4).
>>
>> on rk3399 with
From: Rob Clark
Because eb_composite_fence_create() drops the fence_array reference
after creation of the sync_file, only the sync_file holds a ref to the
fence. But fd_install() makes that reference visable to userspace, so
it must be the last thing we do with the fence.
Signed-off-by: Rob Cla
On 03/02/2023 16:29, Alyssa Rosenzweig wrote:
>>> Mali v10 (second Valhal iteration) and later GPUs replaced the Job
>>> Manager block by a command stream based interface called CSF (for
>>> Command Stream Frontend). This interface is not only turning the job
>>> chain based submission model into a
> > Mali v10 (second Valhal iteration) and later GPUs replaced the Job
> > Manager block by a command stream based interface called CSF (for
> > Command Stream Frontend). This interface is not only turning the job
> > chain based submission model into a command stream based one, but also
> > introd
On 2/3/23 10:43, Hamza Mahfooz wrote:
Currently, it is likely that we will read the relevant LTTPR caps after
link training has completed (which can cause garbage data to be read),
however according to the DP 2.0 spec that should be done before link
training has commenced. So, instead of reading
Hi Randy,
On Fri, Feb 3, 2023 at 4:57 PM Randy Dunlap wrote:
> Is this "sh64" still accurate and applicable? from
> Documentation/kbuild/kbuild.rst:
>
> But some architectures such as x86 and sparc have aliases.
>
> - x86: i386 for 32 bit, x86_64 for 64 bit
> - sh: sh for 32 bit, sh64 for 64 bit
On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote:
>
>
> On 2/3/23 10:19, Ville Syrjälä wrote:
> > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
> >>
> >>
> >> On 2/3/23 07:59, Sebastian Wick wrote:
> >>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> >>> wrote:
>
Hi--
On 2/3/23 02:33, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz
> wrote:
>> On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote:
>>> On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote:
Since this is my
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
initialization.
Bspec: 51864
v2: Add Bspec reference (Gwan-gyeong)
v3: Add Fixes tag
Fixes: 99f55ef
Currently, it is likely that we will read the relevant LTTPR caps after
link training has completed (which can cause garbage data to be read),
however according to the DP 2.0 spec that should be done before link
training has commenced. So, instead of reading the registers on demand,
use the values
Hi Boris,
Thanks for the post - it's great to see the progress!
On 01/02/2023 08:48, Boris Brezillon wrote:
> Mali v10 (second Valhal iteration) and later GPUs replaced the Job
> Manager block by a command stream based interface called CSF (for
> Command Stream Frontend). This interface is not on
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Add support for the DSS controller on TI's new AM625 SoC in the tidss
driver.
The first video port (VP0) in am625-dss can output OLDI signals through
2 OLDI TXes. A 3rd output port has been added with "DISPC_PORT_OLDI" bus
type.
Not a big thing here a
On 2/3/23 10:19, Ville Syrjälä wrote:
> On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
>>
>>
>> On 2/3/23 07:59, Sebastian Wick wrote:
>>> On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
>>> wrote:
On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
> Use
On 25/01/2023 13:35, Aradhya Bhatia wrote:
The ctrl mmr module of the AM625 is different from the AM65X SoC. Thus
the ctrl mmr registers that supported the OLDI TX power have become
different in AM625 SoC.
The common mode voltage of the LVDS buffers becomes random when the
bandgap reference is t
On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote:
>
>
> On 2/3/23 07:59, Sebastian Wick wrote:
> > On Fri, Feb 3, 2023 at 11:40 AM Ville Syrjälä
> > wrote:
> >>
> >> On Fri, Feb 03, 2023 at 02:07:44AM +, Joshua Ashton wrote:
> >>> Userspace has no way of controlling or knowing
On 25/01/2023 13:35, Aradhya Bhatia wrote:
The newer version of DSS (AM625-DSS) has 2 OLDI TXes at its disposal.
These can be configured to support the following modes:
1. OLDI_SINGLE_LINK_SINGLE_MODE
Single Output over OLDI 0.
+--++-+ +---+
| ||
On Fri, Feb 03, 2023 at 11:34:02AM +0200, Jani Nikula wrote:
> On Wed, 25 Jan 2023, Jim Cromie wrote:
> > Hi everyone,
> >
> > In v6.1 DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in
> > drivers at modprobe.
>
> I realize we haven't actually addressed the regression in any way yet,
On 2/3/2023 1:05 AM, Jacek Lawrynowicz wrote:
Hi,
On 02.02.2023 16:04, Jeffrey Hugo wrote:
On 2/2/2023 2:21 AM, Stanislaw Gruszka wrote:
From: Andrzej Kacprowski
FW API structures have been updated to fix misaligned
structure members.
Also changed JSM message header format to account for
fu
On 2/2/23 21:07, Joshua Ashton wrote:
> Userspace has no way of controlling or knowing the pixel encoding
> currently, so there is no way for it to ever get the right values here.
>
> When we do add pixel_encoding control from userspace,we can pick the
> right value for the colorimetry packet b
1 - 100 of 160 matches
Mail list logo
