summaryrefslogtreecommitdiffstats
path: root/drivers/soc/sunxi
Commit message (Collapse)AuthorAgeFilesLines
* soc: sunxi: SUN20I_PPU should depend on PMRandy Dunlap2023-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | An $ARCH or a platform should select PM. Single device drivers should only depend on PM, not select it. Having SUN20I_PPU depend on PM removes a kconfig warning: WARNING: unmet direct dependencies detected for PM Depends on [n]: !MMU [=y] Selected by [y]: - SUN20I_PPU [=y] && (ARCH_SUNXI || COMPILE_TEST [=y]) Fixes: 0ad2185dcb5e ("soc: sunxi: select CONFIG_PM") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Samuel Holland <samuel@sholland.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-sunxi@lists.linux.dev Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* soc: sunxi: select CONFIG_PMArnd Bergmann2023-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Selecting CONFIG_PM_GENERIC_DOMAINS without CONFIG_PM leads to a build failure: WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS Depends on [n]: PM [=n] Selected by [y]: - SUN20I_PPU [=y] && (ARCH_SUNXI [=n] || COMPILE_TEST [=y]) drivers/base/power/domain_governor.c: In function 'default_suspend_ok': drivers/base/power/domain_governor.c:85:24: error: 'struct dev_pm_info' has no member named 'ignore_children' 85 | if (!dev->power.ignore_children) | ^ drivers/base/power/domain.c: In function 'genpd_queue_power_off_work': drivers/base/power/domain.c:657:20: error: 'pm_wq' undeclared (first use in this function) 657 | queue_work(pm_wq, &genpd->power_off_work); | ^~~~~ Unfortunately platforms are inconsistent between using 'select PM' and 'depends on PM' here. CONFIG_PM is a user-visible symbol, so in principle we should be using 'depends on', but on the other hand using 'select' here is more common among drivers/soc. Go with the majority for now, as this has a smaller risk of introducing circular dependencies. We may need to clean this up for consistency later. Fixes: 0e30ca5ab0a8 ("soc: sunxi: Add Allwinner D1 PPU driver") Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* soc: sunxi: Add Allwinner D1 PPU driverSamuel Holland2023-01-273-0/+216
| | | | | | | | | | | | | The PPU contains a series of identical MMIO register ranges, one for each power domain. Each range contains control/status bits for a clock gate, reset line, output gates, and a power switch. (The clock and reset are separate from, and in addition to, the bits in the CCU.) It also contains a hardware power sequence engine to control the other bits. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20230126063419.15971-3-samuel@sholland.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
* soc: sunxi: sram: Only iterate over SRAM childrenSamuel Holland2023-01-121-0/+3
| | | | | | | | | | Now that a regulators child is accepted by the controller binding, the debugfs show routine must be explicitly limited to mmio-sram children. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20221208084127.17443-5-samuel@sholland.org Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
* soc: sunxi: sram: Add support for the D1 system controlSamuel Holland2022-09-181-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>
* soc: sunxi: sram: Export the LDO control registerSamuel Holland2022-09-181-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>
* soc: sunxi: sram: Save a pointer to the OF match dataSamuel Holland2022-09-181-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>
* soc: sunxi: sram: Return void from the release functionSamuel Holland2022-09-181-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>
* soc: sunxi: sram: Fix debugfs info for A64 SRAM CSamuel Holland2022-09-081-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
* soc: sunxi: sram: Fix probe function ordering issuesSamuel Holland2022-09-081-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
* soc: sunxi: sram: Prevent the driver from being unboundSamuel Holland2022-09-081-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
* soc: sunxi: sram: Actually claim SRAM regionsSamuel Holland2022-09-081-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
* soc: sunxi: mbus: Only build the driver on ARM/ARM64Samuel Holland2022-07-051-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
* soc: sunxi_sram: Make use of the helper function ↵Cai Huoqing2021-09-131-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
* Merge tag 'arm-drivers-v5.12' of ↵Linus Torvalds2021-02-201-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 ...
| * soc: sunxi: sram: Add support for more than one EMAC clockAndre Przywara2021-01-281-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
* | soc: sunxi: mbus: Remove DE2 display engine compatiblesPaul Kocialkowski2021-01-281-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
* soc: sunxi: Fix compilation of sunxi_mbusMaxime Ripard2020-11-241-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>
* soc: sunxi: Deal with the MBUS DMA offsets in a central placeMaxime Ripard2020-11-183-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>
* soc: sunxi: sram: remove unneeded semicolonJason Yan2020-09-111-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
* treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner2019-05-212-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>
* soc: sunxi: Fix missing dependency on REGMAP_MMIOSamuel Holland2019-04-301-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>
* soc: sunxi: sram: Add support for the H5 SoC system controlPaul Kocialkowski2018-12-051-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>
* soc: sunxi: sram: Enable EMAC clock access for H3 variantPaul Kocialkowski2018-12-051-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>
* soc: sunxi: Change to use DEFINE_SHOW_ATTRIBUTE macroYangtao Li2018-11-221-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>
* soc: sunxi: Add the A13, A23 and H3 system control compatiblesMaxime Ripard2018-07-191-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>
* drivers: soc: sunxi: Add support for the C1 SRAM regionMaxime Ripard2018-07-111-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>
* soc: sunxi: sram: Add dt match for the A10 system-control compatiblePaul Kocialkowski2018-07-111-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>
* soc: sunxi: sram: Add updated compatible string for A64 system controlChen-Yu Tsai2018-06-191-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>
* soc: sunxi: export a regmap for EMAC clock reg on A64Icenowy Zheng2018-06-191-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>
* drivers: soc: sunxi: add support for A64 and its SRAM CIcenowy Zheng2017-08-181-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>
* drivers: soc: sunxi: add support for remapping func value to reg valueIcenowy Zheng2017-08-181-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>
* drivers: soc: sunxi: fix error processing on base address when claimingIcenowy Zheng2017-08-181-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>
* drivers: soc: sunxi: Fix mask generation for SRAM mappingJens Kuske2016-01-271-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>
* drivers: soc: sunxi: Introduce SoC driver to map SRAMsMaxime Ripard2015-06-013-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.25.1) at 2024-11-04 12:50:46 +0000