Hi Dave, Daniel,
More updates for 5.14. On top of the stuff from last week's PR.
The following changes since commit 2bb5b5f688cbbd5030629905d3ed8032ab46e79f:
drm/radeon/dpm: Disable sclk switching on Oland when two 4K 60Hz monitors are
connected (2021-05-19 22:29:40 -0400)
are available in
Hi Linus,
Usual collection, mostly amdgpu and some i915 regression fixes. I
nearly managed to hose my build/sign machine this week, but I
recovered it just in time, and I even got clang12 built.
Dave.
drm-fixes-2021-05-21-1:
drm fixes for 5.13-rc3
dma-buf:
- WARN fix
amdgpu:
- Fix downscaling
Chrome platforms is unable to handle reading from -1.
It terminates the test after reporting buffer overflow.
Hence, changed the address for invalid buffer to NULL instead of -1.
With this change, errno becomes EINTR when reading from NULL
location. To accomodate, also changing the check of errno
Without wait for vblank, CRC mismatch is seen
between big and small CRC on few systems
Change-Id: I3bec931aa901130997e693ac1cacf389e2a8100f
Signed-off-by: Vidya Srinivas
---
tests/kms_big_fb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/kms_big_fb.c
On Wed, 7 Apr 2021 at 18:43, Alistair Popple wrote:
>
> Some NVIDIA GPUs do not support direct atomic access to system memory
> via PCIe. Instead this must be emulated by granting the GPU exclusive
> access to the memory. This is achieved by replacing CPU page table
> entries with special swap
On Thu, May 6, 2021 at 5:46 PM Rafael J. Wysocki wrote:
>
> On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote:
> >
> > Hi,
> > We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> > suffering the same GPU falling off the bus problem while exiting
> > s2idle with external display
On Friday, 21 May 2021 6:24:27 AM AEST Liam Howlett wrote:
[...]
> > > > diff --git a/mm/rmap.c b/mm/rmap.c
> > > > index 977e70803ed8..f09d522725b9 100644
> > > > --- a/mm/rmap.c
> > > > +++ b/mm/rmap.c
> > > > @@ -1405,10 +1405,6 @@ static bool try_to_unmap_one(struct page *page,
> > > >
On Wed, 19 May 2021 20:35:45 +, Corentin Labbe wrote:
> Converts display/faraday,tve200.txt to yaml.
>
> Signed-off-by: Corentin Labbe
> ---
> Changes since v1:
> - added two subsequent patchs fixing issue found when converting
> - fixed all issues reported by Rob Herring
>
) })
| ^
Caused by commit
0633cdcbaa77 ("drm/i915/dmc: Rename macro names containing csr")
I have used the drm-intel tree from next-20210520 for today.
--
Cheers,
Stephen Rothwell
pgpVjquE6r60Z.pgp
Description: OpenPGP digital signature
Hi all,
On Thu, 20 May 2021 10:19:10 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_mm.c
>
> between commit:
>
> 293837b9ac8d ("Revert "i915: fix remap_io_sg to verify the pgprot"")
>
> from Linus' tree
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/amdkfd/kfd_device.c
between commit:
e9669fb78262 ("drm/amdgpu: Add early fini callback")
from the drm-misc tree and commit:
814ab9930cfd ("drm/amdkfd: register HMM device private zone")
from the
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
between commit:
35bba8313b95 ("drm/amdgpu: Convert driver sysfs attributes to static
attributes")
from the drm-misc tree and commit:
589939d40116 ("drm/amdgpu: fix
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
between commit:
f89f8c6bafd0 ("drm/amdgpu: Guard against write accesses after device removal")
from the drm-misc tree and commit:
0ccc3ccf5b3a ("drm/amdgpu: re-apply "use the
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
between commit:
35bba8313b95 ("drm/amdgpu: Convert driver sysfs attributes to static
attributes")
from the drm-misc tree and commit:
a614b336f1c1 ("drm/amdgpu: fix coding
On Wed, May 19, 2021 at 5:25 PM Stephen Boyd wrote:
>
> Replace 'struct master' with 'struct aggregate_device' and then rename
> 'master' to 'adev' everywhere in the code. While we're here, put a
> struct device inside the aggregate device so that we can register it
> with a bus_type in the next
Hi everyone! As I'm sure most of you heard by now, Freenode's staff has
had a falling out and it's been recommended by their staff that projects
consider the network a hostile entity. I won't go into the details here,
but those who are interested can read up here:
https://lwn.net/Articles/856543/
On Wed, May 19, 2021 at 6:41 PM Stephen Boyd wrote:
>
> Quoting Saravana Kannan (2021-05-19 18:27:50)
> > On Wed, May 19, 2021 at 5:25 PM Stephen Boyd wrote:
> > >
> > > This series is from discussion we had on reordering the device lists for
> > > drm shutdown paths[1]. I've introduced an
On Thu, May 20, 2021 at 10:46 AM Matthew Brost wrote:
>
> On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote:
> > Am 19.05.21 um 18:51 schrieb Matthew Brost:
> > > On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote:
> > > > Oh, yeah we call that gang submit on the AMD
On Wed, 19 May 2021 10:15:35 +0200, Mauro Carvalho Chehab wrote:
> There are some places at drm that ended receiving a
> REPLACEMENT CHARACTER U+fffd ('�'), probably because of
> some bad charset conversion.
>
> Fix them by using what it seems to be the proper
> character.
Applied to
* Alistair Popple [210519 08:38]:
> On Wednesday, 19 May 2021 6:04:51 AM AEST Liam Howlett wrote:
> > External email: Use caution opening links or attachments
> >
> > * Alistair Popple [210407 04:43]:
> > > The behaviour of try_to_unmap_one() is difficult to follow because it
> > > performs
On Wed, May 19, 2021 at 12:43:49PM +0200, Christian König wrote:
> Am 19.05.21 um 10:24 schrieb Daniel Vetter:
> > Motivated because I got confused and Christian confirmed why this
> > works. I think this is non-obvious enough that it merits a slightly
> > longer comment.
> >
> > Cc: Christian
Hi Neil,
since this has not received any Reviewed-by yet I tried my best to
review it myself
On Fri, Apr 30, 2021 at 10:28 AM Neil Armstrong wrote:
[...]
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -485,11 +485,12 @@ static int
On Wed, May 19, 2021 at 09:41:27PM -0400, Stephen Boyd wrote:
> Quoting Saravana Kannan (2021-05-19 18:27:50)
> > On Wed, May 19, 2021 at 5:25 PM Stephen Boyd wrote:
> > >
> > > This series is from discussion we had on reordering the device lists for
> > > drm shutdown paths[1]. I've introduced
Hi Lee
Thank you for the patch
BR
Fabien
ST Restricted
> -Original Message-
> From: Lee Jones
> Sent: jeudi 20 mai 2021 14:02
> To: lee.jo...@linaro.org
> Cc: linux-ker...@vger.kernel.org; Benjamin Gaignard
> ; David Airlie ; Daniel Vetter
> ; Philipp Zabel ; Fabien DESSENNE
> ;
Mauro Carvalho Chehab writes:
> Hi Jon,
>
> This small series contain a series of fixes for the documentation. it is
> against your docs-next branch.
>
> Three of the patches fix duplicated symbols at the ABI documents.
> There are still some ABI warnings from IIO, but all but one were
> already
On Wed, May 19, 2021 at 05:25:19PM -0700, Stephen Boyd wrote:
> The device lists are poorly ordered when the component device code is
> used. This is because component_master_add_with_match() returns 0
> regardless of component devices calling component_add() first. It can
> really only fail if an
On Thu, May 20, 2021 at 08:10:59AM -0700, Matthew Brost wrote:
> On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote:
> > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 18, 2021 at
On Thu, May 20, 2021 at 11:57:44AM +0100, Tvrtko Ursulin wrote:
>
> On 20/05/2021 10:54, Daniel Vetter wrote:
> > On Wed, May 19, 2021 at 7:19 PM Matthew Brost
> > wrote:
> > >
> > > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 18, 2021 at 04:58:30PM
Applied. Thanks!
On Thu, May 20, 2021 at 9:32 AM Wei Yongjun wrote:
>
> GCC reports the following warnings with W=1:
>
> drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c:190:22: warning:
> variable 'ring' set but not used [-Wunused-but-set-variable]
> 190 | struct amdgpu_ring *ring;
> |
Applied. Thanks!
On Thu, May 20, 2021 at 8:04 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:98: warning: expecting prototype for
> amdgpu_vce_init(). Prototype was for amdgpu_vce_sw_init() instead
>
Hi Lee
Thank you for the patch
BR
Fabien
ST Restricted
> -Original Message-
> From: Lee Jones
> Sent: jeudi 20 mai 2021 14:02
> To: lee.jo...@linaro.org
> Cc: linux-ker...@vger.kernel.org; Benjamin Gaignard
> ; David Airlie ; Daniel Vetter
> ; Fabien DESSENNE ; dri-
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/smuio_v13_0.c:99: warning: expecting prototype
> for smuio_v13_0_supports_host_gpu_xgmi(). Prototype was for
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:04 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:51: warning: This comment starts with
> '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
>
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c:775: warning: expecting prototype for
> vcn_v1_0_start(). Prototype was for vcn_v1_0_start_spg_mode() instead
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:04 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:501: warning: expecting prototype for
> sdma_v_0_ctx_switch_enable(). Prototype was for sdma_v5_2_ctx_switch_enable()
> instead
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:04 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c:563: warning: expecting prototype for
> sdma_v_0_ctx_switch_enable(). Prototype was for sdma_v5_0_ctx_switch_enable()
> instead
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c:764: warning: expecting prototype for
> sdma_v4_0_page_ring_set_wptr(). Prototype was for sdma_v4_0_ring_set_wptr()
> instead
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c:281: warning: expecting prototype for
> sdma_v2_4_hdp_flush_ring_emit(). Prototype was for
> sdma_v2_4_ring_emit_hdp_flush()
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c:1008:5: warning: no previous
> prototype for ‘gfx_v9_4_2_query_ras_error_count’ [-Wmissing-prototypes]
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/r100.c:1423: warning: expecting prototype for
> r100_cs_packet_next_vline(). Prototype was for r100_cs_packet_parse_vline()
> instead
>
> Cc: Alex
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c:955: warning: expecting prototype for
> gmc_v8_0_gart_fini(). Prototype was for gmc_v10_0_gart_fini() instead
>
> Cc: Alex
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c:446: warning: expecting prototype
> for mmhub_v1_0_set_fault_enable_default(). Prototype was for
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:526: warning: expecting prototype for
> gmc_v8_0_set_fault_enable_default(). Prototype was for
>
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../include/aldebaran_ip_offset.h:259:29: warning:
> ‘XGMI2_BASE’ defined but not used [-Wunused-const-variable=]
>
Applied. Thanks!
On Thu, May 20, 2021 at 8:05 AM Christian König
wrote:
>
> Am 20.05.21 um 14:02 schrieb Lee Jones:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/radeon/radeon_vm.c:61: warning: expecting prototype for
> > radeon_vm_num_pde(). Prototype was for
Applied. Thanks!
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/cik.c:7450: warning: expecting prototype for
> cik_irq_disable(). Prototype was for cik_irq_suspend() instead
>
> Cc: Alex Deucher
> Cc:
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:468: warning: expecting prototype for
> cik_get_number_of_dram_channels(). Prototype was for
>
On Thu, May 20, 2021 at 9:04 PM Jason Ekstrand wrote:
>
> On Thu, May 20, 2021 at 12:23 PM Jason Ekstrand wrote:
> >
> > On Thu, May 20, 2021 at 5:50 AM Christian König
> > wrote:
> > >
> > > Am 20.05.21 um 09:55 schrieb Daniel Vetter:
> > > > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer
> >
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:04 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/si_dma.c:320: warning: expecting prototype for
> cik_dma_vm_copy_pte(). Prototype was for si_dma_vm_copy_pte() instead
>
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2126: warning: expecting prototype for
> gfx_v7_0_ring_emit_hdp(). Prototype was for gfx_v7_0_ring_emit_hdp_flush()
> instead
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:735: warning: expecting prototype for
> cik_sdma_vm_copy_pages(). Prototype was for cik_sdma_vm_copy_pte() instead
>
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:487: warning: expecting prototype
> for amdgpu_tmz_set(). Prototype was for amdgpu_gmc_tmz_set() instead
>
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:03 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1004: warning: expecting
> prototype for amdgpu_debugfs_regs_gfxoff_write(). Prototype was for
>
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:04 AM Christian König
wrote:
>
> Am 20.05.21 um 14:02 schrieb Lee Jones:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:200: warning: expecting prototype
> > for amdgpu_vm_grab_idle().
Applied. Thanks!
Alex
On Thu, May 20, 2021 at 8:04 AM Christian König
wrote:
>
> Am 20.05.21 um 14:02 schrieb Lee Jones:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/radeon/radeon_cs.c:417: warning: expecting prototype for
> > cs_parser_fini(). Prototype was
On Thu, May 20, 2021 at 12:23 PM Jason Ekstrand wrote:
>
> On Thu, May 20, 2021 at 5:50 AM Christian König
> wrote:
> >
> > Am 20.05.21 um 09:55 schrieb Daniel Vetter:
> > > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
> > >> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> > >>> On
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we
Add a helper function to get a single fence representing
all fences in a dma_resv object.
This fence is either the only one in the object or all not
signaled fences of the object in a flatted out dma_fence_array.
v2 (Jason Ekstrand):
- Take reference of fences both for creating the
This is mostly a re-send of v8 only with a fourth patch which contains the
sync file import ioctl that I had in the original series. I've not updated
the IGT tests yet for sync file import. This resend is mostly intended to
aid in discussions around implicit sync in general. I'll write up some
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch
From: Christian König
Add a helper to iterate over all fences in a dma_fence_array object.
v2 (Jason Ekstrand)
- Return NULL from dma_fence_array_first if head == NULL. This matches
the iterator behavior of dma_fence_chain_for_each in that it iterates
zero times if head == NULL.
-
Pushed to drm-misc-next. Thanks!
Alex
On Wed, May 19, 2021 at 12:45 PM Alex Deucher wrote:
>
> On Wed, May 19, 2021 at 9:57 AM Kai-Heng Feng
> wrote:
> >
> > Commit 3d42f1ddc47a ("vgaarb: Keep adding VGA device in queue") assumes
> > the first device is an integrated GPU. However, on AMD
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #33 from Jerome C (m...@jeromec.com) ---
(In reply to kolAflash from comment #32)
> In the meanwhile I performed test number 2.
>
> > 2. amd-drm-next-5.14-2021-05-12* without ip_block_mask=0x0ff, with Xorg
> [...]
>
> This time the
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #32 from kolAflash (kolafl...@kolahilft.de) ---
Created attachment 296901
--> https://bugzilla.kernel.org/attachment.cgi?id=296901=edit
dmesg via SSH, running amd-drm-next-5.14-2021-05-12 without ip_block_mask=0x0ff
and with Xorg
On Thu, May 20, 2021 at 6:31 PM Christian König
wrote:
>
> Yeah, having the timestamp is a good idea as well.
>
> drm-driver: i915
>
> I think we should rather add something like printing
> file_operations->owner->name to the common fdinfo code.
>
> This way we would have something common for
Am Freitag, dem 02.04.2021 um 15:48 -0500 schrieb Chris Morgan:
> Update the panel to allow setting the rotation value in device tree.
> Tested on an Odroid Go Advance, where the panel is by default rotated 270
> degrees.
>
> Signed-off-by: Chris Morgan
Reviewed-by: Lucas Stach
> ---
>
On Thu, May 20, 2021 at 5:50 AM Christian König
wrote:
>
> Am 20.05.21 um 09:55 schrieb Daniel Vetter:
> > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
> >> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> >>> On Wed, May 19, 2021 at 5:52 AM Michel Dänzer wrote:
> On 2021-05-19
On Thu, May 20, 2021 at 9:18 AM Daniel Vetter wrote:
>
> On Thu, May 20, 2021 at 10:13:38AM +0200, Michel Dänzer wrote:
> > On 2021-05-20 9:55 a.m., Daniel Vetter wrote:
> > > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
> > >>
> > >> On 2021-05-19 5:21 p.m., Jason Ekstrand wrote:
> >
On Thu, May 20, 2021 at 6:41 PM Christian König
wrote:
>
> Am 20.05.21 um 18:34 schrieb Daniel Vetter:
> > On Thu, May 20, 2021 at 06:01:39PM +0200, Christian König wrote:
> >> Am 20.05.21 um 16:54 schrieb Rob Clark:
> >>> On Thu, May 20, 2021 at 7:11 AM Christian König
> >>> wrote:
>
>
On Thu, May 06, 2021 at 12:13:18PM -0700, Matthew Brost wrote:
> From: Daniele Ceraolo Spurio
>
> If we're about to sanitize the GuC, something might have going wrong
> beforehand, so we should avoid trying to talk to it. Even if GuC is
> still running fine, the sanitize will reset its internal
Hi Maxime
On Thu, 20 May 2021 at 16:03, Maxime Ripard wrote:
>
> Hi,
>
> The composite output in the BCM2711 is dealt using the VEC. While the earlier
> SoCs were properly supported, it wasn't functional on the BCM2711. Add the
> needed support from the RPi downstream kernel.
Thanks for
Am 20.05.21 um 18:34 schrieb Daniel Vetter:
On Thu, May 20, 2021 at 06:01:39PM +0200, Christian König wrote:
Am 20.05.21 um 16:54 schrieb Rob Clark:
On Thu, May 20, 2021 at 7:11 AM Christian König
wrote:
Am 20.05.21 um 16:07 schrieb Rob Clark:
On Wed, May 19, 2021 at 11:47 PM Christian
On Thu, May 20, 2021 at 06:01:39PM +0200, Christian König wrote:
> Am 20.05.21 um 16:54 schrieb Rob Clark:
> > On Thu, May 20, 2021 at 7:11 AM Christian König
> > wrote:
> > >
> > >
> > > Am 20.05.21 um 16:07 schrieb Rob Clark:
> > > > On Wed, May 19, 2021 at 11:47 PM Christian König
> > > >
Yeah, having the timestamp is a good idea as well.
drm-driver: i915
I think we should rather add something like printing
file_operations->owner->name to the common fdinfo code.
This way we would have something common for all drivers in the system.
I'm just not sure if that also works if
On Wed, May 19, 2021 at 11:38:53AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>
[AMD Official Use Only]
i would like to add a unit marker for the stats that we monitor in the fd, as
we discussed currently we are displaying the usage percentage, because we
wanted to to provide single query percentages, but this may evolve with time.
May I suggest to add two new fields
On Thu, May 20, 2021 at 4:03 PM Rob Clark wrote:
>
> On Wed, May 19, 2021 at 11:47 PM Christian König
> wrote:
> >
> > Uff, that looks very hardware specific to me.
>
> Howso? I'm not sure I agree.. and even if it was not useful for some
> hw, it should be useful for enough drivers (and harm no
Am 20.05.21 um 16:54 schrieb Rob Clark:
On Thu, May 20, 2021 at 7:11 AM Christian König
wrote:
Am 20.05.21 um 16:07 schrieb Rob Clark:
On Wed, May 19, 2021 at 11:47 PM Christian König
wrote:
Uff, that looks very hardware specific to me.
Howso? I'm not sure I agree.. and even if it was
On Thu, May 20, 2021 at 01:11:59PM +0200, Christian König wrote:
> Am 19.05.21 um 18:51 schrieb Matthew Brost:
> > On Wed, May 19, 2021 at 01:45:39PM +0200, Christian König wrote:
> > > Oh, yeah we call that gang submit on the AMD side.
> > >
> > > Had already some internal discussions how to
On Thu, May 20, 2021 at 11:54:25AM +0200, Daniel Vetter wrote:
> On Wed, May 19, 2021 at 7:19 PM Matthew Brost wrote:
> >
> > On Wed, May 19, 2021 at 01:10:04PM +0200, Daniel Vetter wrote:
> > > On Tue, May 18, 2021 at 04:58:30PM -0700, Matthew Brost wrote:
> > > > Add entry fpr i915 new parallel
On Thu, 2021-05-20 at 17:09 +0200, Thomas Hellström wrote:
>
> +EXPORT_SYMBOL(ttm_tt_unpopulate);
Oh, this one was a leftover. It's not meant to be included anymore.
/Thomas
>
> #ifdef CONFIG_DEBUG_FS
>
From: Tvrtko Ursulin
Continuing on the identically named thread. First six patches are i915 specific
so please mostly look at the last one only which discusses the common options
for DRM drivers.
I haven't updated intel_gpu_top to use this yet so can't report any performance
numbers.
Tvrtko
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish
On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> and i915 is the only (remaining) user.
>
> swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> SWIOTLB_FORCE is set or swiotlb-zen is
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git
Memcpy from wc will be used as well by TTM memcpy.
Move it to core drm, and make the interface do the right thing
even on !X86.
Cc: Christian König
Cc: Daniel Vetter
Cc: Dave Airlie
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/Makefile | 2 +-
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping
This is mainly a pre-check that the core TTM changes for the initial
i915 TTM patch series look reasonably ok.
Main thing is we add the new page-based iomem memcpy util to TTM, and
for some speed the copy-from-wc-x86-only prefetching memcpy to core drm.
Note that the legacy memcpy path is largely
From: Mateusz Kwiatkowski
The BCM2711 VEC uses a slightly different, incompatible, setup than the
one used for the earlier SoC. Add a new compatible for it.
Signed-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/display/brcm,bcm2835-vec.yaml | 4
From: Mateusz Kwiatkowski
On the BCM2711 (Raspberry Pi 4), the VEC is actually connected to
output 2 of pixelvalve3.
NOTE: This contradicts the Broadcom docs, but has been empirically
tested and confirmed by Raspberry Pi firmware devs.
Signed-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime
From: Mateusz Kwiatkowski
The BCM2711 has a slightly different VEC than the one found in the older
SoCs. Now that we support the new variant, add its compatible to the
device tree.
Signed-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2711.dtsi | 1 +
1
From: Mateusz Kwiatkowski
The VEC's DAC on BCM2711 is slightly different compared to the one on
BCM283x and needs different configuration. In particular, bit 3
(mask 0x8) switches the BCM2711 DAC input to "self-test input data",
which makes the output unusable. Separating two compatible variants
1 - 100 of 215 matches
Mail list logo
