summaryrefslogtreecommitdiffstats
path: root/drivers/soc/sunxi
AgeCommit message (Collapse)AuthorFilesLines
2022-09-18soc: sunxi: sram: Add support for the D1 system controlSamuel Holland1-0/+9
D1 has a single EMAC and some LDOs that need to be exported. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20220815041248.53268-11-samuel@sholland.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
2022-09-18soc: sunxi: sram: Export the LDO control registerSamuel Holland1-14/+16
Some newer Allwinner SoCs contain internal LDOs managed by a register in the system control MMIO space. Export this from the regmap in addtion to the EMAC register. Use generic names now that the regmap is no longer EMAC-specific. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20220815041248.53268-10-samuel@sholland.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
2022-09-18soc: sunxi: sram: Save a pointer to the OF match dataSamuel Holland1-3/+3
It is inefficient to match the compatible string every time the regmap is accessed. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20220815041248.53268-9-samuel@sholland.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
2022-09-18soc: sunxi: sram: Return void from the release functionSamuel Holland1-5/+3
There is no point in returning an error here, as the caller can do nothing about it. In fact, all callers already ignore the return value. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20220815041248.53268-8-samuel@sholland.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
2022-09-08soc: sunxi: sram: Fix debugfs info for A64 SRAM CSamuel Holland1-2/+2
The labels were backward with respect to the register values. The SRAM is mapped to the CPU when the register value is 1. Fixes: 5e4fb6429761 ("drivers: soc: sunxi: add support for A64 and its SRAM C") Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-7-samuel@sholland.org
2022-09-08soc: sunxi: sram: Fix probe function ordering issuesSamuel Holland1-8/+5
Errors from debugfs are intended to be non-fatal, and should not prevent the driver from probing. Since debugfs file creation is treated as infallible, move it below the parts of the probe function that can fail. This prevents an error elsewhere in the probe function from causing the file to leak. Do the same for the call to of_platform_populate(). Finally, checkpatch suggests an octal literal for the file permissions. Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-6-samuel@sholland.org
2022-09-08soc: sunxi: sram: Prevent the driver from being unboundSamuel Holland1-3/+2
This driver exports a regmap tied to the platform device (as opposed to a syscon, which exports a regmap tied to the OF node). Because of this, the driver can never be unbound, as that would destroy the regmap. Use builtin_platform_driver_probe() to enforce this limitation. Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-5-samuel@sholland.org
2022-09-08soc: sunxi: sram: Actually claim SRAM regionsSamuel Holland1-0/+1
sunxi_sram_claim() checks the sram_desc->claimed flag before updating the register, with the intent that only one device can claim a region. However, this was ineffective because the flag was never set. Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-4-samuel@sholland.org
2022-07-05soc: sunxi: mbus: Only build the driver on ARM/ARM64Samuel Holland1-0/+1
This driver exists as a workaround for old devicetrees which are missing interconnects properties, so it is only useful for those specific platforms, which all happen to be ARM or ARM64. This solves the issue that the driver fails to build on RISC-V, where PHYS_OFFSET is not defined. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220702032520.22129-1-samuel@sholland.org
2021-09-13soc: sunxi_sram: Make use of the helper function ↵Cai Huoqing1-3/+1
devm_platform_ioremap_resource() Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210908071716.772-1-caihuoqing@baidu.com
2021-02-20Merge tag 'arm-drivers-v5.12' of ↵Linus Torvalds1-8/+23
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 Kocialkowski1-5/+0
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 Przywara1-8/+23
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 Ripard1-1/+1
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 Ripard3-0/+141
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 Yan1-1/+1
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 Gleixner2-0/+2
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 Holland1-0/+1
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 Kocialkowski1-0/+4
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 Kocialkowski1-1/+5
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 Li1-11/+1
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 Ripard1-0/+12
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 Ripard1-0/+10
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 Kocialkowski1-0/+4
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 Tsai1-0/+4
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 Zheng1-2/+55
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 Zheng1-0/+11
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 Zheng1-9/+34
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 Zheng1-0/+3
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 Kuske1-2/+3
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 Ripard3-0/+295
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-29 10:48:10 +0000