On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding thierry.reding@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 ... -Daniel