[patch 14/17] usb: musb_hdrc build fixes
From: Greg KH
Date: Sat Oct 18 2008 - 15:08:31 EST
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx>
commit c767c1c6f1febbd1351cc152bba6e37889322d17 upstream
Minor musb_hdrc updates:
- so it'll build on DaVinci, given relevant platform updates;
* remove support for an un-shipped OTG prototype
* rely on gpiolib framework conversion for the I2C GPIOs
* the <asm/arch/hdrc_cnf.h> mechanism has been removed
- catch comments up to the recent removal of the per-SOC header
with the silicon configuration data;
- and remove two inappropriate "inline" declarations which
just bloat host side code.
There are still some more <asm/arch/XYZ.h> ==> <mach/XYZ.h>
changes needed in this driver, catching up to the relocation
of most of the include/asm-arm/arch-* contents.
Signed-off-by: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Felipe Balbi <felipe.balbi@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
---
drivers/usb/musb/Kconfig | 4 ----
drivers/usb/musb/cppi_dma.h | 4 ++--
drivers/usb/musb/davinci.c | 20 ++++----------------
drivers/usb/musb/musb_core.c | 8 ++++----
drivers/usb/musb/musb_host.c | 6 +++---
5 files changed, 13 insertions(+), 29 deletions(-)
--- a/drivers/usb/musb/cppi_dma.h
+++ b/drivers/usb/musb/cppi_dma.h
@@ -119,8 +119,8 @@ struct cppi {
void __iomem *mregs; /* Mentor regs */
void __iomem *tibase; /* TI/CPPI regs */
- struct cppi_channel tx[MUSB_C_NUM_EPT - 1];
- struct cppi_channel rx[MUSB_C_NUM_EPR - 1];
+ struct cppi_channel tx[4];
+ struct cppi_channel rx[4];
struct dma_pool *pool;
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -30,6 +30,7 @@
#include <linux/delay.h>
#include <linux/clk.h>
#include <linux/io.h>
+#include <linux/gpio.h>
#include <asm/arch/hardware.h>
#include <asm/arch/memory.h>
@@ -39,7 +40,7 @@
#include "musb_core.h"
#ifdef CONFIG_MACH_DAVINCI_EVM
-#include <asm/arch/i2c-client.h>
+#define GPIO_nVBUS_DRV 87
#endif
#include "davinci.h"
@@ -138,7 +139,6 @@ static int vbus_state = -1;
/* VBUS SWITCHING IS BOARD-SPECIFIC */
#ifdef CONFIG_MACH_DAVINCI_EVM
-#ifndef CONFIG_MACH_DAVINCI_EVM_OTG
/* I2C operations are always synchronous, and require a task context.
* With unloaded systems, using the shared workqueue seems to suffice
@@ -146,12 +146,11 @@ static int vbus_state = -1;
*/
static void evm_deferred_drvvbus(struct work_struct *ignored)
{
- davinci_i2c_expander_op(0x3a, USB_DRVVBUS, vbus_state);
+ gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
vbus_state = !vbus_state;
}
static DECLARE_WORK(evm_vbus_work, evm_deferred_drvvbus);
-#endif /* modified board */
#endif /* EVM */
static void davinci_source_power(struct musb *musb, int is_on, int immediate)
@@ -165,21 +164,10 @@ static void davinci_source_power(struct
#ifdef CONFIG_MACH_DAVINCI_EVM
if (machine_is_davinci_evm()) {
-#ifdef CONFIG_MACH_DAVINCI_EVM_OTG
- /* modified EVM board switching VBUS with GPIO(6) not I2C
- * NOTE: PINMUX0.RGB888 (bit23) must be clear
- */
- if (is_on)
- gpio_set(GPIO(6));
- else
- gpio_clear(GPIO(6));
- immediate = 1;
-#else
if (immediate)
- davinci_i2c_expander_op(0x3a, USB_DRVVBUS, !is_on);
+ gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
else
schedule_work(&evm_vbus_work);
-#endif
}
#endif
if (immediate)
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -33,10 +33,6 @@ config USB_MUSB_SOC
default y if ARCH_DAVINCI
default y if ARCH_OMAP2430
default y if ARCH_OMAP34XX
- help
- Use a static <asm/arch/hdrc_cnf.h> file to describe how the
- controller is configured (endpoints, mechanisms, etc) on the
- current iteration of a given system-on-chip.
comment "DaVinci 644x USB support"
depends on USB_MUSB_HDRC && ARCH_DAVINCI
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -82,9 +82,9 @@
/*
* This gets many kinds of configuration information:
* - Kconfig for everything user-configurable
- * - <asm/arch/hdrc_cnf.h> for SOC or family details
* - platform_device for addressing, irq, and platform_data
* - platform_data is mostly for board-specific informarion
+ * (plus recentrly, SOC or family details)
*
* Most of the conditional compilation will (someday) vanish.
*/
@@ -974,9 +974,9 @@ static void musb_shutdown(struct platfor
/*
* The silicon either has hard-wired endpoint configurations, or else
* "dynamic fifo" sizing. The driver has support for both, though at this
- * writing only the dynamic sizing is very well tested. We use normal
- * idioms to so both modes are compile-tested, but dead code elimination
- * leaves only the relevant one in the object file.
+ * writing only the dynamic sizing is very well tested. Since we switched
+ * away from compile-time hardware parameters, we can no longer rely on
+ * dead code elimination to leave only the relevant one in the object file.
*
* We don't currently use dynamic fifo setup capability to do anything
* more than selecting one of a bunch of predefined configurations.
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -108,7 +108,7 @@ static void musb_ep_program(struct musb
/*
* Clear TX fifo. Needed to avoid BABBLE errors.
*/
-static inline void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
+static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
{
void __iomem *epio = ep->regs;
u16 csr;
@@ -436,7 +436,7 @@ musb_advance_schedule(struct musb *musb,
}
}
-static inline u16 musb_h_flush_rxfifo(struct musb_hw_ep *hw_ep, u16 csr)
+static u16 musb_h_flush_rxfifo(struct musb_hw_ep *hw_ep, u16 csr)
{
/* we don't want fifo to fill itself again;
* ignore dma (various models),
@@ -1005,7 +1005,7 @@ static bool musb_h_ep0_continue(struct m
/*
* Handle default endpoint interrupt as host. Only called in IRQ time
- * from the LinuxIsr() interrupt service routine.
+ * from musb_interrupt().
*
* called with controller irqlocked
*/
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/