[PATCH] drm/radeon: fix typo in trinity tiling setup

From: Alex Deucher Using the wrong union. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/ni.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c

[PATCH 0/4] drm/i915: Make video sprites survive a modeset

On Thu, May 24, 2012 at 08:49:53PM +0200, Daniel Vetter wrote: > On Thu, May 24, 2012 at 11:35:35AM -0700, Jesse Barnes wrote: > > On Thu, 24 May 2012 21:29:46 +0300 > > ville.syrjala at linux.intel.com wrote: > > > > > Currently the video sprites appear to get disabled on modeset more by > > >

[Bug 50325] Glyphy bad render on r600g (software render is fine)

https://bugs.freedesktop.org/show_bug.cgi?id=50325 --- Comment #2 from T?r?k Edwin 2012-05-24 14:57:24 PDT --- Created attachment 62080 --> https://bugs.freedesktop.org/attachment.cgi?id=62080 sw-good.png -- Configure bugmail:

[Bug 50325] Glyphy bad render on r600g (software render is fine)

https://bugs.freedesktop.org/show_bug.cgi?id=50325 --- Comment #1 from T?r?k Edwin 2012-05-24 14:57:08 PDT --- Created attachment 62079 --> https://bugs.freedesktop.org/attachment.cgi?id=62079 r600g-bad.png -- Configure bugmail:

[Bug 50325] New: Glyphy bad render on r600g (software render is fine)

https://bugs.freedesktop.org/show_bug.cgi?id=50325 Bug #: 50325 Summary: Glyphy bad render on r600g (software render is fine) Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux

[PATCH 2/3] drm: Be more paranoid with integer overflows

On Thu, May 24, 2012 at 08:30:23PM +0200, Daniel Vetter wrote: > On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > Make sure 'width * cpp' and 'height * pitch + offset' don't exceed > > UINT_MAX. > > > > Signed-off-by: Ville

[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote: > On Thu, 24 May 2012 21:08:58 +0300 > ville.syrjala at linux.intel.com wrote: > > > From: Ville Syrj?l? > > > > Take fb->offset[0] into account when calculating the linear and tile x/y > > offsets. > > > > For non-tiled surfaces

[PATCH 4/4] drm/i915: Implement restore_fbdev_mode hook

From: Ville Syrj?l? Convert intel_fb_restore_mode to be useable as the drm_fb_helper.restore_fbdev_mode hook. This will cause all planes to be disabled when swithing back to fbcon. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/i915_dma.c |2 +-

[PATCH 3/4] drm/i915: Disable/enable planes around mode set

From: Ville Syrj?l? When setting a display mode, disable all planes on the CRTC beforehand, and re-enable them after the new mode has been set. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 48 ++ 1

[PATCH 1/4] drm: Keep a copy of last plane coordinates

From: Ville Syrj?l? If the update_plane() operation succeeds, make a copy of the requested src and crtc coordinates, so that the the plane may be reclipped if the display mode changed later. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c |8

[PATCH 14/14] drm/i915: s/mdelay/msleep/ in the sdvo detect function

A 30 ms delay is simply way too big to waste cpu cycles on. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_sdvo.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 6056603..efa0d17

[PATCH 13/14] drm/i915/sdvo: implement correct return value for ->get_modes

We should return the number of added modes. Luckily no one really cares, but it kinda sticked out compared to the other ->get_modes functions I've looked at recently. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_sdvo.c | 41 ++-- 1 files changed,

[PATCH 12/14] drm/i915: cache hdmi edid

Like the previous patches. While at it also kill a stale comment - we've moved hdmi audio detection from ->get_modes to ->detect and the audio property handling functions. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_hdmi.c | 48

[PATCH 11/14] drm/i915: cache dp edid

Again, let's be slightly more clever here. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_dp.c | 47 ++ 1 files changed, 22 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index

[PATCH 10/14] drm/i915: cache crt edid

Let's put all this new output detection infrastructure and rework to some good use and cache the crt edid. Given that the drm helpers now only call ->detect when actually required, we only need to reset the edid there and can keep it otherwise. Slashes xrandr time on systems that are hotplug

[PATCH 09/14] drm: don't poll forced connectors

Otherwise if the detect callback reports a different state than what the user forced (rather likely), we continously annoy userspace about a hotplug uevent. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc_helper.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff

[PATCH 08/14] drm: don't unnecessarily enable the polling work

... by properly checking connector->polled. This doesn't matter too much because the polling work itself gets this slightly more right and doesn't set repoll if there's nothing to do. But we can do better. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc_helper.c |6 ++ 1 files

[PATCH 07/14] drm: don't start the poll engine in probe_single_connector

Actually there's a reason this stuff is there, and it's called commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9 Author: Chris Wilson Date: Fri Aug 20 09:13:36 2010 +0100 drm/kms: Add a module parameter to disable polling The idea has been that users can enable/disable polling at runtime.

[PATCH 06/14] drm: kill unnecessary calls to connector->detect

Only call that function if something has actually changed (i.e. in the output polling or hdp handling functions) or when userspace asks for the information and DRM_CONNECTOR_POLL_FORCE is set. Let's see how many bugs this uncovers. v2: Run ->detect if the current connector status is 'unknown' -

[PATCH 05/14] drm: properly init/reset connector status

We need this because otherwise the improved connector code has no idea when it needs to run the ->detect callback after boot/resume on all connectors. Because drm/i915 is the only driver that properly calls mode_config_reset at resume time, this will horribly blow up everywhere else.

[PATCH 03/14] drm: introduce DRM_CONNECTOR_POLL_FORCE

Useful for ->detect functions that have different behaviour if force is set. This way probe_single_connector can avoid to do the expensive edid dance on connectors where this is not needed. I've checked through all drivers and set this flag everywhere where the connector->detect function has

[PATCH 01/14] drm: extract drm_kms_helper_hotplug_event

Useful if drivers want to be slightly more clever about hotplug handling. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc_helper.c | 17 +++-- include/drm/drm_crtc_helper.h |1 + 2 files changed, 12 insertions(+), 6 deletions(-) diff --git

[RFC] [PATCH 00/14] HPD/connector-polling rework

Hi all, I've got fed up with our sorry state of connector detection and rampant edid re and rere-reading. This patch series lays the groundwork in the drm helpers so that drivers can avoid all this madness (at least on working hw) and properly cache the edid. With the additional changes for

[PATCH 5/5] drm/i915: Bad pixel formats can't reach the sprite code

From: Ville Syrj?l? The framebuffer pixel format is already checked by the common code. So there's no way an invalid format could reach the driver. So instead of falling back to a default format, call BUG(). Signed-off-by: Ville Syrj?l? ---

[PATCH 4/5] drm/i915: pixel_size == cpp

From: Ville Syrj?l? Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_sprite.c | 19 +++ 1 files changed, 3 insertions(+), 16 deletions(-) diff --git

[PATCH 3/5] drm/i915: Implement proper clipping for video sprites

From: Ville Syrj?l? Properly clip the source when the destination gets clipped by the pipe dimensions. Sadly the video sprite hardware is rather limited so it can't do proper sub-pixel postitioning. Resort to a best effort approach, where the source coordinates

[PATCH 2/5] drm: Add drm_calc_{hscale, vscale}() utility functions

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

[PATCH 1/5] 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.c | 155

[PATCH 0/5] drm/i915: Clip video sprites properly

First add a bit of helper functions to aid in the clipping duties (those patches were already posted a long time ago) and then utilize them to properly clip the video sprites to the pipe dimensions. I also threw in a few small cleanup patches dealing with the sprite code.

[PATCH 6/6] drm/i915: Reject page flips with changed format/offset/pitch

From: Ville Syrj?l? MI display flips can't handle some changes in the framebuffer format or layout. Return an error in such cases. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 13 + 1 files changed, 13 insertions(+), 0

[PATCH 5/6] drm/i915: Handle framebuffer offsets[]

From: Ville Syrj?l? Take fb->offset[0] into account when calculating the linear and tile x/y offsets. For non-tiled surfaces fb->offset[0] is simply added to the linear byte offset. For tiled surfaces treat fb->offsets[0] as a byte offset into the linearized view

[PATCH 4/6] drm/i915: Check the framebuffer offset

From: Ville Syrj?l? The framebuffer offset must be aligned to (macro)pixel size. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git

[PATCH 3/6] drm/i915: Zero initialize mode_cmd

From: Ville Syrj?l? Zero initialize the mode_cmd structure when creating the kernel framebuffer. Avoids having uninitialized data in offsets[0] for instance. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_fb.c |2 +- 1 files changed, 1

[PATCH 2/6] drm/i915: Check framebuffer stride more thoroughly

From: Ville Syrj?l? Make sure the the framebuffer stride is smaller than the maximum accepted by any plane. Also when using a tiled memory make sure the object stride matches the framebuffer stride. Signed-off-by: Ville Syrj?l? ---

[PATCH 1/6] drm/i915: Fix display pixel format handling

From: Ville Syrj?l? Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float format). Fix intel_init_framebuffer() to match hardware and driver limitations: * RGB332 is not supported at all * CI8 is supported * XRGB1555 & co. are supported on Gen3

[PATCH 0/6] drm/i915: Framebuffer layout fixes and sanity checks

Add all kinds of framebuffer layout sanity checks to the code. Also the framebuffer offset wasn't properly handled, and code dealing with the primary plane pixel format was quite broken.

[PATCH 2/3] drm: Be more paranoid with integer overflows

On Thu, May 24, 2012 at 09:54:37PM +0300, Ville Syrj?l? wrote: > On Thu, May 24, 2012 at 08:30:23PM +0200, Daniel Vetter wrote: > > On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrjala at linux.intel.com > > wrote: > > > From: Ville Syrj?l? > > > > > > Make sure 'width * cpp' and 'height *

[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote: > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote: > > On Thu, 24 May 2012 21:08:58 +0300 > > ville.syrjala at linux.intel.com wrote: > > > > > From: Ville Syrj?l? > > > > > > Take fb->offset[0] into account when

[PATCH 3/3] drm: Constify params to format_check() and framebuffer_checks()

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

[PATCH 2/3] drm: Be more paranoid with integer overflows

From: Ville Syrj?l? Make sure 'width * cpp' and 'height * pitch + offset' don't exceed UINT_MAX. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git

[PATCH 1/3] drm: Use stdint types for consistency

From: Ville Syrj?l? The rest of the code uses stdint types, so use them in drm_property_change_is_valid() as well. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 0/3] drm: A few misc patches

Just a few small items caught in my net while trawling the code.

[PATCH 0/4] drm/i915: Make video sprites survive a modeset

On Thu, May 24, 2012 at 11:35:35AM -0700, Jesse Barnes wrote: > On Thu, 24 May 2012 21:29:46 +0300 > ville.syrjala at linux.intel.com wrote: > > > Currently the video sprites appear to get disabled on modeset more by > > accient than by design. > > > > With the current API that behaviour makes

[PATCH 2/3] drm: Be more paranoid with integer overflows

On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Make sure 'width * cpp' and 'height * pitch + offset' don't exceed > UINT_MAX. > > Signed-off-by: Ville Syrj?l? > --- > drivers/gpu/drm/drm_crtc.c | 10 +- > 1 files changed,

[Bug 50232] screen redraw is wrong in sauerbraten with the llvm compiler

https://bugs.freedesktop.org/show_bug.cgi?id=50232 --- Comment #2 from almos 2012-05-24 13:25:38 PDT --- (In reply to comment #1) > Please test with the first patch from bug 50230. The revert patch fixes the ghost image problem. The warning is still printed, but the visuals seem to be good now.

[Bug 50230] offset mapping in nexuiz results in bad texturing with the llvm compiler

https://bugs.freedesktop.org/show_bug.cgi?id=50230 --- Comment #10 from almos 2012-05-24 13:25:32 PDT --- (In reply to comment #9) > Created attachment 62057 [details] [review] > [PATCH] radeon/llvm: fix sampler index in llvm_emit_tex > > Does this patch help? Yes, the patch fixes it. I also

drm/nouveau: NULL pointer deref in drm_handle_vblank() on rebind

I can easily trigger a crash in nouveau interrupt handler by unbinding and rebinding the GPU. The command used: echo $pci_device > nouveau/unbind && \ sleep 5 && \ echo $pci_device > nouveau/bind Kernel is 3.4.0 with modular drm/nouveau. GPU is NVidia nForce IGP (NV11)

[git pull] drm merge window pull

Hi Linus, this is the main merge window request for the drm, Its big, but jam packed will lots of features and of course 0 regressions. (okay maybe there'll be one). Highlights: new KMS drivers for server GPU chipsets: ast, mgag200 and cirrus (qemu only). These drivers use the generic

drm/i915 3.5 merge window: gen6_sanitize_pm errors

These guys seem to be recently introduced: [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206 [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700 This is on my

[Bug 43207] radeon driver on HD6570 shows pixel noise

https://bugzilla.kernel.org/show_bug.cgi?id=43207 --- Comment #8 from J?r?me Glisse 2012-05-24 19:13:23 --- Created an attachment (id=73382) --> (https://bugzilla.kernel.org/attachment.cgi?id=73382) Fix backend map This patch should fix your issue -- Configure bugmail:

[PATCH] omap2+: add drm device

ake your word that it's not simple =). Tomi -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/e3c5d6b2/attachment.pgp>

[pull] drm-intel-fixes for 3.5

Hi Dave, A set of fixes for 3.5: - Fixes for regressions in 3.5: fix spurious gmbus NAK, fix module unload, fix pch pll asserts. - Fix up eDP panel power sequencing - turns out we need to keep vdd on while switching everything off. - Reject doubleclocked modes on dp. - Fixup sdvo interlaced

[Linaro-mm-sig] New "xf86-video-armsoc" DDX driver

> -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: 21 May 2012 10:04 > To: Dave Airlie > Cc: Tom Cooksey; linaro-mm-sig at lists.linaro.org; xorg- > devel at lists.x.org; dri-devel at lists.freedesktop.org > Subject: Re:

[Bug 43207] radeon driver on HD6570 shows pixel noise

https://bugzilla.kernel.org/show_bug.cgi?id=43207 --- Comment #7 from Vladislav Tcendrovskii 2012-05-24 16:30:46 --- I have tested kernel 3.4. Results look a bit strange: When i use modprobe radeon, I have the same pixel noise, which I had before. If I start X, I have screen with

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

> Does the linux API mandates atomic_t to be a 32bits word? AFAIK it is, at least for the platforms we care about. ... >>> >>> Then, the proper course of action would be to add to the linux API, sized >>> atomic operation first, wouldn't it? >> >> No, atomic is fine for this, I

[Bug 50232] screen redraw is wrong in sauerbraten with the llvm compiler

https://bugs.freedesktop.org/show_bug.cgi?id=50232 --- Comment #1 from Vadim Girlin 2012-05-24 08:50:00 PDT --- Please test with the first patch from bug 50230. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You

[PATCH] omap2+: add drm device

e: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/2af85523/attachment.pgp>

[PATCH] omap2+: add drm device

t you have in mind, but it sounds a bit > hacky.. I'd guess if you need 100% backwards compatibility even down > to kernel cmdline / module params, then you probably want to use > omapfb. But there isn't really need to add new features to omapfb in > that case. I was thinking of making omapfb use omapdrm, instead of omapdss. I mean, not planning to do that, just wondering if that would be possible. > Off the top of my head, I guess that 80-90% compatibility would > probably be reasonable to add to omapdrm's fbdev.. and that the last > 10-20% would be too hacky/invasive to justify adding to omapdrm. I think it should be 99.9% - 100% or nothing. If it's only 80-90% compatible, then it's not compatible =). Tomi -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/c8ad9dc8/attachment-0001.pgp>

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

>> Does the linux API mandates atomic_t to be a 32bits word? > > AFAIK it is, at least for the platforms we care about. > ... Then, the proper course of action would be to add to the linux API, sized atomic operation first, wouldn't it? -- Sylvain

[Bug 50230] offset mapping in nexuiz results in bad texturing with the llvm compiler

https://bugs.freedesktop.org/show_bug.cgi?id=50230 --- Comment #9 from Vadim Girlin 2012-05-24 07:38:10 PDT --- Created attachment 62057 --> https://bugs.freedesktop.org/attachment.cgi?id=62057 [PATCH] radeon/llvm: fix sampler index in llvm_emit_tex Does this patch help? -- Configure

[PATCH 0/3] drm: A few misc patches

On Thu, May 24, 2012 at 1:53 PM, wrote: > Just a few small items caught in my net while trawling the code. for the series: Reviewed-by: Alex Deucher > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org >

[Bug 12434] Resume from suspend to RAM broken on ThinkPad R500

https://bugzilla.kernel.org/show_bug.cgi?id=12434 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail:

[Bug 12434] Resume from suspend to RAM broken on ThinkPad R500

https://bugzilla.kernel.org/show_bug.cgi?id=12434 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug 12342] drm_pci_alloc needs to error when alignment constraints not met

https://bugzilla.kernel.org/show_bug.cgi?id=12342 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail:

[Bug 12342] drm_pci_alloc needs to error when alignment constraints not met

https://bugzilla.kernel.org/show_bug.cgi?id=12342 Alan changed: What|Removed |Added Status|NEEDINFO|RESOLVED CC|

[PATCH] drm: fix case where panic notifier isn't unregistered

On Thu, May 24, 2012 at 10:50 AM, Frank Binns wrote: > Hi, > I don't know if this patch got missed in the list traffic or if I did > something wrong but it doesn't appear to have been picked up. This is my > first time contributing so if I did anything wrong some pointers would be >

[patch] drm/udl: unlock before returning in udl_gem_mmap()

On Thu, Mar 22, 2012 at 09:30:56AM +0300, Dan Carpenter wrote: > If we hit an error here, then we should unlock and unreference obj > before returning. > This is still present in linux-next. regards, dan carpenter > Signed-off-by: Dan Carpenter > > diff --git a/drivers/gpu/drm/udl/udl_gem.c

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

> + atomic_tring_int[RADEON_NUM_RINGS]; > boolcrtc_vblank_int[RADEON_MAX_CRTCS]; > - boolpflip[RADEON_MAX_CRTCS]; > - int pflip_refcount[RADEON_MAX_CRTCS]; > + atomic_t

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

On Thu, May 24, 2012 at 1:53 PM, Dave Airlie wrote: > On Thu, May 24, 2012 at 1:46 PM, Sylvain BERTRAND > wrote: Does the linux API mandates atomic_t to be a 32bits word? >>> >>> AFAIK it is, at least for the platforms we care about. >>> ... >> >> Then, the proper course of action would be

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

On Thu, May 24, 2012 at 1:46 PM, Sylvain BERTRAND wrote: >>> Does the linux API mandates atomic_t to be a 32bits word? >> >> AFAIK it is, at least for the platforms we care about. >> ... > > Then, the proper course of action would be to add to the linux API, sized > atomic operation first,

[Bug 12333] Radeon DRM produces kernel BUG at mm/vmalloc.c:292

https://bugzilla.kernel.org/show_bug.cgi?id=12333 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail:

[Bug 12333] Radeon DRM produces kernel BUG at mm/vmalloc.c:292

https://bugzilla.kernel.org/show_bug.cgi?id=12333 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC|

[PATCH RESEND] drm: fix case where panic notifier isn't unregistered

The framebuffer helper panic notifier is unregistered, in drm_fb_helper_fini(), when kernel_fb_helper_list goes from being non-empty to empty. However, in drm_fb_helper_single_fb_probe(), it's possible for the panic notifier to be registered without an element being added to this list if a

[PATCH] staging: omapdrm: fix crash when freeing bad fb

On Thu, May 24, 2012 at 10:44 AM, Andy Gross wrote: > During unload, don't cleanup the framebuffer if it is not valid. > > Signed-off-by: Andy Gross Reviewed-by: Rob Clark > --- > ?drivers/staging/omapdrm/omap_fbdev.c | ? 10 +++--- > ?1 files changed, 7 insertions(+), 3 deletions(-) > >

[PATCH] staging: omapdrm: fix crash when freeing bad fb

On Thu, May 24, 2012 at 10:44 AM, Andy Gross wrote: > During unload, don't cleanup the framebuffer if it is not valid. > > Signed-off-by: Andy Gross Reviewed-by: Rob Clark > --- > ?drivers/staging/omapdrm/omap_fbdev.c | ? 10 +++--- > ?1 files changed, 7 insertions(+), 3 deletions(-) > >

[PATCH] staging: omapdrm: Fix error paths during dmm init

On Thu, May 24, 2012 at 10:43 AM, Andy Gross wrote: > Failures during the dmm probe can cause the kernel to crash. ?Moved > the spinlock to a global and moved list initializations immediately > after the allocation of the dmm private structure. > > Signed-off-by: Andy Gross Reviewed-by: Rob

[PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics

> -Original Message- > From: Sylvain BERTRAND [mailto:sylware at legeek.net] > Sent: Thursday, May 24, 2012 1:59 PM > To: Christian K?nig > Cc: j.glisse at gmail.com; Koenig, Christian; dri-devel at > lists.freedesktop.org > Subject: Re: [PATCH 08/10] drm/radeon: replace pflip and sw_int

[PATCH 06/10] drm/radeon: fix & improve ih ring handling

On Thu, May 24, 2012 at 09:49:10AM +0200, Christian K?nig wrote: > From: Christian Koenig > > The spinlock was actually there to protect the > rptr, but rptr was read outside of the locked area. > > Also we don't really need a spinlock here, an > atomic should to quite fine since we only need

[PATCH 05/10] drm/radeon: remove some unneeded structure members

On Thu, May 24, 2012 at 09:49:09AM +0200, Christian K?nig wrote: > From: Christian Koenig > > Signed-off-by: Christian Koenig Reviewed-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon.h |2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon.h

[PATCH 04/10] drm/radeon: replace vmram_mutex with mclk_lock v2

On Thu, May 24, 2012 at 09:49:08AM +0200, Christian K?nig wrote: > It is a rw_semaphore now and only write locked > while changing the clock. Also the lock is renamed > to better reflect what it is protecting. > > v2: Keep the ttm_vm_ops on IGPs > > Signed-off-by: Christian K?nig Reviewed-by:

[PATCH 03/10] drm/radeon: rework ring syncing code

On Thu, May 24, 2012 at 09:49:07AM +0200, Christian K?nig wrote: > Move inter ring syncing with semaphores into the > existing ring allocations, with that we need to > lock the ring mutex only once. > > Signed-off-by: Christian K?nig Reviewed-by: Jerome Glisse > --- >

[PATCH 02/10] drm/radeon: add infrastructure for advanced ring synchronization

On Thu, May 24, 2012 at 09:49:06AM +0200, Christian K?nig wrote: > Signed-off-by: Christian K?nig Need a small improvement see below, otherwise Reviewed-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon.h | 23 ++- > drivers/gpu/drm/radeon/radeon_fence.c | 73 >

[PATCH 01/10] drm/radeon: remove radeon_fence_create

On Thu, May 24, 2012 at 09:49:05AM +0200, Christian K?nig wrote: > It is completely unnecessary to create fences > before they are emitted, so remove it and a bunch > of checks if fences are emitted or not. > > Signed-off-by: Christian K?nig Reviewed-by: Jerome Glisse > --- >

[PATCH 07/10] drm/radeon: apply Murphy's law to the kms irq code

On Thu, May 24, 2012 at 11:35:15AM -0400, Alex Deucher wrote: > On Thu, May 24, 2012 at 3:49 AM, Christian K?nig > wrote: > > From: Christian Koenig > > > > 1. It is really dangerous to have more than one > > ? spinlock protecting the same information. > > > > 2. radeon_irq_set sometimes wasn't

[PATCH] staging: omapdrm: fix crash when freeing bad fb

During unload, don't cleanup the framebuffer if it is not valid. Signed-off-by: Andy Gross --- drivers/staging/omapdrm/omap_fbdev.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/staging/omapdrm/omap_fbdev.c b/drivers/staging/omapdrm/omap_fbdev.c

[PATCH] staging: omapdrm: Fix error paths during dmm init

Failures during the dmm probe can cause the kernel to crash. Moved the spinlock to a global and moved list initializations immediately after the allocation of the dmm private structure. Signed-off-by: Andy Gross --- drivers/staging/omapdrm/omap_dmm_priv.h |1 -

[PATCH 0/4] drm/i915: Make video sprites survive a modeset

On Thu, 24 May 2012 21:29:46 +0300 ville.syrjala at linux.intel.com wrote: > Currently the video sprites appear to get disabled on modeset more by > accient than by design. > > With the current API that behaviour makes very little sense to me. > You first enable some plane, and then it can get

[PATCH 07/10] drm/radeon: apply Murphy's law to the kms irq code

On Thu, May 24, 2012 at 3:49 AM, Christian K?nig wrote: > From: Christian Koenig > > 1. It is really dangerous to have more than one > ? spinlock protecting the same information. > > 2. radeon_irq_set sometimes wasn't called with lock > ? protection, so it can happen that more than one > ? CPU

[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]

On Thu, 24 May 2012 21:08:58 +0300 ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Take fb->offset[0] into account when calculating the linear and tile x/y > offsets. > > For non-tiled surfaces fb->offset[0] is simply added to the linear > byte offset. > > For tiled surfaces

[PATCH] omap2+: add drm device

; > don't want to duplicate that in N different drivers. > > So why can't all that code be in a tiler library/driver? And I think we've discussed about this before, so sorry if I'm repeating myself. I just find it odd that we are not able to create a nice separate lib/driver for the tiler, which is a separate piece of HW that multiple drivers might want to use. Tomi -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/60e537c3/attachment.pgp>

Oops with Radeon/Uninorth on Maple

Hello, colleagues, I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX board, with CPC925 (U3H) north bridge). For now I'm stuck with a problem: I use radeon card, drm-radeon driver with KMS. If I force drm-radeon to think about a card as about PCI card (by commenting

[PATCH] omap2+: add drm device

On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen wrote: > On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote: > >> but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss >> v4l2 camera working w/ tiler buffers on my pandaboard, for example. >> >> Maybe fbdev is an exception to the

[PATCH] omap2+: add drm device

support for all the ioctls, etc? I guess we'd still need to have omapfb driver to keep the module parameters and behavior the same. Can omapdrm be used from inside the kernel by another driver? Tomi -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/555fd618/attachment.pgp>

GPU lockup dumping

On 23.05.2012 19:02, Jerome Glisse wrote: > On Wed, May 23, 2012 at 12:41 PM, Dave Airlie wrote: >> On Wed, May 23, 2012 at 5:26 PM, Jerome Glisse wrote: >>> On Wed, May 23, 2012 at 12:08 PM, Dave Airlie wrote: On Wed, May 23, 2012 at 3:48 PM, Jerome Glisse wrote: > On Wed, May

[PATCH] drm: fix case where panic notifier isn't unregistered

Hi, I don't know if this patch got missed in the list traffic or if I did something wrong but it doesn't appear to have been picked up. This is my first time contributing so if I did anything wrong some pointers would be appreciated. Thanks Frank > From:

[PATCH 10/10] drm/radeon: work around bugs in caymans compute rings

From: Christian Koenig The shader preemption on cayman doesn't work correctly with multiple rings. So to be able to still make use of the compute rings we use a semaphore to make sure that only one IB can execute at the same time. This isn't as effective as shader

[PATCH 09/10] drm/radeon: replace cs_mutex with vm_mutex

Try to remove or replace the cs_mutex with a vm_mutex where it is still needed. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h| 44 +--- drivers/gpu/drm/radeon/radeon_cs.c |7 ++--- drivers/gpu/drm/radeon/radeon_device.c |2

[PATCH 07/10] drm/radeon: apply Murphy's law to the kms irq code

From: Christian Koenig 1. It is really dangerous to have more than one spinlock protecting the same information. 2. radeon_irq_set sometimes wasn't called with lock protection, so it can happen that more than one CPU would tamper with the irq regs at the same

[PATCH 06/10] drm/radeon: fix & improve ih ring handling

From: Christian Koenig The spinlock was actually there to protect the rptr, but rptr was read outside of the locked area. Also we don't really need a spinlock here, an atomic should to quite fine since we only need to prevent it from being reentrant. Signed-off-by:

[PATCH 05/10] drm/radeon: remove some unneeded structure members

From: Christian Koenig Signed-off-by: Christian Koenig --- drivers/gpu/drm/radeon/radeon.h |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 3e83480..618df9a 100644 ---

  1   2   3   >