linux-toradex.git/drivers/soc/sunxi, branch v5.0

soc: sunxi: sram: Add support for the H5 SoC system control

2018-12-05T10:55:36+00:00

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 
Signed-off-by: Maxime Ripard

soc: sunxi: sram: Enable EMAC clock access for H3 variant

2018-12-05T10:53:41+00:00

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 
Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard

soc: sunxi: Change to use DEFINE_SHOW_ATTRIBUTE macro

2018-11-22T15:45:12+00:00

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li 
Signed-off-by: Maxime Ripard

soc: sunxi: Add the A13, A23 and H3 system control compatibles

2018-07-19T14:39:12+00:00

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

drivers: soc: sunxi: Add support for the C1 SRAM region

2018-07-11T08:55:43+00:00

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 
Signed-off-by: Maxime Ripard 
Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard

soc: sunxi: sram: Add dt match for the A10 system-control compatible

2018-07-11T08:35:16+00:00

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 
Signed-off-by: Paul Kocialkowski 
Signed-off-by: Maxime Ripard

soc: sunxi: sram: Add updated compatible string for A64 system control

2018-06-19T14:56:47+00:00

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 
Signed-off-by: Chen-Yu Tsai

soc: sunxi: export a regmap for EMAC clock reg on A64

2018-06-19T14:55:51+00:00

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 
[wens@csie.org: export whole address range with only EMAC register
		accessible and drop regmap name]
Acked-by: Maxime Ripard 
Signed-off-by: Chen-Yu Tsai

drivers: soc: sunxi: add support for A64 and its SRAM C

2017-08-18T06:30:21+00:00

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 
Signed-off-by: Chen-Yu Tsai

drivers: soc: sunxi: add support for remapping func value to reg value

2017-08-18T06:30:20+00:00

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 
[wens@csie.org: Clarified commit message]
Signed-off-by: Chen-Yu Tsai