* Re:
2009-08-25 10:34 (unknown), Syed Rafiuddin
@ 2009-08-26 11:10 ` Ben Dooks
0 siblings, 0 replies; 16+ messages in thread
From: Ben Dooks @ 2009-08-26 11:10 UTC (permalink / raw)
To: Syed Rafiuddin; +Cc: soni.trilok, linux-omap, linux-arm-kernel, linux-input
Syed Rafiuddin wrote:
> From: Syed Rafiuddin <rafiuddin.syed@ti.com>
>
> This patch Adds Keypad support on OMAP4.And adds
> OMAP4 register addresses and configures them for OMAP4.
[SNIP]
Subjects are considered useful, please supply at-least semi
meaningful subject next time!
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE:
@ 2009-12-05 22:29 Irish News Center
0 siblings, 0 replies; 16+ messages in thread
From: Irish News Center @ 2009-12-05 22:29 UTC (permalink / raw)
You won 750,000gbp.Send:Name,Age,Country
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2010-01-20 19:47 (no subject) Ben Gamari
2010-01-21 0:04 ` Ben Dooks
@ 2010-01-21 0:04 ` Ben Dooks
2010-01-22 15:53 ` Re: Ben Gamari
2 siblings, 0 replies; 16+ messages in thread
From: Ben Dooks @ 2010-01-21 0:04 UTC (permalink / raw)
To: Ben Gamari
Cc: beagleboard, linux-omap, David Brownell, Eric Miao,
Michael Hennerich, Grant Likely,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]
Ben Gamari wrote:
> Bcc:
> Subject: GPIO chip select support in omap2_mcspi driver
>
> Hey,
>
> Recently I have been looking to use a BeagleBoard to drive several
> serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the
> BeagleBoard is severely limited by the number of SPI controllers it
> exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4
> with one). This is insufficient for our application and thus I have been
> investigating adding support to the mcspi driver for using GPIO lines as
> chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers.
>
> To this end, I have a few questions about how this support was
> implemented. First, it seems that the s3c24xx driver is built on the
> spi_bitbang driver, despite interfacing with a dedicated hardware SPI
> controller. What is the reason for this? Was this done specifically for
> the purpose of incorporating support for GPIO CS pins?
The spi_bitbang driver also has a really useful spi queue and workqueue
built into it, which is what the s3c24xx spi driver actually bothers to
use.
> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
> potential problem I can see with this is that omap2_mcspi_set_enable()
> is called to enable the channel before the force_cs() is called (in
> omap2_mcspi_work()). If I'm interpreting the documentation correctly,
> the enable bit starts the clocks, meaning that the chip will begin
> clocking out data before CS is brought high. I must be missing something
> here, no?
>
> For reference, I included a short list of relevant commits below, largely for
> my own benefit. I would greatly appreciate any feedback you might have.
>
> Thanks,
> - Ben
>
>
> pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686
> bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0
[-- Attachment #2: Type: text/plain, Size: 409 bytes --]
--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagleboard-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2010-01-20 19:47 (no subject) Ben Gamari
@ 2010-01-21 0:04 ` Ben Dooks
2010-01-21 0:04 ` Re: Ben Dooks
2010-01-22 15:53 ` Re: Ben Gamari
2 siblings, 0 replies; 16+ messages in thread
From: Ben Dooks @ 2010-01-21 0:04 UTC (permalink / raw)
To: Ben Gamari
Cc: beagleboard, linux-omap, David Brownell, Eric Miao,
Michael Hennerich, Grant Likely, spi-devel-general
Ben Gamari wrote:
> Bcc:
> Subject: GPIO chip select support in omap2_mcspi driver
>
> Hey,
>
> Recently I have been looking to use a BeagleBoard to drive several
> serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the
> BeagleBoard is severely limited by the number of SPI controllers it
> exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4
> with one). This is insufficient for our application and thus I have been
> investigating adding support to the mcspi driver for using GPIO lines as
> chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers.
>
> To this end, I have a few questions about how this support was
> implemented. First, it seems that the s3c24xx driver is built on the
> spi_bitbang driver, despite interfacing with a dedicated hardware SPI
> controller. What is the reason for this? Was this done specifically for
> the purpose of incorporating support for GPIO CS pins?
The spi_bitbang driver also has a really useful spi queue and workqueue
built into it, which is what the s3c24xx spi driver actually bothers to
use.
> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
> potential problem I can see with this is that omap2_mcspi_set_enable()
> is called to enable the channel before the force_cs() is called (in
> omap2_mcspi_work()). If I'm interpreting the documentation correctly,
> the enable bit starts the clocks, meaning that the chip will begin
> clocking out data before CS is brought high. I must be missing something
> here, no?
>
> For reference, I included a short list of relevant commits below, largely for
> my own benefit. I would greatly appreciate any feedback you might have.
>
> Thanks,
> - Ben
>
>
> pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686
> bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2010-01-20 19:47 (no subject) Ben Gamari
2010-01-21 0:04 ` Ben Dooks
2010-01-21 0:04 ` Re: Ben Dooks
@ 2010-01-22 15:53 ` Ben Gamari
2 siblings, 0 replies; 16+ messages in thread
From: Ben Gamari @ 2010-01-22 15:53 UTC (permalink / raw)
To: Ben Gamari
Cc: Ben Dooks, beagleboard, linux-omap, David Brownell, Eric Miao,
Michael Hennerich, Grant Likely, spi-devel-general
Excerpts from Ben Gamari's message of Wed Jan 20 14:47:23 -0500 2010:
> Bcc:
> Subject: GPIO chip select support in omap2_mcspi driver
>
> It seems like the rough idea is to add a cs_gpio field to the device
> struct (omap2_mcspi) and add the appropriate code to the
> omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The
> potential problem I can see with this is that omap2_mcspi_set_enable()
> is called to enable the channel before the force_cs() is called (in
> omap2_mcspi_work()). If I'm interpreting the documentation correctly,
> the enable bit starts the clocks, meaning that the chip will begin
> clocking out data before CS is brought high. I must be missing something
> here, no?
Could someone comment on how this ordering works? As I said, it seems to
me like the SPI controller starts sending before CS is brought high.
I would appreciate any feedback. Thanks!
- Ben
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE:
@ 2010-04-29 2:49 ABC MICROFINANCE BANK (NIG)
0 siblings, 0 replies; 16+ messages in thread
From: ABC MICROFINANCE BANK (NIG) @ 2010-04-29 2:49 UTC (permalink / raw)
We are currently offering loans with very low annual interest rate of 3% to any
part of the world To Apply: Fullname, Country, Age,Loan duration, amount
needed. If interested email us at: Email: abcmicrofinance@discuz.org
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE:
@ 2010-07-07 18:15 Coca Cola Promo
0 siblings, 0 replies; 16+ messages in thread
From: Coca Cola Promo @ 2010-07-07 18:15 UTC (permalink / raw)
One Million Pounds has been Awarded to in you in our COCA COLA
PROMO.Send your
Name..
Country..
Address..
Tel..
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2010-07-20 0:22 wins
0 siblings, 0 replies; 16+ messages in thread
From: wins @ 2010-07-20 0:22 UTC (permalink / raw)
Your e mail address was picked in the Chevron award 2010 which was held
july 15th 2010 , and you are to claim the
sum of $750,000.00 USD. that means you are one of the five(5) lucky
recipents . Your winning number is: (CT-222-6747,FGN/P-900-56).
You are to send us this informations
NAME IN FULL:
DELIVERY ADDRESS:
AGE:
NATIONALITY:
OCCUPATION:
PHONE:
SEX:
^ permalink raw reply [flat|nested] 16+ messages in thread
* (unknown),
@ 2011-02-16 11:53 Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
2011-02-16 12:00 ` Sergei Shtylyov
0 siblings, 2 replies; 16+ messages in thread
From: Hema HK @ 2011-02-16 11:53 UTC (permalink / raw)
To: linux-usb; +Cc: linux-omap, Hema HK
From: Hema HK <hemahk@ti.com
Moved all the board specific internal PHY functions out of usb_musb.c file
as this file is shared between the OMAP2+ and AM35xx platforms.
There exists a file which has the functions specific to internal PHY
used for OMAP4 platform. Moved all phy specific functions to this file
and passing these functions through board data in the board file.
Signed-off-by: Hema HK <hemahk@ti.com>
Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
+++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
@@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 500,
+ .set_phy_power = am35x_musb_phy_power,
+ .clear_irq = am35x_musb_clear_irq,
+ .set_mode = am35x_musb_set_mode,
+ .reset = am35x_musb_reset,
};
static __init void am3517_evm_musb_init(void)
Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -29,6 +29,7 @@
#include <linux/usb.h>
#include <plat/usb.h>
+#include "control.h"
/* OMAP control module register for UTMI PHY */
#define CONTROL_DEV_CONF 0x300
@@ -147,3 +148,95 @@ int omap4430_phy_exit(struct device *dev
return 0;
}
+
+void am35x_musb_reset(void)
+{
+ u32 regval;
+
+ /* Reset the musb interface */
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ regval |= AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval &= ~AM35XX_USBOTGSS_SW_RST;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+}
+
+void am35x_musb_phy_power(u8 on)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 devconf2;
+
+ if (on) {
+ /*
+ * Start the on-chip PHY and its PLL.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
+ devconf2 |= CONF2_PHY_PLLON;
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+
+ pr_info(KERN_INFO "Waiting for PHY clock good...\n");
+ while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
+ & CONF2_PHYCLKGD)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ pr_err(KERN_ERR "musb PHY clock good timed out\n");
+ break;
+ }
+ }
+ } else {
+ /*
+ * Power down the on-chip PHY.
+ */
+ devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_PHY_PLLON;
+ devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+ }
+}
+
+void am35x_musb_clear_irq(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval |= AM35XX_USBOTGSS_INT_CLR;
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am35x_musb_set_mode(u8 musb_mode)
+{
+ u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
+
+ devconf2 &= ~CONF2_OTGMODE;
+ switch (musb_mode) {
+#ifdef CONFIG_USB_MUSB_HDRC_HCD
+ case MUSB_HOST: /* Force VBUS valid, ID = 0 */
+ devconf2 |= CONF2_FORCE_HOST;
+ break;
+#endif
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
+ case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
+ devconf2 |= CONF2_FORCE_DEVICE;
+ break;
+#endif
+#ifdef CONFIG_USB_MUSB_OTG
+ case MUSB_OTG: /* Don't override the VBUS/ID comparators */
+ devconf2 |= CONF2_NO_OVERRIDE;
+ break;
+#endif
+ default:
+ pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
+ }
+
+ omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
+}
Index: linux-2.6/arch/arm/mach-omap2/usb-musb.c
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-2.6/arch/arm/mach-omap2/usb-musb.c
@@ -30,102 +30,9 @@
#include <mach/irqs.h>
#include <mach/am35xx.h>
#include <plat/usb.h>
-#include "control.h"
#if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
-static void am35x_musb_reset(void)
-{
- u32 regval;
-
- /* Reset the musb interface */
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-
- regval |= AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval &= ~AM35XX_USBOTGSS_SW_RST;
- omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
-}
-
-static void am35x_musb_phy_power(u8 on)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies(100);
- u32 devconf2;
-
- if (on) {
- /*
- * Start the on-chip PHY and its PLL.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~(CONF2_RESET | CONF2_PHYPWRDN | CONF2_OTGPWRDN);
- devconf2 |= CONF2_PHY_PLLON;
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-
- pr_info(KERN_INFO "Waiting for PHY clock good...\n");
- while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
- & CONF2_PHYCLKGD)) {
- cpu_relax();
-
- if (time_after(jiffies, timeout)) {
- pr_err(KERN_ERR "musb PHY clock good timed out\n");
- break;
- }
- }
- } else {
- /*
- * Power down the on-chip PHY.
- */
- devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_PHY_PLLON;
- devconf2 |= CONF2_PHYPWRDN | CONF2_OTGPWRDN;
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
- }
-}
-
-static void am35x_musb_clear_irq(void)
-{
- u32 regval;
-
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval |= AM35XX_USBOTGSS_INT_CLR;
- omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
- regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
-}
-
-static void am35x_musb_set_mode(u8 musb_mode)
-{
- u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
-
- devconf2 &= ~CONF2_OTGMODE;
- switch (musb_mode) {
-#ifdef CONFIG_USB_MUSB_HDRC_HCD
- case MUSB_HOST: /* Force VBUS valid, ID = 0 */
- devconf2 |= CONF2_FORCE_HOST;
- break;
-#endif
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
- case MUSB_PERIPHERAL: /* Force VBUS valid, ID = 1 */
- devconf2 |= CONF2_FORCE_DEVICE;
- break;
-#endif
-#ifdef CONFIG_USB_MUSB_OTG
- case MUSB_OTG: /* Don't override the VBUS/ID comparators */
- devconf2 |= CONF2_NO_OVERRIDE;
- break;
-#endif
- default:
- pr_info(KERN_INFO "Unsupported mode %u\n", musb_mode);
- }
-
- omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-}
-
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */
.flags = IORESOURCE_MEM,
@@ -189,10 +96,6 @@ void __init usb_musb_init(struct omap_mu
musb_device.name = "musb-am35x";
musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
musb_resources[1].start = INT_35XX_USBOTG_IRQ;
- board_data->set_phy_power = am35x_musb_phy_power;
- board_data->clear_irq = am35x_musb_clear_irq;
- board_data->set_mode = am35x_musb_set_mode;
- board_data->reset = am35x_musb_reset;
} else if (cpu_is_omap34xx()) {
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
} else if (cpu_is_omap44xx()) {
Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
===================================================================
--- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
@@ -91,6 +91,10 @@ extern int omap4430_phy_exit(struct devi
#endif
+extern void am35x_musb_reset(void);
+extern void am35x_musb_phy_power(u8 on);
+extern void am35x_musb_clear_irq(void);
+extern void am35x_musb_set_mode(u8 musb_mode);
/*
* FIXME correct answer depends on hmc_mode,
Index: linux-2.6/arch/arm/mach-omap2/Makefile
===================================================================
--- linux-2.6.orig/arch/arm/mach-omap2/Makefile
+++ linux-2.6/arch/arm/mach-omap2/Makefile
@@ -218,7 +218,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) += board
hsmmc.o \
omap_phy_internal.o
-obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
+obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
+ omap_phy_internal.o \
obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: your mail
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
@ 2011-02-16 11:55 ` Felipe Balbi
0 siblings, 0 replies; 16+ messages in thread
From: Felipe Balbi @ 2011-02-16 11:55 UTC (permalink / raw)
To: Hema HK; +Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
no subject ??
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2011-02-16 11:53 (unknown), Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
@ 2011-02-16 12:00 ` Sergei Shtylyov
[not found] ` <4D5BBC61.2000905-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
1 sibling, 1 reply; 16+ messages in thread
From: Sergei Shtylyov @ 2011-02-16 12:00 UTC (permalink / raw)
To: Hema HK; +Cc: linux-usb, linux-omap
On 16-02-2011 14:53, Hema HK wrote:
> From: Hema HK<hemahk@ti.com
> Moved all the board specific internal PHY functions out of usb_musb.c file
> as this file is shared between the OMAP2+ and AM35xx platforms.
> There exists a file which has the functions specific to internal PHY
> used for OMAP4 platform. Moved all phy specific functions to this file
> and passing these functions through board data in the board file.
> Signed-off-by: Hema HK<hemahk@ti.com>
> Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
> ===================================================================
> --- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
> +++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
> @@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
> .interface_type = MUSB_INTERFACE_ULPI,
> .mode = MUSB_OTG,
> .power = 500,
> + .set_phy_power = am35x_musb_phy_power,
> + .clear_irq = am35x_musb_clear_irq,
> + .set_mode = am35x_musb_set_mode,
> + .reset = am35x_musb_reset,
> };
>
> static __init void am3517_evm_musb_init(void)
[...]
> Index: linux-2.6/arch/arm/mach-omap2/Makefile
> ===================================================================
> --- linux-2.6.orig/arch/arm/mach-omap2/Makefile
> +++ linux-2.6/arch/arm/mach-omap2/Makefile
> @@ -218,7 +218,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) += board
> hsmmc.o \
> omap_phy_internal.o
>
> -obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
> +obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
> + omap_phy_internal.o \
>
> obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
Doesn't the above board needs board data modified as well?
WBR, Sergei
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE:
[not found] ` <4D5BBC61.2000905-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
@ 2011-02-16 12:17 ` Hema Kalliguddi
0 siblings, 0 replies; 16+ messages in thread
From: Hema Kalliguddi @ 2011-02-16 12:17 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
Hi,
>-----Original Message-----
>From: Sergei Shtylyov [mailto:sshtylyov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org]
>Sent: Wednesday, February 16, 2011 5:31 PM
>To: Hema HK
>Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: Re:
>
>On 16-02-2011 14:53, Hema HK wrote:
>
>> From: Hema HK<hemahk-l0cyMroinI0@public.gmane.org
>
>> Moved all the board specific internal PHY functions out of
>usb_musb.c file
>> as this file is shared between the OMAP2+ and AM35xx platforms.
>> There exists a file which has the functions specific to internal PHY
>> used for OMAP4 platform. Moved all phy specific functions to
>this file
>> and passing these functions through board data in the board file.
>
>> Signed-off-by: Hema HK<hemahk-l0cyMroinI0@public.gmane.org>
>
>> Index: linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
>> ===================================================================
>> --- linux-2.6.orig/arch/arm/mach-omap2/board-am3517evm.c
>> +++ linux-2.6/arch/arm/mach-omap2/board-am3517evm.c
>> @@ -409,6 +409,10 @@ static struct omap_musb_board_data musb_
>> .interface_type = MUSB_INTERFACE_ULPI,
>> .mode = MUSB_OTG,
>> .power = 500,
>> + .set_phy_power = am35x_musb_phy_power,
>> + .clear_irq = am35x_musb_clear_irq,
>> + .set_mode = am35x_musb_set_mode,
>> + .reset = am35x_musb_reset,
>> };
>>
>> static __init void am3517_evm_musb_init(void)
>[...]
>> Index: linux-2.6/arch/arm/mach-omap2/Makefile
>> ===================================================================
>> --- linux-2.6.orig/arch/arm/mach-omap2/Makefile
>> +++ linux-2.6/arch/arm/mach-omap2/Makefile
>> @@ -218,7 +218,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA) += board
>> hsmmc.o \
>> omap_phy_internal.o
>>
>> -obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
>> +obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \
>> + omap_phy_internal.o \
>>
>> obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o
>
> Doesn't the above board needs board data modified as well?
There is no "musb_board_data" for the above board file.
Regards,
Hema
>
>WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2011-12-13 2:58 Matt Shaw
0 siblings, 0 replies; 16+ messages in thread
From: Matt Shaw @ 2011-12-13 2:58 UTC (permalink / raw)
To: doshoes1990
https://docs.google.com/document/d/1-MgXERW0_TNnd0VK2caXYhDXtT58z1DJ0laAmJajrEs/edit
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
2012-07-31 23:52 (unknown), Ricardo Neri
@ 2012-07-31 23:58 ` Ricardo Neri
0 siblings, 0 replies; 16+ messages in thread
From: Ricardo Neri @ 2012-07-31 23:58 UTC (permalink / raw)
To: Ricardo Neri; +Cc: tomi.valkeinen, archit, s-guiriec, linux-omap
On 07/31/2012 06:52 PM, Ricardo Neri wrote:
> From 8b0f9153d078b7182efd604ef8525d50899ce1a3 Mon Sep 17 00:00:00 2001
> From: Ricardo Neri<ricardo.neri@ti.com>
> Date: Mon, 30 Jul 2012 17:54:59 -0500
> Subject: [PATCH v3] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
A small issue while sending the patch. I resubmitted correctly. Sorry
for the spam!
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2014-12-06 13:18 Quan Han
0 siblings, 0 replies; 16+ messages in thread
From: Quan Han @ 2014-12-06 13:18 UTC (permalink / raw)
To: Recipients
Hello,
Compliments of the day to you and I believe all is well. My name is Mr. Quan Han and I work in bank of china. I have a transaction that I believe will be of mutual benefits to both of us. It involves an investment portfolio worth(eight million,three hundred and seventy thousand USD) which I like to acquire with your help and assistance.
Yours sincerely,
Quan Han.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re:
@ 2020-02-06 2:24 Viviane Jose Pereira
0 siblings, 0 replies; 16+ messages in thread
From: Viviane Jose Pereira @ 2020-02-06 2:24 UTC (permalink / raw)
--
Hallo, ich entschuldige mich dafür, dass ich deine Privatsphäre gestört habe. Ich kontaktiere Sie für eine äußerst dringende und vertrauliche Angelegenheit.
Ihnen wurde eine Spende von 15.000.000,00 EUR angeboten Kontakt: cristtom063@gmail.com für weitere Informationen.
Dies ist keine Spam-Nachricht, sondern eine wichtige Mitteilung an Sie. Antworten Sie auf die obige E-Mail, um immer mehr Informationen über die Spende und den Erhalt von Geldern zu erhalten.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-02-06 2:31 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-16 11:53 (unknown), Hema HK
[not found] ` <1297857190-27449-1-git-send-email-hemahk-l0cyMroinI0@public.gmane.org>
2011-02-16 11:55 ` your mail Felipe Balbi
2011-02-16 12:00 ` Sergei Shtylyov
[not found] ` <4D5BBC61.2000905-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
2011-02-16 12:17 ` Hema Kalliguddi
-- strict thread matches above, loose matches on Subject: below --
2020-02-06 2:24 Viviane Jose Pereira
2014-12-06 13:18 Re: Quan Han
2012-07-31 23:52 (unknown), Ricardo Neri
2012-07-31 23:58 ` Ricardo Neri
2011-12-13 2:58 Re: Matt Shaw
2010-07-20 0:22 Re: wins
2010-07-07 18:15 Coca Cola Promo
2010-04-29 2:49 RE: ABC MICROFINANCE BANK (NIG)
2010-01-20 19:47 (no subject) Ben Gamari
2010-01-21 0:04 ` Ben Dooks
2010-01-21 0:04 ` Re: Ben Dooks
2010-01-22 15:53 ` Re: Ben Gamari
2009-12-05 22:29 Irish News Center
2009-08-25 10:34 (unknown), Syed Rafiuddin
2009-08-26 11:10 ` Ben Dooks
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).