On Thu, May 04, 2017 at 09:25:03PM +0100, Chris Wilson wrote:
> On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
> >
> > Enable the GEM dma-buf import interfaces in addition to the export
> > interfaces. This lets vgem be used as a test source for other allocators
> > (e.g. Ion).
> >
On Fri, May 05, 2017 at 10:06:06AM +0300, Amir Goldstein wrote:
> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems code).
Yeah.
> IMO, you should acknowledge that the common use case for fi
I am the author of ddcutil (www.ddcutil.com), a Linux utility that
manages monitor settings using DDC/CI. I am seeing a pattern of user
error reports in which I2C communication is not working when a system
with a recent Intel chip, using the i915 driver, is plugged into a
docking station. Communic
Chris Wilson writes:
> On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
>> On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
>> > Explicitly assign the default priority, and give it a name (macro).
>> >
>> > Signed-off-by: Chris Wilson
>>
>>
>>
>> > kref_init(&ctx->ref
On Thu, May 04, 2017 at 09:09:54PM -0700, Joe Perches wrote:
> On Thu, 2017-05-04 at 21:25 +0100, Chris Wilson wrote:
> > On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
> > >
> > > Enable the GEM dma-buf import interfaces in addition to the export
> > > interfaces. This lets vgem be
+ Daniel
On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> >
> > Currently GVT-g cannot work properly when host GuC submission
> > is enabled, so disable GVT in this case.
> >
> > Cc: Zhenyu Wang
> > Signed-off-by: Chuanxiao Dong
>
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Friday, May 5, 2017 4:55 PM
> To: Zhenyu Wang ; Dong, Chuanxiao
> ; Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] dr
-Voravootivat/Enhancement-to-intel_dp_aux_backlight-driver/20170505-003007
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
On Fri, May 05, 2017 at 11:55:14AM +0300, Joonas Lahtinen wrote:
> + Daniel
>
> On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> > >
> > > Currently GVT-g cannot work properly when host GuC submission
> > > is enabled, so disable GVT i
On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
> >> On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
> >> > Explicitly assign the default priority, and give it a name (macro).
> >> >
On to, 2017-04-27 at 05:54 +, Zhang, Xiong Y wrote:
> >
> > Also, was fixing the IGD driver loading with zero stolen memory
> > considered instead? All this information should exist in the commit
> > message.
> [Zhang, Xiong Y] IGD and i915 driver read pci config register 0x50 to get
> the si
On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote:
> >
> > >
> > > + David and Jon
> > >
> > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> > >
> > > The blocking issue I see is that bisecting is still not pointing at
> > > relevant commits. Both bisected commits from Bugzilla ar
On 05/05/2017 10:13, Chris Wilson wrote:
On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote:
Chris Wilson writes:
On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
On ke, 2017-05-03 at 12:37 +0100, Chris Wilson wrote:
Explicitly assign the default priority, and gi
On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
> On Fri, May 5, 2017 at 9:20 AM, Dan Williams > wrote:
> > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> > wrote:
> > > for (i = 0; i < NFIT_UUID_MAX; i++)
> > > - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16
Due to the complex dependencies between workqueues and RCU, which
are not easily detected by lockdep, do not synchronize RCU during
shrinking. RCU sync gains us very little benefit in real life
scenarios where the amount of memory used by object backing
storage is dominant over the metadata under R
On Fri, May 05, 2017 at 12:40:09PM +0300, Joonas Lahtinen wrote:
> Due to the complex dependencies between workqueues and RCU, which
> are not easily detected by lockdep, do not synchronize RCU during
> shrinking. RCU sync gains us very little benefit in real life
> scenarios where the amount of me
On Fri, May 05, 2017 at 10:21:32AM +0100, Tvrtko Ursulin wrote:
>
> On 05/05/2017 10:13, Chris Wilson wrote:
> >On Fri, May 05, 2017 at 11:31:14AM +0300, Mika Kuoppala wrote:
> >>Chris Wilson writes:
> >>
> >>>On Thu, May 04, 2017 at 04:32:34PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-05-0
On 2017.05.05 11:55:14 +0300, Joonas Lahtinen wrote:
> + Daniel
>
> On ke, 2017-05-03 at 16:36 +0800, Zhenyu Wang wrote:
> > On 2017.05.02 16:58:31 +0800, Chuanxiao Dong wrote:
> > >
> > > Currently GVT-g cannot work properly when host GuC submission
> > > is enabled, so disable GVT in this case.
On Fri, 05 May 2017, Sanford Rockowitz wrote:
> I am the author of ddcutil (www.ddcutil.com), a Linux utility that
> manages monitor settings using DDC/CI. I am seeing a pattern of user
> error reports in which I2C communication is not working when a system
> with a recent Intel chip, using the i9
On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
> To complete the picture for folks not cc'ed on my patches,
> xfs use case suggests there is also justification for the additional helpers:
>
> uuid_is_null() / uuid_equal()
> guid_is_null() / guid_equal()
The is_null is useful and
== Series Details ==
Series: drm/i915: Do not sync RCU during shrinking
URL : https://patchwork.freedesktop.org/series/24008/
State : success
== Summary ==
Series 24008v1 drm/i915: Do not sync RCU during shrinking
https://patchwork.freedesktop.org/api/1.0/series/24008/revisions/1/mbox/
Test g
On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
> wrote:
> > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
> > that are set when there is no VBT") fixes things for you.
>
> I think this is not going to help. Th
On Fri, May 05, 2017 at 09:48:08AM +0300, Jani Nikula wrote:
> On Thu, 04 May 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Turns out our skills in decoding the CLKCFG register weren't good
> > enough. On this particular elk the answer we got was 400 MHz when
> > in re
On 03/05/2017 12:37, Chris Wilson wrote:
add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187)
function old new delta
execlists_submit_ports 262 471+209
port_assign.isra - 136+136
ca
On Fri, May 05, 2017 at 11:49:21AM +0100, Tvrtko Ursulin wrote:
>
> On 03/05/2017 12:37, Chris Wilson wrote:
> >+static void port_assign(struct execlist_port *port,
> >+struct drm_i915_gem_request *rq)
> >+{
> >+GEM_BUG_ON(rq == port_request(port));
> >+
> >+if (port_is
Hi Laura,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20170505]
[cannot apply to v4.11]
[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/Laura-Abbott/dma_buf-import
On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote:
>
>
> On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace
> > driver produced by Intel engineers, one which Intel has the full
> > capability to change. What you're s
We are using some scratch registers in MMIO based send function.
Make their base and count flexible in preparation of upcoming
GuC firmware/hardware changes. While around, change cmd len
parameter verification from WARN_ON to GEM_BUG_ON as we don't
need this all the time.
v2: call out WARN/GEM_BUG
From: Tvrtko Ursulin
It seems that the DMC likes to transition between the DC states
a lot when there are no connected displays (no active power
domains) during simple command submission.
This frantic activity on DC states has a terrible impact on the
performance of the overall chip with huge la
On Tue, May 02, 2017 at 12:53:16PM +0300, Petri Latvala wrote:
> On Wed, Apr 19, 2017 at 01:01:47PM +0200, Arkadiusz Hiler wrote:
> > Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
> > guard, and the file itself was included unconditionally.
>
> I see unconditional config.h
On Thu, May 04, 2017 at 11:00:33AM +0300, Petri Latvala wrote:
> On Wed, Apr 19, 2017 at 01:01:55PM +0200, Arkadiusz Hiler wrote:
> > Currently whole igt_kms.c is disabled while compiling on Android without
> > cairo, so this tests does not compile.
> >
> > There should be cleaner a way to disable
On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote:
> On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote:
> >
> >
> > On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace
> > > driver produced by Intel eng
On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> It seems that the DMC likes to transition between the DC states
> a lot when there are no connected displays (no active power
> domains) during simple command submission.
>
> This frantic activity on DC st
On 05/05/2017 12:16, Chris Wilson wrote:
On Fri, May 05, 2017 at 11:49:21AM +0100, Tvrtko Ursulin wrote:
On 03/05/2017 12:37, Chris Wilson wrote:
+static void port_assign(struct execlist_port *port,
+ struct drm_i915_gem_request *rq)
+{
+ GEM_BUG_ON(rq == port_requ
== Series Details ==
Series: drm/i915: Restore GT performance in headless mode with DMC loaded
URL : https://patchwork.freedesktop.org/series/24017/
State : success
== Summary ==
Series 24017v1 drm/i915: Restore GT performance in headless mode with DMC loaded
https://patchwork.freedesktop.org/
s/context/contention/ in subject
On Wed, May 03, 2017 at 12:37:57PM +0100, Chris Wilson wrote:
> If we do not require to perform priority bumping, and we haven't yet
> submitted the request, we can update its priority in situ and skip
> acquiring the engine locks -- thus avoiding any contention be
On Fri, May 05, 2017 at 12:49:49PM +0100, Chris Wilson wrote:
> On Fri, May 05, 2017 at 01:31:37PM +0200, Arkadiusz Hiler wrote:
> > On Thu, May 04, 2017 at 07:46:34PM -0700, Dmitry Rogozhkin wrote:
> > >
> > >
> > > On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > > > MediaSDK is not a benchmark.
On 03/05/2017 12:37, Chris Wilson wrote:
All the requests at the same priority are executed in FIFO order. They
do not need to be stored in the rbtree themselves, as they are a simple
list within a level. If we move the requests at one priority into a list,
we can then reduce the rbtree to the s
On 03/05/2017 12:37, Chris Wilson wrote:
If we do not require to perform priority bumping, and we haven't yet
submitted the request, we can update its priority in situ and skip
acquiring the engine locks -- thus avoiding any contention between us
and submit/execute.
Signed-off-by: Chris Wilson
On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
>
> On 03/05/2017 12:37, Chris Wilson wrote:
> > struct intel_engine_cs {
> >@@ -367,6 +373,7 @@ struct intel_engine_cs {
> >
> > /* Execlists */
> > struct tasklet_struct irq_tasklet;
> >+struct execlist_priolist default_
On 03/05/2017 12:37, Chris Wilson wrote:
Since we coordinate with the execlists tasklet using a locked schedule
operation that ensures that after we set the engine->irq_posted we
always have an invocation of the tasklet, we do not need to use a locked
operation to set the engine->irq_posted itse
On 05/05/2017 14:32, Chris Wilson wrote:
On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
On 03/05/2017 12:37, Chris Wilson wrote:
struct intel_engine_cs {
@@ -367,6 +373,7 @@ struct intel_engine_cs {
/* Execlists */
struct tasklet_struct irq_tasklet;
+ s
On Fri, May 05, 2017 at 02:30:08PM +0100, Tvrtko Ursulin wrote:
>
> On 03/05/2017 12:37, Chris Wilson wrote:
> >If we do not require to perform priority bumping, and we haven't yet
> >submitted the request, we can update its priority in situ and skip
> >acquiring the engine locks -- thus avoiding
On 03/05/2017 12:37, Chris Wilson wrote:
[snip]
+#include
+
+static inline void __list_del_many(struct list_head *head,
+ struct list_head *first)
+{
+ head->next = first;
+ first->prev = head;
+}
Btw it is similar to __list_cut_position, but wit
On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote:
>
> On 05/05/2017 14:32, Chris Wilson wrote:
> >On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 03/05/2017 12:37, Chris Wilson wrote:
> >>>struct intel_engine_cs {
> >>>@@ -367,6 +373,7 @@ struct intel_engi
On Mon, Mar 27, 2017 at 09:55:40PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have the maximum cursor dimensions stored in the mode_config, so
> let's just consult that information instead of hardcoding the same
> information in multiple places.
>
> We still need to
On Fri, May 05, 2017 at 02:50:46PM +0100, Tvrtko Ursulin wrote:
>
> On 03/05/2017 12:37, Chris Wilson wrote:
>
> [snip]
>
> >+#include
> >+
> >+static inline void __list_del_many(struct list_head *head,
> >+ struct list_head *first)
> >+{
> >+head->next = first
Jani,
Thanks for your quick and detailed response.
You wrote:
> The single DP link is divided to several logical links to sink devices.
Suppose the dock has a DVI and/or HDMI connector. Are those connectors
logical sinks to a master DisplayPort connection, or do they have their
own connection
On 05/05/2017 14:51, Chris Wilson wrote:
On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote:
On 05/05/2017 14:32, Chris Wilson wrote:
On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
On 03/05/2017 12:37, Chris Wilson wrote:
struct intel_engine_cs {
@@ -367,6 +373
On 05/05/2017 15:04, Chris Wilson wrote:
On Fri, May 05, 2017 at 02:50:46PM +0100, Tvrtko Ursulin wrote:
On 03/05/2017 12:37, Chris Wilson wrote:
[snip]
+#include
+
+static inline void __list_del_many(struct list_head *head,
+ struct list_head *first)
+{
+
On Fri, May 05, 2017 at 03:20:08PM +0100, Tvrtko Ursulin wrote:
>
> On 05/05/2017 14:51, Chris Wilson wrote:
> >On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 05/05/2017 14:32, Chris Wilson wrote:
> >>>On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
> >
Hi Dave,
Here's the first pull request for 4.13 from misc-next. It's surprisingly small
given that we had an extra week of feature freeze. The highlights are below, and
aside from these we had miscellaneous (heh) fixes sprinkled throughout.
A bit of administrivia for you:
We now have a standard t
On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> It seems that the DMC likes to transition between the DC states
> a lot when there are no connected displays (no active power
> domains) during simple command submission.
Is it trapping on some interrupt r
On Fri, 05 May 2017 08:55:31 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > >>Hmm, that looks like a rather strange way to return a file descriptor.
> > > >>
> > > >>What is the reason to not use ioctls on the vfio file handle, like
> > > >>older version of these patches did?
> > > >If I underst
Hi Dave,
Many apologies for missing your initial PR. Just one patch to fix up the panel
for HP zBook 17 G2.
drm-misc-next-fixes-2017-05-05:
Core Changes:
- Add quirk for LGD 764 panel to default 10bpc (Mario)
Cc: Mario Kleiner
Cheers, Sean
The following changes since commit 8b03d1ed2c43a2ba5e
In the merge timeline, remove the misc-next ~> drm-next merges while
the merge window is active, and during rc1. Pulls should only be requested
between rc2 and rc5.
Signed-off-by: Sean Paul
---
While the early PR no-no is fresh in my mind, I'll update the merge timeline
to avoid making the same
On 04/05/17 14:26, Srivatsa, Anusha wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Daniele Ceraolo Spurio
Sent: Thursday, May 4, 2017 11:52 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [RFC] drm/i915/guc: capture
On Mon, Mar 27, 2017 at 09:55:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> IVB introduced the CUR_FBC_CTL register which allows reducing the cursor
> height down to 8 lines from the otherwise square cursor dimensions.
> Implement support for it. CUR_FBC_CTL can't be
On 04/05/17 14:31, Chris Wilson wrote:
On Thu, May 04, 2017 at 09:26:35PM +, Srivatsa, Anusha wrote:
+void i915_guc_load_error_log_capture(struct drm_i915_private *i915) {
+ void *log, *buf;
+ struct i915_vma *vma = i915->guc.log.vma;
+
+ if (i915->gpu_error.guc_load_fail
On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote:
>
> On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace
> > driver produced by Intel engineers, one which Intel has the full
> > capability to change. What you're saying
On Fri, May 05, 2017 at 08:43:36AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 04/05/17 14:31, Chris Wilson wrote:
> >On Thu, May 04, 2017 at 09:26:35PM +, Srivatsa, Anusha wrote:
> >>>+void i915_guc_load_error_log_capture(struct drm_i915_private *i915) {
> >>>+ void *log, *buf;
> >>>+ st
On 05/05/2017 15:49, Ville Syrjälä wrote:
On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It seems that the DMC likes to transition between the DC states
a lot when there are no connected displays (no active power
domains) during simple command submission.
On 5/5/2017 8:44 AM, Kenneth Graunke wrote:
On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote:
On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace
driver produced by Intel engineers, one which Intel has the full
capabili
On Fri, May 05, 2017 at 05:13:58PM +0100, Tvrtko Ursulin wrote:
>
> On 05/05/2017 15:49, Ville Syrjälä wrote:
> > On Fri, May 05, 2017 at 12:43:21PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> It seems that the DMC likes to transition between the DC states
> >> a lot when the
>-Original Message-
>From: Nikula, Jani
>Sent: Thursday, May 4, 2017 2:25 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Vivi, Rodrigo ; Ville Syrjala
>; Srivatsa, Anusha
>Subject: Re: [PATCH] drm/i915/cnp: Backlight support for CNP.
>
>On Wed, 03 May 2017, Anusha Sri
On Fri, 05 May 2017, Sanford Rockowitz wrote:
> Jani,
>
> Thanks for your quick and detailed response.
>
> You wrote:
>
>> The single DP link is divided to several logical links to sink devices.
>
> Suppose the dock has a DVI and/or HDMI connector. Are those connectors
> logical sinks to a maste
On Fri, 05 May 2017, "Srivatsa, Anusha" wrote:
>>-Original Message-
>>From: Nikula, Jani
>>Sent: Thursday, May 4, 2017 2:25 AM
>>To: Srivatsa, Anusha ; intel-
>>g...@lists.freedesktop.org
>>Cc: Vivi, Rodrigo ; Ville Syrjala
>>; Srivatsa, Anusha
>>Subject: Re: [PATCH] drm/i915/cnp: Backlig
El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> In several instances the driver passes an 'enum pipe' value to a
> function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> TRANSCODER_x have the same values this doesn't cause functional
> problems. Still it is
On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>
> > In several instances the driver passes an 'enum pipe' value to a
> > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> > TRANSCODER_
We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them after driver load is completed.
v2: keep the object around instead of using kernel memory (chris)
don't store the l
Add option to allow choosing how to adjust brightness if
panel supports both PWM pin and AUX channel.
Signed-off-by: Puthikorn Voravootivat
---
Fix compile error in v5
drivers/gpu/drm/i915/i915_params.c| 8 +---
drivers/gpu/drm/i915/i915_params.h| 2 +-
drivers/gpu
On Mon, Mar 27, 2017 at 09:55:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Bspec tells us that gen3 platforms need 4KiB alignment for CURBASE
> rather than the 256 byte alignment required by i85x. Let's fix that
> and pull the code to determine the correct alignment
On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
wrote:
> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>>
>> > In several instances the driver passes an 'enum pipe' value to a
>> > function expecting an 'enum
On Fri, May 05, 2017 at 10:45:47AM -0700, Daniele Ceraolo Spurio wrote:
> We're currently deleting the GuC logs if the FW fails to load, but those
> are still useful to understand why the loading failed. Keeping the
> object around allows us to access them after driver load is completed.
>
> v2: k
== Series Details ==
Series: drm/i915/guc: capture GuC logs if FW fails to load (rev2)
URL : https://patchwork.freedesktop.org/series/23982/
State : success
== Summary ==
Series 23982v2 drm/i915/guc: capture GuC logs if FW fails to load
https://patchwork.freedesktop.org/api/1.0/series/23982/re
On Friday, May 5, 2017 9:21:54 AM PDT Dmitry Rogozhkin wrote:
> > My point largely stands, when redirected - someone is developing a
> > broken closed source userspace driver and is apparently unwilling to
> > change it. That's the real problem.
> Broken? Have you ever attempted to run functional
Last question (I think). You wrote:
> You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
that's where the problem is.
Where do I go to post this problem?
Thanks,
Sanford
On 05/05/2017 12:49 PM, Jani Nikula wrote:
> On Fri, 05 May 2017, Sanford Rockowitz wrote:
>> Jani,
>>
On Fri, May 05, 2017 at 12:12:49PM -0700, Grant Grundler wrote:
> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
> wrote:
> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> >> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> >>
> >> > In several instances
On Fri, 05 May 2017, Sanford Rockowitz wrote:
> Last question (I think). You wrote:
>
>> You'll want the DP MST I2C code fixed. Well, at least it's my *guess*
> that's where the problem is.
>
> Where do I go to post this problem?
Sorry, I could have added that in my previous reply!
https://bug
The decission to enable GuC loading shouldn't be left to the user.
Provided the HW supports the GuC, there are only two reasons to load it:
- The user has requested GuC submission.
- We have a HuC firmware available (so we need the GuC to validate it).
We leave the enable_guc_submission parameter
AFAIK, every platform with a HuC has a GuC and viceversa, so
make it explicit.
Cc: Anusha Srivatsa
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
CC: Arkadiusz Hiler
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
drivers/gpu/drm/i915/i915_drv.h | 6
On Fri, May 05, 2017 at 03:53:39AM -0400, Sanford Rockowitz wrote:
> I am the author of ddcutil (www.ddcutil.com), a Linux utility that
> manages monitor settings using DDC/CI. I am seeing a pattern of user
> error reports in which I2C communication is not working when a system
> with a recent Inte
On Fri, May 5, 2017 at 1:08 PM, Ville Syrjälä
wrote:
...
>> > I'm not convinced the patch is making things any better really. To
>> > fix this really properly, I think we'd need to introduce a new enum
>> > pch_transcoder and thus avoid the confusion of which type of
>> > transcoder we're talking
>-Original Message-
>From: Mateo Lozano, Oscar
>Sent: Friday, May 5, 2017 6:23 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Mateo Lozano, Oscar ; Srivatsa, Anusha
>; Ceraolo Spurio, Daniele
>; Chris Wilson ;
>Hiler, Arkadiusz
>Subject: [PATCH RFC 2/2] drm/i915/guc: Rename has_guc to has_
On Fri, 2017-05-05 at 19:50 +0300, Jani Nikula wrote:
> On Fri, 05 May 2017, "Srivatsa, Anusha" wrote:
> >>-Original Message-
> >>From: Nikula, Jani
> >>Sent: Thursday, May 4, 2017 2:25 AM
> >>To: Srivatsa, Anusha ; intel-
> >>g...@lists.freedesktop.org
> >>Cc: Vivi, Rodrigo ; Ville Syrjal
>-Original Message-
>From: Pandiyan, Dhinakaran
>Sent: Friday, May 5, 2017 1:35 PM
>To: Nikula, Jani
>Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
>Taylor, Clinton A ; Srivatsa, Anusha
>
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.
>
>On Fri, 2017-05
== Series Details ==
Series: series starting with [1/2] drm/i915/guc: Get rid of the
enable_guc_loading module parameter
URL : https://patchwork.freedesktop.org/series/24048/
State : success
== Summary ==
Series 24048v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/ser
On Mon, Mar 27, 2017 at 09:55:44PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The cursor plane doesn't have any kind of source offset register, so
> the only form of panning possible is via a the base address register.
> The alignment required by CURBASE ranges from 32B
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were
5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP lin
Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate. Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow t
These patches, along with an upcoming series for IGT, enable our
PSR IGT tests to run reliably once again. The first change
enables us to run the PSR tests on SKL and KBL RVP platforms,
whose panels have too slow of a setup time when running in their
preferred mode. The second fixes a minor probl
On SKL+ there is a bit in SRD_CTL that software is not supposed to
modify, but we currently clobber that bit when we enable PSR. In
order to preserve the value of that bit, go ahead and read SRD_CTL and
do a field-wise setting of the various bits that we need to initialize
before writing the regis
According to the eDP spec, when the count field in TEST_SINK_MISC
increments then the six bytes of sink CRC information in the DPCD
should be valid. Unfortunately, this doesn't seem to be the case
on some panels, and as a result we get some incorrect and inconsistent
values from the sink CRC DPCD
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_psr_sink_crc.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 1a03719..8d26b68 100644
--- a/tests/kms_psr_sink_cr
These patches, along with the kernel series at
https://patchwork.freedesktop.org/series/24049/ allow our PSR
IGT tests to run more predictably on HSW, SKL, and KBL. These
patches depend on the kernel series in order to run properly. On
the systems I have available the following sets of tests run
Factor out some code that was replicated in three test utilities into
some new IGT library functions so that we are checking PSR status in
a consistent fashion across all of our PSR tests.
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
lib/Makefile.sources | 2 +
lib/igt.h
Make assert_or_manual() a macro so that we get accurate line number
information when this assertion fails.
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_psr_sink_crc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/kms_psr_sink_c
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_frontbuffer_tracking.c | 95 +---
1 file changed, 10 insertions(+), 85 deletions(-)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c24e4a8..839d2
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_fbcon_fbt.c| 56
tests/kms_psr_sink_crc.c | 36 +--
2 files changed, 49 insertions(+), 43 deletions(-)
diff --git a/tests/kms_fbcon_fbt.c b/
On Mon, Mar 27, 2017 at 09:55:45PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Supposedly 845/865 require only 32 byte alignment for CURBASE. Let's
> relax the checks to allow that instead of demanding 4KiB alignment.
> This will allow cursor panning in 8 pixel units.
>
1 - 100 of 108 matches
Mail list logo
