On Sat, 24 Apr 2010 12:47:34 +0200 Florian Tobias Schandinat <FlorianSchandinat@xxxxxx> wrote: > I was able to narrow this issue down to the fourth bus. So with > if (i == 4) > continue; > in the bus creation loop I'm able to get a working framebuffer which > does not have the issues mentioned. Any ideas what should be done now? That is useful information indeed, thanks. This patch creates an i2c bus on every port which could conceivably have one. That's rather different from the original code, which created a single bus (in the kernel) then swapped it between ports 31 and 2c in weird ways. In particular, it takes over ports which, conceivably, somebody else could be using for GPIO. So, perhaps, there is some contention going on there. If my hypothesis is correct, this problem will go away with the application of the second series, which doesn't create i2c buses on ports used for GPIO. But the problem should be fixed here so we don't have things broken in the middle. Harald, does this reasoning make sense to you? If so, what I should do is bring forward just enough of the via-core code to be able to configure which ports actually get i2c buses created on them. Easily done. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
