Граф коммитов

21 Коммитов

Автор SHA1 Сообщение Дата
Linus Torvalds e767b3530a ARM: SoC drivers for v5.12
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
 
 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmApjS8ACgkQYKtH/8kJ
 UidDyw/6ArE2RWN1qk3GJbQKdCYQdqH4Ig/Nc9LA977ul2BX/BohYoEGCoveH5cG
 16FaYK8tYDCSoTfS0+w1Y8r6TgZKcV6GCM0xLSVtaihk2CO81sUfDFBIppJd614a
 2lGx9DW7205ql4vGcQsK31ncr0hVviHG2e8lOEbFc9SkQpmYuLF1dxW2JK9oWGe2
 rLXHKb20N7AvgN8Y6V0YAOGNpu9MOnx0TbTGn6SMgzIKMkpYaSs/oZY11d9jrn7Y
 m/iIahRWzLFR/lYdrD7Jowpy2A/lcwPdQlRkOiuF1s6FFCqxe1yQsrpcbt/7fXes
 UzOyE494GZFtO0zjFuwglsmiAZDMwO/fQVrIzSGV0SXF8LJpiYYTG1b3Yv5SY5Hr
 r7EF4A7GlmNmd6K1HrXTYJz9tr4oxLDw+9LZGx74JV8x0iK3cd1hRTXb1SbspA6h
 S/KRQsuEjpAyQ6xXWVp2fp6VxZkrjIpPavbcQw2RsoBnbNdrcXahTk96JfpWYGjH
 iyJkEKmCF6/w/s5+xQfy+DYepxFDO0YsPbM7kL5qhaY83KBMOHKJFCUZVWj7md5w
 QIVTeeiSewIlT5bG9XyjIfmsImq1acqTW+QCaxCnvMSsZDBbdhTMK48GwyN9U9+x
 jdQCPQye3TKL2WU6U40FPNIr08QcNy4vmJp4fMqwK5xO3+P+Zhs=
 =I2Zn
 -----END PGP SIGNATURE-----

Merge tag 'arm-drivers-v5.12' of 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-02-20 18:42:28 -08:00
Paul Kocialkowski 530fe6bf0f
soc: sunxi: mbus: Remove DE2 display engine compatibles
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: b4bdc4fbf8 ("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-28 11:23:16 +01:00
Andre Przywara 9117d0c975
soc: sunxi: sram: Add support for more than one EMAC clock
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
2021-01-28 11:19:47 +01:00
Maxime Ripard e24f7fac3b soc: sunxi: Fix compilation of sunxi_mbus
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: 16fee29b07 ("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-24 11:58:33 +01:00
Maxime Ripard b4bdc4fbf8 soc: sunxi: Deal with the MBUS DMA offsets in a central place
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-11-18 09:01:30 +01:00
Jason Yan 1893a2d526
soc: sunxi: sram: remove unneeded semicolon
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
2020-09-11 17:02:39 +02:00
Thomas Gleixner ec8f24b7fa treewide: Add SPDX license identifier - Makefile/Kconfig
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-05-21 10:50:46 +02:00
Samuel Holland a84014e1db soc: sunxi: Fix missing dependency on REGMAP_MMIO
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: 5828729beb ("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>
2019-04-30 17:55:08 +02:00
Paul Kocialkowski c773926822
soc: sunxi: sram: Add support for the H5 SoC system control
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-05 11:55:36 +01:00
Paul Kocialkowski 15e53723ce
soc: sunxi: sram: Enable EMAC clock access for H3 variant
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-12-05 11:53:41 +01:00
Yangtao Li 2a8c9f1203
soc: sunxi: Change to use DEFINE_SHOW_ATTRIBUTE macro
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-11-22 16:45:12 +01:00
Maxime Ripard 7377330a1e
soc: sunxi: Add the A13, A23 and H3 system control compatibles
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-19 16:39:12 +02:00
Maxime Ripard 5fdec16b69
drivers: soc: sunxi: Add support for the C1 SRAM region
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-11 10:55:43 +02:00
Paul Kocialkowski acc26f59f8
soc: sunxi: sram: Add dt match for the A10 system-control compatible
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-07-11 10:35:16 +02:00
Chen-Yu Tsai ede18ae312 soc: sunxi: sram: Add updated compatible string for A64 system control
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-19 22:56:47 +08:00
Icenowy Zheng 5828729beb soc: sunxi: export a regmap for EMAC clock reg on A64
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>
2018-06-19 22:55:51 +08:00
Icenowy Zheng 5e4fb64297 drivers: soc: sunxi: add support for A64 and its SRAM C
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-18 14:30:21 +08:00
Icenowy Zheng 8fed2ce98e drivers: soc: sunxi: add support for remapping func value to reg value
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-18 14:30:20 +08:00
Icenowy Zheng 2262a65f0b drivers: soc: sunxi: fix error processing on base address when claiming
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: 4af34b572a ("drivers: soc: sunxi: Introduce SoC driver to map
		      SRAMs")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2017-08-18 14:30:19 +08:00
Jens Kuske febe6569fa drivers: soc: sunxi: Fix mask generation for SRAM mapping
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>
2016-01-27 20:29:20 +01:00
Maxime Ripard 4af34b572a drivers: soc: sunxi: Introduce SoC driver to map SRAMs
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>
2015-06-01 17:57:34 +02:00