From: tixy@linaro.org (Jon Medhurst (Tixy))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/5] arm64: Juno: Add memory mapped timer node
Date: Tue, 19 May 2015 13:58:03 +0100 [thread overview]
Message-ID: <1432040283.3047.54.camel@linaro.org> (raw)
In-Reply-To: <20150519113116.GH2175@e106497-lin.cambridge.arm.com>
On Tue, 2015-05-19 at 12:31 +0100, Liviu Dudau wrote:
> On Tue, May 19, 2015 at 11:56:43AM +0100, Jon Medhurst (Tixy) wrote:
> > On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote:
> > > Juno based boards have a memory mapped timer @ 0x2a810000. This
> > > is disabled on r0 version of the board due to an SoC errata.
> >
> > So wouldn't it make more sense then to disable it in the dts for r0? As
> > it is, you disable it in the common file below then have to later
> > re-enable it in juno-r1.dts.
>
> From what I have seen in the existing DTs the preffer approach seems to be of
> disabling by default the node declared in the common files and enable
> it in the DT that makes use of it.
Yes, I does look that way, and I agree consistency usually wins out over
any arguments over log or obviousness.
> If there is any guidance on how to describe this sort of situations I
> would really love to read it.
I know of none, but I'd speculate the principal we've discovered is to
fail safe and have potentially absent or broken hardware disabled by
default.
--
Tixy
WARNING: multiple messages have this Message-ID (diff)
From: "Jon Medhurst (Tixy)" <tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Sudeep Holla <Sudeep.Holla-5wv7dgnIgG8@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
LAKML
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2 3/5] arm64: Juno: Add memory mapped timer node
Date: Tue, 19 May 2015 13:58:03 +0100 [thread overview]
Message-ID: <1432040283.3047.54.camel@linaro.org> (raw)
In-Reply-To: <20150519113116.GH2175-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On Tue, 2015-05-19 at 12:31 +0100, Liviu Dudau wrote:
> On Tue, May 19, 2015 at 11:56:43AM +0100, Jon Medhurst (Tixy) wrote:
> > On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote:
> > > Juno based boards have a memory mapped timer @ 0x2a810000. This
> > > is disabled on r0 version of the board due to an SoC errata.
> >
> > So wouldn't it make more sense then to disable it in the dts for r0? As
> > it is, you disable it in the common file below then have to later
> > re-enable it in juno-r1.dts.
>
> From what I have seen in the existing DTs the preffer approach seems to be of
> disabling by default the node declared in the common files and enable
> it in the DT that makes use of it.
Yes, I does look that way, and I agree consistency usually wins out over
any arguments over log or obviousness.
> If there is any guidance on how to describe this sort of situations I
> would really love to read it.
I know of none, but I'd speculate the principal we've discovered is to
fail safe and have potentially absent or broken hardware disabled by
default.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
devicetree <devicetree@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Sudeep Holla <Sudeep.Holla@arm.com>,
Olof Johansson <olof@lixom.net>,
LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 3/5] arm64: Juno: Add memory mapped timer node
Date: Tue, 19 May 2015 13:58:03 +0100 [thread overview]
Message-ID: <1432040283.3047.54.camel@linaro.org> (raw)
In-Reply-To: <20150519113116.GH2175@e106497-lin.cambridge.arm.com>
On Tue, 2015-05-19 at 12:31 +0100, Liviu Dudau wrote:
> On Tue, May 19, 2015 at 11:56:43AM +0100, Jon Medhurst (Tixy) wrote:
> > On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote:
> > > Juno based boards have a memory mapped timer @ 0x2a810000. This
> > > is disabled on r0 version of the board due to an SoC errata.
> >
> > So wouldn't it make more sense then to disable it in the dts for r0? As
> > it is, you disable it in the common file below then have to later
> > re-enable it in juno-r1.dts.
>
> From what I have seen in the existing DTs the preffer approach seems to be of
> disabling by default the node declared in the common files and enable
> it in the DT that makes use of it.
Yes, I does look that way, and I agree consistency usually wins out over
any arguments over log or obviousness.
> If there is any guidance on how to describe this sort of situations I
> would really love to read it.
I know of none, but I'd speculate the principal we've discovered is to
fail safe and have potentially absent or broken hardware disabled by
default.
--
Tixy
next prev parent reply other threads:[~2015-05-19 12:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 17:28 [PATCH v2 0/5] arm64: Juno DT updates and new DT for Juno R1 Liviu Dudau
2015-05-18 17:28 ` Liviu Dudau
2015-05-18 17:28 ` [PATCH v2 1/5] arm64: Juno: Fix the GIC node address label and the frequency of FAXI clock Liviu Dudau
2015-05-18 17:28 ` Liviu Dudau
2015-05-18 17:28 ` [PATCH v2 2/5] arm64: Juno: Split juno.dts into juno-base.dtsi and juno.dts Liviu Dudau
2015-05-18 17:28 ` Liviu Dudau
2015-05-18 17:28 ` [PATCH v2 3/5] arm64: Juno: Add memory mapped timer node Liviu Dudau
2015-05-18 17:28 ` Liviu Dudau
2015-05-19 10:56 ` Jon Medhurst (Tixy)
2015-05-19 10:56 ` Jon Medhurst (Tixy)
2015-05-19 11:31 ` Liviu Dudau
2015-05-19 11:31 ` Liviu Dudau
2015-05-19 11:31 ` Liviu Dudau
2015-05-19 12:58 ` Jon Medhurst (Tixy) [this message]
2015-05-19 12:58 ` Jon Medhurst (Tixy)
2015-05-19 12:58 ` Jon Medhurst (Tixy)
2015-05-18 17:28 ` [PATCH v2 4/5] arm64: Juno: Add GICv2m support in device tree Liviu Dudau
2015-05-18 17:28 ` Liviu Dudau
2015-05-18 17:28 ` [PATCH v2 5/5] arm64: Add DT support for Juno r1 board Liviu Dudau
2015-05-18 17:28 ` Liviu Dudau
2015-05-18 20:14 ` [PATCH v2 0/5] arm64: Juno DT updates and new DT for Juno R1 Arnd Bergmann
2015-05-18 20:14 ` Arnd Bergmann
2015-05-18 20:14 ` Arnd Bergmann
2015-05-18 22:31 ` Liviu Dudau
2015-05-18 22:31 ` Liviu Dudau
2015-05-18 22:31 ` Liviu Dudau
2015-05-19 11:11 ` Sudeep Holla
2015-05-19 11:11 ` Sudeep Holla
2015-05-19 11:11 ` Sudeep Holla
2015-05-20 10:47 ` Liviu Dudau
2015-05-20 10:47 ` Liviu Dudau
2015-05-20 10:47 ` Liviu Dudau
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=1432040283.3047.54.camel@linaro.org \
--to=tixy@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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.