similar to: Delays in DRM nouveau_bios.c

On Fri, 02 Oct 2009 00:07:07 +0100 Stuart Bennett <stuart at freedesktop.org> wrote: > Pekka Paalanen wrote: > > Hi Stuart, > > > > I'm not sure you know, but annarchy just lost all user homes. > > Could you push vbtracetool and whatever personal git repos you > > had, so we can clone them? > > Hey Pekka, I've re-upped vbtracetool and

--- drivers/gpu/drm/nouveau/nouveau_bios.c | 47 ++++++++++++++----------------- 1 files changed, 21 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 5eec5ed..04ac564 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -181,43 +181,42 @@ struct methods { const char

We just need to clear the SBA and ENABLE bits to reset the AGP controller: If the AGP bridge was configured to use "fast writes", clearing the FW bit would break the subsequent MMIO writes and eventually end with a lockup. Note that all the BIOSes I've seen do the same as we did (it works for them because they don't use MMIO), OTOH the blob leaves FW untouched. Signed-off-by:

http://bugs.freedesktop.org/show_bug.cgi?id=18234 Summary: c51 lvds script failure in randr12 mode. if I start the X server the screen is black and the framebuffer too because it trys to link the whole output to the monitor Product: xorg Version: 7.3 Platform: Other OS/Version: Linux (All)

usleep() was being used without checking its return value. When the server receives SIGALRM or SIGIO the waits are shortened and random modesetting failures happen: Use nanosleep and loop around it until the requested time has elapsed. --- src/nouveau_hw.c | 2 +- src/nouveau_local.h | 6 ++++++ src/nv_bios.c | 2 +- src/nv_crtc.c | 2 +- src/nv_include.h | 1 +

Using the ARRAY_SIZE macro improves the readability of the code. Also, it is useless to re-invent it. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p /sizeof(T)) ) Reviewed-by: Thierry Reding <treding at nvidia.com> Signed-off-by: Jérémy

Using the ARRAY_SIZE macro improves the readability of the code. Also, it is not always useful to use a variable to store this constant calculated at compile time nor to re-invent the ARRAY_SIZE macro. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p

http://bugs.freedesktop.org/show_bug.cgi?id=14597 Summary: randr12 failures on 12" powerbooks, and workarounds Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

Hi everyone, Using ARRAY_SIZE improves the code readability. I used coccinelle (I made a change to the array_size.cocci file [1]) to find several places where ARRAY_SIZE could be used instead of other macros or sizeof division. I tried to divide the changes into a patch per subsystem (excepted for staging). If one of the patch should be split into several patches, let me know. In order to reduce

Hi Thomas. On Tue, Nov 24, 2020 at 12:38:18PM +0100, Thomas Zimmermann wrote: > Using struct drm_device.pdev is deprecated. Convert nouveau to struct > drm_device.dev. No functional changes. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > Cc: Ben Skeggs <bskeggs at redhat.com> Suggestion to an alternative implmentation below. > --- >

This is the first time I have tried UBSAN on this specific machine (onboard nforce 420 with HP BIOS on Nance mainboard). nouveau seems to be working fine but gives this UBSAN warning: [ 7.953957] nouveau 0000:00:0d.0: NVIDIA C61 (04c000a2) [ 7.965101] nouveau 0000:00:0d.0: bios: version 05.61.32.25.02 [ 7.966141] nouveau 0000:00:0d.0: fb: 128 MiB of unknown memory type [ 8.015336]

The nouveau driver makes a number of unaligned accesses via the ROM16(), ROM32() and ROM64() macros which fault on SPARC (but would be transparently handled by x86 hardware). Making use of get_unaligned() macro fixes the problem for me. diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.h b/drivers/gpu/drm/nouveau/nouveau_bios.h index 7ccd28f..92031f6 100644 ---

This can show up on SPARC or other architectures that don't handle unaligned accesses. The kernel normally fixes these up, but it shouldn't have to. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nouveau_bios.h | 6 ++---- drm/nouveau/nvkm/subdev/mxm/mxms.c | 4 ++-- 2 files changed, 4

https://bugs.freedesktop.org/show_bug.cgi?id=96836 Bug ID: 96836 Summary: Kernel unaligned access at TPC[105d9fb4] nvkm_instobj_wr32+0x14/0x20 [nouveau] Product: xorg Version: unspecified Hardware: SPARC OS: Linux (All) Status: NEW Severity: normal Priority: medium

Absence of a TMDS Info Table is common on Optimus setups where the NVIDIA gpu is not connected directly to any outputs. Reporting an error in this scenario is too harsh. Accordingly, change the error message to an info message. By default the error message also causes a boot flicker for these sytems. Signed-off-by: Rhys Kidd <rhyskidd at gmail.com> ---

Variable entry is not effectively used, so delete it. drivers/gpu/drm/nouveau/nouveau_connector.c:1298:7: warning: variable 'entry' set but not used. Reported-by: Abaci Robot <abaci at linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5596 Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com> --- drivers/gpu/drm/nouveau/nouveau_connector.c

Optimus cards with no outputs trigger this message (NVD7, for example) This commit changes the warning into an informational message. The return value of the function is not used, so I left it at -EINVAL. Signed-off-by: Albert Pool <albertpool at solcon.nl> Cc: Emil Velikov <emil.l.velikov at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 3 ++- 1 file changed, 2

This adds basic support for driving sensor chips off the nvidia i2c buses, along with basic support for reading the internal GPU sensor on supported chipsets. It's heavily cribbed off nvclock. Having scanned a large number of bioses, I'm pretty convinced that the appropriate i2c bus is always number 2 in the list on <g80 - I'm not sure about later cards yet. There's still a lot

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c