On Tue, Oct 8, 2013 at 5:19 AM, Jean-Francois Moine <moinejf@xxxxxxx> wrote: > On Mon, 7 Oct 2013 10:59:39 -0400 > Rob Clark <robdclark@xxxxxxxxx> wrote: > >> Jean-François, just as an aside, I really don't think code that can be >> shared, like tda998x, should encode a DT requirement.. there are >> plenty of platforms that don't use DT (arm isn't everything, and last >> I heard aarch64 was going to be ACPI). >> >> Beyond that, it is a driver decision whether or not to support only-DT >> or DT + other.. and as long as there is a common board which can use >> the driver but which is not DT, there is probably a compelling reason >> to still support the non-DT case. > > Rob, > > The Cubox is an open platform, and I use it just like a desktop PC. > When its required drivers will be in the mainline, I will do the same > as I do with PCs: I will not recompile a specific kernel each time > there are kernel bugs or security issues. Instead, I will just upgrade > my system from my distributor (Debian), and, in the packages, there > will be a generic mvebu kernel as there is already one for Marvell > Armada 370/xp, Freescale iMX5x/iMX6 (linux-image-3.10-3-armmp). > But, for that, all the Cubox specific stuff must be described in a DT. sure, I'm not saying *not* to support DT (send patches if need be). I'm just saying that it should be ok to also support non-DT case and that shared components (like tda998x) should also still work in non-DT case. BR, -R > -- > Ken ar c'hentañ | ** Breizh ha Linux atav! ** > Jef | http://moinejf.free.fr/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
