On Wed, Nov 25, 2015 at 06:45:26PM +0100, Daniel Vetter wrote:
> My apologies to Chris Wilson for being dense on this topic for
> essentially for years.
>
> This patch doesn't do any big redesign of the overall reset flow, but
> instead just applies changes where it's needed to obey gem_eio. We ca
OK, here is my understanding. We do context pin/unpin during create/free
request or during submit/retire request but with condition (dirty)
check. So the context pincount will be # of requests plus 1, if it is
dirty. Dirty means that context likely is accessed by HW, while
not-dirty means HW is
If the system has no available swap pages, we cannot make forward
progress in the shrinker by releasing active pages, only by releasing
purgeable pages which are immediately reaped. Take total_swap_pages into
account when counting up available objects to be shrunk and subsequently
shrinking them. B
On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> +static bool swap_available(void)
> +{
> + return total_swap_pages || frontswap_enabled;
> +}
Of course these aren't exported symbols, so really this is just RFC
right now.
-Chris
--
Chris Wilson, Intel Open Source Technology Ce
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
dur to irq is disabled. The unnecessary locks has been cleared.
dev->struct_mutex is u
On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> If the system has no available swap pages, we cannot make forward
> progress in the shrinker by releasing active pages, only by releasing
> purgeable pages which are immediately reaped. Take total_swap_pages into
> account when countin
On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote:
> With a little complexity to handle cmds straddling page boundaries, we
> can completely avoiding having to vmap the batch and the shadow batch
> objects whilst running the command parser.
>
> On ivb i7-3720MQ:
>
> x11perf -dot before
On ke, 2015-11-25 at 19:16 +0200, marius.c.v...@intel.com wrote:
> From: Marius Vlad
>
> Signed-off-by: Marius Vlad
> ---
> tests/pm_rpm.c | 120
> +
> 1 file changed, 120 insertions(+)
>
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
>
On Wed, Nov 25, 2015 at 09:51:08PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote:
> > @@ -1097,6 +1003,7 @@ static bool check_cmd(const struct intel_engine_cs
> > *ring,
> > }
> >
> > #define LENGTH_BIAS 2
> > +#define MAX_PARTIAL 256
>
> There see
On 11/25/2015 07:02 AM, Mika Kuoppala wrote:
Nick Hoath writes:
> Use the first retired request on a new context to unpin
> the old context. This ensures that the hw context remains
> bound until it has been written back to by the GPU.
> Now that the context is pinned until later in the reque
On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote:
> On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> > If the system has no available swap pages, we cannot make forward
> > progress in the shrinker by releasing active pages, only by releasing
> > purgeable pages which
On Wed, Nov 25, 2015 at 08:31:02PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote:
> > On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> > > +static bool swap_available(void)
> > > +{
> > > + return total_swap_pages || frontswap_enabled;
>
On Wed, Nov 25, 2015 at 08:13:43PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 09:51:08PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote:
> > > @@ -1097,6 +1003,7 @@ static bool check_cmd(const struct intel_engine_cs
> > > *ring,
> > > }
> >
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.
Cave
This patch converts drm_dp_aux doc to new per-member comment layout
that 4.4 supports as suggested by Daniel.
But also:
1. to let the split text with sense this patch also
introduce a brief general AUX channel definition.
2. Remove .name and .dev duplications from the original text.
3. Improve
Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.
This has no functional change if the EAGAIN support is in
place alrea
The goal here is to offload aux retries handling from the
drivers to drm.
However there are 2 differents cases for retry:
1. Immediately retry - Hardware already took care of needed timeouts
before answering that a retry is possible.
2. Busy - Wait some time and retry.
This
The goal is to kill the intel_dp_dpcd_read_wake for all, however
Jani noticed we cannot ignore the case introduced by:
'commit f6a1906 ("drm/i915: Do a dummy DPCD read before the actual read")'
So, instead for removing this for now let's apply that dummy read
to all DP_AUX_NATIVE_READ cases. Prati
Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.
Since drm level was already taking care of retries and didn't want
to through random retries
This new version first convert the drm_dp_aux doc to new per-member comment
layout
and introduce a propper documentation for EBUSY/EAGAIN retry cases, as
requested by
Daniel.
Also accept many suggestions from Jani, but mostly removes the Nacked patch and
introduce a new one to handle the missed
EBUSY retries are already in place at drm level.
We don't need to replicate the job here.
v2: rebase on top of EAGAIN x EBUSY retries change at drm.
EBUSY retry at DRM is now handling the msleep(1).
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 22 +++---
Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.
This has no functional change if the EAGAIN support is in
place alrea
DP Specs isn't really clear about the amount of retries,
but for cases it mentions retries it also mention times that
vary from 300us to 1ms.
For many cases hardware can handled the timeouts before retry
is possible and allowed, but for many other cases it is better
to wait and give time so the au
This read wake with retries were initially added by 2 commits:
commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure")
commit 899526d9 ("drm/i915/dp: try to read receiver capabilities 3 times
when detecting")
Both mentioning section 9.1 of the 1.1a DisplayPort spec, that actua
On 11/25/2015 10:58 PM, Chris Wilson wrote:
On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote:
On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrot
> On Wed, 25 Nov 2015 11:57:13 +0100,
> Zhang, Xiong Y wrote:
> >
> > > On Wed, 25 Nov 2015 10:56:51 +0100,
> > > Zhang, Xiong Y wrote:
> > > >
> > > > Recently I always see the following error message during S4 or S3 resume
> > > with drm-intel-nightly.
> > > > [ 97.778063] PM: Syncing filesyste
On Thu, 26 Nov 2015 07:06:56 +0100,
Zhang, Xiong Y wrote:
>
> > On Wed, 25 Nov 2015 11:57:13 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > > On Wed, 25 Nov 2015 10:56:51 +0100,
> > > > Zhang, Xiong Y wrote:
> > > > >
> > > > > Recently I always see the following error message during S4 or S3
> > >
> > > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > component ops to get ELD and connection states. It was posted to
> > > alsa-devel shortly ago just as a reference, but this should work well
> > > in such a case, too. The test patches are found in test/hdmi-jack
> > > bran
101 - 128 of 128 matches
Mail list logo
