* [PATCH 1/2] KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
From: Christian Borntraeger @ 2018-06-19 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e4d21bf-d30f-ac66-3017-2badf6a29ec5@arm.com>
On 06/19/2018 12:10 PM, Marc Zyngier wrote:
> On 19/06/18 11:01, Mark Rutland wrote:
>> On Tue, Jun 19, 2018 at 10:42:50AM +0100, Marc Zyngier wrote:
>>> The current behaviour of the compat ioctls is a bit odd.
>>> We provide a compat_ioctl method when KVM_COMPAT is set, and NULL
>>> otherwise. But NULL means that the normal, non-compat ioctl should
>>> be used directly for compat tasks, and there is no way to actually
>>> prevent a compat task from issueing KVM ioctls.
>>>
>>> This patch changes this behaviour, by always registering a compat_ioctl
>>> method, even if KVM_COMPAT is not selected. In that case, the callback
>>> will always return -EINVAL.
>>>
>>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>> I virt/kvm/Kconfig we have:
>>
>> config KVM_COMPAT
>> def_bool y
>> depends on KVM && COMPAT && !S390
>>
>> ... and in arch/s390 we have COMPAT support, so does this potentially break
>> anything there?
>
> It doesn't seem to (COMPAT seems to support the 31 bit stuff, which I
> don't think ever had KVM support), but my s390-foo is quite basic.
>
> Christian, could you help here?
We do not support KVM for 31 bit. So the original goal of the KVM_COMPAT stuff
was to actually disable the compat thing for the KVM device driver.
See
commit de8e5d744051568c8aad ("KVM: Disable compat ioctl for s390").
Now looking back, this patch actually only disabled the compat wrappers and
still allows an 31bit process to run the 64bit ioctls. In theory this should
cause no issues as the 64bit ioctl must fence off all invalid input anyway
but actually forbidding KVM for compat processes is even better.
So I think this patch actually is a good thing.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
if you want you could even add a
Fixes: tag.
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: James Morse @ 2018-06-19 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpMoKP4eG5XhYe5hf5VC9MOY8KuHK=j0ujb8GFpyjAuAww@mail.gmail.com>
Hi Bhupesh,
On 19/06/18 11:37, Bhupesh Sharma wrote:
> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.morse@arm.com> wrote:
>> On 19/06/18 10:57, Jin, Yanjiang wrote:
>>>> -----Original Message-----
>>>> From: Will Deacon [mailto:will.deacon at arm.com]
>>>> Sent: 2018?6?19? 17:41
>>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>>>> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
>>>> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
>>>> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
>>>> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
>>>> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
>>>> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
>>>> kernel at lists.infradead.org>
>>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
>>>> linear region
>>>>>>> It is hard to know all above in kexec-tools now. Originally I
>>>>>>> planned to read memstart_addr's value from "/dev/mem", but someone
>>>>>>> thought not all Kernels enable "/dev/mem", we'd better find a more
>>>>>>> generic approach. So we want to get some suggestions from ARM kernel
>>>> community.
>>>>>>> Can we export this variable in Kernel side through sysconf() or
>>>>>>> other similar methods? Or someone can provide an effect way to get
>>>>>>> memstart_addr's value?
>>>>>>
>>>>>> I thought the suggestion from James was to expose this via an ELF
>>>>>> NOTE in kcore and vmcore (or in the header directly if that's possible, but I'm
>>>> not sure about it)?
>>>>>
>>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a
>>>>> must-have, so we can't depend on it.
>>>>
>>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
>>>>
>>>>> On the other hand, phys_to_virt() is called during generating vmcore
>>>>> in Kexec-tools, vmcore also can't help this issue.
>>>>
>>>> I don't understand this part. If you have the vmcore in your hand, why can't you
>>>> grok the pv offset from the note and use that in phys_to_virt()?
>>>
>>> It is a chicken-and-egg issue.
>>> phys_to virt() is for crashdump setup. To generate vmcore, we must call
>>> phys_to_virt(). At this point, no vmcore exists.
>>
>> Its needed for the parts of the ELF header that kexec-tools generates at kdump
>> load time?
>>
>> So adding this pv_offset to the key=value data crash_save_vmcoreinfo_init()
>> saves isn't available early enough?
> Yes, one case where it is not actually available early enough for
> makedumpfile usage is if we are determining the PT_NOTE contents from
> the '/proc/kcore' on a 'live' system
> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len)
>
> {
>
> <snip..>
> kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET;
>
> }
You are trying to read the vmcoreinfo through /proc/kcore given knowledge of its
physical address.
I'm suggesting adding the contents of vmcoreinfo as a PT_NOTE section of
/proc/kcore's ELF header. No special knowledge necessary, any elf-parser should
be able to dump the values.
> Now the problem at hand is to determine the offset at which the
> pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume
> that when you mentioned above and earlier about adding this pair to
> the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we
> can have 'n' number of PT_LOAD segments.
It looks like there is already a NOTE section with core info in there:
| # readelf -l /proc/kcore
|
| Elf file type is CORE (Core file)
| Entry point 0x0
| There are 16 program headers, starting at offset 64
|
| Program Headers:
| Type Offset VirtAddr PhysAddr
| FileSiz MemSiz Flags Align
| NOTE 0x00000000000003c0 0x0000000000000000 0x0000000000000000
| 0x0000000000001114 0x0000000000000000 0x0
I assume we can add more notes without breaking the existing user...
(and it looks like there are some broken __pa(kernel symbol) users in there.
Thanks,
James
^ permalink raw reply
* [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values from DT
From: Adrian Hunter @ 2018-06-19 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <SN6PR02MB49595D9202DDF98DA16C495CC17D0@SN6PR02MB4959.namprd02.prod.outlook.com>
On 14/06/18 08:38, Manish Narani wrote:
> Ping for RFC
What is eemi? Why aren't there patches for that?
>
>> -----Original Message-----
>> From: Manish Narani [mailto:manish.narani at xilinx.com]
>> Sent: Thursday, June 7, 2018 5:42 PM
>> To: robh+dt at kernel.org; mark.rutland at arm.com; catalin.marinas at arm.com;
>> will.deacon at arm.com; mdf at kernel.org; stefan.krsmanovic at aggios.com;
>> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
>> mmc at vger.kernel.org; devicetree at vger.kernel.org;
>> adrian.hunter at intel.com; michal.simek at xilinx.com; ulf.hansson at linaro.org
>> Cc: Manish Narani <MNARANI@xilinx.com>
>> Subject: [RFC PATCH 3/3] sdhci: arasan: Add support to read Tap Delay values
>> from DT
>>
>> This patch adds support for reading Tap Delay values from Device Tree and
>> write them via eemi calls. The macros containing these tap delay values are
>> removed from the driver.
>>
>> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
>> ---
>> drivers/mmc/host/sdhci-of-arasan.c | 131
>> +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 131 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-
>> of-arasan.c
>> index e3332a5..fc0fd01 100644
>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>> @@ -36,6 +36,8 @@
>>
>> #define PHY_CLK_TOO_SLOW_HZ 400000
>>
>> +#define MMC_BANK2 0x2
>> +
>> /*
>> * On some SoCs the syscon area has a feature where the upper 16-bits of
>> * each 32-bit register act as a write mask for the lower 16-bits. This allows
>> @@ -90,6 +92,10 @@ struct sdhci_arasan_data {
>> struct sdhci_host *host;
>> struct clk *clk_ahb;
>> struct phy *phy;
>> + u32 mio_bank;
>> + u32 device_id;
>> + u32 itapdly[MMC_TIMING_MMC_HS400 + 1];
>> + u32 otapdly[MMC_TIMING_MMC_HS400 + 1];
>> bool is_phy_on;
>>
>> bool has_cqe;
>> @@ -160,11 +166,36 @@ static int sdhci_arasan_syscon_write(struct
>> sdhci_host *host,
>> return ret;
>> }
>>
>> +/**
>> + * arasan_zynqmp_set_tap_delay - Program the tap delays.
>> + * @deviceid: Unique Id of device
>> + * @itap_delay: Input Tap Delay
>> + * @oitap_delay: Output Tap Delay
>> + */
>> +static void arasan_zynqmp_set_tap_delay(u8 deviceid, u8 itap_delay, u8
>> +otap_delay) {
>> + const struct zynqmp_eemi_ops *eemi_ops =
>> zynqmp_pm_get_eemi_ops();
>> + u32 node_id = (deviceid == 0) ? NODE_SD_0 : NODE_SD_1;
>> +
>> + if (!eemi_ops || !eemi_ops->ioctl)
>> + return;
>> +
>> + if (itap_delay)
>> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
>> + PM_TAPDELAY_INPUT, itap_delay, NULL);
>> +
>> + if (otap_delay)
>> + eemi_ops->ioctl(node_id, IOCTL_SET_SD_TAPDELAY,
>> + PM_TAPDELAY_OUTPUT, otap_delay, NULL);
>> }
>> +
>> static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int
>> clock) {
>> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> struct sdhci_arasan_data *sdhci_arasan =
>> sdhci_pltfm_priv(pltfm_host);
>> bool ctrl_phy = false;
>> + u8 itap_delay;
>> + u8 otap_delay;
>>
>> if (!IS_ERR(sdhci_arasan->phy)) {
>> if (!sdhci_arasan->is_phy_on && clock <=
>> PHY_CLK_TOO_SLOW_HZ) { @@ -200,6 +231,16 @@ static void
>> sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
>> }
>> }
>>
>> + if (host->version >= SDHCI_SPEC_300) {
>> + if ((host->timing != MMC_TIMING_LEGACY) &&
>> + (host->timing != MMC_TIMING_UHS_SDR12)) {
>> + itap_delay = sdhci_arasan->itapdly[host->timing];
>> + otap_delay = sdhci_arasan->otapdly[host->timing];
>> + arasan_zynqmp_set_tap_delay(sdhci_arasan-
>>> device_id,
>> + itap_delay, otap_delay);
>> + }
>> + }
>> +
>> if (ctrl_phy && sdhci_arasan->is_phy_on) {
>> phy_power_off(sdhci_arasan->phy);
>> sdhci_arasan->is_phy_on = false;
>> @@ -456,6 +497,7 @@ static const struct of_device_id
>> sdhci_arasan_of_match[] = {
>> { .compatible = "arasan,sdhci-8.9a" },
>> { .compatible = "arasan,sdhci-5.1" },
>> { .compatible = "arasan,sdhci-4.9a" },
>> + { .compatible = "xlnx,zynqmp-8.9a" },
>>
>> { /* sentinel */ }
>> };
>> @@ -641,6 +683,74 @@ static void sdhci_arasan_unregister_sdclk(struct
>> device *dev)
>> of_clk_del_provider(dev->of_node);
>> }
>>
>> +/**
>> + * arasan_zynqmp_dt_parse_tap_delays - Read Tap Delay values from DT
>> + *
>> + * Called at initialization to parse the values of Tap Delays.
>> + *
>> + * @dev: Pointer to our struct device.
>> + */
>> +static void arasan_zynqmp_dt_parse_tap_delays(struct device *dev) {
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct sdhci_host *host = platform_get_drvdata(pdev);
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_arasan_data *sdhci_arasan =
>> sdhci_pltfm_priv(pltfm_host);
>> + struct device_node *np = dev->of_node;
>> +
>> + of_property_read_u32(np, "xlnx,itap_delay_sd_hsd",
>> + &sdhci_arasan->itapdly[MMC_TIMING_SD_HS]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sd_hsd",
>> + &sdhci_arasan->otapdly[MMC_TIMING_SD_HS]);
>> + of_property_read_u32(np, "xlnx,itap_delay_sdr25",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR25]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sdr25",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR25]);
>> + of_property_read_u32(np, "xlnx,itap_delay_sdr50",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR50]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sdr50",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR50]);
>> + of_property_read_u32(np, "xlnx,itap_delay_sd_ddr50",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_DDR50]);
>> + of_property_read_u32(np, "xlnx,otap_delay_sd_ddr50",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_DDR50]);
>> + of_property_read_u32(np, "xlnx,itap_delay_mmc_hsd",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_HS]);
>> + of_property_read_u32(np, "xlnx,otap_delay_mmc_hsd",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_HS]);
>> + of_property_read_u32(np, "xlnx,itap_delay_mmc_ddr50",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_DDR52]);
>> + of_property_read_u32(np, "xlnx,otap_delay_mmc_ddr50",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_DDR52]);
>> + if (sdhci_arasan->mio_bank == MMC_BANK2) {
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_sdr104_b2",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_sdr104_b2",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_mmc_hs200_b2",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_HS200]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_mmc_hs200_b2",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_HS200]);
>> + } else {
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_sdr104_b0",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_sdr104_b0",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_UHS_SDR104]);
>> + of_property_read_u32(np,
>> + "xlnx,itap_delay_mmc_hs200_b0",
>> + &sdhci_arasan-
>>> itapdly[MMC_TIMING_MMC_HS200]);
>> + of_property_read_u32(np,
>> + "xlnx,otap_delay_mmc_hs200_b0",
>> + &sdhci_arasan-
>>> otapdly[MMC_TIMING_MMC_HS200]);
>> + }
>> +}
>> +
>> static int sdhci_arasan_add_host(struct sdhci_arasan_data *sdhci_arasan) {
>> struct sdhci_host *host = sdhci_arasan->host; @@ -776,6 +886,27
>> @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>> goto unreg_clk;
>> }
>>
>> + if (of_device_is_compatible(pdev->dev.of_node,
>> + "xlnx,zynqmp-8.9a")) {
>> + ret = of_property_read_u32(pdev->dev.of_node,
>> + "xlnx,mio_bank",
>> + &sdhci_arasan->mio_bank);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev,
>> + "\"xlnx,mio_bank \" property is missing.\n");
>> + goto clk_disable_all;
>> + }
>> + ret = of_property_read_u32(pdev->dev.of_node,
>> + "xlnx,device_id",
>> + &sdhci_arasan->device_id);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev,
>> + "\"xlnx,device_id \" property is missing.\n");
>> + goto clk_disable_all;
>> + }
>> + arasan_zynqmp_dt_parse_tap_delays(&pdev->dev);
>> + }
>> +
>> sdhci_arasan->phy = ERR_PTR(-ENODEV);
>> if (of_device_is_compatible(pdev->dev.of_node,
>> "arasan,sdhci-5.1")) {
>> --
>> 2.7.4
>
>
^ permalink raw reply
* [PATCHv3 03/19] arm64: introduce sysreg_clear_set()
From: Catalin Marinas @ 2018-06-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-4-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:54PM +0100, Mark Rutland wrote:
> Currently we have a couple of helpers to manipulate bits in particular
> sysregs:
>
> * config_sctlr_el1(u32 clear, u32 set)
>
> * change_cpacr(u64 val, u64 mask)
>
> The parameters of these differ in naming convention, order, and size,
> which is unfortunate. They also differ slightly in behaviour, as
> change_cpacr() skips the sysreg write if the bits are unchanged, which
> is a useful optimization when sysreg writes are expensive.
>
> Before we gain more yet another sysreg manipulation function, let's
> unify these with a common helper, providing a consistent order for
> clear/set operands, and the write skipping behaviour from
> change_cpacr(). Code will be migrated to the new helper in subsequent
> patches.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCHv3 04/19] arm64: kill config_sctlr_el1()
From: Catalin Marinas @ 2018-06-19 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-5-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:55PM +0100, Mark Rutland wrote:
> Now that we have sysreg_clear_set(), we can consistently use this
> instead of config_sctlr_el1().
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* dynamic reservation and allocation of physically contiguous memory using CMA
From: Marek Szyprowski @ 2018-06-19 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DF0025E0-5C00-4566-82D2-F3599F206210@cisco.com>
Hi Amit,
On 2018-06-18 20:23, Amit Chandra (amichand) wrote:
>
> Hi experts,
>
> I had a question related to CMA. I have been trying to use the CMA
> infra to reserve and allocate physically contiguous memory dynamically
> at runtime.
>
> I built a custom kernel based on linux-4.14.47 to invoke the cma
> initialization apis at runtime from kernel loadable module.
>
> I invoke cma_declare_contiguous() followed by cma_init_reserved_areas().
>
> cma_declare_contiguous throws no surprises and succeeds. The issue
> happens when cma_init_reserved_areas() is invoked post that.
>
> Here is the kernel log snippet post that call:
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.593218] cma:
> cma_declare_contiguous(size 0x0000000200000000, base
> 0x0000000000000000, limit 0x0000000000000000 alignment 0x0000000000000000)
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.593228] cma: Reserved
> 8192 MiB at 0x0000001d4d000000
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.593345] BUG: Bad page
> state in process insmod? pfn:1d4d000
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.595758]
> page:ffffefc335340000 count:0 mapcount:-127 mapping:????????? (null)
> index:0x0
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.599193] flags:
> 0x57fffc000000000()
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.600751] raw:
> 057fffc000000000 0000000000000000 0000000000000000 00000000ffffff80
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.603946] raw:
> ffffefc335330020 ffffefc335350020 000000000000000a 0000000000000000
>
> Jun 15 03:30:31 ubuntu-quickstart kernel: [? 384.607152] page dumped
> because: nonzero mapcount
>
> I am having a hard time trying to understand why the mapcount is less
> than 0 here. I figured this is happening in the call to __free_pages()
> from init_cma_reserved_pageblock().
>
> Any pointers here would be really helpful. If I am missing any step
> for cma reservation, please do let me know.
>
> Thanks in advance.
>
CMA initialization is possible only on very early boot stage. CMA will
not work as dynamic module.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCHv3 05/19] arm64: kill change_cpacr()
From: Catalin Marinas @ 2018-06-19 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-6-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:56PM +0100, Mark Rutland wrote:
> Now that we have sysreg_clear_set(), we can use this instead of
> change_cpacr().
>
> Note that the order of the set and clear arguments differs between
> change_cpacr() and sysreg_clear_set(), so these are flipped as part of
> the conversion. Also, sve_user_enable() redundantly clears
> CPACR_EL1_ZEN_EL0EN before setting it; this is removed for clarity.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCHv3 03/19] arm64: introduce sysreg_clear_set()
From: Marc Zyngier @ 2018-06-19 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-4-mark.rutland@arm.com>
On 18/06/18 13:02, Mark Rutland wrote:
> Currently we have a couple of helpers to manipulate bits in particular
> sysregs:
>
> * config_sctlr_el1(u32 clear, u32 set)
>
> * change_cpacr(u64 val, u64 mask)
>
> The parameters of these differ in naming convention, order, and size,
> which is unfortunate. They also differ slightly in behaviour, as
> change_cpacr() skips the sysreg write if the bits are unchanged, which
> is a useful optimization when sysreg writes are expensive.
>
> Before we gain more yet another sysreg manipulation function, let's
> unify these with a common helper, providing a consistent order for
> clear/set operands, and the write skipping behaviour from
> change_cpacr(). Code will be migrated to the new helper in subsequent
> patches.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reviewed-by: Dave Martin <dave.martin@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 48ad361c178e..fefc17dae8ee 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -731,6 +731,17 @@ asm(
> asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
> } while (0)
>
> +/*
> + * Modify bits in a sysreg. Bits in the clear mask are zeroed, then bits in the
> + * set mask are set. Other bits are left as-is.
> + */
> +#define sysreg_clear_set(sysreg, clear, set) do { \
> + u64 __scs_val = read_sysreg(sysreg); \
> + u64 __scs_new = (__scs_val & ~(u64)(clear)) | (set); \
> + if (__scs_new != __scs_val) \
> + write_sysreg(__scs_new, sysreg); \
> +} while (0)
> +
> static inline void config_sctlr_el1(u32 clear, u32 set)
> {
> u32 val;
>
For the record, I have this patch as part of Dave's FPSIMD/SVE fixes.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv3 02/19] arm64: move SCTLR_EL{1,2} assertions to <asm/sysreg.h>
From: Mark Rutland @ 2018-06-19 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-3-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:53PM +0100, Mark Rutland wrote:
> Currently we assert that the SCTLR_EL{1,2}_{SET,CLEAR} bits are
> self-consistent with an assertion in config_sctlr_el1(). This is a bit
> unusual, since config_sctlr_el1() doesn't make use of these definitions,
> and is far away from the definitions themselves.
>
> We can use the CPP #error directive to have equivalent assertions in
> <asm/sysreg.h>, next to the definitions of the set/clear bits, which is
> a bit clearer and simpler.
>
> At the same time, lets fill in the upper 32 bits for both registers in
> their repsective RES0 definitions. This could be a little nicer with
Typo: s/repsective/respective/
I've fixed that up locally.
Mark.
^ permalink raw reply
* [Dev] [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Mark Brown @ 2018-06-19 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619111018.r3m35g4ei6625pqz@holly.lan>
On Tue, Jun 19, 2018 at 12:10:18PM +0100, Daniel Thompson wrote:
> On Mon, Jun 18, 2018 at 09:45:51AM +0200, Linus Walleij wrote:
> > - I am especially curious about input from Andy and Mika from
> > the Intel/ACPI camp on what they have seen for non-discoverable
> > plug-in boards. Does this problem even exist in the Intel
> > world, or not...
> I'm also interested in the "what about ACPI" question?
> Using C makes describing a board in ACPI fairly easy. AFAICT allocating
> IDs to a board rather than its included components is fairly natural for
> ACPI.
Yes, they have this problem - they have plug in modules on for example
the minnowboard and some of their other reference platforms. They have
overlays working for ACPI, these have their own problems in that they
don't appear to have the equivalent of DMI data (at least the patches
people are sending indicates that they don't) which is unfortuate as the
idiomatic thing for ACPI is as you say to key huge chunks of data of
quirk tables based on the DMI information for their boards.
They don't to my knowledge have generic connectors or anything like
that, it's just patches to the base ACPI.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/fed9da48/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-19 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0d40351-8d78-fd69-cc87-d5ea5eaabd2a@arm.com>
Hi James,
On Tue, Jun 19, 2018 at 4:56 PM, James Morse <james.morse@arm.com> wrote:
> Hi Bhupesh,
>
> On 19/06/18 11:37, Bhupesh Sharma wrote:
>> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.morse@arm.com> wrote:
>>> On 19/06/18 10:57, Jin, Yanjiang wrote:
>>>>> -----Original Message-----
>>>>> From: Will Deacon [mailto:will.deacon at arm.com]
>>>>> Sent: 2018?6?19? 17:41
>>>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>>>>> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
>>>>> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
>>>>> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
>>>>> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
>>>>> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
>>>>> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
>>>>> kernel at lists.infradead.org>
>>>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
>>>>> linear region
>
>>>>>>>> It is hard to know all above in kexec-tools now. Originally I
>>>>>>>> planned to read memstart_addr's value from "/dev/mem", but someone
>>>>>>>> thought not all Kernels enable "/dev/mem", we'd better find a more
>>>>>>>> generic approach. So we want to get some suggestions from ARM kernel
>>>>> community.
>>>>>>>> Can we export this variable in Kernel side through sysconf() or
>>>>>>>> other similar methods? Or someone can provide an effect way to get
>>>>>>>> memstart_addr's value?
>>>>>>>
>>>>>>> I thought the suggestion from James was to expose this via an ELF
>>>>>>> NOTE in kcore and vmcore (or in the header directly if that's possible, but I'm
>>>>> not sure about it)?
>>>>>>
>>>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a
>>>>>> must-have, so we can't depend on it.
>>>>>
>>>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
>>>>>
>>>>>> On the other hand, phys_to_virt() is called during generating vmcore
>>>>>> in Kexec-tools, vmcore also can't help this issue.
>>>>>
>>>>> I don't understand this part. If you have the vmcore in your hand, why can't you
>>>>> grok the pv offset from the note and use that in phys_to_virt()?
>>>>
>>>> It is a chicken-and-egg issue.
>>>> phys_to virt() is for crashdump setup. To generate vmcore, we must call
>>>> phys_to_virt(). At this point, no vmcore exists.
>>>
>>> Its needed for the parts of the ELF header that kexec-tools generates at kdump
>>> load time?
>>>
>>> So adding this pv_offset to the key=value data crash_save_vmcoreinfo_init()
>>> saves isn't available early enough?
>
>> Yes, one case where it is not actually available early enough for
>> makedumpfile usage is if we are determining the PT_NOTE contents from
>> the '/proc/kcore' on a 'live' system
>
>> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len)
>>
>> {
>>
>> <snip..>
>> kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET;
>>
>> }
>
> You are trying to read the vmcoreinfo through /proc/kcore given knowledge of its
> physical address.
>
> I'm suggesting adding the contents of vmcoreinfo as a PT_NOTE section of
> /proc/kcore's ELF header. No special knowledge necessary, any elf-parser should
> be able to dump the values.
>
>
>> Now the problem at hand is to determine the offset at which the
>> pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume
>> that when you mentioned above and earlier about adding this pair to
>> the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we
>> can have 'n' number of PT_LOAD segments.
>
> It looks like there is already a NOTE section with core info in there:
> | # readelf -l /proc/kcore
> |
> | Elf file type is CORE (Core file)
> | Entry point 0x0
> | There are 16 program headers, starting at offset 64
> |
> | Program Headers:
> | Type Offset VirtAddr PhysAddr
> | FileSiz MemSiz Flags Align
> | NOTE 0x00000000000003c0 0x0000000000000000 0x0000000000000000
> | 0x0000000000001114 0x0000000000000000 0x0
>
> I assume we can add more notes without breaking the existing user...
>
> (and it looks like there are some broken __pa(kernel symbol) users in there.
Thanks for your inputs.
I am working on fixes on the above lines for kernel and user-space
tools (like makedumpfile, crash-utility and kexec-tools).
I will post some RFC patches on the same lines (or come back in case I
get stuck somewhere) shortly.
Thanks,
Bhupesh
^ permalink raw reply
* [PATCHv3 06/19] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Catalin Marinas @ 2018-06-19 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-7-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:57PM +0100, Mark Rutland wrote:
> In subsequent patches, we'll want to make use of sve_user_enable() and
> sve_user_disable() outside of kernel/fpsimd.c. Let's move these to
> <asm/fpsimd.h> where we can make use of them.
>
> To avoid ifdeffery in sequences like:
>
> if (system_supports_sve() && some_condition
> sve_user_disable();
>
> ... empty stubs are provided when support for SVE is not enabled. Note
> that system_supports_sve() contains as IS_ENABLED(CONFIG_ARM64_SVE), so
> the sve_user_disable() call should be optimized away entirely when
> CONFIG_ARM64_SVE is not selected.
>
> To ensure that this is the case, the stub definitions contain a
> BUILD_BUG(), as we do for other stubs for which calls should always be
> optimized away when the relevant config option is not selected.
>
> At the same time, the include list of <asm/fpsimd.h> is sorted while
> adding <asm/sysreg.h>.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Xie XiuQi @ 2018-06-19 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmce60y3.fsf@e105922-lin.cambridge.arm.com>
Hi Punit,
On 2018/6/14 1:39, Punit Agrawal wrote:
> Punit Agrawal <punit.agrawal@arm.com> writes:
>
>
> [...]
>
>>
>> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end
>> up returning the original node in the fallback path.
>>
>> Xie, does the below patch help? I can submit a proper patch if this
>> fixes the issue for you.
>>
>> -- >8 --
>> Subject: [PATCH] arm64/numa: Enable memoryless numa nodes
>>
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> ---
>> arch/arm64/Kconfig | 4 ++++
>> arch/arm64/mm/numa.c | 2 ++
>> 2 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index eb2cf4938f6d..5317e9aa93ab 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -756,6 +756,10 @@ config USE_PERCPU_NUMA_NODE_ID
>> def_bool y
>> depends on NUMA
>>
>> +config HAVE_MEMORYLESS_NODES
>> + def_bool y
>> + depends on NUMA
>> +
>> config HAVE_SETUP_PER_CPU_AREA
>> def_bool y
>> depends on NUMA
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index dad128ba98bf..c699dcfe93de 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -73,6 +73,8 @@ EXPORT_SYMBOL(cpumask_of_node);
>> static void map_cpu_to_node(unsigned int cpu, int nid)
>> {
>> set_cpu_numa_node(cpu, nid);
>> + set_numa_mem(local_memory_node(nid));
>
> Argh, this should be
>
> set_cpu_numa_mem(cpu, local_memory_node(nid));
>
> There is not guarantee that map_cpu_to_node() will be called on the
> local cpu.
>
> Hanjun, Xie - can you try with the update please?
I've tested this patch, but it does not help.
The boot message is attached.
I tested on a arm board with 128 cores 4 numa nodes, but I set CONFIG_NR_CPUS=72.
Then node 3 is not be created, because node 3 has no memory, and no cpu.
But some pci device may related to node 3, which be set in ACPI table.
165 /* Interface called from ACPI code to setup PCI host controller */
166 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
167 {
168 int node = acpi_get_node(root->device->handle);
169 struct acpi_pci_generic_root_info *ri;
170 struct pci_bus *bus, *child;
171 struct acpi_pci_root_ops *root_ops;
172
// this node may be not created.
177 ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
178 if (!ri)
179 return NULL;
180
181 root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node);
182 if (!root_ops) {
183 kfree(ri);
184 return NULL;
185 }
186
187 ri->cfg = pci_acpi_setup_ecam_mapping(root);
188 if (!ri->cfg) {
189 kfree(ri);
190 kfree(root_ops);
191 return NULL;
192 }
>
> Thanks,
> Punit
>
>> +
>> if (nid >= 0)
>> cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
>> }
>
> .
>
--
Thanks,
Xie XiuQi
-------------- next part --------------
[ 0.000000] Booting Linux on physical CPU 0x0000030000 [0x480fd010]
[ 0.000000] Linux version 4.16.0-rc1-00491-g204a6cc-dirty (xiexiuqi at localhost.localdomain) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05)) #17 SMP PREEMPT Tue Jun 19 16:33:32 CST 2018
[ 0.000000] earlycon: pl11 at MMIO32 0x0000000094080000 (options '')
[ 0.000000] bootconsole [pl11] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.60 by EDK II
[ 0.000000] efi: SMBIOS 3.0=0x3eb60000 ACPI 2.0=0x39710000 MEMATTR=0x3b106418
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x0000000039710000 000024 (v02 HISI )
[ 0.000000] ACPI: XSDT 0x0000000039700000 000074 (v01 HISI HIP08 00000000 01000013)
[ 0.000000] ACPI: FACP 0x0000000039630000 000114 (v06 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: DSDT 0x00000000395C0000 006A1A (v02 HISI HIP08 00000000 INTL 20170929)
[ 0.000000] ACPI: GTDT 0x0000000039620000 000060 (v02 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: DBG2 0x0000000039610000 00005A (v00 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: MCFG 0x0000000039600000 00003C (v01 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: SLIT 0x00000000395F0000 00003C (v01 HISI HIP07 00000000 INTL 20151124)
[ 0.000000] ACPI: SRAT 0x00000000395E0000 0009C0 (v03 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: APIC 0x00000000395D0000 00286C (v04 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: IORT 0x00000000395B0000 00110C (v00 HISI HIP08 00000000 INTL 20170929)
[ 0.000000] ACPI: PPTT 0x00000000311F0000 0037D0 (v01 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: SPMI 0x00000000311E0000 000041 (v05 HISI HIP08 00000000 INTL 20151124)
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30000 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30001 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30002 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30003 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30100 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30101 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30102 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30103 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30200 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30201 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30202 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30203 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30300 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30301 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30302 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30303 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30400 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30401 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30402 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30403 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30500 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30501 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30502 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30503 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30600 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30601 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30602 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30603 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30700 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30701 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30702 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30703 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10000 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10001 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10002 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10003 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10100 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10101 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10102 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10103 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10200 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10201 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10202 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10203 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10300 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10301 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10302 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10303 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10400 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10401 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10402 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10403 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10500 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10501 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10502 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10503 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10600 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10601 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10602 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10603 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10700 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10701 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10702 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10703 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70000 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70001 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70002 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70003 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70100 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70101 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70102 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70103 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: cpu_to_node_map[72] is too small, may not be able to use all cpus
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x2080000000-0x23ffffffff]
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[ 0.000000] ACPI: SRAT: Node 2 PXM 2 [mem 0x402000000000-0x4023ffffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x23ffffe780-0x23ffffffff]
[ 0.000000] NUMA: Initmem setup node 1 [<memory-less node>]
[ 0.000000] NUMA: NODE_DATA [mem 0x4023fffed780-0x4023fffeefff]
[ 0.000000] NUMA: NODE_DATA(1) on node 2
[ 0.000000] NUMA: NODE_DATA [mem 0x4023fffebf00-0x4023fffed77f]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00004023ffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003942ffff]
[ 0.000000] node 0: [mem 0x0000000039430000-0x000000003956ffff]
[ 0.000000] node 0: [mem 0x0000000039570000-0x000000003963ffff]
[ 0.000000] node 0: [mem 0x0000000039640000-0x00000000396fffff]
[ 0.000000] node 0: [mem 0x0000000039700000-0x000000003971ffff]
[ 0.000000] node 0: [mem 0x0000000039720000-0x0000000039b6ffff]
[ 0.000000] node 0: [mem 0x0000000039b70000-0x000000003eb5ffff]
[ 0.000000] node 0: [mem 0x000000003eb60000-0x000000003eb8ffff]
[ 0.000000] node 0: [mem 0x000000003eb90000-0x000000003fbfffff]
[ 0.000000] node 0: [mem 0x0000002080000000-0x00000023ffffffff]
[ 0.000000] node 2: [mem 0x0000402000000000-0x00004023ffffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000023ffffffff]
[ 0.000000] Could not find start_pfn for node 1
[ 0.000000] Initmem setup node 1 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Initmem setup node 2 [mem 0x0000402000000000-0x00004023ffffffff]
[ 0.000000] psci: probing for conduit method from ACPI.
[ 0.000000] psci: PSCIv1.0 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.0
[ 0.000000] random: fast init done
[ 0.000000] percpu: Embedded 24 pages/cpu @ (ptrval) s59432 r8192 d30680 u98304
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] Built 3 zonelists, mobility grouping on. Total pages: 7998480
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: earlycon=pl011,mmio32,0x94080000 console=ttyAMA0,115200 initrd=minifs.cpio.gz acpi=force
[ 0.000000] log_buf_len individual max cpu contribution: 4096 bytes
[ 0.000000] log_buf_len total cpu_extra contributions: 290816 bytes
...
[ 0.141182] Platform MSI: ITS at 0x400202100000 domain created
[ 0.146793] PCI/MSI: ITS at 0x202100000 domain created
[ 0.151690] PCI/MSI: ITS at 0x400202100000 domain created
[ 0.156906] Remapping and enabling EFI services.
[ 0.161562] EFI remap 0x0000000039430000 => (ptrval)
[ 0.167431] EFI remap 0x0000000039480000 => (ptrval)
[ 0.173299] EFI remap 0x00000000394d0000 => (ptrval)
[ 0.179167] EFI remap 0x0000000039520000 => (ptrval)
[ 0.185037] EFI remap 0x0000000039650000 => (ptrval)
[ 0.190905] EFI remap 0x00000000396b0000 => (ptrval)
[ 0.196773] EFI remap 0x0000000039720000 => (ptrval)
[ 0.202639] EFI remap 0x0000000039770000 => (ptrval)
[ 0.208505] EFI remap 0x00000000397c0000 => (ptrval)
[ 0.214371] EFI remap 0x0000000039810000 => (ptrval)
[ 0.220236] EFI remap 0x0000000039860000 => (ptrval)
[ 0.226103] EFI remap 0x00000000398b0000 => (ptrval)
[ 0.231973] EFI remap 0x0000000039900000 => (ptrval)
[ 0.237840] EFI remap 0x0000000039970000 => (ptrval)
[ 0.243710] EFI remap 0x00000000399c0000 => (ptrval)
[ 0.249577] EFI remap 0x0000000039a10000 => (ptrval)
[ 0.255445] EFI remap 0x0000000039a60000 => (ptrval)
[ 0.261313] EFI remap 0x0000000039ab0000 => (ptrval)
[ 0.267184] EFI remap 0x0000000039b00000 => (ptrval)
[ 0.273047] EFI remap 0x000000003eb60000 => (ptrval)
[ 0.278907] EFI remap 0x0000000080000000 => (ptrval)
[ 0.284766] EFI remap 0x0000000202020000 => (ptrval)
[ 0.290626] EFI remap 0x0000000204000000 => (ptrval)
[ 0.296487] EFI remap 0x0000000206200000 => (ptrval)
[ 0.318359] smp: Bringing up secondary CPUs ...
[ 0.422473] Detected VIPT I-cache on CPU1
[ 0.422481] GICv3: CPU1: found redistributor 30001 region 1:0x00000000aa140000
[ 0.422502] CPU1: using LPI pending table @0x00000023ee480000
[ 0.422543] CPU1: Booted secondary processor 0x0000030001 [0x480fd010]
[ 0.522109] Detected VIPT I-cache on CPU2
[ 0.522115] GICv3: CPU2: found redistributor 30002 region 2:0x00000000aa180000
[ 0.522135] CPU2: using LPI pending table @0x00000023ee4b0000
[ 0.522175] CPU2: Booted secondary processor 0x0000030002 [0x480fd010]
[ 0.621751] Detected VIPT I-cache on CPU3
...
[ 7.328992] CPU70: Booted secondary processor 0x0000070102 [0x480fd010]
[ 7.435880] Detected VIPT I-cache on CPU71
[ 7.435931] GICv3: CPU71: found redistributor 70103 region 71:0x00004000aa2c0000
[ 7.435958] CPU71: using LPI pending table @0x00000023ed340000
[ 7.436037] CPU71: Booted secondary processor 0x0000070103 [0x480fd010]
[ 7.436131] smp: Brought up 3 nodes, 72 CPUs
[ 9.146250] SMP: Total of 72 processors activated.
[ 9.151067] CPU features: detected feature: GIC system register CPU interface
[ 9.158247] CPU features: detected feature: Privileged Access Never
...
[ 11.535050] pci 0000:74:02.0: BAR 5: assigned [mem 0xa2000000-0xa2007fff]
[ 11.541829] pci 0000:74:03.0: BAR 5: assigned [mem 0xa2008000-0xa2008fff]
[ 11.548610] pci 0000:75:00.0: BAR 2: assigned [mem 0x144000000-0x1443fffff 64bit pref]
[ 11.556518] pci 0000:75:00.0: BAR 9: assigned [mem 0x144400000-0x1447effff 64bit pref]
[ 11.564426] pci 0000:74:00.0: PCI bridge to [bus 75]
[ 11.569382] pci 0000:74:00.0: bridge window [mem 0x144000000-0x1447fffff 64bit pref]
[ 11.577332] ACPI: PCI Root Bridge [PCI6] (domain 0000 [bus 80-9f])
[ 11.583505] acpi PNP0A08:06: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 11.591850] acpi PNP0A08:06: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[ 11.599851] CPU002: pci_acpi_scan_root: 175 node 3, online 0
[ 11.605503] Unable to handle kernel paging request at virtual address 00001530
[ 11.612712] Mem abort info:
[ 11.615492] ESR = 0x96000004
[ 11.618534] Exception class = DABT (current EL), IL = 32 bits
[ 11.624440] SET = 0, FnV = 0
[ 11.627481] EA = 0, S1PTW = 0
[ 11.630608] Data abort info:
[ 11.633476] ISV = 0, ISS = 0x00000004
[ 11.637299] CM = 0, WnR = 0
[ 11.640254] [0000000000001530] user address but active_mm is swapper
[ 11.646594] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 11.652154] Modules linked in:
[ 11.655198] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc1-00491-g204a6cc-dirty #17
[ 11.663361] Hardware name: Huawei, 06/02/2018
[ 11.673174] pstate: 20c00089 (nzCv daIf +PAN +UAO)
[ 11.677955] pc : ___slab_alloc+0x60/0x590
[ 11.681952] lr : __slab_alloc.isra.24+0x58/0x70
[ 11.686469] sp : ffff00000981b870
[ 11.689771] x29: ffff00000981b870 x28: ffffc023eb8d8000
[ 11.695071] x27: ffff7e008fafd600 x26: ffff8023f0407c00
[ 11.700372] x25: ffff8023f0407c00 x24: ffff000008098da0
[ 11.705671] x23: 0000000000000003 x22: 00000000014080c0
[ 11.710971] x21: 0000000000000000 x20: 0000000000000003
[ 11.716271] x19: ffff8023f0b40870 x18: ffffffffffffffff
[ 11.721571] x17: 0000000000000000 x16: 000000000001c200
[ 11.726871] x15: ffff000009423b88 x14: ffff00008958c94f
[ 11.732171] x13: ffff00000958c95d x12: ffff00000943e858
[ 11.737471] x11: ffff00000943e000 x10: 0000000005f5e0ff
[ 11.742771] x9 : 00000000ffffffd0 x8 : 65646f6e20353731
[ 11.748071] x7 : 203a746f6f725f6e x6 : 00000000000002e8
[ 11.753371] x5 : 000000000000000a x4 : ffff8023f0b40870
[ 11.758670] x3 : ffff000008098da0 x2 : 0000000000000003
[ 11.763970] x1 : 0000000000000000 x0 : 0000000000000000
[ 11.769271] Process swapper/0 (pid: 1, stack limit = 0x00000000b21a776c)
[ 11.775958] Call trace:
[ 11.778392] ___slab_alloc+0x60/0x590
[ 11.782041] __slab_alloc.isra.24+0x58/0x70
[ 11.786212] kmem_cache_alloc_node+0xe0/0x240
[ 11.790556] pci_acpi_scan_root+0xb0/0x270
[ 11.794642] acpi_pci_root_add+0x29c/0x498
[ 11.798726] acpi_bus_attach+0x104/0x210
[ 11.802635] acpi_bus_attach+0xa4/0x210
[ 11.806458] acpi_bus_attach+0xa4/0x210
[ 11.810282] acpi_bus_scan+0x4c/0xb0
[ 11.813846] acpi_scan_init+0xec/0x24c
[ 11.817582] acpi_init+0x300/0x36c
[ 11.820972] do_one_initcall+0x50/0x158
[ 11.824797] kernel_init_freeable+0x188/0x228
[ 11.829141] kernel_init+0x10/0x100
[ 11.832617] ret_from_fork+0x10/0x18
[ 11.836181] Code: 90009081 93407e82 912ec021 f8627821 (f94a9821)
[ 11.842316] ---[ end trace 6b7476446f4b95ab ]---
[ 11.846936] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 11.846936]
[ 11.856079] SMP: stopping secondary CPUs
[ 11.860027] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 11.860027]
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Michal Hocko @ 2018-06-19 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b715082-14d4-f10b-d2d6-b23be7e4bf7e@huawei.com>
On Tue 19-06-18 20:03:07, Xie XiuQi wrote:
[...]
> I tested on a arm board with 128 cores 4 numa nodes, but I set CONFIG_NR_CPUS=72.
> Then node 3 is not be created, because node 3 has no memory, and no cpu.
> But some pci device may related to node 3, which be set in ACPI table.
Could you double check that zonelists for node 3 are generated
correctly?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCHv3 10/19] arm64: convert native/compat syscall entry to C
From: Dave Martin @ 2018-06-19 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-11-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:03:01PM +0100, Mark Rutland wrote:
> Now that the syscall invocation logic is in C, we can migrate the rest
> of the syscall entry logic over, so that the entry assembly needn't look
> at the register values at all.
>
> The SVE reset across syscall logic now unconditionally clears TIF_SVE,
> but sve_user_disable() will only write back to CPACR_EL1 when SVE is
> actually enabled.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/entry.S | 42 ++++--------------------------------------
> arch/arm64/kernel/syscall.c | 40 ++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 42 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 05b9f03f3e00..156c4e3fd1a4 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -720,14 +720,9 @@ el0_sync_compat:
> b.ge el0_dbg
> b el0_inv
> el0_svc_compat:
> - /*
> - * AArch32 syscall handling
> - */
> - ldr x16, [tsk, #TSK_TI_FLAGS] // load thread flags
> - adrp stbl, compat_sys_call_table // load compat syscall table pointer
> - mov wscno, w7 // syscall number in w7 (r7)
> - mov wsc_nr, #__NR_compat_syscalls
> - b el0_svc_naked
> + mov x0, sp
> + bl el0_svc_compat_handler
> + b ret_to_user
>
> .align 6
> el0_irq_compat:
> @@ -925,37 +920,8 @@ ENDPROC(ret_to_user)
> */
> .align 6
> el0_svc:
> - ldr x16, [tsk, #TSK_TI_FLAGS] // load thread flags
> - adrp stbl, sys_call_table // load syscall table pointer
> - mov wscno, w8 // syscall number in w8
> - mov wsc_nr, #__NR_syscalls
> -
> -#ifdef CONFIG_ARM64_SVE
> -alternative_if_not ARM64_SVE
> - b el0_svc_naked
> -alternative_else_nop_endif
> - tbz x16, #TIF_SVE, el0_svc_naked // Skip unless TIF_SVE set:
> - bic x16, x16, #_TIF_SVE // discard SVE state
> - str x16, [tsk, #TSK_TI_FLAGS]
> -
> - /*
> - * task_fpsimd_load() won't be called to update CPACR_EL1 in
> - * ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
> - * happens if a context switch or kernel_neon_begin() or context
> - * modification (sigreturn, ptrace) intervenes.
> - * So, ensure that CPACR_EL1 is already correct for the fast-path case:
> - */
> - mrs x9, cpacr_el1
> - bic x9, x9, #CPACR_EL1_ZEN_EL0EN // disable SVE for el0
> - msr cpacr_el1, x9 // synchronised by eret to el0
> -#endif
> -
> -el0_svc_naked: // compat entry point
> mov x0, sp
> - mov w1, wscno
> - mov w2, wsc_nr
> - mov x3, stbl
> - bl el0_svc_common
> + bl el0_svc_handler
> b ret_to_user
> ENDPROC(el0_svc)
>
> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> index 2adf1a073398..6a31bb2a382b 100644
> --- a/arch/arm64/kernel/syscall.c
> +++ b/arch/arm64/kernel/syscall.c
> @@ -6,7 +6,9 @@
> #include <linux/ptrace.h>
>
> #include <asm/daifflags.h>
> +#include <asm/fpsimd.h>
> #include <asm/thread_info.h>
> +#include <asm/unistd.h>
>
> long do_ni_syscall(struct pt_regs *regs);
>
> @@ -42,8 +44,8 @@ static inline bool has_syscall_work(unsigned long flags)
> int syscall_trace_enter(struct pt_regs *regs);
> void syscall_trace_exit(struct pt_regs *regs);
>
> -asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> - syscall_fn_t syscall_table[])
> +static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> + syscall_fn_t syscall_table[])
> {
> unsigned long flags = current_thread_info()->flags;
>
> @@ -80,3 +82,37 @@ asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
> trace_exit:
> syscall_trace_exit(regs);
> }
> +
> +static inline void sve_user_reset(void)
> +{
Can we call this "sve_user_discard" please?
"Reset" is a reasonable name for the concept, but the "discard"
terminology has been used elsewhere.
> + if (!system_supports_sve())
> + return;
> +
> + /*
> + * task_fpsimd_load() won't be called to update CPACR_EL1 in
> + * ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
> + * happens if a context switch or kernel_neon_begin() or context
> + * modification (sigreturn, ptrace) intervenes.
> + * So, ensure that CPACR_EL1 is already correct for the fast-path case.
> + */
This comment should go after clear_thead_flag(), since it describes not
the purpose of this function but the presence of sve_user_disable().
> + clear_thread_flag(TIF_SVE);
> + sve_user_disable();
> +}
> +
> +extern syscall_fn_t sys_call_table[];
> +
> +asmlinkage void el0_svc_handler(struct pt_regs *regs)
> +{
> + sve_user_reset();
> + el0_svc_common(regs, regs->regs[8], __NR_syscalls, sys_call_table);
> +}
> +
> +#ifdef CONFIG_COMPAT
> +extern syscall_fn_t compat_sys_call_table[];
> +
> +asmlinkage void el0_svc_compat_handler(struct pt_regs *regs)
> +{
> + el0_svc_common(regs, regs->regs[7], __NR_compat_syscalls,
> + compat_sys_call_table);
> +}
> +#endif
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv3 06/19] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Dave Martin @ 2018-06-19 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-7-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:57PM +0100, Mark Rutland wrote:
> In subsequent patches, we'll want to make use of sve_user_enable() and
> sve_user_disable() outside of kernel/fpsimd.c. Let's move these to
> <asm/fpsimd.h> where we can make use of them.
>
> To avoid ifdeffery in sequences like:
>
> if (system_supports_sve() && some_condition
> sve_user_disable();
>
> ... empty stubs are provided when support for SVE is not enabled. Note
> that system_supports_sve() contains as IS_ENABLED(CONFIG_ARM64_SVE), so
> the sve_user_disable() call should be optimized away entirely when
> CONFIG_ARM64_SVE is not selected.
>
> To ensure that this is the case, the stub definitions contain a
> BUILD_BUG(), as we do for other stubs for which calls should always be
> optimized away when the relevant config option is not selected.
>
> At the same time, the include list of <asm/fpsimd.h> is sorted while
> adding <asm/sysreg.h>.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
> ---
> arch/arm64/include/asm/fpsimd.h | 17 ++++++++++++++++-
> arch/arm64/kernel/fpsimd.c | 10 ----------
> 2 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index fa92747a49c8..dd1ad3950ef5 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -16,13 +16,15 @@
> #ifndef __ASM_FP_H
> #define __ASM_FP_H
>
> -#include <asm/ptrace.h>
> #include <asm/errno.h>
> +#include <asm/ptrace.h>
> #include <asm/processor.h>
> #include <asm/sigcontext.h>
> +#include <asm/sysreg.h>
>
> #ifndef __ASSEMBLY__
>
> +#include <linux/build_bug.h>
> #include <linux/cache.h>
> #include <linux/init.h>
> #include <linux/stddef.h>
> @@ -102,6 +104,16 @@ extern int sve_set_vector_length(struct task_struct *task,
> extern int sve_set_current_vl(unsigned long arg);
> extern int sve_get_current_vl(void);
>
> +static inline void sve_user_disable(void)
> +{
> + sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
> +}
> +
> +static inline void sve_user_enable(void)
> +{
> + sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
> +}
> +
> /*
> * Probing and setup functions.
> * Calls to these functions must be serialised with one another.
> @@ -128,6 +140,9 @@ static inline int sve_get_current_vl(void)
> return -EINVAL;
> }
>
> +static inline void sve_user_disable(void) { BUILD_BUG(); }
> +static inline void sve_user_enable(void) { BUILD_BUG(); }
> +
> static inline void sve_init_vq_map(void) { }
> static inline void sve_update_vq_map(void) { }
> static inline int sve_verify_vq_map(void) { return 0; }
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index a98a7f96aff1..58c53bc96928 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -159,16 +159,6 @@ static void sve_free(struct task_struct *task)
> __sve_free(task);
> }
>
> -static void sve_user_disable(void)
> -{
> - sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
> -}
> -
> -static void sve_user_enable(void)
> -{
> - sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
> -}
> -
> /*
> * TIF_SVE controls whether a task can use SVE without trapping while
> * in userspace, and also the way a task's FPSIMD/SVE state is stored
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm: Hook up SYNC_CORE functionality for sys_membarrier()
From: Will Deacon @ 2018-06-19 12:22 UTC (permalink / raw)
To: linux-arm-kernel
Exception return implies context synchronization, so we can hook up the
SYNC_CORE option to sys_membarrier() simply by selecting the Kconfig option,
just like we've done for arm64 already.
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Orion Hodson <oth@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54eeb8d00bc6..b0ac18547370 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -9,6 +9,7 @@ config ARM
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
+ select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
select ARCH_HAS_PHYS_TO_DMA
select ARCH_HAS_SET_MEMORY
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] clk: Fix switching CPU rate from 300Mhz to 1.2GHz on Armada 3700
From: Gregory CLEMENT @ 2018-06-19 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
in this series the first patch is the main patch which fixes the case
when switching CPU rate from 300Mhz (or 200M MHz) to 1.2GH. See the
commit log for the details. As this one is a fix, it should be applied
on v4.18-rc.
While I was on this file, I also switch to SPDX license identifier,
this one is fine for 4.19*;
Thanks,
Gregory
Gregory CLEMENT (2):
clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to
1.2GHz
clk: mvebu: armada-37xx-periph: switch to SPDX license identifier
drivers/clk/mvebu/armada-37xx-periph.c | 43 +++++++++++++++++++++++---
1 file changed, 39 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/2] clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz
From: Gregory CLEMENT @ 2018-06-19 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619123446.694-1-gregory.clement@bootlin.com>
Switching the CPU from the L2 or L3 frequencies (300 and 200 Mhz
respectively) to L0 frequency (1.2 Ghz) requires a significant amount
of time to let VDD stabilize to the appropriate voltage. This amount of
time is large enough that it cannot be covered by the hardware
countdown register. Due to this, the CPU might start operating at L0
before the voltage is stabilized, leading to CPU stalls.
To work around this problem, we prevent switching directly from the
L2/L3 frequencies to the L0 frequency, and instead switch to the L1
frequency in-between. The sequence therefore becomes:
1. First switch from L2/L3(200/300MHz) to L1(600MHZ)
2. Sleep 20ms for stabling VDD voltage
3. Then switch from L1(600MHZ) to L0(1200Mhz).
It is based on the work done by Ken Ma <make@marvell.com>
Cc: stable at vger.kernel.org
Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/clk/mvebu/armada-37xx-periph.c | 38 ++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
index 6860bd5a37c5..44e4e27eddad 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -35,6 +35,7 @@
#define CLK_SEL 0x10
#define CLK_DIS 0x14
+#define ARMADA_37XX_DVFS_LOAD_1 1
#define LOAD_LEVEL_NR 4
#define ARMADA_37XX_NB_L0L1 0x18
@@ -507,6 +508,40 @@ static long clk_pm_cpu_round_rate(struct clk_hw *hw, unsigned long rate,
return -EINVAL;
}
+/*
+ * Switching the CPU from the L2 or L3 frequencies (300 and 200 Mhz
+ * respectively) to L0 frequency (1.2 Ghz) requires a significant
+ * amount of time to let VDD stabilize to the appropriate
+ * voltage. This amount of time is large enough that it cannot be
+ * covered by the hardware countdown register. Due to this, the CPU
+ * might start operating at L0 before the voltage is stabilized,
+ * leading to CPU stalls.
+ *
+ * To work around this problem, we prevent switching directly from the
+ * L2/L3 frequencies to the L0 frequency, and instead switch to the L1
+ * frequency in-between. The sequence therefore becomes:
+ * 1. First switch from L2/L3(200/300MHz) to L1(600MHZ)
+ * 2. Sleep 20ms for stabling VDD voltage
+ * 3. Then switch from L1(600MHZ) to L0(1200Mhz).
+ */
+static void clk_pm_cpu_set_rate_wa(unsigned long rate, struct regmap *base)
+{
+ unsigned int cur_level;
+
+ if (rate != 1200 * 1000 * 1000)
+ return;
+
+ regmap_read(base, ARMADA_37XX_NB_CPU_LOAD, &cur_level);
+ cur_level &= ARMADA_37XX_NB_CPU_LOAD_MASK;
+ if (cur_level <= ARMADA_37XX_DVFS_LOAD_1)
+ return;
+
+ regmap_update_bits(base, ARMADA_37XX_NB_CPU_LOAD,
+ ARMADA_37XX_NB_CPU_LOAD_MASK,
+ ARMADA_37XX_DVFS_LOAD_1);
+ msleep(20);
+}
+
static int clk_pm_cpu_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
@@ -537,6 +572,9 @@ static int clk_pm_cpu_set_rate(struct clk_hw *hw, unsigned long rate,
*/
reg = ARMADA_37XX_NB_CPU_LOAD;
mask = ARMADA_37XX_NB_CPU_LOAD_MASK;
+
+ clk_pm_cpu_set_rate_wa(rate, base);
+
regmap_update_bits(base, reg, mask, load_level);
return rate;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] clk: mvebu: armada-37xx-periph: switch to SPDX license identifier
From: Gregory CLEMENT @ 2018-06-19 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619123446.694-1-gregory.clement@bootlin.com>
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/clk/mvebu/armada-37xx-periph.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
index 44e4e27eddad..a51edaab0c5c 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
/*
* Marvell Armada 37xx SoC Peripheral clocks
*
@@ -5,10 +6,6 @@
*
* Gregory CLEMENT <gregory.clement@free-electrons.com>
*
- * This file is licensed under the terms of the GNU General Public
- * License version 2 or later. This program is licensed "as is"
- * without any warranty of any kind, whether express or implied.
- *
* Most of the peripheral clocks can be modelled like this:
* _____ _______ _______
* TBG-A-P --| | | | | | ______
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Xie XiuQi @ 2018-06-19 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619120714.GE13685@dhcp22.suse.cz>
Hi Michal,
On 2018/6/19 20:07, Michal Hocko wrote:
> On Tue 19-06-18 20:03:07, Xie XiuQi wrote:
> [...]
>> I tested on a arm board with 128 cores 4 numa nodes, but I set CONFIG_NR_CPUS=72.
>> Then node 3 is not be created, because node 3 has no memory, and no cpu.
>> But some pci device may related to node 3, which be set in ACPI table.
>
> Could you double check that zonelists for node 3 are generated
> correctly?
>
zonelists for node 3 is not created at all.
Kernel parse SRAT table to create node info, but in this case,
SRAT table is parsed not completed. Only the first 72 items are parsed.
In SRAT table, we haven't seen node 3 information yet, because cpu_to_node_map[72] is too small.
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30000 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30001 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30002 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30003 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30100 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30101 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30102 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30103 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30200 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30201 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30202 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30203 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30300 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30301 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30302 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30303 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30400 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30401 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30402 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30403 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30500 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30501 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30502 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30503 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30600 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30601 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30602 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30603 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30700 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30701 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30702 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x30703 -> Node 0
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10000 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10001 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10002 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10003 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10100 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10101 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10102 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10103 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10200 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10201 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10202 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10203 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10300 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10301 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10302 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10303 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10400 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10401 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10402 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10403 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10500 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10501 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10502 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10503 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10600 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10601 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10602 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10603 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10700 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10701 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10702 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10703 -> Node 1
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70000 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70001 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70002 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70003 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70100 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70101 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70102 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: PXM 2 -> MPIDR 0x70103 -> Node 2
[ 0.000000] ACPI: NUMA: SRAT: cpu_to_node_map[72] is too small, may not be able to use all cpus
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x2080000000-0x23ffffffff]
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[ 0.000000] ACPI: SRAT: Node 2 PXM 2 [mem 0x402000000000-0x4023ffffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x23ffffe780-0x23ffffffff]
[ 0.000000] NUMA: Initmem setup node 1 [<memory-less node>]
[ 0.000000] NUMA: NODE_DATA [mem 0x4023fffed780-0x4023fffeefff]
[ 0.000000] NUMA: NODE_DATA(1) on node 2
[ 0.000000] NUMA: NODE_DATA [mem 0x4023fffebf00-0x4023fffed77f]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000000000-0x00000000ffffffff]
[ 0.000000] Normal [mem 0x0000000100000000-0x00004023ffffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003942ffff]
[ 0.000000] node 0: [mem 0x0000000039430000-0x000000003956ffff]
[ 0.000000] node 0: [mem 0x0000000039570000-0x000000003963ffff]
[ 0.000000] node 0: [mem 0x0000000039640000-0x00000000396fffff]
[ 0.000000] node 0: [mem 0x0000000039700000-0x000000003971ffff]
[ 0.000000] node 0: [mem 0x0000000039720000-0x0000000039b6ffff]
[ 0.000000] node 0: [mem 0x0000000039b70000-0x000000003eb5ffff]
[ 0.000000] node 0: [mem 0x000000003eb60000-0x000000003eb8ffff]
[ 0.000000] node 0: [mem 0x000000003eb90000-0x000000003fbfffff]
[ 0.000000] node 0: [mem 0x0000002080000000-0x00000023ffffffff]
[ 0.000000] node 2: [mem 0x0000402000000000-0x00004023ffffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000023ffffffff]
[ 0.000000] Could not find start_pfn for node 1
[ 0.000000] Initmem setup node 1 [mem 0x0000000000000000-0x0000000000000000]
[ 0.000000] Initmem setup node 2 [mem 0x0000402000000000-0x00004023ffffffff]
--
Thanks,
Xie XiuQi
^ permalink raw reply
* [PATCH 1/8] dt-bindings: tegra186-hsp: Add shared interrupts
From: Mikko Perttunen @ 2018-06-19 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2bed23e6-19d5-66f8-774e-d613a91b1607@nvidia.com>
On 22.05.2018 18:15, Jon Hunter wrote:
>
> On 08/05/18 12:43, Mikko Perttunen wrote:
>> Non-doorbell interrupts are routed through "shared interrupts". These
>> interrupts can be mapped to various internal interrupt lines. Add
>> interrupt properties for shared interrupts to the tegra186-hsp device
>> tree bindings.
>
> Reading the Tegra documentation, although the doorbells have dedicated
> interrupts, it appears that the doorbell interrupts can also be routed
> via these shared interrupts.
Thanks, I changed the text slightly to account for this.
>
>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>> ---
>> ? Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt |
>> 2 ++
>> ? 1 file changed, 2 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>> b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>> index b99d25fc2f26..9edcdf82d719 100644
>> --- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>> +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt
>> @@ -21,6 +21,8 @@ Required properties:
>> ????? Contains a list of names for the interrupts described by the
>> interrupt
>> ????? property. May contain the following entries, in any order:
>> ????? - "doorbell"
>> +??? - "sharedN", where 'N' is a number from zero up to the number of
>> +????? external interrupts supported by the HSP instance minus one.
>> ????? Users of this binding MUST look up entries in the interrupt
>> property
>> ????? by name, using this interrupt-names property to do so.
>> ? - interrupts
>
> How is the mapping of shared-mailboxes interrupts to the actual
> 'sharedN' interrupt managed?
Currently the driver always uses shared0 for mailbox-full interrupt, and
nothing else, which is what downstream does as well. It's difficult to
do anything else as we can trample on some other driver's configuration..
>
> Cheers
> Jon
>
Thanks,
Mikko
^ permalink raw reply
* [PATCH 0/3] cpufreq: add AVS support for Armada 3700
From: Gregory CLEMENT @ 2018-06-19 12:43 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Armada 37xx supports also Adaptive Voltage Scaling and this series
allow to us it.
In order to configure it, the drives needs to access a new set of
register which is documented in patch 1 and added in the dts in patch
3.
the first 2 patches should be merged through the cpufreq subsystem,
and I will take care of the 3rd patch once the binding will have been
validated.
Thanks,
Gregory CLEMENT (3):
dt-bindings: marvell: Add documentation for the Armada 3700 AVS
binding
cpufreq: armada-37xx: Add AVS support
arm64: dts: marvell: armada-37xx: add the node allowing AVS support
.../bindings/arm/marvell/armada-37xx.txt | 16 ++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 6 +
drivers/cpufreq/armada-37xx-cpufreq.c | 163 +++++++++++++++++-
3 files changed, 182 insertions(+), 3 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: marvell: Add documentation for the Armada 3700 AVS binding
From: Gregory CLEMENT @ 2018-06-19 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619124402.902-1-gregory.clement@bootlin.com>
Extend the documentation of the Armada 37xx SoC with the Adaptive Voltage
Scaling (AVS) registers.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
.../bindings/arm/marvell/armada-37xx.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
index 35c3c3460d17..22438f659d1e 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
@@ -33,3 +33,19 @@ nb_pm: syscon at 14000 {
compatible = "marvell,armada-3700-nb-pm", "syscon";
reg = <0x14000 0x60>;
}
+
+AVS
+---
+
+For AVS an other component is needed:
+
+Required properties:
+- compatible : should contain "marvell,armada-3700-avs", "syscon";
+- reg : the register start and length for the AVS
+
+Example:
+avs: avs at 11500 {
+ compatible = "marvell,armada-3700-avs", "syscon";
+ reg = <0x11500 0x40>;
+}
+
--
2.17.1
^ permalink raw reply related
* [PATCH 2/3] cpufreq: armada-37xx: Add AVS support
From: Gregory CLEMENT @ 2018-06-19 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619124402.902-1-gregory.clement@bootlin.com>
Armada 37xx supports Adaptive Voltage Scaling and thanks to this patch a
voltage is associated to each load level.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/cpufreq/armada-37xx-cpufreq.c | 163 +++++++++++++++++++++++++-
1 file changed, 160 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
index 739da90ff3f6..75491fc841a6 100644
--- a/drivers/cpufreq/armada-37xx-cpufreq.c
+++ b/drivers/cpufreq/armada-37xx-cpufreq.c
@@ -51,6 +51,16 @@
#define ARMADA_37XX_DVFS_LOAD_2 2
#define ARMADA_37XX_DVFS_LOAD_3 3
+/* AVS register set */
+#define ARMADA_37XX_AVS_CTL0 0x0
+#define ARMADA_37XX_AVS_ENABLE BIT(30)
+#define ARMADA_37XX_AVS_HIGH_VDD_LIMIT 16
+#define ARMADA_37XX_AVS_LOW_VDD_LIMIT 22
+#define ARMADA_37XX_AVS_VDD_MASK 0x3F
+#define ARMADA_37XX_AVS_CTL2 0x8
+#define ARMADA_37XX_AVS_LOW_VDD_EN BIT(6)
+#define ARMADA_37XX_AVS_VSET(x) (0x1C + 4 * (x))
+
/*
* On Armada 37xx the Power management manages 4 level of CPU load,
* each level can be associated with a CPU clock source, a CPU
@@ -58,6 +68,17 @@
*/
#define LOAD_LEVEL_NR 4
+#define MIN_VOLT_MV 1000
+
+/* AVS value for the corresponding voltage (in mV) */
+static int avs_map[] = {
+ 747, 758, 770, 782, 793, 805, 817, 828, 840, 852, 863, 875, 887, 898,
+ 910, 922, 933, 945, 957, 968, 980, 992, 1003, 1015, 1027, 1038, 1050,
+ 1062, 1073, 1085, 1097, 1108, 1120, 1132, 1143, 1155, 1167, 1178, 1190,
+ 1202, 1213, 1225, 1237, 1248, 1260, 1272, 1283, 1295, 1307, 1318, 1330,
+ 1342
+};
+
struct armada37xx_cpufreq_state {
struct regmap *regmap;
u32 nb_l0l1;
@@ -71,6 +92,7 @@ static struct armada37xx_cpufreq_state *armada37xx_cpufreq_state;
struct armada_37xx_dvfs {
u32 cpu_freq_max;
u8 divider[LOAD_LEVEL_NR];
+ u32 avs[LOAD_LEVEL_NR];
};
static struct armada_37xx_dvfs armada_37xx_dvfs[] = {
@@ -148,6 +170,128 @@ static void __init armada37xx_cpufreq_dvfs_setup(struct regmap *base,
clk_set_parent(clk, parent);
}
+/*
+ * Find out the armada 37x supported AVS value whose voltage value is
+ * the round-up closest to the target voltage value.
+ */
+static u32 armada_37xx_avs_val_match(int target_vm)
+{
+ u32 avs;
+
+ /* Find out the round-up closest supported voltage value */
+ for (avs = 0; avs < ARRAY_SIZE(avs_map); avs++)
+ if (avs_map[avs] >= target_vm)
+ break;
+
+ /*
+ * If all supported voltages are smaller than target one,
+ * choose the largest supported voltage
+ */
+ if (avs == ARRAY_SIZE(avs_map))
+ avs = ARRAY_SIZE(avs_map) - 1;
+
+ return avs;
+}
+
+/*
+ * For Armada 37xx soc, L0(VSET0) VDD AVS value is set to SVC revision
+ * value or a default value when SVC is not supported.
+ * - L0 can be read out from the register of AVS_CTRL_0 and L0 voltage
+ * can be got from the mapping table of avs_map.
+ * - L1 voltage should be about 100mv smaller than L0 voltage
+ * - L2 & L3 voltage should be about 150mv smaller than L0 voltage.
+ * This function calculates L1 & L2 & L3 AVS values dynamically based
+ * on L0 voltage and fill all AVS values to the AVS value table.
+ */
+static void __init armada37xx_cpufreq_avs_configure(struct regmap *base,
+ struct armada_37xx_dvfs *dvfs)
+{
+ unsigned int target_vm;
+ int load_level = 0;
+ u32 l0_vdd_min;
+
+ if (base == NULL)
+ return;
+
+ /* Get L0 VDD min value */
+ regmap_read(base, ARMADA_37XX_AVS_CTL0, &l0_vdd_min);
+ l0_vdd_min = (l0_vdd_min >> ARMADA_37XX_AVS_LOW_VDD_LIMIT) &
+ ARMADA_37XX_AVS_VDD_MASK;
+ if (l0_vdd_min >= ARRAY_SIZE(avs_map)) {
+ pr_err("L0 VDD MIN %d is not correct.\n", l0_vdd_min);
+ return;
+ }
+ dvfs->avs[0] = l0_vdd_min;
+
+ if (avs_map[l0_vdd_min] <= MIN_VOLT_MV) {
+ /*
+ * If L0 voltage is smaller than 1000mv, then all VDD sets
+ * use L0 voltage;
+ */
+ u32 avs_min = armada_37xx_avs_val_match(MIN_VOLT_MV);
+
+ for (load_level = 1; load_level < LOAD_LEVEL_NR; load_level++)
+ dvfs->avs[load_level] = avs_min;
+
+ return;
+ }
+
+ /*
+ * L1 voltage is equal to L0 voltage - 100mv and it must be
+ * larger than 1000mv
+ */
+
+ target_vm = avs_map[l0_vdd_min] - 100;
+ target_vm = target_vm > MIN_VOLT_MV ? target_vm : MIN_VOLT_MV;
+ dvfs->avs[1] = armada_37xx_avs_val_match(target_vm);
+
+ /*
+ * L2 & L3 voltage is equal to L0 voltage - 150mv and it must
+ * be larger than 1000mv
+ */
+ target_vm = avs_map[l0_vdd_min] - 150;
+ target_vm = target_vm > MIN_VOLT_MV ? target_vm : MIN_VOLT_MV;
+ dvfs->avs[2] = dvfs->avs[3] = armada_37xx_avs_val_match(target_vm);
+}
+
+static void __init armada37xx_cpufreq_avs_setup(struct regmap *base,
+ struct armada_37xx_dvfs *dvfs)
+{
+ unsigned int avs_val = 0, freq;
+ int load_level = 0;
+
+ if (base == NULL)
+ return;
+
+ /* Disable AVS before the configuration */
+ regmap_update_bits(base, ARMADA_37XX_AVS_CTL0,
+ ARMADA_37XX_AVS_ENABLE, 0);
+
+
+ /* Enable low voltage mode */
+ regmap_update_bits(base, ARMADA_37XX_AVS_CTL2,
+ ARMADA_37XX_AVS_LOW_VDD_EN,
+ ARMADA_37XX_AVS_LOW_VDD_EN);
+
+
+ for (load_level = 1; load_level < LOAD_LEVEL_NR; load_level++) {
+ freq = dvfs->cpu_freq_max / dvfs->divider[load_level];
+
+ avs_val = dvfs->avs[load_level];
+ regmap_update_bits(base, ARMADA_37XX_AVS_VSET(load_level-1),
+ ARMADA_37XX_AVS_VDD_MASK << ARMADA_37XX_AVS_HIGH_VDD_LIMIT |
+ ARMADA_37XX_AVS_VDD_MASK << ARMADA_37XX_AVS_LOW_VDD_LIMIT,
+ avs_val << ARMADA_37XX_AVS_HIGH_VDD_LIMIT |
+ avs_val << ARMADA_37XX_AVS_LOW_VDD_LIMIT);
+ }
+
+ /* Enable AVS after the configuration */
+ regmap_update_bits(base, ARMADA_37XX_AVS_CTL0,
+ ARMADA_37XX_AVS_ENABLE,
+ ARMADA_37XX_AVS_ENABLE);
+
+}
+
static void armada37xx_cpufreq_disable_dvfs(struct regmap *base)
{
unsigned int reg = ARMADA_37XX_NB_DYN_MOD,
@@ -216,7 +360,7 @@ static int __init armada37xx_cpufreq_driver_init(void)
struct platform_device *pdev;
unsigned long freq;
unsigned int cur_frequency;
- struct regmap *nb_pm_base;
+ struct regmap *nb_pm_base, *avs_base;
struct device *cpu_dev;
int load_lvl, ret;
struct clk *clk;
@@ -227,6 +371,14 @@ static int __init armada37xx_cpufreq_driver_init(void)
if (IS_ERR(nb_pm_base))
return -ENODEV;
+ avs_base =
+ syscon_regmap_lookup_by_compatible("marvell,armada-3700-avs");
+
+ /* if AVS is not present don't use it but still try to setup dvfs */
+ if (IS_ERR(avs_base)) {
+ pr_info("Syscon failed for Adapting Voltage Scaling: skip it\n");
+ avs_base = NULL;
+ }
/* Before doing any configuration on the DVFS first, disable it */
armada37xx_cpufreq_disable_dvfs(nb_pm_base);
@@ -270,16 +422,21 @@ static int __init armada37xx_cpufreq_driver_init(void)
armada37xx_cpufreq_state->regmap = nb_pm_base;
+ armada37xx_cpufreq_avs_configure(avs_base, dvfs);
+ armada37xx_cpufreq_avs_setup(avs_base, dvfs);
+
armada37xx_cpufreq_dvfs_setup(nb_pm_base, clk, dvfs->divider);
clk_put(clk);
for (load_lvl = ARMADA_37XX_DVFS_LOAD_0; load_lvl < LOAD_LEVEL_NR;
load_lvl++) {
+ unsigned long u_volt = avs_map[dvfs->avs[load_lvl]] * 1000;
freq = cur_frequency / dvfs->divider[load_lvl];
-
- ret = dev_pm_opp_add(cpu_dev, freq, 0);
+ ret = dev_pm_opp_add(cpu_dev, freq, u_volt);
if (ret)
goto remove_opp;
+
+
}
/* Now that everything is setup, enable the DVFS at hardware level */
--
2.17.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