Device tree support for AM35xx M-USB driver

The M-USB drivers glue code for AM35xx SOCs does not yet support device trees.

In legacy kernels, it was left to the respective board_ file to set up some necessary data structures before calling am35x_probe(). To support initialization using a DT, this now needs to be done in am35x.c.

These data structures including a set of four pointers to CPU-specific helper functions from the mach-omap2 directory.

Unfortunately those functions are only declared locally under arch/arm/mach-omap2/, and they can not easily be moved over to am35x.c. (While they just set a few bits in some system control module registers, they call functions from control.c to access the SCM. These control.c functions are also declared locally in mach-omap2 and not exported, and use some static variables and several other local include files.)

So if we want these four functions to be accessible from the driver glue code, their declarations have to be moved to the include/ hierarchy and their names need to be exported. This makes it possible to use the am35x M-USB driver as a kernel module.

The patch defines a new device 'compatible' name (am35x-musb) to differentiate it from omap3-musb. It also adds clock name declarations for interface and function clock to the device tree, so the am35x glue code's clk_get() calls can find them.

Rolf Peukert (5):
Make am35x helper function declarations accessible Export am35x helper functions
Add device tree support for M-USB on AM35xx SOCs Use new MUSB device name in AM3517 device tree. Add some information about the new DT device name

 Documentation/devicetree/bindings/usb/omap-usb.txt | 35 +++++++++++
 arch/arm/boot/dts/am3517.dtsi                      |  4 +-
 arch/arm/mach-omap2/omap_phy_internal.c            |  4 ++
 arch/arm/mach-omap2/usb.h                          |  5 --
 drivers/usb/musb/am35x.c                           | 73
++++++++++++++++++++++
 include/linux/platform_data/usb-omap.h             |  5 ++
 6 files changed, 120 insertions(+), 6 deletions(-)

2.4.10
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

To be able to call these four helper functions from the M-USB AM35xx glue code, their declarations need to be moved to a header file in the kernels include hierarchy.

---
 arch/arm/mach-omap2/usb.h              | 5 -----
 include/linux/platform_data/usb-omap.h | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

index 3395365..8b0cdf5 100644
@@ -63,8 +63,3 @@ struct usbhs_phy_data {
 extern void usb_musb_init(struct omap_musb_board_data *board_data);
 extern void usbhs_init(struct usbhs_omap_platform_data *pdata);
 extern int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys);

To be able to call these four helper functions from a M-USB AM35x driver module, their name symbols need to be exported.

---
 arch/arm/mach-omap2/omap_phy_internal.c | 4 ++++
 1 file changed, 4 insertions(+)

b/arch/arm/mach-omap2/omap_phy_internal.c
index 8e90356..648a60f 100644

@@ -82,6 +82,7 @@ void am35x_musb_reset(void)
 
 	regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
 }
+EXPORT_SYMBOL(am35x_musb_reset);
 
 void am35x_musb_phy_power(u8 on)
 {

@@ -120,6 +121,7 @@ void am35x_musb_phy_power(u8 on)
 		omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
 	}
 }
+EXPORT_SYMBOL(am35x_musb_phy_power);
 
 void am35x_musb_clear_irq(void)
 {

@@ -130,6 +132,7 @@ void am35x_musb_clear_irq(void)
 	omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
 	regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
 }
+EXPORT_SYMBOL(am35x_musb_clear_irq);
 
 void am35x_set_mode(u8 musb_mode)
 {

@@ -152,3 +155,4 @@ void am35x_set_mode(u8 musb_mode)
 
 	omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
 }
+EXPORT_SYMBOL(am35x_set_mode);

2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Add a function that sets up necessary data structures. In older kernels this was done in a board_ file. To support initialization via a DT, this now needs to be included in the probe() function.
Also declare a new device 'compatible' name (am35x-musb) to differentiate it from omap3-musb.

---
 drivers/usb/musb/am35x.c | 73
++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

index c41fe58..3c1477a 100644
@@ -462,6 +462,59 @@ static const struct platform_device_info

am35x_dev_info = {
.dma_mask = DMA_BIT_MASK(32),
};

+static struct musb_hdrc_platform_data *am35x_get_config(
+ struct platform_device *pdev)
+{
+ struct musb_hdrc_platform_data *pdata;
+ struct omap_musb_board_data *bdata;
+ struct musb_hdrc_config *config;
+ struct device_node *np;
+ int val, ret;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto err_out;
+
+ bdata = devm_kzalloc(&pdev->dev, sizeof(*bdata), GFP_KERNEL);
+ if (!bdata)
+ goto err_pdata;
+
+ config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+ if (!config)
+ goto err_bdata;
+
+ bdata->clear_irq = am35x_musb_clear_irq;
+ bdata->reset = am35x_musb_reset;
+ bdata->set_mode = am35x_set_mode;
+ bdata->set_phy_power = am35x_musb_phy_power;
+
+ pdata->board_data = bdata;
+ pdata->config = config;
+
+ /* Read settings from device tree */
+ np = pdev->dev.of_node;
+ if (np) {
+ of_property_read_u32(np, "mode", (u32 *)&pdata->mode);
+ of_property_read_u32(np, "interface-type",
+ (u32 *)&bdata->interface_type);
+ of_property_read_u32(np, "num-eps", (u32 *)&config->num_eps);
+ of_property_read_u32(np, "ram-bits", (u32 *)&config->ram_bits);
+ of_property_read_u32(np, "power", (u32 *)&pdata->power);
+
+ ret = of_property_read_u32(np, "multipoint", &val);
+ if (!ret && val)
+ config->multipoint = true;
+ }
+ return pdata;
+
+err_bdata:
+ devm_kfree(&pdev->dev, bdata);
+err_pdata:
+ devm_kfree(&pdev->dev, pdata);
+err_out:
+ return NULL;
+}
+
static int am35x_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = dev_get_platdata(&pdev->dev);
@@ -479,6 +532,12 @@ static int am35x_probe(struct platform_device *pdev)
goto err0;
}

+ if (!pdata) {
+ pdata = am35x_get_config(pdev);
+ if (!pdata)
+ goto err1;
+ }
+
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(&pdev->dev, "failed to get PHY clock\n");
@@ -548,6 +607,7 @@ err4:
clk_put(phy_clk);

err3:
+err1:
kfree(glue);

err0:
@@ -615,12 +675,25 @@ static int am35x_resume(struct device *dev)

static SIMPLE_DEV_PM_OPS(am35x_pm_ops, am35x_suspend, am35x_resume);

+#ifdef CONFIG_OF
+static const struct of_device_id am35x_id_table[] = {
+ {
+ .compatible = "ti,am35x-musb"
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, am35x_id_table); +#endif
+
static struct platform_driver am35x_driver = {
.probe = am35x_probe,
.remove = am35x_remove,
.driver = {
.name = "musb-am35x",
.pm = &am35x_pm_ops,
+#ifdef CONFIG_OF
+ .of_match_table = of_match_ptr(am35x_id_table),
+#endif
},
};

2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Use new MUSB device name in AM3517 device tree and add name declarations for interface and function clock, so the am35x drivers clk_get() calls can find them.

---
 arch/arm/boot/dts/am3517.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index 0b1c07f5..10838b5 100644
@@ -17,9 +17,11 @@
 
 	ocp {
 		am35x_otg_hs: am35x_otg_hs@5c040000 {
-			compatible = "ti,omap3-musb";
+			compatible = "ti,am35x-musb";
 			ti,hwmods = "am35x_otg_hs";
 			status = "disabled";
+			clocks = <&hsotgusb_ick_am35xx>, <&hsotgusb_fck_am35xx>;
+			clock-names = "ick", "fck";
 			reg = <0x5c040000 0x1000>;
 			interrupts = <71>;
 			interrupt-names = "mc";

2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Add some information about the new device name to the DT documentation.

---
 Documentation/devicetree/bindings/usb/omap-usb.txt | 35
++++++++++++++++++++++
 1 file changed, 35 insertions(+)

b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38d9bb8..cf98f61 100644

@@ -78,3 +78,38 @@ omap_dwc3 {
 	ranges;
 };
 
+AM35x MUSB GLUE
+ - compatible : Should be "ti,am35x-musb"
+ - ti,hwmods : must be "am35x_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num-eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram-bits : Specifies the ram address size. Should be set to "12"
+ - interface-type : Should be set to "1". (The AM35xx SOCs feature an
+   integrated phy, connected via UTMI+)
+ - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+   represents PERIPHERAL.
+ - power : Should be "50". This signifies the controller can supply up to
+   100mA when operating in host mode.
+
+SOC specific device node entry
+am35x_otg_hs: am35x_otg_hs@5c040000 {
+	compatible = "ti,am35x-musb";
+	ti,hwmods = "am35x_otg_hs";
+	clocks = <&hsotgusb_ick_am35xx>, <&hsotgusb_fck_am35xx>;
+	clock-names = "ick", "fck";
+	reg = <0x5c040000 0x1000>;
+	interrupts = <71>;
+	interrupt-names = "mc";
+};
+
+Board specific device node entry
+&am35x_otg_hs {
+	mode = <1>;
+	interface-type = <1>;
+	multipoint = <1>;
+	num-eps = <16>;
+	ram-bits = <12>;
+	power = <50>;
+};

2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello.

I'd rather get rid of this file completely.. How about just do a minimal drivers/phy driver? Maybe take a look at the drivers/phy/phy-dm816x-usb.c for an example. Then you probably want to use the musb_dsps.c driver if possible instead of the legacy am35x.c :)

Regards,

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Hello.

[...]