All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.