[RFC PATCH v2 0/2] omap: add ocp2scp as a misc driver

This patch series is done as a preparatory step for adding phy drivers
for dwc3 and musb.

This series adds a new driver for ocp2scp (only dt) to which phy
drivers are connected.

Since currently there is no generic way to create a child device along
with doing a pm_runtime_enable (the exact requirement for ocp2scp), i'm
sending this second rfc patch with only dt support. If we can figure out
a way to do that generically this patch series can be dropped and I'll
send a patch only for adding dt data.

*arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp* and
*arm: omap: remove ocp2scp_usb_phy_ick clock node* patches are removed
from the series as Benoit is planning to take it up in his series.

This series was developed on
http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next

and [RFC PATCH 00/11] OMAP System Control Module (There is no direct
dependencies with this patch series).

However to test this patch series, the following patch series is needed
[PATCH v7 0/3] usb: multi-phy support
[PATCH v3 0/5] usb: musb: cleanup
[RFC PATCH 00/11] OMAP System Control Module
[RFC PATCH 00/10] omap: musb: Add device tree support (To be sent)

Kishon Vijay Abraham I (2):
  drivers: misc: omap: add a new driver for ocp2scp
  arm/dts: omap4: Add ocp2scp data

 .../devicetree/bindings/misc/omap-ocp2scp.txt      |    9 ++
 arch/arm/boot/dts/omap4.dtsi                       |    7 ++
 drivers/misc/Kconfig                               |    8 ++
 drivers/misc/Makefile                              |    1 +
 drivers/misc/omap-ocp2scp.c                        |   96 ++++++++++++++++++++
 5 files changed, 121 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/omap-ocp2scp.txt
 create mode 100644 drivers/misc/omap-ocp2scp.c

-- 
1.7.5.4

Add ocp2scp data node in omap4 device tree file.

Signed-off-by: Kishon Vijay Abraham I <redacted>
---
 arch/arm/boot/dts/omap4.dtsi |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d2cb392..9082191 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi

@@ -285,5 +285,12 @@
 				compatible = "ti,omap4-usb-phy";
 			};
 		};
+
+		ocp2scp at 4a0ad000  {
+			compatible = "ti,omap-ocp2scp";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ti,hwmods = "ocp2scp_usb_phy";
+		};
 	};
 };

-- 
1.7.5.4

Adds a new driver _ocp2scp_. This driver takes the responsibility of creating
all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY
is connected to ocp2scp.

This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is updated.

Signed-off-by: Kishon Vijay Abraham I <redacted>
---
 .../devicetree/bindings/misc/omap-ocp2scp.txt      |    9 ++
 drivers/misc/Kconfig                               |    8 ++
 drivers/misc/Makefile                              |    1 +
 drivers/misc/omap-ocp2scp.c                        |   96 ++++++++++++++++++++
 4 files changed, 114 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/omap-ocp2scp.txt
 create mode 100644 drivers/misc/omap-ocp2scp.c

diff --git a/Documentation/devicetree/bindings/misc/omap-ocp2scp.txt b/Documentation/devicetree/bindings/misc/omap-ocp2scp.txt
new file mode 100644
index 0000000..e9391d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/omap-ocp2scp.txt

@@ -0,0 +1,9 @@
+* OMAP OCP2SCP - ocp interface to scp interface
+
+properties:
+- compatible : Should be "ti,omap-ocp2scp"
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ti,hwmods : must be "ocp2scp_usb_phy"
+
+Sub-nodes:
+All the devices connected to ocp2scp are described using sub-node to ocp2scp

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 2661f6e..c70aa15 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig

@@ -508,6 +508,14 @@ config USB_SWITCH_FSA9480
 	  stereo and mono audio, video, microphone and UART data to use
 	  a common connector port.
 
+config OMAP_OCP2SCP
+	tristate "OMAP OCP2SCP DRIVER"
+	help
+	  Driver to enable ocp2scp module which transforms ocp interface
+	  protocol to scp protocol. In OMAP4, USB PHY is connected via
+	  OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
+	  OCP2SCP.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 456972f..4d7c8ce 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile

@@ -50,4 +50,5 @@ obj-y				+= lis3lv02d/
 obj-y				+= carma/
 obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
 obj-$(CONFIG_ALTERA_STAPL)	+=altera-stapl/
+obj-$(CONFIG_OMAP_OCP2SCP)	+= omap-ocp2scp.o
 obj-$(CONFIG_INTEL_MEI)		+= mei/

diff --git a/drivers/misc/omap-ocp2scp.c b/drivers/misc/omap-ocp2scp.c
new file mode 100644
index 0000000..f3a11e4
--- /dev/null
+++ b/drivers/misc/omap-ocp2scp.c

@@ -0,0 +1,96 @@
+/*
+ * omap-ocp2scp.c - transform ocp interface protocol to scp protocol
+ *
+ * Copyright (C) 2011 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.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+
+static int ocp2scp_remove_devices(struct device *dev, void *c)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+
+	platform_device_unregister(pdev);
+
+	return 0;
+}
+
+static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
+{
+	int			ret;
+	struct device_node	*np = pdev->dev.of_node;
+
+	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");
+			goto err0;
+		}
+	}
+	pm_runtime_enable(&pdev->dev);
+
+	return 0;
+
+err0:
+	device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices);
+
+	return ret;
+}
+
+static int __devexit omap_ocp2scp_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices);
+
+	return 0;
+}
+
+static const struct of_device_id omap_ocp2scp_id_table[] = {
+	{ .compatible = "ti,omap-ocp2scp" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+
+static struct platform_driver omap_ocp2scp_driver = {
+	.probe		= omap_ocp2scp_probe,
+	.remove		= __devexit_p(omap_ocp2scp_remove),
+	.driver		= {
+		.name	= "omap-ocp2scp",
+		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(omap_ocp2scp_id_table),
+	},
+};
+
+static int __init omap_ocp2scp_init(void)
+{
+	return platform_driver_register(&omap_ocp2scp_driver);
+}
+arch_initcall(omap_ocp2scp_init);
+
+static void __exit omap_ocp2scp_exit(void)
+{
+	platform_driver_unregister(&omap_ocp2scp_driver);
+}
+module_exit(omap_ocp2scp_exit);
+
+MODULE_ALIAS("platform: omap-ocp2scp");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("OMAP OCP2SCP DRIVER");
+MODULE_LICENSE("GPLv2");

-- 
1.7.5.4

On Fri, Jun 22, 2012 at 06:45:41PM +0530, Kishon Vijay Abraham I wrote:

Adds a new driver _ocp2scp_.

That's not what you called this driver in the patch below :(

This driver takes the responsibility of creating
all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY
is connected to ocp2scp.

This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is updated.

Can't this live where the scp drivers live?  Actually, where is that at?
Do we have scp drivers?

thanks,

greg k-h

Hi Greg,

On Sat, Jun 23, 2012 at 10:14 AM, Greg KH [off-list ref] wrote:

On Fri, Jun 22, 2012 at 06:45:41PM +0530, Kishon Vijay Abraham I wrote:

quoted

Adds a new driver _ocp2scp_.

That's not what you called this driver in the patch below :(

quoted

This driver takes the responsibility of creating
all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY
is connected to ocp2scp.

This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is updated.

Can't this live where the scp drivers live? ?Actually, where is that at?
Do we have scp drivers?

AFAIK, there isn't any driver for scp. But we have a driver for ocp
and it is present at arch/arm/mach-omap2/omap_l3_noc.c

Thanks
Kishon

Hi,

On Mon, Jun 25, 2012 at 11:09:54AM +0530, ABRAHAM, KISHON VIJAY wrote:

Hi Greg,

On Sat, Jun 23, 2012 at 10:14 AM, Greg KH [off-list ref] wrote:

quoted

On Fri, Jun 22, 2012 at 06:45:41PM +0530, Kishon Vijay Abraham I wrote:

quoted

Adds a new driver _ocp2scp_.

That's not what you called this driver in the patch below :(

quoted

This driver takes the responsibility of creating
all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY
is connected to ocp2scp.

This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is updated.

Can't this live where the scp drivers live? ?Actually, where is that at?
Do we have scp drivers?

AFAIK, there isn't any driver for scp. But we have a driver for ocp
and it is present at arch/arm/mach-omap2/omap_l3_noc.c

I don't think this deserves a directory of its own. Maybe
drivers/platform/arm/omap/ ?? the l3_noc is an OMAP-specific
interconnect and the SCP bus is also an OMAP-specific bus. I don't know
of any other arch/soc who uses the same interconnect IP as OMAP and the
same ocp2scp bridge. That bridge was created by TI for all I know.

Greg, would drivers/platform/arm/omap/ work for you ? We could also move
the interconnect drivers there.

-- 
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/20120625/b26d08a2/attachment.sig>

On Monday 25 June 2012, Felipe Balbi wrote:

quoted

quoted

Can't this live where the scp drivers live?  Actually, where is that at?
Do we have scp drivers?

AFAIK, there isn't any driver for scp. But we have a driver for ocp
and it is present at arch/arm/mach-omap2/omap_l3_noc.c

I don't think this deserves a directory of its own. Maybe
drivers/platform/arm/omap/ ?? the l3_noc is an OMAP-specific
interconnect and the SCP bus is also an OMAP-specific bus. I don't know
of any other arch/soc who uses the same interconnect IP as OMAP and the
same ocp2scp bridge. That bridge was created by TI for all I know.

Greg, would drivers/platform/arm/omap/ work for you ? We could also move
the interconnect drivers there.

I really don't like the idea of introducing drivers/platform/arm/ because
very little of the stuff that one would put in there are actually ARM
specific.

I have suggested a drivers/bus/ before and people did not see the need
back then, and we agreed to continue having a directory for each bus,
as we have for the big ones (pci, usb, i2c, spi, ...) and a lot of
simple (amba, rapidio, bcma, ...) or obscure (tc,  vlynq, nubus, ...)
ones.

I think we should reconsider the idea of drivers/bus/ with a file per
bus in there at least for new buses, but doing a new drivers/scp/
would be ok for me if there is enough opposition against the idea
of drivers/bus aggregating different buses.

	Arnd

Hi,

On Mon, Jun 25, 2012 at 04:26:08PM +0000, Arnd Bergmann wrote:

On Monday 25 June 2012, Felipe Balbi wrote:

quoted

quoted

quoted

Can't this live where the scp drivers live?  Actually, where is that at?
Do we have scp drivers?

AFAIK, there isn't any driver for scp. But we have a driver for ocp
and it is present at arch/arm/mach-omap2/omap_l3_noc.c

I don't think this deserves a directory of its own. Maybe
drivers/platform/arm/omap/ ?? the l3_noc is an OMAP-specific
interconnect and the SCP bus is also an OMAP-specific bus. I don't know
of any other arch/soc who uses the same interconnect IP as OMAP and the
same ocp2scp bridge. That bridge was created by TI for all I know.

Greg, would drivers/platform/arm/omap/ work for you ? We could also move
the interconnect drivers there.

I really don't like the idea of introducing drivers/platform/arm/ because
very little of the stuff that one would put in there are actually ARM
specific.

I have suggested a drivers/bus/ before and people did not see the need
back then, and we agreed to continue having a directory for each bus,
as we have for the big ones (pci, usb, i2c, spi, ...) and a lot of
simple (amba, rapidio, bcma, ...) or obscure (tc,  vlynq, nubus, ...)
ones.

I think we should reconsider the idea of drivers/bus/ with a file per
bus in there at least for new buses, but doing a new drivers/scp/
would be ok for me if there is enough opposition against the idea
of drivers/bus aggregating different buses.

I don't mind either way. The fact is that this ocp-to-scp bridge is
really a TI/OMAP thing. Not sure it deserves a directory of its own.

-- 
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/20120716/144f22e9/attachment-0001.sig>

Hi,

On Mon, Jul 16, 2012 at 1:42 PM, Felipe Balbi [off-list ref] wrote:

Hi,

On Mon, Jun 25, 2012 at 04:26:08PM +0000, Arnd Bergmann wrote:

quoted

On Monday 25 June 2012, Felipe Balbi wrote:

quoted

quoted

quoted

Can't this live where the scp drivers live?  Actually, where is that at?
Do we have scp drivers?

AFAIK, there isn't any driver for scp. But we have a driver for ocp
and it is present at arch/arm/mach-omap2/omap_l3_noc.c

I don't think this deserves a directory of its own. Maybe
drivers/platform/arm/omap/ ?? the l3_noc is an OMAP-specific
interconnect and the SCP bus is also an OMAP-specific bus. I don't know
of any other arch/soc who uses the same interconnect IP as OMAP and the
same ocp2scp bridge. That bridge was created by TI for all I know.

Greg, would drivers/platform/arm/omap/ work for you ? We could also move
the interconnect drivers there.

I really don't like the idea of introducing drivers/platform/arm/ because
very little of the stuff that one would put in there are actually ARM
specific.

I have suggested a drivers/bus/ before and people did not see the need
back then, and we agreed to continue having a directory for each bus,
as we have for the big ones (pci, usb, i2c, spi, ...) and a lot of
simple (amba, rapidio, bcma, ...) or obscure (tc,  vlynq, nubus, ...)
ones.

I think we should reconsider the idea of drivers/bus/ with a file per
bus in there at least for new buses, but doing a new drivers/scp/
would be ok for me if there is enough opposition against the idea
of drivers/bus aggregating different buses.

I don't mind either way. The fact is that this ocp-to-scp bridge is
really a TI/OMAP thing. Not sure it deserves a directory of its own.

Ok. Then I'll have a file in drivers/bus/ for ocp2scp driver.

Thanks
Kishon

On Monday 16 July 2012, ABRAHAM, KISHON VIJAY wrote:

quoted

quoted

I think we should reconsider the idea of drivers/bus/ with a file per
bus in there at least for new buses, but doing a new drivers/scp/
would be ok for me if there is enough opposition against the idea
of drivers/bus aggregating different buses.

I don't mind either way. The fact is that this ocp-to-scp bridge is
really a TI/OMAP thing. Not sure it deserves a directory of its own.

Ok. Then I'll have a file in drivers/bus/ for ocp2scp driver.

Sounds good to me. I don't care if it's the only file in that directory.
We can point the next person to a bus with a single file to that directory
and let them add theirs.

	Arnd

* Arnd Bergmann [off-list ref] [120716 12:51]:

On Monday 16 July 2012, ABRAHAM, KISHON VIJAY wrote:

quoted

quoted

quoted

I think we should reconsider the idea of drivers/bus/ with a file per
bus in there at least for new buses, but doing a new drivers/scp/
would be ok for me if there is enough opposition against the idea
of drivers/bus aggregating different buses.

I don't mind either way. The fact is that this ocp-to-scp bridge is
really a TI/OMAP thing. Not sure it deserves a directory of its own.

Ok. Then I'll have a file in drivers/bus/ for ocp2scp driver.

Sounds good to me. I don't care if it's the only file in that directory.
We can point the next person to a bus with a single file to that directory
and let them add theirs.

Yes great. Sounds like that's where the omap GPMC bus driver should
end up going eventually.

Regards,

Tony