All of lore.kernel.org
 help / color / mirror / Atom feed
From: patrick.rudolph@9elements.com
To: Julius Werner <jwerner@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Allison Randal <allison@lohutok.net>,
	Alexios Zavras <alexios.zavras@intel.com>,
	Stephen Boyd <swboyd@chromium.org>,
	Samuel Holland <samuel@sholland.org>
Subject: Re: [PATCH v3 1/2] firmware: google: Expose CBMEM over sysfs
Date: Fri, 20 Dec 2019 08:12:22 +0100	[thread overview]
Message-ID: <9158a0d87f6493977455179202cd86165437f5f6.camel@9elements.com> (raw)
In-Reply-To: <CAODwPW8Koy1BvKGJU6PKexYx+PNE+WY7+m69gcxT689vBy+AoQ@mail.gmail.com>

On Mon, 2019-12-09 at 22:54 -0800, Julius Werner wrote:
> > +static int cbmem_probe(struct coreboot_device *cdev)
> > +{
> > +       struct device *dev = &cdev->dev;
> > +       struct cb_priv *priv;
> > +       int err;
> > +
> > +       priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > +       if (!priv)
> > +               return -ENOMEM;
> > +
> > +       memcpy(&priv->entry, &cdev->cbmem_entry, sizeof(priv-
> > >entry));
> > +
> > +       priv->remap = memremap(priv->entry.address,
> > +                              priv->entry.entry_size,
> > MEMREMAP_WB);
> 
> We've just been discussing some problems with CBMEM areas and memory
> mapping types in Chrome OS. CBMEM is not guaranteed to be page-
> aligned
> (at least not the "small" entries), but the kernel can only assign
> memory attributes for a page at a time (and refuses to map the same
> area twice with two different memory types, for good reason). So if
> CBMEM entries sharing a page are mapped as writeback by one driver
> but
> uncached by the other, things break.
> 
> There are some CBMEM entries that need to be mapped uncached (e.g.
> the
> ACPI UCSI table, which isn't even handled by anything using this
> CBMEM
> code) and others for which it would make more sense (e.g. the memory
> console, where firmware may add more lines at runtime), but I don't
> think there are any regions that really *need* to be writeback. None
> of the stuff accessing these areas should access them often enough
> that caching matters, and I think it's generally more common to map
> firmware memory areas as uncached anyway. So how about we standardize
> on mapping it all uncached to avoid any attribute clashes? (That
> would
> mean changing the existing VPD and memconsole drivers to use
> ioremap(), too.)

I wasn't aware that CBMEM is used for DMA as there's no such concept in
coreboot yet. For me it looks like the UCSI is regular DRAM mapped as
WB accessed by the ACPI interpreter.
I'll prepare a new patch-set using ioremap in all drivers that access
CBMEM.


  parent reply	other threads:[~2019-12-20  7:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28 12:50 [PATCH v3 0/2] firmware: google: Expose coreboot tables and CBMEM patrick.rudolph
2019-11-28 12:50 ` [PATCH v3 1/2] firmware: google: Expose CBMEM over sysfs patrick.rudolph
2019-12-10  6:54   ` Julius Werner
     [not found]     ` <CAOxpaSXUgNXaZ40ScZKZQ+iDEQ=vqPytLgicBx==hxp5uL_+dA@mail.gmail.com>
2019-12-13 21:31       ` Mat King
2019-12-17  7:02         ` Stephen Boyd
2019-12-17 20:16           ` Mat King
2019-12-18  9:47             ` Heikki Krogerus
2019-12-18 23:35               ` Mat King
2019-12-19 12:03                 ` Heikki Krogerus
2019-12-20  7:12     ` patrick.rudolph [this message]
2020-01-22 18:15       ` Stephen Boyd
2019-12-17  7:38   ` Stephen Boyd
2019-12-20  7:20     ` patrick.rudolph
2019-12-19 17:17   ` Greg Kroah-Hartman
2019-11-28 12:50 ` [PATCH v3 2/2] firmware: google: Expose coreboot tables " patrick.rudolph
2019-12-17  7:19   ` Stephen Boyd

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=9158a0d87f6493977455179202cd86165437f5f6.camel@9elements.com \
    --to=patrick.rudolph@9elements.com \
    --cc=alexios.zavras@intel.com \
    --cc=allison@lohutok.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samuel@sholland.org \
    --cc=swboyd@chromium.org \
    --cc=tglx@linutronix.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.