Re: [RFC] drm: Add utility function to check for edp1.4

[sonika <sonika.jindal@intel.com>]

On Monday 03 November 2014 01:58 PM, Daniel Vetter wrote:
> On Mon, Nov 3, 2014 at 9:25 AM, Thierry Reding <treding@nvidia.com> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx