From: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> Cc: "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>, Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org>, Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>, ARM kernel mailing list <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org> Subject: Re: Tegra board file deprecation schedule Date: Fri, 27 Apr 2012 14:39:35 -0700 [thread overview] Message-ID: <CAOesGMh3NY4cQERSQY-p0QsMtcCXyhkdGSGnnrckcz8-DPjbBw@mail.gmail.com> (raw) In-Reply-To: <4F9B0E7C.1060408-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote: > Eventually, Tegra support will become device tree only in the mainline > kernel; arch/arm/mach-tegra/board* will be deleted. > > I propose the following policy towards this goal: I'd like to maintain > the board files until the relevant device tree file has the same level > of functionality. Once that is achieved, and a Linus kernel is release > with full support for the board via device tree, the board files can be > deleted from the next kernel release. > > Does anyone have any issues with this? Sounds great, but I think you can be more aggressive than this; no need to keep the non-DT board alive for the final release. > The device tree conversion status is: > > Cardhu/Ventana: > > None; already device tree only > > Seaboard: > > Kaen and Wario board variants are not explicitly supported via device > tree. However, the differences are almost entirely minor (at least as > far as the current features supported in board-seaboard*), so anyone > wishing to use those board variants could easily create their own device > tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in > 3.6 unless someone objects. Wario is no longer an active platform and can be completely removed; I'll post patches for this. Kaen is somewhat active, but I can send a device tree for it; definitely ok to sunset before it's in since we can carry it locally in our downstream kernel tree if needed. > > Harmony: > > Missing support for TPS6586x regulator, and PCI-Express controller. > Thierry is working on this. I hope this support will be ready to be > merged for 3.6, and hence board-harmony* can be deleted in 3.7. > > TrimSlice: > > Missing RTC and Micro-SD slot support. I've sent patches for this, which > will be merged today. > > Missing audio support. I sent patches for this today. I hope they'll be > merged for 3.5. > > Missing PCI-Express support; status above. > > I hope board-trimslice* can be deleted in 3.7. > > Paz00/Toshiba AC100: > > Missing rfkill button support. Defining a good binding for this might > prove challenging. Marc Dietrich started work on this a while back. I > pinged him to see if he intends to continue this work. > > This is probably the long-pole for completely removing board files, > unless we ignore the rfkill feature and delete the board files anyway. if this is the only thing holding it up sunsetting all non-DT boards on tegra then I suggest just adding a one-time runtime test that adds a platform device on that device tree platform. As long as there aren't more of them creeping in over time that should be OK. -Olof
WARNING: multiple messages have this Message-ID (diff)
From: olof@lixom.net (Olof Johansson) To: linux-arm-kernel@lists.infradead.org Subject: Tegra board file deprecation schedule Date: Fri, 27 Apr 2012 14:39:35 -0700 [thread overview] Message-ID: <CAOesGMh3NY4cQERSQY-p0QsMtcCXyhkdGSGnnrckcz8-DPjbBw@mail.gmail.com> (raw) In-Reply-To: <4F9B0E7C.1060408@wwwdotorg.org> On Fri, Apr 27, 2012 at 2:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > Eventually, Tegra support will become device tree only in the mainline > kernel; arch/arm/mach-tegra/board* will be deleted. > > I propose the following policy towards this goal: I'd like to maintain > the board files until the relevant device tree file has the same level > of functionality. Once that is achieved, and a Linus kernel is release > with full support for the board via device tree, the board files can be > deleted from the next kernel release. > > Does anyone have any issues with this? Sounds great, but I think you can be more aggressive than this; no need to keep the non-DT board alive for the final release. > The device tree conversion status is: > > Cardhu/Ventana: > > None; already device tree only > > Seaboard: > > Kaen and Wario board variants are not explicitly supported via device > tree. However, the differences are almost entirely minor (at least as > far as the current features supported in board-seaboard*), so anyone > wishing to use those board variants could easily create their own device > tree files. I plan to ignore Kaen/Wario and delete board-seaboard* in > 3.6 unless someone objects. Wario is no longer an active platform and can be completely removed; I'll post patches for this. Kaen is somewhat active, but I can send a device tree for it; definitely ok to sunset before it's in since we can carry it locally in our downstream kernel tree if needed. > > Harmony: > > Missing support for TPS6586x regulator, and PCI-Express controller. > Thierry is working on this. I hope this support will be ready to be > merged for 3.6, and hence board-harmony* can be deleted in 3.7. > > TrimSlice: > > Missing RTC and Micro-SD slot support. I've sent patches for this, which > will be merged today. > > Missing audio support. I sent patches for this today. I hope they'll be > merged for 3.5. > > Missing PCI-Express support; status above. > > I hope board-trimslice* can be deleted in 3.7. > > Paz00/Toshiba AC100: > > Missing rfkill button support. Defining a good binding for this might > prove challenging. Marc Dietrich started work on this a while back. I > pinged him to see if he intends to continue this work. > > This is probably the long-pole for completely removing board files, > unless we ignore the rfkill feature and delete the board files anyway. if this is the only thing holding it up sunsetting all non-DT boards on tegra then I suggest just adding a one-time runtime test that adds a platform device on that device tree platform. As long as there aren't more of them creeping in over time that should be OK. -Olof
next prev parent reply other threads:[~2012-04-27 21:39 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-27 21:24 Tegra board file deprecation schedule Stephen Warren 2012-04-27 21:24 ` Stephen Warren [not found] ` <4F9B0E7C.1060408-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-04-27 21:39 ` Olof Johansson [this message] 2012-04-27 21:39 ` Olof Johansson [not found] ` <CAOesGMh3NY4cQERSQY-p0QsMtcCXyhkdGSGnnrckcz8-DPjbBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-27 21:53 ` Stephen Warren 2012-04-27 21:53 ` Stephen Warren [not found] ` <4F9B1568.9070704-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-04-27 22:00 ` Fabio Estevam 2012-04-27 22:00 ` Fabio Estevam [not found] ` <CAOMZO5Cnd9knDUuc4aZrPrtk5YKUwpr-oJhUnu=z94=9CfY1ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-27 22:20 ` Stephen Warren 2012-04-27 22:20 ` Stephen Warren 2012-04-28 16:09 ` Marc Dietrich 2012-04-28 16:09 ` Marc Dietrich 2012-04-28 21:34 ` Russell King - ARM Linux 2012-04-28 21:34 ` Russell King - ARM Linux [not found] ` <20120428213456.GD27792-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2012-04-29 18:11 ` Marc Dietrich 2012-04-29 18:11 ` Marc Dietrich 2012-04-29 18:56 ` Russell King - ARM Linux 2012-04-29 18:56 ` Russell King - ARM Linux 2012-04-29 19:16 ` Stephen Warren 2012-04-29 19:16 ` Stephen Warren [not found] ` <4F9D9396.9070009-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-04-30 8:58 ` Marc Dietrich 2012-04-30 8:58 ` Marc Dietrich 2012-04-30 15:58 ` Stephen Warren 2012-04-30 15:58 ` Stephen Warren [not found] ` <4F9EB68A.3080309-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-04-30 16:51 ` Marc Dietrich 2012-04-30 16:51 ` Marc Dietrich 2012-04-29 19:21 ` Stephen Warren 2012-04-29 19:21 ` Stephen Warren [not found] ` <4F9D94B3.4070903-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> 2012-04-30 9:00 ` Marc Dietrich 2012-04-30 9:00 ` Marc Dietrich 2012-04-28 21:26 ` Lucas Stach 2012-04-28 21:26 ` Lucas Stach 2012-04-29 19:25 ` Stephen Warren 2012-04-29 19:25 ` Stephen Warren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOesGMh3NY4cQERSQY-p0QsMtcCXyhkdGSGnnrckcz8-DPjbBw@mail.gmail.com \ --to=olof-nzht3qvonbneowh0uzbu5w@public.gmane.org \ --cc=ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=marvin24-Mmb7MZpHnFY@public.gmane.org \ --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \ --cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.