Commit graph

6 commits

Author SHA1 Message Date
Icenowy Zheng
e9dfd8e960 sunxi: support asymmetric dual rank DRAM on A64/R40
Previously we have known that R40 has a configuration register for its
rank 1, which allows different configuration than rank 0. Reverse
engineering of newest libdram of A64 from Allwinner shows that A64 has
this register too. It's bit 0 (which enables dual rank in rank 0
configuration register) means a dedicated rank size setup is used for
rank 1.

Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
DRAM support necessary.

Add this support. The code could support both A64 and R40, but because
dual rank detection is broken on R40 now, we cannot really use it on R40
currently.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-04-16 01:12:58 +01:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Masahiro Yamada
ed3986ca30 bitops: collect BIT macros to include/linux/bitops.h
Same macros are defined in various places.  Collect them into
include/linux/bitops.h like Linux.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-11-29 00:28:57 +09:00
Icenowy Zheng
f6457ce578 sunxi: Add selective DRAM type and timing
DRAM chip varies, and one code cannot satisfy all DRAMs.

Add options to select a timing set.

Currently only DDR3-1333 (the original set) is added into it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
2017-06-08 22:37:55 +05:30
Icenowy Zheng
f43a009959 sunxi: Rename bus-width related macros in H3 DRAM code
The DesignWare DRAM controller used by H3 and newer SoCs use a bit to
identify whether the DRAM is half-width.

As H3 itself come with 32-bit DRAM, the two modes of the bit used to be
named "MCTL_CR_32BIT" and "MCTL_CR_16BIT", but for SoCs with 16-bit DRAM
they're really 8-bit and 16-bit.

Rename the bit's macro, and also rename the variable name in
dram_sun8i_h3.c.

This commit do not add 16-bit DRAM controller support, but the support
will be introduced in next commit.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
2017-06-08 22:37:55 +05:30
Icenowy Zheng
9934aba427 sunxi: makes an invisible option for H3-like DRAM controllers
Allwinner SoCs after H3 (e.g. A64, H5, R40, V3s) uses a H3-like
DesignWare DRAM controller, which do not have official free DRAM
initialization code, but can use modified dram_sun8i_h3.c.

Add a invisible option for easier DRAM initialization code reuse.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
2017-06-08 22:37:55 +05:30
Renamed from arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h (Browse further)