public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support
Date: Thu, 19 Jan 2012 07:35:33 +0100	[thread overview]
Message-ID: <4F17B9B5.2040303@denx.de> (raw)
In-Reply-To: <20120119053636.3018F188E691@gemini.denx.de>

Hello Wolfgang, Timur, Simon,

Wolfgang Denk wrote:
> Dear Simon Glass,
> 
> In message <CAPnjgZ2kLPfMzzwgHkDJ4eL+wixqLv89+CvdVP7PCcy+XFaqNQ@mail.gmail.com> you wrote:
>>> I was really hoping we could get rid of the concept of a "current" i2c
>>> adapter, and just force all drivers to specify the I2C adapter they
>>> want to use for a given I2C operation. =A0That's how Linux operates, and
>>> it will prevent stuff like this:
>> I agree completely, it was one of the things I was going to ask for.
>> We should add a new parameter to calls instead IMO.
> 
> Let's do one step at a time.  Now we go for multi-bus support.

Ok.

> Implementing a new, better device interface is one of the next steps,
> then.

Some thoughts to the subject "get rid of concept of a current i2c"

- First, it would be great to get rid of that ;-)

- 2 reasons why we currently need the info, what is the current
  i2c adapter/i2c bus:

- U-Boot principle says, don't init a device, if you don't use it.
  So, if we switch to another i2c adapter or i2c bus (A i2c bus is a
  combination if one i2c adpater and n i2c muxes), we must deinit
  the current adapter/bus. Ok, current code didn't this too, but
  this should a goal to keep in mind ... or we define, that this
  is not needed.

- If we have i2c muxes, and you don't know your current i2c bus,
  you must on every i2c access also setup the i2c muxes on this
  i2c bus ... would we do this really?
  if we have the current i2c bus info, we just have to check, if
  we are on this bus, and do the i2c access ... if we are not on
  this i2c bus, we can deinit it complete (the new i2c_core disconnects
  for example all i2c muxes on the i2c bus) and init the new bus.
  All this work is done in a central function i2c_set_bus_numer()

- Looking in the new multibus i2c_core.c file, we should get rid of

  static unsigned int i2c_cur_bus __attribute__((section(".data"))) =
                                CONFIG_SYS_SPD_BUS_NUM;

  and "cur_adap" renamed to "cur_i2c_bus" and should be a
  "struct i2c_bus_hose" pointer.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2012-01-19  6:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-17  7:12 [U-Boot] [PATCH 0/3] Bring in new I2C framework Simon Glass
2012-01-17  7:12 ` [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support Simon Glass
2012-01-17 19:23   ` Mike Frysinger
2012-01-18 20:11   ` Tabi Timur-B04825
2012-01-18 20:41     ` Mike Frysinger
2012-01-18 20:43       ` Timur Tabi
2012-01-18 21:37     ` Simon Glass
2012-01-18 21:39       ` Timur Tabi
2012-01-18 22:21         ` Simon Glass
2012-01-18 22:24           ` Timur Tabi
2012-01-19  5:36       ` Wolfgang Denk
2012-01-19  6:35         ` Heiko Schocher [this message]
2012-01-19  6:53           ` Simon Glass
2012-01-19  7:53             ` Heiko Schocher
2012-01-19 18:07               ` Simon Glass
2012-01-19 11:20             ` Wolfgang Denk
2012-01-19 18:10               ` Simon Glass
2012-01-19 18:47               ` Timur Tabi
2012-01-20  6:50                 ` Heiko Schocher
2012-01-17  7:12 ` [U-Boot] [PATCH 2/3] i2c: common changes for multibus/multiadapter support Simon Glass
2012-01-17  7:12 ` [U-Boot] [PATCH 3/3] WIP: tegra: i2c: Enable new I2C framework Simon Glass
2012-01-17  8:51   ` Heiko Schocher
2012-01-17  8:30 ` [U-Boot] [PATCH 0/3] Bring in " Heiko Schocher
  -- strict thread matches above, loose matches on Subject: below --
2012-10-22 17:40 Heiko Schocher
2012-10-22 17:40 ` [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support 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=4F17B9B5.2040303@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