GitLab

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

This will be used to control external STM-MEM.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

There's no so much differences between different families of STM32.
Manual (migrate STM32F1 -> STM32F2) says, that GPIO and Flash are
significantly different, the other interfaces (we use) are almost
the same. So, let's name this arch as 'stm32', not 'stm32f2' (as we
do this in linux).
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

There's only one MAC controller in all STM32 products. No need to
have it regs 'mapped' in eth device structure (actually, there's
even no need in this structure at all - MAC is always one).
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Don't declare & init local volatile pointer vars to access these
regs in each function, which need these. Use macros instead.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Rationale: to support external RAM there'll be again (like in MAC)
a plenty of GPIOs which should be configured. Don't want to redfine
the GPIO descriptor structure (port + pin), let's have this struct
as a part of STM32F2 GPIO Driver API.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

This reverts commit 664f519a

.

Move drivers back to drivers/gpio|serial.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Note, beside this, to make driver workable, this patch:

- changes SRAM memory distribution. Actually, we have 128K in STM (as
opposite to 64K in A2F). TBDs here: a) CONFIG_MEM_RAM_LEN is a bad
name, since this isn't length of full SRAM, but just a part of it; b)
we should control the summary length of MEM_xxx areas somehow, on a
SOC basis (i.e. A2F has 64K SRAM, STM32F2 has 128K SRAM, etc.), maybe
include/configs/cortex-m3-common.h would be the best choice; c) not
sure if we want to have *all* SRAM parts configurable, e.g. MALLOC size
may be determined automatically.

- in default configuration load files to SRAM (RAM_BUF) (as opposite
to external RAM). TBD here: make this configurable somehow.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

MCO will be used for clocking PHY in ethernet.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Use this driver to configure GPIOs for using them:
- with UART (right now);
- with Ethernet (in the forthcoming patches).
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Previously, all these were located in stm32f2.h. As for me, that
was better: these definitions are really CPU-specific (describe
the CPU specific registers and their fields), and have no rela-
tion to driver or anything else c-code; latters just use them. So,
my opinion is that their place in stm32f2.h header, not in c-files.

The only positive thing here: is more clear stm32f2.h file.

Note, the definitions used by several files (e.g. RCC regs base, used
by clock.c and stm32f2_serial.c) I kept in stm32f2.h. The same about
C-types of register maps.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

Stubs for stm3220g-eval port.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>

for SmartFusion.

Please update the kernel to commit 2619bac, otherwise ethernet driver won't work!

This comment breaks the kernel ethernet driver functionality, see commit id
2619bac in the kernel tree.