From: David Brownell <david-b@pacbell.net>
To: Tony Lindgren <tony@atomide.com>, Manikandan Pillai <mani.pillai@ti.com>
Cc: linux-omap@vger.kernel.org, broonie@sirena.org.uk
Subject: Re: [PATCH 2/2] Changes for adding and building TPS6235x based PR785 board support
Date: Tue, 13 Jan 2009 13:49:09 -0800 [thread overview]
Message-ID: <200901131349.09907.david-b@pacbell.net> (raw)
In-Reply-To: <20090113145909.GQ7344@atomide.com>
On Tuesday 13 January 2009, Tony Lindgren wrote:
> The the read/write_reg should be in drivers/mfd somewhere.
I wouldn't think so ... it's not an MFD, it's just a
regulator that has a feature that's not yet envisioned
by the current regulator framework. (Floor/Ceiling
controls, basically.)
> > @@ -160,5 +218,14 @@ int __init omap_register_i2c_bus(int bus_id, u32
> > clkrate, }
> >
> > omap_i2c_mux_pins(bus_id - 1);
> > - return platform_device_register(pdev);
> > + platform_device_register(pdev);
> > +#if defined(CONFIG_OMAP3EVM_PR785)
> > + if (bus_id == 1) {
> > + omap_i2c_register_child(pdev, "vdd2_consumer", \
> > + &vdd2_platform_device);
> > + omap_i2c_register_child(pdev, "vdd1_consumer", \
> > + &vdd1_platform_device);
> > + }
> > +#endif
> > + return 0;
> > }
>
> Argh, i2c-omap.c is the _bus_ driver, not i2c device!
Right. I don't understand why there's this urge to
scatter board-specific code throughout the driver
tree, instead of leaving it all in mach-omap2/pr785.c
and having the tps6235x.c driver be a pure regulator
driver...
> How different tps6235 is from the twl4030? Maybe you can just add
> functionality to the existing drivers/mfd/twl4030-core.c.
It's very different ... the tps623x chips are trivial,
with about four registers each. No capability OTHER
than being a voltage regulator.
Which is why it's puzzling to see it take so long to
just get a simple voltage regulator driver patch...
Admittedly, the regulator framework is new, and parts
of it still seem to me like they have design problems.
But even so, it's not so hard to figure out how to pass
board-specific regulator configuration data down to the
regulator drivers from a pr785.c board driver.
Now, there *can* be a bit of chicken/egg going on in
some of that initialization. But I don't think that
applies to all of the PR785 support.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-01-13 21:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 7:41 [PATCH 2/2] Changes for adding and building TPS6235x based PR785 board support Manikandan Pillai
2009-01-13 14:59 ` Tony Lindgren
2009-01-13 21:49 ` David Brownell [this message]
2009-01-13 21:51 ` Mark Brown
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=200901131349.09907.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=broonie@sirena.org.uk \
--cc=linux-omap@vger.kernel.org \
--cc=mani.pillai@ti.com \
--cc=tony@atomide.com \
/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