[Bug 111122] 2500U: Graphics corruption on kernel 5.2

https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #10 from Brian Schott --- Just rebuilt mesa, libdrm, and xf86-video-amdgpu from git this evening. The kernel is the gentoo patched version of 5.2.6. The problem is not limited to XFCE's window manager. This is what it looks like in

Re: [PATCH] drm/panfrost: Implement per FD address spaces

On Thu, Aug 8, 2019 at 5:11 PM Alyssa Rosenzweig wrote: > > > @@ -448,6 +453,7 @@ static irqreturn_t panfrost_job_irq_handler(int irq, > > void *data) > > } > > > > if (status & JOB_INT_MASK_DONE(j)) { > > + panfrost_mmu_as_put(pfdev, > >

Re: [PATCH] drm/panfrost: Implement per FD address spaces

On Thu, Aug 8, 2019 at 5:18 PM Matthew Auld wrote: > > On Thu, 8 Aug 2019 at 23:29, Rob Herring wrote: > > > > Up until now, a single shared GPU address space was used. This is not > > ideal as there's no protection between processes and doesn't work for > > supporting the same GPU/CPU VA

Re: [pull] amdgpu, amdkfd, radeon, ttm drm-next-5.4

On Wed, 7 Aug 2019 at 06:03, Alex Deucher wrote: > > Hi Dave, Daniel, > > The big updates here are support for new asics (navi14, navi12, arcturus). Thanks Alex, but due to the readq/writeq this break my local validation builds which means we need to land a fix for that somehow first. Also this

Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus

Hi, We need to discuss how to change or do refactoring on v2. Actually, I don't know the your opinion and how to do it on v2. You have to reply the answer and then after finished the discussion, I recommend that you would rework and resend the v2 patches. On 19. 8. 8. 오후 10:18, Artur Świgoń

[Bug 110258] Lenovo V110-15AST AMD A9-9410 AMD R5 Stoney hangs after waking after suspend. 5.0 onwards

https://bugs.freedesktop.org/show_bug.cgi?id=110258 --- Comment #10 from Eugene Bright --- Does someone work on the fix here? Should this issue be reported to the kernel.org? -- You are receiving this mail because: You are the assignee for the

Re: [PATCH] drm/i915: Use after free in error path in intel_vgpu_create_workload()

On 2019.08.08 11:44:21 +0100, Chris Wilson wrote: > Quoting Dan Carpenter (2019-08-08 11:32:36) > > We can't free "workload" until after the printk or it's a use after > > free. > > > > Fixes: 2089a76ade90 ("drm/i915/gvt: Checking workload's gma earlier") > > Signed-off-by: Dan Carpenter > >

[PATCH v2] drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes

I -thought- I had fixed this entirely, but it looks like that I didn't test this thoroughly enough as we apparently still make one big mistake with nv50_msto_atomic_check() - we don't handle the following scenario: * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 which is

[Bug 111241] Shadertoy shader causing hang

https://bugs.freedesktop.org/show_bug.cgi?id=111241 --- Comment #2 from Dieter Nützel --- RX 580 / NIR amd-staging-drm-next Mesa git Firefox 68.0.1 [42489.228053] [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] *ERROR* Waiting for fences timed out or interrupted!

[Bug 111305] `ttm_bo_handle_move_mem` sometimes takes more than 50 ms

https://bugs.freedesktop.org/show_bug.cgi?id=111305 --- Comment #2 from Paul Menzel --- (In reply to Alex Deucher from comment #1) > The contents of vram have to be moved to system memory on suspend since vram > is powered off. Depending on general memory pressure at suspend time it may > take

[Bug 110865] Rx480 consumes 20w more power in idle than under Windows

https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #13 from Dieter Nützel --- (In reply to Dieter Nützel from comment #12) > (In reply to Alex Deucher from comment #9) > > Created attachment 144983 [details] [review] [review] > > fix DC code > > > > Can you try applying both of

[Bug 110865] Rx480 consumes 20w more power in idle than under Windows

https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #12 from Dieter Nützel --- (In reply to Alex Deucher from comment #9) > Created attachment 144983 [details] [review] > fix DC code > > Can you try applying both of these patches? Assuming both of your monitors > have the same

Re: [PATCH] drm/panfrost: Implement per FD address spaces

On Thu, 8 Aug 2019 at 23:29, Rob Herring wrote: > > Up until now, a single shared GPU address space was used. This is not > ideal as there's no protection between processes and doesn't work for > supporting the same GPU/CPU VA feature. Most importantly, this will > hopefully mitigate Alyssa's

Re: [PATCH v4 2/9] drm/shmem: Put pages independent of a SG table being set

Rob Herring writes: > If a driver does its own management of pages, the shmem helper object's > pages array could be allocated when a SG table is not. There's not > really any good reason to tie putting pages with having a SG table when > freeing the object, so just put pages if the pages array

Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel

On Thu, Aug 08, 2019 at 03:33:00PM -0700, Andrew Morton wrote: > On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook wrote: > > > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8. > > > > > > Andrew, could you take a look and give your Acked-by or pick them up > > > directly? > > > > Given

Re: [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote: > > tglx just picked up 2 other patches of mine, bumping just in case he's > > not picking up patches while on vacation. ;) > > I'm only half on vacation :) > > So I can pick it up. Thanks, will send half margaritas. -- Thanks, ~Nick

Re: [PATCH v4 07/17] drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPS

On Thu, Aug 8, 2019 at 7:44 AM Gerd Hoffmann wrote: > > DEFINE_DRM_GEM_SHMEM_FOPS is identical to DEFINE_DRM_GEM_FOPS now, > drop it. > > Signed-off-by: Gerd Hoffmann > --- > include/drm/drm_gem_shmem_helper.h | 26 - > drivers/gpu/drm/cirrus/cirrus.c | 2

Re: [PATCH v4 06/17] drm/shmem: switch shmem helper to drm_gem_object_funcs->mmap

On Thu, Aug 8, 2019 at 7:44 AM Gerd Hoffmann wrote: > > Switch gem shmem helper from gem_driver->fops->mmap to > drm_gem_object_funcs->mmap. > > Signed-off-by: Gerd Hoffmann > --- > include/drm/drm_gem_shmem_helper.h | 4 ++-- > drivers/gpu/drm/drm_gem_shmem_helper.c | 18

Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel

On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook wrote: > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8. > > > > Andrew, could you take a look and give your Acked-by or pick them up > > directly? > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go > via Andrew? I

[PATCH] drm/panfrost: Implement per FD address spaces

Up until now, a single shared GPU address space was used. This is not ideal as there's no protection between processes and doesn't work for supporting the same GPU/CPU VA feature. Most importantly, this will hopefully mitigate Alyssa's fear of WebGL, whatever that is. Most of the changes here are

[PATCH v4 6/9] drm/panfrost: Consolidate reset handling

Runtime PM resume and job timeouts both call the same sequence of functions, so consolidate them to a common function. This will make changing the reset related code easier. The MMU also needs some re-initialization on reset, so rework its call. In the process, we hide the address space details

[PATCH v4 2/9] drm/shmem: Put pages independent of a SG table being set

If a driver does its own management of pages, the shmem helper object's pages array could be allocated when a SG table is not. There's not really any good reason to tie putting pages with having a SG table when freeing the object, so just put pages if the pages array is populated. Cc: Maarten

[PATCH v4 9/9] drm/panfrost: Bump driver version to 1.1

Increment the driver version to expose the new BO allocation flags. Cc: Tomeu Vizoso Cc: Boris Brezillon Cc: Robin Murphy Cc: Steven Price Acked-by: Alyssa Rosenzweig Signed-off-by: Rob Herring --- drivers/gpu/drm/panfrost/panfrost_drv.c | 7 ++- 1 file changed, 6 insertions(+), 1

[PATCH v4 7/9] drm/panfrost: Convert MMU IRQ handler to threaded handler

In preparation to handle mapping of page faults, we need the MMU handler to be threaded as code paths take a mutex. As the IRQ may be shared, we can't use the default handler and must disable the MMU interrupts locally. Cc: Tomeu Vizoso Cc: Boris Brezillon Cc: Robin Murphy Reviewed-by: Steven

[PATCH v4 5/9] drm/panfrost: Add a no execute flag for BO allocations

Executable buffers have an alignment restriction that they can't cross 16MB boundary as the GPU program counter is 24-bits. This restriction is currently not handled and we just get lucky. As current userspace assumes all BOs are executable, that has to remain the default. So add a new

[PATCH v4 4/9] drm/panfrost: Split panfrost_mmu_map SG list mapping to its own function

In preparation to create partial GPU mappings of BOs on page faults, split out the SG list handling of panfrost_mmu_map(). Cc: Tomeu Vizoso Cc: Boris Brezillon Cc: Robin Murphy Reviewed: Steven Price Acked-by: Alyssa Rosenzweig Signed-off-by: Rob Herring ---

[PATCH v4 3/9] drm/panfrost: Restructure the GEM object creation

Setting the GPU VA when creating the GEM object doesn't allow for any conditional adjustments to the mapping. In preparation to support adjusting the mapping and per FD address spaces, restructure the GEM object creation to map and unmap the GEM object in the GEM object .open() and .close() hooks.

[PATCH v4 8/9] drm/panfrost: Add support for GPU heap allocations

The midgard/bifrost GPUs need to allocate GPU heap memory which is allocated on GPU page faults and not pinned in memory. The vendor driver calls this functionality GROW_ON_GPF. This implementation assumes that BOs allocated with the PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of

[PATCH v4 0/9] drm/panfrost: Add heap and no execute buffer allocation

This series adds new BO allocation flags PANFROST_BO_HEAP and PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults. Hopefully, this is the last version, but I made a few changes after implementing per FD address spaces on top of this. Primarily, I moved the GPU VA mapping into

[PATCH v4 1/9] drm/gem: Allow sparsely populated page arrays in drm_gem_put_pages

Panfrost has a need for pages allocated on demand via GPU page faults. When releasing the pages, the only thing preventing using drm_gem_put_pages() is needing to skip over unpopulated pages, so allow for skipping over NULL struct page pointers. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean

linux-next: manual merge of the amdgpu-fixes tree with the drm-fixes tree

Hi all, Today's linux-next merge of the amdgpu-fixes tree got conflicts in: drivers/gpu/drm/amd/amdkfd/kfd_chardev.c include/uapi/linux/kfd_ioctl.h between commit: 4b3e30ed3ec7 ("Revert "drm/amdkfd: New IOCTL to allocate queue GWS"") from the drm-fixes tree and commit: 7e51b56cd5b8

[Bug 111241] Shadertoy shader causing hang

https://bugs.freedesktop.org/show_bug.cgi?id=111241 --- Comment #1 from Pierre-Eric Pelloux-Prayer --- I could reproduce the issue on a Raven Ridge and a Navi10. But when using NIR (radeonsi_enable_nir=true env variable) the shader is perfectly usable. -- You are receiving this mail because:

[PATCH 09/22] fbdev: omap: avoid using mach/*.h files

All the headers we actually need are now in include/linux/soc, so use those versions instead and allow compile-testing on other architectures. Signed-off-by: Arnd Bergmann --- drivers/video/backlight/Kconfig | 4 ++-- drivers/video/backlight/omap1_bl.c | 4 ++--

Re: [PATCH] nouveau/hmm: map pages after migration

On 8/8/19 12:07 AM, Christoph Hellwig wrote: On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote: When memory is migrated to the GPU it is likely to be accessed by GPU code soon afterwards. Instead of waiting for a GPU fault, map the migrated memory into the GPU page tables with the

[PATCH 02/22] ARM: omap1: make omapfb standalone compilable

The omapfb driver is split into platform specific code for omap1, and driver code that is also specific to omap1. Moving both parts into the driver directory simplifies the structure and avoids the dependency on certain omap machine header files. The interrupt numbers in particular however must

[PATCH 01/22] ARM: omap1: innovator: pass lcd control address as pdata

To avoid using the mach/omap1510.h header file, pass the correct address as platform data. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap1/board-innovator.c | 3 +++ drivers/video/fbdev/omap/lcd_inn1510.c | 7 +-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git

Re: 回复：[PATCH v3 1/1] drm/syncobj: add sideband payload

On 08/08/2019 19:23, Jason Ekstrand wrote: I've got a couple questions that I think go along the lines of what Christian wrote: 1. Should it really be called sideband?  It's a very generic term for what is currently a very generic thing. However, maybe we don't want it to be so generic? 2.

Re: [PATCH v19 00/15] arm64: untag user pointers passed to the kernel

On Wed, Aug 07, 2019 at 07:17:35PM +0200, Andrey Konovalov wrote: > On Tue, Aug 6, 2019 at 7:13 PM Will Deacon wrote: > > > > On Wed, Jul 24, 2019 at 03:20:59PM +0100, Will Deacon wrote: > > > On Wed, Jul 24, 2019 at 04:16:49PM +0200, Andrey Konovalov wrote: > > > > On Wed, Jul 24, 2019 at 4:02

Re: [PATCH 6/9] nouveau: simplify nouveau_dmem_migrate_to_ram

On 8/8/19 8:33 AM, Christoph Hellwig wrote: Factor the main copy page to ram routine out into a helper that acts on a single page and which doesn't require the nouveau_dmem_fault structure for argument passing. Also remove the loop over multiple pages as we only handle one at the moment,

Re: [PATCH RFC 05/19] drm/exynos: Don't reset bridge->next

On Thu, 8 Aug 2019 17:11:36 +0200 Boris Brezillon wrote: > bridge->next is only points to the new bridge if drm_bridge_attach() ^/is// > succeeds. No need to reset it manually here. > > Note that this change is part of the attempt to make the bridge chain > a double-linked

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #4 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- I tried to reproduce it with a kernel which is just a few commits different then this one - https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next I tried with X enabled

[Bug 100239] Incorrect rendering in CS:GO

https://bugs.freedesktop.org/show_bug.cgi?id=100239 --- Comment #24 from Bruno Jacquet (Xaapyks) --- Created attachment 144987 --> https://bugs.freedesktop.org/attachment.cgi?id=144987=edit vega 64 on mesa 19.1.3 -- You are receiving this mail because: You are the assignee for the

[Bug 100239] Incorrect rendering in CS:GO

https://bugs.freedesktop.org/show_bug.cgi?id=100239 Bruno Jacquet (Xaapyks) changed: What|Removed |Added Status|RESOLVED|REOPENED

[Bug 101633] MST monitor, strange behaviour in terminal

https://bugs.freedesktop.org/show_bug.cgi?id=101633 --- Comment #3 from Denys --- Still actual in 5.3.0-rc3 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org

[Bug 101633] MST monitor, strange behaviour in terminal

https://bugs.freedesktop.org/show_bug.cgi?id=101633 Denys changed: What|Removed |Added Summary|[amd-staging] MST monitor, |MST monitor, strange

[Bug 101633] [amd-staging] MST monitor, strange behaviour in terminal

https://bugs.freedesktop.org/show_bug.cgi?id=101633 Denys changed: What|Removed |Added See Also||https://bugs.freedesktop.or

[Bug 110671] Regression: DP outputs out of sync on dual-DP tiled 5k screen

https://bugs.freedesktop.org/show_bug.cgi?id=110671 Denys changed: What|Removed |Added See Also||https://bugs.freedesktop.or

[Bug 110671] Regression: DP outputs out of sync on dual-DP tiled 5k screen

https://bugs.freedesktop.org/show_bug.cgi?id=110671 --- Comment #10 from Denys --- Just added some debug to rc3 and tried to check what happens(in context of 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1). So in program_timing_sync() there is preparing of groups of pipes for sync. And looks like(in

Re: [PATCH RFC 03/19] drm/vc4: Get rid of the dsi->bridge field

Boris Brezillon writes: > Now that we have an official way to request custom encoder/bridge > enable/disable sequences we can get rid of the extra ->bridge field > and use the encoder one. Patch 2, 3 are: Reviewed-by: Eric Anholt signature.asc Description: PGP signature

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #3 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- OK, checked lspci and it's Ellsmere... Never mind. -- You are receiving this mail because: You are watching the assignee of the bug.

Re: [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

On Thu, 8 Aug 2019, Nick Desaulniers wrote: > On Tue, Aug 6, 2019 at 5:59 AM Josh Poimboeuf wrote: > > > Gentle ping... > > > Thomas and Chris: Will someone of you pick this up? > > > As "objtool: Improve UACCESS coverage" [1] went trough tip tree I > > > highly appreciate to do so with this one.

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 Andrey Grodzovsky (andrey.grodzov...@amd.com) changed: What|Removed |Added CC|

[Bug 111334] amdgpu-pro-19.20-812932 fails to compile DKMS

https://bugs.freedesktop.org/show_bug.cgi?id=111334 --- Comment #1 from Gustavo A. Díaz --- Ok, fixed. The problem was that KDE neon modify the file /etc/os-release. The install script run fine since I've modified it (instead of os-releast) from: case "$ID" in ubuntu|linuxmint|debian)

Re: [PATCH 01/26] drm/dp_mst: Move link address dumping into a function

On Wed, Jul 17, 2019 at 09:42:24PM -0400, Lyude Paul wrote: > Since we're about to be calling this from multiple places. Also it makes > things easier to read! > > Cc: Juston Li > Cc: Imre Deak > Cc: Ville Syrjälä > Cc: Harry Wentland > Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter

Re: [PATCH 25/60] drm: Add helper to create a connector for a chain of bridges

Hi Daniel, On Thu, Jul 18, 2019 at 07:01:03PM +0200, Daniel Vetter wrote: > On Sun, Jul 07, 2019 at 09:19:02PM +0300, Laurent Pinchart wrote: > > Most bridge drivers create a DRM connector to model the connector at the > > output of the bridge. This model is historical and has worked pretty > >

[Bug 111333] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* chosen encoder in use 0

https://bugs.freedesktop.org/show_bug.cgi?id=111333 --- Comment #2 from Bugman --- bugzilla-dae...@freedesktop.org pisze: > > *Comment # 1 > on bug 111333 > from Alex Deucher

Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data

Hello, On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote: > On 16.07.2019 11:00, Daniel Vetter wrote: > > On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote: > >> On 11.07.2019 17:50, Daniel Vetter wrote: > >>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:

Re: [PATCH] dma-buf: make dma_fence structure a bit smaller v2

On Thu, Aug 08, 2019 at 04:41:39PM +0200, Christian König wrote: > Daniel any more comments on this one? It's not kerneldoc, but then all the dma-* docs need some serious love anyway, so all good with me. -Daniel > > If not I'm going to push it. > > Christian. > > Am 08.08.19 um 15:22 schrieb

Re: next/master build: 230 builds: 5 failed, 225 passed, 6 errors, 1344 warnings (next-20190805)

On Thu, Aug 8, 2019 at 2:53 PM Guenter Roeck wrote: > > On Mon, Aug 05, 2019 at 12:12:05PM +0100, Mark Brown wrote: > > On Mon, Aug 05, 2019 at 02:40:32AM -0700, kernelci.org bot wrote: > > > > Today's -next fails to build an arm allmodconfig due to: > > > > > allmodconfig (arm, gcc-8) — FAIL, 2

[Bug 111334] amdgpu-pro-19.20-812932 fails to compile DKMS

https://bugs.freedesktop.org/show_bug.cgi?id=111334 Bug ID: 111334 Summary: amdgpu-pro-19.20-812932 fails to compile DKMS Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH 08/60] drm/bridge: Extend bridge API to disable connector creation

Hi Andrzej, On Thu, Aug 08, 2019 at 07:36:49PM +0200, Andrzej Hajda wrote: > On 08.08.2019 16:25, Laurent Pinchart wrote: > > On Wed, Jul 17, 2019 at 08:39:47AM +0200, Andrzej Hajda wrote: > >> On 07.07.2019 20:18, Laurent Pinchart wrote: > >>> Most bridge drivers create a DRM connector to model

Re: drm_panel_get_modes() should take the connector as an argument [Was: drm/bridge: panel: Implement bridge ...]

Hi Sam, On Thu, Aug 08, 2019 at 06:52:53PM +0200, Sam Ravnborg wrote: > Hi Laurent. > > As I said in another mail, you have managed to keep me busy... > > > > I took a look at this - it seems simple: > > > - Update drm_panel.get_modes() to take drm_connector as argument, and fix > > > all

Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data

On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote: > On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote: > > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote: > >> Hi Laurent, > >> > >> I like the approach, current practice when almost every bridge should >

[radeon-alex:amd-19.30 1374/2148] htmldocs: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:204: warning: Function parameter or member 'target_dev' not described in 'amdgpu_dma_buf_map_attach'

Hi Mauro, FYI, the error/warning still remains. tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.30 head: 494cd065e68f6ba299e074e269b57773d7524e67 commit: 247814e2121b6f9d3b5f2ed04a7221b991fb441a [1374/2148] gpu: amdgpu: fix broken amdgpu_dma_buf.c references reproduce: make

Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data

Hello Daniel and Andrzej, On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote: > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote: > > Hi Laurent, > > > > I like the approach, current practice when almost every bridge should > > optionally implement connector, or

Re: [PATCH RFC 01/19] drm: Stop including drm_bridge.h from drm_crtc.h

Hi Boris. Good to see that you kept the alphabetical order in the include files. One nit below. With this fixed: Reviewed-by: Sam Ravnborg Sam > diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h > index 982865866a29..c681a9e22484 100644 > ---

[PATCH] drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes

I -thought- I had fixed this entirely, but it looks like that I didn't test this thoroughly enough as we apparently still make one big mistake with nv50_msto_atomic_check() - we don't handle the following scenario: * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 which is

1c74ca7a1a9a ("drm/fb-helper: call vga_remove_vgacon automatically.")

Hi, for some unfathomable to me reason, the commit in $Subject breaks booting of the 32-bit partition of one of my test boxes. The box doesn't finish booting (normally it boots in text mode, there is no X server setup on it) but it is still responsible in the sense that I can reboot it with the

Re: [PATCH 08/60] drm/bridge: Extend bridge API to disable connector creation

On 08.08.2019 16:25, Laurent Pinchart wrote: > Hi Andrzej, > > On Wed, Jul 17, 2019 at 08:39:47AM +0200, Andrzej Hajda wrote: >> On 07.07.2019 20:18, Laurent Pinchart wrote: >>> Most bridge drivers create a DRM connector to model the connector at the >>> output of the bridge. This model is

Re: [PATCHv2 2/3] i915: convert to new mount API

On 08/08/2019 17:23, Chris Wilson wrote: Quoting Hugh Dickins (2019-08-08 16:54:16) On Thu, 8 Aug 2019, Al Viro wrote: On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote: On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote: Though personally I'm averse to managing

[Bug 111305] `ttm_bo_handle_move_mem` sometimes takes more than 50 ms

https://bugs.freedesktop.org/show_bug.cgi?id=111305 --- Comment #1 from Alex Deucher --- The contents of vram have to be moved to system memory on suspend since vram is powered off. Depending on general memory pressure at suspend time it may take a while to get the contexts of vram into system

Re: drm_panel_get_modes() should take the connector as an argument [Was: drm/bridge: panel: Implement bridge ...]

Hi Laurent. As I said in another mail, you have managed to keep me busy... > > I took a look at this - it seems simple: > > - Update drm_panel.get_modes() to take drm_connector as argument, and fix > > all callers. All callers already have connector available. > > - Drop drm_panel_attach(),

Re: [PATCH 1/2] drm: add cache support for arm64

On Thu, Aug 8, 2019 at 12:59 AM Christoph Hellwig wrote: > > On Wed, Aug 07, 2019 at 10:30:04AM -0700, Rob Clark wrote: > > So, we do end up using GFP_HIGHUSER, which appears to get passed thru > > when shmem gets to the point of actually allocating pages.. not sure > > if that just ends up being

Re: [PATCH 10/60] drm/bridge: Add bridge driver for display connectors

Hi Sam, On Tue, Jul 16, 2019 at 11:28:57AM +0200, Sam Ravnborg wrote: > On Sun, Jul 07, 2019 at 09:18:47PM +0300, Laurent Pinchart wrote: > > Display connectors are modelled in DT as a device node, but have so far > > been handled manually in several bridge drivers. This resulted in > > duplicate

[Bug 111333] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* chosen encoder in use 0

https://bugs.freedesktop.org/show_bug.cgi?id=111333 --- Comment #1 from Alex Deucher --- Are you actually seeing any problems or is it just the message you are concerned about? -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 1/2] drm: add cache support for arm64

On Thu, Aug 8, 2019 at 3:00 AM Christoph Hellwig wrote: > > On Wed, Aug 07, 2019 at 09:09:53AM -0700, Rob Clark wrote: > > > > (Eventually I'd like to support pages passed in from userspace.. but > > > > that is down the road.) > > > > > > Eww. Please talk to the iommu list before starting on

RE: [PATCH 00/34] put_user_pages(): miscellaneous call sites

> > On 8/7/19 7:36 PM, Ira Weiny wrote: > > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote: > >> On Wed 07-08-19 10:37:26, Jan Kara wrote: > >>> On Fri 02-08-19 12:14:09, John Hubbard wrote: > On 8/2/19 7:52 AM, Jan Kara wrote: > > On Fri 02-08-19 07:24:43, Matthew Wilcox

Re: [PATCHv2 2/3] i915: convert to new mount API

Quoting Hugh Dickins (2019-08-08 16:54:16) > On Thu, 8 Aug 2019, Al Viro wrote: > > On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote: > > > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote: > > > > Though personally I'm averse to managing "f"objects through > > > >

Re: 回复：[PATCH v3 1/1] drm/syncobj: add sideband payload

I've got a couple questions that I think go along the lines of what Christian wrote: 1. Should it really be called sideband? It's a very generic term for what is currently a very generic thing. However, maybe we don't want it to be so generic? 2. Do we really want get/set? Or do we want

Re: drm_panel_get_modes() should take the connector as an argument [Was: drm/bridge: panel: Implement bridge ...]

Hi Sam, On Tue, Jul 16, 2019 at 01:08:27PM +0200, Sam Ravnborg wrote: > Hi Laurent et all. > > > +static int panel_bridge_get_modes(struct drm_bridge *bridge, > > + struct drm_connector *connector) > > +{ > > + struct panel_bridge *panel_bridge =

Re: [PATCH] i2c: replace i2c_new_secondary_device with an ERR_PTR variant

On Thu, Aug 08, 2019 at 05:57:09PM +0200, Wolfram Sang wrote: > On Tue, Jul 23, 2019 at 04:47:09PM +0100, Kieran Bingham wrote: > > On 22/07/2019 18:26, Wolfram Sang wrote: > > > In the general move to have i2c_new_*_device functions which return > > > ERR_PTR instead of NULL, this patch converts

Re: [PATCH] i2c: replace i2c_new_secondary_device with an ERR_PTR variant

On Tue, Jul 23, 2019 at 04:47:09PM +0100, Kieran Bingham wrote: > Hi Wolfram, > > On 22/07/2019 18:26, Wolfram Sang wrote: > > In the general move to have i2c_new_*_device functions which return > > ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device(). > > > > There are only

Re: [PATCH 24/60] drm/panel: Add driver for the Toppology TD043MTEA1 panel

Hi Sam, On Wed, Jul 10, 2019 at 03:09:17PM +0200, Sam Ravnborg wrote: > Hi Laurent. > > I had assumed this driver would look like the other Topology driver, but > they differ a lot. So it makes sense to have different drivers. > > This driver implements suspend/resume. > But the correct way

Re: [PATCHv2 2/3] i915: convert to new mount API

On Thu, 8 Aug 2019, Al Viro wrote: > On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote: > > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote: > > > Though personally I'm averse to managing "f"objects through > > > "m"interfaces, which can get ridiculous (notably,

Re: [PATCH 23/60] drm/panel: Add driver for the Toppology TD028TTEC1 panel

Hi Sam, On Wed, Jul 10, 2019 at 09:48:55AM +0200, Sam Ravnborg wrote: > Hi Laurent. > > This driver looks very good. > > On Sun, Jul 07, 2019 at 09:19:00PM +0300, Laurent Pinchart wrote: > > This panel is used on the OpenMoko Neo FreeRunner and Neo 1973. > > Add info in Kconfig help entry? >

Re: [PATCH v4 00/17] drm: add gem ttm helpers, rework mmap workflow.

On Thu, Aug 08, 2019 at 08:39:11AM -0600, Rob Herring wrote: > On Thu, Aug 8, 2019 at 7:44 AM Gerd Hoffmann wrote: > > > > > > > > Gerd Hoffmann (17): > > drm/ttm: turn ttm_bo_device.vma_manager into a pointer > > drm/ttm: add gem_ttm_bo_device_init() > > drm/vram: switch vram helpers to

[Bug 110865] Rx480 consumes 20w more power in idle than under Windows

https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #11 from Martin --- Kernel 5.3.0-rc3 does not boot on my system It hangs at detecting the discs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel

[Bug 111333] [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* chosen encoder in use 0

https://bugs.freedesktop.org/show_bug.cgi?id=111333 Bug ID: 111333 Summary: [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR* chosen encoder in use 0 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64)

[PATCH] drm/virtio: use virtio_max_dma_size

We must make sure our scatterlist segments are not too big, otherwise we might see swiotlb failures (happens with sev, also reproducable with swiotlb=force). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_object.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)

Re: [PATCH 21/60] drm/panel: Add driver for the Sharp LS037V7DW01 panel

Hi Sam, On Mon, Jul 08, 2019 at 09:44:52PM +0200, Sam Ravnborg wrote: > Hi Laurent. > > Third panel driver in line for review. > Review comments that are duplicates from the first two will have only a > brief remark - if any. I'll address them the same way. Please consider all unanswered

Re: [PULL] drm-misc-next

Hi, On Wed, Aug 07, 2019 at 02:30:25PM +0200, Daniel Vetter wrote: > On Wed, Aug 7, 2019 at 2:02 PM Maxime Ripard > wrote: > > On Tue, Aug 06, 2019 at 06:11:32PM +0200, Daniel Vetter wrote: > > > On Tue, Aug 06, 2019 at 06:01:46PM +0200, Maxime Ripard wrote: > > > > On Tue, Aug 06, 2019 at

[Bug 111332] Long running application causes assert in amdgpu_bo.c 'bo->cpu_map_count > 0' failed

https://bugs.freedesktop.org/show_bug.cgi?id=111332 Bug ID: 111332 Summary: Long running application causes assert in amdgpu_bo.c 'bo->cpu_map_count > 0' failed Product: DRI Version: XOrg git Hardware: x86-64 (AMD64)

Re: 回复：[PATCH v3 1/1] drm/syncobj: add sideband payload

Yeah, the idea is indeed rather clever. I'm just wondering if we don't need to optimize it even more. In other words could some IOCTL overhead be saved here if we directly take the value for binary semaphores waits and signals? Christian. Am 08.08.19 um 17:23 schrieb Zhou, David(ChunMing):

回复：[PATCH v3 1/1] drm/syncobj: add sideband payload

Thank you, I got your mean. when you have sideband payload, you will go into timeline path. Clever! -David 原始邮件 主题：Re: [PATCH v3 1/1] drm/syncobj: add sideband payload 发件人：Lionel Landwerlin 收件人："Zhou, David(ChunMing)" ,dri-de...@freedesktop.org 抄送："Koenig, Christian" ,Jason

Re: [PATCH 20/60] drm/panel: Add driver for the NEC NL8048HL11 panel

Hi Sam, On Mon, Jul 08, 2019 at 09:10:08PM +0200, Sam Ravnborg wrote: > Hi Laurent. > > Thanks for keeping me busy :-) My pleasure ;-) > On Sun, Jul 07, 2019 at 09:18:57PM +0300, Laurent Pinchart wrote: > > This panel is used on the Zoom2/3/3630 SDP boards. > > This information may be good to

[PATCH RFC 15/19] drm/imx: pd: Use bus format/flags provided by the bridge when available

Now that bridges can expose the bus format/flags they expect, we can use those instead of the relying on the display_info provided by the connector (which is only valid if the encoder is directly connected to bridge element driving the panel/display). We also explicitly expose the bus formats

[PATCH RFC 13/19] drm/bridge: Add the drm_bridge_chain_get_prev_bridge() helper

Will be useful for bridge drivers that want to do bus format negotiation with their neighbours. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/drm_bridge.c | 19 +++ include/drm/drm_bridge.h | 2 ++ 2 files changed, 21 insertions(+) diff --git

[PATCH RFC 10/19] drm/bridge: Add a drm_bridge_state object

One of the last remaining object to not have its atomic state. This is being motivated by our attempt to support runtime bus-format negotiation between elements of the bridge chain. This patch just paves the road for such a feature by adding a new drm_bridge_state object inheriting from

[PATCH RFC 14/19] drm/bridge: Add the necessary bits to support bus format negotiation

This takes the form of various helpers, plus the addition of 2 new structs: * drm_bus_caps: describe the bus capabilities of a bridge/encoder. For bridges we have one for the input port and one for the output port. Encoders just have one output port. * drm_bus_cfg: added to the

[PATCH RFC 16/19] drm/bridge: lvds-encoder: Add a way to support custom ->atomic_check() implem

Some LVDS drivers might want to negotiate the bus format with the previous element in the encoder chain. Let's define a chip-specific ops structure that contains an ->atomic_check() hook and plug that to the drm_bridge->atomic_check() infra. Signed-off-by: Boris Brezillon ---

  1   2   3   >