On Sat, Aug 24, 2013 at 01:58:47PM +0900, Shinya Kuribayashi wrote:
On 8/21/13 11:39 PM, Christian Ruppert wrote:
On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote:
On 8/5/13 6:31 PM, Christian Ruppert wrote:
On Wed, Jul 24, 2013 at 11:31:44PM +0900, Shinya Kuribayashi wrote:
On 8/21/13 11:39 PM, Christian Ruppert wrote:
On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote:
On 8/5/13 6:31 PM, Christian Ruppert wrote:
On Wed, Jul 24, 2013 at 11:31:44PM +0900, Shinya Kuribayashi wrote:
As said before, all t_SCL things should go away. Please forget
On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote:
Hi,
On 8/5/13 6:31 PM, Christian Ruppert wrote: On Wed, Jul 24, 2013 at
11:31:44PM +0900, Shinya Kuribayashi wrote:
As said before, all t_SCL things should go away. Please forget
about 100kbps, 400kbps, and so on.
Sorry for the slooow response, I've been on vacation.
On Tue, Jul 16, 2013 at 01:16:18PM +0200, Christian Ruppert wrote:
Second step is that if current i2c_dw_scl_hcnt and i2c_dw_scl_lcnt
calculations don't suit with later DW I2C cores, then it would be
nice for someone who can access to
On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote:
Actually, the I2C specification clearly defines f_SCL;max (and thus
implies t_SCL;min), both in the tables and the timing diagrams. Why can
we ignore this constraint while having to meet all the others?
If we meet t_r, t_f,
Hi,
On 8/19/13 8:36 PM, Mika Westerberg wrote:
On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote:
Actually, the I2C specification clearly defines f_SCL;max (and thus
implies t_SCL;min), both in the tables and the timing diagrams. Why can
we ignore this constraint while having
On Mon, Aug 05, 2013 at 12:02:26PM +0200, Wolfram Sang wrote:
Would it make sense to add generic I2C device tree properties for those
parameters? These parameters are independent of the actual bus driver,
rather a PCB property... And as such the correct place would be device
tree or
Every driver would thus have to implement its own defaults in case the
properties are not defined.
Placing the defaults at driver level sounds fine to me.
Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More
Would it make sense to add generic I2C device tree properties for those
parameters? These parameters are independent of the actual bus driver,
rather a PCB property... And as such the correct place would be device
tree or ACPI or similar.
If there are other bus drivers that make use
On 7/22/13 10:17 PM, Christian Ruppert wrote: On Wed, Jul 17, 2013 at
11:39:58PM +0900, Shinya Kuribayashi wrote:
On 7/16/13 8:16 PM, Christian Ruppert wrote: On Sat, Jul 13, 2013 at
02:36:43PM +0900, Shinya Kuribayashi wrote:
Basically, DW I2C core provides a good enough (and quite direct)
On Wed, Jul 17, 2013 at 11:39:58PM +0900, Shinya Kuribayashi wrote:
On 7/16/13 8:16 PM, Christian Ruppert wrote: On Sat, Jul 13, 2013 at
02:36:43PM +0900, Shinya Kuribayashi wrote:
Basically, DW I2C core provides a good enough (and quite direct) way
to control tHIGH and tLOW timing specs,
On 7/16/13 8:16 PM, Christian Ruppert wrote: On Sat, Jul 13, 2013 at
02:36:43PM +0900, Shinya Kuribayashi wrote:
Basically, DW I2C core provides a good enough (and quite direct) way
to control tHIGH and tLOW timing specs, *HCNT and *LCNT registers.
But from my experience (with a slightly old
On Sat, Jul 13, 2013 at 02:36:43PM +0900, Shinya Kuribayashi wrote:
Hi,
Now I've had a look at the whole discussion.
Basically, DW I2C core provides a good enough (and quite direct) way
to control tHIGH and tLOW timing specs, *HCNT and *LCNT registers.
But from my experience (with a
On Fri, Jul 12, 2013 at 04:56:49PM +0900, Shinya Kuribayashi wrote:
On 7/11/13 7:13 PM, Mika Westerberg wrote:
On Thu, Jul 11, 2013 at 10:36:00AM +0300, Mika Westerberg wrote:
On Wed, Jul 10, 2013 at 06:56:35PM +0200, Christian Ruppert wrote:
On Wed, Jul 10, 2013 at 01:52:15PM +0300, Mika
On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote:
What I meant is the following: The clock cycle time Tc is composed of
the four components
Tc = Th + Tf + Tl + Tr
where
Th: Time during which the signal is high
Tf: Falling edge transition time
Tl: Time during
On Wed, Jul 10, 2013 at 01:52:15PM +0300, Mika Westerberg wrote:
On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote:
What I meant is the following: The clock cycle time Tc is composed of
the four components
Tc = Th + Tf + Tl + Tr
where
Th: Time during which the
On Mon, Jul 08, 2013 at 03:42:17PM +0200, Christian Ruppert wrote:
On Mon, Jul 08, 2013 at 02:45:26PM +0300, Mika Westerberg wrote:
The DesignWare I2C controller has high count (HCNT) and low count (LCNT)
registers for each of the I2C speed modes (standard and fast). These
registers are
On Tue, Jul 09, 2013 at 11:44:02AM +0300, Mika Westerberg wrote:
On Mon, Jul 08, 2013 at 03:42:17PM +0200, Christian Ruppert wrote:
On Mon, Jul 08, 2013 at 02:45:26PM +0300, Mika Westerberg wrote:
The DesignWare I2C controller has high count (HCNT) and low count (LCNT)
registers for each
The DesignWare I2C controller has high count (HCNT) and low count (LCNT)
registers for each of the I2C speed modes (standard and fast). These
registers are programmed based on the input clock speed in the driver.
However, that is not always the most accurate way. For example on Intel
BayTrail we
On Mon, Jul 08, 2013 at 02:45:26PM +0300, Mika Westerberg wrote:
The DesignWare I2C controller has high count (HCNT) and low count (LCNT)
registers for each of the I2C speed modes (standard and fast). These
registers are programmed based on the input clock speed in the driver.
However, that
20 matches
Mail list logo