05 Mar, 2014
9 commits
-
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 omap5Signed-off-by: Pekon Gupta
-
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 omap5Signed-off-by: Pekon Gupta
-
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.hBuild tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta
-
Convert sandbox over to use driver model GPIOs.
Signed-off-by: Simon Glass
-
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
Signed-off-by: Marek Vasut
Signed-off-by: Pavel Herrmann
Signed-off-by: Viktor Křivák
Signed-off-by: Tomas Hlavacek -
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
Signed-off-by: Marek Vasut
Signed-off-by: Pavel Herrmann
Signed-off-by: Viktor Křivák
Signed-off-by: Tomas Hlavacek -
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
Signed-off-by: Marek Vasut
Signed-off-by: Pavel Herrmann
Signed-off-by: Viktor Křivák
Signed-off-by: Tomas Hlavacek -
Copied from Linux sources "include/linux/sizes.h" commit
413541dd66d51f791a0b169d9b9014e4f56be13cSigned-off-by: Alexey Brodkin
Cc: Vineet Gupta
Cc: Tom Rini
Cc: Stefan Roese
Cc: Albert Aribaud
Acked-by: Tom Rini
Acked-by: Stefan Roese
[trini: Add bcm Kona platforms to the patch]
Signed-off-by: Tom Rini
04 Mar, 2014
7 commits
-
Add console selection from DTB which is enough to have
OF driven solution.Signed-off-by: Michal Simek
-
Enable initialize sdhci from DTB.
Signed-off-by: Michal Simek
-
Gem can be directly initialized from DTB.
Signed-off-by: Michal Simek
-
- Add xilinx_emaclite_of_init to netdev.h
- Remove global data pointer from the driver
- Add better handling for error state.Signed-off-by: Michal Simek
-
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 ELMThis 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
-
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
-
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
27 Feb, 2014
1 commit
-
Conflicts:
arch/arm/cpu/armv7/config.mk
board/ti/am43xx/mux.c
include/configs/am43xx_evm.hSigned-off-by: Tom Rini
26 Feb, 2014
1 commit
-
With this, fixup a trivial build error of get_effective_memsize needing
to be updated in the new board/freescale/p1010rdb/spl.cSigned-off-by: Tom Rini
25 Feb, 2014
2 commits
-
Use first four characters for phy_type comparison. Strcmp() should not
be used to check the phy_type string which maybe parsed by hwconfig_subarg().
Hwconfig_subarg() returns part of hwconfig string starting from
phy_type value till the end of the string. Since phy_type could be
either "utmi" or "ulpi", strncmp() should be used so that a comparison
of "utmi;fsl_ddr:bank_intlv=auto" with "utmi" will succeed.Signed-off-by: Shaohui Xie
Signed-off-by: Nikhil Badola
Reviewed-by: York Sun -
Function "genphy_parse_link()" used "if (mii_reg & BMSR_ANEGCAPABLE)" before
while "if (phydev->supported & SUPPORTED_Autoneg)" now.
So assign "phydev->supported" to "phydev->drv->features" for ar8031/8033
to enable autonegotiation.Signed-off-by: Zhao Qiang
Reviewed-by: York Sun
24 Feb, 2014
1 commit
-
Lack of this check resulted in a data abort when CPU tried to execute the
following command (without further mandatory input): 'pmic MAX77686_PMIC'.Only the 'pmic list' command requires one passed parameter.
Other require at least two valid parameters for correct operation.Signed-off-by: Lukasz Majewski
23 Feb, 2014
3 commits
-
Add support for the Kona SDHCI found on Broadcom mobile SoCs.
Signed-off-by: Darwin Rambo
Reviewed-by: Steve Rae
Reviewed-by: Tim Kryger -
Add support for the Kona I2C controller found on Broadcom mobile SoCs.
Signed-off-by: Darwin Rambo
Reviewed-by: Steve Rae
Reviewed-by: Tim Kryger -
Add support for the Kona GPIO controller found on Broadcom mobile SoCs.
Signed-off-by: Darwin Rambo
Reviewed-by: Steve Rae
Reviewed-by: Markus Mayer
Reviewed-by: Tim Kryger
22 Feb, 2014
4 commits
-
This patch fixes the following warning messages coming out of
'drivers/net/smc91111.h' when compiled for 'vexpress_aemv8a':warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Currently this issue seems to surface when SMSC is compiled for 64-bit
ARMv8 platforms, so the change is protected under CONFIG_ARM64, so that
it doesn't break other existing platforms.In addition this patch tries to fix some checkpatch errors and warnings
(others related to camel-casing and volatile usage will be addressed
by a later patch).This fix has been tested on both ARMv8 foundation model v1 and v2.
Signed-off-by: Bhupesh Sharma
-
Freescale LayerScape SoCs support controller interleaving on 256 byte size.
This interleaving is mandoratory.Signed-off-by: York Sun
-
DDR base address has been the same from the view of core and DDR
controllers. This has changed for Freescale ARM-based SoCs. Controllers
setup DDR memory in a contiguous space and cores view it at separated
locations.Signed-off-by: York Sun
-
Initially it was believed the DDR controller on Freescale ARM would have
big endian. But some platform will have little endian.Signed-off-by: York Sun
21 Feb, 2014
7 commits
-
Use default_serial_puts() instead of duplicating the implementation.
Signed-off-by: Axel Lin
-
This is required for proper functionality on big-endian targets.
Memory-mapped registres of ARC UART are not 32-bit words but 8-bit bytes
so on little-endian target either acessor (_l or _b) works fine.
On big-endian only _b accessors works as expected.Signed-off-by: Alexey Brodkin
Cc: Vineet Gupta
Cc: Noam Camus
Cc: Tom Rini -
Explanation is in in-lined comment.
Signed-off-by: Alexey Brodkin
Cc: Vineet Gupta
Cc: Noam Camus
Cc: Tom Rini -
With d6a320d we moved some clock externs out of blackfin_local.h and
into clock.h but now need to include in more drivers to
avoid warnings.Cc: Sonic Zhang
Signed-off-by: Tom Rini -
The commit:
"EXT4: Fix number base handling of "ext4write" command"
SHA1: f7740f7712b8638f08b83a7e5d00bc1d6bb086a9Cleaned up the ext4write command format.
This commit shall be regarded as a follow up, since the DFU subsystem is
using those commands for its normal operation.Signed-off-by: Lukasz Majewski
20 Feb, 2014
5 commits
-
Conflicts:
Makefile
drivers/net/npe/MakefileThese two conflicts arise from commit 0b2d3f20
("ARM: NET: Remove the IXP NPE ethernet driver") and are
resolved by deleting the drivers/net/npe/Makefile file
and removing the CONFIG_IXP4XX_NPE line from Makefile. -
As soon as all boards have their CONFIG_SYS_I2C_BASE defined in
configuration files instead of "asm/arch/hardware.h" it's safe to remove
the inclusion in question and make driver platform-independent.Cc: Tom Rini
Cc: Heiko Schocher
Cc: Stefan Roese
Cc: Vipin Kumar
Cc: Armando ViscontiSigned-off-by: Alexey Brodkin
-
Adds support for set-speed on the OMAP24xx I2C Adapter.
Changes to omap24_i2c_write(...) for polling ARDY Bit from IRQ-Status.
Otherwise on a subsequent call the transfer of last byte from the
predecessor is aborted and therefore lost. For exmaple when
i2c_write(...) is followed by a i2c_setspeed(...) (which has to
deactivate and activate master for changing psc,...).Minor cosmetical changes.
Signed-off-by: Hannes Petermaier
Cc: Heiko Schocher -
Make sure the I2C write queue is empty before leaving the mxs_i2c_write().
If we start and I2C write and only wait for ACK, the MXS I2C IP block may
enter next operation while still processing the write aftermath internally.
This will in turn disrupt one or more subsequent transfer(s).A testcase for this issue is as such. This testcase is also interesting because
the first I2C_WRITE which becomes disruptive happens in the 'i2c read' command.
The 'i2c read' command first uses I2C_WRITE to send I2C address of the chip and
then uses I2C_READ to read data from the chip. After this command completes, the
'i2c probe' will use sequence of I2C_WRITE commands to probe the I2C bus. The
problem is that the first I2C_WRITE disrupted the I2C IP block operation and
this sideeffect propagates all the way to this next I2C_WRITE used by the 'i2c
probe' call. The result is the 'i2c probe' receives an ACK on I2C address 0x00,
even if this ACK was owned by the previous I2C_WRITE operation. Note that the
'i2c read' command must read from a valid I2C chip address.Wrong:
> i2c probe
Valid chip addresses: 50 51
> i2c read 0x50 0x0.2 0x10 0x42000000
> i2c probe
Valid chip addresses: 00 50 51With this patch
> i2c probe
Valid chip addresses: 50 51
> i2c read 0x50 0x0.2 0x10 0x42000000
> i2c probe
Valid chip addresses: 50 51Signed-off-by: Marek Vasut
Cc: Heiko Schocher
Cc: Fabio Estevam -
Enhance the DesignWare I2C driver to support address length more
than 1 byte. This enhancement is required as some I2C slave
device such as EEPROM chip might have 16 bit address byte.Signed-off-by: Chin Liang See
Acked-by: Alexey Brodkin
Cc: Tom Rini
cc: Armando Visconti
Cc: Stefan Roese
Cc: Albert ARIBAUD
Cc: Heiko Schocher