Re: [Intel-gfx] [PATCH] igt: Correct the return value for drm short_buffer read

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Tuesday, December 23, 2014 7:31 PM > To: Zhang, Xiong Y > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] igt: Correct the return value for drm > short_buffer read > > On Tue, Dec 23,

Re: [Intel-gfx] 3.19-rc1 errors when opening LID

Pali, This was probably to either add better power management or enable some new features related to acpi. Can you send me the files they created in kernel 3.19 r1 as I can probably trace it back to the bad commit. Regards Nick On 2014-12-25 03:48 AM, Pali Rohár wrote: > I know how to use git...

Re: [Intel-gfx] [PATCH 7/9] drm/i915: don't alloc/free fbc_work at every update

On Tue, Dec 23, 2014 at 10:35:43AM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > Because there's no need for it. Just use a static structure with a > bool field to tell if it's in use or not. The big advantage here is > not saving kzalloc/kfree calls, it's cutting the ugly "failed to > allo

Re: [Intel-gfx] [PATCH 6/9] drm/i915: add the FBC mutex

On Tue, Dec 23, 2014 at 10:35:42AM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > Make sure we're not gonna have weird races in really weird cases where > a lot of different CRTCs are doing rendering and modesets at the same > time. You are not actually reducing the partial coverage from ot

Re: [Intel-gfx] [PATCH 4/9] drm/i915: don't free the CFB while FBC is enabled

On Tue, Dec 23, 2014 at 10:35:40AM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > Because that is probably not very a good idea: if we used the stolen > memory for more things, there could be a risk that someone would > "allocate" the memory that the HW is still using as the CFB while FBC >

Re: [Intel-gfx] [PATCH 2/9] drm/i915: fix the FBC CFB size tracking

On Tue, Dec 23, 2014 at 10:35:38AM -0200, Paulo Zanoni wrote: > From: Paulo Zanoni > > We have dev_priv->fbc.size which is supposed to contain the compressed > FB size, but it is not: at find_compression_threshold() we try to > overallocate the CFB, but we don't consider this when we assign a > v

Re: [Intel-gfx] 3.19-rc1 errors when opening LID

I know how to use git... first I wanted to report errors because maybe it could be known problem or somebody else can come with quick patch even without bisetcing (like for other problems which I reported). Anyway those acpi devices which are mentioned in log do not exist in 3.13 kernel (I do