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-m1stabl...
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