On Thu, Aug 15, 2019 at 1:35 AM Alex Hung wrote:
>
> On Wed, Aug 14, 2019 at 3:31 PM Karol Herbst wrote:
> >
> > This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291.
> >
> > This was never discussed with anybody Nouveau related and we would have
> > NACKed
> > this change immediately.
>
On 8/14/19 12:59 AM, Christoph Hellwig wrote:
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which starts revamping the
migrate_vma functionality. The prime idea is to export three slightly
lower level functions and thus avoid the need for migrate_vma_ops
callbacks.
Diffsta
On Wed, Aug 14, 2019 at 3:31 PM Karol Herbst wrote:
>
> This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291.
>
> This was never discussed with anybody Nouveau related and we would have NACKed
> this change immediately.
>
> We have a better workaround, which makes it actually work with Nou
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 well.
>
> Also what was the issue being solved here? No references to any
https://bugs.freedesktop.org/show_bug.cgi?id=111392
Giuseppe Lumia changed:
What|Removed |Added
Summary|[NV110] bus: MMIO read of |[NV117] bus: MMIO read of
Thanks for the series of fixes. I will check whether these fixes work
on the original intended systems.
On Wed, Aug 14, 2019 at 3:31 PM Karol Herbst wrote:
>
> This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
>
> The original commit message didn't even make sense. AMD _does_ support
v2: fixed compilation error
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
CC: Alex Hung
CC: Rafael J. Wysocki
CC: Dave Airlie
CC: Lyude Paul
CC: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c| 8
2 f
Apperantly things go south if we suspend the device with a different PCIE
link speed set than it got booted with. Fixes runtime suspend on my gp107.
This all looks like some bug inside the pci subsystem and I would prefer a
fix there instead of nouveau, but maybe there is no real nice way of doing
This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
The original commit message didn't even make sense. AMD _does_ support it and
it works with Nouveau as well.
Also what was the issue being solved here? No references to any bugs and not
even explaining any issue at all isn't the way we
Signed-off-by: Karol Herbst
CC: Alex Hung
CC: Rafael J. Wysocki
CC: Dave Airlie
CC: Lyude Paul
CC: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
inde
This reverts commit 887532ca7ca59fcf0547a79211756791128030a3.
We have a better solution for this: b516ea586d717
And same as with the last commit: "NVidia Linux driver" that's Nouveau, any
out of tree driver does _not_ matter. And with Nouveau all of this works even
though it required a proper fix
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
CC: Alex Hung
CC: Rafael J. Wysocki
CC: Dave Airlie
CC: Lyude Paul
CC: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c | 8
drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++
drivers/gpu/drm/nouveau/n
This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291.
This was never discussed with anybody Nouveau related and we would have NACKed
this change immediately.
We have a better workaround, which makes it actually work with Nouveau. No idea
why the comment mentions the Nvidia driver and assu
First three patches are removing ACPI workarounds which should have never
landed.
The last four are adding a workaround to nouveau which seem to help quite
a lot with the RTD3 issues with Nouveau, so let's discuss and get wider
testing of those and see if there is any fallout or laptops where the
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, dma-debug disabled
>
> After hitting that, I try to check who is creating so many DMA mapping and
> see
Hello
Since lot of release (at least since 4.19), I hit the following error message:
DMA-API: cacheline tracking ENOMEM, dma-debug disabled
After hitting that, I try to check who is creating so many DMA mapping and see:
cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c
6 a
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 constraints somewhat save us here. The only example
> > > I can think of a PMD not
On 8/14/19 2:59 AM, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of boilerplate code as-is, and
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 constraints somewhat save us here. The only example
> > I can think of a PMD not containing a uniform pgmap association for
> > each pte is the ca
On Wed, Aug 14, 2019 at 7:37 AM Ralph Corderoy wrote:
>
> Hi Ilia,
>
> A fortnight ago, you wrote:
> > > The video plays, CPU load is less (my aim), but there's ‘tearing’ of
> > > the picture as if small rectangles that are updates are appearing in
> > > the wrong location, off by a little. If I
Hi Ilia,
A fortnight ago, you wrote:
> > The video plays, CPU load is less (my aim), but there's ‘tearing’ of
> > the picture as if small rectangles that are updates are appearing in
> > the wrong location, off by a little. If I step through the frames
> > with mpv's ‘.’ and ‘,’ then I've found a
This series updates DRM drivers to use new CEC notifier API.
Changes since v6:
Made CEC notifiers' registration and de-registration symmetric
in tda998x and dw-hdmi drivers. Also, accidentally dropped one
patch in v6 (change to drm_dp_cec), brought it back now.
Changes sinc
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 Verkuil
Tested-by: Hans Verkuil
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/
Hi,
> > Changing the order doesn't look hard. Patch attached (untested, have no
> > test hardware). But maybe I missed some detail ...
>
> I came up with something very similar by splitting up nouveau_bo_new()
> into allocation and initialization steps, so that when necessary the GEM
> object
On Wed, Aug 14, 2019 at 07:58:27AM +0200, Gerd Hoffmann wrote:
> > Hi Gerd,
> >
> > I've been seeing a regression on Nouveau with recent linux-next releases
> > and git bisect points at this commit as the first bad one. If I revert
> > it (there's a tiny conflict with a patch that was merged subse
Factor out the end of fencing logic from the two migration routines.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/n
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, although the structure of
the main worker function ma
CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper
devic private memory support. Remove the option and just check for
CONFIG_DEVICE_PRIVATE instead.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/Kconfig | 1 -
mm/Kconfig | 3 ---
mm/migrate
nouveau_dmem_migrate_vma and nouveau_dmem_convert_pfn are only called
when CONFIG_DRM_NOUVEAU_SVM is enabled, so there is no need to provide
!CONFIG_DRM_NOUVEAU_SVM stubs for them.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.h | 11 ---
1 file changed, 11 de
Factor the main copy page to vram routine out into a helper that acts
on a single page and which doesn't require the nouveau_dmem_migrate
structure for argument passing. As an added benefit the new version
only allocates the dma address array once and reuses it for each
subsequent chunk of work.
Now that we can rely errors in the normal control flow there is no
need for this flag, remove it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 1
No one ever checks this flag, and we could easily get that information
from the page if needed.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
include/linux/migrate.h| 1 -
mm/migrate.c |
When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouve
There isn't any good reason to pass callbacks to migrate_vma. Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks. This removes a lot
of boilerplate code as-is, and will allow the drivers to drastically
improve code flo
Factor out the repeated device memory address calculation into
a helper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouve
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which starts revamping the
migrate_vma functionality. The prime idea is to export three slightly
lower level functions and thus avoid the need for migrate_vma_ops
callbacks.
Diffstat:
7 files changed, 282 insertions(+), 614 de
On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote:
> Section alignment constraints somewhat save us here. The only example
> I can think of a PMD not containing a uniform pgmap association for
> each pte is the case when the pgmap overlaps normal dram, i.e. shares
> the same 'struct memo
37 matches
Mail list logo
