On Monday 03 November 2014 01:58 PM, Daniel Vetter wrote:
On Mon, Nov 3, 2014 at 9:25 AM, Thierry Reding <treding@xxxxxxxxxx> wrote:
The idea is that you'd grab the DPCD field anyway since it's needed all
over the place. We have a pile of helpers already that take exactly this
block and decode parts of it. So I think this makes sense - dp aux is fast
but not entirely free, so caching seems useful.
If we want to always cache part of the DPCD wouldn't it be better to add
the cache to struct drm_dp_aux instead of having to duplicate this in
every driver?
Right now we don't (yet) have helper functions to probe SST DP sinks,
so there's not really a good place to put it. But yeah longer-term I
hope that some shared SST sink probe functions shows up (especially to
handle all the various crazy corner-cases with VGA probing, e.g. the
apple vga dongle patch Dave sent out many aeons ago), and then putting
that cache into the dp aux struct makes sense. But before that happens
I don't think it makes a lot of sense really, since then we'd also
need to add code to invalidate that cache. Simpler if drivers just
take care of that themselves.
-Daniel
For the edp revision, I am feeling that having a function which simply
reads DP_EDP_REV,
and returns it doesn't add much value.
So, I am thinking to put that part in driver itself. Please let me know
if you feel otherwise.
-Sonika
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
