Commit graph

7 commits

Author SHA1 Message Date
Joe Hershberger
a26cd04920 arch: Make board selection choices optional
By making the board selections optional, every defconfig will include
the board selection when running savedefconfig so if a new board is
added to the top of the list of choices the former top's defconfig will
still be correct.

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tom Rini <trini@konsulko.com>
2015-05-12 18:10:02 -04:00
Masahiro Yamada
58d423b88e dm: select CONFIG_DM* options
As mentioned in the previous commit, adding default values in each
Kconfig causes problems because it does not co-exist with the
"depends on" syntax.  (Please note this is not a bug of Kconfig.)
We should not do so unless we have a special reason.  Actually,
for CONFIG_DM*, we have no good reason to do so.

Generally, CONFIG_DM is not a user-configurable option.  Once we
convert a driver into Driver Model, the board only works with Driver
Model, i.e. CONFIG_DM must be always enabled for that board.
So, using "select DM" is more suitable rather than allowing users to
modify it.  Another good thing is, Kconfig warns unmet dependencies
for "select" syntax, so we easily notice bugs.

Actually, CONFIG_DM and other related options have been added
without consistency: some into arch/*/Kconfig, some into
board/*/Kconfig, and some into configs/*_defconfig.

This commit prefers "select" and cleans up the following issues.

[1] Never use "CONFIG_DM=n" in defconfig files

It is really rare to add "CONFIG_FOO=n" to disable CONFIG options.
It is more common to use "# CONFIG_FOO is not set".  But here, we
do not even have to do it.
Less than half of OMAP3 boards have been converted to Driver Model.
Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is
weird.  Instead, add "select DM" only to appropriate boards, which
eventually eliminates "CONFIG_DM=n", etc.

[2] Delete redundant CONFIGs

Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again
in configs/sandbox_defconfig.
Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and
defines it also in omap3_beagle_defconfig and devkit8000_defconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-04-18 11:11:30 -06:00
Stephen Warren
122426d46e ARM: bcm2835: use phys_to_bus() for mbox
When we communicate with the VideoCore to perform property mailbox
transactions, that is a DMA operation as far as the property buffer
is concerned. Use phys_to_bus() on that buffer.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
79340db7f1 ARM: bcm2835: implement phys_to_bus/bus_to_phys
The BCM283[56] contain both a L1 and L2 cache between the GPU (a/k/a
VideoCore CPU?) and DRAM. DMA-capable peripherals can also optionally
access DRAM via this same  L2 cache (although they always bypass the L1
cache). Peripherals select whether to use or bypass the cache via the
top two bits of the bus address.

An IOMMU exists between the ARM CPU and the rest of the system. This
controls whether the ARM CPU's accesses use or bypass the L1 and/or L2
cache. This IOMMU is configured/controlled exclusively by the VideoCore
CPU.

In order for DRAM accesses made by the ARM core to be coherent with
accesses made by other DMA peripherals, we must program a bus address
into those peripherals that causes the peripheral's accesses to use the
same set of caches that the ARM core's accesses will use.

On the RPi1, the VideoCore firmware sets up the IOMMU to enable use of
the L2 cache. This corresponds to addresses based at 0x40000000.

On the RPi2, the VideoCore firmware sets up the IOMMU to disable use of
the L2 cache. This corresponds to addresses based at 0xc0000000.

This patch implements U-Boot's phys_to_bus/bus_to_phys APIs according
to those rules.

For full details of this setup, please see Dom Cobley's description at:
http://lists.denx.de/pipermail/u-boot/2015-March/208201.html
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/215038
https://www.mail-archive.com/u-boot@lists.denx.de/msg166568.html

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
787affb41b ARM: rpi: add a couple more revision IDs
According to Gordon Henderson's WiringPi library, there are some more
Pi revision IDs out there. Add support for them.

http://git.drogon.net/?p=wiringPi;a=blob_plain;f=wiringPi/wiringPi.c;hb=5edd177112c99416f68ba3e8c6c4db6ed942e796

At least ID 0x13 is out in the wild:

Reported-by: Chee-Yang Chau <cychau@gmail.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-13 08:48:36 -04:00
Masahiro Yamada
d6c418e4b8 ARM: bcm283x: move SoC headers to mach-bcm283x/include/mach
Move arch/arm/include/asm/arch-bcm283x/*
  -> arch/arm/mach-bcm283x/include/mach/*

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-03-28 09:03:09 -04:00
Masahiro Yamada
ddf6bd4876 ARM: bcm283x: merge BCM2835/BCM2836 directories into mach-bcm283x
BCM2835 (used on Raspberry Pi) and BCM2836 (used on Raspberry Pi 2)
are similar enough.  One of the biggest differences is the ARM
processor.  It is reasonable to collect the source files into a
single place, arch/arm/mach-bcm283x/.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-03-28 09:03:09 -04:00