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>
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>
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>
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>
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>
