To enter high speed mode, following steps should be done:
1. When running in high speed mode, i2c clock rate is different
from standard mode. Clock rate must be set according to
specification first.
2. When i2c controller sends a master code and wins arbitration,
high speed mode is entered.
If
On Fri, 31 May 2013 14:20:10 +0200, Jean Delvare wrote:
In HTML output mode, generate HTML 4.01 compliant markup.
---
eeprom/decode-dimms | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
I just committed both patches.
--
Jean Delvare
--
To unsubscribe from this list:
On Fri, Jun 07, 2013 at 08:23:53AM +0300, Mika Westerberg wrote:
Hi Christian,
On Thu, Jun 06, 2013 at 03:43:35PM +0200, Christian Ruppert wrote:
The designware block is not always properly disabled in the case of
transfer errors. Interrupts from aborted transfers might be handled
after
The designware block is not always properly disabled in the case of
transfer errors. Interrupts from aborted transfers might be handled
after the data structures for the following transfer are initialised but
before the hardware is set up. This can corrupt the data structures to
the point that the
On Wed, May 22, 2013 at 10:03:11AM -, Mika Westerberg wrote:
If a process receives signal while it is waiting for I2C transfer to
complete, an error is returned to the caller and the transfer is aborted.
This can cause the driver to fail subsequent transfers. Also according to
commit
3) Thinking about Mainline: To reach the same target - no I2C
detection - and taking
into account above assumption No changes in default behavior
the following will need to be done:
- change i2c-omap/i2c-gpio DT bindings and add parameter which will
allow to change
.class value for
Class based instantiation can cause huge delays when booting. This
mechanism was used when it was not possible to describe slaves on I2C
busses. We now have other mechanisms, so most embedded I2C will not need
classes and it was explicitly not recommended to use them. Add a
deprecation warning for
On Fri, Jun 7, 2013 at 11:51 AM, Christian Ruppert
christian.rupp...@abilis.com wrote:
The designware block is not always properly disabled in the case of
transfer errors. Interrupts from aborted transfers might be handled
after the data structures for the following transfer are initialised but
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index
Hi Wolfram,
On 06/07/2013 12:06 PM, Wolfram Sang wrote:
3) Thinking about Mainline: To reach the same target - no I2C
detection - and taking
into account above assumption No changes in default behavior
the following will need to be done:
- change i2c-omap/i2c-gpio DT bindings and add parameter
Hi Andy,
I like your patch and I just did some testing on it. Unluckily, it
doesn't solve the lock-up problem.
I haven't investigated any further but I suspect that on top of the
cases I observed when debugging this (interrupts after initialisation of
dev, easy to prove) there are more obscure
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-platdrv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git
From: Zbigniew Bodek z...@semihalf.com
The I2C Transaction Generator offloads CPU from managing I2C
transfer step by step.
This feature is currently only available on Armada XP, so usage of
this mechanism is activated through device tree.
[gregory.clem...@free-electrons.com: Rewrite some part
The mv64xxx-i2c embedded in the Armada XP have a new feature called
i2c-bridge. This commit split the i2c information into armada-370.dtsi
and armada-xp.dtsi. Most of the data remains the same and stay in the
common file Armada-370-xp.dtsi. With this new feature the size of the
registers are
Hello,
this patch set adds support for the I2C Transaction Generator which
offloads CPU from managing I2C transfer step by step. This feature is
currently only available on the I2C controller IP embedded in the
Armada XP SoC. That's why usage of this mechanism is optional and
activated through
Hello,
This series contains a real fix for the I2C controller of the Armada
XP SoC and a patch closer to a improvement than a fix.
They are independent and are only in the same series because they are
kind of fixes.
They are based on 3.10-rc4, and they will be small conflicts if they
are
From: Zbigniew Bodek z...@semihalf.com
All the Armada XP (mv78230, mv78260 and mv78460) have a silicon issue
in the I2C controller which violate the i2c repeated start
timing. The I2C standard requires a minimum of 4.7us for the repeated
start condition whereas the I2C controller of the Armada XP
Hello,
This series contains a real fix for the I2C controller of the Armada
XP SoC and a patch closer to a improvement than a fix.
They are independent and are only in the same series because they are
kind of fixes.
They are based on 3.10-rc4, and they will be small conflicts if they
are
From: Zbigniew Bodek z...@semihalf.com
This commit adds checking whether clock-frequency property acquisition
has succeeded. Do not waste time to find baud factors if there is no
information about the desired bus frequency in dts.
[gregory.clem...@free-electrons.com: Reword the commit log]
Dear Gregory CLEMENT,
On Fri, 7 Jun 2013 17:42:22 +0200, Gregory CLEMENT wrote:
/* Driver states */
enum {
MV64XXX_I2C_STATE_INVALID,
@@ -110,6 +133,7 @@ struct mv64xxx_i2c_data {
spinlock_t lock;
struct i2c_msg *msg;
struct i2c_adapter
Hi Greg,
On Fri, Jun 07, 2013 at 05:42:23PM +0200, Gregory CLEMENT wrote:
The mv64xxx-i2c embedded in the Armada XP have a new feature called
i2c-bridge. This commit split the i2c information into armada-370.dtsi
and armada-xp.dtsi. Most of the data remains the same and stay in the
common
On Fri, Jun 07, 2013 at 05:42:23PM +0200, Gregory CLEMENT wrote:
The mv64xxx-i2c embedded in the Armada XP have a new feature called
i2c-bridge. This commit split the i2c information into armada-370.dtsi
and armada-xp.dtsi. Most of the data remains the same and stay in the
common file
Hi All,
I observe, that OMAP4 SDP board boot is failed if CONFIG_SENSORS_LM75=y. See
log below.
This issue reproduced with kernel v3.9-rc6, but without hang - just I2C is stuck
in Bus Busy condition. My investigation results are below.
[2.048858] TCP: cubic registered
[2.052398]
Dear Jason Cooper,
On Fri, 7 Jun 2013 14:09:41 -0400, Jason Cooper wrote:
+- i2c,i2c-bridge : This flag indicate that the i2c controller have the
+ Transaction Generator support and we want to use it. Not all the
+ mv64xxx controller have this feature.
Do you have a list of which
The omap_i2c_isr() does the irq check and schedules threaded handler if any of
enabled IRQs is active, but currently the I2C IRQs are enabled just once,
when I2C IP is enabling (transfer started) and they aren't changed after that.
More over, now the I2C INTC IRQ is disabled when I2C IP is idled.
According to I2C specification the NACK should be handled as folowing:
When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then gene rate either a STOP condition to
abort the transfer, or a repeated START condition to start a new
ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be
processed incorrectly now:
iterration 1:
- I2C irq triggered (ARDY|NACK)
- omap_i2c_isr_thread() will ask NACK, fill dev-cmd_err = OMAP_I2C_STAT_NACK
and trigger cmd_complete completion.
- omap_i2c_xfer_msg() will be
Hi All,
I observe, that OMAP4 SDP board boot is failed if CONFIG_SENSORS_LM75=y. See
log below.
This issue reproduced with kernel v3.9-rc6, but without hang - just I2C is stuck
in Bus Busy condition. My investigation results are below.
[2.048858] TCP: cubic registered
[2.052398]
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
WARN_ONCE(true, We should never be here!\n);
return
From: Kevin Hilman khil...@deeprootsystems.com
Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.
In addition to idling the device, driver's -runtime_suspend() method
currently disables device
Hi,
On Fri, Jun 07, 2013 at 09:46:05PM +0300, Grygorii Strashko wrote:
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
Hi,
On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote:
ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be
Have you seen that happen ever ? AL is Arbitration Lost, we never put
OMAP in a multi-master environment before.
ARDY | NACK I also find it a bit
On Fri, Jun 07, 2013 at 05:42:22PM +0200, Gregory CLEMENT wrote:
From: Zbigniew Bodek z...@semihalf.com
The I2C Transaction Generator offloads CPU from managing I2C
transfer step by step.
This feature is currently only available on Armada XP, so usage of
this mechanism is activated
Grygorii Strashko grygorii.stras...@ti.com writes:
From: Kevin Hilman khil...@deeprootsystems.com
Currently, runtime PM is used to keep the device enabled only during
active transfers and for a configurable runtime PM autosuspend timout
after an xfer.
In addition to idling the device,
34 matches
Mail list logo
