All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Ford <aford173@gmail.com>
To: u-boot@lists.denx.de
Cc: trini@konsulko.com, aford@beaconembedded.com,
	Adam Ford <aford173@gmail.com>
Subject: [PATCH 1/2] arm: omap3: Cleanup sys_info to fit OMAP3 booting with LTO
Date: Sat, 12 Feb 2022 06:12:40 -0600	[thread overview]
Message-ID: <20220212121241.1655425-1-aford173@gmail.com> (raw)

With LTO enabled, some functions appear to be optimized in a
way that causes hanging on some OMAP3 boards after some
unrelated patches were applied.  The solution appears to make
several functions __used.  There also appears be to be some
dead code, so remove it while cleaning this up.

This has been tested on a general purpose OMAP3530, DM3730,
and AM3517.

Signed-off-by: Adam Ford <aford173@gmail.com>

diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h
index a6e9ff84aa..e7078a32db 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -45,16 +45,12 @@ void gpmc_init(void);
 void enable_gpmc_cs_config(const u32 *gpmc_config, const struct gpmc_cs *cs,
 				u32 base, u32 size);
 void set_gpmc_cs0(int flash_type);
-
 void watchdog_init(void);
 void set_muxconf_regs(void);
-
 u32 get_cpu_family(void);
 u32 get_cpu_rev(void);
-u32 get_sku_id(void);
 u32 is_gpmc_muxed(void);
 u32 get_gpmc0_type(void);
-u32 get_gpmc0_width(void);
 u32 is_running_in_sdram(void);
 u32 is_running_in_sram(void);
 u32 is_running_in_flash(void);
diff --git a/arch/arm/mach-omap2/omap3/sys_info.c b/arch/arm/mach-omap2/omap3/sys_info.c
index ac72633c20..5f535e2782 100644
--- a/arch/arm/mach-omap2/omap3/sys_info.c
+++ b/arch/arm/mach-omap2/omap3/sys_info.c
@@ -55,7 +55,7 @@ void omap_die_id(unsigned int *die_id)
 /******************************************
  * get_cpu_type(void) - extract cpu info
  ******************************************/
-u32 get_cpu_type(void)
+static u32 get_cpu_type(void)
 {
 	return readl(&ctrl_base->ctrl_omap_stat);
 }
@@ -64,7 +64,7 @@ u32 get_cpu_type(void)
  * get_cpu_id(void) - extract cpu id
  * returns 0 for ES1.0, cpuid otherwise
  ******************************************/
-u32 get_cpu_id(void)
+static u32 get_cpu_id(void)
 {
 	struct ctrl_id *id_base;
 	u32 cpuid = 0;
@@ -89,7 +89,7 @@ u32 get_cpu_id(void)
 /******************************************
  * get_cpu_family(void) - extract cpu info
  ******************************************/
-u32 get_cpu_family(void)
+__used u32 get_cpu_family(void)
 {
 	u16 hawkeye;
 	u32 cpu_family;
@@ -119,7 +119,7 @@ u32 get_cpu_family(void)
 /******************************************
  * get_cpu_rev(void) - extract version info
  ******************************************/
-u32 get_cpu_rev(void)
+__used u32 get_cpu_rev(void)
 {
 	u32 cpuid = get_cpu_id();
 
@@ -132,41 +132,12 @@ u32 get_cpu_rev(void)
 /*****************************************************************
  * get_sku_id(void) - read sku_id to get info on max clock rate
  *****************************************************************/
-u32 get_sku_id(void)
+static u32 get_sku_id(void)
 {
 	struct ctrl_id *id_base = (struct ctrl_id *)OMAP34XX_ID_L4_IO_BASE;
 	return readl(&id_base->sku_id) & SKUID_CLK_MASK;
 }
 
-/***************************************************************************
- *  get_gpmc0_base() - Return current address hardware will be
- *     fetching from. The below effectively gives what is correct, its a bit
- *   mis-leading compared to the TRM.  For the most general case the mask
- *   needs to be also taken into account this does work in practice.
- *   - for u-boot we currently map:
- *       -- 0 to nothing,
- *       -- 4 to flash
- *       -- 8 to enent
- *       -- c to wifi
- ****************************************************************************/
-u32 get_gpmc0_base(void)
-{
-	u32 b;
-
-	b = readl(&gpmc_cfg->cs[0].config7);
-	b &= 0x1F;		/* keep base [5:0] */
-	b = b << 24;		/* ret 0x0b000000 */
-	return b;
-}
-
-/*******************************************************************
- * get_gpmc0_width() - See if bus is in x8 or x16 (mainly for nand)
- *******************************************************************/
-u32 get_gpmc0_width(void)
-{
-	return WIDTH_16BIT;
-}
-
 /*************************************************************************
  * get_board_rev() - setup to pass kernel board revision information
  * returns:(bit[0-3] sub version, higher bit[7-4] is higher version)
-- 
2.32.0


             reply	other threads:[~2022-02-12 12:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-12 12:12 Adam Ford [this message]
2022-02-12 12:12 ` [PATCH 2/2] arm: omap3: Make some memory functions static and clean headers Adam Ford
2022-02-21 16:39   ` Tom Rini
2022-02-21 16:39 ` [PATCH 1/2] arm: omap3: Cleanup sys_info to fit OMAP3 booting with LTO Tom Rini

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=20220212121241.1655425-1-aford173@gmail.com \
    --to=aford173@gmail.com \
    --cc=aford@beaconembedded.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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.