aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/exported-sql-viewer.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-10-25ARM: dts: stm32: relax qspi pins slew-rate for stm32mp157Patrice Chotard1-4/+4
Relax qspi pins slew-rate to minimize peak currents. Fixes: 844030057339 ("ARM: dts: stm32: add flash nor support on stm32mp157c eval board") Link: https://lore.kernel.org/r/20191025130122.11407-1-alexandre.torgue@st.com Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-24reset: fix reset_control_get_exclusive kerneldoc commentPhilipp Zabel1-1/+1
Add missing parentheses to correctly hyperlink the reference to reset_control_get_shared(). Fixes: 0b52297f2288 ("reset: Add support for shared reset controls") Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-24reset: fix reset_control_lookup kerneldoc commentPhilipp Zabel1-1/+1
Add a missing colon to fix a documentation build warning: ./include/linux/reset-controller.h:45: warning: Function parameter or member 'con_id' not described in 'reset_control_lookup' Fixes: 6691dffab0ab ("reset: add support for non-DT systems") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-24reset: fix of_reset_control_get_count kerneldoc commentPhilipp Zabel1-1/+2
Add a newline and remove a superfluous kerneldoc marker before the of_reset_control_get_count kerneldoc comment, to fix documentation build warnings: ./drivers/reset/core.c:832: warning: Incorrect use of kernel-doc format: * of_reset_control_get_count - Count number of resets available with a device ./drivers/reset/core.c:840: warning: Function parameter or member 'node' not described in 'of_reset_control_get_count' Fixes: 17c82e206d2a ("reset: Add APIs to manage array of resets") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-24reset: fix of_reset_simple_xlate kerneldoc commentPhilipp Zabel1-1/+0
The flags parameter never made it into the API, but was erroneously included in the kerneldoc comment. Remove it to fix a documentation build warning: ./drivers/reset/core.c:86: warning: Excess function parameter 'flags' description in 'of_reset_simple_xlate' Fixes: 61fc41317666 ("reset: Add reset controller API") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-23MAINTAINERS: Update the Spreadtrum SoC maintainerBaolin Wang1-1/+3
Change my email address, and add more Spreadtrum SC27xx series PMIC drivers to maintain. Link: https://lore.kernel.org/r/a48483d13243450ecf3b777d49e741b6367f2c6b.1571881956.git.baolin.wang@linaro.org Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-23MAINTAINERS: Remove Gregory and Brian for ARCH_BRCMSTBFlorian Fainelli1-2/+0
The last time Gregory and Brian did a review was sometime around 2015, since then, they have not been active for ARCH_BRCMSTB changes. Following the position of other maintainers and Harald Welte's position here: [1] http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/ remove both of them. Acked-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-22reset: Fix memory leak in reset_control_array_put()Kishon Vijay Abraham I1-0/+1
Memory allocated for 'struct reset_control_array' in of_reset_control_array_get() is never freed in reset_control_array_put() resulting in kmemleak showing the following backtrace. backtrace: [<00000000c5f17595>] __kmalloc+0x1b0/0x2b0 [<00000000bd499e13>] of_reset_control_array_get+0xa4/0x180 [<000000004cc02754>] 0xffff800008c669e4 [<0000000050a83b24>] platform_drv_probe+0x50/0xa0 [<00000000d3a0b0bc>] really_probe+0x108/0x348 [<000000005aa458ac>] driver_probe_device+0x58/0x100 [<000000008853626c>] device_driver_attach+0x6c/0x90 [<0000000085308d19>] __driver_attach+0x84/0xc8 [<00000000080d35f2>] bus_for_each_dev+0x74/0xc8 [<00000000dd7f015b>] driver_attach+0x20/0x28 [<00000000923ba6e6>] bus_add_driver+0x148/0x1f0 [<0000000061473b66>] driver_register+0x60/0x110 [<00000000c5bec167>] __platform_driver_register+0x40/0x48 [<000000007c764b4f>] 0xffff800008c6c020 [<0000000047ec2e8c>] do_one_initcall+0x5c/0x1b0 [<0000000093d4b50d>] do_init_module+0x54/0x1d0 Fixes: 17c82e206d2a ("reset: Add APIs to manage array of resets") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-18ARM: dts: bcm2837-rpi-cm3: Avoid leds-gpio probing issueStefan Wahren1-0/+8
bcm2835-rpi.dtsi defines the behavior of the ACT LED, which is available on all Raspberry Pi boards. But there is no driver for this particual GPIO on CM3 in mainline yet, so this node was left incomplete without the actual GPIO definition. Since commit 025bf37725f1 ("gpio: Fix return value mismatch of function gpiod_get_from_of_node()") this causing probe issues of the leds-gpio driver for users of the CM3 dtsi file. leds-gpio: probe of leds failed with error -2 Until we have the necessary GPIO driver hide the ACT node for CM3 to avoid this. Reported-by: Fredrik Yhlen <fredrik.yhlen@endian.se> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board") Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-18bus: ti-sysc: Fix watchdog quirk handlingTony Lindgren1-4/+14
I noticed that when probed with ti-sysc, watchdog can trigger on am3, am4 and dra7 causing a device reset. Turns out I made several mistakes implementing the watchdog quirk handling: 1. We must do both writes to spr register 2. We must also call the reset quirk on disable 3. On am3 and am4 we need to also set swsup quirk flag I probably only tested this earlier with watchdog service running when the watchdog never gets disabled. Fixes: 4e23be473e30 ("bus: ti-sysc: Add support for module specific reset quirks") Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-18ARM: OMAP2+: Add pdata for OMAP3 ISP IOMMUSuman Anna1-0/+7
The OMAP3 ISP IOMMU does not have any reset lines, so it didn't need any pdata previously. The OMAP IOMMU driver now requires the platform data ops for device_enable/idle on all the IOMMU devices after commit db8918f61d51 ("iommu/omap: streamline enable/disable through runtime pm callbacks") to enable/disable the clocks properly and maintain the reference count and the omap_hwmod state machine. So, add these callbacks through iommu pdata quirks for the OMAP3 ISP IOMMU. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-18ARM: OMAP2+: Plug in device_enable/idle ops for IOMMUsSuman Anna1-0/+4
The OMAP IOMMU driver requires the device_enable/idle platform data ops on all the IOMMU devices to be able to enable and disable the clocks after commit db8918f61d51 ("iommu/omap: streamline enable/disable through runtime pm callbacks"). Plug in these pdata ops for all the existing IOMMUs through pdata quirks to maintain functionality. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-17ARM: davinci_all_defconfig: enable GPIO backlightBartosz Golaszewski1-0/+1
DA850 EVM has been converted to use GPIO backlight device for display backlight GPIO control. Enable the GPIO backlight module in davinci_all_defconfig to keep backlight support working. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [nsekhar@ti.com: edits to commit message for context] Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-10-17ARM: davinci: dm365: Fix McBSP dma_slave_map entryPeter Ujfalusi1-2/+2
dm365 have only single McBSP, so the device name is without .0 Fixes: 0c750e1fe481d ("ARM: davinci: dm365: Add dma_slave_map to edma") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-10-15ARM: dts: bcm2835-rpi-zero-w: Fix bus-width of sdhciStefan Wahren1-0/+1
The commit e7774049ff25 ("ARM: dts: bcm283x: Define MMC interfaces at board level") accidently dropped the bus width for the sdhci on the RPi Zero W, because the board file was relying on the defaults from bcm2835-rpi.dtsi. So fix this performance regression by adding the bus width to the board file. Fixes: e7774049ff25 ("ARM: dts: bcm283x: Define MMC interfaces at board level") Reported-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-14ARM: imx_v6_v7_defconfig: Enable CONFIG_DRM_MSMFabio Estevam1-0/+1
Since commit 2eba69071b4b ("drm/msm: Remove Kconfig default") the CONFIG_DRM_MSM option is no longer selected by default on i.MX5. Explicitly select CONFIG_DRM_MSM so that we can get GPU support by default on i.MX51 and i.MX53. Fixes: 2eba69071b4b ("drm/msm: Remove Kconfig default") Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-14arm64: dts: imx8mn: Use correct clock for usdhc's ipg clkAnson Huang1-3/+3
On i.MX8MN, usdhc's ipg clock is from IMX8MN_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MN_CLK_DUMMY. Fixes: 6c3debcbae47 ("arm64: dts: freescale: Add i.MX8MN dtsi support") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-14arm64: dts: imx8mm: Use correct clock for usdhc's ipg clkAnson Huang1-3/+3
On i.MX8MM, usdhc's ipg clock is from IMX8MM_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MM_CLK_DUMMY. Fixes: a05ea40eb384 ("arm64: dts: imx: Add i.mx8mm dtsi support") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-14arm64: dts: imx8mq: Use correct clock for usdhc's ipg clkAnson Huang1-2/+2
On i.MX8MQ, usdhc's ipg clock is from IMX8MQ_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MQ_CLK_DUMMY. Fixes: 748f908cc882 ("arm64: add basic DTS for i.MX8MQ") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-14ARM: dts: imx7s: Correct GPT's ipg clock sourceAnson Huang1-4/+4
i.MX7S/D's GPT ipg clock should be from GPT clock root and controlled by CCM's GPT CCGR, using correct clock source for GPT ipg clock instead of IMX7D_CLK_DUMMY. Fixes: 3ef79ca6bd1d ("ARM: dts: imx7d: use imx7s.dtsi as base device tree") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-14ARM: dts: vf610-zii-scu4-aib: Specify 'i2c-mux-idle-disconnect'Andrey Smirnov1-0/+2
Specify 'i2c-mux-idle-disconnect' for both I2C switches present on the board, since both are connected to the same parent bus and all of their children have the same I2C address. Fixes: ca4b4d373fcc ("ARM: dts: vf610: Add ZII SCU4 AIB board") Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Chris Healy <cphealy@gmail.com> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Jeff White <jeff.white@zii.aero> Cc: Rick Ramstetter <rick@anteaterllc.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Tested-by: Chris Healy <cphealy@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-14ARM: dts: imx6q-logicpd: Re-Enable SNVS power keyAdam Ford1-0/+4
A previous patch disabled the SNVS power key by default which breaks the ability for the imx6q-logicpd board to wake from sleep. This patch re-enables this feature for this board. Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to board design") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-14arm64: dts: lx2160a: Correct CPU core idle state nameRan Wang1-18/+18
lx2160a support PW15 but not PW20, correct name to avoid confusing. Signed-off-by: Ran Wang <ran.wang_1@nxp.com> Fixes: 00c5ce8ac023 ("arm64: dts: lx2160a: add cpu idle support") Acked-by: Li Yang <leoyang.li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-12mailmap: Add Simon Arlott (replacement for expired email address)Simon Arlott1-0/+1
Add replacement email address for the one on my expired domain. Signed-off-by: Simon Arlott <simon@octiron.net> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
2019-10-10arm64: dts: rockchip: Fix override mode for rk3399-kevin panelDouglas Anderson1-1/+1
When I re-posted Sean's original commit to add the override mode for the kevin panel, for some reason I didn't notice that the pixel clock wasn't quite right. Looking at /sys/kernel/debug/clk/clk_summary on downstream kernels it can be seen that the VOP clock is supposed to be 266,666,667 Hz achieved by dividing the 800 MHz PLL by 3. Looking at history, it seems that even Sean's first patch [1] had this funny clock rate. I'm not sure where it came from since the commit message specifically mentioned 26666 kHz and the Chrome OS tree [2] can be seen to request 266667 kHz. In any case, let's fix it up. This together with my patch [3] to do the proper rounding when setting the clock rate makes the VOP clock more proper as seen in /sys/kernel/debug/clk/clk_summary. [1] https://lore.kernel.org/r/20180206165626.37692-4-seanpaul@chromium.org [2] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/panel/panel-simple.c#1172 [3] https://lkml.kernel.org/r/20191003114726.v2.1.Ib233b3e706cf6317858384264d5b0ed35657456e@changeid Fixes: 84ebd2da6d04 ("arm64: dts: rockchip: Specify override mode for kevin panel") Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20191008124949.1.I674acd441997dd0690c86c9003743aacda1cf5dd@changeid Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-10arm64: dts: rockchip: Fix usb-c on Hugsun X99 TV BoxVivek Unune1-2/+2
Fix usb-c on X99 TV Box. Tested with armbian w/ kernel 5.3 Signed-off-by: Vivek Unune <npcomplete13@gmail.com> Link: https://lore.kernel.org/r/20190929032230.24628-1-npcomplete13@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-10arm64: dts: rockchip: fix RockPro64 sdmmc settingsSoeren Moch1-1/+0
According to the RockPro64 schematic [1] the rk3399 sdmmc controller is connected to a microSD (TF card) slot. Remove the cap-mmc-highspeed property of the sdmmc controller, since no mmc card can be connected here. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Soeren Moch <smoch@web.de> Link: https://lore.kernel.org/r/20191004203213.4995-1-smoch@web.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-10MAINTAINERS: Add BCM2711 to BCM2835 ARCHStefan Wahren1-1/+2
Clarify that BCM2711 belongs to the BCM2835 ARCH. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Eric Anholt <eric@anholt.net>
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-09arm64: dts: armada-3720-turris-mox: convert usb-phy to phy-supplyMarek Behún1-6/+7
Update Turris Mox device tree to use the phy-supply property of the generic PHY framework instead of the legacy usb-phy property. This is needed since it caused a regression on Turris Mox since "usb: host: xhci-plat: Prevent an abnormally restrictive PHY init skipping". Signed-off-by: Marek Behún <marek.behun@nic.cz> Fixes: eb6c2eb6c7fb ("usb: host: xhci-plat: Prevent an abnormally restrictive PHY init skipping") Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.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-07ARM: dts: sun7i: Drop the module clock from the device treeMaxime Ripard1-3/+2
What we thought would be the module clock is actually the clock meant to be used by the sensors, and play no role in the CSI controller. Now that the binding has been updated to reflect that, let's update the device tree too. Fixes: d2b9c6444301 ("ARM: dts: sun7i: Add CSI0 controller") Reported-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-10-07dt-bindings: media: sun4i-csi: Drop the module clockMaxime Ripard1-5/+2
It turns out that what was thought to be the module clock was actually the clock meant to be used by the sensor, and isn't playing any role with the CSI controller itself. Let's drop that clock from our binding. Fixes: c5e8f4ccd775 ("media: dt-bindings: media: Add Allwinner A10 CSI binding") Reported-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-10-07media: dt-bindings: Fix building error for dt_binding_checkPragnesh Patel1-1/+1
$id doesn't match the actual filename, so update the $id Fixes: c5e8f4ccd7750 ("media: dt-bindings: media: Add Allwinner A10 CSI binding") Signed-off-by: Pragnesh Patel <pragnesh.patel@sifive.com> Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-10-06arm64: dts: zii-ultra: fix ARM regulator statesLucas Stach1-2/+2
The GPIO controlled regulator for the ARM power supply is supplying the higher voltage when the GPIO is driven high. This is opposite to the similar regulator setup on the EVK board and is impacting stability of the board as the ARM domain has been supplied with a too low voltage when to faster OPPs are in use. Fixes: 4a13b3bec3b4 (arm64: dts: imx: add Zii Ultra board support) Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-06soc: imx: imx-scu: Getting UID from SCU should have responseAnson Huang1-1/+1
The SCU firmware API for getting UID should have response, otherwise, the message stored in function stack could be released and then the response data received from SCU will be stored into that released stack and cause kernel NULL pointer dump. Fixes: 73feb4d0f8f1 ("soc: imx-scu: Add SoC UID(unique identifier) support") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-10-04arm64: dts: rockchip: fix RockPro64 sdhci settingsSoeren Moch1-2/+1
The RockPro64 schematics [1], [2] show that the rk3399 EMMC_STRB pin is connected to the RESET pin instead of the DATA_STROBE pin of the eMMC module. So the data strobe cannot be used for its intended purpose on this board, and so the HS400 eMMC mode is not functional. Limit the controller to HS200. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] http://files.pine64.org/doc/rock64/PINE64_eMMC_Module_20170719.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Soeren Moch <smoch@web.de> Link: https://lore.kernel.org/r/20191003215036.15023-2-smoch@web.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-04arm64: dts: rockchip: fix RockPro64 vdd-log regulator settingsSoeren Moch1-1/+1
The RockPro64 schematic [1] page 18 states a min voltage of 0.8V and a max voltage of 1.4V for the VDD_LOG pwm regulator. However, there is an additional note that the pwm parameter needs to be modified. From the schematics a voltage range of 0.8V to 1.7V can be calculated. Additional voltage measurements on the board show that this fix indeed leads to the correct voltage, while without this fix the voltage was set too high. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Soeren Moch <smoch@web.de> Link: https://lore.kernel.org/r/20191003215036.15023-1-smoch@web.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-04ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI supportPatrice Chotard1-1/+1
SPI_STM32_QSPI must be set in buildin as rootfs can be located on QSPI memory device. Link: https://lore.kernel.org/r/20191004124025.17394-1-patrice.chotard@st.com Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-04ARM: dts: logicpd-torpedo-som: Remove twl_keypadAdam Ford1-0/+4
The TWL4030 used on the Logit PD Torpedo SOM does not have the keypad pins routed. This patch disables the twl_keypad driver to remove some splat during boot: twl4030_keypad 48070000.i2c:twl@48:keypad: missing or malformed property linux,keymap: -22 twl4030_keypad 48070000.i2c:twl@48:keypad: Failed to build keymap twl4030_keypad: probe of 48070000.i2c:twl@48:keypad failed with error -22 Signed-off-by: Adam Ford <aford173@gmail.com> [tony@atomide.com: removed error time stamps] Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-04dt-bindings: arm: rockchip: fix Theobroma-System board bindingsHeiko Stuebner1-2/+2
The naming convention for the existing Theobroma boards is soc-q7module-baseboard, so rk3399-puma-haikou and the in-kernel devicetrees also follow that scheme. For some reason in the binding a wrong or outdated naming slipped in which does not match the used devicetrees and makes the dt-schema complain now. Fix this by using the names used in the wild by actual boards. Fixes: a323a513c712 ("dt-bindings: arm: Convert Rockchip board/soc bindings to json-schema") [although the issue was also present in the old txt file] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20190917083453.25744-1-heiko@sntech.de
2019-10-04arm64: dts: rockchip: fix Rockpro64 RK808 interrupt lineHugh Cole-Baker1-3/+3
Fix the pinctrl and interrupt specifier for RK808 to use GPIO3_B2. On the Rockpro64 schematic [1] page 16, it shows GPIO3_B2 used for the interrupt line PMIC_INT_L from the RK808, and there's a note which translates as: "PMU termination GPIO1_C5 changed to this". Tested by setting an RTC wakealarm and checking /proc/interrupts counters. Without this patch, neither the rockchip_gpio_irq counter for the RK808, nor the RTC alarm counter increment when the alarm time is reached. With this patch, both interrupt counters increment by 1 as expected. [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com> Link: https://lore.kernel.org/r/20190921131457.36258-1-sigmaris@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-03ARM: omap2plus_defconfig: Fix selected panels after generic panel changesTony Lindgren1-6/+6
The old omapdrm panels got removed for v5.4 in favor of generic panels, and the Kconfig options changed. Let's update omap2plus_defconfig accordingly so the same panels are still enabled. Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-01ARM: dts: ux500: Fix up the CPU thermal zoneLinus Walleij1-3/+8
This fixes up the default ux500 CPU thermal zone: - Set polling delay to 0 and explain why - Set passive polling delay to 250 - Remove restrictions from the CPU cooling device, we should use all cpufreq steps to cool down if needed. Link: https://lore.kernel.org/r/20191001074628.8122-1-linus.walleij@linaro.org Fixes: b786a05f6ce4 ("ARM: dts: ux500: Update thermal zone") Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-09-30arm64: dts: Fix gpio to pinmux mappingRayagonda Kokatanur2-4/+4
There are total of 151 non-secure gpio (0-150) and four pins of pinmux (91, 92, 93 and 94) are not mapped to any gpio pin, hence update same in DT. Fixes: 8aa428cc1e2e ("arm64: dts: Add pinctrl DT nodes for Stingray SOC") Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-09-30arm64: dts: allwinner: a64: sopine-baseboard: Add PHY regulator delayJernej Skrabec1-0/+6
It turns out that sopine-baseboard needs same fix as pine64-plus for ethernet PHY. Here too Realtek ethernet PHY chip needs additional power on delay to properly initialize. Datasheet mentions that chip needs 30 ms to be properly powered on and that it needs some more time to be initialized. Fix that by adding 100ms ramp delay to regulator responsible for powering PHY. Note that issue was found out and fix tested on pine64-lts, but it's basically the same as sopine-baseboard, only layout and connectors differ. Fixes: bdfe4cebea11 ("arm64: allwinner: a64: add Ethernet PHY regulator for several boards") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-09-30arm64: dts: allwinner: a64: Drop PMU nodeVasily Khoruzhick1-9/+0
Looks like PMU in A64 is broken, it generates no interrupts at all and as result 'perf top' shows no events. Tested on Pine64-LTS. Fixes: 34a97fcc71c2 ("arm64: dts: allwinner: a64: Add PMU node") Cc: Harald Geyer <harald@ccbib.org> Cc: Jared D. McNeill <jmcneill@NetBSD.org> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org> Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-09-30arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delayJernej Skrabec1-0/+9
Depending on kernel and bootloader configuration, it's possible that Realtek ethernet PHY isn't powered on properly. According to the datasheet, it needs 30ms to power up and then some more time before it can be used. Fix that by adding 100ms ramp delay to regulator responsible for powering PHY. Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i") Suggested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-09-30arm64/ARM: configs: Change CONFIG_REMOTEPROC from m to yKeerthy4-4/+4
Commit 6334150e9a36 ("remoteproc: don't allow modular build") changes CONFIG_REMOTEPROC to a boolean from a tristate config option which inhibits all defconfigs marking CONFIG_REMOTEPROC as a module in compiling the remoteproc and dependent config options. So fix the configs to have CONFIG_REMOTEPROC built in. Link: https://lore.kernel.org/r/20190920075946.13282-5-j-keerthy@ti.com Fixes: 6334150e9a36 ("remoteproc: don't allow modular build") Signed-off-by: Keerthy <j-keerthy@ti.com> Acked-by: Will Deacon <will@kernel.org> [olof: Fixed up all 4 occurrances in this one commit] Signed-off-by: Olof Johansson <olof@lixom.net>