On Tue, 18 Apr 2023, "Kandpal, Suraj" wrote:
> 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 clean
> -Original Message-
> From: Mark Yacoub
> Sent: Wednesday, April 12, 2023 12:52 AM
> To: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin ; David Airlie
> ; Daniel Vetter
> Cc: seanp...@chromium.org; Kandpal, Suraj ;
> diand...@chromium.org; dmitry.barysh...@linaro.o
>
> 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
>
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.
>
> Ac
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 suppor
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 dpu_hw
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.
Inst
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
---
drivers/gp
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 o
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 drivers/gpu/drm/msm/msm_gem.c
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 pr
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
> an
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_enco
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 registe
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
disable_tearcheck()
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 ++
.../drm/msm
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 --
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
drivers/gpu/drm/msm/
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 exist
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
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 Sui
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]
Sig
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 i
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 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
---
drivers/gpu/drm/msm
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 -
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 PPSPLIT
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
---
drivers/gpu/drm/ms
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
Reviewe
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 interrupt
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 case
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 ++---
drivers/gpu/drm/msm/ms
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 cr
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 star
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 0x
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 dpu_enco
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
UID:65qeuuc9e0gll25tq5
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
UID:65qeuuc9e0gll25tq
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,
On 17.04.2023 17:30, Konrad Dybcio wrote:
> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
> another path that needs to be handled to ensure MDSS functions properly,
> namely the "reg bus", a.k.a the CPU-MDSS interconnect.
>
> Gating that path may have a variety of effects.
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from none to otherwise
inexplicable DSI timeouts..
O
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from none to otherwise
inexplicable DSI timeouts..
O
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DISPLAY_CFG path, rename
the path-related struc
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DISPLAY_CFG path, rename
the path-related struc
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from none to otherwise
inexplicable DSI timeouts..
D
+), 28 deletions(-)
---
base-commit: d3f2cd24819158bb70701c3549e586f9df9cee67
change-id: 20230417-topic-dpu_regbus-abc94a770952
Best regards,
--
Konrad Dybcio
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, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin
wrote:
On 13/04/2023 21:05, Daniel Vetter wro
onfig-r015-20230417
(https://download.01.org/0day-ci/archive/20230417/202304172130.pxi8pggx-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
On Mon, Apr 17, 2023 at 9:43 AM 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, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin
> > >> 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, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin
> >> wrote:
> >>>
> >>>
> >>> On 13/04/2023 21:05, Daniel Vetter wrote:
> O
Hi Ricardo,
On Mon, Mar 13, 2023 at 04:22:54PM +0100, Ricardo Garcia wrote:
> This is a reminder that the deadline for new memberships and renewals
> finishes in a couple of weeks. Original email follows.
>
> Thanks for your attention.
I don't know if I'm the only one affected by this issue, but
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 conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as possible!
In ord
On 4/17/23 13:41, 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.
Forgot to mention, it will be in A Coruña, Spain :)
https://xdc2023.x.org
As usual, the conference is free of charge and ope
On 16/04/2023 08:48, Daniel Vetter wrote:
On Fri, Apr 14, 2023 at 06:40:27AM -0700, Rob Clark wrote:
On Fri, Apr 14, 2023 at 1:57 AM Tvrtko Ursulin
wrote:
On 13/04/2023 21:05, Daniel Vetter wrote:
On Thu, Apr 13, 2023 at 05:40:21PM +0100, Tvrtko Ursulin wrote:
On 13/04/2023 14:27, Danie
55 matches
Mail list logo
