From: Daniel Vetter <daniel@ffwll.ch>
To: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915: Use dpcd read wake for sink crc calls.
Date: Tue, 17 Nov 2015 15:08:38 +0100 [thread overview]
Message-ID: <20151117140838.GA16848@phenom.ffwll.local> (raw)
In-Reply-To: <CABVU7+txm6PGMXrwH7zb+eq-xLK_cgeNKxK8ZxYaHk=yDQdZmQ@mail.gmail.com>
On Mon, Nov 16, 2015 at 04:05:42PM +0000, Rodrigo Vivi wrote:
> Ok, so after trying it we saw that we really cannot trust on aux mutex.At
> least not on all SKL/KBL
> It worked in a KBL but failed on a SKL that I have here...
>
> So without aux mutex option we still need to get sink_crc more reliable and
> I see only 2 quick ways here:
> - This read wake
> - Return -EBUSY to force the drm retries on message size = 0.
>
> Daniel, what do you believe?
It's still a mess. My opinion is still that we should move the hacks from
read_wake into a more suitable place:
a) either into drm_dp_dpcd_read in drm_dp_helper.c
b) or into intel_dp_aux_transfer in intel_dp.c
Option a) is the right one if this is a generic sink issue (and it seems
to be the case, at least for edp panels). Option b) if it's an issue with
our hw. Either way I think intel_dp_dpcd_read_wake should die.
On a personal gut level I'd go with option a).
Cheers, Daniel
>
> Please let me know witch way and if necessary I rebase the patch and
> re-send.
>
> Thanks,
> Rodrigo.
>
>
>
>
> On Wed, Oct 21, 2015 at 8:27 PM Thulasimani, Sivakumar <
> sivakumar.thulasimani@intel.com> wrote:
>
> >
> >
> > On 10/22/2015 1:44 AM, Damien Lespiau wrote:
> > > On Thu, Oct 22, 2015 at 12:01:21AM +0530, Thulasimani, Sivakumar wrote:
> > >>
> > >> On 8/25/2015 2:50 AM, Vivi, Rodrigo wrote:
> > >>> On Mon, 2015-08-24 at 19:54 +0000, Zanoni, Paulo R wrote:
> > >>>> Em Qui, 2015-08-20 às 16:23 -0700, Rodrigo Vivi escreveu:
> > >>>>> Let's use a native read with retry as suggested per spec to
> > >>>>> fix Sink CRC on SKL when PSR is enabled.
> > >>>>>
> > >>>>> With PSR enabled panel is probably taking more time to wake
> > >>>>> and dpcd read is faling.
> > >>>> Does this commit actually fix any known problem with Sink CRC? Or is
> > >>>> it
> > >>>> just a try? It would be nice to have this clarified in the commit
> > >>>> message.
> > >>> It was just a try but that made sink crc working on my SKL when PSR is
> > >>> enabled. nothing much to add...
> > >> SKL has new register AUX_MUTEX which should be used when accessing dpcd
> > >> on edp. just searched the nightly code and could not find it. it might
> > be
> > >> the reason
> > >> for random dpcd failures reported in the other thread.
> > > We had patches for that back in December 2013 :)
> > >
> > > The feedback from Art was:
> > >
> > > The non-software aux users are PSR/SRD and GTC.
> > > Better leave out the mutex for now. Hardware is going to try do the
> > > arbitration itself. I expect you will then need to increase any
> > software
> > > timeout you may have.
> > >
> > > Do you know if anything has changed since then?
> > >
> > Not sure, it is in the bspec sequence to use AUX hence forwarded. Art
> > might be the
> > right person to contact :). it might be due to some minor DPCD access
> > issues we
> > observed in BDW when PSR was enabled.
> >
> > regards,
> > Sivakumar
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-11-17 14:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 23:12 [PATCH] drm/i915: Use dpcd read wake for sink crc calls Rodrigo Vivi
2015-08-20 23:23 ` Rodrigo Vivi
2015-08-24 4:57 ` Jindal, Sonika
2015-08-24 19:54 ` Zanoni, Paulo R
2015-08-24 21:20 ` Vivi, Rodrigo
2015-10-21 18:31 ` Thulasimani, Sivakumar
2015-10-21 19:59 ` Vivi, Rodrigo
2015-10-21 20:14 ` Damien Lespiau
2015-10-22 3:26 ` Thulasimani, Sivakumar
2015-11-16 16:05 ` Rodrigo Vivi
2015-11-17 14:08 ` Daniel Vetter [this message]
2015-11-18 18:31 ` Vivi, Rodrigo
2015-11-19 9:12 ` Daniel Vetter
2015-08-26 9:06 ` Daniel Vetter
2015-08-26 16:41 ` Vivi, Rodrigo
2015-08-27 9:21 ` Daniel Vetter
2015-08-27 10:45 ` Jani Nikula
2015-10-19 23:08 ` [PATCH] drm/i915: Retry on every aux read Rodrigo Vivi
2015-10-20 7:02 ` Jani Nikula
2015-10-20 7:39 ` Daniel Vetter
2015-10-20 15:36 ` Vivi, Rodrigo
2015-10-20 17:45 ` Vivi, Rodrigo
2015-10-20 18:31 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151117140838.GA16848@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@gmail.com \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox