* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [131217 23:14]: > On 2013-12-17 17:30, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [131216 22:47]: > >> On 2013-12-16 20:41, Tony Lindgren wrote: > >>> * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [131216 06:59]: > >>>> As a temporary solution to enable DSS for selected boards when booting > >>>> with DT, a hack was added to board-generic.c in > >>>> 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable > >>>> DSS for panda & sdp boards). > >>>> > >>>> We're now adding proper DT support, so the hack can be removed. > >>> > >>> I guess this patch should be merged later on after we have the DT support > >>> working? > >> > >> I'll move this patch also to the end of the series. > >> > >> "Merged later" sounds like you mean this could be merged in a separate > >> series. I think this and the other removal can be in this series, they > >> just need to be at the end. > > > > Well yeah let's keep those separate still as at least Russell needed > > some more time with the legacy booting. The point we can drop the > > legacy booting for omap3 may still need to wait a bit, maybe even > > until v3.15 to keep things working. > > They can't be separate. Once I add DT support for a board, I have to > remove the legacy support for that board. This patch removes legacy > support for the boards that are converted in the series. Oh OK yeah makes sense. I was worried about the legacy board-*.c files.. > If I don't remove the legacy support, both DT and legacy side will be > ran, and both create the DSS devices... > > But, it's true that this patch removes the whole file, as all the boards > currently there are converted. But if new boards are added to the DSS > quirks, then I can't remove the file. So I'll change this patch to only > remove the parts for the converted boards, not the whole file. OK > But but... If I understand right, the plan is to remove all omap3 board > files for the next merge window. I'm not totally familiar with the > quirks system, but how should this be handled: > > omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices > are created via DT code. But if the display (i.e. panels) for a > particular omap3 board has not been converted to DT, we should still use > the legacy DSS initialization. But the DSS is already initialized via DT. > > I guess I can set the status for all the DSS nodes to "disabled" in > omap3.dtsi, and that should prevent DT code from creating the DSS > devices. Then, each omap3-board.dts that has been converted to DSS DT, > can override those to "enabled". > > That way the DT code should not create DSS devices by default, and the > quirks system would probably work fine. No need for DSS related quirks for the DT boot case. I was concerned about the legacy board-*.c case. Tony -- 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
