summaryrefslogtreecommitdiff
path: root/drivers/powercap
diff options
context:
space:
mode:
authorMiaoqing Pan <miaoqing@codeaurora.org>2016-01-18 04:33:50 +0300
committerKalle Valo <kvalo@qca.qualcomm.com>2016-01-26 17:47:39 +0300
commit466b0f0208508b08eb59907fac0958d6da7fa3e2 (patch)
tree7446ea6dded033923cf2d22040e54cd52490a27b /drivers/powercap
parent1542bc37842d5d51e4aa71286a08be9615eba884 (diff)
downloadlinux-466b0f0208508b08eb59907fac0958d6da7fa3e2.tar.xz
ath9k: fix data bus error on ar9300 and ar9580
One crash issue be found on ar9300: RTC_RC reg read leads crash, leading the data bus error, due to RTC_RC reg write not happen properly. Warm Reset trigger in continuous beacon stuck for one of the customer for other chip, noticed the MAC was stuck in RTC reset. After analysis noticed DMA did not complete when RTC was put in reset. So, before resetting the MAC need to make sure there are no pending DMA transactions because this reset does not reset all parts of the chip. The 12th and 11th bit of MAC _DMA_CFG register used to do that. 12 cfg_halt_ack 0x0 0 DMA has not yet halted 1 DMA has halted 11 cfg_halt_req 0x0 0 DMA logic operates normally 1 Request DMA logic to stop so software can reset the MAC The Bit [12] of this register indicates when the halt has taken effect or not. the DMA halt IS NOT recoverable; once software sets bit [11] to request a DMA halt, software must wait for bit [12] to be set and reset the MAC. So, the same thing we implemented for ar9580 chip. Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Diffstat (limited to 'drivers/powercap')
0 files changed, 0 insertions, 0 deletions