There is no need to use macros as we can use generic function.
And we can save ~2000 bytes in driver footprint.
Signed-off-by: Michal Wajdeczko
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special global context to mean unordered.
Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to
have the same semanti
Rebrand the current (pointer | bits) pack/unpack utility macros as
explicit bit twiddling for PAGE_SIZE so that we can use the more
flexible underlying macros for different bits.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers
Currently we filter out repeated use of the same timeline in the low
level i915_gem_request_await_request(), after having added the
dependency on the old request. However, we can lift this to
i915_gem_request_await_dma_fence() (before the dependency is added)
using the observation that requests alo
ptr_unpack_bits() is a function-like macro, as such it is meant to be
replaceable by a function. In this case, we should be passing in the
out-param as a pointer.
Bizarrely this does affect code generation:
function old new delta
i915_gem_object_pin_map
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. However, in the
absence of a universal iden
intel_hdmi supports 3 properties, force_audio, broadcast rgb and
scaling mode. The last one is only created for eDP, so the is_eDP
in set_property is not required.
panel fitting and broadcast rgb are straightforward and only requires
changing compute_config.
force_audio is also used to force DVI
No properties are supported, so just use the helper and reject everything.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 6025839ed
Now that we solved all outstanding issues I think it's time to resubmit this.
We now have a connector atomic_check() function which is great for validating
properties, and connection_mutex that's held during the validation callbacks.
This will make all connector properties work correctly when usin
No properties are supported, so just use the helper and reject
everything.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index
MST doesn't support setting any properties, but it should still
use the atomic helper for setting properties.
Only path and tile properties are supported (read-only).
Those are immutable, and handled by drm core.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp_mst.c | 11 +---
They have been unused since 2010, after the code for
intel_tv_save/restore was removed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_tv.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i91
Some atomic properties are common between the various kinds of
connectors, for example a lot of them use panel fitting mode.
It makes sense to put a lot of it in a common place, so each
connector can use it while they're being converted.
Implement the properties required for the connectors:
- scal
intel_dp supports 3 properties, scaling mode, broadcast rgb and
force_audio. intel_digital_connector handles the plumbing,
so we only have to hook this up in compute_config and init.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 138 -
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_lvds.c | 60 +--
1 file changed, 19 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 919d84290774..6bed3827411e 100644
--- a
intel_tv has properties that are handled in the atomic core, but
needs a modeset to update the properties inside the connector.
The detect(), get_mode() and mode_valid() probe callbacks also
depend on the connector state, which made this a good connector
to convert first. It helped find all the is
Do the same as other connectors, attempt to detect hdmi audio in
the detect() callback, and only use the force_audio property as
override. Compute has_audio in pipe_config, and use that value
instead of the probed value directly.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sd
Always detect if audio is available during edid detection.
With less magic switching it's easier to convert the dp connector
properties to atomic.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 38 --
1 file changed, 16 insertions(+), 2
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dsi.c | 61 +---
1 file changed, 13 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index e787142025ac..f4517de69ab3 100644
--- a/dr
SDVO was the last connector that's still using the legacy paths
for properties, and this is with a reason!
This connector implements a lot of properties dynamically,
and some of them shared with the digital connector state,
so sdvo_connector_state subclasses intel_digital_connector_state.
set_pro
== Series Details ==
Series: drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
URL : https://patchwork.freedesktop.org/series/22758/
State : success
== Summary ==
Series 22758v1 drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
https://patchwork.freedesktop.org/api/1.0/series/22758
== Series Details ==
Series: series starting with [1/5] drm/i915: Mark up clflushes as belonging to
an unordered timeline
URL : https://patchwork.freedesktop.org/series/22759/
State : success
== Summary ==
Series 22759v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
These params are passed by value, const qualifiers are ignored any way.
While around, unify timeout_ms type from long to int.
Signed-off-by: Michal Wajdeczko
Suggested-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 20 ++--
d
On Fri, Apr 07, 2017 at 06:48:58PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> > Not getting hangs is a good sign, but lockdep doesn't like it:
> >
> > [ 460.684901] WARNING: CPU: 1 PID: 172 at kernel/workqueue.c:2418
> > check_flush_dependenc
On Mon, Apr 10, 2017 at 09:38:17AM +, Michal Wajdeczko wrote:
> These params are passed by value, const qualifiers are ignored any way.
They are not completely ignored, it just means you are not allowed to
alter the value inside the function. But it doesn't improve code
generation.
> While ar
== Series Details ==
Series: drm/i915: Convert connector properties to atomic. (rev2)
URL : https://patchwork.freedesktop.org/series/22634/
State : success
== Summary ==
Series 22634v2 drm/i915: Convert connector properties to atomic.
https://patchwork.freedesktop.org/api/1.0/series/22634/revi
On 07.04.2017 18:39, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> Thi
On Mon, Apr 10, 2017 at 08:53:25AM +, Michal Wajdeczko wrote:
> There is no need to use macros as we can use generic function.
> And we can save ~2000 bytes in driver footprint.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_dis
On Mon, Apr 10, 2017 at 11:07:07AM +0200, Maarten Lankhorst wrote:
> They have been unused since 2010, after the code for
> intel_tv_save/restore was removed.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Chris Wilson
(I pick the easy ones ;)
-Chris
--
Chris Wilson, Intel Open Source Tech
== Series Details ==
Series: drm/i915: Drop const qualifiers from params in wait_for_register()
URL : https://patchwork.freedesktop.org/series/22763/
State : success
== Summary ==
Series 22763v1 drm/i915: Drop const qualifiers from params in
wait_for_register()
https://patchwork.freedesktop.o
Am 07.04.2017 01:23 schrieb Andrea Arcangeli:
I'm also getting kernel hangs every couple of days. For me it's still
not fixed here in 4.11-rc5. It's hard to reproduce, the best
reproducer is to build lineageos 14.1 on host while running LTP in a
guest to stress the guest VM.
Initially I thought
Hi Maarteen,
Sorry for the late review, I was on vacation last week.
On Thu, 6 Apr 2017 20:55:20 +0200
Maarten Lankhorst wrote:
> mode_valid() called from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector pro
On ma, 2017-04-10 at 09:55 +0100, Chris Wilson wrote:
> 2 clflushes on two different objects are not ordered, and so do not
> belong to the same timeline (context). Either we use a unique context
> for each, or we reserve a special global context to mean unordered.
> Ideally, we would reserve 0 to
On ma, 2017-04-10 at 09:55 +0100, Chris Wilson wrote:
> Currently we filter out repeated use of the same timeline in the low
> level i915_gem_request_await_request(), after having added the
> dependency on the old request. However, we can lift this to
> i915_gem_request_await_dma_fence() (before th
There is no need to use macros as we can use generic function.
And we can save ~2000 bytes in driver footprint.
v2: drop ret var, add 10ms fallback (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Paulo Zanoni
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 15 ++-
1 file c
On Fri, Mar 31, 2017 at 12:29:23PM +0300, Joonas Lahtinen wrote:
> Did you intend to rename too, or where did the title come from?
It's accurate. We have vma->exec_list (later vma->exec_link) that is the
vma's location on the execbufer list, and we have vma->exec_entry which
is the vma's execobj.
== Series Details ==
Series: drm/i915: Use wait_for_register in lpt_reset_fdi_mphy() (rev2)
URL : https://patchwork.freedesktop.org/series/22758/
State : success
== Summary ==
Series 22758v2 drm/i915: Use wait_for_register in lpt_reset_fdi_mphy()
https://patchwork.freedesktop.org/api/1.0/serie
On pe, 2017-04-07 at 20:42 +0100, Chris Wilson wrote:
> The void *data passed to debugfs callbacks is actually the
> drm_i915_private pointer, so use it thusly and avoid the to_i915(dev)
> indirection.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Laht
Those properties are not hooked up on MST and were ignored. Best not expose
them at all.
Without this the next patch fails to start on X.org, because the DP-MST
properties could
not be read.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915
On Fri, Apr 07, 2017 at 06:55:27AM -0700, Dmitry Rogozhkin wrote:
> Starting from Gen8 HW supports dynamic power on/off slices. This
> permits to free power budget and may dramatically affect performance.
> This patch series suggests an interface (debugfs) to permit user to
> setup number of active
On Mon, Apr 10, 2017 at 01:42:46PM +0300, Joonas Lahtinen wrote:
> On pe, 2017-04-07 at 20:42 +0100, Chris Wilson wrote:
> > The void *data passed to debugfs callbacks is actually the
> > drm_i915_private pointer, so use it thusly and avoid the to_i915(dev)
> > indirection.
> >
> > Signed-off-by:
On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote:
> There is no need to use macros as we can use generic function.
> And we can save ~2000 bytes in driver footprint.
>
> v2: drop ret var, add 10ms fallback (Chris)
>
> Signed-off-by: Michal Wajdeczko
> Cc: Paulo Zanoni
> Cc: Chri
Yet again I've proven that I can't negate conditions :(
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
driver
On pe, 2017-04-07 at 06:55 -0700, Dmitry Rogozhkin wrote:
> BDW supports RCS slices powering on/off. To do that we need make_rpcs
> executed on BDW to flash slices configuration.
>
> Change-Id: Ia80b1be329bedc57cc61078ea18ecb3d2580c16a
> Signed-off-by: Dmitry Rogozhkin
> CC: Tvrtko Ursulin
> CC:
On 5 April 2017 at 15:02, Chris Wilson wrote:
> On Wed, Apr 05, 2017 at 02:50:41PM +0100, Matthew Auld wrote:
>> On 5 April 2017 at 14:41, Chris Wilson wrote:
>> > On Tue, Apr 04, 2017 at 11:11:17PM +0100, Matthew Auld wrote:
>> >> To enable 64K pages we need to set the intermediate-page-size(IPS
On Wed, 2017-03-29 at 11:53 +0200, Maarten Lankhorst wrote:
> Op 15-03-17 om 09:43 schreef Mika Kahola:
> >
> > This test case introduces concurrently running test cases for
> > atomic
> > modesetting.
> >
> > The first test or thread draws blue backround with black holes on
> > it.
> > These hol
This function should not be called with long timeouts in atomic context.
Annotate it as might_sleep if timeout is longer than 10us.
Signed-off-by: Michal Wajdeczko
Suggested-by: Chris Wilson
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 6 ++
1 file changed, 6 insertions(+)
d
== Series Details ==
Series: drm: Fix get_property logic fumble
URL : https://patchwork.freedesktop.org/series/22772/
State : success
== Summary ==
Series 22772v1 drm: Fix get_property logic fumble
https://patchwork.freedesktop.org/api/1.0/series/22772/revisions/1/mbox/
Test gem_exec_flush:
On Tue, Apr 04, 2017 at 05:57:34PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-03-29 at 16:56 +0100, Chris Wilson wrote:
> > The major scaling bottleneck in execbuffer is the processing of the
> > execobjects. Creating an auxiliary list is inefficient when compared to
> > using the execobject array
This function should not be called with long timeouts in atomic context.
Annotate it as might_sleep if timeout is longer than 10us.
v2: fix comment (Michal)
Signed-off-by: Michal Wajdeczko
Suggested-by: Chris Wilson
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 5 +
1 file ch
On Mon, Apr 10, 2017 at 12:14:02PM +, Michal Wajdeczko wrote:
> This function should not be called with long timeouts in atomic context.
> Annotate it as might_sleep if timeout is longer than 10us.
>
> Signed-off-by: Michal Wajdeczko
> Suggested-by: Chris Wilson
> Cc: Chris Wilson
> ---
Pl
== Series Details ==
Series: drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
URL : https://patchwork.freedesktop.org/series/22774/
State : warning
== Summary ==
Series 22774v1 drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
https://patchwork.freedesktop.org/api/
On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> Yet again I've proven that I can't negate conditions :(
>
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
You also get to write the igt/kms_getproperty, starting with a
memset(prop_values, 0x
Op 10-04-17 om 14:11 schreef Mika Kahola:
> On Wed, 2017-03-29 at 11:53 +0200, Maarten Lankhorst wrote:
>> Op 15-03-17 om 09:43 schreef Mika Kahola:
>>> This test case introduces concurrently running test cases for
>>> atomic
>>> modesetting.
>>>
>>> The first test or thread draws blue backround wi
Op 10-04-17 om 13:54 schreef Daniel Vetter:
> Yet again I've proven that I can't negate conditions :(
>
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Reported-by: Tvrtko Ursulin
>
There is no need to use macro as we can use generic function.
And as side effect we can lower driver footprint.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
== Series Details ==
Series: drm/i915: Don't allow overuse of __intel_wait_for_register_fw() (rev2)
URL : https://patchwork.freedesktop.org/series/22774/
State : warning
== Summary ==
Series 22774v2 drm/i915: Don't allow overuse of __intel_wait_for_register_fw()
https://patchwork.freedesktop.o
On Mon, Apr 10, 2017 at 12:30:43PM +, Michal Wajdeczko wrote:
> There is no need to use macro as we can use generic function.
> And as side effect we can lower driver footprint.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_dis
On Mon, Apr 10, 2017 at 12:41:30PM +0100, Chris Wilson wrote:
> On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote:
> > There is no need to use macros as we can use generic function.
> > And we can save ~2000 bytes in driver footprint.
> >
> > v2: drop ret var, add 10ms fallback (Chr
== Series Details ==
Series: drm/i915: Use wait_for_register in hsw_disable_lcpll()
URL : https://patchwork.freedesktop.org/series/22776/
State : success
== Summary ==
Series 22776v1 drm/i915: Use wait_for_register in hsw_disable_lcpll()
https://patchwork.freedesktop.org/api/1.0/series/22776/r
On Mon, Apr 10, 2017 at 10:00:30AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Drop const qualifiers from params in wait_for_register()
> URL : https://patchwork.freedesktop.org/series/22763/
> State : success
>
> == Summary ==
>
> Series 22763v1 drm/i915: Drop const q
On Mon, Apr 10, 2017 at 01:56:31PM +0100, Chris Wilson wrote:
> On Mon, Apr 10, 2017 at 12:41:30PM +0100, Chris Wilson wrote:
> > On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote:
> > > There is no need to use macros as we can use generic function.
> > > And we can save ~2000 bytes
On Mon, Apr 10, 2017 at 04:34:30PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 10, 2017 at 01:56:31PM +0100, Chris Wilson wrote:
> > On Mon, Apr 10, 2017 at 12:41:30PM +0100, Chris Wilson wrote:
> > > On Mon, Apr 10, 2017 at 10:22:00AM +, Michal Wajdeczko wrote:
> > > > There is no need to use ma
On Sun, 09 Apr 2017 22:32:46 +0200,
Hans de Goede wrote:
>
> Hi,
>
> On 27-02-17 23:53, Takashi Iwai wrote:
> > On Mon, 27 Feb 2017 22:27:58 +0100,
> > Rafael J. Wysocki wrote:
> >>
> >> On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote:
>
>
>
> >>> Oh, this is interesting, please let me jo
On Mon, Apr 10, 2017 at 12:17:47PM +, Michal Wajdeczko wrote:
> This function should not be called with long timeouts in atomic context.
> Annotate it as might_sleep if timeout is longer than 10us.
>
> v2: fix comment (Michal)
>
> Signed-off-by: Michal Wajdeczko
> Suggested-by: Chris Wilson
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 3fc7d86b3268 ("drm/i915: Drop const qualifiers from p
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
__in
On Mon, Apr 10, 2017 at 03:38:07PM +0100, Chris Wilson wrote:
> submit_request() is called from an atomic context, it's not allowed to
> sleep. We have to be careful in our parameters to
> intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> loop and not incur the wrath of our w
On Mon, Apr 10, 2017 at 04:43:45PM +0200, Michal Wajdeczko wrote:
> On Mon, Apr 10, 2017 at 03:38:07PM +0100, Chris Wilson wrote:
> > submit_request() is called from an atomic context, it's not allowed to
> > sleep. We have to be careful in our parameters to
> > intel_uncore_wait_for_register() to
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Monday, April 10, 2017 5:26 PM
> To: Wajdeczko, Michal
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Don't allow overuse
On Mon, Apr 10, 2017 at 03:26:06PM +0100, Chris Wilson wrote:
> On Mon, Apr 10, 2017 at 12:17:47PM +, Michal Wajdeczko wrote:
> > This function should not be called with long timeouts in atomic context.
> > Annotate it as might_sleep if timeout is longer than 10us.
> >
> > v2: fix comment (Mic
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, s
Allow the caller to use the fast_timeout_us to specify how long to wait
within the atomic section, rather than transparently switching to a
sleeping loop for larger values. This is required as some callsites may
need a long wait and are in an atomic section.
Signed-off-by: Chris Wilson
Cc: Michal
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
__in
Hi all, I am looking for the best driver to use on an old computer running RHEL
7.2. The computer is a Gateway m465-g which has an Intel 945gm Chipset with
integrated graphics - intel graphics media accelerator (GMA) 950.
What driver am I looking for, and how would I install it. The computer do
== Series Details ==
Series: drm/i915: Stop sleeping from inside gen6_bsd_submit_request() (rev2)
URL : https://patchwork.freedesktop.org/series/22783/
State : warning
== Summary ==
Series 22783v2 drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
https://patchwork.freedesktop.org/a
On Mon, Apr 10, 2017 at 02:58:34PM +, Saarinen, Jani wrote:
> HI,
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Chris Wilson
> > Sent: Monday, April 10, 2017 5:26 PM
> > To: Wajdeczko, Michal
> > Cc: intel-gfx@lists.freede
On Mon, Apr 10, 2017 at 04:02:05PM +0100, Chris Wilson wrote:
> Allow the caller to use the fast_timeout_us to specify how long to wait
> within the atomic section, rather than transparently switching to a
> sleeping loop for larger values. This is required as some callsites may
> need a long wait
On Mon, Apr 10, 2017 at 04:02:06PM +0100, Chris Wilson wrote:
> submit_request() is called from an atomic context, it's not allowed to
> sleep. We have to be careful in our parameters to
> intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> loop and not incur the wrath of our w
== Series Details ==
Series: series starting with [1/3] drm/i915: Stop second guessing the caller
for intel_uncore_wait_for_register()
URL : https://patchwork.freedesktop.org/series/22786/
State : success
== Summary ==
Series 22786v1 Series without cover letter
https://patchwork.freedesktop.o
On Mon, Apr 10, 2017 at 05:20:32PM +0200, Michal Wajdeczko wrote:
> On Mon, Apr 10, 2017 at 04:02:05PM +0100, Chris Wilson wrote:
> > Allow the caller to use the fast_timeout_us to specify how long to wait
> > within the atomic section, rather than transparently switching to a
> > sleeping loop for
On Mon, Apr 10, 2017 at 04:02:07PM +0100, Chris Wilson wrote:
> We acquire the forcewake and use I915_READ_FW instead for the atomic
> wait within intel_uncore_wait_for_register. However, this still leaves
> us vulnerable to concurrent mmio access to the register, which can cause
> system hangs on
On Mon, Apr 10, 2017 at 05:23:35PM +0200, Michal Wajdeczko wrote:
> On Mon, Apr 10, 2017 at 04:02:06PM +0100, Chris Wilson wrote:
> > submit_request() is called from an atomic context, it's not allowed to
> > sleep. We have to be careful in our parameters to
> > intel_uncore_wait_for_register() to
Hi,
On 10-04-17 15:56, Takashi Iwai wrote:
On Sun, 09 Apr 2017 22:32:46 +0200,
Hans de Goede wrote:
Hi,
On 27-02-17 23:53, Takashi Iwai wrote:
On Mon, 27 Feb 2017 22:27:58 +0100,
Rafael J. Wysocki wrote:
On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote:
Oh, this is interesting, pl
We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by
virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are
busy. As this is not obvious from the code, add a comment.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 9
Several cherrytrail devices (all of which ship with windows 10) hide the
lpss pwm controller in ACPI, typically the _STA method looks like this:
Method (_STA, 0, NotSerialized) // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}
Return (0x0F)
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, s
On Mon, Apr 10, 2017 at 04:55:31PM +0100, Chris Wilson wrote:
> We acquire the forcewake and use I915_READ_FW instead for the atomic
> wait within intel_uncore_wait_for_register. However, this still leaves
> us vulnerable to concurrent mmio access to the register, which can cause
> system hangs on
Add a bit more colour to the -misc branch explanations, and add a merge timeline
similar to the chart used in drm-intel.
Signed-off-by: Sean Paul
---
I've compiled the with this patch and hosted the output here:
https://people.freedesktop.org/~seanpaul/drm-misc.html
Makefile
== Series Details ==
Series: drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()
URL : https://patchwork.freedesktop.org/series/22790/
State : warning
== Summary ==
Series 22790v1 drm/i915/execlists: Document runtime pm for
intel_lrc_irq_handler()
https://patchwork.freedesktop
== Series Details ==
Series: series starting with [1/3] drm/i915: Stop second guessing the caller
for intel_uncore_wait_for_register() (rev2)
URL : https://patchwork.freedesktop.org/series/22786/
State : warning
== Summary ==
Series 22786v2 Series without cover letter
https://patchwork.freede
Similar to commit 8490ae207f1d ("drm/i915: Suppress busy status for
engines if wedged") we also want to report intel_engine_is_idle() as
true as well as the main intel_engines_are_idle(), as we now check that
the engines are idle when overwriting the HWS page. This is not true
whilst we are setting
On Mon, Apr 10, 2017 at 01:54:45PM +0200, Daniel Vetter wrote:
> Yet again I've proven that I can't negate conditions :(
>
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
Reviewed-by:
This refactoring helps simplify a few things here and there.
Daniele Ceraolo Spurio (2):
drm/i915: Classify the engines in class + instance
drm/i915: Use the engine class to get the context size
Oscar Mateo (3):
drm/i915: Use the same vfunc for BSD2 ring init
drm/i915: Generate the engine
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Oscar Ma
From: Daniele Ceraolo Spurio
In such a way that vcs and vcs2 are just two different instances (0 and 1)
of the same engine class (VIDEO_DECODE_CLASS).
v2: Align the instance types (Tvrtko)
v3: Don't use enums for bspec-defined stuff (Michal)
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Not really needed, but makes the next change a little bit more compact.
v2:
- Use zero-based numbering for engine names: xcs0, xcs1.. xcsN (Tvrtko, Chris)
- Make sure the mock engine name is null-terminated (Tvrtko, Chris)
v3: Because I'm stupid (Chris)
v4: Verify engine name wasn't truncate
If we needed to do something different for the init functions, we could
always look at the engine instance to make the distinction. But, in any
case, the two functions are virtually identical already (please notice
that BSD2_RING is only used from gen8 onwards).
With this, the init functions depen
== Series Details ==
Series: Classify the engines in class + instance (v5)
URL : https://patchwork.freedesktop.org/series/22808/
State : warning
== Summary ==
Series 22808v1 Classify the engines in class + instance (v5)
https://patchwork.freedesktop.org/api/1.0/series/22808/revisions/1/mbox/
1 - 100 of 103 matches
Mail list logo
