At Thu, 23 May 2013 09:51:07 +0800,
Wang Xingchao wrote:
>
> There's deadlock when request_module(i915) in azx_probe.
> It looks like:
> device_lock(audio pci device) -> azx_probe -> module_request
> (or symbol_request) -> modprobe (userspace) -> i915 init ->
> drm_pci_init -> pci_register_driver
At Thu, 23 May 2013 01:04:16 +0800,
Wang Xingchao wrote:
>
> There's deadlock when request_module(i915) in azx_probe.
> It looks like:
> device_lock(audio pci device) -> azx_probe -> module_request
> (or symbol_request) -> modprobe (userspace) -> i915 init ->
> drm_pci_init -> pci_register_driver
On Wed, May 22, 2013 at 11:07:09PM +0200, Thomas Meyer wrote:
>
> Signed-off-by: Thomas Meyer
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-g
At Thu, 23 May 2013 01:04:15 +0800,
Wang Xingchao wrote:
>
> The device can support runtime PM no matter whether
> it support signal wakeup or not. For some chips like Haswell
> which doesnot support PME by default, this patch let haswell
> Display HD-A controller enter runtime suspend, and bring
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) -> azx_probe -> module_request
(or symbol_request) -> modprobe (userspace) -> i915 init ->
drm_pci_init -> pci_register_driver -> bus_add_driver -> driver_attach ->
which in turn tries all locks on
According BSPec: "Workaround: Do not enable Render Command Streamer tracking
for FBC.
Instead insert a LRI to address 0x50380 with data 0x0004 after the
PIPE_CONTROL that
follows each render submission."
v2: Chris noticed that flush_domains check was missing here and also suggested
to do
On Wed, May 22, 2013 at 05:08:06PM +0100, Chris Wilson wrote:
> In commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
> Author: Chris Wilson
> Date: Thu Apr 4 21:31:03 2013 +0100
>
> drm/i915: Workaround incoherence between fences and LLC across multiple
> CPUs
>
> we introduced an empirical
There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) -> azx_probe -> module_request
(or symbol_request) -> modprobe (userspace) -> i915 init ->
drm_pci_init -> pci_register_driver -> bus_add_driver -> driver_attach ->
which in turn tries all locks on
The device can support runtime PM no matter whether
it support signal wakeup or not. For some chips like Haswell
which doesnot support PME by default, this patch let haswell
Display HD-A controller enter runtime suspend, and bring more
power saving whith power-well feature enabled.
Signed-off-by: W
Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.
Signed-off-by: Wang
For Intel Haswell chip, HDA controller and codec have
power well dependency from GPU side. This patch added support
to request/release power well in audio driver. Power save
feature should be enabled to get runtime power saving.
Signed-off-by: Wang Xingchao
---
sound/pci/hda/Kconfig | 10 +++
Hi all,
This is V5 and here're some changes notes:
change from V4-->V5:
- fix reference count bug
- new patch on general runtime pm support for audio pci device
- new patch to avoid request_module() deadlock
change between V3-->V4:
- add new structure i915_power_well
- in
On Wed, May 22, 2013 at 05:40:48PM +0300, Imre Deak wrote:
> Add a double buffer and a single buffer version of the above sequence,
> to check if the modeset does a DPMS ON.
>
> Tested on IVB, with and without the relevant kernel fix, got the
> expected results.
>
> Signed-off-by: Imre Deak
All
Greetings,
It seems that the hack that was reverted in
657445fe8660100ad174600ebfa61536392b7624 helped more than just Haswell
machines. On my Toshiba Kirabook after that change I get completely
garbled/unusable video. I haven't troubleshooted it any deeper yet
beyond reverting since I just happene
In commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
we introduced an empirical workaround for memory corruption when using
fences from multiple CPUs. At the
On Wed, May 22, 2013 at 8:51 AM, Daniel Vetter wrote:
> On Wed, May 22, 2013 at 5:25 PM, Stéphane Marchesin
> wrote:
>> On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter wrote:
>>> On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
>>> wrote:
On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter
On Wed, May 22, 2013 at 5:25 PM, Stéphane Marchesin
wrote:
> On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter wrote:
>> On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
>> wrote:
>>> On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter wrote:
Hi Dave,
You're pull just reminded me th
On Wed, 22 May 2013 15:36:17 +0300
Jani Nikula wrote:
> Both the intel_dpio_{read,write} and valleyview_{punit,nc}_{read,write}
> use the IOSF sideband interface. They access the same registers and do
> mostly the same stuff, but no shared code. There are even duplicate
> register defines for the
On Wed, May 22, 2013 at 02:58:46PM +0100, Chris Wilson wrote:
> On Wed, May 22, 2013 at 04:42:53PM +0300, Mika Kuoppala wrote:
> > Sometimes when user is trying to get error state out from
> > debugfs after gpu hang, the memory is low and/or fragmented
> > enough that kmalloc in seq_file will fail.
On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter wrote:
> On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
> wrote:
>> On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter wrote:
>>> Hi Dave,
>>>
>>> You're pull just reminded me that I've been sitting on a few small -fixes,
>>> too. Nothing really
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f5addac..b311ccd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1787,6
Add a double buffer and a single buffer version of the above sequence,
to check if the modeset does a DPMS ON.
Tested on IVB, with and without the relevant kernel fix, got the
expected results.
Signed-off-by: Imre Deak
---
tests/kms_flip.c | 14 +-
1 file changed, 13 insertions(+),
Currently when exiting with error, we'll get stuck in a DPMS OFF state
if the error happens while we have DPMS OFF set in the test sequence.
This happens even though we switch back to text mode at exit. This might
be a bug in itself to be fixed later, but in any case we want a working
console, so d
Signed-off-by: Imre Deak
---
lib/drmtest.c | 7 +++
lib/drmtest.h | 6 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 9fc03a0..16f5be1 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -1022,7 +1022,6 @@ static struct {
bool i
Signed-off-by: Imre Deak
---
lib/drmtest.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 981ab4b..9fc03a0 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -1065,7 +1065,7 @@ static void call_exit_handlers(int sig)
retu
On Wed, May 22, 2013 at 07:57:59AM -0300, Rodrigo Vivi wrote:
> According BSPec: "Workaround: Do not enable Render Command Streamer tracking
> for FBC.
> Instead insert a LRI to address 0x50380 with data 0x0004 after the
> PIPE_CONTROL that
> follows each render submission."
Missing check fo
On Wed, May 22, 2013 at 04:42:53PM +0300, Mika Kuoppala wrote:
> Sometimes when user is trying to get error state out from
> debugfs after gpu hang, the memory is low and/or fragmented
> enough that kmalloc in seq_file will fail.
>
> Prevent big kmalloc by avoiding seq_file and instead convert
> e
According BSPec: "Workaround: Do not enable Render Command Streamer tracking
for FBC.
Instead insert a LRI to address 0x50380 with data 0x0004 after the
PIPE_CONTROL that
follows each render submission."
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drive
Sometimes when user is trying to get error state out from
debugfs after gpu hang, the memory is low and/or fragmented
enough that kmalloc in seq_file will fail.
Prevent big kmalloc by avoiding seq_file and instead convert
error state to string in smaller chunks.
v2: better alloc flags, better tru
We never check the return values, and there's not much we could do on
errors anyway. Just simplify the signatures. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c |7 +++
drivers/gpu/drm/i915/i915_drv.h |6 +++---
drivers/gpu/drm/i915
Rename all VLV IOSF sideband register accessor functions to
vlv__{read,write}. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 24 -
drivers/gpu/drm/i915/i915_drv.h | 10 +++
drivers/gpu/drm/i915/i915_sysfs.c |2
The lower level sideband read/write functions already do this.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |6 --
drivers/gpu/drm/i915/intel_hdmi.c |4
2 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/inte
Both the intel_dpio_{read,write} and valleyview_{punit,nc}_{read,write}
use the IOSF sideband interface. They access the same registers and do
mostly the same stuff, but no shared code. There are even duplicate
register defines for the same registers. Both have locking, but the
former use dpio_lock
Group both the HSW/LPT SBI interface and VLV IOSF sideband register
accessor functions into a new file. No functional changes.
v2: also move intel_sbi_{read,write} (Daniel)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_drv.h |
Hi all, v2 of the vlv (and now partially also hsw) sideband refactoring
patches [1], addressing Daniel's comments and with two new patches
cleaning things up a bit.
BR,
Jani.
[1] http://mid.gmane.org/cover.1368642827.git.jani.nik...@intel.com
Jani Nikula (5):
drm/i915: group sideband register
On Wed, May 22, 2013 at 12:57:01PM +0300, Imre Deak wrote:
> On Wed, 2013-05-22 at 11:46 +0200, Daniel Vetter wrote:
> > On Wed, May 22, 2013 at 9:48 AM, Jani Nikula
> > wrote:
> > > On Tue, 21 May 2013, Imre Deak wrote:
> > >> We need this to avoid premature timeouts whenever scheduling a timeou
On Wed, May 22, 2013 at 1:24 AM, Dave Jones wrote:
> On Wed, May 22, 2013 at 01:10:36AM +0200, Daniel Vetter wrote:
> > On Wed, May 22, 2013 at 1:01 AM, Dave Jones wrote:
> > > This is new to me as of 3.10-rc2.
> >
> > If this is an ironlake with a DP output it's a know issue which seems
> >
On Tue, May 21, 2013 at 05:17:27PM +0200, Egbert Eich wrote:
> On Wed, May 08, 2013 at 12:50:24PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Follow the same sequence when enabling the cursor plane during
> > modeset. No point in doing this stuff in different order
On Wed, May 22, 2013 at 04:48:15PM +0800, Xiong Zhang wrote:
> HDMI Compliance Testing fail on i915 driver, the error log show:
> M1-M0=0b00(NO Data) of AVI InfoFrame Packet should correspond to the
> aspect ratio of the viewed image.Skip because AVI R3-R0 is no 1000
> (Same as picture aspect ratio
On Wed, 22 May 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> WARN_ON(!spin_is_locked()) is not a good idea on a UP system w/o
> spinlock debugging. Use WARN_ON_SMP() instead.
My bad, thanks for fixing this.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Ville Syrjälä
> ---
On Wed, 2013-05-22 at 11:46 +0200, Daniel Vetter wrote:
> On Wed, May 22, 2013 at 9:48 AM, Jani Nikula
> wrote:
> > On Tue, 21 May 2013, Imre Deak wrote:
> >> We need this to avoid premature timeouts whenever scheduling a timeout
> >> based on the current jiffies value. For an explanation see [1]
On Wed, May 22, 2013 at 9:48 AM, Jani Nikula
wrote:
> On Tue, 21 May 2013, Imre Deak wrote:
>> We need this to avoid premature timeouts whenever scheduling a timeout
>> based on the current jiffies value. For an explanation see [1].
>> The following patches will take the helper into use.
>>
>> On
On Wed, May 22, 2013 at 10:48 AM, Xiong Zhang wrote:
> HDMI Compliance Testing fail on i915 driver, the error log show:
> M1-M0=0b00(NO Data) of AVI InfoFrame Packet should correspond to the
> aspect ratio of the viewed image.Skip because AVI R3-R0 is no 1000
> (Same as picture aspect ratio)
>
> t
HDMI Compliance Testing fail on i915 driver, the error log show:
M1-M0=0b00(NO Data) of AVI InfoFrame Packet should correspond to the
aspect ratio of the viewed image.Skip because AVI R3-R0 is no 1000
(Same as picture aspect ratio)
the default value of active format aspect ratio is 0 which is inva
From: Ville Syrjälä
WARN_ON(!spin_is_locked()) is not a good idea on a UP system w/o
spinlock debugging. Use WARN_ON_SMP() instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel
On Tue, 21 May 2013, Imre Deak wrote:
> We need this to avoid premature timeouts whenever scheduling a timeout
> based on the current jiffies value. For an explanation see [1].
> The following patches will take the helper into use.
>
> Once the more generic solution proposed in the thread at [1] i
On Tue, May 21, 2013 at 06:24:38PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/5/20 Ville Syrjälä :
> > On Thu, May 09, 2013 at 05:13:41PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> We were previously calling sandybridge_update_wm on HSW, but the SNB
> >> function didn't really mat
On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin
wrote:
> On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter wrote:
>> Hi Dave,
>>
>> You're pull just reminded me that I've been sitting on a few small -fixes,
>> too. Nothing really major at all:
>> - fixup edp setup sequence (Dave)
>> - disable s
48 matches
Mail list logo
