On Thu, Feb 11, 2016 at 09:45:17AM +0200, Oleksandr Natalenko wrote:
> Daniel,
>
> I do confirm that this hacky patch:
>
> https://lkml.org/lkml/2016/1/19/637
>
> works around my issue. I understand that this is improper fix, so let me
> know how could I debug my issue further.
Please boot with
On Thu, Feb 11, 2016 at 09:25:35AM +0200, David Weinehall wrote:
> This patch aims to create a separate lib for power management related
> helpers. Initially it only contains code that modify settings for
> external components (to handle components with default settings that
> prevents entering dee
On Wed, Feb 10, 2016 at 05:37:20PM -0800, Marc Herbert wrote:
> On 10/02/16 06:27, Ville Syrjälä wrote:
> > On Tue, Feb 09, 2016 at 04:28:27PM -0800, clinton.a.tay...@intel.com wrote:
> >> From: Clint Taylor
> >>
> >> Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
> >> to s
On Wed, Feb 10, 2016 at 11:39:41AM -0800, Matt Roper wrote:
> On Wed, Jan 27, 2016 at 09:40:01PM +0530, Shobhit Kumar wrote:
> > From: "Kumar, Mahesh"
> >
> > if downscaling is enabled plane data rate increases according to scaling
> > amount. take scaling amount under consideration while calcula
On Mon, Feb 01, 2016 at 09:45:25AM +, Dave Gordon wrote:
> On 30/01/16 11:28, Chris Wilson wrote:
> >On Sat, Jan 30, 2016 at 10:56:27AM +, Chris Wilson wrote:
> >>On Fri, Jan 29, 2016 at 07:19:27PM +, Dave Gordon wrote:
> >>>1. add call to i915_gem_context_fini() to deallocate the defau
On Wed, Feb 03, 2016 at 06:05:01AM -0800, Matt Roper wrote:
> On Wed, Feb 03, 2016 at 01:16:38PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 02, 2016 at 10:06:51PM -0800, Matt Roper wrote:
> > > Due to our lack of two-step watermark programming, our driver has
> > > historically pretended that the
On Mon, Feb 01, 2016 at 11:00:07AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We know this never runs from interrupt context so
> don't need to use the flags variant.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c | 6 ++
Daniel,
I've already tried Ville's patch you've mentioned with no luck.
Kindly find unpatched v4.5-rc3 dmesg with drm debug enabled here: [1]
[1] https://gist.github.com/efb44b7c6bc325978b80
11.02.2016 10:21, Daniel Vetter wrote:
Please boot with drm.debug=0xe and attach the dmesg. Also please
On Mon, Feb 01, 2016 at 02:43:57PM +0100, Maarten Lankhorst wrote:
> Instead of restoring dpms and a flag for whether a temp fb is allocated
> duplicate
> the old plane_state and crtc_state, and restore the members we potentially
> touched.
>
> Signed-off-by: Maarten Lankhorst
Do we have the l
On Mon, Feb 01, 2016 at 02:44:01PM +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/tests/kms_force_connector_basic.c
> b/tests/kms_force_connector_basic.c
> index bd80caeffd82..f827d0008f7b 100644
> --- a/tests/kms_force_connector_basic.c
> +++ b/tests/kms_
On Mon, Feb 01, 2016 at 06:35:33PM +0200, Marius Vlad wrote:
> Allow HDMI EDID injection by making a copy of edid_blob_ptr. When
> disconnecting
> the connector, or forcing a disconnect, the copy will free'd by
> intel_hdmi_unset_edid().
>
> Signed-off-by: Marius Vlad
> ---
> drivers/gpu/drm/i
On Tue, Feb 02, 2016 at 01:05:07PM +0200, Marius Vlad wrote:
> Use the drm_property_blob data for EDID when an blob EDID
> has been supplied over the debugfs interface.
>
> Signed-off-by: Marius Vlad
v2 of patches must have an in-patch changelog of what (and why) stuff
changed.
-Daniel
> ---
>
On Tue, Feb 02, 2016 at 03:03:37PM +0200, Marius Vlad wrote:
> Signed-off-by: Marius Vlad
> ---
> tests/Makefile.sources | 1 +
> tests/kms_hdmi_inject.c | 165
>
> 2 files changed, 166 insertions(+)
> create mode 100644 tests/kms_hdmi_inject.
On Tue, Feb 02, 2016 at 06:25:39PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 02, 2016 at 03:16:37PM +0200, Mika Kahola wrote:
> > From EDID we can read and request higher pixel clock than
> > our HW can support. This set of patches add checks if
> > requested pixel clock is lower than the one suppo
On Tue, Feb 02, 2016 at 03:16:37PM +0200, Mika Kahola wrote:
> From EDID we can read and request higher pixel clock than
> our HW can support. This set of patches add checks if
> requested pixel clock is lower than the one supported by the HW.
> The requested mode is discarded if we cannot support
On Thu, Feb 11, 2016 at 10:54:08AM +0200, Oleksandr Natalenko wrote:
> Daniel,
>
> I've already tried Ville's patch you've mentioned with no luck.
>
> Kindly find unpatched v4.5-rc3 dmesg with drm debug enabled here: [1]
>
> [1] https://gist.github.com/efb44b7c6bc325978b80
That's an IVB. So no
The DMC can incorrectly run off and allow DC states on it's own. We
don't know the root-cause for this yet but this patch makes it more
visible.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_csr.c| 2 ++
drivers/gpu/drm/i915
On Wed, Feb 10, 2016 at 06:32:59PM -0800, Matt Roper wrote:
> Gen9 platforms allow CRTC's to be programmed with a background/canvas
> color below the programmable planes. Let's expose this as a property to
> allow userspace to program a desired value.
>
> This patch is based on earlier work by Ch
On Wed, Feb 10, 2016 at 07:59:05PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Looks like g4x hpd live status bits actually agree with the spec. At
> least they do on the machine I have, and apparently on Nick Bowler's
> g4x as well.
>
> So gm45 may be the only platform
On Tue, Feb 02, 2016 at 02:46:58PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> RPS lock must be taken before the struct_mutex to avoid
> locking inversion. So stop grabbing it for the whole
> powersave initialization and instead only take it during
> the sections which need it.
>
> A
On Tue, Feb 02, 2016 at 11:06:25AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> VMA creation and GEM list management need the big lock.
>
> v2:
>
> Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
>
> Not to mention drm_gem_object_unreference was there in existing
On Tue, Feb 02, 2016 at 02:46:19PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> VMA creation and GEM list management need the big lock.
>
> v2:
>
> Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
>
> Not to mention drm_gem_object_unreference was there in existing
From: Tvrtko Ursulin
We know this never runs from interrupt context so
don't need to use the flags variant.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: Tvrtko Ursulin
VMA creation and GEM list management need the big lock.
v2:
Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall)
Not to mention drm_gem_object_unreference was there in existing
code with no mutex held.
v3:
Some callers of i915_gem_object_create_stolen_for_
From: Tvrtko Ursulin
RPS lock must be taken before the struct_mutex to avoid
locking inversion. So stop grabbing it for the whole
powersave initialization and instead only take it during
the sections which need it.
Also, struct_mutex is not needed any more since dedicated
RPS lock was added in:
From: Tvrtko Ursulin
It does not look like this code needs to wait atomically?
Higher in the call chain it calls the GEM API and I do
not see that the section is under any spin locks or such.
Signed-off-by: Tvrtko Ursulin
Cc: Alex Dai
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_
From: Tvrtko Ursulin
Code does read-modify-write but the read was outside the lock.
It is fine since the caller holds struct mutex, but if we
correct this we open up the opportunity for decreasing the
mutex duration time since the call to ironlake_enable_drps
does not need it any longer since it
From: Tvrtko Ursulin
As the subject says, just to trigger a CI run for some assorted
patches which are all already R-Bed.
Tvrtko Ursulin (5):
drm/i915: Use appropriate spinlock flavour
drm/i915: GEM operations need to be done under the big lock
drm/i915: Fix struct mutex vs. RPS lock inver
On Wed, 10 Feb 2016, "Rogers, Martin" wrote:
> Hi Jani,
>
> I have not submitted a bug yet, because no kernel msgs were produced the
> moment I recreated the issue.
> I used : drm.debug=0x14
>
> Can you suggest something else ?
We want the log anyway to properly identify the machine, outputs,
w
On Wed, Jan 27, 2016 at 02:38:00PM +0100, Daniel Vetter wrote:
> The fake agp driver for the intel graphics gart is only needed for ums
> support. And we ditched that a long time ago:
>
> commit 03dae59c72d8ef6e005f48ba356c863e0587
> Author: Daniel Vetter
> Date: Wed Jul 23 16:27:25 2014 +0
With large apertures we need to use uint64_t for
counts and sizes. commit 0e2071411a4d4e1488a821daf522dffde2809e03
paved way for this but forgot to change the subtest parameters.
v2: Pass correctly to the copy() also (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=93849
Signed-of
On Wed, Feb 10, 2016 at 07:16:03PM +, Rogers, Martin wrote:
> Hi Jani,
>
> I have not submitted a bug yet, because no kernel msgs were produced the
> moment I recreated the issue.
> I used : drm.debug=0x14
That should be drm.debug=14 or drm.debug=0xe
>
> Can you suggest something else ?
>
On Thu, Feb 11, 2016 at 12:31:45PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 27, 2016 at 02:38:00PM +0100, Daniel Vetter wrote:
> > The fake agp driver for the intel graphics gart is only needed for ums
> > support. And we ditched that a long time ago:
> >
> > commit 03dae59c72d8ef6e005f48ba35
From: Tvrtko Ursulin
In GuC mode submitting requests is only putting them into the
GuC queue with the actual submission to hardware following at
some future point. This makes the per engine last context
tracking insufficient for closing the premature context unpin
race.
Instead we need to make r
Patrik Jakobsson writes:
> The DMC can incorrectly run off and allow DC states on it's own. We
> don't know the root-cause for this yet but this patch makes it more
> visible.
>
> Signed-off-by: Patrik Jakobsson
Yes, we definitely need much more state checking and hardening
in this area.
Revie
On Tue, Feb 09, 2016 at 04:28:27PM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
> to set cdclk based on the max required pixel clock based on VCO
> selected.
>
> The vco should be tracked at the atomic le
On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object
On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote:
From: Chris Wilson
This utility function is a companion to i915_gem_object_get_page() that
uses the same cached iterator for the scatterlist to perform fast
sequential lookup of the dma address associated with any page within the
object.
We'll both rename gem_concurrent_all over gem_concurrent_blit
and change gem_concurrent_blit in this changeset. To make
this easier to follow we first do the the rename.
Signed-off-by: David Weinehall
---
tests/gem_concurrent_blit.c | 1548 ++-
1 file chan
Until now we've had no unified way to handle slow/combinatorial tests.
Most of the time we don't want to run slow/combinatorial tests, so this
should remain the default, but when we do want to run such tests,
it has been handled differently in different tests.
This patch adds an --all command line
When gem_concurrent_blit was converted to use the new common framework
for choosing whether or not to include slow/combinatorial tests,
gem_concurrent_all became superfluous. This patch removes it.
Signed-off-by: David Weinehall
---
tests/Makefile.sources |1 -
tests/gem_concurrent_all.
Some subtests are not run by default, for various reasons;
be it because they're only for debugging, because they're slow,
or because they are not of high enough quality.
This patch aims to introduce a common mechanism for categorising
the subtests and introduces a flag (--all) that runs/lists all
Ville,
here is another dmesg: [1]
I've reconnected HDMI cable three times.
Forgot to note, it is HDMI monitor plugged into machine's DVI with
HDMI-DVI cable. I guess this should matter as well.
[1] https://gist.github.com/7057ea8512b9aa7ee5bd
11.02.2016 11:26, Ville Syrjälä написав:
On Thu
On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as oth
Op 11-02-16 om 09:59 schreef Daniel Vetter:
> On Mon, Feb 01, 2016 at 02:44:01PM +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> diff --git a/tests/kms_force_connector_basic.c
>> b/tests/kms_force_connector_basic.c
>> index bd80caeffd82..f827d0008f7b 100644
>> --- a/
On 04/02/16 09:30, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
The BIOS RapidStartTechnology may corrupt the stolen memory across S3
suspend due to unalarmed hibernation, in which case we will not be able
to preserve the User data stored in the stolen region. Hence this patc
On 29/01/16 16:49, Chris Wilson wrote:
intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait
upon a full ring to advance). Don't emit an error for this.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 fil
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, February 11, 2016 11:21 AM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 0/6] Check pixel clock when setting mode
>
> O
On 29/01/16 16:49, Chris Wilson wrote:
As we add the VMA to the request early, it may be cancelled during
execbuf reservation. This will leave the context object pointing to a
I don't get it, request is created after the reservation.
dangling request; i915_wait_request() simply skips the wa
On Thu, Feb 11, 2016 at 01:09:33PM +0200, David Weinehall wrote:
> +enum {
> + /* The set of tests run if nothing else is specified */
> + SUBTEST_TYPE_NORMAL = 1 << 0,
> + /* Basic Acceptance Testing set */
> + SUBTEST_TYPE_BASIC = 1 << 1,
> + /* Tests that are very slow */
> +
On 11/01/16 10:45, Chris Wilson wrote:
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context
On Thu, Feb 11, 2016 at 01:20:46PM +, Tvrtko Ursulin wrote:
>
>
> On 11/01/16 10:45, Chris Wilson wrote:
> >By tracking the iomapping on the VMA itself, we can share that area
> >between multiple users. Also by only revoking the iomapping upon
> >unbinding from the mappable portion of the GGT
On Mon, Feb 01, 2016 at 09:38:02AM +, Dave Gordon wrote:
> On 30/01/16 10:50, Chris Wilson wrote:
> >On Fri, Jan 29, 2016 at 07:19:26PM +, Dave Gordon wrote:
> >>1. Fix intel_cleanup_ring_buffer() to handle the error cleanup
> >>case where the ringbuffer has been allocated but map-and-p
On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote:
> On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote:
> > From: Nick Hoath
> >
> > Swap the order of context & engine cleanup, so that contexts are cleaned
> > up first, and *then* engines. This is a more sensible order anyway
On Thu, Feb 11, 2016 at 01:04:14PM +, Chris Wilson wrote:
> On Thu, Feb 11, 2016 at 01:09:33PM +0200, David Weinehall wrote:
> > +enum {
> > + /* The set of tests run if nothing else is specified */
> > + SUBTEST_TYPE_NORMAL = 1 << 0,
> > + /* Basic Acceptance Testing set */
> > + SUBTE
On Thu, Feb 11, 2016 at 01:16:53PM +0200, Oleksandr Natalenko wrote:
> Ville,
>
> here is another dmesg: [1]
>
> I've reconnected HDMI cable three times.
>
> Forgot to note, it is HDMI monitor plugged into machine's DVI with
> HDMI-DVI cable. I guess this should matter as well.
Shouldn't reall
On 11/02/16 13:29, Chris Wilson wrote:
On Thu, Feb 11, 2016 at 01:20:46PM +, Tvrtko Ursulin wrote:
On 11/01/16 10:45, Chris Wilson wrote:
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from th
On Mon, Feb 01, 2016 at 02:44:02PM +0100, Maarten Lankhorst wrote:
> This is another step in removing legacy state.
>
> Signed-off-by: Maarten Lankhorst
Patches 2,3,4,6 lgtm.
Reviewed-by: Ville Syrjälä
Though I'd still prefer some locking asserts to avoid having to go
double check all the call
From: Ville Syrjälä
intel_digital_port_connected() lacks one 'else'. There's no
actual harm in not having it since each branch has an unconditional
return, so it can't accidentally end up in taking two branches instead
of just the one. But let's be consistent and add the 'else' anyway.
Signed-of
Hi,
Thanks for the review comments. Addressing them in next version.
On Thursday 04 February 2016 07:24 PM, Jani Nikula wrote:
On Wed, 03 Feb 2016, Ramalingam C wrote:
From: Uma Shankar
During Charging OS mode, mipi display was blanking.This is
because during driver load, though encoder, co
Chris Wilson writes:
> On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote:
>> On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote:
>> > From: Nick Hoath
>> >
>> > Swap the order of context & engine cleanup, so that contexts are cleaned
>> > up first, and *then* engines. This i
On Thursday 04 February 2016 06:43 PM, Jani Nikula wrote:
On Wed, 03 Feb 2016, Ramalingam C wrote:
From: Deepak M
The bpp value which is used while calulating the txbyteclkhs values
should be wrt the pixel format value. Currently bpp is coming
from pipe config to calculate txbyteclkhs. Fix i
From: Deepak M
The bpp value which is used while calulating the txbyteclkhs values
should be wrt the pixel format value. Currently bpp is coming
from pipe config to calculate txbyteclkhs. Fix it in this patch.
V2: dsi_pixel_format_bpp is used to retrieve the bpp from pixel_format
[Review
On Thu, Feb 11, 2016 at 09:50:45AM +0100, Daniel Vetter wrote:
> On Wed, Feb 03, 2016 at 06:05:01AM -0800, Matt Roper wrote:
> > On Wed, Feb 03, 2016 at 01:16:38PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 02, 2016 at 10:06:51PM -0800, Matt Roper wrote:
> > > > Due to our lack of two-step water
In case of BXT DSI we are updating the CPU_TRANSCODER
with appropriate value.
Signed-off-by: Ramalingam C
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_display.c |5 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/
From: Uma Shankar
During Charging OS mode, mipi display was blanking.This is
because during driver load, though encoder, connector were
active but crtc returned inactive. This caused sanitize
function to disable the DSI panel. In AOS, this is fine
since HWC will do a modeset and crtc, connector,
From: Tvrtko Ursulin
As we have i915_gem_init, do the reverse in new i915_gem_fini so
the fragile order of doing things is hidden from the outside and
only at one place.
Signed-off-by: Tvrtko Ursulin
Cc: Nick Hoath
Cc: David Gordon
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i91
On Thu, Feb 11, 2016 at 03:39:25PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> As we have i915_gem_init, do the reverse in new i915_gem_fini so
> the fragile order of doing things is hidden from the outside and
> only at one place.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Nick Hoath
On Thu, Feb 11, 2016 at 12:00:50PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 10, 2016 at 06:32:59PM -0800, Matt Roper wrote:
> > Gen9 platforms allow CRTC's to be programmed with a background/canvas
> > color below the programmable planes. Let's expose this as a property to
> > allow userspace to
On Thu, Feb 11, 2016 at 08:05:26AM -0800, Matt Roper wrote:
> On Thu, Feb 11, 2016 at 12:00:50PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 10, 2016 at 06:32:59PM -0800, Matt Roper wrote:
> > > Gen9 platforms allow CRTC's to be programmed with a background/canvas
> > > color below the programmable
Hi Tvrtko,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160211]
[cannot apply to v4.5-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Tvrtko
From: Tvrtko Ursulin
Assorted changes most likely without any practical effect
apart from a tiny reduction in generated code for the interrupt
handler and request submission.
* Remove needless initialization.
* Improve cache locality by reorganizing code and/or using
branch hints to keep un
From: Tvrtko Ursulin
Only caller to get_context_status ensures read pointer stays in
range so the WARN is impossible. Also, if the WARN would be
triggered by a hypothetical new caller stale status would be
returned to them.
Maybe it is better to wrap the pointer in the function itself
then to av
Hi Ankitprasad,
On Thu, Feb 04, 2016 at 05:43:17PM +0100, Lukas Wunner wrote:
> On Thu, Feb 04, 2016 at 04:05:04PM +, Chris Wilson wrote:
> > We could #define INTEL_RAPID_START "INT3392" for
> > if (IS_ENABLED(CONFIG_SUSPEND) && acpi_dev_present(INTEL_RAPID_START))
> > but Anki wanted to keep
Em Ter, 2016-02-09 às 12:33 +0530, Kamble, Sagar A escreveu:
> Hi Paulo,
>
> Thanks for comments.
> 1. Will make change related to #define for number of pipes and
> remove
> the unnecessary ones.
> 2. vrefresh is almost same as "clock/(htotal*vtotal) if we round up
> later. Will keep it vrefresh
On Thu, Feb 11, 2016 at 06:03:10PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Assorted changes most likely without any practical effect
> apart from a tiny reduction in generated code for the interrupt
> handler and request submission.
>
> * Remove needless initialization.
> * Imp
On Thu, Feb 11, 2016 at 06:03:09PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Only caller to get_context_status ensures read pointer stays in
> range so the WARN is impossible. Also, if the WARN would be
> triggered by a hypothetical new caller stale status would be
> returned to the
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the kmap of its first page, which includes guc_process_desc and
doorbell. By doing so, we can simplify the code where we read from
this page to get where GuC is progressing on work queue; and the
code where driver p
From: Clint Taylor
Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
to set cdclk based on the max required pixel clock based on VCO
selected.
The vco should be tracked at the atomic level and all CRTCs updated if
the required vco is changed. At this time the eDP pll is conf
Submitted bug # 94104.
https://bugs.freedesktop.org/show_bug.cgi?id=94104
Thanks,
Martin
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Thursday, February 11, 2016 5:34 AM
To: Rogers, Martin
Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
Subject: R
Framecounter register is read-only so DMC cannot restore it
after exiting DC5 and DC6.
Easiest way to go is to avoid the counter and use vblank
interruptions for this platform and for all the following
ones since DMC came to stay. At least while we can't change
this register to read-write.
Signed
[I'm cheating and doing this code review with the author watching over my
shoulder]
On 11/02/16 15:22, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
> to set cdclk based on the max required pixel clock based on
Hi Rodrigo,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.5-rc3 next-20160211]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Rodrigo-Vivi/drm-i915
Hi Rodrigo,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.5-rc3 next-20160211]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Rodrigo-Vivi/drm-i915
On 1/22/2016 5:39 PM, Kumar, Abhay wrote:
From: Abhay Kumar
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.
v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
delay calculation(Ville).
v3: Addr
On Thu, 11 Feb 2016, Daniel Vetter wrote:
> On Wed, Feb 10, 2016 at 07:59:05PM +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> Looks like g4x hpd live status bits actually agree with the spec. At
>> least they do on the machine I have, and apparently on Nick Bowler's
>>
Hi Dave -
Intel fixes all around, mostly display. Sorry I'm late this week.
BR,
Jani.
The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:
Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tag
Ville,
I've applied patch you've provided and did couple of replugging with
intel_reg in between. Here are the results.
I used additional VGA cable to see what actually I type in console :).
Both HDMI and VGA cables plugged: [1]
Both HDMI and VGA cables unplugged: [2]
Only HDMI cable plugged:
88 matches
Mail list logo