Re: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
Vaibhav,
I have some comments on this patch. Please address them.
> +
> +#include
Add a line here??
> +#include
> +#include
> +#include
> +#include
> +
> +#include "omap_voutlib.h"
> +#include "omap_voutdef.h"
> +
> +MODULE_AUTHOR("Texas Instruments");
> +MODULE_DESCRIPTION("OMAP Video for Linux Video out driver");
> +MODULE_LICENSE("GPL");
> +
> +
> +/* Driver Configuration macros */
> +#define VOUT_NAME "omap_vout"
> +
> +enum omap_vout_channels {
> + OMAP_VIDEO1 = 0,
Why do we have to initialize this to 0. It always start with a value 0
by default.
> + OMAP_VIDEO2,
> +};
> +
> +enum dma_channel_state {
> + DMA_CHAN_NOT_ALLOTED = 0,
Ditto.
> + DMA_CHAN_ALLOTED,
> +};
> +
> +#define QQVGA_WIDTH 160
> +#define QQVGA_HEIGHT 120
> +
> +/* Max Resolution supported by the driver */
> +#define VID_MAX_WIDTH 1280 /* Largest width */
> +#define VID_MAX_HEIGHT 720 /* Largest height */
> +
-
> +
> +module_param(debug, bool, S_IRUGO);
> +MODULE_PARM_DESC(debug, "Debug level (0-1)");
> +
> +/* Local Helper functions */
> +static void omap_vout_isr(void *arg, unsigned int irqstatus);
> +static void omap_vout_cleanup_device(struct omap_vout_device *vout);
> +
Is there a reason why you need these prototypes? I think we could
remove these prototypes and move the function ahead in the file before
it is called.
> +/* list of image formats supported by OMAP2 video pipelines */
> +const static struct v4l2_fmtdesc omap_formats[] = {
> + {
> + /* Note: V4L2 defines RGB565 as:
> + *
> + * Byte 0 Byte 1
> + * g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4 g3
> + *
> + * We interpret RGB565 as:
> + *
> + * Byte 0 Byte 1
> + * g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4 g3
> + */
> + .description = "RGB565, le",
> + .pixelformat = V4L2_PIX_FMT_RGB565,
> + },
> + {
> + /* Note: V4L2 defines RGB32 as: RGB-8-8-8-8 we use
> + * this for RGB24 unpack mode, the last 8 bits are ignored
> + * */
> + .description = "RGB32, le",
> + .pixelformat = V4L2_PIX_FMT_RGB32,
> + },
> + {
> + /* Note: V4L2 defines RGB24 as: RGB-8-8-8 we use
> + * this for RGB24 packed mode
> + *
> + */
> + .description = "RGB24, le",
> + .pixelformat = V4L2_PIX_FMT_RGB24,
> + },
> + {
> + .description = "YUYV (YUV 4:2:2), packed",
> + .pixelformat = V4L2_PIX_FMT_YUYV,
> + },
> + {
> + .description = "UYVY, packed",
> + .pixelformat = V4L2_PIX_FMT_UYVY,
> + },
> +};
> +
> +#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
> +
> +/*
> + * Allocate buffers
> + */
--
> +
> +/*
> + * omap_vout_uservirt_to_phys: This inline function is used to convert user
> + * space virtual address to physical address.
> + */
> +static u32 omap_vout_uservirt_to_phys(u32 virtp)
> +{
> + unsigned long physp = 0;
> + struct vm_area_struct *vma;
> + struct mm_struct *mm = current->mm;
> +
> + vma = find_vma(mm, virtp);
> + /* For kernel direct-mapped memory, take the easy way */
> + if (virtp >= PAGE_OFFSET) {
> + physp = virt_to_phys((void *) virtp);
> + } else if (vma && (vma->vm_flags & VM_IO)
> + && vma->vm_pgoff) {
> + /* this will catch, kernel-allocated,
> + mmaped-to-usermode addresses */
> + physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp -
> vma->vm_start);
> + } else {
> + /* otherwise, use get_user_pages() for general userland pages
> */
> + int res, nr_pages = 1;
> + struct page *pages;
> + down_read(¤t->mm->mmap_sem);
> +
> + res = get_user_pages(current, current->mm, virtp, nr_pages,
> + 1, 0, &pages, NULL);
> + up_read(¤t->mm->mmap_sem);
> +
> + if (res == nr_pages) {
> + physp = __pa(page_address(&pages[0]) +
> + (virtp & ~PAGE_MASK));
> + } else {
> + printk(KERN_WARNING VOUT_NAME
> + "get_user_pages failed\n");
> + return 0;
> + }
> + }
> +
> + return physp;
> +}
Shouldn't we remove omap_vout_uservirt_to_phys() and use videobuf_iolock()
instead as we have done in vpfe_capture.c?
-
> +
> +/*
> + * Convert
Re: [RFC][PATCH] ASoC: OMAP: Fix capture pointer handling for OMAP1510 to work correctly with recent ALSA PCM code
On Sun, Mar 28, 2010 at 10:29:29PM +0200, Janusz Krzysztofik wrote: > The patch reuses the method for software emulation of missing hardware > pointer, already implemented for playback on OMAP1510. It's possible that > event if a hardware pointer is available for capture on this machine, its > behaviour may be not compatible with what upper layer expects. Applied, thanks. -- 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
[PATCH RFC v2 1/5] omap3: add platform init code for OHCI driver
Add platform init code for the OMAP3 OHCI driver.
Also, mux-mode settings are taken care of depending on the
actual port mode selected
Signed-off-by: Anand Gadiyar
---
v2:
- Fix review comments from Felipe and Sergio
- Cover all combinations for mux-mode
- Add a new flag for 3430 es2.x compatibility
-- I've not yet figured out how usb-ehci.c can set this flag
-- so this is left to board files for now
arch/arm/mach-omap2/usb-ehci.c| 155 ++
arch/arm/plat-omap/include/plat/usb.h | 23 +
2 files changed, 178 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/usb-ehci.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/usb-ehci.c
+++ linux-2.6/arch/arm/mach-omap2/usb-ehci.c
@@ -236,3 +236,158 @@ void __init usb_ehci_init(const struct e
#endif /* CONFIG_USB_EHCI_HCD */
+#if defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
+
+static struct resource ohci_resources[] = {
+ {
+ .start = OMAP34XX_OHCI_BASE,
+ .end= OMAP34XX_OHCI_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP34XX_UHH_CONFIG_BASE,
+ .end= OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP34XX_USBTLL_BASE,
+ .end= OMAP34XX_USBTLL_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* general IRQ */
+ .start = INT_34XX_OHCI_IRQ,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static u64 ohci_dmamask = DMA_BIT_MASK(32);;
+
+static struct platform_device ohci_device = {
+ .name = "ohci-omap3",
+ .id = 0,
+ .dev = {
+ .dma_mask = &ohci_dmamask,
+ .coherent_dma_mask = 0x,
+ },
+ .num_resources = ARRAY_SIZE(ohci_resources),
+ .resource = ohci_resources,
+};
+
+static void setup_ohci_io_mux(const enum ohci_omap3_port_mode *port_mode)
+{
+ switch (port_mode[0]) {
+ case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
+ case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
+ omap_mux_init_signal("mm1_rxdp",
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal("mm1_rxdm",
+ OMAP_PIN_INPUT_PULLDOWN);
+ /* FALLTHROUGH */
+ case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
+ case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
+ omap_mux_init_signal("mm1_rxrcv",
+ OMAP_PIN_INPUT_PULLDOWN);
+ /* FALLTHROUGH */
+ case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
+ omap_mux_init_signal("mm1_txen_n", OMAP_PIN_OUTPUT);
+ /* FALLTHROUGH */
+ case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
+ omap_mux_init_signal("mm1_txse0",
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal("mm1_txdat",
+ OMAP_PIN_INPUT_PULLDOWN);
+ break;
+ case OMAP_OHCI_PORT_MODE_UNUSED:
+ /* FALLTHROUGH */
+ default:
+ break;
+ }
+ switch (port_mode[1]) {
+ case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
+ case OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM:
+ omap_mux_init_signal("mm2_rxdp",
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal("mm2_rxdm",
+ OMAP_PIN_INPUT_PULLDOWN);
+ /* FALLTHROUGH */
+ case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
+ case OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM:
+ omap_mux_init_signal("mm2_rxrcv",
+ OMAP_PIN_INPUT_PULLDOWN);
+ /* FALLTHROUGH */
+ case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0:
+ omap_mux_init_signal("mm2_txen_n", OMAP_PIN_OUTPUT);
+ /* FALLTHROUGH */
+ case OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM:
+ omap_mux_init_signal("mm2_txse0",
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal("mm2_txdat",
+ OMAP_PIN_INPUT_PULLDOWN);
+ break;
+ case OMAP_OHCI_PORT_MODE_UNUSED:
+ /* FALLTHROUGH */
+ default:
+ break;
+ }
+ switch (port_mode[2]) {
+ case OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM:
+ case OMAP_OHCI_PORT_MODE_TLL_6PI
[PATCH RFC v2 2/5] usb: ohci: introduce omap3 ohci-hcd driver
Add support for the OHCI controller present in OMAP3 and newer chips. The code is mostly based off the ehci-omap.c driver. Some of it is common to both drivers and will eventually need to be factored out to platform init files. In its current state, the driver cannot co-exist with the EHCI driver, and this will be fixed in later versions. The second one to be loaded will overwrite settings made by the other. For now, this driver should allow the few users of OMAP3 OHCI to get going. Signed-off-by: Anand Gadiyar --- v2: - rename some references from omap to omap3 - address review-comments by Sergio and Felipe. I think I've taken care of everything except the one from Sergio asking for removing extra blank lines in ohci_omap3_fslsmode(). I'll keep them around unless someone else wants them out. drivers/usb/host/ohci-omap3.c | 735 ++ 1 file changed, 735 insertions(+) Index: linux-2.6/drivers/usb/host/ohci-omap3.c === --- /dev/null +++ linux-2.6/drivers/usb/host/ohci-omap3.c @@ -0,0 +1,735 @@ +/* + * ohci-omap3.c - driver for OHCI on OMAP3 and later processors + * + * Bus Glue for OMAP3 USBHOST 3 port OHCI controller + * This controller is also used in later OMAPs and AM35x chips + * + * Copyright (C) 2007-2010 Texas Instruments, Inc. + * Author: Vikram Pandita + * Author: Anand Gadiyar + * + * Based on ehci-omap.c and some other ohci glue layers + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * TODO (last updated Mar 10th, 2010): + * - add kernel-doc + * - Factor out code common to EHCI to a separate file + * - Make EHCI and OHCI coexist together + * - needs newer silicon versions to actually work + * - the last one to be loaded currently steps on the other's toes + * - Add hooks for configuring transceivers, etc. at init/exit + * - Add aggressive clock-management code + */ + +#include +#include + +#include + +/* + * OMAP USBHOST Register addresses: VIRTUAL ADDRESSES + * Use ohci_omap_readl()/ohci_omap_writel() functions + */ + +/* TLL Register Set */ +#defineOMAP_USBTLL_REVISION(0x00) +#defineOMAP_USBTLL_SYSCONFIG (0x10) +#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) +#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) +#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) +#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) +#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 << 0) + +#defineOMAP_USBTLL_SYSSTATUS (0x14) +#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 << 0) + +#defineOMAP_USBTLL_IRQSTATUS (0x18) +#defineOMAP_USBTLL_IRQENABLE (0x1C) + +#defineOMAP_TLL_SHARED_CONF(0x30) +#defineOMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 << 6) +#defineOMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 << 5) +#defineOMAP_TLL_SHARED_CONF_USB_DIVRATION (1 << 2) +#defineOMAP_TLL_SHARED_CONF_FCLK_REQ (1 << 1) +#defineOMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 << 0) + +#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004 * num) +#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24 +#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 << 11) +#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 << 10) +#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 << 9) +#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 << 8) +#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1 << 1) +#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 << 0) + +#define OMAP_TLL_CHANNEL_COUNT 3 + +/* UHH Register Set */ +#defineOMAP_UHH_REVISION (0x00) +#defineOMAP_UHH_SYSCONFIG (0x10) +#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 << 12) +#defineOMAP_UHH_SYSCONFIG_CACTIVITY
[PATCH RFC 4/5] omap: 3430sdp: add ohci platform init
Add platform initialization code for OHCI on the 3430SDP.
Signed-off-by: Anand Gadiyar
---
arch/arm/mach-omap2/board-3430sdp.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-3430sdp.c
@@ -675,6 +675,12 @@ static const struct ehci_hcd_omap_platfo
.reset_gpio_port[2] = -EINVAL
};
+static const struct ohci_hcd_omap_platform_data ohci_pdata __initconst = {
+ .port_mode[0] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[1] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[2] = OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0,
+};
+
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -817,6 +823,7 @@ static void __init omap_3430sdp_init(voi
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(&ehci_pdata);
+ usb_ohci_init(&ohci_pdata);
}
static void __init omap_3430sdp_map_io(void)
--
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
[PATCH RFC 3/5] usb: ohci: Add Kconfig entries for ohci-omap3
On OMAP systems, we have two different of OHCI controllers. The legacy
one is present in OMAP1/2 chips, and the newer one comes bundled as
a companion to the EHCI controller on OMAP3 and newer chips.
We may have multi-omap configurations where OMAP2 and OMAP3
support may be enabled in the same kernel, and need a mechanism
to keep both drivers around.
This patch adds a Kconfig entry for each of these drivers.
Signed-off-by: Anand Gadiyar
---
I've only tested the omap3_defconfig on omap3 boards, and
don't have any old omap1/omap2 boards around.
I'd like feedback on the approach used here, as I'm not sure
if this scales well - maybe we need to revisit the way we do
this platform glue code in *-hcd.c.
drivers/usb/host/Kconfig| 15 +++
drivers/usb/host/ohci-hcd.c | 31 +--
2 files changed, 44 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/usb/host/ohci-hcd.c
===
--- linux-2.6.orig/drivers/usb/host/ohci-hcd.c
+++ linux-2.6/drivers/usb/host/ohci-hcd.c
@@ -1006,9 +1006,14 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVERohci_hcd_s3c2410_driver
#endif
-#ifdef CONFIG_ARCH_OMAP
+#ifdef CONFIG_USB_OHCI_HCD_OMAP1
#include "ohci-omap.c"
-#define PLATFORM_DRIVERohci_hcd_omap_driver
+#define OMAP1_PLATFORM_DRIVER ohci_hcd_omap_driver
+#endif
+
+#ifdef CONFIG_USB_OHCI_HCD_OMAP3
+#include "ohci-omap3.c"
+#define OMAP3_PLATFORM_DRIVER ohci_hcd_omap3_driver
#endif
#ifdef CONFIG_ARCH_LH7A404
@@ -1092,6 +1097,8 @@ MODULE_LICENSE ("GPL");
#if!defined(PCI_DRIVER) && \
!defined(PLATFORM_DRIVER) &&\
+ !defined(OMAP1_PLATFORM_DRIVER) && \
+ !defined(OMAP3_PLATFORM_DRIVER) && \
!defined(OF_PLATFORM_DRIVER) && \
!defined(SA_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
@@ -1133,6 +1140,18 @@ static int __init ohci_hcd_mod_init(void
goto error_platform;
#endif
+#ifdef OMAP1_PLATFORM_DRIVER
+ retval = platform_driver_register(&OMAP1_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_omap1_platform;
+#endif
+
+#ifdef OMAP3_PLATFORM_DRIVER
+ retval = platform_driver_register(&OMAP3_PLATFORM_DRIVER);
+ if (retval < 0)
+ goto error_omap3_platform;
+#endif
+
#ifdef OF_PLATFORM_DRIVER
retval = of_register_platform_driver(&OF_PLATFORM_DRIVER);
if (retval < 0)
@@ -1200,6 +1219,14 @@ static int __init ohci_hcd_mod_init(void
platform_driver_unregister(&PLATFORM_DRIVER);
error_platform:
#endif
+#ifdef OMAP1_PLATFORM_DRIVER
+ platform_driver_unregister(&OMAP1_PLATFORM_DRIVER);
+ error_omap1_platform:
+#endif
+#ifdef OMAP3_PLATFORM_DRIVER
+ platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
+ error_omap3_platform:
+#endif
#ifdef PS3_SYSTEM_BUS_DRIVER
ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
error_ps3:
Index: linux-2.6/drivers/usb/host/Kconfig
===
--- linux-2.6.orig/drivers/usb/host/Kconfig
+++ linux-2.6/drivers/usb/host/Kconfig
@@ -207,6 +207,21 @@ config USB_OHCI_HCD
To compile this driver as a module, choose M here: the
module will be called ohci-hcd.
+config USB_OHCI_HCD_OMAP1
+ bool "OHCI support for OMAP1/2 chips"
+ depends on USB_OHCI_HCD && (ARCH_OMAP1 || ARCH_OMAP2)
+ default y
+ ---help---
+ Enables support for the OHCI controller on OMAP1/2 chips.
+
+config USB_OHCI_HCD_OMAP3
+ bool "OHCI support for OMAP3 and later chips"
+ depends on USB_OHCI_HCD && (ARCH_OMAP3 || ARCH_OMAP4)
+ default y
+ ---help---
+ Enables support for the on-chip OHCI controller on
+ OMAP3 and later chips.
+
config USB_OHCI_HCD_PPC_SOC
bool "OHCI support for on-chip PPC USB controller"
depends on USB_OHCI_HCD && (STB03xxx || PPC_MPC52xx)
--
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
[PATCH RFC 5/5] omap: 3630sdp: add ohci platform init
Add platform initialization code for OHCI on the 3630SDP.
Signed-off-by: Anand Gadiyar
---
arch/arm/mach-omap2/board-3630sdp.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6/arch/arm/mach-omap2/board-3630sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-3630sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-3630sdp.c
@@ -66,6 +66,12 @@ static const struct ehci_hcd_omap_platfo
.reset_gpio_port[2] = -EINVAL
};
+static const struct ohci_hcd_omap_platform_data ohci_pdata __initconst = {
+ .port_mode[0] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[1] = OMAP_OHCI_PORT_MODE_UNUSED,
+ .port_mode[2] = OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0,
+};
+
static void __init omap_sdp_map_io(void)
{
omap2_set_globals_36xx();
@@ -100,6 +106,7 @@ static void __init omap_sdp_init(void)
board_smc91x_init();
enable_board_wakeup_source();
usb_ehci_init(&ehci_pdata);
+ usb_ohci_init(&ohci_pdata);
}
MACHINE_START(OMAP_3630SDP, "OMAP 3630SDP board")
--
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
[PATCH RFC v2 0/5] usb: ohci: introduce ohci-hcd driver for omap3
Hi all, This patch series adds the bus glue layer for the OHCI controller on OMAP3 and later chips. This controller is a companion to the EHCI controller on that chip, and some code is common between the two drivers. The driver has been sitting in internal trees for ages, and I've finally found time to clean it up and submit it. The older OMAP1 and OMAP2 chips had a different OHCI controller, which already has driver support in mainline. I don't have access to any boards with this old controller and haven't tested the old driver on those boards - not sure if it still works. (Also, I made some updates to Kconfig, and have not yet updated the defconfigs for those omap1/2 boards. I'll update them if the Kconfig changes are okay) This controller supports multiple interface modes. Only 2 of them (3-pin DAT/SE0 and 4-pin DP/DM PHY modes) have been tested with this driver. (However the only change for the other modes is one register setting for selecting the mode, and the padconf setting for the omap pads), so I expect it to work correctly. (Someone did offer to test the 6-pin mode. Still awaiting results...) If anyone has OMAP3 boards with an OHCI controller, please test. Thanks, Anand TODO: - Factor out code common to EHCI into a separate file -- Also, make sure EHCI and OHCI don't step over each other's toes - Add hooks for configuring transceivers, etc - Update defconfigs, if Kconfig changes are okay v2 changes: - Cover all padconf combinations for mux-mode for OMAP3 - Added a new flag for ES2.x compatibility to platform data to remove the check in the driver - rename some references from *omap* to *omap3* - Fix review comments from Felipe and Sergio -- 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
Re: [RFC/PATCHv2 1/4] gpiolib: introduce set_debounce method
On Wed, Mar 31, 2010 at 06:35:09PM +0300, Felipe Balbi wrote: > Few architectures, like OMAP, allow you to set > a debouncing time for the gpio before generating > the IRQ. Teach gpiolib about that. > > Signed-off-by: Felipe Balbi This looks useful - for what it's worth Acked-by: Mark Brown -- 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
[PATCH] dma: fix scope of errata i88 upto 3430ES1.0
DMA errata for special end of block programming is applicable
only for OMAP2430 & OMAP3430 ES1.0.
This patch does the necessary checks before the workaround
is applied. Tested on 3430 SDP
Signed-off-by: Thara Gopinath
Signed-off-by: Venkatraman S
---
arch/arm/plat-omap/dma.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..ef965ac 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1663,14 +1663,18 @@ int omap_stop_dma_chain_transfers(int chain_id)
channels = dma_linked_lch[chain_id].linked_dmach_q;
/*
-* DMA Errata:
-* Special programming model needed to disable DMA before end of block
+* DMA Errata: i88
+* Special programming model needed
+* to disable DMA before end of block
*/
sys_cf = dma_read(OCP_SYSCONFIG);
- l = sys_cf;
- /* Middle mode reg set no Standby */
- l &= ~((1 << 12)|(1 << 13));
- dma_write(l, OCP_SYSCONFIG);
+ if (cpu_is_omap2430() || (cpu_is_omap3430() &&
+ omap_rev() == OMAP3430_REV_ES1_0)) {
+ l = sys_cf;
+ /* Middle mode reg set no Standby */
+ l &= ~((1 << 12)|(1 << 13));
+ dma_write(l, OCP_SYSCONFIG);
+ }
for (i = 0; i < dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
@@ -1689,8 +1693,10 @@ int omap_stop_dma_chain_transfers(int chain_id)
/* Reset the Queue pointers */
OMAP_DMA_CHAIN_QINIT(chain_id);
- /* Errata - put in the old value */
- dma_write(sys_cf, OCP_SYSCONFIG);
+ /* Errata: put back the old value */
+ if (cpu_is_omap2430() || (cpu_is_omap3430() &&
+ omap_rev() == OMAP3430_REV_ES1_0))
+ dma_write(sys_cf, OCP_SYSCONFIG);
return 0;
}
--
1.6.3.3
--
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
Re: [RFC][PATCH] ASoC: OMAP: Fix capture pointer handling for OMAP1510 to work correctly with recent ALSA PCM code
Friday 02 April 2010 11:36:56 Mark Brown napisał(a): > On Fri, Apr 02, 2010 at 11:10:36AM +0300, Jarkko Nikula wrote: > > Janusz Krzysztofik wrote: > > > However, I still don't understand what happened to capture stream > > > handling that it stopped working for me. > > > > While I either don't understand the broke I think there's something in > > the capture DMA pointer which shows up only now. So I'm fine if you > > Janusz like to get your patch in and can have my ack. Or do you want to > > debug it further? > > > > Acked-by: Jarkko Nikula > > Personally I don't mind as long as you guys are happy - Janusz? I don't mind either :), please apply. Thanks, Janusz -- 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
Re: [PATCH] [PATCH v4 1/5] omap3: pm: fix for twl4030 script load
Hi Lesly,
On Wed, Mar 31, 2010 at 03:50:28PM +0530, Lesly A M wrote:
> This patch will fix the TRITON sleep/wakeup sequence.
>
> Since the function to populate the sleep script is getting called always
> irrespective of the flag "TWL4030_SLEEP_SCRIPT", other scripts data
> is getting over written by the sleep script.
>
> Also removing the order checking while loading the scripts,
> since the order doesn't matter. Only the values configured
> in the register, which is pointing to the starting address
> of each sequence should be correct.
Tony, I think it would make sense for this patchset to go through the
linux-omap tree.
If you agree, please add my:
Acked-by: Samuel Ortiz
to the patch below.
Cheers,
Samuel.
> Signed-off-by: Lesly A M
> Cc: Nishanth Menon
> Cc: David Derrick
> Cc: Samuel Ortiz
> ---
> drivers/mfd/twl4030-power.c |6 --
> 1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 7efa878..bd98733 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -423,7 +423,6 @@ static int __init load_twl4030_script(struct
> twl4030_script *tscript,
> u8 address)
> {
> int err;
> - static int order;
>
> /* Make sure the script isn't going beyond last valid address (0x3f) */
> if ((address + tscript->size) > END_OF_SCRIPT) {
> @@ -444,7 +443,6 @@ static int __init load_twl4030_script(struct
> twl4030_script *tscript,
> err = twl4030_config_wakeup12_sequence(address);
> if (err)
> goto out;
> - order = 1;
> }
> if (tscript->flags & TWL4030_WAKEUP3_SCRIPT) {
> err = twl4030_config_wakeup3_sequence(address);
> @@ -452,10 +450,6 @@ static int __init load_twl4030_script(struct
> twl4030_script *tscript,
> goto out;
> }
> if (tscript->flags & TWL4030_SLEEP_SCRIPT)
> - if (order)
> - pr_warning("TWL4030: Bad order of scripts (sleep "\
> - "script before wakeup) Leads to boot"\
> - "failure on some boards\n");
> err = twl4030_config_sleep_sequence(address);
> out:
> return err;
> --
> 1.6.0.4
>
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
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
Re: [RFC][PATCH] ASoC: OMAP: Fix capture pointer handling for OMAP1510 to work correctly with recent ALSA PCM code
On Fri, Apr 02, 2010 at 11:10:36AM +0300, Jarkko Nikula wrote: > Janusz Krzysztofik wrote: > > However, I still don't understand what happened to capture stream handling > > that it stopped working for me. > While I either don't understand the broke I think there's something in > the capture DMA pointer which shows up only now. So I'm fine if you > Janusz like to get your patch in and can have my ack. Or do you want to > debug it further? > Acked-by: Jarkko Nikula Personally I don't mind as long as you guys are happy - Janusz? -- 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
Re: [RFC][PATCH] ASoC: OMAP: Fix capture pointer handling for OMAP1510 to work correctly with recent ALSA PCM code
On Thu, 1 Apr 2010 21:45:49 +0200 Janusz Krzysztofik wrote: > Thursday 01 April 2010 14:25:21 Mark Brown napisał(a): > > Any updates on this one? > > Hi Mark, > > I can only confirm that using 2.6.34-rc3, already containing Jarkko's patch, > I > still have to apply mine to get sound working on Amstrad Delta. > > However, I still don't understand what happened to capture stream handling > that it stopped working for me. > While I either don't understand the broke I think there's something in the capture DMA pointer which shows up only now. So I'm fine if you Janusz like to get your patch in and can have my ack. Or do you want to debug it further? Acked-by: Jarkko Nikula -- 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
