Re: [RFC PATCH] usb: hcd: warn about URB buffers that are not DMA aligned and are about to be DMA mapped
On Saturday 15 June 2013 16:22:30 Jussi Kivilinna wrote: > Hm.. rethink this a bit. > > Transfer buffer might be dma aligned but shorter than cacheline and end of > cacheline > used as something else. Manual alignment by host driver does not catch that > or fix that. > So, yes.. dma mapping should work with unaligned buffers, but maybe the actual > problem is multiple buffers from same cacheline. The buffers kmalloc() returns are OK in that regard. A driver that uses a buffer for anything but buffering is buggy. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] usb: hcd: warn about URB buffers that are not DMA aligned and are about to be DMA mapped
On 15.06.2013 16:47, Ming Lei wrote: > On Sat, Jun 15, 2013 at 9:10 PM, Jussi Kivilinna > wrote: >> On 15.06.2013 15:07, Ming Lei wrote: >>> On Sat, Jun 15, 2013 at 6:19 PM, Jussi Kivilinna >>> wrote: On 15.06.2013 10:41, Ming Lei wrote: > Cc: netdev > > On Fri, Jun 14, 2013 at 9:38 PM, Jussi Kivilinna > wrote: >> Appearently some out-of-tree USB host drivers do not handle DMA >> alignment for > > Looks these host drivers have to face the fact that the transfer buffer > is often > DMA non-aligned from network device drivers(in fact, the buffer is from > network protocol stack), if you run usbnet, then you will get the added > warning > immediately. > Yes, getting warning immediately, but once, and blaming host driver seems ok. >>> >>> We do know the fact of non-aligned transfer buffer from network, which has >>> been >>> for long time, so does it make sense to print warning and annoy people? >> >> It's only printed if host controller driver is not behaving correctly. > > If you make sure the warning is only printed on broken controller, > that is fine. > >> >> I have changed the message to be printed for v2-patch, and it is now: >> dev_WARN_ONCE(hcd->self.controller, 1, >> "broken USB host controller driver; does not correctly handle DMA >> alignment for urb->transfer_buffer (offset: %d).\n", >> dma_offset); >> >> I sent the patch as RFC since I'm not sure.. maybe annoying warnings make > > That is fine. > >> people aware of issues that they don't yet know of and things get fixed? > > I mean it isn't good to annoy people who are using good host controller, :-) > Yes, and now it seems that this might very well be the case with this patch. It would cause false warnings. >>> >> URB buffers and let core/hcd.c to do the mapping on architectures that >> have >> minimum DMA alignment requirements. This leads to random memory >> corruptions >> and crashes when using USB device drivers that use unaligned URB buffers. > > Maybe you should check the dma mapping/unmapping implementation of > the arch, non-aligned buffer should have be covered by the API easily. > > Also USB Host controller should have supported non-aligned DMA buffer. From what I found, there was some discussion about these issues around 2010: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/022983.html >>> >>> From the discussion, people think that HCD should handle the unaligned >>> buffer, >>> right? >> >> Yes, that's how I understood it. >> >>> To me, it seems that non-aligned buffers cannot be easily handled by all archs at dma mapping/unmapping phase and that HCD driver should do the alignment on >>> >>> If the memory which shares cache line with transfer buffer can't be >>> accessed during >>> DMA transfer(between URB submit and complete), dma mapping/unmapping >>> should have handled it. >>> >>> About the network transfer buffer case, I think it should be true, >>> otherwise there >>> should have lots of memory corruption reports about usb network drivers. >>> Fortunately, there are seldom such reports. >>> >> >> Another reason why rtl8192cu is so hard, is that it uses pre-allocated array >> for buffers of multiple URBs, and more than one transfer buffer can reside on >> same cache line. > > If so, that should be bug inside rtl8192, and more than one transfer > buffer shares > one cache line should be avoided, I understand the buffer isn't from > network stack, > don't I? > Buffer is not from network stack, but driver allocated array used for control message. >> archs that set ARCH_DMA_MINALIGN. For example, ehci_tegra does copy unaligned transfer buffers to temporary aligned buffers before letting them to USB core. >>> >>> Yes, if host controller can't handle this, the HCD has to work around >>> the problem. Anyway, most of host controllers can deal with the it, >>> can't they? >> >> Can they? Maybe they can handle most cases of unaligned buffers, but not some >> corner cases, like transfer buffers on same cache line. > > Of course, most of in-tree host controller can handle non-aligned buffer. > > If transfer buffers share one same cache line, it should be bug in driver, > not fault of host controller. > Ok. >> >>> > >> >> Instead of fixing host drivers, users end up posting bug reports against >> those USB device drivers that use unaligned buffers for URB; such as with >> rtl8192cu >> (http://thread.gmane.org/gmane.linux.kernel.wireless.general/105631). > > Not only rtl8192cu driver, all USB network device drivers have the > problem. > >> >> Patch makes this issue more visible at core level, and hopefully gives >> hint >> for future hcd driver implementors about this problem. > > So please find the root cause
Re: [RFC PATCH] usb: hcd: warn about URB buffers that are not DMA aligned and are about to be DMA mapped
On 16.06.2013 11:21, Oliver Neukum wrote: > On Saturday 15 June 2013 16:22:30 Jussi Kivilinna wrote: > >> Hm.. rethink this a bit. >> >> Transfer buffer might be dma aligned but shorter than cacheline and end of >> cacheline >> used as something else. Manual alignment by host driver does not catch that >> or fix that. >> So, yes.. dma mapping should work with unaligned buffers, but maybe the >> actual >> problem is multiple buffers from same cacheline. > > The buffers kmalloc() returns are OK in that regard. A driver that uses > a buffer for anything but buffering is buggy. Ok, I'll look at that direction. Thanks. -Jussi > > Regards > Oliver > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: EHCI: Remove double assignment of .start in ehci_msp_hc_driver
This patch removes a double assignment of .start in struct hc_driver
ehci_msp_hc_driver and also makes the code look more tidy.
Signed-off-by: Emil Goode
---
drivers/usb/host/ehci-pmcmsp.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-pmcmsp.c b/drivers/usb/host/ehci-pmcmsp.c
index 363890e..601e208 100644
--- a/drivers/usb/host/ehci-pmcmsp.c
+++ b/drivers/usb/host/ehci-pmcmsp.c
@@ -291,8 +291,7 @@ static const struct hc_driver ehci_msp_hc_driver = {
/*
* basic lifecycle operations
*/
- .reset =ehci_msp_setup,
- .start =ehci_run,
+ .reset = ehci_msp_setup,
.shutdown = ehci_shutdown,
.start = ehci_run,
.stop = ehci_stop,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] USB: OMAP1: add extcon to platform data
Add extcon field to platform data.
Signed-off-by: Aaro Koskinen
---
include/linux/platform_data/usb-omap1.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data/usb-omap1.h
b/include/linux/platform_data/usb-omap1.h
index 8c7764d..43b5ce1 100644
--- a/include/linux/platform_data/usb-omap1.h
+++ b/include/linux/platform_data/usb-omap1.h
@@ -23,6 +23,8 @@ struct omap_usb_config {
unsignedregister_dev:1;
u8 otg;/* port number, 1-based: usb1 == 2 */
+ const char *extcon;/* extcon device for OTG */
+
u8 hmc_mode;
/* implicitly true if otg: host supports remote wakeup? */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] USB: OMAP1: Tahvo USB transceiver driver
Add Tahvo USB transceiver driver.
Based on old code from linux-omap tree. The original driver was written
by Juha Yrjölä, Tony Lindgren, and Timo Teräs.
Signed-off-by: Aaro Koskinen
---
drivers/usb/phy/Kconfig | 14 ++
drivers/usb/phy/Makefile| 1 +
drivers/usb/phy/phy-tahvo.c | 448
3 files changed, 463 insertions(+)
create mode 100644 drivers/usb/phy/phy-tahvo.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 14a50bd..a5c7937 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -145,6 +145,20 @@ config OMAP_OTG
This driver can also be built as a module. If so, the module
will be called omap-otg.
+config TAHVO_USB
+ tristate "Tahvo USB transceiver driver"
+ depends on MFD_RETU && EXTCON
+ help
+ Enable this to support USB transceiver on Tahvo. This is used
+ at least on Nokia 770.
+
+config TAHVO_USB_HOST_BY_DEFAULT
+ depends on TAHVO_USB
+ boolean "Device in USB host mode by default"
+ help
+ Say Y here, if you want the device to enter USB host mode
+ by default on bootup.
+
config USB_ISP1301
tristate "NXP ISP1301 USB transceiver support"
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index c7f391b..f3984d1 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -13,6 +13,7 @@ phy-fsl-usb2-objs := phy-fsl-usb.o
phy-fsm-usb.o
obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb2.o
obj-$(CONFIG_ISP1301_OMAP) += phy-isp1301-omap.o
obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o
+obj-$(CONFIG_TAHVO_USB)+= phy-tahvo.o
obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
new file mode 100644
index 000..a2d96a2
--- /dev/null
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -0,0 +1,448 @@
+/*
+ * Tahvo USB transceiver driver
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ *
+ * Parts copied from isp1301_omap.c.
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * Original driver written by Juha Yrjölä, Tony Lindgren and Timo Teräs.
+ * Modified for Retu/Tahvo MFD by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "tahvo-usb"
+
+#define TAHVO_REG_IDSR 0x02
+#define TAHVO_REG_USBR 0x06
+
+#define USBR_SLAVE_CONTROL (1 << 8)
+#define USBR_VPPVIO_SW (1 << 7)
+#define USBR_SPEED (1 << 6)
+#define USBR_REGOUT(1 << 5)
+#define USBR_MASTER_SW2(1 << 4)
+#define USBR_MASTER_SW1(1 << 3)
+#define USBR_SLAVE_SW (1 << 2)
+#define USBR_NSUSPEND (1 << 1)
+#define USBR_SEMODE(1 << 0)
+
+#define TAHVO_MODE_HOST0
+#define TAHVO_MODE_PERIPHERAL 1
+
+struct tahvo_usb {
+ struct platform_device *pt_dev;
+ struct usb_phy phy;
+ int vbus_state;
+ struct mutexserialize;
+ struct clk *ick;
+ int irq;
+ int tahvo_mode;
+ struct extcon_dev extcon;
+};
+
+static const char *tahvo_cable[] = {
+ "USB-HOST",
+ "USB",
+ NULL,
+};
+
+static ssize_t vbus_state_show(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct tahvo_usb *tu = dev_get_drvdata(device);
+ return sprintf(buf, "%d\n", tu->vbus_state);
+}
+static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);
+
+static void check_vbus_state(struct tahvo_usb *tu)
+{
+ struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
+ int reg, prev_state;
+
+ reg = retu_read(rdev, TAHVO_REG_IDSR);
+ if (reg & TAHVO_STAT_VBUS) {
+ switch (tu->phy.state) {
+ case OTG_STATE_B_IDLE:
+ /* Enable the gadget driver */
+ if (tu->phy.otg->gadget)
+ usb_gadget_vbus_connect(tu->phy.otg->gadget);
+ tu->phy.state = OTG_STATE_B_PERIPHERAL;
+ break;
+ case OTG_STATE_A_IDLE:
+
[PATCH v2 5/5] ARM: OMAP1: nokia770: enable Tahvo
Add platform data for Tahvo.
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap1/board-nokia770.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 62a15e2..85089d8 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -156,6 +156,7 @@ static struct omap_usb_config nokia770_usb_config
__initdata = {
.register_dev = 1,
.hmc_mode = 16,
.pins[0]= 6,
+ .extcon = "tahvo-usb",
};
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
@@ -234,16 +235,26 @@ static struct i2c_board_info nokia770_i2c_board_info_2[]
__initdata = {
{
I2C_BOARD_INFO("retu-mfd", 0x01),
},
+ {
+ I2C_BOARD_INFO("tahvo-mfd", 0x02),
+ },
};
static void __init nokia770_cbus_init(void)
{
const int retu_irq_gpio = 62;
+ const int tahvo_irq_gpio = 40;
if (gpio_request_one(retu_irq_gpio, GPIOF_IN, "Retu IRQ"))
return;
+ if (gpio_request_one(tahvo_irq_gpio, GPIOF_IN, "Tahvo IRQ")) {
+ gpio_free(retu_irq_gpio);
+ return;
+ }
irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ irq_set_irq_type(gpio_to_irq(tahvo_irq_gpio), IRQ_TYPE_EDGE_RISING);
nokia770_i2c_board_info_2[0].irq = gpio_to_irq(retu_irq_gpio);
+ nokia770_i2c_board_info_2[1].irq = gpio_to_irq(tahvo_irq_gpio);
i2c_register_board_info(2, nokia770_i2c_board_info_2,
ARRAY_SIZE(nokia770_i2c_board_info_2));
platform_device_register(&nokia770_cbus_device);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] USB: OMAP1: Tahvo USB support for 770
Hi, These patches add support for Tahvo USB transceiver and allow using both host and peripheral modes on Nokia 770. Tested (peripheral mode, host mode, vbus detection) with 3.10-rc6. History: v2: Use extcon framework to trigger OTG driver mode changes. v1: http://marc.info/?l=linux-omap&m=137081763029385&w=2 Earlier RFC versions: http://marc.info/?l=linux-omap&m=13655371679&w=2 http://marc.info/?l=linux-omap&m=136266725827698&w=2 Aaro Koskinen (5): ARM: OMAP1: USB: move omap_usb_config to platform data USB: OMAP1: add extcon to platform data USB: OMAP1: OTG controller driver USB: OMAP1: Tahvo USB transceiver driver ARM: OMAP1: nokia770: enable Tahvo arch/arm/mach-omap1/board-nokia770.c| 11 + arch/arm/mach-omap1/include/mach/usb.h | 38 +-- drivers/usb/phy/Kconfig | 24 ++ drivers/usb/phy/Makefile| 2 + drivers/usb/phy/phy-omap-otg.c | 171 drivers/usb/phy/phy-tahvo.c | 448 include/linux/platform_data/usb-omap1.h | 53 7 files changed, 710 insertions(+), 37 deletions(-) create mode 100644 drivers/usb/phy/phy-omap-otg.c create mode 100644 drivers/usb/phy/phy-tahvo.c create mode 100644 include/linux/platform_data/usb-omap1.h -- 1.8.3.1 A. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] ARM: OMAP1: USB: move omap_usb_config to platform data
Move omap_usb_config to platform data, so that OTG driver can include it.
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap1/include/mach/usb.h | 38 +---
include/linux/platform_data/usb-omap1.h | 51 +
2 files changed, 52 insertions(+), 37 deletions(-)
create mode 100644 include/linux/platform_data/usb-omap1.h
diff --git a/arch/arm/mach-omap1/include/mach/usb.h
b/arch/arm/mach-omap1/include/mach/usb.h
index 45e5ac7..2c26305 100644
--- a/arch/arm/mach-omap1/include/mach/usb.h
+++ b/arch/arm/mach-omap1/include/mach/usb.h
@@ -8,43 +8,7 @@
#defineis_usb0_device(config) 0
#endif
-struct omap_usb_config {
- /* Configure drivers according to the connectors on your board:
-* - "A" connector (rectagular)
-* ... for host/OHCI use, set "register_host".
-* - "B" connector (squarish) or "Mini-B"
-* ... for device/gadget use, set "register_dev".
-* - "Mini-AB" connector (very similar to Mini-B)
-* ... for OTG use as device OR host, initialize "otg"
-*/
- unsignedregister_host:1;
- unsignedregister_dev:1;
- u8 otg;/* port number, 1-based: usb1 == 2 */
-
- u8 hmc_mode;
-
- /* implicitly true if otg: host supports remote wakeup? */
- u8 rwc;
-
- /* signaling pins used to talk to transceiver on usbN:
-* 0 == usbN unused
-* 2 == usb0-only, using internal transceiver
-* 3 == 3 wire bidirectional
-* 4 == 4 wire bidirectional
-* 6 == 6 wire unidirectional (or TLL)
-*/
- u8 pins[3];
-
- struct platform_device *udc_device;
- struct platform_device *ohci_device;
- struct platform_device *otg_device;
-
- u32 (*usb0_init)(unsigned nwires, unsigned is_device);
- u32 (*usb1_init)(unsigned nwires);
- u32 (*usb2_init)(unsigned nwires, unsigned alt_pingroup);
-
- int (*ocpi_enable)(void);
-};
+#include
void omap_otg_init(struct omap_usb_config *config);
diff --git a/include/linux/platform_data/usb-omap1.h
b/include/linux/platform_data/usb-omap1.h
new file mode 100644
index 000..8c7764d
--- /dev/null
+++ b/include/linux/platform_data/usb-omap1.h
@@ -0,0 +1,51 @@
+/*
+ * Platform data for OMAP1 USB
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive for
+ * more details.
+ */
+#ifndef __LINUX_USB_OMAP1_H
+#define __LINUX_USB_OMAP1_H
+
+#include
+
+struct omap_usb_config {
+ /* Configure drivers according to the connectors on your board:
+* - "A" connector (rectagular)
+* ... for host/OHCI use, set "register_host".
+* - "B" connector (squarish) or "Mini-B"
+* ... for device/gadget use, set "register_dev".
+* - "Mini-AB" connector (very similar to Mini-B)
+* ... for OTG use as device OR host, initialize "otg"
+*/
+ unsignedregister_host:1;
+ unsignedregister_dev:1;
+ u8 otg;/* port number, 1-based: usb1 == 2 */
+
+ u8 hmc_mode;
+
+ /* implicitly true if otg: host supports remote wakeup? */
+ u8 rwc;
+
+ /* signaling pins used to talk to transceiver on usbN:
+* 0 == usbN unused
+* 2 == usb0-only, using internal transceiver
+* 3 == 3 wire bidirectional
+* 4 == 4 wire bidirectional
+* 6 == 6 wire unidirectional (or TLL)
+*/
+ u8 pins[3];
+
+ struct platform_device *udc_device;
+ struct platform_device *ohci_device;
+ struct platform_device *otg_device;
+
+ u32 (*usb0_init)(unsigned nwires, unsigned is_device);
+ u32 (*usb1_init)(unsigned nwires);
+ u32 (*usb2_init)(unsigned nwires, unsigned alt_pingroup);
+
+ int (*ocpi_enable)(void);
+};
+
+#endif /* __LINUX_USB_OMAP1_H */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] USB: OMAP1: OTG controller driver
Transceivers need to manage OTG controller state on OMAP1 to enable
switching between peripheral and host modes. Provide a driver for that.
Signed-off-by: Aaro Koskinen
---
drivers/usb/phy/Kconfig| 10 +++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/phy-omap-otg.c | 171 +
3 files changed, 182 insertions(+)
create mode 100644 drivers/usb/phy/phy-omap-otg.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7ef3eb8..14a50bd 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -135,6 +135,16 @@ config USB_GPIO_VBUS
optionally control of a D+ pullup GPIO as well as a VBUS
current limit regulator.
+config OMAP_OTG
+ tristate "OMAP USB OTG controller driver"
+ depends on ARCH_OMAP_OTG && EXTCON
+ help
+ Enable this to support some transceivers on OMAP1 platforms. OTG
+ controller is needed to switch between host and peripheral modes.
+
+ This driver can also be built as a module. If so, the module
+ will be called omap-otg.
+
config USB_ISP1301
tristate "NXP ISP1301 USB transceiver support"
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index a9169cb..c7f391b 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ISP1301_OMAP)+= phy-isp1301-omap.o
obj-$(CONFIG_MV_U3D_PHY) += phy-mv-u3d-usb.o
obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
+obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_OMAP_USB3)+= phy-omap-usb3.o
obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
new file mode 100644
index 000..2a8c674
--- /dev/null
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -0,0 +1,171 @@
+/*
+ * OMAP OTG controller driver
+ *
+ * Based on code from tahvo-usb.c and isp1301_omap.c drivers.
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct otg_device {
+ void __iomem*base;
+ boolid;
+ boolvbus;
+ struct extcon_specific_cable_nb vbus_dev;
+ struct extcon_specific_cable_nb id_dev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+};
+
+#define OMAP_OTG_CTRL 0x0c
+#define OMAP_OTG_ASESSVLD (1 << 20)
+#define OMAP_OTG_BSESSEND (1 << 19)
+#define OMAP_OTG_BSESSVLD (1 << 18)
+#define OMAP_OTG_VBUSVLD (1 << 17)
+#define OMAP_OTG_ID(1 << 16)
+#define OMAP_OTG_XCEIV_OUTPUTS \
+ (OMAP_OTG_ASESSVLD | OMAP_OTG_BSESSEND | OMAP_OTG_BSESSVLD | \
+OMAP_OTG_VBUSVLD | OMAP_OTG_ID)
+
+static void omap_otg_ctrl(struct otg_device *otg_dev, u32 outputs)
+{
+ u32 l;
+
+ l = readl(otg_dev->base + OMAP_OTG_CTRL);
+ l &= ~OMAP_OTG_XCEIV_OUTPUTS;
+ l |= outputs;
+ writel(l, otg_dev->base + OMAP_OTG_CTRL);
+}
+
+static void omap_otg_set_mode(struct otg_device *otg_dev)
+{
+ if (!otg_dev->id && otg_dev->vbus)
+ /* Set B-session valid. */
+ omap_otg_ctrl(otg_dev, OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
+ else if (otg_dev->vbus)
+ /* Set A-session valid. */
+ omap_otg_ctrl(otg_dev, OMAP_OTG_ASESSVLD);
+ else if (!otg_dev->id)
+ /* Set B-session end to indicate no VBUS. */
+ omap_otg_ctrl(otg_dev, OMAP_OTG_ID | OMAP_OTG_BSESSEND);
+}
+
+static int omap_otg_id_notifier(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct otg_device *otg_dev = container_of(nb, struct otg_device, id_nb);
+
+ otg_dev->id = event;
+ omap_otg_set_mode(otg_dev);
+
+ return NOTIFY_DONE;
+}
+
+static int omap_otg_vbus_notifier(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct otg_device *otg_dev = container_of(nb, struct otg_device,
+ vbus_nb);
+
+ otg_dev->vbus = event;
+ omap_o
Please improve the Kconfig help for USB_PHY
So I'm compiling 3.10-rc, and I am presented with a new config option: menuconfig USB_PHY tristate "USB Physical Layer drivers" select USB_OTG_UTILS help USB controllers (those which are host, device or DRD) need a device to handle the physical layer signalling, commonly called a PHY. The following drivers add support for such PHY devices. Okay, so I have a PC motherboard with a large number of host USB controllers. This tells me those controllers need a PHY, and at least once of the following drivers is needed to support that PHY. But which one? I have an Intel X79 chipset, and "Intel" doesn't appear anywhere in the Kconfig file. It's all Freescale, Philips/NXP, Marvell, Qualcomm, TI OMAP, Samsung, Renesas, etc. The only ICs by any of those on my motherboard are some Marvell SATA controllers. Anyway, I searched my old working .config and I didn't have any such drivers enabled. So I turned off this option, compiled and rebooted, kept my fingers crossed, and... yay! Keyboard still works! Thumb drive still works, USB/SATA adapter still works... I don't know WTF is going on here, but it looks like that help text lied to me. Could someone please rephrase it to reflect the truth better? How about (I'm not sure if this is *correct*, but consider it Signed-off-By if you want to use it): USB controllers (those which are host, peripheral or DRD) need a device to handle the physical layer signalling, commonly called a PHY. Standard x86 motherboards combine the PHY with the controller and do not need a separate driver, but some systems-on-chip use a separate PHY. This is particularly true for dual-role (a.k.a. USB on-the-go) devices. The drivers in this submenu add support for such PHY devices. If you're not sure if this applies to you, it probably doesn't; say N here. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Two remain problems at chipidea driver
On Thu, Mar 21, 2013 at 11:06 AM, Peter Chen wrote:
> On Wed, Mar 20, 2013 at 01:04:33PM +0200, Alexander Shishkin wrote:
>> Peter Chen writes:
>>
>> > On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote:
>> >>
>> >> > Eg, for tablet or phone, the dr_mode may be "gadget", but the
>> >> > otg_capable = 1.
>> >>
>> >> No, because dr_mode indicates controller's capability, and not the
>> >> "current" mode of operation. Why would anyone want to put *that* in a
>> >> DT?
>> >>
>> >
>> > OK, now I totally understand your mind of this problem. In fact, dr_mode
>> > is NOT controller's capability, even at its original place:
>> > (Documentation/devicetree/bindings/usb/fsl-usb.txt or nvidia,
>> > tegra20-ehci.txt)
>> > dr_mode is the usb working mode.
>> >
>> > When we design USB system, the requirements are differ from products
>> > to products.
>> > The phone/tablet device may only wants itself as gadget
>> > device, it needs to be no-response when there is a usb device plug in
>> > (eg usb keyboard with Micro B-to-A cable).
>> >
>> > The car entertainment system or other Standard-A port system do not want
>> > to be enumerated when it plugs to notebook using Standard A-to-A cable.
>>
>> Bah. Of course, you're right. We're stuck with dr_mode till people learn
>> to design middleware stacks that can handle being both host and
>> peripheral.
>>
>> > So, currently, even most of controllers are otg-capable, still most
>> > of designs are one working mode designed. The reason why we design
>> > the dr_mode is that we want controller working mode to be decided
>> > by DT without re-compile the kernel by build out the host/gadget driver.
>>
>> Ok, so then how about introducing *one* more parameter, something like
>> "dr_cap", which
>> 1) when specified, supersedes DCCPARAMS, so no need to read that
>> register any more;
>> 2) when unspecified, use DCCPARAMS;
>> 3) can be one of "host", "peripheral", "otg", "dual_role":
>>- host, peripheral: initialize one role only, stick to that, no otg;
>>- dual_role: initialize both roles, no otg;
>>- otg: both roles, ci->is_otg == true.
>
>>
>> Another question now is, do we need "dual_role" variant for the dr_mode
>> parameter?
>>
>
> "dr_cap" is a good idea to indicate controller's capability, but when
> it combines with "dr_mode", things will be more complicated.
> Eg, how we initialize roles, depends on dr_cap or dr_mode? Besides, we
> need to some judgements if dr_mode and dr_cap are conflict or not.
> Since we already have DCCPARAMS check at each role's init, I suggest
> we only need "otg_cap", it only indicates if otg is capable or not.
> We can do things like below:
>
> dr_mode: "host", "peripheral", "otg"
> otg_cap; false, true
>
> 1) For dr_mode usage, it is used like sascha's patch.
> 2) Then we decide ci->is_otg:
> if (otg_cap is existed)
> ci->is_otg = otg_cap;
> else
> read DDCPARMAS;
> if (both DC and HC are 1)
> ci->is_otg = 1;
> else
> ci->is_otg = 0;
>
> 3) if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET] && ci->is_otg)
> do_otg_init; /* Eg, enable ID interrupt at otgsc */
> 4) At ci_irq:
> if (ci->is_otg)
> otgsc = hw_read(ci, OP_OTGSC, ~0);
>
> /* Since id is only enabled at both roles are enabled,
> * if dr_mode = peripheral and ci_is_otg = true, code will
> * not handle id change.
> */
> if (ci->is_otg && (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) {
> handle id interrupt;
> }
>
> /*
> * Handle vbus change interrupt, it indicates device connection
> * and disconnection events.
> */
> if (ci->is_otg && (otgsc & OTGSC_BSVIE)
> && (otgsc & OTGSC_BSVIS)) {
> handle vbus interrupt;
> }
>
> Besides, at my patch, I always build otg.c, I don't think
> we need to give otg.c a config, this just like we don't
> need to have a config for otg capable. I will
> move all otgsc access to under the condition of ci->is_otg.
>
Alex, I would like to post dual-role/vbus patch recently. Do you have
further suggestion for how to access otgsc? If not, I will
use the way I showed above.
--
BR,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please improve the Kconfig help for USB_PHY
On Sun, Jun 16, 2013 at 04:19:23PM -0400, George Spelvin wrote: > So I'm compiling 3.10-rc, and I am presented with a new config option: > > menuconfig USB_PHY > tristate "USB Physical Layer drivers" > select USB_OTG_UTILS > help > USB controllers (those which are host, device or DRD) need a > device to handle the physical layer signalling, commonly called > a PHY. > > The following drivers add support for such PHY devices. > > Okay, so I have a PC motherboard with a large number of host USB > controllers. This tells me those controllers need a PHY, and > at least once of the following drivers is needed to support that > PHY. > > But which one? I have an Intel X79 chipset, and "Intel" doesn't > appear anywhere in the Kconfig file. It's all Freescale, Philips/NXP, > Marvell, Qualcomm, TI OMAP, Samsung, Renesas, etc. > > The only ICs by any of those on my motherboard are some Marvell > SATA controllers. > > > Anyway, I searched my old working .config and I didn't have any such > drivers enabled. So I turned off this option, compiled and rebooted, > kept my fingers crossed, and... yay! Keyboard still works! > > Thumb drive still works, USB/SATA adapter still works... I don't know > WTF is going on here, but it looks like that help text lied to me. > > Could someone please rephrase it to reflect the truth better? > > How about (I'm not sure if this is *correct*, but consider it > Signed-off-By if you want to use it): > > USB controllers (those which are host, peripheral or DRD) need > a device to handle the physical layer signalling, commonly > called a PHY. > > Standard x86 motherboards combine the PHY with the controller > and do not need a separate driver, but some systems-on-chip > use a separate PHY. This is particularly true for dual-role > (a.k.a. USB on-the-go) devices. > > The drivers in this submenu add support for such PHY devices. > > If you're not sure if this applies to you, it probably doesn't; > say N here. Feel free to rewrite this as a patch, in the proper form, so that I can apply it, I like it much better than what we have now. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: Improve Kconfig help for CONFIG_USB_PHY
The previous text confused users by not describing the very common (e.g. x86 PC) sitations where no PHY driver is necessary. Signed-off-by: George Spelvin --- I still can't vouch for *correctness* of this text; I'm relying on other people in the S-o-b chain to do that. drivers/usb/phy/Kconfig | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 7ef3eb8..b7b37ee 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -4,11 +4,19 @@ menuconfig USB_PHY bool "USB Physical Layer drivers" help - USB controllers (those which are host, device or DRD) need a + USB controllers (those which are host, peripheral or DRD) need a device to handle the physical layer signalling, commonly called a PHY. - - The following drivers add support for such PHY devices. + + Standard x86 motherboards combine the PHY with the controller + and do not need a separate driver, but some systems-on-chip + use a separate PHY. This is particularly true for dual-role + (a.k.a. USB on-the-go) devices. + + The drivers in this submenu add support for such PHY devices. + + If you're not sure if this applies to you, it probably doesn't; + say N here. if USB_PHY -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: dwc3: use extcon fwrk to receive connect/disconnect
On 06/14/2013 10:10 PM, Kishon Vijay Abraham I wrote:
> Modified dwc3-omap to receive connect and disconnect notification using
> extcon framework. Also did the necessary cleanups required after
> adapting to extcon framework.
>
> Signed-off-by: Kishon Vijay Abraham I
> Acked-by: Felipe Balbi
> ---
> This patch depends on
> git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git
> commit:f7ae906
>
> It should also be applied on top of
> usb: dwc3: omap: improve error handling of dwc3_omap_probe patch which is
> merged in Felipe's tree.
>
> So I'm not sure on whose tree this patch should go in.
>
> Changes from v3:
> * did #include of of_extcon.h after Chanwoo resent the patch separating
> extcon-class.c from of_extcon.c
> Changes from v2:
> * updated the Documentation with dwc3 dt binding information.
> * used of_extcon_get_extcon_dev to get extcon device from device tree data.
> Changes from v1:
> * regulator enable/disable is now done here instead of palmas-usb as some
> users
> of palmas-usb wont need regulator.
>
> Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
> drivers/usb/dwc3/dwc3-omap.c | 119
>
> include/linux/usb/dwc3-omap.h | 30 -
> 3 files changed, 105 insertions(+), 49 deletions(-)
> delete mode 100644 include/linux/usb/dwc3-omap.h
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index d4769f3..f1c15f3 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -53,6 +53,11 @@ OMAP DWC3 GLUE
> It should be set to "1" for HW mode and "2" for SW mode.
> - ranges: the child address space are mapped 1:1 onto the parent address
> space
>
> +Optional Properties:
> + - extcon : phandle for the extcon device omap dwc3 uses to detect
> + connect/disconnect events.
> + - vbus-supply : phandle to the regulator device tree node if needed.
> +
> Sub-nodes:
> The dwc3 core should be added as subnode to omap dwc3 glue.
> - dwc3 :
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index f8f76e6..14c1f1b 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -43,13 +43,15 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
>
> @@ -124,9 +126,21 @@ struct dwc3_omap {
> u32 utmi_otg_status;
>
> u32 dma_status:1;
> +
> + struct extcon_specific_cable_nb extcon_vbus_dev;
> + struct extcon_specific_cable_nb extcon_id_dev;
> + struct notifier_block vbus_nb;
> + struct notifier_block id_nb;
> +
> + struct regulator*vbus_reg;
> };
>
> -static struct dwc3_omap *_omap;
> +enum omap_dwc3_vbus_id_status {
> + OMAP_DWC3_ID_FLOAT,
> + OMAP_DWC3_ID_GROUND,
> + OMAP_DWC3_VBUS_OFF,
> + OMAP_DWC3_VBUS_VALID,
> +};
>
> static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
> {
> @@ -138,18 +152,23 @@ static inline void dwc3_omap_writel(void __iomem *base,
> u32 offset, u32 value)
> writel(value, base + offset);
> }
>
> -int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
> +static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
> + enum omap_dwc3_vbus_id_status status)
> {
> - u32 val;
> - struct dwc3_omap*omap = _omap;
> -
> - if (!omap)
> - return -EPROBE_DEFER;
> + int ret;
> + u32 val;
>
> switch (status) {
> case OMAP_DWC3_ID_GROUND:
> dev_dbg(omap->dev, "ID GND\n");
>
> + if (omap->vbus_reg) {
> + ret = regulator_enable(omap->vbus_reg);
> + if (ret) {
> + dev_dbg(omap->dev, "regulator enable failed\n");
> + return;
> + }
> + }
> val = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
> val &= ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
> | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
> @@ -172,6 +191,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status
> status)
> break;
>
> case OMAP_DWC3_ID_FLOAT:
> + if (omap->vbus_reg)
> + regulator_disable(omap->vbus_reg);
> +
> case OMAP_DWC3_VBUS_OFF:
> dev_dbg(omap->dev, "VBUS Disconnect\n");
>
> @@ -185,12 +207,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status
> status)
> break;
>
> default:
> - dev_dbg(omap->dev, "ID float\n");
> + dev_dbg(omap->dev, "invalid state\n");
> }
> -
> - return 0;
> }
> -EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
>
> static
[PATCH v2] usb: phy: Improve Kconfig help for CONFIG_USB_PHY
The previous text confused users by not describing the very common (e.g. x86 PC) sitations where no PHY driver is necessary. Signed-off-by: George Spelvin --- Just for example, here's some alternate, stronger wording. I don't know if this is true, either. Use whichever you prefer. drivers/usb/phy/Kconfig | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 7ef3eb8..6558c3a 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -4,11 +4,17 @@ menuconfig USB_PHY bool "USB Physical Layer drivers" help - USB controllers (those which are host, device or DRD) need a - device to handle the physical layer signalling, commonly called - a PHY. - - The following drivers add support for such PHY devices. + Most USB controllers have the physical layer signalling part + (commonly called a PHY) built in. However, dual-role devices + (a.k.a. USB on-the-go) which support being USB master or slave + with the same connector often use an external PHY. + + The drivers in this submenu add support for such PHY devices. + They are not needed for standard master-only (or the vast + majority of slave-only) USB interfaces. + + If you're not sure if this applies to you, it probably doesn't; + say N here. if USB_PHY -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCh V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci
On Sat, Jun 15, 2013 at 4:01 AM, Alan Stern wrote: > On Fri, 14 Jun 2013, Roger Quadros wrote: > >> >> hi >> >> The following is my understanding. >> >> I think for PHY initialization and shutdown part, it is generic for >> >> other parts. >> >> PHY initialization need to be called before hc_driver->reset is called. >> >> I think it can be added at usb_add_hcd. >> >> For PHY shutdown, it can be added at usb_remove_hcd. >> > >> > Yes, that should work. >> >> I don't think this will work with OMAP USB host controller when used in >> Transceiver-less mode (e.g. HSIC). In this mode we need to release the HSIC >> reset (mapped to PHY init), after the EHCI controller is up and running. >> >> On the other hand, in the PHY mode, the PHY needs to be initialized (brought >> out >> of reset) before the EHCI controller starts. > > In other words, transceiver-less mode effectively works without using a > software-controlled PHY? > >> This behavior might be different on other controllers. Generalization is good >> as long as there is an override available for the controllers to handle the >> PHY init/shutdown themselves. > > To avoid PHY init/shutdown, the platform driver should simply leave the > generic PHY pointer (which has not yet been added to struct hcd) set to > NULL. > So does it mean that i need add adtional usb_phy to struct hcd? I think we can still make use of struct hcd->phy without add addtional members. For OMAP transceiver-less mode, you can still use your own phy init/shutdown and leave the hcd->phy to be NULL, and for the PHY mode, hcd->phy can be set. It will do ->init at usb_add_hcd and ->shutdown at usb_remove_hcd. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
