* [PATCH v2 3/3] arm64: disable ACPI PPTT support temporarily
From: Jeremy Linton @ 2018-06-05 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a93212e3-7965-9ae2-34b0-407f04590567@arm.com>
Hi,
On 06/05/2018 10:27 AM, Sudeep Holla wrote:
>
>
> On 05/06/18 16:02, Rafael J. Wysocki wrote:
>> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> Currently, ARM64 doesn't support updating the CPU topology masks on
>>> CPU hotplug operations. ACPI PPTT support rely on that missing feature
>>> which is technically not incorrect. Instead of reverting all the PPTT
>>> support, let's keep it simple and disable ACPI PPTT support on ARM64
>>> for time-being until the topology updates are added for CPU hotplug
>>> operations.
>>
>> When is that going to happen?
>>> Nobody else uses PPTT now.
>>
>
> No we need it on ARM64. I have even the fixes for the original issue
> but it's bit invasive and too late as we are already in the merge
> window. It needs to be tested on NUMA platforms, I have asked for that
> explicitly.
>
So, there is a lot simpler fix for this, and its to remove the numa mask
dependency from the scheduler domain building. That is just a couple
line fix, and it reverts !ACPI to its original behavior, while the ACPI
LLC building will work around the NUMA in package issue that caused
patch 12/12 as the machine in question doesn't have a LLC crossing numa
domains.
^ permalink raw reply
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
From: Andy Shevchenko @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54785881-da7c-db68-c6a4-70cfd489c1fe@arm.com>
On Tue, Jun 5, 2018 at 7:26 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 05/06/18 17:21, Andy Shevchenko wrote:
>> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> of_property_read_u32 searches for a property in a device node and read
>>> a 32-bit value from it. Instead of using of_get_property to get the
>>> property and then read 32-bit value using of_read_number, we can
>>> simplify it by using of_property_read_u32.
>>>
>>
>> LGTM.
>> Thanks!
>>
>
> Thanks, can I take is Ack ?
>
> Anyways it's too late for v4.18, will repost after the merge window for
> v4.19 with your Ack if you agree.
You can consider like this, though it makes a little change here since
I'm not a maintainer of the code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605163442.4812-1-manivannan.sadhasivam@linaro.org>
Add initial device tree support for Mediatek X20 Development Board
based on MT6797 Deca core SoC. This board is one of the 96Boards
Consumer Edition platform.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60f998c..5b7fd6ad96e4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
new file mode 100644
index 000000000000..2c09ca95d9e2
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for MediaTek X20 Development Board
+ *
+ * Copyright (C) 2018, Linaro Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include "mt6797.dtsi"
+
+/ {
+ model = "Mediatek X20 Development Board";
+ compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x1e605000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart1 {
+ status = "okay";
+};
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: arm: mediatek: Document Mediatek X20 Development Board
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605163442.4812-1-manivannan.sadhasivam@linaro.org>
Document Mediatek X20 Development Board which is a 96Boards Consumer
Edition platform based on MT6797 SoC.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
index 7d21ab37c19c..356df1ee11b9 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -47,6 +47,9 @@ Supported boards:
- Evaluation board for MT6797(Helio X20):
Required root node properties:
- compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
+- Mediatek X20 Development Board:
+ Required root node properties:
+ - compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
- Reference board variant 1 for MT7622:
Required root node properties:
- compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
--
2.17.0
^ permalink raw reply related
* [PATCH v2 0/2] Add Mediatek X20 Development Board support
From: Manivannan Sadhasivam @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
Add devicetree support for Mediatek X20 Development Board by Archermind.
This board is based on the Deca-Core MT6797 SoC from Mediatek and is
one of the 96Boards Consumer Edition platform.
With this devicetree change, board can boot into initramfs.
More information about this board can be found in 96Boards product page:
https://www.96boards.org/product/mediatek-x20/
Thanks,
Mani
Changes in v2:
* Added documentation for board compatible
* Dropped vendor documetation patch since it got applied
Manivannan Sadhasivam (2):
dt-bindings: arm: mediatek: Document Mediatek X20 Development Board
arm64: dts: Add Mediatek X20 Development Board support
.../devicetree/bindings/arm/mediatek.txt | 3 ++
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
3 files changed, 37 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
--
2.17.0
^ permalink raw reply
* [PATCH] PCI: Clean up resource allocation in devm_of_pci_get_host_bridge_resources()
From: Andy Shevchenko @ 2018-06-05 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f35b2972-aa40-5397-facb-765cafe7c315@siemens.com>
On Wed, May 16, 2018 at 3:31 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Instead of first allocating and then freeing memory for struct resource
> in case we cannot parse a PCI resource from the device tree, work
> against a local struct and kmemdup it when we decide to go with it.
>
Bjorn, any comments on this?
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> drivers/pci/of.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index b06585a1da75..fc0f906c5c25 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -266,7 +266,7 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
> struct list_head *resources, resource_size_t *io_base)
> {
> struct device_node *dev_node = dev->of_node;
> - struct resource *res;
> + struct resource *res, tmp_res;
> struct resource *bus_range;
> struct of_pci_range range;
> struct of_pci_range_parser parser;
> @@ -320,18 +320,16 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev,
> if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> continue;
>
> - res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
> + err = of_pci_range_to_resource(&range, dev_node, &tmp_res);
> + if (err)
> + continue;
> +
> + res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL);
> if (!res) {
> err = -ENOMEM;
> goto failed;
> }
>
> - err = of_pci_range_to_resource(&range, dev_node, res);
> - if (err) {
> - devm_kfree(dev, res);
> - continue;
> - }
> -
> if (resource_type(res) == IORESOURCE_IO) {
> if (!io_base) {
> dev_err(dev,
> --
> 2.13.6
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
From: Sudeep Holla @ 2018-06-05 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vd_rQFX1s6jCbj-uLC3K70sSD=s0rt3sWme_f2m90NE5A@mail.gmail.com>
On 05/06/18 17:21, Andy Shevchenko wrote:
> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> of_property_read_u32 searches for a property in a device node and read
>> a 32-bit value from it. Instead of using of_get_property to get the
>> property and then read 32-bit value using of_read_number, we can
>> simplify it by using of_property_read_u32.
>>
>
> LGTM.
> Thanks!
>
Thanks, can I take is Ack ?
Anyways it's too late for v4.18, will repost after the merge window for
v4.19 with your Ack if you agree.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
From: Andy Shevchenko @ 2018-06-05 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526907189-10031-1-git-send-email-sudeep.holla@arm.com>
On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> of_property_read_u32 searches for a property in a device node and read
> a 32-bit value from it. Instead of using of_get_property to get the
> property and then read 32-bit value using of_read_number, we can
> simplify it by using of_property_read_u32.
>
LGTM.
Thanks!
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/base/cacheinfo.c | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> Hi Andy,
>
> Ignore my comment on compile errors error with Werror=incompatible-pointer-types
> I was so hung up on _u64 version and didn't realise that we were using 32-bit
> with of_read_number originally.
>
> Regards,
> Sudeep
>
> v1->v2:
> - Replaced use of of_property_read_u64 with of_property_read_u32
> - Also removed the local variables as Andy initially suggested
>
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 2880e2ab01f5..5d5b5988e88b 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -74,52 +74,48 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *cache_size;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->size))
> + this_leaf->size = 0;
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> static void cache_get_line_size(struct cacheinfo *this_leaf,
> struct device_node *np)
> {
> - const __be32 *line_size;
> int i, lim, ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
>
> for (i = 0; i < lim; i++) {
> + int ret;
> + u32 line_size;
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + ret = of_property_read_u32(np, propname, &line_size);
> + if (!ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> }
> -
> - if (line_size)
> - this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *nr_sets;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(np, propname, NULL);
> - if (nr_sets)
> - this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->number_of_sets))
> + this_leaf->number_of_sets = 0;
> }
>
> static void cache_associativity(struct cacheinfo *this_leaf)
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Rafael J. Wysocki @ 2018-06-05 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ec94a230-2798-8001-d3c5-902ea6f1855b@arm.com>
On Tue, Jun 5, 2018 at 6:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 05/06/18 17:12, Rafael J. Wysocki wrote:
>> On Tue, Jun 5, 2018 at 5:33 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>>
>>> On 05/06/18 16:00, Rafael J. Wysocki wrote:
>>>> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
>>>>> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>>>>>
>>>>> This patch adds the missing dummy/boiler plate implementation to fix
>>>>> the build.
>>>>>
>>>>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>> include/linux/acpi.h | 15 +++++++++++++++
>>>>> include/linux/cacheinfo.h | 2 +-
>>>>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>>>>
>>>>> Hi Rafael,
>>>>>
>>>>> If you are fine with this, can you provide Ack, so that we route this
>>>>> through ARM64 tree where most of the ACPI PPTT support is present.
>>>>>
>>>>> Regards,
>>>>> Sudeep
>>>>>
>>>>> v1->v2:
>>>>> - removed duplicate definition for acpi_find_last_cache_level
>>>>>
>>>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>>>> index 8f2cdb0eca71..4b35a66383f9 100644
>>>>> --- a/include/linux/acpi.h
>>>>> +++ b/include/linux/acpi.h
>>>>> @@ -1299,8 +1299,23 @@ static inline int lpit_read_residency_count_address(u64 *address)
>>>>> }
>>>>> #endif
>>>>>
>>>>> +#ifdef CONFIG_ACPI_PPTT
>>>>> int find_acpi_cpu_topology(unsigned int cpu, int level);
>>>>> int find_acpi_cpu_topology_package(unsigned int cpu);
>>>>> int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
>>>>> +#else
>>>>> +static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
>>>>> +{
>>>>> + return -EINVAL;
>>>>
>>>> Why -EINVAL?
>>>>
>>>
>>> I am not sure either. I used to return -ENOTSUPP, but IIRC someone
>>> suggested to use it only for syscalls. Also I just based it on other
>>> existing functions in acpi.h
>>>
>>> I am open for any alternatives if you think that is better here.
>>
>> It would be good to make it consistent with the error codes returned
>> by the functions when they are present.
>>
>> Anyway, it's fine by me if that's consistent with the other acpi.h stubs.
>>
>
> Thanks, indeed I copied it from existing stubs.
>
> Can I take this as official Ack ?
Yes, please.
^ permalink raw reply
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Sudeep Holla @ 2018-06-05 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hrJs1Oo-uA560qisZ4no4mbgbH+2fza+5B0ErGGYPTHw@mail.gmail.com>
On 05/06/18 17:12, Rafael J. Wysocki wrote:
> On Tue, Jun 5, 2018 at 5:33 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 05/06/18 16:00, Rafael J. Wysocki wrote:
>>> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
>>>> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>>>>
>>>> This patch adds the missing dummy/boiler plate implementation to fix
>>>> the build.
>>>>
>>>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>> include/linux/acpi.h | 15 +++++++++++++++
>>>> include/linux/cacheinfo.h | 2 +-
>>>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>>>
>>>> Hi Rafael,
>>>>
>>>> If you are fine with this, can you provide Ack, so that we route this
>>>> through ARM64 tree where most of the ACPI PPTT support is present.
>>>>
>>>> Regards,
>>>> Sudeep
>>>>
>>>> v1->v2:
>>>> - removed duplicate definition for acpi_find_last_cache_level
>>>>
>>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>>> index 8f2cdb0eca71..4b35a66383f9 100644
>>>> --- a/include/linux/acpi.h
>>>> +++ b/include/linux/acpi.h
>>>> @@ -1299,8 +1299,23 @@ static inline int lpit_read_residency_count_address(u64 *address)
>>>> }
>>>> #endif
>>>>
>>>> +#ifdef CONFIG_ACPI_PPTT
>>>> int find_acpi_cpu_topology(unsigned int cpu, int level);
>>>> int find_acpi_cpu_topology_package(unsigned int cpu);
>>>> int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
>>>> +#else
>>>> +static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
>>>> +{
>>>> + return -EINVAL;
>>>
>>> Why -EINVAL?
>>>
>>
>> I am not sure either. I used to return -ENOTSUPP, but IIRC someone
>> suggested to use it only for syscalls. Also I just based it on other
>> existing functions in acpi.h
>>
>> I am open for any alternatives if you think that is better here.
>
> It would be good to make it consistent with the error codes returned
> by the functions when they are present.
>
> Anyway, it's fine by me if that's consistent with the other acpi.h stubs.
>
Thanks, indeed I copied it from existing stubs.
Can I take this as official Ack ?
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Rafael J. Wysocki @ 2018-06-05 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83b1b038-c4c1-0199-2cb0-fb5343f0e3f5@arm.com>
On Tue, Jun 5, 2018 at 5:33 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 05/06/18 16:00, Rafael J. Wysocki wrote:
>> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
>>> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>>>
>>> This patch adds the missing dummy/boiler plate implementation to fix
>>> the build.
>>>
>>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>> include/linux/acpi.h | 15 +++++++++++++++
>>> include/linux/cacheinfo.h | 2 +-
>>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>>
>>> Hi Rafael,
>>>
>>> If you are fine with this, can you provide Ack, so that we route this
>>> through ARM64 tree where most of the ACPI PPTT support is present.
>>>
>>> Regards,
>>> Sudeep
>>>
>>> v1->v2:
>>> - removed duplicate definition for acpi_find_last_cache_level
>>>
>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>> index 8f2cdb0eca71..4b35a66383f9 100644
>>> --- a/include/linux/acpi.h
>>> +++ b/include/linux/acpi.h
>>> @@ -1299,8 +1299,23 @@ static inline int lpit_read_residency_count_address(u64 *address)
>>> }
>>> #endif
>>>
>>> +#ifdef CONFIG_ACPI_PPTT
>>> int find_acpi_cpu_topology(unsigned int cpu, int level);
>>> int find_acpi_cpu_topology_package(unsigned int cpu);
>>> int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
>>> +#else
>>> +static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
>>> +{
>>> + return -EINVAL;
>>
>> Why -EINVAL?
>>
>
> I am not sure either. I used to return -ENOTSUPP, but IIRC someone
> suggested to use it only for syscalls. Also I just based it on other
> existing functions in acpi.h
>
> I am open for any alternatives if you think that is better here.
It would be good to make it consistent with the error codes returned
by the functions when they are present.
Anyway, it's fine by me if that's consistent with the other acpi.h stubs.
^ permalink raw reply
* [PATCH] coresight: include vmalloc.h for vmap/vunmap
From: Mathieu Poirier @ 2018-06-05 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605114856.1558554-1-arnd@arndb.de>
On 5 June 2018 at 05:48, Arnd Bergmann <arnd@arndb.de> wrote:
> The newly introduced code fails to build in some configurations
> unless we include the right headers:
>
> drivers/hwtracing/coresight/coresight-tmc-etr.c: In function 'tmc_free_table_pages':
> drivers/hwtracing/coresight/coresight-tmc-etr.c:206:3: error: implicit declaration of function 'vunmap'; did you mean 'iounmap'? [-Werror=implicit-function-declaration]
>
> Fixes: 79613ae8715a ("coresight: Add generic TMC sg table framework")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 6164eed0b5fe..3556d9a849e9 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -8,6 +8,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/iommu.h>
> #include <linux/slab.h>
> +#include <linux/vmalloc.h>
> #include "coresight-priv.h"
> #include "coresight-tmc.h"
>
Thank you for that - I have picked it up for 4.18-rc1.
Mathieu
> --
> 2.9.0
>
^ permalink raw reply
* [PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs
From: Chen-Yu Tsai @ 2018-06-05 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605071139.osu2pgpg3ychdxln@flea>
On Tue, Jun 5, 2018 at 3:11 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
>> The cooling device properties, like "#cooling-cells" and
>> "dynamic-power-coefficient", should either be present for all the CPUs
>> of a cluster or none. If these are present only for a subset of CPUs of
>> a cluster then things will start falling apart as soon as the CPUs are
>> brought online in a different order. For example, this will happen
>> because the operating system looks for such properties in the CPU node
>> it is trying to bring up, so that it can register a cooling device.
>>
>> Add such missing properties.
>>
>> Fix other missing properties (clocks, OPP, clock latency) as well to
>> make it all work.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Applied both, thanks!
Please fix the "ARM" prefix when applying. :)
ChenYu
^ permalink raw reply
* VMA/Paging apis broken on ARM/ARM64, possible work-arounds?
From: Mark Rutland @ 2018-06-05 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOq87KqGmH92TOvxR1duCkiMqw+ZPH=NuBUAEhAztLxgRyW1TQ@mail.gmail.com>
On Tue, Jun 05, 2018 at 02:40:28PM +0200, Kamil Leoniak wrote:
> Hi,
Hi,
> I have this problem with the kernel I'm working with. Normally PTEs
> are made for every VM addr (ktext, modules and so on). On ARM/ARM64
> certain VM addrs (in kernel) are allocated only with PMDs, they not
> have a corresponding PTE cells.
>
> This breaks a whole range of kernel APIs, for example "set_memory_rw".
> It will work for any region that has a PTE, but if it's a direct PMD
> mapping, it will fail.
As Russell said, for various reasons, APIs which change the attributes
or permissions of pages aren't supported on arbitrary mappings.
> Is there some simple work-around for that? Can I somehow remap a
> specific VM address into a specific physical address? (to override the
> "simple" PMD mapping).
Could you please explain your use-case?
Why are you trying to remap a range that already has a mapping?
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/3] ASoC: stm32: sai: add iec958 controls support
From: Arnaud Pouliquen @ 2018-06-05 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1520958428-10930-3-git-send-email-olivier.moysan@st.com>
Hi Olivier,
On 03/13/2018 05:27 PM, Olivier MOYSAN wrote:
> Add support of iec958 controls for STM32 SAI.
>
> Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
> ---
> ?sound/core/pcm_iec958.c?????? |?? 1 +
> ?sound/soc/stm/Kconfig???????? |?? 1 +
> ?sound/soc/stm/stm32_sai_sub.c | 101
> +++++++++++++++++++++++++++++++++++++-----
> ?3 files changed, 91 insertions(+), 12 deletions(-)
>
> diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
> index aba1f522e98a..c34735ac3c48 100644
> --- a/sound/core/pcm_iec958.c
> +++ b/sound/core/pcm_iec958.c
> @@ -19,6 +19,7 @@ static int snd_pcm_iec958_info(struct snd_kcontrol
> *kcontrol,
> ?{
> ???????? uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
> ???????? uinfo->count = 1;
> +
> ???????? return 0;
> ?}
Seems that this should be part of your patch 1/3
Regards,
Arnaud
> ?
> diff --git a/sound/soc/stm/Kconfig b/sound/soc/stm/Kconfig
> index 48f9ddd94016..9b2681397dba 100644
> --- a/sound/soc/stm/Kconfig
> +++ b/sound/soc/stm/Kconfig
> @@ -6,6 +6,7 @@ config SND_SOC_STM32_SAI
> ???????? depends on SND_SOC
> ???????? select SND_SOC_GENERIC_DMAENGINE_PCM
> ???????? select REGMAP_MMIO
> +?????? select SND_PCM_IEC958
> ???????? help
> ?????????? Say Y if you want to enable SAI for STM32
> ?
> diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
> index cfeb219e1d78..c2e487e133aa 100644
> --- a/sound/soc/stm/stm32_sai_sub.c
> +++ b/sound/soc/stm/stm32_sai_sub.c
> @@ -26,6 +26,7 @@
> ?#include <sound/asoundef.h>
> ?#include <sound/core.h>
> ?#include <sound/dmaengine_pcm.h>
> +#include <sound/pcm_iec958.h>
> ?#include <sound/pcm_params.h>
> ?
> ?#include "stm32_sai.h"
> @@ -96,7 +97,7 @@
> ? * @slot_mask: rx or tx active slots mask. set at init or at runtime
> ? * @data_size: PCM data width. corresponds to PCM substream width.
> ? * @spdif_frm_cnt: S/PDIF playback frame counter
> - * @spdif_status_bits: S/PDIF status bits
> + * @snd_aes_iec958: iec958 data
> ? */
> ?struct stm32_sai_sub_data {
> ???????? struct platform_device *pdev;
> @@ -125,7 +126,7 @@ struct stm32_sai_sub_data {
> ???????? int slot_mask;
> ???????? int data_size;
> ???????? unsigned int spdif_frm_cnt;
> -?????? unsigned char spdif_status_bits[SAI_IEC60958_STATUS_BYTES];
> +?????? struct snd_aes_iec958 iec958;
> ?};
> ?
> ?enum stm32_sai_fifo_th {
> @@ -184,10 +185,6 @@ static bool stm32_sai_sub_writeable_reg(struct
> device *dev, unsigned int reg)
> ???????? }
> ?}
> ?
> -static const unsigned char
> default_status_bits[SAI_IEC60958_STATUS_BYTES] = {
> -?????? 0, 0, 0, IEC958_AES3_CON_FS_48000,
> -};
> -
> ?static const struct regmap_config stm32_sai_sub_regmap_config_f4 = {
> ???????? .reg_bits = 32,
> ???????? .reg_stride = 4,
> @@ -619,6 +616,59 @@ static void stm32_sai_set_frame(struct snd_soc_dai
> *cpu_dai)
> ???????? }
> ?}
> ?
> +static void stm32_sai_set_channel_status(struct stm32_sai_sub_data *sai,
> +??????????????????????????????????????? struct snd_pcm_runtime *runtime)
> +{
> +?????? if (!runtime)
> +?????????????? return;
> +
> +?????? /* Force the sample rate according to runtime rate */
> +?????? switch (runtime->rate) {
> +?????? case 22050:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_22050;
> +?????????????? break;
> +?????? case 44100:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_44100;
> +?????????????? break;
> +?????? case 88200:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_88200;
> +?????????????? break;
> +?????? case 176400:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_176400;
> +?????????????? break;
> +?????? case 24000:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_24000;
> +?????????????? break;
> +?????? case 48000:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_48000;
> +?????????????? break;
> +?????? case 96000:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_96000;
> +?????????????? break;
> +?????? case 192000:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_192000;
> +?????????????? break;
> +?????? case 32000:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_32000;
> +?????????????? break;
> +?????? default:
> +?????????????? sai->iec958.status[3] = IEC958_AES3_CON_FS_NOTID;
> +?????????????? break;
> +?????? }
> +}
> +
> +static int stm32_sai_iec958_set(struct snd_pcm_iec958_params *iec_param)
> +{
> +?????? struct stm32_sai_sub_data *sai = iec_param->private_data;
> +
> +?????? if (!sai->substream)
> +?????????????? return 0;
> +
> +?????? stm32_sai_set_channel_status(sai, sai->substream->runtime);
> +
> +?????? return 0;
> +}
> +
> ?static int stm32_sai_configure_clock(struct snd_soc_dai *cpu_dai,
> ????????????????????????????????????? struct snd_pcm_hw_params *params)
> ?{
> @@ -709,7 +759,11 @@ static int stm32_sai_hw_params(struct
> snd_pcm_substream *substream,
> ?
> ???????? sai->data_size = params_width(params);
> ?
> -?????? if (!STM_SAI_PROTOCOL_IS_SPDIF(sai)) {
> +?????? if (STM_SAI_PROTOCOL_IS_SPDIF(sai)) {
> +?????????????? /* Rate not already set in runtime structure */
> +?????????????? substream->runtime->rate = params_rate(params);
> +?????????????? stm32_sai_set_channel_status(sai, substream->runtime);
> +?????? } else {
> ???????????????? ret = stm32_sai_set_slots(cpu_dai);
> ???????????????? if (ret < 0)
> ???????????????????????? return ret;
> @@ -789,6 +843,28 @@ static void stm32_sai_shutdown(struct
> snd_pcm_substream *substream,
> ???????? sai->substream = NULL;
> ?}
> ?
> +static int stm32_sai_pcm_new(struct snd_soc_pcm_runtime *rtd,
> +??????????????????????????? struct snd_soc_dai *cpu_dai)
> +{
> +?????? struct stm32_sai_sub_data *sai = dev_get_drvdata(cpu_dai->dev);
> +?????? struct snd_pcm_iec958_params *iec_param;
> +
> +?????? if (STM_SAI_PROTOCOL_IS_SPDIF(sai)) {
> +?????????????? dev_dbg(&sai->pdev->dev, "%s: register iec controls",
> __func__);
> +?????????????? iec_param = devm_kzalloc(&sai->pdev->dev,
> sizeof(*iec_param),
> +??????????????????????????????????????? GFP_KERNEL);
> +?????????????? iec_param->ctrl_set = stm32_sai_iec958_set;
> +?????????????? iec_param->private_data = sai;
> +?????????????? iec_param->cs = sai->iec958.status;
> +?????????????? iec_param->cs_len = 5;
> +?????????????? return snd_pcm_add_iec958_ctl(rtd->pcm, 0,
> +???????????????????????????????????????????? SNDRV_PCM_STREAM_PLAYBACK,
> +???????????????????????????????????????????? iec_param);
> +?????? }
> +
> +?????? return 0;
> +}
> +
> ?static int stm32_sai_dai_probe(struct snd_soc_dai *cpu_dai)
> ?{
> ???????? struct stm32_sai_sub_data *sai = dev_get_drvdata(cpu_dai->dev);
> @@ -809,6 +885,10 @@ static int stm32_sai_dai_probe(struct snd_soc_dai
> *cpu_dai)
> ???????? else
> ???????????????? snd_soc_dai_init_dma_data(cpu_dai, NULL, &sai->dma_params);
> ?
> +?????? /* Next settings are not relevant for spdif mode */
> +?????? if (STM_SAI_PROTOCOL_IS_SPDIF(sai))
> +?????????????? return 0;
> +
> ???????? cr1_mask = SAI_XCR1_RX_TX;
> ???????? if (STM_SAI_IS_CAPTURE(sai))
> ???????????????? cr1 |= SAI_XCR1_RX_TX;
> @@ -820,10 +900,6 @@ static int stm32_sai_dai_probe(struct snd_soc_dai
> *cpu_dai)
> ????????????????????????????????????? sai->synco, sai->synci);
> ???????? }
> ?
> -?????? if (STM_SAI_PROTOCOL_IS_SPDIF(sai))
> -?????????????? memcpy(sai->spdif_status_bits, default_status_bits,
> -????????????????????? sizeof(default_status_bits));
> -
> ???????? cr1_mask |= SAI_XCR1_SYNCEN_MASK;
> ???????? cr1 |= SAI_XCR1_SYNCEN_SET(sai->sync);
> ?
> @@ -861,7 +937,7 @@ static int stm32_sai_pcm_process_spdif(struct
> snd_pcm_substream *substream,
> ???????????????? /* Set channel status bit */
> ???????????????? byte = frm_cnt >> 3;
> ???????????????? mask = 1 << (frm_cnt - (byte << 3));
> -?????????????? if (sai->spdif_status_bits[byte] & mask)
> +?????????????? if (sai->iec958.status[byte] & mask)
> ???????????????????????? *ptr |= 0x04000000;
> ???????????????? ptr++;
> ?
> @@ -888,6 +964,7 @@ static int stm32_sai_pcm_process_spdif(struct
> snd_pcm_substream *substream,
> ?static struct snd_soc_dai_driver stm32_sai_playback_dai[] = {
> ?{
> ???????????????? .probe = stm32_sai_dai_probe,
> +?????????????? .pcm_new = stm32_sai_pcm_new,
> ???????????????? .id = 1, /* avoid call to fmt_single_name() */
> ???????????????? .playback = {
> ???????????????????????? .channels_min = 1,
> --
> 1.9.1
>
^ permalink raw reply
* [alsa-devel] [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Arnaud Pouliquen @ 2018-06-05 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180417111733.GG8973@sirena.org.uk>
Hi Takashi,
On 04/17/2018 01:17 PM, Mark Brown wrote:
> On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
>
>> I guess the blocking patch in this patchset is the patch "add IEC958
>> channel status control helper". This patch has been reviewed several
>> times, but did not get a ack so far.
>> If you think these helpers will not be merged, I will reintegrate the
>> corresponding code in stm driver.
>> Please let me know, if I need to prepare a v2 without helpers, or if we
>> can go further in the review of iec helpers patch ?
>
> I don't mind either way but you're right here, I'm waiting for Takashi
> to review the first patch.? I'd probably be OK with it just integrated
> into the driver if we have to go that way though.
Gentlemen reminder for this patch set. We would appreciate to have your
feedback on iec helper.
>From our point of view it could be useful to have a generic management
of the iec controls based on helpers instead of redefining them in DAIs.
Having the same behavior for these controls could be useful to ensure
coherence of the control management used by application (for instance
Gstreamer uses it to determine iec raw mode capability for iec61937 streams)
Thanks,
Arnaud
^ permalink raw reply
* [PATCH] arm64: cpu_errata: include required headers
From: Catalin Marinas @ 2018-06-05 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605115227.1621618-1-arnd@arndb.de>
On Tue, Jun 05, 2018 at 01:50:07PM +0200, Arnd Bergmann wrote:
> Without including psci.h and arm-smccc.h, we now get a build failure in
> some configurations:
>
> arch/arm64/kernel/cpu_errata.c: In function 'arm64_update_smccc_conduit':
> arch/arm64/kernel/cpu_errata.c:278:10: error: 'psci_ops' undeclared (first use in this function); did you mean 'sysfs_ops'?
>
> arch/arm64/kernel/cpu_errata.c: In function 'arm64_set_ssbd_mitigation':
> arch/arm64/kernel/cpu_errata.c:311:3: error: implicit declaration of function 'arm_smccc_1_1_hvc' [-Werror=implicit-function-declaration]
> arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_2, state, NULL);
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This showed up only recently, but I have not bisected what caused it.
I haven't hit it yet, not sure why. I'm queuing the patch anyway.
Thanks.
--
Catalin
^ permalink raw reply
* [RFC PATCH -tip v5 17/27] arm64: kprobes: Don't call the ->break_handler() in arm kprobes code
From: Will Deacon @ 2018-06-05 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152812780433.10068.4191004481518140821.stgit@devbox>
On Tue, Jun 05, 2018 at 12:56:44AM +0900, Masami Hiramatsu wrote:
> Don't call the ->break_handler() from the arm kprobes code,
> because it was only used by jprobes which got removed.
>
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> arch/arm64/kernel/probes/kprobes.c | 8 --------
> 1 file changed, 8 deletions(-)
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [RFC PATCH -tip v5 06/27] arm64: kprobes: Remove jprobe implementation
From: Will Deacon @ 2018-06-05 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152812748464.10068.10380156315388629319.stgit@devbox>
On Tue, Jun 05, 2018 at 12:51:24AM +0900, Masami Hiramatsu wrote:
> Remove arch dependent setjump/longjump functions
> and unused fields in kprobe_ctlblk for jprobes
> from arch/arm64.
>
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> arch/arm64/include/asm/kprobes.h | 1 -
> arch/arm64/kernel/probes/kprobes.c | 68 ------------------------------------
> 2 files changed, 69 deletions(-)
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Sudeep Holla @ 2018-06-05 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gqQNHCuaeduQ8oQtGNUQcZxK171nDfyMNi1VVfnVsMqQ@mail.gmail.com>
On 05/06/18 16:00, Rafael J. Wysocki wrote:
> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
>> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>>
>> This patch adds the missing dummy/boiler plate implementation to fix
>> the build.
>>
>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> include/linux/acpi.h | 15 +++++++++++++++
>> include/linux/cacheinfo.h | 2 +-
>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>
>> Hi Rafael,
>>
>> If you are fine with this, can you provide Ack, so that we route this
>> through ARM64 tree where most of the ACPI PPTT support is present.
>>
>> Regards,
>> Sudeep
>>
>> v1->v2:
>> - removed duplicate definition for acpi_find_last_cache_level
>>
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 8f2cdb0eca71..4b35a66383f9 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -1299,8 +1299,23 @@ static inline int lpit_read_residency_count_address(u64 *address)
>> }
>> #endif
>>
>> +#ifdef CONFIG_ACPI_PPTT
>> int find_acpi_cpu_topology(unsigned int cpu, int level);
>> int find_acpi_cpu_topology_package(unsigned int cpu);
>> int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
>> +#else
>> +static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
>> +{
>> + return -EINVAL;
>
> Why -EINVAL?
>
I am not sure either. I used to return -ENOTSUPP, but IIRC someone
suggested to use it only for syscalls. Also I just based it on other
existing functions in acpi.h
I am open for any alternatives if you think that is better here.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 3/3] arm64: disable ACPI PPTT support temporarily
From: Sudeep Holla @ 2018-06-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hn+sya29bZJzksDEDt2QPZDY36Hwn=ckw3ikTGp7T1Zw@mail.gmail.com>
On 05/06/18 16:02, Rafael J. Wysocki wrote:
> On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Currently, ARM64 doesn't support updating the CPU topology masks on
>> CPU hotplug operations. ACPI PPTT support rely on that missing feature
>> which is technically not incorrect. Instead of reverting all the PPTT
>> support, let's keep it simple and disable ACPI PPTT support on ARM64
>> for time-being until the topology updates are added for CPU hotplug
>> operations.
>
> When is that going to happen?
> > Nobody else uses PPTT now.
>
No we need it on ARM64. I have even the fixes for the original issue
but it's bit invasive and too late as we are already in the merge
window. It needs to be tested on NUMA platforms, I have asked for that
explicitly.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v5 2/4] dt-bindings: timer: add i.MX EPIT timer binding
From: Rob Herring @ 2018-06-05 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604100035.19558-3-peron.clem@gmail.com>
On Mon, Jun 04, 2018 at 12:00:33PM +0200, Cl?ment P?ron wrote:
> From: Cl?ment Peron <clement.peron@devialet.com>
>
> Add devicetree binding document for NXP's i.MX SoC specific
> EPIT timer driver.
>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
> .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,imxepit.txt b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> new file mode 100644
> index 000000000000..de2e6ef68d24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
> @@ -0,0 +1,21 @@
> +Binding for the i.MX Enhanced Periodic Interrupt Timer (EPIT)
> +
> +The Enhanced Periodic Interrupt Timer (EPIT) is a 32-bit set-and-forget timer
> +that is capable of providing precise interrupts at regular intervals with
> +minimal processor intervention.
> +
> +Required properties:
> +- compatible: should be "fsl,<chip>-epit", "fsl,imx31-epit" where <chip> is
> + imx25, imx6qdl, imx6sl, imx6sul or imx6sx.
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: Should contain EPIT controller interrupt
> +- clocks : The clock provided by the SoC to drive the timer.
> +
> +Example for i.MX6QDL:
> + epit1: epit at 20d0000 {
I think I already mentioned this, but:
timer at ...
> + compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
> + reg = <0x020d0000 0x4000>;
> + interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_EPIT1>;
> + };
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH 0/2] Add Mediatek X20 Development Board support
From: Matthias Brugger @ 2018-06-05 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529072719.GA5529@Mani-XPS-13-9360>
On 29/05/18 09:27, Manivannan Sadhasivam wrote:
> Hi Matthias,
>
> On Tue, May 29, 2018 at 08:38:27AM +0200, Matthias Brugger wrote:
>> Hi Manivannan,
>>
>> it's nice to see that someone at Linaro cares about upstreaming the 96 board.
>> From what I can see, your patches add the very same support to the board as
>> does the mt6797 evaluation board. Do you have plans to upstream more drivers for
>> the board? Do you have a roadmap or something?
>>
>> I'm asking becuase I don't want to have just another dead devicetree in the
>> kernel which does nothing but provides a boot to rootfs. Especially as this can
>> be achieved on the same board with the EVB dts.
>>
>
> I can understand your concern here. I do have plans to add more drivers
> in the future for this board but I can't give you any roadmap for that
> since it mostly falls under the spare time work and I have been doing a
> similar kind of work for the Bubblegum-96 board in parallel.
>
> At most I can guarentee that this board's functionality will be added
> gradually in upcoming days.
>
Sounds good. Fancy to send a v2 with the comments from Rob?
Regards,
Matthias
> Thanks,
> Mani
>
>> Regards,
>> Matthias
>>
>> On 29/05/18 06:52, Manivannan Sadhasivam wrote:
>>> Add devicetree support for Mediatek X20 Development Board by Archermind.
>>> This board is based on the Deca-Core MT6797 SoC from Mediatek and is
>>> one of the 96Boards Consumer Edition platform.
>>>
>>> With this devicetree change, board can boot into initramfs.
>>>
>>> More information about this board can be found in 96Boards product page:
>>> https://www.96boards.org/product/mediatek-x20/
>>>
>>> Manivannan Sadhasivam (2):
>>> dt-bindings: Add vendor prefix for ArcherMind
>>> arm64: dts: Add Mediatek X20 Development Board support
>>>
>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>> arch/arm64/boot/dts/mediatek/Makefile | 1 +
>>> .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
>>> 3 files changed, 35 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>>>
^ permalink raw reply
* [PATCH v2 3/3] arm64: disable ACPI PPTT support temporarily
From: Rafael J. Wysocki @ 2018-06-05 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528209304-3280-3-git-send-email-sudeep.holla@arm.com>
On Tue, Jun 5, 2018 at 4:35 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Currently, ARM64 doesn't support updating the CPU topology masks on
> CPU hotplug operations. ACPI PPTT support rely on that missing feature
> which is technically not incorrect. Instead of reverting all the PPTT
> support, let's keep it simple and disable ACPI PPTT support on ARM64
> for time-being until the topology updates are added for CPU hotplug
> operations.
When is that going to happen?
Nobody else uses PPTT now.
^ permalink raw reply
* [PATCH v2 0/5] arm64: perf: Support for chained counters
From: Julien Thierry @ 2018-06-05 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527591356-10934-1-git-send-email-suzuki.poulose@arm.com>
On 29/05/18 11:55, Suzuki K Poulose wrote:
> This series adds support for counting PMU events using 64bit counters
> for arm64 PMU.
>
> The Arm v8 PMUv3 supports combining two adjacent 32bit counters
> (low even and hig odd counters) to count a given "event" in 64bit mode.
> This series adds the support for 64bit events in the core arm_pmu driver
> infrastructure and adds the support for armv8 64bit kernel PMU to use
> chained counters to count in 64bit mode. For CPU cycles, we use the cycle
> counter in 64bit mode, when requested. If the cycle counter is not available,
> we fall back to chaining the counters.
>
> Tested on Juno, Fast models. Applies on 4.17-rc4
>
For the series:
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
--
Julien Thierry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox