u-boot.git/arch, branch v2017.09-rc2

Merge branch 'master' of git://git.denx.de/u-boot-rockchip

2017-08-14T14:40:01+00:00

stm32f1: remove stm32f1 support

2017-08-13T19:17:37+00:00

A few years ago STM32F1 SoCs support has been added :
0144caf22ce6acd5c  gpio: stm32: add stm32f1 support
2d18ef2364fd3561a  ARMv7M: add STM32F1 support

But neither STM32F1 dedicated defconfig nor board was
associated to these commits.

Got confirmation from Tom Rini and Matt Porter to remove
all this code [1]

[1] http://u-boot.10912.n7.nabble.com/Remove-STM32F1-support-td301603.html

Signed-off-by: Patrice Chotard 
Reviewed-by: Tom Rini

ARM: OMAP5: Enable support for AVS0 for OMAP5 production devices

2017-08-13T19:17:35+00:00

OMAP5432 did go into production with AVS class0 registers which were
mutually exclusive from AVS Class 1.5 registers.

Most OMAP5-uEVM boards use the pre-production Class1.5 which has
production efuse registers set to 0. However on production devices,
these are set to valid data.

scale_vcore logic is already smart enough to detect this and use the
"Nominal voltage" on devices that do not have efuse registers populated.

On a test production device populated as follows:
MPU OPP_NOM:
=> md.l 0x04A0021C4 1
4a0021c4: 03a003e9                               ....
(0x3e9 = 1.01v) vs nom voltage of 1.06v
MPU OPP_HIGH:
=> md.l 0x04A0021C8 1
4a0021c8: 03400485                               ..@.

MM OPP_NOM:
=> md.l 0x04A0021A4 1
4a0021a4: 038003d4                               ....
(0x3d4 = 980mV) vs nom voltage of 1.025v
MM OPP_OD:
=> md.l 0x04A0021A8 1
4a0021a8: 03600403                               ..`.

CORE OPP_NOM:
=> md.l 0x04A0021D8 1
4a0021d8: 000003cf                               ....
(0x3cf = 975mV) vs nom voltage of 1.040v

Since the efuse values are'nt currently used, we do not regress on
existing pre-production samples (they continue to use nominal voltage).

But on boards that do have production samples populated, we can leverage
the optimal voltages necessary for proper operation.

Tested on:
a) 720-2644-001 OMAP5UEVM with production sample.
b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.

Data based on OMAP5432 Technical reference Manual SWPU282AF (May
2012-Revised Aug 2016)

NOTE: All collaterals on OMAP5432 silicon itself seems to have been
removed from ti.com, though EVM details are still available:
http://www.ti.com/tool/OMAP5432-EVM

Signed-off-by: Nishanth Menon 
Reviewed-by: Lokesh Vutla

ARM: OMAP5: Remove OPP_LOW Definitions for ES2.0

2017-08-13T19:17:35+00:00

ES2.0 descopes OPP_LOW definition. So remove it from macros defined.

Signed-off-by: Nishanth Menon 
Reviewed-by: Lokesh Vutla

stm32: remove redundant 'else if'

2017-08-13T19:17:28+00:00

The if in the else branch is superfluous.
We can use a simple if.

The problem was indicated by cppcheck.

Signed-off-by: Heinrich Schuchardt

arm: mvebu: avoid possible NULL dereference

2017-08-13T19:17:28+00:00

It does not make sense to check if info is NULL after
dereferencing it.

The problem was indicated by cppcheck.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Stefan Roese

armv7m: mpu_config add missing break

2017-08-13T19:17:28+00:00

For DEVICE_NON_SHARED the newly assigned value of attr
is overwritten due to a missing break.

The problem was indicated by cppcheck.

Signed-off-by: Heinrich Schuchardt

bcm281xx: clock: avoid possible NULL dereference

2017-08-13T19:17:27+00:00

It does not make sense first to dereference c and then
to check if it is NULL.

The problem was indicated by cppcheck.

Signed-off-by: Heinrich Schuchardt

arm: bcm235xx: clk_set_rate avoid possible NULL deref

2017-08-13T19:17:27+00:00

It does not make sense first to dereference c and then
to check if it is NULL.

Signed-off-by: Heinrich Schuchardt

arm: bcm235xx: avoid possible NULL dereference

2017-08-13T19:17:26+00:00

It does not make sense to first dereference c and then
check if it is NULL.

Signed-off-by: Heinrich Schuchardt