All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@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 15:53:44 -0600	[thread overview]
Message-ID: <4F9B1568.9070704@wwwdotorg.org> (raw)
In-Reply-To: <CAOesGMh3NY4cQERSQY-p0QsMtcCXyhkdGSGnnrckcz8-DPjbBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 04/27/2012 03:39 PM, Olof Johansson wrote:
> 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.
...
> 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.

I'm slightly hesitant not to have some overlap. But then again, I very
rarely use non-DT these days anyway, so it's not like it gets tested
much, unless anyone else is doing it silently.

>> The device tree conversion status is:
...
> 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.

The only one sticking point might be that the Harmony regulator
initialization needs to wait for the regulator driver to be probed, but
happen before the PCIe driver is registers. Perhaps we could hook up
some temporary bus notifiers to handle that. But since PCIe will likely
be fixed in 3.6, we could probably just wait for that on Harmony.

Other than that, it's probably all very easy. I'll work on some patches
and maybe we can at least bring in the TrimSlice and Paz00 schedule.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: Tegra board file deprecation schedule
Date: Fri, 27 Apr 2012 15:53:44 -0600	[thread overview]
Message-ID: <4F9B1568.9070704@wwwdotorg.org> (raw)
In-Reply-To: <CAOesGMh3NY4cQERSQY-p0QsMtcCXyhkdGSGnnrckcz8-DPjbBw@mail.gmail.com>

On 04/27/2012 03:39 PM, Olof Johansson wrote:
> 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.
...
> 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.

I'm slightly hesitant not to have some overlap. But then again, I very
rarely use non-DT these days anyway, so it's not like it gets tested
much, unless anyone else is doing it silently.

>> The device tree conversion status is:
...
> 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.

The only one sticking point might be that the Harmony regulator
initialization needs to wait for the regulator driver to be probed, but
happen before the PCIe driver is registers. Perhaps we could hook up
some temporary bus notifiers to handle that. But since PCIe will likely
be fixed in 3.6, we could probably just wait for that on Harmony.

Other than that, it's probably all very easy. I'll work on some patches
and maybe we can at least bring in the TrimSlice and Paz00 schedule.

  parent reply	other threads:[~2012-04-27 21:53 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
2012-04-27 21:39     ` Olof Johansson
     [not found]     ` <CAOesGMh3NY4cQERSQY-p0QsMtcCXyhkdGSGnnrckcz8-DPjbBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-04-27 21:53       ` Stephen Warren [this message]
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=4F9B1568.9070704@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@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=olof-nZhT3qVonbNeoWH0uzbU5w@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.