* Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
From: Stefan Wahren @ 2019-09-13 10:08 UTC (permalink / raw)
To: Matthias Brugger, catalin.marinas, marc.zyngier, Matthias Brugger,
robh+dt, linux-mm, linux-arm-kernel, linux-riscv, hch,
Nicolas Saenz Julienne
Cc: f.fainelli, robin.murphy, phil, linux-kernel, linux-rpi-kernel,
will, m.szyprowski
In-Reply-To: <2fcc5ad6-fa90-6565-e75c-d20b46965733@suse.com>
Am 13.09.19 um 11:25 schrieb Matthias Brugger:
>
> On 13/09/2019 10:50, Stefan Wahren wrote:
>> Am 13.09.19 um 10:09 schrieb Matthias Brugger:
>>> On 12/09/2019 21:32, Stefan Wahren wrote:
>>>> Am 12.09.19 um 19:18 schrieb Matthias Brugger:
>>>>> On 10/09/2019 11:27, Matthias Brugger wrote:
>>>>>> On 09/09/2019 21:33, Stefan Wahren wrote:
>>>>>>> Hi Nicolas,
>>>>>>>
>>>>>>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
>>>>>>>> Hi all,
>>>>>>>> this series attempts to address some issues we found while bringing up
>>>>>>>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
>>>>>>>> up of these discussions:
>>>>>>>> v4: https://lkml.org/lkml/2019/9/6/352
>>>>>>>> v3: https://lkml.org/lkml/2019/9/2/589
>>>>>>>> v2: https://lkml.org/lkml/2019/8/20/767
>>>>>>>> v1: https://lkml.org/lkml/2019/7/31/922
>>>>>>>> RFC: https://lkml.org/lkml/2019/7/17/476
>>>>>>>>
>>>>>>>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
>>>>>>>> only address the first GB: their DMA address range is
>>>>>>>> 0xc0000000-0xfc000000 which is aliased to the first GB of physical
>>>>>>>> memory 0x00000000-0x3c000000. Note that only some peripherals have these
>>>>>>>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
>>>>>>>> view of the address space by virtue of being hooked up trough a second
>>>>>>>> interconnect.
>>>>>>>>
>>>>>>>> Part of this is solved on arm32 by setting up the machine specific
>>>>>>>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent
>>>>>>>> memory area at the right spot. That said no buffer bouncing (needed for
>>>>>>>> dma streaming) is available at the moment, but that's a story for
>>>>>>>> another series.
>>>>>>>>
>>>>>>>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
>>>>>>>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
>>>>>>>> arch code as if all peripherals where be able to address the first 4GB
>>>>>>>> of memory.
>>>>>>>>
>>>>>>>> In the light of this, the series implements the following changes:
>>>>>>>>
>>>>>>>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G
>>>>>>>> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far
>>>>>>>> the RPi4 is the only arm64 device with such DMA addressing limitations
>>>>>>>> so this hardcoded solution was deemed preferable.
>>>>>>>>
>>>>>>>> - Properly set ARCH_ZONE_DMA_BITS.
>>>>>>>>
>>>>>>>> - Reserve the CMA area in a place suitable for all peripherals.
>>>>>>>>
>>>>>>>> This series has been tested on multiple devices both by checking the
>>>>>>>> zones setup matches the expectations and by double-checking physical
>>>>>>>> addresses on pages allocated on the three relevant areas GFP_DMA,
>>>>>>>> GFP_DMA32, GFP_KERNEL:
>>>>>>>>
>>>>>>>> - On an RPi4 with variations on the ram memory size. But also forcing
>>>>>>>> the situation where all three memory zones are nonempty by setting a 3G
>>>>>>>> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
>>>>>>>>
>>>>>>> i like to test this series on Raspberry Pi 4 and i have some questions
>>>>>>> to get arm64 running:
>>>>>>>
>>>>>>> Do you use U-Boot? Which tree?
>>>>>> If you want to use U-Boot, try v2019.10-rc4, it should have everything you need
>>>>>> to boot your kernel.
>>>>>>
>>>>> Ok, here is a thing. In the linux kernel we now use bcm2711 as SoC name, but the
>>>>> RPi4 devicetree provided by the FW uses mostly bcm2838.
>>>> Do you mean the DTB provided at runtime?
>>>>
>>>> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi
>>>> series?
>>>>
>>>>> U-Boot in its default
>>>>> config uses the devicetree provided by the FW, mostly because this way you don't
>>>>> have to do anything to find out how many RAM you really have. Secondly because
>>>>> this will allow us, in the near future, to have one U-boot binary for both RPi3
>>>>> and RPi4 (and as a side effect one binary for RPi1 and RPi2).
>>>>>
>>>>> Anyway, I found at least, that the following compatibles need to be added:
>>>>>
>>>>> "brcm,bcm2838-cprman"
>>>>> "brcm,bcm2838-gpio"
>>>>>
>>>>> Without at least the cprman driver update, you won't see anything.
>>>>>
>>>>> "brcm,bcm2838-rng200" is also a candidate.
>>>>>
>>>>> I also suppose we will need to add "brcm,bcm2838" to
>>>>> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this.
>>>> How about changing this in the downstream kernel? Which is much easier.
>>> I'm not sure I understand what you want to say. My goal is to use the upstream
>>> kernel with the device tree blob provided by the FW.
>> The device tree blob you are talking is defined in this repository:
>>
>> https://github.com/raspberrypi/linux
>>
>> So the word FW is misleading to me.
>>
> No, it's part of
> https://github.com/raspberrypi/firmware.git
> file boot/bcm2711-rpi-4-b.dtb
The compiled DT blobs incl. the kernel image are stored in this artifact
repository. But the sources for the kernel and the DT are in the Linux
repo. This is necessary to be compliant to the GPL.
>
>>> If you talk about the
>>> downstream kernel, I suppose you mean we should change this in the FW DT blob
>>> and in the downstream kernel. That would work for me.
>>>
>>> Did I understand you correctly?
>> Yes
>>
>> So i suggest to add the upstream compatibles into the repo mentioned above.
>>
>> Sorry, but in case you decided as a U-Boot developer to be compatible
>> with a unreviewed DT, we also need to make U-Boot compatible with
>> upstream and downstream DT blobs.
>>
> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier
> if we can use this DTB we can work towards one binary that can boot both RPi3
> and RPi4. On the other hand we can rely on the FW to detect the amount of memory
> our RPi4 has.
>
> That said, I agree that we should make sure that U-Boot can boot with both DTBs,
> the upstream one and the downstream. Now the question is how to get to this. I'm
> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711
> compatible is already reviewed and can't be changed. From what I can see none of
> these compatibles got merged for now, so we are still at time to change them.
Stephen Boyd was okay with clk changes except of a small nit. So i fixed
this is as he suggested in a separate series. Unfortunately this hasn't
be applied yet [1].
The i2c, pinctrl and the sdhci changes has been applied yet.
In my opinion it isn't the job of the mainline kernel to adapt to a
vendor device tree. It's the vendor device tree which needs to be fixed.
Sorry, but this is my holiday. I will back after the weekend.
Best regards
Stefan
[1] - https://www.spinics.net/lists/linux-clk/msg40534.html
>
> Apart from the point Florian made, to stay consistent with the RPi SoC naming,
> it will save us work, both in the kernel and in U-Boot, as we would need to add
> both compatibles to the code-base.
>
> Regards,
> Matthias
>
>>>>> Regards,
>>>>> Matthias
>>>>>
>>>>>> Regards,
>>>>>> Matthias
>>>>>>
>>>>>>> Are there any config.txt tweaks necessary?
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>>
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V7 3/3] arm64/mm: Enable memory hot remove
From: Catalin Marinas @ 2019-09-13 10:09 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, mhocko, david, linux-mm, arunks, cpandya, ira.weiny,
will, steven.price, valentin.schneider, suzuki.poulose,
Robin.Murphy, broonie, cai, ard.biesheuvel, dan.j.williams,
linux-arm-kernel, osalvador, steve.capper, logang, linux-kernel,
akpm, mgorman
In-Reply-To: <ce127798-3863-0f28-de04-84b177418310@arm.com>
On Fri, Sep 13, 2019 at 11:28:01AM +0530, Anshuman Khandual wrote:
> On 09/13/2019 01:45 AM, Catalin Marinas wrote:
> > On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
> >> @@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> >> void vmemmap_free(unsigned long start, unsigned long end,
> >> struct vmem_altmap *altmap)
> >> {
> >> +#ifdef CONFIG_MEMORY_HOTPLUG
> >> + /*
> >> + * FIXME: We should have called remove_pagetable(start, end, true).
> >> + * vmemmap and vmalloc virtual range might share intermediate kernel
> >> + * page table entries. Removing vmemmap range page table pages here
> >> + * can potentially conflict with a concurrent vmalloc() allocation.
> >> + *
> >> + * This is primarily because vmalloc() does not take init_mm ptl for
> >> + * the entire page table walk and it's modification. Instead it just
> >> + * takes the lock while allocating and installing page table pages
> >> + * via [p4d|pud|pmd|pte]_alloc(). A concurrently vanishing page table
> >> + * entry via memory hot remove can cause vmalloc() kernel page table
> >> + * walk pointers to be invalid on the fly which can cause corruption
> >> + * or worst, a crash.
> >> + *
> >> + * So free_empty_tables() gets called where vmalloc and vmemmap range
> >> + * do not overlap at any intermediate level kernel page table entry.
> >> + */
> >> + unmap_hotplug_range(start, end, true);
> >> + if (!vmalloc_vmemmap_overlap)
> >> + free_empty_tables(start, end);
> >> +#endif
> >> }
> >
> > So, I see the risk with overlapping and I guess for some kernel
> > configurations (PAGE_SIZE == 64K) we may not be able to avoid it. If we
>
> Did not see 64K config options to have overlap, do you suspect they might ?
> After the 52 bit KVA series has been merged, following configurations have
> the vmalloc-vmemmap range overlap problem.
>
> - 4K page size with 48 bit VA space
> - 16K page size with 48 bit VA space
OK. I haven't checked, so it was just a guess that 64K has this problem
since the pgd entry coverage is fairly large.
> > can, that's great, otherwise could we rewrite the above functions to
> > handle floor and ceiling similar to free_pgd_range()? (I wonder how this
> > function works if you called it on init_mm and kernel address range). By
>
> Hmm, never tried that. Are you wondering if this can be used directly ?
> There are two distinct elements which make it very specific to user page
> tables, mmu_gather based TLB tracking and mm->pgtable_bytes accounting
> with mm_dec_nr_pxx().
Ah, I missed the mm_dec_nr_*(). So I don't think it would work directly.
We could, however, use the same approach for kernel page tables.
> > having the vmemmap start/end information it avoids freeing partially
> > filled page table pages.
>
> Did you mean page table pages which can partially overlap with vmalloc ?
Overlapping with the vmalloc range, not necessarily with a mapped
vmalloc area.
> The problem (race) is not because of the inability to deal with partially
> filled table. We can handle that correctly as explained below [1]. The
> problem is with inadequate kernel page table locking during vmalloc()
> which might be accessing intermediate kernel page table pointers which is
> being freed with free_empty_tables() concurrently. Hence we cannot free
> any page table page which can ever have entries from vmalloc() range.
The way you deal with the partially filled table in this patch is to
avoid freeing if there is a non-empty entry (!p*d_none()). This is what
causes the race with vmalloc. If you simply avoid freeing a pmd page,
for example, if the range floor/ceiling is not aligned to PUD_SIZE,
irrespective of whether the other entries are empty or not, you
shouldn't have this problem. You do free the pte page if the range is
aligned to PMD_SIZE but in this case it wouldn't overlap with the
vmalloc space. That's how free_pgd_range() works.
We may have some pgtable pages not freed at both ends of the range
(maximum 6 in total) but I don't really see this an issue. They could be
reused if something else gets mapped in that range.
> Though not completely sure, whether I really understood the suggestion above
> with respect to the floor-ceiling mechanism as in free_pgd_range(). Are you
> suggesting that we should only attempt to free up those vmemmap range page
> table pages which *definitely* could never overlap with vmalloc by working
> on a modified (i.e cut down with floor-ceiling while avoiding vmalloc range
> at each level) vmemmap range instead ?
You can ignore the overlap check altogether, only free the page tables
with floor/ceiling set to the start/size passed to arch_remove_memory()
and vmemmap_free().
> This can be one restrictive version of the function
> free_empty_tables() called in case there is an overlap. So we will
> maintain two versions for free_empty_tables(). Please correct me if
> any the above assumptions or understanding is wrong.
I'd rather have a single version of free_empty_tables(). As I said
above, the only downside is that a partially filled pgtable page would
not be freed even though the other entries are empty.
> But yes, with this we should be able to free up some possible empty page
> table pages which were being left out in the current proposal when overlap
> happens.
>
> [1] Skipping partially filled page tables
>
> All free_pXX_table() functions take care in avoiding freeing partially filled
> page table pages whether they represent or ever represented linear or vmemmap
> or vmalloc mapping in init_mm. They go over each individual entry in a given
> page table making sure that each of them checks as pXX_none() before freeing
> the entire page table page.
Yes but that's what's causing the race with a vmalloc trying to create
such entries.
> > Another question: could we do the page table and the actual vmemmap
> > pages freeing in a single pass (sorry if this has been discussed
> > before)?
>
> We could and some initial versions (till V5) of the series had that in fact.
> Initially Mark Rutland had suggested to do this in two passes. Some extracts
> from the previous discussion.
>
> https://lkml.org/lkml/2019/5/30/1159
>
> -----------------------
> Looking at this some more, I don't think this is quite right, and tI
> think that structure of the free_*() and remove_*() functions makes this
> unnecessarily hard to follow. We should aim for this to be obviously
> correct.
>
> The x86 code is the best template to follow here. As mentioned
> previously, I'm fairly certain it's not entirely correct (e.g. due to
> missing TLB maintenance), and we've already diverged a fair amount in
> fixing up obvious issues, so we shouldn't aim to mirror it.
>
> I think that the structure of unmap_region() is closer to what we want
> here -- do one pass to unmap leaf entries (and freeing the associated
> memory if unmapping the vmemmap), then do a second pass cleaning up any
> empty tables.
> ----------------------
>
> Apart from the fact that two passes over the page table is cleaner and gives
> us more granular and modular infrastructure to use for later purposes, it is
> also a necessity in dealing with vmalloc-vmemmap overlap. free_empty_tables()
> which is the second pass, can be skipped cleanly when overlap is detected.
I'm fine with two passes for unmap and pgtable free for the time being
and if they look fairly similar in a feature version, we can think of
merging them. But for now, stick with two passes. The unmapping one in
this patchset I think seems fine (though I haven't looked in detail).
There is also a race with ptdump that I haven't looked into.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] arm64: Kconfig: Fix VEXPRESS driver dependencies
From: Sudeep Holla @ 2019-09-13 10:12 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Sudeep Holla, linux-clk, linux-kernel,
Kishon Vijay Abraham I, Bartosz Golaszewski, arm, Mark Brown,
Sebastian Reichel, Will Deacon, Michael Turquette,
linux-arm-kernel
In-Reply-To: <8f539b28c25d22b8f515c131cd6b24c309f7ca90.1568239378.git.amit.kucheria@linaro.org>
On Thu, Sep 12, 2019 at 03:48:47AM +0530, Amit Kucheria wrote:
> Push various VEXPRESS drivers behind ARCH_VEXPRESS dependency so that it
> doesn't get enabled by default on other platforms.
>
I couldn't understand the motivation for these changes from the cover letter.
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
> drivers/bus/Kconfig | 2 +-
> drivers/clk/versatile/Kconfig | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index d80e8d70bf10..b2b1beee9953 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -166,7 +166,7 @@ config UNIPHIER_SYSTEM_BUS
>
> config VEXPRESS_CONFIG
> bool "Versatile Express configuration bus"
> - default y if ARCH_VEXPRESS
> + depends on ARCH_VEXPRESS
> depends on ARM || ARM64
> depends on OF
> select REGMAP
> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
> index ac766855ba16..826750292c1e 100644
> --- a/drivers/clk/versatile/Kconfig
> +++ b/drivers/clk/versatile/Kconfig
> @@ -5,8 +5,8 @@ config ICST
> config COMMON_CLK_VERSATILE
> bool "Clock driver for ARM Reference designs"
> depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
> - ARCH_VERSATILE || ARCH_VEXPRESS || ARM64 || \
> - COMPILE_TEST
> + ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST
> + depends on ARM64
This will break 32-bit platforms.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64 updates for 5.4
From: Will Deacon @ 2019-09-13 10:20 UTC (permalink / raw)
To: torvalds; +Cc: catalin.marinas, linux-kernel, linux-arm-kernel
Hi Linus,
Here is the arm64 pull for 5.4 in anticipation of the merge window opening
next week. Although there isn't tonnes of code in terms of line count,
there are a fair few headline features which I've noted both in the tag
and also in the merge commits when I pulled everything together.
The part I'm most pleased with is that we had 35 contributors this time
around, which feels like a big jump from the usual small group of core
arm64 arch developers. Hopefully they all enjoyed it so much that they'll
continue to contribute, but we'll see.
The pull should be straightforward, but it's probably worth highlighting
the following:
* We've pulled in a branch from the risc-v folks which moves our CPU
topology code out to where it can be shared with others.
* There are a few small changes outside of the files we usually touch
(e.g. char/random.c) but these have all been reviewed/acked by the
relevant maintainers.
* There are a couple of very trivial conflicts in linux-next; one is in
arch/Kconfig with the Power tree where you can take both hunks, and the
other is the removal of our asm/dma-mapping.h file by Christoph where
you can just remove the file/ignore our change.
* I've renewed the expiry date on my pgp key, so you may need to refetch
from the kernel.org keys repository.
Cheers,
Will
--->8
The following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d:
Linux 5.3-rc3 (2019-08-04 18:40:12 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-upstream
for you to fetch changes up to e376897f424a1c807779a2635f62eb02d7e382f9:
arm64: remove __iounmap (2019-09-04 13:12:26 +0100)
----------------------------------------------------------------
arm64 updates for 5.4:
- 52-bit virtual addressing in the kernel
- New ABI to allow tagged user pointers to be dereferenced by syscalls
- Early RNG seeding by the bootloader
- Improve robustness of SMP boot
- Fix TLB invalidation in light of recent architectural clarifications
- Support for i.MX8 DDR PMU
- Remove direct LSE instruction patching in favour of static keys
- Function error injection using kprobes
- Support for the PPTT "thread" flag introduced by ACPI 6.3
- Move PSCI idle code into proper cpuidle driver
- Relaxation of implicit I/O memory barriers
- Build with RELR relocations when toolchain supports them
- Numerous cleanups and non-critical fixes
----------------------------------------------------------------
Andrew Murray (5):
jump_label: Don't warn on __exit jump entries
arm64: Use correct ll/sc atomic constraints
arm64: atomics: avoid out-of-line ll/sc atomics
arm64: avoid using hard-coded registers for LSE atomics
arm64: atomics: Remove atomic_ll_sc compilation unit
Andrey Konovalov (3):
arm64: untag user pointers in access_ok and __uaccess_mask_ptr
selftests, arm64: add a selftest for passing tagged pointers to kernel
selftests, arm64: fix uninitialized symbol in tags_test.c
Atish Patra (4):
dt-binding: cpu-topology: Move cpu-map to a common binding.
cpu-topology: Move cpu topology code to common code.
arm: Use common cpu_topology structure and functions.
RISC-V: Parse cpu topology during boot.
Bhupesh Sharma (1):
arm64/kexec: Use consistent convention of initializing 'kxec_buf.mem' with KEXEC_BUF_MEM_UNKNOWN
Catalin Marinas (3):
arm64: Introduce prctl() options to control the tagged user addresses ABI
arm64: Tighten the PR_{SET, GET}_TAGGED_ADDR_CTRL prctl() unused arguments
arm64: Change the tagged_addr sysctl control semantics to only prevent the opt-in
Christoph Hellwig (2):
arm64: unexport set_memory_x and set_memory_nx
arm64: remove __iounmap
Chuhong Yuan (1):
arm64: Replace strncmp with str_has_prefix
Geert Uytterhoeven (1):
arm64: Move TIF_* documentation to individual definitions
Hsin-Yi Wang (4):
arm64: map FDT as RW for early_init_dt_scan()
fdt: add support for rng-seed
arm64: kexec_file: add rng-seed support
fdt: Update CRC check for rng-seed
James Morse (1):
arm64: entry: Move ct_user_exit before any other exception
Jeremy Linton (2):
ACPI/PPTT: Add support for ACPI 6.3 thread flag
arm64: topology: Use PPTT to determine if PE is a thread
Joakim Zhang (2):
perf/imx_ddr: Add support for AXI ID filtering
docs/perf: Add documentation for the i.MX8 DDR PMU
Julien Grall (1):
arm64/ptrace: Fix typoes in sve_set() comment
Julien Thierry (1):
arm64: Remove unused assembly macro
Junhua Huang (1):
arm64: mm: free the initrd reserved memblock in a aligned manner
Kees Cook (1):
arm64/efi: Move variable assignments after SECTIONS
Leo Yan (2):
error-injection: Consolidate override function definition
arm64: Add support for function error injection
Leonard Crestez (1):
perf/imx_ddr: Add MODULE_DEVICE_TABLE
Lorenzo Pieralisi (7):
ACPI/IORT: Rename arm_smmu_v3_set_proximity() 'node' local variable
ARM: cpuidle: Remove useless header include
ARM: cpuidle: Remove overzealous error logging
drivers: firmware: psci: Decouple checker from generic ARM CPUidle
ARM: psci: cpuidle: Introduce PSCI CPUidle driver
ARM: psci: cpuidle: Enable PSCI CPUidle driver
PSCI: cpuidle: Refactor CPU suspend power_state parameter handling
Mark Brown (2):
arm64: Remove unused cpucap_multi_entry_cap_cpu_enable()
arm64: Clarify when cpu_enable() is called
Mark Rutland (9):
arm64: remove pointless __KERNEL__ guards
arm64: constify icache_policy_str[]
arm64: constify aarch64_insn_encoding_class[]
arm64: constify sys64_hook instances
arm64: memory: fix flipped VA space fallout
arm64: memory: rename VA_START to PAGE_END
kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE
arm64: fix fixmap copy for 16K pages and 48-bit VA
arm64: kpti: ensure patched kernel text is fetched from PoU
Masahiro Yamada (2):
arm64: remove unneeded uapi/asm/stat.h
arm64: add arch/arm64/Kbuild
Michael Ellerman (1):
powerpc/Makefile: Always pass --synthetic to nm if supported
Miles Chen (1):
arm64: mm: print hexadecimal EC value in mem_abort_decode()
Nick Desaulniers (1):
arm64: prefer __section from compiler_attributes.h
Peter Collingbourne (1):
arm64: Add support for relocating the kernel with RELR relocations
Qian Cai (1):
arm64/prefetch: fix a -Wtype-limits warning
Raphael Gault (1):
arm64: perf_event: Add missing header needed for smp_processor_id()
Robin Murphy (2):
perf/smmuv3: Validate group size
perf/smmuv3: Validate groups for global filtering
Shaokun Zhang (1):
arm64: perf: Remove unused macro
Stephen Boyd (1):
perf: Remove dev_err() usage after platform_get_irq()
Steve Capper (12):
arm64: mm: Remove bit-masking optimisations for PAGE_OFFSET and VMEMMAP_START
arm64: mm: Flip kernel VA space
arm64: kasan: Switch to using KASAN_SHADOW_OFFSET
arm64: dump: De-constify VA_START and KASAN_SHADOW_START
arm64: mm: Introduce VA_BITS_MIN
arm64: mm: Introduce vabits_actual
arm64: mm: Logic to make offset_ttbr1 conditional
arm64: mm: Separate out vmemmap
arm64: mm: Modify calculation of VMEMMAP_SIZE
arm64: mm: Introduce 52-bit Kernel VAs
arm64: mm: Remove vabits_user
docs: arm64: Add layout and 52-bit info to memory document
Sudeep Holla (4):
Documentation: DT: arm: add support for sockets defining package boundaries
base: arch_topology: update Kconfig help description
MAINTAINERS: Add an entry for generic architecture topology
arm64: smp: disable hotplug on trusted OS resident CPU
Vincenzo Frascino (3):
arm64: Define Documentation/arm64/tagged-address-abi.rst
arm64: Add tagged-address-abi.rst to index.rst
arm64: Relax Documentation/arm64/tagged-pointers.rst
Will Deacon (32):
arm64: esr: Add ESR exception class encoding for trapped ERET
arm64: sysreg: Remove unused and rotting SCTLR_ELx field definitions
arm64: io: Relax implicit barriers in default I/O accessors
init/Kconfig: Fix infinite Kconfig recursion on PPC
arm64: mm: Simplify definition of virt_addr_valid()
arm64: mm: Really fix sparse warning in untagged_addr()
Merge tag 'common/for-v5.4-rc1/cpu-topology' of git://git.kernel.org/.../riscv/linux into for-next/cpu-topology
arm64: memory: Fix virt_addr_valid() using __is_lm_address()
arm64: memory: Ensure address tag is masked in conversion macros
arm64: memory: Rewrite default page_to_virt()/virt_to_page()
arm64: memory: Simplify virt_to_page() implementation
arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitions
arm64: memory: Implement __tag_set() as common function
arm64: memory: Add comments to end of non-trivial #ifdef blocks
arm64: memory: Cosmetic cleanups
Revert "init/Kconfig: Fix infinite Kconfig recursion on PPC"
arm64: smp: Increase secondary CPU boot timeout value
arm64: smp: Don't enter kernel with NULL stack pointer or task struct
arm64: smp: Treat unknown boot failures as being 'stuck in kernel'
Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}"
arm64: tlb: Ensure we execute an ISB following walk cache invalidation
arm64: mm: Add ISB instruction to set_pgd()
arm64: sysreg: Add some field definitions for PAR_EL1
arm64: mm: Ignore spurious translation faults taken from the kernel
arm64: kvm: Replace hardcoded '1' with SYS_PAR_EL1_F
arm64: lse: Remove unused 'alt_lse' assembly macro
arm64: asm: Kill 'asm/atomic_arch.h'
arm64: lse: Make ARM64_LSE_ATOMICS depend on JUMP_LABEL
arm64: atomics: Undefine internal macros after use
arm64: atomics: Use K constraint when toolchain appears to support it
Merge branches 'for-next/52-bit-kva', 'for-next/cpu-topology', 'for-next/error-injection', 'for-next/perf', 'for-next/psci-cpuidle', 'for-next/rng', 'for-next/smpboot', 'for-next/tbi' and 'for-next/tlbi' into for-next/core
Merge branch 'for-next/atomics' into for-next/core
Documentation/admin-guide/perf/imx-ddr.rst | 52 +++
Documentation/arm64/index.rst | 1 +
Documentation/arm64/kasan-offsets.sh | 27 ++
Documentation/arm64/memory.rst | 123 +++++--
Documentation/arm64/tagged-address-abi.rst | 156 ++++++++
Documentation/arm64/tagged-pointers.rst | 21 +-
.../{arm/topology.txt => cpu/cpu-topology.txt} | 256 ++++++++-----
MAINTAINERS | 16 +
Makefile | 4 +
arch/Kconfig | 14 +
arch/arm/include/asm/topology.h | 20 --
arch/arm/kernel/topology.c | 60 +---
arch/arm64/Kbuild | 6 +
arch/arm64/Kconfig | 43 ++-
arch/arm64/Makefile | 23 +-
arch/arm64/include/asm/assembler.h | 28 +-
arch/arm64/include/asm/atomic.h | 99 +++++-
arch/arm64/include/asm/atomic_ll_sc.h | 217 ++++++-----
arch/arm64/include/asm/atomic_lse.h | 395 +++++++--------------
arch/arm64/include/asm/cache.h | 2 +-
arch/arm64/include/asm/cmpxchg.h | 45 ++-
arch/arm64/include/asm/compat.h | 2 -
arch/arm64/include/asm/cpu_ops.h | 3 +
arch/arm64/include/asm/cpufeature.h | 28 +-
arch/arm64/include/asm/cputype.h | 21 +-
arch/arm64/include/asm/debug-monitors.h | 3 -
arch/arm64/include/asm/dma-mapping.h | 3 -
arch/arm64/include/asm/efi.h | 4 +-
arch/arm64/include/asm/esr.h | 3 +-
arch/arm64/include/asm/exception.h | 2 +
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/futex.h | 3 -
arch/arm64/include/asm/hw_breakpoint.h | 3 -
arch/arm64/include/asm/io.h | 10 +-
arch/arm64/include/asm/irqflags.h | 5 +-
arch/arm64/include/asm/kasan.h | 11 +-
arch/arm64/include/asm/lse.h | 49 ++-
arch/arm64/include/asm/memory.h | 141 ++++----
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/include/asm/mmu_context.h | 4 +-
arch/arm64/include/asm/pci.h | 2 -
arch/arm64/include/asm/pgtable-hwdef.h | 2 +-
arch/arm64/include/asm/pgtable.h | 23 +-
arch/arm64/include/asm/pointer_auth.h | 2 +-
arch/arm64/include/asm/proc-fns.h | 2 -
arch/arm64/include/asm/processor.h | 15 +-
arch/arm64/include/asm/ptrace.h | 5 +
arch/arm64/include/asm/signal32.h | 2 -
arch/arm64/include/asm/sysreg.h | 32 +-
arch/arm64/include/asm/thread_info.h | 29 +-
arch/arm64/include/asm/tlbflush.h | 1 +
arch/arm64/include/asm/topology.h | 23 --
arch/arm64/include/asm/uaccess.h | 12 +-
arch/arm64/include/asm/vdso.h | 4 -
arch/arm64/include/asm/vdso_datapage.h | 4 -
arch/arm64/include/uapi/asm/stat.h | 17 -
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/kernel/cpuidle.c | 50 ++-
arch/arm64/kernel/cpuinfo.c | 2 +-
arch/arm64/kernel/entry.S | 36 +-
arch/arm64/kernel/head.S | 116 +++++-
arch/arm64/kernel/hibernate-asm.S | 8 +-
arch/arm64/kernel/hibernate.c | 2 +-
arch/arm64/kernel/image-vars.h | 51 +++
arch/arm64/kernel/image.h | 42 ---
arch/arm64/kernel/insn.c | 2 +-
arch/arm64/kernel/kaslr.c | 11 +-
arch/arm64/kernel/kexec_image.c | 2 +-
arch/arm64/kernel/machine_kexec_file.c | 22 +-
arch/arm64/kernel/module-plts.c | 2 +-
arch/arm64/kernel/perf_event.c | 2 +-
arch/arm64/kernel/process.c | 76 ++++
arch/arm64/kernel/psci.c | 10 +-
arch/arm64/kernel/ptrace.c | 2 +-
arch/arm64/kernel/setup.c | 20 +-
arch/arm64/kernel/smp.c | 4 +-
arch/arm64/kernel/smp_spin_table.c | 2 +-
arch/arm64/kernel/topology.c | 312 +---------------
arch/arm64/kernel/traps.c | 20 +-
arch/arm64/kernel/vmlinux.lds.S | 11 +
arch/arm64/kvm/hyp/switch.c | 2 +-
arch/arm64/kvm/va_layout.c | 14 +-
arch/arm64/lib/Makefile | 21 +-
arch/arm64/lib/atomic_ll_sc.c | 3 -
arch/arm64/lib/error-inject.c | 18 +
arch/arm64/mm/dump.c | 24 +-
arch/arm64/mm/fault.c | 44 ++-
arch/arm64/mm/init.c | 35 +-
arch/arm64/mm/ioremap.c | 4 +-
arch/arm64/mm/kasan_init.c | 9 +-
arch/arm64/mm/mmu.c | 32 +-
arch/arm64/mm/numa.c | 2 +-
arch/arm64/mm/pageattr.c | 2 -
arch/arm64/mm/proc.S | 20 +-
arch/powerpc/Makefile | 2 -
arch/powerpc/include/asm/error-injection.h | 13 -
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/smpboot.c | 3 +
arch/x86/include/asm/error-injection.h | 13 -
drivers/acpi/arm64/iort.c | 6 +-
drivers/acpi/pptt.c | 53 ++-
drivers/base/Kconfig | 2 +-
drivers/base/arch_topology.c | 298 ++++++++++++++++
drivers/char/Kconfig | 9 +
drivers/char/random.c | 14 +
drivers/cpuidle/Kconfig.arm | 10 +
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-arm.c | 13 +-
drivers/cpuidle/cpuidle-psci.c | 236 ++++++++++++
drivers/firmware/psci/psci.c | 167 +--------
drivers/firmware/psci/psci_checker.c | 16 +-
drivers/of/fdt.c | 14 +
drivers/perf/arm_smmuv3_pmu.c | 65 +++-
drivers/perf/fsl_imx8_ddr_perf.c | 75 +++-
drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 4 +-
drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 4 +-
drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 4 +-
drivers/perf/qcom_l2_pmu.c | 6 +-
drivers/perf/xgene_pmu.c | 4 +-
include/asm-generic/error-injection.h | 6 +
include/linux/acpi.h | 5 +
include/linux/arch_topology.h | 26 ++
include/linux/cpuidle.h | 17 +-
include/linux/error-injection.h | 6 +-
include/linux/psci.h | 4 +-
include/linux/random.h | 1 +
include/linux/topology.h | 1 +
include/uapi/linux/prctl.h | 5 +
init/Kconfig | 3 +
kernel/jump_label.c | 4 +-
kernel/sys.c | 16 +
scripts/Makefile.kasan | 11 +-
scripts/tools-support-relr.sh | 16 +
tools/testing/selftests/arm64/.gitignore | 1 +
tools/testing/selftests/arm64/Makefile | 11 +
tools/testing/selftests/arm64/run_tags_test.sh | 12 +
tools/testing/selftests/arm64/tags_test.c | 31 ++
137 files changed, 2687 insertions(+), 1641 deletions(-)
create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
create mode 100644 Documentation/arm64/kasan-offsets.sh
create mode 100644 Documentation/arm64/tagged-address-abi.rst
rename Documentation/devicetree/bindings/{arm/topology.txt => cpu/cpu-topology.txt} (66%)
create mode 100644 arch/arm64/Kbuild
delete mode 100644 arch/arm64/include/uapi/asm/stat.h
create mode 100644 arch/arm64/kernel/image-vars.h
delete mode 100644 arch/arm64/lib/atomic_ll_sc.c
create mode 100644 arch/arm64/lib/error-inject.c
delete mode 100644 arch/powerpc/include/asm/error-injection.h
delete mode 100644 arch/x86/include/asm/error-injection.h
create mode 100644 drivers/cpuidle/cpuidle-psci.c
create mode 100755 scripts/tools-support-relr.sh
create mode 100644 tools/testing/selftests/arm64/.gitignore
create mode 100644 tools/testing/selftests/arm64/Makefile
create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
create mode 100644 tools/testing/selftests/arm64/tags_test.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: SCMI & Devfreq
From: Sudeep Holla @ 2019-09-13 10:23 UTC (permalink / raw)
To: Sujeet Kumar Baranwal; +Cc: linux-arm-kernel, Sudeep Holla
In-Reply-To: <BYAPR18MB24387C9DDE32067F1763B6DEAFB00@BYAPR18MB2438.namprd18.prod.outlook.com>
On Thu, Sep 12, 2019 at 06:55:36PM +0000, Sujeet Kumar Baranwal wrote:
> Hi,
>
> I am a recent adopter of SCMI protocol on marvell processors and has been
> able to use cpufreq governor using scmi-cpufreq frame work to change CPU
> frequency.
>
Good, but just a quick question to check if this is ACPI or DT based
platform ? That matter a lot to answer you query.
> While SCMI_PERFORMANCE_PROTOCL allows multiple "domains" to be created, each
> domain representing one clock with several OPPs, it works well.
OK
> For sysfs command like "cat > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor".
I don't understand the context of above statement.
> I am trying to find how SCMI could help in similar facilities when it comes
> to devfreq for device specific OPP variation.
Yes it needs some work and I do have some prototype, but with no users
in the upstream, I haven't added it yet.
> If someone did similar work done or doing, please enlighten me too.
>
What kind of devices are these ? There was some work around generic
devfreq driver that I had seen on the list and my plan was to do something
similar, I need to dig up details as it was while ago.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 3/3] coresight: etm4x: save/restore state for external agents
From: Andrew Murray @ 2019-09-13 10:32 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Al.Grant, mathieu.poirier, alexander.shishkin, coresight, leo.yan,
Sudeep.Holla, linux-arm-kernel, mike.leach
In-Reply-To: <4b34efe9-7266-30b6-6a8a-8a85bacfe5a3@arm.com>
On Thu, Sep 12, 2019 at 04:35:20PM +0100, Suzuki K Poulose wrote:
> Hi Andrew
>
> On 16/08/2019 16:46, Andrew Murray wrote:
> > Some hardware will ignore bit TRCPDCR.PU which is used to signal
> > to hardware that power should not be removed from the trace unit. Much like
> > self-hosted debug, we should also save/restore the trace unit state when
> > it is in use by external agents.
> >
> > We wish to avoid saving the hardware state when coresight isn't in use
> > to reduce PM latency - However as external trace/debug is designed to be
> > unintrusive to the CPU, the only way of determining that an external agent is
> > present is to read the claim tags (TRCCLAIMCLR). Unfortunately this register
> > needs power and clocking - something it won't have when coresight isn't in use.
> > We also don't want to temporarily enable it due to the latency and PM context.
> >
> > Let's compromise by adding a module parameter that will keep the trace unit
> > powered and clocked, thus allowing us to only save/restore state when external
> > trace (or self-hosted) is in use. Though please note that this doesn't allow
> > for tracing from boot on hardware that needs save/restore as the CPU may idle
> > prior to the ETMv4 driver starting and adding PM hooks to save/restore.
> >
>
> This looks fine to me. Some minor comments below.
>
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > ---
> > drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++++++++++++++++---
> > drivers/hwtracing/coresight/coresight.c | 2 +-
> > include/linux/coresight.h | 7 +++++
> > 3 files changed, 31 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > index 35a524eec36d..c5d527f7cbd5 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > @@ -42,11 +42,12 @@ MODULE_PARM_DESC(boot_enable, "Enable tracing on boot");
> > #define PARAM_PM_SAVE_FIRMWARE 0 /* save self-hosted state as per firmware */
> > #define PARAM_PM_SAVE_NEVER 1 /* never save any state */
> > #define PARAM_PM_SAVE_SELF_HOSTED 2 /* save self-hosted state only */
> > +#define PARAM_PM_SAVE_EXTERNAL 3 /* save all state (keeps power on) */
>
> Should we say PARAM_PM_SAVE_ALWAYS instead ?
>
Yes I think this is OK.
> > static int pm_save_enable = PARAM_PM_SAVE_FIRMWARE;
> > module_param(pm_save_enable, int, 0444);
> > MODULE_PARM_DESC(pm_save_enable,
> > - "Save/restore state on power down: 1 = never, 2 = self-hosted");
> > + "Save/restore state on power down: 1 = never, 2 = self-hosted, 3 = self-hosted/external");
>
> similarly here and also mention that the power/clocks are not dropped in that
> case ? I see the comment above, but please could we make it more explicit ?
I'll change it to ... 3 = self-hosted/external (keeps power on)");
>
> > /* The number of ETMv4 currently registered */
> > static int etm4_count;
> > @@ -1331,6 +1332,22 @@ static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
> > CS_LOCK(drvdata->base);
> > }
> > +static bool etm4_coresight_in_use(struct etmv4_drvdata *drvdata)
> > +{
> > + /* Self-hosted session in progress? */
> > + if (local_read(&drvdata->mode))
> > + return true;
> > +
> > + /* External agents can be detected through claim tags however we
> > + * only read these tags if the trace unit is powered.
> > + */
> > + if (drvdata->csdev && pm_runtime_active(drvdata->csdev->dev.parent))
> > + if (coresight_is_claimed_any(drvdata->base))
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
> > void *v)
> > {
> > @@ -1350,8 +1367,8 @@ static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
> > switch (cmd) {
> > case CPU_PM_ENTER:
> > - /* save the state if self-hosted coresight is in use */
> > - if (local_read(&drvdata->mode))
> > + /* Save the state if coresight is in use */
> > + if (etm4_coresight_in_use(drvdata))
> > if (etm4_cpu_save(drvdata))
> > return NOTIFY_BAD;
> > break;
> > @@ -1488,7 +1505,9 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
> > goto err_arch_supported;
> > }
> > - pm_runtime_put(&adev->dev);
> > + if (pm_save_enable != PARAM_PM_SAVE_EXTERNAL)
> > + pm_runtime_put(&adev->dev);
> > +
>
> It may be a good idea to explain why we don't drop the power here
> in a comment to help people reading the code. You could paste what
> is in the commit description in here to avoid another lookup.
Good idea. I'll modify it slightly however.
>
> > dev_info(&drvdata->csdev->dev, "CPU%d: ETM v%d.%d initialized\n",
> > drvdata->cpu, drvdata->arch >> 4, drvdata->arch & 0xf);
> > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> > index e6ca899fea4e..474b7372864e 100644
> > --- a/drivers/hwtracing/coresight/coresight.c
> > +++ b/drivers/hwtracing/coresight/coresight.c
> > @@ -140,7 +140,7 @@ static inline bool coresight_is_claimed_self_hosted(void __iomem *base)
> > return coresight_read_claim_tags(base) == CORESIGHT_CLAIM_SELF_HOSTED;
> > }
> > -static inline bool coresight_is_claimed_any(void __iomem *base)
> > +bool coresight_is_claimed_any(void __iomem *base)
> > {
> > return coresight_read_claim_tags(base) != 0;
> > }
>
> minor nit: We may retain this as static inline and move this to the header file.
OK.
Thanks,
Andrew Murray
>
> Kind regards
> Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
From: Matthias Brugger @ 2019-09-13 10:39 UTC (permalink / raw)
To: Stefan Wahren, Matthias Brugger, catalin.marinas, marc.zyngier,
robh+dt, linux-mm, linux-arm-kernel, linux-riscv, hch,
Nicolas Saenz Julienne
Cc: f.fainelli, robin.murphy, phil, linux-kernel, linux-rpi-kernel,
will, m.szyprowski
In-Reply-To: <3163f80b-72e5-5da8-0909-a8950d3669f7@gmx.net>
On 13/09/2019 12:08, Stefan Wahren wrote:
> Am 13.09.19 um 11:25 schrieb Matthias Brugger:
>>
>> On 13/09/2019 10:50, Stefan Wahren wrote:
>>> Am 13.09.19 um 10:09 schrieb Matthias Brugger:
>>>> On 12/09/2019 21:32, Stefan Wahren wrote:
>>>>> Am 12.09.19 um 19:18 schrieb Matthias Brugger:
>>>>>> On 10/09/2019 11:27, Matthias Brugger wrote:
>>>>>>> On 09/09/2019 21:33, Stefan Wahren wrote:
>>>>>>>> Hi Nicolas,
>>>>>>>>
>>>>>>>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
>>>>>>>>> Hi all,
>>>>>>>>> this series attempts to address some issues we found while bringing up
>>>>>>>>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
>>>>>>>>> up of these discussions:
>>>>>>>>> v4: https://lkml.org/lkml/2019/9/6/352
>>>>>>>>> v3: https://lkml.org/lkml/2019/9/2/589
>>>>>>>>> v2: https://lkml.org/lkml/2019/8/20/767
>>>>>>>>> v1: https://lkml.org/lkml/2019/7/31/922
>>>>>>>>> RFC: https://lkml.org/lkml/2019/7/17/476
>>>>>>>>>
>>>>>>>>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
>>>>>>>>> only address the first GB: their DMA address range is
>>>>>>>>> 0xc0000000-0xfc000000 which is aliased to the first GB of physical
>>>>>>>>> memory 0x00000000-0x3c000000. Note that only some peripherals have these
>>>>>>>>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
>>>>>>>>> view of the address space by virtue of being hooked up trough a second
>>>>>>>>> interconnect.
>>>>>>>>>
>>>>>>>>> Part of this is solved on arm32 by setting up the machine specific
>>>>>>>>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent
>>>>>>>>> memory area at the right spot. That said no buffer bouncing (needed for
>>>>>>>>> dma streaming) is available at the moment, but that's a story for
>>>>>>>>> another series.
>>>>>>>>>
>>>>>>>>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
>>>>>>>>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
>>>>>>>>> arch code as if all peripherals where be able to address the first 4GB
>>>>>>>>> of memory.
>>>>>>>>>
>>>>>>>>> In the light of this, the series implements the following changes:
>>>>>>>>>
>>>>>>>>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G
>>>>>>>>> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far
>>>>>>>>> the RPi4 is the only arm64 device with such DMA addressing limitations
>>>>>>>>> so this hardcoded solution was deemed preferable.
>>>>>>>>>
>>>>>>>>> - Properly set ARCH_ZONE_DMA_BITS.
>>>>>>>>>
>>>>>>>>> - Reserve the CMA area in a place suitable for all peripherals.
>>>>>>>>>
>>>>>>>>> This series has been tested on multiple devices both by checking the
>>>>>>>>> zones setup matches the expectations and by double-checking physical
>>>>>>>>> addresses on pages allocated on the three relevant areas GFP_DMA,
>>>>>>>>> GFP_DMA32, GFP_KERNEL:
>>>>>>>>>
>>>>>>>>> - On an RPi4 with variations on the ram memory size. But also forcing
>>>>>>>>> the situation where all three memory zones are nonempty by setting a 3G
>>>>>>>>> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
>>>>>>>>>
>>>>>>>> i like to test this series on Raspberry Pi 4 and i have some questions
>>>>>>>> to get arm64 running:
>>>>>>>>
>>>>>>>> Do you use U-Boot? Which tree?
>>>>>>> If you want to use U-Boot, try v2019.10-rc4, it should have everything you need
>>>>>>> to boot your kernel.
>>>>>>>
>>>>>> Ok, here is a thing. In the linux kernel we now use bcm2711 as SoC name, but the
>>>>>> RPi4 devicetree provided by the FW uses mostly bcm2838.
>>>>> Do you mean the DTB provided at runtime?
>>>>>
>>>>> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi
>>>>> series?
>>>>>
>>>>>> U-Boot in its default
>>>>>> config uses the devicetree provided by the FW, mostly because this way you don't
>>>>>> have to do anything to find out how many RAM you really have. Secondly because
>>>>>> this will allow us, in the near future, to have one U-boot binary for both RPi3
>>>>>> and RPi4 (and as a side effect one binary for RPi1 and RPi2).
>>>>>>
>>>>>> Anyway, I found at least, that the following compatibles need to be added:
>>>>>>
>>>>>> "brcm,bcm2838-cprman"
>>>>>> "brcm,bcm2838-gpio"
>>>>>>
>>>>>> Without at least the cprman driver update, you won't see anything.
>>>>>>
>>>>>> "brcm,bcm2838-rng200" is also a candidate.
>>>>>>
>>>>>> I also suppose we will need to add "brcm,bcm2838" to
>>>>>> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this.
>>>>> How about changing this in the downstream kernel? Which is much easier.
>>>> I'm not sure I understand what you want to say. My goal is to use the upstream
>>>> kernel with the device tree blob provided by the FW.
>>> The device tree blob you are talking is defined in this repository:
>>>
>>> https://github.com/raspberrypi/linux
>>>
>>> So the word FW is misleading to me.
>>>
>> No, it's part of
>> https://github.com/raspberrypi/firmware.git
>> file boot/bcm2711-rpi-4-b.dtb
> The compiled DT blobs incl. the kernel image are stored in this artifact
> repository. But the sources for the kernel and the DT are in the Linux
> repo. This is necessary to be compliant to the GPL.
Got it, thanks for clarifying.
>>
>>>> If you talk about the
>>>> downstream kernel, I suppose you mean we should change this in the FW DT blob
>>>> and in the downstream kernel. That would work for me.
>>>>
>>>> Did I understand you correctly?
>>> Yes
>>>
>>> So i suggest to add the upstream compatibles into the repo mentioned above.
>>>
>>> Sorry, but in case you decided as a U-Boot developer to be compatible
>>> with a unreviewed DT, we also need to make U-Boot compatible with
>>> upstream and downstream DT blobs.
>>>
>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier
>> if we can use this DTB we can work towards one binary that can boot both RPi3
>> and RPi4. On the other hand we can rely on the FW to detect the amount of memory
>> our RPi4 has.
>>
>> That said, I agree that we should make sure that U-Boot can boot with both DTBs,
>> the upstream one and the downstream. Now the question is how to get to this. I'm
>> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711
>> compatible is already reviewed and can't be changed. From what I can see none of
>> these compatibles got merged for now, so we are still at time to change them.
>
> Stephen Boyd was okay with clk changes except of a small nit. So i fixed
> this is as he suggested in a separate series. Unfortunately this hasn't
> be applied yet [1].
>
> The i2c, pinctrl and the sdhci changes has been applied yet.
>
> In my opinion it isn't the job of the mainline kernel to adapt to a
> vendor device tree. It's the vendor device tree which needs to be fixed.
>
I agree with that. But if we can make this easier by choosing a compatible which
fits downstream without violating upstream and it makes sense with the naming
scheme of the RPi, I think that's a good argument.
> Sorry, but this is my holiday. I will back after the weekend.
>
Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up
with emails.
Regards,
Matthias
> Best regards
> Stefan
>
> [1] - https://www.spinics.net/lists/linux-clk/msg40534.html
>
>>
>> Apart from the point Florian made, to stay consistent with the RPi SoC naming,
>> it will save us work, both in the kernel and in U-Boot, as we would need to add
>> both compatibles to the code-base.
>>
>> Regards,
>> Matthias
>>
>>>>>> Regards,
>>>>>> Matthias
>>>>>>
>>>>>>> Regards,
>>>>>>> Matthias
>>>>>>>
>>>>>>>> Are there any config.txt tweaks necessary?
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> linux-arm-kernel mailing list
>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>>>
>>>>>> _______________________________________________
>>>>>> linux-arm-kernel mailing list
>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/6] dt-bindings: thermal: Add DT bindings documentation for Amlogic Thermal
From: Amit Kucheria @ 2019-09-13 10:41 UTC (permalink / raw)
To: Guillaume La Roque
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux PM list, Daniel Lezcano, LKML, Eduardo Valentin,
linux-amlogic, Zhang Rui, lakml
In-Reply-To: <20190821222421.30242-2-glaroque@baylibre.com>
On Thu, Aug 22, 2019 at 3:54 AM Guillaume La Roque
<glaroque@baylibre.com> wrote:
>
> Adding the devicetree binding documentation for the Amlogic temperature
> sensor found in the Amlogic Meson G12 SoCs.
> the G12A and G12B SoCs are supported.
Merge the two sentences into a single one?
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/thermal/amlogic,thermal.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>
> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> new file mode 100644
> index 000000000000..f761681e4c0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/thermal/amlogic,thermal.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Amlogic Thermal
> +
> +maintainers:
> + - Guillaume La Roque <glaroque@baylibre.com>
> +
> +description: Binding for Amlogic Thermal
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - amlogic,g12a-cpu-thermal
> + - amlogic,g12a-ddr-thermal
> + - const: amlogic,g12a-thermal
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + amlogic,ao-secure:
> + description: phandle to the ao-secure syscon
> + $ref: '/schemas/types.yaml#/definitions/phandle'
> +
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - amlogic,ao-secure
> +
> +examples:
> + - |
> + cpu_temp: temperature-sensor@ff634800 {
> + compatible = "amlogic,g12a-cpu-thermal",
> + "amlogic,g12a-thermal";
> + reg = <0xff634800 0x50>;
> + interrupts = <0x0 0x24 0x0>;
> + clocks = <&clk 164>;
> + #thermal-sensor-cells = <0>;
> + amlogic,ao-secure = <&sec_AO>;
> + };
> +...
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix function types in COND_SYSCALL
From: Mark Rutland @ 2019-09-13 11:33 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, Catalin Marinas, Kees Cook, Sami Tolvanen,
linux-kernel
In-Reply-To: <20190912131143.u3rncvqdgx4z3ckz@willie-the-truck>
On Thu, Sep 12, 2019 at 02:11:44PM +0100, Will Deacon wrote:
> On Wed, Sep 11, 2019 at 04:15:46PM +0100, Mark Rutland wrote:
> > On Tue, Sep 10, 2019 at 03:40:44PM -0700, Sami Tolvanen wrote:
> > > Define a weak function in COND_SYSCALL instead of a weak alias to
> > > sys_ni_syscall, which has an incompatible type. This fixes indirect
> > > call mismatches with Control-Flow Integrity (CFI) checking.
> > >
> > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> >
> > This looks correct to me, builds fine, and I asume has been tested, so FWIW:
> >
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> >
> > In looking at this, I came to the conclusion that we can drop the ifdeffery
> > around our SYSCALL_DEFINE0(), COND_SYSCALL(), and SYS_NI(), which I evidently
> > cargo-culted from x86 (where the ifdeffery is actually necessary).
>
> Curious: why is it required on x86?
Due to the way they share some native calls with (IA32) compat, but need
slightly different wrappers to marshall registers, they have ifdeffery
like:
#ifdef CONFIG_IA32_EMULATION
#define COND_SYSCALL(name) \
cond_syscall(__x64_sys_##name); \
cond_syscall(__ia32_sys_##name)
#endif
#ifndef COND_SYSCALL
#define COND_SYSCALL(name) cond_syscall(__x64_sys_##name)
#endif
... so that they define the compat wrapper when necessary, but not otherwise.
As we don't share the native syscall table with compat tasks, we don't
need to do anything like that, and can unconditionally define the native
case once.
> > I can send a follow up for that.
>
> Yes, please.
I'll cook that up now, atop of Sami's patch applied to arm64's
for-next/core.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Report USF more clearly
From: Robin Murphy @ 2019-09-13 11:48 UTC (permalink / raw)
To: will, joro; +Cc: iommu, Douglas Anderson, linux-arm-kernel
Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool
for smoking out inadequate firmware, the failure mode is non-obvious
and can be confusing for end users. Add some special-case reporting of
Unidentified Stream Faults to help clarify this particular symptom.
CC: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 5 +++++
drivers/iommu/arm-smmu.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index b7cf24402a94..76ac8c180695 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -499,6 +499,11 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
dev_err_ratelimited(smmu->dev,
"\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
gfsr, gfsynr0, gfsynr1, gfsynr2);
+ if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
+ (gfsr & sGFSR_USF))
+ dev_err_ratelimited(smmu->dev,
+ "Stream ID %hu may not be described by firmware, try booting with \"arm-smmu.disable_bypass=0\"\n",
+ (u16)gfsynr1);
arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_sGFSR, gfsr);
return IRQ_HANDLED;
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index c9c13b5785f2..46f7e161e83e 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -79,6 +79,8 @@
#define ID7_MINOR GENMASK(3, 0)
#define ARM_SMMU_GR0_sGFSR 0x48
+#define sGFSR_USF BIT(2)
+
#define ARM_SMMU_GR0_sGFSYNR0 0x50
#define ARM_SMMU_GR0_sGFSYNR1 0x54
#define ARM_SMMU_GR0_sGFSYNR2 0x58
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 0/3] coresight: etm4x: save/restore ETMv4 context across CPU low power states
From: Andrew Murray @ 2019-09-13 11:53 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Rob Herring, Mark Rutland
Cc: devicetree, Al.Grant, coresight, Leo Yan, Sudeep Holla,
linux-arm-kernel, Mike Leach
Some hardware will ignore bit TRCPDCR.PU which is used to signal
to hardware that power should not be removed from the trace unit.
Let's mitigate against this by conditionally saving and restoring
the trace unit state when the CPU enters low power states.
This patchset introduces a firmware property named
'arm,coresight-loses-context-with-cpu' - when this is present the
hardware state will be conditionally saved and restored.
A module parameter 'pm_save_enable' is also introduced which can
be configured to override the firmware property. This parameter
also provides a means to save/restore state when external agents
are used.
The hardware state is only ever saved and restored when a coresight
session is present.
Changes since v5:
- Fix indentation, comment style and add implicit fallthrough comment
- Use NOTIFY_* for all return values in pm notifier callback
- Rename PARAM_PM_SAVE_EXTERNAL to PARAM_PM_SAVE_ALWAYS
- Update module parameter description
- Add comment to explain why we keep power on
- Rebased onto coresight/next c165d8947bc4 ("eeprom: Deprecate the legacy eeprom driver")
Changes since v4:
- Rename fwnode property to "arm,coresight-loses-context-with-cpu" as this
doesn't imply a software policy
- Update the device tree binding document to indicate that this property
isn't specific to ETMs - also provide a longer description more generic
description with an example of why it might be used
- Set the module parameter at probe based on the value determined by firmware.
The user can still override the firmware via the kernel command line, this
has the effect of hiding the PARAM_PM_SAVE_FIRMWARE option from the user -
though we still internally use it to allow us to determine if the user has
set the parameter.
- Remove unnecessary call to smp_processor_id
- Move etm4_needs_save_restore helper to coresight.c and rename
- Rebased onto coresight/next a04d8683f577 ("...ity of etm4_os_unlock comment")
- Drop Reviewed-By from Suzuki on "coresight: etm4x: save/restore st..." patch
as content changed too much
- Add module option to that keeps clocks/power enabled at probe and saves
state when external or self-hosted is in use.
Changes since v3:
- Only save/restore when self-hosted is being used and detect this
without relying on the coresight registers (which may not be
available)
- Only allocate memory for etmv4_save_state at probe time when
configuration indicates it may be used
- Set pm_save_enable param to 0444 such that it is static after
boot
- Save/restore TRCPDCR
- Add missing comments to struct etm4_drvdata documentation
- Rebased onto coresight/next (8f1f9857)
Changes since v2:
- Move the PM notifier block from drvdata to file static
- Add section names to document references
- Add additional information to commit messages
- Remove trcdvcvr and trcdvcmr from saved state and add a comment to
describe why
- Ensure TRCPDCR_PU is set after restore and add a comment to explain
why we bother toggling TRCPDCR_PU on save/restore
- Reword the pm_save_enable options and add comments
- Miscellaneous style changes
- Move device tree binding documentation to its own patch
Changes since v1:
- Rebased onto coresight/next
- Correcly pass bit number rather than BIT macro to coresight_timeout
- Abort saving state if a timeout occurs
- Fix completely broken pm_notify handling and unregister handler on error
- Use state_needs_restore to ensure state is restored only once
- Add module parameter description to existing boot_enable parameter
and use module_param instead of module_param_named
- Add firmware bindings for coresight-needs-save-restore
- Rename 'disable_pm_save' to 'pm_save_enable' which allows for
disabled, enabled or firmware
- Update comment on etm4_os_lock, it incorrectly indicated that
the code unlocks the trace registers
- Add comments to explain use of OS lock during save/restore
- Fix incorrect error description whilst waiting for PM stable
- Add WARN_ON_ONCE when cpu isn't as expected during save/restore
- Various updates to commit messages
Andrew Murray (3):
coresight: etm4x: save/restore state across CPU low power states
dt-bindings: arm: coresight: Add support for
coresight-loses-context-with-cpu
coresight: etm4x: save/restore state for external agents
.../devicetree/bindings/arm/coresight.txt | 9 +
drivers/hwtracing/coresight/coresight-etm4x.c | 351 +++++++++++++++++-
drivers/hwtracing/coresight/coresight-etm4x.h | 64 ++++
drivers/hwtracing/coresight/coresight.c | 8 +-
include/linux/coresight.h | 13 +
5 files changed, 443 insertions(+), 2 deletions(-)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/3] coresight: etm4x: save/restore state across CPU low power states
From: Andrew Murray @ 2019-09-13 11:53 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Rob Herring, Mark Rutland
Cc: devicetree, Al.Grant, coresight, Leo Yan, Sudeep Holla,
linux-arm-kernel, Mike Leach
In-Reply-To: <20190913115312.12943-1-andrew.murray@arm.com>
Some hardware will ignore bit TRCPDCR.PU which is used to signal
to hardware that power should not be removed from the trace unit.
Let's mitigate against this by conditionally saving and restoring
the trace unit state when the CPU enters low power states.
This patchset introduces a firmware property named
'arm,coresight-loses-context-with-cpu' - when this is present the
hardware state will be conditionally saved and restored.
A module parameter 'pm_save_enable' is also introduced which can
be configured to override the firmware property. This can be set
to never allow save/restore or to conditionally allow it (only for
self-hosted). The default value is determined by firmware.
We avoid saving the hardware state when self-hosted coresight isn't
in use to reduce PM latency - we can't determine this by reading the
claim tags (TRCCLAIMCLR) as these are 'trace' registers which need
power and clocking, something we can't easily provide in the PM
context. Therefore we rely on the existing drvdata->mode internal
state that is set when self-hosted coresight is used (and powered).
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 318 ++++++++++++++++++
drivers/hwtracing/coresight/coresight-etm4x.h | 64 ++++
drivers/hwtracing/coresight/coresight.c | 6 +
include/linux/coresight.h | 6 +
4 files changed, 394 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index a128b5063f46..4cecabdd051b 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -18,6 +18,7 @@
#include <linux/stat.h>
#include <linux/clk.h>
#include <linux/cpu.h>
+#include <linux/cpu_pm.h>
#include <linux/coresight.h>
#include <linux/coresight-pmu.h>
#include <linux/pm_wakeup.h>
@@ -26,6 +27,7 @@
#include <linux/uaccess.h>
#include <linux/perf_event.h>
#include <linux/pm_runtime.h>
+#include <linux/property.h>
#include <asm/sections.h>
#include <asm/local.h>
#include <asm/virt.h>
@@ -37,6 +39,15 @@ static int boot_enable;
module_param(boot_enable, int, 0444);
MODULE_PARM_DESC(boot_enable, "Enable tracing on boot");
+#define PARAM_PM_SAVE_FIRMWARE 0 /* save self-hosted state as per firmware */
+#define PARAM_PM_SAVE_NEVER 1 /* never save any state */
+#define PARAM_PM_SAVE_SELF_HOSTED 2 /* save self-hosted state only */
+
+static int pm_save_enable = PARAM_PM_SAVE_FIRMWARE;
+module_param(pm_save_enable, int, 0444);
+MODULE_PARM_DESC(pm_save_enable,
+ "Save/restore state on power down: 1 = never, 2 = self-hosted");
+
/* The number of ETMv4 currently registered */
static int etm4_count;
static struct etmv4_drvdata *etmdrvdata[NR_CPUS];
@@ -54,6 +65,14 @@ static void etm4_os_unlock(struct etmv4_drvdata *drvdata)
isb();
}
+static void etm4_os_lock(struct etmv4_drvdata *drvdata)
+{
+ /* Writing 0x1 to TRCOSLAR locks the trace registers */
+ writel_relaxed(0x1, drvdata->base + TRCOSLAR);
+ drvdata->os_unlock = false;
+ isb();
+}
+
static bool etm4_arch_supported(u8 arch)
{
/* Mask out the minor version number */
@@ -1085,6 +1104,288 @@ static void etm4_init_trace_id(struct etmv4_drvdata *drvdata)
drvdata->trcid = coresight_get_trace_id(drvdata->cpu);
}
+#ifdef CONFIG_CPU_PM
+static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
+{
+ int i, ret = 0;
+ struct etmv4_save_state *state;
+ struct device *etm_dev = &drvdata->csdev->dev;
+
+ /*
+ * As recommended by 3.4.1 ("The procedure when powering down the PE")
+ * of ARM IHI 0064D
+ */
+ dsb(sy);
+ isb();
+
+ CS_UNLOCK(drvdata->base);
+
+ /* Lock the OS lock to disable trace and external debugger access */
+ etm4_os_lock(drvdata);
+
+ /* wait for TRCSTATR.PMSTABLE to go up */
+ if (coresight_timeout(drvdata->base, TRCSTATR,
+ TRCSTATR_PMSTABLE_BIT, 1)) {
+ dev_err(etm_dev,
+ "timeout while waiting for PM Stable Status\n");
+ etm4_os_unlock(drvdata);
+ ret = -EBUSY;
+ goto out;
+ }
+
+ state = drvdata->save_state;
+
+ state->trcprgctlr = readl(drvdata->base + TRCPRGCTLR);
+ state->trcprocselr = readl(drvdata->base + TRCPROCSELR);
+ state->trcconfigr = readl(drvdata->base + TRCCONFIGR);
+ state->trcauxctlr = readl(drvdata->base + TRCAUXCTLR);
+ state->trceventctl0r = readl(drvdata->base + TRCEVENTCTL0R);
+ state->trceventctl1r = readl(drvdata->base + TRCEVENTCTL1R);
+ state->trcstallctlr = readl(drvdata->base + TRCSTALLCTLR);
+ state->trctsctlr = readl(drvdata->base + TRCTSCTLR);
+ state->trcsyncpr = readl(drvdata->base + TRCSYNCPR);
+ state->trcccctlr = readl(drvdata->base + TRCCCCTLR);
+ state->trcbbctlr = readl(drvdata->base + TRCBBCTLR);
+ state->trctraceidr = readl(drvdata->base + TRCTRACEIDR);
+ state->trcqctlr = readl(drvdata->base + TRCQCTLR);
+
+ state->trcvictlr = readl(drvdata->base + TRCVICTLR);
+ state->trcviiectlr = readl(drvdata->base + TRCVIIECTLR);
+ state->trcvissctlr = readl(drvdata->base + TRCVISSCTLR);
+ state->trcvipcssctlr = readl(drvdata->base + TRCVIPCSSCTLR);
+ state->trcvdctlr = readl(drvdata->base + TRCVDCTLR);
+ state->trcvdsacctlr = readl(drvdata->base + TRCVDSACCTLR);
+ state->trcvdarcctlr = readl(drvdata->base + TRCVDARCCTLR);
+
+ for (i = 0; i < drvdata->nrseqstate; i++)
+ state->trcseqevr[i] = readl(drvdata->base + TRCSEQEVRn(i));
+
+ state->trcseqrstevr = readl(drvdata->base + TRCSEQRSTEVR);
+ state->trcseqstr = readl(drvdata->base + TRCSEQSTR);
+ state->trcextinselr = readl(drvdata->base + TRCEXTINSELR);
+
+ for (i = 0; i < drvdata->nr_cntr; i++) {
+ state->trccntrldvr[i] = readl(drvdata->base + TRCCNTRLDVRn(i));
+ state->trccntctlr[i] = readl(drvdata->base + TRCCNTCTLRn(i));
+ state->trccntvr[i] = readl(drvdata->base + TRCCNTVRn(i));
+ }
+
+ for (i = 0; i < drvdata->nr_resource * 2; i++)
+ state->trcrsctlr[i] = readl(drvdata->base + TRCRSCTLRn(i));
+
+ for (i = 0; i < drvdata->nr_ss_cmp; i++) {
+ state->trcssccr[i] = readl(drvdata->base + TRCSSCCRn(i));
+ state->trcsscsr[i] = readl(drvdata->base + TRCSSCSRn(i));
+ state->trcsspcicr[i] = readl(drvdata->base + TRCSSPCICRn(i));
+ }
+
+ for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
+ state->trcacvr[i] = readl(drvdata->base + TRCACVRn(i));
+ state->trcacatr[i] = readl(drvdata->base + TRCACATRn(i));
+ }
+
+ /*
+ * Data trace stream is architecturally prohibited for A profile cores
+ * so we don't save (or later restore) trcdvcvr and trcdvcmr - As per
+ * section 1.3.4 ("Possible functional configurations of an ETMv4 trace
+ * unit") of ARM IHI 0064D.
+ */
+
+ for (i = 0; i < drvdata->numcidc; i++)
+ state->trccidcvr[i] = readl(drvdata->base + TRCCIDCVRn(i));
+
+ for (i = 0; i < drvdata->numvmidc; i++)
+ state->trcvmidcvr[i] = readl(drvdata->base + TRCVMIDCVRn(i));
+
+ state->trccidcctlr0 = readl(drvdata->base + TRCCIDCCTLR0);
+ state->trccidcctlr1 = readl(drvdata->base + TRCCIDCCTLR1);
+
+ state->trcvmidcctlr0 = readl(drvdata->base + TRCVMIDCCTLR0);
+ state->trcvmidcctlr0 = readl(drvdata->base + TRCVMIDCCTLR1);
+
+ state->trcclaimset = readl(drvdata->base + TRCCLAIMCLR);
+
+ state->trcpdcr = readl(drvdata->base + TRCPDCR);
+
+ /* wait for TRCSTATR.IDLE to go up */
+ if (coresight_timeout(drvdata->base, TRCSTATR, TRCSTATR_IDLE_BIT, 1)) {
+ dev_err(etm_dev,
+ "timeout while waiting for Idle Trace Status\n");
+ etm4_os_unlock(drvdata);
+ ret = -EBUSY;
+ goto out;
+ }
+
+ drvdata->state_needs_restore = true;
+
+ /*
+ * Power can be removed from the trace unit now. We do this to
+ * potentially save power on systems that respect the TRCPDCR_PU
+ * despite requesting software to save/restore state.
+ */
+ writel_relaxed((state->trcpdcr & ~TRCPDCR_PU),
+ drvdata->base + TRCPDCR);
+
+out:
+ CS_LOCK(drvdata->base);
+ return ret;
+}
+
+static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
+{
+ int i;
+ struct etmv4_save_state *state = drvdata->save_state;
+
+ CS_UNLOCK(drvdata->base);
+
+ writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
+
+ writel_relaxed(state->trcprgctlr, drvdata->base + TRCPRGCTLR);
+ writel_relaxed(state->trcprocselr, drvdata->base + TRCPROCSELR);
+ writel_relaxed(state->trcconfigr, drvdata->base + TRCCONFIGR);
+ writel_relaxed(state->trcauxctlr, drvdata->base + TRCAUXCTLR);
+ writel_relaxed(state->trceventctl0r, drvdata->base + TRCEVENTCTL0R);
+ writel_relaxed(state->trceventctl1r, drvdata->base + TRCEVENTCTL1R);
+ writel_relaxed(state->trcstallctlr, drvdata->base + TRCSTALLCTLR);
+ writel_relaxed(state->trctsctlr, drvdata->base + TRCTSCTLR);
+ writel_relaxed(state->trcsyncpr, drvdata->base + TRCSYNCPR);
+ writel_relaxed(state->trcccctlr, drvdata->base + TRCCCCTLR);
+ writel_relaxed(state->trcbbctlr, drvdata->base + TRCBBCTLR);
+ writel_relaxed(state->trctraceidr, drvdata->base + TRCTRACEIDR);
+ writel_relaxed(state->trcqctlr, drvdata->base + TRCQCTLR);
+
+ writel_relaxed(state->trcvictlr, drvdata->base + TRCVICTLR);
+ writel_relaxed(state->trcviiectlr, drvdata->base + TRCVIIECTLR);
+ writel_relaxed(state->trcvissctlr, drvdata->base + TRCVISSCTLR);
+ writel_relaxed(state->trcvipcssctlr, drvdata->base + TRCVIPCSSCTLR);
+ writel_relaxed(state->trcvdctlr, drvdata->base + TRCVDCTLR);
+ writel_relaxed(state->trcvdsacctlr, drvdata->base + TRCVDSACCTLR);
+ writel_relaxed(state->trcvdarcctlr, drvdata->base + TRCVDARCCTLR);
+
+ for (i = 0; i < drvdata->nrseqstate; i++)
+ writel_relaxed(state->trcseqevr[i],
+ drvdata->base + TRCSEQEVRn(i));
+
+ writel_relaxed(state->trcseqrstevr, drvdata->base + TRCSEQRSTEVR);
+ writel_relaxed(state->trcseqstr, drvdata->base + TRCSEQSTR);
+ writel_relaxed(state->trcextinselr, drvdata->base + TRCEXTINSELR);
+
+ for (i = 0; i < drvdata->nr_cntr; i++) {
+ writel_relaxed(state->trccntrldvr[i],
+ drvdata->base + TRCCNTRLDVRn(i));
+ writel_relaxed(state->trccntctlr[i],
+ drvdata->base + TRCCNTCTLRn(i));
+ writel_relaxed(state->trccntvr[i],
+ drvdata->base + TRCCNTVRn(i));
+ }
+
+ for (i = 0; i < drvdata->nr_resource * 2; i++)
+ writel_relaxed(state->trcrsctlr[i],
+ drvdata->base + TRCRSCTLRn(i));
+
+ for (i = 0; i < drvdata->nr_ss_cmp; i++) {
+ writel_relaxed(state->trcssccr[i],
+ drvdata->base + TRCSSCCRn(i));
+ writel_relaxed(state->trcsscsr[i],
+ drvdata->base + TRCSSCSRn(i));
+ writel_relaxed(state->trcsspcicr[i],
+ drvdata->base + TRCSSPCICRn(i));
+ }
+
+ for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
+ writel_relaxed(state->trcacvr[i],
+ drvdata->base + TRCACVRn(i));
+ writel_relaxed(state->trcacatr[i],
+ drvdata->base + TRCACATRn(i));
+ }
+
+ for (i = 0; i < drvdata->numcidc; i++)
+ writel_relaxed(state->trccidcvr[i],
+ drvdata->base + TRCCIDCVRn(i));
+
+ for (i = 0; i < drvdata->numvmidc; i++)
+ writel_relaxed(state->trcvmidcvr[i],
+ drvdata->base + TRCVMIDCVRn(i));
+
+ writel_relaxed(state->trccidcctlr0, drvdata->base + TRCCIDCCTLR0);
+ writel_relaxed(state->trccidcctlr1, drvdata->base + TRCCIDCCTLR1);
+
+ writel_relaxed(state->trcvmidcctlr0, drvdata->base + TRCVMIDCCTLR0);
+ writel_relaxed(state->trcvmidcctlr0, drvdata->base + TRCVMIDCCTLR1);
+
+ writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
+
+ writel_relaxed(state->trcpdcr, drvdata->base + TRCPDCR);
+
+ drvdata->state_needs_restore = false;
+
+ /*
+ * As recommended by section 4.3.7 ("Synchronization when using the
+ * memory-mapped interface") of ARM IHI 0064D
+ */
+ dsb(sy);
+ isb();
+
+ /* Unlock the OS lock to re-enable trace and external debug access */
+ etm4_os_unlock(drvdata);
+ CS_LOCK(drvdata->base);
+}
+
+static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
+ void *v)
+{
+ struct etmv4_drvdata *drvdata;
+ unsigned int cpu = smp_processor_id();
+
+ if (!etmdrvdata[cpu])
+ return NOTIFY_OK;
+
+ drvdata = etmdrvdata[cpu];
+
+ if (!drvdata->save_state)
+ return NOTIFY_OK;
+
+ if (WARN_ON_ONCE(drvdata->cpu != cpu))
+ return NOTIFY_BAD;
+
+ switch (cmd) {
+ case CPU_PM_ENTER:
+ /* save the state if self-hosted coresight is in use */
+ if (local_read(&drvdata->mode))
+ if (etm4_cpu_save(drvdata))
+ return NOTIFY_BAD;
+ break;
+ case CPU_PM_EXIT:
+ /* fallthrough */
+ case CPU_PM_ENTER_FAILED:
+ if (drvdata->state_needs_restore)
+ etm4_cpu_restore(drvdata);
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block etm4_cpu_pm_nb = {
+ .notifier_call = etm4_cpu_pm_notify,
+};
+
+static int etm4_cpu_pm_register(void)
+{
+ return cpu_pm_register_notifier(&etm4_cpu_pm_nb);
+}
+
+static void etm4_cpu_pm_unregister(void)
+{
+ cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
+}
+#else
+static int etm4_cpu_pm_register(void) { return 0; }
+static void etm4_cpu_pm_unregister(void) { }
+#endif
+
static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
{
int ret;
@@ -1101,6 +1402,17 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
dev_set_drvdata(dev, drvdata);
+ if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE)
+ pm_save_enable = coresight_loses_context_with_cpu(dev) ?
+ PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER;
+
+ if (pm_save_enable != PARAM_PM_SAVE_NEVER) {
+ drvdata->save_state = devm_kmalloc(dev,
+ sizeof(struct etmv4_save_state), GFP_KERNEL);
+ if (!drvdata->save_state)
+ return -ENOMEM;
+ }
+
/* Validity for the resource is already checked by the AMBA core */
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
@@ -1135,6 +1447,10 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
if (ret < 0)
goto err_arch_supported;
hp_online = ret;
+
+ ret = etm4_cpu_pm_register();
+ if (ret)
+ goto err_arch_supported;
}
cpus_read_unlock();
@@ -1185,6 +1501,8 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
err_arch_supported:
if (--etm4_count == 0) {
+ etm4_cpu_pm_unregister();
+
cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
if (hp_online)
cpuhp_remove_state_nocalls(hp_online);
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 4523f10ddd0f..546d790cb01b 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -175,6 +175,7 @@
ETM_MODE_EXCL_USER)
#define TRCSTATR_IDLE_BIT 0
+#define TRCSTATR_PMSTABLE_BIT 1
#define ETM_DEFAULT_ADDR_COMP 0
/* PowerDown Control Register bits */
@@ -281,6 +282,65 @@ struct etmv4_config {
u32 ext_inp;
};
+/**
+ * struct etm4_save_state - state to be preserved when ETM is without power
+ */
+struct etmv4_save_state {
+ u32 trcprgctlr;
+ u32 trcprocselr;
+ u32 trcconfigr;
+ u32 trcauxctlr;
+ u32 trceventctl0r;
+ u32 trceventctl1r;
+ u32 trcstallctlr;
+ u32 trctsctlr;
+ u32 trcsyncpr;
+ u32 trcccctlr;
+ u32 trcbbctlr;
+ u32 trctraceidr;
+ u32 trcqctlr;
+
+ u32 trcvictlr;
+ u32 trcviiectlr;
+ u32 trcvissctlr;
+ u32 trcvipcssctlr;
+ u32 trcvdctlr;
+ u32 trcvdsacctlr;
+ u32 trcvdarcctlr;
+
+ u32 trcseqevr[ETM_MAX_SEQ_STATES];
+ u32 trcseqrstevr;
+ u32 trcseqstr;
+ u32 trcextinselr;
+ u32 trccntrldvr[ETMv4_MAX_CNTR];
+ u32 trccntctlr[ETMv4_MAX_CNTR];
+ u32 trccntvr[ETMv4_MAX_CNTR];
+
+ u32 trcrsctlr[ETM_MAX_RES_SEL * 2];
+
+ u32 trcssccr[ETM_MAX_SS_CMP];
+ u32 trcsscsr[ETM_MAX_SS_CMP];
+ u32 trcsspcicr[ETM_MAX_SS_CMP];
+
+ u64 trcacvr[ETM_MAX_SINGLE_ADDR_CMP];
+ u64 trcacatr[ETM_MAX_SINGLE_ADDR_CMP];
+ u64 trccidcvr[ETMv4_MAX_CTXID_CMP];
+ u32 trcvmidcvr[ETM_MAX_VMID_CMP];
+ u32 trccidcctlr0;
+ u32 trccidcctlr1;
+ u32 trcvmidcctlr0;
+ u32 trcvmidcctlr1;
+
+ u32 trcclaimset;
+
+ u32 cntr_val[ETMv4_MAX_CNTR];
+ u32 seq_state;
+ u32 vinst_ctrl;
+ u32 ss_status[ETM_MAX_SS_CMP];
+
+ u32 trcpdcr;
+};
+
/**
* struct etm4_drvdata - specifics associated to an ETM component
* @base: Memory mapped base address for this component.
@@ -336,6 +396,8 @@ struct etmv4_config {
* @atbtrig: If the implementation can support ATB triggers
* @lpoverride: If the implementation can support low-power state over.
* @config: structure holding configuration parameters.
+ * @save_state: State to be preserved across power loss
+ * @state_needs_restore: True when there is context to restore after PM exit
*/
struct etmv4_drvdata {
void __iomem *base;
@@ -381,6 +443,8 @@ struct etmv4_drvdata {
bool atbtrig;
bool lpoverride;
struct etmv4_config config;
+ struct etmv4_save_state *save_state;
+ bool state_needs_restore;
};
/* Address comparator access types */
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 55db77f6410b..c2a48a4e73ea 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -1310,6 +1310,12 @@ static inline int coresight_search_device_idx(struct coresight_dev_list *dict,
return -ENOENT;
}
+bool coresight_loses_context_with_cpu(struct device *dev)
+{
+ return fwnode_property_present(dev_fwnode(dev),
+ "arm,coresight-loses-context-with-cpu");
+}
+
/*
* coresight_alloc_device_name - Get an index for a given device in the
* device index list specific to a driver. An index is allocated for a
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index a2b68823717b..44e552de419c 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -285,6 +285,8 @@ extern void coresight_disclaim_device(void __iomem *base);
extern void coresight_disclaim_device_unlocked(void __iomem *base);
extern char *coresight_alloc_device_name(struct coresight_dev_list *devs,
struct device *dev);
+
+extern bool coresight_loses_context_with_cpu(struct device *dev);
#else
static inline struct coresight_device *
coresight_register(struct coresight_desc *desc) { return NULL; }
@@ -307,6 +309,10 @@ static inline int coresight_claim_device(void __iomem *base)
static inline void coresight_disclaim_device(void __iomem *base) {}
static inline void coresight_disclaim_device_unlocked(void __iomem *base) {}
+static inline bool coresight_loses_context_with_cpu(struct device *dev)
+{
+ return false;
+}
#endif
extern int coresight_get_cpu(struct device *dev);
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 2/3] dt-bindings: arm: coresight: Add support for coresight-loses-context-with-cpu
From: Andrew Murray @ 2019-09-13 11:53 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Rob Herring, Mark Rutland
Cc: devicetree, Al.Grant, coresight, Leo Yan, Sudeep Holla,
linux-arm-kernel, Mike Leach
In-Reply-To: <20190913115312.12943-1-andrew.murray@arm.com>
Some coresight components, because of choices made during hardware
integration, require their state to be saved and restored across CPU low
power states.
The software has no reliable method of detecting when save/restore is
required thus let's add a binding to inform the kernel.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Documentation/devicetree/bindings/arm/coresight.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index fcc3bacfd8bc..d02c42d21f2f 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -87,6 +87,15 @@ its hardware characteristcs.
* port or ports: see "Graph bindings for Coresight" below.
+* Optional properties for all components:
+
+ * arm,coresight-loses-context-with-cpu : boolean. Indicates that the
+ hardware will lose register context on CPU power down (e.g. CPUIdle).
+ An example of where this may be needed are systems which contain a
+ coresight component and CPU in the same power domain. When the CPU
+ powers down the coresight component also powers down and loses its
+ context. This property is currently only used for the ETM 4.x driver.
+
* Optional properties for ETM/PTMs:
* arm,cp14: must be present if the system accesses ETM/PTM management
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 3/3] coresight: etm4x: save/restore state for external agents
From: Andrew Murray @ 2019-09-13 11:53 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Rob Herring, Mark Rutland
Cc: devicetree, Al.Grant, coresight, Leo Yan, Sudeep Holla,
linux-arm-kernel, Mike Leach
In-Reply-To: <20190913115312.12943-1-andrew.murray@arm.com>
Some hardware will ignore bit TRCPDCR.PU which is used to signal
to hardware that power should not be removed from the trace unit. Much like
self-hosted debug, we should also save/restore the trace unit state when
it is in use by external agents.
We wish to avoid saving the hardware state when coresight isn't in use
to reduce PM latency - However as external trace/debug is designed to be
unintrusive to the CPU, the only way of determining that an external agent is
present is to read the claim tags (TRCCLAIMCLR). Unfortunately this register
needs power and clocking - something it won't have when coresight isn't in use.
We also don't want to temporarily enable it due to the latency and PM context.
Let's compromise by adding a module parameter that will keep the trace unit
powered and clocked, thus allowing us to only save/restore state when external
trace (or self-hosted) is in use. Though please note that this doesn't allow
for tracing from boot on hardware that needs save/restore as the CPU may idle
prior to the ETMv4 driver starting and adding PM hooks to save/restore.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 39 +++++++++++++++++--
drivers/hwtracing/coresight/coresight.c | 2 +-
include/linux/coresight.h | 7 ++++
3 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 4cecabdd051b..3cb9ba9a6ddd 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -42,11 +42,12 @@ MODULE_PARM_DESC(boot_enable, "Enable tracing on boot");
#define PARAM_PM_SAVE_FIRMWARE 0 /* save self-hosted state as per firmware */
#define PARAM_PM_SAVE_NEVER 1 /* never save any state */
#define PARAM_PM_SAVE_SELF_HOSTED 2 /* save self-hosted state only */
+#define PARAM_PM_SAVE_ALWAYS 3 /* save all state (keeps power on) */
static int pm_save_enable = PARAM_PM_SAVE_FIRMWARE;
module_param(pm_save_enable, int, 0444);
MODULE_PARM_DESC(pm_save_enable,
- "Save/restore state on power down: 1 = never, 2 = self-hosted");
+ "Save/restore state on power down: 1 = never, 2 = self-hosted, 3 = self-hosted/external (keeps power on)");
/* The number of ETMv4 currently registered */
static int etm4_count;
@@ -1331,6 +1332,23 @@ static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
CS_LOCK(drvdata->base);
}
+static bool etm4_coresight_in_use(struct etmv4_drvdata *drvdata)
+{
+ /* Self-hosted session in progress? */
+ if (local_read(&drvdata->mode))
+ return true;
+
+ /*
+ * External agents can be detected through claim tags however we
+ * only read these tags if the trace unit is powered.
+ */
+ if (drvdata->csdev && pm_runtime_active(drvdata->csdev->dev.parent))
+ if (coresight_is_claimed_any(drvdata->base))
+ return true;
+
+ return false;
+}
+
static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
void *v)
{
@@ -1350,8 +1368,8 @@ static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
switch (cmd) {
case CPU_PM_ENTER:
- /* save the state if self-hosted coresight is in use */
- if (local_read(&drvdata->mode))
+ /* Save the state if coresight is in use */
+ if (etm4_coresight_in_use(drvdata))
if (etm4_cpu_save(drvdata))
return NOTIFY_BAD;
break;
@@ -1488,7 +1506,20 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
goto err_arch_supported;
}
- pm_runtime_put(&adev->dev);
+ /*
+ * We may wish to save the hardware state when coresight is in use so
+ * that we can recover from lost context during PM events. However as
+ * external trace/debug is designed to be unintrusive to the CPU, the
+ * only way of determining that an external agent is present is to read
+ * the claim tags (TRCCLAIMCLR). Unfortunately this register needs power
+ * and clocking - something it won't have when coresight isn't in use.
+ * Therefore we provide a module parameter that keeps the trace unit
+ * powered and clocked, thus allowing us to only save/restore state
+ * when external trace (or self-hosted) is in use.
+ */
+ if (pm_save_enable != PARAM_PM_SAVE_ALWAYS)
+ pm_runtime_put(&adev->dev);
+
dev_info(&drvdata->csdev->dev, "CPU%d: ETM v%d.%d initialized\n",
drvdata->cpu, drvdata->arch >> 4, drvdata->arch & 0xf);
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index c2a48a4e73ea..66ea69b0470b 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -140,7 +140,7 @@ static inline bool coresight_is_claimed_self_hosted(void __iomem *base)
return coresight_read_claim_tags(base) == CORESIGHT_CLAIM_SELF_HOSTED;
}
-static inline bool coresight_is_claimed_any(void __iomem *base)
+bool coresight_is_claimed_any(void __iomem *base)
{
return coresight_read_claim_tags(base) != 0;
}
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 44e552de419c..65bfd2cb0283 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -286,6 +286,8 @@ extern void coresight_disclaim_device_unlocked(void __iomem *base);
extern char *coresight_alloc_device_name(struct coresight_dev_list *devs,
struct device *dev);
+extern bool coresight_is_claimed_any(void __iomem *base);
+
extern bool coresight_loses_context_with_cpu(struct device *dev);
#else
static inline struct coresight_device *
@@ -309,6 +311,11 @@ static inline int coresight_claim_device(void __iomem *base)
static inline void coresight_disclaim_device(void __iomem *base) {}
static inline void coresight_disclaim_device_unlocked(void __iomem *base) {}
+static inline bool coresight_is_claimed_any(void __iomem *base)
+{
+ return false;
+}
+
static inline bool coresight_loses_context_with_cpu(struct device *dev)
{
return false;
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: arm: renesas: Convert 'renesas, prr' to json-schema
From: Rob Herring @ 2019-09-13 12:02 UTC (permalink / raw)
To: Simon Horman
Cc: Mark Rutland, devicetree, Yoshihiro Kaneko, Magnus Damm,
open list:MEDIA DRIVERS FOR RENESAS - FCP,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190908120528.9392-1-horms+renesas@verge.net.au>
On Sun, Sep 8, 2019 at 11:14 PM Simon Horman <horms+renesas@verge.net.au> wrote:
>
> Convert Renesas Product Register bindings documentation to json-schema.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> Based on v5.3-rc1
> Tested using:
> make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/arm/renesas,prr.yaml
>
> v2
> * Use simple enum for compat values
> * Drop "" from compat values
> * Only supply 'maxItems' property to 'reg'
> ---
> .../devicetree/bindings/arm/renesas,prr.txt | 20 -------------
> .../devicetree/bindings/arm/renesas,prr.yaml | 35 ++++++++++++++++++++++
> 2 files changed, 35 insertions(+), 20 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.txt
> create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.yaml
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 9/9] sunxi_defconfig: add new crypto options
From: Maxime Ripard @ 2019-09-13 12:10 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190913081555.GA22538@Red>
[-- Attachment #1.1: Type: text/plain, Size: 688 bytes --]
On Fri, Sep 13, 2019 at 10:15:55AM +0200, Corentin Labbe wrote:
> On Sat, Sep 07, 2019 at 07:03:53AM +0300, Maxime Ripard wrote:
> > On Fri, Sep 06, 2019 at 08:45:51PM +0200, Corentin Labbe wrote:
> > > This patch adds the new allwinner crypto configs to sunxi_defconfig
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > arch/arm/configs/sunxi_defconfig | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > Can you also enable it in arm64's defconfig as a module?
> >
>
> Does you prefer adding a Kconfig "DEFAULT m if ARCH_SUNXI" which
> permit to not touch any defconfig ?
It's not the preferred solution, unfortunately
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: crypto: Add DT bindings documentation for sun8i-ce Crypto Engine
From: Maxime Ripard @ 2019-09-13 12:11 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Herbert Xu, Russell King, linux-kernel,
linux-sunxi, Rob Herring, Corentin Labbe, linux-crypto,
David Miller, linux-arm-kernel
In-Reply-To: <CAGb2v646YkM93BAo=hrpL+tgDU-JJ49-uMCMGECUbouoJrpg=w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1016 bytes --]
On Thu, Sep 12, 2019 at 09:37:17PM +0100, Chen-Yu Tsai wrote:
> On Thu, Sep 12, 2019 at 9:33 PM Maxime Ripard <mripard@kernel.org> wrote:
> > On Thu, Sep 12, 2019 at 09:26:27PM +0100, Chen-Yu Tsai wrote:
> > > > >
> > > > > clock-names:
> > > > > items:
> > > > > - const: ahb
> > > > > - const: mod
> > > > > - const: mbus
> > > >
> > > > And here as well
> > > >
> > > > Something I missed earlier though was that we've tried to unify as
> > > > much as possible the ahb / apb / axi clocks around the bus name, it
> > > > would be great if you could do it.
> > >
> > > I think we also want to standardize "mbus" as "dram"?
> >
> > Do we? The only user so far seems to be sun9i-de, while mbus has more
> > users. I don't really care though, both mbus and dram are pretty
> > generic to me. What makes you prefer dram over mbus?
>
> Argh... it's actually "ram" we use the most. Both "dram" and "mbus"
> have only one instance each.
Let's use ram then :)
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 00/15] arm64: dts: imx8: architecture improvement and adding imx8qm support
From: Oliver Graute @ 2019-09-13 12:16 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree, dongas86, catalin.marinas, will.deacon, robh+dt,
linux-imx, kernel, fabio.estevam, shawnguo, linux-arm-kernel
In-Reply-To: <1568302252-28066-1-git-send-email-aisheng.dong@nxp.com>
On 12/09/19, Dong Aisheng wrote:
> IMX SCU based platforms (e.g. MX8QM/MX8QXP) are comprised of a number of SS
> (Subsystems), those SS may be shared between different SoCs while most of them
> can be reused like Devices Resources, Clocks, Power domains and etc.
>
> This patch series aims to improve the MX8 architecture to comply with the HW
> design to save a lot of duplicated codes and benefits us a better
> maintainability and scalability in the future.
>
> This patch series depends on another clk new binding series:
> https://patchwork.kernel.org/cover/11046287/
Thx for your update of this patch series. I'am running into the issue
that my linux next-20190904 unfortunately is not booting with it on my
imx8QM board. Kernel is just stuck during boot see below.
I applied your v5 of your clock binding patches series and applied this
series in v3. Your former two patch series worked well with next-20190716.
The last messages from the kernel are:
[ 1.019208] imx-scu scu: mbox_request_channel_byname() could not locate channel named "gip3"
[ 1.027316] imx-scu scu: failed to request mbox chan gip3, ret -22
[ 1.033480] imx-scu scu: failed to enable general irq channel: -22
[ 1.039646] imx-scu scu: NXP i.MX SCU Initialized
[ 1.047414] a35_clk: failed to get clock rate -22
[ 1.058682] lcd0-pwm0: failed to power up resource 188 ret -22
[ 1.064314] imx-scu-clk: probe of pwm_clk failed with error -22
[ 1.070538] lcd0: failed to power up resource 187 ret -22
[ 1.075690] imx-scu-clk: probe of lcd_clk failed with error -22
[ 1.085965] mipi_csi0_core_clk: failed to attached the power domain -2
[ 1.092359] mipi_csi0_esc_clk: failed to attached the power domain -2
[ 1.098777] mipi_csi0_i2c0_clk: failed to attached the power domain -2
[ 1.105278] mipi_csi0_pwm0_clk: failed to attached the power domain -2
[ 1.115744] imx8qm-pinctrl scu:pinctrl: initialized IMX pinctrl driver
[ 1.123923] gpio-mxc 5d080000.gpio: IRQ index 1 not found
[ 1.130276] gpio-mxc 5d090000.gpio: IRQ index 1 not found
I see similar messages also with your older working patches, only the
last two lines are new errors.
Best regards,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: simplify syscall wrapper ifdeffery
From: Mark Rutland @ 2019-09-13 12:55 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Mark Rutland, Catalin Marinas, Will Deacon
Back in commit:
4378a7d4be30ec69 ("arm64: implement syscall wrappers")
... I implemented the arm64 syscall wrapper glue following the approach
taken on x86. While doing so, I also copied across some ifdeffery that
isn't necessary on arm64.
On arm64 we don't share any of the native wrappers with compat tasks,
and unlike x86 we don't have alternative implementations of
SYSCALL_DEFINE0(), COND_SYSCALL(), or SYS_NI() defined when AArch32
compat support is enabled.
Thus we don't need to prevent multiple definitions of these macros, and
can remove the #ifndef ... #endif guards protecting them. If any of
these had been previously defined elsewhere, syscalls are unlikely to
work correctly, and we'd want the compiler to warn about the multiple
definitions.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/syscall_wrapper.h | 6 ------
1 file changed, 6 deletions(-)
Hi Will, Catalin,
This is based on Sami's patch [1] implementing a type-safe COND_SYSCALL on
arm64. I've given both a spin atop of today's arm64 for-next/core branch.
Mark.
[1] https://lore.kernel.org/r/20190910224044.100388-1-samitolvanen@google.com
diff --git a/arch/arm64/include/asm/syscall_wrapper.h b/arch/arm64/include/asm/syscall_wrapper.h
index 06d880b3526c..b383b4802a7b 100644
--- a/arch/arm64/include/asm/syscall_wrapper.h
+++ b/arch/arm64/include/asm/syscall_wrapper.h
@@ -66,24 +66,18 @@ struct pt_regs;
} \
static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
-#ifndef SYSCALL_DEFINE0
#define SYSCALL_DEFINE0(sname) \
SYSCALL_METADATA(_##sname, 0); \
asmlinkage long __arm64_sys_##sname(const struct pt_regs *__unused); \
ALLOW_ERROR_INJECTION(__arm64_sys_##sname, ERRNO); \
asmlinkage long __arm64_sys_##sname(const struct pt_regs *__unused)
-#endif
-#ifndef COND_SYSCALL
#define COND_SYSCALL(name) \
asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \
{ \
return sys_ni_syscall(); \
}
-#endif
-#ifndef SYS_NI
#define SYS_NI(name) SYSCALL_ALIAS(__arm64_sys_##name, sys_ni_posix_timers);
-#endif
#endif /* __ASM_SYSCALL_WRAPPER_H */
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Greg Kroah-Hartman @ 2019-09-13 13:02 UTC (permalink / raw)
To: Paolo Bonzini
Cc: mark.rutland, x86, wanpengli, kvm, narmstrong, catalin.marinas,
will.deacon, hpa, khilman, joro, rkrcmar, mingo, Dmitry Vyukov,
syzbot, devicetree, syzkaller-bugs, robh+dt, bp, linux-amlogic,
tglx, linux-arm-kernel, jmattson, USB list, linux-kernel,
sean.j.christopherson, carlo, Vitaly Kuznetsov
In-Reply-To: <db02a285-ad1d-6094-6359-ba80e6d3f2e0@redhat.com>
On Fri, Sep 13, 2019 at 09:34:32AM +0200, Paolo Bonzini wrote:
> On 13/09/19 06:46, Greg Kroah-Hartman wrote:
> > USB drivers expect kmalloc to return DMA-able memory. I don't know
> > about specific alignment issues, that should only an issue for the host
> > controller being used here, which you do not say in the above list.
>
> I have no idea, this is just the analysis of a syzkaller report. From
> the backtrace, it's one that ends up calling kmalloc; all of them should
> have the same issue with KASAN.
>
> The specific alignment requirement for this bug comes from this call in
> usbdev_mmap:
>
> if (remap_pfn_range(vma, vma->vm_start,
> virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> size, vma->vm_page_prot) < 0) {
>
> > We have had some reports that usbdev_mmap() does not do the "correct
> > thing" for all host controllers, but a lot of the DMA work that is in
> > linux-next for 5.4-rc1 should have helped resolve those issues. What
> > tree are you seeing these bug reports happening from?
>
> It's in master, but the relevant code is the same in linux-next; in fact
> in this case there is no DMA involved at all. hcd_buffer_alloc hits
> the case "some USB hosts just use PIO".
>
> On those host controllers, it should be reproducible with just this:
>
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index 7fcb9f782931..cc0460730bce 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -905,9 +905,12 @@ EXPORT_SYMBOL_GPL(__usb_get_extra_descriptor);
> void *usb_alloc_coherent(struct usb_device *dev, size_t size, gfp_t mem_flags,
> dma_addr_t *dma)
> {
> + void *buf;
> if (!dev || !dev->bus)
> return NULL;
> - return hcd_buffer_alloc(dev->bus, size, mem_flags, dma);
> + buf = hcd_buffer_alloc(dev->bus, size, mem_flags, dma);
> + WARN_ON_ONCE(virt_to_phys(buf) & ~PAGE_MASK);
> + return buf;
> }
> EXPORT_SYMBOL_GPL(usb_alloc_coherent);
Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
not need this type of thing. If we got it wrong, please let us know and
then yes, a fix like this would be most appreciated :)
thanks,
greg k-h
>
>
> and CONFIG_KASAN=y or possibly just CONFIG_DEBUG_SLAB=y. mmap-ing /dev/usb
> should warn if my analysis is correct.
>
> If you think the above patch makes sense, I can test it and submit it formally.
>
> Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] iio: adc: stm32-adc: fix a race when using several adcs with dma and irq
From: Fabrice Gasnier @ 2019-09-13 13:21 UTC (permalink / raw)
To: jic23
Cc: lars, alexandre.torgue, linux-iio, pmeerw, linux-kernel,
mcoquelin.stm32, knaack.h, fabrice.gasnier, linux-stm32,
linux-arm-kernel
End of conversion may be handled by using IRQ or DMA. There may be a
race when two conversions complete at the same time on several ADCs.
EOC can be read as 'set' for several ADCs, with:
- an ADC configured to use IRQs. EOCIE bit is set. The handler is normally
called in this case.
- an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA
request instead. It's then automatically cleared by DMA read. But the
handler gets called due to status bit is temporarily set (IRQ triggered
by the other ADC).
So both EOC status bit in CSR and EOCIE control bit must be checked
before invoking the interrupt handler (e.g. call ISR only for
IRQ-enabled ADCs).
Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
drivers/iio/adc/stm32-adc-core.c | 43 +++++++++++++++++++++++++++++++++++++---
drivers/iio/adc/stm32-adc-core.h | 13 ++++++++++++
drivers/iio/adc/stm32-adc.c | 6 ------
3 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
index 9b85fef..7297396 100644
--- a/drivers/iio/adc/stm32-adc-core.c
+++ b/drivers/iio/adc/stm32-adc-core.c
@@ -71,6 +71,8 @@
* @eoc1: adc1 end of conversion flag in @csr
* @eoc2: adc2 end of conversion flag in @csr
* @eoc3: adc3 end of conversion flag in @csr
+ * @ier: interrupt enable register offset for each adc
+ * @eocie_msk: end of conversion interrupt enable mask in @ier
*/
struct stm32_adc_common_regs {
u32 csr;
@@ -78,6 +80,8 @@ struct stm32_adc_common_regs {
u32 eoc1_msk;
u32 eoc2_msk;
u32 eoc3_msk;
+ u32 ier;
+ u32 eocie_msk;
};
struct stm32_adc_priv;
@@ -303,6 +307,8 @@ static const struct stm32_adc_common_regs stm32f4_adc_common_regs = {
.eoc1_msk = STM32F4_EOC1,
.eoc2_msk = STM32F4_EOC2,
.eoc3_msk = STM32F4_EOC3,
+ .ier = STM32F4_ADC_CR1,
+ .eocie_msk = STM32F4_EOCIE,
};
/* STM32H7 common registers definitions */
@@ -311,8 +317,24 @@ static const struct stm32_adc_common_regs stm32h7_adc_common_regs = {
.ccr = STM32H7_ADC_CCR,
.eoc1_msk = STM32H7_EOC_MST,
.eoc2_msk = STM32H7_EOC_SLV,
+ .ier = STM32H7_ADC_IER,
+ .eocie_msk = STM32H7_EOCIE,
};
+static const unsigned int stm32_adc_offset[STM32_ADC_MAX_ADCS] = {
+ 0, STM32_ADC_OFFSET, STM32_ADC_OFFSET * 2,
+};
+
+static unsigned int stm32_adc_eoc_enabled(struct stm32_adc_priv *priv,
+ unsigned int adc)
+{
+ u32 ier, offset = stm32_adc_offset[adc];
+
+ ier = readl_relaxed(priv->common.base + offset + priv->cfg->regs->ier);
+
+ return ier & priv->cfg->regs->eocie_msk;
+}
+
/* ADC common interrupt for all instances */
static void stm32_adc_irq_handler(struct irq_desc *desc)
{
@@ -323,13 +345,28 @@ static void stm32_adc_irq_handler(struct irq_desc *desc)
chained_irq_enter(chip, desc);
status = readl_relaxed(priv->common.base + priv->cfg->regs->csr);
- if (status & priv->cfg->regs->eoc1_msk)
+ /*
+ * End of conversion may be handled by using IRQ or DMA. There may be a
+ * race here when two conversions complete at the same time on several
+ * ADCs. EOC may be read 'set' for several ADCs, with:
+ * - an ADC configured to use DMA (EOC triggers the DMA request, and
+ * is then automatically cleared by DR read in hardware)
+ * - an ADC configured to use IRQs (EOCIE bit is set. The handler must
+ * be called in this case)
+ * So both EOC status bit in CSR and EOCIE control bit must be checked
+ * before invoking the interrupt handler (e.g. call ISR only for
+ * IRQ-enabled ADCs).
+ */
+ if (status & priv->cfg->regs->eoc1_msk &&
+ stm32_adc_eoc_enabled(priv, 0))
generic_handle_irq(irq_find_mapping(priv->domain, 0));
- if (status & priv->cfg->regs->eoc2_msk)
+ if (status & priv->cfg->regs->eoc2_msk &&
+ stm32_adc_eoc_enabled(priv, 1))
generic_handle_irq(irq_find_mapping(priv->domain, 1));
- if (status & priv->cfg->regs->eoc3_msk)
+ if (status & priv->cfg->regs->eoc3_msk &&
+ stm32_adc_eoc_enabled(priv, 2))
generic_handle_irq(irq_find_mapping(priv->domain, 2));
chained_irq_exit(chip, desc);
diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
index 8af507b..8dc936b 100644
--- a/drivers/iio/adc/stm32-adc-core.h
+++ b/drivers/iio/adc/stm32-adc-core.h
@@ -25,8 +25,21 @@
* --------------------------------------------------------
*/
#define STM32_ADC_MAX_ADCS 3
+#define STM32_ADC_OFFSET 0x100
#define STM32_ADCX_COMN_OFFSET 0x300
+/* STM32F4 - registers for each ADC instance */
+#define STM32F4_ADC_CR1 0x04
+
+/* STM32F4_ADC_CR1 - bit fields */
+#define STM32F4_EOCIE BIT(5)
+
+/* STM32H7 - registers for each instance */
+#define STM32H7_ADC_IER 0x04
+
+/* STM32H7_ADC_IER - bit fields */
+#define STM32H7_EOCIE BIT(2)
+
/**
* struct stm32_adc_common - stm32 ADC driver common data (for all instances)
* @base: control registers base cpu addr
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
index 6a7dd08..3c9f456 100644
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -30,7 +30,6 @@
/* STM32F4 - Registers for each ADC instance */
#define STM32F4_ADC_SR 0x00
-#define STM32F4_ADC_CR1 0x04
#define STM32F4_ADC_CR2 0x08
#define STM32F4_ADC_SMPR1 0x0C
#define STM32F4_ADC_SMPR2 0x10
@@ -54,7 +53,6 @@
#define STM32F4_RES_SHIFT 24
#define STM32F4_RES_MASK GENMASK(25, 24)
#define STM32F4_SCAN BIT(8)
-#define STM32F4_EOCIE BIT(5)
/* STM32F4_ADC_CR2 - bit fields */
#define STM32F4_SWSTART BIT(30)
@@ -69,7 +67,6 @@
/* STM32H7 - Registers for each ADC instance */
#define STM32H7_ADC_ISR 0x00
-#define STM32H7_ADC_IER 0x04
#define STM32H7_ADC_CR 0x08
#define STM32H7_ADC_CFGR 0x0C
#define STM32H7_ADC_SMPR1 0x14
@@ -89,9 +86,6 @@
#define STM32H7_EOC BIT(2)
#define STM32H7_ADRDY BIT(0)
-/* STM32H7_ADC_IER - bit fields */
-#define STM32H7_EOCIE STM32H7_EOC
-
/* STM32H7_ADC_CR - bit fields */
#define STM32H7_ADCAL BIT(31)
#define STM32H7_ADCALDIF BIT(30)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5.2 28/37] usb: chipidea: imx: fix EPROBE_DEFER support during driver probe
From: Greg Kroah-Hartman @ 2019-09-13 13:07 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Chen, Fabio Estevam, Greg Kroah-Hartman, Sascha Hauer,
linux-usb, stable, NXP Linux Team, Pengutronix Kernel Team,
André Draszik, Shawn Guo, linux-arm-kernel
In-Reply-To: <20190913130510.727515099@linuxfoundation.org>
If driver probe needs to be deferred, e.g. because ci_hdrc_add_device()
isn't ready yet, this driver currently misbehaves badly:
a) success is still reported to the driver core (meaning a 2nd
probe attempt will never be done), leaving the driver in
a dysfunctional state and the hardware unusable
b) driver remove / shutdown OOPSes:
[ 206.786916] Unable to handle kernel paging request at virtual address fffffdff
[ 206.794148] pgd = 880b9f82
[ 206.796890] [fffffdff] *pgd=abf5e861, *pte=00000000, *ppte=00000000
[ 206.803179] Internal error: Oops: 37 [#1] PREEMPT SMP ARM
[ 206.808581] Modules linked in: wl18xx evbug
[ 206.813308] CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 4.19.35+gf345c93b4195 #1
[ 206.821053] Hardware name: Freescale i.MX7 Dual (Device Tree)
[ 206.826813] PC is at ci_hdrc_remove_device+0x4/0x20
[ 206.831699] LR is at ci_hdrc_imx_remove+0x20/0xe8
[ 206.836407] pc : [<805cd4b0>] lr : [<805d62cc>] psr: 20000013
[ 206.842678] sp : a806be40 ip : 00000001 fp : 80adbd3c
[ 206.847906] r10: 80b1b794 r9 : 80d5dfe0 r8 : a8192c44
[ 206.853136] r7 : 80db93a0 r6 : a8192c10 r5 : a8192c00 r4 : a93a4a00
[ 206.859668] r3 : 00000000 r2 : a8192ce4 r1 : ffffffff r0 : fffffdfb
[ 206.866201] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 206.873341] Control: 10c5387d Table: a9e0c06a DAC: 00000051
[ 206.879092] Process systemd-shutdow (pid: 1, stack limit = 0xb271353c)
[ 206.885624] Stack: (0xa806be40 to 0xa806c000)
[ 206.889992] be40: a93a4a00 805d62cc a8192c1c a8170e10 a8192c10 8049a490 80d04d08 00000000
[ 206.898179] be60: 00000000 80d0da2c fee1dead 00000000 a806a000 00000058 00000000 80148b08
[ 206.906366] be80: 01234567 80148d8c a9858600 00000000 00000000 00000000 00000000 80d04d08
[ 206.914553] bea0: 00000000 00000000 a82741e0 a9858600 00000024 00000002 a9858608 00000005
[ 206.922740] bec0: 0000001e 8022c058 00000000 00000000 a806bf14 a9858600 00000000 a806befc
[ 206.930927] bee0: a806bf78 00000000 7ee12c30 8022c18c a806bef8 a806befc 00000000 00000001
[ 206.939115] bf00: 00000000 00000024 a806bf14 00000005 7ee13b34 7ee12c68 00000004 7ee13f20
[ 206.947302] bf20: 00000010 7ee12c7c 00000005 7ee12d04 0000000a 76e7dc00 00000001 80d0f140
[ 206.955490] bf40: ab637880 a974de40 60000013 80d0f140 ab6378a0 80d04d08 a8080470 a9858600
[ 206.963677] bf60: a9858600 00000000 00000000 8022c24c 00000000 80144310 00000000 00000000
[ 206.971864] bf80: 80101204 80d04d08 00000000 80d04d08 00000000 00000000 00000003 00000058
[ 206.980051] bfa0: 80101204 80101000 00000000 00000000 fee1dead 28121969 01234567 00000000
[ 206.988237] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000
[ 206.996425] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6 60000030 fee1dead 00000000 00000000
[ 207.004622] [<805cd4b0>] (ci_hdrc_remove_device) from [<805d62cc>] (ci_hdrc_imx_remove+0x20/0xe8)
[ 207.013509] [<805d62cc>] (ci_hdrc_imx_remove) from [<8049a490>] (device_shutdown+0x16c/0x218)
[ 207.022050] [<8049a490>] (device_shutdown) from [<80148b08>] (kernel_restart+0xc/0x50)
[ 207.029980] [<80148b08>] (kernel_restart) from [<80148d8c>] (sys_reboot+0xf4/0x1f0)
[ 207.037648] [<80148d8c>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54)
[ 207.045308] Exception stack(0xa806bfa8 to 0xa806bff0)
[ 207.050368] bfa0: 00000000 00000000 fee1dead 28121969 01234567 00000000
[ 207.058554] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000
[ 207.066737] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6
[ 207.071799] Code: ebffffa8 e3a00000 e8bd8010 e92d4010 (e5904004)
[ 207.078021] ---[ end trace be47424e3fd46e9f ]---
[ 207.082647] Kernel panic - not syncing: Fatal exception
[ 207.087894] ---[ end Kernel panic - not syncing: Fatal exception ]---
c) the error path in combination with driver removal causes
imbalanced calls to the clk_*() and pm_()* APIs
a) happens because the original intended return value is
overwritten (with 0) by the return code of
regulator_disable() in ci_hdrc_imx_probe()'s error path
b) happens because ci_pdev is -EPROBE_DEFER, which causes
ci_hdrc_remove_device() to OOPS
Fix a) by being more careful in ci_hdrc_imx_probe()'s error
path and not overwriting the real error code
Fix b) by calling the respective cleanup functions during
remove only when needed (when ci_pdev != NULL, i.e. when
everything was initialised correctly). This also has the
side effect of not causing imbalanced clk_*() and pm_*()
API calls as part of the error code path.
Fixes: 7c8e8909417e ("usb: chipidea: imx: add HSIC support")
Signed-off-by: André Draszik <git@andred.net>
Cc: stable <stable@vger.kernel.org>
CC: Peter Chen <Peter.Chen@nxp.com>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Shawn Guo <shawnguo@kernel.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Pengutronix Kernel Team <kernel@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: NXP Linux Team <linux-imx@nxp.com>
CC: linux-usb@vger.kernel.org
CC: linux-arm-kernel@lists.infradead.org
CC: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20190810150758.17694-1-git@andred.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/chipidea/ci_hdrc_imx.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
index a76708501236d..5faae96735e62 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -453,9 +453,11 @@ err_clk:
imx_disable_unprepare_clks(dev);
disable_hsic_regulator:
if (data->hsic_pad_regulator)
- ret = regulator_disable(data->hsic_pad_regulator);
+ /* don't overwrite original ret (cf. EPROBE_DEFER) */
+ regulator_disable(data->hsic_pad_regulator);
if (pdata.flags & CI_HDRC_PMQOS)
pm_qos_remove_request(&data->pm_qos_req);
+ data->ci_pdev = NULL;
return ret;
}
@@ -468,14 +470,17 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
pm_runtime_put_noidle(&pdev->dev);
}
- ci_hdrc_remove_device(data->ci_pdev);
+ if (data->ci_pdev)
+ ci_hdrc_remove_device(data->ci_pdev);
if (data->override_phy_control)
usb_phy_shutdown(data->phy);
- imx_disable_unprepare_clks(&pdev->dev);
- if (data->plat_data->flags & CI_HDRC_PMQOS)
- pm_qos_remove_request(&data->pm_qos_req);
- if (data->hsic_pad_regulator)
- regulator_disable(data->hsic_pad_regulator);
+ if (data->ci_pdev) {
+ imx_disable_unprepare_clks(&pdev->dev);
+ if (data->plat_data->flags & CI_HDRC_PMQOS)
+ pm_qos_remove_request(&data->pm_qos_req);
+ if (data->hsic_pad_regulator)
+ regulator_disable(data->hsic_pad_regulator);
+ }
return 0;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [v2] ACPI: support for NXP i2c controller
From: Wolfram Sang @ 2019-09-13 14:13 UTC (permalink / raw)
To: Biwen Li
Cc: udit.kumar, s.hauer, rafael, rjw, linux-kernel, leoyang.li,
linux-acpi, andy.shevchenko, meenakshi.aggarwal, linux-i2c,
chuanhua.han, shawnguo, linux-arm-kernel
In-Reply-To: <20190906075319.21244-1-biwen.li@nxp.com>
[-- Attachment #1.1: Type: text/plain, Size: 440 bytes --]
On Fri, Sep 06, 2019 at 03:53:19PM +0800, Biwen Li wrote:
> From: Chuanhua Han <chuanhua.han@nxp.com>
>
> Enable NXP i2c controller to boot with ACPI
>
> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
> Signed-off-by: Biwen Li <biwen.li@nxp.com>
Added Rafael's tag from v1 and applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu: Report USF more clearly
From: Robin Murphy @ 2019-09-13 14:34 UTC (permalink / raw)
To: will, joro; +Cc: iommu, Douglas Anderson, linux-arm-kernel
In-Reply-To: <2762ffd4c196dc91d62e10eb8b753f256ea9b629.1568375317.git.robin.murphy@arm.com>
On 13/09/2019 12:48, Robin Murphy wrote:
> Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool
> for smoking out inadequate firmware, the failure mode is non-obvious
> and can be confusing for end users. Add some special-case reporting of
> Unidentified Stream Faults to help clarify this particular symptom.
>
> CC: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 5 +++++
> drivers/iommu/arm-smmu.h | 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index b7cf24402a94..76ac8c180695 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -499,6 +499,11 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> dev_err_ratelimited(smmu->dev,
> "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
> gfsr, gfsynr0, gfsynr1, gfsynr2);
> + if (IS_ENABLED(CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT) &&
> + (gfsr & sGFSR_USF))
> + dev_err_ratelimited(smmu->dev,
> + "Stream ID %hu may not be described by firmware, try booting with \"arm-smmu.disable_bypass=0\"\n",
> + (u16)gfsynr1);
>
> arm_smmu_gr0_write(smmu, ARM_SMMU_GR0_sGFSR, gfsr);
> return IRQ_HANDLED;
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index c9c13b5785f2..46f7e161e83e 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -79,6 +79,8 @@
> #define ID7_MINOR GENMASK(3, 0)
>
> #define ARM_SMMU_GR0_sGFSR 0x48
> +#define sGFSR_USF BIT(2)
Sigh... and of course what I actually meant here was that this is the
2nd bit, which is bit 1, which is also 2. I blame Friday :(
Robin.
> +
> #define ARM_SMMU_GR0_sGFSYNR0 0x50
> #define ARM_SMMU_GR0_sGFSYNR1 0x54
> #define ARM_SMMU_GR0_sGFSYNR2 0x58
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] ARM: dts: stm32: Enable VREFBUF on stm32mp157a-dk1
From: Fabrice Gasnier @ 2019-09-13 14:34 UTC (permalink / raw)
To: alexandre.torgue
Cc: mark.rutland, devicetree, linux-kernel, robh+dt, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <1568385280-2633-1-git-send-email-fabrice.gasnier@st.com>
Enable VREFBUF as ADC/DAC uses it on stm32mp157a-dk1 board.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
arch/arm/boot/dts/stm32mp157a-dk1.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index 0615d1c..ebd9f33 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -449,3 +449,10 @@
pinctrl-0 = <&uart4_pins_a>;
status = "okay";
};
+
+&vrefbuf {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ vdda-supply = <&vdd>;
+ status = "okay";
+};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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