From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/3] Bring in new I2C framework
Date: Wed, 31 Oct 2012 06:02:03 +0100 [thread overview]
Message-ID: <5090B0CB.1030209@denx.de> (raw)
In-Reply-To: <CAPnjgZ0kdEQtSr==Zw_ty2qS5wmqjjr9DMKMxRF0CZMAN0jEvg@mail.gmail.com>
Hello Simon,
On 30.10.2012 18:22, Simon Glass wrote:
> Hi,
>
> On Tue, Oct 30, 2012 at 9:50 AM, Stephen Warren<swarren@wwwdotorg.org> wrote:
>> On 10/29/2012 11:57 PM, Heiko Schocher wrote:
>>> Hello Stephen,
>>>
>>> On 29.10.2012 16:34, Stephen Warren wrote:
>> ...
>>>> If there are e.g. 4 I2C controllers in an SoC, the driver needs to know
>>>> which one is in use. Passing that information directly to the driver
>>>> functions is much simple than requiring the SoC I2C driver to go grovel
>>>> in some I2C core global variables to find out the same information.
>>>
>>> Ah, do you mean we should change the i2c adapter struct from:
>>>
>>> struct i2c_adapter {
>>> void (*init)(int speed, int slaveaddr);
>>> int (*probe)(uint8_t chip);
>>> int (*read)(uint8_t chip, uint addr, int alen,
>>> uint8_t *buffer, int len);
>>> int (*write)(uint8_t chip, uint addr, int alen,
>>> uint8_t *buffer, int len);
>>> uint (*set_bus_speed)(uint speed);
>>> [...]
>>>
>>> to
>>>
>>> struct i2c_adapter {
>>> void (*init)(struct i2c_adapter *adap, int speed, int
>>> slaveaddr);
>>> int (*probe)(struct i2c_adapter *adap, uint8_t chip);
>>> int (*read)(struct i2c_adapter *adap, uint8_t chip,
>>> uint addr, int alen,
>>> uint8_t *buffer, int len);
>>> int (*write)(struct i2c_adapter *adap, uint8_t chip,
>>> uint addr, int alen,
>>> uint8_t *buffer, int len);
>>> uint (*set_bus_speed)(struct i2c_adapter *adap, uint
>>> speed);
>>> [...]
>>> ?
>>>
>>> We can do this. Simon suggested this too ...
>>
>> Yes, exactly. (the functions will need some way to get information out
>> of the struct i2c_adapter; I assume there's some kind of driver_private
>> field in there too).
>
> Yes.
>
> I will post a few patches to move Tegra over to the new framework as
> it is, so that people can see the impact. Given that every driver has
> to change, it would be my preference to set the i2c API once. But I
> suppose within a short while everything will move to the device model,
> so perhaps the job of this series is just to move things in the right
> direction?
Yes, but not only, I think the i2c framework needs an update.
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:[~2012-10-31 5:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 17:40 [U-Boot] [PATCH 0/3] Bring in new I2C framework Heiko Schocher
2012-10-22 17:40 ` [U-Boot] [PATCH 1/3] i2c: add i2c_core and prepare for new multibus support Heiko Schocher
2012-10-22 17:40 ` [U-Boot] [PATCH 2/3] i2c: common changes for multibus/multiadapter support Heiko Schocher
2012-10-22 22:16 ` Henrik Nordström
2012-10-23 3:25 ` Heiko Schocher
2012-10-22 17:40 ` [U-Boot] [PATCH 3/3] i2c, soft-i2c: switch to new " Heiko Schocher
2012-10-25 21:37 ` [U-Boot] [PATCH 0/3] Bring in new I2C framework Simon Glass
2012-10-26 5:48 ` Heiko Schocher
2012-10-26 16:07 ` Stephen Warren
2012-10-29 9:47 ` Heiko Schocher
2012-10-29 15:34 ` Stephen Warren
2012-10-29 15:56 ` Simon Glass
2012-10-30 5:57 ` Heiko Schocher
2012-10-30 16:50 ` Stephen Warren
2012-10-30 17:22 ` Simon Glass
2012-10-31 5:02 ` Heiko Schocher [this message]
2012-10-31 5:20 ` Tom Rini
2012-10-26 16:08 ` Simon Glass
2012-10-29 9:44 ` Heiko Schocher
2012-10-29 13:48 ` Simon Glass
2012-10-30 5:44 ` Heiko Schocher
2012-10-26 18:44 ` Tom Rini
2012-10-29 9:53 ` Heiko Schocher
2012-10-30 22:38 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2012-01-17 7:12 Simon Glass
2012-01-17 8:30 ` 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=5090B0CB.1030209@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 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.