summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* dm: tpm: Drop CONFIG_DM_TPMSimon Glass2015-10-232-13/+4
| | | | | | | | Now that all TPM drivers use driver model, we can drop the special driver model CONFIG option. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Christophe Ricard<christophe-h.ricard@st.com>
* dm: tpm: Every TPM drivers should depends on DM_TPMChristophe Ricard2015-10-231-3/+3
| | | | | | | | Every TPM drivers should now depends on DM_TPM and not only TPM. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: tpm: Remove every compilation switch for TPM driver modelChristophe Ricard2015-10-232-2/+0
| | | | | | | | | | | As every TPM drivers support UCLASS_TPM, we can only rely on DM_TPM functions. This simplify a bit the code. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: tpm: Add Driver Model support for tpm_atmel_twi driverChristophe Ricard2015-10-232-19/+51
| | | | | | | | tpm_atmel_twi can fit perfectly to the new UCLASS_TPM class. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: tpm: Move tpm_tis_i2c to tpm_i2c_infineonChristophe Ricard2015-10-234-5/+5
| | | | | | | | | | As there is no TCG specification or recommendation for i2c TPM 1.2, move tpm_tis_i2c driver to tpm_i2c_infineon. Other tpm vendors like Atmel or STMicroelectronics may have a different transport protocol for i2c. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
* dm: Rename dev_get_parentdata() to dev_get_parent_priv()Simon Glass2015-10-2314-29/+29
| | | | | | | | The current name is inconsistent with other driver model data access functions. Rename it and fix up all users. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
* drivers: gpio: omap: add support for parsing additional gpio parametersMugunthan V N2015-10-221-0/+11
| | | | | | | | | | | | | With DM_GPIO, gpio parameters like ACTIVE_(LOW/HIGH) are to be parsed in xlate gpio drivers-ops. Since xlate is not implemented in omap_gpio driver, the driver considers all gpio to be ACTIVE_HIGH which is the default case and fails to return actual gpio status for ACTIVE_LOW gpios. So adding .xlate ops to omap_gpio. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* drivers: serial: serial_omap: add comaptibles for all ti platformsMugunthan V N2015-10-221-0/+4
| | | | | | | Adding compatibles for am335x, am437x and dra7 platforms. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
* drivers: serial: serial_omap: populate default clock frequency when not ↵Mugunthan V N2015-10-221-1/+3
| | | | | | | | | | | found in dt In some platforms like am437x, serial node is not populated with clock-frequency node. So in that case have a default clock-clock frequency. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
* drivers: mmc: omap_hsmmc: convert driver to adopt device driver modelMugunthan V N2015-10-221-1/+116
| | | | | | adopt omap_hsmmc driver to device driver model Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
* ARM: k2g: add SD card and eMMC supportRoger Quadros2015-10-221-2/+5
| | | | | | | | Add MMC support for k2g Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
* driver: net: keystone_net: removing unused codeMugunthan V N2015-10-221-10/+0
| | | | | | | | remove unused code as the same is achieved when configuring sgmii and link status is verifed. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* driver: net: keystone_net: add support for rgmii phyVitaly Andrianov2015-10-221-1/+43
| | | | | | | | | In K2G, Ethernet doesn't support SGMII instead it support RGMII, adding support to the driver to connect to RGMII phy. Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* dma: keystone_nav: Fix linkram sizeVitaly Andrianov2015-10-221-1/+1
| | | | | | | | Fix Linkram size. Signed-off-by: Vitaly Andrianov <vitalya@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* driver: net: keystone_net: fix phy mode configurationMugunthan V N2015-10-221-2/+2
| | | | | | | | | | Phy mode is a board property and it can be different between multiple board and ports, so it should not be hardcoded in driver to one specific mode. So adding a field in eth_priv_t structure to pass phy mode to driver. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* remoteproc: Introduce a sandbox dummy driverNishanth Menon2015-10-223-0/+348
| | | | | | | | | | | | | | | Introduce a dummy driver for sandbox that allows us to verify basic functionality. This is not meant to do anything functional - but is more or less meant as a framework plumbing debug helper. The sandbox remoteproc driver maintains absolutey no states and is a simple driver which just is filled with empty hooks. Idea being to give an approximate idea to implement own remoteproc driver using this as a template. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
* drivers: Introduce a simplified remoteproc frameworkNishanth Menon2015-10-225-0/+442
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many System on Chip(SoC) solutions are complex with multiple processors on the same die dedicated to either general purpose of specialized functions. Many examples do exist in today's SoCs from various vendors. Typical examples are micro controllers such as an ARM M3/M0 doing a offload of specific function such as event integration or power management or controlling camera etc. Traditionally, the responsibility of loading up such a processor with a firmware and communication has been with a High Level Operating System(HLOS) such as Linux. However, there exists classes of products where Linux would need to expect services from such a processor or the delay of Linux and operating system being able to load up such a firmware is unacceptable. To address these needs, we need some minimal capability to load such a system and ensure it is started prior to an Operating System(Linux or any other) is started up. NOTE: This is NOT meant to be a solve-all solution, instead, it tries to address certain class of SoCs and products that need such a solution. A very simple model is introduced here as part of the initial support that supports microcontrollers with internal memory (no MMU, no execution from external memory, or specific image format needs). This basic framework can then (hopefully) be extensible to other complex SoC processor support as need be. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Simon Glass <sjg@chromium.org>
* drivers: net: cpsw: convert driver to adopt device driver modelMugunthan V N2015-10-221-1/+244
| | | | | | | adopt cpsw driver to device driver model Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* drivers: net: cpsw: prepare driver for device model migrationMugunthan V N2015-10-221-44/+89
| | | | | | | prepare driver for device model migration Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* Merge git://git.denx.de/u-boot-x86Tom Rini2015-10-2110-50/+89
|\
| * dm: rtc: Correct rtc_read32() return valueSimon Glass2015-10-211-1/+1
| | | | | | | | | | | | | | | | The current check is incorrect and will fail when any non-zero byte is read. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * rtc: mc146818: Use probe() to set up the deviceSimon Glass2015-10-211-2/+2
| | | | | | | | | | | | | | At present this driver uses bind() to set up the device. The bind() method should not touch the hardware, so move the init code to probe(). Signed-off-by: Simon Glass <sjg@chromium.org>
| * rtc: mc146818: Add a comment to the #endifSimon Glass2015-10-211-1/+1
| | | | | | | | | | | | | | Add a comment to make it clear to which block the #endif relates. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * debug_uart: Add an option to announce the debug UARTSimon Glass2015-10-211-0/+10
| | | | | | | | | | | | | | | | | | It is useful to see a message from the debug UART early during boot so that you know things are working. Add an option to enable this. The message will be displayed as soon as debug_uart_init() is called. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * debug_uart: Support board-specific UART initialisationSimon Glass2015-10-211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Some boards need to set things up before the debug UART can be used. On these boards a call to debug_uart_init() is insufficient. When this option is enabled, the function board_debug_uart_init() will be called when debug_uart_init() is called. You can put any code here that is needed to set up the UART ready for use, such as set pin multiplexing or enable clocks. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * debug_uart: Adjust the declaration of debug_uart_init()Simon Glass2015-10-213-3/+3
| | | | | | | | | | | | | | | | | | | | | | We want to be able to add other common code to this function. So change the driver's version to have an underscore before it, just like _debug_uart_putc(). Define debug_uart_init() to call this version. Update all drivers to this new method. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: spi: Add support for Wildcat PointGeorge McCollister2015-10-211-1/+2
| | | | | | | | | | | | | | Add the Wildcat Point ID so Broadwell U based boards can use SPI. Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * dm: pci: Enable VGA address forwarding on bridgesBin Meng2015-10-211-0/+18
| | | | | | | | | | | | | | | | | | To support graphics card behind a PCI bridge, the bridge control register (offset 0x3e) in the configuration space must turn on VGA address forwarding. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * dm: pci: Fix pci_last_busno() to return the real last bus noBin Meng2015-10-211-24/+1
| | | | | | | | | | | | | | | | | | Currently pci_last_busno() only checks the last bridge device under the first UCLASS_PCI device. This is not the case when there are multiple bridge devices. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * video: vesa_fb: Fix wrong return value check of pci_find_class()Bin Meng2015-10-211-1/+1
| | | | | | | | | | | | | | | | | | When pci_find_class() fails to find a device, it returns -ENODEV. But now we check the return value against -1. Fix it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
| * pci: Set PCI_COMMAND_IO bit for VGA deviceBin Meng2015-10-211-0/+6
| | | | | | | | | | | | | | | | PCI_COMMAND_IO bit must be set for VGA device as it needs to respond to legacy VGA IO address. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * dm: pci: Adjust pci_find_and_bind_driver() to return -EPERMSimon Glass2015-10-211-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The current code returns 0 even if it failed to find or bind a driver. The caller then has to check the returned device to see if it is NULL. It is better to return an error code in this case so that it is clear what happened. Adjust the code to return -EPERM, indicating that the device was not bound because it is not needed for pre-relocation use. Add comments so that the return value is clear. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * dm: pci: Correct a few debug() statementsSimon Glass2015-10-211-2/+2
| | | | | | | | | | | | | | | | One debug() statement is missing a newline. The other has a repeated word. Fix these. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * dm: pci: Tidy up auto-config error handlingSimon Glass2015-10-211-3/+12
| | | | | | | | | | | | | | | | | | | | | | When the auto-configuration process fails for a device (generally due to lack of memory) we should return the error correctly so that we don't continue to try memory allocations which will fail. Adjust the code to check for errors and abort if something goes wrong. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* | Merge git://git.denx.de/u-boot-marvellTom Rini2015-10-205-16/+168
|\ \
| * | mmc: mv_sdhci: Configure the SDHCI MBUS bridge windowsStefan Roese2015-10-211-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver did not yet configure the SDHCI MBUS bridge registers. Without this and with CONFIG_MMC_SDMA enabled, mmc hangs at random times. As DMA cannot complete correctly. Tested on db-88f6820-gp eval board. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Dirk Eibach <eibach@gdsys.cc> Tested-by: Kevin Smith <kevin.smith@elecsyscorp.com>
| * | usb: ehci-marvell.c: Add DM supportStefan Roese2015-10-212-16/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds driver model (DM) support to the Marvell EHCI driver. This will be used by the MVEBU SoC's, currently Armada XP and 38x. Tested on Marvell Armada XP and 38x eval boards. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Luka Perkov <luka.perkov@sartura.hr>
| * | dm: core: Enable optional use of fdt_translate_address()Stefan Roese2015-10-212-0/+50
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | The current "simple" address translation simple_bus_translate() is not working on some platforms (e.g. MVEBU). As here more complex "ranges" properties are used in many nodes (multiple tuples etc). This patch enables the optional use of the common fdt_translate_address() function which handles this translation correctly. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
* | sunxi: Use Kconfig CONFIG_MMCMaxime Ripard2015-10-201-1/+1
| | | | | | | | | | | | | | | | | | Not all sunxi boards have an MMC embedded. Switching to the Kconfig option will allow to enable or disable the support in each boards' defconfig. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | mmc: Add generic Kconfig optionMaxime Ripard2015-10-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Add a generic Kconfig option for the CONFIG_MMC option that was used before in the configuration headers. Since all the architectures need to be converted to that first, depend on an non-existent config option that will be extended with architectures that use that option. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | fastboot: Implement OEM format only when we have MMC supportMaxime Ripard2015-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The current fastboot support assumes that CONFIG_FASTBOOT_FLASH implies that we have an MMC in our system, which might not be the case if we have some other storage device. Change the configuration option protecting that call to FASTBOOT_FLASH_MMC_DEV, that makes much more sense. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* | sunxi: power: Change axp209 LDO3 and LDO4 default to disabledHans de Goede2015-10-201-2/+2
| | | | | | | | | | | | | | | | | | LDO3 and LDO4 are normally either unused, or used to power csi attached camera sensors, and as such do not need to be enabled at boot time. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: power: Add support for disabling axp209 regulatorsHans de Goede2015-10-201-4/+46
| | | | | | | | | | | | | | Add support for disabling the regulators found on the axp209 pmic. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: power: Drop protection against multiple calls from axp221 axp_init()Hans de Goede2015-10-201-6/+0
| | | | | | | | | | | | | | | | | | The only thing axp221.c's axp_init() does which needs protection against multiple calls is calling pmic_bus_init, and pmic_bus_init() itself is already protected against being called multiple times. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: power: Use pmic_bus functions for axp152 / axp209 driverHans de Goede2015-10-202-38/+26
| | | | | | | | | | | | | | | | | | Use the generic pmic_bus helpers for the axp152 / axp209 drivers, rather then having them define their own register read / write functions. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: power: Change A23/A33 aldo1 default voltage to 3.0VHans de Goede2015-10-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | On A23 / A33 boards aldo1 is used for VCC-IO and should be 3.0V, make this the default. Note that this does not cause any functional changes since all sun8i board defconfig-s already contained: CONFIG_AXP_ALDO1_VOLT=3000 . Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: power: Change A23/A33 VDD-SYS default from 1.2V to 1.1VHans de Goede2015-10-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | Change the axp223 dcdc2 / VDD-SYS default from 1.2V to 1.1V, 1.1V is the value recommended by Allwinner and is what most fex files specify. This has been tested on a number of A23/A33 tablets including on an A23 Ippo-q8h-v1.2 PCB tablet which has a fex file which specifies 1.2V (which is where our original 1.2V default comes from). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: power: Unify axp pmic function namesHans de Goede2015-10-205-68/+35
| | | | | | | | | | | | | | | | | | Stop prefixing the axp functions for setting voltages, etc. with the model number, there ever is only one pmic driver built into u-boot, this allows simplifying the callers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: power: Make all voltages configurable through KconfigHans de Goede2015-10-201-44/+130
| | | | | | | | | | | | | | | | | | | | | | | | On boards with axp221/223 pmic-s we already allow configuring most voltages. Make the Kconfig options for these also apply to boards with axp152 / axp209 pmic-s and extend them to configure all voltages. The Kconfig defaults are chosen so that this commit does not introduce any functional changes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* | sunxi: Kconfig-ify CONFIG_AXP152_POWER and _AXP209_POWERHans de Goede2015-10-201-3/+29
|/ | | | | | | | | | | | | Kconfig-ify CONFIG_AXP152_POWER and _AXP209_POWER settings, removing them from CONFIG_SYS_EXTRA_OPTIONS. Note that sun5i boards can have either an AXP209 or an AXP152 pmic, the Kconfig default is AXP209, boards with an AXP152 must explicitly select this. Likewise boards without a pmic must explicitly select SUNXI_NO_PMIC in their defconfig. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
OpenPOWER on IntegriCloud