summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-record
diff options
context:
space:
mode:
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.46.0) at 2026-07-16 02:39:37 +0000
former callsite. Acked-By: Vinod Koul <vkoul@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2023-01-16ARM: mmp: remove all board filesArnd Bergmann The old-style board files were marked as 'unused' a while ago and can now be removed for good, leaving only devicetree based boot support. Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2023-01-16ARM: mmp: select specific CPU implementationArnd Bergmann The behavior of the MMP platform code depends on whether the CPU_PXA168/CPU_PXA910/CPU_MMP2 symbols are enabled or not. I believe the intention here was that these can be left disabled for a pure DT-only build, but it's not clear if that actually works. At the minimum, the cpu_is_pxa168() and cpu_is_pxa910() checks behave differently, which causes changes in the power management code. For the moment, make the behavior depend on whether CONFIG_ATAGS is set or not, to make it easier to bisect the removal of the old code later. Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-12-04ARM: mmp: fix timer_read delayDoug Brown timer_read() was using an empty 100-iteration loop to wait for the TMR_CVWR register to capture the latest timer counter value. The delay wasn't long enough. This resulted in CPU idle time being extremely underreported on PXA168 with CONFIG_NO_HZ_IDLE=y. Switch to the approach used in the vendor kernel, which implements the capture delay by reading TMR_CVWR a few times instead. Fixes: 49cbe78637eb ("[ARM] pxa: add base support for Marvell's PXA168 processor line") Signed-off-by: Doug Brown <doug@schmorgal.com> Link: https://lore.kernel.org/r/20221204005117.53452-3-doug@schmorgal.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-10-10ARM: mmp: Make some symbols staticChen Lifu These symbols pxa168_usb_phy_resources, pxa168_u2o_resources, pxa168_u2oehci_resources and pxa168_u2ootg_resources are not used outside of arch/arm/mach-mmp/devices.c, so mark them static. Fixes the following sparse warning: arch/arm/mach-mmp/devices.c:241:17: warning: symbol 'pxa168_usb_phy_resources' was not declared. Should it be static? arch/arm/mach-mmp/devices.c:262:17: warning: symbol 'pxa168_u2o_resources' was not declared. Should it be static? arch/arm/mach-mmp/devices.c:297:17: warning: symbol 'pxa168_u2oehci_resources' was not declared. Should it be static? arch/arm/mach-mmp/devices.c:324:17: warning: symbol 'pxa168_u2ootg_resources' was not declared. Should it be static? Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Chen Lifu <chenlifu@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-08-02Merge tag 'arm-boardfiles-6.0' of ↵Linus Torvalds git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM boardfile deprecation from Arnd Bergmann: "Over the past ten years, new machine support was based on device tree, and an initial set of about 400 boards using ATAGS with boardfile for booting were grandfathered in, with about half of them either removed or converted to DT over time. Based on the recent mailing list discussion I started, I have now turned the findings into a set of patches that marks most board files as 'depends on UNUSED_BOARD_FILES', leaving only 38 of the 196 boards. For the boards that are marked as unused, there are two final chances for potential users: The removal is scheduled to take place after the longterm stable kernel at the end of 2022, so users can stay on that version for another few years, and if anyone still has one of these machines and is planning to keep updating kernels beyond that version, they can speak up now to have their boards taken off the list again. Waiting for the LTS release also makes sure that there will be at least one longterm kernel that contains the recent multiplatform conversion along while still supporting all legacy boards. The short summary of the current status is: - The s3c24xx, cns3xxx, iop32x and mv78xx0 platforms have no known users and will be removed entirely. - The mmp and davinci platforms have DT support for the important machines and will become DT-only after this. - s3c64xx, dove, orion5x, and pxa keep some board files to allow those to be migrated over to DT more easily, but most board files are getting removed now. DT support on these platforms is partially working but requires changes to additional drivers for the other boards. - omap1, ep93xx, sa1100, footbridge and rpc have no DT support at the moment but have some boards with known users. Removing the board files that nobody uses should make it easier to try a DT conversion if anyone cares. There is no explicit timeline what happens with the boards that remain after this removal, but I expect to revisit this in the future, and with most boards gone, there will be a good time to do a treewide review of platform drivers that never gained DT support and have no remaining in-tree board files" Link: https://lore.kernel.org/linux-arm-kernel/CAK8P3a0Z9vGEQbVRBo84bSyPFM-LF+hs5w8ZA51g2Z+NsdtDQA@mail.gmail.com/ * tag 'arm-boardfiles-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: cns3xxx: add CONFIG_UNUSED_BOARD_FILES dependency ARM: iop32x: mark as unused ARM: s3c: mark most board files as unused ARM: omap1: add Kconfig dependencies for unused boards ARM: sa1100: mark most boards as unused ARM: footbridge: mark cats board for removal ARM: mmp: mark all board files for removal ARM: ep93xx: mark most board files as unused ARM: davinci: mark all ATAGS board files as unused ARM: orion: add ATAGS dependencies ARM: pxa: add Kconfig dependencies for ATAGS based boards ARM: add CONFIG_UNUSED_BOARD_FILES ARM: add ATAGS dependencies to non-DT platforms 2022-07-25irqchip/mmp: Declare init functions in common header fileBen Dooks The functions icu_init_irq and mmp2_init_icu are exported from this code, so declare them in the header file to avoid the following sparse warnings: drivers/irqchip/irq-mmp.c:248:13: warning: symbol 'icu_init_irq' was not declared. Should it be static? drivers/irqchip/irq-mmp.c:271:13: warning: symbol 'mmp2_init_icu' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> [maz: fixup commit message] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220724222152.551850-1-ben-linux@fluff.org 2022-07-22ARM: mmp: mark all board files for removalArnd Bergmann The mmp platform supports both ATAGS based board files and DT booting, but it appears that nobody has been interested in board files for a long time. Mark all of them for removal in early 2023 with a dependency on CONFIG_UNUSED_BOARD_FILES, leaving only the DT support for the future, unless someone pops up who uses them. Cc: Lubomir Rintel <lkundrak@v3.sk> Cc: Haojian Zhuang <haojian.zhuang@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-06-02Merge tag 'arm-multiplatform-5.19-2' of ↵Linus Torvalds git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull more ARM multiplatform updates from Arnd Bergmann: "The second part of the multiplatform changes now converts the Intel/Marvell PXA platform along with the rest. The patches went through several rebases before the merge window as bugs were found, so they remained separate. This has to touch a lot of drivers, in particular the touchscreen, pcmcia, sound and clk bits, to detach the driver files from the platform and board specific header files" * tag 'arm-multiplatform-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (48 commits) ARM: pxa/mmp: remove traces of plat-pxa ARM: pxa: convert to multiplatform ARM: pxa/sa1100: move I/O space to PCI_IOBASE ARM: pxa: remove support for MTD_XIP ARM: pxa: move mach/*.h to mach-pxa/ ARM: PXA: fix multi-cpu build of xsc3 ARM: pxa: move plat-pxa to drivers/soc/ ARM: mmp: rename pxa_register_device ARM: mmp: remove tavorevb board support ARM: pxa: remove unused mach/bitfield.h ARM: pxa: move clk register definitions to driver ARM: pxa: move smemc register access from clk to platform cpufreq: pxa3: move clk register access to clk driver ARM: pxa: remove get_clk_frequency_khz() ARM: pxa: pcmcia: move smemc configuration back to arch ASoC: pxa: i2s: use normal MMIO accessors ASoC: pxa: ac97: use normal MMIO accessors ASoC: pxa: use pdev resource for FIFO regs Input: wm97xx - get rid of irq_enable method in wm97xx_mach_ops Input: wm97xx - switch to using threaded IRQ ... 2022-05-31ARM: pxa/mmp: remove traces of plat-pxaArnd Bergmann The missing include directory caused a W=1 warning that can be trivially fixed. I also noticed references in the marvell.rst documentation that can be removed at the same time. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-05-07ARM: pxa: move plat-pxa to drivers/soc/Arnd Bergmann There are two drivers in arch/arm/plat-pxa: mfp and ssp. Both of them should ideally not be needed at all, as there are proper subsystems to replace them. OTOH, they are self-contained and can simply be normal SoC drivers, so move them over there to eliminate one more of the plat-* directories. Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> (mach-pxa) Acked-by: Lubomir Rintel <lkundrak@v3.sk> (mach-mmp) Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-05-07ARM: mmp: rename pxa_register_deviceArnd Bergmann In a multiplatform kernel that includes both pxa and mmp, we get a link failure from the clash of two pxa_register_device functions. Rename the one in mach-mmp to mmp_register_device, along with with the rename of pxa_device_desc. Acked-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-05-07ARM: mmp: remove tavorevb board supportArnd Bergmann There are two tavorevb boards in the kernel, one using a PXA930 chip in mach-pxa, and one using the later PXA910 chip in mach-mmp. They use the same board number, which is generally a bad idea, and in a multiplatform kernel, we can end up with funny link errors like this one resulting from two boards gettting controlled by the same Kconfig symbol: arch/arm/mach-mmp/tavorevb.o: In function `tavorevb_init': tavorevb.c:(.init.text+0x4c): undefined reference to `pxa910_device_uart1' tavorevb.c:(.init.text+0x50): undefined reference to `pxa910_device_gpio' tavorevb.o:(.arch.info.init+0x54): undefined reference to `pxa910_init_irq' tavorevb.o:(.arch.info.init+0x58): undefined reference to `pxa910_timer_init' The mach-pxa TavorEVB seems much more complete than the mach-mmp one that supports only uart, gpio and ethernet. Further, I could find no information about the board on the internet aside from references to the Linux kernel, so I assume this was never available outside of Marvell and can be removed entirely. There is a third board named TavorEVB in the Kconfig description, but this refers to the "TTC_DKB" machine. The two are clearly related, so I change the Kconfig description to just list both names. Cc: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-04-08ARM: rework endianess selectionArnd Bergmann Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago. The problems is that CONFIG_BIG_ENDIAN depends on ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform in the config, but would actually have to be supported by all of them. This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and tend to just work aside from problems in nonportable device drivers. For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM were never set together, so this was disabled on all those machines except for IXP4xx. As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to formalize this logic: all ARMv4/v5 platforms get an explicit dependency on being either big-endian (ixp4xx) or little-endian (the rest). We may want to fix ixp4xx in the future to support both, but it does not work in LE mode at the moment. For the ARMv6/v7 platforms, there are two ways this could be handled a) allow both modes only for platforms selecting 'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the others, given that these were added intentionally at some point. b) allow both modes everwhere, given that it was already possible to build that way by e.g. selecting ARCH_VIRT, and that the list is not an accurate reflection of which platforms may or may not work. Out of these, I picked b) because it seemed slighly more logical to me. Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2022-02-25ARM: mmp: Fix failure to remove sram deviceUwe Kleine-König Make sure in .probe() to set driver data before the function is left to make it possible in .remove() to undo the actions done. This fixes a potential memory leak and stops returning an error code in .remove() that is ignored by the driver core anyhow. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>