[Intel-gfx] [PATCH 1/4] drm/i915: read dpcd 0 - 12 & link_status always

[Daniel Vetter]

On Thu, Sep 03, 2015 at 03:25:04PM +0300, Jani Nikula wrote:
> On Wed, 02 Sep 2015, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Tue, Sep 01, 2015 at 01:16:49PM +0300, Jani Nikula wrote:
> >> On Thu, 27 Aug 2015, Sivakumar Thulasimani <sivakumar.thulasimani at intel.com> wrote:
> >> > From: "Thulasimani,Sivakumar" <sivakumar.thulasimani at intel.com>
> >> >
> >> > Compliance requires the driver to read dpcd register 0 to 12 and
> >> > registers 0x200 to 0x205 to be read always.
> >> > Current code performs dpcd read for short pulse interrupts only
> >> > if the sink is enabled. This patch forces read for link status
> >> > and registers 0 to 12.
> >> 
> >> While this seems a bit silly from the driver perspective, I don't see it
> >> doing much harm either.
> >
> > I don't think this is silly, but fixing it like this might be - currently
> > we don't do _any_ detection of sink ports, so if you have a hub with two
> > outputs and then plug in another one and plug out the first userspace
> > won't reprobe. So probably what we should be doing is not just read the
> > dpcd, but actually look at it, figure out whether something has changed
> > and make sure we send out the uevent even if the hpd line stays unchanged
> > on short pulses to make userspace aware of the changes.
> >
> > Punting on this for now since I suspect there's a bigger story to be had
> > here ...
> 
> Well, I'll bet this would be a preliminary step for that anyway.

Then the commit message should explain that. Adding code that's not needed
just for compliance to be happy just feels very fishy. And if we have more
work to do won't really gain us much since for the full monty we probably
need to juggle a few pieces in the overall picture.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch