On Fri, 25 Jan 2013 18:57:42 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we get one of these messages it means we did something wrong, and
> the first step to fix wrong things is to detect them and recognize
> they exist.
>
> For now, leave most messages as DRM_DEBUG_KMS. After we co
On Fri, 25 Jan 2013 18:57:40 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> While debugging these "unclaimed register" problems I concluded that
> having a backtrace is way much more useful than having the register
> address, since in a lot of cases the register address print on the
> messa
On Fri, 25 Jan 2013 18:57:38 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Otherwise, if the BIOS did anything wrong, our first I915_{READ,WRITE}
> will give us "unclaimed regsiter" messages.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_dma.c |4
> 1 file c
On Fri, 25 Jan 2013 18:57:37 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We plan to treat GEN7_ERR_INT as an interrupt, so use this register
> for the checks inside I915_WRITE. This way we can have the best of
> both worlds: the error message with a register address and the
> interrupt.
On Fri, 25 Jan 2013 18:57:36 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This avoids polluting i915_write##x and also allows us to reuse code
> on i915_read##x.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.c | 24
> 1 file changed, 1
Directory CacheLine Valid controls which PDEs are held in the directory
cache. Each bit represents 16 PDEs (16 PDEs at 4 bytes per entry is 1
cacheline, and therefore, almost makes sense).
Since we can now have an aliasing PPGTT which isn't 2GB, theoretically,
we should also modify the DCLV value
Aside from being a nice prep for some work I'm doing in PPGTT, this also
leaves us with a more accurate size in our gtt_total_entries member.
Since we can't actually use the PPGTT reserved part of the GGTT.
This will help some of the existing assertions find issues which would
overwrite the PPGTT
This refactor clearly identifies the GEN specific portion of the aliased
ppgtt code. Aside from some of the gen specific parts being extracted,
it also preps us for an upcoming patch that pulls out the size, which
has some nice benefits.
v2: Fix wonky error handling (Chris)
Signed-off-by: Ben Wid
When the PPGTT init fails, we may as well reuse the space that we were
reserving for the PPGTT PDEs.
This also fixes an extraneous mutex_unlock.
Reviewed-by: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 33 -
1 file changed,
- i915_gem_init_aliasing_ppgtt should now be static
- move i915_gem_init_ppgtt declaration to the right place
Reviewed-by: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
2 files changed, 2 insertions(+), 3 de
This work sort of led me on the gtt vtable distraction which ended in Daniel
doing his own version. I posted these originally about a month ago. I've
rebased them on dinq. I'd like to see them get merged since they still help
with some other work I'm doing on PPGTT.
Some of this work does conflict
From: Paulo Zanoni
If we get one of these messages it means we did something wrong, and
the first step to fix wrong things is to detect them and recognize
they exist.
For now, leave most messages as DRM_DEBUG_KMS. After we conclude that
a certain message should not be print since our code is cor
From: Paulo Zanoni
This is a debug feature that may pollute dmesg and scare users, so
leave it for the debug mode only. We usually ask for bug reporters to
use the debug flags, so we will still have the opportunity to catch a
lot of errors on users' machines.
Signed-off-by: Paulo Zanoni
---
dr
From: Paulo Zanoni
While debugging these "unclaimed register" problems I concluded that
having a backtrace is way much more useful than having the register
address, since in a lot of cases the register address print on the
message is not the register we're looking for.
We must fix all the "uncla
From: Paulo Zanoni
This will transform a few "Unclaimed register before XXX" into the
more precise version "Unclaimed register YYY (R)", where YYY is the
droid we're looking for, not XXX.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 14 --
1 file changed, 8 i
From: Paulo Zanoni
Otherwise, if the BIOS did anything wrong, our first I915_{READ,WRITE}
will give us "unclaimed regsiter" messages.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_dma.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/dri
From: Paulo Zanoni
We plan to treat GEN7_ERR_INT as an interrupt, so use this register
for the checks inside I915_WRITE. This way we can have the best of
both worlds: the error message with a register address and the
interrupt.
V2: Split in 2 patches: one for the macro, one for changing the
regi
From: Paulo Zanoni
This avoids polluting i915_write##x and also allows us to reuse code
on i915_read##x.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv
From: Paulo Zanoni
Hi
This is new version of 2 patches I sent last week. First we change how unclaimed
registers are currently reported by our driver and in the end we enable gen 7
error interrupts.
Here's what we do:
- Make the current code a little bit more organized
- Use FPGA_DBG instea
From: Ville Syrjälä
VGA0/VGA1/VGA_PD registers apparently haven't existed since Gen4.
Don't touch them on more recent platforms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_suspend.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/driver
From: Ville Syrjälä
From BSpec / SR01 - Clocking Mode:
"The following sequence must be used when disabling the VGA plane.
Write SR01 to set bit 5 = 1 to disable video output.
Wait for 100us.
Disable the VGA plane via Bit 31 of the MMIO VGA control."
So simply call i915_disable_vga() from i915
From: Ville Syrjälä
All display registers should now include the proper offset on VLV.
That means IS_DISPLAYREG() is now useless, and we can eliminate it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 104 +---
1 file changed, 1 insertio
From: Ville Syrjälä
The VGACNTRL register has moved around between different platforms.
To handle the differences add i915_vgacntrl_reg() which returns the
correct offset for the VGACNTRL register.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 10 ++
drivers/g
From: Ville Syrjälä
SR01 needs to be touched to disable VGA on non-UMS setups too.
So the sequencer registers need to include the appripriate offset
on VLV.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff -
From: Ville Syrjälä
When passing the DP/HDMI/SDVO registers to the encoder init functions,
include the VLV specific offset in the value.
v2: Resolved conflicts w/ VLV SDVO elimination
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 16
1 file changed,
From: Ville Syrjälä
Don't call intel_sdvo_init() for VLV.
Preserve the same behaviour as when intel_sdvo_init() would
have returned false.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers
From: Ville Syrjälä
Instead of using ADPA/VLV_ADPA/PCH_ADPA in various parts of
intel_crt code, just use adpa_reg which always contains the
correct value for the platform.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c | 29 +++--
1 file changed, 15 i
From: Ville Syrjälä
v2: Dropped the clock gating registers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8bc31bb..213ff6c 10064
Here are the remaining pieces for killing IS_DISPLAYREG()
I rebased it on top of the modeset_s-r stuff.
The last two VGA patches are not really related but I was lazy and
included them in the same set.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesk
On Fri, Jan 25, 2013 at 09:09:58PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 25, 2013 at 05:53:21PM +0100, Daniel Vetter wrote:
> > The only thing we really care about that it is off. To do so, reuse
> > the recently created i915_redisable_vga function, which is already
> > used to put obnoxious fi
On Fri, Jan 25, 2013 at 05:53:21PM +0100, Daniel Vetter wrote:
> The only thing we really care about that it is off. To do so, reuse
> the recently created i915_redisable_vga function, which is already
> used to put obnoxious firmware into check on lid reopening.
>
> Signed-off-by: Daniel Vetter
From: Paulo Zanoni
Instead of setting it at the beginning of haswell_crtc_mode_set, let's
set it at the beginning of intel_crtc_mode_set. When
intel_crt_mode_set calls drm_vblank_pre_modeset we already need to
have the transcoder_edp correctly set, because eventually
drm_vblank_pre_modeset calls
From: Paulo Zanoni
Our suspend code touches a lot of registers all over the place, so we
need to enable the power well before suspending.
Signed-off-by: Paulo Zanoni
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/g
From: Paulo Zanoni
If the power well is disabled, we should not try to read its
registers, otherwise we'll get "unclaimed register" messages.
V2: Don't check whether the power well is enabled or not, just check
whether we asked it to be enabled or not: if we asked to disable the
power well, don'
From: Paulo Zanoni
We should avoid touching registers that are on the power down well
when we don't need to, because if we touch these registers when the
power well is disabled we'll get tons of "unclaimed register"
messages. This commit fixes some of these messages.
Signed-off-by: Paulo Zanoni
From: Daniel Vetter
We can disable (almost) all the display hw if we only use pipe A, with
the integrated edp transcoder on port A. Because we don't set the cpu
transcoder that early (yet), we need to help us with a trick to simply
check for any edp encoders.
And wrt the old code: Can anyone exp
From: Paulo Zanoni
The current code was wrong in many different ways, so this is a full
rewrite. We don't have "different power wells for different parts of
the GPU", we have a single power well, but we have multiple registers
that can be used to request enabling/disabling the power well. So
let'
From: Paulo Zanoni
Previously I sent "drm/i915: don't read DP_TP_STATUS(PORT_A)", but
after some more discussion I was told by a hardware engineer that we
don't really need to send the idle patterns before the normal pattern
in our current code: we only need this for a DP mode that we currently
d
From: Paulo Zanoni
Hi
So here's the second version of the patches that fix some "unclaimed register"
errors, making our driver good enough to start disabling the power well when
possible (we're still not 100% "unclaimed register" free, recent patches added
some new unclaimed register problems wh
On Fri, Jan 25, 2013 at 10:02:26AM +0800, Zhang Rui wrote:
> On Fri, 2013-01-25 at 09:59 +0800, Zhenyu Wang wrote:
> > On 2013.01.24 19:49:40 +0800, Zhang Rui wrote:
> > > I need some graphics experts' comments before sending it out.
> > >
> >
> > Please send to intel-gfx@lists.freedesktop.org fo
At 2013-01-23 13:02, Daniel Vetter wrote:
Maybe the easiest way is to shoot for a
board with 2x HDMI or DP in total, since you can always use a passive
HDMI->DP dongle to drive the DP port in HDMI mode. But even just
finding boards with 3x digital output seems to be hard.
So, just to make sure
On Fri, 2013-01-25 at 09:59 +0800, Zhenyu Wang wrote:
> On 2013.01.24 19:49:40 +0800, Zhang Rui wrote:
> > I need some graphics experts' comments before sending it out.
> >
>
> Please send to intel-gfx@lists.freedesktop.org for i915 specific issue.
>
I want to get some internal feedback before s
With the probe call in our dispatch table, we can now cut away two of
the remaining members in the intel_gtt shared struct.
v2: Rebased on top of Daniel's series
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c | 36 --
drivers/gpu/drm/i915/
The idea, and much of the code came originally from:
commit 0712f0249c3148d8cf42a3703403c278590d4de5
Author: Ben Widawsky
Date: Fri Jan 18 17:23:16 2013 -0800
drm/i915: Create a vtable for i915 gtt
Daniel didn't like the color of that patch series, and so I asked him to
start something wh
From: Daniel Vetter
At the moment only cosmetics, but being able to initialize/cleanup
arbitrary ppgtt address spaces paves the way to have more than one of
them ... Just in case we ever get around to implementing real
per-process address spaces. Note that in that case another vfunc for
ppgtt wou
From: Daniel Vetter
All the other gen6+ hw code has the gen6_ prefix, so be consistent
about it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt
From: Daniel Vetter
Like for the global gtt we want a notch more flexibility here. Only
big change (besides a few tiny function parameter adjustments) was to
move gen6_ppgtt_insert_entries up (and remove _sg_ from its name, we
only have one kind of insert_entries since the last gtt cleanup).
We
From: Daniel Vetter
We have a few too many differences here, so finally take the prepared
abstraction and run with it. A few smaller changes are required to get
things into shape:
- move i915_cache_level up since we need it in the gt funcs
- split up i915_ggtt_clear_range and move the two functi
Hi,
I didn't find this reported, but maybe it has been, I didn't search for
too long. I'm using 3.8.0-rc4 (plus wireless bits), and lockdep is
unhappy. Note that I am booting with "no_console_suspend".
[ 73.320586] ==
[ 73.320587] [ INFO: po
Note that this slightly changes the order, but we only move it within
the block of registers that restore encoder state. Specifically LVDS
is now restored after DP, whereas previously it was done before.
Legacy vga is still restored afterwards, which seems to be the
important thing (if there's any
The only thing we really care about that it is off. To do so, reuse
the recently created i915_redisable_vga function, which is already
used to put obnoxious firmware into check on lid reopening.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i9
Similarly to how i915_dma.c is shaping up to be the dungeon hole for
all things supporting dri1, create a new one to hide all the crazy
things which are only really useful for ums support. Biggest part is
the register suspend/resume support.
Unfortunately a lot of it is still intermingled with bit
That way the control flow is clearer, and it prepares the stage
to extract these ums functions and hide them somewhere.
There's still tons of display stuff outside of these, but that
requires more work.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_suspend.c | 38 +++---
Hi all,
Jani's recent comment that this is a mess spurred me to pick this up again. An
it looks like it'll simplify parts of the vlv display register rework, too (the
3rd patch to disable legacy VGA safe/restore).
Big move here is that I'm starting a i915_ums.c file to hide all this
display-relat
On Fri, Jan 25, 2013 at 06:20:53PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 25, 2013 at 05:06:51PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 25, 2013 at 12:51:15PM +0200, Ville Syrjälä wrote:
> > > On Thu, Jan 24, 2013 at 11:41:53PM +0100, Daniel Vetter wrote:
> > > > On Thu, Jan 24, 2013 at 03:
On Fri, Jan 25, 2013 at 05:18:58PM +0100, Daniel Vetter wrote:
> On Fri, Jan 25, 2013 at 12:27:54PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 24, 2013 at 11:44:09PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 24, 2013 at 03:29:54PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From
On Fri, Jan 25, 2013 at 5:20 PM, Ville Syrjälä
wrote:
>> > DSPCLK_GATE_D is used in intel_i2c_quirk_set(). OTOH gma500 has the
>> > same code commented out, so it may be that we can skip it too. Anyone
>> > have more details on this quirk?
>>
>> Afaict that quirk is for pnv only.
>
> So, should we
On Fri, Jan 25, 2013 at 05:00:42PM +0100, Daniel Vetter wrote:
> On Fri, Jan 25, 2013 at 02:21:16PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 24, 2013 at 10:39:52PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 24, 2013 at 03:29:34PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From
On Fri, Jan 25, 2013 at 05:06:51PM +0100, Daniel Vetter wrote:
> On Fri, Jan 25, 2013 at 12:51:15PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 24, 2013 at 11:41:53PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 24, 2013 at 03:29:50PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > #de
On Fri, Jan 25, 2013 at 02:26:24PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 24, 2013 at 10:37:28PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 24, 2013 at 03:29:33PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Signed-off-by: Ville Syrjälä
> >
> > It's
On Fri, Jan 25, 2013 at 12:27:54PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 24, 2013 at 11:44:09PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 24, 2013 at 03:29:54PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Signed-off-by: Ville Syrjälä
> >
> > Admi
On Fri, Jan 25, 2013 at 02:04:03PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/25 Ville Syrjälä :
> > On Fri, Jan 25, 2013 at 01:40:08PM -0200, Paulo Zanoni wrote:
> >> Hi
> >>
> >> 2013/1/21 Ville Syrjälä :
> >> > On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
> >> >> From: Paulo Za
On Fri, Jan 25, 2013 at 12:51:15PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 24, 2013 at 11:41:53PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 24, 2013 at 03:29:50PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > #define DSTATE_GFX_RESET_I830 (1<<6)
> > > #define DSTA
Hi
2013/1/25 Ville Syrjälä :
> On Fri, Jan 25, 2013 at 01:40:08PM -0200, Paulo Zanoni wrote:
>> Hi
>>
>> 2013/1/21 Ville Syrjälä :
>> > On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> If the power well is disabled, we should not try to read its
>
On Fri, Jan 25, 2013 at 02:03:40PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 24, 2013 at 11:05:21PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 24, 2013 at 03:29:42PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > When passing the DP/HDMI/SDVO registers to
On Fri, Jan 25, 2013 at 02:21:16PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 24, 2013 at 10:39:52PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 24, 2013 at 03:29:34PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Signed-off-by: Ville Syrjälä
> >
> > We a
On Fri, Jan 25, 2013 at 01:40:08PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/21 Ville Syrjälä :
> > On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> If the power well is disabled, we should not try to read its
> >> registers, otherwise we'll get "un
Hi
2013/1/21 Ville Syrjälä :
> On Fri, Jan 18, 2013 at 06:29:08PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> If the power well is disabled, we should not try to read its
>> registers, otherwise we'll get "unclaimed register" messages.
>>
>> Signed-off-by: Paulo Zanoni
>> ---
>> driv
On Thu, Jan 24, 2013 at 03:54:19PM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/24 :
> > From: Ville Syrjälä
> >
> > Use intel_dig_port->port rather than intel_dp->output_reg.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 9 +
> > 1 file changed, 5 in
On Thu, Jan 24, 2013 at 10:37:28PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:33PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
>
> It's true that we safe/restore these suckers across suspend/resume, but I
> have no id
On Thu, Jan 24, 2013 at 10:39:52PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:34PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
>
> We already have a switch since VGACNTRL moved around on pch-split
> platforms, too. To
On Thu, Jan 24, 2013 at 11:01:42PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:40PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
>
> With Paulo's patch to no longer safe/resume DSPARB on gen4+ gone, there's
> no user of
On Thu, Jan 24, 2013 at 11:05:21PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:42PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When passing the DP/HDMI/SDVO registers to the encoder init functions,
> > include the VLV specific offset in the value.
On Thu, Jan 24, 2013 at 11:12:10PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:45PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > ADPA doesn't include the required offset, so don't use it in VLV
> > specific code. VLV_ADPA must be used instead.
> >
>
On Thu, Jan 24, 2013 at 11:22:15PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:47PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
>
> I've noticed that the PALETTE moved around a bit for pch-split platforms
> already, bu
On Thu, Jan 24, 2013 at 11:26:10PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:49PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Don't touch VGA0/VGA1/VGA_PD in suspend/resume paths.
> >
> > Signed-off-by: Ville Syrjälä
>
> By sheer coincidence I'
On Thu, Jan 24, 2013 at 11:41:53PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:50PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 14 +++---
> > 1 file changed, 7 ins
Hi Dave,
Just a few small things:
- 2x workaround bits from Chris to fix up the new scanline waits enabled
in 3.8 on snb. People who've been struck by this on dual-screen also
need to upgrade the ddx.
- Dump the kernel version into i915_error_state, we've had a few mixups
there recently.
- D
On Thu, Jan 24, 2013 at 11:44:09PM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2013 at 03:29:54PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
>
> Admittedly I haven't checked them closely, but with my proposed patch in
> he modeset_
79 matches
Mail list logo
