From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] socfpga: hotplug: put cpu1 in wfi
Date: Thu, 02 Oct 2014 14:18:09 +0200 [thread overview]
Message-ID: <3341525.7GDFQS2rGu@wuerfel> (raw)
In-Reply-To: <20141001231646.GB1529@amd>
On Thursday 02 October 2014 01:16:46 Pavel Machek wrote:
> > >
> > > struct socfpga_reset_manager {
> > > u32 status;
> > > u32 ctrl;
> > > u32 counts;
> > > u32 padding1;
> > > u32 mpu_mod_reset;
> > > u32 per_mod_reset;
> > > u32 per2_mod_reset;
> > > u32 brg_mod_reset;
> > > };
> > >
> > > from u-boot. Unlike macros, structs have advantages that typos lead to
> > > easier-to-see failure modes... (And they are easier to read/parse,
> > > too).
> > >
> >
> > Copying from uboot sounds good, but I already know that the CPU reset
> > offset is different for our next SOC, Arria 10. The Arria 10 SOC should
> > still be able to use the same MSL as Cyclone5 and Arria5, but with a few
> > differences. One of them being, the CPU1 reset offset is at 0x20 instead
> > of 0x10. So I think having a macro for this one register is a bit
> > cleaner than having to define a whole new struct for Arria10.
>
> I don't think "whole new struct" is a problem. At least it will be
> plain to see what changed (which will get easily lost in ifdefs.
>
> struct cyclone5_reset_manager {
> struct socfpga_reset_manager common;
> u32 brg_mod_reset;
> }
>
> struct aria10_reset_manager {
> struct socfpga_reset_manager common;
> char filler[0x10];
> u32 brg_mod_reset;
> }
>
> if (of_machine_is_compatible("altr,socfpga-arria10"))
> __raw_writel(0, (struct cyclone5_reset_manager *) rst_manager_base_addr->brg_mod_reset));
> else
> __raw_writel(0, (struct aria10_reset_manager *) rst_manager_base_addr->brg_mod_reset));
>
> ...does not sound that bad. (And you'll need some nice solution for
> u-boot, anyway...)
I think it would be better to just add more fields and access a different
field based on the SoC type than cast the structs around.
Also, never use __raw_writel unless you know exactly what you are doing.
This should use writel, or possibly writel_relaxed.
Finally, don't sprinkle of_machine_is_compatible() checks all over the
place. Make the decision once when you initially probe the machine.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Pavel Machek <pavel@denx.de>,
Dinh Nguyen <dinguyen@opensource.altera.com>,
linux@arm.linux.org.uk, atull <atull@opensource.altera.com>,
yvanderv@opensource.altera.com, linux-kernel@vger.kernel.org,
delicious.quinoa@gmail.com
Subject: Re: [PATCH 1/2] socfpga: hotplug: put cpu1 in wfi
Date: Thu, 02 Oct 2014 14:18:09 +0200 [thread overview]
Message-ID: <3341525.7GDFQS2rGu@wuerfel> (raw)
In-Reply-To: <20141001231646.GB1529@amd>
On Thursday 02 October 2014 01:16:46 Pavel Machek wrote:
> > >
> > > struct socfpga_reset_manager {
> > > u32 status;
> > > u32 ctrl;
> > > u32 counts;
> > > u32 padding1;
> > > u32 mpu_mod_reset;
> > > u32 per_mod_reset;
> > > u32 per2_mod_reset;
> > > u32 brg_mod_reset;
> > > };
> > >
> > > from u-boot. Unlike macros, structs have advantages that typos lead to
> > > easier-to-see failure modes... (And they are easier to read/parse,
> > > too).
> > >
> >
> > Copying from uboot sounds good, but I already know that the CPU reset
> > offset is different for our next SOC, Arria 10. The Arria 10 SOC should
> > still be able to use the same MSL as Cyclone5 and Arria5, but with a few
> > differences. One of them being, the CPU1 reset offset is at 0x20 instead
> > of 0x10. So I think having a macro for this one register is a bit
> > cleaner than having to define a whole new struct for Arria10.
>
> I don't think "whole new struct" is a problem. At least it will be
> plain to see what changed (which will get easily lost in ifdefs.
>
> struct cyclone5_reset_manager {
> struct socfpga_reset_manager common;
> u32 brg_mod_reset;
> }
>
> struct aria10_reset_manager {
> struct socfpga_reset_manager common;
> char filler[0x10];
> u32 brg_mod_reset;
> }
>
> if (of_machine_is_compatible("altr,socfpga-arria10"))
> __raw_writel(0, (struct cyclone5_reset_manager *) rst_manager_base_addr->brg_mod_reset));
> else
> __raw_writel(0, (struct aria10_reset_manager *) rst_manager_base_addr->brg_mod_reset));
>
> ...does not sound that bad. (And you'll need some nice solution for
> u-boot, anyway...)
I think it would be better to just add more fields and access a different
field based on the SoC type than cast the structs around.
Also, never use __raw_writel unless you know exactly what you are doing.
This should use writel, or possibly writel_relaxed.
Finally, don't sprinkle of_machine_is_compatible() checks all over the
place. Make the decision once when you initially probe the machine.
Arnd
next prev parent reply other threads:[~2014-10-02 12:18 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 20:27 [PATCH 0/2] socfpga: fix hotplug/add suspend to ram atull at opensource.altera.com
2014-09-24 20:27 ` atull
2014-09-24 20:27 ` [PATCH 1/2] socfpga: hotplug: put cpu1 in wfi atull at opensource.altera.com
2014-09-24 20:27 ` atull
2014-09-24 21:28 ` Russell King - ARM Linux
2014-09-24 21:28 ` Russell King - ARM Linux
2014-09-25 15:06 ` atull
2014-09-25 15:06 ` atull
2014-10-01 13:35 ` Pavel Machek
2014-10-01 13:35 ` Pavel Machek
2014-10-01 14:17 ` atull
2014-10-01 14:17 ` atull
2014-10-01 15:04 ` Pavel Machek
2014-10-01 15:04 ` Pavel Machek
2014-10-01 16:07 ` Dinh Nguyen
2014-10-01 16:07 ` Dinh Nguyen
2014-10-01 23:16 ` Pavel Machek
2014-10-01 23:16 ` Pavel Machek
2014-10-02 11:36 ` Dinh Nguyen
2014-10-02 11:36 ` Dinh Nguyen
2014-10-02 12:18 ` Arnd Bergmann [this message]
2014-10-02 12:18 ` Arnd Bergmann
2014-10-02 21:03 ` atull
2014-10-02 21:03 ` atull
2014-09-24 20:27 ` [PATCH 2/2] socfpga: support suspend to ram atull at opensource.altera.com
2014-09-24 20:27 ` atull
2014-09-25 8:25 ` Steffen Trumtrar
2014-09-25 8:25 ` Steffen Trumtrar
2014-09-25 17:10 ` atull
2014-09-25 17:10 ` atull
2014-09-26 14:56 ` Dinh Nguyen
2014-09-26 14:56 ` Dinh Nguyen
2014-09-26 20:23 ` atull
2014-09-26 20:23 ` atull
2014-10-01 13:49 ` Pavel Machek
2014-10-01 13:49 ` Pavel Machek
2014-10-01 19:24 ` atull
2014-10-01 19:24 ` atull
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=3341525.7GDFQS2rGu@wuerfel \
--to=arnd@arndb.de \
--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.