On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote:
> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
>> Hey Noralf, all,
>> I've been digging for a bit on the regression that this patch has
>> tripped on the HiKey board as reported here:
>> https://lkml.org/lkml/2018/8/16/81
>>
>> The
== Series Details ==
Series: drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
URL : https://patchwork.freedesktop.org/series/48601/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4700_full -> Patchwork__full =
== Summary - SUCCESS ==
No regressions found.
On Thu, Aug 23, 2018 at 07:11:16AM +0200, Maarten Lankhorst wrote:
> Op 23-08-18 om 02:51 schreef Rodrigo Vivi:
> > Static analyzer tools thinks it is possible to have a division by zero
> > here.
> >
> > I don't believe we would really reach this path without any crtc enabled,
> > but may be good
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Tuesday, August 21, 2018 3:26 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com;
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Tuesday, August 21, 2018 3:00 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com;
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Wednesday, August 22, 2018 6:36 PM
>To: Brian Starkey
>Cc: Lankhorst, Maarten ;
>dcasta...@chromium.org; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; Shankar, Uma ;
Op 23-08-18 om 02:51 schreef Rodrigo Vivi:
> Static analyzer tools thinks it is possible to have a division by zero
> here.
>
> I don't believe we would really reach this path without any crtc enabled,
> but may be good to protect against some unexpected path or behavior.
>
> Fixes: cf1f697acb04
== Series Details ==
Series: drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
URL : https://patchwork.freedesktop.org/series/48601/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4700 -> Patchwork_ =
== Summary - SUCCESS ==
No regressions found.
External
On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
> Hey Noralf, all,
> I've been digging for a bit on the regression that this patch has
> tripped on the HiKey board as reported here:
> https://lkml.org/lkml/2018/8/16/81
>
> The first issue was that the kirin driver was setting
>
== Series Details ==
Series: drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
URL : https://patchwork.freedesktop.org/series/48601/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
578f56edabd2 drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
-:38:
Check added to skip the watermark workarounds intended for Gen10 and
below platforms in Gen11.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/intel_pm.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git
== Series Details ==
Series: drm/i915: protect against division by zero.
URL : https://patchwork.freedesktop.org/series/48595/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4700_full -> Patchwork_9998_full =
== Summary - SUCCESS ==
No regressions found.
== Known
== Series Details ==
Series: drm/i915: protect against division by zero.
URL : https://patchwork.freedesktop.org/series/48595/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4700 -> Patchwork_9998 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: drm/i915: protect against division by zero.
URL : https://patchwork.freedesktop.org/series/48595/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4699 -> Patchwork_9997 =
== Summary - FAILURE ==
Serious unknown changes coming with
On Thu, Jul 19, 2018 at 09:22:04PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To reduce the confusion between a drm plane and the planes of
> framebuffers let's desiginate the latter as "color plane".
what about fb_plane instead of color?
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Thu, Jul 19, 2018 at 09:22:08PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the display w/a #1175 to a better place. That place
> being the new skl+ specific plane->check() hook. This leaves
> the skl_check_plane_surface() stuff to deal with the gtt offset
> and src coordinate
On Wed, Aug 01, 2018 at 10:34:41AM -0700, Paulo Zanoni wrote:
> Unlike the other ports, TC ports are not available to use as soon as
> we get a hotplug. The TC PHYs can be shared between multiple
> controllers: display, USB, etc. As a result, handshaking through FIA
> is required around connect
Static analyzer tools thinks it is possible to have a division by zero
here.
I don't believe we would really reach this path without any crtc enabled,
but may be good to protect against some unexpected path or behavior.
Fixes: cf1f697acb04 ("drm/i915/skl: distribute DDB based on panel
On Wed, 2018-08-22 at 11:32 -0700, Dhinakaran Pandiyan wrote:
>
> On Wed, 2018-08-22 at 10:23 -0700, Azhar Shaikh wrote:
> > Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file
> > i915_edp_psr_status.
> >
>
> Reviewed-by: Dhinakaran Pandiyan
>
> > Suggested-by: Dhinakaran Pandiyan
On Fri, 2018-07-20 at 14:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's store the final plane stride in the plane state. This avoids
> having to pick betwen the normal vs. rotated stride during hardware
s/betwen/between
> programming. And once we get GTT remapping the plane
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs (rev4)
URL : https://patchwork.freedesktop.org/series/47902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9996_full =
== Summary - SUCCESS ==
No regressions found.
On Thu, 2018-07-19 at 21:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make the main/aux surface stuff a bit more generic by using an array
> of structures. This will allow us to deal with both the main and aux
> surfaces with common code.
Nitpick: consider having a enum {
On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
> Add plane alpha blending support with the different blend modes.
> This has been tested on a icl to show the correct results,
> on earlier platforms small rounding errors cause issues. But this
> already happens case with fully
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs (rev4)
URL : https://patchwork.freedesktop.org/series/47902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9996 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On Thu, 2018-07-19 at 21:22 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's assume that the primary plane for pipe A has the highest max
> stride of all planes, and we'll use that as the global limit when
> creating a new framebuffer.
Well it was already assuming that but using the
On Wed, 2018-08-22 at 22:03 +, Souza, Jose wrote:
> On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Each plane may have different stride limitations. Let's add a new
> > plane function to retutn the maximum stride for each plane. There's
> > going to
On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Each plane may have different stride limitations. Let's add a new
> plane function to retutn the maximum stride for each plane. There's
> going to be some use for this outside the .atomic_check() stuff hence
> the
On Thu, 2018-07-19 at 21:21 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename some of the tile_offset() functions to aligned_offset() since
> they operate on both linear and tiled functions. And we'll include
> _plane_ in the name of all the variants that take a plane state.
> Should
== Series Details ==
Series: Possible use_mm() mis-uses
URL : https://patchwork.freedesktop.org/series/48584/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9995_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9995_full
== Series Details ==
Series: series starting with [v2] drm/i915: Add a small wrapper to check for
CCS modifiers. (rev2)
URL : https://patchwork.freedesktop.org/series/48524/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4697_full -> Patchwork_9994_full =
== Summary -
== Series Details ==
Series: Possible use_mm() mis-uses
URL : https://patchwork.freedesktop.org/series/48584/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9995 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote:
>
> You're right, but that's a bit fragile and convoluted. I'll fix KFD to
> handle this more robustly. See the attached (untested) patch.
Yes, this patch that makes the whole "has to use current mm" or uses
"get_task_mm()" looks good from a
== Series Details ==
Series: Possible use_mm() mis-uses
URL : https://patchwork.freedesktop.org/series/48584/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8fa6553a2650 Possible use_mm() mis-uses
-:114: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
On Wed, Aug 22, 2018 at 10:58 PM Linus Torvalds
wrote:
>
> On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote:
> >
> > Having said that, I think we *are* protected by the mmu_notifier
> > release because if the process suddenly dies, we will gracefully clean
> > the process's data in our driver
== Series Details ==
Series: series starting with [v2] drm/i915: Add a small wrapper to check for
CCS modifiers. (rev2)
URL : https://patchwork.freedesktop.org/series/48524/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4697 -> Patchwork_9994 =
== Summary - SUCCESS ==
On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote:
>
> Having said that, I think we *are* protected by the mmu_notifier
> release because if the process suddenly dies, we will gracefully clean
> the process's data in our driver and on the H/W before returning to
> the mm core code. And before we
On 2018-08-22 02:13 PM, Christian König wrote:
> Adding Felix because the KFD part of amdgpu is actually his
> responsibility.
>
> If I'm not completely mistaken the release callback of the
> mmu_notifier should take care of that for amdgpu.
You're right, but that's a bit fragile and convoluted.
Hi Dave,
A couple fixes for you that didn't quite make your -rc1 pull last week. I'm
sending this since Gustavo is busy organizing linuxdev-br.
drm-misc-next-fixes-2018-08-22:
- Add an unprepare delay to the tv123wam panel (Sean)
- Update seanpaul's email in MAINTAINERS (Sean)
Cc:
Code looks cleaner with modifiers hidden inside this wrapper.
v2: Remove const qualifier (Ville)
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 21 +++--
drivers/gpu/drm/i915/intel_display.h | 1 +
On Wed, Aug 22, 2018 at 7:44 PM Linus Torvalds
wrote:
> One of the complex ones is the amdgpu driver. It does a
> "use_mm(mmptr)" deep deep in the guts of a macro that ends up being
> used in fa few places, and it's very hard to tell if it's right.
>
> It looks almost certainly buggy (there is no
Hi Linus:
Thanks for letting us know that. We would fix this ASAP. The kvmgt.c
module is a part of GVT-g code. It's our fault that we didn't find this
mis-uses, not i915 or KVM guys. Wish they would feel better after seeing
this message.
Thanks,
Zhi.
On 08/23/18 00:44, Linus Torvalds
On Wed, Aug 22, 2018 at 11:33 AM Linus Torvalds
wrote:
>
> On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote:
> >
> > Yes, KVM is correct but the i915 bits are at least fishy. It's probably
> > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init
> > and kvmgt_guest_exit,
On Wed, Aug 22, 2018 at 11:09:21AM -0500, Jason Ekstrand wrote:
> Fine with me.
>
> Reviewed-by: Jason Ekstrand
Thanks for the review, applied to drm-misc-next.
-Daniel
>
> On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
> wrote:
>
> > This is used for handling future fences. Currently no
On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote:
>
> Yes, KVM is correct but the i915 bits are at least fishy. It's probably
> as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init
> and kvmgt_guest_exit, or maybe mmget_not_zero.
Definitely mmget_not_zero(). If it was
On Wed, 2018-08-22 at 10:23 -0700, Azhar Shaikh wrote:
> Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file
> i915_edp_psr_status.
>
Reviewed-by: Dhinakaran Pandiyan
> Suggested-by: Dhinakaran Pandiyan
> Signed-off-by: Azhar Shaikh
> ---
> Changes in v4:
> - Fix the rebase error
On 22/08/2018 18:44, Linus Torvalds wrote:
> An example of something that *isn't* right, is the i915 kvm interface,
> which does
>
> use_mm(kvm->mm);
>
> on an mm that was initialized in virt/kvm/kvm_main.c using
>
> mmgrab(current->mm);
> kvm->mm = current->mm;
>
>
Adding Felix because the KFD part of amdgpu is actually his responsibility.
If I'm not completely mistaken the release callback of the mmu_notifier
should take care of that for amdgpu.
Regards,
Christian.
Am 22.08.2018 um 18:44 schrieb Linus Torvalds:
Guys and gals,
this is a *very*
== Series Details ==
Series: drm/i915/icl: Fix context slice count configuration
URL : https://patchwork.freedesktop.org/series/48570/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696_full -> Patchwork_9992_full =
== Summary - WARNING ==
Minor unknown changes coming
On Wed, 2018-08-22 at 12:48 +0300, Ville Syrjälä wrote:
> On Tue, Aug 21, 2018 at 06:50:52PM -0700, Dhinakaran Pandiyan wrote:
> > Code looks cleaner with modifiers hidden inside this wrapper.
> >
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 21
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file
i915_edp_psr_status.
Suggested-by: Dhinakaran Pandiyan
Signed-off-by: Azhar Shaikh
---
Changes in v4:
- Fix the rebase error in v3 of adding typecast to bool
- in i915_edp_psr_status(), which is not needed
Changes in v3:
- rebased
On 22/08/2018 18:07, Tvrtko Ursulin wrote:
On 22/08/2018 17:33, Lionel Landwerlin wrote:
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in
Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
On 22/08/2018 17:33, Lionel Landwerlin wrote:
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times
On Wed, Aug 22, 2018 at 05:37:22PM +0100, Daniel Stone wrote:
> Hi Rodrigo,
>
> On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote:
> > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
> > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
> > > > - Sticking to fdo bugzilla and
== Series Details ==
Series: drm/i915/icl: Fix context slice count configuration
URL : https://patchwork.freedesktop.org/series/48570/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696 -> Patchwork_9992 =
== Summary - SUCCESS ==
No regressions found.
External URL:
On Wed, Aug 22, 2018 at 12:37:05PM +0200, Maarten Lankhorst wrote:
> Op 21-08-18 om 10:38 schreef Mahesh Kumar:
> > This patch implements a callback function which will be called before
> > crc read. In this function driver can implement any preparation work
> > required for successfully reading
Guys and gals,
this is a *very* random list of people on the recipients list, but we
had a subtle TLB shootdown issue in the VM, and that brought up some
issues when people then went through the code more carefully.
I think we have a handle on the TLB shootdown bug itself. But when
people were
== Series Details ==
Series: drm/i915/icl: Fix context slice count configuration
URL : https://patchwork.freedesktop.org/series/48570/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5cf33a6a09d9 drm/i915/icl: Fix context slice count configuration
-:10: WARNING:TYPO_SPELLING:
Hi Rodrigo,
On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote:
> On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
> > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
> > > - Sticking to fdo bugzilla and disabling gitlab issues for at least
> > > drm-intel for the time being.
Hi,
On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula
> wrote:
> > Just a couple of concerns from drm/i915 perspective for starters:
> >
> > - Patchwork integration. I think we'll want to keep patchwork for at
> > least intel-gfx etc. for the
On 22/08/2018 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield
Hi,
On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote:
> On 22 August 2018 at 12:44, Daniel Vetter wrote:
> > I think it's time to brainstorm a bit about the gitlab migration. Basic
> > reasons:
> >
> > - fd.o admins want to deprecate shell accounts and hand-rolled
> > infrastructure, because
From: Tvrtko Ursulin
Bitfield width for configuring the active slice count has grown in Gen11
so we need to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should).
== Series Details ==
Series: drm/i915: Fix subslice configuration on Gen9LP
URL : https://patchwork.freedesktop.org/series/48566/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696_full -> Patchwork_9991_full =
== Summary - WARNING ==
Minor unknown changes coming with
Fine with me.
Reviewed-by: Jason Ekstrand
On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
wrote:
> This is used for handling future fences. Currently no driver use
> these, and I think given the new timeline fence proposed by KHR it
> would be better to have a more abstract interface for future
On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
> On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
>
> > - Sticking to fdo bugzilla and disabling gitlab issues for at least
> > drm-intel for the time being. Doing that migration in the same go is a
> > bit much I think.
On 22/08/2018 16:27, Tvrtko Ursulin wrote:
On 22/08/2018 16:22, Lionel Landwerlin wrote:
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when
On Wed, Aug 22, 2018 at 06:32:33PM +0530, Kumar, Mahesh wrote:
> Hi,
>
>
> On 8/22/2018 12:26 AM, Rodrigo Vivi wrote:
> > On Tue, Aug 21, 2018 at 09:30:21PM +0530, Kumar, Mahesh wrote:
> > > Hi,
> > >
> > >
> > > On 8/21/2018 8:27 PM, Kumar, Mahesh wrote:
> > > > Hi,
> > > >
> > > >
> > > >
On 22/08/2018 16:22, Lionel Landwerlin wrote:
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating
On 22/08/2018 16:17, Tvrtko Ursulin wrote:
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it
On 22/08/2018 16:08, Lionel Landwerlin wrote:
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count
power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format
On 22/08/2018 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3
Hi Dan,
On 22 August 2018 at 12:44, Daniel Vetter wrote:
> Hi all,
>
> I think it's time to brainstorm a bit about the gitlab migration. Basic
> reasons:
>
> - fd.o admins want to deprecate shell accounts and hand-rolled
> infrastructure, because it's a pain to keep secure
>
> - gitlab will
== Series Details ==
Series: drm/i915: Fix subslice configuration on Gen9LP
URL : https://patchwork.freedesktop.org/series/48566/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4696 -> Patchwork_9991 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: drm/i915/gtt: Setup guards in scratch page (rev2)
URL : https://patchwork.freedesktop.org/series/48565/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9990_full =
== Summary - WARNING ==
Minor unknown changes coming
On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula
wrote:
> On Wed, 22 Aug 2018, Daniel Vetter wrote:
>> Hi all,
>>
>> I think it's time to brainstorm a bit about the gitlab migration. Basic
>> reasons:
>>
>> - fd.o admins want to deprecate shell accounts and hand-rolled
>> infrastructure, because
On 22/08/18 15:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3
From: Tvrtko Ursulin
According to the documentation, when programming the subslice count power-
gating configuration register, the value to be written into it on Gen9LP
should actually in the format of:
1 slice = 0x001
2 slices = 0x010
3 slices = 0x100
And not the popcount of the
On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
> - Sticking to fdo bugzilla and disabling gitlab issues for at least
> drm-intel for the time being. Doing that migration in the same go is a
> bit much I think. Reassignment across bugzilla and gitlab will be an
> issue.
Can you
== Series Details ==
Series: drm/i915/gtt: Setup guards in scratch page (rev2)
URL : https://patchwork.freedesktop.org/series/48565/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9990 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Quoting Mika Kuoppala (2018-08-22 14:27:14)
> There have been cases where GPU engine has managed to run past
> execbuffer ending due to reasons unknown at that time:
> coherency problems, page table setup errors, hw glitches.
You are trading an obvious error for a subtle one; if userspace got its
== Series Details ==
Series: drm/i915/gtt: Setup guards in scratch page (rev2)
URL : https://patchwork.freedesktop.org/series/48565/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/gtt: Setup guards in scratch page
+drivers/gpu/drm/i915/i915_gem_gtt.c:1017:9:
There have been cases where GPU engine has managed to run past
execbuffer ending due to reasons unknown at that time:
coherency problems, page table setup errors, hw glitches.
Let's try to contain a wild engine head by putting batch
buffer end commands into start and end of scratch page.
v2: add
There have been cases where GPU engine has managed to run past
execbuffer ending due to reasons unknown at that time:
coherency problems, page table setup errors, hw glitches.
Let's try to contain a wild engine head by putting batch
buffer end commands into start and end of scratch page.
Leave
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-21 08:58:26)
>> Chris Wilson writes:
>>
>> > Since we no longer maintain our read position in the CSB pointers
>> > register, it always returns 0 and not where we last read up to. As a
>> > result the CSB probing in the state dumper starts
On Wed, 22 Aug 2018, Daniel Vetter wrote:
> Hi all,
>
> I think it's time to brainstorm a bit about the gitlab migration. Basic
> reasons:
>
> - fd.o admins want to deprecate shell accounts and hand-rolled
> infrastructure, because it's a pain to keep secure
>
> - gitlab will allow us to add
On Wed, Aug 22, 2018 at 12:11:42PM +0100, Brian Starkey wrote:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> >On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> >> fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> >> > Add a blob property for
Quoting Tvrtko Ursulin (2018-08-22 15:49:52)
>
> On 21/08/2018 13:06, Joonas Lahtinen wrote:
> > Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
> >> Joonas, sorry for interfering; could you please explain more regarding the
> >> options for tracing scheduling events better than tracepoints?
>
On Wed, Aug 22, 2018 at 01:44:56PM +0200, Daniel Vetter wrote:
> Hi all,
>
> I think it's time to brainstorm a bit about the gitlab migration. Basic
> reasons:
>
> - fd.o admins want to deprecate shell accounts and hand-rolled
> infrastructure, because it's a pain to keep secure
>
> - gitlab
On 22/08/2018 13:49, Tvrtko Ursulin wrote:
On 21/08/2018 13:06, Joonas Lahtinen wrote:
Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
Joonas, sorry for interfering; could you please explain more
regarding the
options for tracing scheduling events better than tracepoints?
After scheduling
Hi,
On 8/22/2018 12:26 AM, Rodrigo Vivi wrote:
On Tue, Aug 21, 2018 at 09:30:21PM +0530, Kumar, Mahesh wrote:
Hi,
On 8/21/2018 8:27 PM, Kumar, Mahesh wrote:
Hi,
On 8/17/2018 11:50 PM, Rodrigo Vivi wrote:
On Thu, Jul 26, 2018 at 07:44:09PM +0530, Mahesh Kumar wrote:
IPC may cause
On Wed, Aug 22, 2018 at 10:54:05AM +0200, Daniel Vetter wrote:
> For buffer sharing, use dma-buf instead. We can't set smem_start to 0
> unconditionally since that's used by the fbdev mmap default
> implementation. And we have plenty of userspace which would like to
> keep that working.
>
> This
ons 2018-08-22 klockan 12:11 +0100 skrev Brian Starkey:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> > > fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> > > > Add a blob property for
On 21/08/2018 13:06, Joonas Lahtinen wrote:
Quoting Kukanova, Svetlana (2018-08-13 16:44:49)
Joonas, sorry for interfering; could you please explain more regarding the
options for tracing scheduling events better than tracepoints?
After scheduling moves to GuC tools will have to switch to
== Series Details ==
Series: drm/i915: Simplify condition to keep DMC active during S0ix
URL : https://patchwork.freedesktop.org/series/48556/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9989_full =
== Summary - SUCCESS ==
No regressions found.
On Fri, Aug 17, 2018 at 09:24:05AM +0100, Chris Wilson wrote:
> The optimisation inherent in commit 6a2c4232ece1 ("drm/i915: Make the
> physical object coherent with GTT") relies on that once we allocated a
> cursor we would have coherent, zero overhead access to the scanout plane
> holding the
On Wed, Aug 22, 2018 at 02:26:02PM +0300, Imre Deak wrote:
> For S0ix we want to deinit power domains (and so deactivate the DMC
> firmware) exactly when the platform supports the DC9 state. To reach
> S0ix we need DC9 on these platforms (for which the DMC FW needs to be
> deactivated) while to
== Series Details ==
Series: drm/i915: Simplify condition to keep DMC active during S0ix
URL : https://patchwork.freedesktop.org/series/48556/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695 -> Patchwork_9989 =
== Summary - SUCCESS ==
No regressions found.
Hi all,
I think it's time to brainstorm a bit about the gitlab migration. Basic reasons:
- fd.o admins want to deprecate shell accounts and hand-rolled
infrastructure, because it's a pain to keep secure
- gitlab will allow us to add committers on our own, greatly
simplifying that process (and
For S0ix we want to deinit power domains (and so deactivate the DMC
firmware) exactly when the platform supports the DC9 state. To reach
S0ix we need DC9 on these platforms (for which the DMC FW needs to be
deactivated) while to reach S0ix on the rest of the DMC platforms we
need DC6 (which needs
== Series Details ==
Series: drm/syncobj: Drop add/remove_callback from driver interface
URL : https://patchwork.freedesktop.org/series/48542/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4695_full -> Patchwork_9988_full =
== Summary - WARNING ==
Minor unknown changes
1 - 100 of 122 matches
Mail list logo
