On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote:
> Ok, well for starters I think you are mistaken about kmap being able to
> fail. I'm having a hard time finding many users of that function that
> bother to check for an error when calling it.
A quick audit of the arch code shows yo
> + 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 are not related
> to changes in stolen memory usage behavior. I'd assume a successful
> bisect
Hi Daniele:
Thanks for the reply! Joonas and I did some researches in irc after
the email. We found B-spec did say the context image for render engine
consist 20 pages in context layout section. It looks like a mistake in
b-spec. Another interesting we found is the context image size for KB
== Series Details ==
Series: Adding driver-private objects to atomic state (rev2)
URL : https://patchwork.freedesktop.org/series/23308/
State : warning
== Summary ==
Series 23308v2 Adding driver-private objects to atomic state
https://patchwork.freedesktop.org/api/1.0/series/23308/revisions/2/
On Mon, 2017-04-24 at 11:53 -0400, Harry Wentland wrote:
> Patches 1-3: Reviewed-by: Harry Wentland
> Patch 4: Acked-by: Harry Wentland
>
> Harry
>
Thanks for the review.
-DK
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://list
From: "Pandiyan, Dhinakaran"
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and cle
On Tue, 2017-04-25 at 09:51 +0200, Maarten Lankhorst wrote:
> On 21-04-17 07:51, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran"
> >
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> >
On 26/04/17 02:59 AM, wrote:
> Good to know that somebody is working on this. Those problems troubled
> us as well.
Thanks Christian. It's a daunting problem and a there's a lot of work to
do before we will ever be where we need to be so any help, even an ack,
is greatly appreciated.
Logan
_
On Wed, Apr 26, 2017 at 07:56:14PM +0100, Chris Wilson wrote:
> On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> > I was thinking of exactly the same thing as this patch does, u64
> > context id as key, u32 seqnos (wrapped in a container with
> > hlist_node).
>
> #define NSYNC 32
On Friday, April 21, 2017 01:43:51 PM Hans de Goede wrote:
> Hi,
>
> On 21-04-17 13:38, Andy Shevchenko wrote:
> > On Fri, 2017-04-21 at 12:47 +0200, Hans de Goede wrote:
> >> Several Bay / Cherry Trail devices (all of which ship with Windows 10)
> >> hide
> >> the LPSS PWM controller in ACPI, typ
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, I'll work up a draft proposal and send it in a couple days. But
without a lot of cleanup such as this series it's not going t
On Wed, Apr 26, 2017 at 03:47:44PM +0200, Takashi Iwai wrote:
> On Wed, 26 Apr 2017 15:38:53 +0200,
> Ville Syrjälä wrote:
> >
> > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > > On Tue, 25 Apr 2017 22:27:19 +0200,
> > > ville.syrj...@linux.intel.com wrote:
> > > >
> > > > Fro
Em Qua, 2017-04-26 às 15:40 -0300, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni writes:
>
> >
> > Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi
> > escreveu:
> > >
> > > After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
> > > intel_fbc_can_choose()"), no_fbc_reason will be
On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> I was thinking of exactly the same thing as this patch does, u64
> context id as key, u32 seqnos (wrapped in a container with
> hlist_node).
#define NSYNC 32
struct intel_timeline_sync { /* kmalloc-256 slab */
struct hlist_n
Paulo Zanoni writes:
> Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi escreveu:
>> After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
>> intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
>> error
>> message if we don't have a plane in the new state, which should mak
Em Qua, 2017-04-26 às 21:12 +0300, Ville Syrjälä escreveu:
> On Wed, Apr 26, 2017 at 02:57:49PM -0300, Gabriel Krisman Bertazi
> wrote:
> >
> > Paulo Zanoni writes:
> >
> > >
> > > Ouch... Good catch!
> > >
> > > Can you please move the logic to the setup_fbc() function?
> > >
> > > if (gen <
On Wed, Apr 26, 2017 at 02:57:49PM -0300, Gabriel Krisman Bertazi wrote:
> Paulo Zanoni writes:
>
> > Ouch... Good catch!
> >
> > Can you please move the logic to the setup_fbc() function?
> >
> > if (gen < 7)
> > opt.fbc_check_compression = false;
> >
> > This way we avoid redoing the same c
Paulo Zanoni writes:
> Ouch... Good catch!
>
> Can you please move the logic to the setup_fbc() function?
>
> if (gen < 7)
> opt.fbc_check_compression = false;
>
> This way we avoid redoing the same check a trillion times during
> kms_frontbuffer_tracking execution.
>
> Also, I think this o
Hi David,
David Weinehall writes:
> Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
> Some of these are used by media-sdk; if these entries are missing
> the default will instead be to do everything uncached.
>
Keep in mind that MOCS entries are not for free -- Once you
This test got inadvertently disabled by commit 83884e97 (Restore
"lib: Open debugfs files for the given DRM device") when the
initialization order got changed (dbg_init before gem_init).
v2:
- The asserts on fd are useless (Petri)
- Deinit in inverse order.
Cc: Petri Latvala
Signed-off-by: O
On Wed, Apr 26, 2017 at 08:18:06PM +0300, Imre Deak wrote:
> This looks like a left-over from enabling work. The spec defines
> CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED as reserved set, so follow
> this in the programming.
>
> v2:
> - Follow the spec to set CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERV
An error from intel_get_pipe_from_connector() would mean a bug somewhere
else, but we still should check for it to prevent some other more
obscure bug later.
v2:
- Fall back to a reasonable default instead of bailing out in case of
error. (Jani)
Cc: Jani Nikula
Signed-off-by: Imre Deak
---
d
Even though an error from these functions isn't fatal we still want to
have a diagnostic message about it.
v2:
- Don't do assignments in if statements. (Jani)
Cc: Jani Nikula
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 16
1 file changed, 12 insertions(+
The current code assumes that 'enhancements' won't change in case of an
error, but this isn't guaranteed. Fix things by treating any error as a
lack of the given capability.
v2:
- Remove the now redundant init of enhancements. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
Reviewed-by: Vill
This looks like a left-over from enabling work. The spec defines
CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED as reserved set, so follow
this in the programming.
v2:
- Follow the spec to set CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED.
(Ville)
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
driver
On 26/04/17 02:57, Zhi Wang wrote:
Uh...sorry for not mentioning that before:), and stolen memory is not my
business. :(
Actually we root-caused it.
This is how we found this case:
The story is W driver directly allocated the ring buffer after the
context image, and the context image size in
On Mon, 2017-04-24 at 11:22 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/glk: Don't allow 12 bpc when htotal is too big
> URL : https://patchwork.freedesktop.org/series/23451/
> State : success
Pushed, thanks for reviewing.
Ander
>
> == Summary ==
>
> Series 23451v1 d
On Wed, Apr 26, 2017 at 04:40:13PM +0300, Imre Deak wrote:
> plane_state can't be NULL anywhere in this function, so the NULL check
> at the end is redundant, remove it.
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_plane_helper.c | 10 --
On Wed, Apr 26, 2017 at 06:23:42PM +0300, Imre Deak wrote:
> On Wed, Apr 26, 2017 at 06:08:24PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 26, 2017 at 04:40:07PM +0300, Imre Deak wrote:
> > > The assumptions of these users of drm_dp_dpcd_readb() is that the passed
> > > in output buffer won't chan
On Wed, Apr 26, 2017 at 04:40:11PM +0300, Imre Deak wrote:
> On GEN8+ (not counting CHV) the calculation can in theory result in an
> incorrect sign extension with all upper bits set. In practice this is
> unlikely to happen since it would require 4GB of stolen memory set
> aside. For consistency s
On Wed, Apr 26, 2017 at 05:53:52PM +0300, Jani Nikula wrote:
> On Wed, 26 Apr 2017, Imre Deak wrote:
> > On Wed, Apr 26, 2017 at 05:12:32PM +0300, Jani Nikula wrote:
> >> On Wed, 26 Apr 2017, Imre Deak wrote:
> >> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
> >> > e
On Wed, Apr 26, 2017 at 06:12:09PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:08PM +0300, Imre Deak wrote:
> > The current code assumes that 'enhancements' won't change in case of an
> > error, but this isn't guaranteed. Fix things by treating any error as a
> > lack of the given c
On Wed, Apr 26, 2017 at 06:08:24PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:07PM +0300, Imre Deak wrote:
> > The assumptions of these users of drm_dp_dpcd_readb() is that the passed
> > in output buffer won't change in case of error, but this isn't
> > guaranteed.
>
> Hmm. We bl
On Wed, Apr 26, 2017 at 04:40:08PM +0300, Imre Deak wrote:
> The current code assumes that 'enhancements' won't change in case of an
> error, but this isn't guaranteed. Fix things by treating any error as a
> lack of the given capability.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915
On Wed, Apr 26, 2017 at 04:40:07PM +0300, Imre Deak wrote:
> The assumptions of these users of drm_dp_dpcd_readb() is that the passed
> in output buffer won't change in case of error, but this isn't
> guaranteed.
Hmm. We blindly copy as many bytes from the rxbuf into the user
provided buffer as th
Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
Some of these are used by media-sdk; if these entries are missing
the default will instead be to do everything uncached.
This patch improves media-sdk performance with up to 60%
with the (admittedly synthetic) benchmarks we u
On Wed, Apr 26, 2017 at 05:50:06PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:12PM +0300, Imre Deak wrote:
> > This looks like a left-over from enabling work. I don't have the
> > specification to check whether we have to set
> > CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED, for now j
On Wed, Apr 26, 2017 at 03:36:19PM +0100, Tvrtko Ursulin wrote:
> But yes, sounds easy to do it from the idle worker. Just walk
> everything and prune when engine seqno has advanced past it?
Hmm. I was thinking that sounded like a great idea and then realised we
are storing context.seqno not globa
On Wed, Apr 26, 2017 at 03:36:19PM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2017 13:23, Chris Wilson wrote:
> >Too early, it's the timeline (and syncs along it) that's interesting.
> >For our contexts, we can hook into context-close, but we still have some
> >foreign dma-fence-contexts to worry a
On Wed, Apr 26, 2017 at 04:40:06PM +0300, Imre Deak wrote:
> The current code looks like a typo, the specification calls for setting
> bits 31:24 to 0x8C, while preserving bits 23:0. Fix things accordingly.
Yeah, as we checked there were a couple of things in the low 24 bits
with non-zero default
On Wed, 26 Apr 2017, Imre Deak wrote:
> On Wed, Apr 26, 2017 at 05:12:32PM +0300, Jani Nikula wrote:
>> On Wed, 26 Apr 2017, Imre Deak wrote:
>> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
>> > else, but we still should check for it to prevent some other more
>> > o
Em Qua, 2017-04-26 às 10:46 -0300, Paulo Zanoni escreveu:
> Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> >
> > This series adds Y-tiled buffer creation support into IGT libraries
> > and
> > goes on to use this capability to add support into FBC tests to use
> > Y-tiled buffers.
>
On Wed, Apr 26, 2017 at 04:40:12PM +0300, Imre Deak wrote:
> This looks like a left-over from enabling work. I don't have the
> specification to check whether we have to set
> CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED, for now just keep things
> as-is, removing the magic so that static checkers don
== Series Details ==
Series: drm: Fix/remove a few static checker error
URL : https://patchwork.freedesktop.org/series/23571/
State : success
== Summary ==
Series 23571v1 drm: Fix/remove a few static checker error
https://patchwork.freedesktop.org/api/1.0/series/23571/revisions/1/mbox/
Test g
On 26/04/2017 13:23, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
On 26/04/2017 12:18, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 fence
+ *
On Wed, Apr 26, 2017 at 05:12:32PM +0300, Jani Nikula wrote:
> On Wed, 26 Apr 2017, Imre Deak wrote:
> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
> > else, but we still should check for it to prevent some other more
> > obscure bug later.
>
> Do check for invalid p
On Wed, 26 Apr 2017, Imre Deak wrote:
> An error from intel_get_pipe_from_connector() would mean a bug somewhere
> else, but we still should check for it to prevent some other more
> obscure bug later.
Do check for invalid pipe, but please just limp on instead of bailing
out of the functions. See
Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> From: Akash Goel
>
> Signed-off-by: Akash Goel
> Signed-off-by: Praveen Paneri
> ---
> lib/igt_draw.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/lib/igt_draw.c b/lib/igt_draw.c
> i
On Wed, 26 Apr 2017 15:49:06 +0200,
Ville Syrjälä wrote:
>
> On Wed, Apr 26, 2017 at 09:19:21AM +0200, Takashi Iwai wrote:
> > On Wed, 26 Apr 2017 09:04:46 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 26 Apr 2017 03:58:57 +0200,
> > > Pierre-Louis Bossart wrote:
> > > >
> > > > On 04/25/20
Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> Allow tests to create Y-tiled bufferes using a separate
> argument to the test without increasing the number of
> subtests.
>
> Signed-off-by: Praveen Paneri
> ---
> tests/kms_frontbuffer_tracking.c | 46 +++---
On Wed, 26 Apr 2017, Imre Deak wrote:
> Even though an error from these functions isn't fatal we still want to
> have a diagnostic message about it.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
On Wed, Apr 26, 2017 at 03:47:44PM +0200, Takashi Iwai wrote:
> On Wed, 26 Apr 2017 15:38:53 +0200,
> Ville Syrjälä wrote:
> >
> > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > > On Tue, 25 Apr 2017 22:27:19 +0200,
> > > ville.syrj...@linux.intel.com wrote:
> > > >
> > > > Fro
On Wed, Apr 26, 2017 at 09:19:21AM +0200, Takashi Iwai wrote:
> On Wed, 26 Apr 2017 09:04:46 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 26 Apr 2017 03:58:57 +0200,
> > Pierre-Louis Bossart wrote:
> > >
> > > On 04/25/2017 03:27 PM, ville.syrj...@linux.intel.com wrote:
> > > > From: Ville Syrjäl
On Wed, 26 Apr 2017 15:38:53 +0200,
Ville Syrjälä wrote:
>
> On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > On Tue, 25 Apr 2017 22:27:19 +0200,
> > ville.syrj...@linux.intel.com wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > I was wondering why my VLV no longer runtime su
Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> This series adds Y-tiled buffer creation support into IGT libraries
> and
> goes on to use this capability to add support into FBC tests to use
> Y-tiled buffers.
I applied this series and the Kernel patch. If I try to run
kms_draw_crc
On 26/04/2017 14:16, Tvrtko Ursulin wrote:
On 26/04/2017 13:20, Joonas Lahtinen wrote:
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.
v2:
- Squash and get rid of hw_context_size (Chris)
Signed-off-by: Joonas Lahtinen
Cc:
This looks like a left-over from enabling work. I don't have the
specification to check whether we have to set
CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED, for now just keep things
as-is, removing the magic so that static checkers don't complain.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/d
plane_state can't be NULL anywhere in this function, so the NULL check
at the end is redundant, remove it.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_plane_helper.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gp
On GEN8+ (not counting CHV) the calculation can in theory result in an
incorrect sign extension with all upper bits set. In practice this is
unlikely to happen since it would require 4GB of stolen memory set
aside. For consistency still prevent the sign extension explicitly
everywhere.
Signed-off-
The current code assumes that 'enhancements' won't change in case of an
error, but this isn't guaranteed. Fix things by treating any error as a
lack of the given capability.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_sdvo.c | 8
1 file changed, 4 insertions(+), 4 deletions(
The assumptions of these users of drm_dp_dpcd_readb() is that the passed
in output buffer won't change in case of error, but this isn't
guaranteed. Fix this by treating any error as the lack of the given
capability.
In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the
buffer unini
The current code looks like a typo, the specification calls for setting
bits 31:24 to 0x8C, while preserving bits 23:0. Fix things accordingly.
I'm not aware of the typo causing a real problem, so the fix is only for
consistency.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i
An error from intel_get_pipe_from_connector() would mean a bug somewhere
else, but we still should check for it to prevent some other more
obscure bug later.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_panel.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
dif
Even though an error from these functions isn't fatal we still want to
have a diagnostic message about it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/d
The patchset fixes static checker errors all over the place. All of them
are minor, mostly missing error return checks, with the exception of the
first which could fix a real use case.
Imre Deak (8):
drm/i915/vlv: Fix port B PLL opamp initialization
drm/i915/dp: Check error return during DPCD
On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> On Tue, 25 Apr 2017 22:27:19 +0200,
> ville.syrj...@linux.intel.com wrote:
> >
> > From: Ville Syrjälä
> >
> > I was wondering why my VLV no longer runtime suspended, and after some
> > thinking I decided it had to be the LPE audio
On Tue, Apr 25, 2017 at 08:09:34PM -0500, Pierre-Louis Bossart wrote:
> On 4/25/17 3:27 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > There's no need to distinguish between the DP link rate and HDMI TMDS
> > clock for the purposes of the LPE audio. Both are actually the
On Tue, Apr 25, 2017 at 07:27:32PM -0500, Pierre-Louis Bossart wrote:
> On 4/25/17 3:27 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > vlv_display_irq_postinstall() enables the LPE audio interrupts
> > regardless of whether the LPE audio irq chip has masked/unmasked
> > t
On 26/04/2017 13:20, Joonas Lahtinen wrote:
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.
v2:
- Squash and get rid of hw_context_size (Chris)
Signed-off-by: Joonas Lahtinen
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chr
On Wed, Apr 26, 2017 at 12:43:18PM +, Saarinen, Jani wrote:
> Hi,
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Wednesday, April 26, 2017 3:36 PM
> > To: Saarinen, Jani ;
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-
== Series Details ==
Series: drm/i915: Sanitize engine context sizes
URL : https://patchwork.freedesktop.org/series/23567/
State : failure
== Summary ==
Series 23567v1 drm/i915: Sanitize engine context sizes
https://patchwork.freedesktop.org/api/1.0/series/23567/revisions/1/mbox/
Test core_au
Hi,
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, April 26, 2017 3:36 PM
> To: Saarinen, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2]
> drm/i915: Pre-calculat
On ke, 2017-04-26 at 10:43 +, Saarinen, Jani wrote:
> >
> > -Original Message-
> > Subject: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2]
> > drm/i915:
> > Pre-calculate engine context size
> >
> > == Series Details ==
> >
> > Series: series starting with [1/2] drm
On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
>
> > I've a patch for iio-sensor-proxy which fixes the rotation under
> > Xorg /
> > Wayland when using a desktop environment which honors iio-sensor-
> > proxy's
> > rotation detection:
> > https://github.com/hadess/iio-sensor-proxy/pull/
On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2017 12:18, Chris Wilson wrote:
> >On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
> >+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64
> >fence
> >+ * context id to the
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.
v2:
- Squash and get rid of hw_context_size (Chris)
Signed-off-by: Joonas Lahtinen
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Tvrt
On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 344f238..63623dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -418,6 +418,7 @
On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala
>
> If a connector added through drm_fb_helper_add_one_connector() has
> a crtc attached and that crtc has a rotation configured make the
> fbdev inherit the crtc's rotation.
>
> This is useful on e.g. some tablets whi
On 26/04/2017 12:18, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 fence
+ * context id to the last u32 fence seqno waited upon from that context.
+ * Unlike lib/radixtree it uses a pa
On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2017 11:38, Chris Wilson wrote:
> >On Wed, Apr 26, 2017 at 11:20:16AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 19/04/2017 10:41, Chris Wilson wrote:
> >>>Track the latest fence waited upon on each context, and only add a
== Series Details ==
Series: drm/i915: Do a quick check on whether the fence is already signaled
first
URL : https://patchwork.freedesktop.org/series/23561/
State : success
== Summary ==
Series 23561v1 drm/i915: Do a quick check on whether the fence is already
signaled first
https://patchwor
On 26/04/2017 11:48, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 11:43:03AM +0100, Tvrtko Ursulin wrote:
On 26/04/2017 11:15, Chris Wilson wrote:
Now that we try to signal the fence from inside the interrupt handler,
when we reach the signaler thread, the fence is most likely already
signaled
On Wed, Apr 26, 2017 at 11:35:33AM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2017 09:06, Chris Wilson wrote:
> >If we are enabling the breadcrumbs signaling prior to submitting the
> >request, we know that we cannot have missed the interrupt and can
> >therefore skip immediately waking the signale
On 26/04/2017 11:38, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 11:20:16AM +0100, Tvrtko Ursulin wrote:
On 19/04/2017 10:41, Chris Wilson wrote:
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence fo
On Wed, Apr 26, 2017 at 11:43:03AM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2017 11:15, Chris Wilson wrote:
> >Now that we try to signal the fence from inside the interrupt handler,
> >when we reach the signaler thread, the fence is most likely already
> >signaled. Skip manipulating the bottom-ha
> -Original Message-
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2]
> drm/i915:
> Pre-calculate engine context size
>
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Pre-calculate engine context size
> URL : https://patchwork.freedesk
On 26/04/2017 11:15, Chris Wilson wrote:
Now that we try to signal the fence from inside the interrupt handler,
when we reach the signaler thread, the fence is most likely already
signaled. Skip manipulating the bottom-half locks if this is so.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
-
On Wed, Apr 26, 2017 at 11:20:16AM +0100, Tvrtko Ursulin wrote:
>
> On 19/04/2017 10:41, Chris Wilson wrote:
> >Track the latest fence waited upon on each context, and only add a new
> >asynchronous wait if the new fence is more recent than the recorded
> >fence for that context. This requires us
On 26/04/2017 09:06, Chris Wilson wrote:
If we are enabling the breadcrumbs signaling prior to submitting the
request, we know that we cannot have missed the interrupt and can
therefore skip immediately waking the signaler to check.
This reduces a significant chunk of the __i915_gem_request_sub
On 19/04/2017 10:41, Chris Wilson wrote:
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT.
Now that we try to signal the fence from inside the interrupt handler,
when we reach the signaler thread, the fence is most likely already
signaled. Skip manipulating the bottom-half locks if this is so.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c
Uh...sorry for not mentioning that before:), and stolen memory is not my
business. :(
Actually we root-caused it.
This is how we found this case:
The story is W driver directly allocated the ring buffer after the
context image, and the context image size in W driver is 19 pages. GVT-g
will d
On Thu, 20 Apr 2017, Zhenyu Wang wrote:
> Hi,
>
> Please pull gvt next fixes for 4.12.
>
> (resend with subscribed mail address.)
Pulled to drm-intel-next-fixes, thanks.
BR,
Jani.
>
> Thanks.
>
> --
> The following changes since commit b35f34d1da4e77637869c8041a355da810f69fb6:
>
> drm/i915/
Hi Harsh:
Thanks for your help last time. You show us the size of context
image is actual 19 pages on BDW. Is it the same also on CHV?
Thanks,
Zhi.
于 04/26/17 17:52, Joonas Lahtinen 写道:
On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:
Hi Joonas:
Can you change GEN8_LR_CONTEXT_REND
On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:
> Hi Joonas:
> Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)?
> Then we don't need the hack in GVT-g. :P Actually it's 19 pages not
> 20 pages on BDW.
The exception is only made for BDW, not Gen8 overall. Has the change
been ve
== Series Details ==
Series: series starting with [1/2] drm/i915: Pre-calculate engine context size
URL : https://patchwork.freedesktop.org/series/23559/
State : warning
== Summary ==
Series 23559v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23559/revisions/1/
On Wed, Apr 26, 2017 at 12:11:53PM +0300, Joonas Lahtinen wrote:
> Pre-calculate engine context size based on engine class and device
> generation and store it in the engine instance.
>
> Signed-off-by: Joonas Lahtinen
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Cc: Daniele Cera
On Tue 25-04-17 21:03:32, Chris Wilson wrote:
> On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote:
> > Hi,
> > I have just experienced X being shut down once with 4.11-rc2 and 2 times
> > with 4.11-rc6 kernel. I do not remember seeing something like this
> > before but it is quite possi
== Series Details ==
Series: series starting with [1/3] drm/i915: Avoid the branch in computing
intel_ring_space() (rev2)
URL : https://patchwork.freedesktop.org/series/23555/
State : success
== Summary ==
Series 23555v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
Hi Joonas:
Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)? Then we
don't need the hack in GVT-g. :P Actually it's 19 pages not 20 pages on BDW.
Thanks,
Zhi.
于 04/26/17 17:11, Joonas Lahtinen 写道:
Pre-calculate engine context size based on engine class and device
generation an
1 - 100 of 117 matches
Mail list logo
