From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Erik Gilling <konkers-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Subject: Re: [PATCH] arm/dt: tegra devicetree support
Date: Wed, 20 Jul 2011 12:45:16 -0600 [thread overview]
Message-ID: <20110720184516.GF4642@ponder.secretlab.ca> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF049EBDEEFA-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On Wed, Jul 20, 2011 at 11:33:56AM -0700, Stephen Warren wrote:
> Grant Likely wrote at Wednesday, July 20, 2011 12:28 PM:
> > On Wed, Jul 20, 2011 at 08:37:19AM -0700, Stephen Warren wrote:
> > > Grant Likely wrote at Tuesday, July 19, 2011 5:43 PM:
> > > > Everything required to populate NVIDIA Tegra devices from the device
> > > > tree. This patch adds a new DT_MACHINE_DESC() which matches against
> > > > a tegra20 device tree. So far it only registers the on-chip devices,
> > > > but it will be refined in follow on patches to configure clocks and
> > > > pin IO from the device tree also.
> ...
> > > > diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts
> > >
> > > tegra-*.dts don't include status="disable" for all the unused controllers.
> > > Should that be added?
> >
> > I dropped that pattern since my preference has been to have boards
> > explicitly disable unused cores and that has generally been the
> > pattern on other DT platforms.
>
> Sorry if I wasn't clear, but what I meant was that the board-specific
> files tegra-harmony.dts and tegra-seaboard.dts don't include the status=
> "disable" entries for the modules/ports they don't use.
>
> Still, everything probably works OK without that...
For eval platforms, unless it is actively dangerous I would leave
devices enabled. If it is actively dangerous (or potentially so) then
that is an argument to disable by default in the tegra20.dtsi file,
but I've not yet run into any situations like that.
g.
WARNING: multiple messages have this Message-ID (diff)
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm/dt: tegra devicetree support
Date: Wed, 20 Jul 2011 12:45:16 -0600 [thread overview]
Message-ID: <20110720184516.GF4642@ponder.secretlab.ca> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF049EBDEEFA@HQMAIL01.nvidia.com>
On Wed, Jul 20, 2011 at 11:33:56AM -0700, Stephen Warren wrote:
> Grant Likely wrote at Wednesday, July 20, 2011 12:28 PM:
> > On Wed, Jul 20, 2011 at 08:37:19AM -0700, Stephen Warren wrote:
> > > Grant Likely wrote at Tuesday, July 19, 2011 5:43 PM:
> > > > Everything required to populate NVIDIA Tegra devices from the device
> > > > tree. This patch adds a new DT_MACHINE_DESC() which matches against
> > > > a tegra20 device tree. So far it only registers the on-chip devices,
> > > > but it will be refined in follow on patches to configure clocks and
> > > > pin IO from the device tree also.
> ...
> > > > diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts
> > >
> > > tegra-*.dts don't include status="disable" for all the unused controllers.
> > > Should that be added?
> >
> > I dropped that pattern since my preference has been to have boards
> > explicitly disable unused cores and that has generally been the
> > pattern on other DT platforms.
>
> Sorry if I wasn't clear, but what I meant was that the board-specific
> files tegra-harmony.dts and tegra-seaboard.dts don't include the status=
> "disable" entries for the modules/ports they don't use.
>
> Still, everything probably works OK without that...
For eval platforms, unless it is actively dangerous I would leave
devices enabled. If it is actively dangerous (or potentially so) then
that is an argument to disable by default in the tegra20.dtsi file,
but I've not yet run into any situations like that.
g.
WARNING: multiple messages have this Message-ID (diff)
From: Grant Likely <grant.likely@secretlab.ca>
To: Stephen Warren <swarren@nvidia.com>
Cc: Erik Gilling <konkers@android.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Colin Cross <ccross@android.com>, Olof Johansson <olof@lixom.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] arm/dt: tegra devicetree support
Date: Wed, 20 Jul 2011 12:45:16 -0600 [thread overview]
Message-ID: <20110720184516.GF4642@ponder.secretlab.ca> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF049EBDEEFA@HQMAIL01.nvidia.com>
On Wed, Jul 20, 2011 at 11:33:56AM -0700, Stephen Warren wrote:
> Grant Likely wrote at Wednesday, July 20, 2011 12:28 PM:
> > On Wed, Jul 20, 2011 at 08:37:19AM -0700, Stephen Warren wrote:
> > > Grant Likely wrote at Tuesday, July 19, 2011 5:43 PM:
> > > > Everything required to populate NVIDIA Tegra devices from the device
> > > > tree. This patch adds a new DT_MACHINE_DESC() which matches against
> > > > a tegra20 device tree. So far it only registers the on-chip devices,
> > > > but it will be refined in follow on patches to configure clocks and
> > > > pin IO from the device tree also.
> ...
> > > > diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts
> > >
> > > tegra-*.dts don't include status="disable" for all the unused controllers.
> > > Should that be added?
> >
> > I dropped that pattern since my preference has been to have boards
> > explicitly disable unused cores and that has generally been the
> > pattern on other DT platforms.
>
> Sorry if I wasn't clear, but what I meant was that the board-specific
> files tegra-harmony.dts and tegra-seaboard.dts don't include the status=
> "disable" entries for the modules/ports they don't use.
>
> Still, everything probably works OK without that...
For eval platforms, unless it is actively dangerous I would leave
devices enabled. If it is actively dangerous (or potentially so) then
that is an argument to disable by default in the tegra20.dtsi file,
but I've not yet run into any situations like that.
g.
next prev parent reply other threads:[~2011-07-20 18:45 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 23:43 [PATCH] arm/dt: tegra devicetree support Grant Likely
2011-07-19 23:43 ` Grant Likely
2011-07-19 23:43 ` Grant Likely
2011-07-19 23:56 ` Olof Johansson
2011-07-19 23:56 ` Olof Johansson
2011-07-19 23:56 ` Olof Johansson
[not found] ` <CAOesGMiy1t-98KZ_imFkGO-ify3S_00d_0XKc2vcLNRekxOvpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-20 18:56 ` Grant Likely
2011-07-20 18:56 ` Grant Likely
2011-07-20 18:56 ` Grant Likely
2011-07-20 15:37 ` Stephen Warren
2011-07-20 15:37 ` Stephen Warren
2011-07-20 15:37 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF049EBDEE27-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-07-20 16:03 ` Mark Brown
2011-07-20 16:03 ` Mark Brown
2011-07-20 16:03 ` Mark Brown
[not found] ` <20110720160355.GB2406-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2011-07-20 18:31 ` Grant Likely
2011-07-20 18:31 ` Grant Likely
2011-07-20 18:31 ` Grant Likely
[not found] ` <20110720183133.GE4642-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-07-20 18:40 ` Stephen Warren
2011-07-20 18:40 ` Stephen Warren
2011-07-20 18:40 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF049EBDEF01-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-07-20 18:47 ` Grant Likely
2011-07-20 18:47 ` Grant Likely
2011-07-20 18:47 ` Grant Likely
[not found] ` <20110720184758.GG4642-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-07-20 19:49 ` Mark Brown
2011-07-20 19:49 ` Mark Brown
2011-07-20 19:49 ` Mark Brown
2011-07-20 18:28 ` Grant Likely
2011-07-20 18:28 ` Grant Likely
2011-07-20 18:28 ` Grant Likely
[not found] ` <20110720182823.GD4642-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-07-20 18:33 ` Stephen Warren
2011-07-20 18:33 ` Stephen Warren
2011-07-20 18:33 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF049EBDEEFA-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-07-20 18:45 ` Grant Likely [this message]
2011-07-20 18:45 ` Grant Likely
2011-07-20 18:45 ` Grant Likely
2011-07-20 22:49 ` Shawn Guo
2011-07-20 22:49 ` Shawn Guo
2011-07-20 22:49 ` Shawn Guo
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=20110720184516.GF4642@ponder.secretlab.ca \
--to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org \
--cc=konkers-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@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.