drm pixel formats update

On Wed, Nov 16, 2011 at 07:54:12PM +, Alan Cox wrote: > > If anyone has problems with the way the formats are defined, please > > speak up now! Since only Jesse has bothered to comment on my rantings > > I can only assume people are happy with my approach to things. > > Umm .. no. I don't see

[Bug 42999] Notebook with AMD 6520G (A6-3400M) does not resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=42999 --- Comment #3 from interweiss at yahoo.ca 2011-11-16 15:03:59 PST --- Created attachment 53613 --> https://bugs.freedesktop.org/attachment.cgi?id=53613 xorg log Here is my xorg log. -- Configure bugmail:

[Bug 42999] Notebook with AMD 6520G (A6-3400M) does not resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=42999 --- Comment #2 from interweiss at yahoo.ca 2011-11-16 15:00:15 PST --- Created attachment 53612 --> https://bugs.freedesktop.org/attachment.cgi?id=53612 dmesg output Here is my dmesg output. -- Configure bugmail:

[PATCH 4/4] gma500: Move the API

From: Alan Cox Finally move the API where it can be seen Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/cdv_device.c |2 - drivers/gpu/drm/gma500/gem.c |2 - drivers/gpu/drm/gma500/intel_bios.c |2 -

[PATCH 3/4] gma500: kill off NUM_PIPE define

From: Alan Cox We don't want this external in case someone adds more to the hardware. We want it out of the ABI. Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/psb_drm.h |3 --- drivers/gpu/drm/gma500/psb_drv.h |2 ++ 2 files changed, 2 insertions(+), 3

[PATCH 2/4] gma500: Rename the ioctls to avoid clashing with the legacy drivers

From: Alan Cox Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/gem.c |4 ++-- drivers/gpu/drm/gma500/psb_drm.h | 20 ++-- drivers/gpu/drm/gma500/psb_drv.c | 16 3 files changed, 20 insertions(+), 20 deletions(-) diff

[PATCH 1/4] gma500: begin pruning dead bits of API

From: Alan Cox At this point we won't add an external set of definitions. We want to get everything out before we admit to a public API beyond the standardised ones. Signed-off-by: Alan Cox --- drivers/gpu/drm/gma500/psb_drm.h | 159 ++--

[Bug 43000] huge performance regression in ut2004 since 7.11

https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #3 from Ian Romanick 2011-11-16 14:25:23 PST --- If this was a recent change, I'll guess that it will bisect to my changes to the way uniforms are handled. I pushed a patch today that may restore previous performance: commit

[RFC PATCH] drm: Fix off-by-one races on vblank disable

There are two possible races when disabling vblanks. If the IRQ fired but the hardware didn't update its counter yet, then we store too low a hardware counter. (Sensible hardware never does this. Apparently not all hardware is sensible.) If, on the other hand, the counter updated but the IRQ

[PATCH 3/3 v2] drm/i915: hot removal notification to HDMI audio driver

On monitor hot removal: 1) clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE 2) clear ELD Valid bit So that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. cc: Wang Zhenyu Signed-off-by: Wu Fengguang ---

[Intel-gfx] [RFC] Reduce idle vblank wakeups

On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett wrote: > On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote: >> On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote: >> >For Radeon, I'd have thought you could handle this by scheduling >> >an irq >> >for the beginning of scanout (avivo

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

Sorry forgot to remove this left over chunk... Note that I've not yet got the hardware to test the DisplayPort part of this patch, but should be able to do so this week. > --- linux.orig/drivers/gpu/drm/i915/intel_drv.h 2011-11-16 > 20:54:27.0 +0800 > +++

drm pixel formats update

> I think the only format in my list where I didn't use an existing fourcc > is I420/IYUV. And BTW, for that one I used the same "fake" fourcc that Right but you redefine all sorts of stuff in the driver in your patch to non FourCC names which is just confusing (and painful given the format

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

An embedded and charset-unspecified text was scrubbed... Name: eld-hot-removal URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111116/abe8b563/attachment.asc>

[PATCH 2/3] drm/i915: dont trigger hotplug events on unchanged ELD

An embedded and charset-unspecified text was scrubbed... Name: no-extra-eld-passing URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111116/01c9d33c/attachment.asc>

[PATCH 1/3] drm/i915: fix ELD writing for SandyBridge

An embedded and charset-unspecified text was scrubbed... Name: sandybridge-eld-fix URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111116/914003d5/attachment.asc>

[PATCH 0/3] HDMI ELD fixes for 3.2

Keith, Here are 3 fixes on HDMI/ELD audio. The third one adds a ->hot_remove hook to drm_connector_funcs. Please review. [PATCH 1/3] drm/i915: fix ELD writing for SandyBridge [PATCH 2/3] drm/i915: dont trigger hotplug events on unchanged ELD [PATCH 3/3] drm/i915: hot removal notification to

[PATCH 2/2] drm: Redefine pixel formats

From: Ville Syrj?l? Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent names, especially for the RGB formats. Component order and byte order are now strictly specified for each format. The RGB format naming follows a convention where the

[PATCH 1/2] 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

drm pixel formats update

I decided to go all out with the pixel format definitions. Added pretty much all of the possible RGB/BGR variations. Just left out ones with 16bit components and floats. Also added a whole bunch of YUV formats, and 8 bit pseudocolor for good measure. I'm sure some of the fourccs now clash with

[PATCH 2/2] drm: Redefine pixel formats

Hi Ville, Regarding 3 plane YCbCr, DRM_FORMAT_yuv444 (non sub-sampled YCbCr) would also be useful. -Ilyes On Wed, Nov 16, 2011 at 7:42 PM, wrote: > From: Ville Syrj?l? > > Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent > names, especially for the RGB formats.

[Bug 42960] Display does not work when resuming from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #1 from Sandeep 2011-11-16 20:01:12 UTC --- Created attachment 53615 --> https://bugs.freedesktop.org/attachment.cgi?id=53615 glxinfo output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You

drm pixel formats update

> If anyone has problems with the way the formats are defined, please > speak up now! Since only Jesse has bothered to comment on my rantings > I can only assume people are happy with my approach to things. Umm .. no. I don't see why they are needed. Its just an extra layer of gratuitious

[Bug 43000] huge performance regression in ut2004 since 7.11

https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #2 from almos 2011-11-16 11:52:30 PST --- The hw is barts pro (hd6850). The only part changed is mesa: 7.11 is installed (debian unstable), and I compiled one from git. In the latter case I start programs as

[Bug 42999] Notebook with AMD 6520G (A6-3400M) does not resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=42999 --- Comment #1 from Alex Deucher 2011-11-16 11:45:32 PST --- I doubt you are using radeonhd. Please attach your xorg log and dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving

[Bug 43000] huge performance regression in ut2004 since 7.11

https://bugs.freedesktop.org/show_bug.cgi?id=43000 --- Comment #1 from Alex Deucher 2011-11-16 11:42:52 PST --- What hardware are you using? Is mesa the only part that changed or did you also update your kernel and/or ddx? If it's just mesa, can you bisect? If it's multiple parts that you

[Bug 42999] Notebook with AMD 6520G (A6-3400M) does not resume from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=42999 Alex Deucher changed: What|Removed |Added AssignedTo|eich at pdx.freedesktop.org|dri-devel at lists.freedesktop

[Bug 43000] New: huge performance regression in ut2004 since 7.11

https://bugs.freedesktop.org/show_bug.cgi?id=43000 Bug #: 43000 Summary: huge performance regression in ut2004 since 7.11 Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status:

[RFC] Reduce idle vblank wakeups

On Nov 16, 2011, at 6:11 PM, Matthew Garrett wrote: > On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel D?nzer wrote: > >> I thought the main reason for the delay wasn't broken hardware but to >> avoid constantly ping-ponging the vblank IRQ between on and off with >> apps which regularly neeed

drm pixel formats update

> I decided to go all out with the pixel format definitions. Added pretty > much all of the possible RGB/BGR variations. Just left out ones with > 16bit components and floats. Also added a whole bunch of YUV formats, > and 8 bit pseudocolor for good measure. Thank you for including the

[RFC] Reduce idle vblank wakeups

On Wed, Nov 16, 2011 at 07:27:51PM +0100, Mario Kleiner wrote: > It's not broken hardware, but fast ping-ponging it on and off can > make the vblank counter and vblank timestamps unreliable for apps > that need high timing precision, especially for the ones that use > the OML_sync_control

[Bug 42998] New: [r600g] Regression: EVE Online graphics borked again (bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=42998 Bug #: 42998 Summary: [r600g] Regression: EVE Online graphics borked again (bisected) Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64)

Strange effect with i915 backlight controller

At Wed, 16 Nov 2011 13:58:57 +0100, Daniel Mack wrote: > > On 11/14/2011 11:39 AM, Takashi Iwai wrote: > > OK, then perhaps a better fix is to change the check to be equivalent > > with pineview, as you mentioned in the original post. The handling of > > bit 0 for old chips was lost during the

[RFC] Reduce idle vblank wakeups

On Mit, 2011-11-16 at 09:20 -0500, Matthew Garrett wrote: > The drm core currently waits 5 seconds from userspace dropping a request > for vblanks to vblanks actually being disabled. This appears to be a > workaround for broken hardware, but results in a mostly idle desktop > generating a huge

[PATCH 00/23] kill drm cruft with fire

On Mon, Nov 14, 2011 at 17:10, James Simmons wrote: >> > Should I test this set of patches for the VIA driver or wait until you >> > have a second version of this patch? >> >> Testing this on via would be awesome! Iirc I haven't changed anything in >> the via specific patches, but if it's more

[Bug 42997] [R600] Corruption after resume from suspend to ram

https://bugs.freedesktop.org/show_bug.cgi?id=42997 --- Comment #4 from Thomas Wendt 2011-11-16 09:15:13 PST --- Created attachment 53608 --> https://bugs.freedesktop.org/attachment.cgi?id=53608 dmesg output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ---

[Bug 42997] [R600] Corruption after resume from suspend to ram

https://bugs.freedesktop.org/show_bug.cgi?id=42997 --- Comment #3 from Alex Deucher 2011-11-16 09:13:24 PST --- Please attach your dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee

[Bug 42997] [R600] Corruption after resume from suspend to ram

https://bugs.freedesktop.org/show_bug.cgi?id=42997 Alex Deucher changed: What|Removed |Added Attachment #53605|text/x-log |text/plain mime type|

[RFC] Reduce idle vblank wakeups

On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel D?nzer wrote: > I thought the main reason for the delay wasn't broken hardware but to > avoid constantly ping-ponging the vblank IRQ between on and off with > apps which regularly neeed the vblank counter value, as that could make > the counter

[Bug 42997] [R600] Corruption after resume from suspend to ram

https://bugs.freedesktop.org/show_bug.cgi?id=42997 --- Comment #2 from Thomas Wendt 2011-11-16 09:05:23 PST --- Created attachment 53607 --> https://bugs.freedesktop.org/attachment.cgi?id=53607 Screenshot of the corruption -- Configure bugmail:

[Bug 42997] [R600] Corruption after resume from suspend to ram

https://bugs.freedesktop.org/show_bug.cgi?id=42997 --- Comment #1 from Thomas Wendt 2011-11-16 09:04:56 PST --- Created attachment 53606 --> https://bugs.freedesktop.org/attachment.cgi?id=53606 Screenshot of the corruption -- Configure bugmail:

[Bug 42997] New: [R600] Corruption after resume from suspend to ram

https://bugs.freedesktop.org/show_bug.cgi?id=42997 Bug #: 42997 Summary: [R600] Corruption after resume from suspend to ram Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux

[Bug 42998] [r600g] Regression: EVE Online graphics borked again (bisected)

https://bugs.freedesktop.org/show_bug.cgi?id=42998 --- Comment #1 from Vadim 2011-11-16 16:47:41 UTC --- This patch should help: http://lists.freedesktop.org/archives/mesa-dev/2011-November/014688.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are

[PATCH] drm/i915: Hook up Ivybridge eDP

The Ivybridge eDP control register looks like a cross between a Cougarpoint PCH DP control register and a Sandybridge eDP control register. Where things trivially match, share the code. Where there are any tricky bits, just split things out into two obviously separate code paths. Signed-off-by:

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

> So generally we need to provide a userspace interface via ioctls, we > do this with a shared header file that goes in include/drm/ with the > Kbuild bits At the moment the only public API is the generic bits. > Now I'm assuming psb_drm.h is meant to be this file? but as-is its not > really

[PATCH] drm/radeon: introduce a sub allocator and convert ib pool to it

From: Jerome Glisse Somewhat specializaed sub-allocator designed to perform sub-allocation for command buffer not only for current cs ioctl but for future command submission ioctl as well. Patch also convert current ib pool to use the sub allocator. Idea is that ib poll

[PATCH] drm/radeon: introduce a sub allocator and convert ib pool to it

On Wed, Nov 16, 2011 at 2:18 PM, wrote: > From: Jerome Glisse > > Somewhat specializaed sub-allocator designed to perform sub-allocation > for command buffer not only for current cs ioctl but for future command > submission ioctl as well. Patch also convert current ib pool to use > the sub

[PATCH] drm/radeon: introduce a sub allocator and convert ib pool to it

From: Jerome Glisse Somewhat specializaed sub-allocator designed to perform sub-allocation for command buffer not only for current cs ioctl but for future command submission ioctl as well. Patch also convert current ib pool to use the sub allocator. Idea is that ib poll

Strange effect with i915 backlight controller

On 11/14/2011 11:39 AM, Takashi Iwai wrote: > OK, then perhaps a better fix is to change the check to be equivalent > with pineview, as you mentioned in the original post. The handling of > bit 0 for old chips was lost during the refactoring of backlight code > since 2.6.37. > > Does the patch

drm pixel formats update

re Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2016/1724ce93/attachment.pgp>

[PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V3

> >> -int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev); > >> -extern void ttm_dma_unpopulate(struct ttm_tt *ttm, struct device *dev); > >> +int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev); > >> +extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct

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

On Thu, Nov 3, 2011 at 6:22 PM, Alan Cox wrote: > 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. I've started merging it, and my main review focus is as always the userspace

[PATCH 14/14] drm/ttm: simplify memory accounting for ttm user

From: Jerome Glisse Provide helper function to compute the kernel memory size needed for each buffer object. Move all the accounting inside ttm, simplifying driver and avoiding code duplication accross them. Signed-off-by: Jerome Glisse ---

[PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V4

From: Jerome Glisse Move dma data to a superset ttm_dma_tt structure which herit from ttm_tt. This allow driver that don't use dma functionalities to not have to waste memory for it. V2 Rebase on top of no memory account changes (where/when is my delorean when i need it

[PATCH 12/14] drm/nouveau: enable the ttm dma pool when swiotlb is active V3

From: Konrad Rzeszutek Wilk If the card is capable of more than 32-bit, then use the default TTM page pool code which allocates from anywhere in the memory. Note: If the 'ttm.no_dma' parameter is set, the override is ignored and the default TTM pool is used. V2 use

[PATCH 11/14] drm/radeon/kms: enable the ttm dma pool if swiotlb is on V4

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. V2 force dma32 if we fail to set bigger dma mask V3 Rebase on top of no

[PATCH 10/14] drm/ttm: provide dma aware ttm page pool code V9

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 09/14] drm/ttm: introduce callback for ttm_tt populate & unpopulate V4

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. V2

[PATCH 08/14] drm/ttm: merge ttm_backend and ttm_tt V5

From: Jerome Glisse ttm_backend will only exist with a ttm_tt, and ttm_tt will only be of interest when bound to a backend. Merge them to avoid code and data duplication. V2 Rebase on top of memory accounting overhaul V3 Rebase on top of more memory accounting changes V4

[PATCH 07/14] drm/ttm: page allocation use page array instead of list

From: Jerome Glisse Use the ttm_tt pages array for pages allocations, move the list unwinding into the page allocation functions. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 85 +- drivers/gpu/drm/ttm/ttm_tt.c

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

From: Jerome Glisse Signed-off-by: Jerome Glisse Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Thomas Hellstrom --- 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 05/14] 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 Reviewed-by: Thomas Hellstrom ---

[PATCH 04/14] 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 Reviewed-by: Thomas Hellstrom --- drivers/gpu/drm/radeon/radeon_ttm.c |1 - include/drm/ttm/ttm_bo_driver.h |2 -- 2

[PATCH 03/14] 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 02/14] 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

[PATCH 01/14] 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 ---

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V6

Respin some of the patch with syntax/typo fix + patch 10 with proper memory accounting of page being free. Cheers, Jerome

[PATCH 11/14] drm/radeon/kms: enable the ttm dma pool if swiotlb is on V3

On Wed, Nov 16, 2011 at 10:46:57AM -0500, Konrad Rzeszutek Wilk wrote: > > +#ifdef CONFIG_SWIOTLB > > + if (swiotlb_nr_tbl()) { > > + return ttm_dma_populate(ttm, rdev->dev); > > + } > > +#endif > .. > > +#ifdef CONFIG_SWIOTLB > > + if (swiotlb_nr_tbl()) { > > +

[PATCH 10/14] drm/ttm: provide dma aware ttm page pool code V8

On Wed, Nov 16, 2011 at 10:50:01AM -0500, Konrad Rzeszutek Wilk wrote: > > +int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev) > > +{ > .. snip.. > > > + for (i = 0; i < ttm->num_pages; ++i) { > > + ret = ttm_dma_pool_get_pages(pool, ttm, i); > > + if (ret != 0) {

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

> > which I think was your V4 posting (or earlier) (the last patch is something > > I added > > to toggle it off/on to test). > > You have to allocate like a million of gem object to trigger it. > Which I certainly did not, but I did find an accounting error in the rebased v5 version of the

[PATCH 10/14] drm/ttm: provide dma aware ttm page pool code V8

> +int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev) > +{ .. snip.. > + for (i = 0; i < ttm->num_pages; ++i) { > + ret = ttm_dma_pool_get_pages(pool, ttm, i); > + if (ret != 0) { > + ttm_dma_unpopulate(ttm, dev); > +

[PATCH 11/14] drm/radeon/kms: enable the ttm dma pool if swiotlb is on V3

> +#ifdef CONFIG_SWIOTLB > + if (swiotlb_nr_tbl()) { > + return ttm_dma_populate(ttm, rdev->dev); > + } > +#endif .. > +#ifdef CONFIG_SWIOTLB > + if (swiotlb_nr_tbl()) { > + ttm_dma_unpopulate(ttm, rdev->dev); > + return; > + } > +#endif >

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

On Wed, Nov 16, 2011 at 10:15 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 14, 2011 at 01:54:27PM -0500, Jerome Glisse wrote: >> On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote: >> > On 11/14/2011 05:02 PM, Jerome Glisse wrote: >> > >On Mon, Nov 14, 2011 at 9:49 AM, Thomas

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

On Mon, Nov 14, 2011 at 01:54:27PM -0500, Jerome Glisse wrote: > On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote: > > On 11/14/2011 05:02 PM, Jerome Glisse wrote: > > >On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom > >vmware.com> wrote: > > >>On 11/11/2011 11:47 PM, j.glisse

[Intel-gfx] [RFC] Reduce idle vblank wakeups

2011/11/16 Matthew Garrett : > On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel D?nzer wrote: > >> I thought the main reason for the delay wasn't broken hardware but to >> avoid constantly ping-ponging the vblank IRQ between on and off with >> apps which regularly neeed the vblank counter value,

[RFC] Reduce idle vblank wakeups

ttp://lists.freedesktop.org/archives/dri-devel/attachments/2016/d60abb9d/attachment.pgp>

[RFC 3/3] i915: Drop vblank_offdelay

Sandybridge, at least, seems to manage without any vblank offdelay. Dropping this reduces the number of wakeups on an otherwise idle system dramatically. Signed-off-by: Matthew Garrett --- drivers/gpu/drm/i915/i915_dma.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git

[RFC 2/3] drm: Handle the vblank_offdelay=0 case properly

Right now if vblank_offdelay is 0, vblanks won't be disabled after the last user. Fix that case up. Signed-off-by: Matthew Garrett --- drivers/gpu/drm/drm_irq.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index

[RFC 1/3] drm: Make drm_vblank_offdelay per-device

drm_vblank_offdelay is currently a system global, despite the optimal value being hardware-specific. Move it to the drm_device structure. Signed-off-by: Matthew Garrett --- drivers/gpu/drm/drm_irq.c |6 +++--- drivers/gpu/drm/drm_stub.c |8 +--- include/drm/drmP.h |2 +-

[RFC] Reduce idle vblank wakeups

The drm core currently waits 5 seconds from userspace dropping a request for vblanks to vblanks actually being disabled. This appears to be a workaround for broken hardware, but results in a mostly idle desktop generating a huge number of wakeups that are entirely unnecessary but which consume

[PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

A call to i915_add_request() has been made in function i915_gem_busy_ioctl(). i915_add_request can fail, so in it's exit path previously allocated memory needs to be freed. Signed-off-by: Rakib Mullick --- diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index

RFC: Radeon multi ring support branch

On 15.11.2011 20:32, Jerome Glisse wrote: > On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K?nig wrote: >> Hello everybody, >> >> to support multiple compute rings, async DMA engines and UVD we need >> to teach the radeon kernel module how to sync buffers between >> different rings and make

radeon/kms: black screen when loading radeon with modeset=1

On Tuesday 15 of November 2011 23:21:10 Alex Deucher wrote: > On Tue, Nov 15, 2011 at 2:05 PM, Sergey V. wrote: > > Kernel from Linus tree, HEAD at 7f80850d3f9fd8fda23a317044aef3a6bafab06b > > > > Loading radeon module with modeset=1 causes black screen. > > > > Usually it happens at boot time,

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

On Thu, Nov 3, 2011 at 6:22 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: From: Alan Cox a...@linux.intel.com Not really a nice way to split this up further for submission. This provides all the DRM interfacing logic, the headers and relevant glue. I've started merging it, and my main review

Re: Strange effect with i915 backlight controller

On 11/14/2011 11:39 AM, Takashi Iwai wrote: OK, then perhaps a better fix is to change the check to be equivalent with pineview, as you mentioned in the original post. The handling of bit 0 for old chips was lost during the refactoring of backlight code since 2.6.37. Does the patch below

[PATCH 0/3] HDMI ELD fixes for 3.2

Keith, Here are 3 fixes on HDMI/ELD audio. The third one adds a -hot_remove hook to drm_connector_funcs. Please review. [PATCH 1/3] drm/i915: fix ELD writing for SandyBridge [PATCH 2/3] drm/i915: dont trigger hotplug events on unchanged ELD [PATCH 3/3] drm/i915: hot removal notification to HDMI

[PATCH 2/3] drm/i915: dont trigger hotplug events on unchanged ELD

The ELD may or may not change when switching the video mode. If unchanged, don't trigger hot plug events to HDMI audio driver. This avoids disturbing the user with repeated printks. Reported-by: Nick Bowler nbow...@elliptictech.com Signed-off-by: Wu Fengguang fengguang...@intel.com ---

[PATCH 1/3] drm/i915: fix ELD writing for SandyBridge

SandyBridge should be using the same register addresses as IvyBridge. Signed-off-by: Wu Fengguang fengguang...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |6 +++--- drivers/gpu/drm/i915/intel_display.c | 10 +- 2 files changed, 8 insertions(+), 8 deletions(-) ---

[PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

On monitor hot removal: 1) clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE 2) clear ELD Valid bit So that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. cc: Wang Zhenyu zhenyu.z.w...@intel.com Signed-off-by: Wu Fengguang

Re: [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver

Sorry forgot to remove this left over chunk... Note that I've not yet got the hardware to test the DisplayPort part of this patch, but should be able to do so this week. --- linux.orig/drivers/gpu/drm/i915/intel_drv.h 2011-11-16 20:54:27.0 +0800 +++

[PATCH 3/3 v2] drm/i915: hot removal notification to HDMI audio driver

On monitor hot removal: 1) clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE 2) clear ELD Valid bit So that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. cc: Wang Zhenyu zhenyu.z.w...@intel.com Signed-off-by: Wu Fengguang

[RFC] Reduce idle vblank wakeups

The drm core currently waits 5 seconds from userspace dropping a request for vblanks to vblanks actually being disabled. This appears to be a workaround for broken hardware, but results in a mostly idle desktop generating a huge number of wakeups that are entirely unnecessary but which consume

[RFC 1/3] drm: Make drm_vblank_offdelay per-device

drm_vblank_offdelay is currently a system global, despite the optimal value being hardware-specific. Move it to the drm_device structure. Signed-off-by: Matthew Garrett m...@redhat.com --- drivers/gpu/drm/drm_irq.c |6 +++--- drivers/gpu/drm/drm_stub.c |8 +--- include/drm/drmP.h

[RFC 2/3] drm: Handle the vblank_offdelay=0 case properly

Right now if vblank_offdelay is 0, vblanks won't be disabled after the last user. Fix that case up. Signed-off-by: Matthew Garrett m...@redhat.com --- drivers/gpu/drm/drm_irq.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c

[RFC 3/3] i915: Drop vblank_offdelay

Sandybridge, at least, seems to manage without any vblank offdelay. Dropping this reduces the number of wakeups on an otherwise idle system dramatically. Signed-off-by: Matthew Garrett m...@redhat.com --- drivers/gpu/drm/i915/i915_dma.c |3 +++ 1 files changed, 3 insertions(+), 0

Re: [RFC] Reduce idle vblank wakeups

On Wed, 2011-11-16 at 09:20 -0500, Matthew Garrett wrote: The drm core currently waits 5 seconds from userspace dropping a request for vblanks to vblanks actually being disabled. This appears to be a workaround for broken hardware, but results in a mostly idle desktop generating a huge number

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

So generally we need to provide a userspace interface via ioctls, we do this with a shared header file that goes in include/drm/ with the Kbuild bits At the moment the only public API is the generic bits. Now I'm assuming psb_drm.h is meant to be this file? but as-is its not really what I'd

Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V5

On Mon, Nov 14, 2011 at 01:54:27PM -0500, Jerome Glisse wrote: On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote: On 11/14/2011 05:02 PM, Jerome Glisse wrote: On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstromthellst...@vmware.com wrote: On 11/11/2011 11:47 PM,

Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V5

On Wed, Nov 16, 2011 at 10:15 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Mon, Nov 14, 2011 at 01:54:27PM -0500, Jerome Glisse wrote: On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote: On 11/14/2011 05:02 PM, Jerome Glisse wrote: On Mon, Nov 14, 2011 at 9:49 AM,

Re: [PATCH 11/14] drm/radeon/kms: enable the ttm dma pool if swiotlb is on V3

+#ifdef CONFIG_SWIOTLB + if (swiotlb_nr_tbl()) { + return ttm_dma_populate(ttm, rdev-dev); + } +#endif .. +#ifdef CONFIG_SWIOTLB + if (swiotlb_nr_tbl()) { + ttm_dma_unpopulate(ttm, rdev-dev); + return; + } +#endif +#ifdef

  1   2   >