On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding <thierry.reding@xxxxxxxxx> 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 ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
