All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.