msm: timer: Fix racy sched_clock last_ns behavior

Previously we would use the global last_ns variable as a temporary
variable to hold the value we read from the timer. This is racy because
there is no locking and the other cpu can also manipulate last_ns,
causing sched_clock to appear to have jumped backwards. Fix this by
using a local variable for temporary data, and only accessing last_ns
once.

Change-Id: I881d5795c8a339e4baae928f1eb2493b35b88d65
Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>