summaryrefslogtreecommitdiff
path: root/drivers/soc/sunxi
AgeCommit message (Collapse)Author
2021-02-20Merge tag 'arm-drivers-v5.12' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Arnd Bergmann: "Updates for SoC specific drivers include a few subsystems that have their own maintainers but send them through the soc tree: SCMI firmware: - add support for a completion interrupt Reset controllers: - new driver for BCM4908 - new devm_reset_control_get_optional_exclusive_released() function Memory controllers: - Renesas RZ/G2 support - Tegra124 interconnect support - Allow more drivers to be loadable modules TEE/optee firmware: - minor code cleanup The other half of this is SoC specific drivers that do not belong into any other subsystem, most of them living in drivers/soc: - Allwinner/sunxi power management work - Allwinner H616 support - ASpeed AST2600 system identification support - AT91 SAMA7G5 SoC ID driver - AT91 SoC driver cleanups - Broadcom BCM4908 power management bus support - Marvell mbus cleanups - Mediatek MT8167 power domain support - Qualcomm socinfo driver support for PMIC - Qualcomm SoC identification for many more products - TI Keystone driver cleanups for PRUSS and elsewhere" * tag 'arm-drivers-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (89 commits) soc: aspeed: socinfo: Add new systems soc: aspeed: snoop: Add clock control logic memory: tegra186-emc: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE memory: samsung: exynos5422-dmc: Correct function names in kerneldoc memory: ti-emif-pm: Drop of_match_ptr from of_device_id table optee: simplify i2c access drivers: soc: atmel: fix type for same7 tee: optee: remove need_resched() before cond_resched() soc: qcom: ocmem: don't return NULL in of_get_ocmem optee: sync OP-TEE headers tee: optee: fix 'physical' typos drivers: optee: use flexible-array member instead of zero-length array tee: fix some comment typos in header files soc: ti: k3-ringacc: Use of_device_get_match_data() soc: ti: pruss: Refactor the CFG sub-module init soc: mediatek: pm-domains: Don't print an error if child domain is deferred soc: mediatek: pm-domains: Add domain regulator supply dt-bindings: power: Add domain regulator supply soc: mediatek: cmdq: Remove cmdq_pkt_flush() soc: mediatek: pm-domains: Add support for mt8167 ...
2021-01-28soc: sunxi: mbus: Remove DE2 display engine compatiblesPaul Kocialkowski
The DE2 display engine hardware takes physical addresses that do not need PHYS_BASE subtracted. As a result, they should not be present on the mbus driver match list. Remove them. This was tested on the A83T, along with the patch allowing the DMA range map to be non-NULL and restores a working display. Fixes: b4bdc4fbf8d0 ("soc: sunxi: Deal with the MBUS DMA offsets in a central place") Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210115175831.1184260-2-paul.kocialkowski@bootlin.com
2021-01-28soc: sunxi: sram: Add support for more than one EMAC clockAndre Przywara
The Allwinner H616 adds a second EMAC clock register at offset 0x34, for controlling the second EMAC in this chip. Allow to extend the regmap in this case, to cover more than the current 4 bytes exported. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210127172500.13356-9-andre.przywara@arm.com
2020-11-24soc: sunxi: Fix compilation of sunxi_mbusMaxime Ripard
dma_direct_set_offset has been moved from dma-mapping.h to dma-map-ops.h, but our driver hasn't been updated resulting in a build breakage. Let's change the header to fix the build. Fixes: 16fee29b0735 ("dma-mapping: remove the dma_direct_set_offset export") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20201124103546.839711-1-maxime@cerno.tech' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-11-18soc: sunxi: Deal with the MBUS DMA offsets in a central placeMaxime Ripard
So far most of the drivers with the MBUS quirks had to duplicate the code to deal with DT compatibility and enforcing the DMA offsets. Let's move for a more maintainable solution by putting everything in a notifier that would take care of setting up the DMA offsets for all the MBUS devices. Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-09-11soc: sunxi: sram: remove unneeded semicolonJason Yan
Eliminate the following coccicheck warning: drivers/soc/sunxi/sunxi_sram.c:197:2-3: Unneeded semicolon Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20200910140546.1191280-1-yanaijie@huawei.com
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-30soc: sunxi: Fix missing dependency on REGMAP_MMIOSamuel Holland
When enabling ARCH_SUNXI from allnoconfig, SUNXI_SRAM is enabled, but not REGMAP_MMIO, so the kernel fails to link with an undefined reference to __devm_regmap_init_mmio_clk. Select REGMAP_MMIO, as suggested in drivers/base/regmap/Kconfig. This creates the following dependency loop: drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP drivers/base/regmap/Kconfig:7: symbol REGMAP default is visible depending on REGMAP_MMIO drivers/base/regmap/Kconfig:39: symbol REGMAP_MMIO is selected by SUNXI_SRAM drivers/soc/sunxi/Kconfig:4: symbol SUNXI_SRAM is selected by USB_MUSB_SUNXI drivers/usb/musb/Kconfig:63: symbol USB_MUSB_SUNXI depends on GENERIC_PHY drivers/phy/Kconfig:7: symbol GENERIC_PHY is selected by PHY_BCM_NS_USB3 drivers/phy/broadcom/Kconfig:29: symbol PHY_BCM_NS_USB3 depends on MDIO_BUS drivers/net/phy/Kconfig:12: symbol MDIO_BUS default is visible depending on PHYLIB drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected by ARC_EMAC drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ To fix the circular dependency, make USB_MUSB_SUNXI select GENERIC_PHY instead of depending on it. This matches the use of GENERIC_PHY by all but two other drivers. Cc: <stable@vger.kernel.org> # 4.19 Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64") Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05soc: sunxi: sram: Add support for the H5 SoC system controlPaul Kocialkowski
This adds the H5 SoC compatible to the list of device-tree matches for the SRAM driver. Since the variant is the same as the A64 (that precedes the H5), the same variant description is used. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-12-05soc: sunxi: sram: Enable EMAC clock access for H3 variantPaul Kocialkowski
Just like the A64 and H5, the H3 SoC uses the system control block to enable the EMAC clock. Add a variant structure definition for the H3 and use it over the A10 one. This will allow using the H3-specific binding for the syscon node attached to the EMAC instead of the generic syscon binding. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-11-22soc: sunxi: Change to use DEFINE_SHOW_ATTRIBUTE macroYangtao Li
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-07-19soc: sunxi: Add the A13, A23 and H3 system control compatiblesMaxime Ripard
The A13, A23 and H3 have variations of the system controls, in part due to the SRAM that are available (and can be mapped) in the SoC. In order to make it future proof, let's add compatibles for these SoCs in the driver. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-07-11drivers: soc: sunxi: Add support for the C1 SRAM regionMaxime Ripard
This introduces support for the SRAM C1 section, that is controlled by the system controller. This SRAM area can be muxed either to the CPU or the Video Engine, that needs this area to store various tables (e.g. the Huffman VLD decoding tables). This only supports devices with the same layout as the A10 (which also includes the A13, A20, A33 and other SoCs). Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-07-11soc: sunxi: sram: Add dt match for the A10 system-control compatiblePaul Kocialkowski
This binds the new A10 system-control compatible to the associated driver, with the same driver data as the previous compatible. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-06-19soc: sunxi: sram: Add updated compatible string for A64 system controlChen-Yu Tsai
The SRAM mapping controls on Allwinner SoCs is located in a block called "System Controls". This block also has registers for identifying the SoC, reading the state of an external boot-related pin, and on some newer SoCs, glue layer controls for the EMAC Ethernet controller. The A64 variant compatible is renamed to "allwinner,a64-system-control" to reflect this. The old A64 compatible is deprecated. So far we haven't seen any actual use of it. Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2018-06-19soc: sunxi: export a regmap for EMAC clock reg on A64Icenowy Zheng
The A64 SRAM controller memory zone has a EMAC clock register, which is needed by the Ethernet MAC driver (dwmac-sun8i). Export a regmap for this register on A64. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> [wens@csie.org: export whole address range with only EMAC register accessible and drop regmap name] Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-08-18drivers: soc: sunxi: add support for A64 and its SRAM CIcenowy Zheng
Allwinner A64's display engine claims the SRAM C section to work. Add support for the A64 SRAM controller and the SRAM C section of it. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-08-18drivers: soc: sunxi: add support for remapping func value to reg valueIcenowy Zheng
On some Allwinner SoCs, sometimes the value needed to write into the register to claim SRAM is not equal to the value specified in the device tree. The device tree binding defines 0 as "mapped to CPU" and 1 as "mapped to X device". This matches the value written to the configuration register for the SRAM blocks currently supported. However, the not yet supported VE SRAM block is claimed for the device by writing 0x7fffffff, which is vastly different from the other blocks. On the A64, SRAM C is claimed by the device by writing a 0, which is the opposite of the current design. Add a value remapping in sunxi_sram_func structure, and let the sunxi_sram_of_parse function set the remapped register value. This allows us to keep the convention currently used in the device tree binding. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> [wens@csie.org: Clarified commit message] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-08-18drivers: soc: sunxi: fix error processing on base address when claimingIcenowy Zheng
When claiming SRAM, if the base is set to an error, it means that the SRAM controller has been probed, but failed to remap the controller memory zone. If the base is zero, thus the SRAM controller should be not probed at all, and it should return -EPROBE_DEFER. However, currently we returned -EPROBE_DEFER in the former situation, and ignored the latter situation (which will lead to the kernel to panic). Fix the behavior on abnormal base address processing when claiming. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2016-01-27drivers: soc: sunxi: Fix mask generation for SRAM mappingJens Kuske
GENMASK is inclusive on both ends, therefor one has to be subtracted from the width. Also fixes the mask for debug output. Signed-off-by: Jens Kuske <jenskuske@gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2015-06-01drivers: soc: sunxi: Introduce SoC driver to map SRAMsMaxime Ripard
The Allwinner SoCs have a handful of SRAM that can be either mapped to be accessible by devices or the CPU. That mapping is controlled by an SRAM controller, and that mapping might not be set by the bootloader, for example if the device wasn't used at all, or if we're using solutions like the U-Boot's Falcon Boot. We could also imagine changing this at runtime for example to change the mapping of these SRAMs to use them for suspend/resume or runtime memory rate change, if that ever happens. These use cases require some API in the kernel to control that mapping, exported through a drivers/soc driver. This driver also implement a debugfs file that shows the SRAM found in the system, the current mapping and the SRAM that have been claimed by some drivers in the kernel. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>