aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/exported-sql-viewer.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-11-04ARM: imx: use generic function to exit coherencyStefan Agner1-22/+2
The common ARM architecture code provides a generic function to exit coherency called v7_exit_coherency_flush(). Replace the machine specific implementation using the generic function. Tested on a i.MX 6Dual by hotplugging the secondary CPU under load through sysfs several 1000 times. Tested-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-29ARM: tegra: Use WFE for power-gating on Tegra30Dmitry Osipenko2-3/+20
Turned out that WFI doesn't work reliably on Tegra30 as a trigger for the power-gating, it causes CPU hang under some circumstances like having memory controller running of PLLP. The TRM doc states that WFI should be used for the Big-Little "Cluster Switch", while WFE for the power-gating. Hence let's use the WFE for CPU0 power-gating, like it is done for the power-gating of a secondary cores. This fixes CPU hang after entering LP2 with memory running off PLLP. Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29ARM: tegra: Fix FLOW_CTLR_HALT register clobbering by tegra_resume()Dmitry Osipenko1-3/+3
There is an unfortunate typo in the code that results in writing to FLOW_CTLR_HALT instead of FLOW_CTLR_CSR. Cc: <stable@vger.kernel.org> Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-28ARM: exynos: Enable exynos-asv driver for ARCH_EXYNOSSylwester Nawrocki1-0/+1
Enable exynos-asv driver for Exynos 32-bit SoCs. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28ARM: s3c: Rename s5p_usb_phy functionsKrzysztof Kozlowski3-6/+6
The name s5p_usb_phy_init() suggests it is shared with S5Pv210 platform, but it is not. It is specific to S3C64xx, so make it clear in the name. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28ARM: s3c: Rename s3c64xx_spi_setname() functionKrzysztof Kozlowski3-3/+3
The name s3c64xx_spi_setname() suggests it is shared with S3C64xx platform, but except of contents it is not. It is called only by S3C24xx code, so make it clear in the name. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28ARM: imx: Add serial number support for i.MX6/7 SoCsAnson Huang1-1/+37
i.MX6/7 SoCs have a 64-bit SoC unique ID stored in OCOTP, it can be used as SoC serial number, add this support for i.MX6Q/6DL/6SL/6SX/6SLL/6UL/6ULL/6ULZ/7D, see below example on i.MX6Q: root@imx6qpdlsolox:~# cat /sys/devices/soc0/serial_number 240F31D4E1FDFCA7 Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-28ARM: imx: Drop imx_anatop_usb_chrg_detect_disable()Andrey Smirnov1-19/+1
With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger detect in mxs_phy_hw_init()") in tree all of the necessary charger setup is done by the USB PHY driver which covers all of the affected i.MX6 SoCs. NOTE: imx_anatop_usb_chrg_detect_disable() was also called for i.MX7D, but looking at its datasheet it appears to have a different USB PHY IP block, so executing i.MX6 charger disable configuration seems unnecessary. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Peter Chen <peter.chen@nxp.com> Cc: linux-imx@nxp.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-26arm64: Introduce config for S32Mihaela Martinas1-0/+5
Add configuration option for the NXP S32 platform family in Kconfig.platforms. For starters, the only SoC supported will be Treerunner (S32V234), with a single execution target: the S32V234-EVB (rev 29288) board. Signed-off-by: Mihaela Martinas <Mihaela.Martinas@freescale.com> Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com> Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-26ARM: hisi: drop useless depend on ARCH_MULTI_V7Kefeng Wang1-10/+6
The ARCH_HISI depends on ARCH_MULTI_V7, no need to add this depend to each sub-menu config, and use tabs where possible. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2019-10-26arm64: realtek: Select reset controllerAndreas Färber1-0/+1
Select RESET_CONTROLLER for ARCH_REALTEK. Signed-off-by: Andreas Färber <afaerber@suse.de>
2019-10-25ARM: shmobile: rcar-gen2: Drop legacy DT clock supportGeert Uytterhoeven1-1/+0
As of commit 362b334b17943d84 ("ARM: dts: r8a7791: Convert to new CPG/MSSR bindings"), all upstream R-Car Gen2 device tree source files use the unified "Renesas Clock Pulse Generator / Module Standby and Software Reset" DT bindings. Hence remove backward compatibility with old R-Car Gen2 device trees describing a hierarchical representation of the various CPG and MSTP clocks. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191016150939.30620-1-geert+renesas@glider.be
2019-10-23ARM: OMAP2+: Remove duplicated include from pmic-cpcap.cYueHaibing1-2/+0
Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: OMAP2+: pdata-quirks: drop TI_ST/KIM supportSebastian Reichel1-52/+0
All TI_ST users have been migrated to the new serdev based HCILL bluetooth driver. That driver is initialized from DT and does not need any platform quirks. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: make omap44xx_sha0_hwmod and omap44xx_l3_main_2__des staticBen Dooks1-2/+2
The omap44xx_sha0_hwmod and omap44xx_l3_main_2__des objects are not exported so make them static to avoid the following warnings: arch/arm/mach-omap2/omap_hwmod_44xx_data.c:793:19: warning: symbol 'omap44xx_sha0_hwmod' was not declared. Should it be static? arch/arm/mach-omap2/omap_hwmod_44xx_data.c:977:26: warning: symbol 'omap44xx_l3_main_2__des' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: prm44xx: make prm_{save,restore}_context staticBen Dooks1-2/+2
The prm_{save,restore}_context functions are not exported so make them static to avoid the following warnings: arch/arm/mach-omap2/prm44xx.c:748:6: warning: symbol 'prm_save_context' was not declared. Should it be static? arch/arm/mach-omap2/prm44xx.c:759:6: warning: symbol 'prm_restore_context' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: make dra7xx_sha0_hwmod staticBen Dooks1-1/+1
The dra7xx_sha0_hwmod object is not exported outside of omap_hwmod_7xx_data. so make it static to avoid the following warning: arch/arm/mach-omap2/omap_hwmod_7xx_data.c:686:19: warning: symbol 'dra7xx_sha0_hwmod' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-21ARM: OMAP2+: do not export am43xx_control functionsBen Dooks1-2/+2
Do not export am43xx_control_{save,restore}_context to avoid the foloowing warnings: arch/arm/mach-omap2/control.c:687:6: warning: symbol 'am43xx_control_save_context' was not declared. Should it be static? arch/arm/mach-omap2/control.c:701:6: warning: symbol 'am43xx_control_restore_context' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-19MAINTAINERS: Add mailing list for Realtek SoCsAndreas Färber1-0/+1
Document linux-realtek-soc mailing list to be CC'ed on patches. Signed-off-by: Andreas Färber <afaerber@suse.de>
2019-10-18ARM: OMAP2+: Configure voltage controller for cpcap to low-speedTony Lindgren2-6/+14
Looks like the i2c timings in high-speed mode do not work properly to allow us to clear I2C_DISABLE bits for PRM_VOLTCTRL register and the device reboots if I2C_DISABLE bits are cleared. Let's configure the voltage controller i2c for low-speed mode as done in the Motorola Mapphone Android Linux kernel. This saves us about 7mW of power during retention compared to the high-speed values. Let's also change the low-speed warning to pr_info about relying on the bootloader configured low-speed values like we currently do. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-18ARM: OMAP2+: Configure voltage controller for retentionTony Lindgren2-4/+30
Similar to existing omap3_vc_set_pmic_signaling(), let's add omap4 specific omap4_vc_set_pmic_signaling(). This allows the configured devices to enable voltage controller for retention later on during init. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-18ARM: OMAP2+: Make some functions staticYueHaibing1-8/+8
Fix sparse warnings: arch/arm/mach-omap2/pmic-cpcap.c:29:15: warning: symbol 'omap_cpcap_vsel_to_uv' was not declared. Should it be static? arch/arm/mach-omap2/pmic-cpcap.c:43:15: warning: symbol 'omap_cpcap_uv_to_vsel' was not declared. Should it be static? arch/arm/mach-omap2/pmic-cpcap.c:93:15: warning: symbol 'omap_max8952_vsel_to_uv' was not declared. Should it be static? arch/arm/mach-omap2/pmic-cpcap.c:107:15: warning: symbol 'omap_max8952_uv_to_vsel' was not declared. Should it be static? arch/arm/mach-omap2/pmic-cpcap.c:140:15: warning: symbol 'omap_fan535503_vsel_to_uv' was not declared. Should it be static? arch/arm/mach-omap2/pmic-cpcap.c:155:15: warning: symbol 'omap_fan535508_vsel_to_uv' was not declared. Should it be static? arch/arm/mach-omap2/pmic-cpcap.c:173:15: warning: symbol 'omap_fan535503_uv_to_vsel' was not declared. Should it be static? arch/arm/mach-omap2/pmic-cpcap.c:192:15: warning: symbol 'omap_fan535508_uv_to_vsel' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-17MAINTAINERS: mmp: add Git repositoryLubomir Rintel1-0/+1
Add a tree that was set up for to stage the patches for Marvell MMP SoC support. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: remove MMP3 USB PHY registers from regs-usb.hLubomir Rintel1-94/+0
Nothing in mach-mmp/ uses them and they belong to the PHY driver. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: move cputype.h to include/linux/soc/Lubomir Rintel11-8/+10
Let's move cputype.h away from mach-mmp/ so that the drivers outside that directory are able to tell the precise silicon revision. The MMP3 USB OTG PHY driver needs this. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: add SMP supportLubomir Rintel2-0/+35
Used to bring up the second core on MMP3. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: add support for MMP3 SoCLubomir Rintel7-4/+85
Similar to MMP2, which this patch is based on. Known differencies from MMP2 are: * Two PJ4B cores instead of one PJ4 * Tauros 3 L2 cache controller instead of Tauros 2 * A GIC interrupt controller optionally used instead of the MMP one * A TWD local timer * Different USB2 PHY * A USB3 SS controller * More interrupt muxes Hard to tell what else is different, because documentation is not available. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: define MMP_CHIPID by the means of CIU_REG()Lubomir Rintel1-1/+1
A rather trivial cosmetic improvement. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: DT: convert timer driver to use TIMER_OF_DECLARELubomir Rintel3-33/+15
This makes things just a tiny bit simpler. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: map the PGU as wellLubomir Rintel4-1/+24
The MMP2 and later includes a system control unit in this area. We'll need that to initialize the secondary core on MMP3. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: mmp: don't select CACHE_TAUROS2 on all ARCH_MMPLubomir Rintel1-1/+1
MMP3 has a PJ4B with a Tauros 3 cache controller that uses CACHE_L2X0 instead, while CACHE_TAUROS2 is present on PJ4 and PJ1 (Mohawk) based platforms only. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-17ARM: l2c: add definition for FWA in PL310 aux registerLubomir Rintel1-0/+2
The PL310 also has a "Force write allocate" bits in the Auxiliary Control Register. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
2019-10-16ARM: bcm: fix missing __iomem in bcm_kona_smc.cBen Dooks1-1/+1
Fix the following sparse warnings from a missing __iomem in __bcm_kona_smc() function by adding __iomem attriubte. arch/arm/mach-bcm/bcm_kona_smc.c:143:21: warning: incorrect type in initializer (different address spaces) arch/arm/mach-bcm/bcm_kona_smc.c:143:21: expected unsigned int [usertype] *args arch/arm/mach-bcm/bcm_kona_smc.c:143:21: got void [noderef] <asn:2> *static [toplevel] [assigned] bcm_smc _buffer arch/arm/mach-bcm/bcm_kona_smc.c:149:9: warning: incorrect type in argument 2 (different address spaces) arch/arm/mach-bcm/bcm_kona_smc.c:149:9: expected void volatile [noderef] <asn:2> *addr arch/arm/mach-bcm/bcm_kona_smc.c:149:9: got unsigned int [usertype] * arch/arm/mach-bcm/bcm_kona_smc.c:150:9: warning: incorrect type in argument 2 (different address spaces) arch/arm/mach-bcm/bcm_kona_smc.c:150:9: expected void volatile [noderef] <asn:2> *addr arch/arm/mach-bcm/bcm_kona_smc.c:150:9: got unsigned int [usertype] * arch/arm/mach-bcm/bcm_kona_smc.c:151:9: warning: incorrect type in argument 2 (different address spaces) arch/arm/mach-bcm/bcm_kona_smc.c:151:9: expected void volatile [noderef] <asn:2> *addr arch/arm/mach-bcm/bcm_kona_smc.c:151:9: got unsigned int [usertype] * arch/arm/mach-bcm/bcm_kona_smc.c:152:9: warning: incorrect type in argument 2 (different address spaces) arch/arm/mach-bcm/bcm_kona_smc.c:152:9: expected void volatile [noderef] <asn:2> *addr arch/arm/mach-bcm/bcm_kona_smc.c:152:9: got unsigned int [usertype] *[assigned] args Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-16ARM: bcm: include local platsmp.h for bcm2836_smp_opsBen Dooks1-0/+2
Include platsmp.h for the definition of bcm2836_smp_ops to fix the following warning: arch/arm/mach-bcm/platsmp.c:334:29: warning: symbol 'bcm2836_smp_ops' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-16ARM: OMAP2+: Simplify code for clkdm_clock_enable and disableTony Lindgren1-58/+20
We can make clkdm_clk_enable() usable for clkdm_hwmod_enable() by dropping the unused clock check, and drop _clkdm_clk_hwmod_enable(). And we can make clkdm_hwmod_disable() call clkdm_hwmod_disable() and drop the duplicate code in clkdm_hwmod_disable(). Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Drop unused enable_wakeup and disable_wakeupTony Lindgren2-100/+0
We're only using static _enable_wakeup(), the others have no callers. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Initialize voltage controller for omap4Tony Lindgren1-0/+29
We're missing initializing the PRM_VOLTCTRL register for voltage controller. Let's add omap4_vc_init_pmic_signaling() similar to what we have for omap3 and enable voltage control for retention. This brings down droid4 power consumption with mainline kernel to somewhere between 40 and 50mW from about 70 to 80 mW for the whole device when running idle with LCD and backlight off, WLAN connected, and USB and modem modules unloaded. Mostly just rmmod of omap2430, ohci-platform and phy-mapphone-mdm6600 are needed to idle USB and shut down the modem. And after that measuring idle power consumption can be done with reading sysfs entry periodically for /sys/class/power_supply/battery/power_avg. Then rmmod of phy-cpcap-usb will save few more mW, but will disable the debug UART. Note that sometimes CM_L4PER_UART1_CLKCTRL at 0x4a009540 does not idle properly after unloading of phy-mapphone-mdm6600. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Allow core oswr for omap4Tony Lindgren1-12/+2
Commit f74297dd9354 ("ARM: OMAP2+: Make sure LOGICRETSTATE bits are not cleared") disabled oswr (open switch retention) for per and core domains as various GPIO related issues were noticed if the bootloader had configured the bits for LOGICRETSTATE for per and core domains. With the recent gpio-omap fixes, mostly related to commit e6818d29ea15 ("gpio: gpio-omap: configure edge detection for level IRQs for idle wakeup"), things now behave for enabling core oswr for omap4. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Allow per oswr for omap4Tony Lindgren1-2/+4
Commit f74297dd9354 ("ARM: OMAP2+: Make sure LOGICRETSTATE bits are not cleared") disabled oswr (open switch retention) for per and core domains as various GPIO related issues were noticed if the bootloader had configured the bits for LOGICRETSTATE for per and core domains. With the recent gpio-omap fixes, mostly related to commit e6818d29ea15 ("gpio: gpio-omap: configure edge detection for level IRQs for idle wakeup"), things now behave for enabling per oswr for omap4. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Configure voltage controller for cpcapTony Lindgren5-5/+285
We can configure voltage controller for cpcap with the data available in Motorola Mapphone Android Linux kernel. Let's add it so we can have droid4 behave the same way for voltage controller as other omap4 devices and save some power when idle. Note that we're now using high-speed i2c mode, looks like the Motorola kernel had a typo using 0x200 instead of 200 for the timings which may caused it to not work properly. Also note that in the long run, this should just become dts data for a voltage controller device driver. But let's get things working first to make it possible to test further changes easily. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Update 4430 voltage controller operating pointsTony Lindgren2-7/+10
The current operating points in the mainline kernel are out of date for at least omap4430. Let's use the values from Motorola Mapphone Linux Android kernel as presumably those have been verified. Note that these are only used by voltage controller, they do not enable any new operating points for cpufreq. Looking at the recent omap3 cpufreq related patches posted, that's a totally separate series of patches. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Remove bogus warnings for machines without twl PMICTony Lindgren1-1/+2
In general we want to see a quiet dmesg output with no errors or warnings unless something is really wrong and needs attention. We currently see these bogus warnings on boot: twl: not initialized twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 ... Let's avoid these by checking if a device tree node for cpcap PMIC exists. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Drop bogus wkup domain oswr settingTony Lindgren1-2/+1
The wkup domain is always on and does not have logic off setting. This got accidentally added by commit f74297dd9354 ("ARM: OMAP2+: Make sure LOGICRETSTATE bits are not cleared") but is harmless. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-16ARM: OMAP2+: Remove unused wakeup_cpuTony Lindgren1-2/+0
After commit 32d174ed1bd7 ("ARM: OMAP4: MPUSS PM: remove unnecessary shim functions for powerdomain control") this is no longer used. The code continues execution after context restore on the same CPU, so we can just use pm_info->pwrdm. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-10ARM: bcm: Add support for BCM2711 SoCStefan Wahren4-4/+32
Add the BCM2711 to ARCH_BCM2835, but use new machine board code because of the differences. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Florian Fanelli <f.fainelli@gmail.com>
2019-10-09ARM: dts: Use level interrupt for omap4 & 5 wlcoreTony Lindgren5-5/+5
Commit 572cf7d7b07d ("ARM: dts: Improve omap l4per idling with wlcore edge sensitive interrupt") changed wlcore interrupts to use edge interrupt based on what's specified in the wl1835mod.pdf data sheet. However, there are still cases where we can have lost interrupts as described in omap_gpio_unidle(). And using a level interrupt instead of edge interrupt helps as we avoid the check for untriggered GPIO interrupts in omap_gpio_unidle(). And with commit e6818d29ea15 ("gpio: gpio-omap: configure edge detection for level IRQs for idle wakeup") GPIOs idle just fine with level interrupts. Let's change omap4 and 5 wlcore users back to using level interrupt instead of edge interrupt. Let's not change the others as I've only seen this on omap4 and 5, probably because the other SoCs don't have l4per idle independent of the CPUs. Fixes: 572cf7d7b07d ("ARM: dts: Improve omap l4per idling with wlcore edge sensitive interrupt") Depends-on: e6818d29ea15 ("gpio: gpio-omap: configure edge detection for level IRQs for idle wakeup") Cc: Anders Roxell <anders.roxell@linaro.org> Cc: Eyal Reizer <eyalr@ti.com> Cc: Guy Mishol <guym@ti.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-08ARM: dts: am3874-iceboard: Fix 'i2c-mux-idle-disconnect' usageAndrey Smirnov1-8/+1
According to Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt, i2c-mux-idle-disconnect is a property of a parent node since it pertains to the mux/switch as a whole, so move it there and drop all of the concurrences in child nodes. Fixes: d031773169df ("ARM: dts: Adds device tree file for McGill's IceBoard, based on TI AM3874") Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Benoît Cousson <bcousson@baylibre.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Graeme Smecher <gsmecher@threespeedlogic.com> Cc: linux-omap@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Tested-by: Graeme Smecher <gsmecher@threespeedlogic.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-08ARM: dts: omap5: fix gpu_cm clock provider nameTero Kristo1-1/+1
The clkctrl code searches for the parent clockdomain based on the name of the CM provider node. The introduction of SGX node for omap5 made the node name for the gpu_cm to be clock-controller. There is no clockdomain named like this, so the lookup fails. Fix by changing the node name properly. Fixes: 394534cb07d8 ("ARM: dts: Configure sgx for omap5") Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-06Linux 5.4-rc2Linus Torvalds1-2/+2
2019-10-06elf: don't use MAP_FIXED_NOREPLACE for elf executable mappingsLinus Torvalds1-10/+3
In commit 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") we changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the executable mappings. Then, people reported that it broke some binaries that had overlapping segments from the same file, and commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some overlaying elf segment cases. But only some - despite the summary line of that commit, it only did it when it also does a temporary brk vma for one obvious overlapping case. Now Russell King reports another overlapping case with old 32-bit x86 binaries, which doesn't trigger that limited case. End result: we had better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED. Yes, it's a sign of old binaries generated with old tool-chains, but we do pride ourselves on not breaking existing setups. This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp() and the old load_elf_library() use-cases, because nobody has reported breakage for those. Yet. Note that in all the cases seen so far, the overlapping elf sections seem to be just re-mapping of the same executable with different section attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE flag or similar, which acts like NOREPLACE, but allows just remapping the same executable file using different protection flags. It's not clear that would make a huge difference to anything, but if people really hate that "elf remaps over previous maps" behavior, maybe at least a more limited form of remapping would alleviate some concerns. Alternatively, we should take a look at our elf_map() logic to see if we end up not mapping things properly the first time. In the meantime, this is the minimal "don't do that then" patch while people hopefully think about it more. Reported-by: Russell King <linux@armlinux.org.uk> Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") Fixes: ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments") Cc: Michal Hocko <mhocko@suse.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>