linux-kernel - Re: [PATCH v3] i2c: rk3x: Account for repeated start time requirement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20150113114714.GD7660@katana>
Date:	Tue, 13 Jan 2015 12:47:14 +0100
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Doug Anderson <dianders@...omium.org>
Cc:	max.schwarz@...ine.de, heiko@...ech.de,
	u.kleine-koenig@...gutronix.de, addy.ke@...k-chips.com,
	hl@...k-chips.com, cyw@...k-chips.com, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, linux-i2c@...r.kernel.org
Subject: Re: [PATCH v3] i2c: rk3x: Account for repeated start time requirement

On Thu, Dec 18, 2014 at 09:44:07AM -0800, Doug Anderson wrote:
> On Rockchip I2C the controller drops SDA low slightly too soon to meet
> the "repeated start" requirements.
> 
> From my own experimentation over a number of rates:
>  - controller appears to drop SDA at .875x (7/8) programmed clk high.
>  - controller appears to keep SCL high for 2x programmed clk high.
> 
> The first rule isn't enough to meet tSU;STA requirements in
> Standard-mode on the system I tested on.  The second rule is probably
> enough to meet tHD;STA requirements in nearly all cases (especially
> after accounting for the first), but it doesn't hurt to account for it
> anyway just in case.
> 
> Even though the repeated start requirement only need to be accounted
> for during a small part of the transfer, we'll adjust the timings for
> the whole transfer to meet it.  I believe that adjusting the timings
> in just the right place to switch things up for repeated start would
> require several extra interrupts and that doesn't seem terribly worth
> it.
> 
> With this change and worst case rise/fall times, I see 100kHz i2c
> going to ~85kHz.  With slightly optimized rise/fall (800ns / 50ns) I
> see i2c going to ~89kHz.  Fast-mode isn't affected much because
> tSU;STA is shorter relative to tHD;STA there.
> 
> As part of this change we needed to account for the SDA falling time.
> The specification indicates that this should be the same, but we'll
> follow Designware's lead and add a binding.  Note that we deviate from
> Designware and assign the default SDA falling time to be the same as
> the SCL falling time, which is incredibly likely.
> 
> Signed-off-by: Doug Anderson <dianders@...omium.org>

Applied to for-next, thanks!


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)