* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [110419 15:17]: > Hi Tony, All, > > Due to the recent SRAM discussion I started removing SRAM support from > the new omapdss and omapfb driver, which was quite a simple task. Then I > realized that the old omapfb driver also contains SRAM code, removing of > which which wasn't such a simple task. I think I got that solved, but it > needs still cleaning up. OK > But this again reminded me of the mess of having two display drivers, > the old omapfb and the new DSS2. Many of the OMAP2 boards using the old > driver should be quite easy to port to DSS2, with the exception of N800. > DSS2 doesn't support OMAP1, so there's not much that can be done with > those boards currently. > > What is the status of OMAP1 support in general? Is having a working > framebuffer for OMAP1 boards something we need? There are people actively using omap1 boards with the framebuffer, so let's not mess with that except to remove the SRAM support. > Will there be a single kernel config containing OMAP1 and OMAP2+ support > in the future? This will cause problems, as the old and new display > drivers cannot coexist currently. This will not happen any time soon (if ever) because of issues supporting anything below ARMv6 together with ARMv6 and 7 in the same kernel binary. > I have never worked with an OMAP1 board, and I don't own one, and thus I > don't have any experience on OMAP1 display HW. This will make any work I > do on OMAP1 omapfb slightly difficult, but if there's clear need for > OMAP1 fb, then I think the only way to go is to convert the old omapfb > driver to an OMAP1 framebuffer driver. Yeh we can just make old omapfb depends on ARCH_OMAP1. > But whatever is decided on OMAP1 fb, I'll start converting the OMAP2 > drivers to the new DSS2. OK great. Tony -- 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
