[git pull] drm next tree

2014-02-07 Thread Jiri Kosina 
On Fri, 7 Feb 2014, Daniel Vetter wrote:

> Sorry for missing your report here. Before we disable this again for
> gen4 I want to make sure that it's the same irq misrouting issue which
> was already the cause for the gmbus irq mess. Can you please boot with
> pci=nomsi (so that i915 uses irq16)?
> 
> If that's confirmed then I think we should add the same comment we've
> added in intel_i2c.c to this code so that no one dares to wake this
> dragon again. I'll do that when I commit the fix.

Confirmed, with MSI disabled, i915 is using IRQ 16 and everything is 
working well.

-- 
Jiri Kosina
SUSE Labs

[git pull] drm next tree

2014-02-07 Thread Daniel Vetter 
On Fri, Feb 7, 2014 at 2:40 PM, Jiri Kosina  wrote:
> On Fri, 7 Feb 2014, Jani Nikula wrote:
>
>> >> >   git://people.freedesktop.org/~airlied/linux drm-next
>> >> [ ... snip ... ]
>> >> > Daniel Vetter (59):
>> >> [ ... snip ... ]
>> >> >   drm/i915: dp aux irq support for g4x/vlv
>> >>
>> >> This commit causes all kinds of havoc on my ThinkPad x200s. It results in
>> > [ ... snip ... ]
>> >
>> > Not having received any response, I suggest the following for 3.14
>>
>> Daniel, it's your commit this bisects to...
>>
>> If we end up having to revert, I'd just touch the has_aux_irq part, for
>> example:
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 5ede4e8..464c047 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -404,7 +404,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>>   int i, ret, recv_bytes;
>>   uint32_t status;
>>   int try, precharge, clock = 0;
>> - bool has_aux_irq = true;
>> + bool has_aux_irq = INTEL_INFO(dev)->gen >= 5;
>>   uint32_t timeout;
>>
>>   /* dp aux is extremely sensitive to irq latency, hence request the
>
> That, obviously, works for my system as well. Feel free to add
>
> Reported-and-tested-by: Jiri Kosina 
>
> if you are going with this instead of the revert.

Sorry for missing your report here. Before we disable this again for
gen4 I want to make sure that it's the same irq misrouting issue which
was already the cause for the gmbus irq mess. Can you please boot with
pci=nomsi (so that i915 uses irq16)?

If that's confirmed then I think we should add the same comment we've
added in intel_i2c.c to this code so that no one dares to wake this
dragon again. I'll do that when I commit the fix.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[git pull] drm next tree

2014-02-07 Thread Jiri Kosina 
On Fri, 7 Feb 2014, Jani Nikula wrote:

> >> >   git://people.freedesktop.org/~airlied/linux drm-next
> >> [ ... snip ... ]
> >> > Daniel Vetter (59):
> >> [ ... snip ... ]
> >> >   drm/i915: dp aux irq support for g4x/vlv
> >> 
> >> This commit causes all kinds of havoc on my ThinkPad x200s. It results in
> > [ ... snip ... ]
> >
> > Not having received any response, I suggest the following for 3.14
> 
> Daniel, it's your commit this bisects to...
> 
> If we end up having to revert, I'd just touch the has_aux_irq part, for
> example:
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5ede4e8..464c047 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -404,7 +404,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>   int i, ret, recv_bytes;
>   uint32_t status;
>   int try, precharge, clock = 0;
> - bool has_aux_irq = true;
> + bool has_aux_irq = INTEL_INFO(dev)->gen >= 5;
>   uint32_t timeout;
> 
>   /* dp aux is extremely sensitive to irq latency, hence request the

That, obviously, works for my system as well. Feel free to add

Reported-and-tested-by: Jiri Kosina 

if you are going with this instead of the revert.

-- 
Jiri Kosina
SUSE Labs

[git pull] drm next tree

2014-02-07 Thread Jani Nikula 
On Fri, 07 Feb 2014, Jiri Kosina  wrote:
> On Thu, 30 Jan 2014, Jiri Kosina wrote:
>
>> >   git://people.freedesktop.org/~airlied/linux drm-next
>> [ ... snip ... ]
>> > Daniel Vetter (59):
>> [ ... snip ... ]
>> >   drm/i915: dp aux irq support for g4x/vlv
>> 
>> This commit causes all kinds of havoc on my ThinkPad x200s. It results in
> [ ... snip ... ]
>
> Not having received any response, I suggest the following for 3.14

Daniel, it's your commit this bisects to...

If we end up having to revert, I'd just touch the has_aux_irq part, for
example:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5ede4e8..464c047 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -404,7 +404,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
int i, ret, recv_bytes;
uint32_t status;
int try, precharge, clock = 0;
-   bool has_aux_irq = true;
+   bool has_aux_irq = INTEL_INFO(dev)->gen >= 5;
uint32_t timeout;

/* dp aux is extremely sensitive to irq latency, hence request the

or even INTEL_INFO(dev)->gen != 4.

But up to Daniel.


BR,
Jani.




>
>
>
>
> From: Jiri Kosina 
> Subject: [PATCH] Revert "drm/i915: dp aux irq support for g4x/vlv"
>
> This reverts commit 4aeebd7443e36b0a40032e518a9338f48bd27efc.
>
> Conflicts:
>
>   drivers/gpu/drm/i915/i915_reg.h
>
> This commit causes all kinds of havoc on my ThinkPad x200s. It results in
>
>  irq 16: nobody cared (try booting with the "irqpoll" option)
>  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-00854-g4aeebd7 #1
>  Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
>   8800795186c0 88007c203e08 81582503 88007c203e38
>   810a6a98 88007c203e88 880079518600 
>   0010 88007c203e78 810a6d43 0010ffc4af9d
>  Call Trace:
> [] dump_stack+0x7a/0x97
>   [] __report_bad_irq+0x38/0xf0
>   [] note_interrupt+0x1f3/0x240
>   [] handle_irq_event_percpu+0x142/0x220
>   [] handle_irq_event+0x49/0x70
>   [] handle_fasteoi_irq+0x61/0x100
>   [] handle_irq+0x59/0x150
>   [] ? _local_bh_enable+0xe/0x10
>   [] ? irq_enter+0x81/0x90
>   [] do_IRQ+0x5b/0xe0
>   [] common_interrupt+0x6f/0x6f
> [] ? retint_restore_args+0xe/0xe
>   [] ? poll_idle+0x47/0x90
>   [] ? poll_idle+0x20/0x90
>   [] ? ktime_get+0x56/0xd0
>   [] cpuidle_enter_state+0x40/0xd0
>   [] cpuidle_idle_call+0x10a/0x160
>   [] arch_cpu_idle+0x9/0x30
>   [] cpu_idle_loop+0x8b/0x270
>   [] cpu_startup_entry+0x1e/0x20
>   [] rest_init+0xd3/0xe0
>   [] ? csum_partial_copy_generic+0x170/0x170
>   [] start_kernel+0x3b3/0x461
>   [] ? repair_env_string+0x58/0x58
>   [] x86_64_start_reservations+0x1b/0x32
>   [] x86_64_start_kernel+0x13a/0x141
>  handlers:
>  [] usb_hcd_irq [usbcore]
>  Disabling IRQ #16
>
> and things go south afterwards (the machine hangs randomly, I/O is 
> horribly slow, etc).
>
> Signed-off-by: Jiri Kosina 
>
> ---
>  drivers/gpu/drm/i915/i915_irq.c |7 ---
>  drivers/gpu/drm/i915/i915_reg.h |5 -
>  drivers/gpu/drm/i915/intel_dp.c |2 +-
>  3 files changed, 1 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 17d8fcb..b7fae5b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1480,9 +1480,6 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
> *arg)
>  
>   intel_hpd_irq_handler(dev, hotplug_trigger, 
> hpd_status_i915);
>  
> - if (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> - dp_aux_irq_handler(dev);
> -
>   I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
>   I915_READ(PORT_HOTPLUG_STAT);
>   }
> @@ -3670,10 +3667,6 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
>   intel_hpd_irq_handler(dev, hotplug_trigger,
> IS_G4X(dev) ? hpd_status_g4x : 
> hpd_status_i915);
>  
> - if (IS_G4X(dev) &&
> - (hotplug_status & 
> DP_AUX_CHANNEL_MASK_INT_STATUS_G4X))
> - dp_aux_irq_handler(dev);
> -
>   I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
>   I915_READ(PORT_HOTPLUG_STAT);
>   }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a48b7ca..94b4cd5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2139,11 +2139,6 @@
>  #define   CRT_HOTPLUG_MONITOR_COLOR  (3 << 8)
>  #define   CRT_HOTPLUG_MONITOR_MONO   (2 << 8)
>  #define   CRT_HOTPLUG_MONITOR_NONE   (0 << 8)
> -#define   DP_AUX_CHANNEL_D_INT_STATUS_G4X(1 << 6)
> -#define   DP_AUX_CHANNEL_C_INT_STATUS_G4X(1 << 5)
> -#define   DP_AUX_CHANNEL_B_INT_STATUS_G4X(1 << 4)
>

[git pull] drm next tree

2014-02-07 Thread Jiri Kosina 
On Thu, 30 Jan 2014, Jiri Kosina wrote:

> >   git://people.freedesktop.org/~airlied/linux drm-next
> [ ... snip ... ]
> > Daniel Vetter (59):
> [ ... snip ... ]
> >   drm/i915: dp aux irq support for g4x/vlv
> 
> This commit causes all kinds of havoc on my ThinkPad x200s. It results in
[ ... snip ... ]

Not having received any response, I suggest the following for 3.14




From: Jiri Kosina 
Subject: [PATCH] Revert "drm/i915: dp aux irq support for g4x/vlv"

This reverts commit 4aeebd7443e36b0a40032e518a9338f48bd27efc.

Conflicts:

drivers/gpu/drm/i915/i915_reg.h

This commit causes all kinds of havoc on my ThinkPad x200s. It results in

 irq 16: nobody cared (try booting with the "irqpoll" option)
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-00854-g4aeebd7 #1
 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
  8800795186c0 88007c203e08 81582503 88007c203e38
  810a6a98 88007c203e88 880079518600 
  0010 88007c203e78 810a6d43 0010ffc4af9d
 Call Trace:
[] dump_stack+0x7a/0x97
  [] __report_bad_irq+0x38/0xf0
  [] note_interrupt+0x1f3/0x240
  [] handle_irq_event_percpu+0x142/0x220
  [] handle_irq_event+0x49/0x70
  [] handle_fasteoi_irq+0x61/0x100
  [] handle_irq+0x59/0x150
  [] ? _local_bh_enable+0xe/0x10
  [] ? irq_enter+0x81/0x90
  [] do_IRQ+0x5b/0xe0
  [] common_interrupt+0x6f/0x6f
[] ? retint_restore_args+0xe/0xe
  [] ? poll_idle+0x47/0x90
  [] ? poll_idle+0x20/0x90
  [] ? ktime_get+0x56/0xd0
  [] cpuidle_enter_state+0x40/0xd0
  [] cpuidle_idle_call+0x10a/0x160
  [] arch_cpu_idle+0x9/0x30
  [] cpu_idle_loop+0x8b/0x270
  [] cpu_startup_entry+0x1e/0x20
  [] rest_init+0xd3/0xe0
  [] ? csum_partial_copy_generic+0x170/0x170
  [] start_kernel+0x3b3/0x461
  [] ? repair_env_string+0x58/0x58
  [] x86_64_start_reservations+0x1b/0x32
  [] x86_64_start_kernel+0x13a/0x141
 handlers:
 [] usb_hcd_irq [usbcore]
 Disabling IRQ #16

and things go south afterwards (the machine hangs randomly, I/O is 
horribly slow, etc).

Signed-off-by: Jiri Kosina 

---
 drivers/gpu/drm/i915/i915_irq.c |7 ---
 drivers/gpu/drm/i915/i915_reg.h |5 -
 drivers/gpu/drm/i915/intel_dp.c |2 +-
 3 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 17d8fcb..b7fae5b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1480,9 +1480,6 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)

intel_hpd_irq_handler(dev, hotplug_trigger, 
hpd_status_i915);

-   if (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
-   dp_aux_irq_handler(dev);
-
I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
I915_READ(PORT_HOTPLUG_STAT);
}
@@ -3670,10 +3667,6 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
intel_hpd_irq_handler(dev, hotplug_trigger,
  IS_G4X(dev) ? hpd_status_g4x : 
hpd_status_i915);

-   if (IS_G4X(dev) &&
-   (hotplug_status & 
DP_AUX_CHANNEL_MASK_INT_STATUS_G4X))
-   dp_aux_irq_handler(dev);
-
I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
I915_READ(PORT_HOTPLUG_STAT);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a48b7ca..94b4cd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2139,11 +2139,6 @@
 #define   CRT_HOTPLUG_MONITOR_COLOR(3 << 8)
 #define   CRT_HOTPLUG_MONITOR_MONO (2 << 8)
 #define   CRT_HOTPLUG_MONITOR_NONE (0 << 8)
-#define   DP_AUX_CHANNEL_D_INT_STATUS_G4X  (1 << 6)
-#define   DP_AUX_CHANNEL_C_INT_STATUS_G4X  (1 << 5)
-#define   DP_AUX_CHANNEL_B_INT_STATUS_G4X  (1 << 4)
-#define   DP_AUX_CHANNEL_MASK_INT_STATUS_G4X   (7 << 4)
-
 /* SDVO is different across gen3/4 */
 #define   SDVOC_HOTPLUG_INT_STATUS_G4X (1 << 3)
 #define   SDVOB_HOTPLUG_INT_STATUS_G4X (1 << 2)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5ede4e8..464c047 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -404,7 +404,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
int i, ret, recv_bytes;
uint32_t status;
int try, precharge, clock = 0;
-   bool has_aux_irq = true;
+   bool has_aux_irq = INTEL_INFO(dev)->gen >= 5 && !IS_VALLEYVIEW(dev);
uint32_t timeout;

/* dp aux is extremely sensitive to irq latency, hence request the
-- 
Jiri Kosina
SUSE Labs

[git pull] drm next tree

2014-01-30 Thread Jiri Kosina 
On Thu, 30 Jan 2014, Dave Airlie wrote:

>   git://people.freedesktop.org/~airlied/linux drm-next
[ ... snip ... ]
> Daniel Vetter (59):
[ ... snip ... ]
>   drm/i915: dp aux irq support for g4x/vlv

This commit causes all kinds of havoc on my ThinkPad x200s. It results in

 irq 16: nobody cared (try booting with the "irqpoll" option)
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-00854-g4aeebd7 #1
 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
  8800795186c0 88007c203e08 81582503 88007c203e38
  810a6a98 88007c203e88 880079518600 
  0010 88007c203e78 810a6d43 0010ffc4af9d
 Call Trace:
[] dump_stack+0x7a/0x97
  [] __report_bad_irq+0x38/0xf0
  [] note_interrupt+0x1f3/0x240
  [] handle_irq_event_percpu+0x142/0x220
  [] handle_irq_event+0x49/0x70
  [] handle_fasteoi_irq+0x61/0x100
  [] handle_irq+0x59/0x150
  [] ? _local_bh_enable+0xe/0x10
  [] ? irq_enter+0x81/0x90
  [] do_IRQ+0x5b/0xe0
  [] common_interrupt+0x6f/0x6f
[] ? retint_restore_args+0xe/0xe
  [] ? poll_idle+0x47/0x90
  [] ? poll_idle+0x20/0x90
  [] ? ktime_get+0x56/0xd0
  [] cpuidle_enter_state+0x40/0xd0
  [] cpuidle_idle_call+0x10a/0x160
  [] arch_cpu_idle+0x9/0x30
  [] cpu_idle_loop+0x8b/0x270
  [] cpu_startup_entry+0x1e/0x20
  [] rest_init+0xd3/0xe0
  [] ? csum_partial_copy_generic+0x170/0x170
  [] start_kernel+0x3b3/0x461
  [] ? repair_env_string+0x58/0x58
  [] x86_64_start_reservations+0x1b/0x32
  [] x86_64_start_kernel+0x13a/0x141
 handlers:
 [] usb_hcd_irq [usbcore]
 Disabling IRQ #16

and things go south afterwards (the machine hangs randomly, I/O is 
horribly slow, etc etc).

This is the same machine that was the reason for

commit c12aba5aa0e60b7947bc8b6ea25ef55c4acf81a4
Author: Jiri Kosina 
Date:   Tue Mar 19 09:56:57 2013 +0100

drm/i915: stop using GMBUS IRQs on Gen4 chips

back then in 3.9 timeframe, so it might be somehow related. It's, at the 
end of the day, again IRQ 16 -- and see the changelog of c12aba5a why this 
is rather mysterious (IRQ 16 is assigned to the card when it's not using 
MSI, but it *is* in fact using MSI in all the cases).

-- 
Jiri Kosina
SUSE Labs

[git pull] drm next tree

2014-01-30 Thread Paul Bolle 
Dave Airlie schreef op do 30-01-2014 om 02:49 [+]:
> Christian K?nig (10):
>   [...]
>   drm/radeon: add GART debugfs access v3
>   [...]

That one generates a bit of (warning) noise when building on 32 bits
x86:

In file included from include/asm-generic/bug.h:13:0,
 from [...]/linux/arch/x86/include/asm/bug.h:38,
 from include/linux/bug.h:4,
 from include/drm/drm_mm.h:39,
 from include/drm/drm_vma_manager.h:26,
 from include/drm/ttm/ttm_bo_api.h:35,
 from drivers/gpu/drm/radeon/radeon_ttm.c:32:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read':
include/linux/kernel.h:712:17: warning: comparison of distinct pointer types 
lacks a cast [enabled by default]
  (void) (&_min1 == &_min2);  \
 ^
drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 'min'
   ssize_t cur_size = min(size, PAGE_SIZE - off);
  ^

I suppose the last line should read
   ssize_t cur_size = min(size, (size_t) PAGE_SIZE - off);

to silence this. But I haven't tested yet.


Paul Bolle

[git pull] drm next tree

2014-01-30 Thread Dave Airlie 

Hi Linus,

Been a bit busy, first week of kids school, and waiting on other trees to go in 
before I could send this, so its a bit later than I'd normally like.

For some reason the request-pull and the merge into your tree look different,
since some of the changes in this have already gone in via the arm-soc tree
and dma stuff, all for tegra. Hopefully nobody rebased when they shouldn't.

Highlights:
core: timestamp fixes, lots of misc cleanups
new drivers: bochs virtual vga
vmwgfx: major overhaul for their nextgen virt gpu.
i915: runtime D3 on HSW, watermark fixes, power well work, fbc fixes, bdw is no 
longer prelim.
nouveau: gk110/208 acceleration, more pm groundwork, old overlay support
radeon: dpm rework and clockgating for CIK, pci config reset, big endian fixes
tegra: panel support and DSI support, build as module, prime.
armada, omap, gma500, rcar, exynos, mgag200, cirrus, ast: fixes
msm: hdmi support for mdp5

Dave.

The following changes since commit d8ec26d7f8287f5788a494f56e8814210f0e64be:

  Linux 3.13 (2014-01-19 18:40:07 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to ef64cf9d06049e4e9df661f3be60b217e476bee1:

  Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-01-30 
10:46:06 +1000)



Akash Goel (1):
  drm/i915: Fix the offset issue for the stolen GEM objects

Alex Deucher (59):
  drm/radeon/dpm: remove unnecessary checks in dpm_init
  drm/radeon/si: drop cg_update from dpm code
  drm/radeon/cik: drop cg_update from dpm code
  drm/radeon: re-order firmware loading in preparation for dpm rework
  drm/radeon/dpm: add a late enable callback
  drm/radeon/dpm: add late_enable for rs780/rs880/rv6xx
  drm/radeon/dpm: add late_enable for rv7xx-NI
  drm/radeon/dpm: add late_enable for sumo
  drm/radeon/dpm: add late_enable for trinity
  drm/radeon/dpm: add late_enable for SI
  drm/radeon/dpm: add late_enable for CI
  drm/radeon/dpm: add late_enable for KB/KV
  drm/radeon/dpm: switch on new late_enable callback
  drm/radeon/pm: move pm handling into the asic specific code
  drm/radeon: enable gfx cgcg on CIK dGPUs
  drm/radeon: enable gfx cgcg on CIK APUs
  drm/radeon: enable dpm by default on CI dGPUs
  drm/radeon: enable dpm by default on CI APUs
  drm/radeon: remove generic rptr/wptr functions (v2)
  drm/radeon: fix pptable.h portability
  drm/radeon: warn users when hw_i2c is enabled (v2)
  drm/radeon/dpm: make some functions static for CI
  drm/radeon/dpm: make some functions static for sumo
  drm/radeon/dpm: make some functions static for TN
  drm/radeon: move com/atombios scratch reg functions to radeon_mode.h
  drm/radeon: add hard_reset module parameter
  drm/radeon: add pci config hard reset
  drm/radeon: implement pci config reset for r6xx/7xx (v3)
  drm/radeon: implement pci config reset for evergreen/cayman (v2)
  drm/radeon: implement pci config reset for SI (v2)
  drm/radeon: implement pci config reset for CIK (v3)
  Revert "drm/radeon: disable CIK CP semaphores for now"
  drm/radeon: consolidate cp hdp flushing code for CIK
  drm/radeon: consolidate sdma hdp flushing code for CIK
  drm/radeon/cik: use POLL_REG_MEM special op for sDMA HDP flush
  drm/radeon/cik: use WAIT_REG_MEM special op for CP HDP flush
  drm/radeon: disable dpm on BTC
  drm/radeon/cik: use hw defaults for TC_CFG registers
  drm/radeon: disable ss on DP for DCE3.x
  drm/radeon/dp: bump i2c-over-aux retries to 7
  drm/radeon/dp: use usleep_range rather than udelay
  drm/radeon/dp: sleep after powering up the display
  drm/radeon: add query to fetch the max engine clock (v2)
  drm/radeon: handle ss percentage divider properly
  drm/radeon: bail early from enable ss in certain cases
  drm/radeon: write gfx pg bases even when gfx pg is disabled
  drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table
  drm/radeon/dpm: disable mclk switching on desktop RV770
  drm/radeon: fix surface sync in fence on cayman (v2)
  drm/radeon: set the full cache bit for fences on r7xx+
  drm/radeon: fix minor typos in si_dpm.c
  drm/radeon: add UVD support for OLAND
  drm/radeon/runpm: don't runtime suspend non-PX cards
  drm/radeon: skip async dma init on r6xx
  drm/radeon: clean up active vram sizing
  drm/radeon: fix DAC interrupt handling on DCE5+
  drm/radeon: set si_notify_smc_display_change properly
  drm/radeon/DCE4+: clear bios scratch dpms bit (v2)
  drm/radeon/dce8: workaround for atom BlankCrtc table

Andrzej Hajda (1):
  drm: Add MIPI DSI bus support

Archit Taneja (5):
  drm/omap: fix: Defer probe if an omapdss device requests for it at connect
  drm/omap:

[git pull] drm next tree

2014-01-29 Thread Linus Torvalds 
On Wed, Jan 29, 2014 at 6:49 PM, Dave Airlie  wrote:
>
> For some reason the request-pull and the merge into your tree look different,
> since some of the changes in this have already gone in via the arm-soc tree
> and dma stuff, all for tegra. Hopefully nobody rebased when they shouldn't.

Looks more like it's just a few cross-merges, which then ends up
meaning that there are multiple merge-bases and not just one common
ancestor commit.

In that case, a simple "git diff" can't do a great job, and the actual
merge diff will usually end up different.

 Linus

[git pull] drm next tree

2011-03-23 Thread Linus Torvalds 
On Wed, Mar 23, 2011 at 8:33 AM, Jesse Barnes  
wrote:
>
> Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this
> issue though, but it does seem a likely candidate.

Yup, that revert fixes it for me.

Linus

[git pull] drm next tree

2011-03-23 Thread Alessandro Suardi 
On Wed, Mar 23, 2011 at 3:19 AM, Linus Torvalds
 wrote:
> So I had ?hoped - yes, very na?ve of me, I know - that this merge
> window would be different.
>
> But it's not.
>
> On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie  wrote:
>>
>> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.
>
> .. and apparently a lot of breakage too. My crappy laptop that I abuse
> for travel is - once more - broken by the updates. I cannot suspend
> and resume, because every resume seems to fail.
>
> One of the more useful failures was:
>
> [ ? 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> elapsed... GPU hung
> [ ? 61.656079] [drm] capturing error event; look for more information
> in /debug/dri/0/i915_error_state
> [ ? 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
> returns -11 (awaiting 2 at 0, next 3)
>
> and I'm attaching the error_state file from that particular case here.
> In other cases it seems to just hang entirely.
>
> Keith/Jesse/Chris - I don't know that it's i915, and it will take
> forever to bisect (I'll try). But it does seem pretty likely.

Just in case - is it possible to have that commit in diff format ?

Asking as 2.6.38-git2 is the latest kernel where my Latitude E6400
 is displaying X at 1440x900, -git3 through -git6 do not compile and
 -git7 and onwards (up at least to -git11) display 1024x768 instead.

If I run xrandr --fb 1440x900 --output LVDS1 --mode 1440x900
 once in X, then I get 1440x900 display, but then:

  - the wallpaper's original 1024x768 image stays (the rest of the
 display area is filled with the part of image that should be there
 correctly at 1440x900)
  - if I run mplayer and ask it to go fullscreen, it does 1024x768

lspci (from 2.6.38-git2) says:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 0233
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at f6c0 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at ef98 [size=8]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 0233
Flags: bus master, fast devsel, latency 0
Memory at f6b0 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3


thanks,

--alessandro

?"There's always a siren singing you to shipwreck"

?? (Radiohead, "There There")

[git pull] drm next tree

2011-03-23 Thread Jerome Glisse 
On Wed, Mar 23, 2011 at 8:21 AM, Stephen Clark  
wrote:
> On 03/22/2011 10:19 PM, Linus Torvalds wrote:
>>
>> So I had ?hoped - yes, very na?ve of me, I know - that this merge
>> window would be different.
>>
>> But it's not.
>>
>> On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie ?wrote:
>>
>>>
>>> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.
>>>
>>
>> .. and apparently a lot of breakage too. My crappy laptop that I abuse
>> for travel is - once more - broken by the updates. I cannot suspend
>> and resume, because every resume seems to fail.
>>
>> One of the more useful failures was:
>>
>> [ ? 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
>> elapsed... GPU hung
>> [ ? 61.656079] [drm] capturing error event; look for more information
>> in /debug/dri/0/i915_error_state
>> [ ? 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
>> returns -11 (awaiting 2 at 0, next 3)
>>
>> and I'm attaching the error_state file from that particular case here.
>> In other cases it seems to just hang entirely.
>>
>> Keith/Jesse/Chris - I don't know that it's i915, and it will take
>> forever to bisect (I'll try). But it does seem pretty likely.
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Linus
>>
>
> Why can't the gpu be reset/restarted when this happens? When a nic card gets
> hung it is reinitialized
> and restarted why not the gpu?
>
> --

GPU are so complex, i know case where reseting a GPU would lead to
bring down the PCI and the CPU with it (basicly the reset clear some
of the GPU memory controller bit but not the GPU PCI request queue, so
after/while reseting the GPU trigger a several request to bogus
address on the bus, then trigger a double fault and eventually a CPU
shutdown) . Of course here we can blame the hw designer for not having
a proper reset.

All this vary from one GPU to another, it seems that reset have become
more reliable on newer hw.

Cheers,
Jerome

[git pull] drm next tree

2011-03-23 Thread Jesse Barnes 
On Wed, 23 Mar 2011 08:29:35 -0700
Linus Torvalds  wrote:

> On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds
>  wrote:
> >
> > Keith/Jesse/Chris - I don't know that it's i915, and it will take
> > forever to bisect (I'll try). But it does seem pretty likely.
> 
> Ok, so I'm still bisecting, but it's definitely the DRM pull. Current
> bisection log attached (the result does contain the fbdev pull from
> Paul Mundt, but that doesn't touch any files I compile afaik).

Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this
issue though, but it does seem a likely candidate.

-- 
Jesse Barnes, Intel Open Source Technology Center

[git pull] drm next tree

2011-03-23 Thread Linus Torvalds 
On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds
 wrote:
>
> Keith/Jesse/Chris - I don't know that it's i915, and it will take
> forever to bisect (I'll try). But it does seem pretty likely.

Ok, so I'm still bisecting, but it's definitely the DRM pull. Current
bisection log attached (the result does contain the fbdev pull from
Paul Mundt, but that doesn't touch any files I compile afaik).

   Linus
-- next part --
A non-text attachment was scrubbed...
Name: BISECT_LOG
Type: application/octet-stream
Size: 1404 bytes
Desc: not available
URL:

[git pull] drm next tree

2011-03-23 Thread Jesse Barnes 
On Wed, 23 Mar 2011 08:21:53 -0400
Stephen Clark  wrote:

> On 03/22/2011 10:19 PM, Linus Torvalds wrote:
> > So I had  hoped - yes, very na?ve of me, I know - that this merge
> > window would be different.
> >
> > But it's not.
> >
> > On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie  wrote:
> >
> >> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.
> >>  
> > .. and apparently a lot of breakage too. My crappy laptop that I abuse
> > for travel is - once more - broken by the updates. I cannot suspend
> > and resume, because every resume seems to fail.
> >
> > One of the more useful failures was:
> >
> > [   61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> > elapsed... GPU hung
> > [   61.656079] [drm] capturing error event; look for more information
> > in /debug/dri/0/i915_error_state
> > [   61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
> > returns -11 (awaiting 2 at 0, next 3)
> >
> > and I'm attaching the error_state file from that particular case here.
> > In other cases it seems to just hang entirely.
> >
> > Keith/Jesse/Chris - I don't know that it's i915, and it will take
> > forever to bisect (I'll try). But it does seem pretty likely.
> >
> >   Linus
> >
> Why can't the gpu be reset/restarted when this happens? When a nic card 
> gets hung it is reinitialized
> and restarted why not the gpu?

Yeah, we try to restart in this case, but often just end up back in the
same situation when the app runs again.  We could be meaner about
things and SIGILL the app, but often it's an innocent bystander, and
the real problem is kernel object synchronization and/or the DRI driver
generating bad commands.

-- 
Jesse Barnes, Intel Open Source Technology Center

[git pull] drm next tree

2011-03-23 Thread Stephen Clark 
On 03/22/2011 10:19 PM, Linus Torvalds wrote:
> So I had  hoped - yes, very na?ve of me, I know - that this merge
> window would be different.
>
> But it's not.
>
> On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie  wrote:
>
>> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.
>>  
> .. and apparently a lot of breakage too. My crappy laptop that I abuse
> for travel is - once more - broken by the updates. I cannot suspend
> and resume, because every resume seems to fail.
>
> One of the more useful failures was:
>
> [   61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> elapsed... GPU hung
> [   61.656079] [drm] capturing error event; look for more information
> in /debug/dri/0/i915_error_state
> [   61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
> returns -11 (awaiting 2 at 0, next 3)
>
> and I'm attaching the error_state file from that particular case here.
> In other cases it seems to just hang entirely.
>
> Keith/Jesse/Chris - I don't know that it's i915, and it will take
> forever to bisect (I'll try). But it does seem pretty likely.
>
>   Linus
>
Why can't the gpu be reset/restarted when this happens? When a nic card 
gets hung it is reinitialized
and restarted why not the gpu?

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: [git pull] drm next tree

2011-03-23 Thread Stephen Clark 

On 03/22/2011 10:19 PM, Linus Torvalds wrote:

So I had  hoped - yes, very naïve of me, I know - that this merge
window would be different.

But it's not.

On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlieairl...@linux.ie  wrote:
   

i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.
 

.. and apparently a lot of breakage too. My crappy laptop that I abuse
for travel is - once more - broken by the updates. I cannot suspend
and resume, because every resume seems to fail.

One of the more useful failures was:

[   61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
[   61.656079] [drm] capturing error event; look for more information
in /debug/dri/0/i915_error_state
[   61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
returns -11 (awaiting 2 at 0, next 3)

and I'm attaching the error_state file from that particular case here.
In other cases it seems to just hang entirely.

Keith/Jesse/Chris - I don't know that it's i915, and it will take
forever to bisect (I'll try). But it does seem pretty likely.

  Linus
   
Why can't the gpu be reset/restarted when this happens? When a nic card 
gets hung it is reinitialized

and restarted why not the gpu?

--

They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety.  (Ben Franklin)

The course of history shows that as a government grows, liberty
decreases.  (Thomas Jefferson)



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm next tree

2011-03-23 Thread Alessandro Suardi 
On Wed, Mar 23, 2011 at 3:19 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 So I had  hoped - yes, very naïve of me, I know - that this merge
 window would be different.

 But it's not.

 On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie airl...@linux.ie wrote:

 i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.

 .. and apparently a lot of breakage too. My crappy laptop that I abuse
 for travel is - once more - broken by the updates. I cannot suspend
 and resume, because every resume seems to fail.

 One of the more useful failures was:

 [   61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
 elapsed... GPU hung
 [   61.656079] [drm] capturing error event; look for more information
 in /debug/dri/0/i915_error_state
 [   61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
 returns -11 (awaiting 2 at 0, next 3)

 and I'm attaching the error_state file from that particular case here.
 In other cases it seems to just hang entirely.

 Keith/Jesse/Chris - I don't know that it's i915, and it will take
 forever to bisect (I'll try). But it does seem pretty likely.

Just in case - is it possible to have that commit in diff format ?

Asking as 2.6.38-git2 is the latest kernel where my Latitude E6400
 is displaying X at 1440x900, -git3 through -git6 do not compile and
 -git7 and onwards (up at least to -git11) display 1024x768 instead.

If I run xrandr --fb 1440x900 --output LVDS1 --mode 1440x900
 once in X, then I get 1440x900 display, but then:

  - the wallpaper's original 1024x768 image stays (the rest of the
 display area is filled with the part of image that should be there
 correctly at 1440x900)
  - if I run mplayer and ask it to go fullscreen, it does 1024x768

lspci (from 2.6.38-git2) says:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 0233
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at f6c0 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at ef98 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 0233
Flags: bus master, fast devsel, latency 0
Memory at f6b0 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3


thanks,

--alessandro

 There's always a siren singing you to shipwreck

   (Radiohead, There There)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm next tree

2011-03-23 Thread Jesse Barnes 
On Wed, 23 Mar 2011 08:21:53 -0400
Stephen Clark sclar...@earthlink.net wrote:

 On 03/22/2011 10:19 PM, Linus Torvalds wrote:
  So I had  hoped - yes, very naïve of me, I know - that this merge
  window would be different.
 
  But it's not.
 
  On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlieairl...@linux.ie  wrote:
 
  i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.
   
  .. and apparently a lot of breakage too. My crappy laptop that I abuse
  for travel is - once more - broken by the updates. I cannot suspend
  and resume, because every resume seems to fail.
 
  One of the more useful failures was:
 
  [   61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
  elapsed... GPU hung
  [   61.656079] [drm] capturing error event; look for more information
  in /debug/dri/0/i915_error_state
  [   61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
  returns -11 (awaiting 2 at 0, next 3)
 
  and I'm attaching the error_state file from that particular case here.
  In other cases it seems to just hang entirely.
 
  Keith/Jesse/Chris - I don't know that it's i915, and it will take
  forever to bisect (I'll try). But it does seem pretty likely.
 
Linus
 
 Why can't the gpu be reset/restarted when this happens? When a nic card 
 gets hung it is reinitialized
 and restarted why not the gpu?

Yeah, we try to restart in this case, but often just end up back in the
same situation when the app runs again.  We could be meaner about
things and SIGILL the app, but often it's an innocent bystander, and
the real problem is kernel object synchronization and/or the DRI driver
generating bad commands.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm next tree

2011-03-23 Thread Linus Torvalds 
On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds
torva...@linux-foundation.org wrote:

 Keith/Jesse/Chris - I don't know that it's i915, and it will take
 forever to bisect (I'll try). But it does seem pretty likely.

Ok, so I'm still bisecting, but it's definitely the DRM pull. Current
bisection log attached (the result does contain the fbdev pull from
Paul Mundt, but that doesn't touch any files I compile afaik).

   Linus


BISECT_LOG
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm next tree

2011-03-23 Thread Jesse Barnes 
On Wed, 23 Mar 2011 08:29:35 -0700
Linus Torvalds torva...@linux-foundation.org wrote:

 On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 
  Keith/Jesse/Chris - I don't know that it's i915, and it will take
  forever to bisect (I'll try). But it does seem pretty likely.
 
 Ok, so I'm still bisecting, but it's definitely the DRM pull. Current
 bisection log attached (the result does contain the fbdev pull from
 Paul Mundt, but that doesn't touch any files I compile afaik).

Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this
issue though, but it does seem a likely candidate.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm next tree

2011-03-23 Thread Linus Torvalds 
On Wed, Mar 23, 2011 at 8:33 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:

 Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this
 issue though, but it does seem a likely candidate.

Yup, that revert fixes it for me.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm next tree

2011-03-22 Thread Linus Torvalds 
So I had  hoped - yes, very na?ve of me, I know - that this merge
window would be different.

But it's not.

On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie  wrote:
>
> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.

.. and apparently a lot of breakage too. My crappy laptop that I abuse
for travel is - once more - broken by the updates. I cannot suspend
and resume, because every resume seems to fail.

One of the more useful failures was:

[   61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
[   61.656079] [drm] capturing error event; look for more information
in /debug/dri/0/i915_error_state
[   61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request
returns -11 (awaiting 2 at 0, next 3)

and I'm attaching the error_state file from that particular case here.
In other cases it seems to just hang entirely.

Keith/Jesse/Chris - I don't know that it's i915, and it will take
forever to bisect (I'll try). But it does seem pretty likely.

 Linus
-- next part --
A non-text attachment was scrubbed...
Name: error-state.gz
Type: application/x-gzip
Size: 97209 bytes
Desc: not available
URL:

[git pull] drm next tree

2011-03-17 Thread Dave Airlie 

Hi Linus,

since I see drm named in two other pull threads (staging + bkl) I suppose 
I should send my pull req.

Highlights:
core: drop i830 driver and BKL, add support to drm core to allow USB drm 
drivers, generic unaccelerated buffer create/map fns for simple fbdev 
applications (like plymouth), generic drm capabilities ioctl.
ttm: add support for Xen Dom0
radeon: cayman GPU support (fw is in linux-firmware), r600 tiling + 
predication support
nouveau: pageflipping,  Z compression
i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.

Dave.

The following changes since commit 5359533801e3dd3abca5b7d3d985b0b33fd9fe8b:

  drm/radeon: fix problem with changing active VRAM size. (v2) (2011-03-14 
12:51:04 +1000)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Alex Deucher (17):
  drm/radeon/kms: add cayman chip family
  drm/radeon/kms: add ucode loader for cayman
  drm/radeon/kms: add gpu_init function for cayman
  drm/radeon/kms: add support for cayman gart setup
  drm/radeon/kms: add support for CP setup on cayman asics
  drm/radeon/kms: add support for cayman irqs
  drm/radeon/kms: add cayman asic reset support
  drm/radeon/kms/cayman: add asic init/startup/fini/suspend/resume functions
  drm/radeon/kms: add cayman safe regs
  drm/radeon/kms: add radeon_asic entry for cayman
  drm/radeon/kms: add cayman CS check support
  drm/radeon/kms: additional default context regs for cayman
  drm/radeon/kms/cayman: always set certain VGT regs at CP init
  drm/radeon/kms: cayman/evergreen cs checker updates
  drm/radeon/kms: add cayman pci ids
  drm/radeon/kms: allow max clock of 340 Mhz on hdmi 1.3+
  drm/radeon/kms: fix typo in atom overscan setup

Alexander Lam (1):
  drm/i915: allow 945 to control self refresh (CxSR) automatically

Arnd Bergmann (2):
  drm: remove i830 driver
  drm/i810: remove the BKL

Ben Skeggs (46):
  drm/ttm: call driver move_notify() when doing system->tt bo moves
  Merge remote-tracking branch 'airlied/drm-core-next' into drm-nouveau-next
  drm/nouveau: move + rename some stuff in nouveau_sgdma.c
  drm/nouveau: introduce new gart type, and name _SGDMA more appropriately
  drm/nv40: implement support for on-chip PCIEGART
  drm/nv40: support for 39-bit dma addresses on native PCIE chipsets
  drm/nv84: switch to new-style semaphores
  drm/nvc0/pfifo: semi-handle a couple more irqs
  drm/nvc0: implement semaphores for inter-channel sync
  drm/nouveau: silence some compiler warnings
  drm/nv50: 0x50 needs semaphore yields too
  drm/nv84: use vm offsets for semaphores
  drm/nv50: drop explicit yields in favour of smaller PFIFO timeslice
  drm/nv50-nvc0: move non-sharable display state into private structure
  drm/nv50-nvc0: rename disp->evo to disp->master
  drm/nv50-nvc0: disp channels have fixed purposes, don't "allocate" them
  drm/nv50-nvc0: fix ramht entries for multiple evo channels
  drm/nv50-nvc0: tidy evo init failure paths
  drm/nv50-nvc0: include nv50_display in evo debugging
  drm/nouveau: make vbios parser runnable from an atomic context
  drm/nv50-nvc0: switch to tasklet for display isr bh
  drm/nv50-nvc0: request and wait on notification of modeset completion
  drm/nv50-nvc0: tidy evo object creation some more
  drm/nv50-nvc0: precalculate some fb state when creating them
  drm/nv50-nvc0: initialise display sync channels
  drm/nv50-nvc0: activate/update ds channel's framebuffer on modesets
  drm/nv50: enable page flipping
  drm/nvc0: support for sw methods + enable page flipping
  drm/nouveau/vbios: parse more gpio tag bits from connector table
  drm/nouveau: remove no_vm/mappable flags from nouveau_bo
  drm/nv50: simplify bo moves now that they're all through the vm
  drm/nouveau: pass domain rather than ttm flags to gem_new()
  drm/nv50-nvc0: restrict memtype to those specified at creation time
  drm/nv50-nvc0: move vm bind/unbind to move_notify hook
  drm/nv50-nvc0: unmap buffers from the vm when they're evicted
  drm/nvc0: allow creation of buffers with any non-compressed memtype
  drm/nouveau: rename nouveau_vram to nouveau_mem
  drm/nv50-nvc0: delay GART binding until move_notify time
  drm/nv50: support for compression
  drm/nv50: flesh out ZCULL init and match nvidia on later chipsets
  drm/core: add ioctl to query device/driver capabilities
  drm/nvc0: remove vm hack forcing large/small pages to not share a PDE
  drm/nouveau: add nouveau_enum_find() util function
  drm/nv50: decode vm faults some more
  drm/nv50: check for vm traps on every gr irq
  drm/nv40: attempt to reserve just enough vram for all 32 channels

Benjamin Franzke (1):
  drm/nouveau: Fix pageflip event

Bryan Freed (2):
  drm/i915:

[git pull] drm next tree

2011-03-16 Thread Dave Airlie 

Hi Linus,

since I see drm named in two other pull threads (staging + bkl) I suppose 
I should send my pull req.

Highlights:
core: drop i830 driver and BKL, add support to drm core to allow USB drm 
drivers, generic unaccelerated buffer create/map fns for simple fbdev 
applications (like plymouth), generic drm capabilities ioctl.
ttm: add support for Xen Dom0
radeon: cayman GPU support (fw is in linux-firmware), r600 tiling + 
predication support
nouveau: pageflipping,  Z compression
i915: big 855 fix, lots of output setup refactoring, lots of misc fixes.

Dave.

The following changes since commit 5359533801e3dd3abca5b7d3d985b0b33fd9fe8b:

  drm/radeon: fix problem with changing active VRAM size. (v2) (2011-03-14 
12:51:04 +1000)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Alex Deucher (17):
  drm/radeon/kms: add cayman chip family
  drm/radeon/kms: add ucode loader for cayman
  drm/radeon/kms: add gpu_init function for cayman
  drm/radeon/kms: add support for cayman gart setup
  drm/radeon/kms: add support for CP setup on cayman asics
  drm/radeon/kms: add support for cayman irqs
  drm/radeon/kms: add cayman asic reset support
  drm/radeon/kms/cayman: add asic init/startup/fini/suspend/resume functions
  drm/radeon/kms: add cayman safe regs
  drm/radeon/kms: add radeon_asic entry for cayman
  drm/radeon/kms: add cayman CS check support
  drm/radeon/kms: additional default context regs for cayman
  drm/radeon/kms/cayman: always set certain VGT regs at CP init
  drm/radeon/kms: cayman/evergreen cs checker updates
  drm/radeon/kms: add cayman pci ids
  drm/radeon/kms: allow max clock of 340 Mhz on hdmi 1.3+
  drm/radeon/kms: fix typo in atom overscan setup

Alexander Lam (1):
  drm/i915: allow 945 to control self refresh (CxSR) automatically

Arnd Bergmann (2):
  drm: remove i830 driver
  drm/i810: remove the BKL

Ben Skeggs (46):
  drm/ttm: call driver move_notify() when doing system-tt bo moves
  Merge remote-tracking branch 'airlied/drm-core-next' into drm-nouveau-next
  drm/nouveau: move + rename some stuff in nouveau_sgdma.c
  drm/nouveau: introduce new gart type, and name _SGDMA more appropriately
  drm/nv40: implement support for on-chip PCIEGART
  drm/nv40: support for 39-bit dma addresses on native PCIE chipsets
  drm/nv84: switch to new-style semaphores
  drm/nvc0/pfifo: semi-handle a couple more irqs
  drm/nvc0: implement semaphores for inter-channel sync
  drm/nouveau: silence some compiler warnings
  drm/nv50: 0x50 needs semaphore yields too
  drm/nv84: use vm offsets for semaphores
  drm/nv50: drop explicit yields in favour of smaller PFIFO timeslice
  drm/nv50-nvc0: move non-sharable display state into private structure
  drm/nv50-nvc0: rename disp-evo to disp-master
  drm/nv50-nvc0: disp channels have fixed purposes, don't allocate them
  drm/nv50-nvc0: fix ramht entries for multiple evo channels
  drm/nv50-nvc0: tidy evo init failure paths
  drm/nv50-nvc0: include nv50_display in evo debugging
  drm/nouveau: make vbios parser runnable from an atomic context
  drm/nv50-nvc0: switch to tasklet for display isr bh
  drm/nv50-nvc0: request and wait on notification of modeset completion
  drm/nv50-nvc0: tidy evo object creation some more
  drm/nv50-nvc0: precalculate some fb state when creating them
  drm/nv50-nvc0: initialise display sync channels
  drm/nv50-nvc0: activate/update ds channel's framebuffer on modesets
  drm/nv50: enable page flipping
  drm/nvc0: support for sw methods + enable page flipping
  drm/nouveau/vbios: parse more gpio tag bits from connector table
  drm/nouveau: remove no_vm/mappable flags from nouveau_bo
  drm/nv50: simplify bo moves now that they're all through the vm
  drm/nouveau: pass domain rather than ttm flags to gem_new()
  drm/nv50-nvc0: restrict memtype to those specified at creation time
  drm/nv50-nvc0: move vm bind/unbind to move_notify hook
  drm/nv50-nvc0: unmap buffers from the vm when they're evicted
  drm/nvc0: allow creation of buffers with any non-compressed memtype
  drm/nouveau: rename nouveau_vram to nouveau_mem
  drm/nv50-nvc0: delay GART binding until move_notify time
  drm/nv50: support for compression
  drm/nv50: flesh out ZCULL init and match nvidia on later chipsets
  drm/core: add ioctl to query device/driver capabilities
  drm/nvc0: remove vm hack forcing large/small pages to not share a PDE
  drm/nouveau: add nouveau_enum_find() util function
  drm/nv50: decode vm faults some more
  drm/nv50: check for vm traps on every gr irq
  drm/nv40: attempt to reserve just enough vram for all 32 channels

Benjamin Franzke (1):
  drm/nouveau: Fix pageflip event

Bryan Freed (2):
  drm/i915: Honour