Hi
2012/9/9 Daniel Vetter :
> This has been tons of fun to figure out with git blame. The first
> notion of this code block goes back to the original cpu edp enabling
> for ilk in
>
> commit 32f9d658aee5be09ebdd28fc730630e61d0b46db
> Author: Zhenyu Wang
> Date: Fri Jul 24 01:00:32 2009 +0800
>
On Thu, Sep 13, 2012 at 04:43:57PM -0300, Paulo Zanoni wrote:
> 2012/9/13 Daniel Vetter :
> > On Thu, Sep 13, 2012 at 04:11:20PM -0300, Paulo Zanoni wrote:
> >> Hi
> >>
> >> 2012/9/6 Daniel Vetter :
> >> > See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
> >> > applies to all
On Thu, 6 Sep 2012 22:08:35 +0200
Daniel Vetter wrote:
> Hopefully this makes userspace slightly less confused about us
> frobbing the dpms state behind its back. Yeah, it would be better
> to be more careful with not changing the dpms state, but that is
> quite more invasive.
>
> Signed-off-by
On Thu, 6 Sep 2012 22:08:34 +0200
Daniel Vetter wrote:
> ... because our current set_mode implementation doesn't bother to adjust
> for the dpms state, we just forcefully update it. So stop pretending that
> we're better than we are and rip out this extranous call.
>
> Note that this totally co
On Thu, 6 Sep 2012 22:08:33 +0200
Daniel Vetter wrote:
> Because they should have been disabled when shutting down the display
> pipe previously. To ensure that this is the case, add a few assserts
> instead of unconditionally disabling the fdi link.
>
> Signed-off-by: Daniel Vetter
> ---
> d
On Thu, 6 Sep 2012 22:08:32 +0200
Daniel Vetter wrote:
> Even with the old crtc helper code we should have disabled all
> encoders on that pipe by now, and with the new code this would
> definitely paper over a bug. We already have the necessary checks
> in place in intel_disable_transcoder, so
Good evening.
Ii have a config question about a mulit monitor setup:
I'm using the intel driver xf86-video-intel 2.20.0 and want to start a single
driver instance for each screen in xorg in order to use xinerama. Because at
the moment every window which i maximize spans over the whole screen, i
2012/9/13 Daniel Vetter :
> On Thu, Sep 13, 2012 at 04:11:20PM -0300, Paulo Zanoni wrote:
>> Hi
>>
>> 2012/9/6 Daniel Vetter :
>> > See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
>> > applies to all platforms where we currently support eDP on, i.e. ilk,
>> > snb & ivb.
>> >
Good evening.
I have a config question about a multi monitor setup:
I'm using the intel driver xf86-video-intel 2.20.0 and want to start a single
driver instance for each screen in xorg in order to use xinerama. Because at
the moment every window which i maximize spans over the whole screen, i
On Thu, Sep 13, 2012 at 02:46:19PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/9/6 Daniel Vetter :
> > With the previous patch to clean up where exactly these two functions
> > are getting called, this patch can tackle the enable/disable code
> > itself:
>
> This is the kind of patch that's hard to
On Thu, Sep 13, 2012 at 02:46:19PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/9/6 Daniel Vetter :
> > With the previous patch to clean up where exactly these two functions
> > are getting called, this patch can tackle the enable/disable code
> > itself:
>
> This is the kind of patch that's hard to
On Thu, Sep 13, 2012 at 04:11:20PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/9/6 Daniel Vetter :
> > See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
> > applies to all platforms where we currently support eDP on, i.e. ilk,
> > snb & ivb.
> >
>
> Ok, so I looked at BSpec and
Hi
2012/9/6 Daniel Vetter :
> See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This
> applies to all platforms where we currently support eDP on, i.e. ilk,
> snb & ivb.
>
Ok, so I looked at BSpec and the conclusion is: shouldn't we do this
for eDP _and_ DP instead of just eDP? Th
Hi
2012/9/6 Daniel Vetter :
> These have been added because dp links are fiddle things and don't
> like it when we try to re-train an enabled output (or disable a
> disabled output harder). And because the crtc helper code is
> ridiculously bad add tracking the modeset state.
>
> But with the new
Hi
2012/9/6 Daniel Vetter :
> With the previous patch to clean up where exactly these two functions
> are getting called, this patch can tackle the enable/disable code
> itself:
This is the kind of patch that's hard to proof-read. Basically, IMHO,
the intel_dp->DP variable makes things harder to
On Wed, Sep 12, 2012 at 06:00:58PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/9/6 Daniel Vetter :
> > By using the new pre_enabel/post_disable functions.
>
> s/enabel/enable
>
> >
> > To ensure that we only frob the cpu edp pll while the pipe is off add
> > the relevant asserts. Thanks to the new
While reading docs I've noticed that this special workaround to select
the 1.6 GHz DP clock only applies to pre-production ilk machines.
Since the registers we're touching here are rather undocumented and
might be harmful on later chips, rip it out.
For the Bspec reference of this w/a look in "vol
Ben Widawsky writes:
> Also, as a bikeshed you could probably get a much better detection with
> a CRC or something similar.
Wonder if you could use the existing MD5 code in the kernel; would avoid
all sorts of unfortunate false-positives.
--
keith.pack...@intel.com
pgpOfytF7Loyb.pgp
Descrip
At Thu, 13 Sep 2012 16:18:08 +0200,
Daniel Vetter wrote:
>
> On Thu, Sep 13, 2012 at 4:00 PM, Takashi Iwai wrote:
> > But, this makes me wonder why this patch can't go into 3.6. It's a
> > clear bug and the fix is trivial.
> >
> > Daniel, isn't it better to pick the fix (for 3.6) to drm-intel-fi
On Thu, Sep 13, 2012 at 4:00 PM, Takashi Iwai wrote:
> But, this makes me wonder why this patch can't go into 3.6. It's a
> clear bug and the fix is trivial.
>
> Daniel, isn't it better to pick the fix (for 3.6) to drm-intel-fixes,
> then merge back to drm-intel-next?
Well, on a quick read-throu
Hi Dave,
The big ticket item here is the new i915 modeset infrastructure.
Shockingly it didn't not blow up all over the place (i.e. I've managed to
fix the ugly issues before merging). 1-2 smaller corner cases broke, but
we have patches. Also, there's tons of patches on top of this that clean
out
At Thu, 13 Sep 2012 21:53:12 +0800,
Wang Xingchao wrote:
>
> Hi Takashi,
>
> 2012/9/13 Takashi Iwai :
> > At Thu, 13 Sep 2012 11:19:00 +0800,
> > Wang Xingchao wrote:
> >>
> >> Clear Audio Enable bit to trigger unsolicated event to notify Audio
> >> Driver part the HDMI hot plug change. The patch
Hi Takashi,
2012/9/13 Takashi Iwai :
> At Thu, 13 Sep 2012 11:19:00 +0800,
> Wang Xingchao wrote:
>>
>> Clear Audio Enable bit to trigger unsolicated event to notify Audio
>> Driver part the HDMI hot plug change. The patch fixed the bug when
>> remove HDMI cable the bit was not cleared correctly.
On Thu, Sep 13, 2012 at 12:37 PM, Chris Wilson wrote:
> On Wed, 12 Sep 2012 18:47:12 +0100, Damien Lespiau
> wrote:
>> Hi,
>>
>> This series introduces stereo 3D modes support and is split in 3 chunks:
>>
>> 1. 3 kernel patches to parse the 3D_present flag of the HDMI CEA vendor
>> block,
>>
On Thu, 13 Sep 2012 13:13:29 +0200, Daniel Vetter
wrote:
> While reading docs I've noticed that this special workaround to select
> the 1.6 GHz DP clock only applies to pre-production ilk machines.
> Since the registers we're touching here are rather undocumented and
> might be harmful on later c
While reading docs I've noticed that this special workaround to select
the 1.6 GHz DP clock only applies to pre-production ilk machines.
Since the registers we're touching here are rather undocumented and
might be harmful on later chips, rip it out.
For the Bspec reference of this w/a look in "vol
On Thu, Sep 13, 2012 at 11:10:14AM +0100, Chris Wilson wrote:
> On Wed, 12 Sep 2012 23:24:09 +0200, Daniel Vetter
> wrote:
> > It's bogus.
> >
> > If I've followed the history of this piece of code correctly, i.e. the
> > initial register write with the following vblank wait, this goes all
> > t
On Wed, 12 Sep 2012 18:47:12 +0100, Damien Lespiau
wrote:
> Hi,
>
> This series introduces stereo 3D modes support and is split in 3 chunks:
>
> 1. 3 kernel patches to parse the 3D_present flag of the HDMI CEA vendor block,
>to expose 3D formats flags in modes and to add a new property on c
On Wed, 12 Sep 2012 23:24:09 +0200, Daniel Vetter
wrote:
> It's bogus.
>
> If I've followed the history of this piece of code correctly, i.e. the
> initial register write with the following vblank wait, this goes all
> the way back to the original enabling of DP support in
>
> commit a4fc5ed698
Summary
We finished a new round of kernel testing. Generally, in this circle,7 bugs are
closed, 14 bugs are still open.
Test Environment
The Linux Kernel, the operating system core itself
Kernel: (drm-intel-testing)c3c3d4e9c2daeca01c42040cda0e5e0579c5c80b
Some additional commit info:
Merge: e0419
At Thu, 13 Sep 2012 11:19:00 +0800,
Wang Xingchao wrote:
>
> Clear Audio Enable bit to trigger unsolicated event to notify Audio
> Driver part the HDMI hot plug change. The patch fixed the bug when
> remove HDMI cable the bit was not cleared correctly.
>
> In intel_enable_hdmi(), if intel_hdmi->h
On Wed, 12 Sep 2012 13:27:10 -0700
Jesse Barnes wrote:
> This adds a module parameter, gtt_suspend_verify, that will enable a
> simple GTT checksum across suspend and resume.
>
> We currently spend a good amount of time (>20ms) clearing all the GTT
> PTEs at resume time, even though this may not
32 matches
Mail list logo
