i2c: sh_i2c: Update to new CONFIG_SYS_I2C framework

This updates to new I2C framwwork on sh_i2c.
And this also updates boards(kzm9g and ecovec) that using sh_i2c.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
i2c: mxs_i2c: Squash endless loop

The endless waiting for a bit to be set can cause a hang, add a timeout
so we prevent such situation. A testcase for such a hang is below. The
testcase assumes a device to be present at address 0x50 and a device to
NOT be present at address 0x42 . Also note that the "sleep 1" induced
delays are imperative for this bug to manifest .

i2c read 0x42 0x0.2 0x10 0x42000000 ; sleep 1 ; \
i2c read 0x50 0x0.2 0x10 0x42000000 ; sleep 1 ; \
i2c read 0x42 0x0.2 0x10 0x42000000

The expected result of the above command is:

Error reading the chip.
Error reading the chip.

While without this patch, we observe a hang in the last read from 0x42
precisely when waiting for this bit to be set.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework

- add omap24xx driver to new multibus/multiadpater support
- adapted all config files, which uses this driver

Tested on the am335x based siemens boards rut, dxr2 and pxm2
posted here:
http://patchwork.ozlabs.org/patch/263211/

Signed-off-by: Heiko Schocher <hs@denx.de>
Tested-by: Tom Rini <trini@ti.com>
Cc: Lars Poeschel <poeschel@lemonage.de>
Cc: Steve Sakoman <sakoman@gmail.com>
Cc: Thomas Weber <weber@corscience.de>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Cc: Luca Ceresoli <luca.ceresoli@comelit.it>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Ilya Yanok <yanok@emcraft.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Nishanth Menon <nm@ti.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Peter Barada <peter.barada@logicpd.com>
Cc: Nagendra T S  <nagendra@mistralsolutions.com>
Cc: Michael Jones <michael.jones@matrix-vision.de>
Cc: Raphael Assenat <raph@8d.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: Stefano Babic <sbabic@denx.de>
i2c, zynq: convert zynq i2c driver to new multibus/multiadapter framework

- add zync i2c driver to new multibus/multiadpater support
- adapted all config files, which uses this driver

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Michal Simek <michal.simek@xilinx.com>
i2c, omap1510: remove i2c driver

remove omap1510 i2c driver, as there is no board which uses it

Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Jian Zhang <jzhang@ti.com>
cmd_eeprom: fix i2c_{read|write} usage if env is in I2C EEPROM

Data "offset" is not used directly in case of I2C EEPROM. Istead it is
split into "block number" and "offset within mentioned block". Which are
"addr[0]" and "addr[1]" respectively.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Mischa Jonker <mjonker@synopsys.com>
designware_i2c: disable i2c controller during target address setup

As it is stated in DesignWare I2C databook: writes to IC_TAR (0x4)
register succeed only when IC_ENABLE[0] is set to 0.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

Cc: Tom Rini <trini@ti.com>
cc: Armando Visconti <armando.visconti@st.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Cc: Vipin KUMAR <vipin.kumar@st.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Mischa Jonker <mjonker@synopsys.com>
designware_i2c: remove 10msec delay in i2c_xfer_finish

This delay applies to any data transfer on I2C bus.

For example 1kB data read with per-byte access (which happens if
environment is stored in I2C EEPROM) takes more than 10 seconds.

Moreover data bus driver has to care about bus state and data transfer,
but not about internal states of attached devices.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

Cc: Tom Rini <trini@ti.com>
cc: Armando Visconti <armando.visconti@st.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Cc: Vipin KUMAR <vipin.kumar@st.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Mischa Jonker <mjonker@synopsys.com>
powerpc/t1040: enable PBL tool for T1040

Use a default RCW of protocol 0x66.
A PBI configure file which uses CPC as 256KB SRAM. It can be used by
PBL tool on T1040 to build a pbl boot image.

Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
powerpc/p1010rdb: update readme for p1010rdb-pa and p1010rdb-pb

- Remove duplicate doc/README.p1010rdb
- Rename README to README.P1010RDB-PA
- Add new README.P1010RDB-PB

P1010RDB-PB is a variation of previous P1010RDB-PA board.

Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
powerpc/t1040: Update defines to support T1040SoC personalities

T1040 Soc has four personalities:
-T1040 (4 cores with L2 switch)
-T1042:Reduced personality of T1040 without L2 switch
-T1020:Reduced personality of T1040 with less cores(2 cores)
-T1022:Reduced personality of T1040 with 2 cores and without L2 switch

Update defines in arch/powerpc header files, Makefiles and in
driver/net/fm/Makefile to support all T1040 personalities

Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
[York Sun: fixed Makefiles]
Acked-by: York Sun <yorksun@freescale.com>
powerpc/t104xrdb: Add T1040RDB board support

T1040RDB is Freescale Reference Design Board supporting
the T1040 QorIQ Power Architecture™ processor.

 T1040RDB board Overview
 -----------------------
 - Four e5500 cores, each with a private 256 KB L2 cache
 - 256 KB shared L3 CoreNet platform cache (CPC)
 - Interconnect CoreNet platform
 - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
   support
 - Data Path Acceleration Architecture (DPAA) incorporating acceleration
 for the following functions:
    -  Packet parsing, classification, and distribution
    -  Queue management for scheduling, packet sequencing, and congestion
       management
    -  Cryptography Acceleration
    - RegEx Pattern Matching Acceleration
    - IEEE Std 1588 support
    - Hardware buffer management for buffer allocation and deallocation
 - Ethernet interfaces
    - Integrated 8-port Gigabit Ethernet switch
    - Four 1 Gbps Ethernet controllers
 - SERDES Connections, 8 lanes supporting:
    - PCI
    - SGMII
    - QSGMII
    - SATA 2.0
 - DDR Controller 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and
   Interleaving
 -IFC/Local Bus
    - NAND flash: 1GB 8-bit NAND flash
    - NOR: 128MB 16-bit NOR Flash
 - Ethernet
    - Two on-board RGMII 10/100/1G ethernet ports.
    - PHY #0 remains powered up during deep-sleep
 - CPLD
 - Clocks
    - System and DDR clock (SYSCLK, “DDRCLK”)
    - SERDES clocks
 - Power Supplies
 - USB
    - Supports two USB 2.0 ports with integrated PHYs
    - Two type A ports with 5V@1.5A per port.
 - SDHC
    - SDHC/SDXC connector
 - SPI
    - On-board 64MB SPI flash
 - I2C
    - Devices connected: EEPROM, thermal monitor, VID controller
 - Other IO
    - Two Serial ports
    - ProfiBus port

Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
[York Sun: fixed Makefile]
Acked-by: York Sun <yorksun@freescale.com>
powerpc/t104xrdb: Add T1042RDB_PI board support

T1042RDB_PI is Freescale Reference Design Board supporting the T1042
QorIQ Power Architecture™ processor. T1042 is a reduced personality
of T1040 SoC without Integrated 8-port Gigabit. The board is designed
with low power features targeted for Printing Image Market.

T1042RDB_PI is  similar to T1040RDB board with few differences like
it has video interface, supports T1042 personality

 T1042RDB_PI board Overview
 -----------------------
 - Four e5500 cores, each with a private 256 KB L2 cache
 - 256 KB shared L3 CoreNet platform cache (CPC)
 - Interconnect CoreNet platform
 - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
   support
 - Data Path Acceleration Architecture (DPAA) incorporating acceleration
 for the following functions:
    -  Packet parsing, classification, and distribution
    -  Queue management for scheduling, packet sequencing, and congestion
    	management
    -  Cryptography Acceleration
    - RegEx Pattern Matching Acceleration
    - IEEE Std 1588 support
    - Hardware buffer management for buffer allocation and deallocation
 - Ethernet interfaces
    - Two on-board RGMII 10/100/1G ethernet ports.
 - SERDES Connections, 8 lanes supporting:
      — PCI
      — SATA 2.0
 - DDR Controller 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and
   Interleaving
 -IFC/Local Bus
     - NAND flash: 1GB 8-bit NAND flash
     - NOR: 128MB 16-bit NOR Flash
 - Ethernet
     - Two on-board RGMII 10/100/1G ethernet ports.
     - PHY #0 remains powered up during deep-sleep
 - CPLD
 - Clocks
     - System and DDR clock (SYSCLK, “DDRCLK”)
     - SERDES clocks
 - Video
     - DIU supports video at up to 1280x1024x32bpp
     - HDMI connector
 - Power Supplies
 - USB
     - Supports two USB 2.0 ports with integrated PHYs
     - Two type A ports with 5V@1.5A per port.
 - SDHC
     - SDHC/SDXC connector
 - SPI
     - On-board 64MB SPI flash
 - I2C
     - Device connected: EEPROM, thermal monitor, VID controller, RTC
 - Other IO
    - Two Serial ports
    - ProfiBus port
    - Four I2C ports

Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
powerpc/83xx: Define USB1 and USB2 base addr for MPC834x

Define base addresse for both MPH(USB1) and DR(USB2) controllers
for MPC834x socs

Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
powerpc/t4240: set pcie liodn in the correct register

The liodn for the T4240's PCIE controller is no longer set
through a register in the guts register block but with one
in the PCIE register block itself.
Use the already existing SET_PCI_LIODN_BASE macro that puts
the liodn in the correct register.

Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: York Sun <yorksun@freescale.com>
powerpc/t4240: fix per pci endpoint liodn offsets

Update the code that builds the pci endpoint liodn
offset list so that it doesn't overlap with other
liodns and doesn't generate negative offsets like:

  fsl,liodn-offset-list = <0 0xffffffcd 0xffffffcf
                             0xffffffd1 0xffffffd3
                             0xffffffd5 0xffffffd7
                             0xffffffd9 0xffffffdb>;

The update consists in adding a parameter to the
function that builds the list to specify the base
liodn.
On PCI v2.4 use the old base = 256 and, on PCI 3.0
where some of the PCIE liodns are larger than 256,
use a base = 1024. The version check is based on
the PCI controller's version register.

Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: York Sun <yorksun@freescale.com>
powerpc/85xx: fix broken cpu "clock-frequency" property

When indexing freqProcessor[] we use the first
value in the cpu's "reg" property, which on
new e6500 cores IDs the threads.
But freqProcessor[] should be indexed with a
core index so, when fixing "the clock-frequency"
cpu node property, access the freqProcessor[]
with the core index derived from the "reg' property.
If we don't do this, last half of the "cpu" nodes
will have broken "clock-frequency" values.

Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@freescale.com>
Cc: York Sun <yorksun@freescale.com>
Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx
malta: use unmapped flash base address

The physical base address of the NOR flash is 0x1e000000
on the Malta boards. The hardware also maps the first 4MiB
of the flash into the 0x1fc00000-0x1fffffff range.

Currently, U-Boot uses the mapped address to access the
flash, which does not work in recent qemu versions.

Since commit a427338b222b43197c2776cbc996936df0302f51
(mips_malta: correct reading MIPS revision at 0x1fc00010)
writing to the mapped address space causes a CPU exception.
Due to the exception, U-Boot hangs during boot when it tries
to detect the CFI flash chip.

Use the correct physical address for the MALTA_FLASH_BASE
constant to fix the problem. In order to avoid relocation
problems, also update the CONFIG_SYS_{TEXT,MONITOR}_BASE
constants.

The change makes it possible to start U-Boot on a Malta
board emulated with Qemu 1.6.1 and 1.7.0-rc0. It also
works on older versions (tested with 1.1.1, 1.2.2, 1.4.2,
1.5.3).

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
TI:omap: Update u-boot-spl.lds for i2c multibus/multiadapter update

In 6789e84 we update u-boot-spl.lds for OMAP to ensure we include
adapter information, as we use i2c during SPL.  However, the regex used
also means we included commands that may have been built.  On omap5_uevm
this leads to a failure as we include the command from the do_tca642x
command, and fail to link.  The fix is to restrict our regex to only the
i2c list parts.

Signed-off-by: Tom Rini <trini@ti.com>