From: Ryan Mallon <ryan@bluewatersys.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: David Brownell <david-b@pacbell.net>,
Uli Luckas <u.luckas@road.de>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
i2c@lm-sensors.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] Earlier I2C initialization
Date: Mon, 30 Jun 2008 08:34:14 +1200 [thread overview]
Message-ID: <4867F1C6.2060201@bluewatersys.com> (raw)
In-Reply-To: <20080627124143.23ac7b7b@hyperion.delvare>
Jean Delvare wrote:
> Hi Ryan,
>
> On Fri, 27 Jun 2008 09:12:54 +1200, Ryan Mallon wrote:
>> Jean Delvare wrote:
>>> I don't like option 2 at all. drivers/i2c/early could be, but not
>>> drivers/i2c-early.
>> I don't think its a good idea either. The point was that in order to
>> have two sets of i2c drivers with different link order (with regard to
>> the rest of the driver subsystems) you would need two top level
>> directories in drivers/.
>
> I don't think so. Look at what the input subsystem does (from
> drivers/Makefile):
>
> obj-$(CONFIG_SERIO) += input/serio/
> obj-$(CONFIG_GAMEPORT) += input/gameport/
> obj-$(CONFIG_INPUT) += input/
>
> And there are similar examples with video (video/i810/ and
> video/intelfb/ are early in the list).
Ah, didn't realise that.
>We could do the same with i2c:
>
> obj-$(CONFIG_I2C) += i2c/early/
>
> (... lots of things ...)
>
> obj-$(CONFIG_I2C) += i2c/
>
> Of course this implies minor edits to drivers/i2c/Makefile. I don't
> know if we want to do that, but from a technical point of view it seems
> doable.
That certainly is a better solution if it is needed.
>
>> The other way of course, is to use one
>> directory, or subdirectories under drivers/i2c/ and use subsys_initcall.
Yeah, its probably the best solution for now. Doing the categorisation
of the busses will make it easy to split the directories/link order up
later if required.
>>> (...)
>>> If we are going to keep using subsys_initcall in bus drivers, then
>>> moving the bus drivers using it to a separate directory is not needed.
>>> Which doesn't mean we don't want to split the i2c bus drivers into
>>> subdirectories for other reasons, but I want to see this as a separate
>>> issue. BTW, I started categorizing the different types of i2c bus
>>> drivers:
>>> http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/i2c-group-bus-drivers.patch
>>> If you want to help with embedded stuff or SOC or whatever makes sense
>>> to group together, please do! For now, everything I am not familiar
>>> with is in group "Others".
>> I don't know all of the embedded systems, but at a glance the following
>> busses from your others section are used on embedded ARM processors:
>>
>> i2c-at91
>> i2c-davinci
>> i2c-ixp2000
>> i2c-omap
>> i2c-pxa
>> i2c-s3c2410
>> i2c-versatile
>
> OK, I've moved these to a section titled "Embebbed system I2C host
> controller drivers", thanks.
Cool.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon Unit 5, Amuri Park
Phone: +64 3 3779127 404 Barbadoes St
Fax: +64 3 3779135 PO Box 13 889
Email: ryan@bluewatersys.com Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934
next prev parent reply other threads:[~2008-06-29 20:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200806091541.43899.u.luckas@road.de>
[not found] ` <20080609135739.GE30971@flint.arm.linux.org.uk>
[not found] ` <484D947D.1090900@bluewatersys.com>
[not found] ` <484D947D.1090900-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-09 20:59 ` Earlier I2C initialization David Brownell
[not found] ` <200806091359.12791.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
2008-06-09 21:27 ` [PATCH, RFC] " Ryan Mallon
2008-06-10 6:57 ` Jean Delvare
2008-06-10 20:55 ` David Brownell
[not found] ` <200806101355.07792.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
2008-06-11 8:11 ` Jean Delvare
2008-06-11 9:00 ` Russell King - ARM Linux
[not found] ` <20080611090016.GA5338-f404yB8NqCZvn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2008-06-11 9:14 ` Jean Delvare
[not found] ` <48503432.6010105@bluewatersys.com>
[not found] ` <48503432.6010105-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-11 12:05 ` Jean Delvare
2008-06-11 18:31 ` David Brownell
2008-06-12 18:44 ` Jean Delvare
2008-06-12 19:57 ` David Brownell
2008-06-24 17:06 ` Jean Delvare
[not found] ` <20080611101130.1a667abe-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-06-11 20:23 ` Ryan Mallon
2008-06-10 21:33 ` Ryan Mallon
2008-06-10 9:46 ` Uli Luckas
2008-06-11 3:12 ` Ryan Mallon
2008-06-11 7:40 ` Jean Delvare
[not found] ` <485031D5.3020606@bluewatersys.com>
[not found] ` <485031D5.3020606-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-11 12:18 ` Jean Delvare
2008-06-11 20:27 ` David Brownell
2008-06-11 20:54 ` Jean Delvare
2008-06-11 21:24 ` Ryan Mallon
[not found] ` <485042A6.3030705-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-24 16:39 ` Jean Delvare
2008-06-26 21:12 ` Ryan Mallon
2008-06-27 10:41 ` Jean Delvare
2008-06-29 20:34 ` Ryan Mallon [this message]
2008-06-11 21:31 ` Maciej W. Rozycki
2008-06-12 20:21 ` David Brownell
[not found] ` <20080611094039.287ac136-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-06-11 20:13 ` Ryan Mallon
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=4867F1C6.2060201@bluewatersys.com \
--to=ryan@bluewatersys.com \
--cc=david-b@pacbell.net \
--cc=i2c@lm-sensors.org \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=u.luckas@road.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