[PATCH 01/12] gma500: Move the basic driver out of staging

> The first poulsbos used to crash badly when attempting to map the GTT > write-combined, and IIRC it didn't even advertise write-combining > capabilities on the PCI BAR. Has this been improved on lately or how is > this handled currently? It seems to be reliable in the current driver.

[PATCH 03/12] gma500: introduce the GTT and MMU handling logic

The ioremap for stolen RAM is about 8MB - we do actually need that mapped for the console framebuffer. The GTT tables are pretty small (64K or so) and the rest of the GTT space if ever used doesn't get an ioremap. It's a bit different to the i915 world because the CPU cannot indirect via the GTT

[PATCH] DRM planes

> We're talking about gpus, there's no way an application will talk to them > than through some nice cozy abstraction layer like OpenGl, X, ... Even > Wayland has gbm to do the low-level kms scanout allocation. You are talking about scanouts. Nothing more. Nothing in KMS/DRM even requires GPU

[PATCH 01/12] gma500: Move the basic driver out of staging

On 11/03/2011 07:20 PM, Alan Cox wrote: > From: Alan Cox > > This driver supports unaccelerated KMS display, and accelerated console > handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware. > > For the initial merge Medfield will be left out as it needs considerable > further

[PATCH 03/12] gma500: introduce the GTT and MMU handling logic

On Thu, Nov 03, 2011 at 06:21:09PM +, Alan Cox wrote: > From: Alan Cox > > This fits alongside the GEM support to manage our resources on the card > itself. It's not actually clear we need to configure the MMU at all. > Further research is needed before removing it entirely. For now we suck

[PATCH 5/5] vmwgfx: Snoop DMA transfers with non-covering sizes

From: Jakob Bornecrantz Enough to get cursors working under Wayland. Signed-off-by: Jakob Bornecrantz Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 30 +- 1 files changed, 21 insertions(+), 9 deletions(-) diff --git

[PATCH 4/5] vmwgfx: Move the prefered mode first in the list

From: Jakob Bornecrantz Signed-off-by: Jakob Bornecrantz Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

[PATCH 3/5] vmwgfx: Unreference surface on cursor error path

From: Jakob Bornecrantz Signed-off-by: Jakob Bornecrantz Reviewed-by: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

[PATCH 2/5] vmwgfx: Free prefered mode on error path

From: Jakob Bornecrantz Signed-off-by: Jakob Bornecrantz Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

[PATCH 1/5] vmwgfx: Use pointer return error codes

From: Jakob Bornecrantz Signed-off-by: Jakob Bornecrantz Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

[PATCH 0/5 -fixes] More vmwgfx fixes for 3.2

A number of fixes for bugs discovered by Jakob while doing Wayland/EGL testing.

[PATCH 02/12] gma500: GEM and GEM glue

On Thu, Nov 03, 2011 at 06:20:58PM +, Alan Cox wrote: > From: Alan Cox > > The driver uses GEM along with a couple of small bits of wrapping of its > own. The only real oddity here is the support for using the 'stolen' memory > rather than wasting several MB. > > We use a simple resource

[PATCH] DRM planes

On Thu, Nov 03, 2011 at 05:47:43PM +, Alan Cox wrote: > > In short decoding these fourcc values with all their implicit assumptions > > about offset, strides and whatnotelse will be one giant switch mess. Not > > my idea of a nice kernel interface. Also practically guaranteed to result > > in

[PATCH 11/11] drm/radeon/kms: Enable the TTM DMA pool if swiotlb is on

From: Konrad Rzeszutek Wilk With the exception that we do not handle the AGP case. We only deal with PCIe cards such as ATI ES1000 or HD3200 that have been detected to only do DMA up to 32-bits. CC: Dave Airlie CC: Alex Deucher Signed-off-by: Konrad Rzeszutek Wilk

[PATCH 10/11] swiotlb: Expose swiotlb_nr_tlb function to modules

From: Konrad Rzeszutek Wilk As a mechanism to detect whether SWIOTLB is enabled or not. We also fix the spelling - it was swioltb instead of swiotlb. CC: FUJITA Tomonori [v1: Ripped out swiotlb_enabled] Signed-off-by: Konrad Rzeszutek Wilk ---

[PATCH 09/11] ttm: Provide DMA aware TTM page pool code.

From: Konrad Rzeszutek Wilk In TTM world the pages for the graphic drivers are kept in three different pools: write combined, uncached, and cached (write-back). When the pages are used by the graphic driver the graphic adapter via its built in MMU (or AGP) programs these

[PATCH 08/11] drm/ttm: introduce callback for ttm_tt populate & unpopulate

From: Jerome Glisse Move the page allocation and freeing to driver callback and provide ttm code helper function for those. Most intrusive change, is the fact that we now only fully populate an object this simplify some of code designed around the page fault design.

[PATCH 07/11] drm/ttm: merge ttm_backend and ttm_tt

From: Jerome Glisse ttm_backend will exist only and only with a ttm_tt, and ttm_tt will be of interesting use only when bind to a backend. Thus to avoid code & data duplication btw the two merge them. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/nouveau/nouveau_bo.c

[PATCH 06/11] drm/ttm: test for dma_address array allocation failure

From: Jerome Glisse Signed-off-by: Jerome Glisse Reviewed-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_tt.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 2dd45ca..58ea7dc

[PATCH 05/11] drm/ttm: convert page allocation to use page ptr array instead of list V3

From: Jerome Glisse Use the ttm_tt page ptr array for page allocation, move the list to array unwinding into the page allocation functions. V2 split the fix to use ttm put page as a separate fix properly fill pages array when TTM_PAGE_FLAG_ZERO_ALLOC is not set V3 Added back

[PATCH 04/11] drm/ttm: use ttm put pages function to properly restore cache attribute

From: Jerome Glisse On failure we need to make sure the page we free has wb cache attribute. Do this pas call the proper ttm page helper function. Signed-off-by: Jerome Glisse Reviewed-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_tt.c |5 - 1 files

[PATCH 03/11] drm/ttm: remove unused backend flags field

From: Jerome Glisse This field is not use by any of the driver just drop it. Signed-off-by: Jerome Glisse Reviewed-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/radeon/radeon_ttm.c |1 - include/drm/ttm/ttm_bo_driver.h |2 -- 2 files changed, 0 insertions(+),

[PATCH 02/11] drm/ttm: remove split btw highmen and lowmem page

From: Jerome Glisse Split btw highmem and lowmem page was rendered useless by the pool code. Remove it. Note further cleanup would change the ttm page allocation helper to actualy take an array instead of relying on list this could drasticly reduce the number of function call

[PATCH 01/11] drm/ttm: remove userspace backed ttm object support

From: Jerome Glisse This was never use in none of the driver, properly using userspace page for bo would need more code (vma interaction mostly). Removing this dead code in preparation of ttm_tt & backend merge. Signed-off-by: Jerome Glisse Reviewed-by: Konrad Rzeszutek

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator

Hi, So updated patchset, only patch 5 seen change since last set. Last 3 patch are from your patchset, modified on top of mine. Konrad so i added you dma pool allocator on top of that and added support for it to radeon. All in all it's slightly smaller than your patchset. Biggest change is use

[PATCH] DRM planes

Hi all, I've discussed this a bit on irc and consensus seems to be "some ugliness due to interface impendance mistmatches in the kernel? who cares ...". I agree that there's not a fundamental problem with fourcc and planar yuv that can't be fixed with a bunch of boilerplate code with the assorted

[PATCH 12/12] gma500: Now connect up to the DRM build to finish the job

From: Alan Cox Signed-off-by: Alan Cox --- drivers/gpu/drm/Kconfig |3 +++ drivers/gpu/drm/Makefile |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b493663..7c1cb0d 100644 ---

[PATCH 11/12] gma500: Add support for Cedarview

From: Alan Cox Again this is similar but has some differences so we have a set of plug in support. This does make the driver bigger than is needed in some respects but the tradeoff for maintainability is huge. Signed-off-by: Alan Cox ---

[PATCH 10/12] gma500: Add Oaktrail support

From: Alan Cox Oaktrail (GMA600) is found on some tablet/slate PC type systems. It's a bit different to the GMA500 but similar enough it makes sense to plug it into the same driver. Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/oaktrail.h | 252

[PATCH 09/12] gma500: Add Poulsbo support

From: Alan Cox This provides the specific code for Poulsbo, some of which is also used for the later chipsets. We support the GTT, the 2D engine (for console), and the display setup/management. We do not support 3D or the video overlays. In theory enough public info is

[PATCH 08/12] gma500: Add the core DRM files and headers

From: Alan Cox Not really a nice way to split this up further for submission. This provides all the DRM interfacing logic, the headers and relevant glue. Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/psb_drm.h | 207 +++ drivers/gpu/drm/gma500/psb_drv.c | 1210

[PATCH 07/12] gma500: Add the i2c bus support

From: Alan Cox Again this might be a candidate for sharing later. Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/intel_i2c.c | 169 1 files changed, 169 insertions(+), 0 deletions(-) create mode 100644

[PATCH 06/12] gma500: Add the glue to the various BIOS and firmware interfaces

From: Alan Cox Some of this should one day become a library shared by i915 and gma500 I suspct. Best however to deal with that later once it is all nice and stably merged. Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/intel_bios.c | 303 ++

[PATCH 05/12] gma500: Add device framework

From: Alan Cox The devices have various internal differences so we have some abstractions to hide the ugly differences and we then wrap them up in standard interfaces. Add these bits Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/backlight.c | 49 ++

[RFC] Virtual CRTCs (proposal + experimental code)

Hi, Quick question: How does this compare to Dave Airlies' PRIME buffer sharing work for drm respectively the more generic dma_buf buffer sharing work pushed by Linaro? You seem to aim for a solution for similar problems (judging by your description) using a rather different approach. Cheers,

[PATCH 04/12] gma500: introduce the framebuffer support code

From: Alan Cox We support 2D acceleration on some devices but we try and do tricks with the GTT as a starting point as this is far faster. The GTT logic could be improved further but for most display sizes it already makes a pretty good decision. Signed-off-by: Alan Cox

[PATCH 03/12] gma500: introduce the GTT and MMU handling logic

From: Alan Cox This fits alongside the GEM support to manage our resources on the card itself. It's not actually clear we need to configure the MMU at all. Further research is needed before removing it entirely. For now we suck it in (slightly abused) from the old semi-free

[PATCH 02/12] gma500: GEM and GEM glue

From: Alan Cox The driver uses GEM along with a couple of small bits of wrapping of its own. The only real oddity here is the support for using the 'stolen' memory rather than wasting several MB. We use a simple resource manager as we don't need to manage our space

[PATCH 01/12] gma500: Move the basic driver out of staging

From: Alan Cox This driver supports unaccelerated KMS display, and accelerated console handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware. For the initial merge Medfield will be left out as it needs considerable further work to reach a decent standard

[RFC] Virtual CRTCs (proposal + experimental code)

> Well the current plan I had for this was to do it in userspace, I don't think > the kernel > has any business doing it and I think for the simple USB case its fine but > will fallover > when you get to the non-trivial cases where some sort of acceleration is > required to move > pixels

[PATCH] DRM planes

> In short decoding these fourcc values with all their implicit assumptions > about offset, strides and whatnotelse will be one giant switch mess. Not > my idea of a nice kernel interface. Also practically guaranteed to result > in slightly different behaviour in each driver. So you'd rather make

[RFC] Virtual CRTCs (proposal + experimental code)

Am 03.11.2011 16:59, schrieb Ilija Hadzic: > Hi everyone, > > I would like to bring to the attention of dri-devel and linux-fbdev > community a set of hopefully useful and interesting patches that > I (and a few other colleagues) have been working on during the past > few months. Here, I will

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #8 from Anisse Astier 2011-11-03 09:17:28 PDT --- As I said to Alex on IRC, these patches also solves the issue on Toshiba laptops: C670D-10C (AMD E-240) and C670D-11K (AMD E-450). (Old reference:

[Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/2d627f57/attachment.pgp>

[PATCH 1/5] drm: add plane support

On Thu, 3 Nov 2011 11:21:18 -0700 Jesse Barnes wrote: > On Wed, 2 Nov 2011 15:33:04 -0700 > Jesse Barnes wrote: > > > On Wed, 2 Nov 2011 13:03:19 -0700 > > Jesse Barnes wrote: > > > > > Planes are a bit like half-CRTCs. They have a location and fb, but > > > don't drive outputs directly.

[Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space

bed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/84f30dfb/attachment.pgp>

[Intel-gfx] [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/5b3f82a9/attachment.pgp>

[Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

rg/archives/dri-devel/attachments/2003/77cf237e/attachment-0001.pgp>

[PATCH] DRM planes

esc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/c8544473/attachment.pgp>

[PATCH] DRM planes

On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote: > In response to feedback, I've adjusted the new addfb2 ioctl to take per > component pitch and offset args. Generally, the offset[0] field will be > 0, but it's conceivable that some metadata could be stored at the start > of a given

[Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

rubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/6e023fe9/attachment.pgp>

[PATCH 6/8] drm/ttm: test for dma_address array allocation failure

On Wed, Nov 02, 2011 at 07:37:53PM -0400, j.glisse at gmail.com wrote: > From: Jerome Glisse > > Signed-off-by: Jerome Glisse Reviewed-by-me. > --- > drivers/gpu/drm/ttm/ttm_tt.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c

[PATCH 5/8] drm/ttm: convert page allocation to use page ptr array instead of list V2

On Wed, Nov 02, 2011 at 07:37:52PM -0400, j.glisse at gmail.com wrote: > From: Jerome Glisse > > Use the ttm_tt page ptr array for page allocation, move the list to > array unwinding into the page allocation functions. > > V2 split the fix to use ttm put page as a separate fix > properly fill

[PATCH 4/8] drm/ttm: use ttm put pages function to properly restore cache attribute

On Wed, Nov 02, 2011 at 07:37:51PM -0400, j.glisse at gmail.com wrote: > From: Jerome Glisse > > On failure we need to make sure the page we free has wb cache > attribute. Do this pas call the proper ttm page helper function. > > Signed-off-by: Jerome Glisse Reviewed-by... > --- >

[Bug 42490] NUTMEG DP to VGA bridge not working

https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #8 from Alex Deucher 2011-11-03 07:17:19 PDT --- (In reply to comment #7) > I've tried 3.0.6, 3.1 and the drm-core-next branch from: > git://people.freedesktop.org/~airlied/linux > > Is there a radeon linux kernel tree I could

[PATCH] DRM planes

On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes wrote: > On Thu, 3 Nov 2011 18:29:14 +0100 > Daniel Vetter wrote: > >> Hi all, >> >> I've discussed this a bit on irc and consensus seems to be "some ugliness >> due to interface impendance mistmatches in the kernel? who cares ...". I >> agree that

[RFC] Virtual CRTCs (proposal + experimental code)

> > Hi everyone, > > I would like to bring to the attention of dri-devel and linux-fbdev > community a set of hopefully useful and interesting patches that > I (and a few other colleagues) have been working on during the past > few months. Here, I will provide a short abstract, so that you can

[Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space

PANEL_LIGHT_OFF_DELAY_SHIFT; > Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/b4df1dd1/attachment.pgp>

[Intel-gfx] [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training

ested by target */ > intel_get_adjust_train(intel_dp, link_status); Don't you love the training state machine? I think this looks ok, and the DP compliance test should catch any grievous errors, so aside from the bug fix hunk which should be split out: Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/da4d4840/attachment-0001.pgp>

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #8 from Jos van Wolput 2011-11-03 06:03:25 PDT --- (In reply to comment #6) > Which versions of gcc and wine are you using ? I still don't get these errors > with gcc-4.4 (going to update to 4.6 now). Using Debian Sid 64bit,

[RFC] Virtual CRTCs (proposal + experimental code)

On Thu, 3 Nov 2011, David Airlie wrote: > > Well the current plan I had for this was to do it in userspace, I don't think > the kernel > has any business doing it and I think for the simple USB case its fine but > will fallover > when you get to the non-trivial cases where some sort of

[Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms

tting it off, then downing the link? Should this be reordered? -- Jesse Barnes, Intel Open Source Technology Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/0a4fa7a9/attachment.pgp>

[Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job

-- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/1a504ce7/attachment.pgp>

[RFC] Virtual CRTCs (proposal + experimental code)

On Thu, 3 Nov 2011, Roland Scheidegger wrote: > > Am I right in assuming this could also be used for making muxless hybrid > GPUs work (i.e. radeon/intel igp)? Yes, this is actually one of the scenarios on my wish list too. In the terminology that I defined with the introduction of VCRTCM,

[PATCH] DRM planes

all the data is packed into a single bo or not. -- Jesse Barnes, Intel Open Source Technology Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/10b14724/attachment.pgp>

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #7 from Alexandre Demers 2011-11-03 05:13:11 PDT --- I should have added that info. Using Ubuntu Oneiric 64bit, running gcc 4.6.1 and wine 1.3.31. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ---

[RFC] Virtual CRTCs (proposal + experimental code)

Hi everyone, I would like to bring to the attention of dri-devel and linux-fbdev community a set of hopefully useful and interesting patches that I (and a few other colleagues) have been working on during the past few months. Here, I will provide a short abstract, so that you can decide whether

[Intel-gfx] [PATCH] drm/i915: add SNB video sprite support

n/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/8e6a513e/attachment.pgp>

[PATCH 5/5] drm/i915: add destination color key support

On Wed, 2 Nov 2011 13:03:23 -0700 Jesse Barnes wrote: > Add new ioctls for getting and setting the current destination color > key. This allows for simple overlay display control by matching a color > key value in the primary plane before blending the overlay on top. > > Signed-off-by: Jesse

[PATCH 4/5] drm/i915: add SNB and IVB video sprite support

On Wed, 2 Nov 2011 13:03:22 -0700 Jesse Barnes wrote: > The video sprites support various video surface formats natively and can > handle scaling as well. So add support for them using the new DRM core > overlay support functions. > > Signed-off-by: Jesse Barnes > --- Updated with ->destroy

[PATCH 3/5] drm/i915: rename existing overlay support to "legacy"

es/dri-devel/attachments/2003/ae2ee56b/attachment.pgp>

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #6 from Christoph Bumiller 2011-11-03 04:22:21 PDT --- Which versions of gcc and wine are you using ? I still don't get these errors with gcc-4.4 (going to update to 4.6 now). -- Configure bugmail:

[PATCH 2/5] drm: add an fb creation ioctl that takes a pixel format

On Wed, 2 Nov 2011 13:03:20 -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

[PATCH 1/5] drm: add plane support

On Wed, 2 Nov 2011 15:33:04 -0700 Jesse Barnes wrote: > On Wed, 2 Nov 2011 13:03:19 -0700 > Jesse Barnes wrote: > > > Planes are a bit like half-CRTCs. They have a location and fb, but > > don't drive outputs directly. Add support for handling them to the core > > KMS code. > >

[PATCH] drm/radeon/kms: consolidate GART code, fix segfault after GPU lockup V2

From: Jerome Glisse After GPU lockup VRAM gart table is unpinned and thus its pointer becomes unvalid. This patch move the unpin code to a common helper function and set pointer to NULL so that page update code can check if it should update GPU page table or not. That way bo

[PATCH] DRM planes

bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/4b4ae914/attachment.pgp>

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

Hello, I'm sorry for a late reply, but after Kernel Summit/ELC I have some comments. On Friday, October 14, 2011 5:35 PM Daniel Vetter wrote: > On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote: > > >+/** > > >+ * struct dma_buf_ops - operations possible on struct dma_buf > >

[PATCH] DRM planes

msung guys say to make a decision. -- Jesse Barnes, Intel Open Source Technology Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2003/4ec067ed/attachment-0001.pgp>

[Bug 28426] hardware cursor corruption with radeon+kms

https://bugs.freedesktop.org/show_bug.cgi?id=28426 --- Comment #10 from J?rg Billeter 2011-11-03 00:25:59 PDT --- I've now updated to Linux 3.1. It's looking fine so far but it usually takes a couple days or so until the cursor corruption starts. I will report back. -- Configure bugmail:

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #5 from Alexandre Demers 2011-11-02 22:23:54 PDT --- Added Luca since he may have more info on the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because:

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #4 from Alexandre Demers 2011-11-02 22:21:25 PDT --- Same problem over here. Many errors related to either missing "STDMETHODCALLTYPE" in declarations or unneeded "STDMETHODCALLTYPE" in associated files. Compiler doesn't like it

[Bug 41265] KMS does not work on Radeon HD6700M

https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #5 from nover 2011-11-03 03:40:53 UTC --- I have the same laptop, so I can second this. It would be really nice to have this working. As Varban has pointed out, the media dock does indeed have it's own HDMI and VGA ports. And just

[Bug 42490] NUTMEG DP to VGA bridge not working

https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #7 from Mandeep Singh Baines 2011-11-02 19:15:33 PDT --- I've tried 3.0.6, 3.1 and the drm-core-next branch from: git://people.freedesktop.org/~airlied/linux Is there a radeon linux kernel tree I could test? I'm also happy to test

[Bug 28426] hardware cursor corruption with radeon+kms

https://bugs.freedesktop.org/show_bug.cgi?id=28426 --- Comment #10 from Jürg Billeter j...@bitron.ch 2011-11-03 00:25:59 PDT --- I've now updated to Linux 3.1. It's looking fine so far but it usually takes a couple days or so until the cursor corruption starts. I will report back. -- Configure

[Bug 41265] KMS does not work on Radeon HD6700M

https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #5 from nover nick...@isharp.dk 2011-11-03 03:40:53 UTC --- I have the same laptop, so I can second this. It would be really nice to have this working. As Varban has pointed out, the media dock does indeed have it's own HDMI and VGA

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #6 from Christoph Bumiller e0425...@student.tuwien.ac.at 2011-11-03 04:22:21 PDT --- Which versions of gcc and wine are you using ? I still don't get these errors with gcc-4.4 (going to update to 4.6 now). -- Configure bugmail:

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

Hello, I'm sorry for a late reply, but after Kernel Summit/ELC I have some comments. On Friday, October 14, 2011 5:35 PM Daniel Vetter wrote: On Fri, Oct 14, 2011 at 12:00:58PM +0200, Tomasz Stanislawski wrote: +/** + * struct dma_buf_ops - operations possible on struct dma_buf + *

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #7 from Alexandre Demers alexandre.f.dem...@gmail.com 2011-11-03 05:13:11 PDT --- I should have added that info. Using Ubuntu Oneiric 64bit, running gcc 4.6.1 and wine 1.3.31. -- Configure bugmail:

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

https://bugs.freedesktop.org/show_bug.cgi?id=41740 --- Comment #8 from Jos van Wolput wol...@onsneteindhoven.nl 2011-11-03 06:03:25 PDT --- (In reply to comment #6) Which versions of gcc and wine are you using ? I still don't get these errors with gcc-4.4 (going to update to 4.6 now). Using

Re: [PATCH] DRM planes

On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote: In response to feedback, I've adjusted the new addfb2 ioctl to take per component pitch and offset args. Generally, the offset[0] field will be 0, but it's conceivable that some metadata could be stored at the start of a given

[Bug 42490] NUTMEG DP to VGA bridge not working

https://bugs.freedesktop.org/show_bug.cgi?id=42490 --- Comment #8 from Alex Deucher ag...@yahoo.com 2011-11-03 07:17:19 PDT --- (In reply to comment #7) I've tried 3.0.6, 3.1 and the drm-core-next branch from: git://people.freedesktop.org/~airlied/linux Is there a radeon linux kernel tree I

Re: [PATCH] DRM planes

On Thu, 3 Nov 2011 15:11:55 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote: In response to feedback, I've adjusted the new addfb2 ioctl to take per component pitch and offset args. Generally, the offset[0] field will be 0, but it's

[PATCH] drm/radeon/kms: consolidate GART code, fix segfault after GPU lockup V2

From: Jerome Glisse jgli...@redhat.com After GPU lockup VRAM gart table is unpinned and thus its pointer becomes unvalid. This patch move the unpin code to a common helper function and set pointer to NULL so that page update code can check if it should update GPU page table or not. That way bo

[RFC] Virtual CRTCs (proposal + experimental code)

Hi everyone, I would like to bring to the attention of dri-devel and linux-fbdev community a set of hopefully useful and interesting patches that I (and a few other colleagues) have been working on during the past few months. Here, I will provide a short abstract, so that you can decide whether

[Bug 41569] [r600 KMS] Asus A53T A4-3400

https://bugs.freedesktop.org/show_bug.cgi?id=41569 --- Comment #8 from Anisse Astier ani...@astier.eu 2011-11-03 09:17:28 PDT --- As I said to Alex on IRC, these patches also solves the issue on Toshiba laptops: C670D-10C (AMD E-240) and C670D-11K (AMD E-450). (Old reference:

Re: [RFC] Virtual CRTCs (proposal + experimental code)

Am 03.11.2011 16:59, schrieb Ilija Hadzic: Hi everyone, I would like to bring to the attention of dri-devel and linux-fbdev community a set of hopefully useful and interesting patches that I (and a few other colleagues) have been working on during the past few months. Here, I will provide a

Re: [RFC] Virtual CRTCs (proposal + experimental code)

On Thu, 3 Nov 2011, Roland Scheidegger wrote: Am I right in assuming this could also be used for making muxless hybrid GPUs work (i.e. radeon/intel igp)? Yes, this is actually one of the scenarios on my wish list too. In the terminology that I defined with the introduction of VCRTCM, IGP

Re: [RFC] Virtual CRTCs (proposal + experimental code)

Hi, Quick question: How does this compare to Dave Airlies' PRIME buffer sharing work for drm respectively the more generic dma_buf buffer sharing work pushed by Linaro? You seem to aim for a solution for similar problems (judging by your description) using a rather different approach. Cheers,

Re: [RFC] Virtual CRTCs (proposal + experimental code)

Hi everyone, I would like to bring to the attention of dri-devel and linux-fbdev community a set of hopefully useful and interesting patches that I (and a few other colleagues) have been working on during the past few months. Here, I will provide a short abstract, so that you can decide

Re: [PATCH] DRM planes

Hi all, I've discussed this a bit on irc and consensus seems to be some ugliness due to interface impendance mistmatches in the kernel? who cares I agree that there's not a fundamental problem with fourcc and planar yuv that can't be fixed with a bunch of boilerplate code with the assorted

  1   2   >