From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
Date: Mon, 03 Jun 2013 07:13:43 +0200 [thread overview]
Message-ID: <51AC2607.3000209@denx.de> (raw)
In-Reply-To: <b86865dc92ed31d2d2383c832a356e28.squirrel@www.mm-sol.com>
Hello Lubomir,
Am 02.06.2013 13:42, schrieb Lubomir Popov:
>> Hello Lubomir,
>>
>> Am 01.06.2013 18:44, schrieb Lubomir Popov:
>>> New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
>>> (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
>>> OMAPs and derivatives as well. The only anticipated exception would
>>> be the OMAP2420, which shall require driver modification.
[...]
>>> drivers/i2c/omap24xx_i2c.c | 490 +++++++++++++++++++++++++++------------------
>>> 1 file changed, 299 insertions(+), 191 deletions(-)
>>
>> Tested on 3 arm335x based boards, which one uses i2c in SPL
>> code for getting ram parameters, so:
>>
>> Tested-by: Heiko Schocher <hs@denx.de>
> Many thanks for testing, to Tom as well (he did it on the
> Beagleboards, but for one of the older versions, V3 I believe,
> right?).
> When it comes to versions, I see that V1 and V2 are still listed
> in patchwork, probably because of slightly different wording of
> the subject:
> http://patchwork.ozlabs.org/patch/233823/
> http://patchwork.ozlabs.org/patch/246204/
> Could you or Tom clean this up, please? Thanks.
Cleared the v3 v4 version, but missed the v2 and v1, Done.
>> Just one comment:
>> Your patch has 9 checkpatch warnings which are all lines
>> (printf strings) over 80 chars ... some with lines > 110
>> characters ... I know, tom gave you a OK for this ... I am
>> also unhappy with splitting a printf-string over 2 or more lines ...
>> but we have this 80 characters rule ... Wolfgang, what do you
>> think? Should we loosen this rule for printf-strings?
> Yes, I had the long strings splitted in the older versions, but
> then unrolled them back as per Tom's recommendation. IMHO, grep-ability
> is worth breaking this particular rule... But perhaps only for pure
Yep.
> strings w/o format placeholders? I mean, strings could be splitted
> at the format parameters of printf/sprintf arguments.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2013-06-03 5:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-01 16:44 [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions Lubomir Popov
2013-06-02 5:20 ` Heiko Schocher
2013-06-02 11:42 ` Lubomir Popov
2013-06-03 5:13 ` Heiko Schocher [this message]
2013-06-04 4:26 ` Heiko Schocher
2013-06-04 6:49 ` Lubomir Popov
2013-06-04 7:03 ` Heiko Schocher
2013-06-04 21:38 ` Tom Rini
2013-06-02 13:08 ` Tom Rini
2013-06-03 5:15 ` Heiko Schocher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51AC2607.3000209@denx.de \
--to=hs@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox