ankitprasad.r.sha...@intel.com writes:
> From: Ankitprasad Sharma
>
> In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> we try a nonblocking pin for the whole object (since that is fastest if
> reused), then failing that we try to grab one page in the mappable
> aperture.
Should I improve this patch or you have rejected this patch?
Regards,
$4
On Mon, Nov 09, 2015 at 06:57:22PM +0200, Jani Nikula wrote:
> On Mon, 09 Nov 2015, Paulo Zanoni wrote:
> > 2015-11-09 8:17 GMT-02:00 Jani Nikula :
> >> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
> >> wrote:
> >>>
When using i915
O.S. Ubuntu 15.10
Pltaform: Bay Trail I
Issue: When the O.S. is on Virtual Terminal or Text Mode it doesn't detect when
connecting HDMI display, the issue is not present on graphic mode.
Is this expected behavior?
Best Regards,
Adolfo.
___
Beginning with SKL the DP Aux channel communication can be protected
using a built in H/W mutex.
This patch provides an initial implementation for using that mutex.
The use is currently limited to protecting the sink crc request based
on feedback from the H/W designers indicating that using the mu
Signed-off-by: Bob Paauwe
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 647c0ff..fc5097f 100644
--- a/
On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> Atm, we assert that the device is not suspended after the point when the
> HW is truly put to a suspended state. This is fine, but we can catch
> more problems if we check the RPM refcount. After that one drops to zero
> we shouldn't acce
On Mon, 2015-11-09 at 23:24 +0200, Imre Deak wrote:
> On Mon, 2015-11-09 at 21:11 +, Chris Wilson wrote:
> > On Mon, Nov 09, 2015 at 09:14:19PM +0200, Imre Deak wrote:
> > > The device should be on when updating the GGTT PTEs, so add an assert to
> > > all relevant places.
> > >
> > > v2:
> >
On Mon, 2015-11-09 at 21:11 +, Chris Wilson wrote:
> On Mon, Nov 09, 2015 at 09:14:19PM +0200, Imre Deak wrote:
> > The device should be on when updating the GGTT PTEs, so add an assert to
> > all relevant places.
> >
> > v2:
> > - use the existing dev_priv directly everywhere (Ville)
> >
> >
On Mon, Nov 09, 2015 at 09:14:19PM +0200, Imre Deak wrote:
> The device should be on when updating the GGTT PTEs, so add an assert to
> all relevant places.
>
> v2:
> - use the existing dev_priv directly everywhere (Ville)
>
> Signed-off-by: Imre Deak
For completeness, add one to i915_ggtt_inse
On Mon, Nov 09, 2015 at 08:20:09PM +0200, Imre Deak wrote:
> Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedes
On Mon, Nov 09, 2015 at 05:17:13PM +, Thomas Wood wrote:
> Disable output of terminal control characters and progress meters when
> IGT_PLAIN_OUTPUT is set in the environment.
>
> Cc: Derek Morton
> Signed-off-by: Thomas Wood
> ---
> lib/igt_aux.c | 2 +-
> lib/igt_core.c | 23 +++
On Mon, Nov 09, 2015 at 08:16:26PM +0200, Imre Deak wrote:
> After fixing the same issue in the set_caching IOCTL and Chris' request
> to check out the possibilities for an improved RPM ref handling I
> noticed that we have the same issue in the set_tiling IOCTL. Fix this
> up.I didn't see any bug
On Mon, Nov 09, 2015 at 08:20:08PM +0200, Imre Deak wrote:
> We should use the same assert in more places, so export it. Move it to
> intel_runtime_pm.c at the same time, since that's a more logical place
> for it.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_drv.h| 2
Atm, we assert that the device is not suspended after the point when the
HW is truly put to a suspended state. This is fine, but we can catch
more problems if we check the RPM refcount. After that one drops to zero
we shouldn't access the HW any more, although the actual suspend may be
delayed. The
The device should be on when updating the GGTT PTEs, so add an assert to
all relevant places.
v2:
- use the existing dev_priv directly everywhere (Ville)
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/
On ma, 2015-11-09 at 20:37 +0200, Ville Syrjälä wrote:
> On Mon, Nov 09, 2015 at 08:20:11PM +0200, Imre Deak wrote:
> > The device should be on when updating the GGTT PTEs, so add an
> > assert to
> > all relevant places.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_gem
On ma, 2015-11-09 at 20:30 +0200, Ville Syrjälä wrote:
> On Mon, Nov 09, 2015 at 08:20:08PM +0200, Imre Deak wrote:
> > We should use the same assert in more places, so export it. Move it
> > to
> > intel_runtime_pm.c at the same time, since that's a more logical
> > place
> > for it.
> >
> > Sign
On Mon, Nov 09, 2015 at 08:20:11PM +0200, Imre Deak wrote:
> The device should be on when updating the GGTT PTEs, so add an assert to
> all relevant places.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/
On Mon, Nov 09, 2015 at 08:20:08PM +0200, Imre Deak wrote:
> We should use the same assert in more places, so export it. Move it to
> intel_runtime_pm.c at the same time, since that's a more logical place
> for it.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_drv.h| 2
On Fri, Oct 30, 2015 at 11:40:46AM +, Tvrtko Ursulin wrote:
>
> On 30/10/15 11:26, Mika Kuoppala wrote:
> > VMA offsets are 64 bits. Plane surface offsets are in ggtt and
> > the hardware register to set this is thus 32 bits. Be explicit
> > about these and convert carefully to from vma to fin
We should use the same assert in more places, so export it. Move it to
intel_runtime_pm.c at the same time, since that's a more logical place
for it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 6 ++
drivers/gpu/drm/i
Motivated by the discussions with Chris about imrpoving our RPM ref
get/put logic and seeing that we are still missing RPM refs from
places I improved a bit the assert that checks if the device is powered
on while we are accessing the HW. This produced at least one additional
assert on the atomic c
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 10 --
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 0d4a03b..4
The device should be on when updating the GGTT PTEs, so add an assert to
all relevant places.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
in
Atm, we assert that the device is not suspended after the point when the
HW is truly put to a suspended state. This is fine, but we can catch
more problems if we check the RPM refcount. After that one drops to zero
we shouldn't access the HW any more, although the actual suspend may be
delayed. The
On Wed, Nov 04, 2015 at 05:41:16PM +0200, Ander Conselvan De Oliveira wrote:
> Reviewed-by: Ander Conselvan de Oliveira
Pushed to dinq. Thanks for the review.
> On Fri, 2015-10-30 at 23:39 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently there's no trace in
After fixing the same issue in the set_caching IOCTL and Chris' request
to check out the possibilities for an improved RPM ref handling I
noticed that we have the same issue in the set_tiling IOCTL. Fix this
up.I didn't see any bug reports about this one, but the GTT unbind
operation on this path a
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_
On Wed, Nov 04, 2015 at 05:18:28PM +, Daniel Stone wrote:
> Hi,
>
> On 27 October 2015 at 12:46, Mika Kuoppala
> wrote:
> > From: Damien Lespiau
> >
> > That can be handy later on to tell which DMC firmware version the user
> > has, by just looking at the dmesg.
> >
> > v2: use DRM_DEBUG_DRI
cc: Jani Nikula
Signed-off-by: Yetunde Adebisi
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1252108..92d9a52 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -621,6
Disable output of terminal control characters and progress meters when
IGT_PLAIN_OUTPUT is set in the environment.
Cc: Derek Morton
Signed-off-by: Thomas Wood
---
lib/igt_aux.c | 2 +-
lib/igt_core.c | 23 ++-
lib/igt_core.h | 2 ++
3 files changed, 17 insertions(+), 10 d
On Mon, 09 Nov 2015, Paulo Zanoni wrote:
> 2015-11-09 8:17 GMT-02:00 Jani Nikula :
>> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
>> wrote:
>>> The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however
>>> the sysfs brightness level always starts from 0 so it is better to u
On Mon, Nov 09, 2015 at 05:10:40PM +0100, Maarten Lankhorst wrote:
> Op 09-11-15 om 15:48 schreef Ander Conselvan De Oliveira:
> > On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote:
> >> This removes another couple of hacks from intel_crtc->atomic, and
> >> creates proper atomic state for
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been saved.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
The re
Op 09-11-15 om 15:48 schreef Ander Conselvan De Oliveira:
> On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote:
>> This removes another couple of hacks from intel_crtc->atomic, and
>> creates proper atomic state for it.
> Perhaps you could be more verbose about the hacks being removed.
Righ
2015-11-09 8:17 GMT-02:00 Jani Nikula :
> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
> wrote:
>> The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however
>> the sysfs brightness level always starts from 0 so it is better to use
>> 927 as the sysfs maximum brightness level
We need a power domain for disabling DC5/DC6 around modesets to prevent
confusing the DMC.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
Handle DC off as a power well where enabling the power well will prevent
the DMC to enter selected DC states (required around modesets and Aux
A). Disabling the power well will allow DC states again. For now the
highest DC state is DC6 for Skylake and DC5 for Broxton but will be
configurable for Sk
From: Ville Syrjälä
All the DDI power domains are already excluded from
SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS on account of
excluding SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS and
SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS, no need to spell them out again.
Signed-off-by: Ville Syrjälä
Reviewed-by: Patrik
PG2 enabled is not a requirement for disabling DC5. It's just one
of the reasons why the DMC wouldn't enter DC5. During modeset we don't
care about PG2 from a DC perspective, only the fact that DC5/DC6 is not
allowed.
Signed-off-by: Patrik Jakobsson
Reviewed-by: Ville Syrjälä
---
drivers/gpu/dr
From: Ville Syrjälä
Currently the gmbus code uses intel_aux_display_runtime_get/put in an
effort to make sure the hardware is powered up sufficiently for gmbus.
That function only takes the runtime PM reference which on VLV/CHV/BXT
is not enough. We need the disp2d/pipe-a well on VLV/CHV and powe
This v2 of the series is rebased on top of a new series from Imre [1]
and contains a few new patches and reordering.
These patches should sit on top of the DMC redesign patches from
Animesh/Imre [2] which in turn depends on Mika's FW debug patches [3].
First couple of patches are from Ville and i
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6d88f5..31b3a84 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@
We never make use of the distinction between 2 vs 4 lanes so combine
them into a per port domain instead. This saves us a few bits in the
power domain mask. Change suggested by Ville.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/i915_debugfs.c | 28 +
drivers/gpu/drm/
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0c7f435..77d183d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i91
v2: Use _unsafe (Jani)
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_params.c | 6 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915
From: Ville Syrjälä
Introduce intel_display_port_aux_power_domain() which simply returns
the appropriate AUX power domain for a specific port, and then replace
the intel_display_port_power_domain() with calls to the new function
in the DP code. As long as we're not actually enabling the port we d
Move call to gen9_set_dc_state_debugmask_memory_up() into
gen9_set_dc_state() to prevent us missing it somewhere.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 35 -
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/dr
Replaces "drm/i915: Force loading of csr program at boot" in the old
series.
Previously we called blindly into intel_csr_load_program() and depended
on a check of whether the CSR program memory was cleared or not.
This check is not reliable and no longer needed since we fixed the
call-sites of int
On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote:
> This is already handled in pre_disable_primary, disabling it twice is useless.
The atomic.disable_ips field was added in
commit 066cf55b9ce35f1f90dde9fcec01431a9243a949
Author: Rodrigo Vivi
Date: Fri Jun 26 13:55:54 2015 -0700
On Mon, Nov 09, 2015 at 10:02:24PM +0800, Shih-Yuan Lee (FourDollars) wrote:
> On Mon, Nov 9, 2015 at 8:58 PM, Jani Nikula
> wrote:
>
> > On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
> > wrote:
> > > On Mon, Nov 9, 2015 at 6:51 PM, Jani Nikula > >
> > > wrote:
> > >
> > >> On Mon, 09 Nov
On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote:
> By handling this after the atomic helper waits for vblanks there will
> be one less wait for vblank in the atomic path.
I found this a bit confusing. Sounds like you are referring to calling
intel_post_enable_update() after the call to
On 4 November 2015 at 19:36, Zanoni, Paulo R wrote:
> Em Seg, 2015-11-02 às 11:48 +, Thomas Wood escreveu:
>> Initialization was included in commit a976d7e (tests/kms_fbc_crc:
>> refactor context
>> handling code), but won't be executed since it is declared before the
>> first
>> label within
On Tue, 2015-11-03 at 08:31 +0100, Maarten Lankhorst wrote:
> This removes another couple of hacks from intel_crtc->atomic, and
> creates proper atomic state for it.
Perhaps you could be more verbose about the hacks being removed.
> Changes since v1:
> - Rebase on top of wm changes.
>
> Signed-o
On Sat, 07 Nov 2015, Lukas Wunner wrote:
> Hi Jani,
>
> three patches with fbdev deadlock & failure path fixes,
> each with Reviewed-by tag by Ville or Daniel, the third one
> with amended commit message as requested by Daniel in
> <20151030182818.GR16848@phenom.ffwll.local>.
>
> Patch 1 fixes dou
On Mon, Nov 9, 2015 at 8:58 PM, Jani Nikula
wrote:
> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
> wrote:
> > On Mon, Nov 9, 2015 at 6:51 PM, Jani Nikula >
> > wrote:
> >
> >> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" >
> >> wrote:
> >> > On Mon, Nov 9, 2015 at 6:17 PM, Jani Ni
2015-11-05 18:40 GMT-02:00 Ville Syrjälä :
> On Thu, Nov 05, 2015 at 06:34:07PM -0200, Paulo Zanoni wrote:
>> 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi :
>> > There are few platforms with other suspend resume bugs that breaks
>> > the full execution. So let's provide a way to skip suspend resume case
On Mon, Nov 09, 2015 at 03:36:10PM +0200, Imre Deak wrote:
> On ma, 2015-11-09 at 13:25 +, Chris Wilson wrote:
> > On Mon, Nov 09, 2015 at 03:09:18PM +0200, Imre Deak wrote:
> > > Looked through it, it seems only i915_gem_set_tiling() could
> > > release
> > > the PTE's without waking up the ha
On ma, 2015-11-09 at 13:25 +, Chris Wilson wrote:
> On Mon, Nov 09, 2015 at 03:09:18PM +0200, Imre Deak wrote:
> > Looked through it, it seems only i915_gem_set_tiling() could
> > release
> > the PTE's without waking up the hardware (if no need to unbind the
> > object). Otherwise it's true tha
On Mon, Nov 09, 2015 at 03:09:18PM +0200, Imre Deak wrote:
> Looked through it, it seems only i915_gem_set_tiling() could release
> the PTE's without waking up the hardware (if no need to unbind the
> object). Otherwise it's true that all callers hold (or should hold)
> already an RPM ref. To fix t
On pe, 2015-11-06 at 08:54 +, Chris Wilson wrote:
> On Fri, Nov 06, 2015 at 12:57:35AM +0200, Imre Deak wrote:
> > On Thu, 2015-11-05 at 11:56 +, Chris Wilson wrote:
> > > On Thu, Nov 05, 2015 at 01:28:32PM +0200, Imre Deak wrote:
> > > > On ke, 2015-11-04 at 20:57 +, Chris Wilson wrote
On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" wrote:
> On Mon, Nov 9, 2015 at 6:51 PM, Jani Nikula
> wrote:
>
>> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
>> wrote:
>> > On Mon, Nov 9, 2015 at 6:17 PM, Jani Nikula > >
>> > wrote:
>> >
>> >> On Mon, 09 Nov 2015, "Shih-Yuan Lee (Four
Hi Ankitprasad,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.3 next-20151109]
url:
https://github.com/0day-ci/linux/commits/ankitprasad-r-sharma-intel-com/Support-for-mapping-an-object-page-by-page/20151109-191910
base: git://anongit.freedesktop.org
On Mon, Nov 9, 2015 at 6:51 PM, Jani Nikula
wrote:
> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
> wrote:
> > On Mon, Nov 9, 2015 at 6:17 PM, Jani Nikula >
> > wrote:
> >
> >> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" >
> >> wrote:
> >> > The PWM brightness level of Dell XPS 13
Hi Rodrigo,
On 5 November 2015 at 18:49, Rodrigo Vivi wrote:
> So I'm confident we can enable PSR back by default now.
>
> All comments, ideas, suggestions and even bikesheddings are pretty welcome.
You did ask for it ...
I've been looking at pulling this on top of Maarten's tree, and
currently
Hi Rodrigo,
On 5 November 2015 at 18:49, Rodrigo Vivi wrote:
> diff --git a/drivers/gpu/drm/i915/intel_ips.c
> b/drivers/gpu/drm/i915/intel_ips.c
> index b867aba..6bc5c55 100644
> --- a/drivers/gpu/drm/i915/intel_ips.c
> +++ b/drivers/gpu/drm/i915/intel_ips.c
> @@ -105,18 +105,21 @@ bool intel_i
On Mon, Nov 09, 2015 at 01:21:33PM +0200, Jani Nikula wrote:
> On Mon, 09 Nov 2015, Damien Lespiau wrote:
> > That would work for us, but not in the general case (for other
> > projects). I was thinking of using some kind of other heuristic, eg.
> > (subject, commit message, files touched) with a
On Mon, 09 Nov 2015, Damien Lespiau wrote:
> That would work for us, but not in the general case (for other
> projects). I was thinking of using some kind of other heuristic, eg.
> (subject, commit message, files touched) with a levenshtein distance on
> text to allow typo correction.
>
> Just for
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 by using space as
meagre as page size.
Signed-off-by: Chris
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.
Signed-off-by: Chris Wilson
Signed-off-by: Ankitprasad Sh
From: Ankitprasad Sharma
In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than th
From: Ankitprasad Sharma
It is possible that when we want to map an object to the aperture, either
we run out of aperture space or the size of the object is larger than
the mappable aperture. In such cases we might not be able to map the whole
object to the aperture. For cases as such, here we in
On Mon, Nov 09, 2015 at 10:45:14AM +0200, Jani Nikula wrote:
> On Sun, 08 Nov 2015, Damien Lespiau wrote:
> > There are two new patchwork projects then:
> >
> > http://patchwork.freedesktop.org/project/intel-gpu-tools/
> > http://patchwork.freedesktop.org/project/libdrm-intel/
> >
> > I've als
On Sun, Nov 08, 2015 at 05:44:37PM +0100, Lukas Wunner wrote:
> Hi Ville,
>
> On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Reading the driver load/unload code leaves one confused as there's
> > an async_schedule() in the load, but
On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" wrote:
> On Mon, Nov 9, 2015 at 6:17 PM, Jani Nikula
> wrote:
>
>> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
>> wrote:
>> > The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however
>> > the sysfs brightness level always
On Thu, 05 Nov 2015, Rodrigo Vivi wrote:
> On the commit 3301d4092106 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT
> logic")'
> we already had identified that DP_PSR_NO_TRAIN_ON_EXIT
> doesn't mean we shouldn't send TPS patterns, however we start sending the
> minimal TP1 as possible and no TP2.
On Thu, 05 Nov 2015, Rodrigo Vivi wrote:
> Since the beginning there is a confusion on the meaning of this bit.
>
> A previous patch had identified this already and fixed it partially:
> 'commit 3301d409 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic")
>
> DP_PSR_NO_TRAIN_ON_EXIT means the sou
On Mon, Nov 9, 2015 at 6:17 PM, Jani Nikula
wrote:
> On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)"
> wrote:
> > The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however
> > the sysfs brightness level always starts from 0 so it is better to use
> > 927 as the sysfs maximum br
On 11/5/2015 10:50 PM, Vandana Kannan wrote:
From: Daniel Vetter
For render compression, userspace passes aux stride and offset values as an
additional entry in the fb structure. This should not be treated as garbage
and discarded as data belonging to no plane.
This patch introduces a check r
On Fri, Nov 06, 2015 at 03:18:37PM -0800, Yu Dai wrote:
>
>
> On 11/06/2015 02:07 PM, Chris Wilson wrote:
> >On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> >> From: Alex Dai
> >>
> >> We keep a copy of GuC fw in a GEM obj. However its content is lost
> >> if the GEM obj is e
On Mon, 09 Nov 2015, "Shih-Yuan Lee (FourDollars)" wrote:
> The PWM brightness level of Dell XPS 13 (2015) is from 10 to 937 however
> the sysfs brightness level always starts from 0 so it is better to use
> 927 as the sysfs maximum brightness level and it becomes easier to map
> from the PWM brig
On Sun, 2015-11-01 at 12:48 +0100, Maarten Maathuis wrote:
> Hi everyone.
>
> I've been some hardlock problems when switching from the HDMI connection of my
> monitor (connected to another PC) and the displayport (connected to the
> problematic PC), several times a week at least.
>
> In an effort
Reviewed-by: Ander Conselvan de Oliveira
On Thu, 2015-11-05 at 11:49 +0200, Jani Nikula wrote:
> Unsurprisingly macbooks have backlights, just the VBT doesn't seem to
> know it in this case.
>
> Reported-and-tested-by: Daniel Nicoletti
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88
On Sun, 08 Nov 2015, Damien Lespiau wrote:
> There are two new patchwork projects then:
>
> http://patchwork.freedesktop.org/project/intel-gpu-tools/
> http://patchwork.freedesktop.org/project/libdrm-intel/
>
> I've also run the sorting on all the existing patches so the entries
> that were hi
84 matches
Mail list logo
