[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. Signed-Off-b

[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' - o

[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. S

[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 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 --gi

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

Let's put all this new&neat 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 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 3bbd

[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 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 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 1

[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 (All)

[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: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- Yo

[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: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You

Re: Oops with Radeon/Uninorth on Maple

On Thu, 2012-05-24 at 10:18 +0400, Dmitry Eremin-Solenikov wrote: > 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.

Re: [PATCH] gpu: remove gma500 stub driver

On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote: > In v3.3, the gma500 drm driver moved from staging to drm group by > Alan Cox's 3abcf41fb patch. the gma500 drm driver should control > brightness well and don't need gma500 stub driver anymore. Looks good to me. -- Matthew Garrett |

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

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

From: Alex Deucher Using the wrong union. Signed-off-by: Alex Deucher Cc: sta...@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 index b01c2dd..ce4e7cc 100644 ---

[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works

https://bugzilla.kernel.org/show_bug.cgi?id=39832 Santiago Garcia Mantinan changed: What|Removed |Added CC||ma...@manty.net --- Commen

[PATCH] omap2+: add drm device

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/30a10d3c/attachment.pgp>

[no subject]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote: > On 05/18/2012 02:27 PM, Sascha Hauer wrote: > > Hi All, > > > > The following adds a drm/kms driver for the Freescale i.MX LCDC > > controller. Most notable change to the last SDRM based version is that > > the SDRM layer has be

[PATCH] omap2+: add drm device

ffers mapped to one or more overlays, 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>

[PATCH] omap2+: add drm device

o userspace, you *really* > > 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>

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

Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h | 23 ++- drivers/gpu/drm/radeon/radeon_fence.c | 73 + 2 files changed, 85 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/ra

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

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 --- drivers/gpu/drm/radeon/evergreen_blit_kms.c |3 +- drivers/gpu/drm/radeon/r600.c |5 +- drivers/gpu/drm/radeon/

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

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 --- drivers/gpu/drm/radeon/radeon.h|3 ++- drivers/gpu/drm/radeon/radeon_device.c

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

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 --- drivers/gpu/drm/radeon/evergreen.c|2 +- drivers/gpu/drm/radeon/ni.c |2 +- drivers/gpu/drm/rad

[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: Christian Koenig --- driver

[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 preemption, but also isn't as b

[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 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 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/

[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 time. 3. The pm.gui_idl

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

From: Christian Koenig So we can skip the looking. Also renames sw_int to ring_int, cause that better matches its purpose. Signed-off-by: Christian Koenig --- drivers/gpu/drm/radeon/evergreen.c | 32 - drivers/gpu/drm/radeon/r100.c | 10 +++--- drivers/gpu/dr

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 2

[PATCH] omap2+: add drm device

On Thu, May 24, 2012 at 1:05 AM, Tomi Valkeinen wrote: > On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote: >> On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen >> wrote: >> > Hi, >> > >> > On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote: >> >> Register OMAP DRM/KMS platform device. ?DMM i

[PATCH] omap2+: add drm device

On Thu, May 24, 2012 at 1:21 AM, Tomi Valkeinen wrote: > On Thu, 2012-05-24 at 10:05 +0300, Tomi Valkeinen wrote: >> On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote: >> > On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen > > ti.com> wrote: >> > > Hi, >> > > >> > > On Wed, 2012-05-23 at 15:08 -

[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: dri-devel-bounces+frank.binns=imgtec.co

[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] omap2+: add drm device

he > > kernel by another driver? > > Hmm, I'm not quite sure what 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] omap2+: add drm device

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/2af85523/attachment.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

[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, wouldn'

[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] 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 > appreciated

[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 drive

[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|

[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: https://bugzilla

[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|

[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: https://bugzilla

[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 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: https://bugzilla

[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 t

[PATCH] omap2+: add drm device

On Thu, May 24, 2012 at 1:01 AM, Tomi Valkeinen wrote: >> +struct omap_drm_platform_data { >> + ? ? struct omap_kms_platform_data *kms_pdata; >> +}; > > This one is missing struct omap_dmm_platform_data *dmm_pdata, so you > didn't just move the struct. Is that on purpose? Good point. I can clea

[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 bugmai

[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 r

[PATCH] omap2+: add drm device

ot familiar with the related problems, so I take 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>

[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 wo

[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 a

[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 c

[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 > --- > drivers/gpu/drm/

[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 ha

[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 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 > --- > drivers/gpu/drm/radeon/e

[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: J

[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 b/dri

[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 to

[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: [Lin

[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 windows

[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 index

[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 - drivers/staging/omapdrm/omap

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

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

[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 a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr

[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 a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c

[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 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/dr

[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 and earlier * XRGB210101010 & co.

[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 a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel

[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 of the surface. So we end up co

[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 deletions(-) diff --git a/drivers

[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? --- drivers/gpu/drm/i915/intel_display.c | 18 +

[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 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 insertions(+), 1 deletions(-) diff --git

[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 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 are rounded to the nearest (macro)

[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 a/drivers/gpu/drm/i915/intel_sprite.c b/drivers

[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? --- drivers/gpu/drm/i915/intel_sprite.c |8 ++--

[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 include/drm/drm_crtc.h | 24 +++ 2 files

[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 b/drivers/gpu/drm/drm_crtc.c ind

[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 > http://lists.freedesktop.org/m

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) Unbind

[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,

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

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 disabled due to some unrelated operation. So these patches change the behaviour so that

[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 include/drm/drm_crtc.h

[PATCH 2/4] drm: Add restore_fbdev_mode() hook to drm_fb_helper

From: Ville Syrj?l? Add an optional driver specific restore_fbdev_mode() hook to drm_fb_helper. If the driver doesn't provide the hook, drm_fb_helper_restore_fbdev_mode() is called directly as before. In this hook the driver can disable additional planes, cursors etc. that shouldn't be visible w

[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 files changed, 48 insertions(+), 0

[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 +- drivers/gpu/drm/i915/intel_drv.h |

[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 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 di

[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 Clar

[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(-) > > di

[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(-) > > di

[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 ve

<    1   2   3   >