Benoit,
Great news.
I confirm it works. Thanks a bunch for finding the issue!
Next step I guess is to make gmux work to be able to swicth the nvidia
power off whenever we don't need it.
Cheers,
Francois
Dan, do you still need the register dumps (with C pipe)?
On Thu, 2012-08-09 at 22:09 +0200
On Thu, Aug 09, 2012 at 03:58:46PM +0100, Lespiau, Damien wrote:
> On Wed, Aug 8, 2012 at 10:35 PM, Daniel Vetter wrote:
> > Review&testing highly welcome.
>
> Reviewed-by: Damien Lespiau
Ok, I've slurped in all the patches for -next, thanks for comments&review.
-Daniel
--
Daniel Vetter
Mail:
Since forcewake is now protected by a spinlock, we don't need to grab
dev->struct_mutex any more. This way we can also get rid of a stale
comment, noticed by Ben Widawsky while reviewing some locking changes.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 ---
On Wed, 8 Aug 2012 23:35:40 +0200
Daniel Vetter wrote:
> I have the faint hope that the total absence of any locking for the
> rps code wasn't too good an idea and could very well have caused some
> rc6 related regressions.
>
> Unfortunately we've never managed to reproduce these issues on any
On Thu, 9 Aug 2012 15:07:02 +0200
Daniel Vetter wrote:
> It's no fun if your shell hangs when the driver has gone on vacation
> and you want to know why ...
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 32 +---
> 1 file changed,
Hello,
If find a workaround to video corruption for intel gpu on macbook pro
retina.
the work around work as follow :
- patch the kernel 3.5.1 with attached patch
- that OS X and switch to intgrated gpu only with:
http://codykrieger.com/gfxCardStatus
- reboot with the patched kernel
I did not
On Thu, Aug 09, 2012 at 10:10:05AM -0700, ron minnich wrote:
> Thanks for the suggestions, I did move forward to 3.6-rc1.
>
> It gives me lots of messages I expect, but does not yet work...
>
> http://pastebin.com/RLp5qjQX
>
> I'm still convinced there is some basic thing I'm not setting up
> ri
On Thu, Aug 09, 2012 at 02:30:21PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/8/9 Jani Nikula :
> > On Wed, 08 Aug 2012, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> If we don't find the exact refresh rate, go with the next one. This
> >> makes some modes work for me. They won't have the
Hi
2012/8/9 Jani Nikula :
> On Wed, 08 Aug 2012, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If we don't find the exact refresh rate, go with the next one. This
>> makes some modes work for me. They won't have the best settings, but
>> will at least have something. Just returning from this f
Thanks for the suggestions, I did move forward to 3.6-rc1.
It gives me lots of messages I expect, but does not yet work...
http://pastebin.com/RLp5qjQX
I'm still convinced there is some basic thing I'm not setting up
right; still getting these pipe0 stuck messages. Now, the one thing
I'm definit
Hi
2012/8/9 Daniel Vetter :
> On Thu, Aug 09, 2012 at 12:55:41PM +0300, Jani Nikula wrote:
>> On Wed, 08 Aug 2012, Paulo Zanoni wrote:
>> > From: Paulo Zanoni
>> >
>> > Correctly erase the values previously set and also check for 6pbc and
>> > 10bpc.
>>
>> 6 *bpc*. But is the 6 or 10 bpc usage b
On Wed, Aug 08, 2012 at 02:15:32PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> By looking at the current way we're using these definitions I don't
> think this commit will fix any bug, but programmers from the future
> are evil and will certainly find ways to combine macro expansion with
On Thu, Aug 09, 2012 at 12:55:41PM +0300, Jani Nikula wrote:
> On Wed, 08 Aug 2012, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Correctly erase the values previously set and also check for 6pbc and
> > 10bpc.
>
> 6 *bpc*. But is the 6 or 10 bpc usage below correct anyway, as the spec
> sa
On Wed, Aug 08, 2012 at 10:41:14PM +0100, Chris Wilson wrote:
> On Wed, 8 Aug 2012 22:01:51 +0200, Daniel Vetter
> wrote:
> > Handy for lazy people like me, or when people forget to add the output
> > of lspci -nn.
> >
> > v2: Chris Wilson noticed that we have this duplicated already in the
> >
On Wed, Aug 8, 2012 at 10:35 PM, Daniel Vetter wrote:
> Review&testing highly welcome.
Reviewed-by: Damien Lespiau
FWIW, I'll be running my main dev machine (ILK) with RC6 enabled from
now one and see what happens.
--
Damien
___
Intel-gfx mailing li
We change the drps/ips sw/hw state from different callers: Our own irq
handler, the external intel-ips module and from process context. Most
of these callers don't take any lock at all.
Protect everything by making the mchdev_lock irqsave and grabbing it in
all relevant callsites. Note that we hav
The update_gfx_val function called from mark_busy wasn't taking the
mchdev_lock, as it should have. Also sprinkle a few spinlock asserts
over the code to document things better.
Things are still rather confusing, especially since a few variables
in dev_priv are used by both the gen6+ rps code and
It's no fun if your shell hangs when the driver has gone on vacation
and you want to know why ...
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915
- Take the dev->struct_mutex around access the corresponding state
(and adjusting the rps hw state).
- Add an assert to gen6_set_rps to ensure we don't forget about this
in the future.
- Don't set up the min/max_freq files if it doesn't apply to the hw.
And do the same for the gen6+ cache sha
On Thu, Aug 09, 2012 at 10:43:53AM +0100, Chris Wilson wrote:
> On Wed, 8 Aug 2012 23:35:32 +0200, Daniel Vetter
> wrote:
> > Hi all,
> >
> > Essentially just rebase, with Ben's review comments taking into account and
> > one
> > WARN_ON(mutex_is_locked) moved around a bit.
> >
> > Review&tes
On Wed, 08 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> HDMI already works fine on Haswell, but we still have room for improvements.
> This series will make us less dependent on the bits set by the BIOS, will fix
> cases where DVI was not working and will also improve the cases where we
On Wed, 08 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The current situation is: we use WR PLL1 for everything, so if we have
> 2 HDMI outputs they will share the same PLL. As a consequence, when
> you set a mode on HDMI2, HDMI1 will change its refresh rate. If the
> modes are too diff
On Wed, 08 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we don't find the exact refresh rate, go with the next one. This
> makes some modes work for me. They won't have the best settings, but
> will at least have something. Just returning from this function when
> we don't find the p
On Thu, Aug 09, 2012 at 10:58:30AM +0100, Chris Wilson wrote:
> Avoid the forcewake overhead when simply retiring requests, as often the
> last seen seqno is good enough to satisfy the retirment process and will
> be promptly re-run in any case. Only ensure that we force the coherent
> seqno read w
Avoid the forcewake overhead when simply retiring requests, as often the
last seen seqno is good enough to satisfy the retirment process and will
be promptly re-run in any case. Only ensure that we force the coherent
seqno read when we are explicitly waiting upon a completion event to be
sure that
On Wed, 08 Aug 2012, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Correctly erase the values previously set and also check for 6pbc and
> 10bpc.
6 *bpc*. But is the 6 or 10 bpc usage below correct anyway, as the spec
says they are not supported by HDMI or DVI? (Either way, the erase part
of the
On Wed, 8 Aug 2012 23:35:32 +0200, Daniel Vetter
wrote:
> Hi all,
>
> Essentially just rebase, with Ben's review comments taking into account and
> one
> WARN_ON(mutex_is_locked) moved around a bit.
>
> Review&testing highly welcome.
>
> Cheers, Daniel
>
> Daniel Vetter (8):
> drm/i915: p
On Wed, 8 Aug 2012 23:35:34 +0200, Daniel Vetter
wrote:
> - Take the dev->struct_mutex around access the corresponding state
> (and adjusting the rps hw state).
> - Add an assert to gen6_set_rps to ensure we don't forget about this
> in the future.
> - Don't set up the min/max_freq files if
Avoid the forcewake overhead when simply retiring requests, as often the
last seen seqno is good enough to satisfy the retirment process and will
be promptly re-run in any case. Only ensure that we force the coherent
seqno read when we are explicitly waiting upon a completion event to be
sure that
Use _PIPE macro to get correct register definition for IBX/CPT, discard
old variable "i" way.
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/i915_reg.h | 24
drivers/gpu/drm/i915/intel_display.c | 22 +-
2 files changed, 33 insertions(
Added new haswell_write_eld() to initialize Haswell HDMI audio registers
to generate an unsolicited response to the audio controller driver to
indicate that the controller sequence should start.
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/
This patch series enable HDMI audio on Haswell platform, not DP audio.
The DP enablement will come after the DP patches are upstream.
I tested this patch on Sharkbay machine and i could hear clear sound from
HDMI port.
V2 patches fixed one warning and some type errors.
V3 patches changes:
- chan
HDMI audio related registers will be configured in write_eld callback.
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/intel_ddi.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 32604ac..
Add hsw audio registers definition
Signed-off-by: Wang Xingchao
---
drivers/gpu/drm/i915/i915_reg.h | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81a3de6..55aa10e 100644
--- a
[Cc re-added, please don't drop Cc]
At Thu, 09 Aug 2012 04:00:07 +0200,
Øyvind Kvålsvoll wrote:
>
> Patch tested now on alsa-1.0.25, compiled for 3.2.xx kernel.
>
> Unfortunately this patch does not fix the problem, still only noise on
> TrueHD and DTS-HD (on HDMI).
So it didn't change anythin
35 matches
Mail list logo
