On Fri, 16 Dec 2011 12:24:49 -0600 Timur Tabi <timur@xxxxxxxxxxxxx> wrote: > Anatolij Gustschin wrote: > > > We cannot guarantee that the DIU is not in these modes. Even > > if U-Boot didn't set these modes there is still a possibility > > that such mode is configured. E.g. I've seen U-Boot binary > > standalone applications for other display controllers initializing > > the display controller. > > True, but modes 2 and 3 don't make any sense. 2 is just a color bar, > and 3 writes back to memory (which means you need to have a reserved > DMA buffer otherwise you'll crash). Have you really seen Linux boot > with the DIU in either of these modes? No, but it doesn't mean that it is not possible. > > But you are right. With this snippet, if the DIU is already > > disabled, there will be not needed mode register access. So > > the code should better look like: > > > > diu_mode = in_be32(&dr.diu_reg->diu_mode); > > if (diu_mode && diu_mode != MFB_MODE1) > > out_be32(&dr.diu_reg->diu_mode, 0); > > Ok. I'm planning on cleaning up the driver so that it does not > initialize the DIU until the .open call, and once that's done, > I should be able to remove most of the code from your patch. Will DIU splash screen functionality be preserved? Anatolij -- 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
