[Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers

Thierry Reding thierry.reding at gmail.com
Tue Nov 19 00:37:04 PST 2013


On Mon, Nov 18, 2013 at 05:38:18PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding
> <thierry.reding at gmail.com> wrote:
> >> Note that there's already a bit of abstraction for i2c over dp aux, but
> >> imo that's at the wrong level. At least reading through i915, gma500 and
> >> radeon code there's a lot more we could share with just a dp aux helper
> >> library (which then implements useful stuff on top of it).
> >
> > I have some difficulty envisioning how the helper code can work without
> > some sort of driver-specific ops implementation. Currently the helpers
> > only use a snapshot of the DPCD to extract information. Eventually we'll
> > be bound to modify the DPCD, so some method of writing it back (or a
> > subset of it) will be needed. Otherwise the scope of the helper library
> > will be somewhat limited.
> >
> > Once we have the callbacks, the current helpers could be reworked to not
> > use a buffer, but rather an "AUX channel object" and access the
> > registers directly. If there are concerns about performance, it could
> > possibly be implemented as a sort of cache, too. That would make it fast
> > to query the status. I don't think it'll be worth the added complexity,
> > though.
> 
> Oh, my idea is that the dp aux driver callback would at the level of
> the intel_dp_aux_ch function in i915/intel_dp.c (gma500 and radeon
> have something very similar). That alone would allow us to share a
> considerable amount of code. Should have been a bit clearer, I've
> discussed this in a bit more detail with Alex many moons ago ...

Yeah, that's similar to what I had in mind. I think we may need
something slightly more complex, though. We want to support both AUX as
well as I2C over AUX transactions, so we'll probably need to add a mode
argument. I was thinking about adding a dp_aux_msg structure in order to
keep the argument list to a reasonable length.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131119/28ace7aa/attachment.pgp>


More information about the dri-devel mailing list