[Nouveau] pstate for NVS140
I'm trying out the 4.3 RC kernel, major improvements with Nouveau on my old T61 laptop with an NVS140 GPU. Stability and performance both seem massively increased. There are still some stability issues with 3D games and switching resolutions on the fly. 2D performance kicks the pants off the binary driver, 3D performance seems to be catching up. I noticed a module setting for pstate for clocking up and down the GPU, but it's "unimplemented". Dug into the kernel source and saw that my GPU is considered g86 from what I can tell. It calls the g84_clk_new function, which calls the the nv50_clk_new_ code. It looks very much implemented. There's a check in g84_clk_new, checks if the GPU chipset is 0xa0. Anyway, if I just pass in true for the allow_reclock param, it does work, it looks like a lot of chipsets just share the NV50 base code? The clock rates and such appear to be pulled from GPU registers or something. cat pstate 20: core 169 MHz shader 338 MHz memory 100 MHz 21: core 275 MHz shader 550 MHz memory 301 MHz 22: core 400 MHz shader 800 MHz memory 600 MHz AC DC * AC: core 400 MHz shader 800 MHz memory 302 MHz It nets an extra 60-70fps in glxgears, and a handful of FPS in games. Stability wise it works best making adjustments from a virtual console while no graphically intense apps are running in X, ideally even before X starts, it can get unstable during change. I guess long story short, is there anything I can do in regards to testing to help get it enabled upstream for NVS140? Cool stuff. Thanks for all the work on the Nouveau driver. The 4.3 driver is pretty great! ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] External monitor remains black - nouveau reports "link training failed"
Hi list, I had a working dual-monitor setup with KDE Plasma 5 on a Lenovo W530 "Optimus" laptop (hybrid graphics, nouveau + i915 drivers), but it seems to fall apart with recent kernels. My setup works fine with kernels up to and including 4.1.3-201.fc22.x86_64, but with kernel 4.1.6-200.fc22 (as well as another update on top of 4.1.6), the external monitor remains black, and the journal shows several lines kernel: nouveau E[ PDISP][:01:00.0][0x0006] 06:0006:0f48: link training failed not present with previous kernels -- see also https://bugzilla.redhat.com/show_bug.cgi?id=1260053 Bug 1260053 - External monitor remains black with kernel 4.1.6-200.fc22.x86_64 - nouveau reports "link training failed" Any ideas for debugging / narrowing down the issue are much appreciated. Fredy Neeser IBM Zurich Research Laboratory Switzerland ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] pstate for NVS140
On Tue, Sep 15, 2015 at 1:39 AM, Dylan Taft wrote: > I'm trying out the 4.3 RC kernel, major improvements with Nouveau on > my old T61 laptop with an NVS140 GPU. Stability and performance both > seem massively increased. There are still some stability issues with > 3D games and switching resolutions on the fly. 2D performance kicks > the pants off the binary driver, 3D performance seems to be catching > up. > > I noticed a module setting for pstate for clocking up and down the > GPU, but it's "unimplemented". > > Dug into the kernel source and saw that my GPU is considered g86 from > what I can tell. It calls the g84_clk_new function, which calls the > the nv50_clk_new_ code. It looks very much implemented. > > There's a check in g84_clk_new, checks if the GPU chipset is 0xa0. > > Anyway, if I just pass in true for the allow_reclock param, it does > work, it looks like a lot of chipsets just share the NV50 base code? > The clock rates and such appear to be pulled from GPU registers or > something. > > cat pstate > 20: core 169 MHz shader 338 MHz memory 100 MHz > 21: core 275 MHz shader 550 MHz memory 301 MHz > 22: core 400 MHz shader 800 MHz memory 600 MHz AC DC * > AC: core 400 MHz shader 800 MHz memory 302 MHz Note that the memory clock stayed at 300mhz, which isn't great. > > It nets an extra 60-70fps in glxgears, and a handful of FPS in games. > Stability wise it works best making adjustments from a virtual console > while no graphically intense apps are running in X, ideally even > before X starts, it can get unstable during change. > > I guess long story short, is there anything I can do in regards to > testing to help get it enabled upstream for NVS140? Roy, what do you need? At a very minimum, please supply your VBIOS (/sys/kernel/debug/dri/0/vbios.rom), hopefully that'll give some hints as to why memory didn't reclock. A full mmiotrace of the blob driver starting up would be good too, that should include a reclock sequence up to the highest level. (See https://wiki.ubuntu.com/X/MMIOTracing) -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nvs280 / nv34 card only does 1680x1050, not 1920x1080 ?
On 04.09.2015 19:40, poma wrote: > On 04.09.2015 16:56, Ilia Mirkin wrote: >> Tmds is limited to 135mhz on nv3x. If you use analog, you can get full >> resolution. >> On Sep 4, 2015 9:00 AM, "Hans de Goede" wrote: >> >>> Hi All, >>> >>> I've recently acquired a nvs280 card, which is a nv34 >>> gpu based card with a pci-e bridge on the card, this >>> way I can test nv3x problems without needing an agp >>> motherboard. >>> >>> One thing which stands out with this card is that >>> it drivers my dvi lcd monitor at 1680x1050 instead of its >>> native 1920x1080. >>> >>> Is this due to a known limitation on the display pipeline >>> of these cards / nv34 gpu-s. Or is this more likely a bug >>> somewhere ? >>> >>> Regards, >>> >>> Hans >>> > > man 1 cvt > "Create a mode with reduced blanking. ..." > > Enough to fit, > GeForce FX 5200 −DVI− LCD FullHD > > xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 > +hsync -vsync > xrandr --addmode 1920x1080R > xrandr --output --mode 1920x1080R > > > Via xorg conf: /etc/X11/xorg.conf.d/00-FullHD.conf Section "Monitor" Identifier "LCD FullHD" Modeline"1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 +HSync -VSync # Modeline... Option "PreferredMode" "1920x1080R" EndSection Section "Device" Identifier "Chipset NV34" Option "Monitor-" "LCD FullHD" EndSection man 5 xorg.conf ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90871] NV30: Xfwm4 use_compositing - garbled display
https://bugs.freedesktop.org/show_bug.cgi?id=90871 --- Comment #37 from poma --- dmesg - S4 RESUME(THAW) - Xfwm4 "xpresent" - when compositing turned on: nouveau E[ PGRAPH][:01:00.0] (unknown bits 0x0080) nsource: nstatus: nouveau E[ PGRAPH][:01:00.0] ch 1 [Xorg[493]] subc 0 class 0x0039 mthd 0x0100 data 0x -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92032] NV30: WARNING: CPU: 0 PID: 290 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0()
https://bugs.freedesktop.org/show_bug.cgi?id=92032 --- Comment #3 from poma --- BTW it is the same device: "NV30: Xfwm4 use_compositing - garbled display" https://bugs.freedesktop.org/show_bug.cgi?id=90871 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] display: allow up to 16k width/height for fermi+
On 18 September 2015 at 12:31, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> mrnuke on IRC reported that 3x 4K monitors (11520 width total) got
> rejected for some reason. I'm guessing it's this since a single giant
> FB has to be used.
>
> Not sure if the hardware will actually support it, but... who knows.
After looking at the EVO headers, I believe this should be fine. Did
the patch get tested to confirm?
I'd also make the subject "kms" rather than "display".
Ben.
>
> drm/nouveau/nouveau_display.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drm/nouveau/nouveau_display.c b/drm/nouveau/nouveau_display.c
> index 8d0e60d..d3d6438 100644
> --- a/drm/nouveau/nouveau_display.c
> +++ b/drm/nouveau/nouveau_display.c
> @@ -469,9 +469,13 @@ nouveau_display_create(struct drm_device *dev)
> if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA) {
> dev->mode_config.max_width = 4096;
> dev->mode_config.max_height = 4096;
> - } else {
> + } else
> + if (drm->device.info.family < NV_DEVICE_INFO_V0_FERMI) {
> dev->mode_config.max_width = 8192;
> dev->mode_config.max_height = 8192;
> + } else {
> + dev->mode_config.max_width = 16384;
> + dev->mode_config.max_height = 16384;
> }
>
> dev->mode_config.preferred_depth = 24;
> --
> 2.4.6
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau: arm: Add MODULE_FIRMWARE for gk20a
On Wed, Sep 9, 2015 at 11:04 PM, Nicolas Chauvet wrote:
> This patch is needed by initramfs tools to detect
> the required firmware files for the module.
>
> This patch tests for NOUVEAU_PLATFORM_DRIVER and either
> TEGRA_124_SOC or TEGRA_132_SOC for the firmwares related to
> the Tegra K1 generation.
I think you should send this to the Nouveau tree, especially since the
kernel tree probably predates the big refactoring that Nouveau has
undergone.
I also wonder whether these MODULE_FIRMWARE() statements could not be
placed in a more appropriate place, like nouveau_platform.c? This
would allow you to get rid of the test for
CONFIG_NOUVEAU_PLATFORM_DRIVER.
>
> Signed-off-by: Nicolas Chauvet
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index ccefb64..862c225 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -,3 +,14 @@ MODULE_DEVICE_TABLE(pci, nouveau_drm_pci_table);
> MODULE_AUTHOR(DRIVER_AUTHOR);
> MODULE_DESCRIPTION(DRIVER_DESC);
> MODULE_LICENSE("GPL and additional rights");
> +#if defined(CONFIG_NOUVEAU_PLATFORM_DRIVER) && \
> + (IS_ENABLED(CONFIG_ARCH_TEGRA_124_SOC) ||
> IS_ENABLED(CONFIG_ARCH_TEGRA_132_SOC))
> +MODULE_FIRMWARE("nvidia/gk20a/fecs_data.bin");
> +MODULE_FIRMWARE("nvidia/gk20a/fecs_inst.bin");
> +MODULE_FIRMWARE("nvidia/gk20a/gpccs_data.bin");
> +MODULE_FIRMWARE("nvidia/gk20a/gpccs_inst.bin");
> +MODULE_FIRMWARE("nvidia/gk20a/sw_bundle_init.bin");
> +MODULE_FIRMWARE("nvidia/gk20a/sw_ctx.bin");
> +MODULE_FIRMWARE("nvidia/gk20a/sw_method_init.bin");
> +MODULE_FIRMWARE("nvidia/gk20a/sw_nonctx.bin");
> +#endif
> --
> 2.4.3
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] display: allow up to 16k width/height for fermi+
On Fri, Sep 18, 2015 at 9:41 AM, Ben Skeggs wrote:
> On 18 September 2015 at 12:31, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> mrnuke on IRC reported that 3x 4K monitors (11520 width total) got
>> rejected for some reason. I'm guessing it's this since a single giant
>> FB has to be used.
>>
>> Not sure if the hardware will actually support it, but... who knows.
> After looking at the EVO headers, I believe this should be fine. Did
> the patch get tested to confirm?
Not yet. Although in the meanwhile I realized that I don't actually
need 3x 4K monitors... I can just run this patch and do something like
xrandr --fb 16384x16384. But unfortunately there's no monitor
connected in my setup where I can reload nouveau easily, and I reboot
rarely where I do have monitors connected.
>
> I'd also make the subject "kms" rather than "display".
>
> Ben.
>
>>
>> drm/nouveau/nouveau_display.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drm/nouveau/nouveau_display.c b/drm/nouveau/nouveau_display.c
>> index 8d0e60d..d3d6438 100644
>> --- a/drm/nouveau/nouveau_display.c
>> +++ b/drm/nouveau/nouveau_display.c
>> @@ -469,9 +469,13 @@ nouveau_display_create(struct drm_device *dev)
>> if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA) {
>> dev->mode_config.max_width = 4096;
>> dev->mode_config.max_height = 4096;
>> - } else {
>> + } else
>> + if (drm->device.info.family < NV_DEVICE_INFO_V0_FERMI) {
>> dev->mode_config.max_width = 8192;
>> dev->mode_config.max_height = 8192;
>> + } else {
>> + dev->mode_config.max_width = 16384;
>> + dev->mode_config.max_height = 16384;
>> }
>>
>> dev->mode_config.preferred_depth = 24;
>> --
>> 2.4.6
>>
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] display: allow up to 16k width/height for fermi+
On 19 September 2015 at 03:24, Ilia Mirkin wrote:
> On Fri, Sep 18, 2015 at 9:41 AM, Ben Skeggs wrote:
>> On 18 September 2015 at 12:31, Ilia Mirkin wrote:
>>> Signed-off-by: Ilia Mirkin
>>> ---
>>>
>>> mrnuke on IRC reported that 3x 4K monitors (11520 width total) got
>>> rejected for some reason. I'm guessing it's this since a single giant
>>> FB has to be used.
>>>
>>> Not sure if the hardware will actually support it, but... who knows.
>> After looking at the EVO headers, I believe this should be fine. Did
>> the patch get tested to confirm?
>
> Not yet. Although in the meanwhile I realized that I don't actually
> need 3x 4K monitors... I can just run this patch and do something like
> xrandr --fb 16384x16384. But unfortunately there's no monitor
> connected in my setup where I can reload nouveau easily, and I reboot
> rarely where I do have monitors connected.
Doh! True :)
>
>>
>> I'd also make the subject "kms" rather than "display".
>>
>> Ben.
>>
>>>
>>> drm/nouveau/nouveau_display.c | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drm/nouveau/nouveau_display.c b/drm/nouveau/nouveau_display.c
>>> index 8d0e60d..d3d6438 100644
>>> --- a/drm/nouveau/nouveau_display.c
>>> +++ b/drm/nouveau/nouveau_display.c
>>> @@ -469,9 +469,13 @@ nouveau_display_create(struct drm_device *dev)
>>> if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA) {
>>> dev->mode_config.max_width = 4096;
>>> dev->mode_config.max_height = 4096;
>>> - } else {
>>> + } else
>>> + if (drm->device.info.family < NV_DEVICE_INFO_V0_FERMI) {
>>> dev->mode_config.max_width = 8192;
>>> dev->mode_config.max_height = 8192;
>>> + } else {
>>> + dev->mode_config.max_width = 16384;
>>> + dev->mode_config.max_height = 16384;
>>> }
>>>
>>> dev->mode_config.preferred_depth = 24;
>>> --
>>> 2.4.6
>>>
>>> ___
>>> Nouveau mailing list
>>> Nouveau@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau: arm: Add MODULE_FIRMWARE for gk20a
On 19 September 2015 at 01:52, Alexandre Courbot wrote:
> On Wed, Sep 9, 2015 at 11:04 PM, Nicolas Chauvet wrote:
>> This patch is needed by initramfs tools to detect
>> the required firmware files for the module.
>>
>> This patch tests for NOUVEAU_PLATFORM_DRIVER and either
>> TEGRA_124_SOC or TEGRA_132_SOC for the firmwares related to
>> the Tegra K1 generation.
>
> I think you should send this to the Nouveau tree, especially since the
> kernel tree probably predates the big refactoring that Nouveau has
> undergone.
>
> I also wonder whether these MODULE_FIRMWARE() statements could not be
> placed in a more appropriate place, like nouveau_platform.c? This
> would allow you to get rid of the test for
> CONFIG_NOUVEAU_PLATFORM_DRIVER.
Is there any need to be conditional at all? For dGPUs we're going to
have to have them all unconditional anyway, as we have know way of
knowing which GPU it's going to be used with.
Ben.
>
>>
>> Signed-off-by: Nicolas Chauvet
>> ---
>> drivers/gpu/drm/nouveau/nouveau_drm.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index ccefb64..862c225 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> @@ -,3 +,14 @@ MODULE_DEVICE_TABLE(pci, nouveau_drm_pci_table);
>> MODULE_AUTHOR(DRIVER_AUTHOR);
>> MODULE_DESCRIPTION(DRIVER_DESC);
>> MODULE_LICENSE("GPL and additional rights");
>> +#if defined(CONFIG_NOUVEAU_PLATFORM_DRIVER) && \
>> + (IS_ENABLED(CONFIG_ARCH_TEGRA_124_SOC) ||
>> IS_ENABLED(CONFIG_ARCH_TEGRA_132_SOC))
>> +MODULE_FIRMWARE("nvidia/gk20a/fecs_data.bin");
>> +MODULE_FIRMWARE("nvidia/gk20a/fecs_inst.bin");
>> +MODULE_FIRMWARE("nvidia/gk20a/gpccs_data.bin");
>> +MODULE_FIRMWARE("nvidia/gk20a/gpccs_inst.bin");
>> +MODULE_FIRMWARE("nvidia/gk20a/sw_bundle_init.bin");
>> +MODULE_FIRMWARE("nvidia/gk20a/sw_ctx.bin");
>> +MODULE_FIRMWARE("nvidia/gk20a/sw_method_init.bin");
>> +MODULE_FIRMWARE("nvidia/gk20a/sw_nonctx.bin");
>> +#endif
>> --
>> 2.4.3
>>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau: arm: Add MODULE_FIRMWARE for gk20a
On Sat, Sep 19, 2015 at 3:17 AM, Ben Skeggs wrote: > On 19 September 2015 at 01:52, Alexandre Courbot wrote: >> On Wed, Sep 9, 2015 at 11:04 PM, Nicolas Chauvet wrote: >>> This patch is needed by initramfs tools to detect >>> the required firmware files for the module. >>> >>> This patch tests for NOUVEAU_PLATFORM_DRIVER and either >>> TEGRA_124_SOC or TEGRA_132_SOC for the firmwares related to >>> the Tegra K1 generation. >> >> I think you should send this to the Nouveau tree, especially since the >> kernel tree probably predates the big refactoring that Nouveau has >> undergone. >> >> I also wonder whether these MODULE_FIRMWARE() statements could not be >> placed in a more appropriate place, like nouveau_platform.c? This >> would allow you to get rid of the test for >> CONFIG_NOUVEAU_PLATFORM_DRIVER. > Is there any need to be conditional at all? For dGPUs we're going to > have to have them all unconditional anyway, as we have know way of > knowing which GPU it's going to be used with. For dGPU there is indeed probably no use to make it conditional. But do we really want to include the Tegra-specific firmwares on x86 initramsfs? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] PWM-based voltage management input clock
Hello, We recently reverse engineered PWM-based voltage management but found an odity in the input clock frequency for the PWM controller. It seems like RM is assuming an input clock of 27.648 MHz instead of the actual 27MHz crystal found on the board. I thus have the following questions: - Is it a fixed value hardcoded in RM? (Current way it is done in Nouveau) - Should we use crystal_MHz * 1.024? I could spend some time hooking up my osciloscope to the VR to check if it is a bringup issue but it would not help Nouveau much as we need to reproduce the behaviour of RM anyway since this is the only validated configuration. Thanks in advance, Martin PS: The registers for this PWM controller are 0x20340 and 0x20344. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] PWM-based voltage management input clock
Thanks, Martin. I'll try to follow up on this next week and get you an answer. What GPUs have you observed this on? On Fri, Sep 18, 2015 at 11:13:53PM +0300, Martin Peres wrote: > Hello, > > We recently reverse engineered PWM-based voltage management but found an > odity in the input clock frequency for the PWM controller. It seems like RM > is assuming an input clock of 27.648 MHz instead of the actual 27MHz crystal > found on the board. > > I thus have the following questions: > - Is it a fixed value hardcoded in RM? (Current way it is done in Nouveau) > - Should we use crystal_MHz * 1.024? > > I could spend some time hooking up my osciloscope to the VR to check if it > is a bringup issue but it would not help Nouveau much as we need to > reproduce the behaviour of RM anyway since this is the only validated > configuration. > > Thanks in advance, > Martin > > PS: The registers for this PWM controller are 0x20340 and 0x20344. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91738] [NV117] NULL deref in nvkm_i2c_try_acquire_pad, kernel 4.1
https://bugs.freedesktop.org/show_bug.cgi?id=91738 --- Comment #16 from ryanpcmcquen --- Ilia, should I change the status of this bug? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
