From: tony@atomide•com (Tony Lindgren)
To: linux-arm-kernel@lists•infradead.org
Subject: [linux-pm] [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Date: Fri, 1 Jun 2012 07:15:41 -0700 [thread overview]
Message-ID: <20120601141541.GT12766@atomide.com> (raw)
In-Reply-To: <87txyvt9bn.fsf@ti.com>
* Kevin Hilman <khilman@ti•com> [120601 07:11]:
> Tony Lindgren <tony@atomide•com> writes:
>
> > * Tony Lindgren <tony@atomide•com> [120601 04:43]:
> >> * Eduardo Valentin <eduardo.valentin@ti•com> [120525 01:31]:
> >> > +int omap4_usb_phy_power(struct device *dev, int on)
> >> > +{
> >> > + u32 val;
> >> > + int ret;
> >> > +
> >> > + if (on) {
> >> > + ret = omap_control_readl(dev, CONTROL_DEV_CONF, &val);
> >> > + if (!ret && (val & PHY_PD)) {
> >> > + ret = omap_control_writel(dev, ~PHY_PD,
> >> > + CONTROL_DEV_CONF);
> >> > + /* XXX: add proper documentation for this delay */
> >> > + mdelay(200);
> >> > + }
> >> > + } else {
> >> > + ret = omap_control_writel(dev, PHY_PD, CONTROL_DEV_CONF);
> >> > + }
> >> > +
> >> > + return ret;
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(omap4_usb_phy_power);
> >>
> >> I'm not quite convinced that we should export omap_control_read/write
> >> to drivers. If there's a clear register area this USB phy driver can
> >> manage, then ioremaping it separately makes sense. If it's just one
> >> register, then exporting something like omap_control_usb_phy_set()
> >> might be better for ensuring that drivers don't mess up things for
> >> other drivers.
> >
> > After chatting with Benoit a bit we came to the conclusion that the
> > clock and powerdomain state needs to be managed for the children by
> > the SCM core driver so the children can't be completely independent.
> >
> > But rather than exporting omap_control_read/write, maybe you can
> > register the usb/bandgap whatever children with SCM core driver,
> > then have the runtime PM calls from children be passthrough calls
> > to the parent?
> >
> > Maybe Kevin has some better ideas here?
>
> Handling this with parent/child relationships is the way to go for
> runtime PM.
>
> In MFD, are all sub-devices always children of the core device in the
> LDM? If so, it seems relatively easy to handle. If the parent/child
> relationships are modeled correctly in the LDM, then the children do not
> have to know anything about their parent, the runtime PM core will handle
> this (parent will not be runtime suspended until all the children are.)
OK, so the parent-child relationship is there for DT case, but how do
we set it for non-DT case? Call something like this from children:
omap_scm_register(dev, OMAP_SCM_USB_PHY) that then does device_move?
Tony
next prev parent reply other threads:[~2012-06-01 14:15 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 8:25 [RFC PATCH 00/11] OMAP System Control Module Eduardo Valentin
2012-05-25 8:25 ` [RFC PATCH 01/11] ARM: OMAP4: Remove un-used control module headers and defines Eduardo Valentin
2012-05-28 9:12 ` Shilimkar, Santosh
2012-05-25 8:25 ` [RFC PATCH 02/11] ARM: OMAP: expose control.h to mach area Eduardo Valentin
2012-05-28 9:25 ` Shilimkar, Santosh
2012-05-28 10:30 ` Valentin, Eduardo
2012-06-01 11:19 ` Tony Lindgren
2012-05-25 8:25 ` [RFC PATCH 03/11] arm: omap: device: create a device for system control module Eduardo Valentin
2012-05-25 12:30 ` Cousson, Benoit
2012-05-29 9:44 ` Eduardo Valentin
2012-06-14 13:50 ` Konstantin Baydarov
2012-06-15 9:22 ` Valentin, Eduardo
2012-05-29 13:39 ` Konstantin Baydarov
2012-05-25 8:25 ` [RFC PATCH 04/11] OMAP: Add early " Eduardo Valentin
2012-05-25 11:32 ` Konstantin Baydarov
2012-05-25 11:44 ` Valentin, Eduardo
2012-05-25 11:54 ` Konstantin Baydarov
2012-05-25 12:32 ` Cousson, Benoit
2012-05-28 9:58 ` Shilimkar, Santosh
2012-05-25 8:25 ` [RFC PATCH 05/11] mfd: omap: control: core system control driver Eduardo Valentin
2012-05-25 12:52 ` Cousson, Benoit
2012-05-28 11:35 ` Eduardo Valentin
2012-05-29 13:25 ` Cousson, Benoit
2012-06-01 11:29 ` Tony Lindgren
2012-06-01 12:30 ` Shilimkar, Santosh
2012-06-01 12:43 ` Cousson, Benoit
2012-06-01 17:19 ` Eduardo Valentin
2012-06-01 13:40 ` Konstantin Baydarov
2012-06-01 14:13 ` Tony Lindgren
2012-06-01 14:26 ` Konstantin Baydarov
2012-05-28 9:54 ` Shilimkar, Santosh
2012-05-28 11:42 ` Eduardo Valentin
2012-05-28 13:15 ` Shilimkar, Santosh
2012-05-29 13:31 ` Cousson, Benoit
2012-05-25 8:25 ` [RFC PATCH 06/11] OMAP2+: use control module mfd driver in omap_type Eduardo Valentin
2012-05-25 12:53 ` Cousson, Benoit
2012-05-28 10:02 ` Shilimkar, Santosh
2012-05-28 11:24 ` Eduardo Valentin
2012-06-01 11:35 ` Tony Lindgren
2012-05-25 8:25 ` [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver Eduardo Valentin
2012-05-25 13:35 ` Shubhrajyoti Datta
2012-05-25 15:06 ` Cousson, Benoit
2012-06-01 11:38 ` Tony Lindgren
2012-06-01 13:20 ` [linux-pm] " Tony Lindgren
2012-06-01 14:07 ` Kevin Hilman
2012-06-01 14:15 ` Tony Lindgren [this message]
2012-05-25 8:25 ` [RFC PATCH 08/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields Eduardo Valentin
2012-05-25 15:13 ` Cousson, Benoit
2012-05-28 11:17 ` Eduardo Valentin
2012-05-28 10:04 ` Shilimkar, Santosh
2012-05-28 11:18 ` Eduardo Valentin
2012-05-25 8:25 ` [RFC PATCH 09/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor Eduardo Valentin
2012-05-25 15:49 ` Cousson, Benoit
2012-05-28 11:06 ` Eduardo Valentin
2012-05-28 11:16 ` Eduardo Valentin
2012-05-29 13:14 ` Cousson, Benoit
2012-05-29 17:51 ` Mike Turquette
2012-05-25 16:39 ` Konstantin Baydarov
2012-05-28 10:55 ` Eduardo Valentin
2012-06-01 11:42 ` Tony Lindgren
2012-05-25 8:26 ` [RFC PATCH 10/11] omap4: thermal: add basic CPU thermal zone Eduardo Valentin
2012-05-28 9:33 ` Shilimkar, Santosh
2012-05-28 9:48 ` Felipe Balbi
2012-05-28 10:26 ` Valentin, Eduardo
2012-05-29 12:54 ` Cousson, Benoit
2012-05-25 8:26 ` [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4 Eduardo Valentin
2012-05-29 9:49 ` Konstantin Baydarov
2012-05-30 8:38 ` Cousson, Benoit
2012-05-30 9:05 ` Konstantin Baydarov
2012-05-30 9:26 ` Cousson, Benoit
2012-05-30 10:17 ` Konstantin Baydarov
2012-05-30 10:22 ` Cousson, Benoit
2012-05-30 10:42 ` Eduardo Valentin
2012-05-30 12:16 ` Cousson, Benoit
2012-05-31 12:06 ` Konstantin Baydarov
2012-05-31 12:49 ` Eduardo Valentin
2012-05-31 12:52 ` Cousson, Benoit
2012-05-31 14:51 ` Konstantin Baydarov
2012-05-25 8:35 ` [RFC PATCH 00/11] OMAP System Control Module Eduardo Valentin
2012-05-25 10:50 ` Konstantin Baydarov
2012-05-25 11:11 ` Valentin, Eduardo
2012-05-25 12:21 ` Konstantin Baydarov
2012-06-01 0:12 ` [linux-pm] " Kevin Hilman
2012-06-18 11:32 ` [RFC PATCH v2 01/11] ARM: OMAP4: Remove un-used control module headers and defines Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 02/11] ARM: OMAP: expose control.h to mach area Konstantin Baydarov
2012-06-20 10:17 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 03/11] mfd: omap: control: core system control driver Konstantin Baydarov
2012-06-20 10:22 ` Tony Lindgren
2012-06-20 14:13 ` Konstantin Baydarov
2012-06-26 11:17 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 04/11] OMAP2+: use control module mfd driver in omap_type Konstantin Baydarov
2012-06-20 10:24 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 05/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 06/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields Konstantin Baydarov
2012-06-20 10:25 ` Tony Lindgren
2012-06-18 11:32 ` [RFC PATCH v2 07/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 08/11] omap4: thermal: add basic CPU thermal zone Konstantin Baydarov
2012-06-18 11:32 ` [RFC PATCH v2 09/11] ARM: DT: Add support to system control module for OMAP4 Konstantin Baydarov
2012-06-18 12:13 ` Sergei Shtylyov
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=20120601141541.GT12766@atomide.com \
--to=tony@atomide$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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