summaryrefslogtreecommitdiff
path: root/arch/arm/mach-bcm283x
Commit message (Collapse)AuthorAgeLines
* dm: select CONFIG_DM* optionsMasahiro Yamada2015-04-18-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: bcm2835: use phys_to_bus() for mboxStephen Warren2015-04-14-2/+3
| | | | | | | | 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>
* ARM: bcm2835: implement phys_to_bus/bus_to_physStephen Warren2015-04-14-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: rpi: add a couple more revision IDsStephen Warren2015-04-13-1/+3
| | | | | | | | | | | | 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>
* ARM: bcm283x: move SoC headers to mach-bcm283x/include/machMasahiro Yamada2015-03-28-1/+678
| | | | | | | | 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>
* ARM: bcm283x: merge BCM2835/BCM2836 directories into mach-bcm283xMasahiro Yamada2015-03-28-0/+337
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>