[Intel-gfx] [PATCH v2 0/7] drm/i915: Baytrail MIPI DSI support Updated

[Daniel Vetter]

Re-add intel-gfx for real ...

On Wed, Dec 11, 2013 at 3:25 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> Re-adding intel-gfx for the testing discussion.
>
> On Wed, Dec 11, 2013 at 3:00 PM, Shobhit Kumar <shobhit.kumar at intel.com> 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