== Series Details ==
Series: DSC enabling remaining patches
URL : https://patchwork.freedesktop.org/series/51916/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
318c014747fe drm/dsc: Define Display Stream Compression PPS infoframe
-:31: WARNING:FILE_PATH_CHANGES: added, moved or
== Series Details ==
Series: DSC enabling remaining patches
URL : https://patchwork.freedesktop.org/series/51916/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/dsc: Define Display Stream Compression PPS infoframe
Okay!
Commit: drm/dsc: Define VES
On Thu, 01 Nov 2018, Manasi Navare wrote:
> Pushed to the dinq, thanks for the patch.
Thanks, sorry for the trouble.
BR,
Jani.
>
> Manasi
>
> On Thu, Nov 01, 2018 at 02:55:18PM -0700, Manasi Navare wrote:
>> On Thu, Nov 01, 2018 at 02:42:16PM -0700, Anusha Srivatsa wrote:
>> > This patch fixes
== Series Details ==
Series: DSC enabling remaining patches
URL : https://patchwork.freedesktop.org/series/51916/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5074 -> Patchwork_10704 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10704 absolutel
On Thu, 01 Nov 2018, Manasi Navare wrote:
> On Thu, Nov 01, 2018 at 02:06:43PM -0700, Anusha Srivatsa wrote:
>> This patch fixes the naming of the registers:
>>
>> s/PIPE_DSS_CTL/ICL_PIPE_DSS_CTL
>>
>> And also fix the hex values to lower case, to match
>> rest of the definitions.
>>
>> Manasi
On 11/1/2018 9:04 PM, Jani Nikula wrote:
From: Madhav Chauhan
For Gen11 DSI, we use similar registers like for eDP
to find if DSI encoder is connected or not to a pipe.
This patch refactors existing hsw_get_transcoder_state()
to handle this.
v2 by Jani:
- Add WARN_ON(dsi && edp) (Ville)
v2
On 11/1/2018 9:04 PM, Jani Nikula wrote:
From: Madhav Chauhan
Transcoder timings for Gen11 DSI encoder
is available at pipe level unlike in older platform
where port specific registers need to be accessed.
v2 by Jani:
- get timings for (!dsi || icl) instead of (dsi && icl).
Looks ok.
Rega
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Christian König"
Cc: David Rientjes
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
reservations have an optimized fastpath that bypasses dma_fence_wait(),
make sure we still catch all dependencies in lockdep.
To avoid lockdep complaining about recursion on the fake
dma_fence_wait lock we use the dma_fence_might_sleep annotation.
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But
This reverts the following commits:
527187d28569 ("locking/lockdep: Remove cross-release leftovers")
dba04eb76df9 ("locking/Documentation: Remove stale crossrelease_fullstack
parameter")
e966eaeeb623 ("locking/lockdep: Remove the cross-release locking checks")
Since the first two are just fixups
Only way to convince our CI to enable stuff that's new and defaulting
to off. Obviously not for merging.
Signed-off-by: Daniel Vetter
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 7e504b7fbbe1..64cd6a43b397 100644
--- a/lib/
dma-fence is a completion on steriods, which also allows hardware to
directly sync work among each another. It's supposed to be deadlock
free, so let's try to make sure that holds at least for the cpu-only
interactions and waits.
It's a bit much #ifdef, but I figured for the single case it's not
w
i915_request_wait is simply our i915-optimized version of
dma_fence_wait. They both use the exact same code. To help lockdep
discovering all the dependencies, annotate it.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
When cross release was originally merged we've hit a bunch of lockdep
splats around the 2 kthread completions. In all cases they are because
totally independent uses of kthread are mixed up by lockdep into the
same locking class, creating artificial deadlocks.
Fix this by converting kthread code i
This was originally added in 7e7844226f10 ("lockdep: allow to disable
reclaim lockup detection") but a git log -G "GFP_NOLOCKDEP" indicates
it was never used.
Cc: Andrew Morton
Cc: Vlastimil Babka
Cc: Michal Hocko
Cc: Mel Gorman
Cc: Daniel Vetter
Cc: "Levin, Alexander (Sasha Levin)"
Cc: Mike
cross-release annotations will need some serious amounts of vetting
before they can be enabled by default, or we'll just annoy everyone.
Instead split it into a separate option, which for now stays disabled
by default even if you enable overall lockdep.
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Mas
In i915 we also have i915_sw_fence, as some kind of super fence. Since
those include dma-fences (it's the main use really, aside from
chaining them for the scheduler) they're relevant for any lockdep
cycles involving dma_fence.
But i915_sw_fence is also really tough to properly annonate:
- Most of
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job d
Op 31-10-18 om 13:05 schreef Uma Shankar:
> This patch adds a colorspace property enabling
> userspace to switch to various supported colorspaces.
> This will help enable BT2020 along with other colorspaces.
>
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to in
Op 31-10-18 om 13:05 schreef Uma Shankar:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appropriate colorspace. T
Op 01-11-18 om 20:10 schreef Uma Shankar:
> Defined the plane input csc coefficient registers and macros.
> 6 registers are used to program a total of 9 coefficients,
> added macros to define each of them for all the planes
> supporting the feature on pipes. On ICL, bottom 3 planes
> have this capa
On Thu, 01 Nov 2018 16:24:36 +0100,
Ville Syrjälä wrote:
>
> On Wed, Oct 24, 2018 at 06:48:24PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Commit 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as
> > "no callbacks"") broke runtime PM with lpe audio. We can no longer
> >
== Series Details ==
Series: series starting with [01/12] locking/lockdep: restore cross-release
checks
URL : https://patchwork.freedesktop.org/series/51923/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
11e54ecf16c4 locking/lockdep: restore cross-release checks
-:8: ERROR:GIT
This seems to fix some DRM_FORMAT_RGB565 (up-)scaling IGT tests on on my
KBL.
Tested-by: Juha-Pekka Heikkila
On 29.10.2018 20:18, Ville Syrjala wrote:
From: Ville Syrjälä
To get the initial phase correct we need to account for the scale
factor as well. I forgot this initially and was mostly
== Series Details ==
Series: series starting with [01/12] locking/lockdep: restore cross-release
checks
URL : https://patchwork.freedesktop.org/series/51923/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: locking/lockdep: restore cross-release checks
== Series Details ==
Series: RFT drm/i915/execlists: Flush memory before signaling ELSQ
URL : https://patchwork.freedesktop.org/series/51796/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5077 -> Patchwork_10705 =
== Summary - SUCCESS ==
No regressions found.
External
== Series Details ==
Series: series starting with [01/12] locking/lockdep: restore cross-release
checks
URL : https://patchwork.freedesktop.org/series/51923/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5077 -> Patchwork_10706 =
== Summary - FAILURE ==
Serious unknown
v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV.
Added comment about AYUV byte ordering in Gstreamer.
v3: Removed sna_composite_op flags related change to the separate patch.
v4: Fixed review comments, done code refactoring
v5: Fixed following review comments:
- Fixed comment in shade
Hi all,
The following changes tagged drm-intel-testing-2018-11-02:
drm-intel-next-2018-11-02:
The first big pile of changes for v4.21/v5.1:
- DP Display Stream Compression preliminary work, helpers, etc. (Manasi, Anusha)
- Fix flex IO lane count programming (Manasi)
- GEM selftest updates (Chris
://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-11-02
for you to fetch changes up to 5468a543409653a94344671371ff784703fdcb26:
drm/i915: Update DRIVER_DATE to 20181102 (2018-11-02 12:04:11 +0200)
The first
On Fri, 02 Nov 2018, "Kulkarni, Vandita" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Thursday, November 1, 2018 9:04 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Chauhan, Madhav ;
>> ville.syrj...@linux.intel.com; Kulkarni, Vandita
>> ;
>> Lisovskiy, Stanislav ; Nikula
On Wed, Oct 31, 2018 at 10:34:31PM +, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Wednesday, October 31, 2018 2:08 PM
> >To: Srivatsa, Anusha
> >Cc: intel-gfx@lists.freedesktop.org; Singh, Gaurav K
> >;
> >
On Fri, Nov 02, 2018 at 10:19:10AM +0100, Maarten Lankhorst wrote:
> Op 31-10-18 om 13:05 schreef Uma Shankar:
> > This patch adds a colorspace property enabling
> > userspace to switch to various supported colorspaces.
> > This will help enable BT2020 along with other colorspaces.
> >
> > v2: Addr
== Series Details ==
Series: RFT drm/i915/execlists: Flush memory before signaling ELSQ
URL : https://patchwork.freedesktop.org/series/51796/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5077_full -> Patchwork_10705_full =
== Summary - WARNING ==
Minor unknown changes c
The GOP sometimes initializes the DSI pclk at a (slightly) different freq
then the pclk which we pick. intel_pipe_config_compare() allows for this
by doing a fuzzy compare on the port_clock.
But the pclk difference not only results in the port_clock and
base.adjusted_mode.crtc_clock clocks being a
From: Madhav Chauhan
Allocate DSI host structure for each DSI port available on gen11 and
register them with DSI fwk of DRM. Some of the DSI host operations are
also registered as part of this.
Retrieves DSI pkt (from DSI msg) to be sent over DSI link using DRM DSI
exported functions. A wrapper
From: Madhav Chauhan
This patch fills backlight, CABC and general port
info for Gen11 DSI.
Signed-off-by: Madhav Chauhan
Reviewed-by: Jani Nikula
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/icl_dsi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl
From: Madhav Chauhan
This patch read out the current hw state for DSI and
return true if encoder is active.
v2 by Jani:
- Squash connector get hw state hook here
- Squash encode get hw state fix here
v3 by Jani:
- Add encoder->get_power_domains() (Imre)
v4 by Jani:
- Make encoder->get_powe
From: Madhav Chauhan
This patch implements the functionality for getting PIPE
configuration to which DSI encoder is connected. Used during
the atomic modeset.
Signed-off-by: Madhav Chauhan
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/icl_dsi.c | 14 ++
1 file changed, 14 in
Next version of [1]. Sorry for the spam, needed to get the authorship
straight. Fixed power domains and compute config hook initialization.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/51011/
Jani Nikula (1):
drm/i915/icl: add dummy DSI GPIO element execution function
Madhav Chauha
From: Madhav Chauhan
This patch allocates memory for DSI encoder and connector
which will be used for various DSI encoder/connector operations
and attaching the same to DRM subsystem. This patch also extracts
DSI modes info from VBT and save the desired mode info to connector.
v2 by Jani:
- Dro
From: Madhav Chauhan
This patch implements compute config for Gen11 DSI encoder which is
required at the time of modeset.
v2 by Jani:
- drop the enable nop hook
- fixed_mode is always true
- HAS_GMCH_DISPLAY() is always false
v3 by Jani:
- set encoder->compute_config dropped during rebase
From: Madhav Chauhan
For Gen11 DSI, we use similar registers like for eDP
to find if DSI encoder is connected or not to a pipe.
This patch refactors existing hsw_get_transcoder_state()
to handle this.
v2 by Jani:
- Add WARN_ON(dsi && edp) (Ville)
Signed-off-by: Madhav Chauhan
Signed-off-by: J
From: Madhav Chauhan
Transcoder timings for Gen11 DSI encoder
is available at pipe level unlike in older platform
where port specific registers need to be accessed.
v2 by Jani:
- get timings for (!dsi || icl) instead of (dsi && icl).
Signed-off-by: Madhav Chauhan
Signed-off-by: Jani Nikula
-
From: Madhav Chauhan
Display Pins are the only GPIOs that need to be used by
driver for DSI panels. So driver should now have its own
implementation to toggle these pins based on GPIO info
received from VBT sequences.
Signed-off-by: Madhav Chauhan
Signed-off-by: Jani Nikula
---
drivers/gpu/dr
From: Madhav Chauhan
This patch configures DSI video mode dual link by
programming DSS_CTL registers.
v2: Use new bitfield definitions from Anusha's patch
Correct register to be programmed and use max
depth buffer value (James)
v3 by Jani:
- checkpatch fixes
Signed-off-by: Madhav Chau
From: Madhav Chauhan
This patch define missing bitfield for shortplug ctl ddi
register which will be used for ICL DSI GPIO programming.
Signed-off-by: Madhav Chauhan
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/
From: Madhav Chauhan
For ICELAKE DSI, Display Pins are the only GPIOs
that need to be programmed. So DSI driver should have
its own implementation to toggle these pins based on
GPIO info coming from VBT sequences instead of using
platform specific GPIO driver.
Signed-off-by: Madhav Chauhan
Sign
From: Madhav Chauhan
There are two panel power sequencers. Each register
has two addressable instances. This patch defines
both the instances of Panel power control register
Signed-off-by: Madhav Chauhan
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 11 +++
1 file c
From: Madhav Chauhan
Gen11 DSI doesn't use DCS commands based functionality
for enabling/disabling backlight but uses PWM based
functions similar to eDP.
Note by Jani: This should be decided by VBT, not hard coded. DCS
brightness control is still a thing.
Signed-off-by: Madhav Chauhan
Signed-o
Add dummy debug logging GPIO element execution function for ICL.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index b4
On Fri, 02 Nov 2018, Jani Nikula wrote:
> Next version of [1]. Sorry for the spam, needed to get the authorship
> straight. Fixed power domains and compute config hook initialization.
Also at icl-dsi-2018-11-02 branch of
https://cgit.freedesktop.org/~jani/drm/
BR,
Jani.
--
Jani Nikula, Intel O
On 11/2/2018 5:17 PM, Jani Nikula wrote:
Add dummy debug logging GPIO element execution function for ICL.
Signed-off-by: Jani Nikula
Its kinda split of "drm/i915/icl: Add changes to program DSI panel GPIOs"
to pave out the way further. Looks good to me.
Reviewed-by: Madhav Chauhan
Regards,
== Series Details ==
Series: drm/i915: intel_pipe_config_compare: Don't compare DSI PLL regs when
adjusting
URL : https://patchwork.freedesktop.org/series/51934/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
274e7b7c3fd1 drm/i915: intel_pipe_config_compare: Don't compare DSI P
On 11/2/2018 5:17 PM, Jani Nikula wrote:
From: Madhav Chauhan
This patch implements compute config for Gen11 DSI encoder which is
required at the time of modeset.
v2 by Jani:
- drop the enable nop hook
- fixed_mode is always true
- HAS_GMCH_DISPLAY() is always false
v3 by Jani:
- set
== Series Details ==
Series: drm/i915: intel_pipe_config_compare: Don't compare DSI PLL regs when
adjusting
URL : https://patchwork.freedesktop.org/series/51934/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5078 -> Patchwork_10707 =
== Summary - WARNING ==
Minor unknow
== Series Details ==
Series: drm/i915/icl: dsi enabling (rev5)
URL : https://patchwork.freedesktop.org/series/51011/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d23a54178f33 drm/i915/icl: Allocate DSI encoder/connector
-:137: CHECK:CAMELCASE: Avoid CamelCase:
#137: FILE: dri
== Series Details ==
Series: drm/i915/icl: dsi enabling (rev5)
URL : https://patchwork.freedesktop.org/series/51011/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/icl: Allocate DSI encoder/connector
Okay!
Commit: drm/i915/icl: Fill DSI ports
On Thu, Nov 1, 2018 at 9:10 PM Michal Hocko wrote:
> OK, so that explain my question about the test case. Even though you
> generate a lot of page cache, the amount is still too small to trigger
> pagecache mostly reclaim and anon LRUs are scanned as well.
>
> Now to the difference with the previo
== Series Details ==
Series: drm/i915/icl: dsi enabling (rev5)
URL : https://patchwork.freedesktop.org/series/51011/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5078 -> Patchwork_10708 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10708 absolu
Is there a way to check the amount of memory pinned by
i915_gem_object_get_pages_gtt(), it would be very helpful to check
system memory usage.
I think the pinned field in i915_gem_gtt has a different meaning and
doesn't indicate whether a gem object is pinned by
i915_gem_object_get_pages_gtt().
#
Quoting Vovo Yang (2018-11-02 12:48:18)
> Is there a way to check the amount of memory pinned by
> i915_gem_object_get_pages_gtt(), it would be very helpful to check
> system memory usage.
Though it includes a few non-shmemfs objects, see
debugfs/dri/0/i915_gem_objects and the "bound objects".
-Ch
On Fri, 02 Nov 2018, Madhav Chauhan wrote:
> On 11/2/2018 5:17 PM, Jani Nikula wrote:
>> Add dummy debug logging GPIO element execution function for ICL.
>>
>> Signed-off-by: Jani Nikula
> Its kinda split of "drm/i915/icl: Add changes to program DSI panel GPIOs"
> to pave out the way further. Loo
On Thu, Nov 1, 2018 at 10:30 PM Dave Hansen wrote:
> On 11/1/18 5:06 AM, Vovo Yang wrote:
> >> mlock() and ramfs usage are pretty easy to track down. /proc/$pid/smaps
> >> or /proc/meminfo can show us mlock() and good ol' 'df' and friends can
> >> show us ramfs the extent of pinned memory.
> >>
>
This essentially undoes
commit 39868bd7668bd47308b1dfd97c212757caee764f
Author: Chris Wilson
Date: Tue Oct 29 08:55:58 2013 +
drm: Compact booleans within struct drm_file
We do lockless access to these flags everywhere, and it's kinda not a
great idea to mix lockless and bitfields. As
It's lockless, and userspace might chance it underneath us. That's not
really a problem, all userspace gets is a slightly dysfunctional
lease with the current code. But this might change, and gcc might
decide to reload a few too many times, and then boom. So better safe
than sorry.
Cc: Keith Packa
I spent a bit of time scratching heads and figuring out why the igts
don't work. Probably useful to keep this work.
Cc: Keith Packard
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lease.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --g
On 11/2/2018 5:17 PM, Jani Nikula wrote:
From: Madhav Chauhan
This patch read out the current hw state for DSI and
return true if encoder is active.
v2 by Jani:
- Squash connector get hw state hook here
- Squash encode get hw state fix here
v3 by Jani:
- Add encoder->get_power_domains()
On Fri, 02 Nov 2018, Jani Nikula wrote:
> Next version of [1]. Sorry for the spam, needed to get the authorship
> straight. Fixed power domains and compute config hook initialization.
It looks like DDI intel_ddi_get_hw_state() returns true for ICL DSI as
well. I'm not sure how this wasn't a probl
== Series Details ==
Series: drm/i915/icl: dsi enabling (rev5)
URL : https://patchwork.freedesktop.org/series/51011/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5078 -> Patchwork_10709 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10709 absolu
On 11/2/18 6:22 AM, Vovo Yang wrote:
> On Thu, Nov 1, 2018 at 10:30 PM Dave Hansen wrote:
>> On 11/1/18 5:06 AM, Vovo Yang wrote:
mlock() and ramfs usage are pretty easy to track down. /proc/$pid/smaps
or /proc/meminfo can show us mlock() and good ol' 'df' and friends can
show us r
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, November 2, 2018 5:00 PM
>To: Maarten Lankhorst
>Cc: Shankar, Uma ; dri-de...@lists.freedesktop.org;
>intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; Hans Verkuil
>
>Sub
== Series Details ==
Series: drm/i915: intel_pipe_config_compare: Don't compare DSI PLL regs when
adjusting
URL : https://patchwork.freedesktop.org/series/51934/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5078_full -> Patchwork_10707_full =
== Summary - WARNING ==
Mi
== Series Details ==
Series: series starting with [1/3] drm/lease: debug output for lease creation
URL : https://patchwork.freedesktop.org/series/51944/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5d895baffdc1 drm/lease: debug output for lease creation
4f1d249eb9a4 drm/file:
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Friday, November 2, 2018 2:53 PM
>To: Shankar, Uma ; dri-de...@lists.freedesktop.org;
>intel-gfx@lists.freedesktop.org
>Cc: Syrjala, Ville ; a...@redhat.com; Lankhorst,
>Maarten
>
>Subject: Re:
On 2018-11-02 15:13, Shankar, Uma wrote:
>
>> -Original Message-
>> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> Sent: Friday, November 2, 2018 5:00 PM
>> To: Maarten Lankhorst
>> Cc: Shankar, Uma ; dri-de...@lists.freedesktop.org;
>> intel-gfx@lists.freedesktop.org; Syrja
== Series Details ==
Series: series starting with [1/3] drm/lease: debug output for lease creation
URL : https://patchwork.freedesktop.org/series/51944/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5079 -> Patchwork_10710 =
== Summary - SUCCESS ==
No regressions found.
Daniel Vetter writes:
> I spent a bit of time scratching heads and figuring out why the igts
> don't work. Probably useful to keep this work.
Acked-by: Keith Packard
> /* Do not allow sub-leases */
> - if (lessor->lessor)
> + if (lessor->lessor) {
> + DRM_DEBUG_LEASE(
Daniel Vetter writes:
> @@ -359,7 +359,8 @@ void drm_lease_revoke(struct drm_master *top)
> static int validate_lease(struct drm_device *dev,
> struct drm_file *lessor_priv,
> int object_count,
> - struct drm_mode_object **obj
On Fri, Nov 02, 2018 at 02:18:42PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >Sent: Friday, November 2, 2018 2:53 PM
> >To: Shankar, Uma ; dri-de...@lists.freedesktop.org;
> >intel-gfx@lists.freedesktop.org
Op 02-11-18 om 16:41 schreef Ville Syrjälä:
> On Fri, Nov 02, 2018 at 02:18:42PM +, Shankar, Uma wrote:
>>
>>> -Original Message-
>>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>>> Sent: Friday, November 2, 2018 2:53 PM
>>> To: Shankar, Uma ; dri-de...@lists.free
Operating with gtt-addresses has to be done with 64b variables.
CC: Kenneth Graunke
CC: Chris Wilson
Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for full-PPGTT systems.)
Fixes: c7c6e46f913b (drm/i915: Convert execbuf to use struct-of-array packing
for critical fields)
Bugzilla: https:/
Seems extending of any PIN_XXX flags to 64b has no sense for all other
cases.
But also in the code there is mismatching of 64 and 32b flags/data usage
(32b flags may be put to 64b arguments).
Seems that shouldn't cause any issues anymore, but if you think that it
should be fixed - please, let me kn
On Fri, Nov 02, 2018 at 04:44:10PM +0100, Maarten Lankhorst wrote:
> Op 02-11-18 om 16:41 schreef Ville Syrjälä:
> > On Fri, Nov 02, 2018 at 02:18:42PM +, Shankar, Uma wrote:
> >>
> >>> -Original Message-
> >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >>> Sen
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by: Chri
Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
consistently if called concurrently.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 32 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
.../gpu/dr
As the GT_IRQ power domain implies a wakeref, we can use it inplace of
our existing redundant rpm grab.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 11 ---
drivers/gpu/drm/i915/selftests/mock_
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
We observe that the ordering of writes for a CS event is not as strong
from the GPU as we would like, and that on occasions we see the
ringbuffer tail updated before the event is written into the ringbuffer,
leading us to reuse the stale data.
Through around a big hammer to try and batter ELSQ int
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
Include the total size of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr, with the result that
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
We currently require that our per-engine reset can be called from any
context, even hardirq, and in the future wish to perform the device
reset without holding struct_mutex (which requires some lockless
shenanigans that demand the lowlevel intel_reset_gpu() be able to be
used in atomic context). Te
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull th
When we first introduced the reset to sanitize the GPU on taking over
from the BIOS and before returning control to third parties (the BIOS!),
we restricted it to only systems utilizing HW contexts as we were
uncertain of how stable our reset mechanism truly was. We now have
reasonable coverage acr
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dp.c | 231 +---
1 file changed, 121 insertions(+), 110 deleti
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 119
1 - 100 of 258 matches
Mail list logo