aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2015-07-24Merge git://git.denx.de/u-boot-usbTom Rini
2015-07-24arm: marvell: Increase MAXARGS to 32Stefan Roese
This makes more complex U-Boot scripts possible. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-07-24arm: mvebu: db-88f6820-gp: Add SDIO/MMC SPL boot supportStefan Roese
This patch adds the configuration options to boot via SDIO/MMC on the Marvell DB-88F6820-GP Armada A38x board. The default boot device is still SPI NOR flash. To enable MMC booting on this board 2 things need to be changes: a) Change kwbimage.cfg BOOT_FROM sdio b) In the config header select #define CONFIG_SPL_BOOT_DEVICE SPL_BOOT_SDIO_MMC_CARD The generated image needs to be copied to the first bootable MMC partition: dd if=u-boot-spl.kwb of=/dev/sdX1 Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Dirk Eibach <eibach@gdsys.de>
2015-07-23Merge git://git.denx.de/u-boot-uniphierTom Rini
2015-07-23ARM: UniPhier: add PH1-sLD3 SoC supportMasahiro Yamada
The init code for UMC (Unified Memory Controller) and PLL has not been mainlined yet, but U-boot proper should work. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-07-23ARM: UniPhier: update CONFIG_BOOTARGSMasahiro Yamada
Both "earlyprintk" and "loglevel=8" should be useful for the development. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-07-23ARM: UniPhier: add environment variable for TFTP bootMasahiro Yamada
The command "run tftpboot" downloads some files onto the RAM via TFTP and boots the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-07-23ARM: UniPhier: add environment sets for non-FIT Linux bootMasahiro Yamada
Currently, the environment variables "norboot" and "nandboot" only work with CONFIG_FIT, but we do not want to depend on CONFIG_FIT to boot the kernel. This commit adds environments useful for booting Linux with separate uImage + ramdisk + DTB. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-07-23Merge git://git.denx.de/u-boot-marvellTom Rini
2015-07-23arm: mvebu: db-88f6820: Add SPL support with DDR init codeStefan Roese
This patch adds SPL support for the Marvell DB-88F6820-GP board. With this change, the bin_hdr from the original Marvell U-boot is not needed any more on this board. The sources from bin_hdr (SERDES/PHY and DDR setup) are now integrated in mainline U-Boot. And this patch enables them for this board. Signed-off-by: Stefan Roese <sr@denx.de>
2015-07-23arm: mvebu: drivers/ddr: Move Armada XP DDR init code into new directoryStefan Roese
With the upcoming addition of the Armada 38x DDR support, which is not compatible to the Armada XP DDR init code, we need to introduce a new directory infrastructure. To support multiple Marvell DDR controller. This will be the new structure: drivers/ddr/marvell/axp Supporting Armada XP (AXP) devices (and perhaps Armada 370) drivers/ddr/marvell/a38x Supporting Armada 38x devices (and perhaps Armada 39x) Signed-off-by: Stefan Roese <sr@denx.de>
2015-07-23arm: mvebu: add Armada XP SATA supportAnton Schubert
This patch initializes the SATA address windows on Armada XP and allows it to work with the existing mvsata_ide driver. It also adds the necessary configuration for the db-mv784mp-gp board. Signed-off-by: Anton Schubert <anton.schubert@gmx.de> Tested-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-07-22linux_compat: handle __GFP_ZERO in kmalloc()Masahiro Yamada
Currently, kzalloc() returns zero-filled memory, while kmalloc() simply ignores the second argument and never fills the memory area with zeros. I want kmalloc(size, __GFP_ZERO) to behave as kzalloc() does, which will make it easier to add more memory allocator variants. With the introduction of __GFP_ZERO flag, going forward, kzmalloc() variants can fall back to kmalloc() enabling the __GFP_ZERO flag. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Simon Glass <sjg@chromium.org> Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
2015-07-22linux_compat: move vzalloc() to header file as an inline functionMasahiro Yamada
The vzalloc(size) is equivalent to kzalloc(size, 0). Move it to include/linux/compat.h as an inline function in order to avoid the function call overhead. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-22linux_compat: remove cpu_relax() defineMasahiro Yamada
The macro cpu_relax() is defined by several headers in different ways. arch/{arm,avr32,mips}/include/asm/processor.h defines it as follows: #define cpu_relax() barrier() On the other hand, include/linux/compat.h defines it as follows: #define cpu_relax() do {} while (0) If both headers are included from the same source file, the warning warning: "cpu_relax" redefined [enabled by default] is displayed. It effectively makes it impossible to include <linux/compat.h> from some sources. Drop the latter. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Simon Glass <sjg@chromium.org> Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
2015-07-22usb: CONFIG_USB_FASTBOOT prefix replacement for consistencyPaul Kocialkowski
FASTBOOT is defined both by CONFIG_USB_FUNCTION_FASTBOOT AND CONFIG_CMD_FASTBOOT, so it doesn't make much sense to have a CONFIG_USB_FASTBOOT prefix for fastboot-specific options, especially given that other config options for fastboot use the CONFIG_FASTBOOT prefix. This replaces the CONFIG_USB_FASTBOOT prefix with CONFIG_FASTBOOT, for consistency. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2015-07-22implement Fastboot via USB OTG on bcm28155_ap boardsJiandong Zheng
Signed-off-by: Jiandong Zheng <jdzheng@broadcom.com> Signed-off-by: Steve Rae <srae@broadcom.com>
2015-07-22g_dnl: add missing declarationSteve Rae
Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> Test HW: Exynos 4210 (trats), Exynos 5422 (Odroid XU3)
2015-07-22usb: board_usb_init and board_usb_cleanup calls in the fastboot commandPaul Kocialkowski
Each USB download function command calls board_usb_init before registering the USB gadget and board_usb_cleanup after de-registering it. On devices currently using fasboot, musb-new is usually initialized earlier, but some other boards might need the board_usb_init call to properly initialize musb-new. This requires adding an argument (the USB controller index) to the fastboot command, as it is currently done with other USB download gadget functions. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Tested-by: Lukasz Majewski <l.majewski@samsung.com> Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
2015-07-22usb: Fastboot function config for better consistency with other functionsPaul Kocialkowski
USB download gadget functions such as thor and dfu have a separate config option for the USB gadget part of the code, independent from the command part. This switches the fastboot USB gadget to the same scheme, for better consistency. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Tested-by: Lukasz Majewski <l.majewski@samsung.com> Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
2015-07-22usb: USB download gadget and functions config options coherent namingPaul Kocialkowski
This introduces a coherent scheme for naming USB download gadget and functions config options. The download USB gadget config option is moved to CONFIG_USB_GADGET_DOWNLOAD for better consistency with other gadgets and each function's config option is moved to a CONFIG_USB_FUNCTION_ prefix. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Tested-by: Lukasz Majewski <l.majewski@samsung.com> Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
2015-07-22include: usb: Map USB controller base addresses for LS2085ANikhil Badola
Map USB XHCI controller base addresses for LS2085A SOC Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
2015-07-22include: usb: Move USB controller base address mappingNikhil Badola
Move USB controller Base address mapping from ls102xa immap to fsl xhci header. This is required to remove any warnings when controller base addresses are mapped for multiple platforms in their respective files. Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
2015-07-22drivers: usb: fsl: Implement Erratum A-009116 for XHCI controllerNikhil Badola
This adjusts (micro)frame length to appropriate value thus avoiding USB devices to time out over a longer run Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
2015-07-22ls1021aqds: Enable USB IP supportRamneek Mehresh
Enable USB IP support for both EHCI and XHCI for ls1021aqds platform Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
2015-07-22ls1021atwr: Enable USB IP supportRamneek Mehresh
Enable USB IP support for both EHCI and XHCI for ls1021atwr platform Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
2015-07-22usb: fsl: Add XHCI driver supportRamneek Mehresh
Add xhci driver support for all FSL socs Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
2015-07-22usb: xhci: keystone: Remove common dwc3 drv functions callsRamneek Mehresh
Remove all redundant dwc3 driver function calls that are defined by dwc3 driver Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
2015-07-22usb: xhci: omap: Remove common dwc3 drv functions callsRamneek Mehresh
Remove all redundant dwc3 driver function calls that are defined by dwc3 driver Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
2015-07-22usb: xhci: exynos: Remove common dwc3 drv functions callsRamneek Mehresh
Remove all redundant dwc3 driver function calls that are defined by dwc3 driver Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
2015-07-22usb: dwc3: Add DWC3 controller driver supportRamneek Mehresh
Add support for DWC3 XHCI controller driver Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
2015-07-21net: Allow drivers to return -ENOSYS with the write_hwaddr() methodSimon Glass
Some drivers may want to implement this method for some of their devices but not for others. So it is not possible to just leave the operation out of the table. Drivers could get around this by masquerading as two separate drivers but that seems unpleasant. Allow the driver to return an error when it does not want to process the write_hwaddr() method. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21x86: minnowmax: Drop the cache line size hackSimon Glass
Now that the RTL8169 driver warning is fixed we can drop this. The incorrect value is causing problems with USB EHCI. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-07-21dm: usb: Adjust the USB_DEVICE() macro namingSimon Glass
In Linux USB_DEVICE() is used to declare a USB device by vendor/device ID. We should follow the same convention in U-Boot. Rename the existing USB_DEVICE() macro to U_BOOT_USB_DEVICE() and bring in the USB_DEVICE() macro from Linux for use in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: usb: eth: Support driver model with USB EthernetSimon Glass
At present USB Ethernet does not work with CONFIG_DM_ETH. Add driver model support to this feature, so that it can work alongside other Ethernet devices with driver model. It was found that quite a bit of code is common in most of the USB Ethernet drivers. Add this code to the common layer to reduce the amount of duplicate code needed in USB Ethernet drivers when CONFIG_DM_ETH is used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de>
2015-07-21dm: eth: Avoid blocking on packet receptionSimon Glass
Some devices can take a long time to work out whether they have a new packet or now. For example the ASIX USB Ethernet dongle can take 5 seconds to do this, since it waits until it gets a new packet on the wire before allowing the USB bulk read packet to be submitted. At present with driver mode the Ethernet receive code reads 32 packets. This can take a very long time if we must wait for all 32 packets. The old code (before driver model) worked by reading a single set of packets from the USB device, then processing all the packets with in. It would be nice to use the same behaviour with driver model. Add a flag to the receive method which indicates that the driver should try to find a packet if available, by consulting the hardware. When the flag is not set, it should just return any packet data it has already received. If there is none, it should return -EAGAIN so that the loop will terminate. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: usb: Correct the struct usb_driver_entry commentSimon Glass
The function documentation is incorrect. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de>
2015-07-21dm: pci: Add a function to get the BDF for a deviceSimon Glass
It is useful to be able to find the full PCI address (bus, device and function) for a PCI device. Add a function to provide this. Adjust the existing code to use this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: pci: Add support for PCI driver matchingSimon Glass
At present all PCI devices must be present in the device tree in order to be used. Many or most PCI devices don't require any configuration other than that which is done automatically by U-Boot. It is inefficent to add a node with nothing but a compatible string in order to get a device working. Add a mechanism whereby PCI drivers can be declared along with the device parameters they support (vendor/device/class). When no suitable driver is found in the device tree the list of such devices is consulted to determine the correct driver. If this also fails, then a generic driver is used as before. The mechanism used is very similar to that provided by Linux and the header file defintions are copied from Linux 4.1. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
2015-07-21dm: usb: Allow usb host drivers to implement usb_reset_root_portHans de Goede
Allow usb uclass host drivers to implement usb_reset_root_port, this is used by single port usb hosts which do not emulate a hub, such as otg controllers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: Export device_remove_children / device_unbind_childrenHans de Goede
These functions are useful to remove all children from an usb bus before rescanning the bus. Give them a better name and export them. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-21usb: Add an usb_device parameter to usb_reset_root_portHans de Goede
Add an usb_device parameter to usb_reset_root_port so that it knows which root-port it is resetting. This is necessary for proper device-model support for usb_reset_root_port. Also remove a duplicate declaration of usb_reset_root_port() from usb.h . Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-21usb: usb_setup_device: Drop unneeded portnr function argumentHans de Goede
Drop the unneeded portnr function argument, the portnr is part of the usb_device struct which is passed via the dev argument. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-21usb: Drop device-model specific copy of usb_legacy_port_resetHans de Goede
The device-model usb_legacy_port_reset function calls the device-model usb_port_reset function which is a 1 on 1 copy of the non dm usb_legacy_port_reset and this is the only use of usb_port_reset in all of u-boot. Drop both, and alway use the usb_legacy_port_reset() version in common/usb.c . Also while at it make it static as it is only used in common/usb.c . Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-21test: Add a macro to check that a value is not an error pointerSimon Glass
Some functions can return ERR_PTR(errval). Add a unit test macro to check that no error is returned in a pointer. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21led: Return -ENODEV if the LED device cannot be foundSimon Glass
We normally use -ENODEV for a missing device, rather than -ENOENT. The latter is reserved for when we have a device but cannot find something within it. Also avoid looking at the root LED device since it is only a container. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: reset: Allow reset_walk() to returnSimon Glass
Add a new reset_walk_halt() function to cause a reset and then halt on failure. The reset_walk() function returns an error code. This is needed for testing since otherwise U-Boot will halt in the middle of a test. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: Add platform data advice and admonishmentSimon Glass
We should guide people more strongly towards device tree to avoid the proliferation of platform data structures. Add documentation to the driver model README, and also the platform data header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: Add a clock uclassSimon Glass
Clocks are an important feature of platforms and have become increasing complex with time. Most modern SoCs have multiple PLLs and dozens of clock dividers which distribute clocks to on-chip peripherals. Some SoC implementations have a clock API which is private to that SoC family, e.g. Tegra and Exynos. This is useful but it would be better to have a common API that can be understood and used throughout U-Boot. Add a simple clock API as a starting point. It supports querying and setting the rate of a clock. Each clock is a device. To reduce memory and processing overhead the concept of peripheral clocks is provided. These do not need to be explicit devices - it is possible to write a driver that can adjust the I2C clock (for example) without an explicit I2C clock device. This can dramatically reduce the number of devices (and associated overhead) in a complex SoC. Clocks are referenced by a number, and it is expected that SoCs will define that numbering themselves via an enum. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-21dm: Add a system reset uclassSimon Glass
It is common for system reset to be available at multiple levels in modern hardware. For example, an SoC may provide a reset option, and a board may provide its own reset for reasons of security or thoroughness. It is useful to be able to model this hardware without hard-coding the behaviour in the SoC or board. Also there is a distinction sometimes between resetting just the CPU (leaving GPIO state alone) and resetting all the PMICs, just cutting power. To achieve this, add a simple system reset uclass. It allows multiple devices to provide reset functionality and provides a way to walk through them, requesting a particular reset type until is it provided. Signed-off-by: Simon Glass <sjg@chromium.org>