[PATCH v2 0/3] ocp2scp: add non-dt support

[PATCH v2 0/3] ocp2scp: add non-dt support

[Kishon Vijay Abraham I]

This patch series allows ocp2scp driver to create its child devices
from the platform data.

In omap platforms, usb phy is connected to ocp2scp and usb phy is needed
for MUSB to be functional. When ocp2scp driver was added, it had only dt
support which means it wont create usb phy devices for non-dt boot.

This patch series adds non-dt support to ocp2scp and this series is needed
for getting MUSB functional in non-dt boot.

Changes from v1:
* Fixed Sergei's comments on memory leaks

This patch series is rebased on linux-next. 
commit: 080aa9c61ad0a6ed17de5643b32bb4660a0eb29d
Let me know if it had to be based on some other tree/commit.

Did a quick testing for g_zero enumeration in panda board.

Kishon Vijay Abraham I (3):
  drivers: bus: ocp2scp: add pdata support
  ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
  ARM: OMAP: ocp2scp: create omap device for ocp2scp

 arch/arm/mach-omap2/devices.c              |   76 ++++++++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   28 ++++++++++
 drivers/bus/omap-ocp2scp.c                 |   67 ++++++++++++++++++++++--
 include/linux/platform_data/omap_ocp2scp.h |   31 ++++++++++++
 4 files changed, 199 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/platform_data/omap_ocp2scp.h

-- 
1.7.9.5

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Kishon Vijay Abraham I]

ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have information about the devices
that is connected to ocp2scp. ocp2scp driver will now make use of this
information to create the devices that is attached to ocp2scp.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 drivers/bus/omap-ocp2scp.c                 |   67 ++++++++++++++++++++++++++--
 include/linux/platform_data/omap_ocp2scp.h |   31 +++++++++++++
 2 files changed, 95 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/platform_data/omap_ocp2scp.h

diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index ff63560..5db8297 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -22,6 +22,26 @@
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
+#include <linux/platform_data/omap_ocp2scp.h>
+
+/**
+ * _count_resources - count for the number of resources
+ * @res: struct resource *
+ *
+ * Count and return the number of resources populated for the device that is
+ * connected to ocp2scp.
+ */
+static unsigned _count_resources(struct resource *res)
+{
+	int cnt	= 0;
+
+	while (res->start != res->end) {
+		cnt++;
+		res++;
+	}
+
+	return cnt;
+}
 
 static int ocp2scp_remove_devices(struct device *dev, void *c)
 {
@@ -34,20 +54,61 @@ static int ocp2scp_remove_devices(struct device *dev, void *c)
 
 static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
 {
-	int			ret;
-	struct device_node	*np = pdev->dev.of_node;
+	int ret;
+	unsigned res_cnt, i;
+	struct device_node *np = pdev->dev.of_node;
+	struct platform_device *pdev_child;
+	struct omap_ocp2scp_platform_data *pdata = pdev->dev.platform_data;
+	struct omap_ocp2scp_dev *dev;
 
 	if (np) {
 		ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
 		if (ret) {
-			dev_err(&pdev->dev, "failed to add resources for ocp2scp child\n");
+			dev_err(&pdev->dev,
+			    "failed to add resources for ocp2scp child\n");
 			goto err0;
 		}
+	} else if (pdata) {
+		for (i = 0, dev = *pdata->devices; i < pdata->dev_cnt; i++,
+		    dev++) {
+			res_cnt = _count_resources(dev->res);
+
+			pdev_child = platform_device_alloc(dev->drv_name, -1);
+			if (!pdev_child) {
+				dev_err(&pdev->dev,
+				  "failed to allocate mem for ocp2scp child\n");
+				goto err0;
+			}
+
+			ret = platform_device_add_resources(pdev_child,
+			    dev->res, res_cnt);
+			if (ret) {
+				dev_err(&pdev->dev,
+				 "failed to add resources for ocp2scp child\n");
+				goto err1;
+			}
+
+			pdev_child->dev.parent	= &pdev->dev;
+
+			ret = platform_device_add(pdev_child);
+			if (ret) {
+				dev_err(&pdev->dev,
+				   "failed to register ocp2scp child device\n");
+				goto err1;
+			}
+		}
+	} else {
+		dev_err(&pdev->dev, "OCP2SCP initialized without plat data\n");
+		return -EINVAL;
 	}
+
 	pm_runtime_enable(&pdev->dev);
 
 	return 0;
 
+err1:
+	platform_device_put(pdev_child);
+
 err0:
 	device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices);
 
diff --git a/include/linux/platform_data/omap_ocp2scp.h b/include/linux/platform_data/omap_ocp2scp.h
new file mode 100644
index 0000000..5c6c393
--- /dev/null
+++ b/include/linux/platform_data/omap_ocp2scp.h
@@ -0,0 +1,31 @@
+/*
+ * omap_ocp2scp.h -- ocp2scp header file
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon@ti.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_OMAP_OCP2SCP_H
+#define __DRIVERS_OMAP_OCP2SCP_H
+
+struct omap_ocp2scp_dev {
+	const char			*drv_name;
+	struct resource			*res;
+};
+
+struct omap_ocp2scp_platform_data {
+	int				dev_cnt;
+	struct omap_ocp2scp_dev		**devices;
+};
+#endif /* __DRIVERS_OMAP_OCP2SCP_H */
-- 
1.7.9.5

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Tony Lindgren]

* Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> ocp2scp was not having pdata support which makes *musb* fail for non-dt
> boot in OMAP platform. The pdata will have information about the devices
> that is connected to ocp2scp. ocp2scp driver will now make use of this
> information to create the devices that is attached to ocp2scp.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

This fixes the regression on my panda es for musb port:

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [121016 09:53]:
> * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > boot in OMAP platform. The pdata will have information about the devices
> > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > information to create the devices that is attached to ocp2scp.
> > 
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> 
> This fixes the regression on my panda es for musb port:
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Looks like nobody has picked this one up and we need it to
fix the musb regression on omap, so I'll queue these up.

Regards,

Tony

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Felipe Balbi]

Hi,

On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > boot in OMAP platform. The pdata will have information about the devices
> > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > information to create the devices that is attached to ocp2scp.
> > > 
> > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > 
> > This fixes the regression on my panda es for musb port:
> > 
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> Looks like nobody has picked this one up and we need it to
> fix the musb regression on omap, so I'll queue these up.

I don't seem to have the patches around in any mailbox :-(

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/aa8ffc49/attachment.sig>

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [121024 23:24]:
> Hi,
> 
> On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > > boot in OMAP platform. The pdata will have information about the devices
> > > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > > information to create the devices that is attached to ocp2scp.
> > > > 
> > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > 
> > > This fixes the regression on my panda es for musb port:
> > > 
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > 
> > Looks like nobody has picked this one up and we need it to
> > fix the musb regression on omap, so I'll queue these up.
> 
> I don't seem to have the patches around in any mailbox :-(

Bounced them to you. Do you have any better ideas for the
-rc cycle to fix the MUSB regression on omap4?

Regards,

Tony

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Felipe Balbi]

On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121024 23:24]:
> > Hi,
> > 
> > On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> > > * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > > > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > > > boot in OMAP platform. The pdata will have information about the devices
> > > > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > > > information to create the devices that is attached to ocp2scp.
> > > > > 
> > > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > 
> > > > This fixes the regression on my panda es for musb port:
> > > > 
> > > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > 
> > > Looks like nobody has picked this one up and we need it to
> > > fix the musb regression on omap, so I'll queue these up.
> > 
> > I don't seem to have the patches around in any mailbox :-(
> 
> Bounced them to you. Do you have any better ideas for the
> -rc cycle to fix the MUSB regression on omap4?

Well, there are two regressions that I know of. One is caused by the
mode1 DMA changes, which I'll just revert, and the other is the
missing platform_data support on the new PHY driver which these patches
are supposed to solve, right ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/6df2f452/attachment.sig>

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [121025 23:55]:
> On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
> > * Felipe Balbi <balbi@ti.com> [121024 23:24]:
> > > Hi,
> > > 
> > > On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> > > > * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > > > > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > > > > boot in OMAP platform. The pdata will have information about the devices
> > > > > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > > > > information to create the devices that is attached to ocp2scp.
> > > > > > 
> > > > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > > 
> > > > > This fixes the regression on my panda es for musb port:
> > > > > 
> > > > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > > 
> > > > Looks like nobody has picked this one up and we need it to
> > > > fix the musb regression on omap, so I'll queue these up.
> > > 
> > > I don't seem to have the patches around in any mailbox :-(
> > 
> > Bounced them to you. Do you have any better ideas for the
> > -rc cycle to fix the MUSB regression on omap4?
> 
> Well, there are two regressions that I know of. One is caused by the
> mode1 DMA changes, which I'll just revert, and the other is the
> missing platform_data support on the new PHY driver which these patches
> are supposed to solve, right ?

Yes that's it AFAIK.

Regards,

Tony

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Felipe Balbi]

Hi,

On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121025 23:55]:
> > On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi <balbi@ti.com> [121024 23:24]:
> > > > Hi,
> > > > 
> > > > On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> > > > > * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > > > > > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > > > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > > > > > boot in OMAP platform. The pdata will have information about the devices
> > > > > > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > > > > > information to create the devices that is attached to ocp2scp.
> > > > > > > 
> > > > > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > > > 
> > > > > > This fixes the regression on my panda es for musb port:
> > > > > > 
> > > > > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > > > 
> > > > > Looks like nobody has picked this one up and we need it to
> > > > > fix the musb regression on omap, so I'll queue these up.
> > > > 
> > > > I don't seem to have the patches around in any mailbox :-(
> > > 
> > > Bounced them to you. Do you have any better ideas for the
> > > -rc cycle to fix the MUSB regression on omap4?
> > 
> > Well, there are two regressions that I know of. One is caused by the
> > mode1 DMA changes, which I'll just revert, and the other is the
> > missing platform_data support on the new PHY driver which these patches
> > are supposed to solve, right ?
> 
> Yes that's it AFAIK.

Kishon, any other patches I need to take to get MUSB working on v3.7 ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/57bda15d/attachment.sig>

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[kishon]

Hi,

On Saturday 27 October 2012 01:29 AM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti.com> [121025 23:55]:
>>> On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
>>>> * Felipe Balbi <balbi@ti.com> [121024 23:24]:
>>>>> Hi,
>>>>>
>>>>> On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
>>>>>> * Tony Lindgren <tony@atomide.com> [121016 09:53]:
>>>>>>> * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
>>>>>>>> ocp2scp was not having pdata support which makes *musb* fail for non-dt
>>>>>>>> boot in OMAP platform. The pdata will have information about the devices
>>>>>>>> that is connected to ocp2scp. ocp2scp driver will now make use of this
>>>>>>>> information to create the devices that is attached to ocp2scp.
>>>>>>>>
>>>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>>>>>
>>>>>>> This fixes the regression on my panda es for musb port:
>>>>>>>
>>>>>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>>>>>
>>>>>> Looks like nobody has picked this one up and we need it to
>>>>>> fix the musb regression on omap, so I'll queue these up.
>>>>>
>>>>> I don't seem to have the patches around in any mailbox :-(
>>>>
>>>> Bounced them to you. Do you have any better ideas for the
>>>> -rc cycle to fix the MUSB regression on omap4?
>>>
>>> Well, there are two regressions that I know of. One is caused by the
>>> mode1 DMA changes, which I'll just revert, and the other is the
>>> missing platform_data support on the new PHY driver which these patches
>>> are supposed to solve, right ?
>>
>> Yes that's it AFAIK.
>
> Kishon, any other patches I need to take to get MUSB working on v3.7 ?

These should be good enough to get MUSB working..

Thanks
Kishon

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Felipe Balbi]

Hi,

On Sat, Oct 27, 2012 at 05:57:48PM +0530, kishon wrote:
> Hi,
> 
> On Saturday 27 October 2012 01:29 AM, Felipe Balbi wrote:
> >Hi,
> >
> >On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote:
> >>* Felipe Balbi <balbi@ti.com> [121025 23:55]:
> >>>On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
> >>>>* Felipe Balbi <balbi@ti.com> [121024 23:24]:
> >>>>>Hi,
> >>>>>
> >>>>>On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> >>>>>>* Tony Lindgren <tony@atomide.com> [121016 09:53]:
> >>>>>>>* Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> >>>>>>>>ocp2scp was not having pdata support which makes *musb* fail for non-dt
> >>>>>>>>boot in OMAP platform. The pdata will have information about the devices
> >>>>>>>>that is connected to ocp2scp. ocp2scp driver will now make use of this
> >>>>>>>>information to create the devices that is attached to ocp2scp.
> >>>>>>>>
> >>>>>>>>Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >>>>>>>
> >>>>>>>This fixes the regression on my panda es for musb port:
> >>>>>>>
> >>>>>>>Acked-by: Tony Lindgren <tony@atomide.com>
> >>>>>>
> >>>>>>Looks like nobody has picked this one up and we need it to
> >>>>>>fix the musb regression on omap, so I'll queue these up.
> >>>>>
> >>>>>I don't seem to have the patches around in any mailbox :-(
> >>>>
> >>>>Bounced them to you. Do you have any better ideas for the
> >>>>-rc cycle to fix the MUSB regression on omap4?
> >>>
> >>>Well, there are two regressions that I know of. One is caused by the
> >>>mode1 DMA changes, which I'll just revert, and the other is the
> >>>missing platform_data support on the new PHY driver which these patches
> >>>are supposed to solve, right ?
> >>
> >>Yes that's it AFAIK.
> >
> >Kishon, any other patches I need to take to get MUSB working on v3.7 ?
> 
> These should be good enough to get MUSB working..

nothing needed for omap-usb2.c ? That's great, cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121029/ad9b72e6/attachment.sig>

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[kishon]

Hi,

On Monday 29 October 2012 11:40 AM, Felipe Balbi wrote:
> Hi,
>
> On Sat, Oct 27, 2012 at 05:57:48PM +0530, kishon wrote:
>> Hi,
>>
>> On Saturday 27 October 2012 01:29 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote:
>>>> * Felipe Balbi <balbi@ti.com> [121025 23:55]:
>>>>> On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
>>>>>> * Felipe Balbi <balbi@ti.com> [121024 23:24]:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
>>>>>>>> * Tony Lindgren <tony@atomide.com> [121016 09:53]:
>>>>>>>>> * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
>>>>>>>>>> ocp2scp was not having pdata support which makes *musb* fail for non-dt
>>>>>>>>>> boot in OMAP platform. The pdata will have information about the devices
>>>>>>>>>> that is connected to ocp2scp. ocp2scp driver will now make use of this
>>>>>>>>>> information to create the devices that is attached to ocp2scp.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>>>>>>>
>>>>>>>>> This fixes the regression on my panda es for musb port:
>>>>>>>>>
>>>>>>>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>>>>>>>
>>>>>>>> Looks like nobody has picked this one up and we need it to
>>>>>>>> fix the musb regression on omap, so I'll queue these up.
>>>>>>>
>>>>>>> I don't seem to have the patches around in any mailbox :-(
>>>>>>
>>>>>> Bounced them to you. Do you have any better ideas for the
>>>>>> -rc cycle to fix the MUSB regression on omap4?
>>>>>
>>>>> Well, there are two regressions that I know of. One is caused by the
>>>>> mode1 DMA changes, which I'll just revert, and the other is the
>>>>> missing platform_data support on the new PHY driver which these patches
>>>>> are supposed to solve, right ?
>>>>
>>>> Yes that's it AFAIK.
>>>
>>> Kishon, any other patches I need to take to get MUSB working on v3.7 ?
>>
>> These should be good enough to get MUSB working..
>
> nothing needed for omap-usb2.c ? That's great, cheers

No. Nothing of pdata sort is used in omap-usb2.c

Thanks
Kishon

[PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support

[Felipe Balbi]

On Mon, Oct 08, 2012 at 11:29:41AM +0530, Kishon Vijay Abraham I wrote:
> ocp2scp was not having pdata support which makes *musb* fail for non-dt
> boot in OMAP platform. The pdata will have information about the devices
> that is connected to ocp2scp. ocp2scp driver will now make use of this
> information to create the devices that is attached to ocp2scp.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Acked-by: Felipe Balbi <balbi@ti.com>

> ---
>  drivers/bus/omap-ocp2scp.c                 |   67 ++++++++++++++++++++++++++--
>  include/linux/platform_data/omap_ocp2scp.h |   31 +++++++++++++
>  2 files changed, 95 insertions(+), 3 deletions(-)
>  create mode 100644 include/linux/platform_data/omap_ocp2scp.h
> 
> diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
> index ff63560..5db8297 100644
> --- a/drivers/bus/omap-ocp2scp.c
> +++ b/drivers/bus/omap-ocp2scp.c
> @@ -22,6 +22,26 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/of.h>
>  #include <linux/of_platform.h>
> +#include <linux/platform_data/omap_ocp2scp.h>
> +
> +/**
> + * _count_resources - count for the number of resources
> + * @res: struct resource *
> + *
> + * Count and return the number of resources populated for the device that is
> + * connected to ocp2scp.
> + */
> +static unsigned _count_resources(struct resource *res)
> +{
> +	int cnt	= 0;
> +
> +	while (res->start != res->end) {
> +		cnt++;
> +		res++;
> +	}
> +
> +	return cnt;
> +}
>  
>  static int ocp2scp_remove_devices(struct device *dev, void *c)
>  {
> @@ -34,20 +54,61 @@ static int ocp2scp_remove_devices(struct device *dev, void *c)
>  
>  static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
>  {
> -	int			ret;
> -	struct device_node	*np = pdev->dev.of_node;
> +	int ret;
> +	unsigned res_cnt, i;
> +	struct device_node *np = pdev->dev.of_node;
> +	struct platform_device *pdev_child;
> +	struct omap_ocp2scp_platform_data *pdata = pdev->dev.platform_data;
> +	struct omap_ocp2scp_dev *dev;
>  
>  	if (np) {
>  		ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
>  		if (ret) {
> -			dev_err(&pdev->dev, "failed to add resources for ocp2scp child\n");
> +			dev_err(&pdev->dev,
> +			    "failed to add resources for ocp2scp child\n");
>  			goto err0;
>  		}
> +	} else if (pdata) {
> +		for (i = 0, dev = *pdata->devices; i < pdata->dev_cnt; i++,
> +		    dev++) {
> +			res_cnt = _count_resources(dev->res);
> +
> +			pdev_child = platform_device_alloc(dev->drv_name, -1);
> +			if (!pdev_child) {
> +				dev_err(&pdev->dev,
> +				  "failed to allocate mem for ocp2scp child\n");
> +				goto err0;
> +			}
> +
> +			ret = platform_device_add_resources(pdev_child,
> +			    dev->res, res_cnt);
> +			if (ret) {
> +				dev_err(&pdev->dev,
> +				 "failed to add resources for ocp2scp child\n");
> +				goto err1;
> +			}
> +
> +			pdev_child->dev.parent	= &pdev->dev;
> +
> +			ret = platform_device_add(pdev_child);
> +			if (ret) {
> +				dev_err(&pdev->dev,
> +				   "failed to register ocp2scp child device\n");
> +				goto err1;
> +			}
> +		}
> +	} else {
> +		dev_err(&pdev->dev, "OCP2SCP initialized without plat data\n");
> +		return -EINVAL;
>  	}
> +
>  	pm_runtime_enable(&pdev->dev);
>  
>  	return 0;
>  
> +err1:
> +	platform_device_put(pdev_child);
> +
>  err0:
>  	device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices);
>  
> diff --git a/include/linux/platform_data/omap_ocp2scp.h b/include/linux/platform_data/omap_ocp2scp.h
> new file mode 100644
> index 0000000..5c6c393
> --- /dev/null
> +++ b/include/linux/platform_data/omap_ocp2scp.h
> @@ -0,0 +1,31 @@
> +/*
> + * omap_ocp2scp.h -- ocp2scp header file
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef __DRIVERS_OMAP_OCP2SCP_H
> +#define __DRIVERS_OMAP_OCP2SCP_H
> +
> +struct omap_ocp2scp_dev {
> +	const char			*drv_name;
> +	struct resource			*res;
> +};
> +
> +struct omap_ocp2scp_platform_data {
> +	int				dev_cnt;
> +	struct omap_ocp2scp_dev		**devices;
> +};
> +#endif /* __DRIVERS_OMAP_OCP2SCP_H */
> -- 
> 1.7.9.5
> 

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/1419d515/attachment.sig>

[PATCH v2 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy

[Kishon Vijay Abraham I]

In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..cf579b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -21,6 +21,7 @@
 #include <linux/io.h>
 #include <linux/platform_data/gpio-omap.h>
 #include <linux/power/smartreflex.h>
+#include <linux/platform_data/omap_ocp2scp.h>
 
 #include <plat/omap_hwmod.h>
 #include <plat/i2c.h>
@@ -2681,6 +2682,32 @@ static struct omap_hwmod_class omap44xx_ocp2scp_hwmod_class = {
 	.sysc	= &omap44xx_ocp2scp_sysc,
 };
 
+/* ocp2scp dev_attr */
+static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
+	{
+		.name		= "usb_phy",
+		.start		= 0x4a0ad080,
+		.end		= 0x4a0ae000,
+		.flags		= IORESOURCE_MEM,
+	},
+	{
+		/* XXX: Remove this once control module driver is in place */
+		.name		= "ctrl_dev",
+		.start		= 0x4a002300,
+		.end		= 0x4a002303,
+		.flags		= IORESOURCE_MEM,
+	},
+	{ }
+};
+
+static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
+	{
+		.drv_name       = "omap-usb2",
+		.res		= omap44xx_usb_phy_and_pll_addrs,
+	},
+	{ }
+};
+
 /* ocp2scp_usb_phy */
 static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 	.name		= "ocp2scp_usb_phy",
@@ -2694,6 +2721,7 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
+	.dev_attr	= ocp2scp_dev_attr,
 };
 
 /*
-- 
1.7.9.5

[PATCH v2 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy

[Tony Lindgren]

Hi,

* Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
> is assigned a device attribute to represent the attached devices.
...

> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -21,6 +21,7 @@
>  #include <linux/io.h>
>  #include <linux/platform_data/gpio-omap.h>
>  #include <linux/power/smartreflex.h>
> +#include <linux/platform_data/omap_ocp2scp.h>
>  
>  #include <plat/omap_hwmod.h>
>  #include <plat/i2c.h>
> @@ -2681,6 +2682,32 @@ static struct omap_hwmod_class omap44xx_ocp2scp_hwmod_class = {
>  	.sysc	= &omap44xx_ocp2scp_sysc,
>  };
>  
> +/* ocp2scp dev_attr */
> +static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
> +	{
> +		.name		= "usb_phy",
> +		.start		= 0x4a0ad080,
> +		.end		= 0x4a0ae000,
> +		.flags		= IORESOURCE_MEM,
> +	},
> +	{
> +		/* XXX: Remove this once control module driver is in place */
> +		.name		= "ctrl_dev",
> +		.start		= 0x4a002300,
> +		.end		= 0x4a002303,
> +		.flags		= IORESOURCE_MEM,
> +	},
> +	{ }
> +};

Why don't you set the CONTROL_DEV_CONF as a fixed regulator?

That way you can define the fixed regulator in mach-omap2/control.c
and the driver can just pick it up by name.

The 4470 TRM says that this register "power down entire USB
PHY" and "controls USB2PHYCORE.PD pin".

That way you can also get rid of the mysterious mdelay(200)
in omap_usb_phy_power() in omap-usb2.c driver.

However one thing needs to be checked first.

If CONTROL_DEV_CONF is not a regulator but is a signal mux,
then you can map the register with mux framework using the
pinctrl-single. See the pinctrl-single,bits binding that
was recently merged to mainline.

In the mux case you can set up the named states "default" and
"disabled" that the PHY driver can then manipulate with
pinctrl_select_state().

Note that for the mux case we don't have a non-device tree
pinctrl framework solution available, so you're probably
better off setting it up as a fixed regulator with comments
in case it really is a mux.

BTW, the reason I'm thinking CONTROL_DEV_CONF may be a mux
is because omap3 has registers named CONTROL_DEVCONF0 and
CONTROL_DEVCONF1 that mux signals for various devices.
But maybe that naming is just a coincidence.

Regards,

Tony

[PATCH v2 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [121010 17:46]:
> Hi,
> 
> * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
> > is assigned a device attribute to represent the attached devices.
> ...
> 
> > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > @@ -21,6 +21,7 @@
> >  #include <linux/io.h>
> >  #include <linux/platform_data/gpio-omap.h>
> >  #include <linux/power/smartreflex.h>
> > +#include <linux/platform_data/omap_ocp2scp.h>
> >  
> >  #include <plat/omap_hwmod.h>
> >  #include <plat/i2c.h>
> > @@ -2681,6 +2682,32 @@ static struct omap_hwmod_class omap44xx_ocp2scp_hwmod_class = {
> >  	.sysc	= &omap44xx_ocp2scp_sysc,
> >  };
> >  
> > +/* ocp2scp dev_attr */
> > +static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
> > +	{
> > +		.name		= "usb_phy",
> > +		.start		= 0x4a0ad080,
> > +		.end		= 0x4a0ae000,
> > +		.flags		= IORESOURCE_MEM,
> > +	},
> > +	{
> > +		/* XXX: Remove this once control module driver is in place */
> > +		.name		= "ctrl_dev",
> > +		.start		= 0x4a002300,
> > +		.end		= 0x4a002303,
> > +		.flags		= IORESOURCE_MEM,
> > +	},
> > +	{ }
> > +};
> 
> Why don't you set the CONTROL_DEV_CONF as a fixed regulator?

After some more investigating, we may be able to set it up as a
regulator or clock later on. But as a regression fix, this seems
OK for me.

Benoit, is this OK for you?

Regards,

Tony

[PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp

[Kishon Vijay Abraham I]

Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 arch/arm/mach-omap2/devices.c |   76 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..ac2bfce 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,6 +19,7 @@
 #include <linux/of.h>
 #include <linux/pinctrl/machine.h>
 #include <linux/platform_data/omap4-keypad.h>
+#include <linux/platform_data/omap_ocp2scp.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/map.h>
@@ -613,6 +614,80 @@ static void omap_init_vout(void)
 static inline void omap_init_vout(void) {}
 #endif
 
+#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
+static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
+{
+	int cnt	= 0;
+
+	while (ocp2scp_dev->drv_name != NULL) {
+		cnt++;
+		ocp2scp_dev++;
+	}
+
+	return cnt;
+}
+
+static void omap_init_ocp2scp(void)
+{
+	struct omap_hwmod	*oh;
+	struct platform_device	*pdev;
+	int			bus_id = -1, dev_cnt = 0, i;
+	struct omap_ocp2scp_dev	*ocp2scp_dev;
+	const char		*oh_name, *name;
+	struct omap_ocp2scp_platform_data *pdata;
+
+	oh_name = "ocp2scp_usb_phy";
+	name	= "omap-ocp2scp";
+
+	oh = omap_hwmod_lookup(oh_name);
+	if (!oh) {
+		pr_err("%s: could not find omap_hwmod for %s\n", __func__,
+								oh_name);
+		return;
+	}
+
+	pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+	if (!pdata) {
+		pr_err("%s: No memory for ocp2scp pdata\n", __func__);
+		return;
+	}
+
+	ocp2scp_dev = oh->dev_attr;
+	dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
+
+	if (!dev_cnt) {
+		pr_err("%s: No devices connected to ocp2scp\n", __func__);
+		kfree(pdata);
+		return;
+	}
+
+	pdata->devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
+					* dev_cnt, GFP_KERNEL);
+	if (!pdata->devices) {
+		pr_err("%s: No memory for ocp2scp pdata devices\n", __func__);
+		kfree(pdata);
+		return;
+	}
+
+	for (i = 0; i < dev_cnt; i++, ocp2scp_dev++)
+		pdata->devices[i] = ocp2scp_dev;
+
+	pdata->dev_cnt	= dev_cnt;
+
+	pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata), NULL,
+								0, false);
+	if (IS_ERR(pdev)) {
+		pr_err("Could not build omap_device for %s %s\n",
+						name, oh_name);
+		kfree(pdata->devices);
+		kfree(pdata);
+		return;
+	}
+}
+#else
+static inline void omap_init_ocp2scp(void) { }
+#endif
+
 /*-------------------------------------------------------------------------*/
 
 static int __init omap2_init_devices(void)
@@ -640,6 +715,7 @@ static int __init omap2_init_devices(void)
 	omap_init_sham();
 	omap_init_aes();
 	omap_init_vout();
+	omap_init_ocp2scp();
 
 	return 0;
 }
-- 
1.7.9.5

[PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp

[Felipe Balbi]

Hi,

On Mon, Oct 08, 2012 at 11:29:43AM +0530, Kishon Vijay Abraham I wrote:
> Platfrom device for ocp2scp is created using omap_device_build in
> devices file. This is used for both omap4(musb) and omap5(dwc3).
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
>  arch/arm/mach-omap2/devices.c |   76 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index c8c2117..ac2bfce 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -19,6 +19,7 @@
>  #include <linux/of.h>
>  #include <linux/pinctrl/machine.h>
>  #include <linux/platform_data/omap4-keypad.h>
> +#include <linux/platform_data/omap_ocp2scp.h>
>  
>  #include <asm/mach-types.h>
>  #include <asm/mach/map.h>
> @@ -613,6 +614,80 @@ static void omap_init_vout(void)
>  static inline void omap_init_vout(void) {}
>  #endif
>  
> +#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
> +static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
> +{
> +	int cnt	= 0;
> +
> +	while (ocp2scp_dev->drv_name != NULL) {
> +		cnt++;
> +		ocp2scp_dev++;
> +	}
> +
> +	return cnt;
> +}
> +
> +static void omap_init_ocp2scp(void)
> +{
> +	struct omap_hwmod	*oh;
> +	struct platform_device	*pdev;
> +	int			bus_id = -1, dev_cnt = 0, i;
> +	struct omap_ocp2scp_dev	*ocp2scp_dev;
> +	const char		*oh_name, *name;
> +	struct omap_ocp2scp_platform_data *pdata;
> +
> +	oh_name = "ocp2scp_usb_phy";
> +	name	= "omap-ocp2scp";

how about adding checks here to return early case we're not running on
OMAP4 or OMAP5 ??

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/7bf840dc/attachment.sig>

[PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp

[Arnd Bergmann]

On Friday 26 October 2012, Felipe Balbi wrote:
> > +static void omap_init_ocp2scp(void)
> > +{
> > +     struct omap_hwmod       *oh;
> > +     struct platform_device  *pdev;
> > +     int                     bus_id = -1, dev_cnt = 0, i;
> > +     struct omap_ocp2scp_dev *ocp2scp_dev;
> > +     const char              *oh_name, *name;
> > +     struct omap_ocp2scp_platform_data *pdata;
> > +
> > +     oh_name = "ocp2scp_usb_phy";
> > +     name    = "omap-ocp2scp";
> 
> how about adding checks here to return early case we're not running on
> OMAP4 or OMAP5 ??
> 

I suppose even OMAP4-only, since OMAP5 always has DT enabled.

	Arnd

[PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [121026 00:48]:
> On Friday 26 October 2012, Felipe Balbi wrote:
> > > +static void omap_init_ocp2scp(void)
> > > +{
> > > +     struct omap_hwmod       *oh;
> > > +     struct platform_device  *pdev;
> > > +     int                     bus_id = -1, dev_cnt = 0, i;
> > > +     struct omap_ocp2scp_dev *ocp2scp_dev;
> > > +     const char              *oh_name, *name;
> > > +     struct omap_ocp2scp_platform_data *pdata;
> > > +
> > > +     oh_name = "ocp2scp_usb_phy";
> > > +     name    = "omap-ocp2scp";
> > 
> > how about adding checks here to return early case we're not running on
> > OMAP4 or OMAP5 ??
> > 
> 
> I suppose even OMAP4-only, since OMAP5 always has DT enabled.

Hmm yes, currently omap_hwmod_lookup(oh_name) produces
bogus errors for other omaps as the hwmod data is only
there for omap4.

Regards,

Tony

[PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp

[Felipe Balbi]

On Fri, Oct 26, 2012 at 10:21:41AM -0700, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [121026 00:48]:
> > On Friday 26 October 2012, Felipe Balbi wrote:
> > > > +static void omap_init_ocp2scp(void)
> > > > +{
> > > > +     struct omap_hwmod       *oh;
> > > > +     struct platform_device  *pdev;
> > > > +     int                     bus_id = -1, dev_cnt = 0, i;
> > > > +     struct omap_ocp2scp_dev *ocp2scp_dev;
> > > > +     const char              *oh_name, *name;
> > > > +     struct omap_ocp2scp_platform_data *pdata;
> > > > +
> > > > +     oh_name = "ocp2scp_usb_phy";
> > > > +     name    = "omap-ocp2scp";
> > > 
> > > how about adding checks here to return early case we're not running on
> > > OMAP4 or OMAP5 ??
> > > 
> > 
> > I suppose even OMAP4-only, since OMAP5 always has DT enabled.
> 
> Hmm yes, currently omap_hwmod_lookup(oh_name) produces
> bogus errors for other omaps as the hwmod data is only
> there for omap4.

shouldn't that be fixed too ? I mean, if data isn't just return -ENODEV
or something similar.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/f7cbc29e/attachment.sig>

[PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [121026 13:07]:
> On Fri, Oct 26, 2012 at 10:21:41AM -0700, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [121026 00:48]:
> > > On Friday 26 October 2012, Felipe Balbi wrote:
> > > > > +static void omap_init_ocp2scp(void)
> > > > > +{
> > > > > +     struct omap_hwmod       *oh;
> > > > > +     struct platform_device  *pdev;
> > > > > +     int                     bus_id = -1, dev_cnt = 0, i;
> > > > > +     struct omap_ocp2scp_dev *ocp2scp_dev;
> > > > > +     const char              *oh_name, *name;
> > > > > +     struct omap_ocp2scp_platform_data *pdata;
> > > > > +
> > > > > +     oh_name = "ocp2scp_usb_phy";
> > > > > +     name    = "omap-ocp2scp";
> > > > 
> > > > how about adding checks here to return early case we're not running on
> > > > OMAP4 or OMAP5 ??
> > > > 
> > > 
> > > I suppose even OMAP4-only, since OMAP5 always has DT enabled.
> > 
> > Hmm yes, currently omap_hwmod_lookup(oh_name) produces
> > bogus errors for other omaps as the hwmod data is only
> > there for omap4.
> 
> shouldn't that be fixed too ? I mean, if data isn't just return -ENODEV
> or something similar.

Yes some kind of checking is needed here.

Regards,

Tony

[PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp

[kishon]

On Saturday 27 October 2012 01:46 AM, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121026 13:07]:
>> On Fri, Oct 26, 2012 at 10:21:41AM -0700, Tony Lindgren wrote:
>>> * Arnd Bergmann <arnd@arndb.de> [121026 00:48]:
>>>> On Friday 26 October 2012, Felipe Balbi wrote:
>>>>>> +static void omap_init_ocp2scp(void)
>>>>>> +{
>>>>>> +     struct omap_hwmod       *oh;
>>>>>> +     struct platform_device  *pdev;
>>>>>> +     int                     bus_id = -1, dev_cnt = 0, i;
>>>>>> +     struct omap_ocp2scp_dev *ocp2scp_dev;
>>>>>> +     const char              *oh_name, *name;
>>>>>> +     struct omap_ocp2scp_platform_data *pdata;
>>>>>> +
>>>>>> +     oh_name = "ocp2scp_usb_phy";
>>>>>> +     name    = "omap-ocp2scp";
>>>>>
>>>>> how about adding checks here to return early case we're not running on
>>>>> OMAP4 or OMAP5 ??
>>>>>
>>>>
>>>> I suppose even OMAP4-only, since OMAP5 always has DT enabled.
>>>
>>> Hmm yes, currently omap_hwmod_lookup(oh_name) produces
>>> bogus errors for other omaps as the hwmod data is only
>>> there for omap4.
>>
>> shouldn't that be fixed too ? I mean, if data isn't just return -ENODEV
>> or something similar.
>
> Yes some kind of checking is needed here.

Ok. I'll fix and send.

Thanks
Kishon