- Apr 18, 2015
-
-
Masahiro Yamada authored
Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Masahiro Yamada authored
Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Masahiro Yamada authored
Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Masahiro Yamada authored
All the Zynq boards have switch to Driver Model. "select DM" is better than default value in each defconfig. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Masahiro Yamada authored
All the UniPhier boards have switch to Driver Model. "select DM" is better than default value in each defconfig. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Masahiro Yamada authored
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>
-
Simon Glass authored
Since we can support both controllers now, enable this in the device tree. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Simon Glass authored
Convert Exynos boards over to use driver model for USB. This does not remove any unnecessary code so far. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Simon Glass authored
These are needed to enable the USB bus (although not sufficient since it still does not work). Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Haikun.Wang@freescale.com authored
Add QSPI controller dts node in ls1021a.dtsi. Add QSPI slave device dts node in ls1021a-twr.dts and ls1021a-qds.dts. Signed-off-by:
Haikun Wang <Haikun.Wang@freescale.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Haikun.Wang@freescale.com authored
Update DSPI controller node in ls1021a.dtsi. Update flash device node in ls1021a-qds.dts. Ls1021a-twr board doesn't support DSPI, so remove DSPI node in ls1021a-twr.dts. Signed-off-by:
Haikun Wang <Haikun.Wang@freescale.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
haikun authored
Change address_cells and size_cells of root node and 'soc' node from 2 to 1. We backport ls1021a device tree source files from kernel to u-boot. Kernel files set address_cells and size_cells to 2 in order to access more than 4GB space. But we don't have this requirement now and u-boot fdtdec_get_xxx interfaces can't support property whose size is 'u64' completely. So make this change. Signed-off-by:
Haikun Wang <Haikun.Wang@freescale.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
haikun authored
Bring in required device tree files for ls1021a from Linux. These are initially unchanged and have a number of pieces not needed by U-Boot. Signed-off-by:
Haikun Wang <Haikun.Wang@freescale.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Haikun.Wang@freescale.com authored
Backport of kernel commits: 7c14f6c719de092d69c81877786e83ce7ae1a860 35faad2a1563b3d4dc983a82ac41033fe053870c Signed-off-by:
Haikun Wang <Haikun.Wang@freescale.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
The U-Boot device trees are slightly different in a few places. Adjust them to remove most of the differences. Note that U-Boot does not support the concept of interrupts as distinct from GPIOs, so this difference remains. For sandbox, use the same keyboard file as for ARM boards and drop the host emulation bus which seems redundant. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Joe Hershberger authored
This value is not used by the network stack and is available in the global data, so stop passing it around. For the one legacy function that still expects it (init op on old Ethernet drivers) pass in the global pointer version directly to avoid changing that interface. Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com> Reported-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Simon Glass <sjg@chromium.org> (Trival fix to remove an unneeded variable declaration in 4xx_enet.c)
-
Joe Hershberger authored
In the case where the arch defines a custom map_sysmem(), make sure that including just mapmem.h is sufficient to have these functions as they are when the arch does not override it. Also split the non-arch specific functions out of common.h Signed-off-by:
Joe Hershberger <joe.hershberger@ni.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
- Apr 16, 2015
-
-
Kishon Vijay Abraham I authored
Commit d3cfcb3e (ARM: DRA7: Enable clocks for USB OTGSS and USB PHY) changed the member names of prcm_regs from cm_l3init_usb_otg_ss_clkctrl to cm_l3init_usb_otg_ss1_clkctrl and from cm_coreaon_usb_phy_core_clkctrl to cm_coreaon_usb_phy1_core_clkctrl in order to differentiate between the two dwc3 controllers present in dra7xx/am43xx and enabled these clocks in enable_basic_clocks() in hw_data.c. However these clocks continued to be enabled in board files/driver files for dwc3 host mode functionality causing compilation break with few configs. Fixed it here by making all the clocks enabled in enable_basic_clocks() and removing it from board files/driver files here. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com>
-
- Apr 15, 2015
-
-
Paul Kocialkowski authored
Sunxi platforms come with at least 3 TWI (I2C) controllers and some platforms even have up to 5. This adds support for every controller on each supported platform, which is especially useful when using expansion ports on single-board- computers. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Paul Kocialkowski authored
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI controller. However, other platforms using MVTWSI may come with more: this is the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found on the same chip. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Heiko Schocher <hs@denx.de> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Hans de Goede authored
When u-boot boots the board may be powering vbus, we turn off vbus in sunxi_usbc_request_resources, if we are too quick with reading vusb-detect after this we may see a residual charge and assume we've an external vusb connected even though we do not. So when we see an external vusb wait a bit and try again. Without this when dealing with a pmic controller vbus and doing "reset" on the u-boot console the musb host will only init once every other boot, because the other boot it thinks an external vbus is present, this commit fixes this. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Ian Campbell <ijc@hellion.org.uk>
-
Hans de Goede authored
On boards which use the pmic to enable/disable vbus on the otg port, the vbus value is not reset to 0 on reset, as reset only resets the SoC and not the pmic, so explicitly set vbus to 0 on init (request_resources) by moving the gpio_direction_output call into request_resources. For consistency also move the gpio_direction_input call for vbus-detect into request_resources. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Ian Campbell <ijc@hellion.org.uk>
-
Paul Kocialkowski authored
Sunxi platforms have different possible mmc pin mux setups (except for mmc0), which are different across platforms. This lets users configure which is used through the CONFIG_MMC*_PINS Kconfig options. This is especially relevant when a second (in addition to mmc0) port is used and CONFIG_MMC_SUNXI_SLOT_EXTRA is enabled. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Paul Kocialkowski authored
Each hardware feature exposed through the GPIO pin mux is usually using the same function index (for a given port), so there is no need to define one value per pin: one value per hardware feature per port is sufficient, avoids duplication and makes everything easier to understand. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Paul Kocialkowski authored
VBUS detection could be needed not only by the musb code (to prevent host mode), but also by e.g. gadget drivers to start only when a cable is connected. In addition, this allows more flexibility in vbus detection, as it could easily be extended to other USBC indexes. Eventually, this would help making musb support independent from a hardcoded USB controller index (0). Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Paul Kocialkowski authored
VBUS detection and enable is now be used with virtual AXP GPIOs, so all the USB code has to use GPIO in every case and let sunxi_gpio do the heavy lifting. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Paul Kocialkowski authored
This converts the VBUS detection and enable logic to GPIO instead of separate axp functions and checks that have to be used aside usual GPIO functions. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Paul Kocialkowski authored
Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
- Apr 14, 2015
-
-
Kishon Vijay Abraham I authored
Implemented board_usb_init(), board_usb_cleanup() and usb_gadget_handle_interrupts() in am43xx board file that can be invoked by various gadget drivers. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Lukasz Majewski <l.majewski@samsung.com>
-
Kishon Vijay Abraham I authored
Implemented board_usb_init(), board_usb_cleanup() and usb_gadget_handle_interrupts() in dra7xx board file that can be invoked by various gadget drivers. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Lukasz Majewski <l.majewski@samsung.com>
-
Kishon Vijay Abraham I authored
Added resource_size_t type in order to get rid of the following compilation error whiel building dwc3 gadget. include/linux/ioport.h:19:2: error: unknown type name ‘resource_size_t’ Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Lukasz Majewski <l.majewski@samsung.com>
-
Kishon Vijay Abraham I authored
Added dma_free_coherent corresponding to the dma_alloc_coherent in dma-mapping.h in order to free memory allocated using dma_alloc_coherent. This API is used in dwc3 driver. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Lukasz Majewski <l.majewski@samsung.com>
-
Kishon Vijay Abraham I authored
Fixed the following warning here. "warning: ‘dma_alloc_coherent’ defined but not used" while compiling udc-core Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Lukasz Majewski <l.majewski@samsung.com>
-
Kishon Vijay Abraham I authored
Enabled clocks for dwc3 controller and USB PHY present in AM43xx. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Lukasz Majewski <l.majewski@samsung.com>
-
Kishon Vijay Abraham I authored
Enabled clocks for dwc3 controller and USB PHY present in DRA7. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Lukasz Majewski <l.majewski@samsung.com>
-
Stephen Warren authored
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>
-
Stephen Warren authored
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>
-
- Apr 13, 2015
-
-
Pavel Machek authored
Add an error in known-bad case so that we don't produce broken and hard to debug binaries. Signed-off-by:
Pavel Machek <pavel@denx.de>
-
Stephen Warren authored
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>
-
- Apr 11, 2015
-
-
Masahiro Yamada authored
Since commit 79d75d75 (ARM: move -march=* and -mtune= options to arch/arm/Makefile), all the Tegra boards are broken because the SPL is built for ARMv7. Insert Tegra-specific code to arch/arm/Makefile to set compiler flags for an earlier ARM architecture. Note: The v1 patch for commit 79d75d75 *was* correct when it was submitted. Notice it was originally written for multi .config configuration where Kconfig set CONFIG_CPU_V7/CONFIG_CPU_ARM720T for Tegra U-Boot Main/SPL, respectively. But, until it was merged into the mainline, commit e02ee254 (kconfig: switch to single .config configuration) had been already applied there. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by:
Stephen Warren <swarren@nvidia.com> Reported-by:
Jan Kiszka <jan.kiszka@siemens.com> Tested-by:
Jan Kiszka <jan.kiszka@siemens.com>
-