Re: [PATCH v2 06/23] ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
Hi,
I think you can get rid of quite a bit more of the repeated data for
most boards, see below.
* Roger Quadros rog...@ti.com [130315 08:21]:
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 47 ++
1 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ce812de..5584682 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -21,6 +21,7 @@
#include linux/spi/spi.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/usb/phy.h
#include linux/io.h
#include linux/gpio.h
#include linux/mmc/host.h
@@ -445,16 +446,37 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+ .name = nop_usb_xceiv,
+ .id = 2,
+};
Please allocate these in the common ehci platform init code
so you don't have to repeat the same nop_usb_xceiv for each
board-*.c file. If you need to override these, then you can
pass something instead of NULL to the init function.
+static struct usbhs_phy_data phy_data[] __initdata = {
+ {
+ .port = 1,
+ .reset_gpio = 57,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.1,
+ },
+ {
+ .port = 2,
+ .reset_gpio = 61,
+ .vcc_gpio = -EINVAL,
+ .phy_id = nop_usb_xceiv.2,
+ },
+};
This is OK as it's the board specific data needed. If it's the
same for many boards, then you might want to add some init function
for the default case.
+static struct platform_device *sdp3430_devices[] __initdata = {
+ hsusb1_phy_device,
+ hsusb2_phy_device,
+};
It then seems that this can be in the common ehci platform init
code for most cases.
static void __init omap_3430sdp_init(void)
{
int gpio_pendown;
@@ -606,6 +633,14 @@ static void __init omap_3430sdp_init(void)
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
+
+ platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+ /* PHY on HSUSB Port 1 i.e. index 0 */
+ usb_bind_phy(ehci-omap.0, 0, nop_usb_xceiv.1);
+ /* PHY on HSUSB Port 2 i.e. index 1 */
+ usb_bind_phy(ehci-omap.0, 1, nop_usb_xceiv.2);
And this part too in most cases.
+ usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(usbhs_bdata);
}
Regards,
Tony
--
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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros rog...@ti.com [130314 08:45]:
OK. Let me know how the below patch looks. After that, the board code
will look like.
static struct usbhs_phy_data phy_data[] = {
{
.reset_gpio = 147,
.vcc_gpio = 148
.vcc_polarity = 1,
.phy_id = nop_usb_xceiv.2,
},
{}, /* Terminator */
};
usbhs_init_phys(phy_data);
Great, looks good to me.
Patch to implement usbhs_init_phys();
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..b9d6bff 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,12 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/dma-mapping.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/string.h
#include asm/io.h
+#include asm/gpio.h
Please change these both to linux/io.h and linux/gpio.h.
#include soc.h
#include omap_device.h
@@ -472,6 +476,141 @@ void __init setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
}
}
+static const char *reset_supply = reset;
+static const char *vcc_supply = vcc;
+
+/* Template for PHY regulators */
+static struct regulator_consumer_supply hsusb_reg_supplies[] = {
+ { /* .supply .dev_name filled later */ },
+};
+
+static struct regulator_init_data hsusb_reg_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb_reg_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies),
+};
+
+static struct fixed_voltage_config hsusb_reg_config = {
+ /* .supply_name filled later */
+ .microvolts = 330,
+ .gpio = -1, /* updated later */
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1, /* updated later */
+ .enabled_at_boot = 0, /* keep in RESET */
+ /* .init_data filled later */
+};
+
+static struct platform_device_info hsusb_reg_pdev_info = {
+ .name = reg-fixed-voltage,
+ .id = PLATFORM_DEVID_AUTO,
+};
+
+int __init usbhs_init_phys(struct usbhs_phy_data *phy)
+{
+ struct regulator_consumer_supply *supplies;
+ struct regulator_init_data *reg_data;
+ struct fixed_voltage_config *config;
+ char *supply_name;
+ int i;
+
+
+ for (i = 1; i = OMAP3_HS_USB_PORTS; i++) {
Maybe pass the number of ports to initialize too to the
function? Might be more future proof, although it will only
be needed until we have converted to DT.
+
+ if (!phy-phy_id) /* Terminator ? */
+ break;
+
+ if (!gpio_is_valid(phy-reset_gpio))
+ goto check_vcc;
+
+ supplies = kmemdup(hsusb_reg_supplies,
+ ARRAY_SIZE(hsusb_reg_supplies) *
+ sizeof(struct regulator_consumer_supply),
+ GFP_KERNEL);
+ if (!supplies)
+ return -ENOMEM;
+
+ supplies-supply = reset_supply;
+ supplies-dev_name = phy-phy_id;
+
+ reg_data = kmemdup(hsusb_reg_data, sizeof(hsusb_reg_data),
+ GFP_KERNEL);
+ if (!reg_data)
+ return -ENOMEM;
+
+ reg_data-consumer_supplies = supplies;
+
+ config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
+ GFP_KERNEL);
+ if (!config)
+ return -ENOMEM;
+
+ supply_name = kmalloc(14, GFP_KERNEL);
+ if (!supply_name)
+ return -ENOMEM;
+
+ scnprintf(supply_name, 13, hsusb%d_reset, i);
+ config-supply_name = supply_name;
+ config-gpio = phy-reset_gpio;
+ config-init_data = reg_data;
+
+ hsusb_reg_pdev_info.data = config;
+ hsusb_reg_pdev_info.size_data = sizeof(hsusb_reg_config);
+ platform_device_register_full(hsusb_reg_pdev_info);
+
+check_vcc:
+ if (!gpio_is_valid(phy-vcc_gpio))
+ goto next;
+
+ supplies = kmemdup(hsusb_reg_supplies,
+ ARRAY_SIZE(hsusb_reg_supplies) *
+ sizeof(struct regulator_consumer_supply),
+ GFP_KERNEL);
+ if (!supplies)
+ return -ENOMEM;
+
+ supplies-supply = vcc_supply;
+ supplies-dev_name = phy-phy_id;
+
+ reg_data = kmemdup(hsusb_reg_data, sizeof(hsusb_reg_data),
+ GFP_KERNEL);
+ if (!reg_data)
+ return -ENOMEM;
+
+ reg_data-consumer_supplies = supplies;
+
+ config =
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros rog...@ti.com [130313 06:46]: On 03/12/2013 06:40 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130312 04:47]: Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] [3]. ... arch/arm/mach-omap2/board-3430sdp.c| 97 +++- arch/arm/mach-omap2/board-3630sdp.c| 100 +++- arch/arm/mach-omap2/board-am3517crane.c| 95 +-- arch/arm/mach-omap2/board-am3517evm.c | 66 ++- arch/arm/mach-omap2/board-cm-t35.c | 95 ++- arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- arch/arm/mach-omap2/board-generic.c| 67 +++ arch/arm/mach-omap2/board-igep0020.c | 112 --- arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- arch/arm/mach-omap2/board-omap3evm.c | 62 -- arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- arch/arm/mach-omap2/board-omap4panda.c | 122 ++-- arch/arm/mach-omap2/board-overo.c | 54 - arch/arm/mach-omap2/board-zoom.c | 56 - Can't you have some mach-omap2/ehci-common.c that takes care of the initializiation to avoid this much addition to the board-*.c files? You may be able to have just a common function to do it and pass few parameters? Since we moved reset and power handling for the USB PHYs from omap-echi driver into the USB PHY driver we need to define the regulator data for RESET and Power line of each PHY. So most of the code added is just regulator data for the PHY rather than omap-ehci. It seems that you're now repeating minor variations of the same PHY over and over again though. Instead of a common function, I can implement some macros that make it easier to define the regulators for the PHY in the board files. Does this sound OK? Personally I don't like such macros because it hides the implementation and is difficult to read/debug. I'd prefer a common function to initialize the PHY though as it sounds like using macros would just allocate similar PHY many times which seems unnecessary. Regards, Tony -- 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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros rog...@ti.com [130313 09:40]: On 03/13/2013 06:24 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130313 06:46]: On 03/12/2013 06:40 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130312 04:47]: Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] [3]. ... arch/arm/mach-omap2/board-3430sdp.c| 97 +++- arch/arm/mach-omap2/board-3630sdp.c| 100 +++- arch/arm/mach-omap2/board-am3517crane.c| 95 +-- arch/arm/mach-omap2/board-am3517evm.c | 66 ++- arch/arm/mach-omap2/board-cm-t35.c | 95 ++- arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- arch/arm/mach-omap2/board-generic.c| 67 +++ arch/arm/mach-omap2/board-igep0020.c | 112 --- arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- arch/arm/mach-omap2/board-omap3evm.c | 62 -- arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- arch/arm/mach-omap2/board-omap4panda.c | 122 ++-- arch/arm/mach-omap2/board-overo.c | 54 - arch/arm/mach-omap2/board-zoom.c | 56 - Can't you have some mach-omap2/ehci-common.c that takes care of the initializiation to avoid this much addition to the board-*.c files? You may be able to have just a common function to do it and pass few parameters? Since we moved reset and power handling for the USB PHYs from omap-echi driver into the USB PHY driver we need to define the regulator data for RESET and Power line of each PHY. So most of the code added is just regulator data for the PHY rather than omap-ehci. It seems that you're now repeating minor variations of the same PHY over and over again though. Yes it is the vcc and reset regulator data for the PHY that is getting repeated with variations in the GPIO number. Instead of a common function, I can implement some macros that make it easier to define the regulators for the PHY in the board files. Does this sound OK? Personally I don't like such macros because it hides the implementation and is difficult to read/debug. I'd prefer a common function to initialize the PHY though as it sounds like using macros would just allocate similar PHY many times which seems unnecessary. OK, so we want to create the regulator data at runtime to save some memory? I'll come up with something. Or I guess you can have just one instance that gets filled in by some PHY platform init function. Regards, Tony -- 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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
* Roger Quadros rog...@ti.com [130312 04:47]: Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] [3]. ... arch/arm/mach-omap2/board-3430sdp.c| 97 +++- arch/arm/mach-omap2/board-3630sdp.c| 100 +++- arch/arm/mach-omap2/board-am3517crane.c| 95 +-- arch/arm/mach-omap2/board-am3517evm.c | 66 ++- arch/arm/mach-omap2/board-cm-t35.c | 95 ++- arch/arm/mach-omap2/board-cm-t3517.c | 97 +++- arch/arm/mach-omap2/board-devkit8000.c | 20 ++-- arch/arm/mach-omap2/board-generic.c| 67 +++ arch/arm/mach-omap2/board-igep0020.c | 112 --- arch/arm/mach-omap2/board-omap3beagle.c| 93 +-- arch/arm/mach-omap2/board-omap3evm.c | 62 -- arch/arm/mach-omap2/board-omap3pandora.c | 52 +++-- arch/arm/mach-omap2/board-omap3stalker.c | 52 +++- arch/arm/mach-omap2/board-omap3touchbook.c | 62 +- arch/arm/mach-omap2/board-omap4panda.c | 122 ++-- arch/arm/mach-omap2/board-overo.c | 54 - arch/arm/mach-omap2/board-zoom.c | 56 - Can't you have some mach-omap2/ehci-common.c that takes care of the initializiation to avoid this much addition to the board-*.c files? You may be able to have just a common function to do it and pass few parameters? Regards, Tony -- 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] usb: musb: log VBUS error
* Grazvydas Ignotas nota...@gmail.com [130309 16:53]:
VBUS_ERROR is a serious error that the driver often doesn't recover from
in my tests, so we should at least inform the user about it.
Patch makes sens to me, just a related question..
Do you get this when trying to enable the host mode, right? Or have you seen
this in other situations too?
If the error happens when enabling the host mode, my experience is that
the VBUS_ERROR is caused by the musb trying to be too smart and doing the
timeouts automatically. If the VBUS on the hardware does not raise fast
enough to the right range for whatever reason, musb can produce this
error.
Regards,
Tony
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/usb/musb/musb_core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f95404e..df6a54e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
break;
}
- dev_dbg(musb-controller, VBUS_ERROR in %s (%02x, %s), retry
#%d, port1 %08x\n,
+ dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb-controller,
+VBUS_ERROR in %s (%02x, %s), retry #%d, port1
%08x\n,
otg_state_string(musb-xceiv-state),
devctl,
({ char *s;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] usb: musb: log VBUS error
* Grazvydas Ignotas nota...@gmail.com [130311 10:12]: On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren t...@atomide.com wrote: * Grazvydas Ignotas nota...@gmail.com [130309 16:53]: VBUS_ERROR is a serious error that the driver often doesn't recover from in my tests, so we should at least inform the user about it. Patch makes sens to me, just a related question.. Do you get this when trying to enable the host mode, right? Or have you seen this in other situations too? I sometimes see it when booting with cable connected to PC or connecting cable to PC after using a host adapter. In those cases OTG port dies completely until a powercycle :( Hmm OK. I suspect there's some kernel bug currently with the OTG id pin detection where it's initial state during the boot is ignored. But replugging the cable should fix that, and in your case it sounds like that's not the case. If the error happens when enabling the host mode, my experience is that the VBUS_ERROR is caused by the musb trying to be too smart and doing the timeouts automatically. If the VBUS on the hardware does not raise fast enough to the right range for whatever reason, musb can produce this error. Yeah the driver seems to expect that and has a ignore variable, I use KERN_DEBUG level in case it's set. Yes in the host case I think we then just retry enabling the session bit and don't have anything in place to check that the VBUS regulator is ready or not. Have not looked at that code for a while though. Regards, Tony -- 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 4/4] USB: OMAP: Tahvo USB transceiver driver
* Aaro Koskinen aaro.koski...@iki.fi [130307 06:44]: +#include mach/usb.h We should be getting rid of the plat and mach includes for drivers for omap1 also, so let's not make it harder by adding more of it. We should have just the following: include/linux/platform_data/usb-omap.h this contains just minimal pdata include/linux/usb/something.h if needed and cannot be local to driver Regards, Tony -- 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: [GIT PULL] arm-soc: OMAP USB Host cleanup for 3.9
* Roger Quadros rog...@ti.com [130214 04:08]: Hi Tony, This is the ARM-soc part of the OMAP USB Host cleanup series for 3.9. It is based on 3.8-rc6 + usbhost17-common that I sent earlier. Please pull. Thanks. Thanks for reworking this series! I'll pull this. Regards, Tony The following changes since commit 7f07863ec60f7d3dbeec5aff881ea074db3925ed: ARM: OMAP: Consolidate OMAP USB-HS platform data (part 1/3) (2013-02-13 13:22:34 +0200) are available in the git repository at: git://github.com/rogerq/linux.git usbhost17-for-arm-soc Roger Quadros (1): ARM: OMAP: Consolidate OMAP USB-HS platform data (part 3/3) arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-3630sdp.c|2 +- arch/arm/mach-omap2/board-am3517crane.c|2 +- arch/arm/mach-omap2/board-am3517evm.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-igep0020.c |4 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-zoom.c |2 +- arch/arm/mach-omap2/usb-host.c | 29 --- arch/arm/mach-omap2/usb.h | 20 +-- 18 files changed, 23 insertions(+), 60 deletions(-) -- cheers, -roger -- 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 v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
* Roger Quadros rog...@ti.com [130206 01:53]: On 02/05/2013 07:17 PM, Tony Lindgren wrote: * Greg KH gre...@linuxfoundation.org [130205 09:00]: On Tue, Feb 05, 2013 at 01:28:51PM +0200, Roger Quadros wrote: Hi Tony Greg, What's the best way to get these patches in? All patches have been acked by respective maintainers. If Tony can Ack the arch/arm/mach-omap2 stuff then should I send a pull request directly to Greg? or the other way round? Tony, fyi, these patches should not interfere with the dw3c/musb stuff sent by Felipe Kishon. I'm fine with Tony just taking them all if he wants to. OK. Roger, can you please do me a pull request with these against v3.8-rc6? Tony, Since this depends on [1] and [2] which are both in linux-next, should I base it on linux-next? Maybe you can base it on some commit in Greg's USB tree? Just check with Greg that whatever you use as a base is an immutable commit and OK to use as a base. Another option is to defer this to 3.10 merge window, along with the DT adaptation for OMAP USB Host. Once you have a branch ready that builds and boots, let's see how badly that conflicts with other branches we have queued up. If it's trivial only, then maybe Greg can pick up the patches. If not, we can still try to merge it in later on during the merge window as it would be nice to get USB to usable point with DT. Regards, Tony [1] [PATCH v9 00/20] OMAP USB Host cleanup https://lkml.org/lkml/2013/1/23/155 [2] [PATCH v2 0/6] USB: Add support for multiple PHYs of same type https://lkml.org/lkml/2013/1/24/876 -- 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 v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
* Greg KH gre...@linuxfoundation.org [130205 09:00]: On Tue, Feb 05, 2013 at 01:28:51PM +0200, Roger Quadros wrote: Hi Tony Greg, What's the best way to get these patches in? All patches have been acked by respective maintainers. If Tony can Ack the arch/arm/mach-omap2 stuff then should I send a pull request directly to Greg? or the other way round? Tony, fyi, these patches should not interfere with the dw3c/musb stuff sent by Felipe Kishon. I'm fine with Tony just taking them all if he wants to. OK. Roger, can you please do me a pull request with these against v3.8-rc6? Regards, Tony -- 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: [GIT PULL] ARM part of USB patches
* gre...@linuxfoundation.org gre...@linuxfoundation.org [130205 09:28]: On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote: Hi Tony, Greg, On Tuesday 05 February 2013 08:54 PM, kishon wrote: Hi Tony, As discussed, I'm sending a pull request for the arch/arm part of my USB patches. These patches are necessary to get MUSB functional in both dt and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch series *depends* on some of the patches which are merged in usb-next. This patch series should go in only after USB. Or else it will break compilation. Then it probably should go through the USB tree, right? We don't want to break bisectability. Looks like this branch needs to be based on at least 01658f0f (usb: phy: add a new driver for usb part of control module) to compile. Probably needs other USB patches too to make sense. This branch has a high likelihood of conflicting with .dts files, so Kishon, I suggest you do two branches: 1. A branch for Greg based on top of the USB changes This branch should contain: ARM: OMAP4: remove control module address space from PHY and OTG ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox ARM: OMAP: USB: Add phy binding information Naturally please make sure they compile and boot on their own. Looks like this will only cause few trivial include merge conflicts with what I have queued up. You can add my Acked-by: Tony Lindgren t...@atomide.com for those. 2. A branch for Benoit based on v3.8-rc6 That branch should contain all the .dts changes as those will most likely cause nasty merge conflicts otherwise with what Benoit has queued up. Regards, Tony -- 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 4/4] drivers: usb: start using the control module driver
* Felipe Balbi ba...@ti.com [130204 07:57]: Hi, On Fri, Feb 01, 2013 at 11:14:24AM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [130125 02:30]: Hi, On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote: Start using the control module driver for powering on the PHY and for writing to the mailbox instead of writing to the control module registers on their own. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++ Documentation/devicetree/bindings/usb/usb-phy.txt |7 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 I'm taking this patch but I'm leaving out the omap_hwmod_44xx_data.c change just to kill dependency. Can you send that single change as a separate patch which Tony can queue ? For the USB patches, please also leave out patches touching arch/arm/mach-omap2/devices.c. Those are almost guaranteed to cause pointless merge conflicts with other branches. I suggest you set up few immutable branches: 1. Minimal platform_data changes for all your USB changes This should contain include/linux/platform_data changes and changes to arch/arm/*omap* so me and Paul can merge it in too to avoid merge conflicts. 2. The rest of the driver/usb changes This can then be based on #1 branch above. 3. Changes for the .dts files for Benoit These can be queued separately from #1 and #2 above. I'm done with all USB stuff for this merge window. The patches which I didn't take have no dependencies on any drivers/ part. You can easily queue this through your tree. Sorry with a huge pile of USB patches being posted I have no idea at this point which USB related patches for arch/arm/*omap* have no dependencies to the USB driver changes. So I suggest that you, Kishon and Roger figure it out and put together a pull request for me against v3.8-rc6 for the patches I should merge. Regards, Tony -- 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 4/4] drivers: usb: start using the control module driver
* Felipe Balbi ba...@ti.com [130125 02:30]: Hi, On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote: Start using the control module driver for powering on the PHY and for writing to the mailbox instead of writing to the control module registers on their own. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++ Documentation/devicetree/bindings/usb/usb-phy.txt |7 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 I'm taking this patch but I'm leaving out the omap_hwmod_44xx_data.c change just to kill dependency. Can you send that single change as a separate patch which Tony can queue ? For the USB patches, please also leave out patches touching arch/arm/mach-omap2/devices.c. Those are almost guaranteed to cause pointless merge conflicts with other branches. I suggest you set up few immutable branches: 1. Minimal platform_data changes for all your USB changes This should contain include/linux/platform_data changes and changes to arch/arm/*omap* so me and Paul can merge it in too to avoid merge conflicts. 2. The rest of the driver/usb changes This can then be based on #1 branch above. 3. Changes for the .dts files for Benoit These can be queued separately from #1 and #2 above. Regards, Tony -- 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 v2 2/4] ARM: OMAP: devices: create device for usb part of control module
* Felipe Balbi ba...@ti.com [130123 03:27]: Hi, On Mon, Jan 21, 2013 at 07:38:26PM +0530, Kishon Vijay Abraham I wrote: A seperate driver has been added to handle the usb part of control module. A device for the above driver is created here, using the register address information to be used by the driver for powering on the PHY and for writing to the mailbox. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Tony ? Without this we won't have the control module driver. Looks OK to me, but please see my other reply regarding on you setting up some immutable branches to avoid pointless merge conflicts. Regards, Tony -- 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 v2 3/6] ARM: OMAP: USB: Add phy binding information
* Kishon Vijay Abraham I kis...@ti.com [130124 18:36]: This is w.r.t the changes in PHY library to support adding and getting multiple PHYs of the same type. In the new design, the binding information between the PHY and the USB controller should be specified in the platform specific initialization code. So it's been done here for OMAP platforms. This looks OK to me, but should be queued by Felipe in his minimal USB platform_data changes branch that I can pull in too to avoid pointless merge conflicts. Regards, Tony -- 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 v7 01/22] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
* Alan Stern st...@rowland.harvard.edu [130117 07:19]: On Thu, 17 Jan 2013, Roger Quadros wrote: Let's have a single platform data structure for the OMAP's High-Speed USB host subsystem instead of having 3 separate ones i.e. one for board data, one for USB Host (UHH) module and one for USB-TLL module. This makes the code much simpler and avoids creating multiple copies of platform data. CC: Alan Stern st...@rowland.harvard.edu Signed-off-by: Roger Quadros rog...@ti.com For the ehci-omap.c part: Acked-by: Alan Stern st...@rowland.harvard.edu If Samuel acks this patch, I can apply just this patch alone on v3.8-rc3 into an immutable branch omap-for-v3.9/board-usb so we all merge it in as needed. Regards, Tony -- 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 v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
* Roger Quadros rog...@ti.com [130117 03:34]:
We don't need multiple aliases for the OMAP USB host clocks and neither
the dummy clocks so remove them.
It's best that Paul queues this and the next patch as these clock alias
clean-up patches can be done separately. That way the dependency between
arch/arm/*omap* code is cut away as these files should be moved to live
under drivers/clk/omap.
Regards,
Tony
CC: Paul Walmsley p...@pwsan.com
CC: Rajendra Nayak rna...@ti.com
CC: Benoit Cousson b-cous...@ti.com
CC: Mike Turquette mturque...@linaro.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 6ef8758..b58ec96 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3291,8 +3291,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs_tll,usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
CLK(NULL, mmchs3_fck, mmchs3_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, mmchs2_fck, mmchs2_fck,CK_3XXX),
@@ -3329,8 +3327,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(usbhs_tll,usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, mmchs3_ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
@@ -3393,17 +3389,10 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(NULL, utmi_p1_gfclk,dummy_ck, CK_3XXX),
CLK(NULL, utmi_p2_gfclk,dummy_ck, CK_3XXX),
CLK(NULL, xclk60mhsp1_ck, dummy_ck, CK_3XXX),
CLK(NULL, xclk60mhsp2_ck, dummy_ck, CK_3XXX),
- CLK(NULL, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
- CLK(NULL, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_tll,usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_tll,usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(NULL, init_60m_fclk,dummy_ck, CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
--
1.7.4.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 v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
* Paul Walmsley p...@pwsan.com [130117 14:33]: On Thu, 17 Jan 2013, Felipe Balbi wrote: do you mean v3.9 ? It sounds like the other patches need to be merged first before these cleanups can be merged. So rather than adding a merge order dependency during 3.9, it seems best to queue the non-essential clock cleanup side for 3.10. How about let's do it in a late cleanup branch towards the end of the v3.9 merge window? Regards, Tony -- 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 01/14] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
* Roger Quadros rog...@ti.com [130114 03:31]: On 01/11/2013 08:13 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130111 01:43]: Tony, On 01/11/2013 01:45 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130110 08:54]: Let's have a single platform data structure for the OMAP's High-Speed USB host subsystem instead of having 3 separate ones i.e. one for board data, one for USB Host (UHH) module and one for USB-TLL module. This makes the code much simpler and avoids creating multiple copies of platform data. I can apply just this patch alone into an immutable branch that we all can merge in as needed as long as we have acks for the USB and MFD parts. Or does this one need to be changed based on Alan's comments on the EHCI lib related changes? This does not depend on EHCI lib based changes but it depends on the OMAP USB Host cleanup series posted earlier. Can we first apply just the minimal platform_data + board file + clock changes? We could, but I'll then have to make changes to the patches in the first series and re-post them. Do you want me to do that? Yes please. Otherwise we'll unnecessarily complicate the dependencies between arch/arm/*omap* code and the drivers. And we've certainly had enough of self-inflicted merge conflicts with the omap usb code already :) That way I can apply those to some immutable tree for everybody to use, and we cut off the dependency to the driver changes for the rest of the patches. And then I'm off the hook for the rest of the patches :) Or you could just ack this patch ;). The platform data is specific to USB host only :) Well it's not just this patch. It's the clock related patches in your earlier seriers that will conflict with any attempts to move the clock data to live under drivers/clk/omap where it needs to go. And the three patches at the end of this series to add platform data (which look fine), but will likely conflict with something else. Let's try do do these changes in a way where the dependencies are cut to minimum where possible. Regards, Tony -- 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 01/14] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
* Roger Quadros rog...@ti.com [130111 01:43]: Tony, On 01/11/2013 01:45 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130110 08:54]: Let's have a single platform data structure for the OMAP's High-Speed USB host subsystem instead of having 3 separate ones i.e. one for board data, one for USB Host (UHH) module and one for USB-TLL module. This makes the code much simpler and avoids creating multiple copies of platform data. I can apply just this patch alone into an immutable branch that we all can merge in as needed as long as we have acks for the USB and MFD parts. Or does this one need to be changed based on Alan's comments on the EHCI lib related changes? This does not depend on EHCI lib based changes but it depends on the OMAP USB Host cleanup series posted earlier. Can we first apply just the minimal platform_data + board file + clock changes? That way I can apply those to some immutable tree for everybody to use, and we cut off the dependency to the driver changes for the rest of the patches. And then I'm off the hook for the rest of the patches :) Tony -- 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 01/14] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
* Roger Quadros rog...@ti.com [130110 08:54]:
Let's have a single platform data structure for the OMAP's High-Speed
USB host subsystem instead of having 3 separate ones i.e. one for
board data, one for USB Host (UHH) module and one for USB-TLL module.
This makes the code much simpler and avoids creating multiple copies of
platform data.
I can apply just this patch alone into an immutable branch that
we all can merge in as needed as long as we have acks for the USB
and MFD parts.
Or does this one need to be changed based on Alan's comments
on the EHCI lib related changes?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-3630sdp.c|2 +-
arch/arm/mach-omap2/board-am3517crane.c|2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |4 +-
arch/arm/mach-omap2/board-omap3beagle.c|2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 +-
arch/arm/mach-omap2/board-zoom.c |2 +-
arch/arm/mach-omap2/usb-host.c | 30 +++---
arch/arm/mach-omap2/usb.h | 21 +
drivers/mfd/omap-usb-host.c| 46
drivers/mfd/omap-usb-tll.c |8 ++--
drivers/usb/host/ehci-omap.c |6 ++--
include/linux/platform_data/usb-omap.h | 26
22 files changed, 56 insertions(+), 115 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..46147c8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -424,7 +424,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 050aaa7..78b1724 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -53,7 +53,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 51b96a1..26f1916 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -40,7 +40,7 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static struct usbhs_omap_board_data usbhs_bdata __initdata = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index f81a303..c76725d 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -274,7 +274,7 @@ static __init void am3517_evm_mcbsp1_init(void)
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
}
-static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..cdf1d6e 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -418,7 +418,7 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct usbhs_omap_board_data usbhs_bdata __initdata = {
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
diff --git
Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
* Roger Quadros rog...@ti.com [121210 02:23]:
There is no such clock as utmi_p1_gfclk. It is only a clock selector
bit to select th the parent of usb_host_hs_utmi_p1_clk.
So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively.
CC: Paul Walmsley p...@pwsan.com
CC: Rajendra Nayak rna...@ti.com
CC: Benoit Cousson b-cous...@ti.com
CC: Mike Turquette mturque...@gmail.com
Paul, what about this patch? Looks like you've acked the other
clock patches in this series but not this one?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 -
arch/arm/mach-omap2/cclock44xx_data.c | 47
+++--
2 files changed, 33 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index bdf3948..5655414 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3392,8 +3392,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbhost_ick, usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(usbhs_omap, usbhost_ick, usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(NULL, utmi_p1_gfclk,dummy_ck, CK_3XXX),
- CLK(NULL, utmi_p2_gfclk,dummy_ck, CK_3XXX),
CLK(NULL, xclk60mhsp1_ck, dummy_ck, CK_3XXX),
CLK(NULL, xclk60mhsp2_ck, dummy_ck, CK_3XXX),
CLK(NULL, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index aa56c3e..74535fe 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1366,31 +1366,52 @@ static struct clk_hw_omap usb_host_fs_fck_hw = {
DEFINE_STRUCT_CLK(usb_host_fs_fck, usb_host_fs_fck_parent_names,
usb_host_fs_fck_ops);
+static const struct clk_ops utmi_clk_ops = {
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .is_enabled = omap2_dflt_clk_is_enabled,
+ .recalc_rate= omap2_clksel_recalc,
+ .get_parent = omap2_clksel_find_parent_index,
+ .set_parent = omap2_clksel_set_parent,
+};
+
static const char *utmi_p1_gfclk_parents[] = {
init_60m_fclk, xclk60mhsp1_ck,
};
-DEFINE_CLK_MUX(utmi_p1_gfclk, utmi_p1_gfclk_parents, NULL, 0x0,
-OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-OMAP4430_CLKSEL_UTMI_P1_SHIFT, OMAP4430_CLKSEL_UTMI_P1_WIDTH,
-0x0, NULL);
+static const struct clksel utmi_p1_clk_mux_sel[] = {
+ { .parent = init_60m_fclk, .rates = div_1_0_rates },
+ { .parent = xclk60mhsp1_ck, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
-DEFINE_CLK_GATE(usb_host_hs_utmi_p1_clk, utmi_p1_gfclk, utmi_p1_gfclk,
0x0,
+/* Merged utmi_p1_gfclk into usb_host_hs_utmi_p1_clk */
+DEFINE_CLK_OMAP_MUX_GATE(usb_host_hs_utmi_p1_clk, l3_init_clkdm,
+ utmi_p1_clk_mux_sel,
+ OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ OMAP4430_CLKSEL_UTMI_P1_MASK,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT, 0x0, NULL);
+ OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT, NULL,
+ utmi_p1_gfclk_parents, utmi_clk_ops);
static const char *utmi_p2_gfclk_parents[] = {
init_60m_fclk, xclk60mhsp2_ck,
};
-DEFINE_CLK_MUX(utmi_p2_gfclk, utmi_p2_gfclk_parents, NULL, 0x0,
-OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
-OMAP4430_CLKSEL_UTMI_P2_SHIFT, OMAP4430_CLKSEL_UTMI_P2_WIDTH,
-0x0, NULL);
+static const struct clksel utmi_p2_clk_mux_sel[] = {
+ { .parent = init_60m_fclk, .rates = div_1_0_rates },
+ { .parent = xclk60mhsp2_ck, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
-DEFINE_CLK_GATE(usb_host_hs_utmi_p2_clk, utmi_p2_gfclk, utmi_p2_gfclk,
0x0,
+/* Merged utmi_p2_gfclk into usb_host_hs_utmi_p2_clk */
+DEFINE_CLK_OMAP_MUX_GATE(usb_host_hs_utmi_p2_clk, l3_init_clkdm,
+ utmi_p2_clk_mux_sel,
+ OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ OMAP4430_CLKSEL_UTMI_P2_MASK,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT, 0x0, NULL);
+ OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT, NULL,
+ utmi_p2_gfclk_parents, utmi_clk_ops);
DEFINE_CLK_GATE(usb_host_hs_utmi_p3_clk, init_60m_fclk, init_60m_fclk,
0x0,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
@@ -1838,9 +1859,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart4_fck,uart4_fck,
CK_443X),
CLK(NULL,
Re: [PATCH v4 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
* Samuel Ortiz sa...@linux.intel.com [121213 16:57]: Hi Tony, On Thu, Dec 13, 2012 at 01:49:49PM -0800, Tony Lindgren wrote: Hi Samuel, * Roger Quadros rog...@ti.com [121210 02:23]: Instead of using cpu_is_omap..() macros in the device driver we rely on information provided in the platform data. The only information we need is whether the USB Host module has a single ULPI bypass control bit for all ports or individual bypass control bits for each port. OMAP3 REV2.1 and earlier have the former. I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h for omaps by -rc1 before more drivers start using it again. That is assuming nobody else is planning on merging this series for v3.8 presumably. This should go into 3.9, yes. OK looks like you have all the necessary acks except for one clock change. I replied to that one. Want to ack this one? Looks fine to me: Acked-by: Samuel Ortiz sa...@linux.intel.com Thanks, I'll queue that one and then after -rc1 hopefully you have all the necessary acks to queue this one via your mfd tree. Regards, Tony -- 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: MUSB-HDRC Gadget driving VBUS inappropriately
* Ian Coolidge iancooli...@gmail.com [121214 01:55]: Hi, We're using Linux 3.3 on DM3730 with TPS6595xx PMIC for an embedded product. For a particular board, we have musb-hdrc (RTL 1.4) configured in peripheral mode. We use the Ethernet gadget configured for cdc_eem to use Ethernet emulation over USB for this link, and the robustness of the link is mission-critical. To assure this, we have performed some massive reboot testing to ensure that this usb link reliably comes up. Hehehe I've never seen MUSB and mission critical in the same sentence before :) After working through an issue which required pulling in the following patch, - commit b1b552a69b8805e7e338074a9e8b670b4a795218 Author: Michael Grzeschik m.grzesc...@pengutronix.de Date: Wed Aug 8 11:48:10 2012 +0200 usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop - we find that with about a 2% chance, the gadget comes up in some kind of firmware failed state, driving VBUS. In this condition, we found that MUSB_DEVCTL_SESSION bit was set. I understand this to be indicative of MUSB thinking it is in host mode, which agrees with the driven VBUS. Further, in this state, I found that usually, there was one interrupt from twl4030_usb, but NO interrupts from musb-hdrc. So, as a hack, I cleared MUSB_DEVCTL_SESSION in omap2430.c in the notifier block from the VBUS interrupt. This appears to reduce the frequency of the problem -- I now always at least one instance of the musb-hdrc interrupt. However, sometimes, it looks like the MUSB PHY dies shortly thereafter. So, I don't think this hack is fully effective. I reviewed commits that post-date 3.3 in omap2430.c, musb_core.c, twl4030-usb.c, musb_gadget.c, and I couldn't find anything interesting -- it looks like mostly reorganization has taken place. We have also engaged TI to try to get some silicon errata from Mentor Graphics, and maybe a register manual for the MUSB HDRC IP, but this is slow going, and that has little guarantee of paying off anyways. Are there any ideas, or patches that anyone might suggest? Don't know if this is related, but it might. I've noticed and issu with MUSB host mode where MUSB with USB-A cable plugged in fails to come up properly in host mode. It seems to require replugging the USB cable to get it to work in host mode. To reproduce this issue: 1. Boot system with USB-A cable connected and some devices 2. Load g_ether or some gadget module and notice how the USB devices are not discovered, and reloading g_ether does not help. 3. Unplug the USB-A cable, plug in USB-B cable, then plug in USB-A cable again, and the devices are discovered. This one is annoying as it means that trying to use Panda with USB HID devices connected to the MUSB port does not discover them. And the reason to do that is to keep the EHCI ports free for other use naturally.. Regards, Tony -- 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 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
Hi Samuel,
* Roger Quadros rog...@ti.com [121210 02:23]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.
I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h
for omaps by -rc1 before more drivers start using it again.
That is assuming nobody else is planning on merging this series for
v3.8 presumably. Want to ack this one?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-host.c |4
drivers/mfd/omap-usb-host.c|2 +-
include/linux/platform_data/usb-omap.h |3 +++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..2e44e8a 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -508,6 +508,10 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
+
+ if (omap_rev() = OMAP3430_REV_ES2_1)
+ usbhs_data.single_ulpi_bypass = true;
+
} else if (cpu_is_omap44xx()) {
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index cebfe0a..fe7906b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -384,7 +384,7 @@ static void omap_usbhs_init(struct device *dev)
reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
/* Bypass the TLL module for PHY mode operation */
- if (cpu_is_omap3430() (omap_rev() = OMAP3430_REV_ES2_1)) {
+ if (pdata-single_ulpi_bypass) {
dev_dbg(dev, OMAP3 ES version = ES2.1\n);
if (is_ehci_phy_mode(pdata-port_mode[0]) ||
is_ehci_phy_mode(pdata-port_mode[1]) ||
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..ef65b67 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -59,6 +59,9 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
+
+ /* OMAP3 = ES2.1 have a single ulpi bypass control bit */
+ unsignedsingle_ulpi_bypass:1;
};
/*-*/
--
1.7.4.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 v3 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
* Roger Quadros rog...@ti.com [121204 06:15]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.
Thanks for moving this one earlier in the series. Looks like
you're missing Samuel as the MFD maintainer from your cc.
You should resend again with Samuel Ortiz sa...@linux.intel.com
added.
Maybe check the patches in this series with scripts/get_maintainer.pl
to see who all should be cc:ed?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-host.c |4
drivers/mfd/omap-usb-host.c|2 +-
include/linux/platform_data/usb-omap.h |3 +++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..2e44e8a 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -508,6 +508,10 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
+
+ if (omap_rev() = OMAP3430_REV_ES2_1)
+ usbhs_data.single_ulpi_bypass = true;
+
} else if (cpu_is_omap44xx()) {
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index cebfe0a..fe7906b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -384,7 +384,7 @@ static void omap_usbhs_init(struct device *dev)
reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
/* Bypass the TLL module for PHY mode operation */
- if (cpu_is_omap3430() (omap_rev() = OMAP3430_REV_ES2_1)) {
+ if (pdata-single_ulpi_bypass) {
dev_dbg(dev, OMAP3 ES version = ES2.1\n);
if (is_ehci_phy_mode(pdata-port_mode[0]) ||
is_ehci_phy_mode(pdata-port_mode[1]) ||
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..ef65b67 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -59,6 +59,9 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
+
+ /* OMAP3 = ES2.1 have a single ulpi bypass control bit */
+ unsignedsingle_ulpi_bypass:1;
};
/*-*/
--
1.7.4.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 v2 13/22] mfd: omap-usb-host: override number of ports from platform data
* Roger Quadros rog...@ti.com [121128 06:52]:
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device tree) instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/usb-host.c|1 +
arch/arm/plat-omap/include/plat/usb.h |2 +
drivers/mfd/omap-usb-host.c | 34
3 files changed, 24 insertions(+), 13 deletions(-)
Note that plat/usb.h is now include/linux/platform_data/usb-omap.h
in linux next so you need to coordinate with that.
For the arch/arm/*omap*/* parts:
Acked-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 3c43449..eb85528 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -504,6 +504,7 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
ohci_data.es2_compatibility = pdata-es2_compatibility;
usbhs_data.ehci_data = ehci_data;
usbhs_data.ohci_data = ohci_data;
+ usbhs_data.nports = pdata-nports;
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 87ee140..6b618a1 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -27,6 +27,7 @@ enum usbhs_omap_port_mode {
};
struct usbhs_omap_board_data {
+ int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
/* have to be valid if phy_reset is true and portx is in phy mode */
@@ -59,6 +60,7 @@ struct ohci_hcd_omap_platform_data {
};
struct usbhs_omap_platform_data {
+ int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
struct ehci_hcd_omap_platform_data *ehci_data;
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 87b574b..fda235a 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -495,19 +495,27 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
*/
pm_runtime_put_sync(dev);
- switch (omap-usbhs_rev) {
- case OMAP_USBHS_REV1:
- omap-nports = 3;
- break;
- case OMAP_USBHS_REV2:
- omap-nports = 2;
- break;
- default:
- omap-nports = OMAP3_HS_USB_PORTS;
- dev_dbg(dev,
- USB HOST Rev : 0x%d not recognized, assuming %d ports\n,
-omap-usbhs_rev, omap-nports);
- break;
+ /*
+ * If platform data contains nports then use that
+ * else make out number of ports from USBHS revision
+ */
+ if (pdata-nports) {
+ omap-nports = pdata-nports;
+ } else {
+ switch (omap-usbhs_rev) {
+ case OMAP_USBHS_REV1:
+ omap-nports = 3;
+ break;
+ case OMAP_USBHS_REV2:
+ omap-nports = 2;
+ break;
+ default:
+ omap-nports = OMAP3_HS_USB_PORTS;
+ dev_dbg(dev,
+ USB HOST Rev:0x%d not recognized, assuming %d ports\n,
+ omap-usbhs_rev, omap-nports);
+ break;
+ }
}
for (i = 0; i omap-nports; i++)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v2 18/22] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
* Roger Quadros rog...@ti.com [121128 06:51]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.
Does this depend on the other patches in this series? If not,
this should be applied first as this is blocking omap multiplatform
development. And this too needs to be updated for the new location
of usb-omap.h in linux next.
Other than that:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Roger Quadros rog...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-host.c|4
arch/arm/plat-omap/include/plat/usb.h |3 +++
drivers/mfd/omap-usb-host.c |3 +--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index eb85528..455b135 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -509,6 +509,10 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
+
+ if (omap_rev() = OMAP3430_REV_ES2_1)
+ usbhs_data.single_ulpi_bypass = true;
+
} else if (cpu_is_omap44xx()) {
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index 6b618a1..3f2336a 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -65,6 +65,9 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
+
+ /* OMAP3 = ES2.1 have a single ulpi bypass control bit */
+ unsignedsingle_ulpi_bypass:1;
};
struct usbtll_omap_platform_data {
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 62e1f21..aaf272d 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -24,7 +24,6 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/gpio.h
-#include plat/cpu.h
#include plat/usb.h
#include linux/pm_runtime.h
@@ -400,7 +399,7 @@ static void omap_usbhs_init(struct device *dev)
reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
/* Bypass the TLL module for PHY mode operation */
- if (cpu_is_omap3430() (omap_rev() = OMAP3430_REV_ES2_1)) {
+ if (pdata-single_ulpi_bypass) {
dev_dbg(dev, OMAP3 ES version = ES2.1\n);
if (is_ehci_phy_mode(pdata-port_mode[0]) ||
is_ehci_phy_mode(pdata-port_mode[1]) ||
--
1.7.4.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 00/16] OMAP USB Host cleanup
Hi Roger, * Kevin Hilman khil...@deeprootsystems.com [121119 15:24]: Roger Quadros rog...@ti.com writes: Kevin, On 11/16/2012 10:08 PM, Kevin Hilman wrote: Roger Quadros rog...@ti.com writes: Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) - Save power on Panda when EHCI driver is not loaded. Seeing the clock changes/cleanups, I gave this a spin on OMAP3 (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it fixed up the problem where CORE does not hit retention in idle when USB host is enabled, even with no devices attached. Unfortunately, it didn't help. :( oh that's bad. But this series wasn't meant to fix that ;). Oh, sorry. Yeah, I didn't mean this as a nak. Just an opportunity to complain to the maintainers that a long-standing issue needs to be addressed. It seems that drivers/mfd/omap-usb-host.c is one of the last users of cpu_is_omap macros blocking enabling ARM multiplatform support for omap2+. Please fix that ASAP as early as possible in this patch series to remove the dependencies between core omap code development and driver development. Basically you need to remove #include plat/cpu.h and pass the revision information in platform data (and device tree compatible flag when that is supported). Regards, Tony -- 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: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Felipe Balbi ba...@ti.com [121106 03:40]: Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz min...@mina86.com I need more Acks here. Only got one from Nicolas. Anyone else ? For omaps: Acked-by: Tony Lindgren t...@atomide.com -- 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: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Felipe Balbi ba...@ti.com [121106 12:40]: Hi, On Tue, Nov 06, 2012 at 10:42:27AM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121106 10:41]: * Felipe Balbi ba...@ti.com [121106 03:40]: Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz min...@mina86.com I need more Acks here. Only got one from Nicolas. Anyone else ? For omaps: Acked-by: Tony Lindgren t...@atomide.com Heh I guess no omap changes there, so probably not worth adding then. omap1 is old, but it's still omap :-) arch/arm/configs/omap1_defconfig |3 +-- Oh OK so it was not a spurious ack after all :) Tony -- 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: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree node Adaptation
* Keshava Munegowda keshava_mgo...@ti.com [121031 07:29]:
The USB2 Host device node is extracted and used in the probe
of the driver to initialize the usb ports and controller. The
platform specific initialization is also performed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 -
drivers/mfd/omap-usb-host.c| 163
+++-
include/linux/platform_data/usb-omap.h | 19 +++-
3 files changed, 133 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..239c175 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -502,8 +502,6 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
}
ehci_data.phy_reset = pdata-phy_reset;
ohci_data.es2_compatibility = pdata-es2_compatibility;
- usbhs_data.ehci_data = ehci_data;
- usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
Just checking.. Have you tested that these patches also
still work without device tree?
Regards,
Tony
--
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 1/2] ARM: OMAP2+: Introduce local usb.h
Let's move what we can from plat/usb.h to the local usb.h for ARM common zImage support. This is needed so we can remove plat/usb.h for ARM common zImage support. Cc: Felipe Balbi ba...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Partha Basak part...@india.ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: linux-usb@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap1/clock.c |1 arch/arm/mach-omap2/board-2430sdp.c |1 arch/arm/mach-omap2/board-3430sdp.c |1 arch/arm/mach-omap2/board-3630sdp.c |1 arch/arm/mach-omap2/board-4430sdp.c |1 arch/arm/mach-omap2/board-am3517crane.c |1 arch/arm/mach-omap2/board-am3517evm.c|1 arch/arm/mach-omap2/board-cm-t35.c |1 arch/arm/mach-omap2/board-cm-t3517.c |1 arch/arm/mach-omap2/board-devkit8000.c |1 arch/arm/mach-omap2/board-igep0020.c |1 arch/arm/mach-omap2/board-ldp.c |1 arch/arm/mach-omap2/board-omap3beagle.c |1 arch/arm/mach-omap2/board-omap3evm.c |1 arch/arm/mach-omap2/board-omap3logic.c |1 arch/arm/mach-omap2/board-omap3pandora.c |1 arch/arm/mach-omap2/board-omap3stalker.c |1 arch/arm/mach-omap2/board-omap3touchbook.c |1 arch/arm/mach-omap2/board-omap4panda.c |1 arch/arm/mach-omap2/board-overo.c|1 arch/arm/mach-omap2/board-rm680.c|1 arch/arm/mach-omap2/board-rx51.c |1 arch/arm/mach-omap2/board-ti8168evm.c|1 arch/arm/mach-omap2/board-zoom-peripherals.c |1 arch/arm/mach-omap2/board-zoom.c |1 arch/arm/mach-omap2/common.h |2 arch/arm/mach-omap2/omap_phy_internal.c |4 - arch/arm/mach-omap2/twl-common.c |1 arch/arm/mach-omap2/usb-host.c |2 arch/arm/mach-omap2/usb-musb.c |2 arch/arm/mach-omap2/usb.h| 82 arch/arm/plat-omap/include/plat/usb.h| 106 -- 32 files changed, 88 insertions(+), 136 deletions(-) create mode 100644 arch/arm/mach-omap2/usb.h diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c index 638f407..1e49eda 100644 --- a/arch/arm/mach-omap1/clock.c +++ b/arch/arm/mach-omap1/clock.c @@ -22,7 +22,6 @@ #include asm/mach-types.h #include plat/cpu.h -#include plat/usb.h #include plat/clock.h #include plat/sram.h #include plat/clkdev_omap.h diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 95b384d..df561ad 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -35,7 +35,6 @@ #include common.h #include plat/gpmc.h -#include plat/usb.h #include gpmc-smc91x.h #include video/omapdss.h diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 96cd369..14c07ee 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -30,7 +30,6 @@ #include asm/mach/arch.h #include asm/mach/map.h -#include plat/usb.h #include common.h #include plat/dma.h #include plat/gpmc.h diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c index fc224ad..f8e6288 100644 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -18,7 +18,6 @@ #include common.h #include gpmc-smc91x.h -#include plat/usb.h #include mach/board-zoom.h diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 3669c12..5700fc5 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -34,7 +34,6 @@ #include asm/mach/map.h #include common.h -#include plat/usb.h #include plat/mmc.h #include omap4-keypad.h #include video/omapdss.h diff --git a/arch/arm/mach-omap2/board-am3517crane.c b/arch/arm/mach-omap2/board-am3517crane.c index 318fead..603503c 100644 --- a/arch/arm/mach-omap2/board-am3517crane.c +++ b/arch/arm/mach-omap2/board-am3517crane.c @@ -26,7 +26,6 @@ #include asm/mach/map.h #include common.h -#include plat/usb.h #include am35xx-emac.h #include mux.h diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index e162897..0dbeb77 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -33,7 +33,6 @@ #include asm/mach/map.h #include common.h -#include plat/usb.h #include video/omapdss.h #include video/omap-panel-generic-dpi.h #include video/omap-panel-tfp410.h diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index 376d26e..435c7be 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm
[PATCH 2/2] ARM: OMAP: move OMAP USB platform data to linux/platform_data/omap-usb.h
From: Felipe Balbi ba...@ti.com In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to linux/platform_data/omap-usb.h and add a minimal drivers/mfd/usb-omap.h. Cc: Samuel Ortiz sa...@linux.intel.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Partha Basak part...@india.ti.com Cc: Keshava Munegowda keshava_mgo...@ti.com Cc: linux-usb@vger.kernel.org Signed-off-by: Felipe Balbi ba...@ti.com [t...@atomide.com: updated for local mfd/usb-omap.h] Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-4430sdp.c|1 + arch/arm/mach-omap2/board-am3517evm.c |1 + arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/board-omap4panda.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-ti8168evm.c |2 + arch/arm/mach-omap2/usb-tusb6010.c |1 + arch/arm/mach-omap2/usb.h |2 + drivers/mfd/omap-usb-host.c|5 +++ drivers/mfd/omap-usb-tll.c |2 + drivers/mfd/omap-usb.h |2 + drivers/usb/host/ehci-omap.c |3 +- drivers/usb/host/ohci-omap3.c |1 - drivers/usb/musb/am35x.c |3 +- drivers/usb/musb/musb_dsps.c |3 +- drivers/usb/musb/omap2430.h|2 + include/linux/platform_data/usb-omap.h | 47 ++-- 17 files changed, 48 insertions(+), 30 deletions(-) create mode 100644 drivers/mfd/omap-usb.h rename arch/arm/plat-omap/include/plat/usb.h = include/linux/platform_data/usb-omap.h (56%) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 5700fc5..52534ba 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -27,6 +27,7 @@ #include linux/leds.h #include linux/leds_pwm.h #include linux/platform_data/omap4-keypad.h +#include linux/usb/musb.h #include asm/hardware/gic.h #include asm/mach-types.h diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index 0dbeb77..96d6c5a 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -25,6 +25,7 @@ #include linux/can/platform/ti_hecc.h #include linux/davinci_emac.h #include linux/mmc/host.h +#include linux/usb/musb.h #include linux/platform_data/gpio-omap.h #include am35xx.h diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index 6e7e69b..a22a5b6 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -32,6 +32,7 @@ #include linux/spi/ads7846.h #include linux/i2c/twl.h #include linux/usb/otg.h +#include linux/usb/musb.h #include linux/usb/nop-usb-xceiv.h #include linux/smsc911x.h diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 74e39bb..3f0b92a 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -29,6 +29,7 @@ #include linux/regulator/machine.h #include linux/regulator/fixed.h #include linux/ti_wilink_st.h +#include linux/usb/musb.h #include linux/wl12xx.h #include linux/platform_data/omap-abe-twl6040.h diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c index 8c4d27e..c2f8f6c 100644 --- a/arch/arm/mach-omap2/board-rx51.c +++ b/arch/arm/mach-omap2/board-rx51.c @@ -17,6 +17,7 @@ #include linux/io.h #include linux/gpio.h #include linux/leds.h +#include linux/usb/musb.h #include linux/platform_data/spi-omap2-mcspi.h #include asm/mach-types.h diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-omap2/board-ti8168evm.c index 4977c77..5e672c2 100644 --- a/arch/arm/mach-omap2/board-ti8168evm.c +++ b/arch/arm/mach-omap2/board-ti8168evm.c @@ -14,6 +14,8 @@ */ #include linux/kernel.h #include linux/init.h +#include linux/platform_device.h +#include linux/usb/musb.h #include asm/mach-types.h #include asm/mach/arch.h diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c index 805bea6..5e24289 100644 --- a/arch/arm/mach-omap2/usb-tusb6010.c +++ b/arch/arm/mach-omap2/usb-tusb6010.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/gpio.h #include linux/export.h +#include linux/platform_data/usb-omap.h #include linux/usb/musb.h diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h index b2c4ff1..9b986ea 100644 --- a/arch/arm/mach-omap2/usb.h +++ b/arch/arm/mach-omap2/usb.h @@ -1,4 +1,4 @@ -#include plat/usb.h +#include linux/platform_data/usb-omap.h /* AM35x */ /* USB 2.0 PHY Control */ diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 23cec57..cebfe0a 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -26,9 +26,12 @@ #include linux/spinlock.h #include
Re: [PATCH 1/4] usb: phy: add a new driver for usb3 phy
* kishon kis...@ti.com [121012 02:10]:
Hi Tony,
On Thursday 11 October 2012 06:29 AM, Tony Lindgren wrote:
Hi,
* Kishon Vijay Abraham I kis...@ti.com [120919 04:32]:
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.
This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
You may be able to set up the control module register with one
of the following Linux standard frameworks:
1. Fixed regulator defined in mach-omap2/control.c
Is it control.c?
Hmm after looking into it more we're missing one piece of the puzzle
to handle SCM regulators, which is omap-scm-regulator.c :)
I'll do a minimal DT only version of that.
In this case the PHY driver can pick up the regulator by name.
Do you mean we have to define something like fixed_voltage_config
defined in board-4430sdp.c?
From whatever I could make out from regulator/fixed.c,
enabling/disabling of regulator is done using only gpio. I'm not
sure how we can use that to write to control module register.
Yes you're right, we're missing omap-scm-regulator.c, then it will
be trivial to select the regulator from DT like we have for the
twl-regulator.c.
+usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40,
+ 0x4a002370 0x4;
+};
And register 0x4a002370 here. Care to post some info what the
0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
on omap4, or does it have other bits there too?
It's CONTROL_PHY_POWER_USB register and it's structure looks like this.
31:22 USB_PWRCTL_CLK_FREQ
21:14 USB_PWRCTL_CLK_CMD
13:0 RESERVED
CLK_CMD takes values to power up/down the TX and RX in various combinations.
And CLK_FREQ takes values for clock configuration.
Oh, it's a clock. Then it would be best to set it up using the
common clock framework and have the clock registered by the
SCM core driver when those are available.
Maybe please just add a comment for that for later on?
Regards,
Tony
--
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 1/4] usb: phy: add a new driver for usb3 phy
Hi,
* Kishon Vijay Abraham I kis...@ti.com [120919 04:32]:
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.
This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
You may be able to set up the control module register with one
of the following Linux standard frameworks:
1. Fixed regulator defined in mach-omap2/control.c
In this case the PHY driver can pick up the regulator by name.
2. A mux mapped with pinctrl framework using pinctrl-single,bits
binding
And in this case the PHY driver can request the named pinctrl
states like enabled and disabled.
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58,
0x4a002300 0x4;
};
The comments also apply to the omap_usb2.c driver for
0x4a002300 above.
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb3
+ - reg : Address and length of the register set for the device. Also
+add the address of control module phy power register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40,
+ 0x4a002370 0x4;
+};
And register 0x4a002370 here. Care to post some info what the
0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
on omap4, or does it have other bits there too?
The advantage for using regulator fwk and pinctrl fwk is
that the regulator and mux can be children of the SCM
core driver when we have it. And no direct register tinkering
or omap specific custom exported functions are needed ;)
Regards,
Tony
--
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 1/1] musb : remove generic_interrupt and have all drivers define the isr on their own. Remove some unneeded CONFIG_SOC_OMAP_3430 instances
* Philippe De Swert philippedesw...@gmail.com [121004 10:00]: This patch is based on the discussion of a previous patch to fix an issue where the omap2430 musb driver is not working for N9/N950. Moving all the interrupt handling to the devices. Avoids inclusion of generic interrupt and breakage due to sometimes misleading CONFIG options. This makes sure usb always works if on of the subdrivers is chosen. Tested on Nokia N9/N950. Partially clean up CONFIG_SOC_OMAP3430 which is not necessary in the cases where I removed it. Also helps with the removal work of those options that Tony Lindgren predicted would happen at some point. Thanks looks OK to me: Acked-by: Tony Lindgren t...@atomide.com -- 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: MUSB regression in linux next at least for pandboard
* Tony Lindgren t...@atomide.com [121004 18:41]: Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Looks like the system eventually recovers from the EHCI issue after about fivew minutes or so of spamming the logs. It seems the ehci-omap errors are: [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule More data below. Regards, Tony ... [62927.200012] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62927.215606] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 25 [62927.220092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 22 [62927.225738] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62927.232238] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 17 [62927.236633] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62927.241119] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3 [62927.251098] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62927.258605] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 12 [62927.264343] usb 1-1.3.7.5: link qh8-0e01/ea5632c0 start 6 [1/2 us] [62927.274353] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 17 [62927.276092] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 24 [62927.280700] usb 1-1.3.7: clear tt 4 (0120) error -71 [62927.289245] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62927.292633] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62927.296356] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 26 [62927.302368] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 6 [62927.307098] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 24 [62927.308258] hid-generic 0003:047D:1020.000C: can't reset device, ehci-omap.0-1.3.7.4/input0, status -1 [62927.317230] usb 1-1.3.7: clear tt buffer port 5, a26 ep0 t00080248 [62927.322357] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62927.324981] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 5 [62927.330718] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 9 [62927.336364] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 20 [62927.348114] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 [62927.349090] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 5 [62927.356475] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 26 [62927.368469] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62927.372253] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62926.616607] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.622863] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 10 [62926.627746] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.628112] ehci-omap ehci-omap.0: devpath 1.3.7.4 ep0out 3strikes [62926.639404] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 14 [62926.643737] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.651123] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 15 [62926.655609] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 18 [62926.660125] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62926.667480] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 15 [62926.669982] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 1 [62926.680603] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3 [62926.686126] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 14 [62926.693237] usb 1-1.3.7: clear tt buffer port 5, a26 ep0 t00080248 [62926.694091] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 4 [62926.706359] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.709350] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 7 [62926.712554] usb 1-1.3.7: clear tt 4 (0120) error -71 [62926.714599] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 16 [62926.720855] ehci-omap ehci-omap.0: devpath 1.3.7.5 ep0out 3strikes [62926.729248] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.732238] usb 1-1.3.7: clear tt buffer port 4, a18 ep0 t00080248 [62926.736358] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes [62926.742736] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 9 [62926.755615] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 27 [62926.756744] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.763610] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62926.769226] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 29 [62926.780609] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2 [62926.782745] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 19 [62926.789978] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3
MUSB regression in linux next at least for pandboard
Hi Felipe Kishon, Looks like musb is broken at least on pandaboard es in current linux next while it works with v3.6: [1.933074] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [1.939422] unable to find transceiver of type USB2 PHYrouping on. Total pages: 251648 [1.945190] HS USB OTG: no transceiver configured [1.950134] musb-hdrc musb-hdrc.0: musb_init_controller failed with status -19 [1.958160] couldn't find an available UDC I do have CONFIG_OMAP_USB2 set. Note that we won't be able to flip omap4 over to be device tree only probably until v3.9 because of the bindings we're still missing from usability point of view. So this regression should be fixed. Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Regards, Tony -- 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 04/16] ARM: OMAP: Make plat/fpga.h local to arch/arm/plat-omap
There's no need to have this file in plat/fpga.h. We can
make it local to plat-omap replacing fpga_read/write
functions directly with readb/writeb as that's how
they are already defined in fpga.h.
Note that 2420 based H4 is also using the fpga, so let's
keep the led support around in plat-omap until we flip
over mach-omap2 to device tree.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: linux-fb...@vger.kernel.org
Cc: Felipe Balbi ba...@ti.com
Cc: linux-usb@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-fsample.c |6 -
arch/arm/mach-omap1/board-innovator.c | 26 ++--
arch/arm/mach-omap1/board-perseus2.c|6 -
arch/arm/mach-omap1/common.h|1
arch/arm/mach-omap1/fpga.c |2
arch/arm/mach-omap1/include/mach/omap1510.h | 113
arch/arm/mach-omap1/serial.c|1
arch/arm/plat-omap/debug-leds.c |2
arch/arm/plat-omap/fpga.h | 74 ++
arch/arm/plat-omap/include/plat/fpga.h | 193 ---
drivers/usb/host/ohci-omap.c|5 -
drivers/video/omap/lcd_inn1510.c|7 +
12 files changed, 216 insertions(+), 220 deletions(-)
create mode 100644 arch/arm/plat-omap/fpga.h
delete mode 100644 arch/arm/plat-omap/include/plat/fpga.h
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 4b6de70..6f496df 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -30,7 +30,7 @@
#include plat/tc.h
#include mach/mux.h
#include mach/flash.h
-#include plat/fpga.h
+#include ../plat-omap/fpga.h
#include linux/platform_data/keypad-omap.h
#include mach/hardware.h
@@ -123,9 +123,9 @@ static struct resource smc91x_resources[] = {
static void __init fsample_init_smc91x(void)
{
- fpga_write(1, H2P2_DBG_FPGA_LAN_RESET);
+ __raw_writeb(1, H2P2_DBG_FPGA_LAN_RESET);
mdelay(50);
- fpga_write(fpga_read(H2P2_DBG_FPGA_LAN_RESET) ~1,
+ __raw_writeb(__raw_readb(H2P2_DBG_FPGA_LAN_RESET) ~1,
H2P2_DBG_FPGA_LAN_RESET);
mdelay(50);
}
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index db5f7d2..5804da7 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -33,7 +33,7 @@
#include mach/mux.h
#include mach/flash.h
-#include plat/fpga.h
+#include ../plat-omap/fpga.h
#include plat/tc.h
#include linux/platform_data/keypad-omap.h
#include plat/mmc.h
@@ -215,7 +215,7 @@ static struct platform_device *innovator1510_devices[]
__initdata = {
static int innovator_get_pendown_state(void)
{
- return !(fpga_read(OMAP1510_FPGA_TOUCHSCREEN) (1 5));
+ return !(__raw_readb(OMAP1510_FPGA_TOUCHSCREEN) (1 5));
}
static const struct ads7846_platform_data innovator1510_ts_info = {
@@ -279,7 +279,7 @@ static struct platform_device *innovator1610_devices[]
__initdata = {
static void __init innovator_init_smc91x(void)
{
if (cpu_is_omap1510()) {
- fpga_write(fpga_read(OMAP1510_FPGA_RST) ~1,
+ __raw_writeb(__raw_readb(OMAP1510_FPGA_RST) ~1,
OMAP1510_FPGA_RST);
udelay(750);
} else {
@@ -335,10 +335,10 @@ static int mmc_set_power(struct device *dev, int slot,
int power_on,
int vdd)
{
if (power_on)
- fpga_write(fpga_read(OMAP1510_FPGA_POWER) | (1 3),
+ __raw_writeb(__raw_readb(OMAP1510_FPGA_POWER) | (1 3),
OMAP1510_FPGA_POWER);
else
- fpga_write(fpga_read(OMAP1510_FPGA_POWER) ~(1 3),
+ __raw_writeb(__raw_readb(OMAP1510_FPGA_POWER) ~(1 3),
OMAP1510_FPGA_POWER);
return 0;
@@ -390,14 +390,14 @@ static void __init innovator_init(void)
omap_cfg_reg(UART3_TX);
omap_cfg_reg(UART3_RX);
- reg = fpga_read(OMAP1510_FPGA_POWER);
+ reg = __raw_readb(OMAP1510_FPGA_POWER);
reg |= OMAP1510_FPGA_PCR_COM1_EN;
- fpga_write(reg, OMAP1510_FPGA_POWER);
+ __raw_writeb(reg, OMAP1510_FPGA_POWER);
udelay(10);
- reg = fpga_read(OMAP1510_FPGA_POWER);
+ reg = __raw_readb(OMAP1510_FPGA_POWER);
reg |= OMAP1510_FPGA_PCR_COM2_EN;
- fpga_write(reg, OMAP1510_FPGA_POWER);
+ __raw_writeb(reg, OMAP1510_FPGA_POWER);
udelay(10);
platform_add_devices(innovator1510_devices,
ARRAY_SIZE(innovator1510_devices));
@@ -437,6 +437,7 @@ static void __init innovator_init(void)
*/
static void __init innovator_map_io(void)
{
+#ifdef CONFIG_ARCH_OMAP15XX
Re: MUSB regression in linux next at least for pandboard
* Felipe Balbi ba...@ti.com [121004 11:04]: Hi, On Thu, Oct 04, 2012 at 10:31:08AM -0700, Tony Lindgren wrote: Hi Felipe Kishon, Looks like musb is broken at least on pandaboard es in current linux next while it works with v3.6: [1.933074] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [1.939422] unable to find transceiver of type USB2 PHYrouping on. Total pages: 251648 [1.945190] HS USB OTG: no transceiver configured [1.950134] musb-hdrc musb-hdrc.0: musb_init_controller failed with status -19 [1.958160] couldn't find an available UDC I do have CONFIG_OMAP_USB2 set. Note that we won't be able to flip omap4 over to be device tree only probably until v3.9 because of the bindings we're still missing from usability point of view. So this regression should be fixed. I see. Kishon, can you cook a patch adding platform_data until we actually move to DT-only for OMAP4 ? Also on the EHCI port, I've seen issues where unplugging the cable hangs kernel with an infinite loop. But that happens only occasionally, sorry does not seem to happen right now so no output to paste here. Or maybe this issue has already been fixed? Keshava, would you have time to look into this for this -rc cycle ? Also, can you guys also please do a patch to move plat/usb.h to include/linux/platform_data/usb-omap.h that only contains platform data? The init functions should be in local usb.h under arch/arm/*omap*/*. Then also please remove the cpu_is_omap usage from drivers/mfd/omap-usb-host.c if not done already. These are needed to make plat/cpu.h local to mach-omap* for the ARM common zImage support. Thanks, Tony -- 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 1/1] usb: Include generic_interrupt for OMAP2_PLUS
* Felipe Balbi ba...@ti.com [120924 06:08]: Hi, On Mon, Sep 24, 2012 at 03:54:22PM +0300, Philippe De Swert wrote: Hi, On 24/09/2012, Felipe Balbi ba...@ti.com wrote: SoB's mail doesn't From mail. Well still in the progress of migrating of my personal to work laptop. Since the patch does not seem correct the replacement will have matching addresses. /*-*/ #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \ -defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) +defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \ +defined(CONFIG_ARCH_OMAP2PLUS) Weird, how can you build OMAP2PLUS without SOC_OMAP ?? It seems entirely possible. I quickly tried to look if it got defined somewhere and it does not seem to be set anywhere. That is why I got the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig deeper to find out why SOC_OMAP is not set if it should be. From the .config I got (used menuconfig) # # TI OMAP2/3/4 Specific Features # CONFIG_ARCH_OMAP2PLUS_TYPICAL=y CONFIG_SOC_HAS_OMAP2_SDRC=y # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y # CONFIG_ARCH_OMAP4 is not set # CONFIG_SOC_OMAP5 is not set # CONFIG_SOC_OMAP3430 is not set # CONFIG_SOC_TI81XX is not set # CONFIG_SOC_AM33XX is not set CONFIG_OMAP_PACKAGE_CBB=y Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not get set (while it is not a 3430 but a 3630 I am using). Maybe CONFIG_ARCH_OMAP3 would have been a better choice then? that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all OMAP3 boards ? And another question: why don't we have a matching SOC_OMAP3530, SOC_OMAP3630 and so on ? ARCH_OMAP3 will probably eventually just disappear and be replaced with ARCH_OMAP2PLUS + SOC_. But there's no need to do it right now as most of that should be internal to arch/arm/mach-omap2 anyways. I would just set the driver to depend on ARCH_OMAP2PLUS, and rely on the platform_data and DT to do something if specified. That means that on 2420 musb should not probe unless tusb6010 in specified. It seems that things like fifo_mode and generic_interrupt can all be set during the probe based on the platform_data or DT passed information? Regards, Tony -- 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 03/29] ARM: OMAP1: Make plat/mux.h omap1 only
We are moving omap2+ to use the device tree based pinctrl-single.c
and will be removing the old mux framework. This will remove the
omap1 specific parts from plat-omap.
Cc: Felipe Balbi ba...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Richard Purdie rpur...@rpsys.net
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-usb@vger.kernel.org
Cc: linux-pcm...@lists.infradead.org
Cc: spi-devel-gene...@lists.sourceforge.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-ams-delta.c |2 -
arch/arm/mach-omap1/board-fsample.c |2 -
arch/arm/mach-omap1/board-generic.c |2 -
arch/arm/mach-omap1/board-h2.c|2 -
arch/arm/mach-omap1/board-h3.c|2 -
arch/arm/mach-omap1/board-innovator.c |2 -
arch/arm/mach-omap1/board-nokia770.c |2 -
arch/arm/mach-omap1/board-osk.c |2 -
arch/arm/mach-omap1/board-palmte.c|2 -
arch/arm/mach-omap1/board-palmtt.c|2 -
arch/arm/mach-omap1/board-palmz71.c |2 -
arch/arm/mach-omap1/board-perseus2.c |2 -
arch/arm/mach-omap1/board-sx1.c |2 -
arch/arm/mach-omap1/board-voiceblue.c |2 -
arch/arm/mach-omap1/devices.c |2 -
arch/arm/mach-omap1/i2c.c |2 -
arch/arm/mach-omap1/include/mach/mux.h|0
arch/arm/mach-omap1/io.c |2 -
arch/arm/mach-omap1/mcbsp.c |2 -
arch/arm/mach-omap1/mux.c | 58
arch/arm/mach-omap1/pm.c |2 -
arch/arm/mach-omap1/serial.c |2 -
arch/arm/mach-omap1/usb.c |2 -
arch/arm/mach-omap2/common.c |1
arch/arm/mach-omap2/hsmmc.c |1
arch/arm/plat-omap/Makefile |2 -
arch/arm/plat-omap/i2c.c |1
arch/arm/plat-omap/include/plat/omap-serial.h |2 -
arch/arm/plat-omap/mux.c | 90 -
drivers/pcmcia/omap_cf.c |2 -
drivers/spi/spi-omap-uwire.c |2 -
drivers/usb/host/ohci-omap.c |2 -
drivers/usb/musb/tusb6010_omap.c |1
drivers/usb/otg/isp1301_omap.c|2 -
drivers/video/backlight/omap1_bl.c|2 -
drivers/video/omap/lcd_osk.c |2 -
36 files changed, 84 insertions(+), 126 deletions(-)
rename arch/arm/{plat-omap/include/plat/mux.h =
mach-omap1/include/mach/mux.h} (100%)
delete mode 100644 arch/arm/plat-omap/mux.c
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index ab1e51f..05af063 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -37,7 +37,7 @@
#include plat/board-ams-delta.h
#include plat/keypad.h
-#include plat/mux.h
+#include mach/mux.h
#include mach/hardware.h
#include mach/ams-delta-fiq.h
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 6d98552..4b784f2 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -28,7 +28,7 @@
#include asm/mach/map.h
#include plat/tc.h
-#include plat/mux.h
+#include mach/mux.h
#include plat/flash.h
#include plat/fpga.h
#include plat/keypad.h
diff --git a/arch/arm/mach-omap1/board-generic.c
b/arch/arm/mach-omap1/board-generic.c
index 04b5fda..4ec579f 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -22,7 +22,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
+#include mach/mux.h
#include mach/usb.h
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 5560a40..124db5c 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -38,7 +38,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
+#include mach/mux.h
#include plat/dma.h
#include plat/tc.h
#include plat/irda.h
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index edc2487..a6f28a6 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -40,7 +40,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
+#include mach/mux.h
#include plat/tc.h
#include plat/keypad.h
#include plat/dma.h
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index f21c296..0eb9881 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -31,7 +31,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
* Felipe Balbi ba...@ti.com [120906 10:23]:
Hi,
On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control
module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.
Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.
this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.
Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks
ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.
It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)
Tony
--
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 v9 01/13] usb: musb: dsps: add phy control logic to glue
* Ravi Babu ravib...@ti.com [120831 04:10]: --- a/arch/arm/plat-omap/include/plat/usb.h +++ b/arch/arm/plat-omap/include/plat/usb.h @@ -95,7 +95,6 @@ extern void am35x_musb_reset(void); extern void am35x_musb_phy_power(u8 on); extern void am35x_musb_clear_irq(void); extern void am35x_set_mode(u8 musb_mode); -extern void ti81xx_musb_phy_power(u8 on); /* AM35x */ /* USB 2.0 PHY Control */ @@ -120,8 +119,8 @@ extern void ti81xx_musb_phy_power(u8 on); #define CONF2_DATPOL (1 1) /* TI81XX specific definitions */ -#define USBCTRL0 0x620 -#define USBSTAT0 0x624 +#define MUSB_USBSS_REV_816X 0x9 +#define MUSB_USBSS_REV_814X 0xb /* TI816X PHY controls bits */ #define TI816X_USBPHY0_NORMAL_MODE (1 0) This file needs to move to include/linux/platform_data/usb-omap.h as it's blocking the ARM single zImage changes so some coordination is required here. Felipe, can you do a minimal immutable branch with just one patch against v3.6-rc3 that move the header so I can pull in too? Regards, Tony -- 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: Infinite looping in omap2430.c USB driver
* NeilBrown ne...@suse.de [120706 15:44]:
Hello `./scripts/get_maintainer.pl -f drivers/usb/musb/omap2430.c`
omap2430_musb_set_vbus in omap2430.c contains:
while (musb_readb(musb-mregs, MUSB_DEVCTL) 0x80) {
cpu_relax();
if (time_after(jiffies, timeout)) {
dev_err(musb-controller,
configured as A device timeout);
ret = -EINVAL;
break;
}
}
having set
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
so it can busy-loop for up to 1 second. Probably not ideal, but if it works
I wouldn't complain.
The
if (int_usb MUSB_INTR_SESSREQ) {
branch of musb_stage0_irq() called from musb_interrupt (from
generic_interrupt) calls this:
if (musb-int_usb)
retval |= musb_stage0_irq(musb, musb-int_usb,
devctl, power);
so the busy loop can happen in an interrupt handler (not a threaded interrupt
handler), which is probably less ideal.
However this can be called with interrupt disabled, as happens at least
during resume when resume_irqs() calls:
raw_spin_lock_irqsave(desc-lock, flags);
__enable_irq(desc, irq, true);
raw_spin_unlock_irqrestore(desc-lock, flags);
and an interrupt is found to be IRQS_PENDING.
In this case interrupts are disabled so 'jiffies' never changes so this loop
can continue forever.
This happens on my (GTA04) phone fairly regularly - between 1 in 10 and 1 in
30 resumes. The musb-hdrc interrupt is pending and reports
[ 4957.624176] musb-hdrc musb-hdrc: ** IRQ peripheral usb0040 tx rx
'usb0040' is MUSB_INTR_SESSREQ. I think this is triggered by detecting a
voltage change on the USB ID pin - is that right? A short-to-earth would be
a request to switch to host mode, which is why it tries to enable VBUS.
Maybe there is some electrical noise which is being picked up?
I guess that could happen if the transceiver pins are floating during suspend?
In any case I get the interrupt despite nothing being plugged in, and the 0x80
bit of MUSB_DEVCTL never gets cleared.
As far as I remember, musb tries to be smart about changing to host mode,
and tries to do the session and vbus detection on it's own.. AFAIK, there's
nothing you can do until musb is done and detects the VBUS is not rising and
gives up. There are all kind of interrupt flag combinations trying to deal
with that mess, maybe you need to add yet another one?
I've added a simple loop counter which aborts the loop after 1000 loops -
this takes about 5 seconds, but includes some printks which probably slow it
down.
In 2 out of 2 cases, subsequent messages show that the hsmmc driver for the
uSD card that holds my root filesystem is messed up. It seems to be waiting
for a request that is never going to complete.
So maybe the hsmmc is causing the noise that triggers the musb issue.
I can send a patch which add a loop count if you like, but I suspect you can
come up with a much better approach.
Sounds like that loop should be fixed.
Regards,
Tony
--
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
