linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
Date: Tue, 9 Sep 2014 14:42:26 +0100	[thread overview]
Message-ID: <20140909134226.GF29639@arm.com> (raw)
In-Reply-To: <04e8fff8fb044e8ea5ffe92bfe029d6c@BN1PR03MB220.namprd03.prod.outlook.com>

On Tue, Sep 09, 2014 at 12:46:18PM +0100, bhupesh.sharma at freescale.com wrote:
> > On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> > > On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > > > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > > > >
> > > > > However, I'm not sure I follow the reasoning for making this
> > > > > significantly harder, and even ignoring that I don't think this
> > > > > does make things significantly harder. Especially so if we have a
> > > > > PSCI node but not an enable method -- in that case its trivial to
> > > > > patch in an unrelated enable-method anyhow.
> > > >
> > > > Right, it's not actually much harder. A better way to look at it is
> > > > probably that we document what which parts we expect to stay
> > > > constant and which parts are to be filled out by the boot loader.
> > > > Independent of what PSCI implementation the boot loader provides, we
> > > > would like to see enable-method="psci".
> > >
> > > So in the /cpus node, have a comment like:
> > >
> > > /*
> > >  * We expect the enable-method to be "psci", but this is dependent on
> > >  * the FW, which will fill this in.
> > >  */
> > 
> > I was thinking of leaving the enable-method in the cpus node, but having
> > an empty psci node with a similar comment.
> > 
> > > Or, should we put together a soc-guidance.txt with that, ensuring
> > > things are initialised correctly (CNTVOFF, CNTFREQ), etc?
> > 
> > I would very much welcome documentation like that!
> 
> Is this documentation planned (already being worked upon), or should I
> try to spin-out a RFC patch which tries to add this guidance
> documentation.

RFCs are welcome. We had such thing on the random to-do list of the day
but never got to write anything down. As Stuart mentioned, it would be
better to add it as part of the booting.txt document. A potential
soc.txt is more for DT, code structuring (spreading) throughout drivers/
etc. If you have time, that would be good as well ;).

-- 
Catalin

  reply	other threads:[~2014-09-09 13:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03 15:13 [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 1/6] Documentation: DT: Add bindings for FSL NS16550A UART Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 2/6] Documentation: DT: Add entry for FSL LS2085A SoC and Simulator model Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 3/6] Documentation: DT: Add entry for FSL Management Complex Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A SoC Bhupesh Sharma
2014-09-03 18:34   ` Arnd Bergmann
2014-09-04  7:55     ` bhupesh.sharma at freescale.com
2014-09-20 20:35     ` bhupesh.sharma at freescale.com
2014-09-03 15:13 ` [PATCH V3 5/6] arm64: dts/Makefile: Add support for FSL's LS2085A simulator model Bhupesh Sharma
2014-09-03 15:13 ` [PATCH V3 6/6] arm64: Add support for FSL's LS2085A SoC in Kconfig and defconfig Bhupesh Sharma
2014-09-03 15:29 ` [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC Arnd Bergmann
2014-09-03 15:36   ` bhupesh.sharma at freescale.com
2014-09-03 15:39     ` Arnd Bergmann
2014-09-03 15:42       ` bhupesh.sharma at freescale.com
2014-09-03 15:56       ` Mark Rutland
2014-09-03 16:05         ` Arnd Bergmann
2014-09-03 16:09           ` Mark Rutland
2014-09-03 16:10             ` bhupesh.sharma at freescale.com
2014-09-03 16:18             ` Arnd Bergmann
2014-09-03 16:31               ` Mark Rutland
2014-09-03 18:31                 ` Arnd Bergmann
2014-09-04  9:13                   ` Mark Rutland
2014-09-04  9:39                     ` Arnd Bergmann
2014-09-04 16:32                       ` Stuart Yoder
2014-09-09 11:46                       ` bhupesh.sharma at freescale.com
2014-09-09 13:42                         ` Catalin Marinas [this message]
2014-09-20 20:35                       ` bhupesh.sharma at freescale.com
2014-09-22 13:55                         ` Mark Rutland
2014-09-24 14:50                       ` Stuart Yoder
2014-09-03 18:30         ` Geoff Levand

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=20140909134226.GF29639@arm.com \
    --to=catalin.marinas@arm.com \
    --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 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).