[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130619094540.GA2950@katana>
Date: Wed, 19 Jun 2013 11:45:40 +0200
From: Wolfram Sang <wsa@...-dreams.de>
To: Christian Ruppert <christian.ruppert@...lis.com>
Cc: Mika Westerberg <mika.westerberg@...ux.intel.com>,
linux-i2c@...r.kernel.org,
"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
Grant Likely <grant.likely@...retlab.ca>,
Rob Herring <rob.herring@...xeda.com>,
Rob Landley <rob@...dley.net>,
devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Vineet Gupta <Vineet.Gupta1@...opsys.com>,
Pierrick Hascoet <pierrick.hascoet@...lis.com>
Subject: Re: [PATCH REBASE] i2c-designware: make SDA hold time configurable
Hi,
On Wed, Jun 12, 2013 at 04:47:45PM +0200, Christian Ruppert wrote:
> On Mon, Jun 10, 2013 at 05:29:55PM +0200, Wolfram Sang wrote:
> > On Tue, May 14, 2013 at 03:04:02PM +0200, Christian Ruppert wrote:
> > > This patch makes the SDA hold time configurable through device tree.
> > >
> > > [rebased to i2c-current/i2c-next/mainline-3.10-rc1]
> > >
> > > Signed-off-by: Christian Ruppert <christian.ruppert@...lis.com>
> > > Signed-off-by: Pierrick Hascoet <pierrick.hascoet@...lis.com>
> >
> > Hmm, I really have problems adding a generic property. I need to better
> > understand why this is needed? What is the usecase? Can't a safe value
> > be calculated depending on the bus-speed? Is there a public datasheet
> > available somewhere?
>
> I checked with our PCB/Applications team and the data sheets for the
> peripherals in question (DVB demodulator front ends) are under NDA.
> Mika, you seem to be interested in this patch as well. Do you know of
> any publicly available data sheets for hardware requiring this
> adjustment?
So, I looked around and found:
http://www.maximintegrated.com/app-notes/index.mvp/id/3268
which after thinking further about it gives me the following
conclusions:
- sda-hold-time is a property/requirement of a device not following
the I2C spec. It is not a property of the master!
- It should not be encoded in the devicetree, since the flaw is implicit
to the device, so only the driver needs to know about it. I wonder
about something like this in the i2c slave driver:
ret = i2c_request_sda_hold_time(client);
The core then can collect the requests and forward them to the host
driver. This driver then can set up the hardware or return -EOPNOTSUPP
and we can even warn the user that there might be problems ahead.
- I wonder if we really need to have a parameter time-in-ns? The
specs cleary say 300ns, so I'd think this is the value we should
always use. This is from a theorhetical pov though, maybe your
practical experience is different. What values do you need?
> In the case of the Designware block, the parameter both changes SDA and
> START hold times, however, and you'll find lots of data sheets for
> hardware with START hold time requirements on the net, e.g.
> http://ww1.microchip.com/downloads/en/DeviceDoc/21805B.pdf
What I couldn't find is a reference manual for a designware IP that
supports sda hold time? I found some spear SoC which do not have that
register, so that should surely be reflected in the patchset, too.
> The empirical solution in the function i2c_dw_scl_hcnt does not seem to
> work in all cases: Our lab guys confirmed that we have several PCB
> designs which do not work without adjusting the sda-hold-time parameter
> to an appropriate value. The value seems to be different for different
> PCBs.
I'd hope that 300ns is a safe value for all PCBs?
> I suspect that this kind of configurability is not the same for all i2c
> bus master hardware.
Yeah, maybe some do sda-holding by default? Dunno, never checked for
that detail.
Regards,
Wolfram
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists