are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151120/2c32fca4/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151120/1be2397d/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151120/4c723b1b/attachment-0001.html>
From: Jammy Zhou
Set the timeout to AMDGPU_TIMEOUT_INFINITE when overflow happens
Signed-off-by: Jammy Zhou
Reviewed-by: Christian König
---
amdgpu/amdgpu_cs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 4da9821..a
From: Tom St Denis
Signed-off-by: Tom St Denis
Reviewed-by: Christian König
---
amdgpu/amdgpu_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index aa594c4..6747158 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
The goal of this series is to remove many different retries we have
for aux communication and offload them to drm.
However on first attempt I was only returning EBUSY to use drm retries
but there was no waiting there. So this series also introduce a new
approach on drm level to retry on aux commun
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
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
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 +++---
drm level already takes care of the needed retries so instead of
duplicate the effort here.
If the retry is possible immediately we return EAGAIN. Otherwise,
if we have no idea what caused the error let's assume something
was busy and let drm level handle the wait and retries.
Signed-off-by: Rodr
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 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
From: Stephen Chandler Paul
HPD signals on DVI ports can be fired off before the pins required for
DDC probing actually make contact, due to the pins for HPD making
contact first. This results in a HPD signal being asserted but DDC
probing failing, resulting in hotplugging occasionally failing.
On 20 November 2015 at 07:02, Chris Zhong wrote:
> Hi Emil
>
> On 11/19/2015 10:41 PM, Emil Velikov wrote:
>>
>> On 19 November 2015 at 03:35, Chris Zhong wrote:
>>>
>>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>>> IP. This series adds support for a Synopsys DesignWar
On 11/19/2015 08:45 PM, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 08:12:24PM +0100, Mario Kleiner wrote:
>> On 11/19/2015 07:20 PM, Ville Syrjälä wrote:
>>> On Thu, Nov 19, 2015 at 06:46:28PM +0100, Mario Kleiner wrote:
Hi Alex and Michel and Ville,
it's "fix vblank stuff"
On Fri, Nov 20, 2015 at 04:24:50PM +0100, Mario Kleiner wrote:
>
>
> On 11/19/2015 08:45 PM, Ville Syrjälä wrote:
> > On Thu, Nov 19, 2015 at 08:12:24PM +0100, Mario Kleiner wrote:
> >> On 11/19/2015 07:20 PM, Ville Syrjälä wrote:
> >>> On Thu, Nov 19, 2015 at 06:46:28PM +0100, Mario Kleiner
101 - 118 of 118 matches
Mail list logo
