Hi Ville,
On Wed, Nov 04, 2015 at 11:19:49PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> i915 register defines are going to become type safe, so going forward
> the register defines can't be used as straight numbers. Since quirks.c
> needs just a few extra register defi
Hi all,
I am trying to enable XenGT for Android on board vtc1010 in PV mode.
Used:
- Intel® Atom™ processor E3827
- Xen 4.3.1 on branch "byt_experiment".
- dom0: ubuntu 14-04 with linux vgt 3.11.6-vgt+ kernel version
- domU: Android-IA 5.1 with 3.11.6-vgt+ (added Android configs) kernel
version
On Tue, Nov 24, 2015 at 09:21:56PM +0200, Jani Nikula wrote:
> We have serious dangling else bugs waiting to happen in our for_each_
> style macros with ifs. Consider, for example,
>
> #define for_each_power_domain(domain, mask) \
> for ((domain) = 0; (domain) < P
The script uses the obsoleted and removed intel_reg_read tool. Rather
than mechanically fix this to use intel_reg, observe that the hardcoded
register offsets are platform specific. A quick glance suggests they are
for PCH split platforms with FDI, and as such useful only on a minority
of platforms
On Tue, Nov 24, 2015 at 11:01:25PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:06:21PM +0100, Daniel Vetter wrote:
> > Just setting obj->dirty only works if you also have the pages.
>
> Exactly. The CPU access has historically always been page-by-page. The
> style here more or less to
On Tue, Nov 24, 2015 at 08:53:43PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-11-24 at 17:12 +, Daniel Stone wrote:
> > Hi Rodrigo,
> >
> > On 11 November 2015 at 21:19, Rodrigo Vivi
> > wrote:
> > > Proceeding with the big series split here goes the general PSR
> > > improvements and stabil
intel_reg_dumper is gone, replaced by 'intel_reg dump'.
Signed-off-by: Jani Nikula
---
tools/intel_gpu_abrt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt
index a38137d795f4..bde6fb0d2493 100755
--- a/tools/intel_gpu_abrt
+++ b/too
On Tue, Nov 24, 2015 at 02:34:46PM -0800, Yu Dai wrote:
>
>
> On 11/24/2015 11:13 AM, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 10:36:54AM -0800, Yu Dai wrote:
> >>
> >>
> >> On 11/24/2015 10:08 AM, Daniel Vetter wrote:
> >> >On Tue, Nov 24, 2015 at 07:05:47PM +0200, Imre Deak wrote:
> >> >
intel_reg_dumper is gone, replaced by 'intel_reg dump'.
Signed-off-by: Jani Nikula
---
tests/ddx_intel_after_fbdev | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/ddx_intel_after_fbdev b/tests/ddx_intel_after_fbdev
index bcd2c29d8e9e..f068209d7a45 100755
--- a/t
On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote:
> Hm it's not just batches but any object with relocs. Could this explain
> the oddball libva/uxa hang? Stuff like "after playing $game for hours my
> desktop looked funny", but not for tiling issues.
Possible, but with libva having it
On Wed, 25 Nov 2015, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
>> On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
>> > /* Iterate over initialised rings */
>> > #define for_each_ring(ring__, dev_priv__, i__) \
>> >for ((i__) = 0; (i__) <
On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote:
> > > Instead of querying the reset counter before every access to the ring,
> > > query it the first time
On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
> > > If the system has no available swap pages, we cannot make forward
> > > progress in the shrinker by
On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel
> >
On Tue, 2015-11-24 at 15:55 +0100, Maarten Lankhorst wrote:
> Op 24-11-15 om 15:03 schreef Ander Conselvan De Oliveira:
> > On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> > > This removes pre/post_wm_update from intel_crtc->atomic, and
> > > creates atomic state for it in intel_crtc.
On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
> > > /* Iterate over initialised rings */
> > > #define for_each_ring(ring__, dev_priv__, i__) \
> > >
On 11/25/2015 2:51 PM, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.c
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> On skylake some of the registers are only writable when the correct
> power wells are enabled. Because of this watermarks have to be updated
> before the crtc turns off, or you get unclaimed register read and write
> warnings.
>
> This
It's causing endless amounts of trouble by hiding pretty serious bugs
where we wait for a few msecs, but accidentally while holding a
spinlock (sometimes even an irqsafe one).
And the only reason for this was to make the mode for the panic
handler work somewhat. But that _really_ needs to be done
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> wait_vblank is already set in intel_plane_atomic_calc_changes
> for broadwell, waiting for a double vblank is overkill.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/inte
Recently I always see the following error message during S4 or S3 resume with
drm-intel-nightly.
[ 97.778063] PM: Syncing filesystems ... done.
[ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
[
On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
> > > > If the system has no availabl
On Wed, Nov 25, 2015 at 09:02:20AM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote:
> > Hm it's not just batches but any object with relocs. Could this explain
> > the oddball libva/uxa hang? Stuff like "after playing $game for hours my
> > desktop looked
On Wed, Nov 25, 2015 at 02:57:47PM +0530, Goel, Akash wrote:
>
>
> On 11/25/2015 2:51 PM, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> >>On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> >>>On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville S
On Tue, Nov 24, 2015 at 08:13:06PM +0100, Daniel Vetter wrote:
> Hi Ander&Sivakumar,
>
> Dave&I had a short discussion about reprobing DP (and MST) state on
> resume. I think this is something we've missed in our dp hpd handling
> rework thus far. And at least for SST we need to take it into accou
On Wed, 25 Nov 2015 10:56:51 +0100,
Zhang, Xiong Y wrote:
>
> Recently I always see the following error message during S4 or S3 resume with
> drm-intel-nightly.
> [ 97.778063] PM: Syncing filesystems ... done.
> [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [
On 24/11/15 17:47, Daniel Vetter wrote:
On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Current code moves _any_ VMA to the inactive list only when
_all_ rendering on an object (so from any context or VM) has
been completed.
This creates an un-natural sit
On 24/11/15 15:25, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 03:08:09PM +, Tvrtko Ursulin wrote:
On 20/11/15 12:43, Chris Wilson wrote:
Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.
Signe
> On Wed, 25 Nov 2015 10:56:51 +0100,
> Zhang, Xiong Y wrote:
> >
> > Recently I always see the following error message during S4 or S3 resume
> with drm-intel-nightly.
> > [ 97.778063] PM: Syncing filesystems ... done.
> > [ 97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel
> >
On Wed, 25 Nov 2015 11:57:13 +0100,
Zhang, Xiong Y wrote:
>
> > On Wed, 25 Nov 2015 10:56:51 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > Recently I always see the following error message during S4 or S3 resume
> > with drm-intel-nightly.
> > > [ 97.778063] PM: Syncing filesystems ... done.
> >
Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link trainin
On 11/25/2015 3:34 PM, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 08:13:06PM +0100, Daniel Vetter wrote:
Hi Ander&Sivakumar,
Dave&I had a short discussion about reprobing DP (and MST) state on
resume. I think this is something we've missed in our dp hpd handling
rework thus far. And at lea
This is a placeholder for the feature list file. Its content is just
an example.
This needs to be filled in by feature owners with the feature name
and the corresponding tests regex.
Please refer to this piglit commit for more info on this feature.
commit f16d011db75b08ceae241e737059914669134
On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote:
> > > > Instead of querying the reset
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
>
> Merge them by creating a h
On Mon, 16 Nov 2015, Deepak M wrote:
> In CABC (Content Adaptive Brightness Control) content grey level
> scale can be increased while simultaneously decreasing
> brightness of the backlight to achieve same perceived brightness.
>
> The CABC is not standardized and panel vendors are free to follow
On Mon, 16 Nov 2015, Deepak M wrote:
> For dual link panel scenarios there are new fileds added in the
> VBT which indicate on which port the PWM cntrl and CABC ON/OFF
> commands needs to be sent.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Yetunde Adebisi
> Signed-off-by: Deepak M
> ---
>
On Wed, 25 Nov 2015, Jani Nikula wrote:
> On Mon, 16 Nov 2015, Deepak M wrote:
>> For dual link panel scenarios there are new fileds added in the
>> VBT which indicate on which port the PWM cntrl and CABC ON/OFF
>> commands needs to be sent.
>>
>> Cc: Jani Nikula
>> Cc: Daniel Vetter
>> Cc: Yet
On ke, 2015-11-25 at 14:21 +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> > Currently we perform our own wait in post_plane_update,
> > but the atomic core performs another one in wait_for_vblanks.
> > This means that 2 vblanks are done whe
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
>
> Merge them by creating a h
On 11/24/2015 1:33 PM, Wang, Zhi A wrote:
Hi Gurus:
I’m wondering what’s the right approach to deal with the context switch
reason: element_switch? According to b-spec, one ELSP submission may
include two elements, when one element is finished, HW will move to
process next element, the previous
Wow, that's nice! Thanks Michel for the clear explanation! That's just the
answer I'm looking for! :)
Thanks,
Zhi.
> -Original Message-
> From: Thierry, Michel
> Sent: Wednesday, November 25, 2015 8:48 PM
> To: Wang, Zhi A; intel-gfx@lists.freedesktop.org
> Cc: Han, Xu; Li, Weinan Z; He,
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> This is a revert of commit 066cf55b9ce3 "drm/i915: Fix IPS related flicker".
> intel_pre_disable_primary already handles this, and now everything
> goes through the atomic path there's no need to try to disable ips twice.
>
> Signed-off
On 25/11/2015 01:11, Dai, Yu wrote:
On 11/24/2015 08:23 AM, Nick Hoath wrote:
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been saved.
Now that the context is pinned until later in the request/context
lifec
On ons, 2015-11-18 at 10:17 +0100, Daniel Vetter wrote:
> On Wed, Nov 04, 2015 at 10:59:28AM +0100, Patrik Jakobsson wrote:
> > On Wed, Nov 04, 2015 at 10:35:19AM +0100, Robert Fekete wrote:
> > > The old value of 0x7FF will wrap the position at 2048 giving wrong
> > > coordinate values on panels l
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
re
Another question about EXECLIST is: Can a preemption happen between element
switch?
I know this is beyond the scope of i915 a little. I'm just curious if it's
possible.
Let's say we have context A B C
At first, we submit context A B in one ELSP write.
Then, we submit context C in another ELSP
On Mon, Nov 02, 2015 at 12:33:47PM -0800, Rafael Antognolli wrote:
> +static int __init drm_dp_aux_dev_init(void)
> +{
> + int res;
> +
> + drm_dp_aux_dev_class = class_create(THIS_MODULE, "drm_dp_aux_dev");
> + if (IS_ERR(drm_dp_aux_dev_class)) {
> + res = PTR_ERR(drm_dp_a
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> fb_bits is useful to have in the crtc_state for cs flips when
> the code is updated to use intel_frontbuffer_flip_prepare/complete.
> So calculate it in advance and move it to crtc_state. The other stuff
> can be calculated in post_plane
On 11/25/2015 1:00 PM, Wang, Zhi A wrote:
Another question about EXECLIST is: Can a preemption happen between element
switch?
I know this is beyond the scope of i915 a little. I'm just curious if it's
possible.
Let's say we have context A B C
At first, we submit context A B in one ELSP write
On Tue, Nov 24, 2015 at 06:52:09PM +0100, Daniel Vetter wrote:
> On Mon, Nov 23, 2015 at 06:06:17PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Pull the BDW+ DE pipe interrupt mask frobbing into a central place,
> > like we have for other platforms.
> >
> > Signed
OK. I see. Thanks Michel! :) Have a nice day. :)
Thanks,
Zhi.
> -Original Message-
> From: Thierry, Michel
> Sent: Wednesday, November 25, 2015 9:15 PM
> To: Wang, Zhi A; intel-gfx@lists.freedesktop.org
> Cc: Han, Xu; Li, Weinan Z; He, Min; Lv, Zhiyuan; Tian, Kevin
> Subject: Re: [Intel-g
We assume that lock is held on start of the loop scope.
Some paths continuing inside loop didn't adhere to this
assumption, causing segfault on unlocking an already
unlocked mutex. Fix this by re-aquiring lock always.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93013
Cc: Michał Winiarsk
On 11/25/2015 3:28 PM, Chris Wilson wrote:
On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
On Wed, 2015-11-25 at 15:20 +0200, Mika Kuoppala wrote:
> We assume that lock is held on start of the loop scope.
> Some paths continuing inside loop didn't adhere to this
> assumption, causing segfault on unlocking an already
> unlocked mutex. Fix this by re-aquiring lock always.
>
> Bugzilla: ht
Hi,
On 25 November 2015 at 12:21, Ander Conselvan De Oliveira
wrote:
> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
>> @@ -4754,6 +4751,9 @@ static void intel_post_plane_update(struct intel_crtc
>> *crtc)
>> if (atomic->post_enable_primary)
>> intel_post_enable_
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c| 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/g
The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
pipe_config_compare, v2] relaxed the way to compare the pipe
configurations, but one new comparison sneaked in there: it added the
strict has_drrs value check. This causes a regression on many
machines, typically HP laptops with a docking
From: Ville Syrjälä
DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
forbidden to set it for LVDS/CRT as well. So let's move it out of the
ironlake_compute_dpll() and just do it on demand in the pll enable hook.
This allows the PLL to be shared in more cases when dealing with
From: Ville Syrjälä
ironlake_crtc_compute_clock() gets called during atomic compute phase,
so we must check the future pipe type instead of the current type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
We had the "The master control interrupt lied (SDE)!" check and error
message in place for a long time without any problems, until
commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e
Author: Sonika Jindal
Date: Wed Jul 8 17:07:47 2015 +0530
drm/i915: Handle HPD when it has actually occurred
c
This reverts
commit 97e5eddcc5300a0f59a55248cd243937a8ab
Author: Daniel Vetter
Date: Fri Oct 23 10:56:12 2015 +0200
drm/i915: shut up gen8+ SDE irq dmesg noise
With the proper fix ("drm/i915: fix the SDE irq dmesg warnings
properly") reliably in place, bring back the error message.
C
On Wed, Nov 25, 2015 at 03:26:47PM +0100, Takashi Iwai wrote:
> The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
> pipe_config_compare, v2] relaxed the way to compare the pipe
> configurations, but one new comparison sneaked in there: it added the
> strict has_drrs value check. This cau
On Wed, Nov 25, 2015 at 04:47:22PM +0200, Jani Nikula wrote:
> We had the "The master control interrupt lied (SDE)!" check and error
> message in place for a long time without any problems, until
>
> commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e
> Author: Sonika Jindal
> Date: Wed Jul 8 17:07
Nick Hoath writes:
> Use the first retired request on a new context to unpin
> the old context. This ensures that the hw context remains
> bound until it has been written back to by the GPU.
> Now that the context is pinned until later in the request/context
> lifecycle, it no longer needs to be
From: Ville Syrjälä
LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
for transocoder B/C. And more importnatnly we should not consider
the state of underrun reporting for transcoders B/C when checking
whether we can enable the south error interrupt.
The whole thing is a bit
On Wed, Nov 25, 2015 at 05:11:23PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
> for transocoder B/C. And more importnatnly we should not consider
> the state of underrun reporting for transcoders B/C
This testcase tries to validate -EIO behaviour by disabling gpu reset
support in the kernel. Except that the wait subtest forgot to do that,
and therefore gets a return value of 0 instead of the expected -EIO.
With this fix gem_eio passes on a kernel with my fixes completely.
Cc: Chris Wilson
Si
Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu
hang we need to be careful to not run into the "hanging too fast
check":
- don't restore the ban period, but instead keep it at 0.
- make sure we idle the gpu fully before hanging it again (wait
subtest missted that).
With t
On Wed, Nov 25, 2015 at 05:19:24PM +0100, Daniel Vetter wrote:
> Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu
> hang we need to be careful to not run into the "hanging too fast
> check":
That's not how it works. It restores the GPU by triggering a manual
reset.
-Chris
--
On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote:
> This testcase tries to validate -EIO behaviour by disabling gpu reset
> support in the kernel. Except that the wait subtest forgot to do that,
> and therefore gets a return value of 0 instead of the expected -EIO.
>
Wrong. It was in
On Wed, Nov 25, 2015 at 04:29:01PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote:
> > This testcase tries to validate -EIO behaviour by disabling gpu reset
> > support in the kernel. Except that the wait subtest forgot to do that,
> > and therefore gets
We've been chasing a regression[1] that prevented us from merging the last
couple patches of the ILK-style atomic watermark series. We've finally
identified the culprit --- if we fail to reconstruct the BIOS FB, our internal
driver state was left in an inconsistent state which caused confusion for
Our low-level watermark calculation functions don't get called when the
CRTC is disabled or the relevant plane is invisible, so they should
never see a zero htotal or zero bpp. However add some checks to ensure
this is true so that we don't wind up dividing by zero if we make a
mistake elsewhere i
Although we can do a good job of reading out hardware state, the
graphics firmware may have programmed the watermarks in a creative way
that doesn't match how i915 would have chosen to program them. We
shouldn't trust the firmware's watermark programming, but should rather
re-calculate how we thin
Plane state objects contain two copies of src/dest coordinates: the
original (requested by userspace) coordinates in the base
drm_plane_state object, and a second, clipped copy (i.e., what we
actually want to program to the hardware) in intel_plane_state. We've
only been setting up the former set
The intel_dump_pipe_config() always dumps the currently active plane
state for each plane on a CRTC. If we're calling this function to dump
CRTC state that is in-flight (not yet active), then this mismatch can be
misleading and confusing. Let's pay attention to whether the state
we're dumping is
When watermark calculation was moved up to the atomic check phase, the
code was updated to calculate based on in-flight atomic state rather
than already-committed state. However the hsw_compute_linetime_wm()
didn't get updated and continued to pull values out of the
currently-committed CRTC state.
If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb. This mismatch causes problems later on
(e.g., for the watermark code). Since we've failed to reconstruct the
BIOS FB, the best s
We dump during HW state readout, but that's too early to reflect how the
primary plane is actually configured.
In the future it would be nice if we could just read out HW state and
reconstruct FB's at the same point, but at the moment we don't have GEM
initialized sufficiently during hardware read
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means
During state dumping, list planes that have an FB but are invisible
(e.g., because they're offscreen or clipped by other planes) as "not
visible" rather than "enabled." While we're at it, dump the FB format
as a human-readable string rather than a hex format code.
v2: Don't add bpp; make format h
On Wed, Nov 25, 2015 at 1:54 PM, Robert Fekete
wrote:
> On ons, 2015-11-18 at 10:17 +0100, Daniel Vetter wrote:
>> On Wed, Nov 04, 2015 at 10:59:28AM +0100, Patrik Jakobsson wrote:
>> > On Wed, Nov 04, 2015 at 10:35:19AM +0100, Robert Fekete wrote:
>> > > The old value of 0x7FF will wrap the posit
On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote:
> We've been chasing a regression[1] that prevented us from merging the last
> couple patches of the ILK-style atomic watermark series. We've finally
> identified the culprit --- if we fail to reconstruct the BIOS FB, our internal
> drive
Unfortunately the entire improved docbook project died at KS in a
massive bikeshed. So we need to carry this around in drm private trees
forever :(
I discussed this with Dave at kernel summit and he's ok with this.
I'll maintain the asciidoc support in topic/kerneldoc in the
drm-intel.git tree. T
From: Danilo Cesar Lemes de Paula
Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.
Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.
This adds the capability of adding human-r
On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote:
> > We've been chasing a regression[1] that prevented us from merging the last
> > couple patches of the ILK-style atomic watermark series. We've finally
> > identified the
On Wed, Nov 25, 2015 at 08:48:34AM -0800, Matt Roper wrote:
> Although we can do a good job of reading out hardware state, the
> graphics firmware may have programmed the watermarks in a creative way
> that doesn't match how i915 would have chosen to program them. We
> shouldn't trust the firmware
Hi all,
As you might know the markup improvements have been discussed at kernel summit:
https://lwn.net/Articles/662930/
Unfortunately it died in a bikeshed fest due to an alliance of people who think
docs are useless and you should just read code and others who didn't know how to
build the kern
From: Danilo Cesar Lemes de Paula
DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.
* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore
* drivers/gpu/drm/drm_modeset_lock.c: had
On Wed, Nov 25, 2015 at 08:48:35AM -0800, Matt Roper wrote:
> In addition to calculating final watermarks, let's also pre-calculate a
> set of intermediate watermark values at atomic check time. These
> intermediate watermarks are a combination of the watermarks for the old
> state and the new sta
On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote:
> > The wait-request interface still has the wait-seqno legacy of having to
> > acquire the reset_counter under the mutex before calling. That is quite
> > hairy and causes
From: Danilo Cesar Lemes de Paula
Using pandoc as the Markdown engine cause some minor side effects as
pandoc includes main tags for almost everything.
Original Markdown support approach removes those main tags, but it caused
some inconsistencies when that tag is not the main one, like:
..
...
By popular demand.
This needs some adjustment/fixups after feeding snippets to asciidoc
since compared to markdown asciidown escapes xml markup and doesn't
just let it through.
The other noticeable change is that build times increase a lot - we
need to launch the markup process per-snippet, there
On Wed, Nov 25, 2015 at 09:04:11AM -0800, Matt Roper wrote:
> On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote:
> > > We've been chasing a regression[1] that prevented us from merging the last
> > > couple patches of the I
Second attempt using Imres' hints.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: Marius Vlad
Signed-off-by: Marius Vlad
---
tests/pm_rpm.c | 120 +
1 file changed, 120 insertions(+)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index c4fb19c..157cf29 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -1729,6 +17
On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 24, 2015 at 03:3
My apologies to Chris Wilson for being dense on this topic for
essentially for years.
This patch doesn't do any big redesign of the overall reset flow, but
instead just applies changes where it's needed to obey gem_eio. We can
redesign later on, but for now I prefer to make the testcase happy
with
1 - 100 of 128 matches
Mail list logo
