From: Andre Przywara <andre.przywara@arm.com>
To: dazen@189.cn, "Jernej Škrabec" <jernej.skrabec@gmail.com>,
"Mikhail Kalashnikov" <iuncuim@gmail.com>
Cc: u-boot@lists.denx.de, jagan@amarulasolutions.com, trini@konsulko.com
Subject: Re: [PATCH] DRAM_SUN50I_H616_TRIM_SIZE
Date: Mon, 15 Apr 2024 01:22:45 +0100 [thread overview]
Message-ID: <20240415012245.75ccaa5b@minigeek.lan> (raw)
In-Reply-To: <20240413134352.46495-1-dazen@189.cn>
On Sat, 13 Apr 2024 21:43:52 +0800
dazen@189.cn wrote:
Hi,
thanks for sending a patch!
> From: lalakii <dazen@189.cn>
>
> Add "DRAM_SUN50I_H616_TRIM_SIZE" option for 1.5gb board.
>
> Signed-off-by: lalakii <dazen@189.cn>
> ---
> arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h | 1 +
> arch/arm/mach-sunxi/Kconfig | 7 +++++++
> arch/arm/mach-sunxi/dram_sun50i_h616.c | 11 ++++++++++-
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> index a8fdda124a..2d2526fead 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -166,6 +166,7 @@ struct dram_config {
> u8 rows;
> u8 ranks;
> u8 bus_full_width;
> + bool trim_size;
> };
>
> static inline int ns_to_t(int nanoseconds)
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index fe89aec6b9..255a498557 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -108,6 +108,13 @@ config DRAM_SUN50I_H616_TPR12
> default 0x0
> help
> TPR12 value from vendor DRAM settings.
> +
> +config DRAM_SUN50I_H616_TRIM_SIZE
> + bool "H616 DRAM trim size"
> + help
> + Due to unknown issue, some H616 based boards may need to trim
Well, it's not really an unknown issue, is it? The problem seems to be
that the auto detection code cannot deal with the topology of the 1.5GB
DRAM chips.
The general problem with this approach is that it would need to be
enabled at build time, which means the generated image will always trim
the DRAM size, and would not be universal for each board anymore.
So we need something to auto-detect this situation. Can you describe
the failure mode, without this patch? Does the DRAM init code hang or
give up already, or does this all pass, and then later on the board
hangs or crashes when we try access the missing DRAM area?
Maybe a small test access beyond 1.5GB would be able to check for this
particular case?
Cheers,
Andre
> + size a bit.
> +
> endif
>
> config SUN6I_PRCM
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 37c139e0ee..4598d60a57 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -1349,8 +1349,15 @@ static unsigned long mctl_calc_size(const struct dram_config *config)
> {
> u8 width = config->bus_full_width ? 4 : 2;
>
> + unsigned long size;
> +
> + size = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks;
> +
> + if (config->trim_size)
> + size = (size * 3) / (width == 4 ? 4 : 8);
> +
> /* 8 banks */
> - return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks;
> + return size;
> }
>
> static const struct dram_para para = {
> @@ -1379,6 +1386,8 @@ unsigned long sunxi_dram_init(void)
> struct sunxi_prcm_reg *const prcm =
> (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
> struct dram_config config;
> + if (IS_ENABLED(CONFIG_DRAM_SUN50I_H616_TRIM_SIZE))
> + config.trim_size = true;
> unsigned long size;
>
> setbits_le32(&prcm->res_cal_ctrl, BIT(8));
next prev parent reply other threads:[~2024-04-15 0:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-13 13:43 [PATCH] DRAM_SUN50I_H616_TRIM_SIZE dazen
2024-04-15 0:22 ` Andre Przywara [this message]
2024-04-15 21:49 ` Jernej Škrabec
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=20240415012245.75ccaa5b@minigeek.lan \
--to=andre.przywara@arm.com \
--cc=dazen@189.cn \
--cc=iuncuim@gmail.com \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox