From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Sebastian Hesselbarh <sebastian.hesselbarth@googlemail.com>
Cc: linux-kernel@vger.kernel.org, mturquette@ti.com
Subject: Re: [RFC] Common clock framework for external clock generators
Date: Sun, 13 May 2012 13:29:46 +0100 [thread overview]
Message-ID: <20120513122946.GD706@sirena.org.uk> (raw)
In-Reply-To: <4FAB15DB.5050702@googlemail.com>
On Thu, May 10, 2012 at 03:11:55AM +0200, Sebastian Hesselbarh wrote:
Always CC maintainers on mails, things get lost on high volume lists.
> I recently read about the newly introduced common clock framework (ccf)
> and wondered if this could be also used for external, e.g. i2c attached,
> clock generators.
Yes, it should be able to be used for this. I've been posting a driver
for the wm831x PMICs for quite some considerable time.
> static inline u8 si5351_reg_read(struct si5351_driver_data *data, u8 addr)
> {
> return (u8)i2c_smbus_read_byte_data(data->client, addr);
> }
I'd suggest using regmap for the cache support (which helps with
read/modify/write cycles) and because...
> static int si5351_xtal_enable(struct clk_hw *hw)
> {
> struct si5351_driver_data *sidata =
> container_of(hw, struct si5351_driver_data, hw_xtal);
> u8 reg;
>
> reg = si5351_reg_read(sidata, SI5351_FANOUT_ENABLE);
> reg |= SI5351_XTAL_ENABLE;
> si5351_reg_write(sidata, SI5351_FANOUT_ENABLE, reg);
> return 0;
> }
...we should be able to factor things like this out of the drivers using
regmap (we've been getting some great results doing that for regulator
over this release).
> static const struct clk_ops si5351_xtal_ops = {
> .enable = si5351_xtal_enable,
> .disable = si5351_xtal_disable,
These should be prepare() and unprepare() - enable() and disable() are
called from atomic context so you can't do I2C I/O.
> static u8 si5351_clkout_get_parent(struct clk_hw *hw)
> {
> struct si5351_driver_data *sidata = si5351_clkout_get_data(hw);
> return 0;
> }
If we need empty functions like this we should fix the framework.
> sidata = kzalloc(sizeof(struct si5351_driver_data), GFP_KERNEL);
> if (sidata == NULL) {
> dev_err(&client->dev, "unable to allocate driver data\n");
> return -ENOMEM;
> }
devm_kzalloc().
next prev parent reply other threads:[~2012-05-13 12:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-10 1:11 Sebastian Hesselbarh
2012-05-13 12:29 ` Mark Brown [this message]
2012-05-13 16:30 ` Sebastian Hesselbarh
2012-05-13 16:43 ` Mark Brown
2012-05-13 17:11 ` Sebastian Hesselbarh
2012-05-13 17:16 ` Mark Brown
2012-05-14 18:08 ` Turquette, Mike
2012-05-14 18:12 ` Mark Brown
2012-10-11 8:34 ` Daniel Mack
2012-10-11 16:00 ` Sebastian Hesselbarth
2012-10-12 18:17 ` Daniel Mack
2012-10-14 10:59 ` Sebastian Hesselbarth
2012-10-14 11:13 ` Daniel Mack
2012-10-14 16:16 ` Sebastian Hesselbarth
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=20120513122946.GD706@sirena.org.uk \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@ti.com \
--cc=sebastian.hesselbarth@googlemail.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
Powered by JetHome