All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Stanley <joel@jms.id.au>
To: Patrick Williams <patrick@stwcx.xyz>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	 Jeremy Kerr <jk@ozlabs.org>
Cc: Cyril Bur <cyrilbur@gmail.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: [PATCH] ARM: dts: aspeed: Update reserved memory nodes for zaius and witherspoon
Date: Tue, 21 Feb 2017 15:15:34 +1030	[thread overview]
Message-ID: <CACPK8XdiK4p_YkQJdroQjDtAgf89uO0dOtnMF8N2g8OspEFacw@mail.gmail.com> (raw)
In-Reply-To: <20170221041653.GA21380@heinlein.lan>

On Tue, Feb 21, 2017 at 2:46 PM, Patrick Williams <patrick@stwcx.xyz> wrote:
> On Fri, Feb 17, 2017 at 01:48:41PM +1100, Cyril Bur wrote:
>> On Thu, 2017-02-16 at 08:05 -0600, Patrick Williams wrote:
>> > On Thu, Feb 16, 2017 at 04:49:22PM +1100, Cyril Bur wrote:
>> > > -         flash_memory: region@94000000 {
>> > > +         flash_memory: region@98000000 {
>> > >                   no-map;
>> > > -                 reg = <0x94000000 0x04000000>; /* 64M */
>> > > +                 reg = <0x98000000 0x04000000>; /* 64M */
>> > > +         };
>> > > +
>> > > +         vga_memory: framebuffer@9c000000 {
>> > > +                 no-map;
>> > > +                 reg = <0x9c000000 0x04000000>; /* 64MB */
>> >
>> > Do we really have to allocate 64MB to a VGA framebuffer?  We can store a
>> > 4K resolution monitor with 32bit color in 32MB, so why is it required to
>> > reserve this much memory?  Between this and the PNOR memory region, now
>> > 1/4th of the BMCs memory is reserved.
>>
>> The reservation of 64MB is because the hardware is capable of using
>> 64MB, therefore the host can use that region of memory. We're playing
>> it safe here by ensuring the BMC doesn't use any of it to avoid any
>> possibility of the host corrupting BMC memory. This is the most generic
>> dts for the platform so we've gone with stability over performance.
>
> Is there anything the BMC can do to restrict how big of a memory map the
> host side of the VGA can open up?  If there isn't we're going to have to
> allocate this much on all systems because we can't trust the host to
> "behave".

Ben and Jeremy have been enhancing the host driver to be smarter. Ben,
what's the state of play?

Cheers,

Joel

  reply	other threads:[~2017-02-21  4:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16  5:49 [PATCH] ARM: dts: aspeed: Update reserved memory nodes for zaius and witherspoon Cyril Bur
2017-02-16  6:14 ` Mine
2017-02-17  2:51   ` Cyril Bur
2017-02-17  2:56     ` Cyril Bur
2017-02-16 14:05 ` Patrick Williams
2017-02-17  2:48   ` Cyril Bur
2017-02-21  4:16     ` Patrick Williams
2017-02-21  4:45       ` Joel Stanley [this message]
2017-02-21  5:13         ` Benjamin Herrenschmidt

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=CACPK8XdiK4p_YkQJdroQjDtAgf89uO0dOtnMF8N2g8OspEFacw@mail.gmail.com \
    --to=joel@jms.id.au \
    --cc=benh@kernel.crashing.org \
    --cc=cyrilbur@gmail.com \
    --cc=jk@ozlabs.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    /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.