== Series Details ==
Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent
forcewake auto-release timeout across kernel configs
URL : https://patchwork.freedesktop.org/series/5424/
State : failure
== Summary ==
Series 5424v1 Series without cover letter
http://patchwork.fre
== Series Details ==
Series: drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->gen (rev2)
URL : https://patchwork.freedesktop.org/series/5407/
State : failure
== Summary ==
CC [M] drivers/net/usb/cdc_ncm.o
CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o
CC [M] drivers/ne
On Thu, 2016-04-07 at 09:20 -0700, Jim Bride wrote:
> On Thu, Apr 07, 2016 at 11:15:38AM +0300, Ander Conselvan De Oliveira wrote:
> > On Wed, 2016-04-06 at 16:00 -0700, Jim Bride wrote:
> > > In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
> > > much needed clean-up was done,
== Series Details ==
Series: Fixes and workarounds for GuC/doorbell setup
URL : https://patchwork.freedesktop.org/series/5426/
State : failure
== Summary ==
Series 5426v1 Fixes and workarounds for GuC/doorbell setup
http://patchwork.freedesktop.org/api/1.0/series/5426/revisions/1/mbox/
Test d
On Thu, 07 Apr 2016, Dave Gordon wrote:
> Since Jani has given us this macro, I thought I'd make use of it by
> converting all existing instances of this construct with a really
> simple little Coccinelle script:
>
> @intel_gen@
> expression E;
> @@
> <...
> - INTEL_INFO(E)->gen
> + IN
== Series Details ==
Series: Minor i915_dp_mst_info output enhancements (rev2)
URL : https://patchwork.freedesktop.org/series/5346/
State : failure
== Summary ==
Series 5346v2 Minor i915_dp_mst_info output enhancements
http://patchwork.freedesktop.org/api/1.0/series/5346/revisions/2/mbox/
Tes
On Fri, Apr 08, 2016 at 07:02:35AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent
> forcewake auto-release timeout across kernel configs
> URL : https://patchwork.freedesktop.org/series/5424/
> State : failure
>
> ==
== Series Details ==
Series: series starting with [v4,1/3] drm/i915: Use i915_vm_to_ppgtt instead of
manual container_of (rev2)
URL : https://patchwork.freedesktop.org/series/5403/
State : failure
== Summary ==
Series 5403v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0
On Thu, 07 Apr 2016, Animesh Manna wrote:
> Guid is changed for bxt platform, so corrected the guid for bxt.
>
> Signed-off-by: Ananth Krishna R
> Signed-off-by: Bharath K Veera
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/intel_acpi.c | 8 +++-
> 1 file changed, 7 insertion
On Thu, 07 Apr 2016, kbuild test robot wrote:
> Hi Jani,
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [cannot apply to v4.6-rc2 next-20160407]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com/0d
A call to i915_gem_alloc_object can only ever return NULL in the event
of an error.
Cc: Joonas Lahtinen
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915
Looks a little neater and ever so slightly reduces the size of the
binary.
Cc: Joonas Lahtinen
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/
We need to kunmap pt_vadrr and not pt itself, otherwise we end up
mapping a bunch of pages without ever unmapping them.
Cc: Joonas Lahtinen
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i91
Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
Cc: Joonas Lahtinen
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.
Much like with the equivalent gen8_alloc_va_range.
Cc: Joonas Lahtinen
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 180db
If we are not in FULL_48BIT_PPGTT mode then we really shouldn't
continue on with our allocations, given that the call to free_dpd would
bail early without freeing everything, thus leaking memory.
Cc: Joonas Lahtinen
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
1
On Thu, 07 Apr 2016, Jim Bride wrote:
> In order to include monitor name information in debugfs
> output we needed to add a function that would extract the
> monitor name from the EDID, and that function needed to
> reside in the file where the rest of the EDID helper
> functions are implemented.
Op 08-04-16 om 01:23 schreef Matt Roper:
> On Wed, Mar 23, 2016 at 02:58:07PM +0100, Maarten Lankhorst wrote:
>> The modeset state checker no longer has full access to the hardware,
>> instead it should only check affected crtc's.
>>
>> Looking for disabled stuff can be checked immediately after al
On Thu, 07 Apr 2016, Jim Bride wrote:
> Add some additional information (input vs. output port, sink associated
> with VC, peer device type, max number of VCs supported) and ensure that
> any embedded '\0' characters in a branch device's devid string are not
> written to debugfs.
>
> v2: Rebase +
== Series Details ==
Series: drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1
URL : https://patchwork.freedesktop.org/series/5438/
State : failure
== Summary ==
Series 5438v1 drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1
http://patchwork.freedesktop.org/api/1.0
== Series Details ==
Series: series starting with [1/6] drm/i915: remove IS_ERR_OR_NULL check
URL : https://patchwork.freedesktop.org/series/5453/
State : failure
== Summary ==
Series 5453v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5453/revisions/1/mbox/
Tes
On pe, 2016-04-08 at 10:32 +0100, Matthew Auld wrote:
> Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
>
> Cc: Joonas Lahtinen
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/d
On Fri, Apr 08, 2016 at 10:32:32AM +0100, Matthew Auld wrote:
> Much like with the equivalent gen8_alloc_va_range.
Just delete the warn and make the allocation paths stronger if you feel
paranoid.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
On Fri, Apr 08, 2016 at 10:32:29AM +0100, Matthew Auld wrote:
> A call to i915_gem_alloc_object can only ever return NULL in the event
> of an error.
We are planning to report the real error back.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
If we want a contiguous mapping of a single page sized object, we can
forgo using vmap() and just use a regular kmap(). Note that this is only
suitable if the desired pgprot_t is compatible.
v2: Use is_vmalloc_addr()
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Dave Gordon
---
drivers/g
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the mapping into the
obj->pages lifetime, then we can reuse an obj->mapping for both and at
the same time couple it into the shrinker. There is a third vmapping
routine in the cmdpa
Now with a new lick of paint, I introduce the cached obj->mapping pointer
for all your contiguous accesses!
Enjoy,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
We only need the struct_mutex to manipulate the pages_pin_count on the
object, we do not need to hold our BKL when freeing the exported
scatterlist.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +---
1 file changed, 1
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-de...@lists.freedes
When called because we have run out of vmap address space, we only need
to recover objects that have vmappings and not all.
v2: Start using is_vmalloc_addr()
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_shrink
After we pin the ringbuffer into the GGTT, all error paths need to unpin
it again. Move this common step into one block, and make the unable to
iomap error code consistent (i.e. treat it as out of memory to avoid
confusing it with a invalid argument).
Signed-off-by: Chris Wilson
Reviewed-by: Tvrt
On Thu, Apr 07, 2016 at 08:22:11PM +0530, Animesh Manna wrote:
> For BXT, display engine can not generate interrupt when in D3.
> On the othen hand S0ix can be achieved without display in D3. So,
other
> Display should not put into D3 for HPD to work and will not
> have any power impact.
>
> Sig
Store the edram capabilities instead of only the size of
edram. This is preparatory patch to allow edram size calculation
based on edram capability bits for gen9+. With gen9 the
edram is behind llc and is a separate entity. With hsw/bdw
it was more of a victim cache for LLC so the name 'eLLC' might
For gen9 onwards, eDRAM is a true memory side cache. So
there is no need to program idi has mask as it is for eLLC
only.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/
With gen9+ the edram capabilities are defined so
that we can calculate the edram (ellc) size accordingly.
Note that there are undefined combinations for some subset of
edram capability bits. Return the closest size for undefined indexes.
Even if we get it wrong with beginning of future gen enablin
The skl I have reported wrong amount in dmesg.
Mika Kuoppala (3):
drm/i915: Don't program eLLC IDI hash mask for gen9+
drm/i915: Store and use edram capabilities
drm/i915: Calculate edram size
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++--
drivers/gpu/drm/i915/i915_drv.h | 7 +++--
dr
On Fri, Apr 08, 2016 at 02:54:03PM +0300, Mika Kuoppala wrote:
> For gen9 onwards, eDRAM is a true memory side cache. So
> there is no need to program idi has mask as it is for eLLC
> only.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 +-
> 1 file changed, 1 inser
On Fri, Apr 08, 2016 at 02:54:04PM +0300, Mika Kuoppala wrote:
> Store the edram capabilities instead of only the size of
> edram. This is preparatory patch to allow edram size calculation
> based on edram capability bits for gen9+. With gen9 the
> edram is behind llc and is a separate entity. With
== Series Details ==
Series: series starting with [v2,1/6] drm/i915/dmabuf: Tighten struct_mutex for
unmap_dma_buf
URL : https://patchwork.freedesktop.org/series/5454/
State : warning
== Summary ==
Series 5454v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5454/
On Fri, Apr 08, 2016 at 12:00:22PM +0300, Jani Nikula wrote:
> On Thu, 07 Apr 2016, Animesh Manna wrote:
> > Guid is changed for bxt platform, so corrected the guid for bxt.
> >
> > Signed-off-by: Ananth Krishna R
> > Signed-off-by: Bharath K Veera
> > Signed-off-by: Animesh Manna
> > ---
> >
== Series Details ==
Series: edram size calculation
URL : https://patchwork.freedesktop.org/series/5457/
State : success
== Summary ==
Series 5457v1 edram size calculation
http://patchwork.freedesktop.org/api/1.0/series/5457/revisions/1/mbox/
Test gem_exec_basic:
Subgroup basic-bsd:
Hi,
On 11-03-16 11:07, Timo Aaltonen wrote:
29.02.2016, 16:47, Hans de Goede kirjoitti:
sna has no meaningfull accel for gen9+, this causes problems with i.e.
apps using XVideo since the sprite XVideo support does not work well
for many apps.
Therefor it is better to just let the xserver fall
From: Ville Syrjälä
We've had problems on several occasions with using the panel type
from the VBT block 40. Usually it seems to be 2, which often
doesn't give us the correct timings for the panel. After some
more digging I found a way to get a panel type via the OpRegion
SWSCI GBDA "Get Panel De
From: Ville Syrjälä
Store the extracted panel_type under dev_priv.vbt instead of keeping
around a static variable for it.
Cc: Rob Kramer
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 13 +
2 files changed, 10 inserti
From: Ville Syrjälä
VBT can only contain 16 panel entries, indexed with the panel_type.
To play it safe we should reject panel_type > 0xf, so that we don't
read past the valid data.
Cc: Rob Kramer
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
1 file changed, 1 ins
From: Tvrtko Ursulin
In GuC mode submitting requests is only putting them into the
GuC queue with the actual submission to hardware following at
some future point. This makes the per engine last context
tracking insufficient for closing the premature context
unpin race.
Instead we need to make r
From: Tvrtko Ursulin
We can use the new pin/lazy unpin API for more performance
in the execlist submission paths.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lr
From: Tvrtko Ursulin
Retired request queue coupled with retired work handler is a scalability
concern on some workloads of which one dramatic example is gem_close_race.
This series depend on i915_gem_object_pin_map series by Chris Wilson.
Brief outline of patches:
1/4) Allow lockless request
From: Chris Wilson
If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unrefe
== Series Details ==
Series: series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT
URL : https://patchwork.freedesktop.org/series/5458/
State : failure
== Summary ==
Series 5458v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5458/revisions/1/mbox/
From: Tvrtko Ursulin
With the previous patch having extended the pinned lifetime of
contexts by referencing the previous context from the current
request until the latter is retired (completed by the GPU),
we can now remove usage of execlist retired queue entirely.
This is because the above now
The function chv_data_lane_soft_reset() uses the lane count to decide
which lanes to set/reset. However, the HDMI code never sets lane count,
since it always uses the four lanes of the phy. Note that before commit
a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming"), all
lanes were r
== Series Details ==
Series: Eliminating the execlist retired request queue
URL : https://patchwork.freedesktop.org/series/5459/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/intel_dpll_mgr.o
CC [M] drivers/gpu/drm/i915/intel_fbc.o
CC [M] drivers/gpu/drm/i915/intel_fifo_un
On Fri, Apr 08, 2016 at 01:56:15PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT
> URL : https://patchwork.freedesktop.org/series/5458/
> State : failure
>
> == Summary ==
>
> Series 5458v1 Series without cover
On Fri, Apr 08, 2016 at 05:06:04PM +0300, Ander Conselvan de Oliveira wrote:
> The function chv_data_lane_soft_reset() uses the lane count to decide
> which lanes to set/reset. However, the HDMI code never sets lane count,
> since it always uses the four lanes of the phy. Note that before commit
>
On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VBT can only contain 16 panel entries, indexed with the panel_type.
> To play it safe we should reject panel_type > 0xf, so that we don't
> read past the valid data.
>
> Cc: Rob Kramer
> Signed-off-by: Ville Syrjä
On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Store the extracted panel_type under dev_priv.vbt instead of keeping
> around a static variable for it.
>
> Cc: Rob Kramer
> Signed-off-by: Ville Syrjälä
Yes please.
Reviewed-by: Jani Nikula
> ---
> drivers/
On Fri, Apr 08, 2016 at 02:54:56PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In GuC mode submitting requests is only putting them into the
> GuC queue with the actual submission to hardware following at
> some future point. This makes the per engine last context
> tracking insuffici
On Fri, Apr 08, 2016 at 02:54:57PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We can use the new pin/lazy unpin API for more performance
> in the execlist submission paths.
The sticking point for me was the ringbuffer and Braswell having to
re-ioremap it every context pin. I hadn't
On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We've had problems on several occasions with using the panel type
> from the VBT block 40. Usually it seems to be 2, which often
> doesn't give us the correct timings for the panel. After some
> more digging I foun
== Series Details ==
Series: drm/i915: Fix CHV data lane soft reset for HDMI
URL : https://patchwork.freedesktop.org/series/5461/
State : warning
== Summary ==
Series 5461v1 drm/i915: Fix CHV data lane soft reset for HDMI
http://patchwork.freedesktop.org/api/1.0/series/5461/revisions/1/mbox/
On Fri, Apr 08, 2016 at 02:54:58PM +0100, Tvrtko Ursulin wrote:
> @@ -615,11 +613,6 @@ static void execlists_context_queue(struct
> drm_i915_gem_request *request)
> struct drm_i915_gem_request *cursor;
> int num_elements = 0;
>
> - if (request->ctx != request->i915->kernel_contex
On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote:
> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We've had problems on several occasions with using the panel type
> > from the VBT block 40. Usually it seems to be 2, which often
> > doesn't gi
The whole file is ignored on CONFIG_ACPI=n.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index c15718b4862a..d5a4cb80273e 100644
--- a/d
On Fri, Apr 08, 2016 at 02:54:55PM +0100, Tvrtko Ursulin wrote:
> From: Chris Wilson
>
> If we move the release of the GEM request (i.e. decoupling it from the
> various lists used for client and context tracking) after it is complete
> (either by the GPU retiring the request, or by the caller ca
On Fri, 08 Apr 2016, Ville Syrjälä wrote:
> On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote:
>> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > We've had problems on several occasions with using the panel type
>> > from the VBT block 40. Us
Set the lane count for HDMI to 4. This will make it easier to
unduplicate CHV phy code.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
i
The code for programming voltage swing and emphasis was duplicated
between DP and HDMI code. Move that to a new file, intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i
The exact same code was used by HDMI and DP encoders, so move it to
intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 30 +-
drivers/gpu/drm/i915/intel_dpio_phy.c | 3
The same logic is used for DP and HDMI so move it to intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 83 +--
drivers/gpu/drm/i915/intel_dpio_phy.c | 81
The function chv_data_lane_soft_reset() was duplicated in DP and HDMI
code. Move it to intel_dpio_phy.c.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 44 ---
drivers/gpu/drm/
There was a lot of duplication between the CHV specific code in DP and
HDMI encoders. This series moves those to a new file: intel_dpio_phy.c.
I don't really know all the details about that code, so couldn't come
up with decent names for the new funcions. Perhaps Ville can suggest
something better
The only difference between the DP and HDMI versions was the lane count.
Since lane_count is now set appropriately for HDMI too, get rid of the
duplication and move this to intel_dpio_phy.c
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/
On Fri, 2016-04-08 at 17:11 +0300, Ville Syrjälä wrote:
> On Fri, Apr 08, 2016 at 05:06:04PM +0300, Ander Conselvan de Oliveira wrote:
> > The function chv_data_lane_soft_reset() uses the lane count to decide
> > which lanes to set/reset. However, the HDMI code never sets lane count,
> > since it a
On Fri, Apr 08, 2016 at 06:01:41PM +0300, Jani Nikula wrote:
> On Fri, 08 Apr 2016, Ville Syrjälä wrote:
> > On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote:
> >> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> >> > From: Ville Syrjälä
> >> >
> >> > We've had problems on s
== Series Details ==
Series: drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI
URL : https://patchwork.freedesktop.org/series/5462/
State : failure
== Summary ==
Series 5462v1 drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI
http://patchwork.freedesktop.org/api/1.0/series/
The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic ve
We are currently missing the color management update condition to
commit planes on crtc.
Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.)
Cc: Maarten Lankhorst
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_displ
The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.
The RCS registers and the L3CC registers are s
== Series Details ==
Series: drm/i915: Set legacy properties when using legacy gamma set IOCTL.
URL : https://patchwork.freedesktop.org/series/5466/
State : failure
== Summary ==
Series 5466v1 drm/i915: Set legacy properties when using legacy gamma set IOCTL.
http://patchwork.freedesktop.org/a
Color management properties are a bit of an odd use case because
they're not marked as atomic properties. Currently we're not updating
the non atomic values so the drm_crtc_state is out of sync with the
values stored in the crtc object.
Cc: Maarten Lankhorst
Cc: Bob Paauwe
Cc:
Signed-off-by: Li
Hi Paul,
Unfortunate that we've been writing the same patch at the same time :(
I think this we've got pretty much the same fix, but it probably needs
to be done at the DRM level, because this can impact other drivers too.
Cheers,
-
Lionel
On 08/04/16 17:26, Bob Paauwe wrote:
The i915 drive
Hi Paul,
Unfortunate that we've been writing the same patch at the same time :(
I think this we've got pretty much the same fix, but it probably needs
to be done at the DRM level, because this can impact other drivers too.
Cheers,
-
Lionel
On 08/04/16 17:26, Bob Paauwe wrote:
The i915 drive
On Fri, Apr 01, 2016 at 04:02:33PM +0300, Imre Deak wrote:
> This has been corrected in BSpec quite some time ago, but we missed it
> somehow. The wrong field definitions resulted in configuring PHY0 with
> an incorrect GRC value.
>
> CC: Arthur J Runyan
> Signed-off-by: Imre Deak
> ---
> drive
On pe, 2016-04-08 at 20:22 +0300, Ville Syrjälä wrote:
> On Fri, Apr 01, 2016 at 04:02:33PM +0300, Imre Deak wrote:
> > This has been corrected in BSpec quite some time ago, but we missed
> > it
> > somehow. The wrong field definitions resulted in configuring PHY0
> > with
> > an incorrect GRC valu
On Fri, 8 Apr 2016 18:21:51 +0100
Lionel Landwerlin wrote:
> Hi Paul,
>
> Unfortunate that we've been writing the same patch at the same time :(
> I think this we've got pretty much the same fix, but it probably needs
> to be done at the DRM level, because this can impact other drivers too.
>
On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote:
> This register is read-only, so we have never actually set
> OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code
> comment about this. I filed a specification update request to clarify
> this there.
Hmm. Interesting.
On Fri, Apr 01, 2016 at 04:02:40PM +0300, Imre Deak wrote:
> For internal APIs passing dev_priv is preferred to reduce indirections,
> so convert over a few DDI PHY, CDCLK helpers.
>
> No functional change.
>
> Signed-off-by: Imre Deak
Acked-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i91
On Fri, Apr 01, 2016 at 04:02:41PM +0300, Imre Deak wrote:
> The power-down step logically belongs to the individual PHY uninit
> sequence so move it there. The only functional change is that we will
> power down now PHY 1 separately before PHY 0 and preserve the other bits
> in the register which
On pe, 2016-04-08 at 21:02 +0300, Ville Syrjälä wrote:
> On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote:
> > This register is read-only, so we have never actually set
> > OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a
> > code
> > comment about this. I filed a specif
On Fri, 8 Apr 2016 18:17:51 +0100
Lionel Landwerlin wrote:
> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the crtc o
On pe, 2016-04-08 at 21:12 +0300, Imre Deak wrote:
> On pe, 2016-04-08 at 21:02 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote:
> > > This register is read-only, so we have never actually set
> > > OCL2_LDOFUSE_PWR_DIS in it as specified by the specificati
On Fri, Apr 01, 2016 at 04:02:44PM +0300, Imre Deak wrote:
> If BIOS has already programmed and enabled a PHY, don't reprogram it as
> that may interfere with the currently active outputs. A follow-up patch
> will add state verification, so we can catch any misconfiguration on
> BIOS's behalf.
>
>
On Fri, Apr 01, 2016 at 04:02:42PM +0300, Imre Deak wrote:
> Power well 1 is managed by the DMC firmware so don't toggle it on-demand
> from the driver. This means we need to follow the BSpec display
> initialization sequence during driver loading and resuming (both system
> and runtime) and enable
> Date: Thu, 7 Apr 2016 21:49:22 +0100
> From: Chris Wilson
>
> On Thu, Apr 07, 2016 at 08:20:15PM +0200, Mark Kettenis wrote:
> > On OpenBSD I implemented idr_alloc() to return random IDs. While the
> > xf86-video-modesetting driver is perfectly happy with this, the
> > xf86-video-intel driver
On Fri, Apr 08, 2016 at 05:44:13PM +0100, Peter Antoine wrote:
> +static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
> + uint32_t *batch,
> + uint32_t dst_handle,
> + uint32_t size,
> +
== Series Details ==
Series: drm/i915: add missing condition for committing planes on crtc
URL : https://patchwork.freedesktop.org/series/5467/
State : failure
== Summary ==
Series 5467v1 drm/i915: add missing condition for committing planes on crtc
http://patchwork.freedesktop.org/api/1.0/ser
== Series Details ==
Series: drm: atomic: fix legacy gamma set helper
URL : https://patchwork.freedesktop.org/series/5471/
State : warning
== Summary ==
Series 5471v1 drm: atomic: fix legacy gamma set helper
http://patchwork.freedesktop.org/api/1.0/series/5471/revisions/1/mbox/
Test gem_exec_
98 matches
Mail list logo
