Signed-off-by: Gabriel Krisman Bertazi
---
tests/kms_pipe_crc_basic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index f49b434857e6..177211249808 100644
--- a/tests/kms_pipe_crc_basic.c
Do a dummy crc read such that if there are no valid outputs for the
pipe, it skip the test before doing a system suspend.
Signed-off-by: Gabriel Krisman Bertazi
---
tests/kms_pipe_crc_basic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 19/06/17 08:37, Chris Wilson wrote:
If we enter i915_handle_error() a second time and a global reset is
already in progress, we can simply wait for completion of the first
reset. Currently we exit earlier prior to the actual reset being
performed -- the worst of both worlds!
v2: Plug into
On 06/19/2017 03:24 PM, Sean Paul wrote:
On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote:
On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
Problem:
While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immidietly follwoing an atomic_commit.
== Series Details ==
Series: drm/i915/cfl: Fix Workarounds.
URL : https://patchwork.freedesktop.org/series/26010/
State : success
== Summary ==
Series 26010v1 drm/i915/cfl: Fix Workarounds.
https://patchwork.freedesktop.org/api/1.0/series/26010/revisions/1/mbox/
Test gem_exec_flush:
During the review of Coffee Lake workarounds Mika pointed out
that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC
should be removed from CFL and with that I should carry the rv-b.
However when doing the v2 I removed another Workaround that should
remain because although not mentioned
Patch merged to dinq, thanks for spotting this and also for reviews
and comments.
On Mon, Jun 19, 2017 at 11:39 AM, Rodrigo Vivi wrote:
> Paulo noticed that we were missing few bits clear
> before writing values back to the register on
> these RMW MMIO operations.
>
> v2:
On Mon, 19 Jun 2017, Dhinakaran Pandiyan wrote:
> Maarten and Ville noticed that we are enabling backlight via DP aux very
> early in the modeset_init path via the intel_dp_aux_setup_backlight()
> function, since commit e7156c833903 ("drm/i915: Add Backlight Control
On Mon, Jun 19, 2017 at 12:06:07PM -0700, Manasi Navare wrote:
> I have tested this for PORT A and works great to give HPD live status.
> Thanks for the patch. Looks good to me.
>
> On Thu, Jun 15, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote:
> On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> > Problem:
> > While running IGT kms_atomic_transition test suite i encountered
> > a hang in drmHandleEvent immidietly follwoing an atomic_commit.
>
> s/immidietly/immediately/g
>
== Series Details ==
Series: drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev4)
URL : https://patchwork.freedesktop.org/series/25935/
State : success
== Summary ==
Series 25935v4 drm/i915/cnl: Fix RMW on ddi vswing sequence.
On Mon, Jun 19, 2017 at 07:01:21PM +, Vivi, Rodrigo wrote:
> On Mon, 2017-06-19 at 21:22 +0300, Ville Syrjälä wrote:
> > On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote:
> > > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake
> > > workarounds.")
> > > Mika
On Mon, 2017-06-19 at 21:22 +0300, Ville Syrjälä wrote:
> On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote:
> > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake
> > workarounds.")
> > Mika pointed out that Spec tells those 2 workarounds were not needed.
> >
> >
I have tested this for PORT A and works great to give HPD live status.
Thanks for the patch. Looks good to me.
On Thu, Jun 15, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add the missing port A handling to
On Thu, 15 Jun 2017, Imre Deak wrote:
> On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
>> I believe it is worth allowing RPM to work without requiring DMC, no?!
>
> Not if there is no good reason for not using DMC. It was decided early
> on that we won't
On 19/06/17 05:46, Chris Wilson wrote:
Quoting Michel Thierry (2017-06-15 21:18:12)
@@ -2992,10 +3014,8 @@ void i915_gem_reset_finish(struct drm_i915_private
*dev_priv)
lockdep_assert_held(_priv->drm.struct_mutex);
- for_each_engine(engine, dev_priv, id) {
-
Paulo noticed that we were missing few bits clear
before writing values back to the register on
these RMW MMIO operations.
v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
v3: Remove unnecessary braces. (Jani).
Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo
On Mon, 2017-06-19 at 12:39 +0300, Paul Kocialkowski wrote:
> This adds two new tests: common-hpd-after-suspend and
> common-hpd-after-hibernate that are aimed at testing HPD change
> during
> suspend/hibernate for both DP and HDMI, at the same time.
>
> The interest in bringing this test up is
On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote:
> When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake
> workarounds.")
> Mika pointed out that Spec tells those 2 workarounds were not needed.
>
> So when double checking I confirmed that and also that by Spec
>
On Mon, 2017-06-19 at 11:08 -0700, Dhinakaran Pandiyan wrote:
> Maarten and Ville noticed that we are enabling backlight via DP aux very
> early in the modeset_init path via the intel_dp_aux_setup_backlight()
> function, since commit e7156c833903 ("drm/i915: Add Backlight Control using
> DPCD for
Maarten and Ville noticed that we are enabling backlight via DP aux very
early in the modeset_init path via the intel_dp_aux_setup_backlight()
function, since commit e7156c833903 ("drm/i915: Add Backlight Control using
DPCD for eDP connectors (v9)"). Looks like all we need to do during
== Series Details ==
Series: drm/i915: Remove WaDisableKillLogic and
GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.
URL : https://patchwork.freedesktop.org/series/26001/
State : success
== Summary ==
Series 26001v1 drm/i915: Remove WaDisableKillLogic and
== Series Details ==
Series: drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev3)
URL : https://patchwork.freedesktop.org/series/25935/
State : failure
== Summary ==
Series 25935v3 drm/i915/cnl: Fix RMW on ddi vswing sequence.
When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake
workarounds.")
Mika pointed out that Spec tells those 2 workarounds were not needed.
So when double checking I confirmed that and also that by Spec
they only apply to SKL and BXT.
v2: Instead of increase the if/else move
On Sat, 2017-06-17 at 01:31 -0700, Dhinakaran Pandiyan wrote:
> On Friday, June 16, 2017 10:18:28 PM PDT Vivi, Rodrigo wrote:
> > On Fri, 2017-06-16 at 21:54 +, Navare, Manasi D wrote:
> >
> > > On Fri, 2017-06-16 at 21:26 +, Vivi, Rodrigo wrote:
> > >
> > > > On Fri, 2017-06-16 at
Paulo noticed that we were missing few bits clear
before writing values back to the register on
these RMW MMIO operations.
v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
v3: Remove unnecessary braces. (Jani).
Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo
On Sat, 2017-06-17 at 01:31 -0700, Dhinakaran Pandiyan wrote:
> On Friday, June 16, 2017 10:18:28 PM PDT Vivi, Rodrigo wrote:
> > On Fri, 2017-06-16 at 21:54 +, Navare, Manasi D wrote:
> >
> > > On Fri, 2017-06-16 at 21:26 +, Vivi, Rodrigo wrote:
> > >
> > > > On Fri, 2017-06-16 at 21:21
== Series Details ==
Series: HDMI YCBCR output handling in DRM layer (rev4)
URL : https://patchwork.freedesktop.org/series/22684/
State : failure
== Summary ==
Series 22684v4 HDMI YCBCR output handling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/22684/revisions/4/mbox/
Test
Ville Syrjälä writes:
>> mutex_lock(>mode_config.mutex);
>> DRM_DEBUG_KMS("running encoder hotplug functions\n");
>> @@ -339,13 +340,18 @@ static void i915_hotplug_work_func(struct work_struct
>> *work)
>> if (!intel_connector->encoder)
>>
When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.
V2: Rebase
V3: Rebase
V4: Rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
Signed-off-by: Shashank
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
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.
This function adds a csc handler,
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 ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
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 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI
This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 mode.
- get the highest subsamled ycbcr output.
- get the lowest subsamled ycbcr
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference,
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.
This patch moves the
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of
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
This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
structure. While handling the EDID from HDMI 2.0 sinks, its important to
know if the source is capable of handling YCBCR 420 outputs or not, so that
a lot of work can be done/bypassed based on this information. One such
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.
First 2 patches,
== Series Details ==
Series: drm/i915: Wait for concurrent global resets to complete (rev2)
URL : https://patchwork.freedesktop.org/series/25994/
State : success
== Summary ==
Series 25994v2 drm/i915: Wait for concurrent global resets to complete
If we enter i915_handle_error() a second time and a global reset is
already in progress, we can simply wait for completion of the first
reset. Currently we exit earlier prior to the actual reset being
performed -- the worst of both worlds!
v2: Plug into the existing reset_queue, and remember that
On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> Problem:
> While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immidietly follwoing an atomic_commit.
s/immidietly/immediately/g
s/follwoing/following/g
> After dumping the atomic state I relized that in
On Mon, 19 Jun 2017 08:38:32 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > My suggestion was to use vfio device fd for this ioctl and have
> > dmabuf
> > mgr fd as member in above query_plane structure, for region type it
> > would be set to 0.
>
> Region type should be
On Mon, 19 Jun 2017 08:34:13 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > So perhaps this becomes:
> >
> > struct vfio_device_gfx_plane_info {
> > __u64 start;
> > __u64 drm_format_mod;
> > __u32 drm_format;
> > __u32 width;
> > __u32 height;
> > __u32
Link to FDO regression list:
Highlights:
- 22 bugs open during the week
- 20 bugs closed during the week
- 359 total bugs remain open
- 16 bugs labeled ReadyForDev during the week
- 88 total bugs labeled ReadyForDev remain open
Details:
- Bugs open during the week
== Series Details ==
Series: drm/i915: Wait for concurrent global resets to complete
URL : https://patchwork.freedesktop.org/series/25994/
State : success
== Summary ==
Series 25994v1 drm/i915: Wait for concurrent global resets to complete
If we enter i915_handle_error() a second time and a global reset is
already in progress, we can simply wait for completion of the first
reset. Currently we exit earlier prior to the actual reset being
performed -- the worst of both worlds!
Signed-off-by: Chris Wilson
On 14/06/17 16:18, Joonas Lahtinen wrote:
On ke, 2017-06-14 at 11:27 +, Patchwork wrote:
== Series Details ==
Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment
URL : https://patchwork.freedesktop.org/series/25772/
State : success
Janie & Daniel,
This patch could be
On Mon, Jun 19, 2017 at 05:50:28PM +0530, Mahesh Kumar wrote:
> Hi Ville,
>
> Thanks for review
>
>
> On Friday 16 June 2017 07:47 PM, Ville Syrjälä wrote:
> > On Wed, Jun 07, 2017 at 03:19:05PM +0530, Mahesh Kumar wrote:
> >> In previous GEN default Interlace mode enabled is IF-ID mode, but
Quoting Michel Thierry (2017-06-15 21:18:12)
> @@ -2992,10 +3014,8 @@ void i915_gem_reset_finish(struct drm_i915_private
> *dev_priv)
>
> lockdep_assert_held(_priv->drm.struct_mutex);
>
> - for_each_engine(engine, dev_priv, id) {
> - tasklet_enable(>irq_tasklet);
>
Tested OK, also NOTE that this fixes bug 97975
/Marta
> -Original Message-
> From: ville.syrj...@linux.intel.com [mailto:ville.syrj...@linux.intel.com]
> Sent: Monday, June 19, 2017 3:29 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lofstedt, Marta
> Subject:
Quoting Michel Thierry (2017-06-15 21:18:12)
> int i915_gem_reset_prepare(struct drm_i915_private *dev_priv)
> {
> struct intel_engine_cs *engine;
> + struct drm_i915_gem_request *request;
> enum intel_engine_id id;
> int err = 0;
>
> - /* Ensure irq handler
From: Ville Syrjälä
Don't use the display mode size to determine the cursor fb size. That
will lead to a framebuffer with a stride that the cursor plane won't
support. Just use the max cursor size as the fb size instead.
This started to trip up after i915 started
Quoting Tvrtko Ursulin (2017-06-19 13:06:18)
>
> On 16/06/2017 17:02, Chris Wilson wrote:
> > @@ -520,7 +511,8 @@ static inline int use_cpu_reloc(const struct
> > reloc_cache *cache,
> > static int eb_reserve_vma(const struct i915_execbuffer *eb,
> > struct i915_vma
Hi Ville,
Thanks for review
On Friday 16 June 2017 07:47 PM, Ville Syrjälä wrote:
On Wed, Jun 07, 2017 at 03:19:05PM +0530, Mahesh Kumar wrote:
In previous GEN default Interlace mode enabled is IF-ID mode, but IF-ID
mode has many limitations in SKL. This mode doesn't support y-tiling,
90-270
On 16/06/2017 17:02, Chris Wilson wrote:
When userspace is doing most of the work, avoiding relocs (using
NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we
still spend a lot of time processing the arrays in execbuf, even though
we now should have nothing to do most of the
On Fri, Jun 16, 2017 at 04:43:41PM -0700, Rodrigo Vivi wrote:
> When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake
> workarounds.")
> Mika pointed out that Spec tells those 2 workarounds were not needed.
>
> So when double checking I confirmed that and also that by Spec they
== Series Details ==
Series: series starting with [1/2] drm/i915: Simplify intel_engines_init (rev2)
URL : https://patchwork.freedesktop.org/series/25907/
State : success
== Summary ==
Series 25907v2 Series without cover letter
From: Tvrtko Ursulin
Since bb8f0f5abdd7 ("drm/i915: Split intel_engine allocation
and initialisation") intel_info->num_rings is set early in the
load sequence and so available to be used direclty in the 2nd
load phase.
Signed-off-by: Tvrtko Ursulin
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani Nikula
> Sent: Friday, June 16, 2017 1:56 AM
> To: Zanoni, Paulo R ; intel-
> g...@lists.freedesktop.org
> Cc: Zanoni, Paulo R
>
This adds two new tests: common-hpd-after-suspend and
common-hpd-after-hibernate that are aimed at testing HPD change during
suspend/hibernate for both DP and HDMI, at the same time.
The interest in bringing this test up is to reduce the time spent in
testing, with the downside of less precision
On Fri, 16 Jun 2017, Rodrigo Vivi wrote:
> Paulo noticed that we were missing few bits clear
> before writing values back to the register on
> these RMW MMIO operations.
>
> v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
>
> Fixes: cf54ca8bc567 ("drm/i915/cnl:
Hi,
On Fri, 2017-06-16 at 19:28 -0400, Lyude Paul wrote:
> On Fri, 2017-06-16 at 17:17 +0300, Paul Kocialkowski wrote:
> > This adds two new tests: common-hpd-after-suspend and
> > common-hpd-after-hibernate that are aimed at testing HPD change during
> > suspend/hibernate for both DP and HDMI,
On Mon, 15 May 2017, Jani Nikula wrote:
> Continuing [1] for v4.12-rc1
>
> The following commits have been marked as Cc: stable or fixing something
> in v4.12-rc1 or earlier, but failed to cherry-pick to
> drm-intel-fixes. Please see if they are worth backporting, and
On Thu, 15 Jun 2017, Chris Wilson wrote:
> We need to keep track of the last location we ask the hw to read up to
> (RING_TAIL) separately from our last write location into the ring, so
> that in the event of a GPU reset we do not tell the HW to proceed into
> a
Hi all,
Final pile of features for 4.13
New uabi:
- batch bo in first slot, for faster execbuf assembly in userspace
(Chris Wilson)
- (sub)slice getparam, needed for mesa perf support (Robert Bragg)
First pile of patches for cnl/cfl support, maintained by Rodrigo but
with lots of
Op 15-06-17 om 19:23 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Attach the tv_format property to the SDVO connector instead of passing
> a '0' in place of the pointer to the property. This got broken when
> the SDVO connector properties were
Hi,
> So perhaps this becomes:
>
> struct vfio_device_gfx_plane_info {
> __u64 start;
> __u64 drm_format_mod;
> __u32 drm_format;
> __u32 width;
> __u32 height;
> __u32 stride;
> __u32 size;
> __u32 x_pos;
> __u32 y_pos;
> };
Looks good.
Hi,
> My suggestion was to use vfio device fd for this ioctl and have
> dmabuf
> mgr fd as member in above query_plane structure, for region type it
> would be set to 0.
Region type should be DRM_PLANE_TYPE_PRIMARY
> Can't mmap that page to get surface information. There is no way to
>
76 matches
Mail list logo