ENGR00225534-2 mmc: sdhci: using cancel_work_sync instread of cancel_delayed_work

ENGR00225534-2 mmc: sdhci: using cancel_work_sync instread of cancel_delayed_work

We recently met an rarely happened sychronization issue which can cause
mmc timeout during transfer as follows:
[ OK ]onfiguring network interfaces...
[ OK ]ctivating swap...
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 sending status command, retrying
mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0xd00
mmcblk0: error -110 transferring data, sector 9981952, nr 16, cmd response 0x900, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 9981952

The root cause is that host uses cancel_delayed_work to cancel the delayed
clock disable work to avoid clock to be disabled if a new cmd
transfer request happens.
However, the work callback may already be running during the excution
of cancel_delayed_work which can not be cancelled and causes
the clock probably still to be disabled during cmd transfer,
then cmd timeout happens.

Using cancel_work_sync instead to wait for the completion of clock disable
first then we can make sure the clock can not be disabled during the cmd
transfer.

BTW, although the original code checks if in interrupt context, however,
it's still not interrupt context safe due to the unsafe platform_clk_ctrl,
so it's ok to directly use cancel_work_sync here and sdhci_enable_clk is
simply not allowed to be called in irq context.

Acked-by: Ryan QIAN <b32804@freescale.com>
Signed-off-by: Dong Aisheng <b29396@freescale.com>