On Tue, Jul 09, 2013 at 07:58:03PM -0700, Ben Widawsky wrote:
> CC: Chad Versace
> CC: Bryan Bell
> Signed-off-by: Ben Widawsky
So I think we should run this from igt and check its return value. And
since we've had a few bugs with other (currently untested) igt tools, can
you please add a new i
The current code won't report any fifo underruns on cpt if just one
pipe has fifo underrun reporting disabled. We can't enable the
interrupts, but we can still check the per-transcoder bits and so
report the underrun delayed if:
- We always clear the transcoder's bit (and none of the other bits)
On Tue, Jul 09, 2013 at 04:00:31PM -0700, Guenter Roeck wrote:
> This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970
> for
> IvyBridge CPUs.
>
> The original commit results in repeated 'Timed out waiting for forcewake old
> ack to clear' messages on a Supermicro C7H61 boa
The algorithm/information was originally written by Chad, though I
changed the control flow, and I think his original code had a couple of
bugs, though I didn't look very hard before rewriting. That could have
also been different interpretations of the spec.
The excellent comments remain entirely
CC: Chad Versace
CC: Bryan Bell
Signed-off-by: Ben Widawsky
---
tools/Makefile.am | 1 +
tools/intel_get_llc_size.c | 57 ++
2 files changed, 58 insertions(+)
create mode 100644 tools/intel_get_llc_size.c
diff --git a/tools/Makefile.am b/t
Mark the address ranges as accessible with VALGRIND_MAKE_MEM_DEFINED.
Signed-off-by: Chia-I Wu
---
intel/intel_bufmgr_gem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index a51e3f3..f98f7a7 100644
--- a/intel/intel_bufmgr_gem.c
HI Daniel,
On Tue, 9 Jul 2013 16:48:43 +0200 Daniel Vetter wrote:
>
> Can you please add the drm-intel-fixes branch to your linux-next tree
> on top of the for-linux-next branch you've already included from my
> drm-intel repo at git://people.freedesktop.org/~danvet/drm-intel ?
>
> I'm asking si
This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for
IvyBridge CPUs.
The original commit results in repeated 'Timed out waiting for forcewake old
ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
with i7-3770K CPU. It ultimately results in
On Tue, Jul 09, 2013 at 10:33:22PM +0200, Daniel Vetter wrote:
> On Tue, Jul 09, 2013 at 01:14:09PM -0700, Guenter Roeck wrote:
> > This reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970.
> >
> > The commit results in repeated 'Timed out waiting for forcewake old ack
> > to clear' messages o
2013/7/9 Daniel Vetter :
> The current code won't report any fifo underruns on cpt if just one
> pipe has fifo underrun reporting disabled. We can't enable the
> interrupts, but we can still check the per-transcoder bits and so
> report the underrun delayed if:
> - We always clear the transcoder's
On 07/09/2013 02:51 PM, Jesse Barnes wrote:
> You can use intel_reg_dumper or quick_dump from intel-gpu-tools.
> Hopefully your distro has it packaged, otherwise you can build the
> version at git.freedesktop.org/git/xorg/app/intel-gpu-tools.
Great, thx! I'll follow up once I've had a chance to tr
On Tue, 09 Jul 2013 14:46:28 -0700
Christian Kreibich wrote:
> On 07/09/2013 02:27 PM, Jesse Barnes wrote:
> > Sounds like our pixel clock is probably out of the range your monitor
> > wants. If you can get that mode running with the VESA driver you could
> > collect a register dump in the good
On 07/09/2013 02:27 PM, Jesse Barnes wrote:
> Sounds like our pixel clock is probably out of the range your monitor
> wants. If you can get that mode running with the VESA driver you could
> collect a register dump in the good and bad cases so we could compare...
I'm very happy to try (though it'
On Mon, 08 Jul 2013 21:38:13 -0700
Christian Kreibich wrote:
> Hi all,
>
> I hope I have found the right forum for asking my question -- apologies
> if that's not the case. I have a Dell U2412M connected to a Dell
> StudioSlim 540s, with the i915 driver on Fedora's 3.9.6 Kernel running
> KDE (4.
Since the addition of VECS we have a slightly different enable
sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
will end up in hard to track down surprises.
Hence unifiy things and since we have copies of this code in 3 places
now, extract it into its own little helper.
v3: Reba
Same treatment as for SERR_INT: If we clear only the bit for the pipe
we're enabling (but unconditionally) then we can always check for
possible underruns after having disabled the interrupt. That way pipe
underruns won't be lost, but at worst only get reported in a delayed
fashion.
v2: The same l
The current code won't report any fifo underruns on cpt if just one
pipe has fifo underrun reporting disabled. We can't enable the
interrupts, but we can still check the per-transcoder bits and so
report the underrun delayed if:
- We always clear the transcoder's bit (and none of the other bits)
On Tue, Jul 09, 2013 at 05:54:40PM +0100, Chris Wilson wrote:
> This reverts commit 25ff119 and the follow on for Valleyview commit 2dc8aae.
>
> commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
> Author: Chris Wilson
> Date: Thu Apr 4 21:31:03 2013 +0100
>
> drm/i915: Workaround incoherence
On Tue, Jul 09, 2013 at 05:54:39PM +0100, Chris Wilson wrote:
> This hopefully fixes the root cause behind the workaround from
>
> commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
> Author: Chris Wilson
> Date: Thu Apr 4 21:31:03 2013 +0100
>
> drm/i915: Workaround incoherence between fence
On Tue, Jul 09, 2013 at 01:14:09PM -0700, Guenter Roeck wrote:
> This reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970.
>
> The commit results in repeated 'Timed out waiting for forcewake old ack
> to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
> with i7-3770K
On Tue, Jul 09, 2013 at 09:21:41AM -0700, Jesse Barnes wrote:
> On Fri, 5 Jul 2013 19:21:38 +0300
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > I just got confirmation that we're using some old values for the PLL
> > LPF coefficients for DP RBR/HDMI/DAC on VLV. The
>
On Tue, Jul 09, 2013 at 11:35:38AM -0700, Chad Versace wrote:
> On 07/04/2013 11:46 AM, Ben Widawsky wrote:
> >On Thu, Jul 04, 2013 at 08:43:58PM +0200, Daniel Vetter wrote:
> >>On Thu, Jul 4, 2013 at 8:40 PM, Ben Widawsky wrote:
> >>>On Thu, Jul 04, 2013 at 08:14:41PM +0200, Daniel Vetter wrote:
This reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970.
The commit results in repeated 'Timed out waiting for forcewake old ack
to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
with i7-3770K CPU. It ultimately results in a hangup if the system is highly
loaded. Re
On 07/04/2013 11:46 AM, Ben Widawsky wrote:
On Thu, Jul 04, 2013 at 08:43:58PM +0200, Daniel Vetter wrote:
On Thu, Jul 4, 2013 at 8:40 PM, Ben Widawsky wrote:
On Thu, Jul 04, 2013 at 08:14:41PM +0200, Daniel Vetter wrote:
On Thu, Jul 04, 2013 at 11:02:07AM -0700, Ben Widawsky wrote:
To make
This hopefully fixes the root cause behind the workaround from
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to further investigation by Jon Bloom
This reverts commit 25ff119 and the follow on for Valleyview commit 2dc8aae.
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
commit 2dc8aae06d53458dd3624dc
On Fri, 5 Jul 2013 19:21:38 +0300
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I just got confirmation that we're using some old values for the PLL
> LPF coefficients for DP RBR/HDMI/DAC on VLV. The
> VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_9 document lists both values
> by
On Mon, Jul 08, 2013 at 02:06:50PM -0300, Paulo Zanoni wrote:
> 2013/7/4 Daniel Vetter :
> > Since the addition of VECS we have a slightly different enable
> > sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
> > will end up in hard to track down surprises.
> >
> > Hence unifiy th
On Mon, Jul 08, 2013 at 05:20:21PM -0300, Paulo Zanoni wrote:
> Hi
>
> Due to the current features that I'm implementing I started looking at
> our interrupt code so I can reuse it. I noticed quite a few details
> and potential problems, and I can write patches for them, but first I
> think I shou
On Mon, Jul 08, 2013 at 11:38:15AM -0300, Paulo Zanoni wrote:
> 2013/7/4 Daniel Vetter :
> > This way all changes to SDEIMR all go through the same function, with
> > the exception of the (single-threaded) setup/teardown code.
> >
> > For paranoia again add an assert_spin_locked.
> >
> > v2: For ev
On Tue, Jul 09, 2013 at 02:56:33PM +0100, Chris Wilson wrote:
> On Tue, Jul 09, 2013 at 02:44:27PM +0200, Daniel Vetter wrote:
> > v2: Bail out if we hit the WARN_ON to avoid fallout later on. Spotted
> > by Chris Wilson.
> >
> > Suggested-by: Chris Wilson
> > Cc: Chris Wilson
> > Signed-off-by:
On Tue, Jul 09, 2013 at 02:56:01PM +0100, Chris Wilson wrote:
> On Tue, Jul 09, 2013 at 02:44:26PM +0200, Daniel Vetter wrote:
> > Originally I've thought that this fixes up the reset issues on my
> > gm45, but that was just a red herring due to b0rked testing.
> >
> > Still I much prefer writing
In kernel modeset driver mode we're in full control of the chip,
always. So there's no need at all to set mm.suspended in
i915_gem_idle. Hence move that out into the leavevt ioctl. Since
i915_gem_idle doesn't suspend gem any more we can also drop the
re-enabling for KMS in the thaw function.
Also
Hi Stephen
Can you please add the drm-intel-fixes branch to your linux-next tree
on top of the for-linux-next branch you've already included from my
drm-intel repo at git://people.freedesktop.org/~danvet/drm-intel ?
I'm asking since I've merged a patch to -fixes late in the 3.10 cycle
and despite
On Tue, Jul 09, 2013 at 05:05:26PM +0300, Imre Deak wrote:
> DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
> the driver will treat as an invalid value and use 1.62Gbps instead. Fix
> this by capping to 2.7Gbps for sinks reporting a 5.4Gbps max bw.
>
> Also add a warning f
DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
the driver will treat as an invalid value and use 1.62Gbps instead. Fix
this by capping to 2.7Gbps for sinks reporting a 5.4Gbps max bw.
Also add a warning for reserved values.
v2:
- allow only bw values explicitly listed in
On Tue, Jul 09, 2013 at 02:44:27PM +0200, Daniel Vetter wrote:
> v2: Bail out if we hit the WARN_ON to avoid fallout later on. Spotted
> by Chris Wilson.
>
> Suggested-by: Chris Wilson
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel O
On Tue, Jul 09, 2013 at 02:44:26PM +0200, Daniel Vetter wrote:
> Originally I've thought that this fixes up the reset issues on my
> gm45, but that was just a red herring due to b0rked testing.
>
> Still I much prefer writing the right values (all other fields are
> reserved) instead of potentiall
On Tue, Jul 09, 2013 at 03:47:42PM +0300, Imre Deak wrote:
> On Tue, 2013-07-09 at 14:35 +0200, Daniel Vetter wrote:
> > On Tue, Jul 9, 2013 at 12:40 PM, Imre Deak wrote:
> > > DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
> > > the driver will treat as an invalid value a
In kernel modeset driver mode we're in full control of the chip,
always. So there's no need at all to set mm.suspended in
i915_gem_idle. Hence move that out into the leavevt ioctl. Since
i915_gem_idle doesn't suspend gem any more we can also drop the
re-enabling for KMS in the thaw function.
Also
On Tue, Jul 09, 2013 at 11:45:04AM +0200, Daniel Vetter wrote:
> In kernel modeset driver mode we're in full control of the chip,
> always. So there's no need at all to set mm.suspended in
> i915_gem_idle. Hence move that out into the leavevt ioctl. Since
> i915_gem_idle doesn't suspend gem any mor
On Tue, Jul 09, 2013 at 01:40:37PM +0300, Imre Deak wrote:
> DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
> the driver will treat as an invalid value and use 1.62Gbps instead. Fix
> this by capping to 2.7Gbps anything beyond the DP 1.1 bandwidth range.
Comments inline.
On Tue, 2013-07-09 at 14:35 +0200, Daniel Vetter wrote:
> On Tue, Jul 9, 2013 at 12:40 PM, Imre Deak wrote:
> > DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
> > the driver will treat as an invalid value and use 1.62Gbps instead. Fix
> > this by capping to 2.7Gbps anythin
v2: Bail out if we hit the WARN_ON to avoid fallout later on. Spotted
by Chris Wilson.
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen
Originally I've thought that this fixes up the reset issues on my
gm45, but that was just a red herring due to b0rked testing.
Still I much prefer writing the right values (all other fields are
reserved) instead of potentially dragging gunk around. Hence also
clear the register to 0 after a reset.
On Tue, Jul 9, 2013 at 12:40 PM, Imre Deak wrote:
> DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
> the driver will treat as an invalid value and use 1.62Gbps instead. Fix
> this by capping to 2.7Gbps anything beyond the DP 1.1 bandwidth range.
>
> Signed-off-by: Imre Dea
On Tue, Jul 9, 2013 at 12:05 PM, Chris Wilson wrote:
> On Tue, Jul 09, 2013 at 11:10:13AM +0200, Daniel Vetter wrote:
>> One ugly part is that conceptually I think we want to support dma_buf
>> exporting of stolen memory objects. After all exporting scanout buffers
>> for rendering by the dgpu is
DP 1.2 compatible displays may report a 5.4Gbps maximum bandwidth which
the driver will treat as an invalid value and use 1.62Gbps instead. Fix
this by capping to 2.7Gbps anything beyond the DP 1.1 bandwidth range.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
1 file ch
On Tue, Jul 09, 2013 at 11:10:13AM +0200, Daniel Vetter wrote:
> One ugly part is that conceptually I think we want to support dma_buf
> exporting of stolen memory objects. After all exporting scanout buffers
> for rendering by the dgpu is the prime use-case of dma_buf.
No. prime only exports an i
In kernel modeset driver mode we're in full control of the chip,
always. So there's no need at all to set mm.suspended in
i915_gem_idle. Hence move that out into the leavevt ioctl. Since
i915_gem_idle doesn't suspend gem any more we can also drop the
re-enabling for KMS in the thaw function.
Also
On Tue, Jul 09, 2013 at 10:44:39AM +0200, Daniel Vetter wrote:
> In kernel modeset driver mode we're in full control of the chip,
> always. So there's no need at all to set mm.suspended in
> i915_gem_idle. Hence move that out into the leavevt ioctl. Since
> i915_gem_idle doesn't suspend gem any mor
On Tue, Jul 09, 2013 at 09:46:58AM +0100, Chris Wilson wrote:
> On Mon, Jul 08, 2013 at 10:57:09PM +0200, Daniel Vetter wrote:
> > On Fri, Jul 05, 2013 at 02:42:04PM +0100, Chris Wilson wrote:
> > > Despite being a unified memory architecture (UMA) some bits of memory
> > > are more equal than othe
On Mon, Jul 08, 2013 at 04:38:48PM +0300, Abdiel Janulgue wrote:
> Signed-off-by: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++
> include/uapi/drm/i915_drm.h|1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem
On Mon, Jul 08, 2013 at 10:57:09PM +0200, Daniel Vetter wrote:
> On Fri, Jul 05, 2013 at 02:42:04PM +0100, Chris Wilson wrote:
> > Despite being a unified memory architecture (UMA) some bits of memory
> > are more equal than others. In particular we have the thorny issue of
> > stolen memory, memor
In kernel modeset driver mode we're in full control of the chip,
always. So there's no need at all to set mm.suspended in
i915_gem_idle. Hence move that out into the leavevt ioctl. Since
i915_gem_idle doesn't suspend gem any more we can also drop the
re-enabling for KMS in the thaw function.
Also
Daniel noticed a problem where is we wrote to an object with ring A in
the middle of a very long running batch, then executed a quick batch on
ring B before a batch that reads from the same object, its obj->ring would
now point to ring B, but its last_write_seqno would be still relative to
ring A.
On Mon, Jul 08, 2013 at 11:08:31PM -0700, Ben Widawsky wrote:
> By Daniel's request, to make the PPGTT merging more manageable, here are the
> patches associated with the VM/VMA infrastructure. They are not as well tested
> as the previous series, although I would hope that without actually changin
On Mon, Jul 08, 2013 at 11:08:42PM -0700, Ben Widawsky wrote:
> Probably need to squash whole thing, or just the inactive part, tbd...
>
> Signed-off-by: Ben Widawsky
I agree that we need vma->active, but I'm not sold on removing
obj->active. Atm we have to use-cases for checking obj->active:
-
On Mon, Jul 08, 2013 at 11:08:39PM -0700, Ben Widawsky wrote:
> formerly: "drm/i915: Create VMAs (part 5) - move mm_list"
>
> The mm_list is used for the active/inactive LRUs. Since those LRUs are
> per address space, the link should be per VMx .
>
> Because we'll only ever have 1 VMA before this
On Mon, Jul 08, 2013 at 11:08:38PM -0700, Ben Widawsky wrote:
> formerly: "drm/i915: Create VMAs (part 3.5) - map and fenceable
> tracking"
>
> The map_and_fenceable tracking is per object. GTT mapping, and fences
> only apply to global GTT. As such, object operations which are not
> performed on
60 matches
Mail list logo
