On Fri, 2010-12-17 at 21:16 -0800, Stephen Boyd wrote: > The inline assembly differences for v6 vs. v7 in the hvc_dcc > driver are purely optimizations. On a v7 processor, an mrc with > the pc sets the condition codes to the 28-31 bits of the register > being read. It just so happens that the TX/RX full bits the DCC > driver is testing for are high enough in the register to be put > into the condition codes. On a v6 processor, this "feature" isn't > implemented and thus we have to do the usual read, mask, test > operations to check for TX/RX full. > > Since we already test the RX/TX full bits before calling > __dcc_getchar() and __dcc_putchar() we don't actually need to do > anything special for v7 over v6. The only difference is in > hvc_dcc_get_chars(). We would test RX full, poll RX full, and > then read a character from the buffer, whereas now we will test > RX full, read a character from the buffer, and then test RX full > again for the second iteration of the loop. It doesn't seem > possible for the buffer to go from full to empty between testing > the RX full and reading a character. Therefore, replace the v7 > versions with the v6 versions and everything works the same. > > While we're here, cleanup the for loops a bit and mark the inline > assembly as volatile. Not marking it volatile causes GCC to cache > the results of the status and RX buffer registers causing > lockups. I would expect to see three patches. One that adds volatile, which appears to be a good fix. Another patch that changes the assembly lines, and another that does the clean up. The last two are more controversial ones. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
