[PATCH 00/18] drm/i915/dsi: Fix / cleanup dsi enable / disable sequences

[Hans de Goede <hdegoede@redhat.com>]

Hi All,

So while trying to fix my cherrytrail tablet's screen sometimes not
initializing properly (*) I started working on this series to cleanup /
(minor) refactor the dsi enable / disable code, with as goal to then
change it to match the enable / disable sequences which Ville Syrjälä
recently dug up from within the spec.

The first 2 patches I've send before, but I'm resending them since
the other patches in this series depend on them.

The 3th patch is a (small) functional change, which makes the
patches following it move less code around.

Patches 4 - 9 move some stuff around with as goal to have
intel_dsi_pre_enable() and intel_dsi_pre_disable() +
intel_dsi_post_disable() have the entire (de)init sequence in a
clearly readable one function call per step (more or less)
style, so that the ordering is obvious and we can easily match
the code to the spec

Patches 10 - 18 actually modify the code to match the spec, there are
9 patches here as I've chosen to do one tiny change per patch so that
regressions can be bisected to a commit more specific then a
"change the world" commit.

After this patch-set the dsi enable / disable code is much easier to
read (IMHO), almost fully matches the spec (with the single exception
documented) and still works (for me).

There are still some possible improvements to consider:

1) intel_dsi_pre_enable starts with enabling the pll, but
   intel_dsi_post_disable disables it half-way through the
   sequence, since then it is no longer necessary. From a
   power-management pov this is good, but it is assymetrical

2) intel_dsi_pre_enable calls intel_dsi_prepare before calling
   intel_dsi_device_ready, so intel_dsi_post_disable should
   call intel_dsi_unprepare *after* intel_dsi_clear_device_ready,
   but it calls it *before*. Because of this intel_dsi_unprepare
   itself temporarily clears device-ready and resets it in the end.
   It would be good to move intel_dsi_unprepare to *after*
   intel_dsi_clear_device_ready and drop its toggling of the
   device-ready bit, but I'm not sure if that is safe. Perhaps
   there is a specific reason why this is done this way?

3) While working on this I found the following patch which maybe
   should be merged to the mainline i915 code ?  :
   https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/0002-FOR_UPSTREAM-VPG-drm-i915-Move-port-enable-to-after-.patch

   The date on this patch is from long after the decision to
   move the intel_dsi_enable_port call to intel_dsi_pre_enable,
   so it seems to superseed that decision. Maybe we should move the
   intel_dsi_port_enable call from intel_dsi_pre_enable back
   to intel_dsi_enable[_nop] ?

Regards,

Hans


*) The root cause of which turns out to be something different, but since
I had done most of this work when I found that out, I decided to not throw
away my work and instead finish this series and post it upstream
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx