* [PATCH] ahci: qoriq: added ls2088a platforms support
From: Tejun Heo @ 2017-01-18 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484633521-10938-1-git-send-email-yuantian.tang@nxp.com>
On Tue, Jan 17, 2017 at 02:12:01PM +0800, yuantian.tang at nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Ls2088a is new introduced arm-based soc with sata support with
> following features:
> 1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
> specification
> 2. Contains a high-speed descriptor-based DMA controller
> 3. Supports the following:
> a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
> (second-generation SATA), and 6 Gb/s (third-generation SATA)
> b. FIS-based switching
> c. Native command queuing (NCQ) commands
> d. Port multiplier operation
> e. Asynchronous notification
> f. SATA BIST mode
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
Applied to libata/for-4.11.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v2] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Tejun Heo @ 2017-01-18 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFd313wajZzZWGQy20obf4k_7RO43Q10NiBa-8TVYxo3J93inA@mail.gmail.com>
Hello,
On Tue, Jan 17, 2017 at 08:25:21PM +0530, Rameshwar Sahu wrote:
> Hi Tejun,
>
> On Fri, Nov 18, 2016 at 3:15 PM, Rameshwar Prasad Sahu <rsahu@apm.com> wrote:
> > This patch enables NCQ support for APM X-Gene SATA controller hardware v1.1
> > that was broken with hardware v1.0. Second thing, here we should not assume
> > XGENE_AHCI_V2 always in case of having valid _CID in ACPI table. I need to
> > remove this assumption because V1_1 also has a valid _CID for backward
> > compatibly with v1.
> >
> > v2 changes:
> > 1. Changed patch description
> >
> > Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
Hmm... I don't have the patch in my queue. Can you please resend it?
Thanks.
--
tejun
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Kevin Hilman @ 2017-01-18 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202234739.22929-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
> networks which are not affected by the EEE problem, as reported here:
Based on the discussions with Jerome, I'm dropping this series from the
v4.11/dt64 branch for now.
This series also had a small conflict with Jerome's fix[1] for the
odroid-c2, so please rebase any updates here on my v4.10/fixes branch.
Kevin
[1] https://git.kernel.org/cgit/linux/kernel/git/khilman/linux-amlogic.git/commit/?h=v4.10/fixes
^ permalink raw reply
* [PATCH 0/5] meson-gx: reset RGMII PHYs and configure TX delay
From: Martin Blumenstingl @ 2017-01-18 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2a8ao1833.fsf@baylibre.com>
Kevin,
On Wed, Jan 18, 2017 at 8:28 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
>> This partially fixes the 1000Mbit/s ethernet TX throughput issues (on
>> networks which are not affected by the EEE problem, as reported here:
>
> Based on the discussions with Jerome, I'm dropping this series from the
> v4.11/dt64 branch for now.
what is you opinion on having the MDIO node in meson-gx (and keeping
GXBB and GXL/GXM consistent) vs not having PHY autodetection for GXBB
(= not having the MDIO in meson-gx)?
I cannot send a v2 until we have a decision for this
> This series also had a small conflict with Jerome's fix[1] for the
> odroid-c2, so please rebase any updates here on my v4.10/fixes branch.
will keep that in mind, noted.
^ permalink raw reply
* [PATCH V10 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Andy Shevchenko @ 2017-01-18 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484766276-9668-1-git-send-email-agustinv@codeaurora.org>
On Wed, Jan 18, 2017 at 9:04 PM, Agustin Vega-Frias
<agustinv@codeaurora.org> wrote:
> ACPI extended IRQ resources may contain a ResourceSource to specify
> an alternate interrupt controller. Introduce acpi_irq_get and use it
> to implement ResourceSource/IRQ domain mapping.
>
> The new API is similar to of_irq_get and allows re-initialization
> of a platform resource from the ACPI extended IRQ resource, and
> provides proper behavior for probe deferral when the domain is not
> yet present when called.
Thanks, looks better now.
> /**
> + * acpi_get_irq_source_fwhandle() - Retrieve the fwhandle of the given
> + * acpi_resource_source which is used
> + * as an IRQ domain id
Please, make short description here and put long one below
> + * @source: acpi_resource_source to use for the lookup
> + *
* Description:
* ...
*
> + * Returns: The appropriate IRQ fwhandle domain id
> + * NULL on failure
* Return:
* blablabla
> + */
> +static struct fwnode_handle *
> +acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source)
> +{
> + struct fwnode_handle *result;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> +
> + if (!source->string_length)
> + return acpi_gsi_domain_id;
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status)) {
> + pr_warn("Could not find handle for %s\n", source->string_ptr);
> + return NULL;
> + }
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device) {
> + pr_warn("Could not get device for %s\n", source->string_ptr);
I'm not sure both messages have a value.
> + return NULL;
> + }
> +/**
You mark as kernel doc, but in fact it's just a comment.
> + * Context for the resource walk used to lookup IRQ resources.
> + */
> +struct acpi_irq_parse_one_ctx {
> + int rc;
> + unsigned int index;
> + unsigned long *res_flags;
> + struct irq_fwspec *fwspec;
> +};
> +
> +/**
> + * acpi_irq_parse_one_match - Handle a matching IRQ resource
This looks better, but lacks of parameter descriptions.
> + */
> +/**
> + * acpi_irq_parse_one_cb - Handle the given resource
> + * @ares: resource to handle
> + * @context: context for the walk, contains the lookup index and references
> + * to the flags and fwspec where the result is returned
Make it shorter, ideally into one line
> + *
* Description:
> + * This is called by acpi_walk_resources passing each resource returned by
> + * the _CRS method. We only inspect IRQ resources. Since IRQ resources
> + * might contain multiple interrupts we check if the index is within this
> + * one's interrupt array, otherwise we subtract the current resource IRQ
> + * count from the lookup index to prepare for the next resource.
> + * Once a match is found we call acpi_irq_parse_one_match to populate
> + * the result and end the walk by returning AE_CTRL_TERMINATE.
> + *
> + * Return AE_OK if the walk should continue, AE_CTRL_TERMINATE if a matching
* Return:
* blablabla
> + * IRQ resource was found.
> + */
> +/**
> + * acpi_irq_parse_one - Resolve an interrupt for a device
> + * @handle: the device whose interrupt is to be resolved
> + * @index: index of the interrupt to resolve
> + * @fwspec: structure irq_fwspec filled by this function
> + * @flags: resource flags filled by this function
> + *
> + * This function resolves an interrupt for a device by walking its CRS resources
> + * to find the appropriate ACPI IRQ resource and populating the given structure
> + * which can be used to retrieve a Linux IRQ number.
> + *
> + * Returns the result stored in ctx.rc by the callback, or -EINVAL if the given
> + * index is out of range.
Ditto for Description and Return.
> + */
> +static int acpi_irq_parse_one(acpi_handle handle, unsigned int index,
> + struct irq_fwspec *fwspec, unsigned long *flags)
> +{
> + struct acpi_irq_parse_one_ctx ctx = { -EINVAL, index, flags, fwspec };
> + acpi_status status;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_irq_parse_one_cb, &ctx);
> + if (ACPI_FAILURE(status))
> + return -EINVAL;
Shouldn't you have the same in rc? Would be redundant.
> + return ctx.rc;
> +}
> +
> +/**
> + * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
> + * use it to initialize the given Linux IRQ resource.
> + * @handle ACPI device handle
> + * @index ACPI IRQ resource index to lookup
> + * @res Linux IRQ resource to initialize
Ah, you missed colons after field names:
* @field1:
> + *
> + * Return:
Next line: 0 on success
> + * -EINVAL if an error occurs
> + * -EPROBE_DEFER if the IRQ lookup/conversion failed
> + */
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> +{
> + int rc;
Put this last in the definition block.
> + struct irq_fwspec fwspec;
> + struct irq_domain *domain;
> + unsigned long flags;
> +
> + rc = acpi_irq_parse_one(handle, index, &fwspec, &flags);
> + if (rc)
> + return rc;
> +
> + domain = irq_find_matching_fwnode(fwspec.fwnode, DOMAIN_BUS_ANY);
> + if (!domain)
> + return -EPROBE_DEFER;
Hmm... Could it be other issues here?
> +
> + rc = irq_create_fwspec_mapping(&fwspec);
> + if (rc <= 0)
> + return -EINVAL;
> +
> + res->start = rc;
> + res->end = rc;
> + res->flags = flags;
Perhaps struct resource *r should be a parameter to acpi_irq_parse_one().
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_get);
> +
> +/**
> * acpi_set_irq_model - Setup the GSI irqdomain information
> * @model: the value assigned to acpi_irq_model
> * @fwnode: the irq_domain identifier for mapping and looking up
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..61423d2 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> }
>
> r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> + if (r && r->flags & IORESOURCE_DISABLED && ACPI_COMPANION(&dev->dev)) {
has_acpi_companion() ?
> + int ret;
> +
> + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> + if (ret)
> + return ret;
> + }
> @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
> memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
> }
> }
> -
It doesn't belong here.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] ahci: qoriq: added ls2088a platforms support
From: Tejun Heo @ 2017-01-18 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484633521-10938-1-git-send-email-yuantian.tang@nxp.com>
On Tue, Jan 17, 2017 at 02:12:01PM +0800, yuantian.tang at nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Ls2088a is new introduced arm-based soc with sata support with
> following features:
> 1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
> specification
> 2. Contains a high-speed descriptor-based DMA controller
> 3. Supports the following:
> a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
> (second-generation SATA), and 6 Gb/s (third-generation SATA)
> b. FIS-based switching
> c. Native command queuing (NCQ) commands
> d. Port multiplier operation
> e. Asynchronous notification
> f. SATA BIST mode
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
Reverted due to build failure. Did you even try to compile it before
submission? We all make mistakes and that's fine but this one seems a
bit too careless. Please don't do this.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Kevin Hilman @ 2017-01-18 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de>
Andreas F?rber <afaerber@suse.de> writes:
> Hi Neil,
>
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
>> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
>
> Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
> intended, but at the same time it ignored any lowered or heightened
> upper limit coming from the bootloader side.
>
> As a rule of thumb, any nodes that have device_type set can be expected
> to be modified during boot.
>
>> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
>> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
>> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>>
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones,
>
> Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
>
>> but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>
> I'll happily test once HDMI is ready. :)
>
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
>
> Confirming no issues on three runs on meson-gxm-rbox-pro:
>
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info: [2528] dispatching hogs: 4 vm
> stress-ng: info: [2528] cache allocate: default cache size: 256K
> stress-ng: info: [2528] successful run completed in 10.07s
>
> [1]+ Done stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info: [2537] dispatching hogs: 4 vm
> stress-ng: info: [2537] cache allocate: default cache size: 256K
> stress-ng: info: [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info: [2546] dispatching hogs: 4 vm
> stress-ng: info: [2546] cache allocate: default cache size: 256K
> stress-ng: info: [2546] successful run completed in 10.07s
> boxer:~ #
>
>> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
>> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>>
>> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
>> fixup for a future DTS cleanup.
>>
>> Andreas, is this ok for you ?
>
> Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
>
> Kevin, I noticed that this supposedly applied patch did not show up in
> linux-next for testing - could you merge your fixes branch into for-next
> please for those of us working on new stuff?
Any fixes I have queued are always in my for-mext branch (which is
included i linux-next.)
This fix was there as well, but was removed due to objections shortly
after I added it, so it never quite made it to linux-next (or may have
for one day, I'm not sure.)
Kevin
^ permalink raw reply
* [PATCH] ARM: smp: Remove CPU: shutdown notice
From: Florian Fainelli @ 2017-01-18 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118095523.GK20462@pathway.suse.cz>
On 01/18/2017 01:55 AM, Petr Mladek wrote:
> On Tue 2017-01-17 15:39:45, Florian Fainelli wrote:
>> On 01/17/2017 03:23 PM, Russell King - ARM Linux wrote:
>>> On Tue, Jan 17, 2017 at 03:07:12PM -0800, Florian Fainelli wrote:
>>>> This message is not particularly informative, and is not paired with an
>>>> identical message when a CPU is brought online. Finally, it slows the
>>>> CPU hotplug path down, thus allowing less CPU hotplug operations per
>>>> second. Just remove it.
>>>
>>> CPU hotplug isn't a fast operation anyway - it's also fairly disruptive
>>> in that it uses stop_machine() to halt activity everywhere while taking
>>> the CPU offline.
>>
>> We have a test that consists in shutting down all CPUs as frequently as
>> we can and do this for about 2 million iterations which takes roughly
>> 24h, and this printk slows thing down by a reasonable amount. Here are
>> some numbers on 500 hotplug operations:
>>
>> w/ printk:
>> real 0m9.997s
>> user 0m0.725s
>> sys 0m3.030s
>> #
>>
>> w/o printk:
>> real 0m8.547s
>> user 0m0.436s
>> sys 0m1.838s
>
> I am curious that a single printk() might make such a big difference.
It does, because of how printk() is implemented (there is nothing wrong
with it, just slow by nature and how the UART gets written to as well).
>
> One reason might be that the messages are pushed to a "slow" console.
115200 UART, yes that's slow, but not unusual.
>
> Another reason might be that there are many other messages printed
> on the system and there is a contention on logbuf_lock or other
> console related locks.
The other messages being printed are those from the hotplug script that
I run which just checkpoints its running every 50 instances, so it does
not occur that often, the console really is not busy, which really
extracts the overhead of printing "CPU: shutdown".
>
> There might be also the opposite problem. The messages are also read
> by userspace tools that store them into /var/log/messages or systemd
> logs. If these are the only messages printed to the log and if there
> is no other activity on the system. Then the waken loggers might make
> a difference, especially if all CPUs are getting disabled and only
> one is available at some point.
There is none of that, no systemd, no syslog, just minimal userspace
running.
>
> Well, I am not sure what other operations are needed to do the
> CPU hotplug operation.
>
> I cannot judge how the message is useful and if the speed up
> is worth removing it.
>
> Best Regards,
> Petr
>
--
Florian
^ permalink raw reply
* [PATCH v13 2/5] tee: generic TEE subsystem
From: Arnd Bergmann @ 2017-01-18 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479480700-554-3-git-send-email-jens.wiklander@linaro.org>
On Friday, November 18, 2016 3:51:37 PM CET Jens Wiklander wrote:
> Initial patch for generic TEE subsystem.
> This subsystem provides:
> * Registration/un-registration of TEE drivers.
> * Shared memory between normal world and secure world.
> * Ioctl interface for interaction with user space.
> * Sysfs implementation_id of TEE driver
>
> A TEE (Trusted Execution Environment) driver is a driver that interfaces
> with a trusted OS running in some secure environment, for example,
> TrustZone on ARM cpus, or a separate secure co-processor etc.
>
> The TEE subsystem can serve a TEE driver for a Global Platform compliant
> TEE, but it's not limited to only Global Platform TEEs.
>
> This patch builds on other similar implementations trying to solve
> the same problem:
> * "optee_linuxdriver" by among others
> Jean-michel DELORME<jean-michel.delorme@st.com> and
> Emmanuel MICHEL <emmanuel.michel@st.com>
> * "Generic TrustZone Driver" by Javier Gonz?lez <javier@javigon.com>
Can you give an example for a system that would contain more than one
TEE? I see that you support dynamic registration, and it's clear that
there can be more than one type of TEE, but why would one have more
than one at a time, and why not more than 32?
> +static int tee_ioctl_invoke(struct tee_context *ctx,
> + struct tee_ioctl_buf_data __user *ubuf)
> +{
> + int rc;
> + size_t n;
> + struct tee_ioctl_buf_data buf;
> + struct tee_ioctl_invoke_arg __user *uarg;
> + struct tee_ioctl_invoke_arg arg;
> + struct tee_ioctl_param __user *uparams = NULL;
> + struct tee_param *params = NULL;
> +
> + if (!ctx->teedev->desc->ops->invoke_func)
> + return -EINVAL;
> +
> + if (copy_from_user(&buf, ubuf, sizeof(buf)))
> + return -EFAULT;
> +
> + if (buf.buf_len > TEE_MAX_ARG_SIZE ||
> + buf.buf_len < sizeof(struct tee_ioctl_invoke_arg))
> + return -EINVAL;
> +
> + uarg = (struct tee_ioctl_invoke_arg __user *)(unsigned long)buf.buf_ptr;
u64_to_user_ptr()
> + if (copy_from_user(&arg, uarg, sizeof(arg)))
> + return -EFAULT;
> +
> + if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
> + return -EINVAL;
> +
> + if (arg.num_params) {
> + params = kcalloc(arg.num_params, sizeof(struct tee_param),
> + GFP_KERNEL);
> + if (!params)
> + return -ENOMEM;
It would be good to have an upper bound on the number of parameters
to limit the size of the memory allocation here.
> +int tee_device_register(struct tee_device *teedev)
> +{
> + int rc;
> +
> + /*
> + * If the teedev already is registered, don't do it again. It's
> + * obviously an error to try to register twice, but if we return
> + * an error we'll force the driver to remove the teedev.
> + */
> + if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
> + dev_err(&teedev->dev, "attempt to register twice\n");
> + return 0;
> + }
I don't understand what you are protecting against here.
How would we get to this function twice for the same device?
Could you change the caller so it doesn't happen?
> +/**
> + * struct tee_ioctl_param - parameter
> + * @attr: attributes
> + * @memref: a memory reference
> + * @value: a value
> + *
> + * @attr & TEE_PARAM_ATTR_TYPE_MASK indicates if memref or value is used in
> + * the union. TEE_PARAM_ATTR_TYPE_VALUE_* indicates value and
> + * TEE_PARAM_ATTR_TYPE_MEMREF_* indicates memref. TEE_PARAM_ATTR_TYPE_NONE
> + * indicates that none of the members are used.
> + */
> +struct tee_ioctl_param {
> + __u64 attr;
> + union {
> + struct tee_ioctl_param_memref memref;
> + struct tee_ioctl_param_value value;
> + } u;
> +};
> +
> +#define TEE_IOCTL_UUID_LEN 16
> +
Having a union in an ioctl argument seems odd. Have you considered
using two different ioctl command numbers depending on the type?
> +/**
> + * struct tee_iocl_supp_send_arg - Send a response to a received request
> + * @ret: [out] return value
> + * @num_params [in] number of parameters following this struct
> + */
> +struct tee_iocl_supp_send_arg {
> + __u32 ret;
> + __u32 num_params;
> + /*
> + * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
> + * which follows requires 8 byte alignment.
> + *
> + * Commented out element used to visualize the layout dynamic part
> + * of the struct. This field is not available at all if
> + * num_params == 0.
> + *
> + * struct tee_ioctl_param params[num_params];
> + */
> +} __aligned(8);
I'd make that
struct tee_ioctl_param params[0];
as wel here, as I also commented in patch 3 that has a similar structure.
Arnd
^ permalink raw reply
* [PATCH 0/7] ARM: Broadcom Brahma-B15 readahead cache support
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patch series adds support for the Broadcom Brahma-B15 readahead cache.
I submitted that patch series a couple of years ago, and then slept on it so
here is another stab at it.
Note that we did not implement this cache as a version of an outer cache
for several reasons:
- we initially thought we needed to intercept flush_icache_all and
flush_kern_cache_louis but upon further inspection we convinced ourselves
this is no longer needed, still, flush_cache_all() needs special handling
here and needs to wrap around
- the outer cache does not allow differentiating a DMA transfer direction
this is a readahead cache, so it does not participate in writes, flushing
it during reads *and* writes kills the performance
- finally, most operations that outer_cache cares about are on MVA, which
is transparent to the readahead cache here
Florian Fainelli (8):
ARM: v7: allow setting different cache functions
ARM: Add Broadcom Brahma-B15 readahead cache support
ARM: Hook B15 readahead cache functions based on processor
ARM: B15: Add CPU hotplug awareness
ARM: B15: Add suspend/resume hooks
ARM: B15: Register reboot notifier for KEXEC
MAINTAINERS: Update brcmstb entries to cover B15 code
MAINTAINERS | 2 +
arch/arm/include/asm/glue-cache.h | 4 +
arch/arm/include/asm/hardware/cache-b15-rac.h | 10 +
arch/arm/mm/Kconfig | 8 +
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-b15-rac.c | 360 ++++++++++++++++++++++++++
arch/arm/mm/cache-v7.S | 21 ++
arch/arm/mm/proc-v7.S | 6 +-
include/linux/cpuhotplug.h | 2 +
10 files changed, 411 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/include/asm/hardware/cache-b15-rac.h
create mode 100644 arch/arm/mm/cache-b15-rac.c
--
2.9.3
^ permalink raw reply
* [PATCH 1/7] ARM: v7: allow setting different cache functions
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
In preparation for adding support for the Broadcom Brahma-B15 read-ahead
cache which requires a different set of cache functions, allow the
__v7_proc macro to override the cache_fns settings, and default to
v7_cache_fns unless specified otherwise.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/proc-v7.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index d00d52c9de3e..a7b270970e03 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -562,7 +562,7 @@ __v7_setup_stack:
/*
* Standard v7 proc info content
*/
-.macro __v7_proc name, initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0, proc_fns = v7_processor_functions
+.macro __v7_proc name, initfunc, mm_mmuflags = 0, io_mmuflags = 0, hwcaps = 0, proc_fns = v7_processor_functions, cache_fns = v7_cache_fns
ALT_SMP(.long PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
PMD_SECT_AF | PMD_FLAGS_SMP | \mm_mmuflags)
ALT_UP(.long PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AP_READ | \
@@ -578,7 +578,7 @@ __v7_setup_stack:
.long \proc_fns
.long v7wbi_tlb_fns
.long v6_user_fns
- .long v7_cache_fns
+ .long \cache_fns
.endm
#ifndef CONFIG_ARM_LPAE
--
2.9.3
^ permalink raw reply related
* [PATCH 2/7] ARM: Add Broadcom Brahma-B15 readahead cache support
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
This patch adds support for the Broadcom Brahma-B15 CPU readahead cache
controller. This cache controller sits between the L2 and the memory bus
and its purpose is to provide a friendler burst size towards the DDR
interface than the native cache line size.
The readahead cache is mostly transparent, except for
flush_kern_cache_all, which is precisely what we are overriding here.
The readahead cache only intercepts reads, not writes, as such, some
data can remain stale in any of its buffers, such that we need to flush
it, which is an operation that needs to happen in a particular order:
- disable the readahead cache
- flush it
- call the appropriate cache-v7.S function
- re-enable
This patch tries to minimize the impact to the cache-v7.S file by only
providing a stub in case CONFIG_CACHE_B15_RAC is enabled (default for
ARCH_BRCMSTB since it is the current user).
Signed-off-by: Alamy Liu <alamyliu@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/include/asm/glue-cache.h | 4 +
arch/arm/include/asm/hardware/cache-b15-rac.h | 10 ++
arch/arm/mm/Kconfig | 8 ++
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-b15-rac.c | 177 ++++++++++++++++++++++++++
5 files changed, 200 insertions(+)
create mode 100644 arch/arm/include/asm/hardware/cache-b15-rac.h
create mode 100644 arch/arm/mm/cache-b15-rac.c
diff --git a/arch/arm/include/asm/glue-cache.h b/arch/arm/include/asm/glue-cache.h
index 01c3d92624e5..8d1f498e5dd8 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -117,6 +117,10 @@
# endif
#endif
+#if defined(CONFIG_CACHE_B15_RAC)
+# define MULTI_CACHE 1
+#endif
+
#if defined(CONFIG_CPU_V7M)
# define MULTI_CACHE 1
#endif
diff --git a/arch/arm/include/asm/hardware/cache-b15-rac.h b/arch/arm/include/asm/hardware/cache-b15-rac.h
new file mode 100644
index 000000000000..3d43ec06fd35
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-b15-rac.h
@@ -0,0 +1,10 @@
+#ifndef __ASM_ARM_HARDWARE_CACHE_B15_RAC_H
+#define __ASM_ARM_HARDWARE_CACHE_B15_RAC_H
+
+#ifndef __ASSEMBLY__
+
+void b15_flush_kern_cache_all(void);
+
+#endif
+
+#endif
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index f68e8ec29447..abac44a9ffff 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -883,6 +883,14 @@ config OUTER_CACHE_SYNC
The outer cache has a outer_cache_fns.sync function pointer
that can be used to drain the write buffer of the outer cache.
+config CACHE_B15_RAC
+ bool "Enable the Broadcom Brahma-B15 read-ahead cache controller"
+ depends on ARCH_BRCMSTB
+ default y
+ help
+ This option enables the Broadcom Brahma-B15 read-ahead cache
+ controller. If disabled, the read-ahead cache remains off.
+
config CACHE_FEROCEON_L2
bool "Enable the Feroceon L2 cache controller"
depends on ARCH_MV78XX0 || ARCH_MVEBU
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index e8698241ece9..6e61f0b84660 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -101,6 +101,7 @@ AFLAGS_proc-v6.o :=-Wa,-march=armv6
AFLAGS_proc-v7.o :=-Wa,-march=armv7-a
obj-$(CONFIG_OUTER_CACHE) += l2c-common.o
+obj-$(CONFIG_CACHE_B15_RAC) += cache-b15-rac.o
obj-$(CONFIG_CACHE_FEROCEON_L2) += cache-feroceon-l2.o
obj-$(CONFIG_CACHE_L2X0) += cache-l2x0.o l2c-l2x0-resume.o
obj-$(CONFIG_CACHE_L2X0_PMU) += cache-l2x0-pmu.o
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
new file mode 100644
index 000000000000..a53d80b0961b
--- /dev/null
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -0,0 +1,177 @@
+/*
+ * Broadcom Brahma-B15 CPU read-ahead cache management functions
+ *
+ * Copyright (C) 2015, Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/err.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/bitops.h>
+#include <linux/of_address.h>
+
+#include <asm/cacheflush.h>
+#include <asm/hardware/cache-b15-rac.h>
+
+extern void v7_flush_kern_cache_all(void);
+
+/* RAC register offsets, relative to the HIF_CPU_BIUCTRL register base */
+#define RAC_CONFIG0_REG (0x78)
+#define RACENPREF_MASK (0x3)
+#define RACPREFINST_SHIFT (0)
+#define RACENINST_SHIFT (2)
+#define RACPREFDATA_SHIFT (4)
+#define RACENDATA_SHIFT (6)
+#define RAC_CPU_SHIFT (8)
+#define RACCFG_MASK (0xff)
+#define RAC_CONFIG1_REG (0x7c)
+#define RAC_FLUSH_REG (0x80)
+#define FLUSH_RAC (1 << 0)
+
+/* Bitmask to enable instruction and data prefetching with a 256-bytes stride */
+#define RAC_DATA_INST_EN_MASK (1 << RACPREFINST_SHIFT | \
+ RACENPREF_MASK << RACENINST_SHIFT | \
+ 1 << RACPREFDATA_SHIFT | \
+ RACENPREF_MASK << RACENDATA_SHIFT)
+
+#define RAC_ENABLED 0
+
+static void __iomem *b15_rac_base;
+static DEFINE_SPINLOCK(rac_lock);
+
+/* Initialization flag to avoid checking for b15_rac_base, and to prevent
+ * multi-platform kernels from crashing here as well.
+ */
+static unsigned long b15_rac_flags;
+
+static inline u32 __b15_rac_disable(void)
+{
+ u32 val = __raw_readl(b15_rac_base + RAC_CONFIG0_REG);
+ __raw_writel(0, b15_rac_base + RAC_CONFIG0_REG);
+ dmb();
+ return val;
+}
+
+static inline void __b15_rac_flush(void)
+{
+ u32 reg;
+
+ __raw_writel(FLUSH_RAC, b15_rac_base + RAC_FLUSH_REG);
+ do {
+ /* This dmb() is required to force the Bus Interface Unit
+ * to clean oustanding writes, and forces an idle cycle
+ * to be inserted.
+ */
+ dmb();
+ reg = __raw_readl(b15_rac_base + RAC_FLUSH_REG);
+ } while (reg & FLUSH_RAC);
+}
+
+static inline u32 b15_rac_disable_and_flush(void)
+{
+ u32 reg;
+
+ reg = __b15_rac_disable();
+ __b15_rac_flush();
+ return reg;
+}
+
+static inline void __b15_rac_enable(u32 val)
+{
+ __raw_writel(val, b15_rac_base + RAC_CONFIG0_REG);
+ /* dsb() is required here to be consistent with __flush_icache_all() */
+ dsb();
+}
+
+#define BUILD_RAC_CACHE_OP(name, bar) \
+void b15_flush_##name(void) \
+{ \
+ unsigned int do_flush; \
+ u32 val = 0; \
+ \
+ spin_lock(&rac_lock); \
+ do_flush = test_bit(RAC_ENABLED, &b15_rac_flags); \
+ if (do_flush) \
+ val = b15_rac_disable_and_flush(); \
+ v7_flush_##name(); \
+ if (!do_flush) \
+ bar; \
+ else \
+ __b15_rac_enable(val); \
+ spin_unlock(&rac_lock); \
+}
+
+#define nobarrier
+
+/* The readahead cache present in the Brahma-B15 CPU is a special piece of
+ * hardware after the integrated L2 cache of the B15 CPU complex whose purpose
+ * is to prefetch instruction and/or data with a line size of either 64 bytes
+ * or 256 bytes. The rationale is that the data-bus of the CPU interface is
+ * optimized for 256-bytes transactions, and enabling the readahead cache
+ * provides a significant performance boost we want it enabled (typically
+ * twice the performance for a memcpy benchmark application).
+ *
+ * The readahead cache is transparent for Modified Virtual Addresses
+ * cache maintenance operations: ICIMVAU, DCIMVAC, DCCMVAC, DCCMVAU and
+ * DCCIMVAC.
+ *
+ * It is however not transparent for the following cache maintenance
+ * operations: DCISW, DCCSW, DCCISW, ICIALLUIS and ICIALLU which is precisely
+ * what we are patching here with our BUILD_RAC_CACHE_OP here.
+ */
+BUILD_RAC_CACHE_OP(kern_cache_all, nobarrier);
+
+static void b15_rac_enable(void)
+{
+ unsigned int cpu;
+ u32 enable = 0;
+
+ for_each_possible_cpu(cpu)
+ enable |= (RAC_DATA_INST_EN_MASK << (cpu * RAC_CPU_SHIFT));
+
+ b15_rac_disable_and_flush();
+ __b15_rac_enable(enable);
+}
+
+static int __init b15_rac_init(void)
+{
+ struct device_node *dn;
+ int ret = 0, cpu;
+ u32 reg, en_mask = 0;
+
+ dn = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
+ if (!dn)
+ return -ENODEV;
+
+ if (WARN(num_possible_cpus() > 4, "RAC only supports 4 CPUs\n"))
+ goto out;
+
+ b15_rac_base = of_iomap(dn, 0);
+ if (!b15_rac_base) {
+ pr_err("failed to remap BIU control base\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ spin_lock(&rac_lock);
+ reg = __raw_readl(b15_rac_base + RAC_CONFIG0_REG);
+ for_each_possible_cpu(cpu)
+ en_mask |= ((1 << RACPREFDATA_SHIFT) << (cpu * RAC_CPU_SHIFT));
+ WARN(reg & en_mask, "Read-ahead cache not previously disabled\n");
+
+ b15_rac_enable();
+ set_bit(RAC_ENABLED, &b15_rac_flags);
+ spin_unlock(&rac_lock);
+
+ pr_info("Broadcom Brahma-B15 readahead cache at: 0x%p\n",
+ b15_rac_base + RAC_CONFIG0_REG);
+
+out:
+ of_node_put(dn);
+ return ret;
+}
+arch_initcall(b15_rac_init);
--
2.9.3
^ permalink raw reply related
* [PATCH 3/7] ARM: Hook B15 readahead cache functions based on processor
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
If we detect that we are running on a Broadcom Brahma-B15 CPU, and
CONFIG_CACHE_B15_RAC is enabled, make sure that we pick-up the
b15_cache_fns function operations.
If CONFIG_CACHE_B15_RAC is enabled, but we are not running on a Broadcom
Brahma-B15 CPU, we will fallback to calling into the regular
v7_cache_fns with no cost. If CONFIG_CACHE_B15_RAC is disabled, there is
no cost and we just use the regular v7_cache_fns.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/cache-v7.S | 21 +++++++++++++++++++++
arch/arm/mm/proc-v7.S | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index a134d8a13d00..02f8a259c0d6 100644
--- a/arch/arm/mm/cache-v7.S
+++ b/arch/arm/mm/cache-v7.S
@@ -15,6 +15,7 @@
#include <asm/assembler.h>
#include <asm/errno.h>
#include <asm/unwind.h>
+#include <asm/hardware/cache-b15-rac.h>
#include "proc-macros.S"
@@ -446,3 +447,23 @@ ENDPROC(v7_dma_unmap_area)
@ define struct cpu_cache_fns (see <asm/cacheflush.h> and proc-macros.S)
define_cache_functions v7
+
+ /* The Broadcom Brahma-B15 read-ahead cache requires some modifications
+ * to the v7_cache_fns, we only override the ones we need
+ */
+#ifndef CONFIG_CACHE_B15_RAC
+ globl_equ b15_flush_kern_cache_all, v7_flush_kern_cache_all
+#endif
+ globl_equ b15_flush_icache_all, v7_flush_icache_all
+ globl_equ b15_flush_kern_cache_louis, v7_flush_kern_cache_louis
+ globl_equ b15_flush_user_cache_all, v7_flush_user_cache_all
+ globl_equ b15_flush_user_cache_range, v7_flush_user_cache_range
+ globl_equ b15_coherent_kern_range, v7_coherent_kern_range
+ globl_equ b15_coherent_user_range, v7_coherent_user_range
+ globl_equ b15_flush_kern_dcache_area, v7_flush_kern_dcache_area
+
+ globl_equ b15_dma_map_area, v7_dma_map_area
+ globl_equ b15_dma_unmap_area, v7_dma_unmap_area
+ globl_equ b15_dma_flush_range, v7_dma_flush_range
+
+ define_cache_functions b15
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index a7b270970e03..6e7c96df0dc1 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -673,7 +673,7 @@ __v7_ca15mp_proc_info:
__v7_b15mp_proc_info:
.long 0x420f00f0
.long 0xff0ffff0
- __v7_proc __v7_b15mp_proc_info, __v7_b15mp_setup
+ __v7_proc __v7_b15mp_proc_info, __v7_b15mp_setup, cache_fns = b15_cache_fns
.size __v7_b15mp_proc_info, . - __v7_b15mp_proc_info
/*
--
2.9.3
^ permalink raw reply related
* [PATCH 4/7] ARM: B15: Add CPU hotplug awareness
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
The Broadcom Brahma-B15 readahead cache needs to be disabled,
respectively re-enable during a CPU hotplug. In case we were not to do,
CPU hotplug would occasionally fail with random crashes when a given CPU
exits the coherency domain while the RAC is still enabled, as it would
get stale data from the RAC.
In order to avoid adding any specific B15 readahead-cache awareness to
arch/arm/mach-bcm/hotplug-brcmstb.c we use a CPU hotplug state machine
which allows us to catch CPU hotplug events and disable/flush enable the
RAC accordingly.
Signed-off-by: Alamy Liu <alamyliu@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/cache-b15-rac.c | 91 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/cpuhotplug.h | 2 +
2 files changed, 93 insertions(+)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index a53d80b0961b..81bc6f2abec9 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -13,6 +13,8 @@
#include <linux/io.h>
#include <linux/bitops.h>
#include <linux/of_address.h>
+#include <linux/notifier.h>
+#include <linux/cpu.h>
#include <asm/cacheflush.h>
#include <asm/hardware/cache-b15-rac.h>
@@ -42,6 +44,7 @@ extern void v7_flush_kern_cache_all(void);
static void __iomem *b15_rac_base;
static DEFINE_SPINLOCK(rac_lock);
+static u32 rac_config0_reg;
/* Initialization flag to avoid checking for b15_rac_base, and to prevent
* multi-platform kernels from crashing here as well.
@@ -137,6 +140,74 @@ static void b15_rac_enable(void)
__b15_rac_enable(enable);
}
+#ifdef CONFIG_HOTPLUG_CPU
+/* The CPU hotplug case is the most interesting one, we basically need to make
+ * sure that the RAC is disabled for the entire system prior to having a CPU
+ * die, in particular prior to this dying CPU having exited the coherency
+ * domain.
+ *
+ * Once this CPU is marked dead, we can safely re-enable the RAC for the
+ * remaining CPUs in the system which are still online.
+ *
+ * Offlining a CPU is the problematic case, onlining a CPU is not much of an
+ * issue since the CPU and its cache-level hierarchy will start filling with
+ * the RAC disabled, so L1 and L2 only.
+ *
+ * In this function, we should NOT have to verify any unsafe setting/condition
+ * b15_rac_base:
+ *
+ * It is protected by the RAC_ENABLED flag which is cleared by default, and
+ * being cleared when initial procedure is done. b15_rac_base had been set at
+ * that time.
+ *
+ * RAC_ENABLED:
+ * There is a small timing windows, in b15_rac_init(), between
+ * cpuhp_setup_state_*()
+ * ...
+ * set RAC_ENABLED
+ * However, there is no hotplug activity based on the Linux booting procedure.
+ *
+ * Since we have to disable RAC for all cores, we keep RAC on as long as as
+ * possible (disable it as late as possible) to gain the cache benefit.
+ *
+ * Thus, dying/dead states are chosen here
+ *
+ * We are choosing not do disable the RAC on a per-CPU basis, here, if we did
+ * we would want to consider disabling it as early as possible to benefit the
+ * other active CPUs.
+ */
+
+/* Running on the dying CPU */
+static int b15_rac_dying_cpu(unsigned int cpu)
+{
+ spin_lock(&rac_lock);
+
+ /* Indicate that we are starting a hotplug procedure */
+ clear_bit(RAC_ENABLED, &b15_rac_flags);
+
+ /* Disable the readahead cache and save its value to a global */
+ rac_config0_reg = b15_rac_disable_and_flush();
+
+ spin_unlock(&rac_lock);
+
+ return 0;
+}
+
+/* Running on a non-dying CPU */
+static int b15_rac_dead_cpu(unsigned int cpu)
+{
+ spin_lock(&rac_lock);
+
+ /* And enable it */
+ __b15_rac_enable(rac_config0_reg);
+ set_bit(RAC_ENABLED, &b15_rac_flags);
+
+ spin_unlock(&rac_lock);
+
+ return 0;
+}
+#endif /* CONFIG_HOTPLUG_CPU */
+
static int __init b15_rac_init(void)
{
struct device_node *dn;
@@ -157,6 +228,20 @@ static int __init b15_rac_init(void)
goto out;
}
+#ifdef CONFIG_HOTPLUG_CPU
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DEAD,
+ "arm/cache-b15-rac:dead",
+ NULL, b15_rac_dead_cpu);
+ if (ret)
+ goto out_unmap;
+
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
+ "arm/cache-b15-rac:dying",
+ NULL, b15_rac_dying_cpu);
+ if (ret)
+ goto out_cpu_dead;
+#endif
+
spin_lock(&rac_lock);
reg = __raw_readl(b15_rac_base + RAC_CONFIG0_REG);
for_each_possible_cpu(cpu)
@@ -170,6 +255,12 @@ static int __init b15_rac_init(void)
pr_info("Broadcom Brahma-B15 readahead cache at: 0x%p\n",
b15_rac_base + RAC_CONFIG0_REG);
+ goto out;
+
+out_cpu_dead:
+ cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING);
+out_unmap:
+ iounmap(b15_rac_base);
out:
of_node_put(dn);
return ret;
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 20bfefbe7594..1e3672af5b6e 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -44,6 +44,7 @@ enum cpuhp_state {
CPUHP_LUSTRE_CFS_DEAD,
CPUHP_SCSI_BNX2FC_DEAD,
CPUHP_SCSI_BNX2I_DEAD,
+ CPUHP_AP_ARM_CACHE_B15_RAC_DEAD,
CPUHP_WORKQUEUE_PREP,
CPUHP_POWER_NUMA_PREPARE,
CPUHP_HRTIMERS_PREPARE,
@@ -120,6 +121,7 @@ enum cpuhp_state {
CPUHP_AP_ARM64_ISNDEP_STARTING,
CPUHP_AP_SMPCFD_DYING,
CPUHP_AP_X86_TBOOT_DYING,
+ CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
CPUHP_AP_ONLINE,
CPUHP_TEARDOWN_CPU,
CPUHP_AP_ONLINE_IDLE,
--
2.9.3
^ permalink raw reply related
* [PATCH 5/7] ARM: B15: Add suspend/resume hooks
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
The Broadcom Brahma-B15 CPU readahead cache registers will be restored
to their Power-on-Reset values after a S3 suspend/resume cycles, so we
want to restore what we had enabled before.
Another thing we want to take care of is disabling the read-ahead cache
prior to suspending to avoid any sort of side effect with the spinlock
we need to grab to serialize register accesses.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/cache-b15-rac.c | 48 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index 81bc6f2abec9..ef5e93e4b5c2 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -15,6 +15,7 @@
#include <linux/of_address.h>
#include <linux/notifier.h>
#include <linux/cpu.h>
+#include <linux/syscore_ops.h>
#include <asm/cacheflush.h>
#include <asm/hardware/cache-b15-rac.h>
@@ -41,6 +42,10 @@ extern void v7_flush_kern_cache_all(void);
RACENPREF_MASK << RACENDATA_SHIFT)
#define RAC_ENABLED 0
+/* Special state where we want to bypass the spinlock and call directly
+ * into the v7 cache maintenance operations during suspend/resume
+ */
+#define RAC_SUSPENDED 1
static void __iomem *b15_rac_base;
static DEFINE_SPINLOCK(rac_lock);
@@ -96,6 +101,12 @@ void b15_flush_##name(void) \
unsigned int do_flush; \
u32 val = 0; \
\
+ if (test_bit(RAC_SUSPENDED, &b15_rac_flags)) { \
+ v7_flush_##name(); \
+ bar; \
+ return; \
+ } \
+ \
spin_lock(&rac_lock); \
do_flush = test_bit(RAC_ENABLED, &b15_rac_flags); \
if (do_flush) \
@@ -208,6 +219,39 @@ static int b15_rac_dead_cpu(unsigned int cpu)
}
#endif /* CONFIG_HOTPLUG_CPU */
+#ifdef CONFIG_PM_SLEEP
+static int b15_rac_suspend(void)
+{
+ /* Suspend the read-ahead cache oeprations, forcing our cache
+ * implementation to fallback to the regular ARMv7 calls.
+ *
+ * We are guaranteed to be running on the boot CPU@this point and
+ * with every other CPU quiesced, so setting RAC_SUSPENDED is not racy
+ * here.
+ */
+ rac_config0_reg = b15_rac_disable_and_flush();
+ set_bit(RAC_SUSPENDED, &b15_rac_flags);
+
+ return 0;
+}
+
+static void b15_rac_resume(void)
+{
+ /* Coming out of a S3 suspend/resume cycle, the read-ahead cache
+ * register RAC_CONFIG0_REG will be restored to its default value, make
+ * sure we re-enable it and set the enable flag, we are also guaranteed
+ * to run on the boot CPU, so not racy again.
+ */
+ __b15_rac_enable(rac_config0_reg);
+ clear_bit(RAC_SUSPENDED, &b15_rac_flags);
+}
+
+static struct syscore_ops b15_rac_syscore_ops = {
+ .suspend = b15_rac_suspend,
+ .resume = b15_rac_resume,
+};
+#endif
+
static int __init b15_rac_init(void)
{
struct device_node *dn;
@@ -242,6 +286,10 @@ static int __init b15_rac_init(void)
goto out_cpu_dead;
#endif
+#ifdef CONFIG_PM_SLEEP
+ register_syscore_ops(&b15_rac_syscore_ops);
+#endif
+
spin_lock(&rac_lock);
reg = __raw_readl(b15_rac_base + RAC_CONFIG0_REG);
for_each_possible_cpu(cpu)
--
2.9.3
^ permalink raw reply related
* [PATCH 6/7] ARM: B15: Register reboot notifier for KEXEC
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
During kexec, we will go through kernel_kexec() -> syscore_suspend() if
CONFIG_KEXEC_JUMP is set, if not, down the road we end-up calling
kernel_restart_prepare() which invokes reboot notifiers with
SYS_RESTART.
We register a reboot notifier to make sure that the B15 read-ahead cache
is disabled, since it is another level of instruction and data cache,
and we want to avoid any potential side effects with booting a new
kernel with such a cache still turned on.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/cache-b15-rac.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index ef5e93e4b5c2..148d51fdfc3d 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -16,6 +16,7 @@
#include <linux/notifier.h>
#include <linux/cpu.h>
#include <linux/syscore_ops.h>
+#include <linux/reboot.h>
#include <asm/cacheflush.h>
#include <asm/hardware/cache-b15-rac.h>
@@ -151,6 +152,29 @@ static void b15_rac_enable(void)
__b15_rac_enable(enable);
}
+static int b15_rac_reboot_notifier(struct notifier_block *nb,
+ unsigned long action,
+ void *data)
+{
+ /* During kexec, we are not yet migrated on the boot CPU, so we need to
+ * make sure we are SMP safe here. Once the RAC is disabled, flag it as
+ * suspended such that the hotplug notifier returns early.
+ */
+ if (action == SYS_RESTART) {
+ spin_lock(&rac_lock);
+ b15_rac_disable_and_flush();
+ clear_bit(RAC_ENABLED, &b15_rac_flags);
+ set_bit(RAC_SUSPENDED, &b15_rac_flags);
+ spin_unlock(&rac_lock);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block b15_rac_reboot_nb = {
+ .notifier_call = b15_rac_reboot_notifier,
+};
+
#ifdef CONFIG_HOTPLUG_CPU
/* The CPU hotplug case is the most interesting one, we basically need to make
* sure that the RAC is disabled for the entire system prior to having a CPU
@@ -191,6 +215,12 @@ static void b15_rac_enable(void)
/* Running on the dying CPU */
static int b15_rac_dying_cpu(unsigned int cpu)
{
+ /* During kexec/reboot, the RAC is disabled via the reboot notifier
+ * return early here.
+ */
+ if (test_bit(RAC_SUSPENDED, &b15_rac_flags))
+ return 0;
+
spin_lock(&rac_lock);
/* Indicate that we are starting a hotplug procedure */
@@ -207,6 +237,12 @@ static int b15_rac_dying_cpu(unsigned int cpu)
/* Running on a non-dying CPU */
static int b15_rac_dead_cpu(unsigned int cpu)
{
+ /* During kexec/reboot, the RAC is disabled via the reboot notifier
+ * return early here.
+ */
+ if (test_bit(RAC_SUSPENDED, &b15_rac_flags))
+ return 0;
+
spin_lock(&rac_lock);
/* And enable it */
@@ -272,6 +308,13 @@ static int __init b15_rac_init(void)
goto out;
}
+ ret = register_reboot_notifier(&b15_rac_reboot_nb);
+ if (ret) {
+ pr_err("failed to register reboot notifier\n");
+ iounmap(b15_rac_base);
+ goto out;
+ }
+
#ifdef CONFIG_HOTPLUG_CPU
ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DEAD,
"arm/cache-b15-rac:dead",
@@ -308,6 +351,7 @@ static int __init b15_rac_init(void)
out_cpu_dead:
cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING);
out_unmap:
+ unregister_reboot_notifier(&b15_rac_reboot_nb);
iounmap(b15_rac_base);
out:
of_node_put(dn);
--
2.9.3
^ permalink raw reply related
* [PATCH 7/7] MAINTAINERS: Update brcmstb entries to cover B15 code
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
Update the brcmstb entry to cover the Broadcom Brahma-B15 processor
read-ahead cache support code.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c36976d3bd1a..47ee4a93d554 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2671,6 +2671,8 @@ S: Maintained
F: arch/arm/mach-bcm/*brcmstb*
F: arch/arm/boot/dts/bcm7*.dts*
F: drivers/bus/brcmstb_gisb.c
+F: arch/arm/mm/cache-b15-rac.c
+F: arch/arm/include/asm/hardware/cache-b15-rac.h
N: brcmstb
BROADCOM BMIPS MIPS ARCHITECTURE
--
2.9.3
^ permalink raw reply related
* [PATCH 8/8] ARM: smp: Remove CPU: shutdown notice
From: Florian Fainelli @ 2017-01-18 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-1-f.fainelli@gmail.com>
This message is not particularly informative, and is not paired with an
identical message when a CPU is brought online. Finally, it slows the
CPU hotplug path down, thus allowing less CPU hotplug operations per
second. Just remove it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/kernel/smp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7dd14e8395e6..b3e02751ab64 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -251,7 +251,6 @@ void __cpu_die(unsigned int cpu)
pr_err("CPU%u: cpu didn't die\n", cpu);
return;
}
- pr_notice("CPU%u: shutdown\n", cpu);
/*
* platform_cpu_kill() is generally expected to do the powering off
--
2.9.3
^ permalink raw reply related
* [PATCH 0/4] ARM: v7-A !MMU support, CONFIG_VECTORS_BASE removal (almost)
From: afzal mohammed @ 2017-01-18 20:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
ARM core changes to support !MMU Kernel on v7-A MMU processors. This
series also does the preparation for CONFIG_VECTORS_BASE removal.
Based on the feedback from Russell on the initial patches (part RFC),
it was decided to handle vector base dynamically in C & work towards
the the goal of removing VECTORS_BASE from Kconfig. MMU platform's
always have exception base address at 0xffff0000, while no-MMU CP15
scenario was handled dynamically in C. Hivecs handling for no-MMU CP15
that was done in asm has been moved to C as part of dynamic handling.
This now leaves only vector region setup, used by Cortex-R, to be made
devoid of VECTORS_BASE so as to remove it from Kconfig.
Vladimir is planning to rework MPU code, so it has been left untouched.
VECTORS_BASE is to be removed from Kconfig after the MPU region rework.
This series has been tested on top of mainline on,
1. Vybrid CM4 (!MMU)
2. Vybrid CA5 (MMU)
and on top of Vladimir's series[1] on,
1. Vybrid CM4 (!MMU)
2. Vybrid CA5 (MMU & !MMU)
3. AM437x IDK (MMU & !MMU)
Both above had an additional patch [2] as well, which is in next now.
Regards
afzal
[1] "[RFC v2 PATCH 00/23] Allow NOMMU for MULTIPLATFORM",
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html
(git://linux-arm.org/linux-vm.git nommu-rfc-v2)
[2] "[PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM"
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473593.html
afzal mohammed (4):
ARM: mmu: decouple VECTORS_BASE from Kconfig
ARM: nommu: dynamic exception base address setting
ARM: nommu: display vectors base
ARM: nommu: remove Hivecs configuration is asm
arch/arm/include/asm/memory.h | 2 ++
arch/arm/kernel/head-nommu.S | 5 ----
arch/arm/mach-berlin/platsmp.c | 3 +-
arch/arm/mm/dump.c | 5 ++--
arch/arm/mm/init.c | 9 ++++--
arch/arm/mm/mm.h | 5 ++--
arch/arm/mm/nommu.c | 64 ++++++++++++++++++++++++++++++++++++++++--
7 files changed, 79 insertions(+), 14 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/4] ARM: mmu: decouple VECTORS_BASE from Kconfig
From: afzal mohammed @ 2017-01-18 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203525.6246-1-afzal.mohd.ma@gmail.com>
For MMU configurations, VECTORS_BASE is always 0xffff0000, a macro
definition will suffice.
Once exception address is handled dynamically for no-MMU also (this
would involve taking care of region setup too), VECTORS_BASE can be
removed from Kconfig.
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
Though there was no build error without inclusion of asm/memory.h, to
be on the safer side it has been added, to reduce chances of build
breakage in random configurations.
arch/arm/include/asm/memory.h | 2 ++
arch/arm/mach-berlin/platsmp.c | 3 ++-
arch/arm/mm/dump.c | 5 +++--
arch/arm/mm/init.c | 4 ++--
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c674df..9cc9f1dbc88e 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -83,6 +83,8 @@
#define IOREMAP_MAX_ORDER 24
#endif
+#define VECTORS_BASE 0xffff0000
+
#else /* CONFIG_MMU */
/*
diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
index 93f90688db18..578d41031abf 100644
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -15,6 +15,7 @@
#include <asm/cacheflush.h>
#include <asm/cp15.h>
+#include <asm/memory.h>
#include <asm/smp_plat.h>
#include <asm/smp_scu.h>
@@ -75,7 +76,7 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
if (!cpu_ctrl)
goto unmap_scu;
- vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
+ vectors_base = ioremap(VECTORS_BASE, SZ_32K);
if (!vectors_base)
goto unmap_scu;
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 9fe8e241335c..21192d6eda40 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -18,6 +18,7 @@
#include <linux/seq_file.h>
#include <asm/fixmap.h>
+#include <asm/memory.h>
#include <asm/pgtable.h>
struct addr_marker {
@@ -31,8 +32,8 @@ static struct addr_marker address_markers[] = {
{ 0, "vmalloc() Area" },
{ VMALLOC_END, "vmalloc() End" },
{ FIXADDR_START, "Fixmap Area" },
- { CONFIG_VECTORS_BASE, "Vectors" },
- { CONFIG_VECTORS_BASE + PAGE_SIZE * 2, "Vectors End" },
+ { VECTORS_BASE, "Vectors" },
+ { VECTORS_BASE + PAGE_SIZE * 2, "Vectors End" },
{ -1, NULL },
};
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..cf47f86f79ed 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -27,6 +27,7 @@
#include <asm/cp15.h>
#include <asm/mach-types.h>
#include <asm/memblock.h>
+#include <asm/memory.h>
#include <asm/prom.h>
#include <asm/sections.h>
#include <asm/setup.h>
@@ -521,8 +522,7 @@ void __init mem_init(void)
" .data : 0x%p" " - 0x%p" " (%4td kB)\n"
" .bss : 0x%p" " - 0x%p" " (%4td kB)\n",
- MLK(UL(CONFIG_VECTORS_BASE), UL(CONFIG_VECTORS_BASE) +
- (PAGE_SIZE)),
+ MLK(UL(VECTORS_BASE), UL(VECTORS_BASE) + (PAGE_SIZE)),
#ifdef CONFIG_HAVE_TCM
MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
MLK(ITCM_OFFSET, (unsigned long) itcm_end),
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] ARM: nommu: dynamic exception base address setting
From: afzal mohammed @ 2017-01-18 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203525.6246-1-afzal.mohd.ma@gmail.com>
No-MMU dynamic exception base address configuration on CP15
processors. In the case of low vectors, decision based on whether
security extensions are enabled & whether remap vectors to RAM
CONFIG option is selected.
For no-MMU without CP15, current default value of 0x0 is retained.
Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
arch/arm/mm/nommu.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967727e2..db8e784f20f3 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <asm/cacheflush.h>
+#include <asm/cp15.h>
#include <asm/sections.h>
#include <asm/page.h>
#include <asm/setup.h>
@@ -22,6 +23,8 @@
#include "mm.h"
+unsigned long vectors_base;
+
#ifdef CONFIG_ARM_MPU
struct mpu_rgn_info mpu_rgn_info;
@@ -278,15 +281,72 @@ static void sanity_check_meminfo_mpu(void) {}
static void __init mpu_setup(void) {}
#endif /* CONFIG_ARM_MPU */
+#ifdef CONFIG_CPU_CP15
+#ifdef CONFIG_CPU_HIGH_VECTOR
+static unsigned long __init setup_vectors_base(void)
+{
+ unsigned long reg = get_cr();
+
+ set_cr(reg | CR_V);
+ return 0xffff0000;
+}
+#else /* CONFIG_CPU_HIGH_VECTOR */
+/*
+ * ID_PRF1 bits (CP#15 ID_PFR1)
+ */
+#define ID_PFR1_SE (0x3 << 4) /* Security extension enable bits */
+
+/* Read processor feature register ID_PFR1 */
+static unsigned long get_id_pfr1(void)
+{
+ unsigned long val;
+
+ asm("mrc p15, 0, %0, c0, c1, 1" : "=r" (val) : : "cc");
+ return val;
+}
+
+/* Write exception base address to VBAR */
+static void set_vbar(unsigned long val)
+{
+ asm("mcr p15, 0, %0, c12, c0, 0" : : "r" (val) : "cc");
+}
+
+static bool __init security_extensions_enabled(void)
+{
+ return !!(get_id_pfr1() & ID_PFR1_SE);
+}
+
+static unsigned long __init setup_vectors_base(void)
+{
+ unsigned long base = 0, reg = get_cr();
+
+ set_cr(reg & ~CR_V);
+ if (security_extensions_enabled()) {
+ if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM))
+ base = CONFIG_DRAM_BASE;
+ set_vbar(base);
+ } else if (IS_ENABLED(CONFIG_REMAP_VECTORS_TO_RAM)) {
+ if (CONFIG_DRAM_BASE != 0)
+ pr_err("Security extensions not enabled, vectors cannot be remapped to RAM, vectors base will be 0x00000000\n");
+ }
+
+ return base;
+}
+#endif /* CONFIG_CPU_HIGH_VECTOR */
+#endif /* CONFIG_CPU_CP15 */
+
void __init arm_mm_memblock_reserve(void)
{
#ifndef CONFIG_CPU_V7M
+#ifdef CONFIG_CPU_CP15
+ vectors_base = setup_vectors_base();
+#endif
/*
* Register the exception vector page.
* some architectures which the DRAM is the exception vector to trap,
* alloc_page breaks with error, although it is not NULL, but "0."
*/
- memblock_reserve(CONFIG_VECTORS_BASE, 2 * PAGE_SIZE);
+ memblock_reserve(vectors_base, 2 * PAGE_SIZE);
#else /* ifndef CONFIG_CPU_V7M */
/*
* There is no dedicated vector page on V7-M. So nothing needs to be
@@ -310,7 +370,7 @@ void __init sanity_check_meminfo(void)
*/
void __init paging_init(const struct machine_desc *mdesc)
{
- early_trap_init((void *)CONFIG_VECTORS_BASE);
+ early_trap_init((void *)vectors_base);
mpu_setup();
bootmem_init();
}
--
2.11.0
^ permalink raw reply related
* [PATCH 3/4] ARM: nommu: display vectors base
From: afzal mohammed @ 2017-01-18 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203525.6246-1-afzal.mohd.ma@gmail.com>
The exception base address is now dynamically estimated for no-MMU
case, display it.
Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
arch/arm/mm/init.c | 5 +++++
arch/arm/mm/mm.h | 5 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index cf47f86f79ed..9e11f255c3bf 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -522,7 +522,12 @@ void __init mem_init(void)
" .data : 0x%p" " - 0x%p" " (%4td kB)\n"
" .bss : 0x%p" " - 0x%p" " (%4td kB)\n",
+#ifdef CONFIG_MMU
MLK(UL(VECTORS_BASE), UL(VECTORS_BASE) + (PAGE_SIZE)),
+#else
+ MLK_ROUNDUP(vectors_base, vectors_base + PAGE_SIZE),
+#endif
+
#ifdef CONFIG_HAVE_TCM
MLK(DTCM_OFFSET, (unsigned long) dtcm_end),
MLK(ITCM_OFFSET, (unsigned long) itcm_end),
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index ce727d47275c..546f09437fca 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -79,8 +79,9 @@ struct static_vm {
extern struct list_head static_vmlist;
extern struct static_vm *find_static_vm_vaddr(void *vaddr);
extern __init void add_static_vm_early(struct static_vm *svm);
-
-#endif
+#else /* CONFIG_MMU */
+extern unsigned long vectors_base;
+#endif /* CONFIG_MMU */
#ifdef CONFIG_ZONE_DMA
extern phys_addr_t arm_dma_limit;
--
2.11.0
^ permalink raw reply related
* [PATCH 4/4] ARM: nommu: remove Hivecs configuration is asm
From: afzal mohammed @ 2017-01-18 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203525.6246-1-afzal.mohd.ma@gmail.com>
Now that exception based address is handled dynamically for
processors with CP15, remove Highvecs configuration in assembly.
Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
---
arch/arm/kernel/head-nommu.S | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 6b4eb27b8758..2e21e08de747 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -152,11 +152,6 @@ __after_proc_init:
#ifdef CONFIG_CPU_ICACHE_DISABLE
bic r0, r0, #CR_I
#endif
-#ifdef CONFIG_CPU_HIGH_VECTOR
- orr r0, r0, #CR_V
-#else
- bic r0, r0, #CR_V
-#endif
mcr p15, 0, r0, c1, c0, 0 @ write control reg
#elif defined (CONFIG_CPU_V7M)
/* For V7M systems we want to modify the CCR similarly to the SCTLR */
--
2.11.0
^ permalink raw reply related
* Nokia N900: mixers changed between 4.9 and 4.10-rc3, no longer can use in-call speaker
From: Pavel Machek @ 2017-01-18 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116211540.GA19736@amd>
Hi!
> > > So regression seems to be between v4.9 and v4.10. Any ideas?
> >
> > Interesting... seems there are no sound relevant changes after v4.9.
> >
> > Looks like there are only three commits after v4.9 for sound/soc which
> > are built for Nokia N900:
...
> Its definitely caused by something merged here:
>
> commit ce38207f161513ee3d2bd3860489f07ebe65bc78
> Merge: a9042de 995c6a7
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed Dec 14 11:14:28 2016 -0800
>
> So it should be easy to find out..
Doing git bisect now. Hmmm.
pavel at amd:/data/l/linux-n900$ git bisect bad
1a653aa44725668590b36bbe2d7fe4736a69f055 is the first bad commit
commit 1a653aa44725668590b36bbe2d7fe4736a69f055
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Wed Nov 30 06:22:55 2016 +0000
ASoC: core: replace aux_comp_list to component_dev_list
Now, Card has component_dev_list, we can replace aux_comp_list
to component_dev_list with new auxiliary flags
Signed-off-by: Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
:040000 040000 a571fa05e5ce8e00b73bbc3f1e30e26775d619e8
e9336929cacf2d7bc94da99acfc10c9a7f513b8b M include
:040000 040000 87976e9406d452e791870cc12e27cb67ba04fd12
60d36f685642621c0e3ebb61ba7a14186d8b3eb0 M sound
pavel at amd:/data/l/linux-n900$
I'll try reverting this patch on top of 4.10-rc, next. Any other ideas?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170118/5c10026d/attachment.sig>
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Stephen Boyd @ 2017-01-18 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118073432.GA26659@b29397-desktop>
Quoting Peter Chen (2017-01-17 23:34:32)
> On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote:
> > Quoting Peter Chen (2017-01-15 19:45:51)
> > >
> > > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> > > to port it to generic phy framework.
> > >
> >
> > Ok. I'll look into that. Can the other patches in this series be picked
> > up? Otherwise I can resend them all again once I fix the phy_set_mode()
> > call location and introduce a new phy op.
>
> I can pick up chipidea patches after you test the patch I supplied at:
>
> [PATCH v6 11/25] usb: chipidea: vbus event may exist before starting
> gadget
Ok. I've confirmed that this updated patch works fine for me. You can
have my Tested-by and Reviewed-by there.
>
> You may ping other maintainers to pick up other patches.
>
I was hoping you could pick the beginning of the series up until the PHY
drivers, which can go via Kishon's tree. That would mean applying the
drivers/of/ part. Rob is that ok?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox