== Series Details ==
Series: drm/i915/selftests: Filter out both physical address swizzles
URL : https://patchwork.freedesktop.org/series/46214/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4456_full -> Patchwork_9597_full =
== Summary - WARNING ==
Minor unknown changes
On 2018.07.09 18:24:10 +0800, intel-gvt-dev-boun...@lists.freedesktop.org wrote:
> From: Hang Yuan
>
> This helps initramfs builder and other tools to know the full dependencies
> of i915 and have gvt module loaded with i915.
>
> v2: add condition and change to pre-dependency (Chris)
> v3: move
== Series Details ==
Series: series starting with kernel.h: Add for_each_if() (rev3)
URL : https://patchwork.freedesktop.org/series/46158/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4455_full -> Patchwork_9596_full =
== Summary - WARNING ==
Minor unknown changes comin
== Series Details ==
Series: series starting with [1/2] drm/i915: remove confusing GPIO vs PCH_GPIO
URL : https://patchwork.freedesktop.org/series/46200/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4455_full -> Patchwork_9595_full =
== Summary - WARNING ==
Minor unknow
== Series Details ==
Series: drm/i915: Use crtc_state->has_psr instead of CAN_PSR for pipe update
(rev4)
URL : https://patchwork.freedesktop.org/series/46104/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4458 -> Patchwork_9600 =
== Summary - SUCCESS ==
No regressions f
In commit "drm/i915: Wait for PSR exit before checking for vblank
evasion", the idea was to limit the PSR IDLE checks when PSR is
actually supported. While CAN_PSR does do that check, it doesn't
applies on a per-crtc basis. crtc_state->has_psr is a more granular
check that only applies to pipe(s) t
== Series Details ==
Series: Kill resource streamer
URL : https://patchwork.freedesktop.org/series/46224/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4458 -> Patchwork_9599 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.
== Series Details ==
Series: Kill resource streamer
URL : https://patchwork.freedesktop.org/series/46224/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/icl: move has_resource_streamer to GEN11_FEATURES
Okay!
Commit: drm/i915: kill resource streamer
-drivers/gpu/dr
First patch is makes sense for ICL since it doesn't have resource
streamer. It has been a feature that was never properly tested/used so
also kill it on second patch - this is a tentative/rfc: see commit
message.
Lucas De Marchi (2):
drm/i915/icl: move has_resource_streamer to GEN11_FEATURES
d
After disabling resource streamer on ICL (due to it actually not
existing there), I got feedback that there have been some experimental
patches for mesa to use it, but nothing ever landed nor shipped.
This is a tentative to remove it from kernel keeping the uapi defines
around for compatibility. W
Resource streamer has been removed on GEN11 so move it to the FEATURES
macro.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_pci.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i9
Em Sex, 2018-07-06 às 19:09 -0700, Lucas De Marchi escreveu:
> On Fri, May 4, 2018 at 1:33 PM Paulo Zanoni > wrote:
> >
> > Now that our stolen memory is already reserved by the x86 subsystem
> > (since commit "x86/gpu: reserve ICL's graphics stolen memory"),
> > make
> > use of it.
> >
> > Cc:
On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter wrote:
> To avoid compilers complainig about ambigious else blocks when putting
> an if condition into a for_each macro one needs to invert the
> condition and add a dummy else. We have a nice little convenience
> macro for that in drm headers, let
On Mon, 2018-07-09 at 14:28 -0700, Tarun Vyas wrote:
> In commit "drm/i915: Wait for PSR exit before checking for vblank
> evasion", the idea was to limit the PSR IDLE checks when PSR is
> actually supported. While CAN_PSR does do that check, it doesn't
> applies on a per-crtc basis. crtc_state->ha
On Mon, Jul 09, 2018 at 10:36:48AM +0200, Daniel Vetter wrote:
> Avoids the inverted condition compared to the open-coded version.
>
> Signed-off-by: Daniel Vetter
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
I assume you'll merge this with the rest of the serie
== Series Details ==
Series: drm/i915: Use crtc_state->has_psr instead of CAN_PSR for pipe update
(rev3)
URL : https://patchwork.freedesktop.org/series/46104/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4456 -> Patchwork_9598 =
== Summary - SUCCESS ==
No regressions f
== Series Details ==
Series: drm/i915: Use crtc_state->has_psr instead of CAN_PSR for pipe update
(rev3)
URL : https://patchwork.freedesktop.org/series/46104/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fc0aabf8423b drm/i915: Use crtc_state->has_psr instead of CAN_PSR for pi
On Mon, Jul 9, 2018 at 6:11 PM, Daniel Vetter wrote:
> Avoids the inverted condition compared to the open coded version.
>
> Signed-off-by: Daniel Vetter
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: linux...@vger.kernel.org
> Cc: Eric Engestrom
> --
> v2: Fix the logic fumble in the 2nd
In commit "drm/i915: Wait for PSR exit before checking for vblank
evasion", the idea was to limit the PSR IDLE checks when PSR is
actually supported. While CAN_PSR does do that check, it doesn't
applies on a per-crtc basis. crtc_state->has_psr is a more granular
check that only applies to pipe(s) t
On Thu, Jul 05, 2018 at 07:43:54PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the enum hpd_pin type when talking about HPD pins, and rename the
> variable from a very nondescript 'i' to 'pin', a name we already
> use in other parts of the code.
>
> Signed-off-by: Ville Syrjälä
R
On Thu, Jul 05, 2018 at 07:43:53PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of looping over ports and hpd_pins, let's loop over
> the encoders when doing hotplug processing. And instead of
> depending on dev_priv->irq_port[] to tell us whether the
> encoder has the ->hpd_puls
On Mon, Jul 09, 2018 at 09:14:05PM +0100, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2018-07-09 18:51:02)
> > On Mon, Jul 09, 2018 at 02:48:58PM +0100, Chris Wilson wrote:
> > > Error messages are intended to be addressed to the user; be clear,
> > > succinct, instructive and unambiguous. Adding t
== Series Details ==
Series: drm/i915/selftests: Filter out both physical address swizzles
URL : https://patchwork.freedesktop.org/series/46214/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4456 -> Patchwork_9597 =
== Summary - SUCCESS ==
No regressions found.
Extern
== Series Details ==
Series: drm/i915: Remove function details from device error messages
URL : https://patchwork.freedesktop.org/series/46187/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4454_full -> Patchwork_9594_full =
== Summary - FAILURE ==
Serious unknown change
On Wed, Jun 27, 2018 at 02:10:09PM +0530, Ramalingam C wrote:
> On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
> integrity check for the HDCP version that is enabled.
>
> v2:
> Rebased. Function name is changed.
> v3:
> No Changes.
> v4:
> No Changes.
> v5:
> No Changes.
>
On Wed, Jun 27, 2018 at 02:10:08PM +0530, Ramalingam C wrote:
> HDCP check link is invoked only on CP_IRQ detection, instead of all
> short pulses.
>
> v3:
> No Changes.
> v4:
> Added sean in cc and collected the reviewed-by received.
> v5:
> No Change.
>
> Signed-off-by: Ramalingam C
Rev
On Wed, Jun 27, 2018 at 02:10:02PM +0530, Ramalingam C wrote:
> Implements a sequence of enabling and disabling the HDCP2.2
> (auth and encryption).
This is really hard to review, since all I see are stubs. I'd much rather have
each patch do something useful, instead of just call stubs. That said,
On Wed, Jun 27, 2018 at 02:10:01PM +0530, Ramalingam C wrote:
> When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
> enabled.
>
Just squash this into patch 11, no need for a separate patch.
> v2:
> Rebased.
> v3:
> No Changes.
> v4:
> Reviewed-by is collected.
> v5:
> No Ch
On Wed, Jun 27, 2018 at 02:10:00PM +0530, Ramalingam C wrote:
> Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
> supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
>
> v2:
> Included few optimization suggestions [Chris Wilson]
> Commit message is updated as per the reba
On Wed, Jun 27, 2018 at 02:09:59PM +0530, Ramalingam C wrote:
> For reusability purpose, this patch implements the hdcp1.4 bksv's
> read and validation as a functions.
>
> For detecting the HDMI panel's HDCP capability this fucntions will be
> used.
>
> v2:
> Rebased.
> v3:
> No Changes.
> v4
On Wed, Jun 27, 2018 at 02:09:58PM +0530, Ramalingam C wrote:
> As a preparation for making the intel_hdcp_enable as common function
> for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved
> into _intel_hdcp_enable() function.
>
> v3:
> No Changes.
> v4:
> Style fix.
> v5:
> N
On Wed, Jun 27, 2018 at 02:09:56PM +0530, Ramalingam C wrote:
> Intel HDCP2.2 registers are defined with addr offsets and bit details.
>
> v2:
> Replaced the arith calc with _PICK [Sean Paul]
> v3:
> No changes.
> v4:
> %s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
> v5:
> Added parentheses for the
On Wed, Jun 27, 2018 at 02:09:55PM +0530, Ramalingam C wrote:
> For upcoming implementation of HDCP2.2 in I915, important variable
> required for HDCP2.2 are defined.
Please just introduce them when you use them. I can't provide useful review on
this patch unless I can see how the variables are us
On Wed, Jun 27, 2018 at 02:09:54PM +0530, Ramalingam C wrote:
> Considering significant number of HDCP specific variables, it will
> be clean to have separate struct for HDCP.
>
> New structure called intel_hdcp is added within intel_connector.
>
> v2:
> struct hdcp statically allocated. [Sean
On Mon, Jul 09, 2018 at 01:31:52PM -0700, Dhinakaran Pandiyan wrote:
> On Mon, 2018-07-09 at 12:52 -0700, Tarun Vyas wrote:
> > On Mon, Jul 09, 2018 at 11:58:52AM -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Mon, 2018-07-09 at 11:16 -0700, Tarun Vyas wrote:
> > > >
> > > > On Mon, Jul 09, 201
On Wed, Jun 27, 2018 at 02:09:51PM +0530, Ramalingam C wrote:
> This patch adds HDCP register definitions for HDMI and DP HDCP
> adaptations.
>
> HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
> where as HDCP2.2 register offsets in DPCD offsets are defined at
> drm_dp_helper
On Wed, Jun 27, 2018 at 02:09:50PM +0530, Ramalingam C wrote:
> This patch defines the hdcp2.2 protocol messages for authentication.
>
> v2:
> bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
> prefix HDCP_2_2_ is added to the macros. [Tomas]
> v3:
> No Changes.
> v4:
> St
Quoting Rodrigo Vivi (2018-07-09 18:51:02)
> On Mon, Jul 09, 2018 at 02:48:58PM +0100, Chris Wilson wrote:
> > Error messages are intended to be addressed to the user; be clear,
> > succinct, instructive and unambiguous. Adding the function name to
> > that message does not add any information the
On Mon, 2018-07-09 at 12:52 -0700, Tarun Vyas wrote:
> On Mon, Jul 09, 2018 at 11:58:52AM -0700, Dhinakaran Pandiyan wrote:
> >
> > On Mon, 2018-07-09 at 11:16 -0700, Tarun Vyas wrote:
> > >
> > > On Mon, Jul 09, 2018 at 11:30:00AM -0700, Dhinakaran Pandiyan
> > > wrote:
> > > >
> > > >
> > > >
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev5)
URL : https://patchwork.freedesktop.org/series/40181/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4454_full -> Patchwork_9592_full =
== Summary - FAILURE ==
Serious unknown cha
On Mon, Jul 09, 2018 at 11:58:52AM -0700, Dhinakaran Pandiyan wrote:
> On Mon, 2018-07-09 at 11:16 -0700, Tarun Vyas wrote:
> > On Mon, Jul 09, 2018 at 11:30:00AM -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Sun, 2018-07-08 at 18:46 -0700, Tarun Vyas wrote:
> > > >
> > > > In commit "drm/i915
In our swizzling selftests, we cannot predict the physical address of
the target page (at least not simply!) and so skip bit17 swizzles.
However, there are two bit17 swizzle modes and we only skipped on, with
the second being observed on the lab gdg causing the test to fail,
as soon as we hit a pag
On Mon, Jul 09, 2018 at 12:58:28PM -0700, Dhinakaran Pandiyan wrote:
> On Mon, 2018-07-09 at 12:24 -0700, Rodrigo Vivi wrote:
> > On Mon, Jul 09, 2018 at 11:30:00AM -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Sun, 2018-07-08 at 18:46 -0700, Tarun Vyas wrote:
> > > >
> > > > In commit "drm/i9
On Mon, 2018-07-09 at 12:24 -0700, Rodrigo Vivi wrote:
> On Mon, Jul 09, 2018 at 11:30:00AM -0700, Dhinakaran Pandiyan wrote:
> >
> > On Sun, 2018-07-08 at 18:46 -0700, Tarun Vyas wrote:
> > >
> > > In commit "drm/i915: Wait for PSR exit before checking for vblank
> > > evasion", the idea was to
On Mon, Jul 09, 2018 at 11:30:00AM -0700, Dhinakaran Pandiyan wrote:
> On Sun, 2018-07-08 at 18:46 -0700, Tarun Vyas wrote:
> > In commit "drm/i915: Wait for PSR exit before checking for vblank
> > evasion", the idea was to limit the PSR IDLE checks when PSR is
> > actually supported. While CAN_PSR
On Fri, Jul 06, 2018 at 07:09:15PM -0700, Lucas De Marchi wrote:
> On Fri, May 4, 2018 at 1:33 PM Paulo Zanoni wrote:
> >
> > Now that our stolen memory is already reserved by the x86 subsystem
> > (since commit "x86/gpu: reserve ICL's graphics stolen memory"), make
> > use of it.
> >
> > Cc: Joon
== Series Details ==
Series: series starting with [01/11] drm/i915/selftests: Prevent background
reaping of active objects
URL : https://patchwork.freedesktop.org/series/46176/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4454_full -> Patchwork_9591_full =
== Summary - FA
On Mon, 2018-07-09 at 11:16 -0700, Tarun Vyas wrote:
> On Mon, Jul 09, 2018 at 11:30:00AM -0700, Dhinakaran Pandiyan wrote:
> >
> > On Sun, 2018-07-08 at 18:46 -0700, Tarun Vyas wrote:
> > >
> > > In commit "drm/i915: Wait for PSR exit before checking for vblank
> > > evasion", the idea was to li
On Mon, 2018-07-09 at 18:25 +0200, Daniel Vetter wrote:
> v2: Explain a bit better what this is good for, after the discussion
> with Peter Z.
Since I have not been Cc'ed to your discussion there is another
weirdness which this macro prohibits, i.e.
for_each_blah() {
} else {
...blahblah...
}
On Mon, Jul 09, 2018 at 11:30:00AM -0700, Dhinakaran Pandiyan wrote:
> On Sun, 2018-07-08 at 18:46 -0700, Tarun Vyas wrote:
> > In commit "drm/i915: Wait for PSR exit before checking for vblank
> > evasion", the idea was to limit the PSR IDLE checks when PSR is
> > actually supported. While CAN_PSR
On Sat, Jul 07, 2018 at 08:32:16AM +0200, Hans de Goede wrote:
> Hi,
>
> On 07/06/2018 04:16 PM, Ville Syrjälä wrote:
> > On Tue, Jun 19, 2018 at 10:18:27PM +0200, Hans de Goede wrote:
> >> On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
> >> different frequency then the pclk
On Sun, 2018-07-08 at 18:46 -0700, Tarun Vyas wrote:
> In commit "drm/i915: Wait for PSR exit before checking for vblank
> evasion", the idea was to limit the PSR IDLE checks when PSR is
> actually supported. While CAN_PSR does do that check, it doesn't
> applies on a per-crtc basis. crtc_state->ha
On Mon, Jul 9, 2018 at 6:12 PM, Mark Rutland wrote:
> On Mon, Jul 09, 2018 at 06:03:42PM +0200, Peter Zijlstra wrote:
>> On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
>> > for_each_something(foo)
>> > if (foo->bla)
>> > call_bla(foo);
>> > else
>> >
On Mon, Jul 09, 2018 at 02:48:58PM +0100, Chris Wilson wrote:
> Error messages are intended to be addressed to the user; be clear,
> succinct, instructive and unambiguous. Adding the function name to
> that message does not add any information the user requires and in
> the process makes the messag
Hi,
On 07/09/2018 07:37 PM, Rodrigo Vivi wrote:
On Sat, Jul 07, 2018 at 08:32:16AM +0200, Hans de Goede wrote:
Hi,
On 07/06/2018 04:16 PM, Ville Syrjälä wrote:
On Tue, Jun 19, 2018 at 10:18:27PM +0200, Hans de Goede wrote:
On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
On Sat, Jul 07, 2018 at 08:32:16AM +0200, Hans de Goede wrote:
> Hi,
>
> On 07/06/2018 04:16 PM, Ville Syrjälä wrote:
> > On Tue, Jun 19, 2018 at 10:18:27PM +0200, Hans de Goede wrote:
> > > On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
> > > different frequency then the pc
On Mon, Jul 09, 2018 at 06:03:42PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
> > for_each_something(foo)
> > if (foo->bla)
> > call_bla(foo);
> > else
> > call_default(foo);
> >
> > Totally contrived, but this comp
On Mon, 9 Jul 2018, Daniel Vetter wrote:
> Avoids the inverted check compared to the open-coded version.
>
> Signed-off-by: Daniel Vetter
> Cc: Finn Thain
> Cc: linux-m...@lists.linux-m68k.org
Acked-by: Finn Thain
> ---
> include/linux/nubus.h | 2 +-
> 1 file changed, 1 insertion(+), 1 del
== Series Details ==
Series: series starting with kernel.h: Add for_each_if() (rev3)
URL : https://patchwork.freedesktop.org/series/46158/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4455 -> Patchwork_9596 =
== Summary - SUCCESS ==
No regressions found.
External URL
== Series Details ==
Series: series starting with kernel.h: Add for_each_if() (rev3)
URL : https://patchwork.freedesktop.org/series/46158/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
071bf8d2 kernel.h: Add for_each_if()
-:6: WARNING:TYPO_SPELLING: 'ambigious' may be missp
== Series Details ==
Series: series starting with [1/2] drm/i915: remove confusing GPIO vs PCH_GPIO
URL : https://patchwork.freedesktop.org/series/46200/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4455 -> Patchwork_9595 =
== Summary - SUCCESS ==
No regressions found.
Quoting Tvrtko Ursulin (2018-07-09 17:28:02)
>
> On 09/07/2018 14:20, Tomasz Lis wrote:
> > +static int i915_gem_context_clear_data_port_coherent(struct
> > i915_gem_context *ctx)
> > +{
> > + int ret;
> > +
> > + ret = intel_lr_context_modify_data_port_coherency(ctx, false);
> > + if
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Provide a timeout to
i915_gem_wait_for_idle()
URL : https://patchwork.freedesktop.org/series/46175/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4453_full -> Patchwork_9590_full =
== Summary - WARNING ==
On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
> for_each_something(foo)
> if (foo->bla)
> call_bla(foo);
> else
> call_default(foo);
Note that the kernel coding style 'discourages' this style and would
like you to write:
for_each_so
On 09/07/2018 14:20, Tomasz Lis wrote:
The patch adds a parameter to control the data port coherency functionality
on a per-context level. When the IOCTL is called, a command to switch data
port coherency state is added to the ordered list. All prior requests are
executed on old coherency settin
To avoid compilers complainig about ambigious else blocks when putting
an if condition into a for_each macro one needs to invert the
condition and add a dummy else. We have a nice little convenience
macro for that in drm headers, let's move it out. Subsequent patches
will roll it out to other place
Now they are the same as GMBUS*, but without considering the different
address bases. In order to use GMBUS* we just need access to dev_priv in
a few places so this has been added.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/edid.c | 42 +
drivers/
Instead of defining all registers twice, define just a PCH_GPIO_BASE
that has the same address as PCH_GPIO_A and use that to calculate all
the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
the same thing.
This also rewrites the GMBUS[05] registers since they depend on
gpio_mmio
Avoids the inverted condition compared to the open coded version.
Signed-off-by: Daniel Vetter
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Cc: Eric Engestrom
--
v2: Fix the logic fumble in the 2nd hunk, spotted by Eric.
---
include/linux/cpufreq.h | 8 ++--
1 fil
On Mon, Jul 9, 2018 at 6:03 PM, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
>> for_each_something(foo)
>> if (foo->bla)
>> call_bla(foo);
>> else
>> call_default(foo);
>>
>> Totally contrived, but this complains. Li
On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
> for_each_something(foo)
> if (foo->bla)
> call_bla(foo);
> else
> call_default(foo);
>
> Totally contrived, but this complains. Liberally sprinkling {} also shuts
> up the compiler, but it's a
On Mon, Jul 09, 2018 at 05:12:58PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 05:00:07PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra
> > wrote:
> > > On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote:
>
> > >> #define for_each_node_wit
On Monday 09 July 2018 08:40 PM, Daniel Vetter wrote:
On Mon, Jul 09, 2018 at 07:01:09PM +0530, Ramalingam C wrote:
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required component registration.
v2:
mei interface handle is protected with mutex. [Chri
On 2018-07-09 16:24, Lionel Landwerlin wrote:
On 09/07/18 15:03, Lis, Tomasz wrote:
On 2018-07-09 15:48, Lionel Landwerlin wrote:
On 09/07/18 14:20, Tomasz Lis wrote:
The patch adds a parameter to control the data port coherency
functionality
on a per-context level. When the IOCTL is calle
On Mon, Jul 09, 2018 at 05:00:07PM +0200, Daniel Vetter wrote:
> On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra wrote:
> > On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote:
> >> #define for_each_node_with_cpus(node)\
> >> for_each_online_node(node)
On Mon, Jul 09, 2018 at 07:01:09PM +0530, Ramalingam C wrote:
> Initialize HDCP2.2 support. This includes the mei interface
> initialization along with required component registration.
>
> v2:
> mei interface handle is protected with mutex. [Chris Wilson]
> v3:
> Notifiers are used for the mei
On Mon, Jul 9, 2018 at 12:36 PM, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 10:36:49AM +0200, Daniel Vetter wrote:
>> Avoids complaints from gcc about ambiguous else clauses.
>
> Is that a new thing? I'm fairly sure I've never seen it do that,
>
>> Signed-off-by: Daniel Vetter
>> Cc: Andrew
== Series Details ==
Series: drm/i915: Remove function details from device error messages
URL : https://patchwork.freedesktop.org/series/46187/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4454 -> Patchwork_9594 =
== Summary - SUCCESS ==
No regressions found.
Externa
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-07-09 15:13:44)
>> Chris Wilson writes:
>>
>> > Across a reset, the seqno (and thus hangcheck) should restart and the
>> > hangcheck naturally progress, for when it does not, we want to declare an
>> > emergency. Currently, we only detect if re
Quoting Mika Kuoppala (2018-07-09 15:13:44)
> Chris Wilson writes:
>
> > Across a reset, the seqno (and thus hangcheck) should restart and the
> > hangcheck naturally progress, for when it does not, we want to declare an
> > emergency. Currently, we only detect if reset and reinit fails, but we
>
On 09/07/18 15:03, Lis, Tomasz wrote:
On 2018-07-09 15:48, Lionel Landwerlin wrote:
On 09/07/18 14:20, Tomasz Lis wrote:
The patch adds a parameter to control the data port coherency
functionality
on a per-context level. When the IOCTL is called, a command to
switch data
port coherency state
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev5)
URL : https://patchwork.freedesktop.org/series/40181/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4454 -> Patchwork_9592 =
== Summary - SUCCESS ==
No regressions found.
Exte
Chris Wilson writes:
> Across a reset, the seqno (and thus hangcheck) should restart and the
> hangcheck naturally progress, for when it does not, we want to declare an
> emergency. Currently, we only detect if reset and reinit fails, but we
> do not detect if the call to reinit succeeds but the
== Series Details ==
Series: drm/i915: Initialize HDCP2.2 and its MEI interface
URL : https://patchwork.freedesktop.org/series/46180/
State : failure
== Summary ==
Applying: drm/i915: Initialize HDCP2.2 and its MEI interface
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915/
On 2018-07-09 15:48, Lionel Landwerlin wrote:
On 09/07/18 14:20, Tomasz Lis wrote:
The patch adds a parameter to control the data port coherency
functionality
on a per-context level. When the IOCTL is called, a command to switch
data
port coherency state is added to the ordered list. All prio
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev5)
URL : https://patchwork.freedesktop.org/series/40181/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Add IOCTL Param to control data port coherency.
-drivers/gpu/drm/i915/s
== Series Details ==
Series: drm/i915: Add Exec param to control data port coherency. (rev5)
URL : https://patchwork.freedesktop.org/series/40181/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c705f01c81f1 drm/i915: Add IOCTL Param to control data port coherency.
-:15: WARNING:
Quoting Mika Kuoppala (2018-07-09 14:48:31)
> Chris Wilson writes:
>
> > igt_mmap_offset_exhaustion() wants to test what happens when the mmap
> > space is filled with zombie objects, objects discarded by userspace but
> > still active on the GPU. As they are only protected by the active
> > refe
== Series Details ==
Series: series starting with [1/3] drm/i915: Provide a timeout to
i915_gem_wait_for_idle()
URL : https://patchwork.freedesktop.org/series/46170/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4453_full -> Patchwork_9589_full =
== Summary - WARNING ==
== Series Details ==
Series: series starting with [01/11] drm/i915/selftests: Prevent background
reaping of active objects
URL : https://patchwork.freedesktop.org/series/46176/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4454 -> Patchwork_9591 =
== Summary - SUCCESS ==
Chris Wilson writes:
> igt_mmap_offset_exhaustion() wants to test what happens when the mmap
> space is filled with zombie objects, objects discarded by userspace but
> still active on the GPU. As they are only protected by the active
> reference, we have to be certain that active reference is ke
Error messages are intended to be addressed to the user; be clear,
succinct, instructive and unambiguous. Adding the function name to
that message does not add any information the user requires and in
the process makes the message less clear.
E.g.
[ 245.539711] i915 :00:02.0: [drm:i915_gem_i
On 09/07/18 14:20, Tomasz Lis wrote:
The patch adds a parameter to control the data port coherency functionality
on a per-context level. When the IOCTL is called, a command to switch data
port coherency state is added to the ordered list. All prior requests are
executed on old coherency settings,
== Series Details ==
Series: series starting with [01/11] drm/i915/selftests: Prevent background
reaping of active objects
URL : https://patchwork.freedesktop.org/series/46176/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/selftests: Prevent background reaping of
On 09/07/2018 14:26, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-09 14:19:56)
From: Tvrtko Ursulin
vis library has a limited precision compared to our trace data which
prevents zooming into the timeline and seeing the fine detail.
Scale the HTML view by a thousand to work around it.
== Series Details ==
Series: series starting with [01/11] drm/i915/selftests: Prevent background
reaping of active objects
URL : https://patchwork.freedesktop.org/series/46176/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d53e6a02a19e drm/i915/selftests: Prevent background re
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required component registration.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out
Quoting Tvrtko Ursulin (2018-07-09 14:19:56)
> From: Tvrtko Ursulin
>
> vis library has a limited precision compared to our trace data which
> prevents zooming into the timeline and seeing the fine detail.
>
> Scale the HTML view by a thousand to work around it.
Shouldn't there be some clue in
Quoting Ville Syrjälä (2018-07-09 14:19:40)
> On Mon, Jul 09, 2018 at 11:28:47AM +0100, Chris Wilson wrote:
> > gem_render_copy requires a working GPU so check first.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/gem_render_copy.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff -
The patch adds a parameter to control the data port coherency functionality
on a per-context level. When the IOCTL is called, a command to switch data
port coherency state is added to the ordered list. All prior requests are
executed on old coherency settings, and all exec requests after the IOCTL
1 - 100 of 169 matches
Mail list logo
