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 4/7] tegra: Add I2C driver
Date: Fri, 13 Jan 2012 08:12:10 +0100	[thread overview]
Message-ID: <4F0FD94A.304@denx.de> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17801D1D66@HQMAIL01.nvidia.com>

Hello Stephen,

Stephen Warren wrote:
> Simon Glass wrote ednesday, January 11, 2012 9:18 PM:
>> On Mon, Jan 9, 2012 at 2:07 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>> On 12/26/2011 11:11 AM, Simon Glass wrote:
>>>> From: Yen Lin <yelin@nvidia.com>
>>>>
>>>> Add basic i2c driver for Tegra2 with 8- and 16-bit address support.
>>>> The driver supports building both with and without CONFIG_OF_CONTROL.
>>>>
>>>> Without CONFIG_OF_CONTROL a number of CONFIG options must be supplied
>>>> in the board config header file:
>>>>
>>>> I2CSPEED_KHZ - speed to run I2C bus at (typically 100000)
>>>> CONFIG_I2Cx_PIN_MUX - pin mux setting for each port (P, 1, 2, 3)
>>>>         (typically this will be 0 to bring the port out the common
>>>>                 pins)
> ...
> 
>>> ...
>>>> diff --git a/drivers/i2c/tegra2_i2c.c b/drivers/i2c/tegra2_i2c.c
>>> ...
>>>> +struct i2c_bus i2c_controllers[CONFIG_SYS_MAX_I2C_BUS];
>>> What if there are I2C bus extenders/muxes/... such that there are more
>>> I2C buses in the system than Tegra I2C controllers? I'd rather see an
>>> explicit TEGRA_I2C_NUM_CONTROLLERS define used throughout this patch.
>> We don't actually support CONFIG_I2C_MUX, so I can't see how that
>> could happen. Can you please explain a bit more?
> 
> We may not support it now, but I see no reason we won't in the future.
> If we confuse the two defines now, it'll make it harder to allow muxes
> in the future. The fix is simply using the correct define name within
> the I2C driver isn't it; pretty simple.

If we really have this case, we *must* get the multibus/multiadapter
branch from here:

http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/multibus_v2_20111112

to uboot mainline! With that approach we could handle this case
in a clean way ... This branch is not in sync with current TOT, and
it has to be tested again, as I didn't found time for this in the
last year :-( Also, as its base is >2 years old, there are a lot
of checkpatch errors in this patchserie, which have to be cleaned
up ... hope I get some time for it ... help is welcome.

>>>> +int i2c_init_board(void)
>>>> +{
[...]
>>> Surely that function needs to actually do something, at least set up the
>>> clocks so that the (user?) requested rate is honored, or print an error
>>> message if you're only allowed to use the hard-coded bus rate.
>> See my other message. I suppose we could reinit, but we really don't
>> want to honour the speed, since the fdt speed setting is then lost and
>> irrecoverable. For now it feels like we should ignore it.
> 
> Hmm. I suspect the answer here is roughly to override the following in
> cmd_i2c.c:
> 
> /* TODO: Implement architecture-specific get/set functions */
> unsigned int __def_i2c_get_bus_speed(void)
> {
>         return CONFIG_SYS_I2C_SPEED;
> }
> unsigned int i2c_get_bus_speed(void)
>         __attribute__((weak, alias("__def_i2c_get_bus_speed")));
> 
> int __def_i2c_set_bus_speed(unsigned int speed)
> {
>         if (speed != CONFIG_SYS_I2C_SPEED)
>                 return -1;
> 
>         return 0;
> }
> int i2c_set_bus_speed(unsigned int)
>         __attribute__((weak, alias("__def_i2c_set_bus_speed")));
> 
> To actually read/write the rate in use by the driver.

Yep, for this reason this functions are weak, and you can define
a driver specific function which returns the current used settings
in the driver.

Code should compile, if tegra2 not define CONFIG_SYS_I2C_SPEED,
as a "default" value for CONFIG_SYS_I2C_SPEED is defined in
include/i2c.h ...

> Then, fix do_i2c_reset() to use i2c_get_bus_speed() so it interacts
> correctly with those functions.

Yep, I think, you are right here, that should be fixed. As the
default function for i2c_get_bus_speed returns CONFIG_SYS_I2C_SPEED,
that should be OK.

> There may be other places that need to be updates to use those function
> instead of hard-coding CONFIG_SYS_I2C_SPEED too. Perhaps we could even
> get away without defining CONFIG_SYS_I2C_SPEED for Tegra since it's
> meaningless. Instead, ifdef those default function definitions above
> based on whether CONFIG_SYS_I2C_SPEED is defined or not.
> 

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-13  7:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-26 18:11 [U-Boot] [PATCH 0/7] tegra: Add I2C driver and associated parts Simon Glass
2011-12-26 18:11 ` [U-Boot] [PATCH 1/7] tegra: Rename NV_PA_PMC_BASE to TEGRA2_PMC_BASE Simon Glass
2011-12-26 19:12   ` Marek Vasut
2012-01-09 21:34   ` Stephen Warren
2011-12-26 18:11 ` [U-Boot] [PATCH 2/7] tegra: fdt: Add extra I2C definitions for U-Boot Simon Glass
2011-12-26 19:12   ` Marek Vasut
2011-12-27  4:35   ` Stephen Warren
2011-12-27  5:15     ` Simon Glass
2011-12-29  6:40       ` Stephen Warren
2011-12-29  7:11         ` Simon Glass
2011-12-26 18:11 ` [U-Boot] [PATCH 3/7] tegra: Add I2C support to funcmux Simon Glass
2012-01-09 21:36   ` Stephen Warren
2012-01-09 21:40     ` Simon Glass
2012-01-09 22:56       ` Simon Glass
2011-12-26 18:11 ` [U-Boot] [PATCH 4/7] tegra: Add I2C driver Simon Glass
2011-12-26 19:15   ` Marek Vasut
2012-01-08 16:57     ` Simon Glass
2012-01-08 17:06       ` Marek Vasut
2012-01-08 18:16         ` Simon Glass
2012-01-08  5:57   ` Mike Frysinger
2012-01-08 16:46     ` Simon Glass
2012-01-09 22:07   ` Stephen Warren
2012-01-12  4:17     ` Simon Glass
2012-01-12 19:14       ` Stephen Warren
2012-01-13  7:12         ` Heiko Schocher [this message]
2012-01-13 14:49           ` Simon Glass
2012-01-13 15:27             ` Heiko Schocher
2012-02-03 23:18         ` Simon Glass
2011-12-26 18:11 ` [U-Boot] [PATCH 5/7] tegra: Initialise I2C on Nvidia boards Simon Glass
2011-12-26 18:11 ` [U-Boot] [PATCH 6/7] tegra: Select I2C ordering for Seaboard Simon Glass
2012-01-09 21:42   ` Stephen Warren
2011-12-26 18:11 ` [U-Boot] [PATCH 7/7] tegra: Enable I2C on Seaboard Simon Glass
2012-01-09 21:45   ` Stephen Warren
     [not found]     ` <CAPnjgZ3jTm6j-fK_Kn==W3uGr=8pREEWXawP39kojLzzSH07wQ@mail.gmail.com>
     [not found]       ` <74CDBE0F657A3D45AFBB94109FB122FF17801D1D4A@HQMAIL01.nvidia.com>
2012-01-12 19:10         ` Simon Glass
2012-01-12 19:21           ` Stephen Warren
2012-01-12 19:28             ` Simon Glass
2012-01-13  7:34           ` 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=4F0FD94A.304@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