All of lore.kernel.org
 help / color / mirror / Atom feed
From: Weijie Gao <weijie.gao@mediatek.com>
To: David Lechner <dlechner@baylibre.com>, <rmandrad@gmail.com>
Cc: <u-boot@lists.denx.de>, <trini@konsulko.com>,
	<ryder.lee@mediatek.com>, <chunfeng.yun@mediatek.com>,
	<igor.belwon@mentallysanemainliners.org>, <jstephan@baylibre.com>,
	<GSS_MTK_Uboot_upstream@mediatek.com>,
	<emanuele.ghidoli@toradex.com>
Subject: Re: [PATCH] arm: mediatek: mt7988: restore full DRAM bank reporting
Date: Wed, 10 Jun 2026 09:05:39 +0800	[thread overview]
Message-ID: <ccec2dffffeecfc4597f100ba41ea002ba2bbe62.camel@mediatek.com> (raw)
In-Reply-To: <CAMknhBFHpn3ZQSdvNABfSqumk8PqUU6BBxSErN8fpaQ=HT29Kg@mail.gmail.com>

On Fri, 2026-06-05 at 17:00 +0200, David Lechner wrote:
> > On Fri, Jun 5, 2026 at 4:30 PM David Lechner <dlechner@baylibre.com
> > > wrote:
> > > 
> > > On Fri, Jun 5, 2026 at 3:07 PM <rmandrad@gmail.com> wrote:
> > > > > On Tue, Jun 2, 2026 at 6:24 PM Rudy Andram <
> > > > > rmandrad@gmail.com> wrote:
> > > > > > 
> > > > > > MT7988 detects the full installed DRAM in dram_init(), but
> > > > > > after
> > > > > > commit bddd6bbef3dc ("arm: mediatek: mt7988: drop
> > > > > > dram_init_banksize()") it fell back to the generic
> > > > > > dram_init_banksize() implementation.
> > > > > > 
> > > > > > That generic path populates bd->bi_dram[0].size with
> > > > > > get_effective_memsize(), which is capped by
> > > > > > CFG_MAX_MEM_MAPPED.
> > > > > > On
> > > > > > MT7988 this limits the exported DRAM bank to 3 GiB even
> > > > > > when 8
> > > > > > GiB is installed.
> > > > > 
> > > > > Can we just remove the #define CFG_MAX_MEM_MAPPED (and the
> > > > > header file that contains it)? Or is it used somewhere else?
> > > > > 
> > > > 
> > > > Not the header file as   TARGET_MT7988 sets
> > > > SYS_CONFIG_NAME="mt7988" in arch/arm/mach-mediatek/Kconfig
> > > 
> > > We could drop that config too since the header will be empty.
> > > 
> > > > 
> > > > In the mt7988 I don't see CFG_MAX_MEM_MAPPED used elsewhere
> > > > than
> > > > just in common/memsize.c where it limits
> > > > get_effective_memsize()
> > > > 
> > > > Unsetting/removing CFG_MAX_MEM_MAPPED would take u-boot above
> > > > 4gb...
> > > > Some MediaTek ARM64 ports may keep U-Boot below 4 GiB because
> > > > peripherals such as MMC need DMA buffers below 4 GiB ... so, it
> > > > may
> > > > work on my setup but not others. Also, not an expert on u-
> > > > boot  I
> > > > would suggest for others to comment/review
> > > > 
> > > 
> > > What I've done on the other MediaTek platforms for now is add
> > > this to
> > > init.c to take care of the 4GB DMA limit.
> > > 
> > > phys_size_t get_effective_memsize(void) {
> > >        /*
> > >         * Limit gd->ram_top not exceeding SZ_4G. Because some
> > > peripherals like
> > >         * MMC requires DMA buffer allocated below SZ_4G.
> > >         */
> > >         return min(SZ_4G - gd->ram_base, gd->ram_size); }
> > 
> > Meh... I've just realized that this probably doesn't fix the issue
> > as it does basically the same thing as CFG_MAX_MEM_MAPPED. I will
> > have to come back to this next week when I have more time.
> > 
> > > 
> > > There has been some ongoing discussion of a better way to handle
> > > this
> > > in general though, the last few weeks. I need to check the
> > > mailing
> > > list to see if any progress was made since then.
> > > 
> > > If there isn't something yet, I would still propose to drop
> > > CFG_MAX_MEM_MAPPED and add this function so that everything is
> > > the
> > > same.
> 
> 
> 
> On Fri, Jun 5, 2026 at 4:53 PM <rmandrad@gmail.com> wrote:
> > 
> > Was just about to reply on that... happy to drop this patch and let
> > you work on a solution just thought to report my findings but would
> > suggest in the meantime to revert
> > bddd6bbef3dc ("arm: mediatek: mt7988: drop dram_init_banksize()")
> 
> I just saw [1] that has a new config option to address the DMA
> address
> limit and [2] that renames the config option. [1] has already been
> applied to master, so perhaps we could still drop CFG_MAX_MEM_MAPPED
> and use this new option instead? Otherwise, yes, I will consider the
> revert.

The NETSYS DMA of all filogic platform chips can only use DRAM below
4GiB and that's why we added CFG_MAX_MEM_MAPPED to limit the usable
memory in U-Boot.

> 
> [1]: 
> https://lore.kernel.org/u-boot/20260603141814.12672-1-marek.vasut+renesas@mailbox.org/
>  
> [2]: 
> https://lore.kernel.org/u-boot/20260604173330.8586-1-marek.vasut+renesas@mailbox.org/
>  


  reply	other threads:[~2026-06-10  1:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-02 16:22 [PATCH] arm: mediatek: mt7988: restore full DRAM bank reporting Rudy Andram
2026-06-05 12:51 ` David Lechner
2026-06-05 13:08   ` rmandrad
2026-06-05 14:30     ` David Lechner
2026-06-05 14:48       ` David Lechner
2026-06-05 14:54         ` rmandrad
2026-06-05 15:00           ` David Lechner
2026-06-10  1:05             ` Weijie Gao [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-05-30  5:37 Rudy Andram
2026-05-30  5:24 Rudy Andram

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=ccec2dffffeecfc4597f100ba41ea002ba2bbe62.camel@mediatek.com \
    --to=weijie.gao@mediatek.com \
    --cc=GSS_MTK_Uboot_upstream@mediatek.com \
    --cc=chunfeng.yun@mediatek.com \
    --cc=dlechner@baylibre.com \
    --cc=emanuele.ghidoli@toradex.com \
    --cc=igor.belwon@mentallysanemainliners.org \
    --cc=jstephan@baylibre.com \
    --cc=rmandrad@gmail.com \
    --cc=ryder.lee@mediatek.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.