[Intel-gfx] [PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence

[Hans de Goede]

Hi,

On 25-01-18 15:10, Ville Syrjälä wrote:
> On Thu, Jan 25, 2018 at 02:37:26PM +0100, Hans de Goede wrote:
>> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
>> index = 3, one of which has been kindly provided to me by Jan Brummer,
>> where not working with the i915 driver, giving a black screen on the
>> first modeset.
>>
>> The problem with at least these Dells is that their VBT defines a MIPI
>> ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
>> reset in their INIT_OTP sequence, but the deassert must be done before
>> calling intel_dsi_device_ready(), so that is too late.
>>
>> Simply doing the INIT_OTP sequence earlier is not enough to fix this,
>> because the INIT_OTP sequence also sends various MIPI packets to the
>> panel, which can only happen after calling intel_dsi_device_ready().
>>
>> This commit fixes this by making mipi_exec_send_packet() call
>> intel_dsi_device_ready() if not done already, so that we can call the
>> INIT_OTP sequence earlier on affected devices.
>>
>> Note that this only changes the init-sequence on devices for which
>> intel_dsi_use_init_otp_as_deassert() returns true, on other devices
>> intel_dsi->device_ready will be set to true before calling any
>> MIPI sequences which may send packets, so the check added to
>> mipi_exec_send_packet() is a nop there.
> 
> I don't like how wide this kludge spreads in the code.
> 
> Could we instead just extract the deassert sequence from the
> OTP sequence? Looks like your code already assumes that everything
> up to the first DSI packet is part of the deassert sequence. So
> I imagine it should be pretty easy to split the sequence up at
> that same point?

Good idea, I've implemented this it results in slightly more code,
but is a lot cleaner indeed.

v2 with this new approach is coming up...

Regards,

Hans