[Bug 39782] [r300g] XvMC playback fails with MPEG2 video and RV350
https://bugs.freedesktop.org/show_bug.cgi?id=39782 --- Comment #9 from Chris Rankin 2012-01-04 15:35:06 PST --- The following commit does not resolve this bug: commit 7b181d16c3b954bf567563e90e5e94bda833fab8 Author: Christian K?nig Date: Wed Jan 4 15:59:29 2012 +0100 vl/mpeg2: simple fix to get xine running again Otherwise xines xxmc plugin will just display green blocks. Signed-off-by: Christian K?nig xine is still showing a green video window with my RV350. $ mplayer -vo xvmc -vc ffmpeg12mc isn't working here either. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*
Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a écrit : > Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a écrit : > > On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault > > wrote: > > > > > At home only. At work, with a different VGA screen, I'm still getting > > > the issue. > > > > You're still having a problem with the LVDS screen at work with FBC > > disabled? > > Yes, though it now seems random, sometimes it works, sometimes not. I have just tried a fresh 3.2 once, without problem. Within a few days, I'll know whether it's luck or magical-fixup. Samuel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On 01/04/2012 12:37 AM, Alex Deucher wrote: On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller wrote: On 01/03/2012 03:27 PM, Alex Deucher wrote: On Mon, Jan 2, 2012 at 5:07 PM, Helge Dellerwrote: I'm facing the problem with the radeon drm driver, that I now manually need to set the kernel module parameter radeon.no_wb to 1 at bootup, else X just hangs in average up to 8 seconds per minute without any real activity (X or the video driver just seems to wait for something..). Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while all following Fedora distributions including F16 have this problem. I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. I did compared the sources of those kernels and the only obvious change to me is in radeon_ring.c: radeon_ring_free_size() where those lines were added at the top of the function: if (rdev->wb.enabled) rdev->cp.rptr = le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); Given the problems I'm seeing (X-Windows hangs for a few seconds every time) this fits with the idea, that the driver is waiting for a free slot but can't find any (maybe due to wrong values returned by not-working WB?). I'm wondering, if "rdev->wb.enabled" is correct in this place and if "dev_priv->writeback_works" shouldn't be used instead here? It's possible that writeback doesn't work on your system in which case no_wb=1 is apprioriate. dev_priv->writeback_works is part of the old UMS drm and is not used by KMS. The KMS code does not test if writeback works prior to enabling it like UMS did. The slow down you are seeing is caused by the driver waiting for the fence to be written back to memory. If writeback does not work, the fence is never written by the hw and the driver has to wait for the fence to time out. Alex, thanks for the explanations. In my opinion this is a regression then. The old code worked without problems, while with the new driver (or only because of the added code lines) the driver doesn't work out of the box. I just posted a patch to disable writeback by default on KMS on pre-R300 chips: http://lists.freedesktop.org/archives/dri-devel/2012-January/017829.html Thanks a lot for this patch and especially for scheduling it for inclusion into the stable kernel series! It should fix my problems. Helge Wouldn't it be an idea to port over the old UMS writeback-check-test to the new KMS code base to avoid the issues I'm seeing? Maybe, assuming the writeback test reliably fails which I'm not sure is the case. UMS didn't utilize the hardware to the same extent that KMS does so it was less likely to be an issue there. Alex I would be willing to test such code or even provide an initial patch if necessary. Helge ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44466] Assertion 'LLVMOffsetOfElement' when running Furmark with wine
https://bugs.freedesktop.org/show_bug.cgi?id=44466 --- Comment #1 from Laurent carlier 2012-01-04 15:03:09 PST --- It doesn't assert with DRAW_USE_LLVM=0 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] drm: add support for private planes
note: looks like I need to rebase this patch after exynos drm driver
was pulled to drm-next.. if there are some other consumers that are
waiting to be pulled, let me know and I'll just rebase on top of that.
(Either way, it would be a trivial merge conflict.. just add FALSE as
additional arg to drm_plane_init())
BR,
-R
On Tue, Dec 13, 2011 at 8:19 PM, Rob Clark wrote:
> From: Rob Clark
>
> In cases where the scanout hw is sufficiently similar between "overlay"
> and traditional crtc layers, it might be convenient to allow the driver
> to create internal drm_plane helper objects used by the drm_crtc
> implementation, rather than duplicate code between the plane and crtc.
> A private plane is not exposed to userspace.
>
> Signed-off-by: Rob Clark
> ---
> ?drivers/gpu/drm/drm_crtc.c | ? 22 +-
> ?include/drm/drm_crtc.h ? ? | ? ?3 ++-
> ?2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6dad421..d73746e 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -557,7 +557,8 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
> ?int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> ? ? ? ? ? ? ? ? ? unsigned long possible_crtcs,
> ? ? ? ? ? ? ? ? ? const struct drm_plane_funcs *funcs,
> - ? ? ? ? ? ? ? ? ?uint32_t *formats, uint32_t format_count)
> + ? ? ? ? ? ? ? ? ?const uint32_t *formats, uint32_t format_count,
> + ? ? ? ? ? ? ? ? ?bool priv)
> ?{
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
>
> @@ -576,8 +577,16 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane,
> ? ? ? ?plane->format_count = format_count;
> ? ? ? ?plane->possible_crtcs = possible_crtcs;
>
> - ? ? ? list_add_tail(&plane->head, &dev->mode_config.plane_list);
> - ? ? ? dev->mode_config.num_plane++;
> + ? ? ? /* private planes are not exposed to userspace, but depending on
> + ? ? ? ?* display hardware, might be convenient to allow sharing programming
> + ? ? ? ?* for the scanout engine with the crtc implementation.
> + ? ? ? ?*/
> + ? ? ? if (!priv) {
> + ? ? ? ? ? ? ? list_add_tail(&plane->head, &dev->mode_config.plane_list);
> + ? ? ? ? ? ? ? dev->mode_config.num_plane++;
> + ? ? ? } else {
> + ? ? ? ? ? ? ? INIT_LIST_HEAD(&plane->head);
> + ? ? ? }
>
> ? ? ? ?mutex_unlock(&dev->mode_config.mutex);
>
> @@ -592,8 +601,11 @@ void drm_plane_cleanup(struct drm_plane *plane)
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
> ? ? ? ?kfree(plane->format_types);
> ? ? ? ?drm_mode_object_put(dev, &plane->base);
> - ? ? ? list_del(&plane->head);
> - ? ? ? dev->mode_config.num_plane--;
> + ? ? ? /* if not added to a list, it must be a private plane */
> + ? ? ? if (!list_empty(&plane->head)) {
> + ? ? ? ? ? ? ? list_del(&plane->head);
> + ? ? ? ? ? ? ? dev->mode_config.num_plane--;
> + ? ? ? }
> ? ? ? ?mutex_unlock(&dev->mode_config.mutex);
> ?}
> ?EXPORT_SYMBOL(drm_plane_cleanup);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index dd55727..1354ef5 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -828,7 +828,8 @@ extern int drm_plane_init(struct drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_plane *plane,
> ? ? ? ? ? ? ? ? ? ? ? ? ?unsigned long possible_crtcs,
> ? ? ? ? ? ? ? ? ? ? ? ? ?const struct drm_plane_funcs *funcs,
> - ? ? ? ? ? ? ? ? ? ? ? ? uint32_t *formats, uint32_t format_count);
> + ? ? ? ? ? ? ? ? ? ? ? ? const uint32_t *formats, uint32_t format_count,
> + ? ? ? ? ? ? ? ? ? ? ? ? bool private);
> ?extern void drm_plane_cleanup(struct drm_plane *plane);
>
> ?extern void drm_encoder_cleanup(struct drm_encoder *encoder);
> --
> 1.7.5.4
>
[Bug 44466] New: Assertion 'LLVMOffsetOfElement' when running Furmark with wine
https://bugs.freedesktop.org/show_bug.cgi?id=44466 Bug #: 44466 Summary: Assertion 'LLVMOffsetOfElement' when running Furmark with wine Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: lordheavym at gmail.com * Mesa (32 bit under 64 os) from git built with llvm 3.0 * Radeon HD 4850 * Last wine version Mesa is built with llvm 3.0, the bug doesn't seem to occur with llvm 2.9 Here is the output: [lordh at archMain FurMark_1.9.2]$ wine FurMark.exe err:module:load_builtin_dll failed to load .so lib for builtin L"winemp3.acm": libmpg123.so.0: Ne peut ouvrir le fichier d'objet partag?: Aucun fichier ou dossier de ce type fixme:heap:HeapSetInformation (nil) 1 (nil) 0 fixme:win:EnumDisplayDevicesW ((null),0,0x33eaf0,0x), stub! err:wgl:X11DRV_wglGetPixelFormatAttribivARB (0x3b0): unexpected iPixelFormat(0) vs nFormats(175), returns FALSE Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS) fixme:win:EnumDisplayDevicesW ((null),0,0x33e4c4,0x), stub! fixme:win:EnumDisplayDevicesW ((null),1,0x33e4c4,0x), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33ec98,0x), stub! err:wgl:X11DRV_wglGetPixelFormatAttribivARB (0x3cc): unexpected iPixelFormat(0) vs nFormats(175), returns FALSE Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_GEOMETRY_UNIFORM_COMPONENTS) fixme:win:EnumDisplayDevicesW ((null),0,0xf0e28c,0x), stub! err:wgl:X11DRV_wglGetPixelFormatAttribivARB (0x710): unexpected iPixelFormat(0) vs nFormats(175), returns FALSE Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_GEOMETRY_UNIFORM_COMPONENTS) draw/draw_llvm.c:160:create_jit_texture_type: Assertion `LLVMOffsetOfElement(target, texture_type, DRAW_JIT_TEXTURE_DATA) == __builtin_offsetof (struct draw_jit_texture, data)' failed. wine: Unhandled exception 0x8003 at address 0x7cb9cfea (thread 0025), starting debugger... fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:compute_location Only supporting one breg (ecx/18 -> eax/17) fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9e fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d _debug_assert_fail () at /build/src/build/src/gallium/auxiliary/util/u_debug.c:278 0x7cb9cfea _debug_assert_fail+0x57 [/build/src/build/src/gallium/auxiliary/util/u_debug.c:278] in r600_dri.so: int $3 Unable to access file '/build/src/build/src/gallium/auxiliary/util/u_debug.c' Modules: Module Address Debug info Name (91 modules) PE40- 7db000 Deferredfurmark PE7e- 9c5000 Deferredfreeimage PE 1000-1022e000 Deferredcore3d ELF 7b80-7b9c4000 Deferredkernel32 \-PE 7b81-7b9c4000 \ kernel32 ELF 7bc0-7bcd2000 Deferredntdll \-PE 7bc1-7bcd2000 \ ntdll ELF 7bdc5000-7be0 Deferredusp10 \-PE 7bdd-7be0 \ usp10 ELF 7bf0-7bf04000 Deferred ELF 7c2d9000-7c40 Deferredlibglsl.so ELF 7c4b7000-7c742000 Deferredl
Re: [PATCH 2/2] drm: add support for private planes
note: looks like I need to rebase this patch after exynos drm driver
was pulled to drm-next.. if there are some other consumers that are
waiting to be pulled, let me know and I'll just rebase on top of that.
(Either way, it would be a trivial merge conflict.. just add FALSE as
additional arg to drm_plane_init())
BR,
-R
On Tue, Dec 13, 2011 at 8:19 PM, Rob Clark wrote:
> From: Rob Clark
>
> In cases where the scanout hw is sufficiently similar between "overlay"
> and traditional crtc layers, it might be convenient to allow the driver
> to create internal drm_plane helper objects used by the drm_crtc
> implementation, rather than duplicate code between the plane and crtc.
> A private plane is not exposed to userspace.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_crtc.c | 22 +-
> include/drm/drm_crtc.h | 3 ++-
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 6dad421..d73746e 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -557,7 +557,8 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
> int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> unsigned long possible_crtcs,
> const struct drm_plane_funcs *funcs,
> - uint32_t *formats, uint32_t format_count)
> + const uint32_t *formats, uint32_t format_count,
> + bool priv)
> {
> mutex_lock(&dev->mode_config.mutex);
>
> @@ -576,8 +577,16 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane,
> plane->format_count = format_count;
> plane->possible_crtcs = possible_crtcs;
>
> - list_add_tail(&plane->head, &dev->mode_config.plane_list);
> - dev->mode_config.num_plane++;
> + /* private planes are not exposed to userspace, but depending on
> + * display hardware, might be convenient to allow sharing programming
> + * for the scanout engine with the crtc implementation.
> + */
> + if (!priv) {
> + list_add_tail(&plane->head, &dev->mode_config.plane_list);
> + dev->mode_config.num_plane++;
> + } else {
> + INIT_LIST_HEAD(&plane->head);
> + }
>
> mutex_unlock(&dev->mode_config.mutex);
>
> @@ -592,8 +601,11 @@ void drm_plane_cleanup(struct drm_plane *plane)
> mutex_lock(&dev->mode_config.mutex);
> kfree(plane->format_types);
> drm_mode_object_put(dev, &plane->base);
> - list_del(&plane->head);
> - dev->mode_config.num_plane--;
> + /* if not added to a list, it must be a private plane */
> + if (!list_empty(&plane->head)) {
> + list_del(&plane->head);
> + dev->mode_config.num_plane--;
> + }
> mutex_unlock(&dev->mode_config.mutex);
> }
> EXPORT_SYMBOL(drm_plane_cleanup);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index dd55727..1354ef5 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -828,7 +828,8 @@ extern int drm_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> unsigned long possible_crtcs,
> const struct drm_plane_funcs *funcs,
> - uint32_t *formats, uint32_t format_count);
> + const uint32_t *formats, uint32_t format_count,
> + bool private);
> extern void drm_plane_cleanup(struct drm_plane *plane);
>
> extern void drm_encoder_cleanup(struct drm_encoder *encoder);
> --
> 1.7.5.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On 01/04/2012 12:37 AM, Alex Deucher wrote: > On Tue, Jan 3, 2012 at 6:12 PM, Helge Deller wrote: >> On 01/03/2012 03:27 PM, Alex Deucher wrote: >>> >>> On Mon, Jan 2, 2012 at 5:07 PM, Helge Dellerwrote: I'm facing the problem with the radeon drm driver, that I now manually need to set the kernel module parameter radeon.no_wb to 1 at bootup, else X just hangs in average up to 8 seconds per minute without any real activity (X or the video driver just seems to wait for something..). Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while all following Fedora distributions including F16 have this problem. I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. I did compared the sources of those kernels and the only obvious change to me is in radeon_ring.c: radeon_ring_free_size() where those lines were added at the top of the function: if (rdev->wb.enabled) rdev->cp.rptr = le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); Given the problems I'm seeing (X-Windows hangs for a few seconds every time) this fits with the idea, that the driver is waiting for a free slot but can't find any (maybe due to wrong values returned by not-working WB?). I'm wondering, if "rdev->wb.enabled" is correct in this place and if "dev_priv->writeback_works" shouldn't be used instead here? >>> >>> It's possible that writeback doesn't work on your system in which case >>> no_wb=1 is apprioriate. dev_priv->writeback_works is part of the old >>> UMS drm and is not used by KMS. The KMS code does not test if >>> writeback works prior to enabling it like UMS did. The slow down you >>> are seeing is caused by the driver waiting for the fence to be written >>> back to memory. If writeback does not work, the fence is never >>> written by the hw and the driver has to wait for the fence to time >>> out. >> >> >> Alex, thanks for the explanations. >> In my opinion this is a regression then. The old code worked without >> problems, while with the new driver (or only because of the added code >> lines) the driver doesn't work out of the box. > > I just posted a patch to disable writeback by default on KMS on pre-R300 > chips: > http://lists.freedesktop.org/archives/dri-devel/2012-January/017829.html Thanks a lot for this patch and especially for scheduling it for inclusion into the stable kernel series! It should fix my problems. Helge > > >> Wouldn't it be an idea to port over the old UMS writeback-check-test to the >> new KMS code base to avoid the issues I'm seeing? > > Maybe, assuming the writeback test reliably fails which I'm not sure > is the case. UMS didn't utilize the hardware to the same extent that > KMS does so it was less likely to be an issue there. > > Alex > >> I would be willing to test such code or even provide an initial patch if >> necessary. >> >> Helge
[PULL] drm-intel-next
Here are the rest of the 3.3 pending changes. This has a bunch of small bug fixes and overlay plane support for i915. The following changes since commit 7a7e8734ac3235efafd34819b27fbdf5417e6d60: Merge branch 'drm-radeon-testing' of ../drm-radeon-next into drm-core-next (2012-01-03 09:45:12 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-next Ben Widawsky (4): drm/i915: relative_constants_mode race fix drm/i915: Force sync command ordering (Gen6+) drm/i915: Update GEN6_RP_CONTROL definitions drm/i915: drpc debugfs update for gen6 Daniel Vetter (2): drm/i915: kicking rings stuck on semaphores considered harmful drm/i915: don't bail out of intel_wait_ring_buffer too early Eric Anholt (5): drm/i915: Set two chicken bits implicated in missed IRQs on Ivybridge. drm/i915: Do the fallback non-IRQ wait in ring throttle, too. drm/i915: Work around gen7 BLT ring synchronization issues. drm/i915: Make the fallback IRQ wait not sleep. drm/i915: Add support for resetting the SO write pointers on gen7. Jesse Barnes (5): drm/i915: add SNB and IVB video sprite support v6 drm/i915: track sprite coverage and disable primary plane if possible drm/i915: add color key support v4 drm/i915: don't disable a PCH DPLL that's in use drm/i915: only set the intel_crtc DPMS mode to on if the mode set succeeded Keith Packard (1): drm/i915: Clean up multi-threaded forcewake patch drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/i915_debugfs.c| 86 - drivers/gpu/drm/i915/i915_dma.c|5 + drivers/gpu/drm/i915/i915_drv.c|7 - drivers/gpu/drm/i915/i915_drv.h|6 +- drivers/gpu/drm/i915/i915_gem.c| 10 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 63 +++- drivers/gpu/drm/i915/i915_irq.c|7 - drivers/gpu/drm/i915/i915_reg.h| 161 +++- drivers/gpu/drm/i915/intel_display.c | 206 - drivers/gpu/drm/i915/intel_drv.h | 40 ++ drivers/gpu/drm/i915/intel_fb.c|6 + drivers/gpu/drm/i915/intel_ringbuffer.c| 30 ++- drivers/gpu/drm/i915/intel_sprite.c| 668 include/drm/i915_drm.h | 40 ++ 15 files changed, 1290 insertions(+), 46 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_sprite.c -- keith.pack...@intel.com pgpwDnpU9tUBR.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Here are the rest of the 3.3 pending changes. This has a bunch of small bug fixes and overlay plane support for i915. The following changes since commit 7a7e8734ac3235efafd34819b27fbdf5417e6d60: Merge branch 'drm-radeon-testing' of ../drm-radeon-next into drm-core-next (2012-01-03 09:45:12 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-next Ben Widawsky (4): drm/i915: relative_constants_mode race fix drm/i915: Force sync command ordering (Gen6+) drm/i915: Update GEN6_RP_CONTROL definitions drm/i915: drpc debugfs update for gen6 Daniel Vetter (2): drm/i915: kicking rings stuck on semaphores considered harmful drm/i915: don't bail out of intel_wait_ring_buffer too early Eric Anholt (5): drm/i915: Set two chicken bits implicated in missed IRQs on Ivybridge. drm/i915: Do the fallback non-IRQ wait in ring throttle, too. drm/i915: Work around gen7 BLT ring synchronization issues. drm/i915: Make the fallback IRQ wait not sleep. drm/i915: Add support for resetting the SO write pointers on gen7. Jesse Barnes (5): drm/i915: add SNB and IVB video sprite support v6 drm/i915: track sprite coverage and disable primary plane if possible drm/i915: add color key support v4 drm/i915: don't disable a PCH DPLL that's in use drm/i915: only set the intel_crtc DPMS mode to on if the mode set succeeded Keith Packard (1): drm/i915: Clean up multi-threaded forcewake patch drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/i915_debugfs.c| 86 - drivers/gpu/drm/i915/i915_dma.c|5 + drivers/gpu/drm/i915/i915_drv.c|7 - drivers/gpu/drm/i915/i915_drv.h|6 +- drivers/gpu/drm/i915/i915_gem.c| 10 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 63 +++- drivers/gpu/drm/i915/i915_irq.c|7 - drivers/gpu/drm/i915/i915_reg.h| 161 +++- drivers/gpu/drm/i915/intel_display.c | 206 - drivers/gpu/drm/i915/intel_drv.h | 40 ++ drivers/gpu/drm/i915/intel_fb.c|6 + drivers/gpu/drm/i915/intel_ringbuffer.c| 30 ++- drivers/gpu/drm/i915/intel_sprite.c| 668 include/drm/i915_drm.h | 40 ++ 15 files changed, 1290 insertions(+), 46 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_sprite.c -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/54c1f1e6/attachment.pgp>
Patch to add hp t5745 thin client to no-lvds list
Sorry for the mistake, i made a typo when correcting the indentation issue
i had.
here is the correct patch and also the dmidecode from the thin client.
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.0 -0500
+++ intel_lvds.c2012-01-04 14:03:49.134573275 -0500
@@ -723,6 +723,14 @@
DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Hewlett-Packard t5745",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_BOARD_NAME, "hp t5745"),
+ },
+ },
{ } /* terminating entry */
};
On Wed, Jan 4, 2012 at 2:58 PM, Adam Jackson wrote:
> On Wed, 2012-01-04 at 14:08 -0500, Marc Gari?py wrote:
> > Hello,
> >
> > I've been directed here by Stephane Graber. I need to blacklist the
> > LVDS port on some hp t5745 thin client.
> >
> > Here is the bug link:
> > https://bugs.launchpad.net/bugs/911916
>
> Does this actually work? The bug above doesn't include the dmidecode
> output, and...
>
> > + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_BOARD_NAME, "hp st5745"),
>
> I would normally expect HP to capitalize their own name correctly.
>
> - ajax
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/83427817/attachment.htm>
-- next part --
A non-text attachment was scrubbed...
Name: dmidecode-hp-t5745
Type: application/octet-stream
Size: 12514 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/83427817/attachment.obj>
[PATCH 3/3] Revert "drm/ttm: callback move_notify any time bo placement change v4"
This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
when we unbind the device we get this:
sh-4.1# echo ":00:0d.0" > unbind
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] []
nouveau_bo_move_ntfy+0x1d/0xc0 [nouveau]
RSP: 0018:88012deb7be8 EFLAGS: 00010296
RAX: a011ab00 RBX: 8801292ec210 RCX: 880132480498
RDX: 880132480498 RSI: RDI: 8801292ec000
RBP: 88012deb7c18 R08: R09: 88012e654df8
R10: 0001 R11: R12: 0001
R13: 880132480728 R14: 880132480320 R15: 88012e654df8
FS: 7f191ca6a700() GS:88013fc8() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 00012de89000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process sh (pid: 3070, threadinfo 88012deb6000, task 8801295f9e30)
Stack:
88012deb7c08 8801292ec000 0001 880132480728
880132480320 88012e654df8 88012deb7c38 a00eabe6
88012deb7c38 8801292ec000 88012deb7ca8 a00edcd1
Call Trace:
[] ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm]
[] ttm_bo_release+0x251/0x270 [ttm]
[] ? get_parent_ip+0x11/0x50
[] ? ttm_bo_create+0x110/0x110 [ttm]
[] kref_put+0x37/0x70
[] ttm_bo_unref+0x42/0x60 [ttm]
[] ? drm_gem_object_handle_free+0x90/0x90
[] nouveau_gem_object_del+0x3f/0x70 [nouveau]
[] drm_gem_object_free+0x2a/0x40
[] kref_put+0x37/0x70
[] nouveau_fbcon_fini+0xb6/0x130 [nouveau]
[] nouveau_unload+0x1bd/0x230 [nouveau]
[] ? drm_lastclose+0x2c2/0x310
[] drm_put_dev+0x73/0x240
[] nouveau_pci_remove+0x1d/0x20 [nouveau]
[] pci_device_remove+0x37/0x70
[] __device_release_driver+0x66/0xc0
[] device_release_driver+0x2d/0x40
[] driver_unbind+0xa1/0xc0
[] drv_attr_store+0x2c/0x30
[] sysfs_write_file+0xf9/0x180
[] vfs_write+0xc8/0x190
[] sys_write+0x51/0x90
[] system_call_fastpath+0x16/0x1b
Code: 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 41 55
41 54 53 48 83 ec 08 66 66 66 66 90 48 8b 9f 10 02 00 00 <4c> 8b 3e 4c 8d af 10
02 00 00 49 89 fe 49 89 f4 4c 39 eb 75 16
RIP [] nouveau_bo_move_ntfy+0x1d/0xc0 [nouveau]
RSP
CR2:
---[ end trace b57ad98adec9841d ]---
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
drivers/gpu/drm/ttm/ttm_bo.c |9 +++--
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index aa91f7b..47d0b05 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -815,10 +815,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct
ttm_mem_reg *new_mem)
struct nouveau_vma *vma;
list_for_each_entry(vma, &nvbo->vma_list, head) {
- if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
+ if (new_mem->mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem->mm_node);
} else
- if (new_mem && new_mem->mem_type == TTM_PL_TT &&
+ if (new_mem->mem_type == TTM_PL_TT &&
nvbo->page_shift == vma->vm->spg_shift) {
nouveau_vm_map_sg(vma, 0, new_mem->
num_pages << PAGE_SHIFT,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2f0eab6..483cded 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -404,6 +404,9 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
}
+ if (bdev->driver->move_notify)
+ bdev->driver->move_notify(bo, mem);
+
if (!(old_man->flags & TTM_MEMTYPE_FLAG_FIXED) &&
!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED))
ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu,
mem);
@@ -416,9 +419,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
if (ret)
goto out_err;
- if (bdev->driver->move_notify)
- bdev->driver->move_notify(bo, mem);
-
moved:
if (bo->evicted) {
ret = bdev->driver->invalidate_caches(bdev, bo->mem.placement);
@@ -457,9 +457,6 @@ out_err:
static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
{
- if (bo->bdev->driver->move_notify)
- bo->bdev->driver->move_notify(bo, NULL);
-
if (bo->ttm) {
ttm_tt_unbind(bo->ttm);
ttm_tt_destroy(bo->ttm);
--
1.7.7.4
[PATCH 2/3] drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and don't try to free freed pages.
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value for the amount of pages to shrink.
On top of that we would free the cached page pool - which is nonsense
as they are deleted from the pool - so there are no free pages in that
pool..
Also we also missed the opportunity to batch the amount of pages
to free (similar to how ttm_page_alloc.c does it). This reintroduces
the code that was lost during rebasing.
Reviewed-by: Jerome Glisse
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6c06d0b..156ddcd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
struct dma_page *d_page, *next;
enum pool_type type;
bool is_cached = false;
- unsigned count = 0, i;
+ unsigned count = 0, i, npages = 0;
unsigned long irq_flags;
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
@@ -974,8 +974,13 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
} else {
pool->npages_free += count;
list_splice(&ttm_dma->pages_list, &pool->free_list);
+ npages = count;
if (pool->npages_free > _manager->options.max_size) {
- count = pool->npages_free - _manager->options.max_size;
+ npages = pool->npages_free - _manager->options.max_size;
+ /* free at least NUM_PAGES_TO_ALLOC number of pages
+* to reduce calls to set_memory_wb */
+ if (npages < NUM_PAGES_TO_ALLOC)
+ npages = NUM_PAGES_TO_ALLOC;
}
}
spin_unlock_irqrestore(&pool->lock, irq_flags);
@@ -999,9 +1004,9 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
ttm_dma->dma_address[i] = 0;
}
- /* shrink pool if necessary */
- if (count)
- ttm_dma_page_pool_free(pool, count);
+ /* shrink pool if necessary (only on !is_cached pools)*/
+ if (npages)
+ ttm_dma_page_pool_free(pool, npages);
ttm->state = tt_unpopulated;
}
EXPORT_SYMBOL_GPL(ttm_dma_unpopulate);
--
1.7.7.4
[PATCH 1/3] drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool.
Otherwise we are doing redundant work. Especially since the 'unbind' and 'unpopulate' have been merged and nouveau driver ends up calling it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3) we end up spending about 54% CPU time in __change_page_attr_set_clr checking the page flags. The callgraph (annotated) looks as so before this patch: 53.29% gnome-shell [kernel.kallsyms] [k] static_protections | --- static_protections | |--91.80%-- __change_page_attr_set_clr | change_page_attr_set_clr | set_pages_array_wb | | | |--96.55%-- ttm_dma_unpopulate | | nouveau_ttm_tt_unpopulate | | ttm_tt_destroy | | ttm_bo_cleanup_memtype_use | | ttm_bo_release | | kref_put | | ttm_bo_unref | | nouveau_gem_object_del | | drm_gem_object_free | | kref_put | | drm_gem_object_unreference_unlocked | | drm_gem_object_handle_unreference_unlocked.part.1 | | drm_gem_handle_delete | | drm_gem_close_ioctl | | drm_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call_fastpath | | __GI___ioctl | | | --3.45%-- ttm_dma_pages_put | ttm_dma_page_pool_free | ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --8.20%-- change_page_attr_set_clr set_pages_array_wb | |--93.76%-- ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --6.24%-- ttm_dma_pages_put ttm_dma_page_pool_free ttm_dma_unpopulate nouveau_ttm_tt_unpopulate ttm_tt_destroy ttm_bo_cleanup_memtype_use ttm_bo_release kref_put ttm_bo_unref nouveau_gem_object_del drm_gem_object_free kref_put drm_gem_object_unreference_unlocked
[PATCH] fixes to drm-next - ttm code (v2) found when using nouveau.
When I was debugging some DMA API accounting error (which were found to be with the DMA API debug code), I encountered a couple of issues: 1). Doing "unbind" on the PCI device would crash the kernel _only_ with the nouveau driver. The readon worked fine. This was due to: "drm/ttm: callback move_notify any time bo.." and reverting that fixed it. 2). Extreme slowness when moving the cursor madly around. This was due to the nouveau driver calling the unpopulate (now that unbind + unpopulate are squashed) quite a lot (this is using Gnome Shell - I think GNOME2 did not have those issues but I can't recall). Radeon did not have these issues. Anyhow these patches fix the 50% perf regression I saw on nouveau and also some minor bugs that I noticed. Please apply. Thomas asked me to also do some perf results on AGP hardware (both nouveau and radeon) and I am going to do that this week - any pointers of what is a good game/OpenGL application to run a time-based benchmark?
linux-next: Tree for Jan 4 (gpu/drm/nouveau)
On 01/04/2012 12:16 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20120103: drivers/gpu/drm/nouveau/nouveau_pm.c:720:2: error: 'pm' undeclared (first use in this function) Full randconfig file is attached. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- next part -- An embedded and charset-unspecified text was scrubbed... Name: config-r3641 URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/699344fa/attachment.asc>
TTM and AGP conflicts
> >> Attached is patch to fix this, so sorry about that, i must have lost my > >> agp change along the way when working on the patchset. This patch is not > >> extensively tested, i will do more testing tomorrow on more gpu, might > >> even found an nvidia agp i can try. Again sorry for breaking this. > > > > Thanks for the fix up. I was wondering if this purposed change could be > > done instead. Its the same as your fix up except that you pass in the > > ttm_buffer_object for tt_create. The reason is I really like to have the > > ability to have more than one back end to grab a bunch pf pages from. > > Currently its AGP or something else. On some of my embedded devices the > > AGP space is not very large and can be exhausted very quickly. Those > > embedded devices have DMA engines I could use instead. > > This change violate the layer separation ttm wish to preserve see : > http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg16443.html > > You can achieve what you want by either adding a new domain so you would have > system, vram, agp, pcidma and object can be bound to one and only one. Or you > can hack your own agp ttm backend that could bind bo to agp or pci or > both at the same time depending on what you want to achieve. The question is how does one know which domain you want in tt_create. Currenty drivers are using there dev_priv but if you have have more than one option available how does one choose? Would you be okay with passing in a domain flag?
TTM and AGP conflicts
> Attached is patch to fix this, so sorry about that, i must have lost my
> agp change along the way when working on the patchset. This patch is not
> extensively tested, i will do more testing tomorrow on more gpu, might
> even found an nvidia agp i can try. Again sorry for breaking this.
Thanks for the fix up. I was wondering if this purposed change could be
done instead. Its the same as your fix up except that you pass in the
ttm_buffer_object for tt_create. The reason is I really like to have the
ability to have more than one back end to grab a bunch pf pages from.
Currently its AGP or something else. On some of my embedded devices the
AGP space is not very large and can be exhausted very quickly. Those
embedded devices have DMA engines I could use instead.
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8cf4a48..58ad508 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -349,10 +349,11 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned index,
u32 val)
}
static struct ttm_tt *
-nouveau_ttm_tt_create(struct ttm_bo_device *bdev,
+nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
unsigned long size, uint32_t page_flags,
struct page *dummy_read_page)
{
+ struct ttm_bo_device *bdev = bo->bdev;
struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev);
struct drm_device *dev = dev_priv->dev;
@@ -1066,6 +1067,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
return ttm_dma_populate((void *)ttm, dev->dev);
@@ -1105,6 +1112,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate((void *)ttm, dev->dev);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b0ebaf8..655f8e9 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -549,10 +549,12 @@ static struct ttm_backend_func radeon_backend_func = {
.destroy = &radeon_ttm_backend_destroy,
};
-struct ttm_tt *radeon_ttm_tt_create(struct ttm_bo_device *bdev,
- unsigned long size, uint32_t page_flags,
+struct ttm_tt *radeon_ttm_tt_create(struct ttm_buffer_object *bo,
+ unsigned long size,
+ uint32_t page_flags,
struct page *dummy_read_page)
{
+ struct ttm_bo_device *bdev = bo->bdev;
struct radeon_device *rdev;
struct radeon_ttm_tt *gtt;
@@ -588,6 +590,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
return 0;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
@@ -624,6 +631,12 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
unsigned i;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 14ebd36..747c141 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -31,6 +31,7 @@
#include "ttm/ttm_module.h"
#include "ttm/ttm_bo_driver.h"
+#include "ttm/ttm_page_alloc.h"
#ifdef TTM_HAS_AGP
#include "ttm/ttm_placement.h"
#include
@@ -97,6 +98,7 @@ static void ttm_agp_destroy(struct ttm_tt *ttm)
if (agp_be->mem)
ttm_agp_unbind(ttm);
+ ttm_tt_fini(ttm);
kfree(agp_be);
}
@@ -129,4 +131,19 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device
*bdev,
}
EXPORT_SYMBOL(ttm_agp_tt_create);
+int ttm_agp_tt_populate(struct ttm_tt *ttm)
+{
+ if (ttm->state != tt_unpopulated)
+ return 0;
+
+ return ttm_pool_populate(ttm);
+}
+EXPORT_SYMBOL(ttm_agp_tt_populate);
+
+void ttm_agp_tt_unpopulate(struct ttm_tt *ttm)
+{
+ ttm_pool_unpopulate(ttm);
+}
+EXPORT_SYMBOL(ttm_agp_tt_unpopulate);
+
#endif
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2f0eab6..1adc149 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
[Bug 39782] [r300g] XvMC playback fails with MPEG2 video and RV350
https://bugs.freedesktop.org/show_bug.cgi?id=39782 --- Comment #9 from Chris Rankin 2012-01-04 15:35:06 PST --- The following commit does not resolve this bug: commit 7b181d16c3b954bf567563e90e5e94bda833fab8 Author: Christian König Date: Wed Jan 4 15:59:29 2012 +0100 vl/mpeg2: simple fix to get xine running again Otherwise xines xxmc plugin will just display green blocks. Signed-off-by: Christian König xine is still showing a green video window with my RV350. $ mplayer -vo xvmc -vc ffmpeg12mc isn't working here either. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44466] Assertion 'LLVMOffsetOfElement' when running Furmark with wine
https://bugs.freedesktop.org/show_bug.cgi?id=44466 --- Comment #2 from Laurent carlier 2012-01-04 15:07:14 UTC --- ...mesa-7.11.2 seem also to be affected by this bug -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44466] Assertion 'LLVMOffsetOfElement' when running Furmark with wine
https://bugs.freedesktop.org/show_bug.cgi?id=44466 --- Comment #1 from Laurent carlier 2012-01-04 15:03:09 PST --- It doesn't assert with DRAW_USE_LLVM=0 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44466] Assertion 'LLVMOffsetOfElement' when running Furmark with wine
https://bugs.freedesktop.org/show_bug.cgi?id=44466 --- Comment #2 from Laurent carlier 2012-01-04 15:07:14 UTC --- ...mesa-7.11.2 seem also to be affected by this bug -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 44130] Radeon pm segfault
https://bugs.freedesktop.org/show_bug.cgi?id=44130 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Alex Deucher 2012-01-04 07:02:49 PST --- Pushed: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4376eee92e5a8332b470040e672ea99cd44c826a -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Patch to add hp t5745 thin client to no-lvds list
On Wed, 2012-01-04 at 14:08 -0500, Marc Gari?py wrote: > Hello, > > I've been directed here by Stephane Graber. I need to blacklist the > LVDS port on some hp t5745 thin client. > > Here is the bug link: > https://bugs.launchpad.net/bugs/911916 Does this actually work? The bug above doesn't include the dmidecode output, and... > + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), > + DMI_MATCH(DMI_BOARD_NAME, "hp st5745"), I would normally expect HP to capitalize their own name correctly. - ajax -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/473e28c1/attachment.pgp>
Re: Patch to add hp t5745 thin client to no-lvds list
Sorry for the mistake, i made a typo when correcting the indentation issue
i had.
here is the correct patch and also the dmidecode from the thin client.
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.0 -0500
+++ intel_lvds.c2012-01-04 14:03:49.134573275 -0500
@@ -723,6 +723,14 @@
DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Hewlett-Packard t5745",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_BOARD_NAME, "hp t5745"),
+ },
+ },
{ } /* terminating entry */
};
On Wed, Jan 4, 2012 at 2:58 PM, Adam Jackson wrote:
> On Wed, 2012-01-04 at 14:08 -0500, Marc Gariépy wrote:
> > Hello,
> >
> > I've been directed here by Stephane Graber. I need to blacklist the
> > LVDS port on some hp t5745 thin client.
> >
> > Here is the bug link:
> > https://bugs.launchpad.net/bugs/911916
>
> Does this actually work? The bug above doesn't include the dmidecode
> output, and...
>
> > + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
> > + DMI_MATCH(DMI_BOARD_NAME, "hp st5745"),
>
> I would normally expect HP to capitalize their own name correctly.
>
> - ajax
>
dmidecode-hp-t5745
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44466] New: Assertion 'LLVMOffsetOfElement' when running Furmark with wine
https://bugs.freedesktop.org/show_bug.cgi?id=44466 Bug #: 44466 Summary: Assertion 'LLVMOffsetOfElement' when running Furmark with wine Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: lordhea...@gmail.com * Mesa (32 bit under 64 os) from git built with llvm 3.0 * Radeon HD 4850 * Last wine version Mesa is built with llvm 3.0, the bug doesn't seem to occur with llvm 2.9 Here is the output: [lordh@archMain FurMark_1.9.2]$ wine FurMark.exe err:module:load_builtin_dll failed to load .so lib for builtin L"winemp3.acm": libmpg123.so.0: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type fixme:heap:HeapSetInformation (nil) 1 (nil) 0 fixme:win:EnumDisplayDevicesW ((null),0,0x33eaf0,0x), stub! err:wgl:X11DRV_wglGetPixelFormatAttribivARB (0x3b0): unexpected iPixelFormat(0) vs nFormats(175), returns FALSE Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS) fixme:win:EnumDisplayDevicesW ((null),0,0x33e4c4,0x), stub! fixme:win:EnumDisplayDevicesW ((null),1,0x33e4c4,0x), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33ec98,0x), stub! err:wgl:X11DRV_wglGetPixelFormatAttribivARB (0x3cc): unexpected iPixelFormat(0) vs nFormats(175), returns FALSE Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_GEOMETRY_UNIFORM_COMPONENTS) fixme:win:EnumDisplayDevicesW ((null),0,0xf0e28c,0x), stub! err:wgl:X11DRV_wglGetPixelFormatAttribivARB (0x710): unexpected iPixelFormat(0) vs nFormats(175), returns FALSE Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_GEOMETRY_UNIFORM_COMPONENTS) draw/draw_llvm.c:160:create_jit_texture_type: Assertion `LLVMOffsetOfElement(target, texture_type, DRAW_JIT_TEXTURE_DATA) == __builtin_offsetof (struct draw_jit_texture, data)' failed. wine: Unhandled exception 0x8003 at address 0x7cb9cfea (thread 0025), starting debugger... fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag 1f fixme:dbghelp_dwarf:compute_location Only supporting one breg (ecx/18 -> eax/17) fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9e fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9d _debug_assert_fail () at /build/src/build/src/gallium/auxiliary/util/u_debug.c:278 0x7cb9cfea _debug_assert_fail+0x57 [/build/src/build/src/gallium/auxiliary/util/u_debug.c:278] in r600_dri.so: int $3 Unable to access file '/build/src/build/src/gallium/auxiliary/util/u_debug.c' Modules: Module Address Debug info Name (91 modules) PE40- 7db000 Deferredfurmark PE7e- 9c5000 Deferredfreeimage PE 1000-1022e000 Deferredcore3d ELF 7b80-7b9c4000 Deferredkernel32 \-PE 7b81-7b9c4000 \ kernel32 ELF 7bc0-7bcd2000 Deferredntdll \-PE 7bc1-7bcd2000 \ ntdll ELF 7bdc5000-7be0 Deferredusp10 \-PE 7bdd-7be0 \ usp10 ELF 7bf0-7bf04000 Deferred ELF 7c2d9000-7c40 Deferredlibglsl.so ELF 7c4b7000-7c742000 Deferredlibdricore
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 01:28:28PM +, Alan Cox wrote: > > unnusual contexts). I'm not sure whether your proposed instrumentation is > > really worth it though - in i915-land we don't bother with this. But maybe > > In i915 land it's specific code paths so effectively it is marked up. We > don't do it for every random delay in all the connectors and other bits. > The bits of code believing they are safe use sleeping locks and we'll get > spewage if that breaks. Ditto at this point I hope gma500 although I > would not be surpised to find ones I still need to fix from being mdelay. The atomic context check is in the _wait_for macro in intel_drv.h which is used all over the place. Like in the wait_for_vblank function. So I don't think you can use i915.ko as a shiny beacon of how to do it ;-) > > with the firmware provided and randomly b0rked atombios tables it might > > make sense to add the WARN_ON_ONCE you've proposed in the other mail > > I think we need it because it can be added by firmware, it could be > silently done and the atombios paths cover so many different things > beyond modesetting using that exact same function we need the mark up. > > If some vendor puts a 100ms delay in a connector related hotplug check we > are going to have a horrible time debugging 'bugzilla #zillion, 'poor > performance in OpenGL game with Radeon foozillion' Well, hotplug is alreay a giant pain because of the single lock to rule them all design of the current kms code: Long delays already stall everything else (well, cursor updates and pageflips) and we have tons of bugreports that complain about it. In a sense your example undermines my point that we have lower hanger fruit to fix all over the place already ... But as I've said I like the WARN_ON you want to add, but otoh hand think it shouldn't be used to stall the small&hackish fix of adding the relevant in_atomic checks. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Patch to add hp st5747 thin client to no-lvds list
Hello,
I've been directed here by Stephane Graber. I need to blacklist the LVDS
port on hp st5747 thin client.
Here is the bug link:
https://bugs.launchpad.net/bugs/911920
And i attached the following patch to this bug:
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.0 -0500
+++ intel_lvds.c2012-01-04 14:00:13.017501619 -0500
@@ -723,6 +723,14 @@
DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Hewlett-Packard st5747",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_BOARD_NAME, "hp st5747"),
+ },
+ },
{ } /* terminating entry */
};
Thanks
Marc Gariepy
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/e1af1645/attachment.html>
Patch to add hp t5745 thin client to no-lvds list
Hello,
I've been directed here by Stephane Graber. I need to blacklist the LVDS
port on some hp t5745 thin client.
Here is the bug link:
https://bugs.launchpad.net/bugs/911916
And i attached the following patch to this bug:
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.0 -0500
+++ intel_lvds.c2012-01-04 14:03:49.134573275 -0500
@@ -723,6 +723,14 @@
DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Hewlett-Packard t5745",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_BOARD_NAME, "hp st5745"),
+ },
+ },
{ } /* terminating entry */
};
Thanks
Marc Gariepy
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/e1ebb422/attachment.htm>
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote: > > I think Alan's simply wrong. > > In what way ? You stated this, then go on below to say what I did ? > > > Splattering the entire driver for > > these two corner cases which don't happen at all under normal > > circumstances is imho utter nonsense. > > Which is what I said > > | > > Is this only special cases like a panic - if so can it not be called > in a > | > > way that distinguishes between normality and nasty cases. > | > > | > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > | > theory it could be indirectly called from anywhere that uses ATOM > BIOS. > > | So lets stick to practice, and the real world. Screwing up everything > | else because of a crappy problem in your Atom BIOS code sucks but hey it > | happens. screwing up everything because of a theoretical concern is just > | dumb. Meh, missed the first part of your mail here. Looks like a misunderstanding on my side, I was assuming you're proposing to add an atom_exec_atomic thing which - would unconditionally do the spinning delay (by completely abolishing the in_atomic checks) and - which would require to pass around a flag from at least the panic handler throught the entire modeset code. Your actual proposal makes much more sense, and as I've said I kinda like the warning, altough I'm not really sold on the usefulness of it all. After all we already have all the nice ftrace instrumentation to put blame for hoggin the cpu in atomic contexts where it needs to be put. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote: > > I think Alan's simply wrong. > > In what way ? You stated this, then go on below to say what I did ? > > > Splattering the entire driver for > > these two corner cases which don't happen at all under normal > > circumstances is imho utter nonsense. > > Which is what I said > > | > > Is this only special cases like a panic - if so can it not be called > in a > | > > way that distinguishes between normality and nasty cases. > | > > | > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > | > theory it could be indirectly called from anywhere that uses ATOM > BIOS. > > | So lets stick to practice, and the real world. Screwing up everything > | else because of a crappy problem in your Atom BIOS code sucks but hey it > | happens. screwing up everything because of a theoretical concern is just > | dumb. > > > We don't want to do mdelays when they are not needed just because it is > theoretically possible they are not needed. There are several ways to fix > it, one is to stuff in_atomic() etc in the awkward spots. However if > you've got something where you have lots of call points to an interface > this is actually a bad idea, because you grow more insidiously, or a > change elsewhere in the kernel silently turns all your sleeps into delays > and things like live music work stop being doable with radeon graphics. > > So the better way to fix it is to actually have an interface > > atom_execute_table_atomic() > > so that such situations are called out clearly, and any change elsewhere > that messes it all up causes kernel spewage that can be dealt with > properly - either by using _atomic if its something obscure like a panic, > fixing the issue or reverting the problematic change further up the tree. > > Another way to approach it would be to have > > radeon_atom_atomic(rdev); > radeon_atom_whateverfoo(rdev, ...) > radeon_atom_atomic_end(rdev); > > which set and cleared a bitflag that the mdelay/msleep opcode tested. > > That's quicker to implement but a spot less clean. Again it calls out any > such cases and makes them explicit. It also means any accidental changes > that affect this will result in spewage and debugging not silent trashing > of performance for stuff like machine control, music and some gaming. > > It should only be for panic, although accel calls for printk spewage can > hit in atomic context in some situations but I don't think that becomes > an atombios path ? Well, if your dear X server changed the modesetting layout we need to change it back to the kms fb layout so that we can properly display the panic. Which is done by atombios calls afaik (and in i915 has tons of rather long delays, too). I agree with you that we should have a decent grip on where we can actually end up in atomic modeset calls (or for radeon, atombios in general), which imo should only be the panic handler and kdbg (and similar unnusual contexts). I'm not sure whether your proposed instrumentation is really worth it though - in i915-land we don't bother with this. But maybe with the firmware provided and randomly b0rked atombios tables it might make sense to add the WARN_ON_ONCE you've proposed in the other mail -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
> Well, hotplug is alreay a giant pain because of the single lock to rule > them all design of the current kms code: Long delays already stall > everything else (well, cursor updates and pageflips) and we have tons of Yes I hit this with the gma500, it's one reason I did the GTT based scrolling. > bugreports that complain about it. In a sense your example undermines my > point that we have lower hanger fruit to fix all over the place already ... Yes.. I'm trying to stop the rotting fruit getting any further down the tree! The KMS locking isn't just a KMS problem, KMS inherits some of it from the framebuffer which inherits some of it from printk which gets some of it from panic an in IRQ error handling. It's all very messy as a result. I keep poking at the vt and tty layer end of this to try and sort it out from the bottom but it's like a bad cess pit, every time you poke it the smell drives you back to other things. > But as I've said I like the WARN_ON you want to add, but otoh hand think > it shouldn't be used to stall the small&hackish fix of adding the relevant > in_atomic checks. Then I think we basically agree. Alan
[PATCH] fixes to drm-next - ttm code (v2) found when using nouveau.
When I was debugging some DMA API accounting error (which were found to be with the DMA API debug code), I encountered a couple of issues: 1). Doing "unbind" on the PCI device would crash the kernel _only_ with the nouveau driver. The readon worked fine. This was due to: "drm/ttm: callback move_notify any time bo.." and reverting that fixed it. 2). Extreme slowness when moving the cursor madly around. This was due to the nouveau driver calling the unpopulate (now that unbind + unpopulate are squashed) quite a lot (this is using Gnome Shell - I think GNOME2 did not have those issues but I can't recall). Radeon did not have these issues. Anyhow these patches fix the 50% perf regression I saw on nouveau and also some minor bugs that I noticed. Please apply. Thomas asked me to also do some perf results on AGP hardware (both nouveau and radeon) and I am going to do that this week - any pointers of what is a good game/OpenGL application to run a time-based benchmark? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool.
Otherwise we are doing redundant work. Especially since the 'unbind' and 'unpopulate' have been merged and nouveau driver ends up calling it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3) we end up spending about 54% CPU time in __change_page_attr_set_clr checking the page flags. The callgraph (annotated) looks as so before this patch: 53.29% gnome-shell [kernel.kallsyms] [k] static_protections | --- static_protections | |--91.80%-- __change_page_attr_set_clr | change_page_attr_set_clr | set_pages_array_wb | | | |--96.55%-- ttm_dma_unpopulate | | nouveau_ttm_tt_unpopulate | | ttm_tt_destroy | | ttm_bo_cleanup_memtype_use | | ttm_bo_release | | kref_put | | ttm_bo_unref | | nouveau_gem_object_del | | drm_gem_object_free | | kref_put | | drm_gem_object_unreference_unlocked | | drm_gem_object_handle_unreference_unlocked.part.1 | | drm_gem_handle_delete | | drm_gem_close_ioctl | | drm_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call_fastpath | | __GI___ioctl | | | --3.45%-- ttm_dma_pages_put | ttm_dma_page_pool_free | ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --8.20%-- change_page_attr_set_clr set_pages_array_wb | |--93.76%-- ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --6.24%-- ttm_dma_pages_put ttm_dma_page_pool_free ttm_dma_unpopulate nouveau_ttm_tt_unpopulate ttm_tt_destroy ttm_bo_cleanup_memtype_use ttm_bo_release kref_put ttm_bo_unref nouveau_gem_object_del drm_gem_object_free kref_put drm_gem_object_unreference_unlocked
[PATCH 2/3] drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page and don't try to free freed pages.
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value for the amount of pages to shrink.
On top of that we would free the cached page pool - which is nonsense
as they are deleted from the pool - so there are no free pages in that
pool..
Also we also missed the opportunity to batch the amount of pages
to free (similar to how ttm_page_alloc.c does it). This reintroduces
the code that was lost during rebasing.
Reviewed-by: Jerome Glisse
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6c06d0b..156ddcd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
struct dma_page *d_page, *next;
enum pool_type type;
bool is_cached = false;
- unsigned count = 0, i;
+ unsigned count = 0, i, npages = 0;
unsigned long irq_flags;
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
@@ -974,8 +974,13 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
} else {
pool->npages_free += count;
list_splice(&ttm_dma->pages_list, &pool->free_list);
+ npages = count;
if (pool->npages_free > _manager->options.max_size) {
- count = pool->npages_free - _manager->options.max_size;
+ npages = pool->npages_free - _manager->options.max_size;
+ /* free at least NUM_PAGES_TO_ALLOC number of pages
+* to reduce calls to set_memory_wb */
+ if (npages < NUM_PAGES_TO_ALLOC)
+ npages = NUM_PAGES_TO_ALLOC;
}
}
spin_unlock_irqrestore(&pool->lock, irq_flags);
@@ -999,9 +1004,9 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
ttm_dma->dma_address[i] = 0;
}
- /* shrink pool if necessary */
- if (count)
- ttm_dma_page_pool_free(pool, count);
+ /* shrink pool if necessary (only on !is_cached pools)*/
+ if (npages)
+ ttm_dma_page_pool_free(pool, npages);
ttm->state = tt_unpopulated;
}
EXPORT_SYMBOL_GPL(ttm_dma_unpopulate);
--
1.7.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] Revert "drm/ttm: callback move_notify any time bo placement change v4"
This reverts commit 5c2680ddbe14b24771d24841dd66881f90d3d740 otherwise
when we unbind the device we get this:
sh-4.1# echo ":00:0d.0" > unbind
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] []
nouveau_bo_move_ntfy+0x1d/0xc0 [nouveau]
RSP: 0018:88012deb7be8 EFLAGS: 00010296
RAX: a011ab00 RBX: 8801292ec210 RCX: 880132480498
RDX: 880132480498 RSI: RDI: 8801292ec000
RBP: 88012deb7c18 R08: R09: 88012e654df8
R10: 0001 R11: R12: 0001
R13: 880132480728 R14: 880132480320 R15: 88012e654df8
FS: 7f191ca6a700() GS:88013fc8() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 00012de89000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process sh (pid: 3070, threadinfo 88012deb6000, task 8801295f9e30)
Stack:
88012deb7c08 8801292ec000 0001 880132480728
880132480320 88012e654df8 88012deb7c38 a00eabe6
88012deb7c38 8801292ec000 88012deb7ca8 a00edcd1
Call Trace:
[] ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm]
[] ttm_bo_release+0x251/0x270 [ttm]
[] ? get_parent_ip+0x11/0x50
[] ? ttm_bo_create+0x110/0x110 [ttm]
[] kref_put+0x37/0x70
[] ttm_bo_unref+0x42/0x60 [ttm]
[] ? drm_gem_object_handle_free+0x90/0x90
[] nouveau_gem_object_del+0x3f/0x70 [nouveau]
[] drm_gem_object_free+0x2a/0x40
[] kref_put+0x37/0x70
[] nouveau_fbcon_fini+0xb6/0x130 [nouveau]
[] nouveau_unload+0x1bd/0x230 [nouveau]
[] ? drm_lastclose+0x2c2/0x310
[] drm_put_dev+0x73/0x240
[] nouveau_pci_remove+0x1d/0x20 [nouveau]
[] pci_device_remove+0x37/0x70
[] __device_release_driver+0x66/0xc0
[] device_release_driver+0x2d/0x40
[] driver_unbind+0xa1/0xc0
[] drv_attr_store+0x2c/0x30
[] sysfs_write_file+0xf9/0x180
[] vfs_write+0xc8/0x190
[] sys_write+0x51/0x90
[] system_call_fastpath+0x16/0x1b
Code: 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 41 55
41 54 53 48 83 ec 08 66 66 66 66 90 48 8b 9f 10 02 00 00 <4c> 8b 3e 4c 8d af 10
02 00 00 49 89 fe 49 89 f4 4c 39 eb 75 16
RIP [] nouveau_bo_move_ntfy+0x1d/0xc0 [nouveau]
RSP
CR2:
---[ end trace b57ad98adec9841d ]---
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_bo.c |4 ++--
drivers/gpu/drm/ttm/ttm_bo.c |9 +++--
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index aa91f7b..47d0b05 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -815,10 +815,10 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct
ttm_mem_reg *new_mem)
struct nouveau_vma *vma;
list_for_each_entry(vma, &nvbo->vma_list, head) {
- if (new_mem && new_mem->mem_type == TTM_PL_VRAM) {
+ if (new_mem->mem_type == TTM_PL_VRAM) {
nouveau_vm_map(vma, new_mem->mm_node);
} else
- if (new_mem && new_mem->mem_type == TTM_PL_TT &&
+ if (new_mem->mem_type == TTM_PL_TT &&
nvbo->page_shift == vma->vm->spg_shift) {
nouveau_vm_map_sg(vma, 0, new_mem->
num_pages << PAGE_SHIFT,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2f0eab6..483cded 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -404,6 +404,9 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
}
+ if (bdev->driver->move_notify)
+ bdev->driver->move_notify(bo, mem);
+
if (!(old_man->flags & TTM_MEMTYPE_FLAG_FIXED) &&
!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED))
ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu,
mem);
@@ -416,9 +419,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
if (ret)
goto out_err;
- if (bdev->driver->move_notify)
- bdev->driver->move_notify(bo, mem);
-
moved:
if (bo->evicted) {
ret = bdev->driver->invalidate_caches(bdev, bo->mem.placement);
@@ -457,9 +457,6 @@ out_err:
static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
{
- if (bo->bdev->driver->move_notify)
- bo->bdev->driver->move_notify(bo, NULL);
-
if (bo->ttm) {
ttm_tt_unbind(bo->ttm);
ttm_tt_destroy(bo->ttm);
--
1.7.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
> unnusual contexts). I'm not sure whether your proposed instrumentation is > really worth it though - in i915-land we don't bother with this. But maybe In i915 land it's specific code paths so effectively it is marked up. We don't do it for every random delay in all the connectors and other bits. The bits of code believing they are safe use sleeping locks and we'll get spewage if that breaks. Ditto at this point I hope gma500 although I would not be surpised to find ones I still need to fix from being mdelay. > with the firmware provided and randomly b0rked atombios tables it might > make sense to add the WARN_ON_ONCE you've proposed in the other mail I think we need it because it can be added by firmware, it could be silently done and the atombios paths cover so many different things beyond modesetting using that exact same function we need the mark up. If some vendor puts a 100ms delay in a connector related hotplug check we are going to have a horrible time debugging 'bugzilla #zillion, 'poor performance in OpenGL game with Radeon foozillion' Alan
[Bug 24861] [RV250Lf] External monitor loses signal from loading drm modules/firmware until X starts
https://bugs.freedesktop.org/show_bug.cgi?id=24861 Johannes Obermayr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Johannes Obermayr 2012-01-04 05:12:29 PST --- Fixed a long time ago. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
https://bugs.freedesktop.org/show_bug.cgi?id=36037 Johannes Obermayr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Johannes Obermayr 2012-01-04 05:06:07 PST --- It does not crash when building against recent kernels. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 24215] [RV250Lf] radeonPolygonStipplePreKMS in radeon_common.c
https://bugs.freedesktop.org/show_bug.cgi?id=24215 Johannes Obermayr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Johannes Obermayr 2012-01-04 05:03:06 PST --- Obsolete because DRI1 code was removed from Mesa stack in Oct 2011. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Mit, 2012-01-04 at 12:44 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel D?nzer wrote:
> > On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> > > > From: Michel D?nzer
> > > >
> > > > It can be the case e.g. when switching to console for panic output.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> > > >
> > > > Signed-off-by: Michel D?nzer
> > > > ---
> > > >
> > > > v2: Still call msleep() in the normal case. Only compile tested.
> > > >
> > > > drivers/gpu/drm/radeon/atom.c |2 ++
> > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/radeon/atom.c
> > > > b/drivers/gpu/drm/radeon/atom.c
> > > > index 14cc88a..4092e59 100644
> > > > --- a/drivers/gpu/drm/radeon/atom.c
> > > > +++ b/drivers/gpu/drm/radeon/atom.c
> > > > @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx,
> > > > int *ptr, int arg)
> > > > SDEBUG(" count: %d\n", count);
> > > > if (arg == ATOM_UNIT_MICROSEC)
> > > > udelay(count);
> > > > + else if (in_interrupt() || irqs_disabled() || in_atomic())
> > > > + mdelay(count);
> > >
> > > Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
> > > addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
> > > checks for in_dbg_master() to take care of kdbg.
> > >
> > > Can I bother you to create a small helper like in_atomic_kms_context that
> > > checks these three things (and also use it in drm/i915)?
> >
> > Sorry, I've already spent way more time on this than I meant to, and
> > Alan just killed what little motivation I still had to spend more.
>
> I think Alan's simply wrong. The msleep checks in i915 are only used for
> two cases:
> - when using kdbg
> - when displaying a panic
> Afaics radeon has the exact same issue, at least I've seen my radeon
> machine here go down after an oops. Splattering the entire driver for
> these two corner cases which don't happen at all under normal
> circumstances is imho utter nonsense.
>
> I.e. I'd be very happy to smash a r-b onto your patch if you unifiy the
> magical checks with i915 in a common function and add a small comment.
> Does the prospect of an up-front r-b and me promising to harass Dave to
> merge it restore your motivation?
It's certainly helping. :) I'll see what I can do.
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel D?nzer wrote:
> On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> > > From: Michel D?nzer
> > >
> > > It can be the case e.g. when switching to console for panic output.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> > >
> > > Signed-off-by: Michel D?nzer
> > > ---
> > >
> > > v2: Still call msleep() in the normal case. Only compile tested.
> > >
> > > drivers/gpu/drm/radeon/atom.c |2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> > > index 14cc88a..4092e59 100644
> > > --- a/drivers/gpu/drm/radeon/atom.c
> > > +++ b/drivers/gpu/drm/radeon/atom.c
> > > @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int
> > > *ptr, int arg)
> > > SDEBUG(" count: %d\n", count);
> > > if (arg == ATOM_UNIT_MICROSEC)
> > > udelay(count);
> > > + else if (in_interrupt() || irqs_disabled() || in_atomic())
> > > + mdelay(count);
> >
> > Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
> > addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
> > checks for in_dbg_master() to take care of kdbg.
> >
> > Can I bother you to create a small helper like in_atomic_kms_context that
> > checks these three things (and also use it in drm/i915)?
>
> Sorry, I've already spent way more time on this than I meant to, and
> Alan just killed what little motivation I still had to spend more.
I think Alan's simply wrong. The msleep checks in i915 are only used for
two cases:
- when using kdbg
- when displaying a panic
Afaics radeon has the exact same issue, at least I've seen my radeon
machine here go down after an oops. Splattering the entire driver for
these two corner cases which don't happen at all under normal
circumstances is imho utter nonsense.
I.e. I'd be very happy to smash a r-b onto your patch if you unifiy the
magical checks with i915 in a common function and add a small comment.
Does the prospect of an up-front r-b and me promising to harass Dave to
merge it restore your motivation?
Cheers, Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> > From: Michel D?nzer
> >
> > It can be the case e.g. when switching to console for panic output.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> >
> > Signed-off-by: Michel D?nzer
> > ---
> >
> > v2: Still call msleep() in the normal case. Only compile tested.
> >
> > drivers/gpu/drm/radeon/atom.c |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> > index 14cc88a..4092e59 100644
> > --- a/drivers/gpu/drm/radeon/atom.c
> > +++ b/drivers/gpu/drm/radeon/atom.c
> > @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int
> > *ptr, int arg)
> > SDEBUG(" count: %d\n", count);
> > if (arg == ATOM_UNIT_MICROSEC)
> > udelay(count);
> > + else if (in_interrupt() || irqs_disabled() || in_atomic())
> > + mdelay(count);
>
> Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
> addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
> checks for in_dbg_master() to take care of kdbg.
>
> Can I bother you to create a small helper like in_atomic_kms_context that
> checks these three things (and also use it in drm/i915)?
Sorry, I've already spent way more time on this than I meant to, and
Alan just killed what little motivation I still had to spend more.
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
> Every modesetting operation can happen in atomic context or not in
> atomic context, thanks to the wonder of oops printing and also kgdb,
> trying to figure out which table in this one person's bios is the
> "root" cause and special casing for it is insane since tomorrow 20
> other BIOSes could contain that table or a new variant we haven't seen
> before.
>
> Unless one of us is totally misinterpreting what the other is saying
> or what the atombios interpreter is.
Its a sort of bytecode engine that allows the BIOS to describe to the
OS how the GPU should be handled. So what we want to avoid is
accidentally having some other path become spinlock based due to a
random unrelated change and ending up doing 20mS spinning delays without
us getting a warning.
Explicitly calling out that mode setting does this isn't a big deal - we
don't modeset often while doing stuff that is latency sensitive (gaming,
live music, telephony, etc) and if you have the in_atomic check as well
we'd probably only hit it on panic().
The problem is if we just band-aid it without doing this it will (and
always has) ended in tears later.
So as per the other mail all I'm really saying is we want something like
radeon_atom_mode_atomic_begin(rdev)
{
rdev->mode_info.atom_context->atomic = 1;
}
radeon_atom_mode_atomic_end(rdev)
{
rdev->mode_info.atom_context->atomic = 0;
}
/* above maybe with sanity checks to stop missed ones */
and to do
else {
if (!in_atomic())
msleep(count);
else {
WARN_ON(!ctx->atomic);
mdelay(count);
}
}
so that we know it isn't getting hit in places we've not carefully
considered the impact of a huge stall.
Alan
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
> I think Alan's simply wrong. In what way ? You stated this, then go on below to say what I did ? > Splattering the entire driver for > these two corner cases which don't happen at all under normal > circumstances is imho utter nonsense. Which is what I said | > > Is this only special cases like a panic - if so can it not be called in a | > > way that distinguishes between normality and nasty cases. | > | > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in | > theory it could be indirectly called from anywhere that uses ATOM BIOS. | So lets stick to practice, and the real world. Screwing up everything | else because of a crappy problem in your Atom BIOS code sucks but hey it | happens. screwing up everything because of a theoretical concern is just | dumb. We don't want to do mdelays when they are not needed just because it is theoretically possible they are not needed. There are several ways to fix it, one is to stuff in_atomic() etc in the awkward spots. However if you've got something where you have lots of call points to an interface this is actually a bad idea, because you grow more insidiously, or a change elsewhere in the kernel silently turns all your sleeps into delays and things like live music work stop being doable with radeon graphics. So the better way to fix it is to actually have an interface atom_execute_table_atomic() so that such situations are called out clearly, and any change elsewhere that messes it all up causes kernel spewage that can be dealt with properly - either by using _atomic if its something obscure like a panic, fixing the issue or reverting the problematic change further up the tree. Another way to approach it would be to have radeon_atom_atomic(rdev); radeon_atom_whateverfoo(rdev, ...) radeon_atom_atomic_end(rdev); which set and cleared a bitflag that the mdelay/msleep opcode tested. That's quicker to implement but a spot less clean. Again it calls out any such cases and makes them explicit. It also means any accidental changes that affect this will result in spewage and debugging not silent trashing of performance for stuff like machine control, music and some gaming. It should only be for panic, although accel calls for printk spewage can hit in atomic context in some situations but I don't think that becomes an atombios path ? Alan
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
2012/1/4 Alan Cox : >> > So lets stick to practice, and the real world. Screwing up everything >> > else because of a crappy problem in your Atom BIOS code sucks but hey it >> > happens. screwing up everything because of a theoretical concern is just >> > dumb. >> >> Thanks for the flowers, but it's not just a theoretical concern, see the >> bug report. > > The bug report is a single specific case. Figure out the calling > paths afflicted by it, don't be lazy and just dump on everyone on every > path because of a special case you apparently can't be bothered to root > cause. > I'm not sure what we'd gain by passing the atomic context information in from the top of the atom interpreter and using it in this one place vs getting the atomic info in this one place. Every modesetting operation can happen in atomic context or not in atomic context, thanks to the wonder of oops printing and also kgdb, trying to figure out which table in this one person's bios is the "root" cause and special casing for it is insane since tomorrow 20 other BIOSes could contain that table or a new variant we haven't seen before. Unless one of us is totally misinterpreting what the other is saying or what the atombios interpreter is. Dave.
Re: Patch to add hp t5745 thin client to no-lvds list
On Wed, 2012-01-04 at 14:08 -0500, Marc Gariépy wrote: > Hello, > > I've been directed here by Stephane Graber. I need to blacklist the > LVDS port on some hp t5745 thin client. > > Here is the bug link: > https://bugs.launchpad.net/bugs/911916 Does this actually work? The bug above doesn't include the dmidecode output, and... > + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), > + DMI_MATCH(DMI_BOARD_NAME, "hp st5745"), I would normally expect HP to capitalize their own name correctly. - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel D?nzer wrote:
> From: Michel D?nzer
>
> It can be the case e.g. when switching to console for panic output.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
>
> Signed-off-by: Michel D?nzer
> ---
>
> v2: Still call msleep() in the normal case. Only compile tested.
>
> drivers/gpu/drm/radeon/atom.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index 14cc88a..4092e59 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int
> *ptr, int arg)
> SDEBUG(" count: %d\n", count);
> if (arg == ATOM_UNIT_MICROSEC)
> udelay(count);
> + else if (in_interrupt() || irqs_disabled() || in_atomic())
> + mdelay(count);
Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
checks for in_dbg_master() to take care of kdbg.
Can I bother you to create a small helper like in_atomic_kms_context that
checks these three things (and also use it in drm/i915)?
Cheers, Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[Bug 43719] drm-core-next + AGP RV670 = Oops
https://bugs.freedesktop.org/show_bug.cgi?id=43719 --- Comment #3 from Andy Furniss 2012-01-04 03:53:20 PST --- (In reply to comment #2) > Created attachment 55095 [details] [review] > Fix agp on top of ttm tt rework > > Should fix the bug let me know Yes, this fixes it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[patch] gma500: silence gcc warnings in mid_get_vbt_data()
On Wed, 4 Jan 2012 10:26:10 +0300 Dan Carpenter wrote: > Add a cast here to silence a Gcc warning. > drivers/gpu/drm/gma500/mid_bios.c:214:28: warning: > cast from pointer to integer of different size > [-Wpointer-to-int-cast] > > Signed-off-by: Dan Carpenter > --- > Compile tested only. It's actually a non-bug (no 64bit boxes and we always take from within the low 32bits). I guess gcc would have to extremely smart to figure that out though. Acked-by: Alan Cox
[PATCH] Disable LVDS output on Clientron E830 Thin Client
On Tue, 2011-12-27 at 12:06 -0500, Joel Sass wrote:
> --- ./intel_lvds.old2011-12-20 13:25:49.368291249 -0500
> +++ ./intel_lvds.c2011-12-20 13:26:05.160291248 -0500
> @@ -709,6 +709,14 @@
> },
> {
> .callback = intel_no_lvds_dmi_callback,
> +.ident = "Clientron E830",
> +.matches = {
> +DMI_MATCH(DMI_SYS_VENDOR, "Clientron"),
> +DMI_MATCH(DMI_PRODUCT_NAME, "E830"),
> +},
> +},
> +{
> +.callback = intel_no_lvds_dmi_callback,
> .ident = "Asus EeeBox PC EB1007",
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
Reviewed-by: Adam Jackson
- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120104/21e8d9da/attachment.pgp>
TTM and AGP conflicts
On Wed, Jan 4, 2012 at 11:04 AM, James Simmons wrote: > >> >> Attached is patch to fix this, so sorry about that, i must have lost my >> >> agp change along the way when working on the patchset. This patch is not >> >> extensively tested, i will do more testing tomorrow on more gpu, might >> >> even found an nvidia agp i can try. Again sorry for breaking this. >> > >> > Thanks for the fix up. I was wondering if this purposed change could be >> > done instead. Its the same as your fix up except that you pass in the >> > ttm_buffer_object for tt_create. The reason is I really like to have the >> > ability to have more than one back end to grab a bunch pf pages from. >> > Currently its AGP or something else. On some of my embedded devices the >> > AGP space is not very large and can be exhausted very quickly. Those >> > embedded devices have DMA engines I could use instead. >> >> This change violate the layer separation ttm wish to preserve see : >> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg16443.html >> >> You can achieve what you want by either adding a new domain so you would have >> system, vram, agp, pcidma and object can be bound to one and only one. Or you >> can hack your own agp ttm backend that could bind bo to agp or pci or >> both at the same time depending on what you want to achieve. > > The question is how does one know which domain you want in tt_create. > Currenty drivers are using there dev_priv but if you have have more than > one option available how does one choose? Would you be okay with passing > in a domain flag? > Well i agree that something would be usefull there so the driver know which bind/unbind function it should use. Thomas i would prefer passing the bo to the tt_create callback but a flag is the minimum we need. Cheers, Jerome
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Mit, 2012-01-04 at 00:52 +, Alan Cox wrote: > On Tue, 03 Jan 2012 19:25:46 +0100 > Michel D?nzer wrote: > > On Die, 2012-01-03 at 18:09 +, Alan Cox wrote: > > > On Tue, 3 Jan 2012 19:04:00 +0100 > > > Michel D?nzer wrote: > > > > > > > From: Michel D?nzer > > > > > > > > It can be called from atomic context, e.g. when switching to console > > > > for panic > > > > output. > > > > > > Is this only special cases like a panic - if so can it not be called in a > > > way that distinguishes between normality and nasty cases. > > > > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > > theory it could be indirectly called from anywhere that uses ATOM BIOS. > > So lets stick to practice, and the real world. Screwing up everything > else because of a crappy problem in your Atom BIOS code sucks but hey it > happens. screwing up everything because of a theoretical concern is just > dumb. Thanks for the flowers, but it's not just a theoretical concern, see the bug report. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Die, 2012-01-03 at 21:04 +0100, Daniel Vetter wrote: > On Tue, Jan 03, 2012 at 07:16:25PM +0100, Michel D?nzer wrote: > > On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote: > > > 2012/1/3 Michel D?nzer : > > > > From: Michel D?nzer > > > > > > > > It can be called from atomic context, e.g. when switching to console > > > > for panic > > > > output. > > > > > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 > > > > > > I wonder how ugly it would be to check for atomic context or not, > > > > So do I. :) The comment in include/linux/hardirq.h that ends in 'Do not > > use in_atomic() in driver code.' sounds rathery scary... > > We already use in_atomic checks in similar delay code in drm/i915 for the > same reasons. I think the ugly mess that results from the panic notifier > calling into kms code is justification enough to neglect the the comment > about not using in_atomic in drivers. Okay, v2 sent. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
From: Michel D?nzer
It can be the case e.g. when switching to console for panic output.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
Signed-off-by: Michel D?nzer
---
v2: Still call msleep() in the normal case. Only compile tested.
drivers/gpu/drm/radeon/atom.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 14cc88a..4092e59 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int *ptr,
int arg)
SDEBUG(" count: %d\n", count);
if (arg == ATOM_UNIT_MICROSEC)
udelay(count);
+ else if (in_interrupt() || irqs_disabled() || in_atomic())
+ mdelay(count);
else
msleep(count);
}
--
1.7.7.3
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
> > So lets stick to practice, and the real world. Screwing up everything > > else because of a crappy problem in your Atom BIOS code sucks but hey it > > happens. screwing up everything because of a theoretical concern is just > > dumb. > > Thanks for the flowers, but it's not just a theoretical concern, see the > bug report. The bug report is a single specific case. Figure out the calling paths afflicted by it, don't be lazy and just dump on everyone on every path because of a special case you apparently can't be bothered to root cause. Alan
Patch to add hp st5747 thin client to no-lvds list
Hello,
I've been directed here by Stephane Graber. I need to blacklist the LVDS
port on hp st5747 thin client.
Here is the bug link:
https://bugs.launchpad.net/bugs/911920
And i attached the following patch to this bug:
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.0 -0500
+++ intel_lvds.c2012-01-04 14:00:13.017501619 -0500
@@ -723,6 +723,14 @@
DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Hewlett-Packard st5747",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_BOARD_NAME, "hp st5747"),
+ },
+ },
{ } /* terminating entry */
};
Thanks
Marc Gariepy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch to add hp t5745 thin client to no-lvds list
Hello,
I've been directed here by Stephane Graber. I need to blacklist the LVDS
port on some hp t5745 thin client.
Here is the bug link:
https://bugs.launchpad.net/bugs/911916
And i attached the following patch to this bug:
--- linux-3.2.0/drivers/gpu/drm/i915/intel_lvds.c 2011-12-24
10:23:08.0 -0500
+++ intel_lvds.c2012-01-04 14:03:49.134573275 -0500
@@ -723,6 +723,14 @@
DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
},
},
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = "Hewlett-Packard t5745",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_BOARD_NAME, "hp st5745"),
+ },
+ },
{ } /* terminating entry */
};
Thanks
Marc Gariepy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
TTM and AGP conflicts
On Wed, Jan 4, 2012 at 10:36 AM, James Simmons
wrote:
>
>> Attached is patch to fix this, so sorry about that, i must have lost my
>> agp change along the way when working on the patchset. This patch is not
>> extensively tested, i will do more testing tomorrow on more gpu, might
>> even found an nvidia agp i can try. Again sorry for breaking this.
>
> Thanks for the fix up. I was wondering if this purposed change could be
> done instead. Its the same as your fix up except that you pass in the
> ttm_buffer_object for tt_create. The reason is I really like to have the
> ability to have more than one back end to grab a bunch pf pages from.
> Currently its AGP or something else. On some of my embedded devices the
> AGP space is not very large and can be exhausted very quickly. Those
> embedded devices have DMA engines I could use instead.
This change violate the layer separation ttm wish to preserve see :
http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg16443.html
You can achieve what you want by either adding a new domain so you would have
system, vram, agp, pcidma and object can be bound to one and only one. Or you
can hack your own agp ttm backend that could bind bo to agp or pci or
both at the
same time depending on what you want to achieve.
Cheers,
Jerome
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 8cf4a48..58ad508 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -349,10 +349,11 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned
> index, u32 val)
> ?}
>
> ?static struct ttm_tt *
> -nouveau_ttm_tt_create(struct ttm_bo_device *bdev,
> +nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
> ? ? ? ? ? ? ? ? ? ? ?unsigned long size, uint32_t page_flags,
> ? ? ? ? ? ? ? ? ? ? ?struct page *dummy_read_page)
> ?{
> + ? ? ? struct ttm_bo_device *bdev = bo->bdev;
> ? ? ? ?struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev);
> ? ? ? ?struct drm_device *dev = dev_priv->dev;
>
> @@ -1066,6 +1067,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
> ? ? ? ?dev_priv = nouveau_bdev(ttm->bdev);
> ? ? ? ?dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + ? ? ? if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + ? ? ? ? ? ? ? return ttm_agp_tt_populate(ttm);
> + ? ? ? }
> +#endif
> +
> ?#ifdef CONFIG_SWIOTLB
> ? ? ? ?if (swiotlb_nr_tbl()) {
> ? ? ? ? ? ? ? ?return ttm_dma_populate((void *)ttm, dev->dev);
> @@ -1105,6 +1112,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> ? ? ? ?dev_priv = nouveau_bdev(ttm->bdev);
> ? ? ? ?dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + ? ? ? if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + ? ? ? ? ? ? ? ttm_agp_tt_unpopulate(ttm);
> + ? ? ? ? ? ? ? return;
> + ? ? ? }
> +#endif
> +
> ?#ifdef CONFIG_SWIOTLB
> ? ? ? ?if (swiotlb_nr_tbl()) {
> ? ? ? ? ? ? ? ?ttm_dma_unpopulate((void *)ttm, dev->dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b0ebaf8..655f8e9 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -549,10 +549,12 @@ static struct ttm_backend_func radeon_backend_func = {
> ? ? ? ?.destroy = &radeon_ttm_backend_destroy,
> ?};
>
> -struct ttm_tt *radeon_ttm_tt_create(struct ttm_bo_device *bdev,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned long size, uint32_t page_flags,
> +struct ttm_tt *radeon_ttm_tt_create(struct ttm_buffer_object *bo,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned long size,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? uint32_t page_flags,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct page *dummy_read_page)
> ?{
> + ? ? ? struct ttm_bo_device *bdev = bo->bdev;
> ? ? ? ?struct radeon_device *rdev;
> ? ? ? ?struct radeon_ttm_tt *gtt;
>
> @@ -588,6 +590,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
> ? ? ? ? ? ? ? ?return 0;
>
> ? ? ? ?rdev = radeon_get_rdev(ttm->bdev);
> +#if __OS_HAS_AGP
> + ? ? ? if (rdev->flags & RADEON_IS_AGP) {
> + ? ? ? ? ? ? ? return ttm_agp_tt_populate(ttm);
> + ? ? ? }
> +#endif
>
> ?#ifdef CONFIG_SWIOTLB
> ? ? ? ?if (swiotlb_nr_tbl()) {
> @@ -624,6 +631,12 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
> ? ? ? ?unsigned i;
>
> ? ? ? ?rdev = radeon_get_rdev(ttm->bdev);
> +#if __OS_HAS_AGP
> + ? ? ? if (rdev->flags & RADEON_IS_AGP) {
> + ? ? ? ? ? ? ? ttm_agp_tt_unpopulate(ttm);
> + ? ? ? ? ? ? ? return;
> + ? ? ? }
> +#endif
>
> ?#ifdef CONFIG_SWIOTLB
> ? ? ? ?if (swiotlb_nr_tbl()) {
> diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> index 14ebd36..747c141 100644
> --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> @@ -31,6 +31,7 @@
>
> ?#include "ttm/ttm_module.h"
> ?#include "ttm/ttm_bo_driver.h"
> +#include "ttm/ttm_page_alloc.h"
> ?#ifdef TTM_HAS_AGP
> ?#include "ttm/ttm_placement.h"
> ?#include
> @@ -97,6 +98,7 @@ static void ttm_agp_destroy(struct ttm_tt *ttm)
>
> ? ? ? ?if (
[patch] gma500: silence gcc warnings in mid_get_vbt_data()
Add a cast here to silence a Gcc warning. drivers/gpu/drm/gma500/mid_bios.c:214:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Signed-off-by: Dan Carpenter --- Compile tested only. diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index 55fee10..5eee9ad 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -202,7 +202,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) /*so, some values have changed location*/ new_size = vbt->checksum; /*checksum contains lo size byte*/ /*LSB of oaktrail_gct contains hi size byte*/ - new_size |= ((0xff & (unsigned int)vbt->oaktrail_gct)) << 8; + new_size |= ((0xff & (unsigned int)(long)vbt->oaktrail_gct)) << 8; vbt->checksum = vbt->size; /*size contains the checksum*/ if (new_size > 0xff) @@ -211,8 +211,8 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) vbt->size = new_size; /* number of descriptors defined in the GCT */ - number_desc = ((0xff00 & (unsigned int)vbt->oaktrail_gct)) >> 8; - bpi = ((0xff & (unsigned int)vbt->oaktrail_gct)) >> 16; + number_desc = ((0xff00 & (unsigned int)(long)vbt->oaktrail_gct)) >> 8; + bpi = ((0xff & (unsigned int)(long)vbt->oaktrail_gct)) >> 16; vbt->oaktrail_gct = ioremap(addr + GCT_R10_HEADER_SIZE, GCT_R10_DISPLAY_DESC_SIZE * number_desc); pGCT = vbt->oaktrail_gct;
[patch] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
b/drivers/gpu/drm/nouveau/nv50_pm.c
index 0393721..3508de9 100644
--- a/drivers/gpu/drm/nouveau/nv50_pm.c
+++ b/drivers/gpu/drm/nouveau/nv50_pm.c
@@ -540,7 +540,7 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct
nouveau_pm_level *perflvl)
info->mclk_hwsq.len = 0;
if (perflvl->memory) {
clk = calc_mclk(dev, perflvl->memory, &info->mclk_hwsq);
- if (clk < 0) {
+ if ((int)clk < 0) {
ret = clk;
goto error;
}
[PATCH 5/7] drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()
calc_mclk() returns zero on success and negative on failure but clk is a u32. v2: Martin Peres: - clk should be an int, not a u32 Signed-off-by: Martin Peres Signed-off-by: Dan Carpenter --- drivers/gpu/drm/nouveau/nv50_pm.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c b/drivers/gpu/drm/nouveau/nv50_pm.c index 983b432..4be2e20 100644 --- a/drivers/gpu/drm/nouveau/nv50_pm.c +++ b/drivers/gpu/drm/nouveau/nv50_pm.c @@ -659,11 +659,11 @@ nv50_pm_clocks_pre(struct drm_device *dev, struct nouveau_pm_level *perflvl) struct nv50_pm_state *info; struct hwsq_ucode *hwsq; struct pll_lims pll; - int ret = -EINVAL; + int clk, ret = -EINVAL; int N, M, P1, P2; u32 mast = nv_rd32(dev, 0x00c040); u32 divs = read_div(dev); - u32 ctrl, clk, out; + u32 ctrl, out; if (dev_priv->chipset == 0xaa || dev_priv->chipset == 0xac) -- 1.7.8.1 --01070909000807010709--
Re: [PATCH] Disable LVDS output on Clientron E830 Thin Client
On Tue, 2011-12-27 at 12:06 -0500, Joel Sass wrote:
> --- ./intel_lvds.old2011-12-20 13:25:49.368291249 -0500
> +++ ./intel_lvds.c2011-12-20 13:26:05.160291248 -0500
> @@ -709,6 +709,14 @@
> },
> {
> .callback = intel_no_lvds_dmi_callback,
> +.ident = "Clientron E830",
> +.matches = {
> +DMI_MATCH(DMI_SYS_VENDOR, "Clientron"),
> +DMI_MATCH(DMI_PRODUCT_NAME, "E830"),
> +},
> +},
> +{
> +.callback = intel_no_lvds_dmi_callback,
> .ident = "Asus EeeBox PC EB1007",
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: TTM and AGP conflicts
On Wed, Jan 4, 2012 at 11:04 AM, James Simmons wrote: > >> >> Attached is patch to fix this, so sorry about that, i must have lost my >> >> agp change along the way when working on the patchset. This patch is not >> >> extensively tested, i will do more testing tomorrow on more gpu, might >> >> even found an nvidia agp i can try. Again sorry for breaking this. >> > >> > Thanks for the fix up. I was wondering if this purposed change could be >> > done instead. Its the same as your fix up except that you pass in the >> > ttm_buffer_object for tt_create. The reason is I really like to have the >> > ability to have more than one back end to grab a bunch pf pages from. >> > Currently its AGP or something else. On some of my embedded devices the >> > AGP space is not very large and can be exhausted very quickly. Those >> > embedded devices have DMA engines I could use instead. >> >> This change violate the layer separation ttm wish to preserve see : >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg16443.html >> >> You can achieve what you want by either adding a new domain so you would have >> system, vram, agp, pcidma and object can be bound to one and only one. Or you >> can hack your own agp ttm backend that could bind bo to agp or pci or >> both at the same time depending on what you want to achieve. > > The question is how does one know which domain you want in tt_create. > Currenty drivers are using there dev_priv but if you have have more than > one option available how does one choose? Would you be okay with passing > in a domain flag? > Well i agree that something would be usefull there so the driver know which bind/unbind function it should use. Thomas i would prefer passing the bo to the tt_create callback but a flag is the minimum we need. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: TTM and AGP conflicts
> >> Attached is patch to fix this, so sorry about that, i must have lost my > >> agp change along the way when working on the patchset. This patch is not > >> extensively tested, i will do more testing tomorrow on more gpu, might > >> even found an nvidia agp i can try. Again sorry for breaking this. > > > > Thanks for the fix up. I was wondering if this purposed change could be > > done instead. Its the same as your fix up except that you pass in the > > ttm_buffer_object for tt_create. The reason is I really like to have the > > ability to have more than one back end to grab a bunch pf pages from. > > Currently its AGP or something else. On some of my embedded devices the > > AGP space is not very large and can be exhausted very quickly. Those > > embedded devices have DMA engines I could use instead. > > This change violate the layer separation ttm wish to preserve see : > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg16443.html > > You can achieve what you want by either adding a new domain so you would have > system, vram, agp, pcidma and object can be bound to one and only one. Or you > can hack your own agp ttm backend that could bind bo to agp or pci or > both at the same time depending on what you want to achieve. The question is how does one know which domain you want in tt_create. Currenty drivers are using there dev_priv but if you have have more than one option available how does one choose? Would you be okay with passing in a domain flag? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: TTM and AGP conflicts
On Wed, Jan 4, 2012 at 10:36 AM, James Simmons wrote:
>
>> Attached is patch to fix this, so sorry about that, i must have lost my
>> agp change along the way when working on the patchset. This patch is not
>> extensively tested, i will do more testing tomorrow on more gpu, might
>> even found an nvidia agp i can try. Again sorry for breaking this.
>
> Thanks for the fix up. I was wondering if this purposed change could be
> done instead. Its the same as your fix up except that you pass in the
> ttm_buffer_object for tt_create. The reason is I really like to have the
> ability to have more than one back end to grab a bunch pf pages from.
> Currently its AGP or something else. On some of my embedded devices the
> AGP space is not very large and can be exhausted very quickly. Those
> embedded devices have DMA engines I could use instead.
This change violate the layer separation ttm wish to preserve see :
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg16443.html
You can achieve what you want by either adding a new domain so you would have
system, vram, agp, pcidma and object can be bound to one and only one. Or you
can hack your own agp ttm backend that could bind bo to agp or pci or
both at the
same time depending on what you want to achieve.
Cheers,
Jerome
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 8cf4a48..58ad508 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -349,10 +349,11 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned
> index, u32 val)
> }
>
> static struct ttm_tt *
> -nouveau_ttm_tt_create(struct ttm_bo_device *bdev,
> +nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
> unsigned long size, uint32_t page_flags,
> struct page *dummy_read_page)
> {
> + struct ttm_bo_device *bdev = bo->bdev;
> struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev);
> struct drm_device *dev = dev_priv->dev;
>
> @@ -1066,6 +1067,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
> dev_priv = nouveau_bdev(ttm->bdev);
> dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + return ttm_agp_tt_populate(ttm);
> + }
> +#endif
> +
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> return ttm_dma_populate((void *)ttm, dev->dev);
> @@ -1105,6 +1112,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
> dev_priv = nouveau_bdev(ttm->bdev);
> dev = dev_priv->dev;
>
> +#if __OS_HAS_AGP
> + if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
> + ttm_agp_tt_unpopulate(ttm);
> + return;
> + }
> +#endif
> +
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> ttm_dma_unpopulate((void *)ttm, dev->dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b0ebaf8..655f8e9 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -549,10 +549,12 @@ static struct ttm_backend_func radeon_backend_func = {
> .destroy = &radeon_ttm_backend_destroy,
> };
>
> -struct ttm_tt *radeon_ttm_tt_create(struct ttm_bo_device *bdev,
> - unsigned long size, uint32_t page_flags,
> +struct ttm_tt *radeon_ttm_tt_create(struct ttm_buffer_object *bo,
> + unsigned long size,
> + uint32_t page_flags,
> struct page *dummy_read_page)
> {
> + struct ttm_bo_device *bdev = bo->bdev;
> struct radeon_device *rdev;
> struct radeon_ttm_tt *gtt;
>
> @@ -588,6 +590,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
> return 0;
>
> rdev = radeon_get_rdev(ttm->bdev);
> +#if __OS_HAS_AGP
> + if (rdev->flags & RADEON_IS_AGP) {
> + return ttm_agp_tt_populate(ttm);
> + }
> +#endif
>
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> @@ -624,6 +631,12 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
> unsigned i;
>
> rdev = radeon_get_rdev(ttm->bdev);
> +#if __OS_HAS_AGP
> + if (rdev->flags & RADEON_IS_AGP) {
> + ttm_agp_tt_unpopulate(ttm);
> + return;
> + }
> +#endif
>
> #ifdef CONFIG_SWIOTLB
> if (swiotlb_nr_tbl()) {
> diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> index 14ebd36..747c141 100644
> --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> @@ -31,6 +31,7 @@
>
> #include "ttm/ttm_module.h"
> #include "ttm/ttm_bo_driver.h"
> +#include "ttm/ttm_page_alloc.h"
> #ifdef TTM_HAS_AGP
> #include "ttm/ttm_placement.h"
> #include
> @@ -97,6 +98,7 @@ static void ttm_agp_destroy(struct ttm_tt *ttm)
>
> if (agp_
Re: TTM and AGP conflicts
> Attached is patch to fix this, so sorry about that, i must have lost my
> agp change along the way when working on the patchset. This patch is not
> extensively tested, i will do more testing tomorrow on more gpu, might
> even found an nvidia agp i can try. Again sorry for breaking this.
Thanks for the fix up. I was wondering if this purposed change could be
done instead. Its the same as your fix up except that you pass in the
ttm_buffer_object for tt_create. The reason is I really like to have the
ability to have more than one back end to grab a bunch pf pages from.
Currently its AGP or something else. On some of my embedded devices the
AGP space is not very large and can be exhausted very quickly. Those
embedded devices have DMA engines I could use instead.
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8cf4a48..58ad508 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -349,10 +349,11 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned index,
u32 val)
}
static struct ttm_tt *
-nouveau_ttm_tt_create(struct ttm_bo_device *bdev,
+nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
unsigned long size, uint32_t page_flags,
struct page *dummy_read_page)
{
+ struct ttm_bo_device *bdev = bo->bdev;
struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev);
struct drm_device *dev = dev_priv->dev;
@@ -1066,6 +1067,12 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
return ttm_dma_populate((void *)ttm, dev->dev);
@@ -1105,6 +1112,13 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
dev_priv = nouveau_bdev(ttm->bdev);
dev = dev_priv->dev;
+#if __OS_HAS_AGP
+ if (dev_priv->gart_info.type == NOUVEAU_GART_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
+
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate((void *)ttm, dev->dev);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b0ebaf8..655f8e9 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -549,10 +549,12 @@ static struct ttm_backend_func radeon_backend_func = {
.destroy = &radeon_ttm_backend_destroy,
};
-struct ttm_tt *radeon_ttm_tt_create(struct ttm_bo_device *bdev,
- unsigned long size, uint32_t page_flags,
+struct ttm_tt *radeon_ttm_tt_create(struct ttm_buffer_object *bo,
+ unsigned long size,
+ uint32_t page_flags,
struct page *dummy_read_page)
{
+ struct ttm_bo_device *bdev = bo->bdev;
struct radeon_device *rdev;
struct radeon_ttm_tt *gtt;
@@ -588,6 +590,11 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
return 0;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ return ttm_agp_tt_populate(ttm);
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
@@ -624,6 +631,12 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
unsigned i;
rdev = radeon_get_rdev(ttm->bdev);
+#if __OS_HAS_AGP
+ if (rdev->flags & RADEON_IS_AGP) {
+ ttm_agp_tt_unpopulate(ttm);
+ return;
+ }
+#endif
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 14ebd36..747c141 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -31,6 +31,7 @@
#include "ttm/ttm_module.h"
#include "ttm/ttm_bo_driver.h"
+#include "ttm/ttm_page_alloc.h"
#ifdef TTM_HAS_AGP
#include "ttm/ttm_placement.h"
#include
@@ -97,6 +98,7 @@ static void ttm_agp_destroy(struct ttm_tt *ttm)
if (agp_be->mem)
ttm_agp_unbind(ttm);
+ ttm_tt_fini(ttm);
kfree(agp_be);
}
@@ -129,4 +131,19 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device
*bdev,
}
EXPORT_SYMBOL(ttm_agp_tt_create);
+int ttm_agp_tt_populate(struct ttm_tt *ttm)
+{
+ if (ttm->state != tt_unpopulated)
+ return 0;
+
+ return ttm_pool_populate(ttm);
+}
+EXPORT_SYMBOL(ttm_agp_tt_populate);
+
+void ttm_agp_tt_unpopulate(struct ttm_tt *ttm)
+{
+ ttm_pool_unpopulate(ttm);
+}
+EXPORT_SYMBOL(ttm_agp_tt_unpopulate);
+
#endif
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2f0eab6..1adc149 100644
--- a/drivers/gpu/drm
[Bug 44130] Radeon pm segfault
https://bugs.freedesktop.org/show_bug.cgi?id=44130 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Alex Deucher 2012-01-04 07:02:49 PST --- Pushed: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4376eee92e5a8332b470040e672ea99cd44c826a -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
> Well, hotplug is alreay a giant pain because of the single lock to rule > them all design of the current kms code: Long delays already stall > everything else (well, cursor updates and pageflips) and we have tons of Yes I hit this with the gma500, it's one reason I did the GTT based scrolling. > bugreports that complain about it. In a sense your example undermines my > point that we have lower hanger fruit to fix all over the place already ... Yes.. I'm trying to stop the rotting fruit getting any further down the tree! The KMS locking isn't just a KMS problem, KMS inherits some of it from the framebuffer which inherits some of it from printk which gets some of it from panic an in IRQ error handling. It's all very messy as a result. I keep poking at the vt and tty layer end of this to try and sort it out from the bottom but it's like a bad cess pit, every time you poke it the smell drives you back to other things. > But as I've said I like the WARN_ON you want to add, but otoh hand think > it shouldn't be used to stall the small&hackish fix of adding the relevant > in_atomic checks. Then I think we basically agree. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 01:28:28PM +, Alan Cox wrote: > > unnusual contexts). I'm not sure whether your proposed instrumentation is > > really worth it though - in i915-land we don't bother with this. But maybe > > In i915 land it's specific code paths so effectively it is marked up. We > don't do it for every random delay in all the connectors and other bits. > The bits of code believing they are safe use sleeping locks and we'll get > spewage if that breaks. Ditto at this point I hope gma500 although I > would not be surpised to find ones I still need to fix from being mdelay. The atomic context check is in the _wait_for macro in intel_drv.h which is used all over the place. Like in the wait_for_vblank function. So I don't think you can use i915.ko as a shiny beacon of how to do it ;-) > > with the firmware provided and randomly b0rked atombios tables it might > > make sense to add the WARN_ON_ONCE you've proposed in the other mail > > I think we need it because it can be added by firmware, it could be > silently done and the atombios paths cover so many different things > beyond modesetting using that exact same function we need the mark up. > > If some vendor puts a 100ms delay in a connector related hotplug check we > are going to have a horrible time debugging 'bugzilla #zillion, 'poor > performance in OpenGL game with Radeon foozillion' Well, hotplug is alreay a giant pain because of the single lock to rule them all design of the current kms code: Long delays already stall everything else (well, cursor updates and pageflips) and we have tons of bugreports that complain about it. In a sense your example undermines my point that we have lower hanger fruit to fix all over the place already ... But as I've said I like the WARN_ON you want to add, but otoh hand think it shouldn't be used to stall the small&hackish fix of adding the relevant in_atomic checks. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
> unnusual contexts). I'm not sure whether your proposed instrumentation is > really worth it though - in i915-land we don't bother with this. But maybe In i915 land it's specific code paths so effectively it is marked up. We don't do it for every random delay in all the connectors and other bits. The bits of code believing they are safe use sleeping locks and we'll get spewage if that breaks. Ditto at this point I hope gma500 although I would not be surpised to find ones I still need to fix from being mdelay. > with the firmware provided and randomly b0rked atombios tables it might > make sense to add the WARN_ON_ONCE you've proposed in the other mail I think we need it because it can be added by firmware, it could be silently done and the atombios paths cover so many different things beyond modesetting using that exact same function we need the mark up. If some vendor puts a 100ms delay in a connector related hotplug check we are going to have a horrible time debugging 'bugzilla #zillion, 'poor performance in OpenGL game with Radeon foozillion' Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24861] [RV250Lf] External monitor loses signal from loading drm modules/firmware until X starts
https://bugs.freedesktop.org/show_bug.cgi?id=24861 Johannes Obermayr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Johannes Obermayr 2012-01-04 05:12:29 PST --- Fixed a long time ago. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36037] RV250Lf: airlied/drm-fixes branch crashes in new backlight code
https://bugs.freedesktop.org/show_bug.cgi?id=36037 Johannes Obermayr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Johannes Obermayr 2012-01-04 05:06:07 PST --- It does not crash when building against recent kernels. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24215] [RV250Lf] radeonPolygonStipplePreKMS in radeon_common.c
https://bugs.freedesktop.org/show_bug.cgi?id=24215 Johannes Obermayr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Johannes Obermayr 2012-01-04 05:03:06 PST --- Obsolete because DRI1 code was removed from Mesa stack in Oct 2011. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote: > > I think Alan's simply wrong. > > In what way ? You stated this, then go on below to say what I did ? > > > Splattering the entire driver for > > these two corner cases which don't happen at all under normal > > circumstances is imho utter nonsense. > > Which is what I said > > | > > Is this only special cases like a panic - if so can it not be called > in a > | > > way that distinguishes between normality and nasty cases. > | > > | > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > | > theory it could be indirectly called from anywhere that uses ATOM > BIOS. > > | So lets stick to practice, and the real world. Screwing up everything > | else because of a crappy problem in your Atom BIOS code sucks but hey it > | happens. screwing up everything because of a theoretical concern is just > | dumb. Meh, missed the first part of your mail here. Looks like a misunderstanding on my side, I was assuming you're proposing to add an atom_exec_atomic thing which - would unconditionally do the spinning delay (by completely abolishing the in_atomic checks) and - which would require to pass around a flag from at least the panic handler throught the entire modeset code. Your actual proposal makes much more sense, and as I've said I kinda like the warning, altough I'm not really sold on the usefulness of it all. After all we already have all the nice ftrace instrumentation to put blame for hoggin the cpu in atomic contexts where it needs to be put. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 12:09:36PM +, Alan Cox wrote: > > I think Alan's simply wrong. > > In what way ? You stated this, then go on below to say what I did ? > > > Splattering the entire driver for > > these two corner cases which don't happen at all under normal > > circumstances is imho utter nonsense. > > Which is what I said > > | > > Is this only special cases like a panic - if so can it not be called > in a > | > > way that distinguishes between normality and nasty cases. > | > > | > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > | > theory it could be indirectly called from anywhere that uses ATOM > BIOS. > > | So lets stick to practice, and the real world. Screwing up everything > | else because of a crappy problem in your Atom BIOS code sucks but hey it > | happens. screwing up everything because of a theoretical concern is just > | dumb. > > > We don't want to do mdelays when they are not needed just because it is > theoretically possible they are not needed. There are several ways to fix > it, one is to stuff in_atomic() etc in the awkward spots. However if > you've got something where you have lots of call points to an interface > this is actually a bad idea, because you grow more insidiously, or a > change elsewhere in the kernel silently turns all your sleeps into delays > and things like live music work stop being doable with radeon graphics. > > So the better way to fix it is to actually have an interface > > atom_execute_table_atomic() > > so that such situations are called out clearly, and any change elsewhere > that messes it all up causes kernel spewage that can be dealt with > properly - either by using _atomic if its something obscure like a panic, > fixing the issue or reverting the problematic change further up the tree. > > Another way to approach it would be to have > > radeon_atom_atomic(rdev); > radeon_atom_whateverfoo(rdev, ...) > radeon_atom_atomic_end(rdev); > > which set and cleared a bitflag that the mdelay/msleep opcode tested. > > That's quicker to implement but a spot less clean. Again it calls out any > such cases and makes them explicit. It also means any accidental changes > that affect this will result in spewage and debugging not silent trashing > of performance for stuff like machine control, music and some gaming. > > It should only be for panic, although accel calls for printk spewage can > hit in atomic context in some situations but I don't think that becomes > an atombios path ? Well, if your dear X server changed the modesetting layout we need to change it back to the kms fb layout so that we can properly display the panic. Which is done by atombios calls afaik (and in i915 has tons of rather long delays, too). I agree with you that we should have a decent grip on where we can actually end up in atomic modeset calls (or for radeon, atombios in general), which imo should only be the panic handler and kdbg (and similar unnusual contexts). I'm not sure whether your proposed instrumentation is really worth it though - in i915-land we don't bother with this. But maybe with the firmware provided and randomly b0rked atombios tables it might make sense to add the WARN_ON_ONCE you've proposed in the other mail -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
> Every modesetting operation can happen in atomic context or not in
> atomic context, thanks to the wonder of oops printing and also kgdb,
> trying to figure out which table in this one person's bios is the
> "root" cause and special casing for it is insane since tomorrow 20
> other BIOSes could contain that table or a new variant we haven't seen
> before.
>
> Unless one of us is totally misinterpreting what the other is saying
> or what the atombios interpreter is.
Its a sort of bytecode engine that allows the BIOS to describe to the
OS how the GPU should be handled. So what we want to avoid is
accidentally having some other path become spinlock based due to a
random unrelated change and ending up doing 20mS spinning delays without
us getting a warning.
Explicitly calling out that mode setting does this isn't a big deal - we
don't modeset often while doing stuff that is latency sensitive (gaming,
live music, telephony, etc) and if you have the in_atomic check as well
we'd probably only hit it on panic().
The problem is if we just band-aid it without doing this it will (and
always has) ended in tears later.
So as per the other mail all I'm really saying is we want something like
radeon_atom_mode_atomic_begin(rdev)
{
rdev->mode_info.atom_context->atomic = 1;
}
radeon_atom_mode_atomic_end(rdev)
{
rdev->mode_info.atom_context->atomic = 0;
}
/* above maybe with sanity checks to stop missed ones */
and to do
else {
if (!in_atomic())
msleep(count);
else {
WARN_ON(!ctx->atomic);
mdelay(count);
}
}
so that we know it isn't getting hit in places we've not carefully
considered the impact of a huge stall.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
> I think Alan's simply wrong. In what way ? You stated this, then go on below to say what I did ? > Splattering the entire driver for > these two corner cases which don't happen at all under normal > circumstances is imho utter nonsense. Which is what I said | > > Is this only special cases like a panic - if so can it not be called in a | > > way that distinguishes between normality and nasty cases. | > | > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in | > theory it could be indirectly called from anywhere that uses ATOM BIOS. | So lets stick to practice, and the real world. Screwing up everything | else because of a crappy problem in your Atom BIOS code sucks but hey it | happens. screwing up everything because of a theoretical concern is just | dumb. We don't want to do mdelays when they are not needed just because it is theoretically possible they are not needed. There are several ways to fix it, one is to stuff in_atomic() etc in the awkward spots. However if you've got something where you have lots of call points to an interface this is actually a bad idea, because you grow more insidiously, or a change elsewhere in the kernel silently turns all your sleeps into delays and things like live music work stop being doable with radeon graphics. So the better way to fix it is to actually have an interface atom_execute_table_atomic() so that such situations are called out clearly, and any change elsewhere that messes it all up causes kernel spewage that can be dealt with properly - either by using _atomic if its something obscure like a panic, fixing the issue or reverting the problematic change further up the tree. Another way to approach it would be to have radeon_atom_atomic(rdev); radeon_atom_whateverfoo(rdev, ...) radeon_atom_atomic_end(rdev); which set and cleared a bitflag that the mdelay/msleep opcode tested. That's quicker to implement but a spot less clean. Again it calls out any such cases and makes them explicit. It also means any accidental changes that affect this will result in spewage and debugging not silent trashing of performance for stuff like machine control, music and some gaming. It should only be for panic, although accel calls for printk spewage can hit in atomic context in some situations but I don't think that becomes an atombios path ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
2012/1/4 Alan Cox : >> > So lets stick to practice, and the real world. Screwing up everything >> > else because of a crappy problem in your Atom BIOS code sucks but hey it >> > happens. screwing up everything because of a theoretical concern is just >> > dumb. >> >> Thanks for the flowers, but it's not just a theoretical concern, see the >> bug report. > > The bug report is a single specific case. Figure out the calling > paths afflicted by it, don't be lazy and just dump on everyone on every > path because of a special case you apparently can't be bothered to root > cause. > I'm not sure what we'd gain by passing the atomic context information in from the top of the atom interpreter and using it in this one place vs getting the atomic info in this one place. Every modesetting operation can happen in atomic context or not in atomic context, thanks to the wonder of oops printing and also kgdb, trying to figure out which table in this one person's bios is the "root" cause and special casing for it is insane since tomorrow 20 other BIOSes could contain that table or a new variant we haven't seen before. Unless one of us is totally misinterpreting what the other is saying or what the atombios interpreter is. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43719] drm-core-next + AGP RV670 = Oops
https://bugs.freedesktop.org/show_bug.cgi?id=43719 --- Comment #3 from Andy Furniss 2012-01-04 03:53:20 PST --- (In reply to comment #2) > Created attachment 55095 [details] [review] > Fix agp on top of ttm tt rework > > Should fix the bug let me know Yes, this fixes it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Mit, 2012-01-04 at 12:44 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel Dänzer wrote:
> > On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> > > > From: Michel Dänzer
> > > >
> > > > It can be the case e.g. when switching to console for panic output.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> > > >
> > > > Signed-off-by: Michel Dänzer
> > > > ---
> > > >
> > > > v2: Still call msleep() in the normal case. Only compile tested.
> > > >
> > > > drivers/gpu/drm/radeon/atom.c |2 ++
> > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/radeon/atom.c
> > > > b/drivers/gpu/drm/radeon/atom.c
> > > > index 14cc88a..4092e59 100644
> > > > --- a/drivers/gpu/drm/radeon/atom.c
> > > > +++ b/drivers/gpu/drm/radeon/atom.c
> > > > @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx,
> > > > int *ptr, int arg)
> > > > SDEBUG(" count: %d\n", count);
> > > > if (arg == ATOM_UNIT_MICROSEC)
> > > > udelay(count);
> > > > + else if (in_interrupt() || irqs_disabled() || in_atomic())
> > > > + mdelay(count);
> > >
> > > Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
> > > addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
> > > checks for in_dbg_master() to take care of kdbg.
> > >
> > > Can I bother you to create a small helper like in_atomic_kms_context that
> > > checks these three things (and also use it in drm/i915)?
> >
> > Sorry, I've already spent way more time on this than I meant to, and
> > Alan just killed what little motivation I still had to spend more.
>
> I think Alan's simply wrong. The msleep checks in i915 are only used for
> two cases:
> - when using kdbg
> - when displaying a panic
> Afaics radeon has the exact same issue, at least I've seen my radeon
> machine here go down after an oops. Splattering the entire driver for
> these two corner cases which don't happen at all under normal
> circumstances is imho utter nonsense.
>
> I.e. I'd be very happy to smash a r-b onto your patch if you unifiy the
> magical checks with i915 in a common function and add a small comment.
> Does the prospect of an up-front r-b and me promising to harass Dave to
> merge it restore your motivation?
It's certainly helping. :) I'll see what I can do.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 12:29:24PM +0100, Michel Dänzer wrote:
> On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> > On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> > > From: Michel Dänzer
> > >
> > > It can be the case e.g. when switching to console for panic output.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> > >
> > > Signed-off-by: Michel Dänzer
> > > ---
> > >
> > > v2: Still call msleep() in the normal case. Only compile tested.
> > >
> > > drivers/gpu/drm/radeon/atom.c |2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> > > index 14cc88a..4092e59 100644
> > > --- a/drivers/gpu/drm/radeon/atom.c
> > > +++ b/drivers/gpu/drm/radeon/atom.c
> > > @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int
> > > *ptr, int arg)
> > > SDEBUG(" count: %d\n", count);
> > > if (arg == ATOM_UNIT_MICROSEC)
> > > udelay(count);
> > > + else if (in_interrupt() || irqs_disabled() || in_atomic())
> > > + mdelay(count);
> >
> > Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
> > addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
> > checks for in_dbg_master() to take care of kdbg.
> >
> > Can I bother you to create a small helper like in_atomic_kms_context that
> > checks these three things (and also use it in drm/i915)?
>
> Sorry, I've already spent way more time on this than I meant to, and
> Alan just killed what little motivation I still had to spend more.
I think Alan's simply wrong. The msleep checks in i915 are only used for
two cases:
- when using kdbg
- when displaying a panic
Afaics radeon has the exact same issue, at least I've seen my radeon
machine here go down after an oops. Splattering the entire driver for
these two corner cases which don't happen at all under normal
circumstances is imho utter nonsense.
I.e. I'd be very happy to smash a r-b onto your patch if you unifiy the
magical checks with i915 in a common function and add a small comment.
Does the prospect of an up-front r-b and me promising to harass Dave to
merge it restore your motivation?
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch] gma500: silence gcc warnings in mid_get_vbt_data()
On Wed, 4 Jan 2012 10:26:10 +0300 Dan Carpenter wrote: > Add a cast here to silence a Gcc warning. > drivers/gpu/drm/gma500/mid_bios.c:214:28: warning: > cast from pointer to integer of different size > [-Wpointer-to-int-cast] > > Signed-off-by: Dan Carpenter > --- > Compile tested only. It's actually a non-bug (no 64bit boxes and we always take from within the low 32bits). I guess gcc would have to extremely smart to figure that out though. Acked-by: Alan Cox ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Mit, 2012-01-04 at 11:54 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > It can be the case e.g. when switching to console for panic output.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
> >
> > Signed-off-by: Michel Dänzer
> > ---
> >
> > v2: Still call msleep() in the normal case. Only compile tested.
> >
> > drivers/gpu/drm/radeon/atom.c |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> > index 14cc88a..4092e59 100644
> > --- a/drivers/gpu/drm/radeon/atom.c
> > +++ b/drivers/gpu/drm/radeon/atom.c
> > @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int
> > *ptr, int arg)
> > SDEBUG(" count: %d\n", count);
> > if (arg == ATOM_UNIT_MICROSEC)
> > udelay(count);
> > + else if (in_interrupt() || irqs_disabled() || in_atomic())
> > + mdelay(count);
>
> Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
> addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
> checks for in_dbg_master() to take care of kdbg.
>
> Can I bother you to create a small helper like in_atomic_kms_context that
> checks these three things (and also use it in drm/i915)?
Sorry, I've already spent way more time on this than I meant to, and
Alan just killed what little motivation I still had to spend more.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
> > So lets stick to practice, and the real world. Screwing up everything > > else because of a crappy problem in your Atom BIOS code sucks but hey it > > happens. screwing up everything because of a theoretical concern is just > > dumb. > > Thanks for the flowers, but it's not just a theoretical concern, see the > bug report. The bug report is a single specific case. Figure out the calling paths afflicted by it, don't be lazy and just dump on everyone on every path because of a special case you apparently can't be bothered to root cause. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
On Wed, Jan 04, 2012 at 11:33:40AM +0100, Michel Dänzer wrote:
> From: Michel Dänzer
>
> It can be the case e.g. when switching to console for panic output.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
>
> Signed-off-by: Michel Dänzer
> ---
>
> v2: Still call msleep() in the normal case. Only compile tested.
>
> drivers/gpu/drm/radeon/atom.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index 14cc88a..4092e59 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int
> *ptr, int arg)
> SDEBUG(" count: %d\n", count);
> if (arg == ATOM_UNIT_MICROSEC)
> udelay(count);
> + else if (in_interrupt() || irqs_disabled() || in_atomic())
> + mdelay(count);
Afaics in_atomic subsumes in_interrupt. irqs_disabled looks like a nice
addition to cover up the !CONFIG_PREEMPT case. i915 (in intel_drv.h) also
checks for in_dbg_master() to take care of kdbg.
Can I bother you to create a small helper like in_atomic_kms_context that
checks these three things (and also use it in drm/i915)?
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Mit, 2012-01-04 at 00:52 +, Alan Cox wrote: > On Tue, 03 Jan 2012 19:25:46 +0100 > Michel Dänzer wrote: > > On Die, 2012-01-03 at 18:09 +, Alan Cox wrote: > > > On Tue, 3 Jan 2012 19:04:00 +0100 > > > Michel Dänzer wrote: > > > > > > > From: Michel Dänzer > > > > > > > > It can be called from atomic context, e.g. when switching to console > > > > for panic > > > > output. > > > > > > Is this only special cases like a panic - if so can it not be called in a > > > way that distinguishes between normality and nasty cases. > > > > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > > theory it could be indirectly called from anywhere that uses ATOM BIOS. > > So lets stick to practice, and the real world. Screwing up everything > else because of a crappy problem in your Atom BIOS code sucks but hey it > happens. screwing up everything because of a theoretical concern is just > dumb. Thanks for the flowers, but it's not just a theoretical concern, see the bug report. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Die, 2012-01-03 at 21:04 +0100, Daniel Vetter wrote: > On Tue, Jan 03, 2012 at 07:16:25PM +0100, Michel Dänzer wrote: > > On Die, 2012-01-03 at 18:09 +, Dave Airlie wrote: > > > 2012/1/3 Michel Dänzer : > > > > From: Michel Dänzer > > > > > > > > It can be called from atomic context, e.g. when switching to console > > > > for panic > > > > output. > > > > > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43941 > > > > > > I wonder how ugly it would be to check for atomic context or not, > > > > So do I. :) The comment in include/linux/hardirq.h that ends in 'Do not > > use in_atomic() in driver code.' sounds rathery scary... > > We already use in_atomic checks in similar delay code in drm/i915 for the > same reasons. I think the ugly mess that results from the panic notifier > calling into kms code is justification enough to neglect the the comment > about not using in_atomic in drivers. Okay, v2 sent. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] radeon: Use mdelay() instead of msleep() when we can't sleep in atom_op_delay().
From: Michel Dänzer
It can be the case e.g. when switching to console for panic output.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941
Signed-off-by: Michel Dänzer
---
v2: Still call msleep() in the normal case. Only compile tested.
drivers/gpu/drm/radeon/atom.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 14cc88a..4092e59 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -665,6 +665,8 @@ static void atom_op_delay(atom_exec_context *ctx, int *ptr,
int arg)
SDEBUG(" count: %d\n", count);
if (arg == ATOM_UNIT_MICROSEC)
udelay(count);
+ else if (in_interrupt() || irqs_disabled() || in_atomic())
+ mdelay(count);
else
msleep(count);
}
--
1.7.7.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] gma500: silence gcc warnings in mid_get_vbt_data()
Add a cast here to silence a Gcc warning. drivers/gpu/drm/gma500/mid_bios.c:214:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Signed-off-by: Dan Carpenter --- Compile tested only. diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index 55fee10..5eee9ad 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -202,7 +202,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) /*so, some values have changed location*/ new_size = vbt->checksum; /*checksum contains lo size byte*/ /*LSB of oaktrail_gct contains hi size byte*/ - new_size |= ((0xff & (unsigned int)vbt->oaktrail_gct)) << 8; + new_size |= ((0xff & (unsigned int)(long)vbt->oaktrail_gct)) << 8; vbt->checksum = vbt->size; /*size contains the checksum*/ if (new_size > 0xff) @@ -211,8 +211,8 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) vbt->size = new_size; /* number of descriptors defined in the GCT */ - number_desc = ((0xff00 & (unsigned int)vbt->oaktrail_gct)) >> 8; - bpi = ((0xff & (unsigned int)vbt->oaktrail_gct)) >> 16; + number_desc = ((0xff00 & (unsigned int)(long)vbt->oaktrail_gct)) >> 8; + bpi = ((0xff & (unsigned int)(long)vbt->oaktrail_gct)) >> 16; vbt->oaktrail_gct = ioremap(addr + GCT_R10_HEADER_SIZE, GCT_R10_DISPLAY_DESC_SIZE * number_desc); pGCT = vbt->oaktrail_gct; ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: Use mdelay() instead of msleep() in atom_op_delay().
On Tue, 03 Jan 2012 19:25:46 +0100 Michel D?nzer wrote: > On Die, 2012-01-03 at 18:09 +, Alan Cox wrote: > > On Tue, 3 Jan 2012 19:04:00 +0100 > > Michel D?nzer wrote: > > > > > From: Michel D?nzer > > > > > > It can be called from atomic context, e.g. when switching to console for > > > panic > > > output. > > > > Is this only special cases like a panic - if so can it not be called in a > > way that distinguishes between normality and nasty cases. > > No idea, to be honest. It's an ATOM BIOS interpreter opcode, so in > theory it could be indirectly called from anywhere that uses ATOM BIOS. So lets stick to practice, and the real world. Screwing up everything else because of a crappy problem in your Atom BIOS code sucks but hey it happens. screwing up everything because of a theoretical concern is just dumb. I would start by making it some kind of context flag for your interpreter and making people involve the interpreter with a different function call if they can't sleep. At that point you'll be able to define the problem in the real kernel, document the rule and spot further people trying to jump off cliffs before they do. Alan
radeon: writeback-issues since kernel 2.6.34 on ATI FireMV 2200 PCI
On 01/03/2012 03:27 PM, Alex Deucher wrote: > On Mon, Jan 2, 2012 at 5:07 PM, Helge Deller wrote: >> I'm facing the problem with the radeon drm driver, that I now manually need >> to set the kernel module parameter radeon.no_wb to 1 at bootup, else X just >> hangs in average up to 8 seconds per minute without any real activity (X or >> the video driver just seems to wait for something..). >> >> Fedora 13 (kernel 2.6.34.9-69.fc13.x86_64) worked without problems, while >> all following Fedora distributions including F16 have this problem. >> I'm using a dual-DVI ATI RV280 [FireMV 2200 PCI]. >> >> I did compared the sources of those kernels and the only obvious change to >> me is in radeon_ring.c: radeon_ring_free_size() where those lines were added >> at the top of the function: >> if (rdev->wb.enabled) >> rdev->cp.rptr = >> le32_to_cpu(rdev->wb.wb[RADEON_WB_CP_RPTR_OFFSET/4]); >> >> Given the problems I'm seeing (X-Windows hangs for a few seconds every time) >> this fits with the idea, that the driver is waiting for a free slot but >> can't find any (maybe due to wrong values returned by not-working WB?). >> >> I'm wondering, if "rdev->wb.enabled" is correct in this place and if >> "dev_priv->writeback_works" shouldn't be used instead here? >> > > It's possible that writeback doesn't work on your system in which case > no_wb=1 is apprioriate. dev_priv->writeback_works is part of the old > UMS drm and is not used by KMS. The KMS code does not test if > writeback works prior to enabling it like UMS did. The slow down you > are seeing is caused by the driver waiting for the fence to be written > back to memory. If writeback does not work, the fence is never > written by the hw and the driver has to wait for the fence to time > out. Alex, thanks for the explanations. In my opinion this is a regression then. The old code worked without problems, while with the new driver (or only because of the added code lines) the driver doesn't work out of the box. Wouldn't it be an idea to port over the old UMS writeback-check-test to the new KMS code base to avoid the issues I'm seeing? I would be willing to test such code or even provide an initial patch if necessary. Helge
