* [PATCH V4 1/4] ARM: shmobile: r8a7791: Add USBHS clock support
2014-02-23 18:00 [PATCH V4 0/4] ARM: shmobile: koelsch: Add USB support vladimir.barinov
@ 2014-02-23 18:00 ` vladimir.barinov
2014-02-23 18:00 ` [PATCH V4 2/4] ARM: shmobile: r8a7791: Add PCI USB host " vladimir.barinov
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: vladimir.barinov @ 2014-02-23 18:00 UTC (permalink / raw)
To: linux-sh
Cc: linus.walleij, linux-gpio, magnus.damm, horms, gnurou,
linux-kernel, kuninori.morimoto.gx, valentine.barshak
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This adds USBHS clocks to the R8A7791 SoC.
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Changes in V4:
Changes in V3:
* none.
Changes in V2:
* capitalized ARM in the subject;
* rebased on top the latest devel tag.
---
arch/arm/mach-shmobile/clock-r8a7791.c | 4 ++++
1 file changed, 4 insertions(+)
Index: build/arch/arm/mach-shmobile/clock-r8a7791.c
===================================================================
--- build.orig/arch/arm/mach-shmobile/clock-r8a7791.c 2014-02-23 21:47:44.486571967 +0400
+++ build/arch/arm/mach-shmobile/clock-r8a7791.c 2014-02-23 21:47:52.582571801 +0400
@@ -177,6 +177,7 @@
MSTP811, MSTP810, MSTP809,
MSTP726, MSTP724, MSTP723, MSTP721, MSTP720,
MSTP719, MSTP718, MSTP715, MSTP714,
+ MSTP704,
MSTP522,
MSTP314, MSTP312, MSTP311,
MSTP216, MSTP207, MSTP206,
@@ -208,6 +209,7 @@
[MSTP718] = SH_CLK_MSTP32_STS(&p_clk, SMSTPCR7, 18, MSTPSR7, 0), /* SCIF3 */
[MSTP715] = SH_CLK_MSTP32_STS(&p_clk, SMSTPCR7, 15, MSTPSR7, 0), /* SCIF4 */
[MSTP714] = SH_CLK_MSTP32_STS(&p_clk, SMSTPCR7, 14, MSTPSR7, 0), /* SCIF5 */
+ [MSTP704] = SH_CLK_MSTP32_STS(&mp_clk, SMSTPCR7, 4, MSTPSR7, 0), /* HSUSB */
[MSTP522] = SH_CLK_MSTP32_STS(&extal_clk, SMSTPCR5, 22, MSTPSR5, 0), /* Thermal */
[MSTP314] = SH_CLK_MSTP32_STS(&div4_clks[DIV4_SD0], SMSTPCR3, 14, MSTPSR3, 0), /* SDHI0 */
[MSTP312] = SH_CLK_MSTP32_STS(&div6_clks[DIV6_SD1], SMSTPCR3, 12, MSTPSR3, 0), /* SDHI1 */
@@ -281,6 +283,8 @@
CLKDEV_DEV_ID("r8a7791-vin.2", &mstp_clks[MSTP809]),
CLKDEV_DEV_ID("sata-r8a7791.0", &mstp_clks[MSTP815]),
CLKDEV_DEV_ID("sata-r8a7791.1", &mstp_clks[MSTP814]),
+ CLKDEV_DEV_ID("renesas_usbhs", &mstp_clks[MSTP704]),
+ CLKDEV_ICK_ID("usbhs", "usb_phy_rcar_gen2", &mstp_clks[MSTP704]),
};
#define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31) \
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH V4 2/4] ARM: shmobile: r8a7791: Add PCI USB host clock support
2014-02-23 18:00 [PATCH V4 0/4] ARM: shmobile: koelsch: Add USB support vladimir.barinov
2014-02-23 18:00 ` [PATCH V4 1/4] ARM: shmobile: r8a7791: Add USBHS clock support vladimir.barinov
@ 2014-02-23 18:00 ` vladimir.barinov
2014-02-23 18:00 ` [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support vladimir.barinov
2014-02-23 18:00 ` [PATCH V4 4/4] ARM: shmobile: koelsch: Add USB and PCI to defconfig vladimir.barinov
3 siblings, 0 replies; 10+ messages in thread
From: vladimir.barinov @ 2014-02-23 18:00 UTC (permalink / raw)
To: linux-sh
Cc: linus.walleij, linux-gpio, magnus.damm, horms, gnurou,
linux-kernel, kuninori.morimoto.gx, valentine.barshak
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This adds internal PCI USB host clock support to R-Car M2 SoC.
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Changes in V4:
Changes in V3:
* none.
Changes in V2:
* capitalized ARM in the subject;
* rebased on top the latest devel tag.
---
arch/arm/mach-shmobile/clock-r8a7791.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: build/arch/arm/mach-shmobile/clock-r8a7791.c
===================================================================
--- build.orig/arch/arm/mach-shmobile/clock-r8a7791.c 2014-02-23 21:47:52.582571801 +0400
+++ build/arch/arm/mach-shmobile/clock-r8a7791.c 2014-02-23 21:47:57.446571701 +0400
@@ -177,7 +177,7 @@
MSTP811, MSTP810, MSTP809,
MSTP726, MSTP724, MSTP723, MSTP721, MSTP720,
MSTP719, MSTP718, MSTP715, MSTP714,
- MSTP704,
+ MSTP704, MSTP703,
MSTP522,
MSTP314, MSTP312, MSTP311,
MSTP216, MSTP207, MSTP206,
@@ -210,6 +210,7 @@
[MSTP715] = SH_CLK_MSTP32_STS(&p_clk, SMSTPCR7, 15, MSTPSR7, 0), /* SCIF4 */
[MSTP714] = SH_CLK_MSTP32_STS(&p_clk, SMSTPCR7, 14, MSTPSR7, 0), /* SCIF5 */
[MSTP704] = SH_CLK_MSTP32_STS(&mp_clk, SMSTPCR7, 4, MSTPSR7, 0), /* HSUSB */
+ [MSTP703] = SH_CLK_MSTP32_STS(&mp_clk, SMSTPCR7, 3, MSTPSR7, 0), /* EHCI */
[MSTP522] = SH_CLK_MSTP32_STS(&extal_clk, SMSTPCR5, 22, MSTPSR5, 0), /* Thermal */
[MSTP314] = SH_CLK_MSTP32_STS(&div4_clks[DIV4_SD0], SMSTPCR3, 14, MSTPSR3, 0), /* SDHI0 */
[MSTP312] = SH_CLK_MSTP32_STS(&div6_clks[DIV6_SD1], SMSTPCR3, 12, MSTPSR3, 0), /* SDHI1 */
@@ -285,6 +286,8 @@
CLKDEV_DEV_ID("sata-r8a7791.1", &mstp_clks[MSTP814]),
CLKDEV_DEV_ID("renesas_usbhs", &mstp_clks[MSTP704]),
CLKDEV_ICK_ID("usbhs", "usb_phy_rcar_gen2", &mstp_clks[MSTP704]),
+ CLKDEV_DEV_ID("pci-rcar-gen2.0", &mstp_clks[MSTP703]),
+ CLKDEV_DEV_ID("pci-rcar-gen2.1", &mstp_clks[MSTP703]),
};
#define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31) \
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
2014-02-23 18:00 [PATCH V4 0/4] ARM: shmobile: koelsch: Add USB support vladimir.barinov
2014-02-23 18:00 ` [PATCH V4 1/4] ARM: shmobile: r8a7791: Add USBHS clock support vladimir.barinov
2014-02-23 18:00 ` [PATCH V4 2/4] ARM: shmobile: r8a7791: Add PCI USB host " vladimir.barinov
@ 2014-02-23 18:00 ` vladimir.barinov
2014-02-24 3:52 ` Magnus Damm
2014-02-23 18:00 ` [PATCH V4 4/4] ARM: shmobile: koelsch: Add USB and PCI to defconfig vladimir.barinov
3 siblings, 1 reply; 10+ messages in thread
From: vladimir.barinov @ 2014-02-23 18:00 UTC (permalink / raw)
To: linux-sh
Cc: linus.walleij, linux-gpio, magnus.damm, horms, gnurou,
linux-kernel, kuninori.morimoto.gx, valentine.barshak
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This adds the following to R-Car M2 Koelsch board:
- USBHS PHY
- USBHS device
- internal PCI USB host devices
Depending on state of ID pin from MAX3355E chip the usb0 is configured
ether as host or gadget.
In case of gadget the USBHS device is registered.
In case of host the PCI USB is registered.
The USB phy is bound to either USB host or USBHS device respectively, hence
configured to ether channel 0 or 2.
The USBHS can act as USB Host, and this can be easily configured.
But the simplest test with storage stick connected to USBHS Host provides
IP resets and system hangs. Even the PWEN pin is not handled and it is nessasary to
provide VBUS using gpio. It is easy to see in RCAR H2/M2 documentation
that the USBHS IP changed. F.e. the PWEN/EXTLP pins are no more presented in
USBHS via DVSTCTR register. And others.
Since the USBHS is not stable in Host mode lets connect fully tested PCI USB IP to usb0.
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Changes in V4:
* folded USBHS and internal PCI USB related patches together
* added handling of ID pin from MAX3355E chip
* removed ifdefs
Changes in V3:
* fixed a typo in the log message;
* fixed the USB1 device name in the pinmux table.
Changes in V2:
* capitalized ARM in the subject;
* rebased on top the latest devel tag;
* added pipe_type array to the usbhs platform info since it differs from the default.
* capitalized ARM in the subject;
* rebased on top the latest devel tag.
---
arch/arm/mach-shmobile/board-koelsch.c | 183 +++++++++++++++++++++++++++++++++
1 file changed, 183 insertions(+)
Index: build/arch/arm/mach-shmobile/board-koelsch.c
===================================================================
--- build.orig/arch/arm/mach-shmobile/board-koelsch.c 2014-02-23 21:47:44.510571967 +0400
+++ build/arch/arm/mach-shmobile/board-koelsch.c 2014-02-23 21:47:59.358571662 +0400
@@ -36,12 +36,15 @@
#include <linux/pinctrl/machine.h>
#include <linux/platform_data/gpio-rcar.h>
#include <linux/platform_data/rcar-du.h>
+#include <linux/platform_data/usb-rcar-gen2-phy.h>
#include <linux/platform_device.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/fixed.h>
#include <linux/regulator/gpio-regulator.h>
#include <linux/regulator/machine.h>
#include <linux/sh_eth.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/renesas_usbhs.h>
#include <linux/spi/flash.h>
#include <linux/spi/rspi.h>
#include <linux/spi/spi.h>
@@ -367,6 +370,177 @@
DEFINE_RES_IRQ(gic_spi(168)),
};
+/* USBHS */
+static const struct resource usbhs_resources[] __initconst = {
+ DEFINE_RES_MEM(0xe6590000, 0x100),
+ DEFINE_RES_IRQ(gic_spi(107)),
+};
+
+struct usbhs_private {
+ struct renesas_usbhs_platform_info info;
+ struct usb_phy *phy;
+};
+
+#define usbhs_get_priv(pdev) \
+ container_of(renesas_usbhs_get_info(pdev), struct usbhs_private, info)
+
+static int usbhs_power_ctrl(struct platform_device *pdev,
+ void __iomem *base, int enable)
+{
+ struct usbhs_private *priv = usbhs_get_priv(pdev);
+
+ if (!priv->phy)
+ return -ENODEV;
+
+ if (enable) {
+ int retval = usb_phy_init(priv->phy);
+
+ if (!retval)
+ retval = usb_phy_set_suspend(priv->phy, 0);
+ return retval;
+ }
+
+ usb_phy_set_suspend(priv->phy, 1);
+ usb_phy_shutdown(priv->phy);
+ return 0;
+}
+
+static int usbhs_hardware_init(struct platform_device *pdev)
+{
+ struct usbhs_private *priv = usbhs_get_priv(pdev);
+ struct usb_phy *phy;
+
+ phy = usb_get_phy_dev(&pdev->dev, 0);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ priv->phy = phy;
+ return 0;
+}
+
+static int usbhs_hardware_exit(struct platform_device *pdev)
+{
+ struct usbhs_private *priv = usbhs_get_priv(pdev);
+
+ if (!priv->phy)
+ return 0;
+
+ usb_put_phy(priv->phy);
+ priv->phy = NULL;
+ return 0;
+}
+
+static int usbhs_get_id(struct platform_device *pdev)
+{
+ return USBHS_GADGET;
+}
+
+static u32 koelsch_usbhs_pipe_type[] = {
+ USB_ENDPOINT_XFER_CONTROL,
+ USB_ENDPOINT_XFER_ISOC,
+ USB_ENDPOINT_XFER_ISOC,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_INT,
+ USB_ENDPOINT_XFER_INT,
+ USB_ENDPOINT_XFER_INT,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+ USB_ENDPOINT_XFER_BULK,
+};
+
+static struct usbhs_private usbhs_priv __initdata = {
+ .info = {
+ .platform_callback = {
+ .power_ctrl = usbhs_power_ctrl,
+ .hardware_init = usbhs_hardware_init,
+ .hardware_exit = usbhs_hardware_exit,
+ .get_id = usbhs_get_id,
+ },
+ .driver_param = {
+ .buswait_bwait = 4,
+ .pipe_type = koelsch_usbhs_pipe_type,
+ .pipe_size = ARRAY_SIZE(koelsch_usbhs_pipe_type),
+ },
+ }
+};
+
+static void __init koelsch_add_usb0_gadget(void)
+{
+ usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2");
+ platform_device_register_resndata(&platform_bus,
+ "renesas_usbhs", -1,
+ usbhs_resources,
+ ARRAY_SIZE(usbhs_resources),
+ &usbhs_priv.info,
+ sizeof(usbhs_priv.info));
+}
+
+/* Internal PCI0 */
+static const struct resource pci0_resources[] __initconst = {
+ DEFINE_RES_MEM(0xee090000, 0x10000), /* CFG */
+ DEFINE_RES_MEM(0xee080000, 0x10000), /* MEM */
+ DEFINE_RES_IRQ(gic_spi(108)),
+};
+
+static void __init koelsch_add_usb0_host(void)
+{
+ usb_bind_phy("0000:00:01.0", 0, "usb_phy_rcar_gen2");
+ usb_bind_phy("0000:00:02.0", 0, "usb_phy_rcar_gen2");
+ platform_device_register_simple("pci-rcar-gen2",
+ 0, pci0_resources,
+ ARRAY_SIZE(pci0_resources));
+}
+
+/* Internal PCI1 */
+static const struct resource pci1_resources[] __initconst = {
+ DEFINE_RES_MEM(0xee0d0000, 0x10000), /* CFG */
+ DEFINE_RES_MEM(0xee0c0000, 0x10000), /* MEM */
+ DEFINE_RES_IRQ(gic_spi(113)),
+};
+
+static void __init koelsch_add_usb1_host(void)
+{
+ platform_device_register_simple("pci-rcar-gen2",
+ 1, pci1_resources,
+ ARRAY_SIZE(pci1_resources));
+}
+
+/* USBHS PHY */
+static struct rcar_gen2_phy_platform_data usbhs_phy_pdata = {
+ .chan2_pci = 1, /* Channel 2 is PCI USB host */
+};
+
+static const struct resource usbhs_phy_resources[] __initconst = {
+ DEFINE_RES_MEM(0xe6590100, 0x100),
+};
+
+/* Add all available USB devices */
+static void __init koelsch_add_usb_devices(void)
+{
+ /* MAX3355E ID pin */
+ gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
+ if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
+ usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB host */
+ koelsch_add_usb0_host();
+ } else {
+ usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
+ koelsch_add_usb0_gadget();
+ }
+
+ platform_device_register_resndata(&platform_bus, "usb_phy_rcar_gen2",
+ -1, usbhs_phy_resources,
+ ARRAY_SIZE(usbhs_phy_resources),
+ &usbhs_phy_pdata,
+ sizeof(usbhs_phy_pdata));
+ koelsch_add_usb1_host();
+}
+
static const struct pinctrl_map koelsch_pinctrl_map[] = {
/* DU */
PIN_MAP_MUX_GROUP_DEFAULT("rcar-du-r8a7791", "pfc-r8a7791",
@@ -429,6 +603,14 @@
"sdhi2_ctrl", "sdhi2"),
PIN_MAP_MUX_GROUP_DEFAULT("sh_mobile_sdhi.2", "pfc-r8a7791",
"sdhi2_cd", "sdhi2"),
+ /* USB0 */
+ PIN_MAP_MUX_GROUP_DEFAULT("renesas_usbhs", "pfc-r8a7791",
+ "usb0", "usb0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("pci-rcar-gen2.0", "pfc-r8a7791",
+ "usb0", "usb0"),
+ /* USB1 */
+ PIN_MAP_MUX_GROUP_DEFAULT("pci-rcar-gen2.1", "pfc-r8a7791",
+ "usb1", "usb1"),
};
static void __init koelsch_add_standard_devices(void)
@@ -485,6 +667,7 @@
sdhi2_resources, ARRAY_SIZE(sdhi2_resources),
&sdhi2_info, sizeof(struct sh_mobile_sdhi_info));
+ koelsch_add_usb_devices();
}
/*
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
2014-02-23 18:00 ` [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support vladimir.barinov
@ 2014-02-24 3:52 ` Magnus Damm
2014-02-24 7:34 ` Vladimir Barinov
0 siblings, 1 reply; 10+ messages in thread
From: Magnus Damm @ 2014-02-24 3:52 UTC (permalink / raw)
To: vladimir.barinov
Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms],
Alexandre Courbot, linux-kernel, Kuninori Morimoto,
Valentine Barshak
On Mon, Feb 24, 2014 at 3:00 AM, <vladimir.barinov@cogentembedded.com> wrote:
> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> This adds the following to R-Car M2 Koelsch board:
> - USBHS PHY
> - USBHS device
> - internal PCI USB host devices
>
> Depending on state of ID pin from MAX3355E chip the usb0 is configured
> ether as host or gadget.
> In case of gadget the USBHS device is registered.
> In case of host the PCI USB is registered.
>
> The USB phy is bound to either USB host or USBHS device respectively, hence
> configured to ether channel 0 or 2.
>
> The USBHS can act as USB Host, and this can be easily configured.
> But the simplest test with storage stick connected to USBHS Host provides
> IP resets and system hangs. Even the PWEN pin is not handled and it is nessasary to
> provide VBUS using gpio. It is easy to see in RCAR H2/M2 documentation
> that the USBHS IP changed. F.e. the PWEN/EXTLP pins are no more presented in
> USBHS via DVSTCTR register. And others.
>
> Since the USBHS is not stable in Host mode lets connect fully tested PCI USB IP to usb0.
>
> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> Changes in V4:
> * folded USBHS and internal PCI USB related patches together
> * added handling of ID pin from MAX3355E chip
> * removed ifdefs
Thanks for removing the ifdefs and adding some initial implementation
for the MAX chip.
Please see my comments below.
> --- build.orig/arch/arm/mach-shmobile/board-koelsch.c 2014-02-23 21:47:44.510571967 +0400
> +++ build/arch/arm/mach-shmobile/board-koelsch.c 2014-02-23 21:47:59.358571662 +0400
> @@ -367,6 +370,177 @@
> DEFINE_RES_IRQ(gic_spi(168)),
> };
>
> +/* USBHS */
> +static const struct resource usbhs_resources[] __initconst = {
> + DEFINE_RES_MEM(0xe6590000, 0x100),
> + DEFINE_RES_IRQ(gic_spi(107)),
> +};
> +
> +struct usbhs_private {
> + struct renesas_usbhs_platform_info info;
> + struct usb_phy *phy;
> +};
> +
> +#define usbhs_get_priv(pdev) \
> + container_of(renesas_usbhs_get_info(pdev), struct usbhs_private, info)
> +
> +static int usbhs_power_ctrl(struct platform_device *pdev,
> + void __iomem *base, int enable)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> +
> + if (!priv->phy)
> + return -ENODEV;
> +
> + if (enable) {
> + int retval = usb_phy_init(priv->phy);
> +
> + if (!retval)
> + retval = usb_phy_set_suspend(priv->phy, 0);
> + return retval;
> + }
> +
> + usb_phy_set_suspend(priv->phy, 1);
> + usb_phy_shutdown(priv->phy);
> + return 0;
> +}
> +
> +static int usbhs_hardware_init(struct platform_device *pdev)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> + struct usb_phy *phy;
> +
> + phy = usb_get_phy_dev(&pdev->dev, 0);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + priv->phy = phy;
> + return 0;
> +}
> +
> +static int usbhs_hardware_exit(struct platform_device *pdev)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> +
> + if (!priv->phy)
> + return 0;
> +
> + usb_put_phy(priv->phy);
> + priv->phy = NULL;
> + return 0;
> +}
> +
> +static int usbhs_get_id(struct platform_device *pdev)
> +{
> + return USBHS_GADGET;
> +}
Uhm, I sort of expected this place to be where you read out the ID pin
state from the MAX device.
> +static u32 koelsch_usbhs_pipe_type[] = {
> + USB_ENDPOINT_XFER_CONTROL,
> + USB_ENDPOINT_XFER_ISOC,
> + USB_ENDPOINT_XFER_ISOC,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_INT,
> + USB_ENDPOINT_XFER_INT,
> + USB_ENDPOINT_XFER_INT,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> +};
> +
> +static struct usbhs_private usbhs_priv __initdata = {
> + .info = {
> + .platform_callback = {
> + .power_ctrl = usbhs_power_ctrl,
> + .hardware_init = usbhs_hardware_init,
> + .hardware_exit = usbhs_hardware_exit,
> + .get_id = usbhs_get_id,
> + },
> + .driver_param = {
> + .buswait_bwait = 4,
> + .pipe_type = koelsch_usbhs_pipe_type,
> + .pipe_size = ARRAY_SIZE(koelsch_usbhs_pipe_type),
> + },
> + }
> +};
> +
> +static void __init koelsch_add_usb0_gadget(void)
> +{
> + usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2");
> + platform_device_register_resndata(&platform_bus,
> + "renesas_usbhs", -1,
> + usbhs_resources,
> + ARRAY_SIZE(usbhs_resources),
> + &usbhs_priv.info,
> + sizeof(usbhs_priv.info));
> +}
> +
> +/* Internal PCI0 */
> +static const struct resource pci0_resources[] __initconst = {
> + DEFINE_RES_MEM(0xee090000, 0x10000), /* CFG */
> + DEFINE_RES_MEM(0xee080000, 0x10000), /* MEM */
> + DEFINE_RES_IRQ(gic_spi(108)),
> +};
> +
> +static void __init koelsch_add_usb0_host(void)
> +{
> + usb_bind_phy("0000:00:01.0", 0, "usb_phy_rcar_gen2");
> + usb_bind_phy("0000:00:02.0", 0, "usb_phy_rcar_gen2");
> + platform_device_register_simple("pci-rcar-gen2",
> + 0, pci0_resources,
> + ARRAY_SIZE(pci0_resources));
> +}
> +
> +/* Internal PCI1 */
> +static const struct resource pci1_resources[] __initconst = {
> + DEFINE_RES_MEM(0xee0d0000, 0x10000), /* CFG */
> + DEFINE_RES_MEM(0xee0c0000, 0x10000), /* MEM */
> + DEFINE_RES_IRQ(gic_spi(113)),
> +};
> +
> +static void __init koelsch_add_usb1_host(void)
> +{
> + platform_device_register_simple("pci-rcar-gen2",
> + 1, pci1_resources,
> + ARRAY_SIZE(pci1_resources));
> +}
> +
> +/* USBHS PHY */
> +static struct rcar_gen2_phy_platform_data usbhs_phy_pdata = {
> + .chan2_pci = 1, /* Channel 2 is PCI USB host */
> +};
> +
> +static const struct resource usbhs_phy_resources[] __initconst = {
> + DEFINE_RES_MEM(0xe6590100, 0x100),
> +};
> +
> +/* Add all available USB devices */
> +static void __init koelsch_add_usb_devices(void)
> +{
> + /* MAX3355E ID pin */
> + gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
> + if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
> + usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB host */
> + koelsch_add_usb0_host();
> + } else {
> + usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
> + koelsch_add_usb0_gadget();
> + }
I don't think we should perform this kind of check at boot-up. This
goes without saying, but normal USB supports hot-plug so we should
check the cable type when the cable insertion event happens. Please
see my comment above for USBHS-specific location.
I do however understand that according to your investigation you
cannot use USBHS in host mode. I believe further investigation is
needed in that area to determine what is the best way forward.
Regarding VBUS control, I believe it should be possible to drive the
USB0_VBUS as GPIO and manually control the power.
Would it be possible for you to break out USB PCI support for USB1 and
resend that so we can begin by merging that?
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
2014-02-24 3:52 ` Magnus Damm
@ 2014-02-24 7:34 ` Vladimir Barinov
2014-02-24 8:05 ` Magnus Damm
0 siblings, 1 reply; 10+ messages in thread
From: Vladimir Barinov @ 2014-02-24 7:34 UTC (permalink / raw)
To: Magnus Damm
Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms],
Alexandre Courbot, linux-kernel, Kuninori Morimoto,
Valentine Barshak
Hello Magnus,
Thank you for the quick response.
On 02/24/2014 07:52 AM, Magnus Damm wrote:
> +static int usbhs_hardware_init(struct platform_device *pdev)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> + struct usb_phy *phy;
> +
> + phy = usb_get_phy_dev(&pdev->dev, 0);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + priv->phy = phy;
> + return 0;
> +}
> +
> +static int usbhs_hardware_exit(struct platform_device *pdev)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> +
> + if (!priv->phy)
> + return 0;
> +
> + usb_put_phy(priv->phy);
> + priv->phy = NULL;
> + return 0;
> +}
> +
> +static int usbhs_get_id(struct platform_device *pdev)
> +{
> + return USBHS_GADGET;
> +}
> Uhm, I sort of expected this place to be where you read out the ID pin
> state from the MAX device.
Yes, I've seen your work for lager board.
I did differently then you beacause of problem in USBHS Host driver,
hence the need of setup PHY at initial stage to PCI USB and not to USBHS.
>
>> +static u32 koelsch_usbhs_pipe_type[] = {
>> +
>> +/* Add all available USB devices */
>> +static void __init koelsch_add_usb_devices(void)
>> +{
>> + /* MAX3355E ID pin */
>> + gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
>> + if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
>> + usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB host */
>> + koelsch_add_usb0_host();
>> + } else {
>> + usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
>> + koelsch_add_usb0_gadget();
>> + }
> I don't think we should perform this kind of check at boot-up. This
> goes without saying, but normal USB supports hot-plug so we should
> check the cable type when the cable insertion event happens. Please
> see my comment above for USBHS-specific location.
>
> I do however understand that according to your investigation you
> cannot use USBHS in host mode. I believe further investigation is
> needed in that area to determine what is the best way forward.
> Regarding VBUS control, I believe it should be possible to drive the
> USB0_VBUS as GPIO and manually control the power.
I see.
>
> Would it be possible for you to break out USB PCI support for USB1 and
> resend that so we can begin by merging that?
Wouldn't you like me also add USBHS in gadget mode for USB0 with the
similar check like you did on lager (with ID pin),
since it does not need the gpio-rcar changes too.
Also if you'd like I can add the USBHS in Host mode with the ID pin
check like you suggested, but the usb0 host will not be stable.
Probably this could speed up the USBHS Host development/fixing.
Regards,
Vladimir
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
2014-02-24 7:34 ` Vladimir Barinov
@ 2014-02-24 8:05 ` Magnus Damm
2014-02-24 8:29 ` Vladimir Barinov
0 siblings, 1 reply; 10+ messages in thread
From: Magnus Damm @ 2014-02-24 8:05 UTC (permalink / raw)
To: Vladimir Barinov
Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms],
Alexandre Courbot, linux-kernel, Kuninori Morimoto,
Valentine Barshak
Hi Vladimir,
On Mon, Feb 24, 2014 at 4:34 PM, Vladimir Barinov
<vladimir.barinov@cogentembedded.com> wrote:
> Hello Magnus,
>
> Thank you for the quick response.
>
>
> On 02/24/2014 07:52 AM, Magnus Damm wrote:
>>
>> +static int usbhs_hardware_init(struct platform_device *pdev)
>> +{
>> + struct usbhs_private *priv = usbhs_get_priv(pdev);
>> + struct usb_phy *phy;
>> +
>> + phy = usb_get_phy_dev(&pdev->dev, 0);
>> + if (IS_ERR(phy))
>> + return PTR_ERR(phy);
>> +
>> + priv->phy = phy;
>> + return 0;
>> +}
>> +
>> +static int usbhs_hardware_exit(struct platform_device *pdev)
>> +{
>> + struct usbhs_private *priv = usbhs_get_priv(pdev);
>> +
>> + if (!priv->phy)
>> + return 0;
>> +
>> + usb_put_phy(priv->phy);
>> + priv->phy = NULL;
>> + return 0;
>> +}
>> +
>> +static int usbhs_get_id(struct platform_device *pdev)
>> +{
>> + return USBHS_GADGET;
>> +}
>> Uhm, I sort of expected this place to be where you read out the ID pin
>> state from the MAX device.
>
> Yes, I've seen your work for lager board.
> I did differently then you beacause of problem in USBHS Host driver, hence
> the need of setup PHY at initial stage to PCI USB and not to USBHS.
Yeah, I understand. But with the current patches I wonder, isn't there
risk for short circuit ? Say that a USB host cable is connected during
boot and the PCI USB host controller is hooked up, what is stopping us
from switching the cable and driving VBUS from two sides using a USB
function cable? So the current patches seem a bit unsafe to me.
>>> +static u32 koelsch_usbhs_pipe_type[] = {
>>> +
>>> +/* Add all available USB devices */
>>> +static void __init koelsch_add_usb_devices(void)
>>> +{
>>> + /* MAX3355E ID pin */
>>> + gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
>>> + if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
>>> + usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB
>>> host */
>>> + koelsch_add_usb0_host();
>>> + } else {
>>> + usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
>>> + koelsch_add_usb0_gadget();
>>> + }
>>
>> I don't think we should perform this kind of check at boot-up. This
>> goes without saying, but normal USB supports hot-plug so we should
>> check the cable type when the cable insertion event happens. Please
>> see my comment above for USBHS-specific location.
>>
>> I do however understand that according to your investigation you
>> cannot use USBHS in host mode. I believe further investigation is
>> needed in that area to determine what is the best way forward.
>> Regarding VBUS control, I believe it should be possible to drive the
>> USB0_VBUS as GPIO and manually control the power.
>
> I see.
To control USB0_VBUS as GPIO you may need to adjust the PFC tables for
pinctrl. At some point, would it be possible for you to cook up some
prototype code to try to control the USB0_VBUS signal via GPIO? This
may be pointless if the USBHS hardware cannot operate in Host mode
though.
>> Would it be possible for you to break out USB PCI support for USB1 and
>> resend that so we can begin by merging that?
>
> Wouldn't you like me also add USBHS in gadget mode for USB0 with the similar
> check like you did on lager (with ID pin),
> since it does not need the gpio-rcar changes too.
Thanks for your offer. Yes, that would be nice. May I suggest doing it
on two levels:
1) Gadget-only support (is it possible to perform runtime check of ID
pin value at insert event and give error in case of Host?)
2) Incremental USBHS host patch
Using two incremental patches like above we can begin by merging 1)
and keep on working on 2).
> Also if you'd like I can add the USBHS in Host mode with the ID pin check
> like you suggested, but the usb0 host will not be stable.
> Probably this could speed up the USBHS Host development/fixing.
Please add it as a separate incremental patch if possible. I'd like to
have some kind of stable level of support without any funky
dependencies as a first goal, then keep on trying to get USBHS
working.
I think PCI USB for the micro USB port can simply be dropped now and
only use USBHS.
Thank you!
/ magnus
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
2014-02-24 8:05 ` Magnus Damm
@ 2014-02-24 8:29 ` Vladimir Barinov
2014-02-24 8:57 ` Magnus Damm
0 siblings, 1 reply; 10+ messages in thread
From: Vladimir Barinov @ 2014-02-24 8:29 UTC (permalink / raw)
To: Magnus Damm
Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms],
Alexandre Courbot, linux-kernel, Kuninori Morimoto,
Valentine Barshak
Hi Magnus,
On 02/24/2014 12:05 PM, Magnus Damm wrote:
> Hi Vladimir,
>
> On Mon, Feb 24, 2014 at 4:34 PM, Vladimir Barinov
> <vladimir.barinov@cogentembedded.com> wrote:
>> Hello Magnus,
>>
>> Thank you for the quick response.
>>
>>
>> On 02/24/2014 07:52 AM, Magnus Damm wrote:
>>> +static int usbhs_hardware_init(struct platform_device *pdev)
>>> +{
>>> + struct usbhs_private *priv = usbhs_get_priv(pdev);
>>> + struct usb_phy *phy;
>>> +
>>> + phy = usb_get_phy_dev(&pdev->dev, 0);
>>> + if (IS_ERR(phy))
>>> + return PTR_ERR(phy);
>>> +
>>> + priv->phy = phy;
>>> + return 0;
>>> +}
>>> +
>>> +static int usbhs_hardware_exit(struct platform_device *pdev)
>>> +{
>>> + struct usbhs_private *priv = usbhs_get_priv(pdev);
>>> +
>>> + if (!priv->phy)
>>> + return 0;
>>> +
>>> + usb_put_phy(priv->phy);
>>> + priv->phy = NULL;
>>> + return 0;
>>> +}
>>> +
>>> +static int usbhs_get_id(struct platform_device *pdev)
>>> +{
>>> + return USBHS_GADGET;
>>> +}
>>> Uhm, I sort of expected this place to be where you read out the ID pin
>>> state from the MAX device.
>> Yes, I've seen your work for lager board.
>> I did differently then you beacause of problem in USBHS Host driver, hence
>> the need of setup PHY at initial stage to PCI USB and not to USBHS.
> Yeah, I understand. But with the current patches I wonder, isn't there
> risk for short circuit ? Say that a USB host cable is connected during
> boot and the PCI USB host controller is hooked up, what is stopping us
> from switching the cable and driving VBUS from two sides using a USB
> function cable? So the current patches seem a bit unsafe to me.
Yes.
In case of such condition, when the usb cable changed after host device
probe the
risk of VBUS collision is obvious.
The interrupt driven ID pin monitoring in board file could help?
Probably the separate driver for the MAX3355 should not be added since
this provides
poor information, most significant is cable ID.
>
>>>> +static u32 koelsch_usbhs_pipe_type[] = {
>>>> +
>>>> +/* Add all available USB devices */
>>>> +static void __init koelsch_add_usb_devices(void)
>>>> +{
>>>> + /* MAX3355E ID pin */
>>>> + gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
>>>> + if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
>>>> + usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB
>>>> host */
>>>> + koelsch_add_usb0_host();
>>>> + } else {
>>>> + usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
>>>> + koelsch_add_usb0_gadget();
>>>> + }
>>> I don't think we should perform this kind of check at boot-up. This
>>> goes without saying, but normal USB supports hot-plug so we should
>>> check the cable type when the cable insertion event happens. Please
>>> see my comment above for USBHS-specific location.
>>>
>>> I do however understand that according to your investigation you
>>> cannot use USBHS in host mode. I believe further investigation is
>>> needed in that area to determine what is the best way forward.
>>> Regarding VBUS control, I believe it should be possible to drive the
>>> USB0_VBUS as GPIO and manually control the power.
>> I see.
> To control USB0_VBUS as GPIO you may need to adjust the PFC tables for
> pinctrl. At some point, would it be possible for you to cook up some
> prototype code to try to control the USB0_VBUS signal via GPIO? This
> may be pointless if the USBHS hardware cannot operate in Host mode
> though.
No need, there is a set_vbus callback in HSBHS platform code for this
purpose.
>
>>> Would it be possible for you to break out USB PCI support for USB1 and
>>> resend that so we can begin by merging that?
>> Wouldn't you like me also add USBHS in gadget mode for USB0 with the similar
>> check like you did on lager (with ID pin),
>> since it does not need the gpio-rcar changes too.
> Thanks for your offer. Yes, that would be nice. May I suggest doing it
> on two levels:
> 1) Gadget-only support (is it possible to perform runtime check of ID
> pin value at insert event and give error in case of Host?)
> 2) Incremental USBHS host patch
>
> Using two incremental patches like above we can begin by merging 1)
> and keep on working on 2).
>
>> Also if you'd like I can add the USBHS in Host mode with the ID pin check
>> like you suggested, but the usb0 host will not be stable.
>> Probably this could speed up the USBHS Host development/fixing.
> Please add it as a separate incremental patch if possible. I'd like to
> have some kind of stable level of support without any funky
> dependencies as a first goal, then keep on trying to get USBHS
> working.
>
> I think PCI USB for the micro USB port can simply be dropped now and
> only use USBHS.
Sure, will do.
Regards,
Vladimir
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
2014-02-24 8:29 ` Vladimir Barinov
@ 2014-02-24 8:57 ` Magnus Damm
0 siblings, 0 replies; 10+ messages in thread
From: Magnus Damm @ 2014-02-24 8:57 UTC (permalink / raw)
To: Vladimir Barinov
Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms],
Alexandre Courbot, linux-kernel, Kuninori Morimoto,
Valentine Barshak
Hi Vladimir,
On Mon, Feb 24, 2014 at 5:29 PM, Vladimir Barinov
<vladimir.barinov@cogentembedded.com> wrote:
> Hi Magnus,
>
>
> On 02/24/2014 12:05 PM, Magnus Damm wrote:
>>
>> Hi Vladimir,
>>
>> On Mon, Feb 24, 2014 at 4:34 PM, Vladimir Barinov
>> <vladimir.barinov@cogentembedded.com> wrote:
>>>
>>> Hello Magnus,
>>>
>>> Thank you for the quick response.
>>>
>>>
>>> On 02/24/2014 07:52 AM, Magnus Damm wrote:
>>>>
>>>> +static int usbhs_hardware_init(struct platform_device *pdev)
>>>> +{
>>>> + struct usbhs_private *priv = usbhs_get_priv(pdev);
>>>> + struct usb_phy *phy;
>>>> +
>>>> + phy = usb_get_phy_dev(&pdev->dev, 0);
>>>> + if (IS_ERR(phy))
>>>> + return PTR_ERR(phy);
>>>> +
>>>> + priv->phy = phy;
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int usbhs_hardware_exit(struct platform_device *pdev)
>>>> +{
>>>> + struct usbhs_private *priv = usbhs_get_priv(pdev);
>>>> +
>>>> + if (!priv->phy)
>>>> + return 0;
>>>> +
>>>> + usb_put_phy(priv->phy);
>>>> + priv->phy = NULL;
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int usbhs_get_id(struct platform_device *pdev)
>>>> +{
>>>> + return USBHS_GADGET;
>>>> +}
>>>> Uhm, I sort of expected this place to be where you read out the ID pin
>>>> state from the MAX device.
>>>
>>> Yes, I've seen your work for lager board.
>>> I did differently then you beacause of problem in USBHS Host driver,
>>> hence
>>> the need of setup PHY at initial stage to PCI USB and not to USBHS.
>>
>> Yeah, I understand. But with the current patches I wonder, isn't there
>> risk for short circuit ? Say that a USB host cable is connected during
>> boot and the PCI USB host controller is hooked up, what is stopping us
>> from switching the cable and driving VBUS from two sides using a USB
>> function cable? So the current patches seem a bit unsafe to me.
>
> Yes.
> In case of such condition, when the usb cable changed after host device
> probe the
> risk of VBUS collision is obvious.
> The interrupt driven ID pin monitoring in board file could help?
Well, it the board code may be one place to workaround things, but we
probably want to reuse this code somehow. And we already have some
kind of handling in the USBHS code.
When I grep in the directory drivers/usb/phy I can see those drivers
requesting IRQs. Perhaps this IRQ is for hotplug purpose? Maybe we can
have reusable GPIO interrupt driven hotplug detection in some generic
place?
The question is just how to let the OHCI/EHCI code coexist together
with the PHY IRQ code.
> Probably the separate driver for the MAX3355 should not be added since this
> provides
> poor information, most significant is cable ID.
Eventually we may end up with a separate driver, but to begin with it
is probably fine just to monitor GPIO pin states.
>>>>> +static u32 koelsch_usbhs_pipe_type[] = {
>>>>> +
>>>>> +/* Add all available USB devices */
>>>>> +static void __init koelsch_add_usb_devices(void)
>>>>> +{
>>>>> + /* MAX3355E ID pin */
>>>>> + gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
>>>>> + if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
>>>>> + usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB
>>>>> host */
>>>>> + koelsch_add_usb0_host();
>>>>> + } else {
>>>>> + usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
>>>>> + koelsch_add_usb0_gadget();
>>>>> + }
>>>>
>>>> I don't think we should perform this kind of check at boot-up. This
>>>> goes without saying, but normal USB supports hot-plug so we should
>>>> check the cable type when the cable insertion event happens. Please
>>>> see my comment above for USBHS-specific location.
>>>>
>>>> I do however understand that according to your investigation you
>>>> cannot use USBHS in host mode. I believe further investigation is
>>>> needed in that area to determine what is the best way forward.
>>>> Regarding VBUS control, I believe it should be possible to drive the
>>>> USB0_VBUS as GPIO and manually control the power.
>>>
>>> I see.
>>
>> To control USB0_VBUS as GPIO you may need to adjust the PFC tables for
>> pinctrl. At some point, would it be possible for you to cook up some
>> prototype code to try to control the USB0_VBUS signal via GPIO? This
>> may be pointless if the USBHS hardware cannot operate in Host mode
>> though.
>
> No need, there is a set_vbus callback in HSBHS platform code for this
> purpose.
I guess that callback is coming handy now. But I wonder how to control
the VBUS signal? You may now this already, but in some cases the PFC
tables need to be adjusted to allow GPIO control of a certain
function. Please see this patch for r8a7790, maybe something similar
is needed for r8a7791?
http://www.spinics.net/lists/linux-sh/msg28034.html
>>>> Would it be possible for you to break out USB PCI support for USB1 and
>>>> resend that so we can begin by merging that?
>>>
>>> Wouldn't you like me also add USBHS in gadget mode for USB0 with the
>>> similar
>>> check like you did on lager (with ID pin),
>>> since it does not need the gpio-rcar changes too.
>>
>> Thanks for your offer. Yes, that would be nice. May I suggest doing it
>> on two levels:
>> 1) Gadget-only support (is it possible to perform runtime check of ID
>> pin value at insert event and give error in case of Host?)
>> 2) Incremental USBHS host patch
>>
>> Using two incremental patches like above we can begin by merging 1)
>> and keep on working on 2).
>>
>>> Also if you'd like I can add the USBHS in Host mode with the ID pin check
>>> like you suggested, but the usb0 host will not be stable.
>>> Probably this could speed up the USBHS Host development/fixing.
>>
>> Please add it as a separate incremental patch if possible. I'd like to
>> have some kind of stable level of support without any funky
>> dependencies as a first goal, then keep on trying to get USBHS
>> working.
>>
>> I think PCI USB for the micro USB port can simply be dropped now and
>> only use USBHS.
>
> Sure, will do.
Great, thanks for your help!
/ magnus
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH V4 4/4] ARM: shmobile: koelsch: Add USB and PCI to defconfig
2014-02-23 18:00 [PATCH V4 0/4] ARM: shmobile: koelsch: Add USB support vladimir.barinov
` (2 preceding siblings ...)
2014-02-23 18:00 ` [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support vladimir.barinov
@ 2014-02-23 18:00 ` vladimir.barinov
3 siblings, 0 replies; 10+ messages in thread
From: vladimir.barinov @ 2014-02-23 18:00 UTC (permalink / raw)
To: linux-sh
Cc: linus.walleij, linux-gpio, magnus.damm, horms, gnurou,
linux-kernel, kuninori.morimoto.gx, valentine.barshak
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Add USB and PCI to koelsch_defconfig
Signed-off-by: <vladimir.barinov@cogentembedded.com>
Changes in V4:
* Added this patch to series
---
arch/arm/configs/koelsch_defconfig | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
Index: build/arch/arm/configs/koelsch_defconfig
===================================================================
--- build.orig/arch/arm/configs/koelsch_defconfig 2014-02-23 21:47:44.542571966 +0400
+++ build/arch/arm/configs/koelsch_defconfig 2014-02-23 21:48:03.718571572 +0400
@@ -18,6 +18,8 @@
CONFIG_CPU_BPREDICT_DISABLE=y
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_754322=y
+CONFIG_PCI=y
+CONFIG_PCI_RCAR_GEN2=y
CONFIG_SMP=y
CONFIG_SCHED_MC=y
CONFIG_NR_CPUS=8
@@ -81,7 +83,19 @@
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_GPIO=y
# CONFIG_HID is not set
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB_SUPPORT=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PCI=y
+CONFIG_USB_RENESAS_USBHS_HCD=y
+CONFIG_USB_RENESAS_USBHS=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_PHY=y
+CONFIG_USB_RCAR_GEN2_PHY=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_RENESAS_USBHS_UDC=y
+CONFIG_USB_ETH=y
CONFIG_MMC=y
CONFIG_MMC_SDHI=y
CONFIG_NEW_LEDS=y
^ permalink raw reply [flat|nested] 10+ messages in thread