21 Feb, 2014
1 commit
20 Feb, 2014
10 commits
-
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 -
The ADI twi peripheral is not binding to Blackfin processor only.
Access i2c registers by standard io functions.
Fix coding style.Signed-off-by: Scott Jiang
Signed-off-by: Sonic Zhang -
The ADI twi peripheral is not binding to Blackfin processor only.
Change to a generic name.Signed-off-by: Sonic Zhang
-
Signed-off-by: Sonic Zhang
-
Signed-off-by: Sonic Zhang
-
Initialize the second i2c controller.
Signed-off-by: Michael Burr
Signed-off-by: Michal Simek -
Fixed bug with alen == 0 in 'i2c_write', 'i2c_read'
Further minor corrections:
- Write 'address' register before 'data' register.
- Write 'transfer_size' register before 'address' register.Signed-off-by: Michael Burr
Signed-off-by: Michal Simek
06 Feb, 2014
1 commit
-
The architecture is unmaintained and dead, remove it.
Signed-off-by: Marek Vasut
Cc: Albert Aribaud
Cc: Michael Schwingen
Cc: Tom Rini
13 Jan, 2014
5 commits
-
This fixes the following compiler warnings:
fti2c010.c: In function 'fti2c010_read':
fti2c010.c:204:8: warning: 'paddr' may be used uninitialized in this function [-Wuninitialized]
fti2c010.c: In function 'fti2c010_write':
fti2c010.c:266:8: warning: 'paddr' may be used uninitialized in this function [-Wuninitialized]Signed-off-by: Kuo-Jung Su
Cc: Heiko Schocher -
Since we agreed on legacy implementation of "eeprom_{read|write}"
(http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work
again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with
anumber of "built-in" ICs with different chip addresses.Signed-off-by: Alexey Brodkin
Cc: Tom Rini
cc: Armando Visconti
Cc: Stefan Roese
Cc: Albert ARIBAUD
Cc: Heiko Schocher
Cc: Vipin KUMAR
Cc: Tom Rix
Cc: Mischa Jonker
Cc: Kuo-Jung Su -
This corrects i2c core to interpret the value returned by
i2c_set_bus_speed as a success indicator rather than the
actual speed that was set. When i2c_set_bus_speed returns
a failure code, the speed is unknown so the adapter speed
is set to zero.Signed-off-by: Darwin Rambo
Reviewed-by: Tim Kryger
Reviewed-by: Steve Rae
Acked-by: Jagannadha Sutradharudu Teki -
Signed-off-by: Hisashi Nakamura
Signed-off-by: Nobuhiro Iwamatsu -
Signed-off-by: Hisashi Nakamura
Signed-off-by: Nobuhiro Iwamatsu
19 Dec, 2013
1 commit
-
Create the i2c adapter object for the fifth bus on SoC with more than
4 buses. This allow using all the bus available on T30.Signed-off-by: Alban Bedel
Acked-by: Heiko Schocher
Signed-off-by: Tom Warren
11 Dec, 2013
2 commits
-
Conflicts:
board/samsung/trats2/trats2.c
include/configs/exynos5250-dt.hSigned-off-by: Tom Rini
-
Conflicts:
arch/arm/cpu/armv7/rmobile/Makefile
doc/README.scrapyardNeeded manual fix:
arch/arm/cpu/armv7/omap-common/Makefile
board/compulab/cm_t335/u-boot.lds
06 Dec, 2013
1 commit
-
This patch adds the U_BOOT_I2C_ADAP_COMPLETE defines for channels
on Exynos5420 and Exynos5250 and also adds support for init function
for hsi2c channelsSigned-off-by: Naveen Krishna Chatradhi
05 Dec, 2013
6 commits
-
Writing zero into I2Ci.I2C_CNT register causes random I2C failures in OMAP3
based devices. This seems to be related to the following advisory which
apears in multiple erratas for OMAP3 SoCs (OMAP35xx, DM37xx), as well as
OMAP4430 TRM:Advisory:
I2C Module Does Not Allow 0-Byte Data Requests
Details:
When configured as the master, the I2C module does not allow 0-byte data
transfers. Note: Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will cause
undefined behavior.
Workaround(s):
No workaround. Do not use 0-byte data requests.The writes in question are unnecessary from a functional point of view.
Most of them are done after I/O has finished, and the only one that preceds
I/O (in i2c_probe()) is also unnecessary because a stop bit is sent before
actual data transmission takes place.Therefore, remove all writes that zero the cnt register.
Cc: Heiko Schocher
Cc: Thomas Petazzoni
Cc: Tom Rini
Cc: Lubomir Popov
Cc: Enric Balletbo Serra
Signed-off-by: Nikita Kiryanov
Tested-by: Thomas Petazzoni
Tested-by: Lubomir Popov -
For a eeprom with a 2-bytes address (e.g., Ateml AT24C1024B),
the r/w address should be serial out in MSB order.Signed-off-by: Kuo-Jung Su
Cc: Heiko Schocher -
Replace the legacy i2c model with the new one.
Signed-off-by: Kuo-Jung Su
Cc: Heiko Schocher -
Coding style cleanup
Signed-off-by: Kuo-Jung Su
Cc: Heiko Schocher -
Fix clock value initialisation for Exynos other than Exynos5 for hsi2c.
Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
Cc: Minkyu Kang
Cc: Heiko Schocher -
This patch adapts the s3c24x0 driver to the new i2c framework.
Config file is modified for all the boards that use the driver.Signed-off-by: Piotr Wilczek
Signed-off-by: Kyungmin Park
CC: Minkyu Kang
CC: Heiko Schocher
CC: Inderpal Singh
CC: David Müller
CC: Chander Kashyap
CC: Lukasz Majewski
Tested-by: Naveen Krishna Chatradhi
Reviewed-by: Naveen Krishna Chatradhi
14 Nov, 2013
1 commit
-
Since the required API is gpio which is enclosed with CONFIG_ATMEL_LEGACY use
that switch here.Signed-off-by: Andreas Bießmann
Acked-by: Heiko Schocher
13 Nov, 2013
7 commits
-
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
Cc: Tom Rini
cc: Armando Visconti
Cc: Stefan Roese
Cc: Albert ARIBAUD
Cc: Heiko Schocher
Cc: Vipin KUMAR
Cc: Tom Rix
Cc: Mischa Jonker -
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
Cc: Tom Rini
cc: Armando Visconti
Cc: Stefan Roese
Cc: Albert ARIBAUD
Cc: Heiko Schocher
Cc: Vipin KUMAR
Cc: Tom Rix
Cc: Mischa Jonker -
remove omap1510 i2c driver, as there is no board which uses it
Signed-off-by: Heiko Schocher
Cc: Tom Rini
Cc: Jian Zhang -
- add zync i2c driver to new multibus/multiadpater support
- adapted all config files, which uses this driverSigned-off-by: Heiko Schocher
Cc: Joe Hershberger
Cc: Michal Simek -
- add omap24xx driver to new multibus/multiadpater support
- adapted all config files, which uses this driverTested on the am335x based siemens boards rut, dxr2 and pxm2
posted here:
http://patchwork.ozlabs.org/patch/263211/Signed-off-by: Heiko Schocher
Tested-by: Tom Rini
Cc: Lars Poeschel
Cc: Steve Sakoman
Cc: Thomas Weber
Cc: Tom Rix
Cc: Grazvydas Ignotas
Cc: Enric Balletbo i Serra
Cc: Luca Ceresoli
Cc: Igor Grinberg
Cc: Ilya Yanok
Cc: Stefano Babic
Cc: Nishanth Menon
Cc: Pali Rohár
Cc: Peter Barada
Cc: Nagendra T S
Cc: Michael Jones
Cc: Raphael Assenat
Acked-by: Igor Grinberg
Acked-by: Stefano Babic -
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 0x42000000The 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
Cc: Fabio Estevam
Cc: Heiko Schocher
Cc: Stefano Babic -
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
Signed-off-by: Nobuhiro Iwamatsu
01 Nov, 2013
1 commit
-
Signed-off-by: Masahiro Yamada
17 Oct, 2013
4 commits
-
The prototype of handlers had changed.
This commit uses cast with (void *) rather than
the handler-specific prototype.Signed-off-by: Masahiro Yamada
-
Add support for hsi2c controller available on exynos5420.
Note: driver currently supports only fast speed mode 100kbps
Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Vadim Bendebury
Signed-off-by: R. Chandrasekar -
At present the i2c ports are enumerated in a strange way - the
fdtdec_find_aliases_for_id() function is used, but then the ID returned
is ignored and the ports are renumbered. The effect is the same provided
that the device tree has the ports in the same order, or uses aliases,
and has no gaps, but it is not correct.Adjust the code to use the function as intended. This will allows device
tree aliases to change the device order if required.As a result, the i2c_busses variable is dropped. We can't be sure that
there are no 'holes' in the list of buses, so must check the whole
array.Note: it seems that non-FDT operation is now broken in this drive and
will need to be reinstated for upstream.Signed-off-by: Simon Glass
Reviewed-on: https://gerrit.chromium.org/gerrit/59369
Signed-off-by: Naveen Krishna Chatradhi -
The Exynos5 i2c driver does not handle NACKs properly. This change:
- fixes the NACK processing problem (do not continue transaction if
address cycle was NACKed)- eliminates a fair amount of duplicate code
Signed-off-by: Vadim Bendebury
Reviewed-by: Simon Glass
Signed-off-by: Naveen Krishna Chatradhi
