Hi,
> for (pgidx = 0; pgidx < pgcnt; pgidx++) {
> + if (is_file_hugepages(memfd)) {
> + hpage = find_get_page_flags(
> + file_inode(memfd)->i_mapping,
> +
On Thu., Jun. 3, 2021, 15:18 Daniel Vetter, wrote:
> On Thu, Jun 3, 2021 at 7:53 PM Marek Olšák wrote:
> >
> > Daniel, I think what you are suggesting is that we need to enable user
> queues with the drm scheduler and dma_fence first, and once that works, we
> can investigate how much of that
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva
---
JFYI: We had thousands of these sorts
Hi, Bjorn,
On Thu, Jun 3, 2021 at 2:31 AM Bjorn Helgaas wrote:
>
> [+cc linux-pci]
>
> On Wed, Jun 2, 2021 at 11:22 AM Daniel Vetter wrote:
> > On Wed, Jun 02, 2021 at 06:36:03PM +0800, Huacai Chen wrote:
> > > On Wed, Jun 2, 2021 at 2:03 AM Daniel Vetter wrote:
> > > > On Tue, Jun 01, 2021 at
Hi all,
If you don't mind, I'm taking this in my -next[1] branch for v5.14.
Thanks
--
Gustavo
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/log/?h=for-next/kspp
On 6/1/21 17:57, Gustavo A. R. Silva wrote:
> Hi,
>
> Friendly second ping: who can take this?
>
> I
On 6/1/21 19:10, Karol Herbst wrote:
> all three nouveau patches are
>
> Reviewed-by: Karol Herbst
>
> and I don't think anybody would mind if those get into through other
> trees, but maybe drm-mist would be a good place for it if other
> patches involve other drm drivers?
No other person
Hi all,
If you don't mind, I'm taking this in my -next[1] branch for v5.14.
Thanks
--
Gustavo
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/log/?h=for-next/kspp
On 6/1/21 17:58, Gustavo A. R. Silva wrote:
> Hi,
>
> Friendly second ping: who can take this?
>
> I
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.13-rc4
next-20210603]
[cannot apply to drm/drm-next
From: lijian
Macros with complex values should be enclosed in parentheses，
so Added parentheses for the macro 'MAX_N'.
Signed-off-by: lijian
---
drivers/video/fbdev/aty/mach64_gx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/mach64_gx.c
From: lijian
Removed unnecessary 'return' in void functions.
Signed-off-by: lijian
---
drivers/video/fbdev/aty/mach64_gx.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/video/fbdev/aty/mach64_gx.c
b/drivers/video/fbdev/aty/mach64_gx.c
index 9c37e28fb78b..9619661b7843
On 2021-06-03 10:53 p.m., Alex Deucher wrote:
On Thu, Jun 3, 2021 at 9:37 PM Dave Airlie wrote:
On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote:
Please open a gitlab MR for these.
I'd really prefer these tests all get migrated out of here into igt. I
don't think libdrm_amdgpu really
On Wed, Jun 02, 2021 at 03:33:43PM +0100, Tvrtko Ursulin wrote:
>
> On 06/05/2021 20:14, Matthew Brost wrote:
> > Reset implementation for new GuC interface. This is the legacy reset
> > implementation which is called when the i915 owns the engine hang check.
> > Future patches will offload the
From: lijian
Removed unnecessary 'return' in void function uvesafb_vbe_getmonspecs()
and uvesafb_cn_callback().
Signed-off-by: lijian
---
drivers/video/fbdev/uvesafb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index
From: lijian
Removed unnecessary 'return' in void function init_vgachip().
Signed-off-by: lijian
---
drivers/video/fbdev/cirrusfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
index 93802abbbc72..e726e7ac3eeb 100644
---
From: lijian
Removed unnecessary 'return' in void function hvfb_get_option().
Signed-off-by: lijian
---
drivers/video/fbdev/hyperv_fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 23999df52739..c8e57a513896 100644
On Thu, Jun 3, 2021 at 9:37 PM Dave Airlie wrote:
>
> On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote:
> >
> > Please open a gitlab MR for these.
> >
>
> I'd really prefer these tests all get migrated out of here into igt. I
> don't think libdrm_amdgpu really should have tests that test the
>
From: lijian
Removed unnecessary 'return' in void functions.
Signed-off-by: lijian
---
drivers/video/fbdev/cyber2000fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index d45355b9a58c..ee17e7fa8f4b 100644
---
Hi all,
On Thu, 3 Jun 2021 12:48:47 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the amdgpu tree got conflicts in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>
> between commit:
>
> d3116756a710 ("drm/ttm: rename bo->mem and
On Wed, Jun 2, 2021 at 4:01 AM Vinod Koul wrote:
>
> On 27-05-21, 16:30, Rob Clark wrote:
> > On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo
> > wrote:
> > > On Tue, May 25, 2021 at 11:46 PM Vinod Koul wrote:
>
> > > Frankly, I don't like the MSM ACPI solution that I've seen on the laptops.
> >
Code review happens on gitlab now for libdrm.
Alex
On Thu, Jun 3, 2021 at 6:02 PM Grodzovsky, Andrey
wrote:
>
> Is libdrm on gitlab ? I wasn't aware of this. I assumed code reviews still go
> through dri-devel.
>
> Andrey
>
>
> From: Alex Deucher
> Sent: 03
On Thu, Jun 03, 2021 at 11:35:28PM +0200, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 10:16:18PM -0700, Matthew Brost wrote:
> > From: Michal Wajdeczko
> >
> > Generic helpers should be placed in i915_utils.h.
>
> Random rant, but we're _way_ too happy to just stuff random things into
>
Hey Linus,
Two big regression reverts in here, one for fbdev and one i915.
Otherwise it's mostly amdgpu display fixes, and tegra fixes.
Seems about right for rc5.
Dave.
drm-fixes-2021-06-04-1:
drm fixes for 5.13-rc5
fb:
- revert broken fb_defio patch
amdgpu:
- Display fixes
- FRU EEPROM
https://bugzilla.kernel.org/show_bug.cgi?id=213321
--- Comment #5 from Sujay1844 (sujay1...@protonmail.com) ---
K that guy says, it'll be fixed by 5.14
When will that be released??
I heard that 5.14 will be having support for the new Alder Lake M CPUs from
Intel. So I think, we can expect 5.14 to
VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
pl111 is modular. Update the Kconfig to reflect the need.
Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
Signed-off-by: Kees Cook
---
v2: use expected Kconfig style to express this. :)
v1:
On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote:
>
> Please open a gitlab MR for these.
>
I'd really prefer these tests all get migrated out of here into igt. I
don't think libdrm_amdgpu really should have tests that test the
kernel level infrastructure.
I know some people at AMD had issues in
On Fri, Jun 04, 2021 at 12:30:00AM +0200, Daniel Vetter wrote:
> [gmail is funny]
>
> On Thu, Jun 3, 2021 at 11:58 PM Kees Cook wrote:
> >
> > VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
> > pl111 is modular. Update the Kconfig to reflect the need.
> >
> > Cc: Emma
On Friday, 4 June 2021 12:47:40 AM AEST Peter Xu wrote:
> External email: Use caution opening links or attachments
>
> On Thu, Jun 03, 2021 at 09:39:32PM +1000, Alistair Popple wrote:
> > Reclaim won't run on the page due to the extra references from the special
> > swap entries.
>
> That sounds
On 02/06/2021 17:32, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/dp/dp_link.c:374: warning: expecting prototype for
dp_parse_video_pattern_params(). Prototype was for
dp_link_parse_video_pattern_params() instead
On 02/06/2021 17:32, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/msm_gem.c:364: warning: This comment starts with '/**',
but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/msm/msm_gem.c:763: warning: This
If the VMM's (Qemu) memory backend is backed up by memfd + Hugepages
(hugetlbfs and not THP), we have to first find the hugepage(s) where
the Guest allocations are located and then extract the regular 4k
sized subpages from them.
v2: Ensure that the subpage offsets are calculated correctly when
Normal DP suspend operation contains two steps, display off followed
by dp suspend, to complete system wide suspending cycle if display is
up at that time. In this case, DP phy will be powered off at display
off. However there is an exception case that depending on the timing
of dongle plug in
On 2021-06-02 04:01, Vinod Koul wrote:
On 27-05-21, 16:30, Rob Clark wrote:
On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo
wrote:
> On Tue, May 25, 2021 at 11:46 PM Vinod Koul wrote:
> Frankly, I don't like the MSM ACPI solution that I've seen on the laptops.
> The ACPI assumes the entire
https://bugzilla.kernel.org/show_bug.cgi?id=21
Bug ID: 21
Summary: Regression: amdgpu_gfxhub raises protection fault,
crashes display
Product: Drivers
Version: 2.5
Kernel Version: 5.13.0-rc4
Hardware: x86-64
Failing to read the MTP over DSI should not bring down the
system and make us bail out from using the display, it turns
out that this happens when toggling the display off and on,
and that write is often still working so the display output
is just fine. Printing an error is enough.
Tested by
Remove interrupt disablement during backlight setting. It is
way to dangerous and makes platforms instable by having it
miss vblank IRQs leading to the graphics derailing.
The code is using ndelay() which is not available on
platforms such as ARM and will result in 32 * udelay(1)
which is
From: Michal Wajdeczko
Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.
v2: Use %p for ptrdiff print
v3: Use %tx for ptrdiff print
Signed-off-by: Michal Wajdeczko
Signed-off-by:
From: Michal Wajdeczko
Future GuC will require CTB buffers sizes to be multiple of 4K.
Make these changes now as this shouldn't impact us too much.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
---
[gmail is funny]
On Thu, Jun 3, 2021 at 11:58 PM Kees Cook wrote:
>
> VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
> pl111 is modular. Update the Kconfig to reflect the need.
>
> Cc: Emma Anholt
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc:
On Thu, Jun 3, 2021 at 11:58 PM Kees Cook wrote:
>
> VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
> pl111 is modular. Update the Kconfig to reflect the need.
>
> Cc: Emma Anholt
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Fixes:
From: Michal Wajdeczko
Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Reported-by:
From: Michal Wajdeczko
Future GuC will require CTB buffers sizes to be multiple of 4K.
Make these changes now as this shouldn't impact us too much.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
---
Is libdrm on gitlab ? I wasn't aware of this. I assumed code reviews still go
through dri-devel.
Andrey
From: Alex Deucher
Sent: 03 June 2021 17:20
To: Grodzovsky, Andrey
Cc: Maling list - DRI developers ; amd-gfx
list ; Deucher, Alexander
; Christian König
On Thu, Jun 03, 2021 at 02:34:12PM -0700, Kees Cook wrote:
> Avoid randconfig build failures by requiring VEXPRESS_CONFIG either be
> missing, built-in, or modular when pl111 is modular. Fixing this warning
> when:
>
> CONFIG_VEXPRESS_CONFIG=m
> CONFIG_DRM_PL111=y
>
> aarch64-linux-gnu-ld:
VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
pl111 is modular. Update the Kconfig to reflect the need.
Cc: Emma Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
On Thu, Jun 03, 2021 at 11:41:01PM +0200, Daniel Vetter wrote:
> On Thu, Jun 3, 2021 at 11:29 PM Kees Cook wrote:
> >
> > On Thu, Jun 03, 2021 at 02:19:52PM -0700, Kees Cook wrote:
> > > On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote:
> > > > On Thu, Jun 3, 2021 at 8:43 PM Rob
On Thu, Jun 3, 2021 at 11:29 PM Kees Cook wrote:
>
> On Thu, Jun 03, 2021 at 02:19:52PM -0700, Kees Cook wrote:
> > On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
> > > >
> > > > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook
> https://github.com/0day-ci/linux/commits/Matthew-Brost/GuC-CTBs-changes-a-few-misc-patches/20210603-130102
> base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> config: i386-randconfig-a015-20210603 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
On Wed, Jun 02, 2021 at 10:16:18PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> Generic helpers should be placed in i915_utils.h.
Random rant, but we're _way_ too happy to just stuff random things into
i915_utils.h without trying to properly upstream it.
For thinks like this the
Avoid randconfig build failures by requiring VEXPRESS_CONFIG either be
missing, built-in, or modular when pl111 is modular. Fixing this warning
when:
CONFIG_VEXPRESS_CONFIG=m
CONFIG_DRM_PL111=y
aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
On Thu, Jun 03, 2021 at 02:19:52PM -0700, Kees Cook wrote:
> On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
> > >
> > > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> > > >
> > > > Avoid randconfig build failures by
The value of the AFBC_FEATURES register is required by userspace to
determine AFBC support on Bifrost. A user on our IRC channel (#panfrost)
reported a workload that raised a fault on one system's Mali G31 but
worked flawlessly with another system's Mali G31. We determined the
cause to be missing
Please open a gitlab MR for these.
Alex
On Tue, Jun 1, 2021 at 4:17 PM Andrey Grodzovsky
wrote:
>
> Adding some tests to acompany the recently added hot-unplug
> feature. For now the test suite is disabled until the feature
> propagates from drm-misc-next to drm-next.
>
> Andrey Grodzovsky (7):
On Thu, Jun 3, 2021 at 5:11 PM Daniel Vetter wrote:
>
> On Thu, Jun 03, 2021 at 10:22:37AM -0400, Andrey Grodzovsky wrote:
> > Ping
> >
> > Andrey
> >
> > On 2021-06-02 10:20 a.m., Andrey Grodzovsky wrote:
> > >
> > > On 2021-06-02 3:59 a.m., Daniel Vetter wrote:
> > > > On Tue, Jun 1, 2021 at
On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote:
> On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
> >
> > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> > >
> > > Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
> > >
> > > aarch64-linux-gnu-ld:
On Thu, Jun 03, 2021 at 10:22:37AM -0400, Andrey Grodzovsky wrote:
> Ping
>
> Andrey
>
> On 2021-06-02 10:20 a.m., Andrey Grodzovsky wrote:
> >
> > On 2021-06-02 3:59 a.m., Daniel Vetter wrote:
> > > On Tue, Jun 1, 2021 at 10:17 PM Andrey Grodzovsky
> > > wrote:
> > > > Adding some tests to
The schedule function should be in the schedule object.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine.h| 14 ---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 --
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
Signed-off-by: Matthew Brost
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_scheduler.c | 46
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2
Signed-off-by: Matthew Brost
---
Documentation/gpu/i915.rst | 6
drivers/gpu/drm/i915/i915_scheduler_types.h | 37 ++---
2 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c
Rather than touching execlist specific structures in the generic
scheduling code, add a callback function in the backend.
Signed-off-by: Matthew Brost
---
.../drm/i915/gt/intel_execlists_submission.c | 52
drivers/gpu/drm/i915/i915_scheduler.c | 62 +--
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layering.
This is a bit of detour to integrating the
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
v3: add more depends on MMU. For usb drivers this is a bit awkward,
but really it's correct: To be
The value of the AFBC_FEATURES register is required by userspace to
determine AFBC support on Bifrost. A user on our IRC channel (#panfrost)
reported a workload that raised a fault on one system's Mali G31 but
worked flawlessly with another system's Mali G31. We determined the
cause to be missing
Hi Rob,
I love your patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.13-rc4
next-20210603]
[If your patch is applied to the wrong git
The value of the AFBC_FEATURES register is required by userspace to
determine AFBC support on Bifrost. A user on our IRC channel (#panfrost)
reported a workload that raised a fault on one system's Mali G31 but
worked flawlessly with another system's Mali G31. We determined the
cause to be missing
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.13-rc4 next-20210603]
[cannot apply to drm/drm-next]
[If your patch
On Tue, Jun 01, 2021 at 04:59:10PM +0200, Javier Martinez Canillas wrote:
> The series touches different subystems and will need coordination between
> maintainers. Ard Biesheuvel said that can be merged through the EFI tree.
I'm always happy when code from arch/x86/ moves away so
Acked-by:
On Thu, Jun 3, 2021 at 1:42 PM Rob Herring wrote:
>
> On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> >
> > Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
> >
> > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
> > `pl111_vexpress_clcd_init':
> >
On Wed, Jun 2, 2021 at 12:25 AM Zbigniew Kempczyński
wrote:
>
> We have established previously we stop using relocations starting
> from gen12 platforms with Tigerlake as an exception. We keep this
> statement but we want to enable relocations conditionally for
> Rocketlake and Alderlake under
https://bugzilla.kernel.org/show_bug.cgi?id=213321
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Thu, Jun 3, 2021 at 3:35 AM Chen Li wrote:
>
>
> I met a gpu addr bug recently and the kernel log
> tells me the pc is memcpy/memset and link register is
> radeon_uvd_resume.
>
> As we know, in some architectures, optimized memcpy/memset
> may not work well on device memory. Trival
On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
>
> On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> >
> > Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
> >
> > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
> > `pl111_vexpress_clcd_init':
> >
On Thu, Jun 3, 2021 at 7:53 PM Marek Olšák wrote:
>
> Daniel, I think what you are suggesting is that we need to enable user queues
> with the drm scheduler and dma_fence first, and once that works, we can
> investigate how much of that kernel logic can be moved to the hw. Would that
> work?
Applied. Thanks!
Alex
On Thu, Jun 3, 2021 at 7:21 AM Yu Kuai wrote:
>
> Add description for parameters for
> for_each_new_plane_in_state_reverse to fix warnings:
>
> include/drm/drm_atomic.h:908: warning: Function parameter or member '__state'
> not described in
Applied. Thanks!
Alex
On Thu, Jun 3, 2021 at 8:42 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable active_disp is being initialized with a value that
> is never read, it is being re-assigned immediately afterwards.
> Clean up the code by removing the need for variable
Am 03.06.21 um 17:03 schrieb Daniel Vetter:
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
On Thu, Jun 03, 2021 at 09:42:00PM +0300, Andi Shyti wrote:
> Hi Daniel,
>
> > +/*
> > + * This just sets wc mode for shmem helpers. vgem doesn't have any
> > begin/end cpu
> > + * access ioctls, there must use coherent memory or dma-buf sharing just
> > wont
> > + * work.
> > + */
> > +static
On Thu, Jun 3, 2021 at 3:48 AM Daniel Vetter wrote:
>
> On Wed, Jun 02, 2021 at 02:52:50PM -0700, Kees Cook wrote:
> > When cleaning up other drm config dependencies, it is too easy to create
> > larger problems. Instead, mark CONFIG_FB as a "depends":
> >
> > drivers/gpu/drm/Kconfig:74:error:
On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
>
> Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
>
> aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
> `pl111_vexpress_clcd_init':
> pl111_versatile.c:(.text+0x220): undefined reference to
>
Hi Daniel,
> +/*
> + * This just sets wc mode for shmem helpers. vgem doesn't have any begin/end
> cpu
> + * access ioctls, there must use coherent memory or dma-buf sharing just wont
> + * work.
> + */
> +static struct drm_gem_object *vgem_gem_create_object(struct drm_device *dev,
> size_t
Daniel, I think what you are suggesting is that we need to enable user
queues with the drm scheduler and dma_fence first, and once that works, we
can investigate how much of that kernel logic can be moved to the hw. Would
that work? In theory it shouldn't matter whether the kernel does it or the
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
Since we are replacing IS_GEN() with GRAPHICS_VER(), make sure we take
care of the comments as well.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_tv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
For some reason coccinelle misses a few cases in header files with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 37 -
drivers/gpu/drm/i915/i915_reg.h
v3 is a resend from v2 (https://patchwork.freedesktop.org/series/90693/)
now with dri-devel Cc'ed. Notice that this patch series can be applied
splitting it up through the trees, it's not necessary to apply them
together. The intention is to apply first 3 patches on drm-intel-gt-next
and the
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
For some reason coccinelle misses a few cases in gt with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc:
Hi all,
Another small iteration, lost another patch, so another full resend.
Thomas Zimmermann pointed out how to get at drm_gem_shmem_funcs without
getting at drm_gem_shmem_funcs directly.
Test-with: 20210527140732.5762-1-daniel.vet...@ffwll.ch
Cheers, Daniel
Daniel Vetter (4):
dma-buf:
On Thu, Jun 03, 2021 at 09:51:19AM +0100, Tvrtko Ursulin wrote:
>
> On 03/06/2021 05:10, Matthew Brost wrote:
> > On Wed, Jun 02, 2021 at 04:27:18PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 25/05/2021 17:45, Matthew Brost wrote:
>
> [snip]
>
> > > > >* Kludgy way of interfacing with
1 - 100 of 200 matches
Mail list logo
