On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote:
> Hi!
>
>> [ Add some pm | i915 | x86 folks ]
>>
>> Hi,
>>
>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> and I see some call-traces.
>> It is reproducible on suspend and resume.
>>
>> I cannot say which area touches
On Wed, 28 Dec 2016, Sedat Dilek wrote:
> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote:
>> Hi!
>>
>>> [ Add some pm | i915 | x86 folks ]
>>>
>>> Hi,
>>>
>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> and I see some call-traces.
>>> It is reproducible on suspe
On Tue, 27 Dec 2016, Daniel Vetter wrote:
> I'm not sure how this all should look like.
This we definitely agree on, and hence the RFC. :)
I'm pretty sure it should *not* look like it currently does.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
__
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Sedat Dilek
> Sent: Tuesday, December 27, 2016 6:07 PM
> To: Chris Wilson ; Sedat Dilek
> ; Wysocki, Rafael J ;
> Thomas Gleixner ; intel-gfx g...@lists.freedesktop.org>; Linux PM Li
On Wed, Dec 28, 2016 at 10:39:17AM +0200, Jani Nikula wrote:
> On Tue, 27 Dec 2016, Daniel Vetter wrote:
> > I'm not sure how this all should look like.
>
> This we definitely agree on, and hence the RFC. :)
>
> I'm pretty sure it should *not* look like it currently does.
Yup, agreed on that. S
On Tue, Dec 27, 2016 at 07:41:47PM +0100, Daniel Vetter wrote:
> On Tue, Dec 27, 2016 at 06:21:47PM +0200, Jani Nikula wrote:
> > Hi all -
> >
> > This series aims at three goals:
> >
> > 1) Most drivers do similar things around drm_get_edid (namely convert
> > edid to eld, add modes, and update
On Tue, 27 Dec 2016, Daniel Vetter wrote:
> On Tue, Dec 27, 2016 at 06:21:47PM +0200, Jani Nikula wrote:
>> Hi all -
>>
>> This series aims at three goals:
>>
>> 1) Most drivers do similar things around drm_get_edid (namely convert
>> edid to eld, add modes, and update edid blob property). Add a
On Wed, Dec 28, 2016 at 01:12:09PM +0530, Animesh Manna wrote:
> While suspending the device hpd related interrupts are enabled
> to get the interrupt when device is in suspend state.
>
> Though display is in DC9 but system can be in S0 or S0i3 state.
> Hot plug during S0 state will generate de_po
On Wed, Dec 28, 2016 at 11:23:42AM +0200, Jani Nikula wrote:
> On Tue, 27 Dec 2016, Daniel Vetter wrote:
> > On Tue, Dec 27, 2016 at 06:21:47PM +0200, Jani Nikula wrote:
> >> Hi all -
> >>
> >> This series aims at three goals:
> >>
> >> 1) Most drivers do similar things around drm_get_edid (name
On Tue, Dec 27, 2016 at 07:46:55PM +0100, Daniel Vetter wrote:
> On Wed, Dec 28, 2016 at 12:57:07AM +0800, kbuild test robot wrote:
> > tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
> > head: 0d15e733fab5dd48154dda2bebdacd1d87069d08
> > commit: 50f0033d1a0f3a8e9eed09ab68067fbb
On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote:
> On Wed, 28 Dec 2016, Sedat Dilek wrote:
>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote:
>>> Hi!
>>>
[ Add some pm | i915 | x86 folks ]
Hi,
I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
On Thu, Dec 22, 2016 at 08:36:40AM +, Chris Wilson wrote:
> /**
> * drm_mm_for_each_hole - iterator to walk over all holes
> * @entry: drm_mm_node used internally to track progress
> @@ -274,57 +263,27 @@ static inline u64 drm_mm_hole_node_end(const struct
> drm_mm_node *hole_node)
> *
The GuC uses a special mapping for the upper end of the Global GTT,
similar to the way it uses a special mapping for the lower end, so
exclude it from our drm_mm to prevent us using it.
v2: Rename to reflect that it is unmappable similar to the region at the
bottom of the GGTT, and couple it into
On Wed, Dec 28, 2016 at 11:27:37AM +, Chris Wilson wrote:
> The GuC uses a special mapping for the upper end of the Global GTT,
> similar to the way it uses a special mapping for the lower end, so
> exclude it from our drm_mm to prevent us using it.
>
> v2: Rename to reflect that it is unmappa
If the DMA remap fails, one cause can be that we have too many objects
pinned in a small remapping table, such as swiotlb. (DMA remapping does
not trigger the shrinker by itself on its normal failure paths.) So try
purging all other objects (using i915_gem_shrink_all(), sparing our own
pages as we
== Series Details ==
Series: drm/i915/guc: Exclude the upper end of the Global GTT for the GuC
URL : https://patchwork.freedesktop.org/series/17246/
State : failure
== Summary ==
cc1: all warnings being treated as errors
scripts/Makefile.build:293: recipe for target
'drivers/gpu/drm/i915/inte
== Series Details ==
Series: drm/i915: Purge loose pages if we run out of DMA remap space
URL : https://patchwork.freedesktop.org/series/17247/
State : warning
== Summary ==
Series 17247v1 drm/i915: Purge loose pages if we run out of DMA remap space
https://patchwork.freedesktop.org/api/1.0/se
On Thu, Dec 22, 2016 at 08:36:33AM +, Chris Wilson wrote:
> Compute the minimal required hole during scan and only evict those nodes
> that overlap. This enables us to reduce the number of nodes we need to
> evict to the bare minimum.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Laht
On Thu, Dec 22, 2016 at 08:36:37AM +, Chris Wilson wrote:
> Insulate users from changes to the internal hole tracking within
> struct drm_mm_node by using an accessor for hole_follows.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/drm_mm.c
On Wed, Dec 28, 2016 at 02:02:27PM +0100, Daniel Vetter wrote:
> On Thu, Dec 22, 2016 at 08:36:37AM +, Chris Wilson wrote:
> > Insulate users from changes to the internal hole tracking within
> > struct drm_mm_node by using an accessor for hole_follows.
> >
> > Signed-off-by: Chris Wilson
> >
On Thu, Dec 22, 2016 at 08:36:40AM +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the ran
On Wed, Dec 28, 2016 at 2:31 PM, Chris Wilson wrote:
> On Wed, Dec 28, 2016 at 02:02:27PM +0100, Daniel Vetter wrote:
>> On Thu, Dec 22, 2016 at 08:36:37AM +, Chris Wilson wrote:
>> > Insulate users from changes to the internal hole tracking within
>> > struct drm_mm_node by using an accessor
On Wed, Dec 28, 2016 at 02:48:52PM +0100, Daniel Vetter wrote:
> On Thu, Dec 22, 2016 at 08:36:40AM +, Chris Wilson wrote:
> > The drm_mm range manager claimed to support top-down insertion, but it
> > was neither searching for the top-most hole that could fit the
> > allocation request nor fit
On Wed, Dec 28, 2016 at 02:01:29PM +0100, Daniel Vetter wrote:
> On Thu, Dec 22, 2016 at 08:36:33AM +, Chris Wilson wrote:
> > Compute the minimal required hole during scan and only evict those nodes
> > that overlap. This enables us to reduce the number of nodes we need to
> > evict to the bar
On Tue, Dec 27, 2016 at 07:46:55PM +0100, Daniel Vetter wrote:
On Wed, Dec 28, 2016 at 12:57:07AM +0800, kbuild test robot wrote:
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 0d15e733fab5dd48154dda2bebdacd1d87069d08
commit: 50f0033d1a0f3a8e9eed09ab68067fbb57b0669d [3
On Wed, Dec 28, 2016 at 10:37:09PM +0800, Fengguang Wu wrote:
> On Tue, Dec 27, 2016 at 07:46:55PM +0100, Daniel Vetter wrote:
> >On Wed, Dec 28, 2016 at 12:57:07AM +0800, kbuild test robot wrote:
> >>tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
> >>head: 0d15e733fab5dd48154d
Hi Chris,
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v4.10-rc1 next-20161224]
[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/Chris-Wilson/drm-i915-guc-Exclude-the-upper
Useful for dumping lots of data into dmesg, e.g. drm_mm.
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_print.c | 6 ++
include/drm/drm_print.h | 20 ++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/d
Including all drivers. I thought about keeping small compat functions
to avoid having to change all drivers. But I really like the
drm_printer idea, so figured spreading it more widely is a good thing.
Cc: Rob Clark
Cc: Russell King
Cc: Alex Deucher
Cc: Christian König
Cc: Lucas Stach
Cc: Tom
On Wed, Dec 28, 2016 at 05:42:10PM +0100, Daniel Vetter wrote:
> static int ttm_pl_vram = TTM_PL_VRAM;
> diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
> b/drivers/gpu/drm/selftests/test-drm_mm.c
> index 2ce92f4dcfc7..598fde492863 100644
> --- a/drivers/gpu/drm/selftests/test-drm_mm.c
> +++
== Series Details ==
Series: series starting with [1/2] drm/printer: add debug printer
URL : https://patchwork.freedesktop.org/series/17251/
State : warning
== Summary ==
Series 17251v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17251/revisions/1/mbox/
Test k
On 28/12/16 03:27, Chris Wilson wrote:
The GuC uses a special mapping for the upper end of the Global GTT,
similar to the way it uses a special mapping for the lower end, so
exclude it from our drm_mm to prevent us using it.
v2: Rename to reflect that it is unmappable similar to the region at
On Wed, Dec 28, 2016 at 03:31:19PM +0100, Daniel Vetter wrote:
> On Wed, Dec 28, 2016 at 2:31 PM, Chris Wilson
> wrote:
> > On Wed, Dec 28, 2016 at 02:02:27PM +0100, Daniel Vetter wrote:
> >> On Thu, Dec 22, 2016 at 08:36:37AM +, Chris Wilson wrote:
> >> > Insulate users from changes to the i
On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek wrote:
> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote:
>> On Wed, 28 Dec 2016, Sedat Dilek wrote:
>>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote:
Hi!
> [ Add some pm | i915 | x86 folks ]
>
> Hi,
>
> I ha
On 2016.12.28 14:33 Rafael J. Wysocki wrote:
> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek wrote:
>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote:
>>> On Wed, 28 Dec 2016, Sedat Dilek wrote:
On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote:
P.S.: Revert "cpu/hotplug:
On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki wrote:
> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek wrote:
>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote:
>>> On Wed, 28 Dec 2016, Sedat Dilek wrote:
On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek wrote:
> Hi!
>
>>
From: Dhanya
This series contains patches for enabling CSC and Gamma for
GLK. Also, it programs unity gamma to Pre-CSC Gamma lut for GLK+.
Tested on GLK silicon.
Dhanya (2):
drm/i915/glk: Enable Pipe Level CSC & Gamma Feature.
drm/i915/glk: Program pre_csc_gamma with unity gamma
drivers/g
From: Dhanya
For GLK, we need to program new register PLANE_COLOR_CTL
for enabling CSC and Gamma. This patch sets the pipe gamma
and pipe csc bit in the PLANE_COLOR_CTL.
Signed-off-by: Dhanya
---
drivers/gpu/drm/i915/intel_color.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 18 ++
From: Dhanya
For GLK, Pre-CSC Gamma correction get enabled/disabled based
on "Pipe CSC Enable" bit in the PLANE_COLOR_CTL.
This patch programs Unity Gamma in these registers.
Signed-off-by: Dhanya
---
drivers/gpu/drm/i915/i915_reg.h| 13 +
drivers/gpu/drm/i915/intel_color.c | 3
Regards
Shashank
On 12/27/2016 3:07 PM, Daniel Vetter wrote:
On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
Hi Shashank,
On 21-12-2016 15:29, Shashank Sharma wrote:
This patch adds a small helper function, which clears the cached
information about a hot-pluggable display, from
40 matches
Mail list logo
