[Bug 43954] Some textures are not correctly rendered on HD 6950

https://bugs.freedesktop.org/show_bug.cgi?id=43954 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 38173] DXT3 and DXT5 broken on Cayman gpu

https://bugs.freedesktop.org/show_bug.cgi?id=38173 Alexandre Demers changed: What|Removed |Added CC||alexandre.f.demers at gmail.co

[r600g] ATI Radeon HD6950, dual monitor and power profile

Am 20.12.2011 21:20, schrieb Adam Jackson: > On 12/20/11 1:38 PM, Harald Judt wrote: >> Hi, >> >> When using more than one monitor, the card uses higher clocks than in >> single-monitor mode and low-power profile. As a subjectively negative >> side-effect, the fan on the card starts making more

[RFC PATCH 1/8] drm: Add drm_format_num_planes() utility function

On Tue, Dec 20, 2011 at 7:55 PM, Rob Clark wrote: > On Mon, Dec 19, 2011 at 4:33 PM, ? wrote: >> From: Ville Syrj?l? >> >> This function returns the number of planes used by a specific pixel >> format. > > btw, I end up with a very similar util fxn in omapdrm driver.. would > be nice to have

[RFC v3 0/2] Introduce DMA buffer sharing mechanism

On Mon, Dec 19, 2011 at 02:03:28PM +0530, Sumit Semwal wrote: > Hello Everyone, > > This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the > changelog below. > > Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the > need to have a common mechanism

[PATCH libdrm 3/3] libdrm: Fix AddFB2 memcpy() size

From: Ville Syrj?l? Using sizeof() on a function parameter with an array type does not work. sizeof() treats such parameters as pointers. Signed-off-by: Ville Syrj?l? --- xf86drmMode.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH libdrm 2/3] libdrm: Add drmModeFreePlaneResources()

From: Ville Syrj?l? This function was missing. Signed-off-by: Ville Syrj?l? --- xf86drmMode.c |9 + xf86drmMode.h |1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/xf86drmMode.c b/xf86drmMode.c index e67ed4a..473e734 100644

[PATCH libdrm 1/3] libdrm: Plug memory leaks

From: Ville Syrj?l? drmModeFreeResources() always leaked some memory. drmModeGetPlaneResources() and drmModeGetPlane() leaked in one error path. Signed-off-by: Ville Syrj?l? --- xf86drmMode.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff

[Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

>> >> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the >> changelog below. >> >> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the >> need to have a common mechanism to share memory buffers across different >> devices - ARM, video hardware,

[r600g] ATI Radeon HD6950, dual monitor and power profile

Hi, When using more than one monitor, the card uses higher clocks than in single-monitor mode and low-power profile. As a subjectively negative side-effect, the fan on the card starts making more noise. Other cards I used before had no problem with staying quiet even when more monitors were

high_memory address in /proc/dri/*/vma

On Tue, Dec 20, 2011 at 05:32:13PM +0100, Daniel Vetter wrote: > On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote: > > [Re-sent to the right address, I hope.] > > > > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not > > leak kernel addresses via

[Bug 43964] Rendering is distorded in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964 --- Comment #3 from Ian Romanick 2011-12-20 10:40:59 PST --- (In reply to comment #0) > CG: 'PostEffect_Motion_fp.cg' using profile: 'arbfp1' > CG ERROR : "The compile returned an error." > --- >

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 10:41:45AM -0600, Rob Clark wrote: > On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote: > > On Monday 19 December 2011, Semwal, Sumit wrote: > >> I didn't see a consensus on whether dma_buf should enforce some form > >> of serialization within the API - so atleast for

[PATCH 1/3] drm/omap: drm API update: addfb2

On Tue, Dec 20, 2011 at 5:30 PM, Ville Syrj?l? wrote: > On Tue, Dec 20, 2011 at 04:58:51PM -0600, Rob Clark wrote: >> +static const struct format formats[] = { >> + ? ? /* 16bpp [A]RGB: */ >> + ? ? { OMAP_DSS_COLOR_RGB16, ? ? ? DRM_FORMAT_RGB565, ? {{2, 1}}, false }, >> /* RGB16-565 */ >> + ? ?

high_memory address in /proc/dri/*/vma

On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote: > [Re-sent to the right address, I hope.] > > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not > leak kernel addresses via /proc/dri/*/vma") you changed the logging of > high_memory: > > - seq_printf(m,

[PATCH 3/3] drm/omap: multiplanar and YUV support

From: Rob Clark Add support in framebuffer objects for other color formats and multi- planar YUV (NV12). Since this requires changing the API between the plane and fb for getting scanout information (paddr, etc), take advantage of the opportunity and put in place a way to allow

[PATCH 2/3] drm/omap: add drm_plane support

From: Rob Clark Because framebuffer layer and overlay scanout video pipes are basically thing in OMAP display subsystem (the only difference being that the first video pipe does not support scaling or YUV formats), much of the CRTC code is pulled into the plane implementation, and a

[PATCH 1/3] drm/omap: drm API update: addfb2

From: Rob Clark Update to reflect changes in: "drm: add an fb creation ioctl that takes a pixel format v5" Signed-off-by: Rob Clark --- drivers/staging/omapdrm/omap_drv.h | 30 +- drivers/staging/omapdrm/omap_fb.c| 103 ++

[PATCH 0/3] drm/omap: updates for addfb2 and plane support

From: Rob Clark The first patch updates omapdrm for API changes introduced when addfb2 support (for multi-planar fb's) was added (in drm-next). The next patch adds drm plane (overlay) support, with CRTCs using private plane objects to avoid code duplication between the CRTC and

[PATCH] drm/omap: GEM, deal with cache

From: Rob Clark Uncached/writecombine buffers need to be clean before creating uc/wc userspace mappings, lest dirty cache lines fall down and corrupt the contents of the buffer. Signed-off-by: Rob Clark --- drivers/staging/omapdrm/omap_gem.c | 30 ++

[r600g] ATI Radeon HD6950, dual monitor and power profile

On Tue, Dec 20, 2011 at 4:19 PM, Harald Judt wrote: > Am 20.12.2011 21:20, schrieb Adam Jackson: >> >> On 12/20/11 1:38 PM, Harald Judt wrote: >>> >>> Hi, >>> >>> When using more than one monitor, the card uses higher clocks than in >>> single-monitor mode and low-power profile. As a subjectively

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell wrote: > > One of the goals of this project is to unify the fragmented space of the > ARM SoC memory managers so that each vendor doesn't implement their own, > and they can all be closer to mainline. That is a very good objective. > I fear that

[Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie wrote: >>> >>> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the >>> changelog below. >>> >>> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the >>> need to have a common mechanism to share memory

[PATCH RESEND] vmwgfx: fix incorrect vram size check in vmw_kms_fb_create()

The previous commit didn't correctly fix the integer overflow issue. http://git.kernel.org/linus/e133e737 - unsigned int required_size; + u64 required_size; ... required_size = mode_cmd->pitch * mode_cmd->height; - if (unlikely(required_size >

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Monday 19 December 2011, Semwal, Sumit wrote: > I didn't see a consensus on whether dma_buf should enforce some form > of serialization within the API - so atleast for v1 of dma-buf, I > propose to 'not' impose a restriction, and we can tackle it (add new > ops or enforce as design?) whenever

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tuesday 20 December 2011, Sakari Ailus wrote: > (I'm jumping into the discussion in the middle, and might miss something > that has already been talked about. I still hope what I'm about to say is > relevant. :-)) It certainly is relevant. > In subsystems such as V4L2 where drivers deal with

[r600g] ATI Radeon HD6950, dual monitor and power profile

On 12/20/11 1:38 PM, Harald Judt wrote: > Hi, > > When using more than one monitor, the card uses higher clocks than in > single-monitor mode and low-power profile. As a subjectively negative > side-effect, the fan on the card starts making more noise. Other cards I > used before had no problem

[PATCH] drm/edid: Try harder to fix up broken headers

On 12/7/11 6:26 PM, Adam Jackson wrote: > There's no reason to force the first byte to be correct if we're already > scoring how correct the header is. Don't use this. The 00 check is needed to make sure we only attempt the header fixup on the zeroth block (not extensions). - ajax

[RFC PATCH 1/8] drm: Add drm_format_num_planes() utility function

On Mon, Dec 19, 2011 at 4:33 PM, wrote: > From: Ville Syrj?l? > > This function returns the number of planes used by a specific pixel > format. btw, I end up with a very similar util fxn in omapdrm driver.. would be nice to have this in core to avoid duplicating in every driver supporting

[PATCH] fixes to drm-next - TTM DMA code (v1)

On Mon, Dec 19, 2011 at 08:51:15PM +0100, Thomas Hellstrom wrote: > On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote: > >On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote: > >>On 12/13/2011 05:07 PM, Jerome Glisse wrote: > >>>On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad

[Bug 43954] Some textures are not correctly rendered on HD 6950

https://bugs.freedesktop.org/show_bug.cgi?id=43954 --- Comment #1 from Michel D?nzer 2011-12-20 03:52:48 PST --- Could be bug 38173. Does it work better with the environment variable MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_compression_s3tc ? -- Configure bugmail:

[PATCH] drm/radeon/kms: don't use 0 bpc for adjusting hdmi clock

From: Dave Airlie If the bpc is set from the connector is 0, we then use it later to adjust in a special case the HDMI pixel clock, however if the bpc is 0, we end up passing a 0 pixel clock into the code. I'm not sure if this is the correct answer or if we should avoid the

[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote: > This is the first step in defining a dma buffer sharing mechanism. > > A new buffer object dma_buf is added, with operations and API to allow easy > sharing of this buffer object across devices. > > The framework allows: > -

[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 10:36 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote: >> This is the first step in defining a dma buffer sharing mechanism. >> >> A new buffer object dma_buf is added, with operations and API to allow easy >> sharing of this

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

Hi Arnd, On Fri, Dec 09, 2011 at 02:13:03PM +, Arnd Bergmann wrote: > On Thursday 08 December 2011, Daniel Vetter wrote: > > > c) only allowing streaming mappings, even if those are non-coherent > > > (requiring strict serialization between CPU (in-kernel) and dma users of > > > the buffer) >

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote: > On Monday 19 December 2011, Semwal, Sumit wrote: >> I didn't see a consensus on whether dma_buf should enforce some form >> of serialization within the API - so atleast for v1 of dma-buf, I >> propose to 'not' impose a restriction, and we

high_memory address in /proc/dri/*/vma

On Tue, Dec 20, 2011 at 8:32 AM, Daniel Vetter wrote: > On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote: >> [Re-sent to the right address, I hope.] >> >> Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not >> leak kernel addresses via /proc/dri/*/vma") you changed

[PATCH] drm/radeon/kms: don't use 0 bpc for adjusting hdmi clock

On Tue, Dec 20, 2011 at 6:47 AM, Dave Airlie wrote: > From: Dave Airlie > > If the bpc is set from the connector is 0, we then use it later to adjust > in a special case the HDMI pixel clock, however if the bpc is 0, we end up > passing a 0 pixel clock into the code. > > I'm not sure if this is

[Bug 43964] Rendering is distorded in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964 Laurent carlier changed: What|Removed |Added Summary|A script fail to build in |Rendering is distorded in

Rebased drm_plane patches

- Original Message - > From: "ville syrjala" > To: dri-devel at lists.freedesktop.org > Sent: Monday, 19 December, 2011 10:06:37 PM > Subject: Rebased drm_plane patches > > I rebased this set on top of drm-next. > > I updated some of the error values based on what Jesse suggested. >

high_memory address in /proc/dri/*/vma

mean now. This is, as you say, only a > problem "in theory". Is it worth fixing currently? I don't know. > If so, we probably need to add the "K" option to %x in some fashion. Something like that, yes. Ben. -- Ben Hutchings Humans are not rational beings; they are ra

[Bug 43771] [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap: Assertion `img_filter == 1' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=43771 Stephane Marchesin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

high_memory address in /proc/dri/*/vma

they are not pointers. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 828 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111220/9027c103/attachment.pgp>

[RFC PATCH 8/8] drm: Add drm_chroma_phase_offsets() utility function

From: Ville Syrj?l? This function is is there to help driver writers. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c | 47 + include/drm/drm_crtc_helper.h |3 ++ 2 files changed, 50 insertions(+),

[RFC PATCH 7/8] drm: plane: Add plane options ioctl

From: Ville Syrj?l? Add a new ioctl DRM_IOCTL_MODE_PLANE_OPTS which is used to configure various settings for the plane. I left out gamma correction thinking that it could be added using a separate ioctl, since there's already a gamma ioctl for CRTCs.

[RFC PATCH 6/8] drm: Add drm_calc_{hscale, vscale}() utility functions

From: Ville Syrj?l? Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c | 102 + include/drm/drm_crtc_helper.h |4 ++ 2 files changed, 106 insertions(+), 0 deletions(-) diff --git

[RFC PATCH 5/8] drm: Add struct drm_region and assorted utility functions

From: Ville Syrj?l? struct drm_region represents a two dimensional region. The utility functions are there to help driver writers. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c | 156 +

[RFC PATCH 4/8] drm: Add drm_framebuffer_check() utility function

From: Ville Syrj?l? This function performs a battery of sanity checks on the requested framebuffer layout. Drivers can call it from their fb_create hook. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c | 85

[RFC PATCH 3/8] drm: Add drm_format_{horz, vert}_chroma_subsampling() utility functions

From: Ville Syrj?l? These functions return the chroma subsampling factors for the specified pixel format. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c | 60 + include/drm/drm_crtc_helper.h |2 +

[RFC PATCH 2/8] drm: Add drm_format_plane_cpp() utility function

From: Ville Syrj?l? This function returns the bytes per pixel value based on the pixel format and plane index. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c | 45 + include/drm/drm_crtc_helper.h |

[RFC PATCH 1/8] drm: Add drm_format_num_planes() utility function

From: Ville Syrj?l? This function returns the number of planes used by a specific pixel format. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc_helper.c | 33 + include/drm/drm_crtc_helper.h |3 +++ 2 files

Plane helpers and a new plane options ioctl

Here are the utility functions again. Rebased and updated slightly. I adapted drm_framebuffer_check() to handle multiple handles, and I changed some of the error values it returns. The plane options ioctl is a bit of an open question. I started by adding separate ioctls for some subsets of the

high_memory address in /proc/dri/*/vma

[Re-sent to the right address, I hope.] Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not leak kernel addresses via /proc/dri/*/vma") you changed the logging of high_memory: - seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n", + seq_printf(m, "vma

[PATCH 12/12] drm: Replace pitch with pitches[] in drm_framebuffer

From: Ville Syrj?l? Otherwise each driver would need to keep the information inside their own framebuffer object structure. Also add offsets[]. BOs on the other hand are driver specific, so those can be kept in driver specific structures. Signed-off-by: Ville

[PATCH 11/12] drm: Check that the requested pixel format is valid

From: Ville Syrj?l? Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 75 1 files changed, 75 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index

[PATCH 10/12] drm: plane: Check that the fb pixel format is supported by the plane

From: Ville Syrj?l? Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 80cfe1c..66a165d 100644 ---

[PATCH 09/12] drm: plane: Make 'formats' parameter to drm_plane_init() const

From: Ville Syrj?l? Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c |2 +- include/drm/drm_crtc.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index

[PATCH 08/12] drm: plane: Check crtc coordinates against integer overflows in setplane ioctl

From: Ville Syrj?l? Help drivers a little by guaranteeing that crtc_x+crtc_w and crtc_y+crtc_h don't overflow. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git

[PATCH 07/12] drm: plane: Check source coordinates

From: Ville Syrj?l? Make sure the source coordinates stay within the buffer. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH 06/12] drm: plane: Clear plane.crtc and plane.fb after disable_plane()

From: Ville Syrj?l? These are the only indication to user space that the plane was disabled. Signed-off-by: Ville Syrj?l? Acked-by: Jesse Barnes --- drivers/gpu/drm/drm_crtc.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git

[PATCH 05/12] drm: Fix __user sparse warnings

From: Ville Syrj?l? Several pointers and casts were missing __user annotations. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 30 +++--- 1 files changed, 15 insertions(+), 15 deletions(-) diff --git

[PATCH 04/12] drm: plane: mutex_unlock() was missing

From: Ville Syrj?l? Unlock the mode_config mutex if drm_plane_init() fails. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH 03/12] drm: fourcc: Use __u32 instead of u32

From: Ville Syrj?l? drm_fourcc.h can be included from user space so use the appropriate types. Signed-off-by: Ville Syrj?l? --- include/drm/drm_fourcc.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_fourcc.h

[PATCH 02/12] drm: Install drm_fourcc.h

From: Ville Syrj?l? Userspace needs this header. Signed-off-by: Ville Syrj?l? --- include/drm/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/drm/Kbuild b/include/drm/Kbuild index 3a60ac8..a5c0e10 100644 ---

[PATCH 01/12] drm: Add a missing ')'

From: Ville Syrj?l? The code happened to compile because the flag wasn't actually used yet. Signed-off-by: Ville Syrj?l? --- include/drm/drm_mode.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/drm/drm_mode.h

Rebased drm_plane patches

I rebased this set on top of drm-next. I updated some of the error values based on what Jesse suggested. I also added a few patches to fix various issues that came up since I last posted the patches. Since the patch to drop the planar formats with YVU plane order wasn't applied to drm-next, I

[Bug 43964] Rendering is distorded in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964 Laurent carlier lordhea...@gmail.com changed: What|Removed |Added Summary|A script fail to build in |Rendering is

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

Hi Arnd, On Fri, Dec 09, 2011 at 02:13:03PM +, Arnd Bergmann wrote: On Thursday 08 December 2011, Daniel Vetter wrote: c) only allowing streaming mappings, even if those are non-coherent (requiring strict serialization between CPU (in-kernel) and dma users of the buffer) I

Re: Rebased drm_plane patches

- Original Message - From: ville syrjala ville.syrj...@linux.intel.com To: dri-devel@lists.freedesktop.org Sent: Monday, 19 December, 2011 10:06:37 PM Subject: Rebased drm_plane patches I rebased this set on top of drm-next. I updated some of the error values based on what

[PATCH] drm/radeon/kms: don't use 0 bpc for adjusting hdmi clock

From: Dave Airlie airl...@redhat.com If the bpc is set from the connector is 0, we then use it later to adjust in a special case the HDMI pixel clock, however if the bpc is 0, we end up passing a 0 pixel clock into the code. I'm not sure if this is the correct answer or if we should avoid the

[Bug 43954] Some textures are not correctly rendered on HD 6950

https://bugs.freedesktop.org/show_bug.cgi?id=43954 --- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-12-20 03:52:48 PST --- Could be bug 38173. Does it work better with the environment variable MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_compression_s3tc ? -- Configure bugmail:

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell rmor...@nvidia.com wrote: One of the goals of this project is to unify the fragmented space of the ARM SoC memory managers so that each vendor doesn't implement their own, and they can all be closer to mainline. That is a very good objective. I

Re: [PATCH] drm/radeon/kms: don't use 0 bpc for adjusting hdmi clock

On Tue, Dec 20, 2011 at 6:47 AM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com If the bpc is set from the connector is 0, we then use it later to adjust in a special case the HDMI pixel clock, however if the bpc is 0, we end up passing a 0 pixel clock into the

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tuesday 20 December 2011, Sakari Ailus wrote: (I'm jumping into the discussion in the middle, and might miss something that has already been talked about. I still hope what I'm about to say is relevant. :-)) It certainly is relevant. In subsystems such as V4L2 where drivers deal with such

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Monday 19 December 2011, Semwal, Sumit wrote: I didn't see a consensus on whether dma_buf should enforce some form of serialization within the API - so atleast for v1 of dma-buf, I propose to 'not' impose a restriction, and we can tackle it (add new ops or enforce as design?) whenever we

Re: high_memory address in /proc/dri/*/vma

On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote: [Re-sent to the right address, I hope.] Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not leak kernel addresses via /proc/dri/*/vma) you changed the logging of high_memory: - seq_printf(m, vma use

Re: [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - different

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 19 December 2011, Semwal, Sumit wrote: I didn't see a consensus on whether dma_buf should enforce some form of serialization within the API - so atleast for v1 of dma-buf, I propose to 'not' impose a restriction, and

Re: [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 10:36 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 20, 2011 at 10:41:45AM -0600, Rob Clark wrote: On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 19 December 2011, Semwal, Sumit wrote: I didn't see a consensus on whether dma_buf should enforce some form of serialization within the API - so atleast

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

On Mon, Dec 19, 2011 at 08:51:15PM +0100, Thomas Hellstrom wrote: On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote: On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote: On 12/13/2011 05:07 PM, Jerome Glisse wrote: On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk

[PATCH libdrm 1/3] libdrm: Plug memory leaks

From: Ville Syrjälä ville.syrj...@linux.intel.com drmModeFreeResources() always leaked some memory. drmModeGetPlaneResources() and drmModeGetPlane() leaked in one error path. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- xf86drmMode.c |6 ++ 1 files changed, 6

[PATCH libdrm 2/3] libdrm: Add drmModeFreePlaneResources()

From: Ville Syrjälä ville.syrj...@linux.intel.com This function was missing. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- xf86drmMode.c |9 + xf86drmMode.h |1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/xf86drmMode.c b/xf86drmMode.c index

[PATCH libdrm 3/3] libdrm: Fix AddFB2 memcpy() size

From: Ville Syrjälä ville.syrj...@linux.intel.com Using sizeof() on a function parameter with an array type does not work. sizeof() treats such parameters as pointers. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- xf86drmMode.c |6 +++--- 1 files changed, 3 insertions(+), 3

[r600g] ATI Radeon HD6950, dual monitor and power profile

Hi, When using more than one monitor, the card uses higher clocks than in single-monitor mode and low-power profile. As a subjectively negative side-effect, the fan on the card starts making more noise. Other cards I used before had no problem with staying quiet even when more monitors were

[Bug 43964] Rendering is distorded in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964 --- Comment #3 from Ian Romanick i...@freedesktop.org 2011-12-20 10:40:59 PST --- (In reply to comment #0) CG: 'PostEffect_Motion_fp.cg' using profile: 'arbfp1' CG ERROR : The compile returned an error. ---

Re: high_memory address in /proc/dri/*/vma

On Tue, Dec 20, 2011 at 05:32:13PM +0100, Daniel Vetter wrote: On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote: [Re-sent to the right address, I hope.] Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not leak kernel addresses via /proc/dri/*/vma) you

Re: [RFC v3 0/2] Introduce DMA buffer sharing mechanism

On Mon, Dec 19, 2011 at 02:03:28PM +0530, Sumit Semwal wrote: Hello Everyone, This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share

Re: [RFC PATCH 1/8] drm: Add drm_format_num_planes() utility function

On Mon, Dec 19, 2011 at 4:33 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com This function returns the number of planes used by a specific pixel format. btw, I end up with a very similar util fxn in omapdrm driver.. would be nice to have this in

Re: [PATCH] drm/edid: Try harder to fix up broken headers

On 12/7/11 6:26 PM, Adam Jackson wrote: There's no reason to force the first byte to be correct if we're already scoring how correct the header is. Don't use this. The 00 check is needed to make sure we only attempt the header fixup on the zeroth block (not extensions). - ajax

Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU. This need

Re: [r600g] ATI Radeon HD6950, dual monitor and power profile

On 12/20/11 1:38 PM, Harald Judt wrote: Hi, When using more than one monitor, the card uses higher clocks than in single-monitor mode and low-power profile. As a subjectively negative side-effect, the fan on the card starts making more noise. Other cards I used before had no problem with

Re: [RFC PATCH 1/8] drm: Add drm_format_num_planes() utility function

On Tue, Dec 20, 2011 at 7:55 PM, Rob Clark robdcl...@gmail.com wrote: On Mon, Dec 19, 2011 at 4:33 PM,  ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com This function returns the number of planes used by a specific pixel format. btw, I end up with a

Re: [r600g] ATI Radeon HD6950, dual monitor and power profile

Am 20.12.2011 21:20, schrieb Adam Jackson: On 12/20/11 1:38 PM, Harald Judt wrote: Hi, When using more than one monitor, the card uses higher clocks than in single-monitor mode and low-power profile. As a subjectively negative side-effect, the fan on the card starts making more noise. Other

Re: [r600g] ATI Radeon HD6950, dual monitor and power profile

On Tue, Dec 20, 2011 at 4:19 PM, Harald Judt h.j...@gmx.at wrote: Am 20.12.2011 21:20, schrieb Adam Jackson: On 12/20/11 1:38 PM, Harald Judt wrote: Hi, When using more than one monitor, the card uses higher clocks than in single-monitor mode and low-power profile. As a subjectively

Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie airl...@gmail.com wrote: This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory

[PATCH] drm/omap: GEM, deal with cache

From: Rob Clark r...@ti.com Uncached/writecombine buffers need to be clean before creating uc/wc userspace mappings, lest dirty cache lines fall down and corrupt the contents of the buffer. Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_gem.c | 30

[PATCH 0/3] drm/omap: updates for addfb2 and plane support

From: Rob Clark r...@ti.com The first patch updates omapdrm for API changes introduced when addfb2 support (for multi-planar fb's) was added (in drm-next). The next patch adds drm plane (overlay) support, with CRTCs using private plane objects to avoid code duplication between the CRTC and

[PATCH 2/3] drm/omap: add drm_plane support

From: Rob Clark r...@ti.com Because framebuffer layer and overlay scanout video pipes are basically thing in OMAP display subsystem (the only difference being that the first video pipe does not support scaling or YUV formats), much of the CRTC code is pulled into the plane implementation, and a

[PATCH 3/3] drm/omap: multiplanar and YUV support

From: Rob Clark r...@ti.com Add support in framebuffer objects for other color formats and multi- planar YUV (NV12). Since this requires changing the API between the plane and fb for getting scanout information (paddr, etc), take advantage of the opportunity and put in place a way to allow fb's

  1   2   >