Readding intel-gfx.
On Sat, Jan 11, 2014 at 12:20 AM, Daniel Vetter wrote:
> On Fri, Jan 10, 2014 at 8:24 PM, Ben Widawsky
> wrote:
>> On Mon, Jan 6, 2014 at 11:51 PM, Daniel Vetter wrote:
>>> Neither patch subject nor the commit message mention that this fixes a
>>> bug. Also, the Testcase: li
Hi all,
New -testing cycle with cool stuff:
- final bits for runtime D3 on Haswell from Paul (now enabled fully)
- parse the backlight modulation freq information in the VBT from Jani
(but not yet used)
- more watermark improvements from Ville for ilk-ivb and bdw
- bugfixes for fastboot from Jes
On Fri, Jan 10, 2014 at 03:12:29PM -0600, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Jeff McGee (4):
> pm_rps: Use unbuffered I/O on sysfs files
> pm_rps: Assert that valid sysfs writes return success
> pm_rps: Fix test to target original min and max
> pm_rps: Use igt exit handler
On Fri, 10 Jan 2014 19:17:02 -0200
Paulo Zanoni wrote:
> 2014/1/10 Jesse Barnes :
> > We were apparently relying on the defaults on BDW, which resulted in no
> > hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to
> > enable all interrupts.
> >
> > v2: use preinstall instead
2014/1/10 Jesse Barnes :
> We were apparently relying on the defaults on BDW, which resulted in no
> hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to
> enable all interrupts.
>
> v2: use preinstall instead of redundant SDIER write
>
> References: https://bugs.freedesktop.org
We were apparently relying on the defaults on BDW, which resulted in no
hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to
enable all interrupts.
v2: use preinstall instead of redundant SDIER write
References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
References: ht
2014/1/10 Jesse Barnes :
> On Fri, 10 Jan 2014 13:02:20 -0800
> Jesse Barnes wrote:
>
>> We were apparently relying on the defaults on BDW, which resulted in no
>> hotplug or AUX interrupts.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
>> References: https://bugs.freedeskto
2014/1/10 Jesse Barnes :
> We were apparently relying on the defaults on BDW, which resulted in no
> hotplug or AUX interrupts.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
> References: https://bugs.freedesktop.org/show_bug.cgi?id=72833
> Signed-off-by: Jesse Barnes
> ---
>
From: Jeff McGee
Bionic C library may not re-read a buffered, read-only file which
results in failure to monitor changes in gt_cur_freq_mhz.
Signed-off-by: Jeff McGee
---
tests/pm_rps.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tests/pm_rps.c b/tests/pm_rps.c
i
From: Jeff McGee
do_writeval now always checks the return value, whether we expect
success or a specific error. Also add new macro writeval_inval to
simplify repeated use of do_writeval to test for EINVAL return code.
Signed-off-by: Jeff McGee
---
tests/pm_rps.c | 23 +++
1
From: Jeff McGee
The goal of the test is to confirm that gt_cur_freq_mhz can be forced
to the boundaries of the frequency range by collapsing gt_min_freq_mhz
and gt_max_freq_mhz to the target value. But we miss testing the upper
end of the range by targetting the current value of max after it has
From: Jeff McGee
Jeff McGee (4):
pm_rps: Use unbuffered I/O on sysfs files
pm_rps: Assert that valid sysfs writes return success
pm_rps: Fix test to target original min and max
pm_rps: Use igt exit handler for restore
tests/pm_rps.c | 85 +
From: Jeff McGee
Signed-off-by: Jeff McGee
---
tests/pm_rps.c | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index c968ecb..7c739b6 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -36,14 +36,6
On Fri, 10 Jan 2014 13:02:20 -0800
Jesse Barnes wrote:
> We were apparently relying on the defaults on BDW, which resulted in no
> hotplug or AUX interrupts.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
> References: https://bugs.freedesktop.org/show_bug.cgi?id=72833
> Sign
We need to read out the CDclk to calculate the DP aux divider correctly.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7df5085..4ac1da5 100644
--- a/dr
We were apparently relying on the defaults on BDW, which resulted in no
hotplug or AUX interrupts.
References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
References: https://bugs.freedesktop.org/show_bug.cgi?id=72833
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_irq.c | 4 +++
On Fri, Jan 10, 2014 at 08:26:23PM +, Chris Wilson wrote:
> Only objects pinned to the display engine can be an active framebuffer,
> so we can refine the current check for any pinned object to be a
> pinned-display object.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_ge
On Fri, Jan 10, 2014 at 12:41:49PM -0800, Ben Widawsky wrote:
> On Fri, Jan 10, 2014 at 08:26:23PM +, Chris Wilson wrote:
> > Only objects pinned to the display engine can be an active framebuffer,
> > so we can refine the current check for any pinned object to be a
> > pinned-display object.
>
On Fri, Jan 10, 2014 at 06:38:59PM +0100, Daniel Vetter wrote:
> On Fri, Jan 10, 2014 at 11:20:42AM -0600, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > Use unbuffered file I/O to simplify and ensure proper sysfs access.
> > Bionic C library may not re-read a read-only file unless unbu
On Fri, Jan 10, 2014 at 12:22:44PM -0800, Ben Widawsky wrote:
> On Mon, Dec 16, 2013 at 06:58:20PM +, Chris Wilson wrote:
> > On Mon, Dec 16, 2013 at 12:01:07PM +, Chris Wilson wrote:
> > > If i915_driver_load fails before i915_gem_load we try to unlink the ggtt
> > > prior to initialising
Only objects pinned to the display engine can be an active framebuffer,
so we can refine the current check for any pinned object to be a
pinned-display object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
dif
On Mon, Dec 16, 2013 at 06:58:20PM +, Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 12:01:07PM +, Chris Wilson wrote:
> > If i915_driver_load fails before i915_gem_load we try to unlink the ggtt
> > prior to initialising the list and triggering an oops.
>
> This is incomplete.
>
> > Sign
Daniel thought that this was an opportune moment to include which pins
and bits ended up being stuck in the WARN.
Suggested-by: Daniel Vetter
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i91
On Fri, Jan 10, 2014 at 11:59:10AM -0800, Ben Widawsky wrote:
> I will gladly re-review if you make any of my suggested changes.
Hmm, I had already done the capture_vma one since that is required to
display the right addresses in the error state.
The output is like:
vm[0]
Active [0]:
Pinned
On Thu, Jan 09, 2014 at 10:57:23PM +, Chris Wilson wrote:
> The current error state harks back to the era of just a single VM. For
> full-ppgtt, we capture every bo on every VM. It behoves us to then print
> every bo for every VM, which we currently fail to do and so miss vital
> information in
On Fri, Jan 10, 2014 at 06:49:20PM +, Chris Wilson wrote:
> It seems that hardware that is broken enough to emit a hotplug IRQ even
> though the pin is surposedly disable, will do so indefinitely.
>
> References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
> Link: https://bugzilla.redh
On Fri, Jan 10, 2014 at 06:49:20PM +, Chris Wilson wrote:
> It seems that hardware that is broken enough to emit a hotplug IRQ even
> though the pin is surposedly disable, will do so indefinitely.
>
> References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
> Link: https://bugzilla.redh
Disabling the hotplug IRQ is a two-step process. First, inside the IRQ
handler we mark the rogue hotplug pin for disabling. Then later in the
hotplug worker, we actually disable the hotplug pin. So we should not
WARN about the rogue hotplug IRQ being sent until after we have
completed disabling the
It seems that hardware that is broken enough to emit a hotplug IRQ even
though the pin is surposedly disable, will do so indefinitely.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1051369
Signed-off-by: Chris Wilson
---
drivers
On Tue, Jan 07, 2014 at 02:55:55PM -0200, Paulo Zanoni wrote:
> +static bool
> +intel_ddi_ensure_encoder_type(struct intel_encoder *encoder)
[...]
> + if (connector->base.status == connector_status_connected) {
> + DRM_DEBUG_KMS("Can't change DDI %c personality to
On Fri, Jan 10, 2014 at 11:20:42AM -0600, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Use unbuffered file I/O to simplify and ensure proper sysfs access.
> Bionic C library may not re-read a read-only file unless unbuffered,
> which results in failure to monitor changes in gt_cur_freq_mhz.
From: Ville Syrjälä
When using pipe A and transcoder EDP w/o panel fitter on
HSW, the PF CRC isn't available as the panel fitter is entirely
bypassed. Check for this and refuse to give out CRCs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +
On Fri, Jan 10, 2014 at 06:32:49PM +0100, Daniel Vetter wrote:
> On Fri, Jan 10, 2014 at 09:16:39AM -0800, Ben Widawsky wrote:
> > On Fri, Jan 10, 2014 at 06:09:15PM +0100, Daniel Vetter wrote:
> > > On Fri, Jan 10, 2014 at 03:47:52PM +, Damien Lespiau wrote:
> > > > There are only two cases he
On Fri, Jan 10, 2014 at 09:16:39AM -0800, Ben Widawsky wrote:
> On Fri, Jan 10, 2014 at 06:09:15PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 10, 2014 at 03:47:52PM +, Damien Lespiau wrote:
> > > There are only two cases here, pre and post SNB (PPGTT).
> > >
> > > Signed-off-by: Damien Lespia
On Tue, Dec 17, 2013 at 02:27:39PM +, Chris Wilson wrote:
> We attempt to reschedule an active work which can itself corrupt the
> workqueue lists, and we may then free the work item whilst the task is
> still pending. Both of these may lead to a system deadlock and an
> unresponsive machine wi
On Fri, Jan 10, 2014 at 06:09:15PM +0100, Daniel Vetter wrote:
> On Fri, Jan 10, 2014 at 03:47:52PM +, Damien Lespiau wrote:
> > There are only two cases here, pre and post SNB (PPGTT).
> >
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
From: Jeff McGee
Use unbuffered file I/O to simplify and ensure proper sysfs access.
Bionic C library may not re-read a read-only file unless unbuffered,
which results in failure to monitor changes in gt_cur_freq_mhz.
Adapt do_writeval to assert that no write error occurs when we expect
none.
E
Hi,
On 2013-12-17 16:27, Chris Wilson wrote:
> We attempt to reschedule an active work which can itself corrupt the
> workqueue lists, and we may then free the work item whilst the task is
> still pending. Both of these may lead to a system deadlock and an
> unresponsive machine without any output
On Fri, Jan 10, 2014 at 03:47:52PM +, Damien Lespiau wrote:
> There are only two cases here, pre and post SNB (PPGTT).
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drive
On Fri, Jan 10, 2014 at 02:06:45PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> PFIT_CONTROL doesn't exist on 830M, so avoid reading it in
> i9xx_get_pfit_config().
>
> Also assume that only mobile gen2/3 chipsets have a panel fitter. This
> matches the documentation, bu
On Thu, Jan 2, 2014 at 12:56 PM, Robert Navarro wrote:
I too am having the same issue. I'm running on kernel 3.12.6 (just updated)
>
> The issue happens less frequently, but it still happens and it's quite
> annoying.
>
> Previously I would just get lines like this:
>
> [ 342.071567] [drm:ilk_di
On Tue, Jan 07, 2014 at 02:55:53PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> In some cases we have more than 1 connector associated to an encoder
> (e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of
> these connectors. If we only allowed modesets for connected connector
On Wed, Jan 08, 2014 at 05:26:31PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The WA is mentioned in HSW's GAMMA_MODE register documentation, but
> not on on BDW's documentation, so let's assume it is not needed there.
>
> Signed-off-by: Paulo Zanoni
It looks that way indeed (not test
Arjan van de Ven reported that on his test machine that he was seeing
stalls of greater than 1 frame greatly impacting the user experience. He
tracked this down to being the locked flush during a pagefault as being
the culprit hogging the struct_mutex and so blocking any other user from
proceeding.
There are only two cases here, pre and post SNB (PPGTT).
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3192
Run all relevant tests on all rings.
Suggested-by: Daniel Vetter
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 132 ---
1 file changed, 90 insertions(+), 42 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
ind
Split context related tests from non-context ones
and cleanup the naming.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 138 ---
1 file changed, 108 insertions(+), 30 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_st
On Fri, Jan 10, 2014 at 05:10:20PM +0200, Jani Nikula wrote:
> It's an accident waiting to happen.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_drv.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/d
On Fri, 10 Jan 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There isn't an explicit stolen memory base register on gen2.
> Some old comment in the i915 code suggests we should get it via
> max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
>
> The e820 map in said
It's an accident waiting to happen.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 46aea6c..33a3ed4 100644
--- a/drivers/gpu/drm/i
On Fri, Jan 10, 2014 at 02:06:44PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I spotted a few small issues while reading the code w/ older platforms
> in mind. The panel fitter/LVDS port patches probably have no real impact
> since it looks like those non-existing regis
From: Ville Syrjälä
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[0.00] BIOS-e820: [mem 0x000
On Thu, Jan 09, 2014 at 05:08:16PM +0200, Imre Deak wrote:
> VGA detection requires the reference clock to be on, so make sure this
> is the case.
>
> This fixes VGA hotplug/manual detection where all pipes are off and so
> we would normally disable all clocks.
>
> v2:
> - Instead of disabling PS
From: Ville Syrjälä
There's no LVDS port on 830M so don't go reading the LVDS control
register.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
From: Ville Syrjälä
INSTPM is a masked register so use the _MASKED_BIT_{ENABLE,DISABLE}
macros when enabling/disabling self-refresh on 915GM.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
From: Ville Syrjälä
PFIT_CONTROL doesn't exist on 830M, so avoid reading it in
i9xx_get_pfit_config().
Also assume that only mobile gen2/3 chipsets have a panel fitter. This
matches the documentation, but I didn't have real hardware to verify.
Gen4 docmentation is a bit inconsistent, but experi
From: Ville Syrjälä
I spotted a few small issues while reading the code w/ older platforms
in mind. The panel fitter/LVDS port patches probably have no real impact
since it looks like those non-existing registers always return 0. But
might as well avoid reading them.
The 915GM SR fix is untested
On Sat, Dec 14, 2013 at 08:38:30PM -0200, Rodrigo Vivi wrote:
> From: Daniel Vetter
>
> So shuffle the checks around a bit. Also give all the structs and
> functions proper prefixes: i830_ for the dual-pipe mobile platforms
> and i845_ for the two single-pipe desktop platforms.
>
> Note that the
On Fri, Jan 10, 2014 at 03:18:26PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> Many of the fields from Gen6 have gone away for vlv. Strip all those
> fields that are not relevent and try to update fields that we care
> about. This patch give information about current RP & RC status and
From: Deepak S
Many of the fields from Gen6 have gone away for vlv. Strip all those
fields that are not relevent and try to update fields that we care
about. This patch give information about current RP & RC status and
individual Wells.
v2: Move Render & Media Well status to separate lines (Vill
From: Ville Syrjälä
If the first modeset operation fails, we will attempt to restore the
previous configuration that we read out from the hardware. But as we
don't yet reconstruct the framebuffer information, we end up calling
the modeset code with an enabled crtc but with fb==NULL. This will
lea
From: Ville Syrjälä
Add 'new_enabled' to intel_crtc and precompute it alongside new_encoder
and new_crtc. This will allow making decisions about shared resources
that are affected by the set of active pipes, before we've clobbered
anything for real.
Signed-off-by: Ville Syrjälä
---
drivers/gpu
From: Ville Syrjälä
On VLV we need to compute the new cdclk before we've updated the current
state. The code achieved that in a somewhat complex way. Now that we
have new_enabled and new_config, we can simplify the code quite a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_d
From: Ville Syrjälä
Add a new_config pointer to intel_crtc which will point to the new pipe
config for said crtc while intel_crtc.config will still contain the old
config during first parts of the modeset operation. This is a step
towards having the entire new state available during the compute p
From: Ville Syrjälä
I started to think a bit about how the code should look for doing a full
modeset for more than one pipe at a time. This is how far I got yesterday.
I suppose the next thing would be moving the PLL calculations into compute
config stage, and then actually computing a new pipe
On Fri, Jan 10, 2014 at 08:40:34AM +, Goel, Akash wrote:
> >> For your usecase, have you tried to simply reduce the stolen area as
> >> much as possible? Our friendly competition on ARM SoCs seems to have
> >> mostly moved away from gfx reserved chunks towards more flexible
> >> approaches l
On Fri, Jan 10, 2014 at 08:53:42AM +0100, Daniel Vetter wrote:
> My OCD just couldn't let this slide. Spotted while reviewing Ville's
> patch to only flip planes when we have FBC.
>
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Right. It has bothered me too, but I've been too lazy to run s
>> For your usecase, have you tried to simply reduce the stolen area as
>> much as possible? Our friendly competition on ARM SoCs seems to have
>> mostly moved away from gfx reserved chunks towards more flexible
>> approaches like CMA. Giving stolen back to the linux page allocator
>> should be
68 matches
Mail list logo
