From: Vincent Whitchurch <vincent.whitchurch@axis.com> To: <vigneshr@ti.com>, <richard@nod.at>, <miquel.raynal@bootlin.com>, <joern@lazybastard.org> Cc: <kernel@axis.com>, Vincent Whitchurch <vincent.whitchurch@axis.com>, <linux-mtd@lists.infradead.org>, <devicetree@vger.kernel.org>, <robh+dt@kernel.org>, <krzk+dt@kernel.org>, <frowand.list@gmail.com>, <linux-kernel@vger.kernel.org> Subject: [PATCH v3 4/4] mtd: phram: Allow cached mappings Date: Tue, 12 Apr 2022 15:53:02 +0200 [thread overview] Message-ID: <20220412135302.1682890-5-vincent.whitchurch@axis.com> (raw) In-Reply-To: <20220412135302.1682890-1-vincent.whitchurch@axis.com> Currently phram always uses ioremap(), but this is unnecessary when normal memory is used. If the reserved-memory node does not specify the no-map property, indicating it should be mapped as system RAM and ioremap() cannot be used on it, use a cached mapping using memremap(MEMREMAP_WB) instead. On one of my systems this improves read performance by ~70%. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> --- drivers/mtd/devices/phram.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c index 506e9edf5c85..89d74a1eff4f 100644 --- a/drivers/mtd/devices/phram.c +++ b/drivers/mtd/devices/phram.c @@ -34,6 +34,7 @@ struct phram_mtd_list { struct mtd_info mtd; struct list_head list; + bool cached; }; static LIST_HEAD(phram_list); @@ -96,6 +97,7 @@ static int register_device(struct platform_device *pdev, const char *name, phys_addr_t start, size_t len, uint32_t erasesize) { struct device_node *np = pdev ? pdev->dev.of_node : NULL; + bool cached = np ? !of_property_read_bool(np, "no-map") : false; struct phram_mtd_list *new; int ret = -ENOMEM; @@ -103,8 +105,13 @@ static int register_device(struct platform_device *pdev, const char *name, if (!new) goto out0; + new->cached = cached; + ret = -EIO; - new->mtd.priv = ioremap(start, len); + if (cached) + new->mtd.priv = memremap(start, len, MEMREMAP_WB); + else + new->mtd.priv = ioremap(start, len); if (!new->mtd.priv) { pr_err("ioremap failed\n"); goto out1; @@ -140,7 +147,7 @@ static int register_device(struct platform_device *pdev, const char *name, return 0; out2: - iounmap(new->mtd.priv); + cached ? memunmap(new->mtd.priv) : iounmap(new->mtd.priv); out1: kfree(new); out0: @@ -362,7 +369,7 @@ static int phram_remove(struct platform_device *pdev) struct phram_mtd_list *phram = platform_get_drvdata(pdev); mtd_device_unregister(&phram->mtd); - iounmap(phram->mtd.priv); + phram->cached ? memunmap(phram->mtd.priv) : iounmap(phram->mtd.priv); kfree(phram); return 0; -- 2.34.1
WARNING: multiple messages have this Message-ID (diff)
From: Vincent Whitchurch <vincent.whitchurch@axis.com> To: <vigneshr@ti.com>, <richard@nod.at>, <miquel.raynal@bootlin.com>, <joern@lazybastard.org> Cc: <kernel@axis.com>, Vincent Whitchurch <vincent.whitchurch@axis.com>, <linux-mtd@lists.infradead.org>, <devicetree@vger.kernel.org>, <robh+dt@kernel.org>, <krzk+dt@kernel.org>, <frowand.list@gmail.com>, <linux-kernel@vger.kernel.org> Subject: [PATCH v3 4/4] mtd: phram: Allow cached mappings Date: Tue, 12 Apr 2022 15:53:02 +0200 [thread overview] Message-ID: <20220412135302.1682890-5-vincent.whitchurch@axis.com> (raw) In-Reply-To: <20220412135302.1682890-1-vincent.whitchurch@axis.com> Currently phram always uses ioremap(), but this is unnecessary when normal memory is used. If the reserved-memory node does not specify the no-map property, indicating it should be mapped as system RAM and ioremap() cannot be used on it, use a cached mapping using memremap(MEMREMAP_WB) instead. On one of my systems this improves read performance by ~70%. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> --- drivers/mtd/devices/phram.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c index 506e9edf5c85..89d74a1eff4f 100644 --- a/drivers/mtd/devices/phram.c +++ b/drivers/mtd/devices/phram.c @@ -34,6 +34,7 @@ struct phram_mtd_list { struct mtd_info mtd; struct list_head list; + bool cached; }; static LIST_HEAD(phram_list); @@ -96,6 +97,7 @@ static int register_device(struct platform_device *pdev, const char *name, phys_addr_t start, size_t len, uint32_t erasesize) { struct device_node *np = pdev ? pdev->dev.of_node : NULL; + bool cached = np ? !of_property_read_bool(np, "no-map") : false; struct phram_mtd_list *new; int ret = -ENOMEM; @@ -103,8 +105,13 @@ static int register_device(struct platform_device *pdev, const char *name, if (!new) goto out0; + new->cached = cached; + ret = -EIO; - new->mtd.priv = ioremap(start, len); + if (cached) + new->mtd.priv = memremap(start, len, MEMREMAP_WB); + else + new->mtd.priv = ioremap(start, len); if (!new->mtd.priv) { pr_err("ioremap failed\n"); goto out1; @@ -140,7 +147,7 @@ static int register_device(struct platform_device *pdev, const char *name, return 0; out2: - iounmap(new->mtd.priv); + cached ? memunmap(new->mtd.priv) : iounmap(new->mtd.priv); out1: kfree(new); out0: @@ -362,7 +369,7 @@ static int phram_remove(struct platform_device *pdev) struct phram_mtd_list *phram = platform_get_drvdata(pdev); mtd_device_unregister(&phram->mtd); - iounmap(phram->mtd.priv); + phram->cached ? memunmap(phram->mtd.priv) : iounmap(phram->mtd.priv); kfree(phram); return 0; -- 2.34.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-04-12 13:53 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-12 13:52 [PATCH v3 0/4] mtd: phram improvements Vincent Whitchurch 2022-04-12 13:52 ` Vincent Whitchurch 2022-04-12 13:52 ` [PATCH v3 1/4] mtd: core: Check devicetree alias for index Vincent Whitchurch 2022-04-12 13:52 ` Vincent Whitchurch 2022-04-21 7:36 ` Miquel Raynal 2022-04-21 7:36 ` Miquel Raynal 2022-04-12 13:53 ` [PATCH v3 2/4] dt-bindings: reserved-memory: Support MTD/block device Vincent Whitchurch 2022-04-12 13:53 ` Vincent Whitchurch 2022-04-14 16:00 ` Rob Herring 2022-04-14 16:00 ` Rob Herring 2022-04-21 7:36 ` Miquel Raynal 2022-04-21 7:36 ` Miquel Raynal 2022-04-12 13:53 ` [PATCH v3 3/4] mtd: phram: Allow probing via reserved-memory Vincent Whitchurch 2022-04-12 13:53 ` Vincent Whitchurch 2022-04-14 16:02 ` Rob Herring 2022-04-14 16:02 ` Rob Herring 2022-04-21 7:36 ` Miquel Raynal 2022-04-21 7:36 ` Miquel Raynal 2022-04-12 13:53 ` Vincent Whitchurch [this message] 2022-04-12 13:53 ` [PATCH v3 4/4] mtd: phram: Allow cached mappings Vincent Whitchurch 2022-04-13 6:45 ` kernel test robot 2022-04-13 6:45 ` kernel test robot 2022-04-14 9:04 ` Vincent Whitchurch 2022-04-14 9:04 ` Vincent Whitchurch 2022-04-14 9:04 ` Vincent Whitchurch 2022-04-25 8:28 ` Miquel Raynal 2022-04-25 8:28 ` Miquel Raynal 2022-04-25 8:28 ` Miquel Raynal 2022-04-25 8:30 ` Miquel Raynal 2022-04-25 8:30 ` Miquel Raynal 2022-04-25 8:30 ` Miquel Raynal 2022-05-10 15:26 ` Vincent Whitchurch 2022-05-10 15:26 ` Vincent Whitchurch 2022-05-10 15:26 ` Vincent Whitchurch 2022-04-21 7:35 ` Miquel Raynal 2022-04-21 7:35 ` Miquel Raynal
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=20220412135302.1682890-5-vincent.whitchurch@axis.com \ --to=vincent.whitchurch@axis.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=joern@lazybastard.org \ --cc=kernel@axis.com \ --cc=krzk+dt@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=miquel.raynal@bootlin.com \ --cc=richard@nod.at \ --cc=robh+dt@kernel.org \ --cc=vigneshr@ti.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: linkBe 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.