Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7199
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
The adj_start calculation for DRM_MM_CREATE_TOP should happen after
mm->color_adjust. There was an inconsistency between
drm_mm_insert_helper_range
and drm_mm_insert_helper, as the later was already updating after
color_adjust.
Didn't spot it before, as color_adjust is only done in systems without
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7198
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
I'm still continuing to experience video lockups though not quite as
frequent as before. The most recent was 12 August. I'm running the
kernel as shown in my sig. I've attached my Xorg.0.log. I'm able to SSH
into my desktop from my tablet and running
cat /sys/class/drm/card0/error shows 'no error s
On Sat, Aug 15, 2015 at 02:56:57PM +1000, Dave Airlie wrote:
> On 11 August 2015 at 17:54, Maarten Lankhorst
> wrote:
> > The port is removed synchronously, but the connector delayed.
> > This causes a use after free which can cause a kernel BUG with
> > slug_debug=FPZU. This is fixed by freeing t
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7184
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
On 08/04/2015 02:29 PM, Toralf Förster wrote:
> On 08/02/2015 09:43 AM, Pavel Machek wrote:
>> Any chance to bisect it?
> Did it.
>
> FWIW: the mentioned commit was introduced between 3.18 and 3.19.
> But my system (hardened 64 bit Gentoo) did not suffer from it till version
> 4.0.8.
> The harden
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7158
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7158
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7156
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
On Fri, Aug 14, 2015 at 06:34:18PM -0300, Paulo Zanoni wrote:
> The spec says we just can't use it.
But what about when we inherit a framebuffer at that address?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Int
On Fri, Aug 14, 2015 at 06:34:13PM -0300, Paulo Zanoni wrote:
> The FBC hardware for these platforms doesn't have access to the
> bios_reserved range, so it always assumes the maximum (8mb) is used.
> So avoid this range while allocating.
>
> This solves a bunch of FIFO underruns that happen if yo
On Fri, Aug 14, 2015 at 06:34:20PM -0300, Paulo Zanoni wrote:
> This reverts commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb.
>
> Technology has evolved and now we have eDP panels with 3200x1800
> resolution. In the meantime, the BIOS guys didn't change the default
> 32mb for stolen memory. And we
On Fri, Aug 14, 2015 at 06:34:12PM -0300, Paulo Zanoni wrote:
> If we want to try to enable FBC by default on any platform we need to
> be on the safe side and disable it in case we get an underrun while
> FBC is enabled on the corresponding pipe. We currently already have
> other reasons for FIFO
Hello,
with the latest commit batch to drm-intel-nightly from friday night, my lenovo
t440p again starts to oops as soon as I attach it to the docking station. this
image http://imgur.com/mxtLaxW shows the oops trace.
Can someone with a T440/540 and docking station confirm this?
Regards
Dieter
15 matches
Mail list logo
