Hi Christoph,
Thanks for your comments. I'm also replying here to your comments on the
previous series.
On Tuesday, March 17, 2020 10:28:35 AM EDT Christoph Hellwig wrote:
> Any reason drivers can't just use pci_map_rom insteadἅ which already
> does the right thing?
Some machines don't expose
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
From: Lyude Paul
We're finally getting CRC support in nouveau, so let's start testing
this in igt as well! While the normal CRC capture tests are nice,
there's a number of Nvidia-specific hardware characteristics that we
need to test as well.
The most important one is known as a "notifier
From: Lyude Paul
Nvidia display hardware provides a set of flexible dithering options for
CRTCs. This dithering is actually noticeable in the CRC output for all
available tap points, and can be seen as CRC values for identical frames
cycling between either 2 or 4 values repeatedly (each one of
From: Lyude Paul
Like igt_assert_fd(), but using igt_require() instead
Signed-off-by: Lyude Paul
---
lib/igt_core.h | 12
1 file changed, 12 insertions(+)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index fae5f59e..b66336cf 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@
From: Lyude Paul
Nouveau has finally gotten CRC support, hooray! Well, it's under review
at least:
https://patchwork.freedesktop.org/series/74804/
(it has a cover letter, but nouveau's mailing list configuration has
blocked the email so I'm waiting for a moderator to fix that)
So, this series
From: Lyude Paul
Like igt_debugfs_connector_dir(), but for pipes instead.
Signed-off-by: Lyude Paul
---
lib/igt_debugfs.c | 29 +
lib/igt_debugfs.h | 1 +
2 files changed, 30 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index
From: Lyude Paul
I ended up hitting some bugs when writing nouveau's CRC implementation
due to incorrectly handling the situation where we disable CRCs on a
pipe that already been disabled, which ended up causing some other vague
igt issues when running certain tests in multi-mode.
So, let's
From: Lyude Paul
Signed-off-by: Lyude Paul
---
tests/kms_pipe_crc_basic.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index d169b7bd..f121e27e 100644
--- a/tests/kms_pipe_crc_basic.c
+++
From: Lyude Paul
There's been a TODO sitting in the kms_plane test suite for a while now
as a placeholder for actually generating a reference CRC for
plane-position-hole tests. This means we have never actually been
verifying whether or not partially covering our hole with a hardware
plane works
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6
From: Ville Syrjälä
Add some kind of vblank workers. The interface is similar to regular
delayed works, and also allows for re-scheduling.
Whatever hardware programming we do in the work must be fast
(must at least complete during the vblank, sometimes during
the first few scanlines of vblank),
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
No functional changes
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 9a9a7f5003d3..0d42a7e5deff
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 0d42a7e5deff..9fb00c4b9764 100644
---
This function doesn't exist
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_bios.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.h
b/drivers/gpu/drm/nouveau/nouveau_bios.h
index 18eb061ccafb..5495f004a297 100644
---
On 3/17/20 5:59 AM, Christoph Hellwig wrote:
On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
I've been using v7 of Ralph's tester and it is working well - it has
DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
you able?
This hunk seems trivial enough to
On 3/17/20 4:56 AM, Jason Gunthorpe wrote:
On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote:
The reason for it being backwards is that "normally" a device doesn't want
the device private page to be faulted back to system memory, it wants to
get the device private struct page so
On 3/17/20 12:34 AM, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote:
On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Remove the code to fault device private pages back into system memory
that has never been used by any driver. Also replace the usage of
On Tue, Mar 17, 2020 at 01:59:55PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
> > I've been using v7 of Ralph's tester and it is working well - it has
> > DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
> > you able?
>
On Fri, Mar 13, 2020 at 06:22:58PM -0400, Mikel Rychliski wrote:
> /**
> + * pci_platform_rom - ioremap() the ROM image provided by the platform
> * @pdev: pointer to pci device struct
> * @size: pointer to receive size of pci window over ROM
> + *
> + * Return: kernel virtual pointer to
On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
> I've been using v7 of Ralph's tester and it is working well - it has
> DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
> you able?
>
> This hunk seems trivial enough to me, can we include it now?
I can send
On Tue, Mar 17, 2020 at 01:28:13PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote:
> > On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote:
> > > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a
> > > > driver
On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote:
> > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a
> > > driver can
> > > look at the struct page but what if a driver needs to fault in a
On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote:
> > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a driver
> > can
> > look at the struct page but what if a driver needs to fault in a page from
> > another device's private memory? Should it call
On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote:
>
> On 3/16/20 12:32 PM, Christoph Hellwig wrote:
> > Remove the code to fault device private pages back into system memory
> > that has never been used by any driver. Also replace the usage of the
> > HMM_PFN_DEVICE_PRIVATE flag in
On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote:
> The reason for it being backwards is that "normally" a device doesn't want
> the device private page to be faulted back to system memory, it wants to
> get the device private struct page so it can update its page table to point
>
On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote:
> On 3/16/20 12:32 PM, Christoph Hellwig wrote:
>> Remove the code to fault device private pages back into system memory
>> that has never been used by any driver. Also replace the usage of the
>> HMM_PFN_DEVICE_PRIVATE flag in the
34 matches
Mail list logo
