On 14/07/17 11:24 AM, Ilia Mirkin wrote:
> On Thu, Jul 13, 2017 at 10:14 PM, Michel Dänzer wrote:
>> On 13/07/17 09:31 PM, Ilia Mirkin wrote:
>>> On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer wrote:
On 18/04/17 07:07 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off
Quoting Chris Wilson (2017-07-14 00:27:05)
> First question is whether or not we should wait for the gpu. Using
> peekdata/pokedata implies the target thread is stopped, we could infer
> that also means that any gpu tasks are also stopped for the client. (To
> be accurate we would have to flush the
On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
> So, if you think this is wrong, can you fix this warning in a way that
> you'd like?
As I replied previously [1], with more background, fixing the warnings
properly, in a way that actually improves the code instead of making it
worse, would mean a
On Wed, 12 Jul 2017, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2017-07-12 09:47:25)
>> On Tuesday, July 11, 2017 3:19:53 PM PDT Jim Bride wrote:
>> > On SKL+ there is a bit in SRD_CTL that software is not supposed to
>> > modify, but we currently clobber that bit when we enable PSR. In
>
On Tue, 11 Jul 2017, Jim Bride wrote:
> According to the eDP spec, when the count field in TEST_SINK_MISC
> increments then the six bytes of sink CRC information in the DPCD
> should be valid. Unfortunately, this doesn't seem to be the case
> on some panels, and as a result we get some incorrect
On Thu, 13 Jul 2017, Sean Paul wrote:
> On Wed, Jul 12, 2017 at 02:12:24PM +0200, Daniel Vetter wrote:
>> The problem is that we have a distributed cache - every committer has
>> a copy. Which means even just a slight clock skew will make sure that
>> a naive gc algorithm results in lots of thrash
Hi,
> > > Right we need to know this at device initialization time for both
> > > cases
> > > to initialize VGACommonState structure for that device
> >
> > Why do you need a VGACommonState?
> >
>
> We need to create a GRAPHIC_CONSOLE for vGPU device and specify
> GraphicHwOps so that from it
On Wed, 12 Jul 2017, Rodrigo Vivi wrote:
> This sequence is part of enable source anyways, but they
> only need to be executed once and not on every activation,
> So let's re-create hsw_enable_source.
>
> Cc: Daniel Vetter
> Cc: Dhinakaran Pandiyan
> Cc: Jim Bride
> Cc: Vathsala NAgaraju
> Sig
Hi,
> In case when VFIO region is used to provide surface to QEMU, plane_id
> would be region index,
Then we should name it "region_index" not "plane_id".
> for example region 10 could be used for primary
> surface and region 11 could be used for cursor surface. So in that
> case,
> mdev vendo
On Wed, 12 Jul 2017, Rodrigo Vivi wrote:
> Let's move the activation calls together after enable is done.
>
> No real functional change should be expected here. Just an attempt
> to get it clear when we are really activating PSR after enabling it.
>
> Cc: Daniel Vetter
> Cc: Dhinakaran Pandiyan
Hi,
> Another open is, so far, our design is focused on dmabuf based gfx
> plane only. Can we go a step further to consider a general
> Buffer sharing interface? If we reference V4L2, we can see dmabuf can
> be considered as one kind of buffers, we can have more
> kinds of buffers, like mmap bu
Hi Paulo,
On Thursday 13 July 2017 01:47 AM, Paulo Zanoni wrote:
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
Allow tests to create Y-tiled bufferes using a separate
argument to the test without increasing the number of
subtests.
v2: Changed tiling option to string (Paulo)
I h
Hi,
> +struct vfio_device_gfx_plane_info {
> + __u32 argsz;
> + __u32 flags;
> + /* in */
> + __u32 drm_plane_type; /* type of plane:
> DRM_PLANE_TYPE_* */
> + /* out */
> + __u32 drm_format; /* drm format of plane */
DRM_FORMAT_*
drm_format_mod is gone? Not ne
On 7/14/2017 7:00 AM, Zhang, Tina wrote:
>
>
>> -Original Message-
>> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>> Behalf Of Kirti Wankhede
>> Sent: Wednesday, July 12, 2017 8:45 PM
>> To: Zhang, Tina ; Gerd Hoffmann
>> ; Tian, Kevin ; linux-
>> ker...@
On 7/14/2017 3:31 PM, Gerd Hoffmann wrote:
> Hi,
>
>> In case when VFIO region is used to provide surface to QEMU, plane_id
>> would be region index,
>
> Then we should name it "region_index" not "plane_id".
>
>> for example region 10 could be used for primary
>> surface and region 11 could
On Wed, 05 Jul 2017, Mahesh Kumar wrote:
> From: "Kumar, Mahesh"
>
> This patch creates a new function for clamping u64 to fixed16.
> And make use of this function in other fixed16 wrappers.
>
> Signed-off-by: Mahesh Kumar
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_drv.
On Thu, 13 Jul 2017, Maarten Lankhorst
wrote:
> Op 05-07-17 om 16:31 schreef Mahesh Kumar:
>> From: "Kumar, Mahesh"
>>
>> use same cpp value in different phase of plane WM caluclation.
>>
>> Signed-off-by: Mahesh Kumar
>> Reviewed-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_pm.
From: Matthew Auld
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
av
Hi all,
Another tiny iteration, bigger change being storing uuid in
(UUID_STRING_LEN + 1) sized array of char.
Cheers,
Lionel Landwerlin (1):
drm/i915/perf: prune OA configs
Matthew Auld (1):
drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
drivers/gpu/drm/i915/i915_drv.c |
On 13/07/17 15:42, Matthew Auld wrote:
On 13 July 2017 at 12:22, Lionel Landwerlin
wrote:
From: Matthew Auld
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to l
Hi Jani,
Thanks for review.
On Friday 14 July 2017 03:56 PM, Jani Nikula wrote:
On Thu, 13 Jul 2017, Maarten Lankhorst
wrote:
Op 05-07-17 om 16:31 schreef Mahesh Kumar:
From: "Kumar, Mahesh"
use same cpp value in different phase of plane WM caluclation.
Signed-off-by: Mahesh Kumar
Revi
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which c
On Friday 14 July 2017 12:32 AM, Daniel Vetter wrote:
On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote:
On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote:
On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C wrote:
On Thursday 13 July 2017 02:15 PM, Daniel Vetter wrote:
On Thu,
== Series Details ==
Series: Add support for loadable OA configs
URL : https://patchwork.freedesktop.org/series/27295/
State : success
== Summary ==
Series 27295v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27295/revisions/1/mbox/
Test gem_exec_suspen
Hello,
By default tearing is evident when running full-screen OpenGL
applications such as [1] or playing one of the numerous tearing test
videos from youtube in mpv (with mpv's xv, opengl or vaapi video output
drivers, I guess glamor implements xv via OpenGL so no surprise there).
By accident I'v
== Series Details ==
Series: YCBCR 4:2:0 handling in DRM layer (rev3)
URL : https://patchwork.freedesktop.org/series/26972/
State : success
== Summary ==
Series 26972v3 YCBCR 4:2:0 handling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/26972/revisions/3/mbox/
Test kms_flip:
DRM connector property is created to represent the content protection
state of the connector and to configure the same.
CP States defined:
DRM_CP_UNSUPPORTED - CP is not supported
DRM_CP_DISABLE - CP is disabled
DRM_CP_ENABLE - CP is enabled
V2: Red
== Series Details ==
Series: DRM Interfaces for HDCP support (rev2)
URL : https://patchwork.freedesktop.org/series/27170/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK in
On Wed, Jul 12, 2017 at 12:17:24PM +0300, Abdiel Janulgue wrote:
> This allows us to proceed gracefully without invoking the global
> CI-level timeout especially when opening the buggy crtc-data
> file descriptor.
>
> Signed-off-by: Abdiel Janulgue
> ---
> tests/debugfs_test.c | 5 -
> 1 fil
Hi,
> There could be only two planes, one DRM_PLANE_TYPE_PRIMARY and one
> DRM_PLANE_TYPE_CURSOR.
> Steps from gfx_update for region case would be:
> - VFIO_DEVICE_QUERY_GFX_PLANE with plane_type =
> DRM_PLANE_TYPE_PRIMARY
> - if vfio_device_gfx_plane_info.size > 0, read region for primary
> su
On Fri, 2017-07-14 at 15:45 +0530, Kirti Wankhede wrote:
>
> On 7/14/2017 3:31 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> > > In case when VFIO region is used to provide surface to QEMU,
> > > plane_id
> > > would be region index,
> >
> > Then we should name it "region_index" not "plane_id".
> >
On 7/14/2017 5:35 PM, Gerd Hoffmann wrote:
> Hi,
>
>> There could be only two planes, one DRM_PLANE_TYPE_PRIMARY and one
>> DRM_PLANE_TYPE_CURSOR.
>> Steps from gfx_update for region case would be:
>> - VFIO_DEVICE_QUERY_GFX_PLANE with plane_type =
>> DRM_PLANE_TYPE_PRIMARY
>
>> - if vfio_dev
On 07/14, Lionel Landwerlin wrote:
> In the following commit we'll introduce loadable userspace
> configs. This change reworks how configurations are handled in the
> perf driver and retains only the test configurations in kernel space.
>
> We now store the test config in dev_priv and resolve the
Hi Lionel,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20170714]
[cannot apply to v4.12]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Lionel
On Thu, Jul 06, 2017 at 03:05:19PM +0200, Maarten Lankhorst wrote:
> Op 06-07-17 om 15:00 schreef Daniel Vetter:
> > With deferred fbdev setup we always need to forward hotplug events,
> > even if fbdev isn't fully set up yet. Otherwise the deferred setup
> > will neer happen.
> >
> > Originally th
Hi Paulo,
On Thursday 13 July 2017 02:31 AM, Paulo Zanoni wrote:
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
Now that we have support for Y-tiled buffers, add another
iteration of tests for Y-tiled buffers.
Have you tested this on platforms that don't support Y-tiled buffers?
On Fri, Jul 14, 2017 at 12:57:23PM +0300, Jani Nikula wrote:
> On Thu, 13 Jul 2017, Sean Paul wrote:
> > On Wed, Jul 12, 2017 at 02:12:24PM +0200, Daniel Vetter wrote:
> >> The problem is that we have a distributed cache - every committer has
> >> a copy. Which means even just a slight clock skew
On Friday 14 July 2017 01:29 AM, Paulo Zanoni wrote:
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
From: Akash Goel
v2: Moved identical code into a single function (Paulo)
My MI-fu is not very strong, but I tried to check this against BSpec
and I believe this patch is correct
On Friday 14 July 2017 01:49 AM, Paulo Zanoni wrote:
Em Qua, 2017-07-12 às 13:45 +0530, Praveen Paneri escreveu:
Hi Paulo,
On Wednesday 12 July 2017 12:33 AM, Paulo Zanoni wrote:
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
From: Paulo Zanoni
This is the program that's supp
On Friday 14 July 2017 03:03 AM, Paulo Zanoni wrote:
Em Sex, 2017-06-09 às 15:48 +0530, Praveen Paneri escreveu:
This patch adds Y-tiling support for igt_draw_rect function.
v2: Use helper function to get tile sizes (Ville)
v3: Moved igt_get_fb_tile_size() out of the for loop
for better per
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE - C
Em Sex, 2017-07-14 às 19:25 +0530, Praveen Paneri escreveu:
> Hi Paulo,
>
> On Thursday 13 July 2017 02:31 AM, Paulo Zanoni wrote:
> > Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
> > > Now that we have support for Y-tiled buffers, add another
> > > iteration of tests for Y-tiled bu
On Tue, Jul 11, 2017 at 04:33:03PM +0200, Maarten Lankhorst wrote:
> Make it more clear that post commit return ret is really return 0,
>
> and add a missing drm_atomic_helper_cleanup_planes when
> drm_atomic_helper_wait_for_fences fails.
>
> Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition
On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kerne
On 14/07/17 13:20, Matthew Auld wrote:
On 07/14, Lionel Landwerlin wrote:
In the following commit we'll introduce loadable userspace
configs. This change reworks how configurations are handled in the
perf driver and retains only the test configurations in kernel space.
We now store the test con
On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:
On Wed, May 3, 2017 at 9:31 AM, Chris Wilson wrote:
On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote:
On 05/03/2017 08:52 AM, Mika Kuoppala wrote:
Oscar Mateo [1] writes:
On 05/02/2017 09:17 AM, Mika Kuoppala wrote:
Chris
On Fri, Jul 14, 2017 at 04:30:30PM +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> > We want to change swap_state to wait indefinitely, but to do this
> > swap_state should wait interruptibly. This requires propagating
> > the error to each driver.
On Tue, Jul 11, 2017 at 04:33:02PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state could previously never fail, in order to still
> continue it would set a limit of 10s on waiting for previous updates to
> complete,
> then it moved forward. This can be very bad when ignoring previou
On Tue, Jul 11, 2017 at 04:33:09PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> MSM has its own busy tracking, which means the swap_state call can be
On Tue, Jul 11, 2017 at 04:33:10PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Thierry Reding
> Cc: Jonatha
On Tue, Jul 11, 2017 at 04:33:12PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> VC4 has its own nonblocking modeset tracking through the vc4->async_m
On Tue, Jul 11, 2017 at 04:33:13PM +0200, Maarten Lankhorst wrote:
> Now that all drivers check the return value, convert swap_state to
> __must_check. This is done separately to force build warnings if we
> missed a driver.
>
> Signed-off-by: Maarten Lankhorst
Maybe squash in with the next comm
On Tue, Jul 11, 2017 at 04:33:14PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_
Quoting Oscar Mateo (2017-07-14 15:52:59)
>
>
>
> On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:
> > On Wed, May 3, 2017 at 9:31 AM, Chris Wilson
> > wrote:
> >> On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote:
> >>> On 05/03/2017 08:52 AM, Mika Kuoppala wrote:
> >>>
> >>> Oscar
Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
Fixes: 2889caa92321 - ("drm/i915: Eliminate lots of iterations over the
execobjects array")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
1acfc104cdf8 missed to convert this one caller to be lockless. The side
effect of that was that the error check in lookup_context() became
incorrect. Convert now this caller too.
Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only context lookups")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by:
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.
Reported-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Cc: # v4.12+
---
drivers
Hi again,
Here is a v4 that uncovered an issue in the existing code.
Thanks to Matthew for his in-depth review!
Cheers,
Lionel Landwerlin (2):
drm/i915/perf: fix flex eu registers programming
drm/i915/perf: prune OA configs
Matthew Auld (1):
drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG
Quoting Imre Deak (2017-07-14 16:12:42)
> Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
>
> Fixes: 2889caa92321 - ("drm/i915: Eliminate lots of iterations over the
> execobjects array")
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by: Imre Deak
/o\ Oops.
Reviewed-by: Chris Wilson
-Chri
From: Matthew Auld
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
av
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 63 +++
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 90 +--
lib/igt_kms.h | 3 ++
2 files changed, 59 insertions(+
From: Brian Starkey
Add support in igt_kms for Writeback connectors, with the ability to
attach framebuffers and retrieve fences.
Signed-off-by: Brian Starkey
---
lib/igt_aux.c | 1 +
lib/igt_kms.c | 76 ++-
lib/igt_kms.h | 16 ++
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 123 ++
1 file changed,
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 6 +-
lib/igt_kms.h | 7 +
tests/Makefile.s
From: Brian Starkey
Separate out the CRC code for better compartmentalisation. Should ease
the addition of more/different CRC sources in the future.
Signed-off-by: Brian Starkey
---
lib/Makefile.sources | 2 +
lib/igt_chamelium.h | 1 +
lib/igt_crc.c
We're trying to introduce support for writeback connectors, a way to
expose in DRM the hardware functionality from display engines that
allows to write back into memory the result of the DE's composition
of supported planes.
Generic DRM support is available here [1] and will be merged once
this pa
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix error checking/locking in
perf/lookup_context()
URL : https://patchwork.freedesktop.org/series/27309/
State : success
== Summary ==
Series 27309v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
Quoting Patchwork (2017-07-14 16:28:47)
> e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s
> UTC integration manifest
> 090da8a drm/i915: Fix user ptr check size in eb_relocate_vma()
> 84be7c7 drm/i915: Fix error checking/locking in perf/lookup_context()
And because pw
== Series Details ==
Series: Add support for loadable OA configs
URL : https://patchwork.freedesktop.org/series/27310/
State : success
== Summary ==
Series 27310v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27310/revisions/1/mbox/
Test gem_exec_suspen
From: Ville Syrjälä
Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.
Even worse, a write to any of the cursor register apart
Reviewed-by: Lionel Landwerlin
On 14/07/17 16:12, Imre Deak wrote:
1acfc104cdf8 missed to convert this one caller to be lockless. The side
effect of that was that the error check in lookup_context() became
incorrect. Convert now this caller too.
Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only c
On Fri, Jul 14, 2017 at 12:46:08PM +0300, Jani Nikula wrote:
> On Tue, 11 Jul 2017, Jim Bride wrote:
> > According to the eDP spec, when the count field in TEST_SINK_MISC
> > increments then the six bytes of sink CRC information in the DPCD
> > should be valid. Unfortunately, this doesn't seem to
== Series Details ==
Series: drm/i915: Fix cursor updates on some platforms
URL : https://patchwork.freedesktop.org/series/27314/
State : success
== Summary ==
Series 27314v1 drm/i915: Fix cursor updates on some platforms
https://patchwork.freedesktop.org/api/1.0/series/27314/revisions/1/mbox/
On 14 July 2017 at 16:15, Lionel Landwerlin
wrote:
> We were reserving fewer dwords in the ring than necessary. Indeed
> we're always writing all registers once, so discard the actual number
> of registers given by the user and just program the whitelisted ones
> once.
>
> Reported-by: Matthew Aul
Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27)
> From: Ville Syrjälä
>
> Turns out that just writing CURPOS isn't sufficient to move the cursor
> on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
> On those platforms we need to arm even the CURPOS update with a
>
On Fri, Jul 14, 2017 at 05:24:03PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27)
> > From: Ville Syrjälä
> >
> > Turns out that just writing CURPOS isn't sufficient to move the cursor
> > on some platforms. My 830 works just fine, but eg. 945 and PNV don
No functional change is expected here since at this point
PSR is not allowed to go to any active state. In other
words, not really enabled.
However let's do in a separated patch so it gets clear
on what is change and specially it can helps on bisect
case if we figure something has caused changes i
This sequence is part of enable source anyways, but they
only need to be executed once and not on every activation,
So let's re-create hsw_enable_source.
v2: Avoid changing order here to avoid changing behaviour
as suggested by Jani.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
== Series Details ==
Series: PSR clean-up, new vfuncs and more use of HW tracking. (rev3)
URL : https://patchwork.freedesktop.org/series/27194/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/uts
Let's move the activation calls together after enable is done.
No real functional change should be expected here. Just an attempt
to get it clear when we are really activating PSR after enabling it.
v2: Add braces on if/else because commit message there is too long
as suggested by Jani.
Cc:
Tested by: Elio Martinez
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Patchwork
Sent: Friday, July 7, 2017 6:25 PM
To: nav...@emeril.freedesktop.org; Navare, Manasi D
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] ✓ Fi.CI.BAT:
Tested by: Elio Martinez
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Manasi Navare
Sent: Friday, July 7, 2017 6:13 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [RESEND v2 2/2] drm/i915/dp: Validate the compliance test
li
== Series Details ==
Series: PSR clean-up, new vfuncs and more use of HW tracking. (rev4)
URL : https://patchwork.freedesktop.org/series/27194/
State : success
== Summary ==
Series 27194v4 PSR clean-up, new vfuncs and more use of HW tracking.
https://patchwork.freedesktop.org/api/1.0/series/27
On 13 July 2017 at 12:16, Lionel Landwerlin
wrote:
> v2: Add tests regarding removing configs (Matthew)
> Add tests regarding adding/removing configs without permissions
> (Matthew)
>
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 201
> +++
I can live without those logs, and it avoids a kernel
recompile&reboot.
Signed-off-by: Daniel Vetter
---
tests/drv_module_reload.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
index db2ad2cf0f43..be831851dec2 100644
On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
wrote:
> On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
>> So, if you think this is wrong, can you fix this warning in a way that
>> you'd like?
>
> As I replied previously [1], with more background, fixing the warnings
> properly, in a way that actual
Hi,
I'm a bit late to the party, but as I already mentioned at [1] the CNL
render ctx size is smaller than the gen9 one according to the specs. The
ctx format in the specs contains 16752 dwords, i.e. 17 pages, to which
we need to add 1 page for the PPHWSP, so 18 pages total. If we re-use
the
* Don't define it twice.
* Define MSBs first, like the rest of i915_reg.h.
* Add CNL_ prefix to the bit that arrived in CNL.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 8 +++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
On 07/12/2017 04:47 PM, Rodrigo Vivi wrote:
Version 1.05 is now available for CNL.
According to its release notes the only difference is:
- Change from aux A pwrreq always turn on during restore,
to saving and restoring aux A pwrreq.
Reviewed-by: Clinton Taylor
-Clint
Anusha Sriv
On 14/07/17 18:09, Matthew Auld wrote:
On 13 July 2017 at 12:16, Lionel Landwerlin
wrote:
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
Signed-off-by: Lionel Landwerlin
---
tests/perf.c | 201 ++
== Series Details ==
Series: drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions
URL : https://patchwork.freedesktop.org/series/27321/
State : success
== Summary ==
Series 27321v1 drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions
https://patchwork.freedesktop.org/api/1.0/series/27321/revis
oh! I believe you had warned me about this beforehand but I forgot... sorry
Reviewed-by: Rodrigo Vivi
On Fri, Jul 14, 2017 at 10:52 AM, Paulo Zanoni wrote:
> * Don't define it twice.
> * Define MSBs first, like the rest of i915_reg.h.
> * Add CNL_ prefix to the bit that arrived in CNL.
>
>
On 14 July 2017 at 18:57, Lionel Landwerlin
wrote:
> On 14/07/17 18:09, Matthew Auld wrote:
>>
>> On 13 July 2017 at 12:16, Lionel Landwerlin
>> wrote:
>>>
>>> v2: Add tests regarding removing configs (Matthew)
>>> Add tests regarding adding/removing configs without permissions
>>> (Mat
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
> This patch checks encoder level support for YCBCR420 outputs.
> The logic goes as simple as this:
> If the input mode is YCBCR420-only mode: prepare HDMI for
> YCBCR420 output, else continue with RGB output mode.
>
> It checks if t
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
>
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for ycbcr
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
> To support ycbcr output, we need a pipe CSC block to do
> RGB->YCBCR conversion.
>
> Current Intel platforms have only one pipe CSC unit, so
> we can either do color correction using it, or we can perform
> RGB->YCBCR conversion.
>
On 17-06-29 22:49:44, Ville Syrjälä wrote:
[snip]
... but here it's ALIGN(formats_offset+formats_size). I think we should
be aligning the same thing in both cases, or we add a BUILD_BUG_ON to
make sure the header size always stays a multiple of 8 bytes.
That's mainly because the design of the
1 - 100 of 138 matches
Mail list logo
