On Tue, Jul 11, 2017 at 08:14:08AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > +struct vfio_device_query_gfx_plane {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > + struct vfio_device_gfx_plane_info plane_info;
> > > + __u32 plane_type;
> > > + __s32 fd; /* dma-buf fd */
> > > + __u32 plane_id;
On Thu, Jul 06, 2017 at 06:29:55AM +0800, Tina Zhang wrote:
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
> get the plan and its related information.
>
> The dma-buf's life cycle is handled by user mode and tracked by kernel.
> The returned fd in struct vfio_device_que
Instead check info->ops->owner, which amounts to the same.
Spotted because I want to remove the pile of broken and cargo-culted
fb_info->flags assignments in drm drivers.
v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines
that I've failed to spot.
Cc: Bartlomiej Zolnierkiewic
== Series Details ==
Series: Make fbcon a built-time depency for fbdev, take 2 (rev2)
URL : https://patchwork.freedesktop.org/series/26909/
State : failure
== Summary ==
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrele
On Mon, 10 Jul 2017, Pavel Moukhataev wrote:
> Hello
>
> I exeprience problems with Intel graphics driver. It hangs during loading.
> I'm not a big specialist in Linux drivers and I can't debug video driver
> and fix problem manually. But may be there are some people that can help me
> - I can ins
On Monday, July 10, 2017 10:33:46 PM PDT ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make the min_pixclk thing less confusing by changing it to track
> the minimum acceptable cdclk frequency instead. This means moving
> the application of the guardbands to a slightly higher lev
On Monday, July 10, 2017 1:58:52 PM PDT Rodrigo Vivi wrote:
> Paulo had noticed that inside cnl_ddi_vswing_program
> the case was handling voltage but with no indication
> of type where a missing type could also take us to that
> path. So my first attempt was to add a message to
> let clear who tri
Quoting Jason Ekstrand (2017-07-11 01:01:20)
> Given that domain tracking is global, we can also run into interesting issues
> if process A does a CPU map, writes to it, and then hands it to process B
> which
> uses it from the GPU. Without being very aggressive about set_domain, we have
> no kno
Quoting Mika Kuoppala (2017-07-10 15:14:19)
> Chris Wilson writes:
>
> > Since we make call i915_gem_context_mark_guilty() concurrently when
> > resetting different engines in parallel, we need to make sure that our
> > updates are safe for the unlocked access.
> >
> > Signed-off-by: Chris Wilson
Each Linux distro takes a different spin on providing kernel's uapi
headers (especialy the *drm*.h).
You can get them with linux-headers, you can get them with libdrm.
Sometime you can even get them twice, from both sources.
Sometimes the headers match your kernel version, sometimes you end up
st
Hi~ all,
I want to run the testcases of igt, but there are some problems during
that. Lots of testcase started with gem and kms skiped.
Thanks for your helping.
I make the piglit and igt by following steps
$cd piglit
$cmake .
$male
$make install
$cd intel-gpu-tools
On Tue, Jul 11, 2017 at 02:47:42AM -0700, Dhinakaran Pandiyan wrote:
> On Monday, July 10, 2017 10:33:46 PM PDT ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make the min_pixclk thing less confusing by changing it to track
> > the minimum acceptable cdclk frequency instead.
Hi Dave, drm/i915 fixes for v4.13-rc1. Almost half of them for stable
kernels, the rest for issues in this merge window. Two batches of GVT
fixes, otherwise fixes all around.
BR,
Jani.
The following changes since commit bdbbf7d619d1fd2f1fa9eb529b7817e4faf73f5e:
drm/i915: Clear execbuf's vma b
On Tue, 11 Jul 2017, Zhenyu Wang wrote:
> Hi,
>
> Still against dinf, here's current gvt fixes for 4.13.
Pulled, thanks.
BR,
Jani.
>
> Thanks.
> --
> The following changes since commit 7581d5ca2bb269cfc2ce2d0cb489aac513167f6b:
>
> drm/i915/fbdev: Check for existence of ifbdev->vma before oper
This patch series is adding NV12 support for Skylake display after
rebasing on latest drm-intel-nightly. Initial series of the patches
can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html
Feature has been currently tested with custom linux based test tool
IGT te
From: Chandra Konduru
This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling
v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler
v3:
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
lo
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The lo
From: Chandra Konduru
This patch adds NV12 to list of supported formats for
primary plane
v2: Rebased (Chandra Konduru)
v3: Rebased (me)
v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats
v5: Reb
From: Chandra Konduru
This patch adds NV12 to format_is_yuv() function
for sprite planes.
v2:
-Use intel_ prefix for format_is_yuv (Ville)
v3: Rebased (me)
v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to th
From: Chandra Konduru
This patch updates scaler max limit support for NV12
v2: Rebased (me)
v3: Rebased (me)
v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Tested-by: Clinton Taylor
Reviewed-by: Clinton Taylor
Signed-of
From: Chandra Konduru
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats
v4: Ad
From: Chandra Konduru
This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.
v2:
-Fix an issue in checks added (Chandra Konduru)
v3: rebased (me)
v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
On Mon, Jul 10, 2017 at 02:25:39PM -, Patchwork wrote:
> == Series Details ==
>
> Series: Revert "drm/i915: Add heuristic to determine better way to adjust
> brightness"
> URL : https://patchwork.freedesktop.org/series/27065/
> State : failure
OK, seems I botched that one :S
Will geerate
On Tue, 2017-07-11 at 03:14 -0700, Dhinakaran Pandiyan wrote:
> On Monday, July 10, 2017 1:58:52 PM PDT Rodrigo Vivi wrote:
> > Paulo had noticed that inside cnl_ddi_vswing_program
> > the case was handling voltage but with no indication
> > of type where a missing type could also take us to that
>
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.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
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: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nv50_display.c | 5 -
1 file
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 to atomic interfaces
internally")
Cc: Ben Skeggs
Cc: dri-de...@lists.freedes
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.
Atmel tracks pending commits through dc->commit.pending, so it can
ignore the changes by setting stall = false. We never return failure in
this ca
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 previous updates,
because the hw state and sw state may get out of sync when for e
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
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
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
done with stall = false, in which case it should never return an error.
Hand
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: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 +-
1 file changed, 5 inser
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: CK Hu
Cc: Philipp Zabel
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
--
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_modeset
semaphore, so it doesn't need to stall in swap_state. Pass stall = fal
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: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.c | 7 ++
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_atomic_helper.c
index bfb98fbd0e0e..05a22aeffbb0 100644
--- a/drivers/gpu/drm/drm
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
---
include/drm/drm_atomic_helper.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/inclu
Instead check info->ops->owner, which amounts to the same.
Spotted because I want to remove the pile of broken and cargo-culted
fb_info->flags assignments in drm drivers.
v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines
that I've failed to spot.
v3: Don't nuke FBINFO_FLAG_D
== Series Details ==
Series: Adding NV12 support for SKL display (rev5)
URL : https://patchwork.freedesktop.org/series/25377/
State : success
== Summary ==
Series 25377v5 Adding NV12 support for SKL display
https://patchwork.freedesktop.org/api/1.0/series/25377/revisions/5/mbox/
Test kms_pipe
On 07/11/2017 07:10 AM, Vidya Srinivas wrote:
From: Chandra Konduru
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_for
== Series Details ==
Series: drm/atomic: Make drm_atomic_helper_swap_state waiting interruptible.
URL : https://patchwork.freedesktop.org/series/27112/
State : warning
== Summary ==
Series 27112v1 drm/atomic: Make drm_atomic_helper_swap_state waiting
interruptible.
https://patchwork.freedeskt
Hi Arkadiusz,
On 11 July 2017 at 12:48, Arkadiusz Hiler wrote:
> Each Linux distro takes a different spin on providing kernel's uapi
> headers (especialy the *drm*.h).
>
> You can get them with linux-headers, you can get them with libdrm.
> Sometime you can even get them twice, from both sources.
== Series Details ==
Series: Make fbcon a built-time depency for fbdev, take 2 (rev3)
URL : https://patchwork.freedesktop.org/series/26909/
State : failure
== Summary ==
Series 26909v3 Make fbcon a built-time depency for fbdev, take 2
https://patchwork.freedesktop.org/api/1.0/series/26909/revi
On Tue, Jul 11, 2017 at 04:12:18PM +0100, Emil Velikov wrote:
> Hi Arkadiusz,
>
> On 11 July 2017 at 12:48, Arkadiusz Hiler wrote:
> > Each Linux distro takes a different spin on providing kernel's uapi
> > headers (especialy the *drm*.h).
> >
> > You can get them with linux-headers, you can get
On Tue, Jul 11, 2017 at 07:40:55PM +0530, Vidya Srinivas wrote:
> From: Chandra Konduru
>
> This patch adds NV12 to list of supported formats for sprite plane.
>
> v2: Rebased (me)
>
> v3: Review comments by Ville addressed
> - Removed skl_plane_formats_with_nv12 and added
> NV12 ca
On Tue, Jul 11, 2017 at 07:40:56PM +0530, Vidya Srinivas wrote:
> From: Chandra Konduru
>
> This patch adds NV12 as supported format
> to intel_framebuffer_init and performs various checks.
>
> v2:
> -Fix an issue in checks added (Chandra Konduru)
>
> v3: rebased (me)
>
> v4: Review comments b
On Tue, Jul 11, 2017 at 07:40:54PM +0530, Vidya Srinivas wrote:
> From: Chandra Konduru
>
> This patch adds NV12 to list of supported formats for
> primary plane
>
> v2: Rebased (Chandra Konduru)
>
> v3: Rebased (me)
>
> v4: Review comments by Ville addressed
> Removed the skl_primary_fo
On Tue, Jul 11, 2017 at 07:40:53PM +0530, Vidya Srinivas wrote:
> From: Chandra Konduru
>
> This patch updates scaler max limit support for NV12
>
> v2: Rebased (me)
>
> v3: Rebased (me)
>
> v4: Missed the Tested-by/Reviewed-by in the previous series
> Adding the same to commit message i
On Tue, Jul 11, 2017 at 07:40:48PM +0530, Vidya Srinivas wrote:
> This patch series is adding NV12 support for Skylake display after
> rebasing on latest drm-intel-nightly. Initial series of the patches
> can be found here:
> https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html
>
Reviewed-by: Rodrigo Vivi
On Thu, Jul 06, 2017 at 05:40:23PM +0300, Imre Deak wrote:
> The power well IDs are used for lookup, so they must be unique on a
> given platform; ensure this on CHV. This didn't cause an actual problem
> since we didn't need to look up power wells which happened to sha
On Thu, Jul 6, 2017 at 7:40 AM, Imre Deak wrote:
> Atm, the power well IDs are defined in separate platform specific enums,
> which isn't ideal for the following reasons:
> - the IDs are used by helpers like lookup_power_well() in a platform
> independent way
> - the always-on power well is used
couldn't we remove now .always_on variable?
anyways:
Reviewed-by Rodrigo Vivi
On Thu, Jul 6, 2017 at 7:40 AM, Imre Deak wrote:
> Power well IDs are used for lookup so they must be unique. To ensure
> this assign the always-on power well ID everywhere where it's missing.
> This didn't cause a
Reviewed-by: Rodrigo Vivi
On Thu, Jul 6, 2017 at 7:40 AM, Imre Deak wrote:
> Make the GEN2 power well ID assignment explicit for consistency.
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c
On Thu, Jul 06, 2017 at 05:40:26PM +0300, Imre Deak wrote:
> Make the GEN2 power well ID assignment explicit for consistency.
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
> 2 files c
On Thu, Jul 06, 2017 at 05:40:35PM +0300, Imre Deak wrote:
> The pattern of a power well backing a set of pipe IRQ or VGA
> functionality applies to all HSW+ platforms. Using power well attributes
> instead of platform checks to decide whether to init/reset pipe IRQs and
> VGA correspondingly is cl
On Thu, Jul 06, 2017 at 05:40:37PM +0300, Imre Deak wrote:
> The pattern of a power well backing a set of fuses whose initialization
> we need to wait for during power well enabling is common to all GEN9+
> platforms. Adding support for this to the HSW power well enable helper
> allows us to use th
On Thu, Jul 6, 2017 at 7:40 AM, Imre Deak wrote:
> Add an ID for the HSW/BDW global display power well for consistency. The
> ID is selected so that it can be used to get at the HW request and
> status flags with the corresponding GEN9+ macros. Unifying the HSW/BDW
> and GEN9+ versions of these ma
On Fri, Jul 07, 2017 at 05:39:07PM +0300, Imre Deak wrote:
> Check that all the power well IDs are unique on the given platform.
>
> v2:
> - Fix using BIT_ULL() instead of BIT() for 64 bit mask.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
> 1 f
Quoting Chris Wilson (2017-02-14 12:40:01)
> [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> memory (8802538683d0)
> [ 236.828642]
> 42001e7f0008
> [ 236.839543] i i i i u u u u i i i i i i i i u u u u u u u u u
On 02/05/17 12:49, Chris Wilson wrote:
+
+union drm_i915_gem_context_param_sseu {
+ struct {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eu_per_subslice;
+ u8 max_eu_per_subslice;
+ } packed;
__u64 value;
};
I think
On Tue, Jul 11, 2017 at 9:43 AM, Rodrigo Vivi wrote:
> On Thu, Jul 6, 2017 at 7:40 AM, Imre Deak wrote:
>> Atm, the power well IDs are defined in separate platform specific enums,
>> which isn't ideal for the following reasons:
>> - the IDs are used by helpers like lookup_power_well() in a platfo
On Tue, Jul 11, 2017 at 08:05:39PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 06, 2017 at 05:40:37PM +0300, Imre Deak wrote:
> > The pattern of a power well backing a set of fuses whose initialization
> > we need to wait for during power well enabling is common to all GEN9+
> > platforms. Adding sup
On Mon, 2017-07-10 at 13:27 +0300, Paul Kocialkowski wrote:
> On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote:
> > --snip--
> > (also sorry this one took a while to get to, had to do a lot of
> > thinking because I never really solved the problems mentioned here
> > when
> > I tried working on
On Tue, Jul 11, 2017 at 10:21:55AM -0700, Rodrigo Vivi wrote:
> On Tue, Jul 11, 2017 at 9:43 AM, Rodrigo Vivi wrote:
> > On Thu, Jul 6, 2017 at 7:40 AM, Imre Deak wrote:
> >> Atm, the power well IDs are defined in separate platform specific enums,
> >> which isn't ideal for the following reasons:
On Tue, Jul 11, 2017 at 08:22:19PM +0300, Imre Deak wrote:
> On Tue, Jul 11, 2017 at 08:05:39PM +0300, Ville Syrjälä wrote:
> > On Thu, Jul 06, 2017 at 05:40:37PM +0300, Imre Deak wrote:
> > > The pattern of a power well backing a set of fuses whose initialization
> > > we need to wait for during p
On Tue, Jul 11, 2017 at 08:37:24PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 11, 2017 at 08:22:19PM +0300, Imre Deak wrote:
> > On Tue, Jul 11, 2017 at 08:05:39PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jul 06, 2017 at 05:40:37PM +0300, Imre Deak wrote:
> > > > The pattern of a power well backing
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
> This function can be used by igt_draw to get accurate
> tile dimensions for all tile formats.
>
> v2: Added comments to function igt_get_fb_tile_size (Daniel)
>
> Signed-off-by: Praveen Paneri
> ---
> lib/igt_fb.c | 16 +-
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
> igt_get_fb_tile_size function takes modifer as an argument
> This helper function will let users to convert tiling to
> modifier and use igt_get_fb_tile_size()
>
> Signed-off-by: Praveen Paneri
> ---
> lib/igt_fb.c | 26 ++
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
> From: Paulo Zanoni
>
> This is the program that's supposed to test lib/igt_draw. We just
> added Y tiling support for the library, so add the tests now.
>
This is not my original version of the patch, yet there's no changelog
mention
On Mon, 2017-07-10 at 22:33 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently the .modeset_calc_cdclk() hooks check the final cdclk value
> against the max allowed. That's not really sufficient since the low
> level calc_cdclk() functions effectively clamp the min
Link to FDO regression list:
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=DRM%2FIntel&f0=OP&f1=OP&f2=short_desc&f3=keywords&f4=CP&f5=CP&j1=OR&known_name=i915%20regressions&list_id=600614&o2=anywordssubstr&o3=anywordss
On Tue, 2017-07-11 at 16:00 +0300, Ville Syrjälä wrote:
> On Tue, Jul 11, 2017 at 02:47:42AM -0700, Dhinakaran Pandiyan wrote:
> > On Monday, July 10, 2017 10:33:46 PM PDT ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Make the min_pixclk thing less confusing b
The pattern of a power well backing a set of pipe IRQ or VGA
functionality applies to all HSW+ platforms. Using power well attributes
instead of platform checks to decide whether to init/reset pipe IRQs and
VGA correspondingly is cleaner and it allows us to unify the HSW/BDW and
GEN9+ power well co
After the previous refactorings the HSW/BDW and GEN9+ power well helpers
are practically identical, so use the HSW power well helpers for GEN9+
too. This means using the HSW power well ops instead of the SKL one and
setting the irq_pipe_mask, has_vga and has_fuses attributes as needed.
v2:
- Rebas
Atm, the power well IDs are defined in separate platform specific enums,
which isn't ideal for the following reasons:
- the IDs are used by helpers like lookup_power_well() in a platform
independent way
- the always-on power well is used by multiple platforms and so needs
now separate IDs, alth
Add an ID for the HSW/BDW global display power well for consistency. The
ID is selected so that it can be used to get at the HW request and
status flags with the corresponding GEN9+ macros. Unifying the HSW/BDW
and GEN9+ versions of these macros and the power well ops using them
will be done in fol
Make the I830 power well ID assignment explicit for consistency.
v2:
- s/GEN2/I830/ in the comment, since other GEN2s don't have the power
well. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
Reviewed-by: Rodrigo Vivi (v1)
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/
The pattern of a power well backing a set of fuses whose initialization
we need to wait for during power well enabling is common to all GEN9+
platforms. Adding support for this to the HSW power well enable helper
allows us to use the HSW/BDW power well code for GEN9+ as well in a
follow-up patch.
Check that all the power well IDs are unique on the given platform.
v2:
- Fix using BIT_ULL() instead of BIT() for 64 bit mask.
v3:
- Move the check to a separate function. (Ville)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 18 ++
1 file changed, 18 i
== Series Details ==
Series: drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev8)
URL : https://patchwork.freedesktop.org/series/26922/
State : warning
== Summary ==
Series 26922v8 drm/i915: Unify the HSW/BDW and GEN9+ power well code
https://patchwork.freedesktop.org/api/1.0/series/26
Using the HWSP ggtt_offset to get the lrca offset is only correct if the
HWSP happens to be before it (when we reuse the PPHWSP of the kernel
context as the engine HWSP). Instead of making this assumption, get the
lrca offset from the kernel_context engine state.
And while looking at this part of
== Series Details ==
Series: drm/i915/guc: Don't make assumptions while getting the lrca offset
URL : https://patchwork.freedesktop.org/series/27136/
State : success
== Summary ==
Series 27136v1 drm/i915/guc: Don't make assumptions while getting the lrca
offset
https://patchwork.freedesktop.o
On 6/22/2017 4:30 AM, Petri Latvala wrote:
The current documentation for tests is limited to a single string per
test binary. This patch adds support for documenting individual
subtests.
The syntax for subtest documentation is:
igt_subtest_documentation("Frob knobs to see if one of the "
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were
5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP lin
These patches, along with an upcoming series for IGT, enable our
PSR IGT tests to run reliably once again on HSW, BDW, and SKL.
The first change enables us to run the PSR tests on some RVP platforms
whose panels have too slow of a setup time when running in their
preferred mode. The second fixes a
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
order to preserve the value of that bit, go ahead and read SRD_CTL and
do a field-wise setting of the various bits that we need to initialize
before writing the regis
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 and inconsistent
values from the sink CRC DPCD
Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate. Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow t
Quoting Michel Thierry (2017-07-11 22:29:39)
> Using the HWSP ggtt_offset to get the lrca offset is only correct if the
> HWSP happens to be before it (when we reuse the PPHWSP of the kernel
> context as the engine HWSP). Instead of making this assumption, get the
> lrca offset from the kernel_cont
== Series Details ==
Series: Kernel PSR Fix-ups
URL : https://patchwork.freedesktop.org/series/27137/
State : failure
== Summary ==
Series 27137v1 Kernel PSR Fix-ups
https://patchwork.freedesktop.org/api/1.0/series/27137/revisions/1/mbox/
Test core_auth:
Subgroup basic-auth:
Signed-off-by: Jim Bride
---
lib/igt_psr.c| 12
lib/igt_psr.h| 1 +
tests/kms_fbcon_fbt.c| 28
tests/kms_frontbuffer_tracking.c | 17 +
tests/kms_psr_sink_crc.c | 16 ++--
These patches, along with the kernel series at
https://patchwork.freedesktop.org/series/27137/ allow our PSR
IGT tests to run more predictably on HSW, BDW, and SKL. These
patches depend on the kernel series in order to run properly. On
the systems I have available the following sets of tests run
Add functions to tell whether the source and sink support PSR as well
as a function to determine whether PSR is possible (both source and
sink support PSR.) Also modify the PSR tests to use these functions.
Signed-off-by: Jim Bride
---
lib/Makefile.sources | 1 +
lib/igt_psr.c
Signed-off-by: Jim Bride
---
lib/igt_psr.c| 11 +++
lib/igt_psr.h| 1 +
tests/kms_frontbuffer_tracking.c | 12 +++-
tests/kms_psr_sink_crc.c | 2 +-
4 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/lib/igt_psr.c b/li
Create files to contain PSR-specific IGT functions and add macros
to enable and disable PSR.
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
lib/Makefile.sources | 1 +
lib/igt.h| 1 +
lib/igt_psr.h| 30 ++
The multidraw subtest was not taking whether or not the GEM buffer had
ever been in write-combining mode when checking for PSR state, so fix
that.
Reviewed-by: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_frontbuffer_tracking.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
dif
Signed-off-by: Jim Bride
---
lib/igt_psr.c| 34 +
lib/igt_psr.h| 2 ++
tests/kms_fbcon_fbt.c| 4
tests/kms_frontbuffer_tracking.c | 2 +-
tests/kms_psr_sink_crc.c | 41 +
Signed-off-by: Jim Bride
---
lib/igt_psr.c| 13 +
lib/igt_psr.h| 1 +
tests/kms_frontbuffer_tracking.c | 5 +
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/lib/igt_psr.c b/lib/igt_psr.c
index d27c32a..8dda659 100644
--- a
Our tests were sometimes using the string representation of the sink CRC
and sometimes a binary version, so for consistency's sake, as well as to
make the utility function return something closer to what the eDP spec
talks about, all sink CRC operations are now assuming that the sink CRC
is retriev
1 - 100 of 126 matches
Mail list logo
