All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] WIP: tegra: i2c: Enable new CONFIG_SYS_I2C framework
Date: Tue, 13 Nov 2012 10:30:06 -0700	[thread overview]
Message-ID: <50A2839E.1030905@wwwdotorg.org> (raw)
In-Reply-To: <50A1E780.4090807@denx.de>

On 11/12/2012 11:24 PM, Heiko Schocher wrote:
> Hello Stephen,
> 
> On 08.11.2012 18:05, Stephen Warren wrote:
>> On 11/07/2012 11:47 PM, Heiko Schocher wrote:
>>> On 01.11.2012 18:03, Stephen Warren wrote:
>> ...
>>>> I'd suggest having a CONFIG_SYS_I2C_DRIVERS variable at most, and each
>>>> driver registers an arbitrary number of adapters and/or buses during
>>>> its
>>>> initialization.
>>>
>>> Why should an i2c driver register buses? That is board specific.
>>
>> I don't entirely agree here. Certainly the information is
>> board-specific, but I don't believe that precludes bus registration
>> occurring from the I2C adapter drivers themselves, based on information
>> passed from a board file or device tree.
>>
>> If a particular adapter is instantiated by the board, then there is
>> clearly an I2C bus attached to that adapter. Hence, it's quite
>> reasonable for the adapter itself to register the bus directly attached
>> to it.
> 
> But some i2c drivers have more than one instance... would you for all
> boards register all possible instances of a driver? ...

Register, but perhaps not initialize, seems fine to me.

After all, what if the user wishes to use the I2C adapters for some
custom command; up-front registration of all valid adapters is required
for that, although actual initialization can always be deferred until
if/when the adapter is actually used.

The other issue is that as I pointed out before, the move to define
which I2C (and all other peripheral) adapters are used via device tree
rather than board/config files on some U-Boot platforms seems completely
at odds with not always registering all I2C adapters, at least on the
platforms that use device tree.

>> Following on from there, if there's an I2C bus mux attached to some I2C
>> bus, then there are clearly I2C buses downstream from the bus mux, and
>> the bus mux driver knows exactly how many there are, and can register
>> those buses.
> 
> Here again, why register all possible buses? We are just a bootloader ...

I don't see how being a bootloader is relevant. After all, people can
use for example U-Boot I2C or GPIO commands for board bringup, to
implement HW initialization via custom boot scripts, etc.

  parent reply	other threads:[~2012-11-13 17:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-30 17:28 [U-Boot] [PATCH 1/2] tegra: i2c: Add function to know about current bus Simon Glass
2012-10-30 17:28 ` [U-Boot] [PATCH 2/2] WIP: tegra: i2c: Enable new CONFIG_SYS_I2C framework Simon Glass
2012-10-30 22:32   ` Stephen Warren
2012-10-31  6:00     ` Heiko Schocher
2012-10-31 15:41       ` Stephen Warren
2012-10-31 15:56         ` Simon Glass
2012-10-31 16:25           ` Stephen Warren
2012-11-01  7:42             ` Heiko Schocher
2012-11-01 17:03               ` Stephen Warren
2012-11-05 20:39                 ` Simon Glass
2012-11-08  7:02                   ` Heiko Schocher
2012-11-08 18:03                     ` Simon Glass
2012-11-08  6:47                 ` Heiko Schocher
2012-11-08 17:05                   ` Stephen Warren
2012-11-13  6:24                     ` Heiko Schocher
2012-11-13  7:48                       ` Wolfgang Denk
2012-11-13 17:30                       ` Stephen Warren [this message]
2012-10-31  5:53   ` Heiko Schocher
2012-10-31  5:26 ` [U-Boot] [PATCH 1/2] tegra: i2c: Add function to know about current bus Heiko Schocher
2012-11-05 20:43   ` Simon Glass
2012-11-08  7:05     ` 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=50A2839E.1030905@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --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.