drivers: qcom: rpmh-rsc: do not read back the register write on trigger

When triggering a TCS to send its contents, reading back the trigger
value may return an incorrect value. That is because, writing the
trigger may raise an interrupt which could be handled immediately and
the trigger value could be reset in the interrupt handler.

A write_tcs_reg_sync() would read back the value that is written and try
to match it to the value written to ensure that the value is written,
but if that value is different, we are stuck in loop forever. In this
case the call stack shows -

   dump_backtrace+0x0/0x190
   show_stack+0x20/0x30
   dump_stack+0xe8/0x13c
   ipi_cpu_stop+0xc0/0xd8
   ipi_cpu_stop+0x0/0xd8
   gic_handle_irq+0x110/0x1d4
   el1_irq+0xb4/0x130
   __const_udelay+0x8c/0xb0
   write_tcs_reg_sync+0x84/0xe0
   __tcs_trigger+0xc4/0xd8
   rpmh_rsc_send_data+0x4b4/0x4c0
   rpmh_write_batch+0x1b4/0x320
   msm_bus_commit_data+0x7a4/0xa00
   update_client_paths+0x1f8/0x270
   update_request_adhoc+0x180/0x488
   msm_bus_scale_client_update_request+0x34/0x60
   _sde_power_data_bus_set_quota+0x3cc/0x570
   sde_power_data_bus_set_quota+0x234/0x298
   sde_rsc_client_trigger_vote+0x1b0/0x290
   sde_core_perf_crtc_update+0xa34/0xe88
   sde_crtc_disable+0x2b0/0x530
   msm_atomic_helper_commit_modeset_disables+0x434/0x790
   complete_commit+0x7c/0xc10
   _msm_drm_commit_work_cb+0x178/0x300

There is a drv->lock to protect against threads writing the TCS enable
register but the interrupt handler that modifies this variable does not
use the lock. Hence the race. We could solve this by locking in the
interrupt handler, however that will add more latency to the path. The
alternate is not to use the _sync variant for the TCS write and that is
because we don't care when the write actually happens. Only when the
write happens, the interrupt response could happen and therefore we are
protected from the race with the interrupt handler.

Change-Id: I54866b9b9d85fa79c8df84aecd502764b9f9158a
Signed-off-by: Lina Iyer <ilina@codeaurora.org>