From: "Munegowda, Keshava" <keshava_mgowda@ti.com>
To: balbi@ti.com, Paul Walmsley <paul@pwsan.com>
Cc: linux-usb@vger.kernel.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org, khilman@ti.com, b-cousson@ti.com,
gadiyar@ti.com, sameo@linux.intel.com, parthab@india.ti.com,
tony@atomide.com, johnstul@us.ibm.com, vishwanath.bs@ti.com,
Greg KH <greg@kroah.com>
Subject: Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
Date: Mon, 10 Oct 2011 16:45:11 +0530 [thread overview]
Message-ID: <CAP05o4JPrG1kH+x8F25OOteug+x++uTY8fEdaAsg+=6TaYB7Aw@mail.gmail.com> (raw)
In-Reply-To: <20111010100507.GG6685@legolas.emea.dhcp.ti.com>
On Mon, Oct 10, 2011 at 3:35 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Mon, Oct 10, 2011 at 12:26:15PM +0300, Felipe Balbi wrote:
>> On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
>> > On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi <balbi@ti.com> wrote:
>> > > Hi,
>> > >
>> > > On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
>> > >> Hi paul and Felipe
>> > >>
>> > >> Here is the highlights of the change in the design of USB Host which
>> > >> we can do after kernel 3.2 release;
>> > >>
>> > >> 1. separate the TLL changes from UHH
>> > >> 2. The TLL is be a new platform driver in ./drivers/mfd
>> > >> 3. the TLL platform driver will export apis for enable/disable clocks
>> > >> and settings.
>> > >
>> > > TLL should control its clocks through pm_runtime APIs like anything
>> > > else. If you really must export APIs to be used by UHH, you need to have
>> > > an API so that you can claim/release a TLL channel and get/put for
>> > > increasing/decreasing PM counters.
>> > >
>> > > I still think though, you should try to avoid exporting OMAP-specific
>> > > APIs all over the place. Ideally, we would be able to have some way of
>> > > saying that UHH and TLL are closely related... something like having the
>> > > ability to say e.g. two devices are sibblings of each other, so that we
>> > > could ask for a sibbling to wakeup/sleep depending if we need it or not.
>> >
>> > do we have sibling structures today? I dont think so.
>>
>> no we don't.
>
> Ok, here's a first shot at it:
>
> From 600ae62f4b4a832d90a83d43227deb6f84b9def1 Mon Sep 17 00:00:00 2001
> From: Felipe Balbi <balbi@ti.com>
> Date: Mon, 10 Oct 2011 12:56:34 +0300
> Subject: [RFC/NOT-FOR-MERGING/PATCH] base: add the idea of sibling devices
> Organization: Texas Instruments\n
>
> It's possible that some devices, which share a
> common parent, need to talk to each due to a
> very close relationship between them.
>
> Generally, one device will provide some sort of
> resources to the other (e.g. clocks) while still
> both sharing another common parent.
>
> In such cases, it seems necessary to define those
> two devices as siblings, rather than a virtual
> parent relationship, and have means for one device
> to ask the sibling device to e.g. turn on its clocks.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/base/core.c | 41 +++++++++++++++++++++++++++++++++++++++++
> include/linux/device.h | 7 +++++++
> 2 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index bc8729d..3b7f2e5 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -589,6 +589,7 @@ void device_initialize(struct device *dev)
> dev->kobj.kset = devices_kset;
> kobject_init(&dev->kobj, &device_ktype);
> INIT_LIST_HEAD(&dev->dma_pools);
> + INIT_LIST_HEAD(&dev->siblings);
> mutex_init(&dev->mutex);
> lockdep_set_novalidate_class(&dev->mutex);
> spin_lock_init(&dev->devres_lock);
> @@ -889,6 +890,7 @@ int device_private_init(struct device *dev)
> */
> int device_add(struct device *dev)
> {
> + struct device *sibling, *n;
> struct device *parent = NULL;
> struct class_interface *class_intf;
> int error = -EINVAL;
> @@ -923,6 +925,10 @@ int device_add(struct device *dev)
> parent = get_device(dev->parent);
> setup_parent(dev, parent);
>
> + /* setup siblings */
> + list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node)
> + get_device(sibling);
> +
> /* use parent numa_node */
> if (parent)
> set_dev_node(dev, dev_to_node(parent));
> @@ -1071,6 +1077,31 @@ void put_device(struct device *dev)
> }
>
> /**
> + * get_sibling_device_byname - finds a sibling device by its name
> + * @dev: device.
> + * @name: name for the sibling to find.
> + *
> + * This is here to help drivers which need to ask their siblings
> + * for something in particular (like ask sibling to turn clocks on)
> + * achieve that by first finding the correct device pointer for
> + * that sibling.
> + */
> +struct device *get_sibling_device_byname(struct device *dev, const char *name)
> +{
> + struct device *sibling, *n;
> + struct device *found = NULL;
> +
> + list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node) {
> + if (!strcmp(dev_name(sibling), name))
> + found = sibling;
> + goto found;
> + }
> +
> +found:
> + return found;
> +}
> +
> +/**
> * device_del - delete device from system.
> * @dev: device.
> *
> @@ -1085,6 +1116,7 @@ void put_device(struct device *dev)
> */
> void device_del(struct device *dev)
> {
> + struct device *sibling, *n;
> struct device *parent = dev->parent;
> struct class_interface *class_intf;
>
> @@ -1120,6 +1152,15 @@ void device_del(struct device *dev)
> device_remove_attrs(dev);
> bus_remove_device(dev);
>
> + /* teardown siblings */
> + list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node) {
> + /* siblings must have the same parent */
> + WARN(sibling->parent != parent,
> + "siblings must have a common parent\n");
> +
> + get_device(sibling);
> + }
> +
> /*
> * Some platform devices are driven without driver attached
> * and managed resources may have been acquired. Make sure
> diff --git a/include/linux/device.h b/include/linux/device.h
> index c20dfbf..ae9cec9 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -551,6 +551,9 @@ struct device_dma_parameters {
> struct device {
> struct device *parent;
>
> + struct list_head sibling_node;
> + struct list_head siblings;
> +
> struct device_private *p;
>
> struct kobject kobj;
> @@ -764,6 +767,10 @@ extern int (*platform_notify_remove)(struct device *dev);
> extern struct device *get_device(struct device *dev);
> extern void put_device(struct device *dev);
>
> +/* finds a sibling struct device pointer */
> +extern struct device *get_sibling_device_byname(struct device *dev,
> + const char *name);
> +
> extern void wait_for_device_probe(void);
>
> #ifdef CONFIG_DEVTMPFS
> --
> 1.7.6.396.ge0613
>
> one way to use this would be to mark both hwmods has having the same
> parent and pointing to each other as siblings. Then, from UHH you could:
>
> if (port->mode == TLL) {
> tll = get_sibling_device_by_name(dev, "usbtll");
> if (!tll)
> error();
>
> pm_runtime_get_sync(tll);
> }
>
> or something similar. As of now, I'm not so sure this is a very good
> idea, but decided to gather some comments anyway.
>
> Does anybody see any change of this getting used in more cases ? Greg,
> I'm adding you to this thread, if you have any comments to this, I'd
> like to hear them.
This design looks good and perfectly suits our requirements.
Paul/Others
please provide your thoughts..
regards
keshava
next prev parent reply other threads:[~2011-10-10 11:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-06 11:38 Keshava Munegowda
2011-10-07 9:06 ` Paul Walmsley
2011-10-07 9:21 ` Munegowda, Keshava
2011-10-07 9:35 ` Paul Walmsley
2011-10-07 10:33 ` Munegowda, Keshava
2011-10-10 8:52 ` Munegowda, Keshava
2011-10-10 9:03 ` Felipe Balbi
2011-10-10 9:17 ` Munegowda, Keshava
2011-10-10 9:26 ` Felipe Balbi
2011-10-10 10:05 ` Felipe Balbi
2011-10-10 11:15 ` Munegowda, Keshava [this message]
2011-10-10 15:19 ` Alan Stern
2011-10-10 16:03 ` Felipe Balbi
2011-10-10 19:55 ` Alan Stern
2011-10-10 20:10 ` Felipe Balbi
2011-10-11 0:15 ` Alan Stern
2011-10-11 8:13 ` Felipe Balbi
2011-10-11 14:04 ` Alan Stern
2011-10-11 14:08 ` Felipe Balbi
2011-10-11 18:52 ` Paul Walmsley
2011-10-11 19:12 ` Felipe Balbi
2011-10-11 19:17 ` Paul Walmsley
2011-10-11 19:19 ` Felipe Balbi
2011-10-10 21:49 ` Paul Walmsley
2011-10-10 22:13 ` Paul Walmsley
2011-10-10 20:59 ` Paul Walmsley
2011-10-11 1:18 ` Paul Walmsley
2011-10-07 10:43 ` Munegowda, Keshava
2011-10-07 14:27 ` Munegowda, Keshava
2011-10-11 0:40 ` Paul Walmsley
2011-10-11 8:01 ` Cousson, Benoit
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='CAP05o4JPrG1kH+x8F25OOteug+x++uTY8fEdaAsg+=6TaYB7Aw@mail.gmail.com' \
--to=keshava_mgowda@ti.com \
--cc=b-cousson@ti.com \
--cc=balbi@ti.com \
--cc=gadiyar@ti.com \
--cc=greg@kroah.com \
--cc=johnstul@us.ibm.com \
--cc=khilman@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=parthab@india.ti.com \
--cc=paul@pwsan.com \
--cc=sameo@linux.intel.com \
--cc=tony@atomide.com \
--cc=vishwanath.bs@ti.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
all inboxes | Powered by JetHome®