All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hiremath, Vaibhav" <hvaibhav@ti.com>
To: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Mohammed, Afzal" <afzal@ti.com>,
	"Bedia, Vaibhav" <vaibhav.bedia@ti.com>,
	"Cousson, Benoit" <b-cousson@ti.com>,
	"Hilman, Kevin" <khilman@ti.com>,
	"Nayak, Rajendra" <rnayak@ti.com>
Subject: RE: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
Date: Wed, 15 Aug 2012 09:10:57 +0000	[thread overview]
Message-ID: <79CD15C6BA57404B839C016229A409A83EA8F4CD@DBDE01.ent.ti.com> (raw)
In-Reply-To: <20120814082911.GG11011@atomide.com>

On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote:
> Hi,
> 
> * Paul Walmsley <paul@pwsan.com> [120726 13:07]:
> > On Wed, 25 Jul 2012, Paul Walmsley wrote:
> > 
> > > These IP blocks and the ECAP IP blocks have periods in their names.
> > > The rest of the IP block named in the file don't use periods -- which
> > > is also the style used by the rest of the OMAP SoCs.  Is there
> > > some reason that these have periods in their names?
> > 
> > I've changed those to match the rest of the names, and queued the 
> > following for 3.7.
> > 
> > Thanks again for all the hard work you all put into this.  I realize that 
> > with all the upstream changes, this was probably a little painful for you. 
> > But from my perspective you've been a pleasure to work with through the 
> > process.
> 
> As am33xx and omap5 are DT only, we should start moving towards getting
> rid of grep -E "irq|pa_start|pa_end|dma" in this patch and get the standard
> data from .dtsi files instead.
> 

It may not be so straight, given the fact that hwmod layer 
requires these resources, as hwmod is responsible to configure SYSCONF 
register of the device (happens very early at core_init level).

Somehow we have to have some mechanism to initialize " _mpu_rt_va" before 
core_init call, which will take DT resources and initialize accordingly.

Another dependency we will have is on system timers, Jon has already done 
some initial work on this, but I believe we did not concluded on the it.
I will re-start the thread again, since in any case DT support in timer is 
required.


> Alternatively we could get rid of the names and match the module based on
> pa_start and pa_end.
> 

Just FYI, from resource perspective, I have changed omap_device layer for DT 
resources only (still need hwmod resources as explained above) and patch 
looks something like (and it works) -


diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..cb481fe 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -528,10 +528,15 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
         * HACK: Ideally the resources from DT should match, and hwmod
         * should just add the missing ones. Since the name is not
         * properly populated by DT, stick to hwmod resources only.
+        *
+        * But in case of all new devices, like AM33XX and OMAP5, where
+        * only DT boot is supported,  stick to DT resources only.
         */
-       if (pdev->num_resources && pdev->resource)
+       if (pdev->num_resources && pdev->resource) {
                dev_warn(&pdev->dev, "%s(): resources already allocated %d\n",
                        __func__, pdev->num_resources);
+               goto skip_res_override;
+       }

        res_count = omap_device_count_resources(od);
        if (res_count > 0) {
@@ -550,6 +555,7 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
                        goto oda_exit3;
        }

+skip_res_override:
        if (!pm_lats) {
                pm_lats = omap_default_latency;
                pm_lats_cnt = ARRAY_SIZE(omap_default_latency);


Thanks,
Vaibhav

WARNING: multiple messages have this Message-ID (diff)
From: hvaibhav@ti.com (Hiremath, Vaibhav)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
Date: Wed, 15 Aug 2012 09:10:57 +0000	[thread overview]
Message-ID: <79CD15C6BA57404B839C016229A409A83EA8F4CD@DBDE01.ent.ti.com> (raw)
In-Reply-To: <20120814082911.GG11011@atomide.com>

On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote:
> Hi,
> 
> * Paul Walmsley <paul@pwsan.com> [120726 13:07]:
> > On Wed, 25 Jul 2012, Paul Walmsley wrote:
> > 
> > > These IP blocks and the ECAP IP blocks have periods in their names.
> > > The rest of the IP block named in the file don't use periods -- which
> > > is also the style used by the rest of the OMAP SoCs.  Is there
> > > some reason that these have periods in their names?
> > 
> > I've changed those to match the rest of the names, and queued the 
> > following for 3.7.
> > 
> > Thanks again for all the hard work you all put into this.  I realize that 
> > with all the upstream changes, this was probably a little painful for you. 
> > But from my perspective you've been a pleasure to work with through the 
> > process.
> 
> As am33xx and omap5 are DT only, we should start moving towards getting
> rid of grep -E "irq|pa_start|pa_end|dma" in this patch and get the standard
> data from .dtsi files instead.
> 

It may not be so straight, given the fact that hwmod layer 
requires these resources, as hwmod is responsible to configure SYSCONF 
register of the device (happens very early at core_init level).

Somehow we have to have some mechanism to initialize " _mpu_rt_va" before 
core_init call, which will take DT resources and initialize accordingly.

Another dependency we will have is on system timers, Jon has already done 
some initial work on this, but I believe we did not concluded on the it.
I will re-start the thread again, since in any case DT support in timer is 
required.


> Alternatively we could get rid of the names and match the module based on
> pa_start and pa_end.
> 

Just FYI, from resource perspective, I have changed omap_device layer for DT 
resources only (still need hwmod resources as explained above) and patch 
looks something like (and it works) -


diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..cb481fe 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -528,10 +528,15 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
         * HACK: Ideally the resources from DT should match, and hwmod
         * should just add the missing ones. Since the name is not
         * properly populated by DT, stick to hwmod resources only.
+        *
+        * But in case of all new devices, like AM33XX and OMAP5, where
+        * only DT boot is supported,  stick to DT resources only.
         */
-       if (pdev->num_resources && pdev->resource)
+       if (pdev->num_resources && pdev->resource) {
                dev_warn(&pdev->dev, "%s(): resources already allocated %d\n",
                        __func__, pdev->num_resources);
+               goto skip_res_override;
+       }

        res_count = omap_device_count_resources(od);
        if (res_count > 0) {
@@ -550,6 +555,7 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
                        goto oda_exit3;
        }

+skip_res_override:
        if (!pm_lats) {
                pm_lats = omap_default_latency;
                pm_lats_cnt = ARRAY_SIZE(omap_default_latency);


Thanks,
Vaibhav

  reply	other threads:[~2012-08-15  9:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-25 11:07 [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data Vaibhav Hiremath
2012-07-25 11:07 ` Vaibhav Hiremath
2012-07-25 20:41 ` Paul Walmsley
2012-07-25 20:41   ` Paul Walmsley
2012-07-26 20:02   ` Paul Walmsley
2012-07-26 20:02     ` Paul Walmsley
2012-07-27  8:36     ` Hiremath, Vaibhav
2012-07-27  8:36       ` Hiremath, Vaibhav
2012-08-14  8:29     ` Tony Lindgren
2012-08-14  8:29       ` Tony Lindgren
2012-08-15  9:10       ` Hiremath, Vaibhav [this message]
2012-08-15  9:10         ` Hiremath, Vaibhav
2012-08-17  7:49         ` Tony Lindgren
2012-08-17  7:49           ` Tony Lindgren
2012-08-17  8:22           ` Hiremath, Vaibhav
2012-08-17  8:22             ` Hiremath, Vaibhav
2012-08-17  8:40             ` Tony Lindgren
2012-08-17  8:40               ` Tony Lindgren
2012-08-17  9:51               ` Hiremath, Vaibhav
2012-08-17  9:51                 ` Hiremath, Vaibhav
2012-08-17  9:58                 ` Tony Lindgren
2012-08-17  9:58                   ` Tony Lindgren
2012-08-17 10:09                   ` Hiremath, Vaibhav
2012-08-17 10:09                     ` Hiremath, Vaibhav
2012-08-17 11:33                   ` Benoit Cousson
2012-08-17 11:33                     ` Benoit Cousson
2012-08-17 11:43                 ` Benoit Cousson
2012-08-17 11:43                   ` Benoit Cousson

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=79CD15C6BA57404B839C016229A409A83EA8F4CD@DBDE01.ent.ti.com \
    --to=hvaibhav@ti.com \
    --cc=afzal@ti.com \
    --cc=b-cousson@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=rnayak@ti.com \
    --cc=tony@atomide.com \
    --cc=vaibhav.bedia@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.