from:"Roy Spliet"

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

2021-04-13 Thread Roy Spliet


Op 13-04-2021 om 10:48 schreef Karol Herbst:

On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet  wrote:


Op 13-04-2021 om 01:10 schreef Karol Herbst:

On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet  wrote:


Hello Aaron,

Thanks for your insights. A follow-up query and some observations in-line.

Op 12-04-2021 om 20:06 schreef Aaron Plattner:

On 4/10/21 1:48 PM, Roy Spliet wrote:

Op 10-04-2021 om 20:23 schreef Lukas Wunner:

On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:

Can I ask someone with more
technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm
about
the possible challenges of nouveau taking matters into its own hand
rather
than keeping this PCI quirk around?


It sounds to me like the HDA is not powered if no cable is plugged in.
What is reponsible then for powering it up or down, firmware code on
the GPU or in the host's BIOS?


Sometimes the BIOS, but definitely unconditionally the PCI quirk code:
https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289

(CC Aaron Plattner)


My basic understanding is that the audio function stops responding
whenever the graphics function is powered off. So the requirement here
is that the audio driver can't try to talk to the audio function while
the graphics function is asleep, and must trigger a graphics function
wakeup before trying to communicate with the audio function.


I believe that vgaswitcheroo takes care of this for us.



yeah, and also: why would the driver want to do stuff? If the GPU is
turned off, there is no point in communicating with the audio device
anyway. The driver should do the initial probe and leave the device be
unless it's actively used. Also there is no such thing as "use the
audio function, but not the graphics one"


I think
there are also requirements about the audio function needing to be awake
when the graphics driver is updating the ELD, but I'm not sure.



well, it's one physical device anyway, so technically the audio
function is powered on.


This is harder on Windows because the audio driver lives in its own
little world doing its own thing but on Linux we can do better.


Ideally, we should try to find out how to control HDA power from the
operating system rather than trying to cooperate with whatever firmware
is doing.  If we have that capability, the OS should power the HDA up
and down as it sees fit.


After system boot, I don't think there's any firmware involved, but I'm
not super familiar with the low-level details and it's possible the
situation changed since I last looked at it.

I think the problem with having nouveau write this quirk is that the
kernel will need to re-probe the PCI device to notice that it has
suddenly become a multi-function device with an audio function, and
hotplug the audio driver. I originally looked into trying to do that but
it was tricky because the PCI subsystem didn't really have a mechanism
for a single-function device to become a multi-function device on the
fly and it seemed easier to enable it early on during bus enumeration.
That way the kernel sees both functions all the time without anything
else having to be special about this configuration.


Well, we do have this pci/quirk.c thing, no? Nouveau does flip the
bit, but I am actually not sure if that's even doing something
anymore. Maybe in the runtime_resume case it's still relevant but not
sure _when_ DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY is triggered, it does
seem to be called even in the runtime_resume case though.



Right, so for a little more context: a while ago I noticed that my
laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems
legit, given how this GPU has no displays attached; they're all hooked
up to the Intel integrated GPU. That threw off the snd_hda_intel
mid-probe, and as a result didn't permit runpm, keeping the entire GPU,
PCIe bus and thus the CPU package awake. A bit of hackerly later we
decided to continue probing without a codec, and now my laptop is happy,
but...
A new problem popped up with several other NVIDIA GPUs that expose their
HDA subdevice, but somehow its inaccessible. Relevant lines from a
users' log:

[3.031222] MXM: GUID detected in BIOS
[3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index
(0x3) is beyond end of object (length 0x0) (20200925/exoparg2-393)
[3.031352] ACPI Error: Aborting method \_SB.PCI0.GFX0._DSM due to
previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529)
[3.031419] ACPI: \_SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b)
[3.031424] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
[3.031619] pci :00:02.0: optimus capabilities: enabled, status
dynamic power,
[3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index
(0x3) is beyond end of object (length 0x0) (20200925/exoparg2-393)

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

2021-04-13 Thread Roy Spliet


Op 13-04-2021 om 01:10 schreef Karol Herbst:

On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet  wrote:


Hello Aaron,

Thanks for your insights. A follow-up query and some observations in-line.

Op 12-04-2021 om 20:06 schreef Aaron Plattner:

On 4/10/21 1:48 PM, Roy Spliet wrote:

Op 10-04-2021 om 20:23 schreef Lukas Wunner:

On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:

Can I ask someone with more
technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm
about
the possible challenges of nouveau taking matters into its own hand
rather
than keeping this PCI quirk around?


It sounds to me like the HDA is not powered if no cable is plugged in.
What is reponsible then for powering it up or down, firmware code on
the GPU or in the host's BIOS?


Sometimes the BIOS, but definitely unconditionally the PCI quirk code:
https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289

(CC Aaron Plattner)


My basic understanding is that the audio function stops responding
whenever the graphics function is powered off. So the requirement here
is that the audio driver can't try to talk to the audio function while
the graphics function is asleep, and must trigger a graphics function
wakeup before trying to communicate with the audio function.


I believe that vgaswitcheroo takes care of this for us.



yeah, and also: why would the driver want to do stuff? If the GPU is
turned off, there is no point in communicating with the audio device
anyway. The driver should do the initial probe and leave the device be
unless it's actively used. Also there is no such thing as "use the
audio function, but not the graphics one"


I think
there are also requirements about the audio function needing to be awake
when the graphics driver is updating the ELD, but I'm not sure.



well, it's one physical device anyway, so technically the audio
function is powered on.


This is harder on Windows because the audio driver lives in its own
little world doing its own thing but on Linux we can do better.


Ideally, we should try to find out how to control HDA power from the
operating system rather than trying to cooperate with whatever firmware
is doing.  If we have that capability, the OS should power the HDA up
and down as it sees fit.


After system boot, I don't think there's any firmware involved, but I'm
not super familiar with the low-level details and it's possible the
situation changed since I last looked at it.

I think the problem with having nouveau write this quirk is that the
kernel will need to re-probe the PCI device to notice that it has
suddenly become a multi-function device with an audio function, and
hotplug the audio driver. I originally looked into trying to do that but
it was tricky because the PCI subsystem didn't really have a mechanism
for a single-function device to become a multi-function device on the
fly and it seemed easier to enable it early on during bus enumeration.
That way the kernel sees both functions all the time without anything
else having to be special about this configuration.


Well, we do have this pci/quirk.c thing, no? Nouveau does flip the
bit, but I am actually not sure if that's even doing something
anymore. Maybe in the runtime_resume case it's still relevant but not
sure _when_ DECLARE_PCI_FIXUP_CLASS_RESUME_EARLY is triggered, it does
seem to be called even in the runtime_resume case though.



Right, so for a little more context: a while ago I noticed that my
laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems
legit, given how this GPU has no displays attached; they're all hooked
up to the Intel integrated GPU. That threw off the snd_hda_intel
mid-probe, and as a result didn't permit runpm, keeping the entire GPU,
PCIe bus and thus the CPU package awake. A bit of hackerly later we
decided to continue probing without a codec, and now my laptop is happy,
but...
A new problem popped up with several other NVIDIA GPUs that expose their
HDA subdevice, but somehow its inaccessible. Relevant lines from a
users' log:

[3.031222] MXM: GUID detected in BIOS
[3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index
(0x3) is beyond end of object (length 0x0) (20200925/exoparg2-393)
[3.031352] ACPI Error: Aborting method \_SB.PCI0.GFX0._DSM due to
previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529)
[3.031419] ACPI: \_SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b)
[3.031424] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
[3.031619] pci :00:02.0: optimus capabilities: enabled, status
dynamic power,
[3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index
(0x3) is beyond end of object (length 0x0) (20200925/exoparg2-393)
[3.031731] ACPI Error: Aborting method \_SB.PCI0.GFX0._DSM due to
previous error (AE_AML_PACKAGE_LIMIT)

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

2021-04-12 Thread Roy Spliet


Hello Aaron,

Thanks for your insights. A follow-up query and some observations in-line.

Op 12-04-2021 om 20:06 schreef Aaron Plattner:

On 4/10/21 1:48 PM, Roy Spliet wrote:

Op 10-04-2021 om 20:23 schreef Lukas Wunner:

On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:

Can I ask someone with more
technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm 
about
the possible challenges of nouveau taking matters into its own hand 
rather

than keeping this PCI quirk around?


It sounds to me like the HDA is not powered if no cable is plugged in.
What is reponsible then for powering it up or down, firmware code on
the GPU or in the host's BIOS?


Sometimes the BIOS, but definitely unconditionally the PCI quirk code: 
https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289


(CC Aaron Plattner)


My basic understanding is that the audio function stops responding 
whenever the graphics function is powered off. So the requirement here 
is that the audio driver can't try to talk to the audio function while 
the graphics function is asleep, and must trigger a graphics function 
wakeup before trying to communicate with the audio function.


I believe that vgaswitcheroo takes care of this for us.

I think 
there are also requirements about the audio function needing to be awake 
when the graphics driver is updating the ELD, but I'm not sure.


This is harder on Windows because the audio driver lives in its own 
little world doing its own thing but on Linux we can do better.



Ideally, we should try to find out how to control HDA power from the
operating system rather than trying to cooperate with whatever firmware
is doing.  If we have that capability, the OS should power the HDA up
and down as it sees fit.


After system boot, I don't think there's any firmware involved, but I'm 
not super familiar with the low-level details and it's possible the 
situation changed since I last looked at it.


I think the problem with having nouveau write this quirk is that the 
kernel will need to re-probe the PCI device to notice that it has 
suddenly become a multi-function device with an audio function, and 
hotplug the audio driver. I originally looked into trying to do that but 
it was tricky because the PCI subsystem didn't really have a mechanism 
for a single-function device to become a multi-function device on the 
fly and it seemed easier to enable it early on during bus enumeration. 
That way the kernel sees both functions all the time without anything 
else having to be special about this configuration.


Right, so for a little more context: a while ago I noticed that my 
laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems 
legit, given how this GPU has no displays attached; they're all hooked 
up to the Intel integrated GPU. That threw off the snd_hda_intel 
mid-probe, and as a result didn't permit runpm, keeping the entire GPU, 
PCIe bus and thus the CPU package awake. A bit of hackerly later we 
decided to continue probing without a codec, and now my laptop is happy, 
but...
A new problem popped up with several other NVIDIA GPUs that expose their 
HDA subdevice, but somehow its inaccessible. Relevant lines from a 
users' log:


[3.031222] MXM: GUID detected in BIOS
[3.031280] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index 
(0x3) is beyond end of object (length 0x0) (20200925/exoparg2-393)
[3.031352] ACPI Error: Aborting method \_SB.PCI0.GFX0._DSM due to 
previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529)

[3.031419] ACPI: \_SB_.PCI0.GFX0: failed to evaluate _DSM (0x300b)
[3.031424] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
[3.031619] pci :00:02.0: optimus capabilities: enabled, status 
dynamic power,
[3.031667] ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index 
(0x3) is beyond end of object (length 0x0) (20200925/exoparg2-393)
[3.031731] ACPI Error: Aborting method \_SB.PCI0.GFX0._DSM due to 
previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529)
[3.031791] ACPI Error: Aborting method \_SB.PCI0.PEG0.PEGP._DSM due 
to previous error (AE_AML_PACKAGE_LIMIT) (20200925/psparse-529)

[3.031856] ACPI: \_SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM (0x300b)
[3.031859] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type 
mismatch - Found [Buffer], ACPI requires [Package] (20200925/nsarguments-61)
[3.032058] pci :01:00.0: optimus capabilities: enabled, status 
dynamic power,
[3.032061] VGA switcheroo: detected Optimus DSM method 
\_SB_.PCI0.PEG0.PEGP handle

[3.032323] checking generic (d000 41) vs hw (f600 100)
[3.032325] checking generic (d000 41) vs hw (e000 1000)
[3.032326] checking generic (d000 41) vs hw (f000 200)
[3.032410] nouveau :01:00.0: NVID

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

2021-04-10 Thread Roy Spliet


Op 10-04-2021 om 20:23 schreef Lukas Wunner:

On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:

Can I ask someone with more
technical knowledge of snd_hda_intel and vgaswitcheroo to brainstorm about
the possible challenges of nouveau taking matters into its own hand rather
than keeping this PCI quirk around?


It sounds to me like the HDA is not powered if no cable is plugged in.
What is reponsible then for powering it up or down, firmware code on
the GPU or in the host's BIOS?


Sometimes the BIOS, but definitely unconditionally the PCI quirk code: 
https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289


(CC Aaron Plattner)



Ideally, we should try to find out how to control HDA power from the
operating system rather than trying to cooperate with whatever firmware
is doing.  If we have that capability, the OS should power the HDA up
and down as it sees fit.

Thanks,

Lukas



___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

2021-04-10 Thread Roy Spliet

Reviving this thread as we have another user (rightfully) complaining on
IRC about this.

The way I see it there's two issues:
1) snd_hda_intel not allowing runpm (or w/e vgaswitcheroo needs) when
there's missing codecs, inhibiting the entire GPU from performing runpm.
This needlessly wastes lots of battery power.
2) HDMI audio not working on such machines unless it was plugged in at
boot-time.

The original workarounds proposed by Kai-Heng seem to fix 1), which is
progress. I don't see a reason why that should be held off even if it
doesn't fix 2).
To fix 2), more work is needed. On a high level, I suspect nouveau
should start controlling the enabling/disabling of the HDA controller
based on connector events and/or connector state at module load.
Currently the PCI quirk seems to enable it wholesale, and I don't know
why. If no GPU driver is loaded, it's pointless to turn the HDA device
on. The blob presumably doesn't need this either, as it can control the
device just as well as nouveau. If it doesn't, NVIDIA should fix it
rather than rely on this quirk. The only reason I can think of is that
snd_hda_intel or vgaswitcheroo isn't prepared for hot(un)plugging (or
alternatively reprobing) devices. Without that, we presumably won't
solve issue 2). Can I ask someone with more technical knowledge of
snd_hda_intel and vgaswitcheroo to brainstorm about the possible
challenges of nouveau taking matters into its own hand rather than
keeping this PCI quirk around?

Roy

Op 04-01-2021 om 13:20 schreef Karol Herbst:

On Tue, Dec 22, 2020 at 3:50 AM Kai-Heng Feng
wrote:

On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin wrote:

On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
wrote:

[+Cc nouveau]

On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai wrote:
[snip]

Quite possibly the system doesn't power up HDA controller when there's
no external monitor.
So when it's connected to external monitor, it's still needed for HDMI audio.
Let me ask the user to confirm this.

Yeah, it's the basic question whether the HD-audio is supposed to work
on this machine at all. If yes, the current approach we take makes
less sense - instead we should rather make the HD-audio controller
working.

Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.

- The second problem is that pci_enable_device() ignores the error
returned from pci_set_power_state() if it's -EIO. And the
inaccessible access error returns -EIO, although it's rather a fatal
problem. So the driver believes as the PCI device gets enabled
properly.

This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix
regression in pci_enable_device_bars") to fix UHCI controller.

- The third problem is that HD-audio driver blindly believes the
codec_mask read from the register even if it's a read failure as I
already showed.

This approach has least regression risk.

Yes, but it assumes that HD-audio is really non-existent.

I really don't know any good approach to address this.
On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the
driver will flag the magic bit to make HDA audio appear on the PCI
bus.
IIRC the current approach is to make nouveau and device link work.

I don't have the full context of this discussion, but the kernel
force-enables the HDA subfunction nowadays, irrespective of nouveau or
nvidia or whatever:

That's the problem.

The nvidia HDA controller on the affected system only gets its power
after HDMI cable plugged, so the probe on boot fails.

it might be that the code to enable the sub function is a bit broken
:/ but it should work. Maybe the quirk_nvidia_hda function needs to be
called on more occasions? No idea.

Kai-Heng

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/quirks.c?h=v5.10#n5267

Cheers,

-ilia

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128

2021-03-21 Thread Roy Spliet


Tested-by: Roy Spliet 

Op 08-03-2021 om 16:50 schreef Daniel Thompson:

On Thu, Mar 04, 2021 at 08:52:41PM -0500, Lyude Paul wrote:

While Kepler does technically support 256x256 cursors, it turns out that
Kepler actually has some additional requirements for scanout surfaces that
we're not enforcing correctly, which aren't present on Maxwell and later.
Cursor surfaces must always use small pages (4K), and overlay surfaces must
always use large pages (128K).

Fixing this correctly though will take a bit more work: as we'll need to
add some code in prepare_fb() to move cursor FBs in large pages to small
pages, and vice-versa for overlay FBs. So until we have the time to do
that, just limit cursor surfaces to 128x128 - a size small enough to always
default to small pages.

This means small ovlys are still broken on Kepler, but it is extremely
unlikely anyone cares about those anyway :).

Signed-off-by: Lyude Paul 
Fixes: d3b2f0f7921c ("drm/nouveau/kms/nv50-: Report max cursor size to 
userspace")
Cc:  # v5.11+


I was experiencing problems with the mouse cursor on my system in v5.11
and after a bisect to help me search the web I found my way to this
patch, which fixed the problem for me.

Mine is an Armv8 system but there is nothing particularly exotic from a
graphics card or software point of view: Debian bullseye/wayland
(gnome-shell 3.38.3, mesa-20.3.4) running on a GT-710.

However FWIW:
Tested-by: Daniel Thompson 


Daniel.



---
  drivers/gpu/drm/nouveau/dispnv50/disp.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 196612addfd6..1c9c0cdf85db 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2693,9 +2693,20 @@ nv50_display_create(struct drm_device *dev)
else
nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
  
-	if (disp->disp->object.oclass >= GK104_DISP) {

+   /* FIXME: 256x256 cursors are supported on Kepler, however unlike 
Maxwell and later
+* generations Kepler requires that we use small pages (4K) for cursor 
scanout surfaces. The
+* proper fix for this is to teach nouveau to migrate fbs being used 
for the cursor plane to
+* small page allocations in prepare_fb(). When this is implemented, we 
should also force
+* large pages (128K) for ovly fbs in order to fix Kepler ovlys.
+* But until then, just limit cursors to 128x128 - which is small 
enough to avoid ever using
+* large pages.
+*/
+   if (disp->disp->object.oclass >= GM107_DISP) {
dev->mode_config.cursor_width = 256;
dev->mode_config.cursor_height = 256;
+   } else if (disp->disp->object.oclass >= GK104_DISP) {
+   dev->mode_config.cursor_width = 128;
+   dev->mode_config.cursor_height = 128;
} else {
dev->mode_config.cursor_width = 64;
dev->mode_config.cursor_height = 64;
--
2.29.2


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] drm/nouveau/kms/nve4-nv108: Don't advertise 256x256 cursor support yet

2021-03-21 Thread Roy Spliet


Tested-by: Roy Spliet 

Op 05-03-2021 om 22:21 schreef Lyude Paul:

While Kepler does technically support 256x256 cursors, it turns out that
in order for us to use these correctly we need to make sure that the cursor
plane uses a ctxdma that is set to use small (4K)/large (128K) pages -
whichever is applicable to the given cursor surface.

Right now however, we share the main kmsVramCtxDma that is used for all but
the ovly plane which defaults to small pages - resulting in artifacts when
we use 256x256 cursor surfaces. So until we teach nouveau to use a separate
ctxdma for the cursor, let's just stop advertising 256x256 cursors by
default - which should fix the issues that users were seeing.

Coincidentally - this is also why small ovlys don't work on Kepler: the
ctxdma we use for ovlys is set to large pages.

Changes since v2:
* Fix comments and patch description

Signed-off-by: Lyude Paul 
Fixes: d3b2f0f7921c ("drm/nouveau/kms/nv50-: Report max cursor size to 
userspace")
Cc:  # v5.11+
---
  drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 196612addfd6..d92cf9e17ac3 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2693,9 +2693,19 @@ nv50_display_create(struct drm_device *dev)
else
nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
  
-	if (disp->disp->object.oclass >= GK104_DISP) {

+   /* FIXME: 256x256 cursors are supported on Kepler, however unlike 
Maxwell and later
+* generations Kepler requires that we specify the page type, small 
(4K) or large (128K),
+* correctly for the ctxdma being used on curs/ovly. We currently share 
a ctxdma across all
+* display planes (except ovly) that defaults to small pages, which 
results in artifacting
+* on 256x256 cursors. Until we teach nouveau to create an appropriate 
ctxdma for the cursor
+* fb in use, simply avoid advertising support for 256x256 cursors.
+*/
+   if (disp->disp->object.oclass >= GM107_DISP) {
dev->mode_config.cursor_width = 256;
dev->mode_config.cursor_height = 256;
+   } else if (disp->disp->object.oclass >= GK104_DISP) {
+   dev->mode_config.cursor_width = 128;
+   dev->mode_config.cursor_height = 128;
} else {
dev->mode_config.cursor_width = 64;
dev->mode_config.cursor_height = 64;


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drivers: drm: nouveau: nvkm: Replace a word with a better phonetic word in the file macros.fuc

2021-02-05 Thread Roy Spliet


Op 05-02-2021 om 13:05 schreef Bhaskar Chowdhury:



s/fuck/heck/


Signed-off-by: Bhaskar Chowdhury 
---
  drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
index 3737bd27f74e..1407a1b16d95 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
@@ -46,7 +46,7 @@
  #define NV_PPWR_INTR_EN_SET_SUBINTR  
0x0800
  #define NV_PPWR_INTR_EN_SET_WATCHDOG 
0x0002
  #define NV_PPWR_INTR_EN_CLR  
0x0014
-#define NV_PPWR_INTR_EN_CLR_MASK/* fuck i hate envyas */ -1
+#define NV_PPWR_INTR_EN_CLR_MASK/* heck, i hate envyas */ 
-1


Please make sure that the values remain properly right-justified when 
proposing such changes.

Best,

Roy


  #define NV_PPWR_INTR_ROUTE   
0x001c
  #define NV_PPWR_TIMER_LOW
0x002c
  #define NV_PPWR_WATCHDOG_TIME
0x0034
--
2.30.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Request for help in adding a HDMI output

2021-01-23 Thread Roy Spliet


Op 23-01-2021 om 23:18 schreef o1bigtenor:


OK, so this is your 4k monitor. It is plugged into the *secondary*
GPU, and does not report any 4k@60 modes in the EDID (well, it does
report 4k@60 YUV 4:2:0 modes, but we don't support those in nouveau at
this time). Whether that's because the monitor itself doesn't support
HDMI 2.0, or you plugged it into your old GPU which does not support
HDMI 2.0, I couldn't say from just this output. What I can say is that
no amount of modelines will get you 4k@60 in this setup with nouveau.



[...]

If you would point out a suggestion that I haven't tried - - - please?


A quick DuckDuckGo for "Hisense 4K 60Hz only reports 30Hz" gives this 
thread: https://www.coolcomputing.com/article.php?sid=4659 . No idea 
whether this also applies to your 2016 model. Have you scavenged through 
the TVs menu's to make sure HDMI 2.0 is explicitly enabled?

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] Documentation: nouveau: Introduce some nouveau documentation

2020-09-24 Thread Roy Spliet





Op 24-09-2020 om 16:21 schreef Karol Herbst:

On Thu, Sep 24, 2020 at 3:06 PM Roy Spliet  wrote:



Op 23-09-2020 om 22:36 schreef Karol Herbst:

On Wed, Sep 23, 2020 at 10:39 PM Jeremy Cline  wrote:


On Wed, Sep 23, 2020 at 09:02:45PM +0200, Karol Herbst wrote:

On Fri, Sep 11, 2020 at 6:21 PM Jeremy Cline  wrote:





yeah, I think overall this file is a good idea and being able to get a
quick overview over the driver is helpful. I think if we focus on the
user facing things first, like the hwmon or other things users
generally interact with would be helpful. I think if we start to
document areas where there are many low hanging fruits, this could
help random people to start with easier tasks and get more used to the
driver overall, so I'd probably ignore most of the stuff which really
requires a fundamental understanding on how things work and focus more
on vbios parsing (which has annoying interfaces anyway and it might
make sense to make it more consistent and nicer to use) and/or simple
code interfacing with the mmio space.



I'll admit to being motivated by entirely selfish reasons. I know
practically nothing about nouveau and I'm the type of person who likes
to keep notes about how things work together, both free form and
structured in-line docs. All that to say, I think focusing on the
"low-hanging fruit" stuff will be very beneficial and I'm happy to do
that, but I'm also interested in documenting everything else I run
across.



yeah, that's fine. I was just giving a suggestion on where the initial
focus should be on.


Eg some users have problems with their fans as they are either always
ramping up to max, or not running at all... GPUs temperature or power
consumption is reporting incorrectly... all those things users hit
regularly, but which isn't really important enough so it just falls
under the table even if it gets reported.



This does bring up an interesting point about organization and target
audiences. Typically when I'm writing documentation I like to organize
things by target audiences, so we could have a layout like:

* General Introduction

* User Guide
  - Overview of supported hardware/features/etc


That's best to document in a wiki though. And we had plans to convert
the existing old wiki over to gitlab. And maybe It think we really
should do that and clean it up while we work on that. It's just a huge
project but maybe just starting with whatever you want to do would be
fine and after a while nothing is left. Anyway, I think we should
discuss this more openly with the others as well. i don't like the
current wiki anyway, as only approved developers can change things and
with a gitlab wiki we could even take MRs on stuff.


  - Installation


well.. I think this can be skipped ;) But still, also belongs more
into a wiki. I think what we could cover here is to how to clean up
remaining stuff from the blob driver as this is something which comes
up quite a lot on IRC though.


  - Configuration (module parameters and such)
  - Troubleshooting


that would be cool to have in the wiki as well. Just collecting the
most common issue and document it there. Especially if it is on
gitlab, users can just do that as well :)


  - Getting Involved (bug reporting, running tests, etc)


yeah, and we have some stuff on that on the old wiki already, it's
just very outdated and needs updating, which as said above can only be
done by developers and developers sadly have other things to do :)



* Developer Guide
  - Architecture Overview
  - External APIs (include/uapi/drm/nouveau_drm.h, any sysfs stuff)?
  - Internal APIs


Right, those things I'd like to see in the kernel tree actually.


  - Debugging and Development Tools
  - Contribution Guide



Those I think belong more into the wiki again. The latter is a bit
hard to split as there are kernel guides, but also community and
project guides. Mesa does things differently than let's say the
kernel. And Nouveau is still in this limbo state being on the old
infra, but also on the new one with mesa...


I'm not sure how much stuff people want to keep on the
nouveau.freedesktop.org wiki vs here.



I think the first step actually is to set up a proper nouveau project
on gitlab for dealing with issues and the wiki. I would be fine to do
that and we can also move the code there late. But maybe let's start
with the wiki :)


Risking to turn this into a "let's fix everything in one go" project
that ends up never getting finished, I just want to make sure that
everybody is also aware of the documentation generated from Envytools
[0]. Especially "architecture overview" (that is, if we're talking about
hardware architecture and not driver/software architecture) might be
better suited in envytools.

As for module parameters, IMHO modinfo is supposed to be the source of
information. It

Re: [Nouveau] [RFC] Documentation: nouveau: Introduce some nouveau documentation

2020-09-24 Thread Roy Spliet




Op 23-09-2020 om 22:36 schreef Karol Herbst:

On Wed, Sep 23, 2020 at 10:39 PM Jeremy Cline  wrote:


On Wed, Sep 23, 2020 at 09:02:45PM +0200, Karol Herbst wrote:

On Fri, Sep 11, 2020 at 6:21 PM Jeremy Cline  wrote:





yeah, I think overall this file is a good idea and being able to get a
quick overview over the driver is helpful. I think if we focus on the
user facing things first, like the hwmon or other things users
generally interact with would be helpful. I think if we start to
document areas where there are many low hanging fruits, this could
help random people to start with easier tasks and get more used to the
driver overall, so I'd probably ignore most of the stuff which really
requires a fundamental understanding on how things work and focus more
on vbios parsing (which has annoying interfaces anyway and it might
make sense to make it more consistent and nicer to use) and/or simple
code interfacing with the mmio space.



I'll admit to being motivated by entirely selfish reasons. I know
practically nothing about nouveau and I'm the type of person who likes
to keep notes about how things work together, both free form and
structured in-line docs. All that to say, I think focusing on the
"low-hanging fruit" stuff will be very beneficial and I'm happy to do
that, but I'm also interested in documenting everything else I run
across.



yeah, that's fine. I was just giving a suggestion on where the initial
focus should be on.


Eg some users have problems with their fans as they are either always
ramping up to max, or not running at all... GPUs temperature or power
consumption is reporting incorrectly... all those things users hit
regularly, but which isn't really important enough so it just falls
under the table even if it gets reported.



This does bring up an interesting point about organization and target
audiences. Typically when I'm writing documentation I like to organize
things by target audiences, so we could have a layout like:

* General Introduction

* User Guide
 - Overview of supported hardware/features/etc


That's best to document in a wiki though. And we had plans to convert
the existing old wiki over to gitlab. And maybe It think we really
should do that and clean it up while we work on that. It's just a huge
project but maybe just starting with whatever you want to do would be
fine and after a while nothing is left. Anyway, I think we should
discuss this more openly with the others as well. i don't like the
current wiki anyway, as only approved developers can change things and
with a gitlab wiki we could even take MRs on stuff.


 - Installation


well.. I think this can be skipped ;) But still, also belongs more
into a wiki. I think what we could cover here is to how to clean up
remaining stuff from the blob driver as this is something which comes
up quite a lot on IRC though.


 - Configuration (module parameters and such)
 - Troubleshooting


that would be cool to have in the wiki as well. Just collecting the
most common issue and document it there. Especially if it is on
gitlab, users can just do that as well :)


 - Getting Involved (bug reporting, running tests, etc)


yeah, and we have some stuff on that on the old wiki already, it's
just very outdated and needs updating, which as said above can only be
done by developers and developers sadly have other things to do :)



* Developer Guide
 - Architecture Overview
 - External APIs (include/uapi/drm/nouveau_drm.h, any sysfs stuff)?
 - Internal APIs


Right, those things I'd like to see in the kernel tree actually.


 - Debugging and Development Tools
 - Contribution Guide



Those I think belong more into the wiki again. The latter is a bit
hard to split as there are kernel guides, but also community and
project guides. Mesa does things differently than let's say the
kernel. And Nouveau is still in this limbo state being on the old
infra, but also on the new one with mesa...


I'm not sure how much stuff people want to keep on the
nouveau.freedesktop.org wiki vs here.



I think the first step actually is to set up a proper nouveau project
on gitlab for dealing with issues and the wiki. I would be fine to do
that and we can also move the code there late. But maybe let's start
with the wiki :)


Risking to turn this into a "let's fix everything in one go" project 
that ends up never getting finished, I just want to make sure that 
everybody is also aware of the documentation generated from Envytools 
[0]. Especially "architecture overview" (that is, if we're talking about 
hardware architecture and not driver/software architecture) might be 
better suited in envytools.


As for module parameters, IMHO modinfo is supposed to be the source of 
information. It's sadly lacking any "sub-"option inside nouveau.config 
and nouveau.debug, which may be by design. Perhaps expanding the modinfo 
explanations can help cover at least all the other options in a way that 
never gets out of sync wi

Re: [Nouveau] [PATCH 1/3] drm/radeon: remove AGP support

2020-05-12 Thread Roy Spliet


Op 12-05-2020 om 14:36 schreef Alex Deucher:

On Tue, May 12, 2020 at 4:16 AM Michel Dänzer  wrote:


On 2020-05-11 10:12 p.m., Alex Deucher wrote:

On Mon, May 11, 2020 at 1:17 PM Christian König
 wrote:


AGP is deprecated for 10+ years now and not used any more on modern hardware.

Old hardware should continue to work in PCI mode.


Might want to clarify that there is no loss of functionality here.
Something like:

"There is no loss of functionality here.  GPUs will continue to
function.  This just drops the use of the AGP MMU in the chipset in
favor of the MMU on the device which has proven to be much more
reliable.  Due to its unreliability, AGP support has been disabled on
PowerPC for years already so there is no change on PowerPC."


There's a difference between something being disabled by default or not
being available at all. We may decide it's worth it anyway, but let's do
it based on facts.



I didn't mean to imply that AGP GART support was already removed.  But
for the vast majority of users the end result is the same.  If you
knew enough re-enable AGP GART, you probably wouldn't have been as
confused about what this patch set does either.  To reiterate, this
patch set does not remove support for AGP cards, it only removes the
support for AGP GART.  The cards will still be functional using the
device GART.  There may be performance tradeoffs there in some cases.


I'll volunteer to be the one asking: how big is this performance 
difference? Have any benchmarks been run before and after removal of AGP 
GART code on affected nouveau/radeon systems? Or is this code being 
dropped _just_ because it's cumbersome, with no regard for metrics that 
determine the value of AGP GART support?


Roy



Alex
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau



___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-06 Thread Roy Spliet


(Re-sending to list rather than just to James)

Is this format modifier information not stored, or otherwise worth 
storing, directly in the nouveau_bo object associated with the 
framebuffer? I'm not particularly knowledgeable on the topic, but there 
already seem to exist some fields with very similar names in nouveau_bo.

Best,

Roy

On 06/02/2020 15:17, James Jones wrote:
Note I'm adding some fields to nouveau_framebuffer in the series 
"drm/nouveau: Support NVIDIA format modifiers."  I sent out v3 of that 
yesterday.  It would probably still be possible to avoid them by 
re-extracting the relevant data from the format modifier on the fly when 
needed, but it is simpler and likely less error-prone with the wrapper 
struct.


Thanks,
-James

On 2/6/20 2:19 AM, Thomas Zimmermann wrote:

After its cleanup, struct nouveau_framebuffer is only a wrapper around
struct drm_framebuffer. Use the latter directly.

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/nouveau/dispnv50/wndw.c   | 26 +++
  drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++--
  drivers/gpu/drm/nouveau/nouveau_display.h | 12 +--
  drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 14 ++--
  4 files changed, 28 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c 
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c

index ba1399965a1c..4a67a656e007 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -40,11 +40,11 @@ nv50_wndw_ctxdma_del(struct nv50_wndw_ctxdma *ctxdma)
  }
  static struct nv50_wndw_ctxdma *
-nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct 
nouveau_framebuffer *fb)

+nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct drm_framebuffer *fb)
  {
-    struct nouveau_drm *drm = nouveau_drm(fb->base.dev);
+    struct nouveau_drm *drm = nouveau_drm(fb->dev);
  struct nv50_wndw_ctxdma *ctxdma;
-    struct nouveau_bo *nvbo = nouveau_gem_object(fb->base.obj[0]);
+    struct nouveau_bo *nvbo = nouveau_gem_object(fb->obj[0]);
  const u8    kind = nvbo->kind;
  const u32 handle = 0xfb00 | kind;
  struct {
@@ -236,16 +236,16 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw 
*wndw, bool modeset,

 struct nv50_wndw_atom *asyw,
 struct nv50_head_atom *asyh)
  {
-    struct nouveau_framebuffer *fb = 
nouveau_framebuffer(asyw->state.fb);

+    struct drm_framebuffer *fb = asyw->state.fb;
  struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
-    struct nouveau_bo *nvbo = nouveau_gem_object(fb->base.obj[0]);
+    struct nouveau_bo *nvbo = nouveau_gem_object(fb->obj[0]);
  int ret;
  NV_ATOMIC(drm, "%s acquire\n", wndw->plane.name);
-    if (asyw->state.fb != armw->state.fb || !armw->visible || modeset) {
-    asyw->image.w = fb->base.width;
-    asyw->image.h = fb->base.height;
+    if (fb != armw->state.fb || !armw->visible || modeset) {
+    asyw->image.w = fb->width;
+    asyw->image.h = fb->height;
  asyw->image.kind = nvbo->kind;
  ret = nv50_wndw_atomic_check_acquire_rgb(asyw);
@@ -261,13 +261,13 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw 
*wndw, bool modeset,

  asyw->image.blockh = nvbo->mode >> 4;
  else
  asyw->image.blockh = nvbo->mode;
-    asyw->image.blocks[0] = fb->base.pitches[0] / 64;
+    asyw->image.blocks[0] = fb->pitches[0] / 64;
  asyw->image.pitch[0] = 0;
  } else {
  asyw->image.layout = 1;
  asyw->image.blockh = 0;
  asyw->image.blocks[0] = 0;
-    asyw->image.pitch[0] = fb->base.pitches[0];
+    asyw->image.pitch[0] = fb->pitches[0];
  }
  if (!asyh->state.async_flip)
@@ -486,16 +486,16 @@ nv50_wndw_cleanup_fb(struct drm_plane *plane, 
struct drm_plane_state *old_state)

  static int
  nv50_wndw_prepare_fb(struct drm_plane *plane, struct drm_plane_state 
*state)

  {
-    struct nouveau_framebuffer *fb = nouveau_framebuffer(state->fb);
+    struct drm_framebuffer *fb = state->fb;
  struct nouveau_drm *drm = nouveau_drm(plane->dev);
  struct nv50_wndw *wndw = nv50_wndw(plane);
  struct nv50_wndw_atom *asyw = nv50_wndw_atom(state);
-    struct nouveau_bo *nvbo = nouveau_gem_object(state->fb->obj[0]);
+    struct nouveau_bo *nvbo = nouveau_gem_object(fb->obj[0]);
  struct nv50_head_atom *asyh;
  struct nv50_wndw_ctxdma *ctxdma;
  int ret;
-    NV_ATOMIC(drm, "%s prepare: %p\n", plane->name, state->fb);
+    NV_ATOMIC(drm, "%s prepare: %p\n", plane->name, fb);
  if (!asyw->state.fb)
  return 0;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c

index bbbff55eb5d5..94f7fd48e1cf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -207,10 +207,10 @@ int
  nouveau_framebuffer_new(struct drm_device *dev,

Re: [Nouveau] [PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver v2

2020-01-24 Thread Roy Spliet

Without diving in any of the details, your commit message has me curious 
and concerned... In a "manager" kind of way, despite being neither a 
manager nor an insider or active contributor. ;-)


On 24/01/2020 14:30, Christian König wrote:

From: Christian König 

While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.


What made you conclude this mechanism doesn't work? Does this imply that 
Nouveau is broken? If so: Does the migration of this code from TTM to 
Nouveau mean that Nouveau remains broken, but it's now simply no longer 
your problem? And what would it take to fix Nouveau?

Best,

Roy



In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.

The patch should be functional correct, but is only compile tested!

v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve

Signed-off-by: Christian König 
Acked-by: Daniel Vetter 
---
  drivers/gpu/drm/nouveau/nouveau_bo.c  | 107 --
  drivers/gpu/drm/nouveau/nouveau_bo.h  |   3 +
  drivers/gpu/drm/nouveau/nouveau_drv.h |   2 +
  drivers/gpu/drm/nouveau/nouveau_ttm.c |  43 ++-
  4 files changed, 131 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 81668104595f..acee054f77ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -137,6 +137,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct nouveau_bo *nvbo = nouveau_bo(bo);
  
  	WARN_ON(nvbo->pin_refcnt > 0);

+   nouveau_bo_del_io_reserve_lru(bo);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
  
  	/*

@@ -304,6 +305,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int 
align, u32 flags,
  
  	nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;

nouveau_bo_placement_set(nvbo, flags, 0);
+   INIT_LIST_HEAD(&nvbo->io_reserve_lru);
  
  	ret = ttm_bo_init(nvbo->bo.bdev, &nvbo->bo, size, type,

  &nvbo->placement, align >> PAGE_SHIFT, false,
@@ -574,6 +576,26 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
PAGE_SIZE, DMA_FROM_DEVICE);
  }
  
+void nouveau_bo_add_io_reserve_lru(struct ttm_buffer_object *bo)

+{
+   struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+   struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+   mutex_lock(&drm->ttm.io_reserve_mutex);
+   list_move_tail(&nvbo->io_reserve_lru, &drm->ttm.io_reserve_lru);
+   mutex_unlock(&drm->ttm.io_reserve_mutex);
+}
+
+void nouveau_bo_del_io_reserve_lru(struct ttm_buffer_object *bo)
+{
+   struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+   struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+   mutex_lock(&drm->ttm.io_reserve_mutex);
+   list_del_init(&nvbo->io_reserve_lru);
+   mutex_unlock(&drm->ttm.io_reserve_mutex);
+}
+
  int
  nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -675,8 +697,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
}
  
  			man->func = &nouveau_vram_manager;

-   man->io_reserve_fastpath = false;
-   man->use_io_reserve_lru = true;
} else {
man->func = &ttm_bo_manager_func;
}
@@ -1305,6 +1325,8 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool 
evict,
if (bo->destroy != nouveau_bo_del_ttm)
return;
  
+	nouveau_bo_del_io_reserve_lru(bo);

+
if (mem && new_reg->mem_type != TTM_PL_SYSTEM &&
mem->mem.page == nvbo->page) {
list_for_each_entry(vma, &nvbo->vma_list, head) {
@@ -1427,6 +1449,30 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo, 
struct file *filp)
  filp->private_data);
  }
  
+static void

+nouveau_ttm_io_mem_free_locked(struct nouveau_drm *drm, struct ttm_mem_reg 
*reg)
+{
+   struct nouveau_mem *mem = nouveau_mem(reg);
+
+   if (!reg->bus.base)
+   return; /* already freed */
+
+   if (drm->client.mem->oclass >= NVIF_CLASS_MEM_NV50) {
+   switch (reg->mem_type) {
+   case TTM_PL_TT:
+   if (mem->kind)
+   nvif_object_unmap_handle(&mem->mem.object);
+   break;
+   case TTM_PL_VRAM:
+   nvif_object_unmap_handle(&mem->mem.object);
+   break;
+   default:
+   break;
+   }
+   }
+   reg->bus.base = 0;
+}
+
  static int
  nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg 
*reg)
  {
@@ -1434,18 +1480,26 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *reg)
struct nouveau_drm *dr

Re: [Nouveau] [PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init

2020-01-03 Thread Roy Spliet


(re-sending as plain text)

NACK. The before and after of this patch are functionally identical. The 
if-block returns unconditionally ("return priv;"), so the kfree will 
only ever be reached if the condition in the if-statement evaluates to 
false. Explicitly writing out an else-block is thus superfluous.


Op 03-01-2020 om 09:10 schreef wuxu.wu:

Hi, I think there has a incorrect kfree in pcirom_init function. In
pcirom_init function priv porinter could be free only when priv != null
and priv->rom is null.

Signed-off-by: wuxu.wu 
---
  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da0..d776e01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -70,8 +70,9 @@ pcirom_init(struct nvkm_bios *bios, const char *name)
(priv->rom = pci_map_rom(pdev, &priv->size))) {
priv->pdev = pdev;
return priv;
+   } else {
+   kfree(priv);
}
-   kfree(priv);
}
pci_disable_rom(pdev);
}


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init

2020-01-03 Thread Roy Spliet

NACK. The before and after of this patch are functionally identical. The 
if-block returns unconditionally ("return priv;"), so the kfree will 
only ever be reached if the condition in the if-statement evaluates to 
false. Explicitly writing out an else-block is thus superfluous.


Op 03-01-2020 om 09:10 schreef wuxu.wu:

Hi, I think there has a incorrect kfree in pcirom_init function. In
pcirom_init function priv porinter could be free only when priv != null
and priv->rom is null.

Signed-off-by: wuxu.wu 
---
  drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da0..d776e01 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -70,8 +70,9 @@ pcirom_init(struct nvkm_bios *bios, const char *name)
(priv->rom = pci_map_rom(pdev, &priv->size))) {
priv->pdev = pdev;
return priv;
+   } else {
+   kfree(priv);
}
-   kfree(priv);
}
pci_disable_rom(pdev);
}
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3] clk: Restore BYPASS_PLL_CHECK from PLLs

2019-09-06 Thread Roy Spliet

(Accidentally replied in person instead of to the list. Here a ~verbatim 
copy of my e-mail earlier)


Briefly, the BYPASS_PLL_CHECK bit disables the PLL locking test when set 
to 1. PLLs should still lock (or not, if the params are wildly 
out-of-bounds), but the test is bypassed and disabled when the bit is set.
This bit was definitely used on NVA3/5/8 by the blob as I confirmed 
ploughing through traces. I recall seeing the same behaviour (disabling) 
on early Fermi's, but I'd have to dig a whole lot deeper through old 
trace to confirm. As for why NVIDIA disables this test after verifying 
the PLL locked, my highly speculative guess back then was just power 
savings. As to why nouveau does it: when in Rome...
The fact that this makes a difference in stability on GF119 makes me 
wonder whether the PLL control register has a different layout on these 
GPUs. The BYPASS_PLL_CHECK bit might no longer be a BYPASS_PLL_CHECK 
bit, but have a completely different meaning. As this gen was 
centimetring towards Kepler, you might want to:
1) investigate behaviour of this bit and the rest of the control bits on 
an idle GF119. Got a machine with an Intel/AMD IGP? Good, stick the 
GF119 in as a secondary GPU and you can trace while messing with the 
VDEC PLL or some other insignificant domain's PLL manually without 
hanging the card or your machine,
2) Look at Kepler code either in nouveau or nvgpu to see if their PLL 
reconfiguration code matches your traces closer,

3) Be cheeky and ask NVIDIA.

Depending on further investigation you may have to create a new 
clk/gf119.c subdev to facilitate potential differences between earlier 
Fermis and this one.


Roy


On 06/09/2019 12:43, Mark Menzynski wrote:

I have looked at problem with Fermi GPUs where changing to higher clock
led to really bad perfomance (with GpuTest 20x worse perfomance) and later also 
crashes of the nouveau. It seemed
to be affected by Shader Clock in Voltage Entries in the video BIOS. Disabling
BYPASS_PLL_CHECK in CLK0_CTRL seems to completely fix the issue. I have
tried to search this BYPASS_PLL_CHECK in Nvidia traces but seemed it
wasn't used nowhere for CLK settings.

Removing this works fine, but I don't know what it's really for.
Actual bit setting this BYPASS_PLL_CHECK is on 0x10:
lookup -ac0 0x137000 0x10
PCLOCK.CLK0_CTRL => { BYPASS_PLL_CHECK | UNK12 = 0 }
Also, disabling this bit on other CLKs doesn't seem to break anything.

v2: add back PLL lock test
v3: add restoring original value after PLL lock test

Signed-off-by: Mark Menzynski 
---
  drm/nouveau/nvkm/subdev/clk/gf100.c | 7 +--
  drm/nouveau/nvkm/subdev/clk/gk104.c | 5 -
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nvkm/subdev/clk/gf100.c 
b/drm/nouveau/nvkm/subdev/clk/gf100.c
index 7f67f9f5..a97af0e9 100644
--- a/drm/nouveau/nvkm/subdev/clk/gf100.c
+++ b/drm/nouveau/nvkm/subdev/clk/gf100.c
@@ -368,6 +368,7 @@ gf100_clk_prog_2(struct gf100_clk *clk, int idx)
struct gf100_clk_info *info = &clk->eng[idx];
struct nvkm_device *device = clk->base.subdev.device;
const u32 addr = 0x137000 + (idx * 0x20);
+   bool bypass_state = false;
if (idx <= 7) {
nvkm_mask(device, addr + 0x00, 0x0004, 0x);
nvkm_mask(device, addr + 0x00, 0x0001, 0x);
@@ -376,12 +377,14 @@ gf100_clk_prog_2(struct gf100_clk *clk, int idx)
nvkm_mask(device, addr + 0x00, 0x0001, 0x0001);
  
  			/* Test PLL lock */

+   bypass_state = nvkm_rd32(device, addr + 0x00) & 
0x0010;
nvkm_mask(device, addr + 0x00, 0x0010, 0x);
nvkm_msec(device, 2000,
if (nvkm_rd32(device, addr + 0x00) & 0x0002)
break;
);
-   nvkm_mask(device, addr + 0x00, 0x0010, 0x0010);
+   if (bypass_state)
+   nvkm_mask(device, addr + 0x00, 0x0010, 
0x0010);
  
  			/* Enable sync mode */

nvkm_mask(device, addr + 0x00, 0x0004, 0x0004);
@@ -476,5 +479,5 @@ gf100_clk_new(struct nvkm_device *device, int index, struct 
nvkm_clk **pclk)
return -ENOMEM;
*pclk = &clk->base;
  
-	return nvkm_clk_ctor(&gf100_clk, device, index, false, &clk->base);

+   return nvkm_clk_ctor(&gf100_clk, device, index, true, &clk->base);
  }
diff --git a/drm/nouveau/nvkm/subdev/clk/gk104.c 
b/drm/nouveau/nvkm/subdev/clk/gk104.c
index 0b37e3da..c9ede404 100644
--- a/drm/nouveau/nvkm/subdev/clk/gk104.c
+++ b/drm/nouveau/nvkm/subdev/clk/gk104.c
@@ -388,6 +388,7 @@ gk104_clk_prog_2(struct gk104_clk *clk, int idx)
struct gk104_clk_info *info = &clk->eng[idx];
struct nvkm_device *device = clk->base.subdev.device;
const u32 addr = 0x137000 + (idx * 0x20);
+   bool byp

Re: [Nouveau] [Piglit] X.Org GSoC 2019 - Student Application Period

2019-03-26 Thread Roy Spliet


Thanks for reaching out on the matter Ilia.
I am not to be relied on. If you're lucky, I might be able to take some 
questions about past work, but cannot make a solid time commitment that 
warrants being a mentor.
Of course, the mentor does not necessarily have to have the deepest 
understanding of the subject matter. *At the end of the GSOC* a good 
student should be trusted with having more knowledge on the specific 
topic than the mentor. That being said, DVFS is fidgetty and the outcome 
is binary (it either works or crashes your machine spectacularly), so 
it's difficult to get someone started and keep 'em motivated if as a 
mentor you don't have experience on the topic. As such, I'd consider it 
a high risk topic to promote unless one of the relative veteran 
developers (Ben, Martin, Karol, or Lyude in the case of clock/power 
gating) is keen to mentor.


Roy


On 26/03/2019 15:07, Ilia Mirkin wrote:

On Tue, Mar 26, 2019 at 10:56 AM Trevor Woerner  wrote:


On Tue 2019-03-26 @ 10:40:49 AM, Ilia Mirkin wrote:

Just looked over the projects... they all seem valid


Thank you for taking the time to have a look and provide feedback!


but are there
people who could realistically mentor a GSoC student for these? IMHO
unless mentors can be identified, these should all be archived.


Attracting mentors is probably the hardest part of running GSoC. Perhaps if a
student shows interest in a given topic, someone might be inspired to sign up
as a mentor?

Keeping the list of ideas up-to-date and finding mentors are the two things
I'm hoping to make a noticeable improvement to this year. It also ties in
strongly with:

 https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/76

Best regards,
 Trevor


BTW - I meant my comment to only apply to nouveau-related projects.
Both in terms of validity, as well as mentorship-unavailability.

It sucks for a student to come in, think that some project is
available to work on, only to find that there's no one who can mentor
them. I don't know how often that happens, but I bet it's "sometimes".
Better to get them to dedicate themselves to projects that do have
mentors available.

[And yeah, I know these are meant as "ideas", but I think in practice
it's "here's a list of projects for you to select from". Only a very
rare student will come up with their own idea.]

   -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Google's Chrome Team might Blacklist Nouveau on Chromium

2018-09-26 Thread Roy Spliet

I don't think any nouveau dev would disagree with the choice for a 
software rendered browser over an unreliable browser. Insofar I still 
count as a nouveau dev, I'll back this decision because it benefits user 
experience.
What is disappointing though is that when I perform a search on our bug 
tracker (see [0] and [1]), I find precisely _one_ relevant bug. Shame on 
us for not following up on that one, but shame on the Chrome developers 
to decide they'd rather blacklist a driver than publicly* reach out and 
ask what's going on. Blacklisting 3D rendering on nouveau isn't going to 
fix nouveau, it's a short-term improvement with no long term prospect.


On 26/09/18 11:25, Megaf wrote:

Well, I agree with them.
Nouveau is extremely unstable on my MacBook Pro with Nvidia 320M, 
freezing all the time and draining a lot of battery.

Performance wise is not too bad tho.
There's plenty of reported bugs already around the web if someone 
wants to investigate it.
Don't take this as personal criticism, I really appreciate the fact that 
you reach out and bring this to our attention. What I do wish to point 
out to anyone is that there are too many projects with too many bug 
trackers out there to track all of them. In reality nouveau devs monitor 
the nouveau bugtracker [2], and if you're lucky the tracker of their 
favourite distro. I don't believe it's feasible to expect driver devs to 
track more - we're already grossly under"staffed". Sure, Chrome is a 
popular piece of software, but so is Firefox, LibreOffice, VirtualBox, 
Wine, Dolphin, Gnome Shell etc. etc... So my advice to anyone: if you 
want bugs actually fixed in nouveau, do your civil duty and file them in 
the nouveau bugtracker.


Roy

[0] 
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=Driver%2Fnouveau&product=xorg&query_format=advanced&short_desc=chrome&short_desc_type=allwordssubstr
[1] 
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=Drivers%2FDRI%2Fnouveau&product=Mesa&query_format=advanced&short_desc=chrome&short_desc_type=allwordssubstr

[2] https://nouveau.freedesktop.org/wiki/Bugs/

* I'm aware that a sizeable portion of the workforce behind nouveau is 
currently employed by Red Hat. What happens behind their scenes is 
unknown to me and other contributors...


Thanks
Megaf
https://www.megaf.info/

email: mme...@gmail.com 
skype: eumegaf
discord: Megaf#6582


On Sun, 23 Sep 2018 at 04:06, Matthew Ary > wrote:



I thought you all would like to know that Google considers Nouveau
to be unstable and is now actively considering blacklisting.
Please see this issue on their issue tracker.

https://bugs.chromium.org/p/chromium/issues/detail?id=876523
___
Nouveau mailing list
Nouveau@lists.freedesktop.org 
https://lists.freedesktop.org/mailman/listinfo/nouveau



___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3 5/6] kms/nv50: detect HDMI max MHz correctly

2018-08-03 Thread Roy Spliet



On 03/08/18 16:56, Karol Herbst wrote:

On Fri, Aug 3, 2018 at 4:08 PM, Ilia Mirkin  wrote:

On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst  wrote:

v2: clean up left over comments
 don't overwrite hdmimhz parameter
 cap to 297MHz

Signed-off-by: Karol Herbst 
---
  drm/nouveau/dispnv50/disp.c |  5 +
  drm/nouveau/nouveau_connector.c | 15 ++-
  drm/nouveau/nouveau_encoder.h   |  4 
  3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drm/nouveau/dispnv50/disp.c b/drm/nouveau/dispnv50/disp.c
index fa23d7a2..103433cb 100644
--- a/drm/nouveau/dispnv50/disp.c
+++ b/drm/nouveau/dispnv50/disp.c
@@ -1433,7 +1433,12 @@ nv50_sor_create(struct drm_connector *connector, struct 
dcb_output *dcbe,
 case DCB_OUTPUT_LVDS: type = DRM_MODE_ENCODER_LVDS; break;
 case DCB_OUTPUT_DP:
 nv_encoder->dp.no_interlace = caps->sor[or].dp.no_interlace;
+   type = DRM_MODE_ENCODER_TMDS;
+   break;
 case DCB_OUTPUT_TMDS:
+   nv_encoder->tmds.max_mhz = caps->sor[or].tmds.max_mhz;
+   type = DRM_MODE_ENCODER_TMDS;
+   break;
 default:
 type = DRM_MODE_ENCODER_TMDS;
 break;
diff --git a/drm/nouveau/nouveau_connector.c b/drm/nouveau/nouveau_connector.c
index 074e6d52..65fac604 100644
--- a/drm/nouveau/nouveau_connector.c
+++ b/drm/nouveau/nouveau_connector.c
@@ -980,15 +980,20 @@ static unsigned
  get_tmds_link_bandwidth(struct drm_connector *connector, bool hdmi)
  {
 struct nouveau_connector *nv_connector = nouveau_connector(connector);
+   struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
 struct nouveau_drm *drm = nouveau_drm(connector->dev);
 struct dcb_output *dcb = nv_connector->detected_encoder->dcb;

+   if (hdmi && nouveau_hdmimhz > 0)
+   return nouveau_hdmimhz * 1000;
+
+   if (nv_encoder->tmds.max_mhz)
+   /* no HDMI 2.0 for now and not quite clear if we can use
+ * higher HDMI clocks than 297MHz
+ */
+   return min(297, nv_encoder->tmds.max_mhz) * 1000;

So ... will you start reporting 297MHz single-link TMDS bandwidth over DVI now?

What values show up in max_mhz in practice, across the boards you've
tested (ideally a per-generation summary would be nice).


It is a bit silly that those limits are multiple of 10MHz though :/

Fermi (GF119, allthough those caps are there starting with GF110, but
changing the code for that is a bit more messy currently): 230
Kepler: 340
Maxwell+: 600


Do you have ideas on whether the limit shouldn't rather be the minimum 
of 1) the CAPS-indicated limit and 2) the pixel clock PLL limit derived 
from the PLL limits table (and/or other related VBIOS tables)? Is there 
a reason to believe NVIDIA deliberately hard-coded an upper bound of 
297MHz? Can you perhaps try really hard to nudge the official driver to 
set pixel clocks on Kepler somewhere between 297 and 340MHz by messing 
with the VBIOS tables and modelines (even if it fails to bring the 
display up because the PLL never locks or sth...)?


I really want to test this 340MHz limit on Kepler before though.

we also have a few more caps (which are unrelated to the max clock
over DVI, but maybe you have some ideas where we could use them or fix
potential issues we don't know yet how to fix them?):
SINGLE_LVDS18
SINGLE_LVDS24
DUAL_LVDS18
DUAL_LVDS24
SINGLE_TMDS_A
SINGLE_TMDS_B
DUAL_TMDS
DP_A
DP_B

besides that there is tons of stuff inside
open-gpu-doc/Display-Class-Methods/2/cl907d.h, it is the
CORE_NOTIFIER_3_CAPABILITIES stuff.


+
 if (hdmi) {
-   if (nouveau_hdmimhz > 0)
-   return nouveau_hdmimhz * 1000;
-   /* Note: these limits are conservative, some Fermi's
-* can do 297 MHz. Unclear how this can be determined.
-*/
 if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_KEPLER)
 return 297000;
 if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_FERMI)
diff --git a/drm/nouveau/nouveau_encoder.h b/drm/nouveau/nouveau_encoder.h
index f74af5ce..fbef9dc0 100644
--- a/drm/nouveau/nouveau_encoder.h
+++ b/drm/nouveau/nouveau_encoder.h
@@ -65,6 +65,10 @@ struct nouveau_encoder {
 int link_bw;
 bool no_interlace;
 } dp;
+
+   struct {
+   uint16_t max_mhz;
+   } tmds;
 };

 void (*enc_save)(struct drm_encoder *encoder);
--
2.17.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


__

Re: [Nouveau] trouble connecting to Panduit VGA adapter

2017-09-01 Thread Roy Spliet

If this doesn't work I suspect the converter is really blocking/damaging 
the EDID information. The official NVIDIA driver is willing to fall back 
to default modes, but this fall-back was handled less gracefully on 
nouveau last time I checked.


You might be able to use the xrandr tool to manually add a mode for the 
display. Forgive me for not knowing the exact syntax, but from what I 
recall you can use cvt to generate a modeline and copy-paste the 
parameters into an xrandr command to add, then use a second xrandr 
command to enable the display either in mirror mode or positioned 
relative to another display. If you're lucky, that mode corresponds well 
enough with what the projector will accept to just work.



Op 01-09-17 om 18:01 schreef Ilia Mirkin:

Are you running a v4.12-based kernel? If so, update to v4.13-rcN or
integrate 
https://github.com/skeggsb/linux/commit/13a86519202c5d119d83640d6f781f3181205d2c
into your kernel build.

On Fri, Sep 1, 2017 at 12:50 PM, Marko Schuetz-Schmuck
 wrote:

I want to connect to an InFocus projector that sits behind a Panduit VGA
adapter. I use a Thinkpad P51 with a mini display-port to VGA
converter. The laptop runs Manjaro and has the
video-hybrid-intel-nouveau-prime installed and it works with other
monitors. For some reason it does not detect the projector that is
connected through the Panduit. The keyboard shortcut to switch monitor
configuration says "No External Display". xrandr reports only the
built-in screen.

I talked to the technician for the room installation and he told me that
he had seen this before on a Ubuntu machine and that switching to the
proprietary nvidia driver solved that problem. For various reasons I'd
rather not switch to that driver.

I also found some lines with "DRM: DDC responded, but no EDID for DP-1"
in them from around the time I tried connecting to the projector. Could
they be related?

Is there some setting or configuration that can help in this case?

Best regards,

Marko

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: Add support for clockgating on Fermi+

2017-04-25 Thread Roy Spliet


Thanks for the work so far.

A quick scan through the first NVC4 trace at hand, using upstream 
demmio, reveals at least 20 writes to the BLCG registers of PGRAPH and a 
few in PXBAR prior to altering the value of register 0x20200 (see 
below). We know that these are related to the clock gating you enable. 
Are you 110% sure that fiddling with 0x20200 bits without first setting 
these values can *never* cause any issues with stability or correctness, 
even under the weirdest of loads?



Roy

8<--

[0] 96.240915 MMIO32 W 0x4041f0 0xc646 PGRAPH.DISPATCH.HW_BLK.BLCG 
<= 0xc646

[0] 96.240925 MMIO32 W 0x409890 0x0045 PGRAPH.CTXCTL.HW_BLK.BLCG <= 0x45
[0] 96.240935 MMIO32 W 0x4078c0 0x4242 PGRAPH.TPBUS.HW_BLK.BLCG <= 
0x4242
[0] 96.240946 MMIO32 W 0x406000 0x4442 PGRAPH.UNK6000.HW_BLK0.BLCG 
<= 0x4442
[0] 96.240956 MMIO32 W 0x406010 0x4242 PGRAPH.UNK6000.HW_BLK1.BLCG 
<= 0x4242
[0] 96.240966 MMIO32 W 0x405860 0x4242 PGRAPH.UNK5800.HW_BLK.BLCG <= 
0x4242
[0] 96.240977 MMIO32 W 0x40590c 0xc242 PGRAPH.UNK5900.HW_CGBLK.BLCG 
<= 0xc242
[0] 96.240987 MMIO32 W 0x408040 0xc443 PGRAPH.CCACHE.HW_BLK.BLCG <= 
0xc443
[0] 96.240997 MMIO32 W 0x41a890 0x4242 
PGRAPH.GPC_BROADCAST.CTXCTL.HW_BLK.BLCG <= 0x4242
[0] 96.241007 MMIO32 W 0x418500 0xc242 
PGRAPH.GPC_BROADCAST.UNK500.HW_CGBLK.BLCG <= 0xc242
[0] 96.241018 MMIO32 W 0x418608 0xc242 
PGRAPH.GPC_BROADCAST.UNK600.HW_BLK.BLCG <= 0xc242
[0] 96.241028 MMIO32 W 0x418688 0xc242 
PGRAPH.GPC_BROADCAST.UNK680.HW_BLK.BLCG <= 0xc242
[0] 96.241038 MMIO32 W 0x418718 0x0042 
PGRAPH.GPC_BROADCAST.UNK700.HW_BLK.BLCG <= 0x42
[0] 96.241048 MMIO32 W 0x418828 0x8442 
PGRAPH.GPC_BROADCAST.ESETUP.HW_CGBLK.BLCG <= 0x8442
[0] 96.241058 MMIO32 W 0x418bbc 0xc242 
PGRAPH.GPC_BROADCAST.TPBUS.HW_BLK.BLCG <= 0xc242
[0] 96.241069 MMIO32 W 0x418970 0xc242 
PGRAPH.GPC_BROADCAST.ZCULL.HW_BLK.BLCG <= 0xc242
[0] 96.241079 MMIO32 W 0x418c70 0xc242 
PGRAPH.GPC_BROADCAST.TPCONF.HW_BLK.BLCG <= 0xc242
[0] 96.241089 MMIO32 W 0x418cf0 0xc242 
PGRAPH.GPC_BROADCAST.UNKC80.HW_BLK.BLCG <= 0xc242
[0] 96.241102 MMIO32 W 0x418d70 0xc242 
PGRAPH.GPC_BROADCAST.UNKD00.HW_BLK.BLCG <= 0xc242
[0] 96.241112 MMIO32 W 0x418f0c 0xc242 
PGRAPH.GPC_BROADCAST.UNKF00.HW_BLK.BLCG <= 0xc242
[0] 96.241122 MMIO32 W 0x418e0c 0xc242 
PGRAPH.GPC_BROADCAST.UNKE00.HW_BLK.BLCG <= 0xc242
[0] 96.241132 MMIO32 W 0x419020 0xc242 
PGRAPH.GPC_BROADCAST.CCACHE.HW_CGBLK0.BLCG <= 0xc242
[0] 96.241143 MMIO32 W 0x419038 0x0042 
PGRAPH.GPC_BROADCAST.CCACHE.HW_CGBLK1.BLCG <= 0x42
[0] 96.241153 MMIO32 W 0x418898 0x4242 PGRAPH.GPC_BROADCAST.FFB.BLCG 
<= 0x4242
[0] 96.241163 MMIO32 W 0x419a40 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK0.BLCG <= 0xc242
[0] 96.241173 MMIO32 W 0x419a48 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK1.BLCG <= 0xc242
[0] 96.241183 MMIO32 W 0x419a50 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK2.BLCG <= 0xc242
[0] 96.241194 MMIO32 W 0x419a58 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK3.BLCG <= 0xc242
[0] 96.241204 MMIO32 W 0x419a60 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK4.BLCG <= 0xc242
[0] 96.241214 MMIO32 W 0x419a68 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK5.BLCG <= 0xc242
[0] 96.241224 MMIO32 W 0x419a70 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK6.BLCG <= 0xc242
[0] 96.241235 MMIO32 W 0x419a78 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK7.BLCG <= 0xc242
[0] 96.241245 MMIO32 W 0x419a80 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX.HW_CGBLK8.BLCG <= 0xc242
[0] 96.241255 MMIO32 W 0x419acc 0xc742 
PGRAPH.GPC_BROADCAST.TPC_ALL.TEX+0xcc <= 0xc742
[0] 96.241265 MMIO32 W 0x419868 0x8242 
PGRAPH.GPC_BROADCAST.TPC_ALL.POLY.HW_BLK.BLCG <= 0x8242
[0] 96.241275 MMIO32 W 0x419ccc 0x4242 
PGRAPH.GPC_BROADCAST.TPC_ALL.L1.BLCG0 <= 0x4242
[0] 96.241286 MMIO32 W 0x419cd4 0x4242 
PGRAPH.GPC_BROADCAST.TPC_ALL.L1.HW_CGBLK1.BLCG <= 0x4242
[0] 96.241296 MMIO32 W 0x419cdc 0x4242 
PGRAPH.GPC_BROADCAST.TPC_ALL.L1.HW_CGBLK2.BLCG <= 0x4242
[0] 96.241306 MMIO32 W 0x419be8 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.TPBUS.HW_BLK.BLCG <= 0xc242
[0] 96.241316 MMIO32 W 0x419d30 0xc242 
PGRAPH.GPC_BROADCAST.TPC_ALL.MASTER.HW_CGBLK.BLCG <= 0xc242
[0] 96.241326 MMIO32 W 0x419c70 0xc542 
PGRAPH.GPC_BROADCAST.TPC_ALL.UNK400.HW_BLK.BLCG <= 0xc542
[0] 96.241337 MMIO32 W 0x419fc0 0xd04b 
PGRAPH.GPC_BROADCAST.TPC_ALL.MP.HW_BLK0.BLCG <= 0xd04b
[0] 96.241347 MMIO32 W 0x419fd4 0xcb4b 
PGRAPH.GPC_BROADCAST.TPC_ALL.MP.HW_BLK1.BLCG <= 0xcb4b
[0] 96.241357 MMIO32 W 0x419fe8 0xcb4b 
PGRAPH.GPC_BROADCAST.TPC_ALL.MP.HW_BLK2.BLCG <= 0xcb4b
[0] 96.241367 MMIO32 W 0x408810 0xc242 
PGRAPH.ROP_BROADCAST.ZROP.HW_CGBLK0.BLCG <= 0xc242
[0] 96.241377 MMIO32 W 0x408818 0xc242 
PGRAPH.ROP_BROADCAST.ZROP.HW_CGBLK1.BLCG <= 0xc242
[0] 96.241388 MMIO32 W 0x408a80 0xc242 
PGRAPH.ROP_BROADCAST.HW_CGBLK0.BLCG <= 0xc242
[0] 96.241398 MMIO32 W 0x408a

Re: [Nouveau] [PATCH] volt: Improve min/max deteaction of range based volting

2017-04-22 Thread Roy Spliet


Response in-line:


Op 22-04-17 om 13:22 schreef Karol Herbst:

info.min and info.max doesn't always represent the actual voltage range we
can use. Do the same as with the entry based volting.

Fixes "ERROR: Can't get value of subfeature in0_min: Can't read" errors
in sensors.

Signed-off-by: Karol Herbst 
---
  drm/nouveau/nvkm/subdev/volt/base.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drm/nouveau/nvkm/subdev/volt/base.c 
b/drm/nouveau/nvkm/subdev/volt/base.c
index e344901c..61b29c7a 100644
--- a/drm/nouveau/nvkm/subdev/volt/base.c
+++ b/drm/nouveau/nvkm/subdev/volt/base.c
@@ -195,14 +195,16 @@ nvkm_volt_parse_bios(struct nvkm_bios *bios, struct 
nvkm_volt *volt)
data = nvbios_volt_parse(bios, &ver, &hdr, &cnt, &len, &info);
if (data && info.vidmask && info.base && info.step && info.ranged) {
nvkm_debug(subdev, "found ranged based VIDs\n");
-   volt->min_uv = info.min;
-   volt->max_uv = info.max;
+   volt->min_uv = 0x;
+   volt->max_uv = 0;
for (i = 0; i < info.vidmask + 1; i++) {
if (info.base >= info.min &&
info.base <= info.max) {
How bogus are info.min and info.max when you get that error? Is this 
if-statement still valid?

volt->vid[volt->vid_nr].uv = info.base;
volt->vid[volt->vid_nr].vid = i;
volt->vid_nr++;
+   volt->min_uv = min(volt->min_uv, info.base);
+   volt->max_uv = max(volt->max_uv, info.base);
}
info.base += info.step;
}


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 0/4] nouveau_hwmon: migrate to hwmon_device_register_with_info

2017-04-13 Thread Roy Spliet

Just a non-technical (but important!) point: if you send four patches, 
make sure their title (the first line of your git commit messages) 
describes the content. Given you re-used the same title four times, I 
dare to say it's too generic.
Also, I noticed that this is not the standard git patch format as 
produced by git format-patch. I don't know whether this is a concern (or 
whether you tweaked the format yourself), but in the off chance that you 
are relatively new to git, I recommend you to look up the "git 
format-patch" and "git send-email" commands. They make life a lot easier 
in our mailing-list based work-flow!
This being said, thanks for the work! I'm sure with a bit of minor 
tweaking this is suitable for upstream.


Roy

Op 13-04-17 om 10:07 schreef Oscar Salvador:

Hi again,

I've split the patches as Karol Herbst suggested.
I hope now it's fine.

This series of patches introduce the new hwmon_device_register_with_info
and gets rid of the old hwmon_device_register.

This patch adds the default sensors with their possible config values.
Just to prepare for the next patches


--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig  2017-04-12 
19:18:09.638073562 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c   2017-04-12 
19:19:44.244797202 +0200
@@ -692,6 +692,78 @@ static const struct attribute_group hwmo
  static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
  };
+
+static const u32 nouveau_config_chip[] = {
+   HWMON_C_UPDATE_INTERVAL,
+   0
+};
+
+static const u32 nouveau_config_in[] = {
+   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+   0
+};
+
+static const u32 nouveau_config_temp[] = {
+   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+   HWMON_T_EMERGENCY_HYST,
+   0
+};
+
+static const u32 nouveau_config_fan[] = {
+   HWMON_F_INPUT,
+   0
+};
+
+static const u32 nouveau_config_pwm[] = {
+   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+   0
+};
+
+static const u32 nouveau_config_power[] = {
+   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+   0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+   .type = hwmon_chip,
+   .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+   .type = hwmon_temp,
+   .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+   .type = hwmon_fan,
+   .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+   .type = hwmon_in,
+   .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+   .type = hwmon_pwm,
+   .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+   .type = hwmon_power,
+   .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+   &nouveau_chip,
+   &nouveau_temp,
+   &nouveau_fan,
+   &nouveau_in,
+   &nouveau_pwm,
+   &nouveau_power,
+   NULL
+};
  #endif
  
  int

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau


___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

1 2 3 >

1 - 100 of 230 matches

Mail list logo