All of lore.kernel.org
 help / color / mirror / Atom feed
From: <rmandrad@gmail.com>
To: "'David Lechner'" <dlechner@baylibre.com>
Cc: <u-boot@lists.denx.de>, <trini@konsulko.com>,
	<ryder.lee@mediatek.com>, <weijie.gao@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: Fri, 5 Jun 2026 15:54:37 +0100	[thread overview]
Message-ID: <000a01dcf4fb$3ba10810$b2e31830$@gmail.com> (raw)
In-Reply-To: <CAMknhBGng1iVxs7+5cWPaAyjOxBs8Dbzp3fuHhHWHbi3eJs3fw@mail.gmail.com>

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()")

-----Original Message-----
From: David Lechner <dlechner@baylibre.com> 
Sent: 05 June 2026 15:48
To: rmandrad@gmail.com
Cc: u-boot@lists.denx.de; trini@konsulko.com; ryder.lee@mediatek.com; weijie.gao@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

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.


  reply	other threads:[~2026-06-05 14:54 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 [this message]
2026-06-05 15:00           ` David Lechner
2026-06-10  1:05             ` Weijie Gao
  -- 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='000a01dcf4fb$3ba10810$b2e31830$@gmail.com' \
    --to=rmandrad@gmail.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=ryder.lee@mediatek.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=weijie.gao@mediatek.com \
    /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.