driver: Always call set_tear_on on CMD mode panels

[z3ntu]

The downstream msm-4.9 driver is unconditinally calling mdss_dsi_set_tear_on with command mode panels, replicate the same in the driver generator.

When this doesn't get enabled then the panel doesn't generate any Tearing Effect output signal which is used by MDSS.

See downstream: https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-4.9/+/refs/heads/int/13/fp3/drivers/video/fbdev/msm/mdss_dsi.c#1776
This is observed with the following panel: https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-4.9/+/refs/heads/int/13/fp3/arch/arm64/boot/dts/qcom/dsi-hx83112b-djn-1080p-cmd.dtsi (seen by the panel being stuck at 30Hz instead of 60Hz)

---

Draft: Not sure though if this solution is acceptable / good for any cmd mode panel. I'm assuming most already call this during the _on commands.

Also probably we should also call mipi_dsi_dcs_set_tear_off during _off, since downstream also calls this there (see the mdss_dsi.c file above with mdss_dsi_set_tear_off)?

[stephan-gh]

Not sure though if this solution is acceptable / good for any cmd mode panel. I'm assuming most already call this during the _on commands.

Maybe you can add a check to avoid generating this command twice?

Also probably we should also call mipi_dsi_dcs_set_tear_off during _off, since downstream also calls this there (see the mdss_dsi.c file above with mdss_dsi_set_tear_off)?

Probably yes then...

[z3ntu]

Sounds like you don't think this is a terrible idea so I'll spend some more effort on making this proper 😉

I see in the msm8953 panel drivers a bunch of panels that do have this call right now so I guess those will be my test subjects.

[MarijnS95]

Yes it is quite often missing but sometimes already part of the panel-on commands, maybe it's unconditionally sent twice and probably doesn't hurt.