aboutsummaryrefslogtreecommitdiff
path: root/drivers/soc/sunxi
AgeCommit message (Collapse)AuthorFilesLines
2024-07-11soc: sunxi: sram: Constify struct regmap_configJavier Carrasco1-1/+1
`sunxi_sram_regmap_config` is not modified and can be declared as const to move its data to a read-only section. Signed-off-by: Javier Carrasco <[email protected]> Reviewed-by: Andre Przywara <[email protected]> Link: https://lore.kernel.org/r/20240705-sunxi-sram-const-regmap_config-v1-1-1b997cd65d0f@gmail.com Signed-off-by: Chen-Yu Tsai <[email protected]>
2024-05-28soc: sunxi: sram: Remove unused list 'claimed_sram'Dr. David Alan Gilbert1-2/+0
The list 'claimed_sram' seems unused, as far as I can tell it always has been. I think the 'list' member of sunxi_sram_data was intended to be used when it was on that list. Remove them. Build tested only. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chen-Yu Tsai <[email protected]>
2024-03-11soc: sunxi: sram: export register 0 for THS on H616Andre Przywara1-0/+22
The Allwinner H616 SoC contains a mysterious bit at register offset 0x0 in the SRAM control block. If bit 16 is set (the reset value), the temperature readings of the THS are way off, leading to reports about 200C, at normal ambient temperatures. Clearing this bits brings the reported values down to the expected values. The BSP code clears this bit in firmware (U-Boot), and has an explicit comment about this, but offers no real explanation. Experiments in U-Boot show that register 0x0 has no effect on the SRAM C visibility: all tested bit settings still allow full read and write access by the CPU to the whole of SRAM C. Only bit 24 of the register at offset 0x4 makes all of SRAM C inaccessible by the CPU. So modelling the THS switch functionality as an SRAM region would not reflect reality. Since we should not rely on firmware settings, allow other code (the THS driver) to access this register, by exporting it through the already existing regmap. This mimics what we already do for the LDO control and the EMAC register. To avoid concurrent accesses to the same register at the same time, by the SRAM switch code and the regmap code, use the same lock to protect the access. The regmap subsystem allows to use an existing lock, so we just need to hook in there. Signed-off-by: Andre Przywara <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-04pmdomain: sunxi: Move Kconfig option to the pmdomain subsystemUlf Hansson1-9/+0
The Kconfig option belongs closer to the corresponding implementation, hence let's move it from the soc subsystem to the pmdomain subsystem. Cc: Chen-Yu Tsai <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Samuel Holland <[email protected]> Cc: <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2023-08-12Merge tag 'sunxi-drivers-for-6.6-1' of ↵Arnd Bergmann1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/drivers - simplify code in sunxi-rsb - fix includes in sunxi_sram * tag 'sunxi-drivers-for-6.6-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: soc: sunxi: Explicitly include correct DT includes bus: sunxi-rsb: Convert to devm_platform_ioremap_resource() Link: https://lore.kernel.org/r/20230806180650.GA127142@jernej-laptop Signed-off-by: Arnd Bergmann <[email protected]>
2023-08-06soc: sunxi: Explicitly include correct DT includesRob Herring1-1/+1
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/20230803-dt-header-cleanups-for-soc-v2-21-d8de2cc88bff@kernel.org Signed-off-by: Jernej Skrabec <[email protected]>
2023-07-14soc: sunxi: Move power-domain driver to the genpd dirUlf Hansson2-208/+0
To simplify with maintenance let's move the sunxi power-domain driver to the new genpd directory. Going forward, patches are intended to be managed through a separate git tree, according to MAINTAINERS. Cc: Chen-Yu Tsai <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Samuel Holland <[email protected]> Cc: <[email protected]> Acked-by: Jernej Skrabec <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2023-03-14kbuild, soc: sunxi: sram: remove MODULE_LICENSE in non-modulesNick Alcock1-1/+0
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <[email protected]> Suggested-by: Luis Chamberlain <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Hitomi Hasegawa <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Samuel Holland <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
2023-03-14soc: sunxi: Use of_property_present() for testing DT property presenceRob Herring1-1/+1
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Reviewed-by: Andre Przywara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
2023-02-10soc: sunxi: SUN20I_PPU should depend on PMRandy Dunlap1-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 <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Jernej Skrabec <[email protected]> Cc: Samuel Holland <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Arnd Bergmann <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-01-30soc: sunxi: select CONFIG_PMArnd Bergmann1-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 <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-01-27soc: sunxi: Add Allwinner D1 PPU driverSamuel Holland3-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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
2023-01-12soc: sunxi: sram: Only iterate over SRAM childrenSamuel Holland1-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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]>
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected]' Signed-off-by: Arnd Bergmann <[email protected]>
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Daniel Vetter <[email protected]>
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 <[email protected]> Signed-off-by: Jason Yan <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
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 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
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: <[email protected]> # 4.19 Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64") Signed-off-by: Samuel Holland <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Bin Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Paul Kocialkowski <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]> Signed-off-by: Paul Kocialkowski <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]>
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 <[email protected]> [[email protected]: export whole address range with only EMAC register accessible and drop regmap name] Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]>
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 <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]>
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 <[email protected]> [[email protected]: Clarified commit message] Signed-off-by: Chen-Yu Tsai <[email protected]>
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 <[email protected]> Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") Signed-off-by: Chen-Yu Tsai <[email protected]>
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Hans de Goede <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.