All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH]fsl_i2c: Move i2c_board_init to after i2c_init operations
Date: Mon, 12 Apr 2010 20:17:50 +0200	[thread overview]
Message-ID: <20100412181750.9581F19F60@gemini.denx.de> (raw)
In-Reply-To: <20100412180215.GA11973@richardretanubun.eng.lan>

Dear richardretanubun at ruggedcom.com,

In message <20100412180215.GA11973@richardretanubun.eng.lan> you wrote:
> From 00f84e4a9a2d13971c9328fc815825456b25f760 Mon Sep 17 00:00:00 2001
> From: Richard Retanubun <richardretanubun@ruggedcom.com>
> Date: Mon, 12 Apr 2010 13:32:09 -0400
> Subject: [PATCH] fsl_i2c: Move the call for i2c_init_board to the end of i2c_init
> 
> This patch moved the call to i2c_init_board to the end of i2c_init.
> This allows the board fixup functions to take advantage of the
> setups done by i2c_init (i.e. bus speed and slave address).
> 
> On other boards, i2c_init_board is called before i2c_init operation
> because the method of resetting i2c bus typically uses GPIOs
> to bit-bang SCLK. For i2c controllers that is using fsl_i2c this is
> unneccessary because there is a i2c register access sequence that
> accomplish the same thing, and it is better to do the accesses
> after the bus speed and slave address have been configured.

I dislike such inconsitent behaviour. It would be better if we could
rely on a specific initialization sequence, i. e. the function always
be called at the beginning or always at the end. Having to deal with
a situation where one or the other might happen, even on the same
hardware, depending on if we use the HW or the SW I2C driver, sounds
like a nightmare to me.

If you need a late init function, then better add a new one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Have you lived in this village all your life?"        "No, not yet."

  reply	other threads:[~2010-04-12 18:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-09 17:22 [U-Boot] Moving i2c_board_init to after i2c_init operations Richard Retanubun
2010-04-12  6:11 ` Heiko Schocher
2010-04-12 18:02   ` [U-Boot] [PATCH]fsl_i2c: Move " richardretanubun at ruggedcom.com
2010-04-12 18:17     ` Wolfgang Denk [this message]
2010-04-12 18:22       ` Richard Retanubun
2010-04-12 18:38         ` Wolfgang Denk
2010-04-12 19:17           ` [U-Boot] [PATCH]fsl_i2c: Add i2c_board_late_init richardretanubun at ruggedcom.com
2010-04-12 19:28             ` Wolfgang Denk
2010-04-14  7:02               ` Heiko Schocher
2010-04-14 15:48                 ` [U-Boot] [PATCH v3]fsl_i2c: " richardretanubun at ruggedcom.com
2010-04-12 19:32             ` [U-Boot] [PATCH v2]fsl_i2c: " richardretanubun at ruggedcom.com

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=20100412181750.9581F19F60@gemini.denx.de \
    --to=wd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.