summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)AuthorFilesLines
2020-09-18arch_topology, arm, arm64: define arch_scale_freq_invariant()Valentin Schneider1-0/+1
arch_scale_freq_invariant() is used by schedutil to determine whether the scheduler's load-tracking signals are frequency invariant. Its definition is overridable, though by default it is hardcoded to 'true' if arch_scale_freq_capacity() is defined ('false' otherwise). This behaviour is not overridden on arm, arm64 and other users of the generic arch topology driver, which is somewhat precarious: arch_scale_freq_capacity() will always be defined, yet not all cpufreq drivers are guaranteed to drive the frequency invariance scale factor setting. In other words, the load-tracking signals may very well *not* be frequency invariant. Now that cpufreq can be queried on whether the current driver is driving the Frequency Invariance (FI) scale setting, the current situation can be improved. This combines the query of whether cpufreq supports the setting of the frequency scale factor, with whether all online CPUs are counter-based FI enabled. While cpufreq FI enablement applies at system level, for all CPUs, counter-based FI support could also be used for only a subset of CPUs to set the invariance scale factor. Therefore, if cpufreq-based FI support is present, we consider the system to be invariant. If missing, we require all online CPUs to be counter-based FI enabled in order for the full system to be considered invariant. If the system ends up not being invariant, a new condition is needed in the counter initialization code that disables all scale factor setting based on counters. Precedence of counters over cpufreq use is not important here. The invariant status is only given to the system if all CPUs have at least one method of setting the frequency scale factor. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-18arm: Move ipi_teardown() to a CONFIG_HOTPLUG_CPU sectionMarc Zyngier1-12/+11
ipi_teardown() is only used when CONFIG_HOTPLUG_CPU is enabled. Move the function to a location guarded by this config option. Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-09-17dma-mapping: introduce DMA range map, supplanting dma_pfn_offsetJim Quinlan3-14/+16
The new field 'dma_range_map' in struct device is used to facilitate the use of single or multiple offsets between mapping regions of cpu addrs and dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only capable of holding a single uniform offset and had no region bounds checking. The function of_dma_get_range() has been modified so that it takes a single argument -- the device node -- and returns a map, NULL, or an error code. The map is an array that holds the information regarding the DMA regions. Each range entry contains the address offset, the cpu_start address, the dma_start address, and the size of the region. of_dma_configure() is the typical manner to set range offsets but there are a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel driver code. These cases now invoke the function dma_direct_set_offset(dev, cpu_addr, dma_addr, size). Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> [hch: various interface cleanups] Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
2020-09-17ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAEChristoph Hellwig1-0/+4
The DMA offset notifier can only be used if PHYS_OFFSET is at least KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit phys_addr_t. Currently the code compiles fine despite that, a pending change to the DMA offset handling would create a compiler warning for this case. Add an ifdef to not compile the code except for LPAE configs. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2020-09-17ARM/dma-mapping: move various helpers from dma-mapping.h to dma-direct.hChristoph Hellwig3-51/+51
Move the helpers to translate to and from direct mapping DMA addresses to dma-direct.h. This not only is the most logical place, but the new placement also avoids dependency loops with pending commits. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
2020-09-17ARM/dma-mapping: remove dma_to_virtChristoph Hellwig2-21/+1
dma_to_virt is entirely unused, remove it. Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-09-17ARM/dma-mapping: remove a __arch_page_to_dma #errorChristoph Hellwig1-4/+0
The __arch_page_to_dma hook is long gone. Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-09-17ARM: dts: sun8i: v3s: Enable crypto engineMartin Cerveny1-0/+11
V3s contains crypto engine that is compatible with A33. Add device tree node. Signed-off-by: Martin Cerveny <m.cerveny@computer.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200907162458.23730-3-m.cerveny@computer.org
2020-09-17ARM: dts: sun8i: a33: Update codec widget namesSamuel Holland2-4/+4
The sun8i-codec driver introduced a new set of DAPM widgets that more accurately describe the hardware topology. Update the various device trees to use the new widget names. Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200726012557.38282-6-samuel@sholland.org
2020-09-17ARM: dts: sun8i: r40: Add video engine nodeJernej Skrabec1-0/+11
Allwinner R40 SoC has a video engine. Add a node for it. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200825173523.1289379-6-jernej.skrabec@siol.net
2020-09-17ARM: tegra: nexus7: Add SMB347 battery chargerDavid Heidelberg1-1/+23
SMB347 is a battery charger controller which is found on the Nexus 7 device. Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: nexus7: Add touchscreenDmitry Osipenko1-0/+18
Nexus 7 2012 has Elantech EKTF3624 touchscreen, this patch adds TS node to the device-tree. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: nexus7: Use PLLC for WiFi MMC clock parentDmitry Osipenko1-0/+5
The default parent for all MMCs is PLLP, which is running at 408 MHz on Tegra30 and 50 MHz clock can't be derived from PLLP. The maximum SDIO clock rate is 50 MHz, but this rate isn't achievable using PLLP. Let's switch the WiFi MMC clock parent to PLLC in order to get true 50 MHz. This patch doesn't fix any problems, it's just a minor improvement. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: acer-a500: Use PLLC for WiFi MMC clock parentDmitry Osipenko1-0/+4
The default parent for all MMCs is PLLP, which is running at 216 MHz on Tegra20 and 50 MHz clock can't be derived from PLLP. The maximum SDIO clock rate is 50 MHz, but this rate isn't achievable using PLLP. Let's switch the WiFi MMC clock parent to PLLC in order to get true 50 MHz. This patch doesn't fix any problems, it's just a minor improvement. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: acer-a500: Set WiFi MMC clock rate to 50 MHzDmitry Osipenko1-1/+1
Previously 50MHz clock rate didn't work because of the wrong PINCTRL configuration used for SDIO pins. Now the PINCTRL config is corrected and the MMC clock rate could be bumped safely to 50MHz, increasing WiFi TX throughput by 20 Mbit/s and allowing to hit the maximum 40 Mbit/s. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: acer-a500: Correct PINCTRL configurationDmitry Osipenko1-2/+10
The low-power-mode drive was set to DIV_4 for some of PINCTRL groups, while these groups should use DIV_1. This patch fixes the wrong PINCTRL configurations and adds a full drive-setup for the changed configs, just for completeness since the added values match the default configuration. Now WiFi SDIO communication works properly using legacy signaling mode if SDIO BUS clocked at 50MHz, which is a maximum SDIO clock rate on Tegra20. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: acer-a500: Remove atmel,cfg_name propertyDmitry Osipenko1-2/+0
This property was supposed to be upstreamed, but it was NAKed recently in a favor to a better approach of firmware loading. It also turned out that the firmware loading isn't really necessary because it's stored in a non-volatile memory inside of the touchscreen controller and previously the FW loading was needed in order to get touchscreen working, but it actually was a TS driver problem which is resolved now. Hence remove the unsupported property. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: acer-a500: Add aliases for MMCDmitry Osipenko1-3/+7
MMC core now supports binding to a specific ID, which is very handy for embedded devices, like Acer A500, because MMC ID may change depending on kernel version or configuration which affects MMC driver probe order. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: tegra: nexus7: Add aliases for MMCDmitry Osipenko1-2/+5
MMC core now supports binding to a specific ID, which is very handy for embedded devices, like Nexus 7, because MMC ID may change depending on kernel version or configuration which affects MMC driver probe order. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-09-17ARM: Remove custom IRQ stat accountingMarc Zyngier3-34/+5
Let's switch the arm code to the core accounting, which already does everything we need. Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-09-17ARM: Kill __smp_cross_call and coMarc Zyngier2-25/+7
The old IPI registration interface is now unused on arm, so let's get rid of it. Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2020-09-16ARM: s3c64xx: bring back notes from removed debug-macro.SKrzysztof Kozlowski1-1/+6
Documentation references notes from a removed debug-macro.S file so bring the contents here. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200911143343.498-3-krzk@kernel.org
2020-09-16ARM: dts: s5pv210: replace deprecated "gpios" i2c-gpio property in GoniKrzysztof Kozlowski1-2/+2
"gpios" property is deprecated. Update the Goni DTS to fix dtbs_checks warnings like: i2c-pmic: 'sda-gpios' is a required property i2c-pmic: 'scl-gpios' is a required property Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200907161141.31034-24-krzk@kernel.org
2020-09-16ARM: dts: s5pv210: replace deprecated "gpios" i2c-gpio property in AquilaKrzysztof Kozlowski1-2/+2
"gpios" property is deprecated. Update the Aquila DTS to fix dtbs_checks warnings like: i2c-pmic: 'sda-gpios' is a required property i2c-pmic: 'scl-gpios' is a required property Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200907161141.31034-23-krzk@kernel.org
2020-09-16ARM: dts: s5pv210: move fixed regulators under root node in GoniKrzysztof Kozlowski1-37/+27
The fixed regulators are kept under dedicated "regulators" node but this causes multiple dtschema warnings: regulators: $nodename:0: 'regulators' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' regulators: #size-cells:0:0: 0 is not one of [1, 2] regulators: fixed-regulator@0:reg:0: [0] is too short regulators: fixed-regulator@1:reg:0: [1] is too short regulators: fixed-regulator@2:reg:0: [2] is too short regulators: fixed-regulator@3:reg:0: [3] is too short Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200907161141.31034-22-krzk@kernel.org
2020-09-16ARM: dts: s5pv210: move fixed regulators under root node in AquilaKrzysztof Kozlowski1-28/+19
The fixed regulators are kept under dedicated "regulators" node but this causes multiple dtschema warnings: regulators: $nodename:0: 'regulators' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' regulators: #size-cells:0:0: 0 is not one of [1, 2] regulators: fixed-regulator@0:reg:0: [0] is too short regulators: fixed-regulator@1:reg:0: [1] is too short regulators: fixed-regulator@2:reg:0: [2] is too short Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200907161141.31034-21-krzk@kernel.org
2020-09-16ARM: dts: exynos: Align OPP table name with dt-schemaKrzysztof Kozlowski2-9/+9
Device tree nodes should have hyphens instead of underscores. This is also expected by the bindings. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200903191438.12781-5-krzk@kernel.org
2020-09-16ARM: s3c24xx: fix Wunused-variable warning on !MMUKrzysztof Kozlowski6-6/+6
If S3C24xx machine code is build without CONFIG_MMU, the iotable() macros do nothing so annotate structures to get rid of warnings: arch/arm/mach-s3c24xx/common.c:140:24: warning: ‘s3c_iodesc’ defined but not used [-Wunused-variable] arch/arm/mach-s3c24xx/s3c2410.c:49:24: warning: ‘s3c2410_iodesc’ defined but not used [-Wunused-variable] arch/arm/mach-s3c24xx/s3c2412.c:60:24: warning: ‘s3c2412_iodesc’ defined but not used [-Wunused-variable] arch/arm/mach-s3c24xx/s3c2416.c:54:24: warning: ‘s3c2416_iodesc’ defined but not used [-Wunused-variable] arch/arm/mach-s3c24xx/s3c2443.c:45:24: warning: ‘s3c2443_iodesc’ defined but not used [-Wunused-variable] arch/arm/mach-s3c24xx/s3c244x.c:44:24: warning: ‘s3c244x_iodesc’ defined but not used [-Wunused-variable] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200910154150.3318-2-krzk@kernel.org
2020-09-16ARM: samsung: fix PM debug build with DEBUG_LL but !MMUKrzysztof Kozlowski1-0/+1
Selecting CONFIG_SAMSUNG_PM_DEBUG (depending on CONFIG_DEBUG_LL) but without CONFIG_MMU leads to build errors: arch/arm/plat-samsung/pm-debug.c: In function ‘s3c_pm_uart_base’: arch/arm/plat-samsung/pm-debug.c:57:2: error: implicit declaration of function ‘debug_ll_addr’ [-Werror=implicit-function-declaration] Fixes: 99b2fc2b8b40 ("ARM: SAMSUNG: Use debug_ll_addr() to get UART base address") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200910154150.3318-1-krzk@kernel.org
2020-09-16efi/libstub: arm32: Base FDT and initrd placement on image addressArd Biesheuvel1-12/+11
The way we use the base of DRAM in the EFI stub is problematic as it is ill defined what the base of DRAM actually means. There are some restrictions on the placement of FDT and initrd which are defined in terms of dram_base, but given that the placement of the kernel in memory is what defines these boundaries (as on ARM, this is where the linear region starts), it is better to use the image address in these cases, and disregard dram_base altogether. Reviewed-by: Maxim Uvarov <maxim.uvarov@linaro.org> Tested-by: Maxim Uvarov <maxim.uvarov@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-09-16ARM: dts: at91: sama5d2: add missing flexcom spi node propertiesAlexandre Belloni1-0/+10
SPI nodes require #address-cells and #size-cells add those properties in the flexcom spi nodes. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20200831171129.3886857-8-alexandre.belloni@bootlin.com
2020-09-16ARM: dts: at91: add unit-address to memory nodeAlexandre Belloni51-51/+51
The memory node requires a unit-address, add it. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20200831171129.3886857-7-alexandre.belloni@bootlin.com
2020-09-16ARM: dts: at91: move mmc pinctrl-names property to board dtsAlexandre Belloni20-8/+17
Having the pinctrl-names property in the dtsi leads to dtbs_check warnings when the board dts doesn't define pinctrl-0. Instead, move the property to the board dts actually using the mmc node. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20200831171129.3886857-5-alexandre.belloni@bootlin.com
2020-09-16ARM: tegra: Pass multiple versions in opp-supported-hw propertyViresh Kumar4-1393/+88
We can now pass multiple versions in "opp-supported-hw" property, lets do that and simplify the tables a bit. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-15ARM: add malloc size to decompressor kexec size structureRussell King3-4/+8
Add the required malloc size to the decompressor kexec size structure. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: add TEXT_OFFSET to decompressor kexec image structureRussell King3-1/+6
Add the TEXT_OFFSET to the decompressor's kexec image structure to kexec knows what offset to use. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9007/1: l2c: fix prefetch bits init in L2X0_AUX_CTRL using DT valuesGuillaume Tucker1-4/+12
The L310_PREFETCH_CTRL register bits 28 and 29 to enable data and instruction prefetch respectively can also be accessed via the L2X0_AUX_CTRL register. They appear to be actually wired together in hardware between the registers. Changing them in the prefetch register only will get undone when restoring the aux control register later on. For this reason, set these bits in both registers during initialisation according to the devicetree property values. Link: https://lore.kernel.org/lkml/76f2f3ad5e77e356e0a5b99ceee1e774a2842c25.1597061474.git.guillaume.tucker@collabora.com/ Fixes: ec3bd0e68a67 ("ARM: 8391/1: l2c: add options to overwrite prefetching behavior") Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9010/1: uncompress: Print the location of appended DTBLinus Walleij1-0/+23
When using the kernel with an appended DTB it is useful to know where this will end up in the physical memory at the time the kernel boots. We add a debug print macro that will help out with this. Here is a sample debug print after passing -DDEBUG to head.S during compilation: DTB:0x40CEBA70 (0x000051B5) C:0x402080C0-0x40CF0CE0->0x41801D00-0x422EA920 DTB:0x422E56B0 (0x00005262) This means that the appended DTB is first found after the compressed kernel at 0x40CEBA70 of size 0x51B5 and then after the compressed kernel is moved to 0x41801D00 it is found again at 0x422E56B0 and is there size 0x5262. The growth in size of the FDT is due to the call to atags_to_fdt() that augments the DTB with ATAG information. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9009/1: uncompress: Enable debug in head.SLinus Walleij1-0/+1
The assembly file head.S includes some debug code that does not get enabled when we select CONFIG_DEBUG_UNCOMPRESS. The debug in head.S relies on the user tagging on -DDEBUG on the compilation command line. To simplify debugging, tag on -DDEBUG so that we also get these debug messages when selecting CONFIG_DEBUG_UNCOMPRESS. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9008/1: uncompress: Drop excess whitespace printLinus Walleij1-2/+0
This drops some whitespace from the debug message about where we move the compressed kernel: r after the message is completely surplus since the putc routine will anyway add r after n, and the initial linefeed just assumes that this will always be the first message on the console, which is not certain to be true. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9006/1: uncompress: Wait for ready and busy in debug printsLinus Walleij1-5/+10
For some platforms such as Qualcomm we need to wait for the UART to be ready before writing characters to the UART in the same manner as the macro in debug.S used with the main "Uncompressing Linux ..." text. Pass an extra temporary variable to writeb and make it call waituarttxrdy and busyuart just like the other decomression messages. Optionally it will also call waituartcts if and only if CONFIG_DEBUG_UART_FLOW_CONTROL is selected. After this the decompression debug messages work fine on Qualcomm platforms if you compile head.S with -DDEBUG. Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9005/1: debug: Select flow control for all debug UARTsLinus Walleij5-10/+19
Instead of a flow control selection mechanism specifically for 8250, make this available for all debug UARTs. If the debug UART supports waiting for CTS to be asserted, then this code can be activated for terminals that need it. We keep the defaults for EBSA110, Footbridge, Gemini and RPC so that this still works as expected for these older platforms: they assume that flow control shall be enabled for debug prints. I switch the location of the check for ifdef CONFIG_DEBUG_UART_FLOW_CONTROL from the actual debug UART drivers: the code would get compiled-out for 8250 and Tegra unless their custom config (or passing -DFLOW_CONTROL in the Tegra case) was not set. Instead this is conditional at the three places where we print debug messages. The idea is that debug UARTs can be implemented without this ifdef boilerplate so they look cleaner, alas the ifdef has to be somewhere. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9004/1: debug: Split waituart to CTS and TXRDYLinus Walleij27-30/+114
This patch was triggered by a remark from Russell that introducing a call to the waituart (needed to fix debug prints on the Qualcomm platforms) was dangerous because in some cases this will involve waiting for a modem CTS (clear to send) signal, and debug messages would maybe not work on platforms with no modem connected to the UART port: they will just hang waiting for the modem to assert CTS and this might never happen. Looking through all UART debug drivers implementing the waituart macro I discovered that all users except two actually use this macro to check if the UART is ready for TX, let's call this TXRDY. Only two debug UART drivers actually check for CTS: - arch/arm/include/debug/8250.S - arch/arm/include/debug/tegra.S The former is very significant since the 8250 is possibly the most common UART on the planet. We have the following problem: the semantics of waituart are ambiguous making it dangerous to introduce the macro to debug code fixing debug prints for Qualcomm. To start to pry this problem apart, this patch does the following: - Convert all debug UART drivers to define two macros: - waituartcts with the clear semantic to wait for CTS to be asserted - waituarttxrdy with the clear semantic to wait for the TX capability of the UART to be ready - When doing this take care to assign the right function to each drivers macro, so they now do exactly the above. - Update the three sites in the kernel invoking the waituart macro to call waituartcts/waituarttxrdy in sequence, so that the functional impact on the kernel should be zero. After this we can start to change the code sites using this code to do the right thing. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 9003/1: uncompress: Delete unused debug macrosLinus Walleij1-30/+0
The debug macros debug_reloc_start and debug_reloc_end were rendered unused in commit 6d7d0ae51574943bf571d269da3243257a2d15db "ARM: 6750/1: improvements to compressed/head.S". Later on a different debug macro named dbgkc was introduced in commit f3c899927e19d1be39818145efc39ea27b8efc69 "ARM: 8786/1: Debug kernel copy by printing". Delete the dead debug code. Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: 8997/2: hw_breakpoint: Handle inexact watchpoint addressesDouglas Anderson1-28/+72
This is commit fdfeff0f9e3d ("arm64: hw_breakpoint: Handle inexact watchpoint addresses") but ported to arm32, which has the same problem. This problem was found by Android CTS tests, notably the "watchpoint_imprecise" test [1]. I tested locally against a copycat (simplified) version of the test though. [1] https://android.googlesource.com/platform/bionic/+/master/tests/sys_ptrace_test.cpp Link: https://lkml.kernel.org/r/20191019111216.1.I82eae759ca6dc28a245b043f485ca490e3015321@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-09-15ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Add can0 support to camera DBLad Prabhakar1-0/+11
This patch enables CAN0 interface exposed through connector J4 on the camera DB. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Link: https://lore.kernel.org/r/20200911083615.17377-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-09-15ARM: dts: r8a7742: Add VSP supportLad Prabhakar1-0/+36
Add VSP support to R8A7742 (RZ/G1H) SoC dtsi. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com> Link: https://lore.kernel.org/r/20200911080929.15058-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2020-09-14ARM: dts: hisilicon: Fix SP805 clocksAndre Przywara1-2/+3
The SP805 DT binding requires two clocks to be specified, but Hisilicon platform DTs currently only specify one clock. In practice, Linux would pick a clock named "apb_pclk" for the bus clock, and the Linux and U-Boot SP805 driver would use the first clock to derive the actual watchdog counter frequency. Since currently both are the very same clock, we can just double the clock reference, and add the correct clock-names, to match the binding. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2020-09-14ARM: dts: hisilicon: Fix SP804 usersAndre Przywara2-12/+22
The SP804 binding only specifies one or three clocks, but does not allow just two clocks. The HiSi 3620 .dtsi specified two clocks for the two timers, plus gave one "apb_pclk" clock-name to appease the primecell bus driver. Extend the clocks by duplicating the first clock to the end of the clock list, and add two dummy clock-names to make the primecell driver happy. I don't know what the real APB clock for the IP is, but with the current DT the first timer clock was used for that, so this change keeps the current status. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2020-09-14Merge 5.9-rc5 into usb-nextGreg Kroah-Hartman17-56/+43
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-03 00:25:30 +0300