> From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > Sent: Wednesday, January 07, 2009 2:26 AM > > It just happens to be the IRQ path has a very slow dissertation path when > you take into account timing domains that it shows up. > > > > Shrinking the race window with SO then using a read back to get the last one > or two is most conservative and safe. Probably 97% for IO accesses are ok on > OMAP as device, but that is probably 99.9% with SO. In our testing we may be > able to make that 97 a 99. Still I'd rather not risk the 1% for production. > > Sure you can patch the SO back if you want to. However, it's a more > generic problem, and Russell has stated that he does not want to > merge it. Yes Russell doesn't like it. However, I didn't see any viable alternate solution offered. If ARM or any hardware vendor does something badly in hardware punishing the current generation in hopes of changing the next is not so good. Especially if some work around exists. In the end vendors will carry some out of tree patch. All that will happen is a new person to the lists will be put off. > At least the interrupt problems are easy to debug now, so I'd say > those are easy one liners to fix. The other places where we need > to flush posted writes may be harder to track down, but should be > possible to spot by reading the code of the problem driver. The code you added to spotlight issues and the fixes it generates should stay in place. SO does not solve the whole problem it just shrinks it. I don't like the idea of exposing ourselves to some known hardware limitation just because we don't like the fix. Already a lot of hours have been wasted on this issue. Why drag it out further. I've complained bitterly already and those nits have been acknowledged by hardware people in TI and ARM. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
