* [PATCH] mfd: stm32: Adopt SPDX identifier
From: Lee Jones @ 2017-12-05 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205145809.20514-1-benjamin.gaignard@st.com>
On Tue, 05 Dec 2017, Benjamin Gaignard wrote:
> Add SPDX identifier
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/mfd/stm32-lptimer.c | 2 +-
> drivers/mfd/stm32-timers.c | 2 +-
> include/linux/mfd/stm32-lptimer.h | 2 +-
> include/linux/mfd/stm32-timers.h | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/stm32-lptimer.c b/drivers/mfd/stm32-lptimer.c
> index 075330a25f61..2606e340c9f7 100644
> --- a/drivers/mfd/stm32-lptimer.c
> +++ b/drivers/mfd/stm32-lptimer.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * STM32 Low-Power Timer parent driver.
> *
> @@ -7,7 +8,6 @@
> *
> * Inspired by Benjamin Gaignard's stm32-timers driver
> *
> - * License terms: GNU General Public License (GPL), version 2
> */
Nit, can you also remove the blank line above please?
Same will all of the below.
--
Lee Jones
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] mfd: stm32: Adopt SPDX identifier
From: Benjamin Gaignard @ 2017-12-05 15:24 UTC (permalink / raw)
To: linux-arm-kernel
Add SPDX identifier
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/mfd/stm32-lptimer.c | 6 +-----
drivers/mfd/stm32-timers.c | 4 +---
include/linux/mfd/stm32-lptimer.h | 6 +-----
include/linux/mfd/stm32-timers.h | 4 +---
4 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/stm32-lptimer.c b/drivers/mfd/stm32-lptimer.c
index 075330a25f61..a00f99f36559 100644
--- a/drivers/mfd/stm32-lptimer.c
+++ b/drivers/mfd/stm32-lptimer.c
@@ -1,13 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* STM32 Low-Power Timer parent driver.
- *
* Copyright (C) STMicroelectronics 2017
- *
* Author: Fabrice Gasnier <fabrice.gasnier@st.com>
- *
* Inspired by Benjamin Gaignard's stm32-timers driver
- *
- * License terms: GNU General Public License (GPL), version 2
*/
#include <linux/mfd/stm32-lptimer.h>
diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
index a6675a449409..1d347e5dfa79 100644
--- a/drivers/mfd/stm32-timers.c
+++ b/drivers/mfd/stm32-timers.c
@@ -1,9 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) STMicroelectronics 2016
- *
* Author: Benjamin Gaignard <benjamin.gaignard@st.com>
- *
- * License terms: GNU General Public License (GPL), version 2
*/
#include <linux/mfd/stm32-timers.h>
diff --git a/include/linux/mfd/stm32-lptimer.h b/include/linux/mfd/stm32-lptimer.h
index 77c7cf40d9b4..605f62264825 100644
--- a/include/linux/mfd/stm32-lptimer.h
+++ b/include/linux/mfd/stm32-lptimer.h
@@ -1,13 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* STM32 Low-Power Timer parent driver.
- *
* Copyright (C) STMicroelectronics 2017
- *
* Author: Fabrice Gasnier <fabrice.gasnier@st.com>
- *
* Inspired by Benjamin Gaignard's stm32-timers driver
- *
- * License terms: GNU General Public License (GPL), version 2
*/
#ifndef _LINUX_STM32_LPTIMER_H_
diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
index ce7346e7f77a..2aadab6f34a1 100644
--- a/include/linux/mfd/stm32-timers.h
+++ b/include/linux/mfd/stm32-timers.h
@@ -1,9 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (C) STMicroelectronics 2016
- *
* Author: Benjamin Gaignard <benjamin.gaignard@st.com>
- *
- * License terms: GNU General Public License (GPL), version 2
*/
#ifndef _LINUX_STM32_GPTIMER_H_
--
2.15.0
^ permalink raw reply related
* [PATCH v6 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer
From: Yury Norov @ 2017-12-05 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204200506.3224-8-cdall@kernel.org>
On Mon, Dec 04, 2017 at 09:05:05PM +0100, Christoffer Dall wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> The VGIC can now support the life-cycle of mapped level-triggered
> interrupts, and we no longer have to read back the timer state on every
> exit from the VM if we had an asserted timer interrupt signal, because
> the VGIC already knows if we hit the unlikely case where the guest
> disables the timer without ACKing the virtual timer interrupt.
>
> This means we rework a bit of the code to factor out the functionality
> to snapshot the timer state from vtimer_save_state(), and we can reuse
> this functionality in the sync path when we have an irqchip in
> userspace, and also to support our implementation of the
> get_input_level() function for the timer.
>
> This change also means that we can no longer rely on the timer's view of
> the interrupt line to set the active state, because we no longer
> maintain this state for mapped interrupts when exiting from the guest.
> Instead, we only set the active state if the virtual interrupt is
> active, and otherwise we simply let the timer fire again and raise the
> virtual interrupt from the ISR.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> include/kvm/arm_arch_timer.h | 2 ++
> virt/kvm/arm/arch_timer.c | 75 +++++++++++++++++++++-----------------------
> 2 files changed, 38 insertions(+), 39 deletions(-)
>
> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> index 01ee473517e2..f57f795d704c 100644
> --- a/include/kvm/arm_arch_timer.h
> +++ b/include/kvm/arm_arch_timer.h
> @@ -90,6 +90,8 @@ void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
>
> void kvm_timer_init_vhe(void);
>
> +bool kvm_arch_timer_get_input_level(int vintid);
> +
> #define vcpu_vtimer(v) (&(v)->arch.timer_cpu.vtimer)
> #define vcpu_ptimer(v) (&(v)->arch.timer_cpu.ptimer)
>
[...]
> +bool kvm_arch_timer_get_input_level(int vintid)
> +{
> + struct kvm_vcpu *vcpu = kvm_arm_get_running_vcpu();
> + struct arch_timer_context *timer;
> +
> + if (vintid == vcpu_vtimer(vcpu)->irq.irq)
> + timer = vcpu_vtimer(vcpu);
> + else
> + BUG(); /* We only map the vtimer so far */
> +
> + if (timer->loaded)
> + __timer_snapshot_state(timer);
> +
> + return kvm_timer_should_fire(timer);
> +}
I think it worth to reword to highlight your intention about BUG,
and save 1 call to vcpu_vtimer()
bool kvm_arch_timer_get_input_level(int vintid)
{
struct kvm_vcpu *vcpu = kvm_arm_get_running_vcpu();
struct arch_timer_context *timer = vcpu_vtimer(vcpu);
/* We only map the vtimer so far */
BUG_ON(vintid != timer->irq.irq)
if (timer->loaded)
__timer_snapshot_state(timer);
return kvm_timer_should_fire(timer);
}
> int kvm_timer_enable(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> @@ -841,7 +838,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
> }
>
> ret = kvm_vgic_map_phys_irq(vcpu, host_vtimer_irq, vtimer->irq.irq,
> - NULL);
> + kvm_arch_timer_get_input_level);
> if (ret)
> return ret;
>
> --
> 2.14.2
^ permalink raw reply
* [PATCH v3 05/15] drm/sun4i: Fix error path handling
From: Chen-Yu Tsai @ 2017-12-05 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f2443c41082fc6e086570da38d20744c52fe636.1512486553.git-series.maxime.ripard@free-electrons.com>
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The commit 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap
> initialization sequence") moved a bunch of logic around, but forgot to
> update the gotos after the introduction of the err_free_dotclock label.
>
> It means that if we fail later that the one introduced in that commit,
> we'll just to the old label which isn't free the clock we created. This
> will result in a breakage as soon as someone tries to do something with
> that clock, since its resources will have been long reclaimed.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap initialization sequence")
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks.
I think this was reported, or I noticed it after the patch was merged,
but then I got busy with other stuff.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v3 09/15] drm/sun4i: Add A83T support
From: Jernej Škrabec @ 2017-12-05 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0f8137abb37de936db82c1251556ee84fb23c7fe.1512486553.git-series.maxime.ripard@free-electrons.com>
Hi Maxime,
Dne torek, 05. december 2017 ob 16:10:21 CET je Maxime Ripard napisal(a):
> Add support for the A83T display pipeline.
>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +++++
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 9 +++++++++
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c index 49215d91c853..6f5e721b545e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -347,6 +347,7 @@ static const struct of_device_id sun4i_drv_of_table[] =
> { { .compatible = "allwinner,sun6i-a31s-display-engine" },
> { .compatible = "allwinner,sun7i-a20-display-engine" },
> { .compatible = "allwinner,sun8i-a33-display-engine" },
> + { .compatible = "allwinner,sun8i-a83t-display-engine" },
> { .compatible = "allwinner,sun8i-v3s-display-engine" },
> { }
> };
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 92f4738101e6..9b757450555f
> 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1132,6 +1132,10 @@ static const struct sun4i_tcon_quirks
> sun8i_a33_quirks = { .has_lvds_pll = true,
> };
>
> +static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
> + /* nothing is supported */
> +};
> +
> static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
> /* nothing is supported */
> };
> @@ -1144,6 +1148,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
> { .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks },
> { .compatible = "allwinner,sun7i-a20-tcon", .data = &sun7i_a20_quirks }, {
> .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks }, + {
> .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
> &sun8i_a83t_lcd_quirks }, { .compatible = "allwinner,sun8i-v3s-tcon", .data
> = &sun8i_v3s_quirks }, { }
> };
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c index ff235e3228ce..6829bec4ba68
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -477,6 +477,11 @@ static int sun8i_mixer_remove(struct platform_device
> *pdev) return 0;
> }
>
> +static const struct sun8i_mixer_cfg sun8i_a83t_mixer_cfg = {
> + .vi_num = 1,
> + .ui_num = 3,
> +};
> +
I think you should expand that structure with:
.ccsc = 0,
.scaler_mask = 0xf,
.mod_rate = 150000000,
Best regards,
Jernej
> static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
> .vi_num = 2,
> .ui_num = 1,
> @@ -487,6 +492,10 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg
> = {
>
> static const struct of_device_id sun8i_mixer_of_table[] = {
> {
> + .compatible = "allwinner,sun8i-a83t-de2-mixer-0",
> + .data = &sun8i_a83t_mixer_cfg,
> + },
> + {
> .compatible = "allwinner,sun8i-v3s-de2-mixer",
> .data = &sun8i_v3s_mixer_cfg,
> },
> --
> git-series 0.9.1
^ permalink raw reply
* [PATCH 4/7 v2] net: ethernet: i825xx: Fix platform_get_irq's error checking
From: David Miller @ 2017-12-05 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39363858-995c-eea4-070e-b21a7ac49bec@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Tue, 5 Dec 2017 11:04:55 +0530
> Hi David,
>
>
> On Monday 04 December 2017 11:55 PM, David Miller wrote:
>> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> Date: Mon, 4 Dec 2017 23:18:20 +0530
>>
>>> @@ -120,9 +120,10 @@ static int sni_82596_probe(struct platform_device
>>> *dev)
>>> netdevice->dev_addr[5] = readb(eth_addr + 0x06);
>>> iounmap(eth_addr);
>>> - if (!netdevice->irq) {
>>> + if (netdevice->irq <= 0) {
>>> printk(KERN_ERR "%s: IRQ not found for i82596 at 0x%lx\n",
>>> __FILE__, netdevice->base_addr);
>>> + retval = netdevice->irq ? netdevice->irq : -ENODEV;
>>> goto probe_failed;
>>> }
>> Ok, thinking about this some more...
>>
>> It is impossible to use platform_get_irq() without every single call
>> site having this funny:
>>
>> ret = val ? val : -ENODEV;
>>
>> sequence.
>>
>> This is unnecessary duplication and it is also error prone, so I
>> really think this logic belongs in platform_get_irq() itself. It can
>> convert '0' to -ENODEV and that way we need no special logic in the
>> callers at all.
> platform_get_irq() will return 0 only for sparc, If sparc initialize
> platform
> data irq[PROMINTR_MAX] as zero. Otherwise platform_get_irq() will
> never return
> 0. It will return either IRQ number or error (as negative number). But
> I am getting
> review comment by reviewer/maintainer in other subsystem to add check
> for
> zero. So I have done same changes here. Please correct me if i am
> wrong.
If you make the change that I suggest, you instead can check for
'-ENODEV' to mean no IRQ.
^ permalink raw reply
* [PATCH v2 00/27] Improve DE2 support
From: Jernej Škrabec @ 2017-12-05 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205103618.ps64m57xemsbo44r@flea.lan>
Hi Maxime,
Dne torek, 05. december 2017 ob 11:36:18 CET je Maxime Ripard napisal(a):
> Hi,
>
> On Fri, Dec 01, 2017 at 07:05:23AM +0100, Jernej Skrabec wrote:
> > Current DE2 driver is very basic and uses a lot of magic constants since
> > there is no documentation and knowledge about it was limited at the time.
> >
> > With studying BSP source code, deeper knowledge was gained which allows
> > to improve mainline driver considerably.
> >
> > At the beginning of this series, some code refactoring is done as well
> > as adding some checks (patches 1-15).
> >
> > Further patches add multi-plane support with HW scaling and all possible
> > RGB formats (patches 16-21).
> >
> > At last, support for YUV formats is added (patches 22-26).
> >
> > At the end, I included patch which puts lowest plane before second lowest.
> > This should help testing VI planes when mixer has configuration 1 VI plane
> > and 1 or more UI planes (most SoCs except V3s).
> >
> > This code was developed on H3, but it should work on every SoC if correct
> > configuration structure is provided.
> >
> > H3 code can be found here:
> > https://github.com/jernejsk/linux-1/commits/de2_impr_for_next
>
> Thanks a lot for that huge rework.
>
> I've applied the patches 1 to 26, and will push them to drm-misc once
> the compilations are done.
>
> In the future, if you happen to do such a huge rework again (which
> hopefully won't be needed :)), please use the -M option of
> format-patch. It will reduce a lot the verbosity of files renaming and
> will help the review.
Noted.
I think I missed initialization of min_scaler and max_scaler in
sun8i_vi_layer_atomic_check() in sun8i_vi_layer.c when I was reworking
patches.
Will you fix patch with those two lines
min_scale = DRM_PLANE_HELPER_NO_SCALING;
max_scale = DRM_PLANE_HELPER_NO_SCALING;
or should I send new patch which fixes that or should I send new version of
original patch?
Best regards,
Jernej
^ permalink raw reply
* [RFC PATCH] arm64: deactivate saved ttbr when mm is deactivated
From: Vinayak Menon @ 2017-12-05 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205145529.GA24035@arm.com>
On 12/5/2017 8:25 PM, Will Deacon wrote:
> On Tue, Dec 05, 2017 at 11:06:20AM +0000, Mark Rutland wrote:
>> On Tue, Dec 05, 2017 at 10:30:40AM +0530, Vinayak Menon wrote:
>>> On 12/4/2017 11:30 PM, Mark Rutland wrote:
>>>> On Mon, Dec 04, 2017 at 04:55:33PM +0000, Will Deacon wrote:
>>>>> On Mon, Dec 04, 2017 at 09:53:26PM +0530, Vinayak Menon wrote:
>>>>>> A case is observed where a wrong physical address is read,
>>>>>> resulting in a bus error and that happens soon after TTBR0 is
>>>>>> set to the saved ttbr by uaccess_ttbr0_enable. This is always
>>>>>> seen to happen in the exit path of the task.
>>>>>>
>>>>>> exception
>>>>>> __arch_copy_from_user
>>>>>> __copy_from_user
>>>>>> probe_kernel_read
>>>>>> get_freepointer_safe
>>>>>> slab_alloc_node
>>>>>> slab_alloc
>>>>>> kmem_cache_alloc
>>>>>> kmem_cache_zalloc
>>>>>> fill_pool
>>>>>> __debug_object_init
>>>>>> debug_object_init
>>>>>> rcuhead_fixup_activate
>>>>>> debug_object_fixup
>>>>>> debug_object_activate
>>>>>> debug_rcu_head_queue
>>>>>> __call_rcu
>>>>>> ep_remove
>>>>>> eventpoll_release_file
>>>>>> __fput
>>>>>> ____fput
>>>>>> task_work_run
>>>>>> do_exit
>>>>>>
>>>>>> The mm has been released and the pgd is freed, but probe_kernel_read
>>>>>> invoked from slub results in call to __arch_copy_from_user. At the
>>>>>> entry to __arch_copy_from_user, when SW PAN is enabled, this results
>>>>>> in stale value being set to ttbr0. May be a speculative fetch aftwerwards
>>>>>> is resulting in invalid physical address access.
>>>> I think the problem here is that switch_mm() avoids updating the saved ttbr
>>>> value when the next mm is init_mm.
>>> For this switch to happen, the schedule() in do_task_dead at the end
>>> of do_exit() need to be called, right ? The issue is happening soon
>>> after exit_mm (probably from exit_files).
>> I'd assumed that we'd switch_mm() away from the task's mm prior to the
>> final mmput(). Otherwise, I can't see why we don't have issues in the
>> non SW PAN case (as that would leave the HW TTBR0 stale).
>>
>> However, I can't see exactly where we do that, so I'll go diggging.
>> Something doesn't seem quite right.
>>
>> Do you have a reproducer for the issue?
> I'd be very interested in that, or just more details about how this was
> observed. What was the workload? Kernel version? Hardware? .config? Do you
> know for sure that it was a page table walk that triggered the abort?
>
> In the report above, Vinayak claims that "The mm has been released and the
> pgd is freed" but that really shouldn't happen in the do_exit path. We free
> the other levels of page table in free_pgtables, but deliberately keep the
> mm and the pgd around until we've switched away in finish_task_switch.
>
> I'm quite prepared to believe that the ttbr0 stashing by the SW PAN code
> isn't bulletproof, but I'm struggling to see how the backtrace above
> can happen.
The issue was reported on 3.18 kernel. The hardware configuration is A53 octa core. The test which reproduces this
is a reboot test, which just boots up android and then reboots, and this is done in a loop. It may be reproducing
this problem? as reboot causes the tasks to be killed (do_exit). Its not very easy to reproduce the problem. "The issue
is not reproducible when CONFIG_ARM64_SW_TTBR0_PAN is disabled". What I have looked at is the coredumps
collected when the problem happens. The issue is that one of the cores tries to access a physical address which is
invalid. Interestingly there is no mapping for this physical address in page tables. And every time the issue happens,
the core which issues the wrong address is found to be in the path above, few instructions after the TTBR0 write
inside uaccess_ttbr0_enable (and rest of the callstack is also consistent, debug_object_init->kmem_cache_alloc->probe_kernel_read).
We are not sure it is a page table walk that resulted in this, that was just a guess, that a speculative access
would have caused a table walk with an invalid TTBR0. As per the coredumps, tsk->mm is made NULL. Rest was
assumption, that mm is released and pgd is freed. I assumed do_exit->exit_mmap->mmput->__mmdrop will do that.
But let me go and check if I can figure out from the dumps if that has really happened. I remember doing it but let me
confirm. Let me know if you want me to collect any other info from the dumps.
Thanks,
Vinayak
^ permalink raw reply
* [PATCH] arm: l2c: unlock ways when in non-secure mode
From: Etienne Carriere @ 2017-12-05 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB6PR04MB32211AC670BCAD49CB9F2F38883F0@DB6PR04MB3221.eurprd04.prod.outlook.com>
Hello,
On 3 December 2017 at 12:20, Peng Fan <peng.fan@nxp.com> wrote:
> Hi Russell,
>
>> > > > > >
>> > > > > > On Sun, Nov 26, 2017 at 08:25:30PM +0800, Peng Fan wrote:
>> > > > > > > To boot Linux in Non-secure mode with l2x0, the l2x0
>> > > > > > > controller is enabled in secure mode and ways locked to make
>> > > > > > > it seems L2 cache disabled during linux boot process. So
>> > > > > > > during l2x0 initialization, need to unlock the ways to make
>> > > > > > > l2x0 could
>> > cache data/inst.
>> > > > > >
>> > > > > > Why was this chosen instead of doing what everyone else does?
>> > > > >
>> > > > > I am not aware of how other platform handles the l2x0 unlock in
>> > > > > non secure mode. Could you please share with me what others choose?
>> > > >
>> > > > That's not what I was asking.
>> > > >
>> > > > Everyone else provides a way for the l2x0 controller to be enabled
>> > > > and disabled from non-secure mode.
>> > >
>> > > Thanks for the information. I see that some platforms implements
>> > l2c_write_sec.
>> > >
>> > > >
>> > > > Why have you decided to enable the l2x0 controller and leave it
>> > > > enabled, and then lock down all the cache ways - which means you
>> > > > need the kernel to do something entirely different for your platform.
>> > >
>> > > Currently we are running OP-TEE on i.MX6/7 with Linux in non-secure
>> > > mode. See In
>> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> > > it
>> > > hub.com%2FOP-
>> > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern
>> > >
>> > el%2Fgeneric_entry_a32.S%23L428&data=02%7C01%7Cpeng.fan%40nxp.com%
>> > 7C32
>> > >
>> >
>> e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
>> > C0%
>> > >
>> >
>> 7C0%7C636473747645673295&sdata=ZGaxxhs8mPNcqk5l2aSiStkPRFNxLzFFj45w
>> > kj%
>> > > 2Ff%2Fu4%3D&reserved=0
>> > > Pl310 is enabled. And In
>> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
>> > > it
>> > > hub.com%2FOP-
>> > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern
>> > >
>> > el%2Fgeneric_entry_a32.S%23L461&data=02%7C01%7Cpeng.fan%40nxp.com%
>> > 7C32
>> > >
>> >
>> e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
>> > C0%
>> > >
>> >
>> 7C0%7C636473747645673295&sdata=rO1LG3639lfclvtgzZRTTPcSAGDQNG0Clqb
>> > D1wC
>> > > 4wGk%3D&reserved=0
>> > > pl310 locked before returning back to Linux.
>> > >
>> > > I see ti platform not enabled pl310 in OP-TEE, leaving Linux to
>> > > enable it. platform-sam/stm/ zynq7k/imx Have pl310 enabled in OP-TEE.
>> > >
>> > > I could switch to use l2c_write_sec dedicated for i.MX. But I think
>> > > this patch is
>> > also a valid point.
>> > > What do you suggest?
>> >
>> > What I'm concerned about is that there's a valid scenario where the L2
>> > cache would be enabled and left enabled by the secure mode code - that
>> > is if the secure mode wishes to take advantage of the L2 cache, and
>> > has locked down some ways for its own use.
>> >
>> > In this scenario, the secure world would have set the L2 cache up to
>> > prevent the non-secure side unlocking those ways. This would mean
>> > that the NS_LOCKDOWN bit in the auxiliary control register would be
>> > clear. The PL310 TRM has this to say:
>> >
>> > "On reset the Non-Secure Lockdown Enable bit is set to 0 and Lockdown
>> > Registers are not permitted to be modified by non-secure accesses. In
>> > that configuration, if a non-secure access tries to write to those
>> > registers, the write response returns a DECERR response."
>> >
>> > which means that if we blindly try and unlock the ways, we will end up
>> > triggering an exception, and that will crash the kernel.
>
> Just have a follow up question. If implementing l2c_write_sec, the kernel image
> could not only running in non-secure world. If we want the image to support
> running in secure and non-secure world, do you have any suggestions about
> the l2c things?
>
> Thanks,
> Peng.
>
The weird part is that there is no HW means on ARM cores for a
privileged (or not) execution level to know whether it runs in secure
or non-secure state.
Moreover, the split between secure and non-secure wolrd is really
related the the boot stages.
A boot scheme can decide to split secure/non-secure world (i.e run
optee in secure and linux in non-secure), or can decide to boot the
Linux kernel in secure state.
So, IMO this is pure SW configuration. How to handle that?
Static built-in configuration of the Kernel is not flexible enough.
Device tree (or kernel cmdline) could be mean for the boot stage to
inform the Linux kernel on its execution state.
>>
>> Currently, we set auxiliary control register to let NS could unlock. BIT26 set to 1.
>> But you bring a valid point is if TEE would like to lock down some ways for its
>> own use, l2c_write_sec should be used, to avoid Linux to directly unlock.
>>
>> >
>> > Given that the kernel does _not_ handle this scenario today, I fail to
>> > see why OP-TEE would decide that, on ARM by default, it will enable
>> > the L2 cache and lock all ways.
>> >
>> > As you have already found, at least OMAP has decided to do things
>> > sensibly. I fail to see why everyone else can't also decide to do the sensible
>> thing.
>>
>> Most platforms just set BIT26 to allow non-secure unlock ways without
>> considering reserving ways dedicated to TEE.
>>
>> i.MX also has BIT26 set, so if l2c_init is not a good place, do you think moving
>> unlock to imx_init_l2cache is ok? But this means "enabling(unlock)" L2C earlier
>> which is before l2c_init
>>
>> >
>> > Please talk to the OP-TEE folk to see whether the OP-TEE behaviour can
>> > be changed first.
>>
>> +OP-TEE maintainers Etienne, Jens
>> Do you have comments on this?
>>
The current OP-TEE implementation choose this 'locked/invalidated'
state for the L2 cache because it is quite easy to integrate and
currently fits the OP-TEE needs.
Not a very convincing argument I must admit.
A cleaner implementation would rather require the secure side to
provide an API for the Linux kernel the enable/disable/configure the
L2.
Some standardized ARM SMC would be nice for that. Otherwise, each
platform must provide it own means.
Note however, that if the Linux kernel relies on some SMC to access L2
cache services, this expects there is a SMC handler (aka secure
monitor) installed, which may not be the case if the bootloader boots
the Linux kernel without installing such a secure monitor: the
execution of the SMC instruction would likely to crash the kernel.
This is about the same as for the PSCI support.
Regards,
etienne
>> Thanks,
>> Peng.
>>
>> >
>> > --
>> > RMK's Patch system:
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>> >
>> armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cpeng.fan%4
>> >
>> 0nxp.com%7C32e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92c
>> >
>> d99c5c301635%7C0%7C0%7C636473747645673295&sdata=4i8a6dYNkHlMXiYQZ
>> > N9Ej4b68q%2FZfMCZvIUfJtFy0Jc%3D&reserved=0
>> > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down
>> > 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [RFC PATCH 0/5] perf events patches for improved ARM64 support
From: John Garry @ 2017-12-05 16:13 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for some perf events features,
targeted at ARM64, implemented in a generic fashion.
The two main features are as follows:
- support for arch/vendor/platform pmu events directory structure
- support for parsing architecture recommended pmu events
On the back of these, the Cavium ThunderX2 and HiSilicon hip08
JSONs are relocated/added.
TODO:
- Documentation needs to be updated for recommended
events format in the JSON
- tidy up patches a bit
John Garry (5):
perf jevents: add support for pmu events vendor subdirectory
perf jevents: add support for arch recommended events
perf vendor events arm64: add armv8 recommended events JSON
perf vendor events arm64: relocate thunderx2 JSON
perf vendor events arm64: add HiSilicon hip08 JSON
.../pmu-events/arch/arm64/armv8-recommended.json | 452 +++++++++++++++++++++
.../arch/arm64/cavium/thunderx2-imp-def.json | 62 ---
.../arch/arm64/cavium/thunderx2/core-imp-def.json | 32 ++
.../arch/arm64/hisilicon/hip08/core-imp-def.json | 122 ++++++
tools/perf/pmu-events/arch/arm64/mapfile.csv | 3 +-
tools/perf/pmu-events/jevents.c | 272 ++++++++++++-
6 files changed, 859 insertions(+), 84 deletions(-)
create mode 100644 tools/perf/pmu-events/arch/arm64/armv8-recommended.json
delete mode 100644 tools/perf/pmu-events/arch/arm64/cavium/thunderx2-imp-def.json
create mode 100644 tools/perf/pmu-events/arch/arm64/cavium/thunderx2/core-imp-def.json
create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/core-imp-def.json
--
1.9.1
^ permalink raw reply
* [RFC PATCH 1/5] perf jevents: add support for pmu events vendor subdirectory
From: John Garry @ 2017-12-05 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512490399-94107-1-git-send-email-john.garry@huawei.com>
For some architectures (like arm64), it is required to
support a vendor sub-directory and not put all the JSONs
for a given vendor in the same dir.
This is because all the events for the same vendor will be
in the same pmu events table, which may cause conflict.
This conflict would be in the instance that a vendor's custom
implemented events do have the same meaning on different
platforms. In addition, "perf list" command may list events
which are not even supported for a given platform.
This patch adds support for an arch/vendor/platform directory
hierarchy, while maintaining support for arch/platform
structure. In this, each platform would always have its own pmu
events table.
In generated file pmu_events.c, each platform table name is in
the format pme{_vendor}_platform, like this:
struct pmu_events_map pmu_events_map[] = {
{
.cpuid = "0x00000000420f5160",
.version = "v1",
.type = "core",
.table = pme_cavium_thunderx2
},
{
.cpuid = 0,
.version = 0,
.type = 0,
.table = 0,
},
};
or this:
struct pmu_events_map pmu_events_map[] = {
{
.cpuid = "GenuineIntel-6-56",
.version = "v5",
.type = "core",
.table = pme_broadwellde
},
[snip]
{
.cpuid = 0,
.version = 0,
.type = 0,
.table = 0,
},
};
Signed-off-by: John Garry <john.garry@huawei.com>
---
tools/perf/pmu-events/jevents.c | 57 ++++++++++++++++++++++++++++++++++++++---
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index b578aa2..a0d489e 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -588,7 +588,7 @@ static char *file_name_to_table_name(char *fname)
* Derive rest of table name from basename of the JSON file,
* replacing hyphens and stripping out .json suffix.
*/
- n = asprintf(&tblname, "pme_%s", basename(fname));
+ n = asprintf(&tblname, "pme_%s", fname);
if (n < 0) {
pr_info("%s: asprintf() error %s for file %s\n", prog,
strerror(errno), fname);
@@ -598,7 +598,7 @@ static char *file_name_to_table_name(char *fname)
for (i = 0; i < strlen(tblname); i++) {
c = tblname[i];
- if (c == '-')
+ if (c == '-' || c == '/')
tblname[i] = '_';
else if (c == '.') {
tblname[i] = '\0';
@@ -755,15 +755,52 @@ static int get_maxfds(void)
static FILE *eventsfp;
static char *mapfile;
+static int isLeafDir(const char *fpath)
+{
+ DIR *d;
+ struct dirent *dir;
+ int res = 1;
+ d = opendir(fpath);
+ if (!d)
+ return 0;
+
+ while ((dir = readdir(d)) != NULL) {
+ if (dir-> d_type == DT_DIR && dir->d_name[0] != '.') {
+ res = 0;
+ break;
+ }
+ }
+
+ closedir(d);
+
+ return res;
+}
+
static int process_one_file(const char *fpath, const struct stat *sb,
int typeflag, struct FTW *ftwbuf)
{
- char *tblname, *bname = (char *) fpath + ftwbuf->base;
+ char *tblname, *bname;
int is_dir = typeflag == FTW_D;
int is_file = typeflag == FTW_F;
int level = ftwbuf->level;
int err = 0;
+ if (level == 2 && is_dir) {
+ /*
+ * For level 2 directory, bname will include parent name,
+ * like vendor/platform. So search back from platform dir
+ * to find this.
+ */
+ bname = (char *) fpath + ftwbuf->base - 2;
+ while (true) {
+ if (*bname == '/')
+ break;
+ bname--;
+ }
+ bname++;
+ } else
+ bname = (char *) fpath + ftwbuf->base;
+
pr_debug("%s %d %7jd %-20s %s\n",
is_file ? "f" : is_dir ? "d" : "x",
level, sb->st_size, bname, fpath);
@@ -773,7 +810,7 @@ static int process_one_file(const char *fpath, const struct stat *sb,
return 0;
/* model directory, reset topic */
- if (level == 1 && is_dir) {
+ if (level == 1 && is_dir && isLeafDir(fpath)) {
if (close_table)
print_events_table_suffix(eventsfp);
@@ -791,6 +828,18 @@ static int process_one_file(const char *fpath, const struct stat *sb,
print_events_table_prefix(eventsfp, tblname);
return 0;
+ } else if (level == 2 && is_dir) {
+ if (close_table)
+ print_events_table_suffix(eventsfp);
+
+ tblname = file_name_to_table_name(bname);
+ if (!tblname) {
+ pr_info("%s: Error determining table name for %s, exiting\n", prog,
+ bname);
+ return -1;
+ }
+
+ print_events_table_prefix(eventsfp, tblname);
}
/*
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: John Garry @ 2017-12-05 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512490399-94107-1-git-send-email-john.garry@huawei.com>
For some architectures (like arm64), there are architecture-
defined recommended events. Vendors may not be obliged to
follow the recommendation and may implement their own pmu
event for a specific event code.
This patch adds support for parsing events from arch-defined
recommended JSONs, and then fixing up vendor events when
they have implemented these events as recommended.
In the vendor JSON, to specify that the event is supported
according to the recommendation, only the event code is
added to the JSON entry - no other event elements need be
added, like below:
[
{
"EventCode": "0x40",
},
]
The pmu event parsing will check for "BriefDescription"
field presence only for this.
If "BriefDescription" is present, then it is implied
that the vendor has implemented their own custom event,
and there is no fixup. Other fields are ignored.
*TODO: update documentation
Signed-off-by: John Garry <john.garry@huawei.com>
---
tools/perf/pmu-events/jevents.c | 215 ++++++++++++++++++++++++++++++++++++----
1 file changed, 198 insertions(+), 17 deletions(-)
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index a0d489e..a820ed4 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -42,6 +42,7 @@
#include <dirent.h>
#include <sys/time.h> /* getrlimit */
#include <sys/resource.h> /* getrlimit */
+#include <sys/queue.h>
#include <ftw.h>
#include <sys/stat.h>
#include "jsmn.h"
@@ -366,6 +367,94 @@ static int print_events_table_entry(void *data, char *name, char *event,
return 0;
}
+struct event_struct {
+ char *name;
+ char *event;
+ char *desc;
+ char *long_desc;
+ char *pmu;
+ char *unit;
+ char *perpkg;
+ char *metric_expr;
+ char *metric_name;
+ char *metric_group;
+ LIST_ENTRY(event_struct) list;
+ char strings[];
+};
+
+LIST_HEAD(listhead, event_struct) recommended_events;
+
+static int save_recommended_events(void *data, char *name, char *event,
+ char *desc, char *long_desc,
+ char *pmu, char *unit, char *perpkg,
+ char *metric_expr,
+ char *metric_name, char *metric_group)
+{
+ static int count = 0;
+ char temp[1024];
+ struct event_struct *es;
+ struct stat *sb = data;
+ int len = 0;
+ char *strings;
+
+ /*
+ * Lazily allocate size of the JSON file to hold the
+ * strings, which would be more than large enough.
+ */
+ len = sb->st_size;
+
+ es = malloc(sizeof(*es) + len);
+ if (!es)
+ return -ENOMEM;
+ memset(es, 0, sizeof(*es));
+ LIST_INSERT_HEAD(&recommended_events, es, list);
+
+ strings = &es->strings[0];
+
+ if (name) {
+ es->name = strings;
+ strings += snprintf(strings, len, "%s", name) + 1;
+ }
+ if (event) {
+ es->event = strings;
+ strings += snprintf(strings, len, "%s", event) + 1;
+ }
+ if (desc) {
+ es->desc = strings;
+ strings += snprintf(strings, len, "%s", desc) + 1;
+ }
+ if (long_desc) {
+ es->long_desc = strings;
+ strings += snprintf(strings, len, "%s", long_desc) + 1;
+ }
+ if (pmu) {
+ es->pmu = strings;
+ strings += snprintf(strings, len, "%s", pmu) + 1;
+ }
+ if (unit) {
+ es->unit = strings;
+ strings += snprintf(strings, len, "%s", unit) + 1;
+ }
+ if (perpkg) {
+ es->perpkg = strings;
+ strings += snprintf(strings, len, "%s", perpkg) + 1;
+ }
+ if (metric_expr) {
+ es->metric_expr = strings;
+ strings += snprintf(strings, len, "%s", metric_expr) + 1;
+ }
+ if (metric_name) {
+ es->metric_name = strings;
+ strings += snprintf(strings, len, "%s", metric_name) + 1;
+ }
+ if (metric_group) {
+ es->metric_group = strings;
+ strings += snprintf(strings, len, "%s", metric_group) + 1;
+ }
+
+ return 0;
+}
+
static void print_events_table_suffix(FILE *outfp)
{
fprintf(outfp, "{\n");
@@ -407,6 +496,61 @@ static char *real_event(const char *name, char *event)
return event;
}
+static void fixup_field(char *from, char **to)
+{
+ /*
+ * If we already had a valid pointer (string), then
+ * don't allocate a new one, just reuse and overwrite.
+ */
+ if (!*to)
+ *to = malloc(strlen(from));
+
+ strcpy(*to, from);
+}
+
+static int try_fixup(const char *fn, char *event, char **desc, char **name, char **long_desc, char **pmu, char **filter,
+ char **perpkg, char **unit, char **metric_expr, char **metric_name, char **metric_group)
+{
+ /* try to find matching event from recommended values */
+ struct event_struct *es;
+
+ LIST_FOREACH(es, &recommended_events, list) {
+ if (!strcmp(event, es->event)) {
+ /* now fixup */
+ if (es->desc)
+ fixup_field(es->desc, desc);
+ if (es->name)
+ fixup_field(es->name, name);
+ if (es->long_desc)
+ fixup_field(es->long_desc, long_desc);
+ if (es->pmu)
+ fixup_field(es->pmu, pmu);
+ // if (event_struct->filter)
+ // fixup_field(event_struct->filter, filter);
+ if (es->perpkg)
+ fixup_field(es->perpkg, perpkg);
+ if (es->unit)
+ fixup_field(es->unit, unit);
+ if (es->metric_expr)
+ fixup_field(es->metric_expr, metric_expr);
+ if (es->metric_name)
+ fixup_field(es->metric_name, metric_name);
+ if (es->metric_group)
+ fixup_field(es->metric_group, metric_group);
+
+ return 0;
+ }
+ }
+
+ pr_err("%s: could not find matching %s for %s\n", prog, event, fn);
+ return -1;
+}
+
+#define FREE_MEMORIES \
+ free(event); free(desc); free(name); free(long_desc); \
+ free(extra_desc); free(pmu); free(filter); free(perpkg); \
+ free(unit); free(metric_expr); free(metric_name);
+
/* Call func with each event in the json file */
int json_events(const char *fn,
int (*func)(void *data, char *name, char *event, char *desc,
@@ -551,20 +695,22 @@ int json_events(const char *fn,
if (name)
fixname(name);
+ if (!desc) {
+ /*
+ * If we have no valid desc, then fixup *all* values from recommended
+ * by matching the event.
+ */
+ err = try_fixup(fn, event, &desc, &name, &long_desc, &pmu, &filter, &perpkg, &unit, &metric_expr,
+ &metric_name, &metric_group);
+ if (err) {
+ FREE_MEMORIES
+ goto out_free;
+ }
+ }
+
err = func(data, name, real_event(name, event), desc, long_desc,
pmu, unit, perpkg, metric_expr, metric_name, metric_group);
- free(event);
- free(desc);
- free(name);
- free(long_desc);
- free(extra_desc);
- free(pmu);
- free(filter);
- free(perpkg);
- free(unit);
- free(metric_expr);
- free(metric_name);
- free(metric_group);
+ FREE_MEMORIES
if (err)
break;
tok += j;
@@ -776,6 +922,32 @@ static int isLeafDir(const char *fpath)
return res;
}
+static int isJsonFile(const char *name)
+{
+ const char *suffix;
+
+ if (strlen(name) < 5)
+ return 0;
+
+ suffix = name + strlen(name) - 5;
+
+ if (strncmp(suffix, ".json", 5) == 0)
+ return 1;
+ return 0;
+}
+
+static int preprocess_level0_files(const char *fpath, const struct stat *sb,
+ int typeflag, struct FTW *ftwbuf)
+{
+ int level = ftwbuf->level;
+ int is_file = typeflag == FTW_F;
+
+ if (level == 1 && is_file && isJsonFile(fpath))
+ return json_events(fpath, save_recommended_events, (void *)sb);
+
+ return 0;
+}
+
static int process_one_file(const char *fpath, const struct stat *sb,
int typeflag, struct FTW *ftwbuf)
{
@@ -806,8 +978,10 @@ static int process_one_file(const char *fpath, const struct stat *sb,
level, sb->st_size, bname, fpath);
/* base dir */
- if (level == 0)
- return 0;
+ if (level == 0) {
+ LIST_INIT(&recommended_events);
+ return nftw(fpath, preprocess_level0_files, get_maxfds(), 0);
+ }
/* model directory, reset topic */
if (level == 1 && is_dir && isLeafDir(fpath)) {
@@ -869,9 +1043,7 @@ static int process_one_file(const char *fpath, const struct stat *sb,
* ignore it. It could be a readme.txt for instance.
*/
if (is_file) {
- char *suffix = bname + strlen(bname) - 5;
-
- if (strncmp(suffix, ".json", 5)) {
+ if (!isJsonFile(bname)) {
pr_info("%s: Ignoring file without .json suffix %s\n", prog,
fpath);
return 0;
@@ -933,6 +1105,7 @@ int main(int argc, char *argv[])
const char *output_file;
const char *start_dirname;
struct stat stbuf;
+ struct event_struct *es1, *es2;
prog = basename(argv[0]);
if (argc < 4) {
@@ -988,6 +1161,14 @@ int main(int argc, char *argv[])
goto empty_map;
}
+ /* Free struct for recommended events */
+ es1 = LIST_FIRST(&recommended_events);
+ while (es1) {
+ es2 = LIST_NEXT(es1, list);
+ free(es1);
+ es1 = es2;
+ }
+
if (close_table)
print_events_table_suffix(eventsfp);
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 3/5] perf vendor events arm64: add armv8 recommended events JSON
From: John Garry @ 2017-12-05 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512490399-94107-1-git-send-email-john.garry@huawei.com>
Add JSON for arm64 IMPLEMENTATION DEFINED recommended events.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
---
.../pmu-events/arch/arm64/armv8-recommended.json | 452 +++++++++++++++++++++
1 file changed, 452 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/arm64/armv8-recommended.json
diff --git a/tools/perf/pmu-events/arch/arm64/armv8-recommended.json b/tools/perf/pmu-events/arch/arm64/armv8-recommended.json
new file mode 100644
index 0000000..5584c31
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/armv8-recommended.json
@@ -0,0 +1,452 @@
+[
+ {
+ "PublicDescription": "Attributable Level 1 data cache access, read",
+ "EventCode": "0x40",
+ "EventName": "L1D_CACHE_RD",
+ "BriefDescription": "L1D cache access, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data cache access, write",
+ "EventCode": "0x41",
+ "EventName": "L1D_CACHE_WR",
+ "BriefDescription": "L1D cache access, write",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data cache refill, read",
+ "EventCode": "0x42",
+ "EventName": "L1D_CACHE_REFILL_RD",
+ "BriefDescription": "L1D cache refill, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data cache refill, write",
+ "EventCode": "0x43",
+ "EventName": "L1D_CACHE_REFILL_WR",
+ "BriefDescription": "L1D cache refill, write",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data cache refill, inner",
+ "EventCode": "0x44",
+ "EventName": "L1D_CACHE_REFILL_INNER",
+ "BriefDescription": "L1D cache refill, inner",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data cache refill, outer",
+ "EventCode": "0x45",
+ "EventName": "L1D_CACHE_REFILL_OUTER",
+ "BriefDescription": "L1D cache refill, outer",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data cache Write-Back, victim",
+ "EventCode": "0x46",
+ "EventName": "L1D_CACHE_WB_VICTIM",
+ "BriefDescription": "L1D cache Write-Back, victim",
+ },
+ {
+ "PublicDescription": "Level 1 data cache Write-Back, cleaning and coherency",
+ "EventCode": "0x47",
+ "EventName": "L1D_CACHE_WB_CLEAN",
+ "BriefDescription": "L1D cache Write-Back, cleaning and coherency",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data cache invalidate",
+ "EventCode": "0x48",
+ "EventName": "L1D_CACHE_INVAL",
+ "BriefDescription": "L1D cache invalidate",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data TLB refill, read",
+ "EventCode": "0x4C",
+ "EventName": "L1D_TLB_REFILL_RD",
+ "BriefDescription": "L1D tlb refill, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data TLB refill, write",
+ "EventCode": "0x4D",
+ "EventName": "L1D_TLB_REFILL_WR",
+ "BriefDescription": "L1D tlb refill, write",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data or unified TLB access, read",
+ "EventCode": "0x4E",
+ "EventName": "L1D_TLB_RD",
+ "BriefDescription": "L1D tlb access, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 1 data or unified TLB access, write",
+ "EventCode": "0x4F",
+ "EventName": "L1D_TLB_WR",
+ "BriefDescription": "L1D tlb access, write",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data cache access, read",
+ "EventCode": "0x50",
+ "EventName": "L2D_CACHE_RD",
+ "BriefDescription": "L2D cache access, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data cache access, write",
+ "EventCode": "0x51",
+ "EventName": "L2D_CACHE_WR",
+ "BriefDescription": "L2D cache access, write",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data cache refill, read",
+ "EventCode": "0x52",
+ "EventName": "L2D_CACHE_REFILL_RD",
+ "BriefDescription": "L2D cache refill, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data cache refill, write",
+ "EventCode": "0x53",
+ "EventName": "L2D_CACHE_REFILL_WR",
+ "BriefDescription": "L2D cache refill, write",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data cache Write-Back, victim",
+ "EventCode": "0x56",
+ "EventName": "L2D_CACHE_WB_VICTIM",
+ "BriefDescription": "L2D cache Write-Back, victim",
+ },
+ {
+ "PublicDescription": "Level 2 data cache Write-Back, cleaning and coherency",
+ "EventCode": "0x57",
+ "EventName": "L2D_CACHE_WB_CLEAN",
+ "BriefDescription": "L2D cache Write-Back, cleaning and coherency",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data cache invalidate",
+ "EventCode": "0x58",
+ "EventName": "L2D_CACHE_INVAL",
+ "BriefDescription": "L2D cache invalidate",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data or unified TLB refill, read",
+ "EventCode": "0x5c",
+ "EventName": "L2D_TLB_REFILL_RD",
+ "BriefDescription": "L2D cache refill, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data or unified TLB refill, write",
+ "EventCode": "0x5d",
+ "EventName": "L2D_TLB_REFILL_WR",
+ "BriefDescription": "L2D cache refill, write",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data or unified TLB access, read",
+ "EventCode": "0x5e",
+ "EventName": "L2D_TLB_RD",
+ "BriefDescription": "L2D cache access, read",
+ },
+ {
+ "PublicDescription": "Attributable Level 2 data or unified TLB access, write",
+ "EventCode": "0x5f",
+ "EventName": "L2D_TLB_WR",
+ "BriefDescription": "L2D cache access, write",
+ },
+ {
+ "PublicDescription": "Bus access read",
+ "EventCode": "0x60",
+ "EventName": "BUS_ACCESS_RD",
+ "BriefDescription": "Bus access read",
+ },
+ {
+ "PublicDescription": "Bus access write",
+ "EventCode": "0x61",
+ "EventName": "BUS_ACCESS_WR",
+ "BriefDescription": "Bus access write",
+ }
+ {
+ "PublicDescription": "Bus access, Normal, Cacheable, Shareable",
+ "EventCode": "0x62",
+ "EventName": "BUS_ACCESS_SHARED",
+ "BriefDescription": "Bus access, Normal, Cacheable, Shareable",
+ }
+ {
+ "PublicDescription": "Bus access, not Normal, Cacheable, Shareable",
+ "EventCode": "0x63",
+ "EventName": "BUS_ACCESS_NOT_SHARED",
+ "BriefDescription": "Bus access, not Normal, Cacheable, Shareable",
+ }
+ {
+ "PublicDescription": "Bus access, Normal",
+ "EventCode": "0x64",
+ "EventName": "BUS_ACCESS_NORMAL",
+ "BriefDescription": "Bus access, Normal",
+ }
+ {
+ "PublicDescription": "Bus access, peripheral",
+ "EventCode": "0x65",
+ "EventName": "BUS_ACCESS_PERIPH",
+ "BriefDescription": "Bus access, peripheral",
+ }
+ {
+ "PublicDescription": "Data memory access, read",
+ "EventCode": "0x66",
+ "EventName": "MEM_ACCESS_RD",
+ "BriefDescription": "Data memory access, read",
+ }
+ {
+ "PublicDescription": "Data memory access, write",
+ "EventCode": "0x67",
+ "EventName": "MEM_ACCESS_WR",
+ "BriefDescription": "Data memory access, write",
+ }
+ {
+ "PublicDescription": "Unaligned access, read",
+ "EventCode": "0x68",
+ "EventName": "UNALIGNED_LD_SPEC",
+ "BriefDescription": "Unaligned access, read",
+ }
+ {
+ "PublicDescription": "Unaligned access, write",
+ "EventCode": "0x69",
+ "EventName": "UNALIGNED_ST_SPEC",
+ "BriefDescription": "Unaligned access, write",
+ }
+ {
+ "PublicDescription": "Unaligned access",
+ "EventCode": "0x6a",
+ "EventName": "UNALIGNED_LDST_SPEC",
+ "BriefDescription": "Unaligned access",
+ }
+ {
+ "PublicDescription": "Exclusive operation speculatively executed, LDREX or LDX",
+ "EventCode": "0x6c",
+ "EventName": "LDREX_SPEC",
+ "BriefDescription": "Exclusive operation speculatively executed, LDREX or LDX",
+ }
+ {
+ "PublicDescription": "Exclusive operation speculatively executed, STREX or STX pass",
+ "EventCode": "0x6d",
+ "EventName": "STREX_PASS_SPEC",
+ "BriefDescription": "Exclusive operation speculatively executed, STREX or STX pass",
+ }
+ {
+ "PublicDescription": "Exclusive operation speculatively executed, STREX or STX fail",
+ "EventCode": "0x6e",
+ "EventName": "STREX_FAIL_SPEC",
+ "BriefDescription": "Exclusive operation speculatively executed, STREX or STX fail",
+ }
+ {
+ "PublicDescription": "Exclusive operation speculatively executed, STREX or STX",
+ "EventCode": "0x6f",
+ "EventName": "STREX_SPEC",
+ "BriefDescription": "Exclusive operation speculatively executed, STREX or STX",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, load",
+ "EventCode": "0x70",
+ "EventName": "LD_SPEC",
+ "BriefDescription": "Operation speculatively executed, load",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, store",
+ "EventCode": "0x71",
+ "EventName": "ST_SPEC",
+ "BriefDescription": "Operation speculatively executed, store",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, load or store",
+ "EventCode": "0x72",
+ "EventName": "LDST_SPEC",
+ "BriefDescription": "Operation speculatively executed, load or store",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, integer data processing",
+ "EventCode": "0x73",
+ "EventName": "DP_SPEC",
+ "BriefDescription": "Operation speculatively executed, integer data processing",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, Advanced SIMD instruction",
+ "EventCode": "0x74",
+ "EventName": "ASE_SPEC",
+ "BriefDescription": "Operation speculatively executed, Advanced SIMD instruction",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, floating-point instruction",
+ "EventCode": "0x75",
+ "EventName": "VFP_SPEC",
+ "BriefDescription": "Operation speculatively executed, floating-point instruction",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, software change of the PC",
+ "EventCode": "0x76",
+ "EventName": "PC_WRITE_SPEC",
+ "BriefDescription": "Operation speculatively executed, software change of the PC",
+ }
+ {
+ "PublicDescription": "Operation speculatively executed, Cryptographic instruction",
+ "EventCode": "0x77",
+ "EventName": "CRYPTO_SPEC",
+ "BriefDescription": "Operation speculatively executed, Cryptographic instruction",
+ }
+ {
+ "PublicDescription": "Branch speculatively executed, immediate branch"
+ "EventCode": "0x78",
+ "EventName": "BR_IMMED_SPEC",
+ "BriefDescription": "Branch speculatively executed, immediate branch"
+ }
+ {
+ "PublicDescription": "Branch speculatively executed, procedure return"
+ "EventCode": "0x79",
+ "EventName": "BR_RETURN_SPEC",
+ "BriefDescription": "Branch speculatively executed, procedure return"
+ }
+ {
+ "PublicDescription": "Branch speculatively executed, indirect branch"
+ "EventCode": "0x7a",
+ "EventName": "BR_INDIRECT_SPEC",
+ "BriefDescription": "Branch speculatively executed, indirect branch"
+ }
+ {
+ "PublicDescription": "Barrier speculatively executed, ISB"
+ "EventCode": "0x7c",
+ "EventName": "ISB_SPEC",
+ "BriefDescription": "Barrier speculatively executed, ISB"
+ }
+ {
+ "PublicDescription": "Barrier speculatively executed, DSB"
+ "EventCode": "0x7d",
+ "EventName": "DSB_SPEC",
+ "BriefDescription": "Barrier speculatively executed, DSB"
+ }
+ {
+ "PublicDescription": "Barrier speculatively executed, DMB"
+ "EventCode": "0x7e",
+ "EventName": "DMB_SPEC",
+ "BriefDescription": "Barrier speculatively executed, DMB"
+ }
+ {
+ "PublicDescription": "Exception taken, Other synchronous"
+ "EventCode": "0x81",
+ "EventName": "EXC_UNDEF",
+ "BriefDescription": "Exception taken, Other synchronous"
+ }
+ {
+ "PublicDescription": "Exception taken, Supervisor Call"
+ "EventCode": "0x82",
+ "EventName": "EXC_SVC",
+ "BriefDescription": "Exception taken, Supervisor Call"
+ }
+ {
+ "PublicDescription": "Exception taken, Instruction Abort"
+ "EventCode": "0x83",
+ "EventName": "EXC_PABORT",
+ "BriefDescription": "Exception taken, Instruction Abort"
+ }
+ {
+ "PublicDescription": "Exception taken, Data Abort and SError"
+ "EventCode": "0x84",
+ "EventName": "EXC_DABORT",
+ "BriefDescription": "Exception taken, Data Abort and SError"
+ }
+ {
+ "PublicDescription": "Exception taken, IRQ"
+ "EventCode": "0x86",
+ "EventName": "EXC_IRQ",
+ "BriefDescription": "Exception taken, IRQ"
+ }
+ {
+ "PublicDescription": "Exception taken, FIQ"
+ "EventCode": "0x87",
+ "EventName": "EXC_FIQ",
+ "BriefDescription": "Exception taken, FIQ"
+ }
+ {
+ "PublicDescription": "Exception taken, Secure Monitor Call"
+ "EventCode": "0x88",
+ "EventName": "EXC_SMC",
+ "BriefDescription": "Exception taken, Secure Monitor Call"
+ }
+ {
+ "PublicDescription": "Exception taken, Hypervisor Call"
+ "EventCode": "0x8a",
+ "EventName": "EXC_HVC",
+ "BriefDescription": "Exception taken, Hypervisor Call"
+ }
+ {
+ "PublicDescription": "Exception taken, Instruction Abort not taken locally"
+ "EventCode": "0x8b",
+ "EventName": "EXC_TRAP_PABORT",
+ "BriefDescription": "Exception taken, Instruction Abort not taken locally"
+ }
+ {
+ "PublicDescription": "Exception taken, Data Abort or SError not taken locally"
+ "EventCode": "0x8c",
+ "EventName": "EXC_TRAP_DABORT",
+ "BriefDescription": "Exception taken, Data Abort or SError not taken locally"
+ }
+ {
+ "PublicDescription": "Exception taken, Other traps not taken locally"
+ "EventCode": "0x8d",
+ "EventName": "EXC_TRAP_OTHER",
+ "BriefDescription": "Exception taken, Other traps not taken locally"
+ }
+ {
+ "PublicDescription": "Exception taken, IRQ not taken locally"
+ "EventCode": "0x8e",
+ "EventName": "EXC_TRAP_IRQ",
+ "BriefDescription": "Exception taken, IRQ not taken locally"
+ }
+ {
+ "PublicDescription": "Exception taken, FIQ not taken locally"
+ "EventCode": "0x8f",
+ "EventName": "EXC_TRAP_FIQ",
+ "BriefDescription": "Exception taken, FIQ not taken locally"
+ }
+ {
+ "PublicDescription": "Release consistency operation speculatively executed, Load-Acquire"
+ "EventCode": "0x90",
+ "EventName": "RC_LD_SPEC",
+ "BriefDescription": "Release consistency operation speculatively executed, Load-Acquire"
+ }
+ {
+ "PublicDescription": "Release consistency operation speculatively executed, Store-Release"
+ "EventCode": "0x91",
+ "EventName": "RC_ST_SPEC",
+ "BriefDescription": "Release consistency operation speculatively executed, Store-Release"
+ }
+ {
+ "PublicDescription": "Attributable Level 3 data or unified cache access, read"
+ "EventCode": "0xa0",
+ "EventName": "L3D_CACHE_RD",
+ "BriefDescription": "Attributable Level 3 data or unified cache access, read"
+ }
+ {
+ "PublicDescription": "Attributable Level 3 data or unified cache access, write"
+ "EventCode": "0xa1",
+ "EventName": "L3D_CACHE_WR",
+ "BriefDescription": "Attributable Level 3 data or unified cache access, write"
+ }
+ {
+ "PublicDescription": "Attributable Level 3 data or unified cache refill, read"
+ "EventCode": "0xa2",
+ "EventName": "L3D_CACHE_REFILL_RD",
+ "BriefDescription": "Attributable Level 3 data or unified cache refill, read"
+ }
+ {
+ "PublicDescription": "Attributable Level 3 data or unified cache refill, write"
+ "EventCode": "0xa3",
+ "EventName": "L3D_CACHE_REFILL_WR",
+ "BriefDescription": "Attributable Level 3 data or unified cache refill, write"
+ }
+ {
+ "PublicDescription": "Attributable Level 3 data or unified cache Write-Back, victim"
+ "EventCode": "0xa6",
+ "EventName": "L3D_CACHE_WB_VICTIM",
+ "BriefDescription": "Attributable Level 3 data or unified cache Write-Back, victim"
+ }
+ {
+ "PublicDescription": "Attributable Level 3 data or unified cache Write-Back, cache clean"
+ "EventCode": "0xa7",
+ "EventName": "L3D_CACHE_WB_CLEAN",
+ "BriefDescription": "Attributable Level 3 data or unified cache Write-Back, cache clean"
+ }
+ {
+ "PublicDescription": "Attributable Level 3 data or unified cache access, invalidate"
+ "EventCode": "0xa8",
+ "EventName": "L3D_CACHE_INVAL",
+ "BriefDescription": "Attributable Level 3 data or unified cache access, invalidate"
+ }
+]
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 4/5] perf vendor events arm64: relocate thunderx2 JSON
From: John Garry @ 2017-12-05 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512490399-94107-1-git-send-email-john.garry@huawei.com>
Since the pmu events architecture folder structure supports
arch/vendor/platform structure, relocate the ThunderX2 JSON.
Also since Cavium ThunderX2 has implemented its events
according to ARM recommendation, remove the fields apart from
"EventCode".
Signed-off-by: John Garry <john.garry@huawei.com>
---
.../arch/arm64/cavium/thunderx2-imp-def.json | 62 ----------------------
.../arch/arm64/cavium/thunderx2/core-imp-def.json | 32 +++++++++++
tools/perf/pmu-events/arch/arm64/mapfile.csv | 2 +-
3 files changed, 33 insertions(+), 63 deletions(-)
delete mode 100644 tools/perf/pmu-events/arch/arm64/cavium/thunderx2-imp-def.json
create mode 100644 tools/perf/pmu-events/arch/arm64/cavium/thunderx2/core-imp-def.json
diff --git a/tools/perf/pmu-events/arch/arm64/cavium/thunderx2-imp-def.json b/tools/perf/pmu-events/arch/arm64/cavium/thunderx2-imp-def.json
deleted file mode 100644
index 2db45c4..0000000
--- a/tools/perf/pmu-events/arch/arm64/cavium/thunderx2-imp-def.json
+++ /dev/null
@@ -1,62 +0,0 @@
-[
- {
- "PublicDescription": "Attributable Level 1 data cache access, read",
- "EventCode": "0x40",
- "EventName": "l1d_cache_rd",
- "BriefDescription": "L1D cache read",
- },
- {
- "PublicDescription": "Attributable Level 1 data cache access, write ",
- "EventCode": "0x41",
- "EventName": "l1d_cache_wr",
- "BriefDescription": "L1D cache write",
- },
- {
- "PublicDescription": "Attributable Level 1 data cache refill, read",
- "EventCode": "0x42",
- "EventName": "l1d_cache_refill_rd",
- "BriefDescription": "L1D cache refill read",
- },
- {
- "PublicDescription": "Attributable Level 1 data cache refill, write",
- "EventCode": "0x43",
- "EventName": "l1d_cache_refill_wr",
- "BriefDescription": "L1D refill write",
- },
- {
- "PublicDescription": "Attributable Level 1 data TLB refill, read",
- "EventCode": "0x4C",
- "EventName": "l1d_tlb_refill_rd",
- "BriefDescription": "L1D tlb refill read",
- },
- {
- "PublicDescription": "Attributable Level 1 data TLB refill, write",
- "EventCode": "0x4D",
- "EventName": "l1d_tlb_refill_wr",
- "BriefDescription": "L1D tlb refill write",
- },
- {
- "PublicDescription": "Attributable Level 1 data or unified TLB access, read",
- "EventCode": "0x4E",
- "EventName": "l1d_tlb_rd",
- "BriefDescription": "L1D tlb read",
- },
- {
- "PublicDescription": "Attributable Level 1 data or unified TLB access, write",
- "EventCode": "0x4F",
- "EventName": "l1d_tlb_wr",
- "BriefDescription": "L1D tlb write",
- },
- {
- "PublicDescription": "Bus access read",
- "EventCode": "0x60",
- "EventName": "bus_access_rd",
- "BriefDescription": "Bus access read",
- },
- {
- "PublicDescription": "Bus access write",
- "EventCode": "0x61",
- "EventName": "bus_access_wr",
- "BriefDescription": "Bus access write",
- }
-]
diff --git a/tools/perf/pmu-events/arch/arm64/cavium/thunderx2/core-imp-def.json b/tools/perf/pmu-events/arch/arm64/cavium/thunderx2/core-imp-def.json
new file mode 100644
index 0000000..99313eb
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/cavium/thunderx2/core-imp-def.json
@@ -0,0 +1,32 @@
+[
+ {
+ "EventCode": "0x40",
+ },
+ {
+ "EventCode": "0x41",
+ },
+ {
+ "EventCode": "0x42",
+ },
+ {
+ "EventCode": "0x43",
+ },
+ {
+ "EventCode": "0x4C",
+ },
+ {
+ "EventCode": "0x4D",
+ },
+ {
+ "EventCode": "0x4E",
+ },
+ {
+ "EventCode": "0x4F",
+ },
+ {
+ "EventCode": "0x60",
+ },
+ {
+ "EventCode": "0x61",
+ }
+]
diff --git a/tools/perf/pmu-events/arch/arm64/mapfile.csv b/tools/perf/pmu-events/arch/arm64/mapfile.csv
index 219d675..32fa0d1 100644
--- a/tools/perf/pmu-events/arch/arm64/mapfile.csv
+++ b/tools/perf/pmu-events/arch/arm64/mapfile.csv
@@ -12,4 +12,4 @@
#
#
#Family-model,Version,Filename,EventType
-0x00000000420f5160,v1,cavium,core
+0x00000000420f5160,v1,cavium/thunderx2,core
--
1.9.1
^ permalink raw reply related
* [RFC PATCH 5/5] perf vendor events arm64: add HiSilicon hip08 JSON
From: John Garry @ 2017-12-05 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512490399-94107-1-git-send-email-john.garry@huawei.com>
Add HiSilicon hip08 JSON. Since hip08 has its events
implementated according to ARM recommendation, only add
fields "EventCode" (where applicable - hip08 also has
implemented some other custom events).
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
---
.../arch/arm64/hisilicon/hip08/core-imp-def.json | 122 +++++++++++++++++++++
tools/perf/pmu-events/arch/arm64/mapfile.csv | 1 +
2 files changed, 123 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/core-imp-def.json
diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/core-imp-def.json b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/core-imp-def.json
new file mode 100644
index 0000000..94fde40
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/core-imp-def.json
@@ -0,0 +1,122 @@
+[
+ {
+ "EventCode": "0x40",
+ },
+ {
+ "EventCode": "0x41",
+ },
+ {
+ "EventCode": "0x42",
+ },
+ {
+ "EventCode": "0x43",
+ },
+ {
+ "EventCode": "0x46",
+ },
+ {
+ "EventCode": "0x47",
+ },
+ {
+ "EventCode": "0x48",
+ },
+ {
+ "EventCode": "0x4C",
+ },
+ {
+ "EventCode": "0x4D",
+ },
+ {
+ "EventCode": "0x4E",
+ },
+ {
+ "EventCode": "0x4F",
+ },
+ {
+ "EventCode": "0x50",
+ },
+ {
+ "EventCode": "0x51",
+ },
+ {
+ "EventCode": "0x52",
+ },
+ {
+ "EventCode": "0x53",
+ },
+ {
+ "EventCode": "0x56",
+ },
+ {
+ "EventCode": "0x57",
+ },
+ {
+ "EventCode": "0x58",
+ },
+ {
+ "PublicDescription": "Level 1 instruction cache prefetch access count",
+ "EventCode": "0x102e",
+ "EventName": "L1I_CACHE_PRF",
+ "BriefDescription": "L1I cache prefetch access count",
+ },
+ {
+ "PublicDescription": "Level 1 instruction cache miss due to prefetch access count",
+ "EventCode": "0x102f",
+ "EventName": "L1I_CACHE_PRF_REFILL",
+ "BriefDescription": "L1I cache miss due to prefetch access count",
+ },
+ {
+ "PublicDescription": "Instruction queue is empty",
+ "EventCode": "0x1043",
+ "EventName": "IQ_IS_EMPTY",
+ "BriefDescription": "Instruction queue is empty",
+ },
+ {
+ "PublicDescription": "Instruction fetch stall cycles",
+ "EventCode": "0x1044",
+ "EventName": "IF_IS_STALL",
+ "BriefDescription": "Instruction fetch stall cycles",
+ },
+ {
+ "PublicDescription": "Instructions can receive, but not send",
+ "EventCode": "0x2014",
+ "EventName": "FETCH_BUBBLE",
+ "BriefDescription": "Instructions can receive, but not send",
+ },
+ {
+ "PublicDescription": "Prefetch request from LSU",
+ "EventCode": "0x6013",
+ "EventName": "PRF_REQ",
+ "BriefDescription": "Prefetch request from LSU",
+ },
+ {
+ "PublicDescription": "Hit on prefetched data",
+ "EventCode": "0x6014",
+ "EventName": "HIT_ON_PRF",
+ "BriefDescription": "Hit on prefetched data",
+ },
+ {
+ "PublicDescription": "Cycles of that the number of issuing micro operations are less than 4",
+ "EventCode": "0x7001",
+ "EventName": "EXE_STALL_CYCLE",
+ "BriefDescription": "Cycles of that the number of issue ups are less than 4",
+ },
+ {
+ "PublicDescription": "No any micro operation is issued and meanwhile any load operation is not resolved",
+ "EventCode": "0x7004",
+ "EventName": "MEM_STALL_ANYLOAD",
+ "BriefDescription": "No any micro operation is issued and meanwhile any load operation is not resolved",
+ },
+ {
+ "PublicDescription": "No any micro operation is issued and meanwhile there is any load operation missing L1 cache and pending data refill",
+ "EventCode": "0x7006",
+ "EventName": "MEM_STALL_L1MISS",
+ "BriefDescription": "No any micro operation is issued and meanwhile there is any load operation missing L1 cache and pending data refill",
+ },
+ {
+ "PublicDescription": "No any micro operation is issued and meanwhile there is any load operation missing both L1 and L2 cache and pending data refill from L3 cache",
+ "EventCode": "0x7007",
+ "EventName": "MEM_STALL_L2MISS",
+ "BriefDescription": "No any micro operation is issued and meanwhile there is any load operation missing both L1 and L2 cache and pending data refill from L3 cache",
+ },
+]
diff --git a/tools/perf/pmu-events/arch/arm64/mapfile.csv b/tools/perf/pmu-events/arch/arm64/mapfile.csv
index 32fa0d1..9cc42da 100644
--- a/tools/perf/pmu-events/arch/arm64/mapfile.csv
+++ b/tools/perf/pmu-events/arch/arm64/mapfile.csv
@@ -13,3 +13,4 @@
#
#Family-model,Version,Filename,EventType
0x00000000420f5160,v1,cavium/thunderx2,core
+0x00000000480fd010,v1,hisilicon/hip08,core
--
1.9.1
^ permalink raw reply related
* [RFC PATCH] arm64: deactivate saved ttbr when mm is deactivated
From: Mark Rutland @ 2017-12-05 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205110619.et5nhkkprv7tmshu@lakrids.cambridge.arm.com>
On Tue, Dec 05, 2017 at 11:06:20AM +0000, Mark Rutland wrote:
> On Tue, Dec 05, 2017 at 10:30:40AM +0530, Vinayak Menon wrote:
> > On 12/4/2017 11:30 PM, Mark Rutland wrote:
> > > On Mon, Dec 04, 2017 at 04:55:33PM +0000, Will Deacon wrote:
> > >> On Mon, Dec 04, 2017 at 09:53:26PM +0530, Vinayak Menon wrote:
> > >>> A case is observed where a wrong physical address is read,
> > >>> resulting in a bus error and that happens soon after TTBR0 is
> > >>> set to the saved ttbr by uaccess_ttbr0_enable. This is always
> > >>> seen to happen in the exit path of the task.
> > >>>
> > >>> exception
> > >>> __arch_copy_from_user
> > >>> __copy_from_user
> > >>> probe_kernel_read
> > >>> get_freepointer_safe
> > >>> slab_alloc_node
> > >>> slab_alloc
> > >>> kmem_cache_alloc
> > >>> kmem_cache_zalloc
> > >>> fill_pool
> > >>> __debug_object_init
> > >>> debug_object_init
> > >>> rcuhead_fixup_activate
> > >>> debug_object_fixup
> > >>> debug_object_activate
> > >>> debug_rcu_head_queue
> > >>> __call_rcu
> > >>> ep_remove
> > >>> eventpoll_release_file
> > >>> __fput
> > >>> ____fput
> > >>> task_work_run
> > >>> do_exit
> > >>>
> > >>> The mm has been released and the pgd is freed, but probe_kernel_read
> > >>> invoked from slub results in call to __arch_copy_from_user. At the
> > >>> entry to __arch_copy_from_user, when SW PAN is enabled, this results
> > >>> in stale value being set to ttbr0. May be a speculative fetch aftwerwards
> > >>> is resulting in invalid physical address access.
>
> > > I think the problem here is that switch_mm() avoids updating the saved ttbr
> > > value when the next mm is init_mm.
>
> > For this switch to happen, the schedule() in do_task_dead at the end
> > of do_exit() need to be called, right ? The issue is happening soon
> > after exit_mm (probably from exit_files).
>
> I'd assumed that we'd switch_mm() away from the task's mm prior to the
> final mmput(). Otherwise, I can't see why we don't have issues in the
> non SW PAN case (as that would leave the HW TTBR0 stale).
>
> However, I can't see exactly where we do that, so I'll go diggging.
> Something doesn't seem quite right.
AFAICT, we rely on finish_task_switch() to do the final drop of the mm,
after* we've switched away from the task. So while the task is
installed, the mm (and associated pgd) should still be live, and not
freed.
So my patch shouldn't be necessary.
I'm afraid I don't have any other theory as to what's going on here.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] mm: make faultaround produce old ptes
From: Linus Torvalds @ 2017-12-05 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205121614.ek45btdgrpbmvf45@armageddon.cambridge.arm.com>
On Tue, Dec 5, 2017 at 4:16 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> I would be more in favour of some heuristics to dynamically reduce the
> fault-around bytes based on the memory pressure rather than choosing
> between young or old ptes. Or, if we are to go with old vs young ptes,
> make this choice dependent on the memory pressure regardless of whether
> the CPU supports hardware accessed bit.
That sounds like a good idea, but possibly a bit _too_ smart for
something that likely isn't a big deal.
The current behavior definitely is based on a "swapping is not a big
deal" mindset, and that getting the best LRU isn't worth it. That's
probably true in most circumstances, but if you really do have low
memory, and you really do have fairly random access behavior that
where the actual working set size is close to the actual memory size,
then a "get rid of faultaround pages earlier" mode would be a good
thing.
So I'm not at all against your idea - it sounds like the
RightThing(tm) to do - I just wonder how painful it is to generate a
sane heuristic that actually works in practice..
Linus
^ permalink raw reply
* [PATCH v6 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
From: Marc Zyngier @ 2017-12-05 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205150328.gcwnt5jzmoarvetd@yury-thinkpad>
On 05/12/17 15:03, Yury Norov wrote:
> On Mon, Dec 04, 2017 at 09:05:04PM +0100, Christoffer Dall wrote:
>> From: Christoffer Dall <christoffer.dall@linaro.org>
>>
>> For mapped IRQs (with the HW bit set in the LR) we have to follow some
>> rules of the architecture. One of these rules is that VM must not be
>> allowed to deactivate a virtual interrupt with the HW bit set unless the
>> physical interrupt is also active.
>>
>> This works fine when injecting mapped interrupts, because we leave it up
>> to the injector to either set EOImode==1 or manually set the active
>> state of the physical interrupt.
>>
>> However, the guest can set virtual interrupt to be pending or active by
>> writing to the virtual distributor, which could lead to deactivating a
>> virtual interrupt with the HW bit set without the physical interrupt
>> being active.
>>
>> We could set the physical interrupt to active whenever we are about to
>> enter the VM with a HW interrupt either pending or active, but that
>> would be really slow, especially on GICv2. So we take the long way
>> around and do the hard work when needed, which is expected to be
>> extremely rare.
>>
>> When the VM sets the pending state for a HW interrupt on the virtual
>> distributor we set the active state on the physical distributor, because
>> the virtual interrupt can become active and then the guest can
>> deactivate it.
>>
>> When the VM clears the pending state we also clear it on the physical
>> side, because the injector might otherwise raise the interrupt. We also
>> clear the physical active state when the virtual interrupt is not
>> active, since otherwise a SPEND/CPEND sequence from the guest would
>> prevent signaling of future interrupts.
>>
>> Changing the state of mapped interrupts from userspace is not supported,
>> and it's expected that userspace unmaps devices from VFIO before
>> attempting to set the interrupt state, because the interrupt state is
>> driven by hardware.
>>
>> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> ---
>> virt/kvm/arm/vgic/vgic-mmio.c | 71 +++++++++++++++++++++++++++++++++++++++----
>> virt/kvm/arm/vgic/vgic.c | 7 +++++
>> virt/kvm/arm/vgic/vgic.h | 1 +
>> 3 files changed, 73 insertions(+), 6 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
>> index 747b0a3b4784..8d173d99a7a4 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
>> @@ -16,6 +16,7 @@
>> #include <linux/kvm.h>
>> #include <linux/kvm_host.h>
>> #include <kvm/iodev.h>
>> +#include <kvm/arm_arch_timer.h>
>> #include <kvm/arm_vgic.h>
>>
>> #include "vgic.h"
>> @@ -143,10 +144,22 @@ static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
>> return vcpu;
>> }
>>
>> +/* Must be called with irq->irq_lock held */
>
> Instead of enforcing this rule in comment, you can enforce it in code:
>
> BUG_ON(!spin_is_locked(irq->irq_lock))
Are we going to litter the kernel with such assertions? I don't think
that's a valuable thing to do.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Add configs for peripherals on Keystone2 SoCs
From: Santosh Shilimkar @ 2017-12-05 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205091940.22957-1-vigneshr@ti.com>
On 12/5/2017 1:19 AM, Vignesh R wrote:
> Enable Cadence QSPI present on 66AK2G SoC and Keystone USB PHY driver
> for K2E.
>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 992a8a5da065..c4f4f6682ea5 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -185,6 +185,7 @@ CONFIG_MTD_NAND_BRCMNAND=y
> CONFIG_MTD_NAND_VF610_NFC=y
> CONFIG_MTD_NAND_DAVINCI=y
> CONFIG_MTD_SPI_NOR=y
> +CONFIG_SPI_CADENCE_QUADSPI=m
> CONFIG_SPI_FSL_QUADSPI=m
> CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> @@ -675,6 +676,7 @@ CONFIG_USB_CHIPIDEA_HOST=y
> CONFIG_USB_ISP1760=y
> CONFIG_USB_HSIC_USB3503=y
> CONFIG_AB8500_USB=y
> +CONFIG_KEYSTONE_USB_PHY=m
> CONFIG_NOP_USB_XCEIV=m
> CONFIG_USB_GPIO_VBUS=y
> CONFIG_USB_ISP1301=y
>
There are more peripherals/drivers which are enabled
in keystone config.
PWM_TIECAP, CAN_C_CAN, RESET_TI_SYSCON, TI_SCI_PROTOCOL,
TI_MESSAGE_MANAGER, NOP_USB_XCEIV, GPIO_PCA953X etc etc
Could please check the complete config and update the
patch please ?
^ permalink raw reply
* [PATCH] irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry
From: Marc Zyngier @ 2017-12-05 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <250756b7-741e-9295-abcd-b4a69898c10a@codeaurora.org>
On 05/12/17 13:21, Shanker Donthineni wrote:
> Hi Marc,
>
> On 12/05/2017 02:59 AM, Marc Zyngier wrote:
>> On 04/12/17 14:04, Shanker Donthineni wrote:
>>> Hi Thanks,
>>>
>>> On 12/04/2017 04:28 AM, Marc Zyngier wrote:
>>>> On 03/12/17 23:21, Shanker Donthineni wrote:
>>>>> As per MADT specification, it's perfectly valid firmware can pass
>>>>> MADT table to OS with disabled GICC entries. ARM64-SMP code skips
>>>>> those cpu cores to bring online. However the current GICv3 driver
>>>>> probe bails out in this case on systems where redistributor regions
>>>>> are not in the always-on power domain.
>>>>>
>>>>> This patch does the two things to fix the panic.
>>>>> - Don't return an error in gic_acpi_match_gicc() for disabled GICC.
>>>>> - No need to keep GICR region information for disabled GICC.
>>>>>
>>>>> Kernel crash traces:
>>>>> Kernel panic - not syncing: No interrupt controller found.
>>>>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26
>>>>> [<ffff000008087770>] dump_backtrace+0x0/0x218
>>>>> [<ffff0000080879dc>] show_stack+0x14/0x20
>>>>> [<ffff00000883b078>] dump_stack+0x98/0xb8
>>>>> [<ffff0000080c5c14>] panic+0x118/0x26c
>>>>> [<ffff000008b62348>] init_IRQ+0x24/0x2c
>>>>> [<ffff000008b609fc>] start_kernel+0x230/0x394
>>>>> [<ffff000008b601e4>] __primary_switched+0x64/0x6c
>>>>> ---[ end Kernel panic - not syncing: No interrupt controller found.
>>>>>
>>>>> Disabled GICC subtable example:
>>>>> Subtable Type : 0B [Generic Interrupt Controller]
>>>>> Length : 50
>>>>> Reserved : 0000
>>>>> CPU Interface Number : 0000003D
>>>>> Processor UID : 0000003D
>>>>> Flags (decoded below) : 00000000
>>>>> Processor Enabled : 0
>>>>> Performance Interrupt Trig Mode : 0
>>>>> Virtual GIC Interrupt Trig Mode : 0
>>>>> Parking Protocol Version : 00000000
>>>>> Performance Interrupt : 00000017
>>>>> Parked Address : 0000000000000000
>>>>> Base Address : 0000000000000000
>>>>> Virtual GIC Base Address : 0000000000000000
>>>>> Hypervisor GIC Base Address : 0000000000000000
>>>>> Virtual GIC Interrupt : 00000019
>>>>> Redistributor Base Address : 0000FFFF88F40000
>>>>> ARM MPIDR : 000000000000000D
>>>>> Efficiency Class : 00
>>>>> Reserved : 000000
>>>>>
>>>>> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
>>>>> ---
>>>>> drivers/irqchip/irq-gic-v3.c | 14 +++++++++-----
>>>>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>>>>> index b56c3e2..a30fbac 100644
>>>>> --- a/drivers/irqchip/irq-gic-v3.c
>>>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>>>> @@ -1331,6 +1331,10 @@ static int __init gic_of_init(struct device_node *node, struct device_node *pare
>>>>> u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
>>>>> void __iomem *redist_base;
>>>>>
>>>>> + /* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */
>>>>> + if (!(gicc->flags & ACPI_MADT_ENABLED))
>>>>> + return 0;
>>>>> +
>>>>> redist_base = ioremap(gicc->gicr_base_address, size);
>>>>> if (!redist_base)
>>>>> return -ENOMEM;
>>>>> @@ -1374,13 +1378,13 @@ static int __init gic_acpi_match_gicc(struct acpi_subtable_header *header,
>>>>> (struct acpi_madt_generic_interrupt *)header;
>>>>>
>>>>> /*
>>>>> - * If GICC is enabled and has valid gicr base address, then it means
>>>>> - * GICR base is presented via GICC
>>>>> + * If GICC is enabled and has not valid gicr base address, then it means
>>>>> + * GICR base is not presented via GICC
>>>>> */
>>>>> - if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
>>>>> - return 0;
>>>>> + if ((gicc->flags & ACPI_MADT_ENABLED) && (!gicc->gicr_base_address))
>>>>> + return -ENODEV;
>>>>
>>>> This doesn't feel quite right. It would mean that having the ENABLED
>>>> flag cleared and potentially no address would make it valid? It looks to
>>>> me that the original code is "less wrong".
>>>>
>>>> What am I missing?
>>>>
>>>
>>> Original definition of the function gic_acpi_match_gicc().
>>> {
>>> if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
>>> return 0;
>>>
>>> return -ENODEV;
>>> }
>>>
>>> Above code triggers the driver probe fail for the two reasons.
>>> 1) GICC with ACPI_MADT_ENABLED=0, it's a bug according to ACPI spec.
>>> 2) GICC with ACPI_MADT_ENABLED=1 and invalid GICR address, expected.
>>>
>>>
>>> This patch fix the first failed case and keep the second case intact.
>>> if ((gicc->flags & ACPI_MADT_ENABLED) && (!gicc->gicr_base_address))
>>> return -ENODEV;
>>>
>>> return 0;
>> If (1) is a firmware bug, then why is it handled in the SMP code? You're
>> even saying that this is the right thing to do?
>>
>
> It's a bug in Linux GICv3 driver not firmware. Firmware is populating MADT
> table according to ACPI specification.
>
>> As for (2), you seem to imply that only the address matter. So why isn't
>> it just:
>>
>> if (gicc->gicr_base_address)
>> return 0;
>>
>> ?
>
> ACPI spec says operating shouldn't attempt to use GICC configuration parameters
> if the flag ACPI_MADT_ENABLED is cleared. I believe we should check GICR address
> only for enabled GICC interfaces.
Then please rewrite the commit message to actually explain this. This is
confusing as hell.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARM: dts: introduce the sama5d2 ptc ek board
From: Baruch Siach @ 2017-12-05 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205142312.21506-1-ludovic.desroches@microchip.com>
Hi Ludovic,
On Tue, Dec 05, 2017 at 03:23:12PM +0100, Ludovic Desroches wrote:
> Add the official SAMA5D2 Peripheral Touch Controller Evaluation
> Kit board.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
[...]
> + memory {
> + reg = <0x20000000 0x80000>;
> + };
The size value is clearly wrong; you surely don't run on 512KB RAM. You most
likely rely on the bootloader to fix the size value. Since sama5d2.dtsi has a
memory node already with the same address, you can just drop it from here.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH V6 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: linux-arm-kernel
Introduce new ACPI and OF device ids for thw HW along with the helper
functions.
Changes from v5:
* use struct device as a calling parameter to get_match_data() callback
so that we can reuse the existing OF API.
* revert the change on acpi_get_match_data() to V4.
Sinan Kaya (7):
Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
ACPI / bus: Introduce acpi_get_match_data() function
device property: Introduce a common API to fetch device match data
OF: properties: Implement get_match_data() callback
ACPI: properties: Implement get_match_data() callback
dmaengine: qcom_hidma: Add support for the new revision
dmaengine: qcom_hidma: Add identity register support
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 +--
drivers/acpi/bus.c | 12 +++++++
drivers/acpi/property.c | 7 ++++
drivers/base/property.c | 6 ++++
drivers/dma/qcom/hidma.c | 41 ++++++++++------------
drivers/of/property.c | 7 ++++
include/linux/acpi.h | 6 ++++
include/linux/fwnode.h | 4 +++
include/linux/property.h | 2 ++
9 files changed, 65 insertions(+), 24 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH V6 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
A new version of the HIDMA IP has been released with bug fixes. Bumping the
hardware version to differentiate from others.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 55492c2..5d93d6d 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,8 +47,8 @@ When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
-- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
-for MSI capable HW.
+- compatible: must contain "qcom,hidma-1.0" for initial HW or
+ "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
--
1.9.1
^ permalink raw reply related
* [PATCH V6 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
OF has of_device_get_match_data() function to extract driver specific data
structure. Add a similar function for ACPI.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/bus.c | 12 ++++++++++++
include/linux/acpi.h | 6 ++++++
2 files changed, 18 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e..b271eb1 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -785,6 +785,18 @@ const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
}
EXPORT_SYMBOL_GPL(acpi_match_device);
+void *acpi_get_match_data(const struct device *dev)
+{
+ const struct acpi_device_id *match;
+
+ match = acpi_match_device(dev->driver->acpi_match_table, dev);
+ if (!match)
+ return NULL;
+
+ return (void *)match->driver_data;
+}
+EXPORT_SYMBOL_GPL(acpi_get_match_data);
+
int acpi_match_device_ids(struct acpi_device *device,
const struct acpi_device_id *ids)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 502af53..a927260 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -584,6 +584,7 @@ extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
const struct device *dev);
+void *acpi_get_match_data(const struct device *dev);
extern bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv);
int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
@@ -755,6 +756,11 @@ static inline const struct acpi_device_id *acpi_match_device(
return NULL;
}
+static inline void *acpi_get_match_data(const struct device *dev)
+{
+ return NULL;
+}
+
static inline bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv)
{
--
1.9.1
^ permalink raw reply related
* [PATCH V6 3/7] device property: Introduce a common API to fetch device match data
From: Sinan Kaya @ 2017-12-05 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512493493-6464-1-git-send-email-okaya@codeaurora.org>
There is an OF/ACPI function to obtain the driver data. We want to hide
OF/ACPI details from the device drivers and abstract following the device
family of functions.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/base/property.c | 6 ++++++
include/linux/fwnode.h | 4 ++++
include/linux/property.h | 2 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 7ed99c1..65bf6f2 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1335,3 +1335,9 @@ int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
return fwnode_call_int_op(fwnode, graph_parse_endpoint, endpoint);
}
EXPORT_SYMBOL(fwnode_graph_parse_endpoint);
+
+void *device_get_match_data(struct device *dev)
+{
+ return fwnode_call_ptr_op(dev_fwnode(dev), get_match_data, dev);
+}
+EXPORT_SYMBOL_GPL(device_get_match_data);
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 0c35b6c..ab9aab5 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -15,6 +15,7 @@
#include <linux/types.h>
struct fwnode_operations;
+struct device;
struct fwnode_handle {
struct fwnode_handle *secondary;
@@ -66,6 +67,7 @@ struct fwnode_reference_args {
* endpoint node.
* @graph_get_port_parent: Return the parent node of a port node.
* @graph_parse_endpoint: Parse endpoint for port and endpoint id.
+ * @get_match_data: Return the driver match data.
*/
struct fwnode_operations {
void (*get)(struct fwnode_handle *fwnode);
@@ -101,6 +103,8 @@ struct fwnode_operations {
(*graph_get_port_parent)(struct fwnode_handle *fwnode);
int (*graph_parse_endpoint)(const struct fwnode_handle *fwnode,
struct fwnode_endpoint *endpoint);
+ void *(*get_match_data)(const struct fwnode_handle *fwnode,
+ struct device *dev);
};
#define fwnode_has_op(fwnode, op) \
diff --git a/include/linux/property.h b/include/linux/property.h
index 6bebee1..01fa55b 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -275,6 +275,8 @@ int device_add_properties(struct device *dev,
enum dev_dma_attr device_get_dma_attr(struct device *dev);
+void *device_get_match_data(struct device *dev);
+
int device_get_phy_mode(struct device *dev);
void *device_get_mac_address(struct device *dev, char *addr, int alen);
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox