summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* powerpc/t1040qds: Add Video - HDMI supportPriyanka Jain2014-03-07-1/+255
| | | | | | | | | | | | | | | | | | T1040 has internal display interface unit (DIU) for driving video. T1040QDS supports video mode via -LCD using TI enconder -HDMI type interface via HDMI encoder Chrontel, CH7301C encoder which is I2C programmable is used as HDMI connector on T1040QDS. This patch add support to -enable Video interface for T1040QDS -route qixis multiplexing to enable DIU-HDMI interface on board -program DIU pixel clock gerenartor for T1040 -program HDMI encoder via I2C on board Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* powerpc/mpc85xx: Add SCFG_PIXCLKCR register support for T1040Priyanka Jain2014-03-07-0/+9
| | | | | | | | | | | | | | | | T1040 SoC has SCFG (Supplement Configuration) Block which provides chip specific configuration and status support. The base address of SCFG block in T1040 is 0xfc000. SCFG contains SCFG_PIXCLKCR (DIU pixel clock control register) at offset 0x28. Add definition of -SCFG block -SCFG_PIXCLKCR register -Bits definition of SCFG_PIXCLK register Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* powerpc/t2080rdb: Add T2080PCIe-RDB board supportShengzhou Liu2014-03-07-0/+1777
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | T2080PCIe-RDB is a Freescale Reference Design Board that hosts the T2080 SoC. It works in two mode: standalone mode and PCIe endpoint mode. T2080PCIe-RDB Feature Overview ------------------------------ Processor: - T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz DDR Memory: - Single memory controller capable of supporting DDR3 and DDR3-LP devices - 72bit 4GB DDR3-LP SODIMM in slot Ethernet interfaces: - Two 10M/100M/1G RGMII ports on-board - Two 10Gbps SFP+ ports on-board - Two 10Gbps Base-T ports on-board Accelerator: - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC SerDes 16 lanes configuration: - SerDes-1 Lane A-B: to two 10G XFI fiber (MAC9 & MAC10) - SerDes-1 Lane C-D: to two 10G Base-T (MAC1 & MAC2) - SerDes-1 Lane E-H: to PCIe Goldfinger (PCIe4 x4, Gen3) - SerDes-2 Lane A-D: to PCIe Slot (PCIe1 x4, Gen2) - SerDes-2 Lane E-F: to C293 secure co-processor (PCIe2 x2) - SerDes-2 Lane G-H: to SATA1 & SATA2 IFC/Local Bus: - NOR: 128MB 16-bit NOR flash - NAND: 512MB 8-bit NAND flash - CPLD: for system controlling with programable header on-board eSPI: - 64MB N25Q512 SPI flash USB: - Two USB2.0 ports with internal PHY (both Type-A) PCIe: - One PCIe x4 gold-finger - One PCIe x4 connector - One PCIe x2 end-point device (C293 Crypto co-processor) SATA: - Two SATA 2.0 ports on-board SDHC: - support a TF-card on-board I2C: - Four I2C controllers. UART: - Dual 4-pins UART serial ports Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* powerpc/t208xqds: fixup for t208xqdsShengzhou Liu2014-03-07-2/+3
| | | | | | | | Change QIXIS timing parameter CONFIG_SYS_CS3_FTIM2 to 8 from 0. Fix EMI2 for t2080qds, which was caused by adding t2081qds. Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* bootstage: powerpc: support fdt stash and reportingMela Custodio2014-03-07-0/+7
| | | | | | | | | This implements stashing of bootstage timing data to FDT and automatic timing reporting. To enable define CONFIG_BOOTSTAGE_FDT and CONFIG_BOOTSTAGE_REPORT respectively. Signed-off-by: Rommel G Custodio <sessyargc+u-boot@gmail.com> Reviewed-by: York Sun <yorksun@freescale.com>
* powerpc/usb: Workaround for erratum-A006261Suresh Gupta2014-03-07-2/+128
| | | | | | | | | | | USB spec says that the minimum disconnect threshold should be over 525 mV. However, internal USB PHY threshold value is below this specified value. Due to this some devices disconnect at run-time. Hence, phy settings are tweaked to increased disconnect threshold to be above 525mV by using this workaround. Signed-off-by: Suresh Gupta <suresh.gupta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* powerpc/b4860: Add workaround for errata A006384 and A006475Shaveta Leekha2014-03-07-2/+220
| | | | | | | | | | | | | SerDes PLLs may not lock reliably at 5 G VCO configuration(A006384) and at cold temperatures(A006475), workaround recalibrate the PLLs with some SerDes configuration Both these errata are only applicable for b4 rev1. So, make workaround for these errata conditional, depending upon soc version. Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* B4860qds: Set SerDes2 refclk2 at to 156.25MHz for XFI to workShaveta Leekha2014-03-07-4/+3
| | | | | | | | | | Change setting of SerDes2 refclk2 to have the default value as it is coming on board that is 156.25MHz, for XFI to work. Also change PLL_NUM variable to the one defined in config_mpc85xx.h for B4860 and B4420. Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* B4860/B4420: Add PLL_NUM define for B4420/B4860 to use SerDes2 Refclks ↵Shaveta Leekha2014-03-07-0/+2
| | | | | | | | | | re-configuration B4860 has two PLL per SerDes whereas B4420 has one PLL per SerDes, add their defines in arch/powerpc/include/asm/config_mpc85xx.h Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* 85xx/b4860: Alternate serdes protocols for B4860/B4420poonam aggrwal2014-03-07-0/+36
| | | | | | | | | | | | | | | On B4860 and B4420, some serdes protocols can be used with LC VCO as well as Ring VCO options. Addded Alternate options with LC VCO for such protocols. For example protocol 0x2a on srds 1 becomes 0x29 if it is LC VCO. The alternate option has the same functionality as the original option; the only difference being LC VCO rather than Ring VCO. Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* board/b4860qds: Add support to make PCIe SATA work on B4860QDSShaveta Leekha2014-03-07-9/+113
| | | | | | | | | | | | 1) SerDes2 Refclks have been set properly to make PCIe SATA to work as it work on SerDes refclk of 100MHz 2) Mask the SerDes's device reset request before changing the Refclks for SerDes1 and SerDes2 for PLL locks to happen properly, device reset request bit unmasked after SerDes refclks configuration Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* board/b4860qds: Add support to make Aurora work on B4860QDSShaveta Leekha2014-03-07-4/+111
| | | | | | | | | | | | | 1) Add new SerDes1 protocols having Aurora in them 2) Add VSC cross point connections for Aurora to work with CPRI and SGMIIs 3) Configure VSC crossbar switch to connect SerDes1 lanes to aurora on board, by checking SerDes1 protocols 4) SerDes1 Refclks have been set properly to make Aurora, CPRI and SGMIIs to work together properly Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* Merge branch 'master' of git://git.denx.de/u-boot-nand-flashTom Rini2014-03-04-802/+321
|\
| * mtd: nand: omap: move omap_elm.h from arch/arm/include/asm to drivers/mtd/nandpekon gupta2014-03-04-2/+2
| | | | | | | | | | | | | | | | | | omap_elm.h is a generic header used by OMAP ELM driver for all TI platfoms. Hence this file should be present in generic folder instead of architecture specific include folder. Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
| * mtd: nand: omap: move omap_gpmc.h from arch/arm/include/asm to drivers/mtd/nandpekon gupta2014-03-04-8/+6
| | | | | | | | | | | | | | | | | | omap_gpmc.h is a generic header used by OMAP NAND driver for all TI platfoms. Hence this file should be present in generic folder instead of architecture specific include folder. Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
| * mtd: nand: omap: merge duplicate GPMC data from different arch-xx headers ↵pekon gupta2014-03-04-196/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into common omap_gpmc.h Each SoC platform (AM33xx, OMAP3, OMAP4, OMAP5) has its own copy of GPMC related defines and declarations scattered in SoC platform specific header files like include/asm/arch-xx/cpu.h However, GPMC hardware remains same across all platforms thus this patch merges GPMC data scattered across different arch-xx specific header files into single header file include/asm/arch/omap_gpmc.h Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
| * mtd: nand: omap: remove unused #defines from common omap_gpmc.hpekon gupta2014-03-04-73/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP NAND driver can detect Page-size and OOB-size of NAND device from ONFI params or nand_id[] table. And based on that it defines ECC layout. This patch 1) removes following board configs used for defining NAND ECC layout - GPMC_NAND_ECC_LP_x16_LAYOUT (for large page x16 NAND) - GPMC_NAND_ECC_LP_x8_LAYOUT (for large page x8 NAND) - GPMC_NAND_ECC_SP_x16_LAYOUT (for small page x16 NAND) - GPMC_NAND_ECC_SP_x8_LAYOUT (for small page x8 NAND) 2) removes unused #defines in common omap_gpmc.h depending on above configs Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
| * mtd: nand: omap: remove redundant platform specific header: arch-xx/omap_gpmc.hpekon gupta2014-03-04-86/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there are two sets of omap_gpmc.h header files (a) arch/arm/include/asm/omap_gpmc.h common header file for all platforms, containing defines and declarations used by GPMC NAND driver. (b) arch/arm/include/asm/arch-xx/omap_gpmc.h SoC platform specific header file containing defines like ECC layout. This patch removes platform specific arch-xx/omap_gpmc.c because: - GPMC hardware engine is common for all SoC platforms hence only (a) is enough - ECC layout is now defined in omap_nand.c driver itself based on ecc-scheme selected. Hence all ECC layout declarations in (b) are redundant. Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
| * board/ti/am335x/README: update for NAND bootpekon gupta2014-03-03-17/+36
| | | | | | | | | | | | | | | | | | NAND boot mode on AM335x EVM has been verified, and steps to use it has been documented and update in this README Signed-off-by: Pekon Gupta <pekon@ti.com> Acked-by: Peter Korsgaard <jacmet@sunsite.dk> Acked-by: Tom Rini <trini@ti.com>
| * mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemespekon gupta2014-03-03-90/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | chip->ecc.correct() is used for detecting and correcting bit-flips during read operations. In omap-nand driver it implemented as: (a) omap_correct_data(): for h/w based ECC_HAM1 scheme (b) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW for ECC_BCH8 scheme using GPMC and software lib/bch.c (c) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW for ECC_BCH8 scheme using GPMC and ELM This patch updates (c) - checks for calc_ecc[]==0x00 so that error_correction is not required for known good pages. - adds scalability for other ECC_BCHx scheme by merging following omap_rotate_ecc_bch() + omap_fix_errors_bch() => omap_correct_data_bch() - fixing logic for bit-flip correction based on error_loc[count] Signed-off-by: Pekon Gupta <pekon@ti.com>
| * mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemespekon gupta2014-03-03-163/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | chip->ecc.calculate() is used for calculating and fetching of ECC syndrome by processing the data passed during Read/Write accesses. All H/W based ECC schemes use GPMC controller to calculate ECC syndrome. But each BCHx_ECC scheme has its own implemetation of post-processing and fetching ECC syndrome from GPMC controller. This patch updates OMAP_ECC_BCH8_CODE_HW ECC scheme in following way: - merges multiple chip->calculate API for different ECC schemes omap_calculate_ecc() + omap_calculate_ecc_bch() + omap_calculate_ecc_bch_sw() ==> omap_calculate_ecc() - removes omap_ecc_disable() and instead uses it as inline. Signed-off-by: Pekon Gupta <pekon@ti.com>
| * mtd: nand: omap: optimize chip->ecc.hwctl() for H/W ECC schemespekon gupta2014-03-03-149/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | chip->ecc.hwctl() is used for preparing the H/W controller before read/write NAND accesses (like assigning data-buf, enabling ECC scheme configs, etc.) Though all ECC schemes in OMAP NAND driver use GPMC controller for generating ECC syndrome (for both Read/Write accesses). But but in current code HAM1_ECC and BCHx_ECC schemes implement individual function to achieve this. This patch (1) removes omap_hwecc_init() and omap_hwecc_init_bch() as chip->ecc.hwctl will re-initializeGPMC before every read/write call. omap_hwecc_init_bch() -> omap_enable_ecc_bch() (2) merges the GPMC configuration code for all ECC schemes into single omap_enable_hwecc(), thus adding scalability for future ECC schemes. omap_enable_hwecc() + omap_enable_ecc_bch() -> omap_enable_hwecc() Signed-off-by: Pekon Gupta <pekon@ti.com>
* | Merge branch 'master' of git://git.denx.de/u-boot-mipsTom Rini2014-03-04-21/+4
|\ \
| * | malta: correct tcl script path in README.maltaJames Hogan2014-03-04-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | README.malta referred to board/malta, but malta has now been moved within board/imgtec/, so correct the path. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com> Cc: Paul Burton <paul.burton@imgtec.com>
| * | MIPS: fix types u64 and __u64 to unsigned long longDaniel Schwierzeck2014-03-04-20/+3
| |/ | | | | | | | | | | | | | | Linux MIPS uses asm-generic/int-ll64.h in asm/types.h. Thus u64 and __u64 are defined as unsigned long long. Port this over to U-Boot. Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
* | arc: arcangel4: set board entry <none> to fix a build errorMasahiro Yamada2014-03-04-13/+2
| | | | | | | | | | | | | | | | There are no source files in board/synopsys/arcangel4/ directory. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
* | kbuild: allow empty board directoriesMasahiro Yamada2014-03-04-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | U-Boot has compelled all boards to have board/${BOARD}/ or board/${VENDOR}/${BOARD}/ directory. Sometimes it does not seem suitable for some boards, for example Sandbox. (Is it a board?) And arcangel4 board has nothing to compile under the board directory. This commit makes the build system more flexible: If '<none>' is given to the 6th column (=Board name) of boards.cfg, Kbuild will not descend into the board directory. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* | kbuild: tools: fix a bug that always builds Denx logoMasahiro Yamada2014-03-04-2/+2
| | | | | | | | | | | | | | | | | | LOGO_BMP was never overwritten by board-specific or vendor-specific logos. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Reported-by: Bo Shen <voice.shen@atmel.com> Tested-by: Bo Shen <voice.shen@atmel.com>
* | kbuild: add "cross_tools" target to build tools for the targetMasahiro Yamada2014-03-04-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Programs in tools/ directory are usually built for the host. But some of them (mkimage, dumpimge, gen_eth_addr, etc.) are useful on the target OS too. Actually, prior to Kbuild, U-Boot could build tools for the target like follows: $ make <target_board>_config $ export CROSS_COMPILE=<cross_gcc_prefix> $ make HOSTCC=${CROSS_COMPILE}gcc HOSTSTRIP=${CROSS_COMPILE}strip tools In Kbuild, we can no longer replace HOSTCC at the command line. In order to get back that feature, this commit adds "cross-tools" target. Usage: Build tools for the host $ make CROSS_COMPILE=<cross_gcc_prefix> tools Build tools for the target $ make CROSS_COMPILE=<cross_gcc_prefix> cross_tools Besides, "make cross_tools" strip tools programs because we generally expect smaller storages on embedded systems. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Reported-by: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: Tom Rini <trini@ti.com> Tested-by: Heiko Schocher <hs@denx.de> Acked-by: Heiko Schocher <hs@denx.de>
* | kbuild: fix "tools-all" targetMasahiro Yamada2014-03-04-1/+1
| | | | | | | | | | | | | | | | | | The top Makefile must export HOST_TOOLS_ALL to use it in tools/Makefile. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Heiko Schocher <hs@denx.de> Acked-by: Heiko Schocher <hs@denx.de>
* | board: config.mk: delete unused sinclude directiveMasahiro Yamada2014-03-04-4/+0
| | | | | | | | | | | | config.tmp is not there. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* | board: .gitignore: ignore board-specific generated filesMasahiro Yamada2014-03-04-0/+4
| | | | | | | | | | | | | | | | | | | | Ignore - board/cray/L1/bootscript.{c|image} - board/matrix_vision/mvblm7/bootscript.img - board/maxtir_vision/mvsmr/bootscript.img Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Andre Schwarz <andre.schwarz@matrix-vision.de>
* | board: gaisler: delete unnecessary include pathMasahiro Yamada2014-03-04-10/+0
| | | | | | | | | | | | | | | | The same outputs are generated with or without -I$(TOPDIR)/board. I cannot understand why it is necessary. Remove. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Daniel Hellstrom <daniel@gaisler.com>
* | kbuild: fix CROSS_COMPILE settings in config.mkMasahiro Yamada2014-03-04-14/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The syntax CROSS_COMIPLE ?= <cross_compiler_prefix> does not work because config.mk is parsed after exporting CROSS_COMPILE. Like Linux Kernel's arch/$(ARCH)/Makefile, we must write as follows: ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := <cross_compiler_prefix> endif Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* | kbuild: consolidate PLATFORM_LIBSMasahiro Yamada2014-03-04-9/+4
| | | | | | | | | | | | | | | | | | | | We had switched to Kbuild so now we can specify PLATFORM_LIBS/PLATFORM_LIBGCC with relative path. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Tom Rini <trini@ti.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | scripts: update checkpatch.pl to latest upstream versionTom Rini2014-03-04-208/+1067
| | | | | | | | | | | | | | | | | | | | Update to v3.14-rc4's version of checkpatch.pl. In doing so we drop the changes to top_of_kernel_tree() as we pass in --no-tree and drop our changes about MAINTAINERS as that's for reporting checkpatch.pl problems itself (and upstream has said they'll reword this section to be clearer). Signed-off-by: Tom Rini <trini@ti.com>
* | Add 64-bit data support for memory commandsYork Sun2014-03-04-11/+174
| | | | | | | | | | | | | | | | | | | | Add 64-bit data for memory commands, such as md, mw, mm, cmp. The new size ".q " is introduced. For 64-bit architecture, 64-bit data is enabled by default, by detecting compiler __LP64__. It is optional for other architectures. Signed-off-by: York Sun <yorksun@freescale.com>
* | dm: Remove old driver model documentationSimon Glass2014-03-04-3662/+0
| | | | | | | | | | | | | | | | | | | | | | This documentation pertains to the planned implementation of driver model in U-Boot for each subsystem, but it has not been superseded. It is probably better to have this documentation in the source code for each subsystem where possible, so that docbook will pick it up. Where this does not make sense, new documentation can be placed in some suitable file in doc/driver-model. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: Enable gpio command to support driver modelSimon Glass2014-03-04-13/+116
| | | | | | | | | | | | | | | | | | | | Now that named GPIO banks are supported, along with a way of obtaining the status of a GPIO (input or output), we can provide an enhanced GPIO command for driver model. Where the driver provides its own operation for obtaining the GPIO state, this is used, otherwise a generic version is sufficient. Signed-off-by: Simon Glass <sjg@chromium.org>
* | sandbox: Convert GPIOs to use driver modelSimon Glass2014-03-04-88/+151
| | | | | | | | | | | | Convert sandbox over to use driver model GPIOs. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: Add GPIO support and testsSimon Glass2014-03-04-0/+483
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add driver model support for GPIOs. Since existing GPIO drivers do not use driver model, this feature must be enabled by CONFIG_DM_GPIO. After all GPO drivers are converted over we can perhaps remove this config. Tests are provided for the sandbox implementation, and are a sufficient sanity check for basic operation. The GPIO uclass understands the concept of named banks of GPIOs, with each GPIO device providing a single bank. Within each bank the GPIOs are numbered using an offset from 0 to n-1. For example a bank named 'b' with 20 offsets will provide GPIOs named b0 to b19. Anonymous GPIO banks are also supported, and are just numbered without any prefix. Each time a GPIO driver is added to the uclass, the GPIOs are renumbered accordinging, so there is always a global GPIO numbering order. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
* | dm: Add a demonstration/example driverSimon Glass2014-03-04-0/+432
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As an example of how to write a uclass and a driver, provide a demo version of each, accessible through the 'demo' command. To use these with driver model, define CONFIG_CMD_DEMO and CONFIG_DM_DEMO. The two demo drivers are enabled with CONFIG_DM_DEMO_SIMPLE and CONFIG_DM_DEMO_SHAPE. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
* | dm: Add a 'dm' command for testingSimon Glass2014-03-04-0/+135
| | | | | | | | | | | | | | | | | | | | | | This command is not required for driver model operation, but can be useful for testing. It provides simple dumps of internal data structures. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
* | dm: Add basic testsSimon Glass2014-03-04-0/+1426
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some tests of driver model functionality. Coverage includes: - basic init - binding of drivers to devices using platform_data - automatic probing of devices when referenced - availability of platform data to devices - lifecycle from bind to probe to remove to unbind - renumbering within a uclass when devices are probed/removed - calling driver-defined operations - deactivation of drivers when removed - memory leak across creation and destruction of drivers/uclasses - uclass init/destroy methods - automatic probe/remove of children/parents when needed This function is enabled for sandbox, using CONFIG_DM_TEST. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: Set up driver model after relocationSimon Glass2014-03-04-0/+33
| | | | | | | | | | | | | | | | Make driver model available after relocation, by setting up data structures and scanning for devices using compiled-in platform_data and (when available) the device tree. Signed-off-by: Simon Glass <sjg@chromium.org>
* | sandbox: config: Enable driver modelSimon Glass2014-03-04-0/+1
| | | | | | | | | | | | Use driver model in sandbox to permit running of driver model unit test. Signed-off-by: Simon Glass <sjg@chromium.org>
* | dm: Add base driver model supportSimon Glass2014-03-04-0/+1601
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add driver model functionality for generic board. This includes data structures and base code for registering devices and uclasses (groups of devices with the same purpose, e.g. all I2C ports will be in the same uclass). The feature is enabled with CONFIG_DM. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Pavel Herrmann <morpheus.ibis@gmail.com> Signed-off-by: Viktor Křivák <viktor.krivak@gmail.com> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
* | dm: Add README for driver modelSimon Glass2014-03-04-0/+368
| | | | | | | | | | | | This adds a README to help with understanding of this series. Signed-off-by: Simon Glass <sjg@chromium.org>
* | yaffs: Remove private list implementationSimon Glass2014-03-04-127/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | U-Boot already has a list implementation, and files which include both that and the yaffs implementation will get errors: In file included from ydirectenv.h:80:0, from yportenv.h:81, from yaffs_guts.h:19, from yaffs_allocator.h:19, from yaffs_allocator.c:14: yaffs_list.h:32:8: error: redefinition of ‘struct list_head’ struct list_head { ^ Remove the yaffs implementation. Signed-off-by: Simon Glass <sjg@chromium.org>
* | Add cmd_process_error() to report and process errorsSimon Glass2014-03-04-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | U-Boot now uses errors defined in include/errno.h which are negative integers. Commands which fail need to report the error and return 1 to indicate failure. Add this functionality in cmd_process_error(). For now this merely reports the error number. It would be possible also to produce a helpful error message by storing the error strings in U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-11-06 12:50:43 +0000