On Tue, Aug 13, 2013 at 06:09:09PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> In order to transition more of our code over to using a VMA instead of
> an pair - we must have the vma accessible at execbuf time. Up
> until now, we've only had a VMA when actually binding an object.
>
> Th
From: Ben Widawsky
In order to transition more of our code over to using a VMA instead of
an pair - we must have the vma accessible at execbuf time. Up
until now, we've only had a VMA when actually binding an object.
The previous patch helped handle the distinction on bound vs. unbound.
This pa
The conditional is usually a recoverable driver bug, and so WARNing, and
preventing the drm_mm code from doing potential damage (BUG) is
desirable.
This issue was hit and fixed twice while developing the i915 multiple
address space code. The first fix is the patch just before this, and is
hit on a
Cleanup the map and fenceable setting during bind to make more sense,
and not check i915_is_ggtt() 2 unnecessary times
v2: Move the bools into the if block (Chris) - There are ways to tidy
this function (fence calculations for instance) even further, but they
are quite invasive, so I am punting on
VMAs can be created and not bound. One may think of it as lazy cleanup,
and safely gloss over the conditions which manufacture it. In either
case, when the object backing the i915 vma is destroyed, we must cleanup
the vma without stumbling into a bunch of pitfalls that assume the vma
is bound.
NOT
When building kernels for a preliminary hardware target, having to add a
kernel command-line option can prove inconvenient. Add a Kconfig option
that changes the default of this option to 1.
Signed-off-by: Josh Triplett
---
I dropped the indication of the default in the module parameter
documen
The HDMI vendor infoframe can contain a HDMI VIC (as of HDMI 1.4, only
used for 4k formats).
Signed-off-by: Damien Lespiau
---
tools/intel_infoframes.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/tools/intel_infoframes.c b/tools/intel_infoframe
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 28
2 files changed, 30 insertions(+)
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this
This can then be used by DRM drivers to setup their vendor infoframes.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 36
include/drm/drm_edid.h | 4
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/driver
We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.
(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
detai
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.
Cc: Thierry Reding
Cc: Terje Bergström
Cc: linux-te...@vger.kernel.org
Signed-off-by: Damien Lespiau
---
drivers/gpu/host1x/drm/hdmi.c
Provide the programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.
Signed-off-by: Damien Lespiau
---
driver
Just like:
Author: Damien Lespiau
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar data present bits.
Signed-off-by: Damien Lespiau
---
drivers/video/hdmi.c | 5 +++--
include/l
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:
Author: Damien Lespiau
Date: Tue Aug 6 20:3
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 68 ++
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0faa08e..606335f 100644
--- a
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the "4096x2160" string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
re
A few styles issues have crept in here, fix them before touching this
code again.
v2: constify arguments that can be (Ville Syrjälä)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/d
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 5 ++---
include/drm/drm_crtc.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfc7a1b..e014785 10
Following up the first instance of this series:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html
Here is a v2 with Ville's review pass and a few additions:
- Alternate clock modes for 4k resolutions
- HDMI vendor specific infoframe support in drivers/video/hdmi.c
- E
On Tue, Aug 13, 2013 at 04:29:47PM +0300, Jani Nikula wrote:
> This does not include any panel specific sub-encoders yet.
>
> Signed-off-by: Jani Nikula
> Signed-off-by: Shobhit Kumar
Quick bikesheed on how you wire up the get_modes stuff, mostly because I'm
just discussing this on irc with Rob
On Tue, Aug 06, 2013 at 05:43:23PM -0300, Paulo Zanoni wrote:
> 2013/8/6 Daniel Vetter :
> > On Tue, Aug 06, 2013 at 04:33:53PM -0300, Paulo Zanoni wrote:
> >> 2013/8/5 Daniel Vetter :
> >> > On Mon, Aug 05, 2013 at 10:42:08AM -0300, Paulo Zanoni wrote:
> >> >> 2013/8/5 Daniel Vetter :
> >> >> > On
On Tue, Aug 13, 2013 at 01:55:36PM -0700, Ben Widawsky wrote:
> On Mon, Aug 12, 2013 at 04:53:03PM -0700, Ben Widawsky wrote:
> > Cc: Mika Kuoppala
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198
> > Signed-off-by: B
On Tue, Aug 13, 2013 at 10:32:19PM +0200, Daniel Vetter wrote:
> On Tue, Aug 13, 2013 at 06:59:34PM +0100, Chris Wilson wrote:
> > If the CRTC for this modeset is not attached to any encoder, it will be
> > off. In this case, we will need to turn it on as well as update its
> > base. This requires
On Mon, Aug 12, 2013 at 04:53:03PM -0700, Ben Widawsky wrote:
> Cc: Mika Kuoppala
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
>
On Tue, Aug 13, 2013 at 11:55:17AM -0700, Stéphane Marchesin wrote:
> It's basically the same deal as the RC6+ issues on ivy bridge
> except this time with RC6 on sandy bridge. Like last time the
> core of the issue is that the timings don't work 100% with our
> voltage regulator. So from time to t
len);
>>>> >> > return NULL;
>>>> >> >
>>>> >> > --
>>>> >>
>>>> >> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>>>> >> from the top).
>
On Tue, Aug 13, 2013 at 10:32:19PM +0200, Daniel Vetter wrote:
> On Tue, Aug 13, 2013 at 06:59:34PM +0100, Chris Wilson wrote:
> > If the CRTC for this modeset is not attached to any encoder, it will be
> > off. In this case, we will need to turn it on as well as update its
> > base. This requires
On Tue, Aug 13, 2013 at 06:59:34PM +0100, Chris Wilson wrote:
> If the CRTC for this modeset is not attached to any encoder, it will be
> off. In this case, we will need to turn it on as well as update its
> base. This requires a full modeset sequence.
>
> Bugzilla: https://bugs.freedesktop.org/sh
with the known background.
> >> So-to-say 3/4 "blind".
> >
> > That implies that the scanout is always reading from the base of stolen.
> > Can you grab intel_reg_dumper so that I can check what values the
> > transcoder is set to?
> >
> > At the m
can read "Ubuntu 12.04 LTS" with the known background.
>> So-to-say 3/4 "blind".
>
> That implies that the scanout is always reading from the base of stolen.
> Can you grab intel_reg_dumper so that I can check what values the
> transcoder is set to?
>
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
> >> wrote:
> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200,
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> Files attached.
>> >
>> > Can you also please att
It's basically the same deal as the RC6+ issues on ivy bridge
except this time with RC6 on sandy bridge. Like last time the
core of the issue is that the timings don't work 100% with our
voltage regulator. So from time to time, the kernel will print
a warning message about the GPU not getting out o
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> >> Files attached.
> >
> > Can you also please attach a full dmesg so I can check for anything
> > unusual?
> >
On Tue, Aug 13, 2013 at 02:41:15PM -0300, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
>
> On Mon, Aug 12, 2013 at 2:34 PM, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > The machines that fall in this category are the SDVs that have a PCI
> > ID starting with 0x0C. These are very early
On Tue, Aug 13, 2013 at 03:00:59PM -0300, Paulo Zanoni wrote:
> 2013/8/13 Chris Wilson :
> > After computing the stage changes for the set_config, record those in
> > the debug log.
> >
> > Signed-off-by: Chris Wilson
>
> I've already written different versions of this patch when debugging
> thin
On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote:
>> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson
>> > wrote:
>> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek w
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
> Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
2013/8/13 Chris Wilson :
> After computing the stage changes for the set_config, record those in
> the debug log.
>
> Signed-off-by: Chris Wilson
I've already written different versions of this patch when debugging
things in the past. Definitely useful.
Reviewed-by: Paulo Zanoni
> ---
> drive
If the CRTC for this modeset is not attached to any encoder, it will be
off. In this case, we will need to turn it on as well as update its
base. This requires a full modeset sequence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Signed-off-by: Chris Wilson
Cc: Rodrigo Vivi
---
After computing the stage changes for the set_config, record those in
the debug log.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a
Reviewed-by: Rodrigo Vivi
On Mon, Aug 12, 2013 at 2:34 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The machines that fall in this category are the SDVs that have a PCI
> ID starting with 0x0C. These are very early pre-production machines
> and may not fully work. Other Haswell SDVs have PC
On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote:
> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson
> > wrote:
> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek
>
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson
> wrote:
>> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
>>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote:
>>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nig
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote:
>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
>> >
>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is t
On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote:
> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly:
> >
> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit
> > commit 5456fe3882812aba251886e36fe55
gt;>> Did that make a difference? It shouldn't if the error is occuring before
>>>>> X even starts...
>>>>
>>>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>>>> Xorg.log :-).
>>>>
>&g
Sedat -
>>>>>
>>>>> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime.
>>>>
>>>> Did that make a difference? It shouldn't if the error is occuring before
>>>> X even starts...
>>>
>>> NO, was jus
make a difference? It shouldn't if the error is occuring before
>>> X even starts...
>>
>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my
>> Xorg.log :-).
>>
>> As said logging out of Unity-2D and entering LightDM greeter
" (HD-3000 was new to me) in my
> Xorg.log :-).
>
> As said logging out of Unity-2D and entering LightDM greeter - screen is fine.
> Starting again a Unity-2D session - no screen corruption, too.
>
> - Sedat -
Some more testing:
[1] With my X stack:
FIRST BAD: next-20130812
L
On Tue, Aug 13, 2013 at 02:39:55PM +0100, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 10:36:04AM -0300, Rodrigo Vivi wrote:
> > applied to experimental drm-intel-collector.
> >
> > drivers/gpu/drm/i915/i915_gem.c: In function ‘__wait_seqno’:
> > drivers/gpu/drm/i915/i915_gem.c:1033:20: warning:
On Tue, Aug 13, 2013 at 10:36:04AM -0300, Rodrigo Vivi wrote:
> applied to experimental drm-intel-collector.
>
> drivers/gpu/drm/i915/i915_gem.c: In function ‘__wait_seqno’:
> drivers/gpu/drm/i915/i915_gem.c:1033:20: warning: ‘timeout_jiffies’ may be
> used
> +uninitialized in this function
Dumb
applied to experimental drm-intel-collector.
drivers/gpu/drm/i915/i915_gem.c: In function ‘__wait_seqno’:
drivers/gpu/drm/i915/i915_gem.c:1033:20: warning: ‘timeout_jiffies’ may be used
+uninitialized in this function
On Tue, Aug 6, 2013 at 10:03 PM, Chris Wilson wrote:
> Rather than continue
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/auo_dsi_display.c | 182
drivers/gpu/drm/i915/intel_dsi.c |5 +
drivers/gpu/drm/i915/intel_dsi.h
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e3ca335..7edb9c0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/
From: Shobhit Kumar
Initial parsing of the VBT MIPI block. For now, just store the panel id
if found.
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/intel_bios.c | 16 +++
drivers/gpu/drm/i915/inte
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: ymohanma
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_
DPLL is not needed for DSI
Signed-off-by: Jani Nikula
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_display.c | 48 --
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/int
From: ymohanma
Signed-off-by: ymohanma
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_reg.h | 10 ++
drivers/gpu/drm/i915/intel_display.c |2 +
drivers/gpu/drm/i915/intel_dsi.c |5 +
drive
This does not include any panel specific sub-encoders yet.
Signed-off-by: Jani Nikula
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_dsi.c | 548 ++
3 files ch
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_dsi_cmd.c | 442 ++
drivers/gpu/drm/i915/intel_dsi_cmd.h | 109 +
3 files changed, 552 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_ds
The sub-encoder model is copied from DVO.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.h | 99 ++
1 file changed, 99 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dsi.h
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/
Signed-off-by: Jani Nikula
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_drv.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 01455aa..a31abc6 100644
--- a/drivers/gpu/drm/i915/in
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a30e876..aced53a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -297
Add definitions for VLV MIPI DSI registers.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 409 +++
1 file changed, 409 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index aced53a..32e32b6 1006
For GPIO NC, CCK, CCU, and GPS CORE.
Signed-off-by: Jani Nikula
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/i915_drv.h |8 +
drivers/gpu/drm/i915/i915_reg.h |4 +++
drivers/gpu/drm/i915/intel_sideband.c | 56 +
3 files changed,
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..8768c5f 100644
---
Hi all -
This series adds rudimentary MIPI DSI support to Baytrail. It's been
built around the idea of panel specific sub-encoders, similar to the DVO
support we have. This work is by no means complete; there are plenty of
rough edges, but it should be a somewhat sane start to build upon.
I'm awa
On Tue, Aug 13, 2013 at 01:20:13PM +0100, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 03:12:59PM +0300, Ville Syrjälä wrote:
> > Thinking about this stuff a bit, I think I actually came up with a
> > scenario where we would currently fail to invalidate the CPU cache
> > between non-snooped GPU/GT
On Tue, Aug 13, 2013 at 03:12:59PM +0300, Ville Syrjälä wrote:
> Thinking about this stuff a bit, I think I actually came up with a
> scenario where we would currently fail to invalidate the CPU cache
> between non-snooped GPU/GTT access and CPU access:
>
> 1. make bo non-snooped w/ pin_display=tr
On Mon, Aug 12, 2013 at 11:46:17AM +0100, Chris Wilson wrote:
> By our earlier reckoning, move from a snooped/llc setting to an uncached
> setting, leaves the CPU cache in a consistent state irrespective of our
> domain tracking - so we can forgo the warning about the lack of
> invalidation. Simila
On Tue, Aug 13, 2013 at 09:54:48AM +0200, Daniel Vetter wrote:
> On Mon, Aug 12, 2013 at 11:46:17AM +0100, Chris Wilson wrote:
> > By our earlier reckoning, move from a snooped/llc setting to an uncached
> > setting, leaves the CPU cache in a consistent state irrespective of our
> > domain tracking
Hi,
feel free to add...
Reported -by: Sedat Dilek (against
next-20130813 see [1])
Tested-by: Sedat Dilek
Thanks.
Regards,
- Sedat -
[1] http://lists.freedesktop.org/archives/intel-gfx/2013-August/031725.html
___
Intel-gfx mailing list
Intel-gfx
On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> >> After a logout from my "BROKEN" Unity-2D sessio
On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson
> wrote:
> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> >> After a logout from my "BROKEN" Unity-2D session - the login-screen
> >> for LightDM seems to be OK.
> >> Th
On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
>> After a logout from my "BROKEN" Unity-2D session - the login-screen
>> for LightDM seems to be OK.
>> Then entering my Unity-2D desktop is OK - no screen corruptions.
>
> What ha
On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
> After a logout from my "BROKEN" Unity-2D session - the login-screen
> for LightDM seems to be OK.
> Then entering my Unity-2D desktop is OK - no screen corruptions.
What hardware and display do you have?
-Chris
--
Chris Wilson, Intel
On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
>> Hi,
>>
>> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
>> top, it's simply black.
>> I can estimate the UR
On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote:
> Hi,
>
> with today's next-20130813 I cannot see 1/10 of my desktop-screen's
> top, it's simply black.
> I can estimate the URL line in Firefox (or open a new tab blindly and
> get a known URL from my
;
>>> The akpm tree gained a conflict against the staging tree.
>>>
>>>
>>>
>>
>> Hi,
>>
>> with today's next-20130813 I cannot see 1/10 of my desktop-sc
ct against the staging tree.
>
> The akpm tree gained a conflict against the staging tree.
>
> ----
>
Hi,
with today's next-20130813 I cannot see 1/10 of my desktop-screen's
top, it's simply black
On Mon, Aug 12, 2013 at 10:33:37AM -0700, Stéphane Marchesin wrote:
> On Fri, Aug 9, 2013 at 9:55 PM, Ben Widawsky wrote:
> > On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
> >> This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> >> (drm/i915: load boot cont
On Mon, Aug 12, 2013 at 11:46:17AM +0100, Chris Wilson wrote:
> By our earlier reckoning, move from a snooped/llc setting to an uncached
> setting, leaves the CPU cache in a consistent state irrespective of our
> domain tracking - so we can forgo the warning about the lack of
> invalidation. Simila
On Mon, Aug 12, 2013 at 04:53:03PM -0700, Ben Widawsky wrote:
> Cc: Mika Kuoppala
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198
> Signed-off-by: Ben Widawsky
Tested-by: lu hua (both bug reports)
Please pimp the comm
On Mon, Aug 12, 2013 at 05:34:17PM -0700, Ben Widawsky wrote:
> Cleanup the map and fenceable setting during bind to make more sense,
> and not check i915_is_ggtt() 2 unnecessary times
>
> v2: Move the bools into the if block (Chris) - There are ways to tidy
> this function (fence calculations for
86 matches
Mail list logo
