== Series Details ==
Series: Link Training failure handling by sending Hotplug Uevent (rev5)
URL : https://patchwork.freedesktop.org/series/16399/
State : failure
== Summary ==
Series 16399v5 Link Training failure handling by sending Hotplug Uevent
https://patchwork.freedesktop.org/api/1.0/ser
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure and limits the max
link_rate and lane_count values to these fallb
== Series Details ==
Series: Add Automation Support for DP Compliance Testing (Rev 2)
URL : https://patchwork.freedesktop.org/series/16591/
State : failure
== Summary ==
Series 16591v1 Add Automation Support for DP Compliance Testing (Rev 2)
https://patchwork.freedesktop.org/api/1.0/series/165
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color v
This addresses all the review comments from the earlier patch series:
https://patchwork.freedesktop.org/series/15771/
DP 1.2 compliance testing can be acheived using DPR-120's CTS suite.
This compliance unit sends a short pulse to initiate link training
and video pattern generation compliance test
v2:
* Add all the other DP Complianec TEST register defs (Jani Nikula)
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
include/drm/drm_dp_helper.h | 58 +
1 file changed, 58 ins
This patch does not change anything functionally, just cleans up
the DP compliance related variables and stores them all together
in a separate struct intel_dp_compliance. There is another struct
intel_dp_compliance_data to store all the test data. This makes it easy to
reset the compliance variabl
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is se
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> This patch adds support to decode system memory bandwidth
> which will be used for arbitrated display memory percentage
> calculation in GEN9 based system.
>
> Changes from v1:
> - Address comments from Paulo
> - implement decode functi
On Thu, Dec 08, 2016 at 03:02:19PM -0800, anushasr wrote:
> From: Peter Antoine
>
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You cannot
== Series Details ==
Series: HuC Loading Patches
URL : https://patchwork.freedesktop.org/series/16584/
State : success
== Summary ==
Series 16584v1 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/16584/revisions/1/mbox/
fi-bdw-5557u total:247 pass:233 dwarn:0 dfa
From: Peter Antoine
Add debugfs entry for HuC loading status check.
v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
v11: rebased on top of drm-tip
v12: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by
From: Anusha Srivatsa
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before
From: Anusha Srivatsa
This patch adds the HuC Loading for the BXT by using
the updated file construction.
Version 1.7 of the HuC firmware.
v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/
From: Peter Antoine
This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after i
From: Peter Antoine
Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw'
From: Peter Antoine
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
v2: rebased on-top of drm-intel-nigh
From: Peter Antoine
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5:
These patches add HuC loading support. The GuC is required to
authenticate the HuC. The userspace patches that check for a
fully loaded HuC firmware and use it can be found at:
https://lists.freedesktop.org/archives/libva/2016-September/004554.html
https://lists.freedesktop.org/archives/libva/201
From: Anusha Srivatsa
This patch adds the support to load HuC on KBL
Version 2.0
v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/intel_huc_loader.c | 16
1 file changed, 1
Hi Daniel,
On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> > Atomic drivers may set properties like rotation on the same fb, which
> > may require a call to prepare_fb even when framebuffer stays identical.
> >
> > Inste
On Thu, Dec 08, 2016 at 04:52:24PM +, Tvrtko Ursulin wrote:
> Idea for another late test:
>
> for (offset = 0; offset < 0x4; offset++) {
> fw_domain = intel_uncore_forcewake_for_reg(dev_priv, { .reg =
> offset }, FW_REG_READ | FW_REG_WRITE);
> if (WARN_ON(fw_domain & ~dev_priv-
On Thu, Dec 08, 2016 at 11:51:30PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> >
On Thu, Dec 08, 2016 at 11:46:02PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > If link training fails, then we need to fallback to lower
> > link rate first and if link training fails at RBR, then
> > fallback to lower lane count.
> > This function finds the next lowe
On Thu, 08 Dec 2016, Daniel Vetter wrote:
> It's been years since drm-intel had only one maintainer, and the
> primary use-case for dim ub was only to sync between machines. Update
> the docs to reflect this, to avoid misleading committers. Also update
> the maintainer-tools branch, which is somet
On Tue, 06 Dec 2016, Manasi Navare wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
>
On Tue, 06 Dec 2016, Manasi Navare wrote:
> If link training fails, then we need to fallback to lower
> link rate first and if link training fails at RBR, then
> fallback to lower lane count.
> This function finds the next lower link rate/lane count
> value after link training failure and limits t
Daniel, can we merge this patch?
It has no dependency on other link train patches,
it is just a clean up for the existing driver code that
uses max link rate and lane count values.
Other link train patches have dependency on this thats why
it was part of the series.
But it would be great if this ge
On Thu, Dec 08, 2016 at 11:23:39PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > Sink's capabilities are advertised through DPCD registers and get
> > updated only on hotplug. So they should be computed only once in the
> > long pulse handler and saved off in intel_dp s
On Tue, 06 Dec 2016, Manasi Navare wrote:
> Sink's capabilities are advertised through DPCD registers and get
> updated only on hotplug. So they should be computed only once in the
> long pulse handler and saved off in intel_dp structure for the use
> later. For this reason two new fields max_sink
On Thu, Dec 08, 2016 at 05:38:34PM +, Tvrtko Ursulin wrote:
>
> On 07/12/2016 13:58, Chris Wilson wrote:
> >Third retroactive test, make sure that the seqno waiters are woken.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 171
> > +++
On Thu, 08 Dec 2016, Ville Syrjälä wrote:
> On Thu, Dec 08, 2016 at 04:58:21PM +0100, Daniel Vetter wrote:
>> On Thu, Dec 08, 2016 at 11:11:50AM +0200, Jani Nikula wrote:
>> > On Thu, 08 Dec 2016, Jani Nikula wrote:
>> > > On Thu, 08 Dec 2016, Jani Nikula wrote:
>> > >> This lets us use IS_MOBIL
On Mon, 2016-12-05 at 18:59 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v6,1/2] drm/i915/gen9: Fix PCODE polling during
> CDCLK change notification
> URL : https://patchwork.freedesktop.org/series/16375/
> State : success
>
> == Summary ==
>
> Series 16375
On Thu, Dec 08, 2016 at 05:45:23PM +, Tvrtko Ursulin wrote:
>
> On 07/12/2016 13:58, Chris Wilson wrote:
> >Just a simple move to avoid a forward declaration.
>
> Patch subject is wrong - you are moving
> intel_logical_ring_alloc_request_extras.
I moved what I said, what diff shows is the op
== Series Details ==
Series: Link Training failure handling by sending Hotplug Uevent (rev4)
URL : https://patchwork.freedesktop.org/series/16399/
State : failure
== Summary ==
Series 16399v4 Link Training failure handling by sending Hotplug Uevent
https://patchwork.freedesktop.org/api/1.0/ser
== Series Details ==
Series: Link Training failure handling by sending Hotplug Uevent (rev3)
URL : https://patchwork.freedesktop.org/series/16399/
State : failure
== Summary ==
Series 16399v3 Link Training failure handling by sending Hotplug Uevent
https://patchwork.freedesktop.org/api/1.0/ser
Thanks Sean.
Done, fixed the typo and submitted the patch.
Regards
Manasi
On Thu, Dec 08, 2016 at 02:36:25PM -0500, Sean Paul wrote:
>
>
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 72fa5b2..34eddb9 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requireme
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 72fa5b2..34eddb9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,22 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>
== Series Details ==
Series: drm/i915/psr: report psr2 status from psr2_ctl
URL : https://patchwork.freedesktop.org/series/16577/
State : success
== Summary ==
Series 16577v1 drm/i915/psr: report psr2 status from psr2_ctl
https://patchwork.freedesktop.org/api/1.0/series/16577/revisions/1/mbox/
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requireme
Reads psr2 enable status from EDP_PSR2_CTL
Cc: Rodrigo Vivi
Signed-off-by: vathsala nagaraju
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a74
Hi Jani,
Could you please review this patch?
This patch was changed a bit from the last time you reviewed it
based on feedback from Sean Paul that the driver need not
validate the modes and prune the mode on link training failure.
Instead it should just send the hotplug uevent after setting link s
Hi Jani,
This patch uses the simplified fallback logic where
if link train fails, we first lower the max sink link rate
to a lower value until it reaches RBR keeping the max lane count
unchanged and then lower the lane count and set max lane count to
this lowered lane count and resetting the link
Jani,
Could you please review this patch? This is the patch that
calculates the max sink link rate and max sink lane count only
once at hotplug and then anytime the max lane count and common rates are
requested,
the helper functions use these values.
This simplifies the fallback logic since we ca
It's been years since drm-intel had only one maintainer, and the
primary use-case for dim ub was only to sync between machines. Update
the docs to reflect this, to avoid misleading committers. Also update
the maintainer-tools branch, which is something Paulo's script also
does.
Motivated because P
On Thu, Dec 08, 2016 at 05:58:44PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2016 at 07:51:21PM -0800, Manasi Navare wrote:
> > Ville,
> > You mentioned that this detect_done should be set to false also
> > in the resume case so in i915_display_resume where it calls
> > intel_hpd_init that even
On 07/12/2016 13:58, Chris Wilson wrote:
Just a simple move to avoid a forward declaration.
Patch subject is wrong - you are moving
intel_logical_ring_alloc_request_extras.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 132 +++
1 f
On 07/12/2016 13:58, Chris Wilson wrote:
i915_vma_move_to_active() requires the struct_mutex for serialisation
with retirement, so mark it up with lockdep_assert_held().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --gi
On Thu, 2016-12-08 at 19:22 +0200, Saarinen, Jani wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Don't clflush before release phys object
> > URL : https://patchwork.freedesktop.org/series/16569/
> > State : warning
> >
> > == Summary ==
> >
> > Series 16569v1 drm/i915: Don't clflus
On 07/12/2016 13:58, Chris Wilson wrote:
Third retroactive test, make sure that the seqno waiters are woken.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 171 +++
1 file changed, 171 insertions(+)
diff --git a/drivers/gpu/drm/i915/int
> == Series Details ==
>
> Series: drm/i915: Don't clflush before release phys object
> URL : https://patchwork.freedesktop.org/series/16569/
> State : warning
>
> == Summary ==
>
> Series 16569v1 drm/i915: Don't clflush before release phys object
> https://patchwork.freedesktop.org/api/1.0/se
== Series Details ==
Series: drm/i915: Don't clflush before release phys object
URL : https://patchwork.freedesktop.org/series/16569/
State : warning
== Summary ==
Series 16569v1 drm/i915: Don't clflush before release phys object
https://patchwork.freedesktop.org/api/1.0/series/16569/revisions
On 07/12/2016 18:52, Chris Wilson wrote:
In addition to just testing the fw table we load, during the initial
mock testing we can test that all tables are valid (so the testing is
not limited to just the platforms that load that particular table).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
On Thu, Dec 08, 2016 at 04:58:21PM +0100, Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 11:11:50AM +0200, Jani Nikula wrote:
> > On Thu, 08 Dec 2016, Jani Nikula wrote:
> > > On Thu, 08 Dec 2016, Jani Nikula wrote:
> > >> This lets us use IS_MOBILE() for distinguishing the desktop and mobile
> >
On Thu, Dec 08, 2016 at 06:17:28PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 08, 2016 at 08:45:31AM +, Chris Wilson wrote:
> > On Wed, Dec 07, 2016 at 07:28:10PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Use two-dimensional arrays and named initial
== Series Details ==
Series: drm/i915: Reorder phys backing storage release (rev3)
URL : https://patchwork.freedesktop.org/series/16468/
State : success
== Summary ==
Series 16468v3 drm/i915: Reorder phys backing storage release
https://patchwork.freedesktop.org/api/1.0/series/16468/revisions/
On Thu, Dec 08, 2016 at 04:12:37PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-12-08 às 17:00 +0100, Daniel Vetter escreveu:
> > On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote:
> > >
> > > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> > > >
> > > > This series impleme
On Thu, Dec 08, 2016 at 08:45:31AM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 07:28:10PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Use two-dimensional arrays and named initializers to make the
> > overlay filter coefficient tables easier to parse for hu
Em Qui, 2016-12-08 às 17:00 +0100, Daniel Vetter escreveu:
> On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote:
> >
> > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> > >
> > > This series implements following set of functionality
> > > Implement IPC WA's for Broxton/KBL
On Thu, Dec 08, 2016 at 08:35:48AM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 07:28:07PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Replace the use of crtc->mode.h/vdisplay with the more appropriate
> > config->pipe_src_w/h.
>
> I'll ask the dumb questi
When we teardown the backing storage for the phys object, we copy from
the coherent contiguous block back to the shmemfs object, clflushing as
we go. Trying to clflush the invalid sg beforehand just oops and would
be redundant (due to it already being coherent, and clflushed
afterwards).
Reported-
On Thu, Dec 08, 2016 at 06:46:49PM +0800, Wang Elaine wrote:
> From: Elaine Wang
>
> Some platforms only have VCS ring in VDBox. To avoid accessing the
> non-existent rings or display registers, check the ring_mask
> and num_pipes in gen8 IRQ install and reset functions.
>
> Cc: Joonas Lahtinen
On Thu, Dec 08, 2016 at 08:50:17AM -0700, Shuah Khan wrote:
> On 12/07/2016 07:09 AM, Chris Wilson wrote:
> > On Wed, Dec 07, 2016 at 01:58:19PM +, Chris Wilson wrote:
> >> Although being a GPU driver most functionality of i915.ko depends upon
> >> real hardware, many of its internal interfaces
On Wed, Dec 07, 2016 at 07:16:13PM -0500, Lyude wrote:
> We've had support for universal planes since kernel version 3.15, so
> there's not really a good reason to try supporting drivers that lack
> plane support now. As well, the current has_universal_planes logic is
> broken anyway as it makes th
On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote:
> Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> > This series implements following set of functionality
> > Implement IPC WA's for Broxton/KBL
> > Enable IPC in supported platforms
> > Convert WM calculation to
On Wed, Dec 07, 2016 at 07:51:21PM -0800, Manasi Navare wrote:
> Ville,
> You mentioned that this detect_done should be set to false also
> in the resume case so in i915_display_resume where it calls
> intel_hpd_init that eventually schedules the hpd_poll_init_work and
> calls drm_helper_hpd_irq_ev
On Thu, Dec 08, 2016 at 11:11:50AM +0200, Jani Nikula wrote:
> On Thu, 08 Dec 2016, Jani Nikula wrote:
> > On Thu, 08 Dec 2016, Jani Nikula wrote:
> >> This lets us use IS_MOBILE() for distinguishing the desktop and mobile
> >> parts instead of duplicating PCI IDs in Pineview specific checks.
> >
On Wed, Dec 07, 2016 at 09:40:33PM +, Robert Bragg wrote:
> This adds a 'Perf' section to i915.rst with the following sub sections:
> - Overview
> - Comparison with Core Perf
> - i915 Driver Entry Points
> - i915 Perf Stream
> - i915 Perf Observation Architecture Stream
> - All i915 Perf Intern
== Series Details ==
Series: drm/atomic: Remove drm_atomic_helper_framebuffer_changed
URL : https://patchwork.freedesktop.org/series/16561/
State : success
== Summary ==
Series 16561v1 drm/atomic: Remove drm_atomic_helper_framebuffer_changed
https://patchwork.freedesktop.org/api/1.0/series/165
> == Series Details ==
>
> Series: drm/edid: Don't print an error if the checksum of a CEA block is wrong
> URL : https://patchwork.freedesktop.org/series/16556/
> State : warning
>
> == Summary ==
>
> Series 16556v1 drm/edid: Don't print an error if the checksum of a CEA block
> is
> wrong
>
On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote:
> The current api doesn't take into account that whenever properties like
> rotation or z-pos change we have to wait for vblank. To make sure
> that we wait correctly, err on the side of caution and wait whenever
> a plane is added
On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> Atomic drivers may set properties like rotation on the same fb, which
> may require a call to prepare_fb even when framebuffer stays identical.
>
> Instead of handling all the special cases in the core, let the driver
> decide wh
On Thu, Dec 08, 2016 at 02:45:26PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we know in advance
> how many there can be. Also stop re-using new_crtc_state->enable,
> we can now simply set a bitmask with crtc_crtc_mask.
> ---
> drivers/gpu/drm/drm_atomic_
On Thu, Dec 08, 2016 at 02:45:24PM +0100, Maarten Lankhorst wrote:
> When DPMS was introduced to atomic, vblanks only worked when the crtc
> was enabled and active. wait_for_vblanks were not converted to check for
> crtc_state->active, which may cause an attempt for vblank_get to fail.
>
> This is
On Mon, Dec 05, 2016 at 12:42:11PM -0800, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> >Sent: Thursday, December 1, 2016 5:11 AM
> >To: Srivatsa, Anusha ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx
On Thu, Dec 08, 2016 at 05:05:54PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's possible we can't reach th
== Series Details ==
Series: Claw back the IS_ optimisation (rev2)
URL : https://patchwork.freedesktop.org/series/16544/
State : warning
== Summary ==
Series 16544v2 Claw back the IS_ optimisation
https://patchwork.freedesktop.org/api/1.0/series/16544/revisions/2/mbox/
Test drv_module_reload:
On Tue, 06 Dec 2016, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduce
== Series Details ==
Series: drm/edid: Don't print an error if the checksum of a CEA block is wrong
URL : https://patchwork.freedesktop.org/series/16556/
State : warning
== Summary ==
Series 16556v1 drm/edid: Don't print an error if the checksum of a CEA block is
wrong
https://patchwork.freed
In commit a4f5ea64f0a8 ("drm/i915: Refactor object page API"), I
reordered the object->pages teardown to be more friendly wrt to a
separate obj->mm.lock. However, I overlooked the phys object and left it
with a dangling use-after-free of its phys_handle. Move the allocation
of the phys handle to ge
On Thu, Dec 08, 2016 at 04:18:50PM +0200, Imre Deak wrote:
> Yep. Btw, I also pondered if we could just make this part of
> wait_for(), but not sure if we want the corresponding code increase
> (and for -stable we'd want a minimal diff). It's not required in other
> cases, although it could speed u
Hi Ville,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20161208]
[cannot apply to v4.9-rc8]
[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/ville
On to, 2016-12-08 at 14:02 +, Chris Wilson wrote:
> On Mon, Dec 05, 2016 at 06:27:37PM +0200, Imre Deak wrote:
> > commit 848496e5902833600f7992f4faa82dc1546051ba
> > Author: Ville Syrjälä
> > Date: Wed Jul 13 16:32:03 2016 +0300
> >
> > drm/i915: Wait up to 3ms for the pcu to ack the c
== Series Details ==
Series: drm/i915: Respect ring_mask and num_pipes when install IRQ
URL : https://patchwork.freedesktop.org/series/16547/
State : success
== Summary ==
Series 16547v1 drm/i915: Respect ring_mask and num_pipes when install IRQ
https://patchwork.freedesktop.org/api/1.0/series
On 08/12/2016 14:00, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
On 08/12/2016 13:37, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
On 08/12/2016 10:46, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Instead of listi
On Thu, Dec 08, 2016 at 03:03:29PM +0200, Joonas Lahtinen wrote:
> On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote:
> > Currently the reference for the dmabuf->obj is incremented for the
> > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace
> > interface), but is released in
On 8 December 2016 at 13:45, Maarten Lankhorst
wrote:
> Do something similar to vc4, only allow updating the cursor state
> in-place through a fastpath when the watermarks are unaffected. This
> will allow cursor movement to be smooth, but changing cursor size or
> showing/hiding cursor will still
On Thu, Dec 08, 2016 at 11:57:25AM +, Robert Bragg wrote:
> On Thu, Dec 8, 2016 at 12:17 AM, Daniel Vetter wrote:
> >
> > On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote:
> > > This is still missing corresponding documentation changes, and I haven't
> > > moved anything to drm_pri
On Mon, Dec 05, 2016 at 06:27:37PM +0200, Imre Deak wrote:
> commit 848496e5902833600f7992f4faa82dc1546051ba
> Author: Ville Syrjälä
> Date: Wed Jul 13 16:32:03 2016 +0300
>
> drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> SKL
>
> increased the timeout to match
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
> On 08/12/2016 13:37, Jani Nikula wrote:
>> On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
>>> On 08/12/2016 10:46, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of listing them individua
This function is now completely unused, zap it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 35 ---
include/drm/drm_atomic_helper.h | 3 ---
2 files changed, 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/d
drm_atomic_helpers use framebuffer_changed to skip some vblank waits
in case properties don't change. This may skip vblank waits also when
properties like rotation are changed. Fix this by always waiting for
vblank if planes are added to the state, and always calling prepare_fb
even when fb stays t
The current api doesn't take into account that whenever properties like
rotation or z-pos change we have to wait for vblank. To make sure
that we wait correctly, err on the side of caution and wait whenever
a plane is added to state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomi
Stop relying on a per crtc_state last_vblank_count, we know in advance
how many there can be. Also stop re-using new_crtc_state->enable,
we can now simply set a bitmask with crtc_crtc_mask.
---
drivers/gpu/drm/drm_atomic_helper.c | 29 +++--
include/drm/drm_crtc.h
Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.
Only moving and chang
When DPMS was introduced to atomic, vblanks only worked when the crtc
was enabled and active. wait_for_vblanks were not converted to check for
crtc_state->active, which may cause an attempt for vblank_get to fail.
This is probably harmless, but convert from enable to active anyway.
Signed-off-by:
Atomic drivers may set properties like rotation on the same fb, which
may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver
decide when prepare_fb and cleanup_fb are noops.
Signed-off-by: Maarten Lankhorst
--
On 08/12/2016 13:37, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
On 08/12/2016 10:46, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Instead of listing them individually we can generate them
using the new i915_platforms.h header.
Also
1 - 100 of 165 matches
Mail list logo