On Wed, Feb 13, 2013 at 01:40:56PM +0100, Daniel Vetter wrote:
> On Tue, Feb 05, 2013 at 01:07:01PM +1000, Dave Airlie wrote:
> > On Tue, Feb 5, 2013 at 12:55 AM, Daniel Vetter wrote:
> > > On Thu, Jan 31, 2013 at 07:43:38PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > >> From: Ville Syr
On Wed, Feb 13, 2013 at 10:24:59PM +, Reese, Armin C wrote:
> Thanks for the patch, Chris.
>
> This is exactly what we were looking for to replace the VMAP feature you
> submitted a couple of years ago. We need a method to quickly move data from
> user mode allocations into video memory (by
Thanks for the patch, Chris.
This is exactly what we were looking for to replace the VMAP feature you
submitted a couple of years ago. We need a method to quickly move data from
user mode allocations into video memory (by mapping backing pages into the GTT).
The Interface appears simple enough
On Wed, Feb 13, 2013 at 10:55:24PM +0200, Imre Deak wrote:
> Since afaics this problem relates only to _FBs_ in stolen memory the
> first one is:
>
> commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb
> Author: Chris Wilson
> Date: Thu Nov 15 11:32:27 2012 +
>
> drm/i915: Allocate fbcon f
On Wed, Feb 13, 2013 at 08:39:58PM +, Chris Wilson wrote:
> On Wed, Feb 13, 2013 at 09:56:05PM +0200, Imre Deak wrote:
> > As explained by Chris Wilson gem objects in stolen memory are always
> > coherent with the GPU so we don't need to ever flush the CPU caches for
> > these.
> >
> > This fi
On Wed, 2013-02-13 at 20:39 +, Chris Wilson wrote:
> On Wed, Feb 13, 2013 at 09:56:05PM +0200, Imre Deak wrote:
> > As explained by Chris Wilson gem objects in stolen memory are always
> > coherent with the GPU so we don't need to ever flush the CPU caches for
> > these.
> >
> > This fixes a b
On Wed, Feb 13, 2013 at 09:56:05PM +0200, Imre Deak wrote:
> As explained by Chris Wilson gem objects in stolen memory are always
> coherent with the GPU so we don't need to ever flush the CPU caches for
> these.
>
> This fixes a breakage - at least with the compact sg patches applied -
> during t
As explained by Chris Wilson gem objects in stolen memory are always
coherent with the GPU so we don't need to ever flush the CPU caches for
these.
This fixes a breakage - at least with the compact sg patches applied -
during the resume/restore gtt mappings path, when we tried to clflush an
FB obj
On Tue, Nov 06, 2012 at 04:25:38PM +, Ben Widawsky wrote:
> v2: Use the correct lock to protect PM interrupt regs, this was
> accidentally lost from earlier (Haihao)
> Fix return types (Ben)
>
> CC: Xiang, Haihao
> Signed-off-by: Ben Widawsky
[snip]
> ---
> diff --git a/drivers/gpu/drm/i91
On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse wrote:
> On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
>> We already have the quirk entry for the mobile platform, but also
>> reports on some desktop versions. So be paranoid and set it
>> everywhere.
>>
>> References:
>> http://www.mail
If we start disabling the encoders, there is a potential for a pending
flip to never occur - and so we will end up waiting indefinitely.
v2: Also pre-emptively perform the drm_vblank_off() before switching off
the encoders.
References:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video
If we start disabling the encoders, there is a potential for a pending
flip to never occur - and so we will end up waiting indefinitely.
References:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1097315
Cc: Timo Aaltonen
Cc: Daniel Vetter
Signed-off-by: Chris Wilson
-
On Wed, Feb 13, 2013 at 06:11:00PM +0100, Daniel Vetter wrote:
> I'm confused here - where can we extract parallelism in set_base
> between waiting for pending flips and the pinning? And imo set_base
> isn't really critical: It's officially a synchronous thing (we have a
> vblank wait in there), an
On Wed, Feb 13, 2013 at 04:29:00PM +, Damien Lespiau wrote:
> In order to have the tests finish in a reasonable time in certain
> environments,
> it'd be nice to have a "quick" mode that uses low loop and buffer counts.
>
> Of course, more tests would be converted in the long run.
I like thi
On Wed, Feb 13, 2013 at 6:26 PM, Ville Syrjälä
wrote:
> The flip is making progress on the GPU side, and at the same time the
> CPU side can make some progress with the pin operation. At least that
> was my theory.
The pin should be a no-op when moving a given framebuffer around. It's
only really
On Wed, Feb 13, 2013 at 06:11:00PM +0100, Daniel Vetter wrote:
> On Wed, Feb 13, 2013 at 6:06 PM, Ville Syrjälä
> wrote:
> >> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> > b/drivers/gpu/drm/i915/intel_display.c
> >> > index a2e04f7..7e047c1 100644
> >> > --- a/drivers/gpu/drm/i915/in
On Wed, Feb 13, 2013 at 6:06 PM, Ville Syrjälä
wrote:
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index a2e04f7..7e047c1 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -2330
On Wed, Feb 13, 2013 at 06:52:29PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 13, 2013 at 04:23:27PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 29, 2013 at 06:13:34PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > If a GPU reset occurs while a page flip has
On Wed, Feb 13, 2013 at 04:49:35PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 06:13:38PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Since obj->pending_flips was never set, intel_pipe_set_base() never
> > actually waited for pending page flips to complet
On Wed, Feb 13, 2013 at 04:23:27PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 06:13:34PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > If a GPU reset occurs while a page flip has been submitted to the ring,
> > the flip will never complete once the ring ha
Signed-off-by: Damien Lespiau
---
tests/gem_storedw_batches_loop.c |2 +-
tests/gem_storedw_loop_blt.c |2 +-
tests/gem_storedw_loop_bsd.c |2 +-
tests/gem_storedw_loop_render.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/gem_storedw_batche
In some environments, we don't really want to loop 10 times or
allocate 152352621 buffers because it makes the tests too long to run.
This adds a way to specify "quick" values to reduce the time taken by
certain tests.
Signed-off-by: Damien Lespiau
---
lib/drmtest.c | 22 +
In order to have the tests finish in a reasonable time in certain environments,
it'd be nice to have a "quick" mode that uses low loop and buffer counts.
Of course, more tests would be converted in the long run.
--
Damien
___
Intel-gfx mailing list
In
On Wed, Feb 13, 2013 at 10:16:27AM +, Damien Lespiau wrote:
> On Tue, Jan 29, 2013 at 06:13:33PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The pending flip mask no longer set anywhere, so trying to wait for
> > while it's non-zero is a no-op. Remove it comple
On Wed, Feb 13, 2013 at 3:03 PM, Chris Wilson wrote:
> On Wed, Feb 13, 2013 at 12:32:03PM +0100, Daniel Vetter wrote:
>> Hi all
>>
>> So this is my old attempt to push our modeset infrastructure a bit further,
>> rebased on top of latest dinq. Originally I wanted to push this a bit further
>> stil
On Tue, Jan 29, 2013 at 06:13:38PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Since obj->pending_flips was never set, intel_pipe_set_base() never
> actually waited for pending page flips to complete.
>
> We really do want to wait for the pending flips, because otherwis
On Tue, Jan 29, 2013 at 06:13:35PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Someone may be waiting for a flip that will never complete due to a GPU
> reset. Wake up all such waiters when the hang is first detected, and
> after the reset processing has finished.
>
> S
On Tue, Jan 29, 2013 at 06:13:34PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If a GPU reset occurs while a page flip has been submitted to the ring,
> the flip will never complete once the ring has been reset.
>
> The GPU reset can be detected by sampling the reset_co
On Wed, Feb 13, 2013 at 01:29:23PM +, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_d
On Wed, Feb 13, 2013 at 12:32:03PM +0100, Daniel Vetter wrote:
> Hi all
>
> So this is my old attempt to push our modeset infrastructure a bit further,
> rebased on top of latest dinq. Originally I wanted to push this a bit further
> still before submitting for rfc, but with fastboot picking up I
Signed-off-by: Damien Lespiau
---
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/drivers/gpu/drm/i915/intel_display.c
index 7635947..e7fc6e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
++
On Tue, Feb 05, 2013 at 01:07:01PM +1000, Dave Airlie wrote:
> On Tue, Feb 5, 2013 at 12:55 AM, Daniel Vetter wrote:
> > On Thu, Jan 31, 2013 at 07:43:38PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> >> From: Ville Syrjälä
> >>
> >> Support for real RGB332 is a rarity, most hardware only r
On Wed, Feb 13, 2013 at 12:51:33PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 13, 2013 at 10:23:28AM +, Damien Lespiau wrote:
> > On Tue, Jan 29, 2013 at 06:13:34PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > If a GPU reset occurs while a page flip ha
Up to now we've relied on the bios to get this right for us. Let's try
out whether our code has improved a bit, since we should dither
always when the output bpp doesn't match the plane bpp.
- gen5+ should be fine, since we only use the bios hint as an upgrade.
- gen4 changes, since here dithering
Now that we have a useful struct for this, let's use it. Some neat
pointer-chasing required, but it's all there already.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 8 ++--
d
With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 97 +---
drivers/
Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.
So the best place to do this is somewhere in the encoders, with a
generic fallback for those encoders without special needs. To f
So ditch that if clause from the i8xx pll update code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cf72df5..4a6fb9
Now we can ditch the checks in the Haswell disable code.
v2: add support for Haswell
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
We need to be able to read out the hw state code for a bunch
of reasons:
- Correctly disabling boot-up/resume state.
- Pure paranoia.
Since not all of the pipe configuration is e.g. relevant for
fastboot (or at least we can allow some wiggle room in some
parameters, like the clocks), we need to ad
The only exception left is is_cpu_edp in the haswell modeset code.
We need that to assign the cpu transcoder, but we might want to
move that eventually into the encoder, too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 37 +++-
1 file c
We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
v2: Add a massive comment in the code to explain this mess.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_dp.c
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_
- gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
the possibility to dither to 6bpc using the panel fitter
- g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
- TV/SDVO out are the only connectors available on platforms with
a pipe bpp != 8, add code to force th
- There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
float layout, but we don't really support it.
- 10bpc is a gen4+ feature, fix up the support for it.
- Update_plane should never see a wrong fb bpp value, BUG in the
corresponding cases.
v2: Rebase on top of Ville's plane pi
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the enco
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cp
This is used way too often in the enable/disable paths. And will
be even more useful in the future.
Note that correct semantics of this change highly depend upon
correct updating of intel_crtc->config: Like with all other
modeset state, we need to call ->disable with the old config,
but ->mode_set
Used by SDVO (and hopefully, eventually HDMI, if we ever get around
to fixing up the low dotclock CEA modes ...).
This required adding a new encoder->mode_set callback to be able to
pass around the intel_crtc_config.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 80 +++
Only used by the lvds encoder. Note that we shouldn't do the same
simple conversion with the FORCE_6BPC flag, since that's much better
handling by moving all the pipe_bcp computation around.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
drivers/gpu/drm/
To make decent modeset state checking possible (e.g. for the check
mode with atomic modesetting) we want to have the full pipe
configuration and state checks done before we touch the hw.
To ensure that all the little bits&pieces that are now moved to the
pipe_config handle this correctly, move its
Currently only containing the requested and the adjusted mode. And
only crtc callbacks are converted somewhat to it, encoders will be
done on a as-needed basis (simply too much churn in one patch
otherwise).
Future patches will add tons more useful stuff to this struct,
starting with the very simp
Hi all
So this is my old attempt to push our modeset infrastructure a bit further,
rebased on top of latest dinq. Originally I wanted to push this a bit further
still before submitting for rfc, but with fastboot picking up I think it's
better to throw it out there now.
Roughly this adds a new int
On Wed, Feb 13, 2013 at 10:23:28AM +, Damien Lespiau wrote:
> On Tue, Jan 29, 2013 at 06:13:34PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > If a GPU reset occurs while a page flip has been submitted to the ring,
> > the flip will never complete once the ring h
Am Mittwoch, den 13.02.2013, 09:31 + schrieb Chris Wilson:
> Whilst IOMMU is enabled for the Intel GPU on Ironlake, it appears that
> using WC writes to update the PTE on the GPU fail miserably. The result
Either remove using or add an s to fail. ;-)
> looks like the majority of the writes do
On Tue, Jan 29, 2013 at 06:13:38PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Since obj->pending_flips was never set, intel_pipe_set_base() never
> actually waited for pending page flips to complete.
>
> We really do want to wait for the pending flips, because otherwis
On Tue, Jan 29, 2013 at 06:13:37PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Move the functionality of intel_crtc_wait_for_pending_flips()
> into intel_crtc_wait_for_pending_flips_locked().
>
> intel_crtc_wait_for_pending_flips() is now just a wrapper that
> grab stru
On Tue, Jan 29, 2013 at 06:13:36PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Just shuffle the code around. No functional changes.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
Mastering the art of small orthognal commits :)
--
Damien
_
On Tue, Jan 29, 2013 at 06:13:35PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Someone may be waiting for a flip that will never complete due to a GPU
> reset. Wake up all such waiters when the hang is first detected, and
> after the reset processing has finished.
>
> S
On Tue, Jan 29, 2013 at 06:13:34PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If a GPU reset occurs while a page flip has been submitted to the ring,
> the flip will never complete once the ring has been reset.
>
> The GPU reset can be detected by sampling the reset_co
On Tue, Jan 29, 2013 at 06:13:33PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The pending flip mask no longer set anywhere, so trying to wait for
> while it's non-zero is a no-op. Remove it completely.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
--
On Wed, Feb 13, 2013 at 09:25:58AM +, Chris Wilson wrote:
> Whilst IOMMU is enabled for the Intel GPU on Ironlake, it appears that
> using WC writes to update the PTE on the GPU fail miserably. The result
> looks like the majority of the writes do not land leading to lots of
> screen corruption
Whilst IOMMU is enabled for the Intel GPU on Ironlake, it appears that
using WC writes to update the PTE on the GPU fail miserably. The result
looks like the majority of the writes do not land leading to lots of
screen corruption and a hard system hang.
v2: s/
Bugzilla: https://bugzilla.freedeskto
Whilst IOMMU is enabled for the Intel GPU on Ironlake, it appears that
using WC writes to update the PTE on the GPU fail miserably. The result
looks like the majority of the writes do not land leading to lots of
screen corruption and a hard system hang.
Reported-by: Nathan Myers
Bugzilla: https:/
64 matches
Mail list logo
