http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-intel30git has a lot of intel(0):
switch to mode in sequence. Is this normal/expected behavior? Known bug?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg.
On Tue, 2014-04-22 at 13:52 -0600, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:37:37AM +0800, Zhao Yakui wrote:
> > Based on the hardware spec, the BDW GT3 machine has two independent
> > BSD ring that can be used to dispatch the video commands.
> > So just initialize it.
> >
> > V3->V4: Fol
On Thu, 2014-04-24 at 09:21 -0600, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:37:37AM +0800, Zhao Yakui wrote:
> > Based on the hardware spec, the BDW GT3 machine has two independent
> > BSD ring that can be used to dispatch the video commands.
> > So just initialize it.
> >
> > V3->V4: Fol
On 04/24/2014 08:39 AM, Chris Wilson wrote:
> On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
>> Is it possible that there's still a get_page() reference that's holding
>> those pages in place from the graphics code?
>
> Not from i915.ko. The last resort of our shrinker is to drop all
On Fri, 25 Apr 2014, Pavel Machek wrote:
> > > And we have a winner here :-)
> > >
> > > Ok, it was not as painfull as I feared.
> > >
> > > It does not revert cleanly, but doing it by hand was not that bad.
> >
> > Oh my. That is bizarre, can you check whether you have
> >
> > commit 9991ae78
> On Thu, Apr 24, 2014 at 09:40:38PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > And if you can indeed reliably reproduce this a bisect could be really
> > > useful.
> >
> > And we have a winner here :-)
> >
> > Ok, it was not as painfull as I feared.
> >
> > It does not revert cleanly, but d
Hi!
> > > And if you can indeed reliably reproduce this a bisect could be really
> > > useful.
> >
> > And we have a winner here :-)
> >
> > Ok, it was not as painfull as I feared.
> >
> > It does not revert cleanly, but doing it by hand was not that bad.
>
> Oh my. That is bizarre, can you c
To be able to do this we need to separately keep track of how many
crtcs need a given WRPLL and how many actually actively use it. The
common shared dpll framework already has all this, including massive
state readout and cross checking. Which allows us to do this switch in
a fairly small patch.
S
Keeping track of the power domains is a bit messy since crtc->active
is currently updated by the platform hooks, but we need to be aware of
which state transition exactly is going on. Maybe we simply need to
shovel all the power domain handling down into platform code to
simplify this. But doing th
Still tacked onto the side, but slowly getting there.
v2: Don't forget the debugfs file.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c |
To make things a bit more manageable extract a new function for
reading out common ddi port state. This means a bit of duplication
between encoders and the core since both look at the same registers,
but doesn't seem worth to make a fuzz about.
We can also remove the state readout code in intel_dd
Mostly this patch is one big excersize in deleting code and asserts
which are no longer needed. Note that we still abuse the shared dpll
framework a bit since we call the enable/disable functions from the
crtc mode_set and off hooks. But changing the actual hardware sequence
will be done in the nex
This time around another cute hack to pre-fill the pll->hw_state with
the right values. And also remove a bunch of checks which will be
replaced by lots more checks in the common framework.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 51 +++
Similar to how the ->crtc_mode_set hook should touch the hardware to
enable anything the ->crtc_off hook should disable anything in the
hardware. Otherwise runtime pm for dpms will not work.
Currently the only things left int the haswell_crtc_off hook is
disabling the ddi plls. We can't move the W
This way only the dynamic WRPLL selection for hdmi ddi mode is
done in intel_ddi_pll_select.
v2: Don't clobber the precomputed values when selecting clocks fro
hdmi encoders.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 4 +++-
drivers/gpu/drm/i915/intel_ddi.c | 34 +++--
Yet another pch encoder special case quenched from haswell modeset
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 11 ++-
drivers/gpu/drm/i915/intel_display.c | 2 --
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
With this all the pch pre-enable work has been moved into the special
hsw crt encoder functions.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 4
drivers/gpu/drm/i915/intel_display.c | 2 --
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
Currently still with a redudant WARN_ON in there, the common shared
dpll code will take care of this in the future.
Also we need to flip the switch for the transitional hack now to make
sure that we disable the right pll.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 2
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae45041c..c99951fdc572 100644
--- a/drivers/gpu/drm/i915/i915_d
With this all the pch encoder specific code is now gone from the
haswell ->crtc_disable function. Which finally readies the stage
for the last piece of all the hsw crt encoder rework, namely also
moving the SPLL disabling into the encoder post_disable function.
Which the next patch will do.
Signed
The call to intel_ddi_pll_enable in haswell_crtc_mode_set is the only
function that still touches the hardware state from the crtc mode_set
callback on hsw. Since the SPLL isn't ever shared we can easily take
it out into the hsw crt encoder functions.
Temporarily we'll loose a bit of WARN_ON cover
The WRPLLs won't use them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index babeb7e92ee4..b01ee265310f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/
Just boring sed job for preparation.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 4 ++--
drivers/gpu/drm/i915/intel_ddi.c | 30 +++---
drivers/gpu/drm/i915/intel_drv.h | 5 +++--
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/dr
Just filing in names and ids, but not yet officially registering them
so that the hw state cross checker doesn't completely freak out about
them. Still since we do already read out and cross check
config->shared_dpll the basics are now there to flesh out the wrpll
shared dpll implementation.
The i
Unfortunately this requires a bunch of exports for pch handling
functions, but there's been various plans floating around to extract
them all into an intel_pch.c helper library anyway.
In any case haswell_crtc_enable is now pch encoder free.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915
We can just create a ->post_disable hook to shovel all the fdi/pch
specific code into it - it's all only used by the crt encoder anyway.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 26 ++
drivers/gpu/drm/i915/intel_display.c | 18 --
Step 2 in pimping the hsw_crt_post_disable hook.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_c
A lot of the code in set_base is uncessary when the crtc is off, so we
can get rid of it all. Also, we don't need to call the fbc/psr update
functions since the crtc enable/disable hooks do that already.
The only things we really need are:
- Pin the new framebuffer and potentially unpin the old fr
The pch encoder case really isn't anything generic on hsw:
- It's for the vga port only and
- the vga port does only exist on some hsw platforms.
Imo it helps the generic code flow a lot if we shovel all this into
hsw specific enable/disable hooks. A bonus is that some of our largest
files (intel_
The connector->get_hw_state function is actually platform dependent.
So move it out of the shared connector init functions. This allows us
to drop another intel_ddi.c export.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 10 +++---
drivers/gpu/drm/i915/intel_dp.c |
Again the same story: This code just transform sw state from the pipe
config into hardware state. And again we can't move the pll code, but
this time around because the state isn't properly tracked in the pipe
config.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 47 +++
All the hard work was already done, only thing left to do is remove
the empty callback. And a now rather misleading comment I've spotted
while reading through code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 14 --
1 file changed, 14 deletions(-)
diff --git
All these functions simply convert sw state as encoded in the pipe
config or primary framebuffer into hardware state. So we can move them
all into the crtc enable hook. Unfortunately this means a little bit
of duplication between the i9xx and vlv functions, but since we
already have highly refactor
Besides the fairly useless BUG_ON the logic is completely generic
and cane be used on any platform what wants to reuse the shared
dpll support code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/d
Our two ->crtc_mode_set callbacks really don't care whether the fb is
pinned and set up already or not - all the state computation and
handling which originally looked at the framebuffer is already using
the indirection through the pipe configuration.
Eventually we want to move this up a bit more,
With this all hw writes are also gone from the ->crtc_mode_set hook on
vlv. I wondered whether we should track more of the pll state in the
pipe config, but otoh as long as we don't have shared plls that's not
really useful - the cross-checking of the port clock should be
sufficient.
While at it a
Now this really should be in the pipe config somewhere, but till now
it isn't. We can at least move it up a bit next to all the other pll
code since intel_dp_set_m_n really doesn't depend upon this.
This is just prep work so that moving all the hw frobbing code from
->crtc_mode_set to ->crtc_enabl
Similar to dp the only thing we do is call intel_write_eld and prepare
a bit of state for the enable hooks. The only difference is that we
write that to the hardware instead of keeping track of it somewhere in
software.
Still we can just move all this to the very first enable hook.
Signed-off-by:
A bit more care required here since there are some very few things
between the call to encoder->mode_set and encoder->pre_enable. But
they're either book-keeping or only matter for the vga port on the
pch. So of no concern.
Note that with the new sequence we write the infoframes after
selecting th
Noticed while reading around.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
Well, the newly created intel_ddi_get_port_state.
In general intel_ddi.c has way too intimate knowledge with everyone
else as exemplified with all the encoder/connector noodling and the
massive exported function list.
As a first step explictly pass around the port, first in the encoder
callback.
Way back we've used this to reject framebuffers with unsupported
pixel formats. But since the modesetting reorg with the compute
config stage we reject those much earlier and just BUG() in this
callback. So switch to a void return type.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_
SPLL would be a reference clock we could potentially share,
especially if we want to use the SSC mode. But currently we
don't, so let's rip out this complexity for a simpler conversion
to the new display pll framework.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
dri
Looking at our current dsi driver I note that:
- We don't have any slave driver right now.
- There's zero support for the hardware state readout and cross check
code.
- All the modeset state seems to be tracked in the intel_dsi structure
instead of the pipe config.
Given all that I can't prope
Again this code just transforms sw state from the pipe config into
hardware state, so we can just move it around. Unfortunately again a
few forward declarations since intel_display.c is becoming a bit of a
mess.
Note that both for i9xx and ironlake code the only things remaining in
the ->crtc_mode
All the other checks also check hw state, so checking our software
refcounts for the plls looks a bit odd. Also this will simplify the
conversion over to the shared dpll framework, which itself has massive
amounts of checks to make sure that we never leave a display pll
enabled when we shouldn't.
This is the last piece of code which write state to the hardware in
the ironalake ->crtc_mode_set callback.
I think we could merge this with the pll->enable hook, but otoh the
ordering requirements with the ldvs port are really tricky. Doing the
FP0/1 writes up-front before we even prepare the lvd
Luckily the bit definitions match, but it's still confusing
to use one when handling the other. So sprinkle some OCD over
the #defines to make them match and use the right version in
each place.
Maybe we should unify these definitions completely, but that
can always be done sometime in the future.
The modeset sequence docs are very clear that we should disable the
pipe before we switch off any ports, for both pch ports and the cpu
edp port.
In practice it doesn't seem to matter too much since for non-DP pch
ports it only matters that the pch transcoder is still on. And for cpu
edp ports it
Just for consistency, this patch won't fix anything really.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b3bd25109ea3..2f46658d6d5
These two writes are the very last hw writes from the
->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit
different, so this here is just warm-up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 16 +++-
1 file changed, 11 insertions(+), 5 dele
My plan here is to split up set_base into a prepare step, which does
the pinning, and a commit stage, which updates the hw state. Eventually
we should be able to move the prepare step at the beginning of any
atomic update. For now I only want to move the commit step into the
crtc_enable callbacks.
Instead of every time it isn't active: We only need to do that when
the pll is currently unused, i.e. when pll->refcount == 0. For
paranoia add a warning for the ibx case where plls have a fixed
mapping and hence should always be unused after the call to
intel_put_shared_dpll.
Signed-off-by: Danie
Only ilk/snb/ivb need the port A pll setup, so move it to the
pre_enable hook for those platforms. We can savely do this since on
those platforms there's nothing that touches the hardware between the
encoder->mode_set and the encoder->pre_enable calls.
Also add a comment that port A is ilk+ only.
With all the preceding refactoring the dp mode_set callback only
computes a bit of state (all derived from the pipe config) and also
writes the eld. As long as we do that before we enable the audio bit
or depend upon the correct value in intel_dp->DP we'll be fine.
No other hw state is touched.
W
There's no need to check whether audio is enabled (which for ddi ports
is done through the crtc->eld_vld flag) since at the cost of a
potentially unecessary register rmw cycle we can unconditionally do
this.
Note that the edp check is just paranoia since we won't ever call the
write_eld function f
At least on those platforms which have a simple bit and don't rely
on the fully programmable CSC unit to do this.
Note that with the current code this includes CHV, but I guess that
platform will match BYT.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 9 +
dri
Those functions are only used on vlv platforms, so no need to check.
Especially if we're not too consistent about it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdmi.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i
We in the pre_enable hook we should only rely on the pipe config and
not on some other state set through properties or detect functions.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/
Including state readout and cross-checking. This allows us to get rid
of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy
if the BIOS hasn't set up the audio routing like we want it too.
Wrt fastboot and external screens I see a few options:
- Don't.
- Try to fix up eld, infofram
For compliance we really should be sending NULL infoframes always
when we detect a hdmi capable monitor. Also remove the now redudant
setting for the has_audio case and enforce that audio is only
possible with a hdmi sink.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdmi.c | 5 ++
All the callbacks are gone now.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 33 ++---
1 file changed, 2 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f8ebe9b5
For a bunch of reasons we want to move away from the ->mode_set
callbacks: All hw state setup needs to move into ->enable hooks (so
that DOMS can do runtime pm) and all the configuration setup needs to
move into the compute_config functions.
To start with this make the enocer->mode_set callback op
SDVO is used by both crtcs using the i9xx_ and the ironlake_
functions. For both cases there is nothing between the
encoder->mode_set and the encoder->pre_enable calls that touches the
hardware.
The vlv_ functions are different since they enable the pll before the
->pre_enable hook. But SDVO isn't
Currently for the i9xx crtc hooks there's nothing between the call to
encoder->mode_set and encoder->pre_enable which touches the hardware.
Therefore, since tv is only used on gen3/4, we can just move the hook.
Yay for easy cases!
The only other important thing to check is that the new
->pre_enab
intel_tv_mode_set is just too big.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 111 ++--
1 file changed, 61 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index bafe92e317d5
We only support TV-out on gen3/4 mobile platforms, and i915gm is the
only one that matches.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index
intel_tv_mode_set is still too bug.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 04bf8caaac0c..a6a
Also add state readout and cross-check support. The only invasive change
is wiring up the new flag to the ->set_infoframes callbacks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 9 +
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.
We only set a few bits in the ADPA register, which we then read back
in the enable/disable hooks. So we can just move that bit of state
computation code to the place where we need it since setting these
bits without enabling the CRT encoder has no effects.
The only exceptions are the hotplug bits
The pipe and plane _are_ disabled when we call this. So replace it
all with the corresponding assert (as self-documenting code) and
rip out all the lore.
Checking for a disabled plane would require us to export those macros
from intel_display.c, but if the pipe is off the plane isn't working
eithe
This way we can rely on the state cross-checker to have a bit
assurance that we'll get it right.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu
Currently for the i9xx crtc hooks there's nothing between the call to
encoder->mode_set and encoder->pre_enable which touches the hardware.
Therefore, since dvo is only used on gen2, we can just move the hook.
Yay for easy cases!
The only other important thing to check is that the new
->pre_enabl
Hi all,
So this is a little patch series that started very innocently as a small cleanup
in prep for some of the bigger features and then got out of hand. It now
implements runtime pm support for DPMS on everything that supports it.
Still rather lightly tested because of too many distractions thi
Signed-off-by: Daniel Vetter
---
lib/igt_kms.c | 28
lib/igt_kms.h | 1 +
tests/kms_flip.c| 36
tests/testdisplay.c | 36
4 files changed, 37 insertions(+), 64 deletions(-)
dif
Very basic since I lack a bit ideas. After all with the latest
patches runtime pm doesn't make much a difference between dpms off
and disabling the outputs completely with SetCrtc.
Signed-off-by: Daniel Vetter
---
tests/pm_pc8.c | 22 +-
1 file changed, 21 insertions(+), 1 de
On Thu, 2014-04-24 at 18:17 -0300, Rodrigo Vivi wrote:
> Honestly I don't like patches that adds regs definitions without
> actually using them.
I usually add them too in the patch using them first. In this case I
thought that since there are quite a lot of them, it's easier for the
reviewer since
On Wed, Feb 12, 2014 at 07:18:40PM +, Chris Wilson wrote:
> For stolen pages, since it is verboten to access them directly on many
> architectures, we have to read them through the GTT aperture. If they
> are not accessible through the aperture, then we have to abort.
>
> This was complicated
From: Paulo Zanoni
We still have way too many bugs with DP link training. We keep
switching between "narrow and fast" and "wide and slow", we recently
added 5GHz support, and whenever there's a bug report, we have to ask
people to apply patches and test them.
Wouldn't it be so much better if we
From: Paulo Zanoni
Extract this function to make the input and output parameters more
clear to the code reader.
I also have plans to allow ways to change the current parameters, so
the code will get even more complicated without the refactor. I also
have plans to add alternative implementations
From: Paulo Zanoni
Even if the panel claims it can support 4 lanes, there's the
possibility that the HW can't, so consider this while selecting the
max lane count.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 file changed, 18 insertions(+), 2 del
Honestly I don't like patches that adds regs definitions without
actually using them.
But also,
On Mon, Apr 14, 2014 at 2:24 PM, Imre Deak wrote:
> Needed by the VLV S0ix context save/restore helpers.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 43
> +
Although there are more work to be done I don't see any issue or
damage by putting it already to the correct place.
So, feel free to use: Reviewed-by: Rodrigo Vivi
On Wed, Apr 16, 2014 at 9:57 AM, Imre Deak wrote:
> On Wed, 2014-04-16 at 15:22 +0300, Ville Syrjälä wrote:
>> On Mon, Apr 14, 2014
Apparently Ville already Reviewed this one, but since I was checking
the doc and it was right feel free to also use: Reviewed-by: Rodrigo
Vivi
same for next 2 patches.
On Mon, Apr 14, 2014 at 2:24 PM, Imre Deak wrote:
> These will be needed by the upcoming VLV RPM helpers.
>
> Signed-off-by: Im
Makes sense for me, so
Reviewed-by: Rodrigo Vivi
On Tue, Apr 22, 2014 at 7:09 PM, Imre Deak wrote:
> Atm we can end up in the GPU reset deferred work in D3 state if the last
> runtime PM reference is dropped between detecting a hang/scheduling the
> work and executing the work. At least one such
On Thu, Apr 24, 2014 at 09:40:38PM +0200, Pavel Machek wrote:
> Hi!
>
> > And if you can indeed reliably reproduce this a bisect could be really
> > useful.
>
> And we have a winner here :-)
>
> Ok, it was not as painfull as I feared.
>
> It does not revert cleanly, but doing it by hand was no
Fix regression where only 20% of screen works in X. This is manual
revert of a51435a3137ad8ae75c288c39bd2d8b2696bae8f.
Signed-off-by: Pavel Machek
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6bc68bd..cf63c67 100644
--- a/drivers/gpu/drm
Hi!
> And if you can indeed reliably reproduce this a bisect could be really useful.
And we have a winner here :-)
Ok, it was not as painfull as I feared.
It does not revert cleanly, but doing it by hand was not that bad.
Best regards,
P
Hi!
> And if you can indeed reliably reproduce this a bisect could be
> really useful
It seems reliable, yes. So far I got:
Pavel
git bisect start
# good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14
git bisect good 455c6f
On Tue, 22 Apr 2014 20:19:41 +0300
Mika Kuoppala wrote:
> Hi,
>
> Here are patches to initialize first render context to a hopefully,
> valid state. If pipeline/context is not initialized and we enter rc6 on bdw,
> the render ring can hung on the first batch submitted. That is atleast
> the hyp
On Thu, Apr 24, 2014 at 02:22:39AM -0700, Chris Wilson wrote:
> On Fri, Mar 28, 2014 at 03:58:25PM -0700, Volkin, Bradley D wrote:
> > On Mon, Mar 17, 2014 at 05:21:55AM -0700, Chris Wilson wrote:
> > > @@ -1949,58 +1956,58 @@ static unsigned long
> > > __i915_gem_shrink(struct drm_i915_private *d
Reviewed-by: Brad Volkin
On Thu, Apr 24, 2014 at 10:07:32AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> This adds a small benchmark for the new userptr functionality.
>
> Apart from basic surface creation and destruction, also tested is the
> impact of having userptr surfaces in th
On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
From: Chris Wilson
Make sure that the whole BDB section is within the MMIO region prior to
accessing it contents. That we don't read outside of the secion is left
up to the individual section parsers.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo
On 4/19/2014 2:34 AM, Rodrigo Vivi wrote:
From: Chris Wilson
Be we read and chase pointers from the VBT, it is prudent to make sure
that those accesses are wholly contained within the MMIO region, or else
we may cause a kernel panic during boot.
Signed-off-by: Chris Wilson
Signed-off-by: Rodr
On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
> On 04/23/2014 10:58 PM, Chris Wilson wrote:
> > [ 4756.750938] Node 0 DMA free:14664kB min:32kB low:40kB high:48kB
> > active_anon:0kB inactive_anon:1024kB active_file:0kB inactive_file:4kB
> > unevictable:0kB isolated(anon):0kB isola
On 04/23/2014 10:58 PM, Chris Wilson wrote:
> [ 4756.750938] Node 0 DMA free:14664kB min:32kB low:40kB high:48kB
> active_anon:0kB inactive_anon:1024kB active_file:0kB inactive_file:4kB
> unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB
> managed:15908kB mlocked:0kB dirty:0k
On Thu, Apr 17, 2014 at 10:37:34AM +0800, Zhao Yakui wrote:
> This is the patch set that tries to add the support of dual BSD rings on BDW
> GT3. Based on hardware spec, the BDW GT3 has two independent BSD rings, which
> can be used to process the video commands. To be simpler, it is transparent
>
On Thu, Apr 17, 2014 at 10:37:37AM +0800, Zhao Yakui wrote:
> Based on the hardware spec, the BDW GT3 machine has two independent
> BSD ring that can be used to dispatch the video commands.
> So just initialize it.
>
> V3->V4: Follow Imre's comment to do some minor updates. For example:
> more com
On Thu, 24 Apr 2014, Pavel Machek wrote:
> > That says that i915.ko failed to initialise the GPU (or rather the GPU
> > wasn't responding) and bailed during module load. The key line here is
>
> > [drm:init_ring_common] *ERROR* render ring initialization failed ctl
> > 0001f001 head 2034 tai
On Thu, Apr 24, 2014 at 05:11:10PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 24, 2014 at 10:49:28AM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > This was suggested by Chris on his review to the first version of
> > "drm/i915: get power domain in case the BIOS enabled eDP VDD". Well,
1 - 100 of 139 matches
Mail list logo
