From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] ARM: l2c: add options to overwrite prefetching behavior
Date: Fri, 29 May 2015 10:52:05 -0700 [thread overview]
Message-ID: <5568A745.7020502@gmail.com> (raw)
In-Reply-To: <1431726751-9169-1-git-send-email-hauke@hauke-m.de>
On 15/05/15 14:52, Hauke Mehrtens wrote:
> These options make it possible to overwrites the data and instruction
> prefetching behavior of the arm pl310 cache controller.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> v2: only set prefetch
> v1: set prefetch and aux
>
> Documentation/devicetree/bindings/arm/l2cc.txt | 4 ++++
> arch/arm/mm/cache-l2x0.c | 20 ++++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> index 0dbabe9..528821a 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -67,6 +67,10 @@ Optional properties:
> disable if zero.
> - arm,prefetch-offset : Override prefetch offset value. Valid values are
> 0-7, 15, 23, and 31.
> +- arm,prefetch-data : Enable data prefetch. Enabling prefetching
> + can improve performance.
I do not think the "can improve performance" has a place in a binding,
this is either not technical enough about what this does, or marketing
enough it does not buy us much.
data/instruction pre-fetching are commonly found on cache controller
these days, so I would be tempted to remove the "arm," prefixing here
since this can be generalized to other kinds of cache controllers.
Documenting that this can be either a boolean, or accept a value (see
below) could help.
> +- arm,prefetch-instr : Enable instruction prefetch. Enabling prefetching
> + can improve performance.
>
> Example:
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index e309c8f..1aa970a 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1199,6 +1199,26 @@ static void __init l2c310_of_parse(const struct device_node *np,
> pr_err("L2C-310 OF arm,prefetch-offset property value is missing\n");
> }
>
> + ret = of_property_read_u32(np, "arm,prefetch-data", &val);
> + if (ret == 0) {
> + if (val)
> + prefetch |= L310_PREFETCH_CTRL_DATA_PREFETCH;
> + else
> + prefetch &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
> + } else if (ret != -EINVAL) {
> + pr_err("L2C-310 OF arm,prefetch-data property value is missing\n");
> + }
If we want to generalize the use of this property, there could indeed be
a value associated with it, if the cache controller supports different
pre-fetching strides, however this is not the cache for these cache
controllers it seems, are not we going to show error messages more often
than desired?
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org
Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org
Subject: Re: [PATCH v3] ARM: l2c: add options to overwrite prefetching behavior
Date: Fri, 29 May 2015 10:52:05 -0700 [thread overview]
Message-ID: <5568A745.7020502@gmail.com> (raw)
In-Reply-To: <1431726751-9169-1-git-send-email-hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
On 15/05/15 14:52, Hauke Mehrtens wrote:
> These options make it possible to overwrites the data and instruction
> prefetching behavior of the arm pl310 cache controller.
>
> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
> ---
> v2: only set prefetch
> v1: set prefetch and aux
>
> Documentation/devicetree/bindings/arm/l2cc.txt | 4 ++++
> arch/arm/mm/cache-l2x0.c | 20 ++++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
> index 0dbabe9..528821a 100644
> --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> @@ -67,6 +67,10 @@ Optional properties:
> disable if zero.
> - arm,prefetch-offset : Override prefetch offset value. Valid values are
> 0-7, 15, 23, and 31.
> +- arm,prefetch-data : Enable data prefetch. Enabling prefetching
> + can improve performance.
I do not think the "can improve performance" has a place in a binding,
this is either not technical enough about what this does, or marketing
enough it does not buy us much.
data/instruction pre-fetching are commonly found on cache controller
these days, so I would be tempted to remove the "arm," prefixing here
since this can be generalized to other kinds of cache controllers.
Documenting that this can be either a boolean, or accept a value (see
below) could help.
> +- arm,prefetch-instr : Enable instruction prefetch. Enabling prefetching
> + can improve performance.
>
> Example:
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index e309c8f..1aa970a 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1199,6 +1199,26 @@ static void __init l2c310_of_parse(const struct device_node *np,
> pr_err("L2C-310 OF arm,prefetch-offset property value is missing\n");
> }
>
> + ret = of_property_read_u32(np, "arm,prefetch-data", &val);
> + if (ret == 0) {
> + if (val)
> + prefetch |= L310_PREFETCH_CTRL_DATA_PREFETCH;
> + else
> + prefetch &= ~L310_PREFETCH_CTRL_DATA_PREFETCH;
> + } else if (ret != -EINVAL) {
> + pr_err("L2C-310 OF arm,prefetch-data property value is missing\n");
> + }
If we want to generalize the use of this property, there could indeed be
a value associated with it, if the cache controller supports different
pre-fetching strides, however this is not the cache for these cache
controllers it seems, are not we going to show error messages more often
than desired?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-05-29 17:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 21:52 [PATCH v3] ARM: l2c: add options to overwrite prefetching behavior Hauke Mehrtens
2015-05-15 21:52 ` Hauke Mehrtens
2015-05-29 17:33 ` Hauke Mehrtens
2015-05-29 17:33 ` Hauke Mehrtens
2015-05-29 17:49 ` Russell King - ARM Linux
2015-05-29 17:49 ` Russell King - ARM Linux
2015-05-29 17:52 ` Florian Fainelli [this message]
2015-05-29 17:52 ` Florian Fainelli
2015-05-29 18:11 ` Hauke Mehrtens
2015-05-29 18:11 ` Hauke Mehrtens
2015-05-29 18:30 ` Florian Fainelli
2015-05-29 18:30 ` Florian Fainelli
2015-05-29 18:35 ` Florian Fainelli
2015-05-29 18:35 ` Florian Fainelli
2015-05-29 18:46 ` Hauke Mehrtens
2015-05-29 18:46 ` Hauke Mehrtens
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=5568A745.7020502@gmail.com \
--to=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.