Hi, Yongqiang:
Yongqiang Niu 於 2021年5月1日 週六 上午11:13寫道：
>
> In cmdq mode, packet may be flushed before it is executed, so
> the pending flag should be cleared after cmdq packet is done.
>
> Signed-off-by: CK Hu
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 57
't need to care about which one (irq or
cmdq_cb) come first. Even though cmdq_cb come later, GCE would have
already write register in vblank.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20210430=368166ec7600ba83587cfcb31d817cf6479cf006
Regards,
Chun-Kuang.
On Fri, 30 Apr 2021 19:19:59 -0700, Umesh Nerlige Ramappa wrote:
>
> On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
> > On April 30, 2021 18:00:58 "Dixit, Ashutosh"
> > wrote:
> >
> > On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
> >
> > Looks
In cmdq mode, packet may be flushed before it is executed, so
the pending flag should be cleared after cmdq packet is done.
Signed-off-by: CK Hu
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 57 ++---
1 file changed, 52 insertions(+), 5
move page flip handle into cmdq cb
irq callback will before cmdq flush ddp register
into hardware, that will cause the display frame page
flip event before it realy display out time
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 46 ++---
base Linux 5.12-rc2
Change since v1:
- add none cmdq version for patch 1
- add one more patch to clear pending flag
Yongqiang Niu (2):
drm/mediatek: move page flip handle into cmdq cb
drm/mediatek: clear pending flag when cmdq packet is done.
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 103
On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
On April 30, 2021 18:00:58 "Dixit, Ashutosh"
wrote:
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
Looks like the engine can be dropped since all timestamps are in sync.
I
just have one
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue
with the same CU mask value used during CRIU dump.
Signed-off-by: David Yat Sin
Change-Id: I1822fa2488f90365dfe7a3c5971a2ed6c0046b4a
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 160 +--
From: David Yat Sin
When doing a restore on a different node, the gpu_id's on the restore
node may be different. But the user space application will still refer
use the original gpu_id's in the ioctl calls. Adding code to create a
gpu id mapping so that kfd can determine actual gpu_id during the
From: David Yat Sin
Dump contents of queue control stacks on CRIU dump and restore them
during CRIU restore.
(rajneesh: rebased to 5.11 and fixed merge conflict)
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: David Yat Sin
Change-Id: Ia1f38f3d4309e1f026981b16d26306672f3bf266
---
From: David Yat Sin
Add support to existing CRIU ioctl's to save and restore events during
criu checkpoint and restore.
Signed-off-by: David Yat Sin
Change-Id: I1635b1fa91a81abcbd19290cb88c8ca142c390e0
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 185 ---
From: David Yat Sin
Dump contents of queue MQD's on CRIU dump and restore them during CRIU
restore.
Signed-off-by: David Yat Sin
Change-Id: If54f892fb6cb8a5bde8a993891dad0dbb997c239
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 35 --
From: Rajneesh Bhardwaj
This reverts commit 12ebe2b9df192a2a8580cd9ee3e9940c116913c8.
This is just a temporary work around and will be dropped later.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same doorbell id value used during CRIU dump.
Signed-off-by: David Yat Sin
Change-Id: I6a79de1f8c760d5a9d28e7951740296f2f8796a7
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1 +
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same queue id value used during CRIU dump. Adding a new private
structure queue_restore_data to store queue restore information.
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: David Yat Sin
Change-Id:
From: David Yat Sin
Add support to existing CRIU ioctl's to save number of queues and queue
properties for each queue during checkpoint and re-create queues on restore.
Signed-off-by: David Yat Sin
Change-Id: Ifcd5e8359f492eef015867f354f44146dd1b6848
---
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same sdma id value used during CRIU dump.
Signed-off-by: David Yat Sin
Change-Id: I8ed667edb8b9b7b5089e59b78de9be80493a2808
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1 +
From: Rajneesh Bhardwaj
This adds support to create userptr BOs on restore and introduces a new
ioctl to restart memory notifiers for the restored userptr BOs.
When doing CRIU restore MMU notifications can happen anytime after we call
amdgpu_mn_register. Prevent MMU notifications until we reach
From: Rajneesh Bhardwaj
This implements the KFD CRIU Restore ioctl that lays the basic
foundation for the CRIU restore operation. It provides support to
create the buffer objects corresponding to Non-Paged system memory
mapped for GPU and/or CPU access and lays basic foundation for the
userptrs
From: Rajneesh Bhardwaj
This adds support to discover the buffer objects that belong to a
process being checkpointed. The data corresponding to these buffer
objects is returned to user space plugin running under criu master
context which then stores this info to recreate these buffer objects
From: Rajneesh Bhardwaj
This IOCTL is expected to be called as a precursor to the actual
Checkpoint operation. This does the basic discovery into the target
process seized by CRIU and relays the information to the userspace that
utilizes it to start the Checkpoint operation via another dedicated
From: Rajneesh Bhardwaj
Checkpoint-Restore in userspace (CRIU) is a powerful tool that can
snapshot a running process and later restore it on same or a remote
machine but expects the processes that have a device file (e.g. GPU)
associated with them, provide necessary driver support to assist
From: Rajneesh Bhardwaj
- Update debug config for Checkpoint-Restore (CR) support
- Also include necessary options for CR with docker containers.
Signed-off-by: Rajneesh Bhardwaj
Change-Id: Ie993f9b99553d46c48c60a5a1c054de0d923bc86
---
arch/x86/configs/rock-dbg_defconfig | 53
From: Rajneesh Bhardwaj
Update rock-rel_defconfig for monolithic kernel release that enables
CRIU support with kfd.
Signed-off-by: Rajneesh Bhardwaj
(cherry picked from commit 4a6d309a82648a23a4fc0add83013ac6db6187d5)
Change-Id: Ie6fe1e44285f4fccc17092baee664e8d784851fa
---
This patch series is a prototype for supporting CRIU for ROCm
applications. More work is needed before this can be upstreamed and
released, including a new ioctl API that is extensible without breaking
the ABI.
The user mode code to go with this can be found at
We have been working on a prototype supporting CRIU (Checkpoint/Restore
In Userspace) for accelerated compute applications running on AMD GPUs
using ROCm (Radeon Open Compute Platform). We're happy to finally share
this work publicly to solicit feedback and advice. The end-goal is to
get this work
On April 30, 2021 18:00:58 "Dixit, Ashutosh" wrote:
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
Looks like the engine can be dropped since all timestamps are in sync. I
just have one more question here. The timestamp itself is 36 bits. Should
the uapi also report the
On Fri, 30 Apr 2021 16:00:46 -0700, Dixit, Ashutosh wrote:
>
> On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
> >
> > Looks like the engine can be dropped since all timestamps are in sync. I
> > just have one more question here. The timestamp itself is 36 bits. Should
> > the
On 2021-04-30 12:30, Stephen Boyd wrote:
This patch series attempts to trim down the drm logging in the msm
driver to make it useable with DRM_UT_DRIVER, DRM_UT_KMS, and DRM_UT_DP
levels enabled. Right now the log is really spammy and prints multiple
lines for what feels like every frame. I
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
>
> Looks like the engine can be dropped since all timestamps are in sync. I
> just have one more question here. The timestamp itself is 36 bits. Should
> the uapi also report the timestamp width to the user OR should I just
>
[AMD Official Use Only - Internal Distribution Only]
I'll fix the dpcd part to use kHz on Monday
My apologies as well, not only for coming up with the wrong patch in first
place, but also for missing to CC all the maintainers.
-Original Message-
From: Lyude Paul
Sent: Friday, April
Alright - I had Ville double check this and give their A-B on IRC (I just need
to fix the open coded link_rate_to_bw() here). Since this got broken on drm-
misc-next I'm going to go ahead and push the fix there, since I'm not going to
be around next Monday or Tuesday and I don't want to leave i915
Noticed this while fixing another issue in drm_dp_read_downstream_info(),
the open coded DP_DOWNSTREAMPORT_PRESENT check here just duplicates what we
already do in drm_dp_is_branch(), so just get rid of it.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 4 +---
1 file changed,
While the DP specification isn't entirely clear on if this should be
allowed or not, some branch devices report having downstream ports present
while also reporting a downstream port count of 0. So to avoid breaking
those devices, we need to handle this in drm_dp_read_downstream_info().
So, to do
On Thu, Apr 29, 2021 at 02:07:58PM -0500, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 7:34 PM Umesh Nerlige Ramappa
wrote:
Perf measurements rely on CPU and engine timestamps to correlate
events of interest across these time domains. Current mechanisms get
these timestamps separately and
[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.
[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.
Fixes: 98025a62cb00 ("drm/dp_mst: Use
This is a follow-up change to fix incorrectly used max link rate source
capability at MST init time.
Change history:
v1:
- Initial
v2:
- Use local variabale for improved code readability
- Fix the comment to point to the correct sub-directory
Nikola Cornij (1):
drm/i915: Use the
Hi,
On Fri, Apr 30, 2021 at 8:10 AM wrote:
>
> On 30-04-2021 02:33, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Apr 29, 2021 at 11:04 AM Rob Herring wrote:
> >>
> >> On Mon, Apr 26, 2021 at 11:29:15AM +0530, Rajeev Nandan wrote:
> >> > Add bindings for DisplayPort aux backlight driver.
> >> >
On Fri, 2021-04-30 at 17:22 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e. it
> could be 0 if not not configured, leading to no MST on this platform.
>
> [how]
> Do not use the value from BIOS, but from the structure populated at
>
[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.
[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.
Fixes: 98025a62cb00 ("drm/dp_mst: Use
This is a follow-up change to fix incorrectly used max link rate source
capability at MST init time.
Change history:
v1:
- Initial
Nikola Cornij (1):
drm/dp_mst: Use the correct max source link rate for i915
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
1 file changed, 2
Hi,
On Thu, Apr 29, 2021 at 6:28 PM Linus Walleij wrote:
>
> On Fri, Apr 30, 2021 at 3:25 AM Doug Anderson wrote:
>
> > > I think pm_runtime_disable(); need to be added there?
> >
> > I'm a bit confused. You're saying that I need to add
> > pm_runtime_disable() to panel_simple_remove()? Doesn't
Quoting Maxime Ripard (2021-04-13 03:13:18)
> Hi,
>
> This is a follow-up of the discussion here:
> https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
>
> This implements a mechanism to raise and lower clock rates based on consumer
> workloads, with an example of such an
On Mon, 26 Apr 2021 15:18:10 +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds DT binding document for Richtek RT4831.
>
> Signed-off-by: ChiYuan Huang
> ---
> Resend this v6 patch series to loop devicetree reviewers.
> ---
> .../devicetree/bindings/mfd/richtek,rt4831.yaml| 90
>
On Mon, Apr 26, 2021 at 03:18:09PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Adds DT binding document for Richtek RT4831 backlight.
>
> Signed-off-by: ChiYuan Huang
> Reviewed-by: Daniel Thompson
> ---
> Resend this v6 patch series to loop devicetree reviewers.
>
> For next, need to
The pull request you sent on Fri, 30 Apr 2021 13:50:25 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-04-30
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/95275402f66e88c56144a2d859c13594b651b29b
Thank you!
--
Deet-doot-dot, I am a bot.
These prints flood the logs with drm debugging set to enable kms and
driver logging (DRM_UT_KMS and DRM_UT_DRIVER). Let's move these prints
to the atomic bucket (DRM_UT_ATOMIC) as they're related to the atomic
paths.
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Kuogee Hsieh
Cc:
Put these debug prints in the vblank code into the appropriate vblank
category via drm_dbg_vbl().
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Kuogee Hsieh
Cc: aravi...@codeaurora.org
Cc: Sean Paul
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
Use the DPU_DEBUG_PLANE() helper to print the plane number instead of
open coding it.
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Kuogee Hsieh
Cc: aravi...@codeaurora.org
Cc: Sean Paul
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 +++--
1 file
These messages are useful for bringup/early development but in
production they don't provide much value. We know what sort of GPU we
have and interrupt information can be gathered other ways. This cuts
down on lines in the drm debug logs that happen too often, making the
debug logs practically
These are verbose prints that tell us about the framebuffer state. Let's
move them to drm_dbg_state() so that they're only printed if we're
interested in verbose state logging while drm debugging.
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Kuogee Hsieh
Cc: aravi...@codeaurora.org
Cc: Sean Paul
This patch series attempts to trim down the drm logging in the msm
driver to make it useable with DRM_UT_DRIVER, DRM_UT_KMS, and DRM_UT_DP
levels enabled. Right now the log is really spammy and prints multiple
lines for what feels like every frame. I moved those prints off to
other DRM_UT_* levels
This print is missing a newline, and doesn't really provide any value.
Drop it.
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Cc: Kuogee Hsieh
Cc: aravi...@codeaurora.org
Cc: Sean Paul
Signed-off-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_panel.c | 1 -
1 file changed, 1 deletion(-)
diff
JFYI for anyone who is interested, I will be respinning my patches for adding
backlight helpers very soon since we've got pretty much all of the prep work
for it upstream now
On Mon, 2021-04-26 at 12:49 +0300, Jani Nikula wrote:
> On Mon, 26 Apr 2021, Rajeev Nandan wrote:
> > Add backlight
From: Tom Rix
Static analysis reports this problem
amdgpu_pm.c:478:16: warning: The right operand of '<' is a garbage value
for (i = 0; i < data.nums; i++) {
^ ~
In some cases data is not set. Initialize to 0 and flag not setting
data as an error with the existing
Hi Simon,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.12 next-20210430]
[If your patch is applied to the wrong git
Quoting Rob Clark (2021-04-30 10:17:39)
> From: Rob Clark
>
> dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> code path that ended up in dpu_plane_atomic_update(), even if the plane
> was not involved in the current atomic update. While a bit dubious,
> this worked before
On Fri, Apr 30, 2021 at 12:31:27AM +0800, kernel test robot wrote:
> Hi Bernard,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.12 next-20210429]
> [If your patch is applied to the wrong git tree,
On Fri, Apr 30, 2021 at 10:14 AM Rob Clark wrote:
>
> From: Rob Clark
>
> dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> code path that ended up in dpu_plane_atomic_update(), even if the plane
> was not involved in the current atomic update. While a bit dubious,
> this
On 2021-04-30 6:25 a.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 04:34:55PM -0400, Andrey Grodzovsky wrote:
On 2021-04-29 3:05 p.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:
On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
On Thu, Apr
From: Rob Clark
dpu_crtc_atomic_flush() was directly poking it's attached planes in a
code path that ended up in dpu_plane_atomic_update(), even if the plane
was not involved in the current atomic update. While a bit dubious,
this worked before because plane->state would always point to
On Fri, Apr 30, 2021 at 6:57 PM Jason Ekstrand wrote:
>
> On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter wrote:
> >
> > On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
> > >
> > > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 11:35 PM Jason
On 4/30/21 10:26, Deucher, Alexander wrote:
> [AMD Public Use]
>
> + Gustavo, amd-gfx
>
>> -Original Message-
>> From: Christian Zigotzky
>> Sent: Friday, April 30, 2021 8:00 AM
>> To: gustavo...@kernel.org; Deucher, Alexander
>>
>> Cc: R.T.Dickinson ; Darren Stevens > zone.net>;
On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter wrote:
>
> On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
> >
> > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> > >
> > > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > > wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 2:07 PM
On Thu, Apr 29, 2021 at 02:05:53PM +0200, Werner Sembach wrote:
> When encoder validation of a display mode fails, retry with less bandwidth
> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
> to support 4k60Hz output, which previously failed silently.
>
> AMDGPU had
On Thu, Apr 8, 2021 at 6:20 AM Maxime Ripard wrote:
>
> Hi Stephen,
>
> On Tue, Mar 30, 2021 at 11:56:15AM -0700, Stephen Boyd wrote:
> > Quoting Maxime Ripard (2021-03-30 08:35:27)
> > > Hi Stephen,
> > >
> > > On Mon, Mar 29, 2021 at 06:52:01PM -0700, Stephen Boyd wrote:
> > > > Trimming Cc
On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand wrote:
>
> On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
> >
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > wrote:
> > >
> > > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 02:01:16PM
On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter wrote:
>
> On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
> >
> > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> > >
> > > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > > On Thu, Apr 29, 2021 at 1:56 PM Daniel
On 2021-04-30 2:47 a.m., Christian König wrote:
Am 29.04.21 um 19:06 schrieb Andrey Grodzovsky:
On 2021-04-29 3:18 a.m., Christian König wrote:
I need to take another look at this part when I don't have a massive
headache any more.
Maybe split the patch set up into different parts,
On Fri, Apr 30, 2021 at 6:40 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 20:16, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
> > wrote:
> >> On 28/04/2021 18:09, Jason Ekstrand wrote:
> >>> On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
> >>> wrote:
> On
On Fri, Apr 30, 2021 at 6:18 AM Tvrtko Ursulin
wrote:
>
>
> On 29/04/2021 15:54, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 28/04/2021 18:24, Jason Ekstrand wrote:
> >>> On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
> >>> wrote:
>
On Fri, Apr 30, 2021 at 02:40:02PM +, Simon Ser wrote:
> Let the user know what went wrong in drm_gem_fb_init_with_funcs
> failure paths.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Noralf Trønnes
> Cc: Andrzej Pietrasiewicz
> ---
>
[AMD Public Use]
+ Gustavo, amd-gfx
> -Original Message-
> From: Christian Zigotzky
> Sent: Friday, April 30, 2021 8:00 AM
> To: gustavo...@kernel.org; Deucher, Alexander
>
> Cc: R.T.Dickinson ; Darren Stevens zone.net>; mad skateman ; linuxppc-dev
> ; Olof Johansson ;
> Maling
On 30-04-2021 02:33, Doug Anderson wrote:
Hi,
On Thu, Apr 29, 2021 at 11:04 AM Rob Herring wrote:
On Mon, Apr 26, 2021 at 11:29:15AM +0530, Rajeev Nandan wrote:
> Add bindings for DisplayPort aux backlight driver.
>
> Changes in v2:
> - New
>
> Signed-off-by: Rajeev Nandan
> ---
>
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Make sure to allocate a resource object here.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_sys_manager.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_sys_manager.c
>
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/nouveau/nouveau_mem.h | 1 +
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 4
> 2 files changed, 5 insertions(+)
>
> diff --git
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 51
> 1 file changed, 30 insertions(+), 21 deletions(-)
>
> diff --git
On 2021-04-30 4:40 p.m., Simon Ser wrote:
> Let the user know what went wrong in drm_gem_fb_init_with_funcs
> failure paths.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Noralf Trønnes
> Cc: Andrzej Pietrasiewicz
> ---
>
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Let the user know what went wrong in drm_gem_fb_init_with_funcs
failure paths.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Noralf Trønnes
Cc: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1
On Fri, Apr 30, 2021 at 3:27 PM Tvrtko Ursulin
wrote:
> On 30/04/2021 12:48, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> When a non-persistent context exits we currently mark it as banned in
> >> order to trigger
On Fri, Apr 30, 2021 at 3:32 PM Hans de Goede wrote:
>
> Hi,
>
> On 4/30/21 1:38 PM, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 4/29/21 9:09 PM, Daniel Vetter wrote:
> >>> On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine
p.s.
On 4/30/21 1:38 PM, Daniel Vetter wrote:
Offtopic:
> I'm also not sure why we have to use the kdev stuff here. For other
> random objects we need to look up we're building that functionality on
> that object. It means you need to keep another list_head around for
> that lookup, but that's
Hi,
On 4/30/21 1:38 PM, Daniel Vetter wrote:
> On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 4/29/21 9:09 PM, Daniel Vetter wrote:
>>> On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
Hi,
On 4/29/21 2:04 PM, Daniel Vetter wrote:
> On
On 30/04/2021 12:48, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Make sure to allocate a resource object here.
>
> Signed-off-by: Christian König
Ok, I guess I have to keep reading,
Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/ttm/ttm_sys_manager.c | 7 +++
> 1 file changed, 7 insertions(+)
On 30/04/2021 14:07, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
wrote:
On 30/04/2021 13:30, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Start with the range manager to make the resource object the base
> class for the allocated nodes.
>
> While at it cleanup a lot of the code around that.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |
On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
wrote:
>
>
>
> On 30/04/2021 13:30, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
> > wrote:
> >> On 30/04/2021 07:53, Daniel Vetter wrote:
> >>> On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> >>> wrote:
>
>
Am 30.04.21 um 14:05 schrieb Matthew Auld:
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
Init all fields in ttm_resource_alloc() when we create a new resource.
Signed-off-by: Christian König
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 --
On 30/04/2021 13:30, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 02:01:16PM
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
>
>
> On 30/04/2021 07:53, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand
> > wrote:
> >>
> >> On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
> >>>
> >>> On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason
Cc Robin & Joerg
Maxime Ripard 于2021年4月30日周五 下午5:22写道：
>
> On Sun, Apr 25, 2021 at 08:36:05PM +0800, Kevin Tang wrote:
> > Adds DPU(Display Processor Unit) support for the Unisoc's display
> > subsystem.
> > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
> >
> > v2:
On Fri, 30 Apr 2021 at 10:25, Christian König
wrote:
>
> Init all fields in ttm_resource_alloc() when we create a new resource.
>
> Signed-off-by: Christian König
> Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 --
> drivers/gpu/drm/ttm/ttm_bo.c| 26
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
On Thu, Apr 29,
On Thu, Apr 29, 2021 at 06:34:51PM +0100, Tvrtko Ursulin wrote:
>
> On 29/04/2021 17:31, Ville Syrjälä wrote:
> > On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > __i915_active_call annotation is required on the retire callback to ensure
> >
Even better :)
On Fri, Apr 30, 2021, 13:46 Liu Ying wrote:
> Hi Robert,
>
> On Fri, 2021-04-30 at 11:56 +0200, Robert Foss wrote:
> > Hey Liu,
> >
> > This patch does not apply on upstream-drm-misc/drm-misc-next. When it
> > passes local testing & building, I'm ready to merge it.
>
> I see Neil
On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When a non-persistent context exits we currently mark it as banned in
> order to trigger fast termination of any outstanding GPU jobs it may have
> left running.
>
> In doing so we apply a very strict 1ms
Hi Robert,
On Fri, 2021-04-30 at 11:56 +0200, Robert Foss wrote:
> Hey Liu,
>
> This patch does not apply on upstream-drm-misc/drm-misc-next. When it
> passes local testing & building, I'm ready to merge it.
I see Neil has already pushed this entire patch series to
drm-misc-next.
1 - 100 of 164 matches
Mail list logo
