* [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
* [PATCH v2 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
From: Rafael J. Wysocki @ 2018-06-05 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528209304-3280-2-git-send-email-sudeep.holla@arm.com>
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?
> +}
> +static inline int find_acpi_cpu_topology_package(unsigned int cpu)
> +{
> + return -EINVAL;
> +}
> +static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
> +{
> + return -EINVAL;
> +}
> +#endif
>
> #endif /*_LINUX_ACPI_H*/
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index 89397e30e269..70e19bc6cc9f 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -98,7 +98,7 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
> int init_cache_level(unsigned int cpu);
> int populate_cache_leaves(unsigned int cpu);
> int cache_setup_acpi(unsigned int cpu);
> -#ifndef CONFIG_ACPI
> +#ifndef CONFIG_ACPI_PPTT
> /*
> * acpi_find_last_cache_level is only called on ACPI enabled
> * platforms using the PPTT for topology. This means that if
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v10 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC
From: Valentin Schneider @ 2018-06-05 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525091712.37227-1-liwei213@huawei.com>
Hi,
On 25/05/18 10:17, Li Wei wrote:
> This patchset adds driver support for UFS for Hi3660 SoC. It is verified on HiKey960 board.
>
> Li Wei (5):
> scsi: ufs: add Hisilicon ufs driver code
> dt-bindings: scsi: ufs: add document for hisi-ufs
> arm64: dts: add ufs dts node
> arm64: defconfig: enable configs for Hisilicon ufs
> arm64: defconfig: enable f2fs and squashfs
>
> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 41 ++
> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 +-
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 18 +
> arch/arm64/configs/defconfig | 11 +
> drivers/scsi/ufs/Kconfig | 9 +
> drivers/scsi/ufs/Makefile | 1 +
> drivers/scsi/ufs/ufs-hisi.c | 619 +++++++++++++++++++++
> drivers/scsi/ufs/ufs-hisi.h | 115 ++++
> 8 files changed, 821 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> create mode 100644 drivers/scsi/ufs/ufs-hisi.c
> create mode 100644 drivers/scsi/ufs/ufs-hisi.h
>
> Major changes in v10:
> - solve review comments from Rob Herring.
> *Modify the "reset-names" describe in ufs-hisi.txt binding file.
> *List clocks in ufs-hisi.txt binding file.
> *remove the "arst" and keep only "rst" in the binging files.
> *remove the "arst" member from both dts and c code.
> Major changes in v9:
> - solve review comments from Rob Herring.
> *remove freq-table-hz in ufs-hisi.txt binding file.
> *Move the rst to the ufshcd_pltfm.txt common binding file.
> *Modify the member "assert" of UFS host structure to "arst".
> Major changes in v8:
> - solve review comments from zhangfei.
> *Add Version history.
> - solve review comments from Rob Herring.
> *remove freq-table-hz.
> - solve review comments from Riku Voipio.
> *Add MODULE_DEVICE_TABLE for ufs driver.
>
Tested on top of linux-next (4.17.0-next-20180605), I can reliably load
my debian userspace flashed on the 'system' fastboot partition.
Tested-by: Valentin Schneider <valentin.schneider@arm.com>
^ permalink raw reply
* [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Maxime Ripard @ 2018-06-05 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <313a74ea-0be6-cff1-6b2f-06a4b0b7ba8d@settrans.net>
On Mon, Jun 04, 2018 at 06:33:02PM +0100, Bob Ham wrote:
> On 04/06/18 09:13, Maxime Ripard wrote:
> > On Sat, Jun 02, 2018 at 05:03:13PM +0100, Bob Ham wrote:
>
> >> + * This file is dual-licensed: you can use it either under the terms
> >> + * of the GPL or the X11 license, at your option. Note that this dual
> >> + * licensing only applies to this file, and not this project as a
> >> + * whole.
>
> >> + * The above copyright notice and this permission notice shall be
> >> + * included in all copies or substantial portions of the Software.
>
> > And this is redundant with the SPDX header.
>
> The X11 license notice states explicitly that the notice has to be
> included in the file. Wouldn't removing it be a violation of the license?
The SPDX header is explicitly here to remove the license text and
create a tag that is in a indirect reference to the license text in
LICENSES. It's not going away.
> >> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> >
> > Each step should increase the perceived brightness by roughly 1/Nth, N
> > being the number of steps. Usually PWM backlights don't work like that.
>
> FYI, this was copied from another .dts file. All of the other
> brightness-levels settings in sun{4,5,7}i .dts files follow similar
> patterns:
>
> sun4i-a10-dserve-dsrv9703c.dts: brightness-levels = <0 10
> 20 30 40 50 60 70 80 90 100>;
> sun4i-a10-inet1.dts: brightness-levels = <0 10 20 30 40 50 60
> 70 80 90 100>;
> sun4i-a10-pov-protab2-ips9.dts: brightness-levels = <0 10
> 20 30 40 50 60 70 80 90 100>;
> sun5i-a13-empire-electronix-d709.dts: brightness-levels = <0 10
> 20 30 40 50 60 70 80 90 100>;
> sun5i-a13-utoo-p66.dts: brightness-levels = <0 30 40 50 60 70 80
> 90 100>;
> sun5i-gr8-evb.dts: brightness-levels = <0 10 20 30 40 50 60
> 70 80 90 100>;
> sun7i-a20-wexler-tab7200.dts: brightness-levels = <0 10 20 30 40
> 50 60 70 80 90 100>;
I never said we were perfect reviewers. Feel free to help in the process.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/ec5e1ba7/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: marvell: armada-37xx: add nodes to support watchdog
From: Marek Behún @ 2018-06-05 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605144345.2021-1-marek.behun@nic.cz>
This adds the system controller node for CPU Miscellaneous Registers
(which is needed for the watchdog node) and the watchdog node.
Signed-off-by: Marek Behun <marek.behun@nic.cz>
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 8cd43ce38571..8388793f10ac 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -101,6 +101,11 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ cpu_misc: system-controller at d000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0xd000 0x1000>;
+ };
+
spi0: spi at 10600 {
compatible = "marvell,armada-3700-spi";
#address-cells = <1>;
@@ -142,6 +147,13 @@
status = "disabled";
};
+ wdt: watchdog-timer at 8300 {
+ compatible = "marvell,armada-3700-wdt";
+ reg = <0x8300 0x40>;
+ marvell,system-controller = <&cpu_misc>;
+ clocks = <&xtalclk>;
+ };
+
nb_periph_clk: nb-periph-clk at 13000 {
compatible = "marvell,armada-3700-periph-clock-nb";
reg = <0x13000 0x100>;
--
2.16.4
^ permalink raw reply related
* [PATCH v2 1/2] watchdog: Add support for Armada 37xx CPU watchdog
From: Marek Behún @ 2018-06-05 14:43 UTC (permalink / raw)
To: linux-arm-kernel
This adds support for the CPU watchdog found on Marvell Armada 37xx
SoCs.
There are 4 counters which can be set as CPU watchdog counters.
This driver uses the second counter (ID 1, counting from 0)
(Marvell's Linux also uses second counter by default).
In the future it could be adapted to use other counters, with
definition in the device tree.
Signed-off-by: Marek Behun <marek.behun@nic.cz>
Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com>
create mode 100644 Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt
create mode 100644 drivers/watchdog/armada_37xx_wdt.c
diff --git a/Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt b/Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt
new file mode 100644
index 000000000000..4ba9e40ad386
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/armada-37xx-wdt.txt
@@ -0,0 +1,23 @@
+* Armada 37xx CPU Watchdog Timer Controller
+
+Required properties:
+- compatible : must be "marvell,armada-3700-wdt"
+- reg : base physical address of the controller and length of memory mapped
+ region.
+- clocks : the clock feeding the watchdog timer. See clock-bindings.txt
+- marvell,system-controller : reference to syscon node for the CPU Miscellaneous
+ Registers
+
+Example:
+
+ cpu_misc: system-controller at d000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0xd000 0x1000>;
+ };
+
+ wdt: watchdog-timer at 8300 {
+ compatible = "marvell,armada-3700-wdt";
+ reg = <0x8300 0x40>;
+ marvell,system-controller = <&cpu_misc>;
+ clocks = <&xtalclk>;
+ };
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3ece1335ba84..4ca96c5a10bc 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -255,6 +255,17 @@ config ARM_SBSA_WATCHDOG
To compile this driver as module, choose M here: The module
will be called sbsa_gwdt.
+config ARMADA_37XX_WATCHDOG
+ tristate "Armada 37xx watchdog"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ select MFD_SYSCON
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer found on
+ Marvell Armada 37xx SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called armada_37xx_wdt.
+
config ASM9260_WATCHDOG
tristate "Alphascale ASM9260 watchdog"
depends on MACH_ASM9260 || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 715a21078e0c..eae72c5fa1e0 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
# ARM Architecture
obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
+obj-$(CONFIG_ARMADA_37XX_WATCHDOG) += armada_37xx_wdt.o
obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
diff --git a/drivers/watchdog/armada_37xx_wdt.c b/drivers/watchdog/armada_37xx_wdt.c
new file mode 100644
index 000000000000..24af496103c6
--- /dev/null
+++ b/drivers/watchdog/armada_37xx_wdt.c
@@ -0,0 +1,353 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Watchdog driver for Marvell Armada 37xx SoCs
+ *
+ * Author: Marek Behun <marek.behun@nic.cz>
+ */
+
+#include <asm/io.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+#include <linux/watchdog.h>
+
+/*
+ * There are four counters that can be used for watchdog on Armada 37xx.
+ * The addresses for counter control registers are register base plus ID*0x10,
+ * where ID is 0, 1, 2 or 3.
+ * In this driver we use ID 1. Marvell's Linux also uses this ID by default,
+ * and the U-Boot driver written simultaneosly by the same author as this
+ * driver also uses ID 1.
+ * Maybe in the future we could change this driver to support other counters,
+ * depending on the device tree, but I don't think this is necessary.
+ *
+ * Note that CNTR_ID cannot be 3, because the third counter is an increment
+ * counter, and this driver is written to support decrementing counters only.
+ */
+
+/* relative to cpu_misc */
+#define WDT_TIMER_SELECT 0x64
+#define WDT_TIMER_SELECT_MASK 0xf
+#define WDT_TIMER_SELECT_VAL BIT(CNTR_ID)
+
+/* relative to reg */
+#define CNTR_ID 1
+
+#define CNTR_CTRL (CNTR_ID * 0x10)
+#define CNTR_CTRL_ENABLE 0x0001
+#define CNTR_CTRL_ACTIVE 0x0002
+#define CNTR_CTRL_MODE_MASK 0x000c
+#define CNTR_CTRL_MODE_ONESHOT 0x0000
+#define CNTR_CTRL_PRESCALE_MASK 0xff00
+#define CNTR_CTRL_PRESCALE_MIN 2
+#define CNTR_CTRL_PRESCALE_SHIFT 8
+
+#define CNTR_COUNT_LOW (CNTR_CTRL + 0x4)
+#define CNTR_COUNT_HIGH (CNTR_CTRL + 0x8)
+
+#define WATCHDOG_TIMEOUT 120
+
+static unsigned int timeout = WATCHDOG_TIMEOUT;
+module_param(timeout, int, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default="
+ __MODULE_STRING(WATCHDOG_TIMEOUT) ")");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct armada_37xx_watchdog {
+ struct watchdog_device wdt;
+ struct regmap *cpu_misc;
+ void __iomem *reg;
+ u64 timeout; /* in clock ticks */
+ unsigned long clk_rate;
+ struct clk *clk;
+};
+
+static u64 get_counter_value(struct armada_37xx_watchdog *dev)
+{
+ u64 val;
+
+ val = readl(dev->reg + CNTR_COUNT_HIGH);
+ val = (val << 32) | readl(dev->reg + CNTR_COUNT_LOW);
+
+ return val;
+}
+
+static void set_counter_value(struct armada_37xx_watchdog *dev)
+{
+ writel(dev->timeout & 0xffffffff, dev->reg + CNTR_COUNT_LOW);
+ writel(dev->timeout >> 32, dev->reg + CNTR_COUNT_HIGH);
+}
+
+static void armada_37xx_wdt_counter_enable(struct armada_37xx_watchdog *dev)
+{
+ u32 reg;
+
+ reg = readl(dev->reg + CNTR_CTRL);
+ reg |= CNTR_CTRL_ENABLE;
+ writel(reg, dev->reg + CNTR_CTRL);
+}
+
+static void armada_37xx_wdt_counter_disable(struct armada_37xx_watchdog *dev)
+{
+ u32 reg;
+
+ reg = readl(dev->reg + CNTR_CTRL);
+ reg &= ~CNTR_CTRL_ENABLE;
+ writel(reg, dev->reg + CNTR_CTRL);
+}
+
+static int armada_37xx_wdt_ping(struct watchdog_device *wdt)
+{
+ struct armada_37xx_watchdog *dev = watchdog_get_drvdata(wdt);
+
+ armada_37xx_wdt_counter_disable(dev);
+ set_counter_value(dev);
+ armada_37xx_wdt_counter_enable(dev);
+
+ return 0;
+}
+
+static unsigned int armada_37xx_wdt_get_timeleft(struct watchdog_device *wdt)
+{
+ struct armada_37xx_watchdog *dev = watchdog_get_drvdata(wdt);
+ unsigned int res;
+
+ res = get_counter_value(dev) * CNTR_CTRL_PRESCALE_MIN / dev->clk_rate;
+
+ return res;
+}
+
+static int armada_37xx_wdt_set_timeout(struct watchdog_device *wdt,
+ unsigned int timeout)
+{
+ struct armada_37xx_watchdog *dev = watchdog_get_drvdata(wdt);
+
+ wdt->timeout = timeout;
+
+ /*
+ * Compute the timeout in clock rate. We use smallest possible prescaler,
+ * which divides the clock rate by 2 (CNTR_CTRL_PRESCALE_MIN).
+ */
+ dev->timeout = (u64)dev->clk_rate * timeout / CNTR_CTRL_PRESCALE_MIN;
+
+ return 0;
+}
+
+static bool armada_37xx_wdt_is_running(struct armada_37xx_watchdog *dev)
+{
+ u32 reg;
+
+ regmap_read(dev->cpu_misc, WDT_TIMER_SELECT, ®);
+ if ((reg & WDT_TIMER_SELECT_MASK) != WDT_TIMER_SELECT_VAL)
+ return false;
+
+ reg = readl(dev->reg + CNTR_CTRL);
+ return !!(reg & CNTR_CTRL_ACTIVE);
+}
+
+static int armada_37xx_wdt_start(struct watchdog_device *wdt)
+{
+ struct armada_37xx_watchdog *dev = watchdog_get_drvdata(wdt);
+ u32 reg;
+
+ reg = readl(dev->reg + CNTR_CTRL);
+
+ if (reg & CNTR_CTRL_ACTIVE)
+ return -EBUSY;
+
+ /* set mode */
+ reg = (reg & ~CNTR_CTRL_MODE_MASK) | CNTR_CTRL_MODE_ONESHOT;
+
+ /* set prescaler to the min value of 2 */
+ reg &= ~CNTR_CTRL_PRESCALE_MASK;
+ reg |= CNTR_CTRL_PRESCALE_MIN << CNTR_CTRL_PRESCALE_SHIFT;
+
+ writel(reg, dev->reg + CNTR_CTRL);
+
+ set_counter_value(dev);
+
+ regmap_write(dev->cpu_misc, WDT_TIMER_SELECT, WDT_TIMER_SELECT_VAL);
+ armada_37xx_wdt_counter_enable(dev);
+
+ return 0;
+}
+
+static int armada_37xx_wdt_stop(struct watchdog_device *wdt)
+{
+ struct armada_37xx_watchdog *dev = watchdog_get_drvdata(wdt);
+
+ armada_37xx_wdt_counter_disable(dev);
+ regmap_write(dev->cpu_misc, WDT_TIMER_SELECT, 0);
+
+ return 0;
+}
+
+static const struct watchdog_info armada_37xx_wdt_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .identity = "Armada 37xx Watchdog",
+};
+
+static const struct watchdog_ops armada_37xx_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = armada_37xx_wdt_start,
+ .stop = armada_37xx_wdt_stop,
+ .ping = armada_37xx_wdt_ping,
+ .set_timeout = armada_37xx_wdt_set_timeout,
+ .get_timeleft = armada_37xx_wdt_get_timeleft,
+};
+
+static int armada_37xx_wdt_probe(struct platform_device *pdev)
+{
+ struct armada_37xx_watchdog *dev;
+ struct resource *res;
+ struct regmap *regmap;
+ int ret;
+
+ dev = devm_kzalloc(&pdev->dev, sizeof(struct armada_37xx_watchdog),
+ GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
+ dev->wdt.info = &armada_37xx_wdt_info;
+ dev->wdt.ops = &armada_37xx_wdt_ops;
+ dev->wdt.min_timeout = 1;
+
+ regmap = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "marvell,system-controller");
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+ dev->cpu_misc = regmap;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+ dev->reg = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+
+ /* init clock */
+ dev->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(dev->clk))
+ return PTR_ERR(dev->clk);
+
+ ret = clk_prepare_enable(dev->clk);
+ if (ret)
+ return ret;
+
+ dev->clk_rate = clk_get_rate(dev->clk);
+
+ /*
+ * Since the timeout in seconds is given as 32 bit unsigned int, and
+ * the counters hold 64 bit values, even after multiplication by clock
+ * rate the counter can hold timeout of UINT_MAX seconds.
+ */
+ dev->wdt.min_timeout = 0;
+ dev->wdt.max_timeout = UINT_MAX;
+ dev->wdt.parent = &pdev->dev;
+
+ /* default value, possibly override by module parameter or dtb */
+ dev->wdt.timeout = WATCHDOG_TIMEOUT;
+ watchdog_init_timeout(&dev->wdt, timeout, &pdev->dev);
+
+ platform_set_drvdata(pdev, &dev->wdt);
+ watchdog_set_drvdata(&dev->wdt, dev);
+
+ armada_37xx_wdt_set_timeout(&dev->wdt, dev->wdt.timeout);
+
+ if (armada_37xx_wdt_is_running(dev))
+ set_bit(WDOG_HW_RUNNING, &dev->wdt.status);
+ else
+ armada_37xx_wdt_stop(&dev->wdt);
+
+ watchdog_set_nowayout(&dev->wdt, nowayout);
+ ret = watchdog_register_device(&dev->wdt);
+ if (ret)
+ goto disable_clk;
+
+ dev_info(&pdev->dev, "Initial timeout %d sec%s\n",
+ dev->wdt.timeout, nowayout ? ", nowayout" : "");
+
+ return 0;
+
+disable_clk:
+ clk_disable_unprepare(dev->clk);
+ return ret;
+}
+
+static int armada_37xx_wdt_remove(struct platform_device *pdev)
+{
+ struct watchdog_device *wdt = platform_get_drvdata(pdev);
+ struct armada_37xx_watchdog *dev = watchdog_get_drvdata(wdt);
+
+ watchdog_unregister_device(wdt);
+ clk_disable_unprepare(dev->clk);
+ return 0;
+}
+
+static void armada_37xx_wdt_shutdown(struct platform_device *pdev)
+{
+ struct watchdog_device *wdt = platform_get_drvdata(pdev);
+
+ armada_37xx_wdt_stop(wdt);
+}
+
+static int __maybe_unused armada_37xx_wdt_suspend(struct device *dev)
+{
+ struct watchdog_device *wdt = dev_get_drvdata(dev);
+
+ return armada_37xx_wdt_stop(wdt);
+}
+
+static int __maybe_unused armada_37xx_wdt_resume(struct device *dev)
+{
+ struct watchdog_device *wdt = dev_get_drvdata(dev);
+
+ if (watchdog_active(wdt))
+ return armada_37xx_wdt_start(wdt);
+
+ return 0;
+}
+
+static const struct dev_pm_ops armada_37xx_wdt_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(armada_37xx_wdt_suspend,
+ armada_37xx_wdt_resume)
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id armada_37xx_wdt_match[] = {
+ { .compatible = "marvell,armada-3700-wdt", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, armada_37xx_wdt_match);
+#endif
+
+static struct platform_driver armada_37xx_wdt_driver = {
+ .probe = armada_37xx_wdt_probe,
+ .remove = armada_37xx_wdt_remove,
+ .shutdown = armada_37xx_wdt_shutdown,
+ .driver = {
+ .name = "armada_37xx_wdt",
+ .of_match_table = of_match_ptr(armada_37xx_wdt_match),
+ .pm = &armada_37xx_wdt_dev_pm_ops,
+ },
+};
+
+module_platform_driver(armada_37xx_wdt_driver);
+
+MODULE_AUTHOR("Marek Behun <marek.behun@nic.cz>");
+MODULE_DESCRIPTION("Armada 37xx CPU Watchdog");
+
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:armada_37xx_wdt");
--
2.16.4
^ permalink raw reply related
* [PATCH v2 3/3] arm64: disable ACPI PPTT support temporarily
From: Sudeep Holla @ 2018-06-05 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528209304-3280-1-git-send-email-sudeep.holla@arm.com>
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.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9fd4a8ccce07..98a5c78a80f9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,7 +7,6 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
- select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
--
2.7.4
^ 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