[Bug 33912] [RV515] Kernel .35 onwards, Random X freezes while scrolling
https://bugzilla.kernel.org/show_bug.cgi?id=33912 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #9 from Alex Deucher 2011-06-10 05:05:08 --- Can you bisect? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
On Thu, 2011-06-09 at 09:21 +0100, Alan Cox wrote:
> On Thu, 09 Jun 2011 14:05:59 +1000
> Dave Airlie wrote:
>
> > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> > > To properly support the various plane formats supported by different
> > > hardware, the kernel must know the pixel format of a framebuffer object.
> > > So add a new ioctl taking a format argument corresponding to a fourcc
> > > name from videodev2.h.
> >
> > I'd rather we don't directly tie things like that, either create a
> > fourcc header that isn't V4L2 or DRM related and use that or generate
> > two headers one with DRM_ and one with V4L2 prefixes. Mainly so we can
> > keep the DRM interface in some way OS agnostic.
>
> It *is* OS agnostic (it started on the Amiga)
>
> You also don't need a headwer with a complete list of fourcc names in it,
> that is the half the point of FourCC.
#define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
RGB-3-3-2 */
See that V4L2 and v4l2? I'd rather not have them used in the drm
interface, either a DRM_ variant or a FOURCC_ variant that removes the
V4L2. Also having it in a different include file to "videodev2.h", so
yes we can pass FOURCC values but I'd rather we gave people a drm
specific way to generate them or make a generic set of macros that don't
include the V4L2 headers.
Dave.
[PATCH 14/15] gma500: nuke the PSB debug stuff
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: > On Thu, 9 Jun 2011 03:10:03 +0200 > Patrik Jakobsson wrote: > > > Hi Alan > > > > Just a thought. Shouldn't we use the DRM macros for printing debug info? > > Linux has perfectly good printing functions and using them means we can > use dev_dbg() which supports things like nice runtime switching. You mean like the drm debug functions runtime switching? that predated the kernel ones and nobody ever ported :-) Though if psb wants to be different to other drm drivers it can lead the way, though it'll be a total nightmare for all the people who follow documentation on how to debug drm drivers using drm.debug=1,2,4,8. for various code paths. Dave.
[Bug 33912] [RV515] Kernel .35 onwards, Random X freezes while scrolling
https://bugzilla.kernel.org/show_bug.cgi?id=33912 Vish changed: What|Removed |Added Kernel Version|.35 .36 .37 .38 |.35, .36, .37, .38, .39 --- Comment #8 from Vish 2011-06-10 03:22:57 --- Also happens in .39 kernel $ uname -a Linux Aspire-5670 2.6.39-02063901-generic #201106030905 SMP Fri Jun 3 10:56:14 UTC 2011 i686 GNU/Linux -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)
https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #2 from Alexandre Demers 2011-06-09 19:58:59 PDT --- Since it only happens when I use Diablo 2 with Glide, it is probably related to the Glide to OpenGL wrapper. If indeed the extension is not supported in r600g, then it is related to the application, thus the wrapper. I could try with a different wrapper (instead of GLIDE3-to-OpenGL-Wrapper/svenwrapper). -- 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 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)
https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #2 from Alexandre Demers 2011-06-09 19:58:59 PDT --- Since it only happens when I use Diablo 2 with Glide, it is probably related to the Glide to OpenGL wrapper. If indeed the extension is not supported in r600g, then it is related to the application, thus the wrapper. I could try with a different wrapper (instead of GLIDE3-to-OpenGL-Wrapper/svenwrapper). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/3] alpha, drm: Update Alpha DRM support
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote: > > This patch set fixes Alpha-specific support in the DRM code, > allowing Radeon KMS and the MGA driver to work properly on > Alpha-based machines. > > Jay > > Jay Estabrook (3): > ?alpha, drm: Update Alpha DRM support > ?alpha, drm: Cleanup Alpha support in DRM generic code > ?alpha, drm: Remove obsolete Alpha support in MGA DRM code > ?alpha, drm: Add Alpha support to Radeon DRM code > > ?drivers/gpu/drm/drm_bufs.c ? ? ? ? ?| ? ?3 --- > ?drivers/gpu/drm/drm_vm.c ? ? ? ? ? ?| ? ?2 +- > ?drivers/gpu/drm/mga/mga_drv.h ? ? ? | ? 19 --- > ?drivers/gpu/drm/radeon/radeon_ttm.c | ? 23 +++ > ?4 files changed, 24 insertions(+), 23 deletions(-) Patches 1 and 3 are Tested-by: Matt Turner They also fix Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=23227 In that report, Michel Danzer had some comments about the patch, so I'm CC'ing him. Thanks! Matt
[PATCH 3/3] alpha, drm: Add Alpha support to Radeon DRM code
Alpha needs to have the system bus address for the device's local memory available, so that it can be returned to user-level, where it may be used in an mmap(). So, we make bus.addr hold the ioremap() return for kernel use, and then we can modify bus.base appropriately. Signed-off-by: Jay Estabrook --- drivers/gpu/drm/radeon/radeon_ttm.c | 23 +++ 1 file changed, 23 insertions(+) diff -Naurp a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c --- a/drivers/gpu/drm/radeon/radeon_ttm.c 2011-04-26 23:48:50.0 -0400 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c 2011-05-03 18:24:27.0 -0400 @@ -450,6 +450,29 @@ static int radeon_ttm_io_mem_reserve(str return -EINVAL; mem->bus.base = rdev->mc.aper_base; mem->bus.is_iomem = true; +#ifdef __alpha__ + /* +* Alpha: use bus.addr to hold the ioremap() return, +* so we can modify bus.base below. +*/ + if (mem->placement & TTM_PL_FLAG_WC) + mem->bus.addr = + ioremap_wc(mem->bus.base + mem->bus.offset, + mem->bus.size); + else + mem->bus.addr = + ioremap_nocache(mem->bus.base + mem->bus.offset, + mem->bus.size); + + /* +* Alpha: Take just the bus offset and +* add the hose/domain memory base. +* Then, bus.base can be returned +* for use in an mmap() call. +*/ + mem->bus.base = (mem->bus.base & 0x0UL) + + rdev->ddev->hose->dense_mem_base; +#endif break; default: return -EINVAL; ---
[PATCH 2/3] alpha, drm: Remove obsolete Alpha support in MGA DRM code
Remove an obsolete Alpha adjustment in the drm for MGA on Alpha.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/mga/mga_drv.h | 19 ---
1 file changed, 19 deletions(-)
diff -Naurp a/drivers/gpu/drm/mga/mga_drv.h b/drivers/gpu/drm/mga/mga_drv.h
--- a/drivers/gpu/drm/mga/mga_drv.h 2011-04-26 23:48:50.0 -0400
+++ b/drivers/gpu/drm/mga/mga_drv.h 2011-05-02 11:51:48.0 -0400
@@ -195,29 +195,10 @@ extern long mga_compat_ioctl(struct file
#define mga_flush_write_combine() DRM_WRITEMEMORYBARRIER()
-#if defined(__linux__) && defined(__alpha__)
-#define MGA_BASE(reg) ((unsigned long)(dev_priv->mmio->handle))
-#define MGA_ADDR(reg) (MGA_BASE(reg) + reg)
-
-#define MGA_DEREF(reg) (*(volatile u32 *)MGA_ADDR(reg))
-#define MGA_DEREF8(reg)(*(volatile u8 *)MGA_ADDR(reg))
-
-#define MGA_READ(reg) (_MGA_READ((u32 *)MGA_ADDR(reg)))
-#define MGA_READ8(reg) (_MGA_READ((u8 *)MGA_ADDR(reg)))
-#define MGA_WRITE(reg, val)do { DRM_WRITEMEMORYBARRIER(); MGA_DEREF(reg) =
val; } while (0)
-#define MGA_WRITE8(reg, val) do { DRM_WRITEMEMORYBARRIER(); MGA_DEREF8(reg)
= val; } while (0)
-
-static inline u32 _MGA_READ(u32 *addr)
-{
- DRM_MEMORYBARRIER();
- return *(volatile u32 *)addr;
-}
-#else
#define MGA_READ8(reg) DRM_READ8(dev_priv->mmio, (reg))
#define MGA_READ(reg) DRM_READ32(dev_priv->mmio, (reg))
#define MGA_WRITE8(reg, val) DRM_WRITE8(dev_priv->mmio, (reg), (val))
#define MGA_WRITE(reg, val)DRM_WRITE32(dev_priv->mmio, (reg), (val))
-#endif
#define DWGREG00x1c00
#define DWGREG0_END0x1dff
---
[PATCH 1/3] alpha, drm: Cleanup Alpha support in DRM generic code
Remove an obsolete Alpha adjustment, and modify another,
to go with the current Alpha architecture support.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/drm_bufs.c|3 ---
drivers/gpu/drm/drm_vm.c |2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff -Naurp a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
--- a/drivers/gpu/drm/drm_bufs.c2011-04-26 23:48:50.0 -0400
+++ b/drivers/gpu/drm/drm_bufs.c2011-05-02 11:51:48.0 -0400
@@ -183,9 +183,6 @@ static int drm_addmap_core(struct drm_de
return -EINVAL;
}
#endif
-#ifdef __alpha__
- map->offset += dev->hose->mem_space->start;
-#endif
/* Some drivers preinitialize some maps, without the X Server
* needing to be aware of it. Therefore, we just return success
* when the server tries to create a duplicate map.
diff -Naurp a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
--- a/drivers/gpu/drm/drm_vm.c 2011-04-26 23:48:50.0 -0400
+++ b/drivers/gpu/drm/drm_vm.c 2011-05-02 11:51:48.0 -0400
@@ -526,7 +526,7 @@ static int drm_mmap_dma(struct file *fil
static resource_size_t drm_core_get_reg_ofs(struct drm_device *dev)
{
#ifdef __alpha__
- return dev->hose->dense_mem_base - dev->hose->mem_space->start;
+ return dev->hose->dense_mem_base;
#else
return 0;
#endif
---
[PATCH 0/3] alpha, drm: Update Alpha DRM support
This patch set fixes Alpha-specific support in the DRM code, allowing Radeon KMS and the MGA driver to work properly on Alpha-based machines. Jay Jay Estabrook (3): alpha, drm: Update Alpha DRM support alpha, drm: Cleanup Alpha support in DRM generic code alpha, drm: Remove obsolete Alpha support in MGA DRM code alpha, drm: Add Alpha support to Radeon DRM code drivers/gpu/drm/drm_bufs.c |3 --- drivers/gpu/drm/drm_vm.c|2 +- drivers/gpu/drm/mga/mga_drv.h | 19 --- drivers/gpu/drm/radeon/radeon_ttm.c | 23 +++ 4 files changed, 24 insertions(+), 23 deletions(-) ---
Re: [PATCH 0/3] alpha, drm: Update Alpha DRM support
On Thu, Jun 9, 2011 at 6:06 PM, Jay Estabrook wrote: > > This patch set fixes Alpha-specific support in the DRM code, > allowing Radeon KMS and the MGA driver to work properly on > Alpha-based machines. > > Jay > > Jay Estabrook (3): > alpha, drm: Update Alpha DRM support > alpha, drm: Cleanup Alpha support in DRM generic code > alpha, drm: Remove obsolete Alpha support in MGA DRM code > alpha, drm: Add Alpha support to Radeon DRM code > > drivers/gpu/drm/drm_bufs.c | 3 --- > drivers/gpu/drm/drm_vm.c | 2 +- > drivers/gpu/drm/mga/mga_drv.h | 19 --- > drivers/gpu/drm/radeon/radeon_ttm.c | 23 +++ > 4 files changed, 24 insertions(+), 23 deletions(-) Patches 1 and 3 are Tested-by: Matt Turner They also fix Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=23227 In that report, Michel Danzer had some comments about the patch, so I'm CC'ing him. Thanks! Matt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] alpha, drm: Remove obsolete Alpha support in MGA DRM code
Remove an obsolete Alpha adjustment in the drm for MGA on Alpha.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/mga/mga_drv.h | 19 ---
1 file changed, 19 deletions(-)
diff -Naurp a/drivers/gpu/drm/mga/mga_drv.h b/drivers/gpu/drm/mga/mga_drv.h
--- a/drivers/gpu/drm/mga/mga_drv.h 2011-04-26 23:48:50.0 -0400
+++ b/drivers/gpu/drm/mga/mga_drv.h 2011-05-02 11:51:48.0 -0400
@@ -195,29 +195,10 @@ extern long mga_compat_ioctl(struct file
#define mga_flush_write_combine() DRM_WRITEMEMORYBARRIER()
-#if defined(__linux__) && defined(__alpha__)
-#define MGA_BASE(reg) ((unsigned long)(dev_priv->mmio->handle))
-#define MGA_ADDR(reg) (MGA_BASE(reg) + reg)
-
-#define MGA_DEREF(reg) (*(volatile u32 *)MGA_ADDR(reg))
-#define MGA_DEREF8(reg)(*(volatile u8 *)MGA_ADDR(reg))
-
-#define MGA_READ(reg) (_MGA_READ((u32 *)MGA_ADDR(reg)))
-#define MGA_READ8(reg) (_MGA_READ((u8 *)MGA_ADDR(reg)))
-#define MGA_WRITE(reg, val)do { DRM_WRITEMEMORYBARRIER(); MGA_DEREF(reg) =
val; } while (0)
-#define MGA_WRITE8(reg, val) do { DRM_WRITEMEMORYBARRIER(); MGA_DEREF8(reg)
= val; } while (0)
-
-static inline u32 _MGA_READ(u32 *addr)
-{
- DRM_MEMORYBARRIER();
- return *(volatile u32 *)addr;
-}
-#else
#define MGA_READ8(reg) DRM_READ8(dev_priv->mmio, (reg))
#define MGA_READ(reg) DRM_READ32(dev_priv->mmio, (reg))
#define MGA_WRITE8(reg, val) DRM_WRITE8(dev_priv->mmio, (reg), (val))
#define MGA_WRITE(reg, val)DRM_WRITE32(dev_priv->mmio, (reg), (val))
-#endif
#define DWGREG00x1c00
#define DWGREG0_END0x1dff
---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] alpha, drm: Cleanup Alpha support in DRM generic code
Remove an obsolete Alpha adjustment, and modify another,
to go with the current Alpha architecture support.
Signed-off-by: Jay Estabrook
---
drivers/gpu/drm/drm_bufs.c|3 ---
drivers/gpu/drm/drm_vm.c |2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff -Naurp a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
--- a/drivers/gpu/drm/drm_bufs.c2011-04-26 23:48:50.0 -0400
+++ b/drivers/gpu/drm/drm_bufs.c2011-05-02 11:51:48.0 -0400
@@ -183,9 +183,6 @@ static int drm_addmap_core(struct drm_de
return -EINVAL;
}
#endif
-#ifdef __alpha__
- map->offset += dev->hose->mem_space->start;
-#endif
/* Some drivers preinitialize some maps, without the X Server
* needing to be aware of it. Therefore, we just return success
* when the server tries to create a duplicate map.
diff -Naurp a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
--- a/drivers/gpu/drm/drm_vm.c 2011-04-26 23:48:50.0 -0400
+++ b/drivers/gpu/drm/drm_vm.c 2011-05-02 11:51:48.0 -0400
@@ -526,7 +526,7 @@ static int drm_mmap_dma(struct file *fil
static resource_size_t drm_core_get_reg_ofs(struct drm_device *dev)
{
#ifdef __alpha__
- return dev->hose->dense_mem_base - dev->hose->mem_space->start;
+ return dev->hose->dense_mem_base;
#else
return 0;
#endif
---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] alpha, drm: Update Alpha DRM support
This patch set fixes Alpha-specific support in the DRM code, allowing Radeon KMS and the MGA driver to work properly on Alpha-based machines. Jay Jay Estabrook (3): alpha, drm: Update Alpha DRM support alpha, drm: Cleanup Alpha support in DRM generic code alpha, drm: Remove obsolete Alpha support in MGA DRM code alpha, drm: Add Alpha support to Radeon DRM code drivers/gpu/drm/drm_bufs.c |3 --- drivers/gpu/drm/drm_vm.c|2 +- drivers/gpu/drm/mga/mga_drv.h | 19 --- drivers/gpu/drm/radeon/radeon_ttm.c | 23 +++ 4 files changed, 24 insertions(+), 23 deletions(-) --- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] alpha, drm: Add Alpha support to Radeon DRM code
Alpha needs to have the system bus address for the device's local memory available, so that it can be returned to user-level, where it may be used in an mmap(). So, we make bus.addr hold the ioremap() return for kernel use, and then we can modify bus.base appropriately. Signed-off-by: Jay Estabrook --- drivers/gpu/drm/radeon/radeon_ttm.c | 23 +++ 1 file changed, 23 insertions(+) diff -Naurp a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c --- a/drivers/gpu/drm/radeon/radeon_ttm.c 2011-04-26 23:48:50.0 -0400 +++ b/drivers/gpu/drm/radeon/radeon_ttm.c 2011-05-03 18:24:27.0 -0400 @@ -450,6 +450,29 @@ static int radeon_ttm_io_mem_reserve(str return -EINVAL; mem->bus.base = rdev->mc.aper_base; mem->bus.is_iomem = true; +#ifdef __alpha__ + /* +* Alpha: use bus.addr to hold the ioremap() return, +* so we can modify bus.base below. +*/ + if (mem->placement & TTM_PL_FLAG_WC) + mem->bus.addr = + ioremap_wc(mem->bus.base + mem->bus.offset, + mem->bus.size); + else + mem->bus.addr = + ioremap_nocache(mem->bus.base + mem->bus.offset, + mem->bus.size); + + /* +* Alpha: Take just the bus offset and +* add the hose/domain memory base. +* Then, bus.base can be returned +* for use in an mmap() call. +*/ + mem->bus.base = (mem->bus.base & 0x0UL) + + rdev->ddev->hose->dense_mem_base; +#endif break; default: return -EINVAL; --- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Radeon drm: Hang with posting GPU when PCI card is primary
> [ 10.169900] [drm] radeon kernel modesetting enabled. > [ 10.170270] radeon :02:00.0: enabling device (0080 -> 0083) > [ 10.170816] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 > [ 10.171044] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, > low) -> IRQ 11 > [ 10.172664] [drm] initializing kernel modesetting (RV100 0x1002:0x5159). > [ 10.172897] [drm] register mmio base: 0xFEAF > [ 10.173098] [drm] register mmio size: 65536 > [ 10.273609] [drm] GPU not posted. posting now... Hmm. Added some printk-s (POSTing combios for example) and now it did not hang any more but failed gracefully which is much better. [5.769826] [drm] radeon kernel modesetting enabled. [5.770181] radeon :02:00.0: enabling device (0080 -> 0083) [5.770677] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [5.770903] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 [5.772142] [drm] initializing kernel modesetting (RV100 0x1002:0x5159). [5.772363] [drm] register mmio base: 0xFEAF [5.772529] [drm] register mmio size: 65536 [5.914902] [drm] GPU not posted. posting now... [5.915086] [drm] POSTing combios [5.938458] agpgart-intel :00:00.0: AGP 2.0 bridge [5.938697] agpgart: Couldn't find an AGP VGA controller. [5.938914] radeon :02:00.0: GTT: 64M 0xF800 - 0xFBFF [5.939133] [drm] Generation 1 PCI interface in multifunction mode [5.939352] [drm] Limiting VRAM to one aperture [5.939569] radeon :02:00.0: limiting VRAM to PCI aperture size [5.939792] radeon :02:00.0: VRAM: 128M 0xE800 - 0xEFFF (128M used) [5.940212] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.940425] [drm] Driver supports precise vblank timestamp query. [5.940666] [drm] radeon: irq initialized. [5.941035] [drm] Detected VRAM RAM=128M, BAR=128M [5.941263] [drm] RAM width 64bits SDR [5.941607] [TTM] Zone kernel: Available graphics memory: 257508 kiB. [5.941825] [TTM] Initializing pool allocator. [5.942111] radeon :02:00.0: df650c00 pin failed [5.942351] radeon :02:00.0: Fatal error during GPU init [5.942567] [drm] radeon: finishing device. [5.942783] [drm] radeon: cp finalized [5.943014] [TTM] Trying to take down uninitialized memory manager type 1 [5.943243] [TTM] Finalizing pool allocator. [5.943523] [TTM] Zone kernel: Used memory at exit: 0 kiB. [5.943693] [drm] radeon: ttm finalized [5.944380] radeon :02:00.0: PCI INT A disabled [5.944564] radeon: probe of :02:00.0 failed with error -22 -- Meelis Roos (mroos at ut.ee) http://www.cs.ut.ee/~mroos/
Modeline problem with Radeon KMS
> > So it decides this modeline is usable for the console while it is not. > > Ah, ok. yeah, that mode has a much higher clock than those chips can > handle. Where is that mode even coming from? I don't see it in the > EDID. The attached patch should filter out that mode. It works, thank you! Now the console is switching 256x96 charactest and I can see the console. fbset tells mode "2048x1536" geometry 2048 1536 2048 1536 8 timings 0 0 0 0 0 0 0 accel true rgba 8/0,8/0,8/0,0/0 endmode -- Meelis Roos (mroos at linux.ee)
[PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
On Fri, 2011-06-03 at 12:54 +0200, Sascha Hauer wrote: > The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers. > That is because the framebuffers for each file are in the filp_head > member of struct drm_framebuffer, not in the head member. > > Signed-off-by: Sascha Hauer > --- Looks good, commited to drm-fixes tree. Dave.
[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: > To properly support the various plane formats supported by different > hardware, the kernel must know the pixel format of a framebuffer object. > So add a new ioctl taking a format argument corresponding to a fourcc > name from videodev2.h. I'd rather we don't directly tie things like that, either create a fourcc header that isn't V4L2 or DRM related and use that or generate two headers one with DRM_ and one with V4L2 prefixes. Mainly so we can keep the DRM interface in some way OS agnostic. Dave.
[PATCH 14/15] gma500: nuke the PSB debug stuff
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote: > On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: >> On Thu, 9 Jun 2011 03:10:03 +0200 >> Patrik Jakobsson wrote: >> >> > Hi Alan >> > >> > Just a thought. Shouldn't we use the DRM macros for printing debug info? >> >> Linux has perfectly good printing functions and using them means we can >> use dev_dbg() which supports things like nice runtime switching. > > You mean like the drm debug functions runtime switching? that predated > the kernel ones and nobody ever ported :-) > > Though if psb wants to be different to other drm drivers it can lead the > way, though it'll be a total nightmare for all the people who follow > documentation on how to debug drm drivers using drm.debug=1,2,4,8. for > various code paths. Yes, my concern was about drm.debug and use of all the DRM portability stuff (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...) The portability might not be important at this point but I just wanted to raise the question so I know what is right / wrong. Alan, I've been working on the output code but think I've reached a dead end. I'm up to 2 lines of changes and it's just a big mess. I'm gonna go for slowly fixing up the current code instead. I also got my hands on a laptop with a gma500 so I can test that my changes doesn't break LVDS. Stay tuned. Thanks
[PATCH 14/15] gma500: nuke the PSB debug stuff
> Yes, my concern was about drm.debug and use of all the DRM portability stuff > (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...) > > The portability might not be important at this point but I just wanted to > raise > the question so I know what is right / wrong. The gma500 driver uses a lot of direct Linux services rather than disappearing into the weird world of drm_mm and the like so any portability is going to be a bit of an illusion at best. If someone ports it to another GPL licensed OS then I may have to reconsider a bit, we shall see. > Alan, I've been working on the output code but think I've reached a dead end. > I'm up to 2 lines of changes and it's just a big mess. I'm gonna go for > slowly fixing up the current code instead. I also got my hands on a laptop > with a gma500 so I can test that my changes doesn't break LVDS. Stay tuned. Will do. Got another chunk of patches to fire at Greg shortly and I've now beaten pretty much all of it into passing CodingStyle so hopefully any noise will settle down at that point. Still not ready to leave staging, passing CodingStyle and being clean are not quite the same thing in this case !
[PATCH 14/15] gma500: nuke the PSB debug stuff
> Though if psb wants to be different to other drm drivers it can lead the > way, though it'll be a total nightmare for all the people who follow > documentation on how to debug drm drivers using drm.debug=1,2,4,8. for > various code paths. Actually it seems to work out nicely because you can debug DRM core goings on and driver goings on separately. Also the driver ones can be turned on/off on their own at runtime which is a godsend. As you can imagine I've been testing the debugging a fair bit ! Alan
[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
> > You also don't need a headwer with a complete list of fourcc names in it,
> > that is the half the point of FourCC.
>
> #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
> RGB-3-3-2 */
>
> See that V4L2 and v4l2? I'd rather not have them used in the drm
They are just helpers. The only thing that fourcc is is a 4 byte packed
value of four symbols.
> interface, either a DRM_ variant or a FOURCC_ variant that removes the
> V4L2. Also having it in a different include file to "videodev2.h", so
> yes we can pass FOURCC values but I'd rather we gave people a drm
> specific way to generate them or make a generic set of macros that don't
> include the V4L2 headers.
You need a macro to assemble fourcc codes and that seems to be about it -
so just an equivalent of the v4l2_fourcc macro.
Alan
[PATCH 1/4] drm: add plane support
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
> On Wed, 8 Jun 2011 11:41:17 +0200
> Marcus Lorentzon wrote:
>
>
>> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
>>
>>> On Tue, 7 Jun 2011 13:07:39 -0700
>>> Jesse Barnes wrote:
>>>
>>>
>>>
+/* Planes blend with or override other bits on the CRTC */
+struct drm_mode_set_plane {
+ __u32 plane_id;
+ __u32 crtc_id;
+ __u32 fb_id; /* contains surface format type */
+
+ __u32 crtc_x, crtc_y;
+ __u32 x, y;
+
+ /* FIXME: color key/mask, scaling, z-order, other? */
+};
>>> Forgot to add the scaling factors to this. Would:
>>> __u32 scaling_x; /* fixed 16.16 format */
>>> __u32 scaling_y;
>>> work for people?
>>>
>>>
>> If you want to pan around in zoomed in video/viewfinder/snapshots it
>> might be better to have a fixed 16.16 source rectangle and a integer
>> destination rectangle. That way you can move around the zoomed in source
>> rectangle in small increments and upscale it to destination rectangle
>> (and skip fractions if HW don't support it). For example, if you zoom 4x
>> and have only fixed 16.16 scaling factor, you still get the the integer
>> fb (x, y) position in the top left corner (crtc_x, crtc_y) of the
>> overlay. And when you pan in the overlay, you will have to move source
>> rectangle in 4 destination pixel increments. So what about this instead:
>>
>> __u32 x, y, src_w, src_h; /* fixed 16.16 */
>> __u32 crtc_x, crtc_y, crtc_w, crtc_h;
>>
>> Maybe rename x, y to src_x, src_y? crtc_w/h is needed to define zoom
>> factor (scaling_[wh] = crtc_[wh] / src_[wh]).
>>
>> So the "zoom transform" would be defined by (src_x, src_y, src_w, src_h)
>> => (crtc_x, crtc_y, crtc_w, crtc_h)
>>
>> It also gets rid of how to handle corner cases where scaling factor
>> defines a source area outside source fb. Now you can just say both rect
>> has to be inside crtc/fb. And you can also animate/move/clip a zoomed
>> overlay off screen without picture jumping (fb and display coords don't
>> align when zoomed).
>>
>> Summary, rectangles allow more precise representation of zoom factor,
>> and 16.16 source coords for stable image when moving overlay off screen
>> (clipping) or panning overlay content.
>>
>> BTW. Why not just add "__s32 z;" too? drm_mode_set_plane seems to be
>> plane position setup.
>>
> Yeah, all good points. I was thinking the source info could be mostly
> gleaned from the associated fb, but if you have hw that can source just
> a rect and scale it, passing rects around makes the most sense.
>
> And z-order is a trivial addition, so I have no problem with that. But
> communicating plane blending restrictions (including z-order) still has
> to be done with a separate ioctl. But that should probably be added by
> someone who has crazy hardware and the ability to test it!
>
> Thanks,
>
After a nights sleep I think a better solution to the clipped jumping
image would be to actually allow to position the dest rect outside the
"crtc rect". That way the user never have to calculate any fixed point
position of the source rect in the non zoomed case. Instead the driver
can clip at the best possible position to limit the jumping. Because the
dest rect will always be aligned on integer pixels.
But it might still be worth keeping fixed position for source rect when
doing pan and zoom, to be used by capable HW.
So to allow simpler user code when moving/animating overlay off screen.
It would be good to allow off screen coord for dest rect. That is, make
crtc_[xy] into signed __s32.
Will try to add the commit and the blend ioctl later including tests,
but first I need to finish and push the base KMS driver :)
/BR
/Marcus
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #10 from Harald Judt 2011-06-09 10:36:13 PDT --- Bug 27523 seems similar, but not identical to this one. https://bugs.freedesktop.org/show_bug.cgi?id=27523 -- 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 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #10 from Harald Judt 2011-06-09 10:36:13 PDT --- Bug 27523 seems similar, but not identical to this one. https://bugs.freedesktop.org/show_bug.cgi?id=27523 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)
https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #1 from Ian Romanick 2011-06-09 10:18:17 PDT --- That enum is GL_FRAGMENT_SHADER_ATI. If that driver doesn't support GL_ATI_fragment_shader, and I believe that only the r200 driver does, this is an application bug. I'll leave it to the radeon developers to close this. -- 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
[PATCH] drm/gem: add hooks to notify driver when object handle is created/destroyed
On Thu, 2011-06-09 at 10:24 +1000, skeggsb at gmail.com wrote:
> From: Ben Skeggs
>
> Nouveau is going to use these hooks to map/unmap objects from a client's
> private GPU address space.
Forgot the v2 notes.. inlined below..
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/drm_gem.c | 21 +++--
> include/drm/drmP.h|2 ++
> 2 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 74e4ff5..bad3359 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -210,6 +210,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
> idr_remove(&filp->object_idr, handle);
> spin_unlock(&filp->table_lock);
>
> + if (dev->driver->gem_close_object)
> + dev->driver->gem_close_object(obj, filp);
> drm_gem_object_handle_unreference_unlocked(obj);
This is the only change, moved the call to the driver hook outside of
the spinlock.
Ben.
>
> return 0;
> @@ -226,7 +228,8 @@ drm_gem_handle_create(struct drm_file *file_priv,
> struct drm_gem_object *obj,
> u32 *handlep)
> {
> - int ret;
> + struct drm_device *dev = obj->dev;
> + int ret;
>
> /*
>* Get the user-visible handle using idr.
> @@ -247,6 +250,15 @@ again:
> return ret;
>
> drm_gem_object_handle_reference(obj);
> +
> + if (dev->driver->gem_open_object) {
> + ret = dev->driver->gem_open_object(obj, file_priv);
> + if (ret) {
> + drm_gem_handle_delete(file_priv, *handlep);
> + return ret;
> + }
> + }
> +
> return 0;
> }
> EXPORT_SYMBOL(drm_gem_handle_create);
> @@ -401,7 +413,12 @@ drm_gem_open(struct drm_device *dev, struct drm_file
> *file_private)
> static int
> drm_gem_object_release_handle(int id, void *ptr, void *data)
> {
> + struct drm_file *file_priv = data;
> struct drm_gem_object *obj = ptr;
> + struct drm_device *dev = obj->dev;
> +
> + if (dev->driver->gem_close_object)
> + dev->driver->gem_close_object(obj, file_priv);
>
> drm_gem_object_handle_unreference_unlocked(obj);
>
> @@ -417,7 +434,7 @@ void
> drm_gem_release(struct drm_device *dev, struct drm_file *file_private)
> {
> idr_for_each(&file_private->object_idr,
> - &drm_gem_object_release_handle, NULL);
> + &drm_gem_object_release_handle, file_private);
>
> idr_remove_all(&file_private->object_idr);
> idr_destroy(&file_private->object_idr);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 738b3a5..4912cb7 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -886,6 +886,8 @@ struct drm_driver {
>*/
> int (*gem_init_object) (struct drm_gem_object *obj);
> void (*gem_free_object) (struct drm_gem_object *obj);
> + int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
> + void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
>
> /* vga arb irq handler */
> void (*vgaarb_irq)(struct drm_device *dev, bool state);
[PATCH] drm/gem: add hooks to notify driver when object handle is created/destroyed
From: Ben Skeggs
Nouveau is going to use these hooks to map/unmap objects from a client's
private GPU address space.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/drm_gem.c | 21 +++--
include/drm/drmP.h|2 ++
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 74e4ff5..bad3359 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -210,6 +210,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(&filp->object_idr, handle);
spin_unlock(&filp->table_lock);
+ if (dev->driver->gem_close_object)
+ dev->driver->gem_close_object(obj, filp);
drm_gem_object_handle_unreference_unlocked(obj);
return 0;
@@ -226,7 +228,8 @@ drm_gem_handle_create(struct drm_file *file_priv,
struct drm_gem_object *obj,
u32 *handlep)
{
- int ret;
+ struct drm_device *dev = obj->dev;
+ int ret;
/*
* Get the user-visible handle using idr.
@@ -247,6 +250,15 @@ again:
return ret;
drm_gem_object_handle_reference(obj);
+
+ if (dev->driver->gem_open_object) {
+ ret = dev->driver->gem_open_object(obj, file_priv);
+ if (ret) {
+ drm_gem_handle_delete(file_priv, *handlep);
+ return ret;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_gem_handle_create);
@@ -401,7 +413,12 @@ drm_gem_open(struct drm_device *dev, struct drm_file
*file_private)
static int
drm_gem_object_release_handle(int id, void *ptr, void *data)
{
+ struct drm_file *file_priv = data;
struct drm_gem_object *obj = ptr;
+ struct drm_device *dev = obj->dev;
+
+ if (dev->driver->gem_close_object)
+ dev->driver->gem_close_object(obj, file_priv);
drm_gem_object_handle_unreference_unlocked(obj);
@@ -417,7 +434,7 @@ void
drm_gem_release(struct drm_device *dev, struct drm_file *file_private)
{
idr_for_each(&file_private->object_idr,
-&drm_gem_object_release_handle, NULL);
+&drm_gem_object_release_handle, file_private);
idr_remove_all(&file_private->object_idr);
idr_destroy(&file_private->object_idr);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 738b3a5..4912cb7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -886,6 +886,8 @@ struct drm_driver {
*/
int (*gem_init_object) (struct drm_gem_object *obj);
void (*gem_free_object) (struct drm_gem_object *obj);
+ int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
+ void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
/* vga arb irq handler */
void (*vgaarb_irq)(struct drm_device *dev, bool state);
--
1.7.5.2
[Bug 38089] Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)
https://bugs.freedesktop.org/show_bug.cgi?id=38089 --- Comment #1 from Ian Romanick 2011-06-09 10:18:17 PDT --- That enum is GL_FRAGMENT_SHADER_ATI. If that driver doesn't support GL_ATI_fragment_shader, and I believe that only the r200 driver does, this is an application bug. I'll leave it to the radeon developers to close this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #9 from Harald Judt 2011-06-09 10:13:49 PDT --- > However, it's a bit better now, as it did not happen during normal > desktop usage (till now). I spoke too soon. Problem is still there :-( -- 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 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #9 from Harald Judt 2011-06-09 10:13:49 PDT --- > However, it's a bit better now, as it did not happen during normal > desktop usage (till now). I spoke too soon. Problem is still there :-( -- 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/4] drm: add an fb creation ioctl that takes a pixel format
On Thu, 09 Jun 2011 14:05:59 +1000 Dave Airlie wrote: > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: > > To properly support the various plane formats supported by different > > hardware, the kernel must know the pixel format of a framebuffer object. > > So add a new ioctl taking a format argument corresponding to a fourcc > > name from videodev2.h. > > I'd rather we don't directly tie things like that, either create a > fourcc header that isn't V4L2 or DRM related and use that or generate > two headers one with DRM_ and one with V4L2 prefixes. Mainly so we can > keep the DRM interface in some way OS agnostic. It *is* OS agnostic (it started on the Amiga) You also don't need a headwer with a complete list of fourcc names in it, that is the half the point of FourCC. Alan
[PATCH 14/15] gma500: nuke the PSB debug stuff
On Thu, 9 Jun 2011 03:10:03 +0200 Patrik Jakobsson wrote: > Hi Alan > > Just a thought. Shouldn't we use the DRM macros for printing debug info? Linux has perfectly good printing functions and using them means we can use dev_dbg() which supports things like nice runtime switching.
Re: Radeon drm: Hang with posting GPU when PCI card is primary
> [ 10.169900] [drm] radeon kernel modesetting enabled. > [ 10.170270] radeon :02:00.0: enabling device (0080 -> 0083) > [ 10.170816] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 > [ 10.171044] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, > low) -> IRQ 11 > [ 10.172664] [drm] initializing kernel modesetting (RV100 0x1002:0x5159). > [ 10.172897] [drm] register mmio base: 0xFEAF > [ 10.173098] [drm] register mmio size: 65536 > [ 10.273609] [drm] GPU not posted. posting now... Hmm. Added some printk-s (POSTing combios for example) and now it did not hang any more but failed gracefully which is much better. [5.769826] [drm] radeon kernel modesetting enabled. [5.770181] radeon :02:00.0: enabling device (0080 -> 0083) [5.770677] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [5.770903] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 [5.772142] [drm] initializing kernel modesetting (RV100 0x1002:0x5159). [5.772363] [drm] register mmio base: 0xFEAF [5.772529] [drm] register mmio size: 65536 [5.914902] [drm] GPU not posted. posting now... [5.915086] [drm] POSTing combios [5.938458] agpgart-intel :00:00.0: AGP 2.0 bridge [5.938697] agpgart: Couldn't find an AGP VGA controller. [5.938914] radeon :02:00.0: GTT: 64M 0xF800 - 0xFBFF [5.939133] [drm] Generation 1 PCI interface in multifunction mode [5.939352] [drm] Limiting VRAM to one aperture [5.939569] radeon :02:00.0: limiting VRAM to PCI aperture size [5.939792] radeon :02:00.0: VRAM: 128M 0xE800 - 0xEFFF (128M used) [5.940212] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.940425] [drm] Driver supports precise vblank timestamp query. [5.940666] [drm] radeon: irq initialized. [5.941035] [drm] Detected VRAM RAM=128M, BAR=128M [5.941263] [drm] RAM width 64bits SDR [5.941607] [TTM] Zone kernel: Available graphics memory: 257508 kiB. [5.941825] [TTM] Initializing pool allocator. [5.942111] radeon :02:00.0: df650c00 pin failed [5.942351] radeon :02:00.0: Fatal error during GPU init [5.942567] [drm] radeon: finishing device. [5.942783] [drm] radeon: cp finalized [5.943014] [TTM] Trying to take down uninitialized memory manager type 1 [5.943243] [TTM] Finalizing pool allocator. [5.943523] [TTM] Zone kernel: Used memory at exit: 0 kiB. [5.943693] [drm] radeon: ttm finalized [5.944380] radeon :02:00.0: PCI INT A disabled [5.944564] radeon: probe of :02:00.0 failed with error -22 -- Meelis Roos (mr...@ut.ee) http://www.cs.ut.ee/~mroos/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #8 from almos 2011-06-09 07:59:43 PDT --- (In reply to comment #6) > > I don't consider Hyper-Z ready yet but thanks for testing it. > > It is enabled by default now, is it by accident? Perhaps you mean that it always reports this? r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: NO It used to mean that those features are enabled, but now it means that those are available in HW. Now if hyperz is enabled, these are printed: radeon: Acquired Hyper-Z. radeon: Released Hyper-Z. -- 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 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #8 from almos 2011-06-09 07:59:43 PDT --- (In reply to comment #6) > > I don't consider Hyper-Z ready yet but thanks for testing it. > > It is enabled by default now, is it by accident? Perhaps you mean that it always reports this? r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: NO It used to mean that those features are enabled, but now it means that those are available in HW. Now if hyperz is enabled, these are printed: radeon: Acquired Hyper-Z. radeon: Released Hyper-Z. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #7 from Marek Olšák 2011-06-09 07:21:05 PDT --- (In reply to comment #6) > > I don't consider Hyper-Z ready yet but thanks for testing it. > > It is enabled by default now, is it by accident? It's disabled. There are some annoying bugs and I have no clue how to fix them. -- 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 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #7 from Marek Ol??k 2011-06-09 07:21:05 PDT --- (In reply to comment #6) > > I don't consider Hyper-Z ready yet but thanks for testing it. > > It is enabled by default now, is it by accident? It's disabled. There are some annoying bugs and I have no clue how to fix them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37168] Regression: Kernel hard-lock when running Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=37168 Sven Arvidsson changed: What|Removed |Added CC||s...@whiz.se --- Comment #5 from Sven Arvidsson 2011-06-09 06:57:06 PDT --- I tried to reproduce this on my 5670, but couldn't. I don't get a memory leak or a hard lock, instead the viewer (tried both SL and Imprudence) segfaults after a short while. This is with current git master, with 7.10 everything seems to be working. I will try to bisect and file a new bug in case it's not the same problem. -- 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 37168] Regression: Kernel hard-lock when running Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=37168 Sven Arvidsson changed: What|Removed |Added CC||sa at whiz.se --- Comment #5 from Sven Arvidsson 2011-06-09 06:57:06 PDT --- I tried to reproduce this on my 5670, but couldn't. I don't get a memory leak or a hard lock, instead the viewer (tried both SL and Imprudence) segfaults after a short while. This is with current git master, with 7.10 everything seems to be working. I will try to bisect and file a new bug in case it's not the same problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37032] DRM_RADEON=m with CONFIG_FB=y fails
https://bugzilla.kernel.org/show_bug.cgi?id=37032 Andrew Morton changed: What|Removed |Added CC||akpm at linux-foundation.org Component|Configuration |Video(DRI - non Intel) AssignedTo|other_configuration at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org Product|Other |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Re: [PATCH 14/15] gma500: nuke the PSB debug stuff
> Yes, my concern was about drm.debug and use of all the DRM portability stuff > (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...) > > The portability might not be important at this point but I just wanted to > raise > the question so I know what is right / wrong. The gma500 driver uses a lot of direct Linux services rather than disappearing into the weird world of drm_mm and the like so any portability is going to be a bit of an illusion at best. If someone ports it to another GPL licensed OS then I may have to reconsider a bit, we shall see. > Alan, I've been working on the output code but think I've reached a dead end. > I'm up to 2 lines of changes and it's just a big mess. I'm gonna go for > slowly fixing up the current code instead. I also got my hands on a laptop > with a gma500 so I can test that my changes doesn't break LVDS. Stay tuned. Will do. Got another chunk of patches to fire at Greg shortly and I've now beaten pretty much all of it into passing CodingStyle so hopefully any noise will settle down at that point. Still not ready to leave staging, passing CodingStyle and being clean are not quite the same thing in this case ! ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/15] gma500: nuke the PSB debug stuff
> Though if psb wants to be different to other drm drivers it can lead the > way, though it'll be a total nightmare for all the people who follow > documentation on how to debug drm drivers using drm.debug=1,2,4,8. for > various code paths. Actually it seems to work out nicely because you can debug DRM core goings on and driver goings on separately. Also the driver ones can be turned on/off on their own at runtime which is a godsend. As you can imagine I've been testing the debugging a fair bit ! Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
> > You also don't need a headwer with a complete list of fourcc names in it,
> > that is the half the point of FourCC.
>
> #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
> RGB-3-3-2 */
>
> See that V4L2 and v4l2? I'd rather not have them used in the drm
They are just helpers. The only thing that fourcc is is a 4 byte packed
value of four symbols.
> interface, either a DRM_ variant or a FOURCC_ variant that removes the
> V4L2. Also having it in a different include file to "videodev2.h", so
> yes we can pass FOURCC values but I'd rather we gave people a drm
> specific way to generate them or make a generic set of macros that don't
> include the V4L2 headers.
You need a macro to assemble fourcc codes and that seems to be about it -
so just an equivalent of the v4l2_fourcc macro.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/15] gma500: nuke the PSB debug stuff
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote: > On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: >> On Thu, 9 Jun 2011 03:10:03 +0200 >> Patrik Jakobsson wrote: >> >> > Hi Alan >> > >> > Just a thought. Shouldn't we use the DRM macros for printing debug info? >> >> Linux has perfectly good printing functions and using them means we can >> use dev_dbg() which supports things like nice runtime switching. > > You mean like the drm debug functions runtime switching? that predated > the kernel ones and nobody ever ported :-) > > Though if psb wants to be different to other drm drivers it can lead the > way, though it'll be a total nightmare for all the people who follow > documentation on how to debug drm drivers using drm.debug=1,2,4,8. for > various code paths. Yes, my concern was about drm.debug and use of all the DRM portability stuff (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...) The portability might not be important at this point but I just wanted to raise the question so I know what is right / wrong. Alan, I've been working on the output code but think I've reached a dead end. I'm up to 2 lines of changes and it's just a big mess. I'm gonna go for slowly fixing up the current code instead. I also got my hands on a laptop with a gma500 so I can test that my changes doesn't break LVDS. Stay tuned. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Modeline problem with Radeon KMS
> > So it decides this modeline is usable for the console while it is not. > > Ah, ok. yeah, that mode has a much higher clock than those chips can > handle. Where is that mode even coming from? I don't see it in the > EDID. The attached patch should filter out that mode. It works, thank you! Now the console is switching 256x96 charactest and I can see the console. fbset tells mode "2048x1536" geometry 2048 1536 2048 1536 8 timings 0 0 0 0 0 0 0 accel true rgba 8/0,8/0,8/0,0/0 endmode -- Meelis Roos (mr...@linux.ee) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #6 from Fabio Pedretti 2011-06-09 04:37:34 PDT --- > I don't consider Hyper-Z ready yet but thanks for testing it. It is enabled by default now, is it by accident? -- 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 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #6 from Fabio Pedretti 2011-06-09 04:37:34 PDT --- > I don't consider Hyper-Z ready yet but thanks for testing it. It is enabled by default now, is it by accident? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #17 from Henri Verbeet 2011-06-09 04:30:29 PDT --- I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to Wine first for that to work. -- 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 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #17 from Henri Verbeet 2011-06-09 04:30:29 PDT --- I.e., you'd need to apply http://bugs2.winehq.org/attachment.cgi?id=35068 to Wine first for that to work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #16 from Henri Verbeet 2011-06-09 04:27:59 PDT --- (In reply to comment #15) > Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? > > So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod" > would cause it to fall back to 2.0? We enabled SM3 if ARB_shader_texture_lod is present, but it's not currently a requirement for SM3. I'm seriously considering changing that, but currently disabling ARB_shader_texture_lod doesn't necessarily disable SM3. -- 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 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #16 from Henri Verbeet 2011-06-09 04:27:59 PDT --- (In reply to comment #15) > Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? > > So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod" > would cause it to fall back to 2.0? We enabled SM3 if ARB_shader_texture_lod is present, but it's not currently a requirement for SM3. I'm seriously considering changing that, but currently disabling ARB_shader_texture_lod doesn't necessarily disable SM3. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #15 from Sven Arvidsson 2011-06-09 04:02:32 PDT --- Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod" would cause it to fall back to 2.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 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #15 from Sven Arvidsson 2011-06-09 04:02:32 PDT --- Wine checks for ARB_shader_texture_lod to enable SM3.0 now, doesn't it? So using something like MESA_EXTENSION_OVERRIDE="-GL_ARB_shader_texture_lod" would cause it to fall back to 2.0? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #14 from Henri Verbeet 2011-06-09 03:57:31 PDT --- (In reply to comment #10) > Is there a way to disable the shader model 3.0 in Wine/DX9? Not at the moment, but I'm considering adding a registry key to limit the maximum exposed shader model. -- 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 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #14 from Henri Verbeet 2011-06-09 03:57:31 PDT --- (In reply to comment #10) > Is there a way to disable the shader model 3.0 in Wine/DX9? Not at the moment, but I'm considering adding a registry key to limit the maximum exposed shader model. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
On Thu, 2011-06-09 at 09:21 +0100, Alan Cox wrote:
> On Thu, 09 Jun 2011 14:05:59 +1000
> Dave Airlie wrote:
>
> > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote:
> > > To properly support the various plane formats supported by different
> > > hardware, the kernel must know the pixel format of a framebuffer object.
> > > So add a new ioctl taking a format argument corresponding to a fourcc
> > > name from videodev2.h.
> >
> > I'd rather we don't directly tie things like that, either create a
> > fourcc header that isn't V4L2 or DRM related and use that or generate
> > two headers one with DRM_ and one with V4L2 prefixes. Mainly so we can
> > keep the DRM interface in some way OS agnostic.
>
> It *is* OS agnostic (it started on the Amiga)
>
> You also don't need a headwer with a complete list of fourcc names in it,
> that is the half the point of FourCC.
#define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
RGB-3-3-2 */
See that V4L2 and v4l2? I'd rather not have them used in the drm
interface, either a DRM_ variant or a FOURCC_ variant that removes the
V4L2. Also having it in a different include file to "videodev2.h", so
yes we can pass FOURCC values but I'd rather we gave people a drm
specific way to generate them or make a generic set of macros that don't
include the V4L2 headers.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/15] gma500: nuke the PSB debug stuff
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote: > On Thu, 9 Jun 2011 03:10:03 +0200 > Patrik Jakobsson wrote: > > > Hi Alan > > > > Just a thought. Shouldn't we use the DRM macros for printing debug info? > > Linux has perfectly good printing functions and using them means we can > use dev_dbg() which supports things like nice runtime switching. You mean like the drm debug functions runtime switching? that predated the kernel ones and nobody ever ported :-) Though if psb wants to be different to other drm drivers it can lead the way, though it'll be a total nightmare for all the people who follow documentation on how to debug drm drivers using drm.debug=1,2,4,8. for various code paths. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #13 from Marek Olšák 2011-06-09 03:38:24 PDT --- (In reply to comment #12) > (In reply to comment #10) > > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 > > error messages seem to be unfixable hardware limitations. > OK, but why does it hardlock the kernel? No idea. > > As I understand section 7.5.5 of Radeon R5xx Acceleration (page 77), r3xx and > r4xx do support loops. I'm confused. There are some loops in vertex shaders, but they're so oversimplified that implementing GLSL loops with that is impossible and we haven't been able to make it work even for simple cases anyway. Please attach a new log with RADEON_DEBUG=vp -- 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 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #13 from Marek Ol??k 2011-06-09 03:38:24 PDT --- (In reply to comment #12) > (In reply to comment #10) > > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 > > error messages seem to be unfixable hardware limitations. > OK, but why does it hardlock the kernel? No idea. > > As I understand section 7.5.5 of Radeon R5xx Acceleration (page 77), r3xx and > r4xx do support loops. I'm confused. There are some loops in vertex shaders, but they're so oversimplified that implementing GLSL loops with that is impossible and we haven't been able to make it work even for simple cases anyway. Please attach a new log with RADEON_DEBUG=vp -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 14/15] gma500: nuke the PSB debug stuff
Hi Alan
Just a thought. Shouldn't we use the DRM macros for printing debug info?
-Patrik
On Wed, Jun 8, 2011 at 12:15 PM, Alan Cox wrote:
> From: Alan Cox
>
> Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
> drivers if and when we need debug on stuff.
>
> Signed-off-by: Alan Cox
> ---
>
> ?drivers/staging/gma500/mrst_crtc.c ? ? ? ? ?| ? 23 ++
> ?drivers/staging/gma500/mrst_lvds.c ? ? ? ? ?| ? 12 +--
> ?drivers/staging/gma500/psb_bl.c ? ? ? ? ? ? | ? ?8 --
> ?drivers/staging/gma500/psb_drv.c ? ? ? ? ? ?| ? 33 +++--
> ?drivers/staging/gma500/psb_drv.h ? ? ? ? ? ?| ? 96 +++---
> ?drivers/staging/gma500/psb_fb.c ? ? ? ? ? ? | ? 34 +
> ?drivers/staging/gma500/psb_gem.c ? ? ? ? ? ?| ? ?6 +-
> ?drivers/staging/gma500/psb_gtt.c ? ? ? ? ? ?| ? ?6 +-
> ?drivers/staging/gma500/psb_intel_bios.c ? ? | ? 17 +
> ?drivers/staging/gma500/psb_intel_display.c ?| ? 99
> +++
> ?drivers/staging/gma500/psb_intel_lvds.c ? ? | ? 53 ++
> ?drivers/staging/gma500/psb_intel_opregion.c | ? ?7 --
> ?drivers/staging/gma500/psb_intel_sdvo.c ? ? | ? 34 -
> ?drivers/staging/gma500/psb_irq.c ? ? ? ? ? ?| ? 33 ++---
> ?14 files changed, 87 insertions(+), 374 deletions(-)
>
> diff --git a/drivers/staging/gma500/mrst_crtc.c
> b/drivers/staging/gma500/mrst_crtc.c
> index fd97c80..fb9f2a2 100644
> --- a/drivers/staging/gma500/mrst_crtc.c
> +++ b/drivers/staging/gma500/mrst_crtc.c
> @@ -103,7 +103,7 @@ static const struct mrst_limit_t *mrst_limit(struct
> drm_crtc *crtc)
> ? ? ? ? ? ? ? ?}
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?limit = NULL;
> - ? ? ? ? ? ? ? PSB_DEBUG_ENTRY("mrst_limit Wrong display type.\n");
> + ? ? ? ? ? ? ? dev_err(dev->dev, "mrst_limit Wrong display type.\n");
> ? ? ? ?}
>
> ? ? ? ?return limit;
> @@ -117,7 +117,7 @@ static void mrst_clock(int refclk, struct mrst_clock_t
> *clock)
>
> ?void mrstPrintPll(char *prefix, struct mrst_clock_t *clock)
> ?{
> - ? ? ? PSB_DEBUG_ENTRY("%s: dotclock = %d, ?m = %d, p1 = %d.\n",
> + ? ? ? pr_debug("%s: dotclock = %d, ?m = %d, p1 = %d.\n",
> ? ? ? ? ? ? prefix, clock->dot, clock->m, clock->p1);
> ?}
>
> @@ -149,8 +149,7 @@ mrstFindBestPLL(struct drm_crtc *crtc, int target, int
> refclk,
> ? ? ? ? ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
> - ? ? ? DRM_DEBUG("mrstFindBestPLL err = %d.\n", err);
> -
> + ? ? ? dev_dbg(crtc->dev->dev, "mrstFindBestPLL err = %d.\n", err);
> ? ? ? ?return err != target;
> ?}
>
> @@ -172,8 +171,6 @@ static void mrst_crtc_dpms(struct drm_crtc *crtc, int
> mode)
> ? ? ? ?u32 temp;
> ? ? ? ?bool enabled;
>
> - ? ? ? PSB_DEBUG_ENTRY("mode = %d, pipe = %d\n", mode, pipe);
> -
> ? ? ? ?if (!gma_power_begin(dev, true))
> ? ? ? ? ? ? ? ?return;
>
> @@ -320,8 +317,6 @@ static int mrst_crtc_mode_set(struct drm_crtc *crtc,
> ? ? ? ?uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
> ? ? ? ?struct drm_encoder *encoder;
>
> - ? ? ? PSB_DEBUG_ENTRY("pipe = 0x%x\n", pipe);
> -
> ? ? ? ?if (!gma_power_begin(dev, true))
> ? ? ? ? ? ? ? ?return 0;
>
> @@ -446,10 +441,9 @@ static int mrst_crtc_mode_set(struct drm_crtc *crtc,
> ? ? ? ?ok = mrstFindBestPLL(crtc, adjusted_mode->clock, refclk, &clock);
>
> ? ? ? ?if (!ok) {
> - ? ? ? ? ? ? ? PSB_DEBUG_ENTRY(
> - ? ? ? ? ? ? ? ? ? ? ? "mrstFindBestPLL fail in mrst_crtc_mode_set.\n");
> + ? ? ? ? ? ? ? dev_dbg(dev->dev, "mrstFindBestPLL fail in
> mrst_crtc_mode_set.\n");
> ? ? ? ?} else {
> - ? ? ? ? ? ? ? PSB_DEBUG_ENTRY("mrst_crtc_mode_set pixel clock = %d,"
> + ? ? ? ? ? ? ? dev_dbg(dev->dev, "mrst_crtc_mode_set pixel clock = %d,"
> ? ? ? ? ? ? ? ? ? ? ? ? "m = %x, p1 = %x.\n", clock.dot, clock.m,
> ? ? ? ? ? ? ? ? ? ? ? ? clock.p1);
> ? ? ? ?}
> @@ -540,11 +534,9 @@ int mrst_pipe_set_base(struct drm_crtc *crtc,
> ? ? ? ?u32 dspcntr;
> ? ? ? ?int ret = 0;
>
> - ? ? ? PSB_DEBUG_ENTRY("\n");
> -
> ? ? ? ?/* no fb bound */
> ? ? ? ?if (!crtc->fb) {
> - ? ? ? ? ? ? ? DRM_DEBUG("No FB bound\n");
> + ? ? ? ? ? ? ? dev_dbg(dev->dev, "No FB bound\n");
> ? ? ? ? ? ? ? ?return 0;
> ? ? ? ?}
>
> @@ -574,13 +566,12 @@ int mrst_pipe_set_base(struct drm_crtc *crtc,
> ? ? ? ? ? ? ? ?dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?default:
> - ? ? ? ? ? ? ? DRM_ERROR("Unknown color depth\n");
> + ? ? ? ? ? ? ? dev_err(dev->dev, "Unknown color depth\n");
> ? ? ? ? ? ? ? ?ret = -EINVAL;
> ? ? ? ? ? ? ? ?goto pipe_set_base_exit;
> ? ? ? ?}
> ? ? ? ?REG_WRITE(dspcntr_reg, dspcntr);
>
> - ? ? ? DRM_DEBUG("Writing base %08lX %08lX %d %d\n", start, offset, x, y);
> ? ? ? ?if (0 /* FIXMEAC - check what PSB needs */) {
> ? ? ? ? ? ? ? ?REG_WRITE(dspbase, offset);
> ? ? ? ? ? ? ? ?REG_READ(dspbase);
> diff --git a/drivers/staging/gma500/mrst_lvds.c
> b/drivers/staging/gma500/mrst_lvds.c
> index 22ea00e..aac80cc 100644
> --- a/drivers/staging/gma500/mrst_lvds.c
> +++ b/drivers/staging/gma500/mrst_lvds.c
> @@ -47,7 +47,6 @@ static void mrst_lvds_set_power(struct drm_device *dev,
> ?{
> ? ? ? ?u32 pp_status;
> ?
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #12 from almos 2011-06-09 02:31:46 PDT --- (In reply to comment #10) > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 > error messages seem to be unfixable hardware limitations. OK, but why does it hardlock the kernel? As I understand section 7.5.5 of Radeon R5xx Acceleration (page 77), r3xx and r4xx do support loops. I'm confused. > > Is there a way to disable the shader model 3.0 in Wine/DX9? The shader model > 2.0, which the hardware was designed for, doesn't have loops, and HL2 must > support that (otherwise it wouldn't work on Windows either). I don't think wine advertises SM3.0, as s.t.a.l.k.e.r. shadow of Chernobyl doesn't let me choose dynamic lighting, which is expected (BTW it's almost platinum quality with wine 1.3.20 and mesa 7.11-dev, great work :) Isn't there a d3dwinfo tool that does the same as glxinfo? -- 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 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #12 from almos 2011-06-09 02:31:46 PDT --- (In reply to comment #10) > The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 > error messages seem to be unfixable hardware limitations. OK, but why does it hardlock the kernel? As I understand section 7.5.5 of Radeon R5xx Acceleration (page 77), r3xx and r4xx do support loops. I'm confused. > > Is there a way to disable the shader model 3.0 in Wine/DX9? The shader model > 2.0, which the hardware was designed for, doesn't have loops, and HL2 must > support that (otherwise it wouldn't work on Windows either). I don't think wine advertises SM3.0, as s.t.a.l.k.e.r. shadow of Chernobyl doesn't let me choose dynamic lighting, which is expected (BTW it's almost platinum quality with wine 1.3.20 and mesa 7.11-dev, great work :) Isn't there a d3dwinfo tool that does the same as glxinfo? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH 1/4] drm: add plane support
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzon wrote:
On 06/07/2011 11:01 PM, Jesse Barnes wrote:
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
+/* Planes blend with or override other bits on the CRTC */
+struct drm_mode_set_plane {
+ __u32 plane_id;
+ __u32 crtc_id;
+ __u32 fb_id; /* contains surface format type */
+
+ __u32 crtc_x, crtc_y;
+ __u32 x, y;
+
+ /* FIXME: color key/mask, scaling, z-order, other? */
+};
Forgot to add the scaling factors to this. Would:
__u32 scaling_x; /* fixed 16.16 format */
__u32 scaling_y;
work for people?
If you want to pan around in zoomed in video/viewfinder/snapshots it
might be better to have a fixed 16.16 source rectangle and a integer
destination rectangle. That way you can move around the zoomed in source
rectangle in small increments and upscale it to destination rectangle
(and skip fractions if HW don't support it). For example, if you zoom 4x
and have only fixed 16.16 scaling factor, you still get the the integer
fb (x, y) position in the top left corner (crtc_x, crtc_y) of the
overlay. And when you pan in the overlay, you will have to move source
rectangle in 4 destination pixel increments. So what about this instead:
__u32 x, y, src_w, src_h; /* fixed 16.16 */
__u32 crtc_x, crtc_y, crtc_w, crtc_h;
Maybe rename x, y to src_x, src_y? crtc_w/h is needed to define zoom
factor (scaling_[wh] = crtc_[wh] / src_[wh]).
So the "zoom transform" would be defined by (src_x, src_y, src_w, src_h)
=> (crtc_x, crtc_y, crtc_w, crtc_h)
It also gets rid of how to handle corner cases where scaling factor
defines a source area outside source fb. Now you can just say both rect
has to be inside crtc/fb. And you can also animate/move/clip a zoomed
overlay off screen without picture jumping (fb and display coords don't
align when zoomed).
Summary, rectangles allow more precise representation of zoom factor,
and 16.16 source coords for stable image when moving overlay off screen
(clipping) or panning overlay content.
BTW. Why not just add "__s32 z;" too? drm_mode_set_plane seems to be
plane position setup.
Yeah, all good points. I was thinking the source info could be mostly
gleaned from the associated fb, but if you have hw that can source just
a rect and scale it, passing rects around makes the most sense.
And z-order is a trivial addition, so I have no problem with that. But
communicating plane blending restrictions (including z-order) still has
to be done with a separate ioctl. But that should probably be added by
someone who has crazy hardware and the ability to test it!
Thanks,
After a nights sleep I think a better solution to the clipped jumping
image would be to actually allow to position the dest rect outside the
"crtc rect". That way the user never have to calculate any fixed point
position of the source rect in the non zoomed case. Instead the driver
can clip at the best possible position to limit the jumping. Because the
dest rect will always be aligned on integer pixels.
But it might still be worth keeping fixed position for source rect when
doing pan and zoom, to be used by capable HW.
So to allow simpler user code when moving/animating overlay off screen.
It would be good to allow off screen coord for dest rect. That is, make
crtc_[xy] into signed __s32.
Will try to add the commit and the blend ioctl later including tests,
but first I need to finish and push the base KMS driver :)
/BR
/Marcus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 almos changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #8 from almos 2011-06-09 01:53:24 PDT --- Fix confirmed. Thanks. -- 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 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 almos changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #8 from almos 2011-06-09 01:53:24 PDT --- Fix confirmed. Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
On Thu, 09 Jun 2011 14:05:59 +1000 Dave Airlie wrote: > On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: > > To properly support the various plane formats supported by different > > hardware, the kernel must know the pixel format of a framebuffer object. > > So add a new ioctl taking a format argument corresponding to a fourcc > > name from videodev2.h. > > I'd rather we don't directly tie things like that, either create a > fourcc header that isn't V4L2 or DRM related and use that or generate > two headers one with DRM_ and one with V4L2 prefixes. Mainly so we can > keep the DRM interface in some way OS agnostic. It *is* OS agnostic (it started on the Amiga) You also don't need a headwer with a complete list of fourcc names in it, that is the half the point of FourCC. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/15] gma500: nuke the PSB debug stuff
On Thu, 9 Jun 2011 03:10:03 +0200 Patrik Jakobsson wrote: > Hi Alan > > Just a thought. Shouldn't we use the DRM macros for printing debug info? Linux has perfectly good printing functions and using them means we can use dev_dbg() which supports things like nice runtime switching. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
