== Summary ==
Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly:
2016y-01m-19d-19h-38m-52s UTC integration manifest
Test drv_module_reload_basic:
dmesg-warn -> PASS (snb-x220t)
dmesg-warn -> PASS (snb-dellxps)
dmesg-wa
On 01/20/2016 01:50 AM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 09:00:40PM +0530, Kumar, Shobhit wrote:
On 01/19/2016 08:45 PM, Shobhit Kumar wrote:
INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get and
pwm_get calls in i915. Add a retry to give time for the INTEL_SOC_PMIC
t
== Summary ==
Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly:
2016y-01m-19d-19h-38m-52s UTC integration manifest
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS (ilk-hp8440p)
Subgroup read-crc-pipe-b-frame-sequence:
Currently CI servers still push test results to internal servers, and
that's why we right now can't document this all properly in public.
Meanwhile just add a basic tl;dr section as a placeholder.
Acked-by: Jani Nikula
Signed-off-by: Daniel Vetter
---
drm-intel.rst | 16
1 file
On Tue, Jan 19, 2016 at 02:37:55PM -0800, Kumar, Abhay wrote:
>
>
> On 1/12/2016 5:57 PM, Kumar, Abhay wrote:
> >From: Abhay Kumar
> >
> >Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
> >if this time is already spent in suspend/poweron time.
> >
> >v2: Use CLOCK_BOOTTI
On Wed, Jan 20, 2016 at 02:08:06PM +0530, Kumar, Shobhit wrote:
>
> On 01/20/2016 01:50 AM, Daniel Vetter wrote:
> >On Tue, Jan 19, 2016 at 09:00:40PM +0530, Kumar, Shobhit wrote:
> >>On 01/19/2016 08:45 PM, Shobhit Kumar wrote:
> >>>INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get
On Wed, Jan 20, 2016 at 08:20:50AM -, Patchwork wrote:
> == Summary ==
>
> Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly:
> 2016y-01m-19d-19h-38m-52s UTC integration manifest
>
> Test drv_module_reload_basic:
> dmesg-warn -> PASS (snb-x220t)
>
On Tue, Jan 19, 2016 at 11:43:04AM -0800, Matt Roper wrote:
> This reverts commit 396e33ae204f52abebec9e578f44c749305500f4.
>
> This commit was triggering some FIFO underrun warnings on ILK-IVB
> platforms (but surprisingly not on HSW/BDW that share more or less the
> same codepaths). These under
On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
> intel_dp_detect() is called for not just detection but
> during modes enumeration as well. Repeating the whole
> sequence during each of these calls is wasteful and
> time consuming.
> This patch moves probing for panel, DPCD read et
On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
> Current DP detection has DPCD operations split across
> intel_dp_hpd_pulse and intel_dp_detect which contains
> duplicates as well. Also intel_dp_detect is called
> during modes enumeration as well which will result
> in multiple dpc
On Tue, Jan 19, 2016 at 09:50:08PM +0200, Mika Kuoppala wrote:
> Sometimes we get dmesg warnings claiming that DC6 was already
> enabled prior to our enabling. Investigations using readback of
> the written dc state value indicate that sometimes when we disable
> the dc6, the write doesn't stick, o
On Tue, 19 Jan 2016, Daniel Vetter wrote:
> On Mon, Jan 18, 2016 at 09:19:48AM +0200, Jani Nikula wrote:
>> Without the DOC:, kernel-doc confuses the documentation block for
>> something else.
>>
>> Signed-off-by: Jani Nikula
>
> Hm, we don't pull intel_pm.c into the gpu.tmpl at all, which means
On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
> When created originally intel_dp_check_link_status()
> was supposed to handle only link training for short
> pulse but has grown into handler for short pulse itself.
> This patch cleans up this function by splitting it into
> two hal
Chris Wilson writes:
> On Tue, Jan 19, 2016 at 09:50:08PM +0200, Mika Kuoppala wrote:
>> Sometimes we get dmesg warnings claiming that DC6 was already
>> enabled prior to our enabling. Investigations using readback of
>> the written dc state value indicate that sometimes when we disable
>> the dc
Ville Syrjälä writes:
> On Tue, Jan 19, 2016 at 09:50:09PM +0200, Mika Kuoppala wrote:
>> If we have driver failure in our power well and/or dc
>> state keeping, we might try to reset without powers.
>>
>> Evidence shows that resetting the chip with dc6 enabled
>> don't lead to desired results.
Hi,
On 19/01/16 19:02, Dave Gordon wrote:
There are a number of places where the driver needs a request, but isn't
working on behalf of any specific user or in a specific context. At
present, we associate them with the per-engine default context. A future
patch will abolish those per-engine con
On 01/20/2016 02:30 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 02:37:55PM -0800, Kumar, Abhay wrote:
On 1/12/2016 5:57 PM, Kumar, Abhay wrote:
From: Abhay Kumar
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron ti
Just include the RC6 paragraph and functions from intel_pm.c, nothing
fancy.
Signed-off-by: Jani Nikula
---
Documentation/DocBook/gpu.tmpl | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 351e801cead9..c2351dd51694 100
Op 18-01-16 om 18:20 schreef Daniel Vetter:
> On Mon, Jan 18, 2016 at 04:49:06PM +0100, Julia Lawall wrote:
>> List_for_each entry binds its first argument to an offset from the list
>> pointer, so this should not be NULL.
>>
>> Generated by: scripts/coccinelle/iterators/itnull.cocci
>>
>> Signed-o
On Wed, 2015-12-09 at 17:29 +0530, Deepak M wrote:
> For broxton dual link Z-inversion overlap field is present
> in MIPI_CTRL register unlike the other platforms, hence
> setting the same in this patch.
>
Tested-by: Mika Kahola
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/i915_reg.h
On 19/01/16 20:22, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 03:25:17PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Having this on stack triggers the -Wframe-larger-than=1024 and
is not nice to put such big things on the kernel stack anyway.
This required a little bit of refactoring
On Wed, Jan 20, 2016 at 11:49:51AM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Tue, Jan 19, 2016 at 09:50:08PM +0200, Mika Kuoppala wrote:
> >> Sometimes we get dmesg warnings claiming that DC6 was already
> >> enabled prior to our enabling. Investigations using readback of
> >> t
On Wed, Jan 20, 2016 at 09:56:10AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 19/01/16 19:02, Dave Gordon wrote:
> >There are a number of places where the driver needs a request, but isn't
> >working on behalf of any specific user or in a specific context. At
> >present, we associate them with t
On 1/11/2016 6:02 PM, Chris Wilson wrote:
On Sat, Jan 09, 2016 at 05:01:30PM +0530, akash.g...@intel.com wrote:
+static void* mmap_bo(int fd, uint32_t handle, uint64_t size)
+{
+ uint32_t *ptr = gem_mmap__cpu(fd, handle, 0, size, PROT_READ);
+ gem_set_domain(fd, handle, I915_GEM_DO
The capability to detect unclaimed register access was
recently introduced for vlv/chv platforms. Apparently
there are plenty of unclaimed access on these platforms,
resulting in new dmesg warns. But as we are trying to form
a beachhead for CI/Bat, all new warns are adding to the
noise and thus not
Hi Jani,
[auto build test WARNING on v4.4-rc8]
[also build test WARNING on next-20160120]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-doc-add-power-management-section
On Wed, Jan 20, 2016 at 12:03:37PM +0200, Jani Nikula wrote:
> Just include the RC6 paragraph and functions from intel_pm.c, nothing
> fancy.
>
> Signed-off-by: Jani Nikula
Assuming kernel CI doesn't complain about new warnings when we do this.
Reviewed-by: Daniel Vetter
> ---
> Documentation
On Wed, Jan 20, 2016 at 12:32:23PM +0200, Mika Kuoppala wrote:
> The capability to detect unclaimed register access was
> recently introduced for vlv/chv platforms. Apparently
> there are plenty of unclaimed access on these platforms,
> resulting in new dmesg warns. But as we are trying to form
> a
On Tue, Jan 19, 2016 at 09:50:09PM +0200, Mika Kuoppala wrote:
> If we have driver failure in our power well and/or dc
> state keeping, we might try to reset without powers.
>
> Evidence shows that resetting the chip with dc6 enabled
> don't lead to desired results. The dmc kept it's enabled
> dc6
On Fri, 2015-12-04 at 19:47 +0530, Deepak M wrote:
> From: Gaurav K Singh
>
> After sending SHUTDOWN or TURN ON packet,check the DPI
> FIFO empty status.
>
Tested-by: Mika Kahola
> Signed-off-by: Gaurav K Singh
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 6 ++
> 1 file changed, 6 insertion
On Wed, Jan 20, 2016 at 08:18:03AM +0100, Maarten Lankhorst wrote:
> Op 19-01-16 om 20:22 schreef Ville Syrjälä:
> > On Mon, Jan 18, 2016 at 11:23:21AM +0100, Maarten Lankhorst wrote:
> >> Op 14-01-16 om 17:52 schreef Ville Syrjälä:
> >>> On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrot
Daniel Vetter writes:
> We've had this since forever, and's randomly reporting issues and as
> such causing piles&piles of CI noise. Mika is working on proper debug
> infrastructure for this, and on fixing this properly.
>
> Meanwhile make CI more useful for everyone else.
>
> Cc: Mika Kuoppala
== Summary ==
Built on c783b5011894af49992f2095cb2848b6cf8ebc57 drm-intel-nightly:
2016y-01m-20d-10h-12m-03s UTC integration manifest
Test gem_sync:
Subgroup basic-render:
pass -> DMESG-FAIL (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
Em Ter, 2016-01-19 às 22:21 +, Vivi, Rodrigo escreveu:
> On Tue, 2016-01-19 at 17:46 +, Zanoni, Paulo R wrote:
> > Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu:
> > > When we stop the sink CRC calculation we wait a while until the
> > > counter
> > > is reset to zero and return
== Summary ==
Built on c783b5011894af49992f2095cb2848b6cf8ebc57 drm-intel-nightly:
2016y-01m-20d-10h-12m-03s UTC integration manifest
Test gem_sync:
Subgroup basic-render:
pass -> DMESG-FAIL (bdw-nuci7)
Test kms_force_connector_basic:
Subgroup force-connecto
On Wed, Jan 20, 2016 at 12:37:39PM +, Zanoni, Paulo R wrote:
> Em Ter, 2016-01-19 às 22:21 +, Vivi, Rodrigo escreveu:
> > On Tue, 2016-01-19 at 17:46 +, Zanoni, Paulo R wrote:
> > > Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu:
> > > > When we stop the sink CRC calculation w
On Wed, Jan 20, 2016 at 03:29:00PM +0530, Kumar, Shobhit wrote:
> On 01/20/2016 02:30 PM, Daniel Vetter wrote:
> > On Tue, Jan 19, 2016 at 02:37:55PM -0800, Kumar, Abhay wrote:
> >>
> >>
> >> On 1/12/2016 5:57 PM, Kumar, Abhay wrote:
> >>> From: Abhay Kumar
> >>>
> >>> Make resume/on codepath not
Hi,
Comments below this pre text.
Many of the comments are related to the indent and style of the code.
That stuff is important to fix for future maintainability. In order for
the future review to be more effective, I'd like to next see a v5 of
the series where the code quality concerns have been
From: Tvrtko Ursulin
Will simplify the following fix and sounds logical.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Nick Hoath
---
drivers/gpu/drm/i915/intel_lrc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.
From: Tvrtko Ursulin
In GuC mode LRC pinning lifetime depends exclusively on the
request liftime. Since that is terminated by the seqno update
that opens up a race condition between GPU finishing writing
out the context image and the driver unpinning the LRC.
To extend the LRC lifetime we will e
From: Tvrtko Ursulin
Previously intel_lr_context_(un)pin were operating on requests
which is in conflict with their names.
If we make them take a context and an engine, it makes the names
make more sense and it also makes future fixes possible.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
C
From: Chris Wilson
Broadwell and later currently use the same unordered command sequence to
update the seqno in the HWS status page and then assert the user
interrupt. We should apply the w/a from legacy (where we do an mmio
read to delay the seqno read after the interrupt), but this is not
enoug
== Summary ==
Built on a84f26193f3fd63600b2f4c280c0046e4a191322 drm-intel-nightly:
2016y-01m-20d-12h-56m-53s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
dmesg-warn -> PASS (skl-
On Wed, Jan 20, 2016 at 01:40:56PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Will simplify the following fix and sounds logical.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Nick Hoath
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 2 ++
> 1 file changed, 2 insertions
On Wed, Jan 20, 2016 at 01:40:57PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In GuC mode LRC pinning lifetime depends exclusively on the
> request liftime. Since that is terminated by the seqno update
> that opens up a race condition between GPU finishing writing
> out the context i
On Wed, Jan 20, 2016 at 01:40:55PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Previously intel_lr_context_(un)pin were operating on requests
> which is in conflict with their names.
>
> If we make them take a context and an engine, it makes the names
> make more sense and it also ma
On Tue, Jan 19, 2016 at 09:28:03PM +0100, Daniel Vetter wrote:
> On Tue, Jan 19, 2016 at 06:23:17PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > In this atomic age, we can't trust the plane->fb pointer anymore.
> > It might get update too late. Instead we are suppos
On 20/01/16 13:55, Chris Wilson wrote:
On Wed, Jan 20, 2016 at 01:40:57PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In GuC mode LRC pinning lifetime depends exclusively on the
request liftime. Since that is terminated by the seqno update
that opens up a race condition between GPU fini
Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu:
> Current platforms that support PSR on other port than A only support
> link
> standby mode.
>
> The logic here was wrong since 'commit 89251b177b ("drm/i915: PSR:
> deprecate link_standby support for core platforms.")
What's wrong/broken
On Wed, Jan 20, 2016 at 02:06:43PM +, Tvrtko Ursulin wrote:
>
> On 20/01/16 13:55, Chris Wilson wrote:
> >On Wed, Jan 20, 2016 at 01:40:57PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>In GuC mode LRC pinning lifetime depends exclusively on the
> >>request liftime. Since th
On 20/01/2016 14:06, Tvrtko Ursulin wrote:
On 20/01/16 13:55, Chris Wilson wrote:
On Wed, Jan 20, 2016 at 01:40:57PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In GuC mode LRC pinning lifetime depends exclusively on the
request liftime. Since that is terminated by the seqno update
tha
On SKL and KBL we can have pipe A/B/C disabled by fuse settings. The
pipes must be fused in descending order (e.g. C, B+C, A+B+C). We simply
decrease info->num_pipes if we find a valid fused out config.
v2: Don't store the pipe disabled mask in device info (Damien)
v3: Don't check FUSE_STRAP regi
The patch summary is now too long. Just use the one from patch 5 ("read
sink_count dpcd always"). You can mention in the commit message that the value
of sink count is now stored in struct intel_dp, but that doesn't need to be in
the summary.
One more comment below.
On Tue, 2016-01-19 at 16:07 +05
On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
> This patch checks for changes in sink count between short pulse
> hpds and forces full detect when there is a change.
>
> This will allow both detection of hotplug and unplug of panels
> through dongles that give only short pulse fo
== Summary ==
Built on e9545b0b60b73d8be3d41048af5b8f2c1e2fc4c1 drm-intel-nightly:
2016y-01m-20d-13h-55m-37s UTC integration manifest
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS (skl-i5k-2)
bdw-nuci7total:143 pass:1
From: Tvrtko Ursulin
In GuC mode LRC pinning lifetime depends exclusively on the
request liftime. Since that is terminated by the seqno update
that opens up a race condition between GPU finishing writing
out the context image and the driver unpinning the LRC.
To extend the LRC lifetime we will e
Op 15-01-16 om 10:06 schreef Marius Vlad:
> So far, we had only COMMIT_UNIVERSAL and COMMIT_LEGACY, using
> drmModeSetPlane()/drmSetCrtc(). This patch adds COMMIT_ATOMIC
> to igt_display_commit2() that makes use of drmModeAtomicCommit().
>
> Signed-off-by: Marius Vlad
> ---
> lib/igt_kms.c | 190
Hi,
On 20 January 2016 at 14:52, Maarten Lankhorst
wrote:
> Op 15-01-16 om 10:06 schreef Marius Vlad:
>> + /* populate plane req */
>> + igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID,
>> crtc_id);
> Set crtc_id and fb_id to 0 when disabling plane.
>> +
On Wed, Jan 20, 2016 at 02:50:47PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In GuC mode LRC pinning lifetime depends exclusively on the
> request liftime. Since that is terminated by the seqno update
> that opens up a race condition between GPU finishing writing
> out the context i
== Summary ==
Built on e9545b0b60b73d8be3d41048af5b8f2c1e2fc4c1 drm-intel-nightly:
2016y-01m-20d-13h-55m-37s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-ultra) UNSTABLE
Test gem_sync:
Subgroup basic-render:
Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu:
> Link standby support has been deprecated with 'commit 89251b177
> ("drm/i915: PSR: deprecate link_standby support for core
> platforms.")'
>
> The reason for that is that main link in full off offers more power
> savings and on HSW and BD
Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu:
> Unfortunately we don't know all panels and platforms out there and we
> found internal prototypes without VBT proper set but where only
> link in standby worked well.
>
> So, before enable PSR by default let's instrument the PSR parameter
On 20/01/16 07:49, Patchwork wrote:
== Summary ==
Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly:
2016y-01m-19d-19h-38m-52s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-nuci7) UNSTABLE
http
On Fri, Jan 08, 2016 at 03:03:53PM +, Peter Antoine wrote:
> This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory
> spaces do not overlap.
>
> Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
> Signed-off-by: Peter Antoine
> ---
> drivers/gpu/drm/i915/i915_guc_reg.h
No functional changes.
While I'm here, let's also rename gem_uses_aliasing_ppgtt (since it's
being used to indicate if we are using ANY kind of ppgtt) and introduce
gem_uses_full_ppgtt and gem_uses_full_48b_ppgtt to drop some unnecessary
code from tests that were previously calling getparam directl
We can move it from softpin test into lib, and since softpin support is
highly unlikely to go away in-between getparam ioctl calls, let's just
do a single call and store the value.
Signed-off-by: Michał Winiarski
---
lib/ioctl_wrappers.c | 29 +
lib/ioctl_wrappers.h |
When the memory backing the userptr object is freed by the user, but the
BO itself is not closed, it's possible to trigger recursive deadlock
caused by operations done on different BO mapped in that region.
Testcases are simulating such behaviour by using MAP_FIXED mmap flag.
v2: Grammar/naming fi
Hi Chris,
These tests were developed for testing buffered SVM(using userptr and soft
pinning API). I think Dan wanted me to rename the tests to gem_softpin, since
they were being checked in as tests which validated the softpin kernel patches.
Can we rename the existing tests to gem_buffered_
From: Ville Syrjälä
Using 'unsigned long' for ggtt offsets doesn't make much sense. Use
'u32' instead since we've not yet seen a >4GiB ggtt.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 ++
drivers/gpu/drm/i915/intel_drv.h | 12 ++--
From: Ville Syrjälä
Pass stride in addition to width and height to rotate_pages(). For now
width and stride are the same, but once framebuffer offsets enter the
scene that may no longer be the case.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +--
1 file change
From: Ville Syrjälä
intel_rotate_fb_obj_pages() doens't need the entire gtt view, just the
rotation info suffices.
Signed-off-by: Ville Syrjälä
---
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
From: Ville Syrjälä
This is the new version of [1]. I already sent a bunch of the earlir
patches as separate prep series [2] and [3]. [2] was already pushed
fully, but most of the patches from [3] didn't get reviewed yet, so
I've included them in this series so that the CI machinery might
actuall
From: Ville Syrjälä
Also rename 'rotation_info' to 'rotated' to match the view type exactly,
this should avoid confusion which union members is valid for each view
type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
From: Ville Syrjälä
Add a few helpers to get the dimensions of the chroma plane(s).
v2: Add kernel-doc (Daniel)
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
include/drm/drm_crtc.h | 30 ++
1 file changed, 30 inser
From: Ville Syrjälä
The fb_modifiers and cpp arguments passed to intel_tile_width() in
intel_fill_fb_ggtt_view() got accidentally swapped around. I'm pretty
sure I fixed this already, but could be I lost the fix accidentally
during some rebases or something. Anyway, fix it up for real.
Fixes: d9
From: Ville Syrjälä
Throw out a bunch of unnecessary stuff from struct intel_rotation_info,
and pull most of the remaining stuff to live under an array of
per-color plane sub-structures.
What still remains outside the sub-structure will be reorgranized later
as well, but that requires more work
From: Ville Syrjälä
Instead of repopulatin the rotation_info struct for the fb every time
we try to use the fb, we can just populate it once when creating the fb,
and later we can just copy the pre-populate struct into the gtt_view.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_d
From: Ville Syrjälä
intel_compute_page_offsets() gets passed a bunch of the framebuffer
metadate sepearately. Just pass the framebuffer itself to make life
simpler for the caller, and make it less likely they would make a
mistake in the order of the arguments (as most as just unsigned ints and
su
From: Ville Syrjälä
intel_compute_page_offset() can dig up the correct pitch from the fb
itself, no need for the caller to pass it in.
A bit of extra care is needed for the lower level
_intel_compute_page_offset() since that one gets called before the
rotated pitch under intel_fb is populated. N
From: Ville Syrjälä
SKL+ needs >4K alignment for tiled surfaces, so make
intel_compute_page_offset() handle it.
The way we do it is first we compute the closest tile boundary
as before, and then figure out how many tiles we need to go
to reach the desired alignment. The difference in the offset
From: Ville Syrjälä
Redo the fb rotation handling in order to:
- eliminate the NV12 special casing
- handle fb->offsets[] properly
- make the rotation handling reasier for the plane code
To achieve these goals we reduce intel_rotation_info to only contain
(for each plane) the rotated view width,
From: Ville Syrjälä
rotate_pages() checks to see if it got called with a NULL sg, and then
goes to extract it from sg->sgl. It always gets called with a NULL sg
for the first plane, so moving the initial 'sg=st->sgl' assignment out
into intel_rotate_fb_obj_pages() seems less special-casey.
Signe
From: Ville Syrjälä
The page aligned surface address calculation needs to know which way
things are rotated. The contract now says that the caller must pass the
rotate x/y coordinates, as well as the tile_height aligned stride in
the tile_height direction. This will make it fairly simple to deal
From: Ville Syrjälä
We more or less randomly call the "bytes per pixel" value
'cpp', 'bytes_per_pixel', 'pixel_size', or even 'bpp'. Let's just pick
one and stick to it. I've chosen 'cpp'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 +++---
drivers/gpu/drm/i915/
From: Ville Syrjälä
intel_pin_and_fence_fb_obj() only needs the framebuffer, and the desird
rotation (to find the right GTT view for it), so no need to pass all
kinds of plane stuff.
The main motivation is to get rid of the uggy NULL plane_state handling
due to fbdev.
v2: Add a note why I reall
From: Ville Syrjälä
intel_compute_tile_offset() and intel_add_fb_offsets() get passed the fb
and the rotation. As both of those come from the plane state we can just
pass that in instead.
For extra consitency pass the plane state to intel_fb_xy_to_linear() as
well even though it only really need
From: Ville Syrjälä
We convert the fb->offsets[] into x/y offsets, so they must be
(macro)pixel aligned. Check for this, and if things look good
allow fb->offsets[] != 0 when creating fbs since we now handle
them correctly.
v2: Move to last place in the series and improve the commit message
Sig
Hi
In our IGT/Kernel culture, patch commit titles (here, presented as the
email subject) are usually small (under 70-80 chars) providing a quick
summary of what the change does.
Also, we try to make each patch contain a single logical and complete
change. So, for example, one approach you could h
After the recent discussions regarding the effects of the vblank
disabling policies on PC state residencies, I started running some
experiments to reevaluate some non-intuitive conclusions I had
reached. In order to help me do this, I decided to write this tool.
The idea is very simple: the tool p
On Wed, Jan 20, 2016 at 09:05:35PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Instead of repopulatin the rotation_info struct for the fb every time
> we try to use the fb, we can just populate it once when creating the fb,
> and later we can just copy the pre-populate s
On Wed, Jan 20, 2016 at 06:48:25PM +0100, Michał Winiarski wrote:
> No functional changes.
> While I'm here, let's also rename gem_uses_aliasing_ppgtt (since it's
> being used to indicate if we are using ANY kind of ppgtt) and introduce
> gem_uses_full_ppgtt and gem_uses_full_48b_ppgtt to drop some
On Wed, Jan 20, 2016 at 06:48:26PM +0100, Michał Winiarski wrote:
> We can move it from softpin test into lib, and since softpin support is
> highly unlikely to go away in-between getparam ioctl calls, let's just
> do a single call and store the value.
>
> Signed-off-by: Michał Winiarski
Reviewed
On Mon, Jan 18, 2016 at 08:45:35PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau
>
> We'd like to be able to program the blending modes of display planes.
> Ville suggested to use something similar to the GL blend states, which
> does seem like a good idea.
>
> For now, we only consider
On Mon, Jan 18, 2016 at 08:45:36PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau
>
> This patch adds the blend functions, and as per the
> blend function, updates the plane control register values
>
> V2: Add blend support for all RGB formats
> Fix the reg writes on plane_ctl_alpha b
On Mon, Jan 18, 2016 at 08:45:37PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau
>
> In the hope of expressing colors in the KMS API in a consitant want,
> let's introduce a ARGB 16161616 color and a few convinience macros
> around it.
>
> Signed-off-by: Damien Lespiau
This is somewhat
On Mon, Jan 18, 2016 at 08:45:38PM +0530, Vandita Kulkarni wrote:
> From: Damien Lespiau
>
> Add blend color property and update the
> documentation for the same
>
> V2: Add blend color support in get property.
It would be good to describe in a bit more detail what "blend color"
means. It's un
From: Tom O'Rourke
SLPC (Single Loop Power Controller) is a replacement for
some host-based power management features. The SLPC
implemenation runs in firmware on GuC.
This series is a first request for comments. This series
is not expected to be merged. After changes based on
comments, a late
From: Tom O'Rourke
When SLPC is controlling requested frequency, the rps.cur_freq
value is not used to make the frequency request.
Before using rps.cur_freq in sysfs or debugfs, read
requested frequency from register to get the value
most recently requested by SLPC firmware.
Signed-off-by: Tom
From: Tom O'Rourke
Expose host2guc_action for use by SLPC in intel_slpc.c.
Expose functions to allocate and release objects used
by GuC to be used for SLPC shared memory object.
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_guc_submission.c | 6 +++---
drivers/gpu/drm/i915/intel_g
From: Tom O'Rourke
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_slpc.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_slpc.h
b/drivers/gpu/drm/i915/intel_slpc.h
index bb1d12e..e7ff4a0 100644
--- a/drivers/gpu/drm/i915/in
1 - 100 of 120 matches
Mail list logo
