mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®