ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> As per Chris Wilson's suggestion make
> i915_gem_execbuffer_wait_for_flips() go away.
>
> This was used to stall the GPU ring while there are pending
> page flips involving the relevant BO. Ie. while the BO is still
> being scanned o
On Wed, Oct 31, 2012 at 01:27:48PM -0700, Jesse Barnes wrote:
> On Wed, 31 Oct 2012 17:50:24 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Refactor the code that stores the panning x/y position into the sarea.
> >
> > This also changes the code so that it won't
On Wed, Oct 31, 2012 at 01:23:05PM -0700, Jesse Barnes wrote:
> On Wed, 31 Oct 2012 17:50:15 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
Fails to apply here somehow. Also, this thing is base64 encoded, which
confused my normal wor
On Wed, 31 Oct 2012 19:26:13 +0100, Daniel Vetter
wrote:
> Makes more sense to group the entire mode_set stage into one function.
> Noticed while discussiing the rather confusing set of function names
> with Paulo Zanoni. Unfortunately I don't have an idea to make the
> function names lesss confu
On Thu, Nov 01, 2012 at 12:03:39AM +0200, Imre Deak wrote:
> drm_vblank_off() requires callers to hold the event_lock.
>
> Signed-off-by: Imre Deak
Hm, do we put this code through its paces already in flip_test by
scheduling a vblank wait in the future (a second or so), and then
disabling the di
This allows the power related code to run independently of the rest of
the pipeline, extending the resume and init time improvements into
userspace, which would otherwise have been blocked on the struct mutex
if we were doing PCU communication.
Suggested-by: Daniel Vetter
Signed-off-by: Jesse Bar
The console lock can be contended, so rather than prevent other drivers
after us from being held up, queue the console suspend into the global
work queue that can happen anytime. I've measured this to take around
200ms on my T420. Combined with the ring freq/turbo change, we should
save almost 1/
The BIOS shouldn't be touching this memory across suspend/resume, so
just leave it alone. This saves us ~6ms on resume on my T420 (retested
with write combined PTEs).
v2: change gtt restore default on pre-gen4 (Chris)
move needs_gtt_restore flag into dev_priv
v3: make sure we restore GTT on r
Communicating via the mailbox registers with the PCU can take quite
awhile. And updating the ring frequency or enabling turbo is not
something that needs to happen synchronously, so take it out of our init
and resume paths to speed things up (~200ms on my T420).
v2: add comment about why we use a
drm_vblank_off() requires callers to hold the event_lock.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b453901..56f1119 1
drm_vblank_off() requires callers to hold the event_lock, while itself
locking vbl_time and vblank_time_lock. This defines a dependency chain
that conflicts with the one in drm_handle_vblank() where we first lock
vblank_time_lock and then the event_lock. Fix this by reversing the
locking order in d
Now that we no longer pretend to have flexibility in matching any
north display block with any pch, we can ditch this.
v2: Fix the embarassing rebase fail that Paulo Zanoni spotted.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 78 +++
Found in Bspec vol4h South Display Engine Registers [CPT, PPT],
section "5.3.1 TRANS_CHICKEN_1—Transcoder Chicken Bits 1"
v2: Make it compile.
Reviewed-by: Paulo Zanoni (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 6 ++
We need to set the timing override chicken bit after fdi link training
has completed and before we enable the transcoder. We also have to
clear that bit again after disabling the pch transcoder.
See "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" and "Graphi
They are all written for a specific north disaplay->pch combination.
So stop pretending otherwise.
Reviewed-by: Paulo Zanoni
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i
We don't really support fancy north display/pch combinations, so
put a big yelling WARN_ON in there. It /should/ be impossible, but
alas, the rumours don't stop (mostly due to really early silicon
sometimes using older PCHs).
v2: Fixup the logic fumble noticed by Paulo Zanoni. I should actually
tr
Hi all,
So the next try at my ivb fdi b/c fixes, hopefully with all the stupid mistakes
from the previous version fixed up. Note that I still have fdi link training
fail sometimes, but at least it's no longer silent.
Compared to Bspec we do a few things wrong, so there's more work to do still.
C
On Tue, 30 Oct 2012 18:17:58 +0100
Daniel Vetter wrote:
> On Fri, Oct 26, 2012 at 7:08 PM, Jesse Barnes
> wrote:
> > Communicating via the mailbox registers with the PCU can take quite
> > awhile. And updating the ring frequency or enabling turbo is not
> > something that needs to happen synch
On Wed, 31 Oct 2012 17:50:24 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Refactor the code that stores the panning x/y position into the sarea.
>
> This also changes the code so that it won't mistakenly update
> sareaB_x/y for pipe >= C.
>
> Signed-off-by: Ville Syrjäl
On Wed, 31 Oct 2012 17:50:21 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The framebuffer pixel format is already checked by the common code.
> So there's no way an invalid format could reach the driver. So instead
> of falling back to a default format, call BUG().
>
> S
On Wed, 31 Oct 2012 17:50:20 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 19 +++
> 1 files changed, 3 in
On Wed, 31 Oct 2012 17:50:19 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The current code can't deal with framebuffers with an offset. Return an
> error when trying to create such a framebuffer until the rest of the
> code is fixed to handle them.
>
> Signed-off-by: Vil
On Wed, 31 Oct 2012 17:50:18 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make sure the the framebuffer stride is smaller than 32k. That
> seems to be the limit on recent hardware. Not quite sure if
> <=Gen4 has smaller limits.
>
> Also when using a tiled memory make sur
On Wed, 31 Oct 2012 17:50:15 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/
On Wed, 31 Oct 2012 17:50:14 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float
> format).
>
> Fix intel_init_framebuffer() to match hardware and driver limitations:
> * RGB332 is not supported at all
> *
From: Paulo Zanoni
On Haswell/LPT we must disable the PCH transcoder before we disable
the FDI, so don't check for disabled FDI there.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/d
From: Paulo Zanoni
This is a full revert of 59c859d6f2e78344945e8a8406a194156176bc4e:
drm/i915: account for only one PCH receiver on Haswell
Now that the PCH code is fixed to be able use the only PCH transcoder
independently of the pipe and CPU transcoder, we can revert this.
Signed-off-by:
From: Paulo Zanoni
This function is only for the previous gens.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a01901a..0119b3b 100644
---
From: Paulo Zanoni
These workarounds are documented on the CRT mode set sequence.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
in
From: Paulo Zanoni
... instead of "pipe", which is wrong.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
in
From: Paulo Zanoni
That function is made for IBX. Running it on LPT will trigger tons of
"unclaimed register" errors. The only port remaining on LPT is
PCH_ADPA.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/g
From: Paulo Zanoni
Because we already set all the bits we can set.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f
From: Paulo Zanoni
... instead of PIPECONF_INTERLACE_MASK.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 066994f..4fbb
From: Paulo Zanoni
... instead of using "pipe". As already explained in previous commits,
since Haswell/LPT cpu_transcoder, pch_transcoder and pipe are not the
same thing.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 24 +---
1 file changed, 9 inse
From: Paulo Zanoni
These asserts are specific to IBX/CPT/PPT. Inside the assert_pch_pll
function we even "return" in case we detect LPT, but I prefer to just
not call it. In the future we might rename to something like
ibx_assert_pch_pll.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/in
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 763e909..7e8f4ed 100644
--- a/drivers/gp
From: Paulo Zanoni
Since now we have lpt_enable_pch_transcoder.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 066eb27..763e909 100644
From: Paulo Zanoni
For now the new functions are just copies. Differences will be added
later.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 77 +++-
1 file changed, 75 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
From: Paulo Zanoni
To ironlake_{en,dis}able_pch_transcoder since these functions will be
different on Haswell/LPT and since the "transcoder" they {en,dis}able
is on the PCH.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 16
1 file changed, 8 insertions
From: Paulo Zanoni
On Haswell/LPT, pipe, cpu_transcoder and pch_transcoder are different
things with different values, unlinke the previous gens. So here we
use the right thing at the right place.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1
From: Paulo Zanoni
There is no LVDS, so don't poke the LVDS registers.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8
From: Paulo Zanoni
This is just wrong. The lpt_program_iclkip should disable the PCH
pixel clocks (and yes, we plan to rename it later).
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_d
From: Paulo Zanoni
Because this function is only for the older PCHs, not the newer ones.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
From: Paulo Zanoni
This is done way earlier on HSW/LPT and is just wrong here.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ee81932
From: Paulo Zanoni
This covers the "Disable FDI" section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 26 ++
drivers/gpu/drm/i915/intel_display.c | 3 +--
dri
From: Paulo Zanoni
>From the mode set sequence document: "Each setting should be tried at
least twice before failing mode set".
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dd
From: Paulo Zanoni
We shouldn't call DRM_ERROR when still looping through voltage levels
since this is expected and not really a failure. So in this commit we
adjust the error path to only DRM_ERROR when we really fail after
trying everything.
While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG
From: Paulo Zanoni
... on hsw_fdi_link_train. Check the mode set sequence documentation.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
inde
From: Paulo Zanoni
We already "break" when the link training succeeds.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/inte
From: Paulo Zanoni
First we wait 30us for the FDI receiver lane calibration, then we wait
5us for the FDI auto training time.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dd
From: Paulo Zanoni
That's what our mode set sequence documentation says we need to do.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index
From: Paulo Zanoni
According to the mode set sequence documentation, this is the right
place. According to the FDI_RX_TUSIZE register description, this is
the value we should set.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 3 +++
1 file changed, 3 insertions(+)
diff --
From: Paulo Zanoni
... inside hsw_fdi_link_train. Just set the bits we want, everything
else is zero.
While at it, also POSTING_READ the register before waiting.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c397da3..e903502 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++
From: Paulo Zanoni
There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using
"pipe" here is wrong.
While at it, also reuse the rx_ctl_val variable created in the
previous commit.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 24
1 file
From: Paulo Zanoni
Haswell FDI link training is very different from the previous
generations.
After this commit, hsw_fdi_link_train is responsible for implementing
all the steps described as "Enable and train FDI" from the Haswell
CRT mode set sequence documentation.
We need to train the FDI be
From: Paulo Zanoni
Since this function will only run on Haswell/LPT and newer.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 69 +---
1 file changed, 1 insertion(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/d
From: Paulo Zanoni
Since now we have lpt_pch_enable for them.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 73d6
From: Paulo Zanoni
For now it's just a fork of ironlake_pch_enable. The next commits will
change this.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 111 ++-
1 file changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
From: Paulo Zanoni
Because things changed on Haswell/LPT and the bits checked by
intel_crt_get_hw_state have moved to other registers.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_crt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i
From: Paulo Zanoni
Those bits just don't exist on LPT. The CRT DAC, PCH transcoder and
FDI RX are always connected to DDI E.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_crt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c
From: Paulo Zanoni
Hi
As you may have noticed this is not "Haswell VGA enablement", but "Haswell VGA
fixes" since VGA is already enabled on Haswell. Even though it's enabled,
whenever I try to "xrandr --output VGA1 --auto" my machine hard hangs.
So what does this series fixes?
- It makes our
On 10/27/12 9:52 AM, Daniel Vetter wrote:
This essentially reverts
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
simply because it doesn't scale: It misses SDVO an
On 10/27/12 9:52 AM, Daniel Vetter wrote:
Userspace seems to like this, see
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
This makes them sort to the front in
On Wed, 31 Oct 2012 10:47:03 -0700
Eric Anholt wrote:
> Jesse Barnes writes:
>
> > Signed-off-by: Jesse Barnes
>
> So, these days if you go to render to a buffer that's been flipped from,
> your rendering gets stalled (since the buffer may still be scanned out
> when the rendering starts happ
From: Damien Lespiau
ILK+ have this register on the PCH. This check was triggering unclaimed
writes.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_bios.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i9
On Wed, Oct 31, 2012 at 07:38:40PM +0200, ville.syrj...@linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index cbc0035..83e16f8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@
On Wed, Oct 31, 2012 at 10:44:47AM -0700, Eric Anholt wrote:
> Ville Syrjälä writes:
>
> > On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote:
> >> The hw supports async flips through the render ring, so why not expose it?
> >> It gives us one more "tear me harder" option we can use in
Makes more sense to group the entire mode_set stage into one function.
Noticed while discussiing the rather confusing set of function names
with Paulo Zanoni. Unfortunately I don't have an idea to make the
function names lesss confusion.
v2: Use for_each_encoder_on_crtc as suggested by Chris Wilso
On Wed, Oct 31, 2012 at 07:04:29PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 31, 2012 at 05:28:40PM +0100, Daniel Vetter wrote:
> > On Wed, Oct 31, 2012 at 05:50:17PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Split the i9xx clock stuff out from i9xx_co
On Wed, Oct 31, 2012 at 05:43:16PM +, Chris Wilson wrote:
> On Wed, 31 Oct 2012 19:38:41 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > intel_pipe_set_base() never actually waited for any pending page flips
> > on the CRTC. It looks like it tried to, by calling in
Hi
2012/10/29 Daniel Vetter :
> Now that we no longer pretend to have flexibility in matching any
> north display block with any pch, we can ditch this.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_pm.c | 71
> +++-
Jesse Barnes writes:
> Signed-off-by: Jesse Barnes
So, these days if you go to render to a buffer that's been flipped from,
your rendering gets stalled (since the buffer may still be scanned out
when the rendering starts happening), which is the thing we need to
avoid. I don't see this patch s
Hi
2012/10/29 Daniel Vetter :
> Found in Bspec vol4h South Display Engine Registers [CPT, PPT],
> section "5.3.1 TRANS_CHICKEN_1—Transcoder Chicken Bits 1"
>
> Signed-off-by: Daniel Vetter
Magic!
I wonder if we shouldn't read->change->write instead of just write,
zeroing every other bit. This
Frederic Plourde writes:
> From: Tomeu Vizoso
>
> When i915 driver decides to fallback to software, the texture's Map
> gets replaced by its Buffer attribute, which is NULL because the
> texture hasn't been allocated by swrast yet.
>
> The attached patch makes sure that the image buffer for the
Ville Syrjälä writes:
> On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote:
>> The hw supports async flips through the render ring, so why not expose it?
>> It gives us one more "tear me harder" option we can use in the DDX and
>> for other cases where simply flipping to the latest buff
On Wed, 31 Oct 2012 19:38:41 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_pipe_set_base() never actually waited for any pending page flips
> on the CRTC. It looks like it tried to, by calling intel_finish_fb() on
> the current front buffer. But the pending flips w
Hi
2012/10/29 Daniel Vetter :
> On Mon, Oct 29, 2012 at 6:02 PM, Paulo Zanoni wrote:
>> The description of the chicken bit used in the workaround even says that:
>> "Workaround: Enable the override prior to enabling the transcoder.
>> Disable the override after disabling the transcoder".
>>
>> Th
From: Ville Syrjälä
As per Chris Wilson's suggestion make
i915_gem_execbuffer_wait_for_flips() go away.
This was used to stall the GPU ring while there are pending
page flips involving the relevant BO. Ie. while the BO is still
being scanned out by the display controller.
The recommended altern
From: Ville Syrjälä
intel_pipe_set_base() never actually waited for any pending page flips
on the CRTC. It looks like it tried to, by calling intel_finish_fb() on
the current front buffer. But the pending flips were actually tracked
in the BO of the previous front buffer, so the call to intel_fin
This is my quick attempt at aliminating i915_gem_execbuffer_wait_for_flips().
While doing that I noticed that intel_pipe_set_base() never actually waited
for pending flips, while it probably should.
I also spotted another possible problem, for which I didn't provide a patch.
We wait on the pendin
Hi
2012/10/29 Daniel Vetter :
> We don't really support fancy north display/pch combinations, so
> put a big yelling WARN_ON in there. It /should/ be impossible, but
> alas, the rumours don't stop (mostly due to really early silicon
> sometimes using older PCHs).
>
> Signed-off-by: Daniel Vetter
On Mon, Oct 29, 2012 at 03:14:51PM +, Damien Lespiau wrote:
> From: Damien Lespiau
>
> v2: Use a switch for consistency (Chris Wilson)
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_sprite.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> dif
Hi
2012/10/29 Daniel Vetter :
> They are all written for a specific north disaplay->pch combination.
> So stop pretending otherwise.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_display.c | 14 +-
> 1 file changed, 5 insertions(+),
On Wed, Oct 31, 2012 at 05:28:40PM +0100, Daniel Vetter wrote:
> On Wed, Oct 31, 2012 at 05:50:17PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Split the i9xx clock stuff out from i9xx_compute_clocks().
> >
> > Only compile tested!
> >
> > Signed-off-by: Ville Sy
On Wed, Oct 31, 2012 at 05:50:17PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Split the i9xx clock stuff out from i9xx_compute_clocks().
>
> Only compile tested!
>
> Signed-off-by: Ville Syrjälä
I'm working on a massive overhaul of the clock computation madness, so
On Wed, 31 Oct 2012 15:49:36 +
Chris Wilson wrote:
> On Wed, 31 Oct 2012 08:39:09 -0700, Jesse Barnes
> wrote:
> > On Wed, 31 Oct 2012 16:26:54 +0100
> > Daniel Vetter wrote:
> >
> > > On Wed, Oct 31, 2012 at 4:23 PM, Jesse Barnes
> > > wrote:
> > > >
> > > >> On Tue, Oct 30, 2012 at 01
On Wed, Oct 31, 2012 at 04:26:54PM +0100, Daniel Vetter wrote:
> On Wed, Oct 31, 2012 at 4:23 PM, Jesse Barnes
> wrote:
> >
> >> On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote:
> >> > The hw supports async flips through the render ring, so why not expose
> >> > it?
> >> > It gives
On Wed, Oct 31, 2012 at 4:49 PM, Chris Wilson wrote:
> Because it involves the driver stalling.
And the coherent case of get_seqno is expensive. And depending upon
workload we'll get quite some interrupts, since we can't filter for
just the single batchbuffer completion we want at the hw level.
-
On Wed, 31 Oct 2012 17:50:16 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add the MI_WAIT_FOR_EVENT bits for sprites, and fix up the whole thing
> for IVB which moved most of the bits around.
>
Please just kill this code. Everyone will be happier and there will be
rejo
On Wed, 31 Oct 2012 10:57:08 +0100
Daniel Vetter wrote:
> On Sun, Oct 28, 2012 at 07:08:56PM -0700, Ben Widawsky wrote:
> > As a quick hack we make the old intel_gtt structure mutable so we
> > can fool a bunch of the existing code which depends on elements in
> > that data structure. We can/shou
From: Ville Syrjälä
Refactor the code that stores the panning x/y position into the sarea.
This also changes the code so that it won't mistakenly update
sareaB_x/y for pipe >= C.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 43 ++
1
From: Ville Syrjälä
intel_modeset_adjusted_mode() doesn't modify the passed display mode. So
pass it as const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b
From: Ville Syrjälä
i9xx_adjust_sdvo_tv_clock(), i9xx_compute_clocks() and
ironlake_compute_clocks() do not modify the adjusted_mode passed in, so
pass it as const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c |6 +++---
1 files changed, 3 insertions(+), 3 deletion
From: Ville Syrjälä
The framebuffer pixel format is already checked by the common code.
So there's no way an invalid format could reach the driver. So instead
of falling back to a default format, call BUG().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c |8 ++--
From: Ville Syrjälä
Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 19 +++
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers
From: Ville Syrjälä
The current code can't deal with framebuffers with an offset. Return an
error when trying to create such a framebuffer until the rest of the
code is fixed to handle them.
Signed-off-by: Ville Syrjälä
---
I had an earlier version that actually added the handling for the offs
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index da8400a..2555986 100644
--- a/drivers/gpu/drm/i915/i915_reg
Here's a bunch of changes that were sitting in my drm_atomic tree, but
not really related to that work.
I quickly modified the fb offset handling patch to avoid having to
write test cases :), and the stride patch to avoid open questions
about <=Gen4 stride limits.
The execbuffer patch is an open
From: Ville Syrjälä
Make sure the the framebuffer stride is smaller than 32k. That
seems to be the limit on recent hardware. Not quite sure if
<=Gen4 has smaller limits.
Also when using a tiled memory make sure the object stride matches
the framebuffer stride.
Signed-off-by: Ville Syrjälä
---
1 - 100 of 116 matches
Mail list logo
