* [PATCH] nvmem: uniphier: change access unit from 32bit to 8bit
From: Srinivas Kandagatla @ 2017-12-13 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213183152.A835.4A936039@socionext.com>
On 13/12/17 09:31, Kunihiko Hayashi wrote:
> Hello Srinivas,
>
> This patch was already reviewed and tested for all UniPhier SoCs:
> https://patchwork.kernel.org/patch/10069557/
>
> Do you have any comments, or would you please pick it up?
Thanks for your patience,
I will send it along with other fixes to Greg Sometime this week!
Rgrds,
Srini
>
> Thank you,
>
> On Wed, 22 Nov 2017 14:14:59 +0900 Kunihiko Hayashi <hayashi.kunihiko@socionext.com> wrote:
>
>> The efuse on UniPhier allows 8bit access according to the specification.
>> Since bit offset of nvmem is limited to 0-7, it is desiable to change
>> access unit of nvmem to 8bit.
>>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> ---
>> drivers/nvmem/uniphier-efuse.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
>> index 2bb45c4..fac3122 100644
>> --- a/drivers/nvmem/uniphier-efuse.c
>> +++ b/drivers/nvmem/uniphier-efuse.c
>> @@ -27,11 +27,11 @@ static int uniphier_reg_read(void *context,
>> unsigned int reg, void *_val, size_t bytes)
>> {
>> struct uniphier_efuse_priv *priv = context;
>> - u32 *val = _val;
>> + u8 *val = _val;
>> int offs;
>>
>> - for (offs = 0; offs < bytes; offs += sizeof(u32))
>> - *val++ = readl(priv->base + reg + offs);
>> + for (offs = 0; offs < bytes; offs += sizeof(u8))
>> + *val++ = readb(priv->base + reg + offs);
>>
>> return 0;
>> }
>> @@ -53,8 +53,8 @@ static int uniphier_efuse_probe(struct platform_device *pdev)
>> if (IS_ERR(priv->base))
>> return PTR_ERR(priv->base);
>>
>> - econfig.stride = 4;
>> - econfig.word_size = 4;
>> + econfig.stride = 1;
>> + econfig.word_size = 1;
>> econfig.read_only = true;
>> econfig.reg_read = uniphier_reg_read;
>> econfig.size = resource_size(res);
>> --
>> 2.7.4
>
> ---
> Best Regards,
> Kunihiko Hayashi
>
>
^ permalink raw reply
* [PATCH V4 03/12] drivers: Add boot constraints core
From: Greg Kroah-Hartman @ 2017-12-13 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2868a37e561cab91ba5495a1e14b9548c8e93c3e.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:51PM +0530, Viresh Kumar wrote:
> Some devices are powered ON by the bootloader before the bootloader
> handovers control to Linux. It maybe important for those devices to keep
> working until the time a Linux device driver probes the device and
> reconfigure its resources.
>
> A typical example of that can be the LCD controller, which is used by
> the bootloaders to show image(s) while the platform is booting into
> Linux. The LCD controller can be using some resources, like clk,
> regulators, PM domain, etc, that are shared between several devices.
> These shared resources should be configured to satisfy need of all the
> users. If another device's (X) driver gets probed before the LCD
> controller driver in this case, then it may end up reconfiguring these
> resources to ranges satisfying the current users (only device X) and
> that can make the LCD screen unstable.
>
> This patch introduces the concept of boot-constraints, which will be set
> by the bootloaders and the kernel will satisfy them until the time
> driver for such a device is probed (successfully or unsuccessfully).
>
> The list of boot constraint types is empty for now, and will be
> incrementally updated by later patches.
>
> Only two routines are exposed by the boot constraints core for now:
>
> - dev_boot_constraint_add(): This shall be called by parts of the kernel
> (before the device is probed) to set the constraints.
>
> - dev_boot_constraints_remove(): This is called only by the driver core
> after a device is probed successfully or unsuccessfully. Special
> handling is done here for deferred probing.
>
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Minor nits:
> ---
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/base/dd.c | 20 ++--
> drivers/boot_constraints/Kconfig | 9 ++
> drivers/boot_constraints/Makefile | 3 +
> drivers/boot_constraints/core.c | 199 ++++++++++++++++++++++++++++++++++++++
> drivers/boot_constraints/core.h | 33 +++++++
> include/linux/boot_constraint.h | 46 +++++++++
> 8 files changed, 306 insertions(+), 7 deletions(-)
> create mode 100644 drivers/boot_constraints/Kconfig
> create mode 100644 drivers/boot_constraints/Makefile
> create mode 100644 drivers/boot_constraints/core.c
> create mode 100644 drivers/boot_constraints/core.h
> create mode 100644 include/linux/boot_constraint.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 505c676fa9c7..e595ffad2214 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -4,6 +4,8 @@ source "drivers/amba/Kconfig"
>
> source "drivers/base/Kconfig"
>
> +source "drivers/boot_constraints/Kconfig"
> +
> source "drivers/bus/Kconfig"
>
> source "drivers/connector/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index d90fdc413648..29d03466cb2a 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_FB_INTEL) += video/fbdev/intelfb/
> obj-$(CONFIG_PARPORT) += parport/
> obj-$(CONFIG_NVM) += lightnvm/
> obj-y += base/ block/ misc/ mfd/ nfc/
> +obj-$(CONFIG_DEV_BOOT_CONSTRAINTS) += boot_constraints/
> obj-$(CONFIG_LIBNVDIMM) += nvdimm/
> obj-$(CONFIG_DAX) += dax/
> obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index ad44b40fe284..4eec27fe2b2b 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -17,6 +17,7 @@
> * This file is released under the GPLv2
> */
Can you rebase this patch, I think it will have conflicts or fuzz here.
>
> +#include <linux/boot_constraint.h>
> #include <linux/device.h>
> #include <linux/delay.h>
> #include <linux/dma-mapping.h>
> @@ -409,15 +410,20 @@ static int really_probe(struct device *dev, struct device_driver *drv)
> */
> devices_kset_move_last(dev);
>
> - if (dev->bus->probe) {
> + if (dev->bus->probe)
> ret = dev->bus->probe(dev);
> - if (ret)
> - goto probe_failed;
> - } else if (drv->probe) {
> + else if (drv->probe)
> ret = drv->probe(dev);
> - if (ret)
> - goto probe_failed;
> - }
> +
> + /*
> + * Remove boot constraints for both successful and unsuccessful probe(),
> + * except for the case where EPROBE_DEFER is returned by probe().
> + */
> + if (ret != -EPROBE_DEFER)
> + dev_boot_constraints_remove(dev);
This feels odd, but ok, I trust you :)
> +
> + if (ret)
> + goto probe_failed;
>
> if (test_remove) {
> test_remove = false;
> diff --git a/drivers/boot_constraints/Kconfig b/drivers/boot_constraints/Kconfig
> new file mode 100644
> index 000000000000..77831af1c6fb
> --- /dev/null
> +++ b/drivers/boot_constraints/Kconfig
> @@ -0,0 +1,9 @@
> +config DEV_BOOT_CONSTRAINTS
> + bool "Boot constraints for devices"
> + help
> + This enables boot constraints detection for devices. These constraints
> + are (normally) set by the Bootloader and must be satisfied by the
> + kernel until the relevant device driver is probed. Once the driver is
> + probed, the constraint is dropped.
> +
> + If unsure, say N.
> diff --git a/drivers/boot_constraints/Makefile b/drivers/boot_constraints/Makefile
> new file mode 100644
> index 000000000000..0f2680177974
> --- /dev/null
> +++ b/drivers/boot_constraints/Makefile
> @@ -0,0 +1,3 @@
> +# Makefile for device boot constraints
> +
> +obj-y := core.o
> diff --git a/drivers/boot_constraints/core.c b/drivers/boot_constraints/core.c
> new file mode 100644
> index 000000000000..366a05d6d9ba
> --- /dev/null
> +++ b/drivers/boot_constraints/core.c
> @@ -0,0 +1,199 @@
> +/*
> + * This takes care of boot time device constraints, normally set by the
> + * Bootloader.
> + *
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2.
Care to update this patch with the new SPDX format for licenses?
> + */
> +
> +#define pr_fmt(fmt) "Boot Constraints: " fmt
You don't have any pr_* calls, so this isn't needed :)
> +struct constraint {
> + struct constraint_dev *cdev;
> + struct list_head node;
> + enum dev_boot_constraint_type type;
> + void (*free_resources)(void *data);
> + void *free_resources_data;
> +
> + int (*add)(struct constraint *constraint, void *data);
> + void (*remove)(struct constraint *constraint);
> + void *private;
> +};
> +
> +/* Forward declarations of constraint specific callbacks */
> +#endif /* _CORE_H */
What is this comment at the end of the file for?
> diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
> new file mode 100644
> index 000000000000..2b816bf74144
> --- /dev/null
> +++ b/include/linux/boot_constraint.h
> @@ -0,0 +1,46 @@
> +/*
> + * Boot constraints header.
> + *
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2
> + */
> +#ifndef _LINUX_BOOT_CONSTRAINT_H
> +#define _LINUX_BOOT_CONSTRAINT_H
> +
> +#include <linux/err.h>
> +#include <linux/types.h>
> +
> +struct device;
> +
> +enum dev_boot_constraint_type {
> + DEV_BOOT_CONSTRAINT_NONE,
> +};
> +
> +struct dev_boot_constraint {
> + enum dev_boot_constraint_type type;
> + void *data;
> +};
> +
> +struct dev_boot_constraint_info {
> + struct dev_boot_constraint constraint;
> +
> + /* This will be called just before the constraint is removed */
> + void (*free_resources)(void *data);
> + void *free_resources_data;
> +};
> +
> +#ifdef CONFIG_DEV_BOOT_CONSTRAINTS
> +int dev_boot_constraint_add(struct device *dev,
> + struct dev_boot_constraint_info *info);
> +void dev_boot_constraints_remove(struct device *dev);
> +#else
> +static inline
> +int dev_boot_constraint_add(struct device *dev,
> + struct dev_boot_constraint_info *info)
> +{ return -EINVAL; }
Why return an error? Shouldn't this just "succeed" if the option is not
built in? What will you do with it if it fails because of this?
thanks,
greg k-h
^ permalink raw reply
* [PATCH V4 03/12] drivers: Add boot constraints core
From: Greg Kroah-Hartman @ 2017-12-13 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2868a37e561cab91ba5495a1e14b9548c8e93c3e.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:51PM +0530, Viresh Kumar wrote:
> Some devices are powered ON by the bootloader before the bootloader
> handovers control to Linux. It maybe important for those devices to keep
> working until the time a Linux device driver probes the device and
> reconfigure its resources.
>
> A typical example of that can be the LCD controller, which is used by
> the bootloaders to show image(s) while the platform is booting into
> Linux. The LCD controller can be using some resources, like clk,
> regulators, PM domain, etc, that are shared between several devices.
> These shared resources should be configured to satisfy need of all the
> users. If another device's (X) driver gets probed before the LCD
> controller driver in this case, then it may end up reconfiguring these
> resources to ranges satisfying the current users (only device X) and
> that can make the LCD screen unstable.
>
> This patch introduces the concept of boot-constraints, which will be set
> by the bootloaders and the kernel will satisfy them until the time
> driver for such a device is probed (successfully or unsuccessfully).
>
> The list of boot constraint types is empty for now, and will be
> incrementally updated by later patches.
>
> Only two routines are exposed by the boot constraints core for now:
I think we need some documentation somewhere on how to use this, right?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 3/4] thermal: armada: add support for CP110
From: Baruch Siach @ 2017-12-13 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874lovq9cx.fsf@free-electrons.com>
Hi Gregory,
On Wed, Dec 13, 2017 at 10:13:02AM +0100, Gregory CLEMENT wrote:
> On mer., d?c. 13 2017, Baruch Siach <baruch@tkos.co.il> wrote:
[...]
> > There are two separate issues here:
> >
> > 1. DT binding
> >
> > 2. init_sensor callback implementation
> >
> > We both agree on #1. The A38x and CP110 need separate compatible strings. In
> > case we want to access the LSB control register on Armada 38x, we will need
> > yet another compatible string (marvell,armada380-v2-thermal maybe?).
>
> Actually, if it is _compatible_ then we will use the same compatible, ie
> "marvell,armadacp110-thermal"
Reusing the same compatible string for the same hardware peripheral in
different SoCs is not a good idea. You often find out later that they are not
actually the same.
But this point is moot. The A38x and CP110 thermal sensors are not the same.
The overheat interrupt registers are in different offsets.
> > As for #2, I'm all for sharing as much code as possible. I find the vendor
> > kernel approach of duplicating the init routines[1] unhelpful as it violates
> > the DRY principle. The differences between armada380_init_sensor() and
> > cp110_init_sensor() are minor. In my opinion, these differences should be
> > expressed explicitly in the armada_thermal_data, in a similar way to my
> > suggested control_msb_offset field. The vendor code hides these differences in
> > slight variations of duplicated code.
> >
> > What is the advantage of a separate init routine?
>
> The main advantage is to be able keep the armada380_init_sensor as the
> legacy init, and then being able to use the new armadacp110_init_sensor
> for the new binding.
I disagree, sorry. I don't think I can make my point any more clear than I
did.
I am fine with you or Miquel making the code changes that you think are
necessary. I'll comment on the code when I see it.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] ARM: exynos_defconfig - enable CONFIG_EXYNOS_IOMMU
From: Marek Szyprowski @ 2017-12-13 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212213110.20893-1-shuahkh@osg.samsung.com>
Hi Shuah,
On 2017-12-12 22:31, Shuah Khan wrote:
> EXYNOS_IOMMU is disabled in exynos_defconfig since it is known to cause
> boot failures on Exynos Chrome-books. The recommendation is for IOMMU to
> be enabled manually on systems as needed.
>
> A recent exynos_drm change added a warning message when EXYNOS_IOMMU is
> disabled. It is necessary to enable it to avoid the warning messages.
> A few initial tests have shown that enabling EXYNOS_IOMMU might be safe
> on Exynos Chrome-books.
>
> Enable CONFIG_EXYNOS_IOMMU in exynos_defconfig.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Due to some other changes in the order of operations during boot process,
power domains are initialized very early and because of the temporary
lack of devices (which are not yet added to the system), are turned off.
This practically stops FIMD for scanning framebuffer very early during
boot, before IOMMU gets initialized and "solves" the issue, which was
the reason to disable Exynos IOMMU by default.
Like I've already said, I've checked Exynos Snow Chromebook boots fine
with IOMMU support enabled, both with v4.15-rc3 and linux-next.
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/configs/exynos_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index f1d7834..0ccd5eb 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -281,6 +281,7 @@ CONFIG_DEVFREQ_GOV_POWERSAVE=y
> CONFIG_DEVFREQ_GOV_USERSPACE=y
> CONFIG_ARM_EXYNOS_BUS_DEVFREQ=y
> CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP=y
> +CONFIG_EXYNOS_IOMMU=y
> CONFIG_EXTCON=y
> CONFIG_EXTCON_MAX14577=y
> CONFIG_EXTCON_MAX77693=y
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] arm64: mm: Fix false positives in set_pte_at access/dirty race detection
From: Yisheng Xie @ 2017-12-13 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213092119.GB27222@arm.com>
Hi Will,
On 2017/12/13 17:21, Will Deacon wrote:
> Hi Yisheng,
>
> On Wed, Dec 13, 2017 at 09:01:23AM +0800, Yisheng Xie wrote:
>> On 2017/12/12 19:43, Will Deacon wrote:
>>> Jiankang reports that our race detection in set_pte_at is firing when
>>> copying the page tables in dup_mmap as a result of a fork(). In this
>>> situation, the page table isn't actually live and so there is no way
>>> that we can race with a concurrent update from the hardware page table
>>> walker.
>>>
>>> This patch reworks the race detection so that we require either the
>>> mm to match the current active_mm (i.e. currently installed in our TTBR0)
>>> or the mm_users count to be greater than 1, implying that the page table
>>> could be live in another CPU. The mm_users check might still be racy,
>>> but we'll avoid false positives and it's not realistic to validate that
>>> all the necessary locks are held as part of this assertion.
>>>
>>> Cc: Yisheng Xie <xieyisheng1@huawei.com>
>>> Reported-by: Jiankang Chen <chenjiankang1@huawei.com>
>>> Tested-by: Jiankang Chen <chenjiankang1@huawei.com>
>>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>>> ---
>>> arch/arm64/include/asm/pgtable.h | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>> index 3ff03a755c32..bdcc7f1c9d06 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -42,6 +42,8 @@
>>> #include <asm/cmpxchg.h>
>>> #include <asm/fixmap.h>
>>> #include <linux/mmdebug.h>
>>> +#include <linux/mm_types.h>
>>> +#include <linux/sched.h>
>>>
>>
>> Do you have compiled kernel after apply this patch? In our environment, it will
>> fail to compile kernel if include file here(I will attach some log later).
>> Instead, we move these included file after mmdebug.h, and I do not know whether
>> this is just my compiler's problem:
>
> It compiles fine for me. Are you seeing a problem building this on top of
> mainline? If so, what is your .config?
Oh, you have already moved it after #ifndef __ASSEMBLY__ , sorry for not finding
this when review this patch.
And I also have just compiled with this patch in mainline, is ok.
Thanks for your help.
Thanks
Yisheng Xie
>
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -42,6 +42,8 @@
>> #include <asm/cmpxchg.h>
>> #include <asm/fixmap.h>
>> #include <linux/mmdebug.h>
>> +#include <linux/mm_types.h>
>> +#include <linux/sched.h>
>>
>> Sorry for not having told you this information.
>>
>> Thanks
>> Yisheng Xie
>>
>> compiler err log: ==========
>> [...]
>> include/linux/mm_types_task.h:60: Error: unknown mnemonic `struct' -- `struct page_frag{'
>> include/asm-generic/preempt.h:9: Error: unknown mnemonic `static' -- `static inline int preempt_count(void)'
>> include/linux/mm_types_task.h:61: Error: unknown mnemonic `struct' -- `struct page*page'
>> include/asm-generic/preempt.h:10: Error: junk at end of line, first unrecognized character is `{'
>> include/linux/mm_types_task.h:63: Error: unknown mnemonic `__u32' -- `__u32 offset'
>> include/asm-generic/preempt.h:11: Error: unknown mnemonic `return' -- `return READ_ONCE(((struct thread_info*)current)->preempt_count)'
>> include/linux/mm_types_task.h:64: Error: unknown mnemonic `__u32' -- `__u32 size'
>> [...]
>
> This looks like the includes are being pulled into an assembly file, but
> this part is guarded by #ifndef __ASSEMBLY__ so I can't see how that could
> happen.
>
> Will
>
> .
>
^ permalink raw reply
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-13 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213083829.ptdeggbon3szmko4@verge.net.au>
Hello Simon,
thank you for your feedback.
> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
> > Add CMT[01] support to SoC DT.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
> > 1 file changed, 30 insertions(+)
>
> I was expecting the cmt nodes to be "disabled" in the SoC file
> and then enabled selectively in board files. Am I missing something?
Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific DT. The system will park it and leave its clock disabled until actually needed for something.
The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it disabled by default?
Thanks,
Fab
>
> Otherwise this patch looks good to me.
>
> > diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> > index 59860c8..0e2834a 100644
> > --- a/arch/arm/boot/dts/r8a7743.dtsi
> > +++ b/arch/arm/boot/dts/r8a7743.dtsi
> > @@ -262,6 +262,36 @@
> > IRQ_TYPE_LEVEL_LOW)>;
> > };
> >
> > +cmt0: timer at ffca0000 {
> > +compatible = "renesas,r8a7743-cmt0",
> > + "renesas,rcar-gen2-cmt0";
> > +reg = <0 0xffca0000 0 0x1004>;
> > +interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > +clocks = <&cpg CPG_MOD 124>;
> > +clock-names = "fck";
> > +power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> > +resets = <&cpg 124>;
> > +};
> > +
> > +cmt1: timer at e6130000 {
> > +compatible = "renesas,r8a7743-cmt1",
> > + "renesas,rcar-gen2-cmt1";
> > +reg = <0 0xe6130000 0 0x1004>;
> > +interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
> > +clocks = <&cpg CPG_MOD 329>;
> > +clock-names = "fck";
> > +power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> > +resets = <&cpg 329>;
> > +};
> > +
> > cpg: clock-controller at e6150000 {
> > compatible = "renesas,r8a7743-cpg-mssr";
> > reg = <0 0xe6150000 0 0x1000>;
> > --
> > 2.7.4
> >
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH V4 09/12] boot_constraint: Add earlycon helper
From: Greg Kroah-Hartman @ 2017-12-13 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f32e9a84a985e36cbff76df73faf0e3966d90ada.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:57PM +0530, Viresh Kumar wrote:
> Getting boot messages during initial kernel boot is a common problem,
> which (almost) everyone wants to solve. Considering that this would be
> required by multiple platforms, provide a helper to check if "earlycon"
> or "earlyprintk" boot arguments are passed to kernel or not. The
> platforms can use this helper to add serial constraints only if earlycon
> if required.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/boot_constraints/Makefile | 2 +-
> drivers/boot_constraints/serial.c | 28 ++++++++++++++++++++++++++++
> include/linux/boot_constraint.h | 2 ++
> 3 files changed, 31 insertions(+), 1 deletion(-)
> create mode 100644 drivers/boot_constraints/serial.c
>
> diff --git a/drivers/boot_constraints/Makefile b/drivers/boot_constraints/Makefile
> index a765094623a3..0d4f88bb767c 100644
> --- a/drivers/boot_constraints/Makefile
> +++ b/drivers/boot_constraints/Makefile
> @@ -1,3 +1,3 @@
> # Makefile for device boot constraints
>
> -obj-y := clk.o deferrable_dev.o core.o pm.o supply.o
> +obj-y := clk.o deferrable_dev.o core.o pm.o serial.o supply.o
> diff --git a/drivers/boot_constraints/serial.c b/drivers/boot_constraints/serial.c
> new file mode 100644
> index 000000000000..d0d07d4aa6af
> --- /dev/null
> +++ b/drivers/boot_constraints/serial.c
> @@ -0,0 +1,28 @@
> +/*
> + * This contains helpers related to serial boot constraints.
> + *
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2.
> + */
> +
> +#include <linux/init.h>
> +
> +static bool earlycon_boot_constraints_enabled __initdata;
> +
> +bool __init boot_constraint_earlycon_enabled(void)
> +{
> + return earlycon_boot_constraints_enabled;
> +}
> +
> +static int __init enable_earlycon_boot_constraints(char *str)
> +{
> + earlycon_boot_constraints_enabled = true;
> +
> + return 0;
> +}
> +__setup_param("earlycon", boot_constraint_earlycon,
> + enable_earlycon_boot_constraints, 0);
> +__setup_param("earlyprintk", boot_constraint_earlyprintk,
> + enable_earlycon_boot_constraints, 0);
> diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
> index c110b36e490f..aeada69b87e6 100644
> --- a/include/linux/boot_constraint.h
> +++ b/include/linux/boot_constraint.h
> @@ -10,6 +10,7 @@
> #define _LINUX_BOOT_CONSTRAINT_H
>
> #include <linux/err.h>
> +#include <linux/init.h>
> #include <linux/types.h>
>
> struct device;
> @@ -58,6 +59,7 @@ int dev_boot_constraint_add(struct device *dev,
> void dev_boot_constraints_remove(struct device *dev);
> void dev_boot_constraint_add_deferrable_of(struct dev_boot_constraint_of *oconst,
> int count);
> +bool __init boot_constraint_earlycon_enabled(void);
> #else
> static inline
> int dev_boot_constraint_add(struct device *dev,
No need for this function if it's not enabled?
And this feels really odd, does it really save any work for the
individual "constraint" to check for this option? I'm all for helper
functions, but this feels like more work than it's worth...
thanks,
greg k-h
^ permalink raw reply
* [PATCH V4 10/12] boot_constraint: Add support for Hisilicon platforms
From: Greg Kroah-Hartman @ 2017-12-13 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <facf1c5838468c8440240e2828a8e4982003a6f6.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:58PM +0530, Viresh Kumar wrote:
> This adds boot constraint support for Hisilicon platforms. Currently
> only one use case is supported: earlycon. One of the UART is enabled by
> the bootloader and is used for early console in the kernel. The boot
> constraint core handles it properly and removes constraints once the
> serial device is probed by its driver.
>
> This is tested on hi6220-hikey 96board.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> arch/arm64/Kconfig.platforms | 1 +
> drivers/boot_constraints/Makefile | 2 +
> drivers/boot_constraints/hikey.c | 145 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 148 insertions(+)
> create mode 100644 drivers/boot_constraints/hikey.c
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 6b54ee8c1262..265df4a088ab 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -87,6 +87,7 @@ config ARCH_HISI
> select ARM_TIMER_SP804
> select HISILICON_IRQ_MBIGEN if PCI
> select PINCTRL
> + select DEV_BOOT_CONSTRAINTS
> help
> This enables support for Hisilicon ARMv8 SoC family
>
> diff --git a/drivers/boot_constraints/Makefile b/drivers/boot_constraints/Makefile
> index 0d4f88bb767c..43c89d2458e9 100644
> --- a/drivers/boot_constraints/Makefile
> +++ b/drivers/boot_constraints/Makefile
> @@ -1,3 +1,5 @@
> # Makefile for device boot constraints
>
> obj-y := clk.o deferrable_dev.o core.o pm.o serial.o supply.o
> +
> +obj-$(CONFIG_ARCH_HISI) += hikey.o
> diff --git a/drivers/boot_constraints/hikey.c b/drivers/boot_constraints/hikey.c
> new file mode 100644
> index 000000000000..5f69f9451d93
> --- /dev/null
> +++ b/drivers/boot_constraints/hikey.c
> @@ -0,0 +1,145 @@
> +/*
> + * This takes care of Hisilicon boot time device constraints, normally set by
> + * the Bootloader.
> + *
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2.
> + */
> +
> +#include <linux/boot_constraint.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +
> +struct hikey_machine_constraints {
> + struct dev_boot_constraint_of *dev_constraints;
> + unsigned int count;
> +};
> +
> +static struct dev_boot_constraint_clk_info uart_iclk_info = {
> + .name = "uartclk",
> +};
> +
> +static struct dev_boot_constraint_clk_info uart_pclk_info = {
> + .name = "apb_pclk",
> +};
> +
> +static struct dev_boot_constraint hikey3660_uart_constraints[] = {
> + {
> + .type = DEV_BOOT_CONSTRAINT_CLK,
> + .data = &uart_iclk_info,
> + }, {
> + .type = DEV_BOOT_CONSTRAINT_CLK,
> + .data = &uart_pclk_info,
> + },
> +};
> +
> +static const char * const uarts_hikey3660[] = {
> + "serial at fff32000", /* UART 6 */
> +};
> +
> +static struct dev_boot_constraint_of hikey3660_dev_constraints[] = {
> + {
> + .compat = "arm,pl011",
> + .constraints = hikey3660_uart_constraints,
> + .count = ARRAY_SIZE(hikey3660_uart_constraints),
> +
> + .dev_names = uarts_hikey3660,
> + .dev_names_count = ARRAY_SIZE(uarts_hikey3660),
> + },
> +};
> +
> +static struct hikey_machine_constraints hikey3660_constraints = {
> + .dev_constraints = hikey3660_dev_constraints,
> + .count = ARRAY_SIZE(hikey3660_dev_constraints),
> +};
> +
> +static const char * const uarts_hikey6220[] = {
> + "uart at f7113000", /* UART 3 */
> +};
> +
> +static struct dev_boot_constraint_of hikey6220_dev_constraints[] = {
> + {
> + .compat = "arm,pl011",
> + .constraints = hikey3660_uart_constraints,
> + .count = ARRAY_SIZE(hikey3660_uart_constraints),
> +
> + .dev_names = uarts_hikey6220,
> + .dev_names_count = ARRAY_SIZE(uarts_hikey6220),
> + },
> +};
> +
> +static struct hikey_machine_constraints hikey6220_constraints = {
> + .dev_constraints = hikey6220_dev_constraints,
> + .count = ARRAY_SIZE(hikey6220_dev_constraints),
> +};
> +
> +static struct dev_boot_constraint hikey3798cv200_uart_constraints[] = {
> + {
> + .type = DEV_BOOT_CONSTRAINT_CLK,
> + .data = &uart_pclk_info,
> + },
> +};
> +
> +static const char * const uarts_hikey3798cv200[] = {
> + "serial at 8b00000", /* UART 0 */
> +};
> +
> +static struct dev_boot_constraint_of hikey3798cv200_dev_constraints[] = {
> + {
> + .compat = "arm,pl011",
> + .constraints = hikey3798cv200_uart_constraints,
> + .count = ARRAY_SIZE(hikey3798cv200_uart_constraints),
> +
> + .dev_names = uarts_hikey3798cv200,
> + .dev_names_count = ARRAY_SIZE(uarts_hikey3798cv200),
> + },
> +};
> +
> +static struct hikey_machine_constraints hikey3798cv200_constraints = {
> + .dev_constraints = hikey3798cv200_dev_constraints,
> + .count = ARRAY_SIZE(hikey3798cv200_dev_constraints),
> +};
> +
> +static const struct of_device_id machines[] __initconst = {
> + { .compatible = "hisilicon,hi3660", .data = &hikey3660_constraints },
> + { .compatible = "hisilicon,hi3798cv200", .data = &hikey3798cv200_constraints },
> + { .compatible = "hisilicon,hi6220", .data = &hikey6220_constraints },
> + { }
> +};
> +
> +static int __init hikey_constraints_init(void)
> +{
> + const struct hikey_machine_constraints *constraints;
> + const struct of_device_id *match;
> + struct device_node *np;
> +
> + if (!boot_constraint_earlycon_enabled())
> + return 0;
> +
> + np = of_find_node_by_path("/");
What is this for?
> + if (!np)
> + return -ENODEV;
> +
> + match = of_match_node(machines, np);
> + of_node_put(np);
> +
> + if (!match)
> + return 0;
> +
> + constraints = match->data;
> + BUG_ON(!constraints);
Never crash the device for a driver configuration issue. That's going
to be bad.
> + dev_boot_constraint_add_deferrable_of(constraints->dev_constraints,
> + constraints->count);
> +
> + return 0;
> +}
> +
> +/*
> + * The amba-pl011 driver registers itself from arch_initcall level. Setup the
> + * serial boot constraints before that in order not to miss any boot messages.
> + */
> +postcore_initcall_sync(hikey_constraints_init);
Now you have to worry about the bootconstraints earlycon being called
before/after your code. That's another linking order dependancy you
just created. It feels more complex for something so "simple" as
looking for the earlycon flag...
thanks,
greg k-h
^ permalink raw reply
* [PATCH V4 06/12] boot_constraint: Add support for PM constraints
From: Greg Kroah-Hartman @ 2017-12-13 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000268f9c5b06354333a18dbe26fc8b052231ed8.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:54PM +0530, Viresh Kumar wrote:
> This patch adds the PM constraint type.
>
> The constraint is set by attaching the power domain for the device,
> which will also enable the power domain. This guarantees that the power
> domain doesn't get shut down while being used.
>
> We don't need to detach the power domain to remove the constraint as the
> domain is attached only once, from here or before driver probe.
>
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/boot_constraints/Makefile | 2 +-
> drivers/boot_constraints/core.c | 4 ++++
> drivers/boot_constraints/core.h | 3 +++
> drivers/boot_constraints/pm.c | 24 ++++++++++++++++++++++++
> include/linux/boot_constraint.h | 1 +
> 5 files changed, 33 insertions(+), 1 deletion(-)
> create mode 100644 drivers/boot_constraints/pm.c
>
> diff --git a/drivers/boot_constraints/Makefile b/drivers/boot_constraints/Makefile
> index 3424379fd1e4..b7ade1a7afb5 100644
> --- a/drivers/boot_constraints/Makefile
> +++ b/drivers/boot_constraints/Makefile
> @@ -1,3 +1,3 @@
> # Makefile for device boot constraints
>
> -obj-y := clk.o core.o supply.o
> +obj-y := clk.o core.o pm.o supply.o
> diff --git a/drivers/boot_constraints/core.c b/drivers/boot_constraints/core.c
> index 9213e56e8078..f4d3520ddb04 100644
> --- a/drivers/boot_constraints/core.c
> +++ b/drivers/boot_constraints/core.c
> @@ -98,6 +98,10 @@ static struct constraint *constraint_allocate(struct constraint_dev *cdev,
> add = constraint_clk_add;
> remove = constraint_clk_remove;
> break;
> + case DEV_BOOT_CONSTRAINT_PM:
> + add = constraint_pm_add;
> + remove = constraint_pm_remove;
> + break;
> case DEV_BOOT_CONSTRAINT_SUPPLY:
> add = constraint_supply_add;
> remove = constraint_supply_remove;
> diff --git a/drivers/boot_constraints/core.h b/drivers/boot_constraints/core.h
> index 4f28ac2ef691..a051c3d7c8ab 100644
> --- a/drivers/boot_constraints/core.h
> +++ b/drivers/boot_constraints/core.h
> @@ -33,6 +33,9 @@ struct constraint {
> int constraint_clk_add(struct constraint *constraint, void *data);
> void constraint_clk_remove(struct constraint *constraint);
>
> +int constraint_pm_add(struct constraint *constraint, void *data);
> +void constraint_pm_remove(struct constraint *constraint);
> +
> int constraint_supply_add(struct constraint *constraint, void *data);
> void constraint_supply_remove(struct constraint *constraint);
>
> diff --git a/drivers/boot_constraints/pm.c b/drivers/boot_constraints/pm.c
> new file mode 100644
> index 000000000000..edba5eca5093
> --- /dev/null
> +++ b/drivers/boot_constraints/pm.c
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2.
> + */
> +
> +#define pr_fmt(fmt) "PM Boot Constraints: " fmt
You don't use this :(
^ permalink raw reply
* [PATCH V4 05/12] boot_constraint: Add support for clk constraints
From: Greg Kroah-Hartman @ 2017-12-13 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb9fb79a1486bc2ed62cfb2257db44b1498ad66e.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:53PM +0530, Viresh Kumar wrote:
> This patch adds the clk constraint type.
>
> The constraint is set by enabling the clk for the device. Once the
> device is probed, the clk is disabled and the constraint is removed.
>
> We may want to do clk_set_rate() from here, but lets wait for some real
> users that really want it.
>
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/boot_constraints/Makefile | 2 +-
> drivers/boot_constraints/clk.c | 70 +++++++++++++++++++++++++++++++++++++++
> drivers/boot_constraints/core.c | 4 +++
> drivers/boot_constraints/core.h | 3 ++
> include/linux/boot_constraint.h | 5 +++
> 5 files changed, 83 insertions(+), 1 deletion(-)
> create mode 100644 drivers/boot_constraints/clk.c
>
> diff --git a/drivers/boot_constraints/Makefile b/drivers/boot_constraints/Makefile
> index a45616f0c3b0..3424379fd1e4 100644
> --- a/drivers/boot_constraints/Makefile
> +++ b/drivers/boot_constraints/Makefile
> @@ -1,3 +1,3 @@
> # Makefile for device boot constraints
>
> -obj-y := core.o supply.o
> +obj-y := clk.o core.o supply.o
> diff --git a/drivers/boot_constraints/clk.c b/drivers/boot_constraints/clk.c
> new file mode 100644
> index 000000000000..b5b1d63c3e76
> --- /dev/null
> +++ b/drivers/boot_constraints/clk.c
> @@ -0,0 +1,70 @@
> +/*
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2.
> + */
> +
> +#define pr_fmt(fmt) "Clock Boot Constraints: " fmt
You don't use this :(
^ permalink raw reply
* [PATCH V4 04/12] boot_constraint: Add support for supply constraints
From: Greg Kroah-Hartman @ 2017-12-13 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e171b6a496a6f5645804d9ed9cb53b4bcbe75a0.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:52PM +0530, Viresh Kumar wrote:
> This patch adds the first constraint type: power-supply.
>
> The constraint is set by enabling the regulator and setting a voltage
> range (if required) for the respective regulator device, which will be
> honored by the regulator core even if more users turn up. Once the
> device is probed, the regulator is released and the constraint is
> removed.
>
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/boot_constraints/Makefile | 2 +-
> drivers/boot_constraints/core.c | 4 ++
> drivers/boot_constraints/core.h | 3 ++
> drivers/boot_constraints/supply.c | 98 +++++++++++++++++++++++++++++++++++++++
> include/linux/boot_constraint.h | 8 +++-
> 5 files changed, 113 insertions(+), 2 deletions(-)
> create mode 100644 drivers/boot_constraints/supply.c
>
> diff --git a/drivers/boot_constraints/Makefile b/drivers/boot_constraints/Makefile
> index 0f2680177974..a45616f0c3b0 100644
> --- a/drivers/boot_constraints/Makefile
> +++ b/drivers/boot_constraints/Makefile
> @@ -1,3 +1,3 @@
> # Makefile for device boot constraints
>
> -obj-y := core.o
> +obj-y := core.o supply.o
> diff --git a/drivers/boot_constraints/core.c b/drivers/boot_constraints/core.c
> index 366a05d6d9ba..b9c024a3bdf5 100644
> --- a/drivers/boot_constraints/core.c
> +++ b/drivers/boot_constraints/core.c
> @@ -94,6 +94,10 @@ static struct constraint *constraint_allocate(struct constraint_dev *cdev,
> void (*remove)(struct constraint *constraint);
>
> switch (type) {
> + case DEV_BOOT_CONSTRAINT_SUPPLY:
> + add = constraint_supply_add;
> + remove = constraint_supply_remove;
> + break;
> default:
> return ERR_PTR(-EINVAL);
> }
> diff --git a/drivers/boot_constraints/core.h b/drivers/boot_constraints/core.h
> index 7ba4ac172c09..73b9d2d22a12 100644
> --- a/drivers/boot_constraints/core.h
> +++ b/drivers/boot_constraints/core.h
> @@ -30,4 +30,7 @@ struct constraint {
> };
>
> /* Forward declarations of constraint specific callbacks */
> +int constraint_supply_add(struct constraint *constraint, void *data);
> +void constraint_supply_remove(struct constraint *constraint);
> +
> #endif /* _CORE_H */
> diff --git a/drivers/boot_constraints/supply.c b/drivers/boot_constraints/supply.c
> new file mode 100644
> index 000000000000..30f816dbf12c
> --- /dev/null
> +++ b/drivers/boot_constraints/supply.c
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2.
> + */
> +
> +#define pr_fmt(fmt) "Supply Boot Constraints: " fmt
And again :)
^ permalink raw reply
* [PATCH V4 07/12] boot_constraint: Add debugfs support
From: Greg Kroah-Hartman @ 2017-12-13 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a796de9a338d7d0876faa3ec99f5cb49315c893c.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:55PM +0530, Viresh Kumar wrote:
> This patch adds debugfs support for boot constraints. This is how it
> looks for a "vmmc-supply" constraint for the MMC device.
>
> $ ls -R /sys/kernel/debug/boot_constraints/
> /sys/kernel/debug/boot_constraints/:
> f723d000.dwmmc0
>
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0:
> clk-ciu pm-domain supply-vmmc supply-vmmcaux
>
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0/clk-ciu:
>
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0/pm-domain:
>
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0/supply-vmmc:
> u_volt_max u_volt_min
>
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0/supply-vmmcaux:
> u_volt_max u_volt_min
>
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/boot_constraints/clk.c | 3 ++
> drivers/boot_constraints/core.c | 60 +++++++++++++++++++++++++++++++++++++++
> drivers/boot_constraints/core.h | 6 ++++
> drivers/boot_constraints/pm.c | 11 +++++--
> drivers/boot_constraints/supply.c | 9 ++++++
> 5 files changed, 87 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/boot_constraints/clk.c b/drivers/boot_constraints/clk.c
> index b5b1d63c3e76..91b7b538ef32 100644
> --- a/drivers/boot_constraints/clk.c
> +++ b/drivers/boot_constraints/clk.c
> @@ -49,6 +49,8 @@ int constraint_clk_add(struct constraint *constraint, void *data)
> cclk->clk_info.name = kstrdup_const(clk_info->name, GFP_KERNEL);
> constraint->private = cclk;
>
> + constraint_add_debugfs(constraint, clk_info->name);
> +
> return 0;
>
> put_clk:
> @@ -63,6 +65,7 @@ void constraint_clk_remove(struct constraint *constraint)
> {
> struct constraint_clk *cclk = constraint->private;
>
> + constraint_remove_debugfs(constraint);
> kfree_const(cclk->clk_info.name);
> clk_disable_unprepare(cclk->clk);
> clk_put(cclk->clk);
> diff --git a/drivers/boot_constraints/core.c b/drivers/boot_constraints/core.c
> index f4d3520ddb04..707ffac690fc 100644
> --- a/drivers/boot_constraints/core.c
> +++ b/drivers/boot_constraints/core.c
> @@ -24,6 +24,64 @@
> static LIST_HEAD(constraint_devices);
> static DEFINE_MUTEX(constraint_devices_mutex);
>
> +/* Debugfs */
> +
> +static struct dentry *rootdir;
> +
> +static void constraint_device_add_debugfs(struct constraint_dev *cdev)
> +{
> + struct device *dev = cdev->dev;
> +
> + cdev->dentry = debugfs_create_dir(dev_name(dev), rootdir);
> +}
> +
> +static void constraint_device_remove_debugfs(struct constraint_dev *cdev)
> +{
> + debugfs_remove_recursive(cdev->dentry);
> +}
> +
> +void constraint_add_debugfs(struct constraint *constraint, const char *suffix)
> +{
> + struct device *dev = constraint->cdev->dev;
> + const char *prefix;
> + char name[NAME_MAX];
> +
> + switch (constraint->type) {
> + case DEV_BOOT_CONSTRAINT_CLK:
> + prefix = "clk";
> + break;
> + case DEV_BOOT_CONSTRAINT_PM:
> + prefix = "pm";
> + break;
> + case DEV_BOOT_CONSTRAINT_SUPPLY:
> + prefix = "supply";
> + break;
> + default:
> + dev_err(dev, "%s: Constraint type (%d) not supported\n",
> + __func__, constraint->type);
> + return;
> + }
> +
> + snprintf(name, NAME_MAX, "%s-%s", prefix, suffix);
> +
> + constraint->dentry = debugfs_create_dir(name, constraint->cdev->dentry);
> +}
> +
> +void constraint_remove_debugfs(struct constraint *constraint)
> +{
> + debugfs_remove_recursive(constraint->dentry);
> +}
> +
> +static int __init constraint_debugfs_init(void)
> +{
> + /* Create /sys/kernel/debug/opp directory */
> + rootdir = debugfs_create_dir("boot_constraints", NULL);
Your comment makes no sense at all, it would be better, and correct, to
have no comment at all :)
^ permalink raw reply
* [PATCH V4 08/12] boot_constraint: Manage deferrable constraints
From: Greg Kroah-Hartman @ 2017-12-13 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88c7a0a6421d267c118f501ea1e920b04649002d.1509284255.git.viresh.kumar@linaro.org>
On Sun, Oct 29, 2017 at 07:18:56PM +0530, Viresh Kumar wrote:
> It is possible that some of the resources aren't available at the time
> constraints are getting set and the boot constraints core will return
> -EPROBE_DEFER for them. In order to retry adding the constraints at a
> later point of time (after the resource is added and before any of its
> users come up), this patch proposes two things:
>
> - Each constraint is represented by a virtual platform device, so that
> it is re-probed again until the time all the dependencies aren't met.
> The platform device is removed along with the constraint, with help of
> the free_resources() callback.
>
> - Enable early defer probing support by calling
> driver_enable_deferred_probe(), so that the core retries probing
> deferred devices every time any device is bound to a driver. This
> makes sure that the constraint is set before any of the users of the
> resources come up.
>
> This is tested on ARM64 Hikey board where probe was deferred for a
> device.
>
> Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/base/dd.c | 12 ++
> drivers/boot_constraints/Makefile | 2 +-
> drivers/boot_constraints/deferrable_dev.c | 235 ++++++++++++++++++++++++++++++
> include/linux/boot_constraint.h | 14 ++
> 4 files changed, 262 insertions(+), 1 deletion(-)
> create mode 100644 drivers/boot_constraints/deferrable_dev.c
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 4eec27fe2b2b..19eff5d08b9a 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -228,6 +228,18 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +/**
> + * driver_enable_deferred_probe() - Enable probing of deferred devices
> + *
> + * We don't want to get in the way when the bulk of drivers are getting probed
> + * and so deferred probe is disabled in the beginning. Enable it now because we
> + * need it.
> + */
> +void driver_enable_deferred_probe(void)
> +{
> + driver_deferred_probe_enable = true;
> +}
> +
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> *
> diff --git a/drivers/boot_constraints/Makefile b/drivers/boot_constraints/Makefile
> index b7ade1a7afb5..a765094623a3 100644
> --- a/drivers/boot_constraints/Makefile
> +++ b/drivers/boot_constraints/Makefile
> @@ -1,3 +1,3 @@
> # Makefile for device boot constraints
>
> -obj-y := clk.o core.o pm.o supply.o
> +obj-y := clk.o deferrable_dev.o core.o pm.o supply.o
> diff --git a/drivers/boot_constraints/deferrable_dev.c b/drivers/boot_constraints/deferrable_dev.c
> new file mode 100644
> index 000000000000..04056f317aff
> --- /dev/null
> +++ b/drivers/boot_constraints/deferrable_dev.c
> @@ -0,0 +1,235 @@
> +/*
> + * Copyright (C) 2017 Linaro.
> + * Viresh Kumar <viresh.kumar@linaro.org>
> + *
> + * This file is released under the GPLv2.
> + */
> +
> +#define pr_fmt(fmt) "Boot Constraints: " fmt
Hey, you use this one!
But you shouldn't :)
> +/* This only creates platform devices for now */
> +static void add_deferrable_of_single(struct device_node *np,
> + struct dev_boot_constraint *constraints,
> + int count)
> +{
> + struct device *dev;
> + int ret;
> +
> + if (!of_device_is_available(np))
> + return;
> +
> + ret = of_platform_bus_create(np, NULL, NULL, NULL, false);
> + if (ret)
> + return;
> +
> + if (of_device_is_compatible(np, "arm,primecell")) {
Why is "arm,primecell" in the core code here?
> + struct amba_device *adev = of_find_amba_device_by_node(np);
> +
> + if (!adev) {
> + pr_err("Failed to find amba dev: %s\n", np->full_name);
Never use pr_* when you have a valid struct device to use. Don't you
have one from the struct device_node * passed in here?
> + return;
> + }
> + dev = &adev->dev;
> + } else {
> + struct platform_device *pdev = of_find_device_by_node(np);
> +
> + if (!pdev) {
> + pr_err("Failed to find pdev: %s\n", np->full_name);
Same here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH V4 00/12] drivers: Boot Constraints core
From: Greg Kroah-Hartman @ 2017-12-13 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128041818.GE11413@vireshk-i7>
On Tue, Nov 28, 2017 at 09:48:18AM +0530, Viresh Kumar wrote:
> On 29-10-17, 19:18, Viresh Kumar wrote:
> > Here is V4 of the boot constraints core based on your feedback from V3.
> > We now have support for three platforms (as you suggested) included in
> > this series: Hisilicon, IMX and Qualcomm.
>
> Hi Greg,
>
> I was waiting for rc1 to come out before sending a reminder for this
> series and so here is one :)
I've reviewed it enough for now, needs a tiny bit of work, but looking
much better, nice job!
gre gk-h
^ permalink raw reply
* [PATCH V4 03/12] drivers: Add boot constraints core
From: Viresh Kumar @ 2017-12-13 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213094205.GB13194@kroah.com>
On 13-12-17, 10:42, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:51PM +0530, Viresh Kumar wrote:
> > + /*
> > + * Remove boot constraints for both successful and unsuccessful probe(),
> > + * except for the case where EPROBE_DEFER is returned by probe().
> > + */
> > + if (ret != -EPROBE_DEFER)
> > + dev_boot_constraints_remove(dev);
>
> This feels odd, but ok, I trust you :)
I did this because it may not be right to keep the boot constraints up for a
device that failed to probe. For example, a LCD screen may continue wasting
power if its device failed to probe. At least I would like to see a real case
where we don't want to remove the constraints here on probe failure.
> > +/* Forward declarations of constraint specific callbacks */
> > +#endif /* _CORE_H */
>
> What is this comment at the end of the file for?
Perhaps this should be moved to a later patch.
Ack for every other comment you gave.
--
viresh
^ permalink raw reply
* [PATCH V4 03/12] drivers: Add boot constraints core
From: Viresh Kumar @ 2017-12-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213094227.GC13194@kroah.com>
On 13-12-17, 10:42, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:51PM +0530, Viresh Kumar wrote:
> > Some devices are powered ON by the bootloader before the bootloader
> > handovers control to Linux. It maybe important for those devices to keep
> > working until the time a Linux device driver probes the device and
> > reconfigure its resources.
> >
> > A typical example of that can be the LCD controller, which is used by
> > the bootloaders to show image(s) while the platform is booting into
> > Linux. The LCD controller can be using some resources, like clk,
> > regulators, PM domain, etc, that are shared between several devices.
> > These shared resources should be configured to satisfy need of all the
> > users. If another device's (X) driver gets probed before the LCD
> > controller driver in this case, then it may end up reconfiguring these
> > resources to ranges satisfying the current users (only device X) and
> > that can make the LCD screen unstable.
> >
> > This patch introduces the concept of boot-constraints, which will be set
> > by the bootloaders and the kernel will satisfy them until the time
> > driver for such a device is probed (successfully or unsuccessfully).
> >
> > The list of boot constraint types is empty for now, and will be
> > incrementally updated by later patches.
> >
> > Only two routines are exposed by the boot constraints core for now:
>
> I think we need some documentation somewhere on how to use this, right?
Will add that in next version.
--
viresh
^ permalink raw reply
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Geert Uytterhoeven @ 2017-12-13 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <TY1PR06MB0895B34EFC2A48F49AFF0694C0350@TY1PR06MB0895.apcprd06.prod.outlook.com>
Hi Fabrizio,
On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
>> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
>> > Add CMT[01] support to SoC DT.
>> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
>> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>> > ---
>> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
>> > 1 file changed, 30 insertions(+)
>>
>> I was expecting the cmt nodes to be "disabled" in the SoC file
>> and then enabled selectively in board files. Am I missing something?
>
> Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific DT. The system will park it and leave its clock disabled until actually needed for something.
> The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it disabled by default?
It's debatable (thus up to Simon the maintainer ;-).
For I/O devices, we disable them in the SoC .dtsi file.
For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
them enabled.
Timers are core functionality, but who's actually using these timers?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
From: Vladimir Murzin @ 2017-12-13 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-2-git-send-email-alexandre.torgue@st.com>
On 12/12/17 18:02, Alexandre Torgue wrote:
> On cortex-M7 MCU, DMA have to use a non cache-able memory area. For this
> reason a dedicated memory pool is created for DMA.
> This patch creates a DMA memory pool of 1MB of each STM32 MCU which
> embeds a cortex-M7 expect stm32f746-disco. Indeed, as stm32f746-disco has
^^^^^^
except?
> only a 8MB SDRAM and it's tricky to reduce memory used by Kernel.
I guess that 1MB is a kind of "should be enough" estimate, probably something
along with [1] would give you exact numbers...
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>
> diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
> index 2d4e717..3f52a7b 100644
> --- a/arch/arm/boot/dts/stm32746g-eval.dts
> +++ b/arch/arm/boot/dts/stm32746g-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xc0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
> index 4463ca1..08699a2 100644
> --- a/arch/arm/boot/dts/stm32f769-disco.dts
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xC0000000 0x1000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc0f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts b/arch/arm/boot/dts/stm32h743i-disco.dts
> index 79e841d..104545a 100644
> --- a/arch/arm/boot/dts/stm32h743i-disco.dts
> +++ b/arch/arm/boot/dts/stm32h743i-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart2;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts b/arch/arm/boot/dts/stm32h743i-eval.dts
> index 9f0e72c..5bd4b16 100644
> --- a/arch/arm/boot/dts/stm32h743i-eval.dts
> +++ b/arch/arm/boot/dts/stm32h743i-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
>
Usage of dma-default looks correct to me, so FWIW
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
[1] https://lkml.org/lkml/2017/7/7/296
Vladimir
^ permalink raw reply
* [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Will Deacon @ 2017-12-13 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7352752.eljzo8O4u9@aspire.rjw.lan>
[adding Lorenzo, Sudeep and Hanjun -- see Rafael's comment below]
On Wed, Dec 13, 2017 at 01:22:59AM +0100, Rafael J. Wysocki wrote:
> On Monday, December 11, 2017 4:50:58 PM CET Prarit Bhargava wrote:
> > Other architectures can use SPCR to setup an early console or console
> > but the current code is ARM64 specific.
> >
> > Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
> > function acpi_arch_setup_console() that can be used for arch-specific
> > setup. Move flags into ACPI code. Update the Documention on the use of
> > the SPCR.
> >
> > [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
> > Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
> > mmio value. Move baud rate check earlier.
> >
> > Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>
> This mostly affects ARM64, so ACKs from that side are requisite for it.
>
> > Cc: linux-doc at vger.kernel.org
> > Cc: linux-kernel at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-pm at vger.kernel.org
> > Cc: linux-acpi at vger.kernel.org
> > Cc: linux-serial at vger.kernel.org
> > Cc: Bhupesh Sharma <bhsharma@redhat.com>
> > Cc: Lv Zheng <lv.zheng@intel.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: x86 at kernel.org
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Timur Tabi <timur@codeaurora.org>
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 6 +-
> > arch/arm64/kernel/acpi.c | 128 ++++++++++++++++-
> > drivers/acpi/Kconfig | 7 +-
> > drivers/acpi/spcr.c | 175 ++++++------------------
> > drivers/tty/serial/earlycon.c | 15 +-
> > include/linux/acpi.h | 11 +-
> > include/linux/serial_core.h | 2 -
> > 7 files changed, 184 insertions(+), 160 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 6571fbfdb2a1..0d173289c67e 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -914,9 +914,9 @@
> >
> > earlycon= [KNL] Output early console device and options.
> >
> > - When used with no options, the early console is
> > - determined by the stdout-path property in device
> > - tree's chosen node.
> > + [ARM64] The early console is determined by the
> > + stdout-path property in device tree's chosen node,
> > + or determined by the ACPI SPCR table.
> >
> > cdns,<addr>[,options]
> > Start an early, polled-mode console on a Cadence
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index b3162715ed78..b3e33bbdf3b7 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -25,7 +25,6 @@
> > #include <linux/memblock.h>
> > #include <linux/of_fdt.h>
> > #include <linux/smp.h>
> > -#include <linux/serial_core.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cpu_ops.h>
> > @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
> > return ret;
> > }
> >
> > +/*
> > + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> > + * occasionally getting stuck as 1. To avoid the potential for a hang, check
> > + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> > + * implementations, so only do so if an affected platform is detected in
> > + * acpi_parse_spcr().
> > + */
> > +bool qdf2400_e44_present;
> > +EXPORT_SYMBOL(qdf2400_e44_present);
> > +
> > +/*
> > + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> > + * Detect them by examining the OEM fields in the SPCR header, similar to PCI
> > + * quirk detection in pci_mcfg.c.
> > + */
> > +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> > +{
> > + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> > + return false;
> > +
> > + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> > + return true;
> > +
> > + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> > + h->oem_revision == 1)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +/*
> > + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> > + * register aligned to 32-bit. In addition, the BIOS also encoded the
> > + * access width to be 8 bits. This function detects this errata condition.
> > + */
> > +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > +{
> > + bool xgene_8250 = false;
> > +
> > + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> > + return false;
> > +
> > + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> > + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
> > + return false;
> > +
> > + if (!memcmp(tb->header.oem_table_id, "XGENESPC",
> > + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
> > + xgene_8250 = true;
> > +
> > + if (!memcmp(tb->header.oem_table_id, "ProLiant",
> > + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
> > + xgene_8250 = true;
> > +
> > + return xgene_8250;
> > +}
> > +
> > +int acpi_arch_setup_console(struct acpi_table_spcr *table,
> > + char *opts, char *uart, char *iotype,
> > + int baud_rate, bool earlycon)
> > +{
> > + if (table->header.revision < 2) {
> > + pr_err("wrong table version\n");
> > + return -ENOENT;
> > + }
> > +
> > + switch (table->interface_type) {
> > + case ACPI_DBG2_ARM_SBSA_32BIT:
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
> > + /* fall through */
> > + case ACPI_DBG2_ARM_PL011:
> > + case ACPI_DBG2_ARM_SBSA_GENERIC:
> > + case ACPI_DBG2_BCM2835:
> > + snprintf(uart, ACPI_SPCR_BUF_SIZE, "pl011");
> > + break;
> > + default:
> > + if (strlen(uart) == 0)
> > + return -ENOENT;
> > + }
> > +
> > + /*
> > + * If the E44 erratum is required, then we need to tell the pl011
> > + * driver to implement the work-around.
> > + *
> > + * The global variable is used by the probe function when it
> > + * creates the UARTs, whether or not they're used as a console.
> > + *
> > + * If the user specifies "traditional" earlycon, the qdf2400_e44
> > + * console name matches the EARLYCON_DECLARE() statement, and
> > + * SPCR is not used. Parameter "earlycon" is false.
> > + *
> > + * If the user specifies "SPCR" earlycon, then we need to update
> > + * the console name so that it also says "qdf2400_e44". Parameter
> > + * "earlycon" is true.
> > + *
> > + * For consistency, if we change the console name, then we do it
> > + * for everyone, not just earlycon.
> > + */
> > + if (qdf2400_erratum_44_present(&table->header)) {
> > + qdf2400_e44_present = true;
> > + if (earlycon)
> > + snprintf(uart, ACPI_SPCR_BUF_SIZE, "qdf2400_e44");
> > + }
> > +
> > + if (xgene_8250_erratum_present(table)) {
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
> > +
> > + /* for xgene v1 and v2 we don't know the clock rate of the
> > + * UART so don't attempt to change to the baud rate state
> > + * in the table because driver cannot calculate the dividers
> > + */
> > + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx", uart,
> > + iotype, table->serial_port.address);
> > + } else {
> > + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart,
> > + iotype, table->serial_port.address, baud_rate);
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(acpi_arch_setup_console);
> > +
> > /*
> > * acpi_boot_table_init() called from setup_arch(), always.
> > * 1. find RSDP and get its address, and then find XSDT
> > @@ -230,10 +351,11 @@ void __init acpi_boot_table_init(void)
> >
> > done:
> > if (acpi_disabled) {
> > - if (earlycon_init_is_deferred)
> > + if (console_acpi_spcr_enable)
> > early_init_dt_scan_chosen_stdout();
> > } else {
> > - parse_spcr(earlycon_init_is_deferred);
> > + /* Always enable the ACPI SPCR console */
> > + acpi_parse_spcr(console_acpi_spcr_enable);
> > if (IS_ENABLED(CONFIG_ACPI_BGRT))
> > acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> > }
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index 46505396869e..9ae98eeada76 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -79,7 +79,12 @@ config ACPI_DEBUGGER_USER
> > endif
> >
> > config ACPI_SPCR_TABLE
> > - bool
> > + bool "ACPI Serial Port Console Redirection Support"
> > + default y if ARM64
> > + help
> > + Enable support for Serial Port Console Redirection (SPCR) Table.
> > + This table provides information about the configuration of the
> > + earlycon console.
> >
> > config ACPI_LPIT
> > bool
> > diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> > index 324b35bfe781..f4bb8110e404 100644
> > --- a/drivers/acpi/spcr.c
> > +++ b/drivers/acpi/spcr.c
> > @@ -16,65 +16,18 @@
> > #include <linux/kernel.h>
> > #include <linux/serial_core.h>
> >
> > -/*
> > - * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> > - * occasionally getting stuck as 1. To avoid the potential for a hang, check
> > - * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> > - * implementations, so only do so if an affected platform is detected in
> > - * parse_spcr().
> > - */
> > -bool qdf2400_e44_present;
> > -EXPORT_SYMBOL(qdf2400_e44_present);
> > -
> > -/*
> > - * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> > - * Detect them by examining the OEM fields in the SPCR header, similiar to PCI
> > - * quirk detection in pci_mcfg.c.
> > - */
> > -static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> > -{
> > - if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> > - return false;
> > -
> > - if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> > - return true;
> > -
> > - if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> > - h->oem_revision == 1)
> > - return true;
> > -
> > - return false;
> > -}
> > -
> > -/*
> > - * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> > - * register aligned to 32-bit. In addition, the BIOS also encoded the
> > - * access width to be 8 bits. This function detects this errata condition.
> > - */
> > -static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > +int __weak acpi_arch_setup_console(struct acpi_table_spcr *table,
> > + char *opts, char *uart, char *iotype,
> > + int baud_rate, bool earlycon)
> > {
> > - bool xgene_8250 = false;
> > -
> > - if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> > - return false;
> > -
> > - if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> > - memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
> > - return false;
> > -
> > - if (!memcmp(tb->header.oem_table_id, "XGENESPC",
> > - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
> > - xgene_8250 = true;
> > -
> > - if (!memcmp(tb->header.oem_table_id, "ProLiant",
> > - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
> > - xgene_8250 = true;
> > -
> > - return xgene_8250;
> > + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart, iotype,
> > + table->serial_port.address, baud_rate);
> > + return 0;
> > }
> >
> > +bool console_acpi_spcr_enable __initdata;
> > /**
> > - * parse_spcr() - parse ACPI SPCR table and add preferred console
> > + * acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
> > *
> > * @earlycon: set up earlycon for the console specified by the table
> > *
> > @@ -86,13 +39,13 @@ static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > * from arch initialization code as soon as the DT/ACPI decision is made.
> > *
> > */
> > -int __init parse_spcr(bool earlycon)
> > +int __init acpi_parse_spcr(bool earlycon)
> > {
> > - static char opts[64];
> > + static char opts[ACPI_SPCR_OPTS_SIZE];
> > + static char uart[ACPI_SPCR_BUF_SIZE];
> > + static char iotype[ACPI_SPCR_BUF_SIZE];
> > struct acpi_table_spcr *table;
> > acpi_status status;
> > - char *uart;
> > - char *iotype;
> > int baud_rate;
> > int err;
> >
> > @@ -105,48 +58,6 @@ int __init parse_spcr(bool earlycon)
> > if (ACPI_FAILURE(status))
> > return -ENOENT;
> >
> > - if (table->header.revision < 2) {
> > - err = -ENOENT;
> > - pr_err("wrong table version\n");
> > - goto done;
> > - }
> > -
> > - if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> > - switch (ACPI_ACCESS_BIT_WIDTH((
> > - table->serial_port.access_width))) {
> > - default:
> > - pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
> > - case 8:
> > - iotype = "mmio";
> > - break;
> > - case 16:
> > - iotype = "mmio16";
> > - break;
> > - case 32:
> > - iotype = "mmio32";
> > - break;
> > - }
> > - } else
> > - iotype = "io";
> > -
> > - switch (table->interface_type) {
> > - case ACPI_DBG2_ARM_SBSA_32BIT:
> > - iotype = "mmio32";
> > - /* fall through */
> > - case ACPI_DBG2_ARM_PL011:
> > - case ACPI_DBG2_ARM_SBSA_GENERIC:
> > - case ACPI_DBG2_BCM2835:
> > - uart = "pl011";
> > - break;
> > - case ACPI_DBG2_16550_COMPATIBLE:
> > - case ACPI_DBG2_16550_SUBSET:
> > - uart = "uart";
> > - break;
> > - default:
> > - err = -ENOENT;
> > - goto done;
> > - }
> > -
> > switch (table->baud_rate) {
> > case 3:
> > baud_rate = 9600;
> > @@ -165,43 +76,36 @@ int __init parse_spcr(bool earlycon)
> > goto done;
> > }
> >
> > - /*
> > - * If the E44 erratum is required, then we need to tell the pl011
> > - * driver to implement the work-around.
> > - *
> > - * The global variable is used by the probe function when it
> > - * creates the UARTs, whether or not they're used as a console.
> > - *
> > - * If the user specifies "traditional" earlycon, the qdf2400_e44
> > - * console name matches the EARLYCON_DECLARE() statement, and
> > - * SPCR is not used. Parameter "earlycon" is false.
> > - *
> > - * If the user specifies "SPCR" earlycon, then we need to update
> > - * the console name so that it also says "qdf2400_e44". Parameter
> > - * "earlycon" is true.
> > - *
> > - * For consistency, if we change the console name, then we do it
> > - * for everyone, not just earlycon.
> > - */
> > - if (qdf2400_erratum_44_present(&table->header)) {
> > - qdf2400_e44_present = true;
> > - if (earlycon)
> > - uart = "qdf2400_e44";
> > + switch (table->interface_type) {
> > + case ACPI_DBG2_16550_COMPATIBLE:
> > + case ACPI_DBG2_16550_SUBSET:
> > + snprintf(uart, ACPI_SPCR_BUF_SIZE, "uart");
> > + break;
> > + default:
> > + break;
> > }
> >
> > - if (xgene_8250_erratum_present(table)) {
> > - iotype = "mmio32";
> > + if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> > + u8 width = ACPI_ACCESS_BIT_WIDTH((
> > + table->serial_port.access_width));
> > + switch (width) {
> > + default:
> > + pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
> > + case 8:
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio");
> > + break;
> > + case 16:
> > + case 32:
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio%d", width);
> > + break;
> > + }
> > + } else
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "io");
> >
> > - /* for xgene v1 and v2 we don't know the clock rate of the
> > - * UART so don't attempt to change to the baud rate state
> > - * in the table because driver cannot calculate the dividers
> > - */
> > - snprintf(opts, sizeof(opts), "%s,%s,0x%llx", uart, iotype,
> > - table->serial_port.address);
> > - } else {
> > - snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
> > - table->serial_port.address, baud_rate);
> > - }
> > + err = acpi_arch_setup_console(table, opts, uart, iotype, baud_rate,
> > + earlycon);
> > + if (err)
> > + goto done;
> >
> > pr_info("console: %s\n", opts);
> >
> > @@ -209,7 +113,6 @@ int __init parse_spcr(bool earlycon)
> > setup_earlycon(opts);
> >
> > err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
> > -
> > done:
> > acpi_put_table((struct acpi_table_header *)table);
> > return err;
> > diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> > index 4c8b80f1c688..b22afb62c7a3 100644
> > --- a/drivers/tty/serial/earlycon.c
> > +++ b/drivers/tty/serial/earlycon.c
> > @@ -196,26 +196,15 @@ int __init setup_earlycon(char *buf)
> > return -ENOENT;
> > }
> >
> > -/*
> > - * When CONFIG_ACPI_SPCR_TABLE is defined, "earlycon" without parameters in
> > - * command line does not start DT earlycon immediately, instead it defers
> > - * starting it until DT/ACPI decision is made. At that time if ACPI is enabled
> > - * call parse_spcr(), else call early_init_dt_scan_chosen_stdout()
> > - */
> > -bool earlycon_init_is_deferred __initdata;
> > -
> > /* early_param wrapper for setup_earlycon() */
> > static int __init param_setup_earlycon(char *buf)
> > {
> > int err;
> >
> > - /*
> > - * Just 'earlycon' is a valid param for devicetree earlycons;
> > - * don't generate a warning from parse_early_params() in that case
> > - */
> > + /* Just 'earlycon' is a valid param for devicetree and ACPI SPCR. */
> > if (!buf || !buf[0]) {
> > if (IS_ENABLED(CONFIG_ACPI_SPCR_TABLE)) {
> > - earlycon_init_is_deferred = true;
> > + console_acpi_spcr_enable = true;
> > return 0;
> > } else if (!buf) {
> > return early_init_dt_scan_chosen_stdout();
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index dc1ebfeeb5ec..875d7327d91c 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -1241,10 +1241,17 @@ static inline bool acpi_has_watchdog(void) { return false; }
> > #endif
> >
> > #ifdef CONFIG_ACPI_SPCR_TABLE
> > +#define ACPI_SPCR_OPTS_SIZE 64
> > +#define ACPI_SPCR_BUF_SIZE 32
> > extern bool qdf2400_e44_present;
> > -int parse_spcr(bool earlycon);
> > +extern bool console_acpi_spcr_enable __initdata;
> > +extern int acpi_arch_setup_console(struct acpi_table_spcr *table,
> > + char *opts, char *uart, char *iotype,
> > + int baud_rate, bool earlycon);
> > +int acpi_parse_spcr(bool earlycon);
> > #else
> > -static inline int parse_spcr(bool earlycon) { return 0; }
> > +static const bool console_acpi_spcr_enable;
> > +static inline int acpi_parse_spcr(bool earlycon) { return 0; }
> > #endif
> >
> > #if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
> > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> > index 37b044e78333..abfffb4b1c37 100644
> > --- a/include/linux/serial_core.h
> > +++ b/include/linux/serial_core.h
> > @@ -376,10 +376,8 @@ extern int of_setup_earlycon(const struct earlycon_id *match,
> > const char *options);
> >
> > #ifdef CONFIG_SERIAL_EARLYCON
> > -extern bool earlycon_init_is_deferred __initdata;
> > int setup_earlycon(char *buf);
> > #else
> > -static const bool earlycon_init_is_deferred;
> > static inline int setup_earlycon(char *buf) { return 0; }
> > #endif
> >
> >
>
>
^ permalink raw reply
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: Suzuki K Poulose @ 2017-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513160036-41377-1-git-send-email-gengdongjiu@huawei.com>
On 13/12/17 10:13, Dongjiu Geng wrote:
> ARM v8.4 extensions add new neon instructions for performing a
> multiplication of each FP16 element of one vector with the corresponding
> FP16 element of a second vector, and to add or subtract this without an
> intermediate rounding to the corresponding FP32 element in a third vector.
>
> This patch detects this feature and let the userspace know about it via a
> HWCAP bit and MRS emulation.
>
> Cc: Dave Martin <Dave.Martin@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Looks good to me.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513153607.2439.2.camel@Nokia-N900>
On Wed, Dec 13, 2017 at 9:26 AM, Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> On Wed Dec 13 08:34:22 2017 Linus Walleij <linus.walleij@linaro.org> wrote:
>> Arnd has been nudging me to do DT conversion for EP93xx
>> so if there are many active industrial users of these
>> I should prioritize it, because these things have 20+ years
>> support cycles.
>
> I'm not sure how important or necessary at all is to change anything in these legacy platforms.
I suspect that at several points in the next 5 to 10 years, we will remove
additional platforms or CPU types, as we tend to do when a platform
becomes a maintenance burden and is clearly not used by anyone.
It's hard to predict in advance what triggers the removal, but as the
number of platforms that are not using DT or ARCH_MULTIPLATFORM
goes down to a small number, there will be increased interested in either
removing or converting the remaining ones. This is not an immediate
danger at the moment, since we still have 14 platforms that are not
using ARCH_MULTIPLATFORM, and 23 that have remaining
board files, but you don't want to be the last user of the last platform
after the other ones are done ;-)
>> We also need to think about upholding support in GCC for
>> ARMv4(t) for the foreseeable future if there is a big web of
>> random deeply embedded systems out there that will need
>> updates.
>
> But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked 'deprecated'
and will likely be gone in gcc-8 (it's still there as of last week). ARMv4T
is going to be around for a while, and you can even keep building for
ARMv4 using "-march=armv4t -marm" when linking with 'ld --fix-v4bx'.
Debian recently did a survey to find out whether there were still users
on ARMv4 or ARMv4T, and the result was that probably everyone is
on ARMv5E or ARMv6 for the ARM port (which is separate from the
ARMHF port that is ARMv7+). See also
https://lists.debian.org/debian-user/2017/11/msg00379.html
and let them know quickly if you use Debian stable releases and
plan to update to Debian 10 (Buster) in the future.
Arnd
^ permalink raw reply
* [PATCH 2/3] ARM: configs: stm32: Enable ARM_MPU
From: Vladimir Murzin @ 2017-12-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-3-git-send-email-alexandre.torgue@st.com>
On 12/12/17 18:02, Alexandre Torgue wrote:
> STM32 MCUs embed a Memory Protection Unit. Enabling this setting will
> allow the Kernel to configure the MPU according to devicetree.
Would it be better to "select ARM_MPU" for machines with Cortex-M7?
Vladimir
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index bb358ff..e642bdf9 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -24,6 +24,7 @@ CONFIG_SET_MEM_PARAM=y
> CONFIG_DRAM_BASE=0x90000000
> CONFIG_FLASH_MEM_BASE=0x08000000
> CONFIG_FLASH_SIZE=0x00200000
> +CONFIG_ARM_MPU=y
> CONFIG_PREEMPT=y
> # CONFIG_ATAGS is not set
> CONFIG_ZBOOT_ROM_TEXT=0x0
>
^ permalink raw reply
* [PATCH V4 10/12] boot_constraint: Add support for Hisilicon platforms
From: Viresh Kumar @ 2017-12-13 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213094718.GE13194@kroah.com>
On 13-12-17, 10:47, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:58PM +0530, Viresh Kumar wrote:
> > +static const struct of_device_id machines[] __initconst = {
> > + { .compatible = "hisilicon,hi3660", .data = &hikey3660_constraints },
> > + { .compatible = "hisilicon,hi3798cv200", .data = &hikey3798cv200_constraints },
> > + { .compatible = "hisilicon,hi6220", .data = &hikey6220_constraints },
> > + { }
> > +};
> > +
> > +static int __init hikey_constraints_init(void)
> > +{
> > + const struct hikey_machine_constraints *constraints;
> > + const struct of_device_id *match;
> > + struct device_node *np;
> > +
> > + if (!boot_constraint_earlycon_enabled())
> > + return 0;
> > +
> > + np = of_find_node_by_path("/");
>
> What is this for?
We need to match the above list of "machines" with the root node and "np" here
points to the root node.. and ...
> > + if (!np)
> > + return -ENODEV;
> > +
> > + match = of_match_node(machines, np);
Its used here.
> > + of_node_put(np);
> > +/*
> > + * The amba-pl011 driver registers itself from arch_initcall level. Setup the
> > + * serial boot constraints before that in order not to miss any boot messages.
> > + */
> > +postcore_initcall_sync(hikey_constraints_init);
>
> Now you have to worry about the bootconstraints earlycon being called
> before/after your code.
For boot-constraints to work for any device, it is extremely important to add
the constraint before the device is probed by its driver, otherwise the driver
would end up re-configuring the resources. There is no other way then having
this order dependency here.
> That's another linking order dependancy you
> just created. It feels more complex for something so "simple" as
> looking for the earlycon flag...
--
viresh
^ permalink raw reply
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: Dongjiu Geng @ 2017-12-13 10:13 UTC (permalink / raw)
To: linux-arm-kernel
ARM v8.4 extensions add new neon instructions for performing a
multiplication of each FP16 element of one vector with the corresponding
FP16 element of a second vector, and to add or subtract this without an
intermediate rounding to the corresponding FP32 element in a third vector.
This patch detects this feature and let the userspace know about it via a
HWCAP bit and MRS emulation.
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
---
Change since v2:
1. Change the HWCAP_FHM to HWCAP_ASIMDFHM
Change since v1:
1. Address Dave and Suzuki's comments to update the commit message.
2. Address Dave's comments to update Documentation/arm64/elf_hwcaps.txt.
---
Documentation/arm64/cpu-feature-registers.txt | 4 +++-
Documentation/arm64/elf_hwcaps.txt | 4 ++++
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c | 2 ++
arch/arm64/kernel/cpuinfo.c | 1 +
6 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt
index bd9b3fa..a70090b 100644
--- a/Documentation/arm64/cpu-feature-registers.txt
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -110,7 +110,9 @@ infrastructure:
x--------------------------------------------------x
| Name | bits | visible |
|--------------------------------------------------|
- | RES0 | [63-48] | n |
+ | RES0 | [63-52] | n |
+ |--------------------------------------------------|
+ | FHM | [51-48] | y |
|--------------------------------------------------|
| DP | [47-44] | y |
|--------------------------------------------------|
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index 89edba1..57324ee 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -158,3 +158,7 @@ HWCAP_SHA512
HWCAP_SVE
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_ASIMDFHM
+
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..1818077 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -419,6 +419,7 @@
#define SCTLR_EL1_CP15BEN (1 << 5)
/* id_aa64isar0 */
+#define ID_AA64ISAR0_FHM_SHIFT 48
#define ID_AA64ISAR0_DP_SHIFT 44
#define ID_AA64ISAR0_SM4_SHIFT 40
#define ID_AA64ISAR0_SM3_SHIFT 36
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index cda76fa..f018c3d 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -43,5 +43,6 @@
#define HWCAP_ASIMDDP (1 << 20)
#define HWCAP_SHA512 (1 << 21)
#define HWCAP_SVE (1 << 22)
+#define HWCAP_ASIMDFHM (1 << 23)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..bc7e707 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
* sync with the documentation of the CPU feature register ABI.
*/
static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_FHM_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_DP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM4_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM3_SHIFT, 4, 0),
@@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unus
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM3),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM4),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDDP),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDFHM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 1e25545..7f94623 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -76,6 +76,7 @@
"asimddp",
"sha512",
"sve",
+ "asimdfhm",
NULL
};
--
1.9.1
^ permalink raw reply related
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