From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: "Frank Rowand" <frowand.list@gmail.com>,
"Michel Pollet" <michel.pollet@bp.renesas.com>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"Simon Horman" <horms@verge.net.au>,
"Michel Pollet" <buserror+upstream@gmail.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Phil Edworthy" <phil.edworthy@renesas.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Rajendra Nayak" <rnayak@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Stefan Wahren" <stefan.wahren@i2se.com>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Russell King" <linux@armlinux.org.uk>,
"Douglas Anderson" <dianders@chromium.org>,
"Chen-Yu Tsai" <wens@csie.org>,
"Carlo Caione" <carlo@endlessm.com>,
"Andreas Färber" <afaerber@suse.de>,
"Frank Rowand" <frank.rowand@sony.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
Date: Wed, 6 Jun 2018 21:42:59 +0200 [thread overview]
Message-ID: <CAMuHMdXv2UXTx_ttCqytH2TePoJ-Pw4gJ-PaSOmUL969ac1BMw@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqJCkP_c_wKGRc7Qzkiw8sZLRf6MGz-WgVsLjnQfqK8r6Q@mail.gmail.com>
Hi Rob,
On Wed, Jun 6, 2018 at 9:35 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Actually, this is all already documented in the DT spec and it is
> always 2 cells[1]. We should perhaps just remove whatever is
> duplicated from the spec.
>
> Rob
>
> [1]
> ``cpu-release-addr`` | SD | ``<u64>`` The
> cpu-release-addr property is required for
> cpu nodes that have
> an enable-method property
> value of
> ``"spin-table"``. The value specifies the
> physical address of
> a spin table entry that
> releases a
> secondary CPU from its spin loop.
Interesting. But why is this <u64>, and not just following #address-cells?
Due to the ePAPR-spec being 64-bit Power System-centric?
There's also "initial-mapped-area", which must use 64-bit values for effective
and physical addresses, according to ePAPR.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2018-06-06 19:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 11:28 [PATCH v4 0/3] Renesas R9A06G032 SMP enabler Michel Pollet
2018-06-05 11:28 ` [PATCH v4 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method Michel Pollet
2018-06-05 13:23 ` Geert Uytterhoeven
2018-06-06 8:47 ` Simon Horman
2018-06-05 11:28 ` [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver Michel Pollet
2018-06-05 13:24 ` Geert Uytterhoeven
2018-06-05 17:34 ` Frank Rowand
2018-06-06 6:36 ` Michel Pollet
2018-06-06 19:30 ` Frank Rowand
2018-06-06 19:35 ` Rob Herring
2018-06-06 19:42 ` Geert Uytterhoeven [this message]
2018-06-06 20:28 ` Rob Herring
2018-06-06 21:31 ` Frank Rowand
2018-06-06 19:37 ` Florian Fainelli
2018-06-06 19:46 ` Geert Uytterhoeven
2018-06-06 21:48 ` Frank Rowand
2018-06-06 21:52 ` Frank Rowand
2018-06-07 6:59 ` Michel Pollet
2018-06-07 15:54 ` Rob Herring
2018-06-08 6:50 ` Michel Pollet
2018-06-08 8:47 ` Geert Uytterhoeven
2018-06-08 20:41 ` Rob Herring
2018-06-09 12:10 ` Geert Uytterhoeven
2018-06-05 11:28 ` [PATCH v4 3/3] ARM: dts: Renesas R9A06G032 SMP enable method Michel Pollet
2018-06-05 13:24 ` Geert Uytterhoeven
2018-06-05 13:24 ` Geert Uytterhoeven
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=CAMuHMdXv2UXTx_ttCqytH2TePoJ-Pw4gJ-PaSOmUL969ac1BMw@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=afaerber@suse.de \
--cc=buserror+upstream@gmail.com \
--cc=carlo@endlessm.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=f.fainelli@gmail.com \
--cc=frank.rowand@sony.com \
--cc=frowand.list@gmail.com \
--cc=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=mark.rutland@arm.com \
--cc=michel.pollet@bp.renesas.com \
--cc=phil.edworthy@renesas.com \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=stefan.wahren@i2se.com \
--cc=wens@csie.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).