linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Olof Johansson <olof@lixom.net>
Cc: "Nishanth Menon" <nm@ti.com>, "Tony Lindgren" <tony@atomide.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Felipe Balbi" <balbi@ti.com>,
	"Benoît Cousson" <bcousson@baylibre.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH] ARM: OMAP3630: Add generic machine descriptor
Date: Fri, 20 Sep 2013 12:42:28 -0500	[thread overview]
Message-ID: <20130920174228.GK18721@radagast> (raw)
In-Reply-To: <CAOesGMiru=RUHS4XKLL=DC+hxtAJqtcjgd5hPbaccnAfEZ3y0g@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1460 bytes --]

Hi,

On Fri, Sep 20, 2013 at 10:16:48AM -0700, Olof Johansson wrote:
> > On Fri, Sep 20, 2013 at 09:19:02AM -0700, Olof Johansson wrote:
> >> On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon <nm@ti.com> wrote:
> >> > An alternative approach may be to (for all SoCs):
> >> > 1. define every SoC entry - ti,omap3430 ti,omap3630...
> >> > 2. have a generic omap3_init which uses "if (of_machine_is_compatible("ti,omap3630"))"
> >> > to invoke the appropriate omap3xxx_init_early.
> >>
> >> Yes, this would be better, but you can do add a DT_MACHINE as in this
> >> patch but have ti,omap3630 as the dt_compat table. Then there's no
> >> need to add runtime checks.
> >
> > I was going to reply that adding of_machine_is_compatible("ti,omap3630")
> > would help in some situations, but guess it's already tainted ;-)
> 
> Oh, if it's just a few checks, then by all means go down that route. I
> didn't look at the code to see how much it would be.
> 
> But if a new DT_MACHINE is added, then it should definitely be based
> on ti,omap3630 instead of listing all the boards.

the idea was to CPU compatible property to conditionally enable known
erratas workarounds. In some cases, Revision register can't be trusted,
so instead of creating per-errata DT properties (since that'd be
describing the SW, in a way), I thought of using
of_machine_is_compatible() checks, but that assumes CPU compatible is
"correct".

cheers

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2013-09-20 17:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-20 16:08 [RFC PATCH] ARM: OMAP3630: Add generic machine descriptor Nishanth Menon
2013-09-20 16:19 ` Olof Johansson
2013-09-20 16:23   ` Felipe Balbi
2013-09-20 17:16     ` Olof Johansson
2013-09-20 17:42       ` Felipe Balbi [this message]
2013-09-20 19:10         ` Nishanth Menon
2013-10-07 16:49           ` [PATCH 0/2] ARM: dts: OMAP: standardize SoC specific bindings Nishanth Menon
2013-10-07 16:49             ` [PATCH 1/2] Documentation: dt: OMAP: standardize SoC naming definition Nishanth Menon
2013-10-07 19:17               ` Tony Lindgren
2013-10-07 16:49             ` [PATCH 2/2] ARM: dts: omap3-beagle: use 3630 definitions Nishanth Menon
2013-10-07 19:20               ` Tony Lindgren
2013-10-07 20:30                 ` [PATCH V2] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree Nishanth Menon
2013-10-07 20:32                   ` Nishanth Menon
2013-10-07 20:43                 ` [PATCH V3] " Nishanth Menon
2013-10-08  0:05                   ` Sebastian Reichel
2013-10-08 12:00                     ` Nishanth Menon
2013-10-08 17:58                       ` Tony Lindgren
2013-10-08 17:59                         ` Nishanth Menon
2013-10-08 17:47                 ` [PATCH 2/2] ARM: dts: omap3-beagle: use 3630 definitions Felipe Balbi
2013-10-08 18:01                   ` Nishanth Menon

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=20130920174228.GK18721@radagast \
    --to=balbi@ti.com \
    --cc=bcousson@baylibre.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=olof@lixom.net \
    --cc=tony@atomide.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).