From: Felipe Balbi <me@felipebalbi.com>
To: David Brownell <david-b@pacbell.net>
Cc: Felipe Balbi <felipe.balbi@nokia.com>, linux-omap@vger.kernel.org
Subject: Re: [PATCH 0/2] twl4030-usb patches
Date: Tue, 2 Sep 2008 21:58:06 +0300 [thread overview]
Message-ID: <20080902185804.GD6814@frodo> (raw)
In-Reply-To: <200809020839.28372.david-b@pacbell.net>
On Tue, Sep 02, 2008 at 08:39:28AM -0700, David Brownell wrote:
> On Tuesday 02 September 2008, Felipe Balbi wrote:
> >
> > The following patches convert twl4030-usb to a platform_device
> > in order to set the usb mode via platform_data and get
> > rid of the Kconfig entry for that.
>
> Shouldn't twl4030 first be converted to be a "new style"
> I2C driver? Then if this approach is to be used, its
> probe() would create those platform devices as children
> of the I2C device node, and with relevant platform_data.
In that case, how would handle the case where more than one twl client
sits in the same i2c address ?
USB is alone on one id, but vibrator, pwm and others (sorry, at home
without docs) shares the same id. How would you pass the proper
platform_data to different drivers ?
I'd say a good approach, would be to let twl4030-core.c handle all the i2c
communication and the other twl modules become a platform_device using
the read/write functions exported from twl4030-core.c
> The platform_data for all those child devices should be
> provided as part of the platform_data for the "main" TWL
> driver, so everything can be properly board-specific.
let me get it straight. You mean something like:
struct twl4030_core_platform_data {
struct twl4030_usb_platform_data *usb_data;
struct twl4030_rtc_platform_data *rtc_data;
[...]
};
Hmm... yeah, maybe that could work. But I'd have to see how you're
thinking of letting twl4030-core.c create all the platform_devices for
all the other modules.
One thing we might say, Jean Delvare won't accept twl4030 the way it is
now. Old style i2c drivers will be dropped soon. We have to get twl4030
properly done otherwise it'll be a pain later.
> Also, since it seems twl4030 docs won't become public
> but docs for its catalog versions[0] will, it'd be good
> to update file headers and Kconfig to mention tps659x0
> parts so that folk without twl4030 NDA's can eventually
> work with this code...
Good idea. I'm sure we should do it at some point. Thanks for the link.
--
balbi
next prev parent reply other threads:[~2008-09-02 18:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 12:31 [PATCH 0/2] twl4030-usb patches Felipe Balbi
2008-09-02 12:31 ` [PATCH 1/3] i2c: twl4030-usb: move to platform_device Felipe Balbi
2008-09-02 12:31 ` [PATCH 2/2] i2c: twl4030-usb: add 'vbus' sysfs file Felipe Balbi
2008-09-02 12:34 ` [PATCH 0/2] twl4030-usb patches Felipe Balbi
2008-09-02 15:43 ` David Brownell
2008-09-02 18:48 ` Felipe Balbi
2008-09-02 19:52 ` David Brownell
2008-09-02 15:39 ` David Brownell
2008-09-02 18:58 ` Felipe Balbi [this message]
2008-09-02 19:37 ` David Brownell
2008-09-02 19:49 ` Felipe Balbi
2008-09-02 20:15 ` David Brownell
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=20080902185804.GD6814@frodo \
--to=me@felipebalbi.com \
--cc=david-b@pacbell.net \
--cc=felipe.balbi@nokia.com \
--cc=linux-omap@vger.kernel.org \
/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