drivers:power:max77693: add support for new multi function pmic max77693

This patch add support for new multi function pmic max77693.
The driver is split into three modules: pmic, muic and fuelgage.

Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
power:battery: add battery support for Trats2 board

Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
samsung:common:i2c: add definions for third soft I2C adapter for Trats2 board

Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
CC: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
samsung: trats2: add support for new board Trats2

This patch add support for a new Samsung board Trats2.

Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN

Linux modified the MTD driver interface in commit edbc4540 (with the
same name as this commit). The effect is that calls to mtd_read will
not return -EUCLEAN if the number of ECC-corrected bit errors is below
a certain threshold, which defaults to the strength of the ECC. This
allows -EUCLEAN to stop indicating "some bits were corrected" and begin
indicating "a large number of bits were corrected, the data held in
this region of flash may be lost soon". UBI makes use of this and when
-EUCLEAN is returned from mtd_read it will move data to another block
of flash. Without adopting this interface change UBI on U-boot attempts
to move data between blocks every time a single bit is corrected using
the ECC, which is a very common occurance on some devices.

For some devices where bit errors are common enough, UBI can get stuck
constantly moving data around because each block it attempts to use has
a single bit error. This condition is hit when wear_leveling_worker
attempts to move data from one PEB to another in response to an
-EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
called to perform the data copy, and after the data is written it is
read back to check its validity. If that read returns UBI_IO_BITFLIPS
(in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
wear_leveling worker, which then proceeds to schedule the destination
PEB for erasure. This leads to erase_worker running on the PEB, and
following a successful erase wear_leveling_worker is called which
begins this whole cycle all over again. The end result is that (without
UBI debug output enabled) the boot appears to simply hang whilst in
reality U-boot busily works away at destroying a block of the NAND
flash. Debug output from this situation:

  UBI DBG: ensure_wear_leveling: schedule scrubbing
  UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
  UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
  UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
  UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
  UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
  UBI: fixable bit-flip detected at PEB 1027
  UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
  UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
  UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
  UBI: fixable bit-flip detected at PEB 4083
  UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
  UBI DBG: erase_worker: erase PEB 4083 EC 55
  UBI DBG: sync_erase: erase PEB 4083, old EC 55
  UBI DBG: do_sync_erase: erase PEB 4083
  UBI DBG: sync_erase: erased PEB 4083, new EC 56
  UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
  UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
  UBI DBG: ensure_wear_leveling: schedule scrubbing
  UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
  ...

This patch adopts the interface change as in Linux commit edbc4540 in
order to avoid such situations. Given that none of the drivers under
drivers/mtd return -EUCLEAN, this should only affect those using
software ECC. I have tested that it works on a board which is
currently out of tree, but which I hope to be able to begin
upstreaming soon.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Stefan Roese <sr@denx.de>
cmd_mtdparts: use 64 bits for flash size, partition size & offset

This matches the 64 bit size in struct mtd_info and allows the mtdparts
command to function correctly with a flash >= 4GiB. Format specifiers
for size & offset are given the ll length, matching its use in
drivers/mtd in absence of something like inttypes.h/PRIx64.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Stefan Roese <sr@denx.de>
cmd_ubi: use int64_t volume size for 'ubi create'

int64_t matches the bytes field in struct ubi_mkvol_req to which the
size is assigned. With the prior signed 32 bit integer, volumes were
restricted to being less than 2GiB in size.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Stefan Roese <sr@denx.de>
cmd_ubi: add write.part command, to write a volume in multiple parts

This allows you to write data to an UBI volume when the amount of memory
available to write that data from is less than the total size of the
data. For example, you may split a root filesystem UBIFS image into
parts, provide the total size of the image to the first write.part
command and then use multiple write.part commands to write the
subsequent parts of the volume. This results in a sequence of commands
akin to:

  ext4load mmc 0:1 0x80000000 rootfs.ubifs.0
  ubi write.part 0x80000000 root 0x08000000 0x18000000
  ext4load mmc 0:1 0x80000000 rootfs.ubifs.1
  ubi write.part 0x80000000 root 0x08000000
  ext4load mmc 0:1 0x80000000 rootfs.ubifs.2
  ubi write.part 0x80000000 root 0x08000000

This would write 384MiB of data to the UBI volume 'root' whilst only
requiring 128MiB of said data to be held in memory at a time.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Stefan Roese <sr@denx.de>
Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master'
Merge branch 'master' of git://git.denx.de/u-boot-nand-flash
Merge branch 'master' of git://git.denx.de/u-boot-arm