Re-add intel-gfx for real ... On Wed, Dec 11, 2013 at 3:25 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > Re-adding intel-gfx for the testing discussion. > > On Wed, Dec 11, 2013 at 3:00 PM, Shobhit Kumar <shobhit.kumar@xxxxxxxxx> wrote: >>>> btw for command mode support I'd really like to see an automated >>>> testcase. Ville has done a crc based testcase for fbc and it greatly >>>> helped in hunting down issues and corner cases. We plan to do >>>> something similar for edp psr (using the mandatory sync crcs). Is >>>> there anything like that for command mode dsi so that we can check >>>> that the manual update all works correctly? Preferably something in >>>> the sink, but if we have some way to do crcs on the source that might >>>> also be useful. >>> >>> >>> I think support for that is going to be panel specific if it exists at >>> all. Some panels support reading back the framebuffer, but reading is >>> low power mode only i.e. too slow to be useful. I've also seen a pentile >>> amoled display return the internal pentile representation of the frame, >>> not what was written to the buffer. >>> >> >> Agree. I will see what can be done. BTW command mode code is there but we >> have not got it working yet :). Another thing we are starting now is Dual >> link. I will keep testing in mind. > > If we don't have any means to check the panel's framebuffer I think we > should look into source-based CRCs if possible. If that again also > doesn't work for command mode display I guess we're left with indirect > testing by sharing the overall invalidation logic with PSR. But that > only really works if both psr and dsi command-mode use the same > sw-based invalidation logic, as soon as we use some of the hw support > (like we do for psr on hsw) the testing doesn't translate to DSI cmd > mode panels any more. > > So some good ideas for how we could better validate the cmd mode logic > would be awesome, I think atm we only have sub-par options. And ime > such fb invalidation like for fbc/psr is really tricky, if we need to > rely on manual testing then that pretty much means it'll always be > broken a bit. Or regress really often without us noticing :( > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
