Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression

Hi Thomas, On Tue, Aug 13, 2019 at 05:36:16PM +0800, Feng Tang wrote: > Hi Thomas, > > On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote: > > Hi Thomas, > > > > On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote: > > > Hi, > > > > > > >>Actually we run the benchmark as a backgro

Re: [PATCH v5 1/1] drm/syncobj: add sideband payload

If it is not submitted yet,  Reviewed-by: Chunming Zhou -David On 2019年08月09日 21:43, Lionel Landwerlin wrote: The Vulkan timeline semaphores allow signaling to happen on the point of the timeline without all of the its dependencies to be created. The current 2 implementations (AMD/Intel) of

Re: linux-next: build warning after merge of the drm-misc tree

On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote: > > Hi Stephen. > > On Fri, Aug 16, 2019 at 01:31:32PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the drm-misc tree, today's linux-next build (x86_64 > > allmodconfig) produced this warning: > > > > warning: same module name

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

On Fri, Aug 16, 2019 at 3:00 AM Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 10:49:31PM +0200, Daniel Vetter wrote: > > On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > > > So if someone can explain to me how that

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #101 from ReddestDream --- Grasping at straws a bit here, but it occurred to me that maybe Linux kernel testing on Radeon VII was done on an early VBIOS that didn't have full UEFI support yet. We know that AMD had to issue a VBIOS up

[PATCH] dma-buf: fix a memory leak bug

In sync_file_merge(), 'fences' is firstly allocated through kcalloc(). Later on, if the size is not sufficient, krealloc() is invoked to reallocate 'nfences', which is assigned to 'fences'. However, if krealloc() fails, 'fences' is not deallocated, leading to a memory leak bug. To fix the above is

Re: linux-next: build warning after merge of the drm-misc tree

Hi Stephen. On Fri, Aug 16, 2019 at 01:31:32PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > warning: same module names found: > drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl804

[git pull] drm fixes for 5.3-rc5

Hi Linus, Nothing too crazy this week, one amdgpu fix to use vmalloc for a struct that grew in size, and another MST fix for nouveau, and some other misc fixes. Regards, Dave. drm-fixes-2019-08-16: drm fixes for 5.3-rc5 i915: - single GVT use after free fix scheduler: - entity destruction race

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 5:41 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 01:47:12PM -0700, Dan Williams wrote: > > On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote: > > > > > > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote: > > > > > > > So nor HMM nor driver should

linux-next: build warning after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) produced this warning: warning: same module names found: drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko warning: same module names found:

Re: Linux Kernel 5.2.8 (uvc or i915? <<<)

[adding mailing lists etc. with Nathaniel's test info] On 8/15/19 7:21 PM, Nathaniel Russell wrote: > Well i surpressed the uvcvideo driver and you are right Randy it > definitely is not the uvcvideo driver. There is something going on in > the i915 driver. > > > On 8/15/19, Randy Dunlap wrote

Re: Linux Kernel 5.2.8 (uvc or i915?)

On 8/15/19 6:15 PM, Nathaniel Russell wrote: > I would really like help with the kernel error with my uvcvideo driver. > Hi again. What makes you think that the problem is related to the uvcvideo driver? Does some previous kernel version work correctly? If so, what version(s)? Does this warni

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 10:49:31PM +0200, Daniel Vetter wrote: > On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > > So if someone can explain to me how that works with lockdep I can of > > > course implement it. But afai

Re: [PATCH 09/11] ARM: dts: qcom: pm8941: add 5vs2 regulator node

On Thu, Aug 15, 2019 at 10:34:17AM +0200, Linus Walleij wrote: > On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote: > > > pm8941 is missing the 5vs2 regulator node so let's add it since its > > needed to get the external display working. This regulator was already > > configured in the interrupt

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, 15 Aug 2019 10:44:29 +0200 Michal Hocko wrote: > > I continue to struggle with this. It introduces a new kernel state > > "running preemptibly but must not call schedule()". How does this make > > any sense? > > > > Perhaps a much, much more detailed description of the oom_reaper > > s

[Bug 204181] NULL pointer dereference regression in amdgpu

https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #31 from Sergey Kondakov (virtuous...@gmail.com) --- (In reply to Andrey Grodzovsky from comment #30) > (In reply to Sergey Kondakov from comment #27) > > Sergey, I tried to reproduce you latest issue on Ellsmere (Polaris 10) with > "

Re: [PATCH] mm/hmm: hmm_range_fault handle pages swapped out

On Thu, Aug 15, 2019 at 08:52:56PM +, Yang, Philip wrote: > hmm_range_fault may return NULL pages because some of pfns are equal to > HMM_PFN_NONE. This happens randomly under memory pressure. The reason is > for swapped out page pte path, hmm_vma_handle_pte doesn't update fault > variable from

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #10 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Created attachment 284445 --> https://bugzilla.kernel.org/attachment.cgi?id=284445&action=edit resume_failure.log The kernel OOPS is just a result of previous GFX ring test

[PATCH] mm/hmm: hmm_range_fault handle pages swapped out

hmm_range_fault may return NULL pages because some of pfns are equal to HMM_PFN_NONE. This happens randomly under memory pressure. The reason is for swapped out page pte path, hmm_vma_handle_pte doesn't update fault variable from cpu_flags, so it failed to call hmm_vam_do_fault to swap the page in.

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 08:41:33PM +, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote: > > > So nor HMM nor driver should dereference the struct page (i do not > > think any iommu driver would either), > > Er, they do technically deref the struct page: >

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > So if someone can explain to me how that works with lockdep I can of > > course implement it. But afaics that doesn't exist (I tried to explain > > that somewhere else alrea

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote: > > > So nor HMM nor driver should dereference the struct page (i do not > > think any iommu driver would either), > > Er, they do technically deref the struct page: > > nouvea

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 01:12:22PM -0700, Dan Williams wrote: > On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse wrote: > > > > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote: > > > > > > > > On Wed, Aug 14, 2019 at 07:48:28A

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > So if someone can explain to me how that works with lockdep I can of > course implement it. But afaics that doesn't exist (I tried to explain > that somewhere else already), and I'm no really looking forward to > hacking also on lock

Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 9:35 PM Michal Hocko wrote: > > On Thu 15-08-19 16:18:10, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote: > > > > > This is what you claim and I am saying that fs_reclaim is about a > > > restricted reclaim context and it is an ugly

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: > > The last detail is I'm still unclear what a GFP flags a blockable > > invalidate_range_start() should use. Is GFP_KERNEL OK? > > I hope I will not make this muddy again ;) > invalidate_range_start in the blockable mode can use/depe

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote: > > > > > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > > > > On Wed, Aug 14, 2019 at 6:28 AM Jason

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote: > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote: > > > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote: > > > > > > > > On Wed, Aug 14, 2019 at 09:38:54

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote: > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote: > > > > > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote: > > > > On Tue, Aug 13, 2019 at 06:36:3

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu 15-08-19 16:18:10, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote: > > > This is what you claim and I am saying that fs_reclaim is about a > > restricted reclaim context and it is an ugly hack. It has proven to > > report false positives. Maybe it can

Re: [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

Quoting Chris Wilson (2019-08-15 20:03:13) > Quoting Daniel Vetter (2019-08-15 19:48:42) > > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson > > wrote: > > > Quoting Daniel Vetter (2019-08-14 18:20:53) > > > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > > > > Now that dma_fence

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote: > This is what you claim and I am saying that fs_reclaim is about a > restricted reclaim context and it is an ugly hack. It has proven to > report false positives. Maybe it can be extended to a generic reclaim. > I haven't tried that. D

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

https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #18 from Wiktor Kaczor --- So, I've installed Compton as an alternative compositor on XFCE4 (I disabled the internal one), it works rather well The only problem I could find so far is that the graphics corruption persists when moving

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu 15-08-19 15:24:48, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote: > > On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack

Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings

On Thu, Aug 15, 2019 at 09:06:41PM +0300, Laurent Pinchart wrote: > Hi Greg, > > On Thu, Aug 15, 2019 at 04:53:00PM +0200, Greg Kroah-Hartman wrote: > > On Thu, Aug 15, 2019 at 02:31:26PM +, Fabrizio Castro wrote: > > > On 15 August 2019 15:15, Laurent Pinchart wrote: > > > > On Thu, Aug 15, 2

Re: [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

Quoting Daniel Vetter (2019-08-15 19:48:42) > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2019-08-14 18:20:53) > > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > > > Now that dma_fence_signal always takes the spinlock to flush the > > > > cb_

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 02:27:19PM -0400, Jerome Glisse wrote: > > How exactly? This is holding the page pin, so the only way the VA > > mapping can be changed is via explicit user action. > > > > ie: > > > >gpu_write_something(va, size) > >mmap(.., va, size, MMAP_FIXED); > >gpu_wait_

Re: [PATCH 0/6] drm+dma: cache support for arm, etc

Sorry if the style is messed up, replying from my phone. Am 15.08.2019 20:27 schrieb Christoph Hellwig : On Thu, Aug 15, 2019 at 06:21:00PM +, Koenig, Christian wrote: > > (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead > > of dma_alloc_attrs. The initial differ

Re: [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote: > Quoting Daniel Vetter (2019-08-14 18:20:53) > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > > Now that dma_fence_signal always takes the spinlock to flush the > > > cb_list, simply take the spinlock and call dma_fence_sign

Re: [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked

Quoting Daniel Vetter (2019-08-14 18:20:53) > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > Now that dma_fence_signal always takes the spinlock to flush the > > cb_list, simply take the spinlock and call dma_fence_signal_locked() to > > avoid code repetition. > > > > Suggested-

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 12:19 PM wrote: > > > -Original Message- > > From: Takashi Iwai > > Sent: Thursday, August 15, 2019 9:57 AM > > To: Alex Deucher > > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; > > dri-devel; > > Linux ACPI Mailing List; Alex Hung; Ben

Re: [RFC] drm: Bump encoder limit from 32 to 64

On Thu, Aug 15, 2019 at 8:03 PM Lyude Paul wrote: > > Assuming that GPUs would never have even close to 32 separate video > encoders is quite honestly a pretty reasonable assumption. Unfortunately > we do not live in a reasonable world, as it looks like it is actually > possible to find devices th

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 03:01:59PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 01:39:22PM -0400, Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > > > > > > > I'm not really w

Re: [PATCH 0/6] drm+dma: cache support for arm, etc

Am 15.08.19 um 19:53 schrieb Christoph Hellwig: > On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote: >> On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig wrote: >>> As said before I don't think these low-level helpers are the >>> right API to export, but even if they did you'd just cover

Re: [PATCH v7 1/9] drm_dp_cec: add connector info support.

Reviewed-by: Lyude Paul On Wed, 2019-08-14 at 12:44 +0200, Dariusz Marcinkiewicz wrote: > Pass the connector info to the CEC adapter. This makes it possible > to associate the CEC adapter with the corresponding drm connector. > > Signed-off-by: Dariusz Marcinkiewicz > Signed-off-by: Hans Verkui

Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings

Hi Greg, On Thu, Aug 15, 2019 at 04:53:00PM +0200, Greg Kroah-Hartman wrote: > On Thu, Aug 15, 2019 at 02:31:26PM +, Fabrizio Castro wrote: > > On 15 August 2019 15:15, Laurent Pinchart wrote: > > > On Thu, Aug 15, 2019 at 04:04:00PM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Aug 15, 201

[RFC] drm: Bump encoder limit from 32 to 64

Assuming that GPUs would never have even close to 32 separate video encoders is quite honestly a pretty reasonable assumption. Unfortunately we do not live in a reasonable world, as it looks like it is actually possible to find devices that will create more drm_encoder objects then this. Case in po

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote: > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote: > > > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote: > > > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote: > > > > Section alignment constraint

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 01:39:22PM -0400, Jerome Glisse wrote: > On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > > > > > I'm not really well versed in the details of our userptr, but both > > > amdgpu and i915 wa

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote: > On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > > __GFP_DIRECT_RECLAIM.. > > > > > >

[Bug 111211] Kernel 5.2.2+ introduced tearing, corruption and freezes with Raven Ridge 2500U

https://bugs.freedesktop.org/show_bug.cgi?id=111211 Bráulio Barros de Oliveira changed: What|Removed |Added Summary|Kernel 5.2.2 introduced |Kernel 5.2.2+ introduced

[Bug 111211] Kernel 5.2.2 introduced tearing, corruption and freezes with Raven Ridge 2500U

https://bugs.freedesktop.org/show_bug.cgi?id=111211 Bráulio Barros de Oliveira changed: What|Removed |Added Status|RESOLVED|REOPENED Resolutio

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, 15 Aug 2019 18:19:52 +0200, wrote: > > > -Original Message- > > From: Takashi Iwai > > Sent: Thursday, August 15, 2019 9:57 AM > > To: Alex Deucher > > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; > > dri-devel; > > Linux ACPI Mailing List; Alex Hung;

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

On Tue, Aug 13, 2019 at 05:58:52PM -0400, Jerome Glisse 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 t

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > __GFP_DIRECT_RECLAIM.. > > > > > > This matches the existing test in __need_fs_reclaim() - so if you are >

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > > > I'm not really well versed in the details of our userptr, but both > > amdgpu and i915 wait for the gpu to complete from > > invalidate_range_start. Jerome has at

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > I'm not really well versed in the details of our userptr, but both > amdgpu and i915 wait for the gpu to complete from > invalidate_range_start. Jerome has at least looked a lot at the amdgpu > one, so maybe he can explain what exact

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 07:21:47PM +0200, Daniel Vetter wrote: > On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote: > > > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 04:4

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > > > > > You have to wait for the

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 01:11:56PM -0400, Jerome Glisse wrote: > On Thu, Aug 15, 2019 at 01:56:31PM -0300, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > > __GFP_DIRECT_RECLA

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote: > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > > > You have to wait for the gpu to finnish current processing in > > > invalidate_range_start.

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 01:56:31PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > __GFP_DIRECT_RECLAIM.. > > > > > > This matches the existing test in __need_fs_reclaim() -

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > __GFP_DIRECT_RECLAIM.. > > > > This matches the existing test in __need_fs_reclaim() - so if you are > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compac

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > You have to wait for the gpu to finnish current processing in > > invalidate_range_start. Otherwise there's no point to any of this > > really. So the wait_event/

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 5:10 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > You have to wait for the gpu to finnish current processing in > > invalidate_range_start. Otherwise there's no point to any of this > > really. So the wait_event/dma_fenc

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu 15-08-19 11:12:19, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 03:21:27PM +0200, Michal Hocko wrote: > > On Thu 15-08-19 09:23:44, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 08:58:29AM +0200, Daniel Vetter wrote: > > > > On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorp

RE: [PATCH v2 4/9] drm/timings: Add link flags

Hi Laurent, Thank you for the feedback! I think we need to come a conclusion on here: https://patchwork.kernel.org/patch/11095547/ before taking the comments on this patch any further. Thanks, Fab > From: Laurent Pinchart > Sent: 15 August 2019 13:00 > Subject: Re: [PATCH v2 4/9] drm/timings:

RE: [PATCH v2 7/9] drm: rcar-du: lvds: Add dual-LVDS panels support

Hello Laurent, Thank you for your feedback! > From: linux-renesas-soc-ow...@vger.kernel.org > On Behalf Of Laurent Pinchart > Sent: 15 August 2019 14:09 > Subject: Re: [PATCH v2 7/9] drm: rcar-du: lvds: Add dual-LVDS panels support > > Hi Fabrizio, > > Thank you for the patch. > > On Thu, Au

Re: [PATCH] drm/amdgpu: Apply flags after amdgpu_device_ip_init()

On Thu, Aug 15, 2019 at 10:59 AM Kai-Heng Feng wrote: > > at 21:33, Deucher, Alexander wrote: > > > Thanks for finding this! I think the attached patch should fix the issue > > and it's much less invasive. > > Yes it also fix the issue, please add by tested-by: > Tested-by: Kai-Heng Feng > Tha

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > You have to wait for the gpu to finnish current processing in > invalidate_range_start. Otherwise there's no point to any of this > really. So the wait_event/dma_fence_wait are unavoidable really. I don't envy your task :| But, wha

RE: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings

Hi Greg, hi Laurent, Thank you for your feedback! > From: Greg Kroah-Hartman > Sent: 15 August 2019 15:53 > Subject: Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings > > On Thu, Aug 15, 2019 at 02:31:26PM +, Fabrizio Castro wrote: > > Hi Greg, hi Laurent, > > > > Thank you f

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 10:37 AM Alex Deucher wrote: > > On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst wrote: > > > > On Thu, Aug 15, 2019 at 4:20 PM wrote: > > > > > > > > There are definitely going to be regressions on machines in the field > > > > > with the > > > > > in tree drivers by reve

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, 15 Aug 2019 16:37:05 +0200, Alex Deucher wrote: > > On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst wrote: > > > > On Thu, Aug 15, 2019 at 4:20 PM wrote: > > > > > > > > There are definitely going to be regressions on machines in the field > > > > > with the > > > > > in tree drivers by r

Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings

On Thu, Aug 15, 2019 at 02:31:26PM +, Fabrizio Castro wrote: > Hi Greg, hi Laurent, > > Thank you for your feedback! > > > From: linux-kernel-ow...@vger.kernel.org > > On Behalf Of Laurent Pinchart > > Sent: 15 August 2019 15:15 > > Subject: Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings

RE: [PATCH v2 5/9] drm/panel: Add timings field to drm_panel

Hi Sam, Thank you for your feedback! > From: Sam Ravnborg > Sent: 15 August 2019 15:14 > Subject: Re: [PATCH v2 5/9] drm/panel: Add timings field to drm_panel > > Hi Fabrizio > > On Thu, Aug 15, 2019 at 12:04:29PM +0100, Fabrizio Castro wrote: > > We need to know if the panel supports dual-lin

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 4:38 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 03:12:11PM +0200, Daniel Vetter wrote: > > On Thu, Aug 15, 2019 at 3:04 PM Jason Gunthorpe wrote: > > > > > > On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote: > > > > > > > As the oom reaper is the pri

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 10:30 AM wrote: > > > On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst wrote: > > > > > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher > > wrote: > > > > > > > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst > > > > wrote: > > > > > > > > > > On Thu, Aug 15, 2019 at 3:56 P

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 03:12:11PM +0200, Daniel Vetter wrote: > On Thu, Aug 15, 2019 at 3:04 PM Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote: > > > > > As the oom reaper is the primary guarantee of the oom handling forward > > > progress it cannot be

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst wrote: > > On Thu, Aug 15, 2019 at 4:20 PM wrote: > > > > > > There are definitely going to be regressions on machines in the field > > > > with the > > > > in tree drivers by reverting this. I think we should have an answer > > > > for all of > >

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 4:34 PM wrote: > > > -Original Message- > > From: Karol Herbst > > Sent: Thursday, August 15, 2019 9:25 AM > > To: Limonciello, Mario > > Cc: Dave Airlie; LKML; Linux ACPI Mailing List; dri-devel; nouveau; Rafael > > J . > > Wysocki; Alex Hung; Ben Skeggs; David A

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 4:30 PM wrote: > > > On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst wrote: > > > > > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher > > wrote: > > > > > > > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst > > > > wrote: > > > > > > > > > > On Thu, Aug 15, 2019 at 3:56 PM

RE: [PATCH v2 0/9] Add dual-LVDS panel support to EK874

Hi Sam, Thank you for your feedback! > From: Sam Ravnborg > Sent: 15 August 2019 15:16 > Subject: Re: [PATCH v2 0/9] Add dual-LVDS panel support to EK874 > > Hi Fabrizio > > > it appears that Rob has been busy converting the dt-bindings relevant to > > this > > series, and his changes are now

Re: [Bug 204407] New: Bad page state in process Xorg

On 8/3/19 1:29 AM, Petr Vandrovec wrote: > On Fri, Aug 2, 2019, 3:59 PM Matthew Wilcox > wrote: > > That doesn't help because we call reset_page_owner() in the free > page path. > > We could turn on tracing because we call trace_mm_page_free() in this >

RE: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings

Hi Greg, hi Laurent, Thank you for your feedback! > From: linux-kernel-ow...@vger.kernel.org > On Behalf Of Laurent Pinchart > Sent: 15 August 2019 15:15 > Subject: Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings > > Hi Greg, > > On Thu, Aug 15, 2019 at 04:04:00PM +0200, Greg

Re: [PATCH 1/4] drm/radeon: handle PCIe root ports with addressing limitations

Am 15.08.19 um 16:15 schrieb Alex Deucher: > On Thu, Aug 15, 2019 at 4:34 AM Koenig, Christian > wrote: >> Am 15.08.19 um 09:27 schrieb Christoph Hellwig: >>> radeon uses a need_dma32 flag to indicate to the drm core that some >>> allocations need to be done using GFP_DMA32, but it only checks the

[Bug 110886] After S3 resume, kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:57:crtc-0] flip_done timed out

https://bugs.freedesktop.org/show_bug.cgi?id=110886 --- Comment #12 from Kai-Heng Feng --- > Now it always shows PSP fail. I've dug up more info about this issue. It always times out in psp_cmd_submit_buf(). Particularly, this code section: while (*((unsigned int *)psp->fence_buf) != ind

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 4:20 PM wrote: > > > > There are definitely going to be regressions on machines in the field > > > with the > > > in tree drivers by reverting this. I think we should have an answer for > > > all of > > those > > > before this revert is accepted. > > > > > > Regarding sy

[Bug 110886] After S3 resume, kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:57:crtc-0] flip_done timed out

https://bugs.freedesktop.org/show_bug.cgi?id=110886 --- Comment #11 from Kai-Heng Feng --- (In reply to Samantha McVey from comment #10) > I am getting this same issue (at least I believe the same). It is in the 5.2 > series but not in the 5.1 series of the kernel. If needed I can post my > logs.

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst wrote: > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher wrote: > > > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst wrote: > > > > > > On Thu, Aug 15, 2019 at 3:56 PM wrote: > > > > > > > > > -Original Message- > > > > > From: linux-acpi-ow

Re: [PATCH v2 0/9] Add dual-LVDS panel support to EK874

Hi Fabrizio > it appears that Rob has been busy converting the dt-bindings relevant to this > series, and his changes are now found in linux-next. Most notably > Documentation/devicetree/bindings/display/panel/panel-lvds.txt has now become > Documentation/devicetree/bindings/display/panel/lvds.yam

Re: [PATCH 1/4] drm/radeon: handle PCIe root ports with addressing limitations

On Thu, Aug 15, 2019 at 4:34 AM Koenig, Christian wrote: > > Am 15.08.19 um 09:27 schrieb Christoph Hellwig: > > radeon uses a need_dma32 flag to indicate to the drm core that some > > allocations need to be done using GFP_DMA32, but it only checks the > > device addressing capabilities to make th

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher wrote: > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst wrote: > > > > On Thu, Aug 15, 2019 at 3:56 PM wrote: > > > > > > > -Original Message- > > > > From: linux-acpi-ow...@vger.kernel.org > > > > On > > > > Behalf Of Dave Airlie > > > > S

Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings

Hi Greg, On Thu, Aug 15, 2019 at 04:04:00PM +0200, Greg Kroah-Hartman wrote: > On Thu, Aug 15, 2019 at 04:18:38PM +0300, Laurent Pinchart wrote: > > Hi Fabrizio, > > > > (CC'ing Greg as the architect of the SPDX move) > > _one of_, not the one that did the most of he work, that would be Thomas :

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst wrote: > > On Thu, Aug 15, 2019 at 3:56 PM wrote: > > > > > -Original Message- > > > From: linux-acpi-ow...@vger.kernel.org > > > On > > > Behalf Of Dave Airlie > > > Sent: Wednesday, August 14, 2019 5:48 PM > > > To: Karol Herbst > > > Cc:

Re: [PATCH v2 5/9] drm/panel: Add timings field to drm_panel

Hi Fabrizio On Thu, Aug 15, 2019 at 12:04:29PM +0100, Fabrizio Castro wrote: > We need to know if the panel supports dual-link, similarly > to bridges, therefore add a reference to drm_timings in > drm_panel. Why do we need to know this? Why is it needed in drm_panel and not in some driver specif

Re: [PATCH 2/5] kernel.h: Add non_block_start/end()

On Thu, Aug 15, 2019 at 03:21:27PM +0200, Michal Hocko wrote: > On Thu 15-08-19 09:23:44, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 08:58:29AM +0200, Daniel Vetter wrote: > > > On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote: > > > > On Wed, Aug 14, 2019 at 10:20:24PM +0200

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 12:47 AM Dave Airlie wrote: > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote: > > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c. > > > > The original commit message didn't even make sense. AMD _does_ support it > > and > > it works with Nouveau as w

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 3:56 PM wrote: > > > -Original Message- > > From: linux-acpi-ow...@vger.kernel.org On > > Behalf Of Dave Airlie > > Sent: Wednesday, August 14, 2019 5:48 PM > > To: Karol Herbst > > Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; Alex Hung; Ben > > Sk

Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings

On Thu, Aug 15, 2019 at 04:18:38PM +0300, Laurent Pinchart wrote: > Hi Fabrizio, > > (CC'ing Greg as the architect of the SPDX move) _one of_, not the one that did the most of he work, that would be Thomas :) > On Thu, Aug 15, 2019 at 12:04:27PM +0100, Fabrizio Castro wrote: > > The information

Re: DMA-API: cacheline tracking ENOMEM, dma-debug disabled due to nouveau ?

On 15/08/2019 14:35, Christoph Hellwig wrote: On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: Hello Since lot of release (at least since 4.19), I hit the following error message: DMA-API: cacheline tracking ENOMEM,

  1   2   >