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
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 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 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.
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 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
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
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
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. Bus/clock speed is totally
pointless concept for the I2C bus systems. For
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. Bus/clock speed is totally
pointless concept for the I2C bus systems. For
> 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-kernel" in
the body of a message to majord...@vger.kernel.org
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
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-kernel in
the body of a message to majord...@vger.kernel.org
> > >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
On Wed, Jul 24, 2013 at 11:31:44PM +0900, Shinya Kuribayashi wrote:
> 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
On Wed, Jul 24, 2013 at 11:31:44PM +0900, Shinya Kuribayashi wrote:
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
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 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
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 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
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
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 slightly old version of DW I2C core
around 2005, version 1.06a or so), DW I2C
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,
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 Westerberg wrote:
On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian
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 Westerberg wrote:
On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian
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
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 slightly old version of DW I2C core
around 2005, version 1.06a or so), DW I2C
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 Westerberg wrote:
> > > On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote:
> > > > What I meant
On Wed, Jul 10, 2013 at 06:56:35PM +0200, Christian Ruppert wrote:
> 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
On Wed, Jul 10, 2013 at 06:56:35PM +0200, Christian Ruppert wrote:
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
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 Westerberg wrote:
On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote:
What I meant is the
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
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
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 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
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
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
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,
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
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
52 matches
Mail list logo
