Setting dss1_alwon_fck rate
Hi, Any comments on these two patches from Mans, that enable setting dss1_alwon_fck? I've been using them with the new DSS, works fine for me. http://marc.info/?l=linux-omapm=122454507816731w=2 Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock34xx.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) http://marc.info/?l=linux-omapm=122454507816734w=2 This makes clk_get_parent() work on OMAP2/3. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock.c |5 + arch/arm/mach-omap2/clock.h |1 + arch/arm/mach-omap2/clock24xx.c |1 + arch/arm/mach-omap2/clock34xx.c |1 + 4 files changed, 8 insertions(+), 0 deletions(-) Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [irda-users] [PATCH] OMAP IrDA driver
Hi, On Fri, 5 Dec 2008 12:04:29 +0530, Trilok Soni [EMAIL PROTECTED] wrote: This time adding LKML too. Could you please inline the patch so that we can have an easier review ? Cheers, Samuel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-omap] [PATCH 2/2] DSPBRIDGE: Freeing allocated resources on rmmod
On Thursday 04 December 2008, Ramirez Luna, Omar wrote: + DSP_STATUS dsp_status = DSP_SOK; + HANDLE hDrvObject = NULL; + struct PROCESS_CONTEXT *pTmp = NULL; + struct PROCESS_CONTEXT *pCtxtclosed = NULL; + struct PROCESS_CONTEXT *pCtxttraverse = NULL; It WoUlD bE a LoT nIcEr ... ... if new code didn't introduce new CamelCase usage, and didn't use Hungarian notation. Hungarian notation makes some sense in assembly language, where it was created to help cope with the lack of typing. But not in C. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [irda-users] [PATCH] OMAP IrDA driver
Hi Samuel, On Fri, Dec 5, 2008 at 2:58 PM, [EMAIL PROTECTED] wrote: Hi, On Fri, 5 Dec 2008 12:04:29 +0530, Trilok Soni [EMAIL PROTECTED] wrote: This time adding LKML too. Could you please inline the patch so that we can have an easier review ? I don't have proper git-send-email integration with gmail, so I am going to copy/paste this patch here: From e218cd5b2f29fa3ca342a5f4074a9e3cd3cacdad Mon Sep 17 00:00:00 2001 From: Trilok Soni [EMAIL PROTECTED] Date: Fri, 28 Nov 2008 16:49:44 +0530 Subject: [PATCH] OMAP IrDA driver Add Texas Instruments OMAP IrDA device driver, which supports SIR/MIR and FIR. Signed-off-by: Trilok Soni [EMAIL PROTECTED] --- drivers/net/irda/Kconfig |9 + drivers/net/irda/Makefile |1 + drivers/net/irda/omap-ir.c | 893 3 files changed, 903 insertions(+), 0 deletions(-) create mode 100644 drivers/net/irda/omap-ir.c diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig index e631755..6af0c15 100644 --- a/drivers/net/irda/Kconfig +++ b/drivers/net/irda/Kconfig @@ -342,5 +342,14 @@ config MCS_FIR To compile it as a module, choose M here: the module will be called mcs7780. +config OMAP_IR + tristate OMAP IrDA(SIR/MIR/FIR) + depends on IRDA ARCH_OMAP +help + Say Y here if you want to build support for the Texas Instruments + OMAP IrDA device driver, which supports SIR/MIR/FIR. This driver + relies on platform specific helper routines so available capabilities + may vary from one OMAP target to another. + endmenu diff --git a/drivers/net/irda/Makefile b/drivers/net/irda/Makefile index 5d20fde..72bbc2a 100644 --- a/drivers/net/irda/Makefile +++ b/drivers/net/irda/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_VIA_FIR) += via-ircc.o obj-$(CONFIG_PXA_FICP) += pxaficp_ir.o obj-$(CONFIG_MCS_FIR) += mcs7780.o obj-$(CONFIG_AU1000_FIR) += au1k_ir.o +obj-$(CONFIG_OMAP_IR) += omap-ir.o # SIR drivers obj-$(CONFIG_IRTTY_SIR)+= irtty-sir.o sir-dev.o # dongle drivers for SIR drivers diff --git a/drivers/net/irda/omap-ir.c b/drivers/net/irda/omap-ir.c new file mode 100644 index 000..bf29585 --- /dev/null +++ b/drivers/net/irda/omap-ir.c @@ -0,0 +1,893 @@ +/* + * BRIEF MODULE DESCRIPTION + * + * Infra-red driver for the OMAP1610-H2 and OMAP1710-H3 and H4 Platforms + * (SIR/MIR/FIR modes) + * (based on omap-sir.c) + * + * Copyright 2003 MontaVista Software Inc. + * Author: MontaVista Software, Inc. + *[EMAIL PROTECTED] + * + * Copyright 2004 Texas Instruments. + * + * 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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN + * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * 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., + * 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +#include linux/module.h +#include linux/types.h +#include linux/init.h +#include linux/errno.h +#include linux/netdevice.h +#include linux/slab.h +#include linux/rtnetlink.h +#include linux/interrupt.h +#include linux/delay.h +#include linux/ioport.h +#include linux/dma-mapping.h +#include linux/platform_device.h +#include linux/workqueue.h +#include linux/io.h +#include linux/serial.h + +#include net/irda/irda.h +#include net/irda/irmod.h +#include net/irda/wrapper.h +#include net/irda/irda_device.h + +#include asm/irq.h +#include asm/mach-types.h +#include asm/dma.h + +#include mach/hardware.h +#include mach/mux.h +#include mach/gpio.h +#include mach/irda.h + +#define UART3_EFR_EN (1 4) +#define UART3_MCR_EN_TCR_TLR (1 6) + +#define UART3_LCR_WL_8 (3 0) +#define UART3_LCR_SP2 (1 2) +#define UART3_LCR_DIVEN(1 7) + +#define UART3_FCR_FIFO_EN (1 0) +#define UART3_FCR_FIFO_RX (1 1) +#define UART3_FCR_FIFO_TX
RE: [PATCH 1/1] Save sram context after changing MPU, DSP or core clocks
Hi Peter, This patch causes linker error without CONFIG_PM option, should add #ifdef:s around the call to omap3_save_scratchpad_contents(); -Tero -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Peter 'p2' De Schrijver Sent: 19 November, 2008 13:45 To: linux-omap@vger.kernel.org Cc: De-Schrijver Peter (Nokia-D/Helsinki) Subject: [PATCH 1/1] Save sram context after changing MPU, DSP or core clocks Signed-off-by: Peter 'p2' De Schrijver [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock34xx.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index d97d5a9..962ce56 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -911,6 +911,9 @@ printk(%s set to %luHz intended rate %luHz\n,dpll2_clk-name,clk_get_rate(dpll clk_set_rate(dpll3_clk, prcm_vdd-rate); curr_vdd2_prcm_set = prcm_vdd; } + + omap3_save_scratchpad_contents(); + return 0; } -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Save sram context after changing MPU, DSP or core clocks
On Fri, Dec 05, 2008 at 11:49:03AM +0200, Kristo Tero (Nokia-D/Tampere) wrote: Hi Peter, This patch causes linker error without CONFIG_PM option, should add #ifdef:s around the call to omap3_save_scratchpad_contents(); That looks a bit ugly though :( Cheers, Peter -- goa is a state of mind -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OneNAND: OMAP2: Switch to generic gpio calls
From: Jarkko Nikula [EMAIL PROTECTED]
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
Signed-off-by: Adrian Hunter [EMAIL PROTECTED]
---
drivers/mtd/onenand/omap2.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index a7e4d98..c260e2d 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -149,7 +149,7 @@ static int omap2_onenand_wait(struct mtd_info *mtd, int
state)
INIT_COMPLETION(c-irq_done);
if (c-gpio_irq) {
- result = omap_get_gpio_datain(c-gpio_irq);
+ result = gpio_get_value(c-gpio_irq);
if (result == -1) {
ctrl = read_reg(c, ONENAND_REG_CTRL_STATUS);
intr = read_reg(c, ONENAND_REG_INTERRUPT);
@@ -629,14 +629,14 @@ static int __devinit omap2_onenand_probe(struct
platform_device *pdev)
}
if (c-gpio_irq) {
- if ((r = omap_request_gpio(c-gpio_irq)) 0) {
+ if ((r = gpio_request(c-gpio_irq, OneNAND irq)) 0) {
dev_err(pdev-dev, Failed to request GPIO%d for
OneNAND\n, c-gpio_irq);
goto err_iounmap;
}
- omap_set_gpio_direction(c-gpio_irq, 1);
+ gpio_direction_input(c-gpio_irq);
- if ((r = request_irq(OMAP_GPIO_IRQ(c-gpio_irq),
+ if ((r = request_irq(gpio_to_irq(c-gpio_irq),
omap2_onenand_interrupt, IRQF_TRIGGER_RISING,
pdev-dev.driver-name, c)) 0)
goto err_release_gpio;
@@ -723,10 +723,10 @@ err_release_dma:
if (c-dma_channel != -1)
omap_free_dma(c-dma_channel);
if (c-gpio_irq)
- free_irq(OMAP_GPIO_IRQ(c-gpio_irq), c);
+ free_irq(gpio_to_irq(c-gpio_irq), c);
err_release_gpio:
if (c-gpio_irq)
- omap_free_gpio(c-gpio_irq);
+ gpio_free(c-gpio_irq);
err_iounmap:
iounmap(c-onenand.base);
err_release_mem_region:
@@ -760,8 +760,8 @@ static int __devexit omap2_onenand_remove(struct
platform_device *pdev)
omap2_onenand_shutdown(pdev);
platform_set_drvdata(pdev, NULL);
if (c-gpio_irq) {
- free_irq(OMAP_GPIO_IRQ(c-gpio_irq), c);
- omap_free_gpio(c-gpio_irq);
+ free_irq(gpio_to_irq(c-gpio_irq), c);
+ gpio_free(c-gpio_irq);
}
iounmap(c-onenand.base);
release_mem_region(c-phys_base, ONENAND_IO_SIZE);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Addition of Set Routing ioctl support[V5]
From: Vaibhav Hiremath [EMAIL PROTECTED]
Fixed review comments:
g_routing:
Removed g_routing, since it was not required
at decoder level. Same can be handled at master
level.
Signed-off-by: Brijesh Jadav [EMAIL PROTECTED]
Signed-off-by: Hardik Shah [EMAIL PROTECTED]
Signed-off-by: Manjunath Hadli [EMAIL PROTECTED]
Signed-off-by: R Sivaraj [EMAIL PROTECTED]
Signed-off-by: Vaibhav Hiremath [EMAIL PROTECTED]
Signed-off-by: Karicheri Muralidharan [EMAIL PROTECTED]
---
include/media/v4l2-int-device.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 9c2df41..ecda3c7 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -183,6 +183,9 @@ enum v4l2_int_ioctl_num {
vidioc_int_s_crop_num,
vidioc_int_g_parm_num,
vidioc_int_s_parm_num,
+ vidioc_int_querystd_num,
+ vidioc_int_s_std_num,
+ vidioc_int_s_video_routing_num,
/*
*
@@ -284,6 +287,9 @@ V4L2_INT_WRAPPER_1(g_crop, struct v4l2_crop, *);
V4L2_INT_WRAPPER_1(s_crop, struct v4l2_crop, *);
V4L2_INT_WRAPPER_1(g_parm, struct v4l2_streamparm, *);
V4L2_INT_WRAPPER_1(s_parm, struct v4l2_streamparm, *);
+V4L2_INT_WRAPPER_1(querystd, v4l2_std_id, *);
+V4L2_INT_WRAPPER_1(s_std, v4l2_std_id, *);
+V4L2_INT_WRAPPER_1(s_video_routing, struct v4l2_routing, *);
V4L2_INT_WRAPPER_0(dev_init);
V4L2_INT_WRAPPER_0(dev_exit);
--
1.5.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - omap2: add OMAP2 camera driver. - v4l2-int-if: add three new ioctls for std handling and routing - v4l: add new tvp514x I2C video decoder driver Thanks to Nokia and TI for these drivers! Regards, Hans diffstat: b/linux/drivers/media/video/omap24xxcam-dma.c | 601 b/linux/drivers/media/video/omap24xxcam.c | 1908 ++ b/linux/drivers/media/video/omap24xxcam.h | 593 b/linux/drivers/media/video/tvp514x.c | 1569 + b/linux/drivers/media/video/tvp514x_regs.h| 297 b/linux/include/media/tvp514x.h | 118 + linux/drivers/media/video/Kconfig | 18 linux/drivers/media/video/Makefile|4 linux/include/media/v4l2-int-device.h |6 9 files changed, 5114 insertions(+) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Remove drivers/input/touchscreen/omap directory?
Hi Tony, I think no one using touchscreen drivers under this directory, please remove. I will start process of sending tsc patches to upstream soon... -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remove drivers/input/touchscreen/omap directory?
On Fri, 5 Dec 2008 19:25:48 +0530 ext Trilok Soni [EMAIL PROTECTED] wrote: Hi Tony, I think no one using touchscreen drivers under this directory, please remove. I will start process of sending tsc patches to upstream soon... That's great! Also drivers/spi/tsc2301-mixer.c can be removed in part of the process. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in linux omap clock framework?
Hi,
I have had strange clk_enable() crashes with DSS2, and now I managed to
isolate it. With the included patch, on OMAP3 SDP board, with default
kernel config, I always get the crash below. In this example case it
happens at specific time on boot, but with DSS2 it happens randomly at
runtime, when I enable the DSS clocks.
diff --git a/drivers/video/omap/omapfb_main.c
b/drivers/video/omap/omapfb_main.c
index 3bb4247..2d5ef0d 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -27,6 +27,7 @@
#include linux/platform_device.h
#include linux/mm.h
#include linux/uaccess.h
+#include linux/clk.h
#include mach/dma.h
#include mach/omapfb.h
@@ -1806,6 +1807,18 @@ static int omapfb_probe(struct platform_device
*pdev)
{
BUG_ON(fbdev_pdev != NULL);
+ {
+ struct clk *c1, *c2;
+ c1 = clk_get(pdev-dev, dss_ick);
+ c2 = clk_get(pdev-dev, dss1_fck);
+ while(1) {
+ clk_enable(c1);
+ clk_enable(c2);
+ clk_disable(c1);
+ clk_disable(c2);
+ }
+ }
+
/* Delay actual initialization until the LCD is registered */
fbdev_pdev = pdev;
if (fbdev_panel != NULL)
@@ -1958,7 +1971,7 @@ module_param_named(rotate, def_rotate, uint,
0664);
module_param_named(mirror, def_mirror, uint, 0664);
module_param_named(manual_update, manual_update, bool, 0664);
-module_init(omapfb_init);
+late_initcall(omapfb_init);
module_exit(omapfb_cleanup);
MODULE_DESCRIPTION(TI OMAP framebuffer driver);
And the crash:
1Unhandled fault: external abort on non-linefetch (0x1028) at
0xd8200098
Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
Internal error: : 1028 [#1]
Internal error: : 1028 [#1]
Modules linked in:Modules linked in:
CPU: 0Not tainted (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
CPU: 0Not tainted (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
PC is at __irq_svc+0x34/0x80
PC is at __irq_svc+0x34/0x80
LR is at _omap2_clk_enable+0xa0/0xe0
LR is at _omap2_clk_enable+0xa0/0xe0
pc : [c002c9d4]lr : [c0036314]psr: 6193
sp : c7817d30 ip : c7817d40 fp : c7817d8c
pc : [c002c9d4]lr : [c0036314]psr: 6193
sp : c7817d30 ip : c7817d40 fp : c7817d8c
r10: c001a210 r9 : r8 : c0395048
r10: c001a210 r9 : r8 : c0395048
r7 : c03910c0 r6 : c03910c0 r5 : d820 r4 :
r7 : c03910c0 r6 : c03910c0 r5 : d820 r4 :
r3 : 6013 r2 : c003ae80 r1 : c0036314 r0 : c7817d78
r3 : 6013 r2 : c003ae80 r1 : c0036314 r0 : c7817d78
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387f Table: 80004018 DAC: 0017
Control: 10c5387f Table: 80004018 DAC: 0017
Process swapper (pid: 1, stack limit = 0xc78162e0)
Process swapper (pid: 1, stack limit = 0xc78162e0)
Stack: (0xc7817d30 to 0xc7818000)
Stack: (0xc7817d30 to 0xc7818000)
7d20: 7d20:
0010 0010 0001 0001
7d40: 7d40: 8013 8013 c037ac4c c037ac4c c03910c0 c03910c0
c03910c0 c03910c0 c0395048 c0395048 c001a210 c001a210
c7817d8c c7817d8c
7d60: 7d60: c7817d40 c7817d40 c7817d78 c7817d78 c0036314 c0036314
c003ae80 c003ae80 6013 6013 fffe fffe
c037ac4c c037ac4c
7d80: 7d80: c7817da4 c7817da4 c7817d90 c7817d90 c018bef4 c018bef4
c003ae48 c003ae48 c037de28 c037de28 c037ded4 c037ded4 c7817db4 c7817db4
c7817da8 c7817da8
7da0: 7da0: c01afd70 c01afd70 c018beac c018beac c7817dd4 c7817dd4
c7817db8 c7817db8 c01aef90 c01aef90 c01afd5c c01afd5c c037de28 c037de28
c037ded4 c037ded4
7dc0: 7dc0: c03910c0 c03910c0 c03910c0 c03910c0 c7817df4 c7817df4
c7817dd8 c7817dd8 c01af0a4 c01af0a4 c01aeecc c01aeecc
c7817df8 c7817df8
7de0: 7de0: c01af03c c01af03c c03910c0 c03910c0 c7817e1c c7817e1c
c7817df8 c7817df8 c01ae510 c01ae510 c01af048 c01af048 c78034d8 c78034d8
c037de70 c037de70
7e00: 7e00: c03910c0 c03910c0
c7941b60 c7941b60 c7817e2c c7817e2c c7817e20 c7817e20 c01aedd8 c01aedd8
c01ae4d0 c01ae4d0
7e20: 7e20: c7817e5c c7817e5c c7817e30 c7817e30 c01ae994 c01ae994
c01aedc4 c01aedc4 c0325184 c0325184 c03910c0 c03910c0
c03a0480 c03a0480
7e40: 7e40: c03910c0 c03910c0
c7817e84 c7817e84 c7817e60 c7817e60 c01af298 c01af298
c01ae8f8 c01ae8f8
7e60: 7e60: c03a0480 c03a0480 c0024b00 c0024b00
c001a210 c001a210 c7817e94 c7817e94
c7817e88 c7817e88
7e80: 7e80: c01b0108 c01b0108 c01af20c c01af20c c7817ebc c7817ebc
c7817e98 c7817e98 c001a41c c001a41c c01b009c c01b009c c0019c1c c0019c1c
c01754b0 c01754b0
7ea0: 7ea0: 12bdf916 12bdf916
c03a0480 c03a0480 c7817fdc c7817fdc
RE: [linux-omap] [PATCH 2/2] DSPBRIDGE: Freeing allocated resources on rmmod
Hi David, From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2008 3:39 AM To: Ramirez Luna, Omar Cc: linux-omap@vger.kernel.org; Hiroshi DOYU; Gupta, Ramesh; Kanigeri, Hari Subject: Re: [linux-omap] [PATCH 2/2] DSPBRIDGE: Freeing allocated resources on rmmod On Thursday 04 December 2008, Ramirez Luna, Omar wrote: + DSP_STATUS dsp_status = DSP_SOK; + HANDLE hDrvObject = NULL; + struct PROCESS_CONTEXT *pTmp = NULL; + struct PROCESS_CONTEXT *pCtxtclosed = NULL; + struct PROCESS_CONTEXT *pCtxttraverse = NULL; It WoUlD bE a LoT nIcEr ... ... if new code didn't introduce new CamelCase usage, and didn't use Hungarian notation. Hungarian notation makes some sense in assembly language, where it was created to help cope with the lack of typing. But not in C. Thanks for your comments and time, we are still working towards meeting open source standards and enhancing the code with all the feedback received (RW, RMK, TL, HD, FC and many more people) to get the driver pushed a piece at a time. There are still action items in our list, along with coding style, but we'll keep working to get them done. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OneNAND: OMAP2: Switch to generic gpio calls
On Friday 05 December 2008, Adrian Hunter wrote:
- if ((r = omap_request_gpio(c-gpio_irq)) 0) {
+ if ((r = gpio_request(c-gpio_irq, OneNAND irq)) 0) {
Worth noting that this depends on the OMAP patches which
make those calls be equivalent. Those patches are going
into 2.6.29-early via the ARM tree, as I recall; getting
the merge order wrong would break bisectability -- but
not buildability.
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in linux omap clock framework?
[EMAIL PROTECTED] writes:
Hi,
I have had strange clk_enable() crashes with DSS2, and now I managed to
isolate it. With the included patch, on OMAP3 SDP board, with default
kernel config, I always get the crash below. In this example case it
happens at specific time on boot, but with DSS2 it happens randomly at
runtime, when I enable the DSS clocks.
diff --git a/drivers/video/omap/omapfb_main.c
b/drivers/video/omap/omapfb_main.c
index 3bb4247..2d5ef0d 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -27,6 +27,7 @@
#include linux/platform_device.h
#include linux/mm.h
#include linux/uaccess.h
+#include linux/clk.h
#include mach/dma.h
#include mach/omapfb.h
@@ -1806,6 +1807,18 @@ static int omapfb_probe(struct platform_device
*pdev)
{
BUG_ON(fbdev_pdev != NULL);
+ {
+ struct clk *c1, *c2;
+ c1 = clk_get(pdev-dev, dss_ick);
+ c2 = clk_get(pdev-dev, dss1_fck);
+ while(1) {
+ clk_enable(c1);
+ clk_enable(c2);
+ clk_disable(c1);
+ clk_disable(c2);
+ }
+ }
+
/* Delay actual initialization until the LCD is registered */
fbdev_pdev = pdev;
if (fbdev_panel != NULL)
@@ -1958,7 +1971,7 @@ module_param_named(rotate, def_rotate, uint,
0664);
module_param_named(mirror, def_mirror, uint, 0664);
module_param_named(manual_update, manual_update, bool, 0664);
-module_init(omapfb_init);
+late_initcall(omapfb_init);
module_exit(omapfb_cleanup);
MODULE_DESCRIPTION(TI OMAP framebuffer driver);
And the crash:
1Unhandled fault: external abort on non-linefetch (0x1028) at
0xd8200098
Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
Internal error: : 1028 [#1]
Internal error: : 1028 [#1]
Modules linked in:Modules linked in:
CPU: 0Not tainted (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
CPU: 0Not tainted (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
PC is at __irq_svc+0x34/0x80
PC is at __irq_svc+0x34/0x80
LR is at _omap2_clk_enable+0xa0/0xe0
LR is at _omap2_clk_enable+0xa0/0xe0
What looks to be happening is an interrupt is firing in the middle of
your clk_enable() call, and accesses to the Interrupt controller
registers are triggering a fault.
As a temporary workaround, could you try wrapping your clk_enable()
with an IRQ save/restore? Something like:
local_irq_save(flags);
clk_enable(c);
local_irq_restore(flags);
If this works, then we need to investigate in more detail which
interrupt is firing, and why the INTC registers are not accessible.
Kevin
pc : [c002c9d4]lr : [c0036314]psr: 6193
sp : c7817d30 ip : c7817d40 fp : c7817d8c
pc : [c002c9d4]lr : [c0036314]psr: 6193
sp : c7817d30 ip : c7817d40 fp : c7817d8c
r10: c001a210 r9 : r8 : c0395048
r10: c001a210 r9 : r8 : c0395048
r7 : c03910c0 r6 : c03910c0 r5 : d820 r4 :
r7 : c03910c0 r6 : c03910c0 r5 : d820 r4 :
r3 : 6013 r2 : c003ae80 r1 : c0036314 r0 : c7817d78
r3 : 6013 r2 : c003ae80 r1 : c0036314 r0 : c7817d78
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387f Table: 80004018 DAC: 0017
Control: 10c5387f Table: 80004018 DAC: 0017
Process swapper (pid: 1, stack limit = 0xc78162e0)
Process swapper (pid: 1, stack limit = 0xc78162e0)
Stack: (0xc7817d30 to 0xc7818000)
Stack: (0xc7817d30 to 0xc7818000)
7d20: 7d20:
0010 0010 0001 0001
7d40: 7d40: 8013 8013 c037ac4c c037ac4c c03910c0 c03910c0
c03910c0 c03910c0 c0395048 c0395048 c001a210 c001a210
c7817d8c c7817d8c
7d60: 7d60: c7817d40 c7817d40 c7817d78 c7817d78 c0036314 c0036314
c003ae80 c003ae80 6013 6013 fffe fffe
c037ac4c c037ac4c
7d80: 7d80: c7817da4 c7817da4 c7817d90 c7817d90 c018bef4 c018bef4
c003ae48 c003ae48 c037de28 c037de28 c037ded4 c037ded4 c7817db4 c7817db4
c7817da8 c7817da8
7da0: 7da0: c01afd70 c01afd70 c018beac c018beac c7817dd4 c7817dd4
c7817db8 c7817db8 c01aef90 c01aef90 c01afd5c c01afd5c c037de28 c037de28
c037ded4 c037ded4
7dc0: 7dc0: c03910c0 c03910c0 c03910c0 c03910c0 c7817df4 c7817df4
c7817dd8 c7817dd8 c01af0a4 c01af0a4 c01aeecc c01aeecc
c7817df8 c7817df8
7de0: 7de0: c01af03c c01af03c c03910c0 c03910c0 c7817e1c c7817e1c
c7817df8 c7817df8 c01ae510 c01ae510 c01af048 c01af048 c78034d8 c78034d8
c037de70 c037de70
7e00: 7e00: c03910c0 c03910c0
c7941b60 c7941b60 c7817e2c c7817e2c c7817e20 c7817e20 c01aedd8 c01aedd8
c01ae4d0 c01ae4d0
7e20: 7e20: c7817e5c c7817e5c c7817e30 c7817e30 c01ae994 c01ae994
c01aedc4 c01aedc4 c0325184 c0325184
RE: [PATCH] Add OMAP2 camera driver
Thanks, Vaibhav Hiremath -Original Message- From: Tony Lindgren [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2008 5:16 AM To: Hiremath, Vaibhav Cc: Koen Kooi; Trilok Soni; Hans Verkuil; Sakari Ailus; linux- [EMAIL PROTECTED] Mailing List; [EMAIL PROTECTED] Subject: Re: [PATCH] Add OMAP2 camera driver * Hiremath, Vaibhav [EMAIL PROTECTED] [081203 01:38]: Thanks, Vaibhav Hiremath -Original Message- From: Koen Kooi [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 3:04 PM To: Hiremath, Vaibhav Cc: Trilok Soni; Hans Verkuil; Sakari Ailus; linux- [EMAIL PROTECTED] Mailing List; [EMAIL PROTECTED] Subject: Re: [PATCH] Add OMAP2 camera driver Op 3 dec 2008, om 08:05 heeft Hiremath, Vaibhav het volgende geschreven: OMAP3 - Display - (Posted twice with old DSS library) - omap_vout.c - omap_voutlib.c - omap_voutlib.h - omap_voutdef.h Camera - (Will come soon) - omap34xxcam.c - omap34xxcam.h ISP - (Will come soon) - Here definitely we will plenty number of files. Isn't DSS2 supposed to work on omap2 (and perhaps omap1) as well? [Hiremath, Vaibhav] yes, but the DSS2 library goes under arch/arm/plat-omap/dss/. The above files are belongs to the driver underneath. Huh? Why would it need to be under plat-omap? [Hiremath, Vaibhav] This is low level library which will export Kernel API's to top level driver like, Frame buffer and V4L2 driver. So this has to be in some common directory, and both patches on DSS (from Tomi and from TI) aligned to the same thing. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add OMAP2 camera driver
* Hiremath, Vaibhav [EMAIL PROTECTED] [081205 10:58]: From: Tony Lindgren [mailto:[EMAIL PROTECTED] * Hiremath, Vaibhav [EMAIL PROTECTED] [081203 01:38]: snip Isn't DSS2 supposed to work on omap2 (and perhaps omap1) as well? [Hiremath, Vaibhav] yes, but the DSS2 library goes under arch/arm/plat-omap/dss/. The above files are belongs to the driver underneath. Huh? Why would it need to be under plat-omap? [Hiremath, Vaibhav] This is low level library which will export Kernel API's to top level driver like, Frame buffer and V4L2 driver. So this has to be in some common directory, and both patches on DSS (from Tomi and from TI) aligned to the same thing. We're not adding driver specific code to arch/arm/plat-omap. Please place your shared driver code either under drivers/video and export the functions needed by v4l like all other linux driver code does. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] Omap3 updates for 2.6.29 merge window
Hi, Here are some updates for omap3 for review. Regards, Tony --- Arun KS (1): ARM: OMAP3: Pin multiplexing updates for 24xx and 34xx Grazvydas Ignotas (1): ARM: OMAP3: Add basic support for Pandora handheld console Jarkko Nikula (1): ARM: OMAP3: Add OMAP34xx pin multiplexing into I2C bus registration helper Santosh Shilimkar (1): ARM: OMAP3: DMA: Fix for sDMA Errata 1.113 Stanley.Miao (1): ARM: OMAP3: LDP: Add Ethernet device support to make ldp boot succeess Tony Lindgren (1): ARM: OMAP3: Warn about spurious interrupts arch/arm/configs/omap3_pandora_defconfig| 1409 +++ arch/arm/configs/omap_ldp_defconfig | 148 +++ arch/arm/mach-omap2/Kconfig |4 arch/arm/mach-omap2/Makefile|1 arch/arm/mach-omap2/board-ldp.c | 57 + arch/arm/mach-omap2/board-omap3pandora.c| 281 + arch/arm/mach-omap2/irq.c | 39 + arch/arm/mach-omap2/mux.c | 44 + arch/arm/plat-omap/dma.c| 15 arch/arm/plat-omap/i2c.c| 55 + arch/arm/plat-omap/include/mach/board-ldp.h |5 arch/arm/plat-omap/include/mach/mux.h | 41 + 12 files changed, 2076 insertions(+), 23 deletions(-) create mode 100644 arch/arm/configs/omap3_pandora_defconfig create mode 100644 arch/arm/mach-omap2/board-omap3pandora.c -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: OMAP3: Warn about spurious interrupts
In the case of spurious interrupt, the handler for previous interrupt
handler needs to flush posted writes with a read back of the interrupt
ack register. Warn about handlers that need to flush posted writes.
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
arch/arm/mach-omap2/irq.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index c40fc37..636e282 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -23,6 +23,7 @@
#define INTC_REVISION 0x
#define INTC_SYSCONFIG 0x0010
#define INTC_SYSSTATUS 0x0014
+#define INTC_SIR 0x0040
#define INTC_CONTROL 0x0048
#define INTC_MIR_CLEAR00x0088
#define INTC_MIR_SET0 0x008c
@@ -60,6 +61,30 @@ static u32 intc_bank_read_reg(struct omap_irq_bank *bank,
u16 reg)
return __raw_readl(bank-base_reg + reg);
}
+static int previous_irq;
+
+/*
+ * On 34xx we can get occasional spurious interrupts if the ack from
+ * an interrupt handler does not get posted before we unmask. Warn about
+ * the interrupt handlers that need to flush posted writes.
+ */
+static int omap_check_spurious(unsigned int irq)
+{
+ u32 sir, spurious;
+
+ sir = intc_bank_read_reg(irq_banks[0], INTC_SIR);
+ spurious = sir 6;
+
+ if (spurious 1) {
+ printk(KERN_WARNING Spurious irq %i: 0x%08x, please flush
+ posted write for irq %i\n,
+ irq, sir, previous_irq);
+ return spurious;
+ }
+
+ return 0;
+}
+
/* XXX: FIQ and additional INTC support (only MPU at the moment) */
static void omap_ack_irq(unsigned int irq)
{
@@ -70,6 +95,20 @@ static void omap_mask_irq(unsigned int irq)
{
int offset = irq (~(IRQ_BITS_PER_REG - 1));
+ if (cpu_is_omap34xx()) {
+ int spurious = 0;
+
+ /*
+* INT_34XX_GPT12_IRQ is also the spurious irq. Maybe because
+* it is the highest irq number?
+*/
+ if (irq == INT_34XX_GPT12_IRQ)
+ spurious = omap_check_spurious(irq);
+
+ if (!spurious)
+ previous_irq = irq;
+ }
+
irq = (IRQ_BITS_PER_REG - 1);
intc_bank_write_reg(1 irq, irq_banks[0], INTC_MIR_SET0 + offset);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: OMAP3: Add OMAP34xx pin multiplexing into I2C bus registration helper
From: Jarkko Nikula [EMAIL PROTECTED]
- Simplify function omap_i2c_mux_pins
- Add OMAP34xx pin multiplexing for busses 1 - 3
Signed-off-by: Jarkko Nikula [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
arch/arm/plat-omap/i2c.c | 55 ++
1 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 0e6d147..89a6ab0 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -79,26 +79,43 @@ static struct platform_device omap_i2c_devices[] = {
#endif
};
-static void __init omap_i2c_mux_pins(int bus_id)
+#if defined(CONFIG_ARCH_OMAP24XX)
+static const int omap24xx_pins[][2] = {
+ { M19_24XX_I2C1_SCL, L15_24XX_I2C1_SDA },
+ { J15_24XX_I2C2_SCL, H19_24XX_I2C2_SDA },
+};
+#else
+static const int omap24xx_pins[][2] = {};
+#endif
+#if defined(CONFIG_ARCH_OMAP34XX)
+static const int omap34xx_pins[][2] = {
+ { K21_34XX_I2C1_SCL, J21_34XX_I2C1_SDA},
+ { AF15_34XX_I2C2_SCL, AE15_34XX_I2C2_SDA},
+ { AF14_34XX_I2C3_SCL, AG14_34XX_I2C3_SDA},
+};
+#else
+static const int omap34xx_pins[][2] = {};
+#endif
+
+static void __init omap_i2c_mux_pins(int bus)
{
- /* TODO: Muxing for OMAP3 */
- switch (bus_id) {
- case 1:
- if (cpu_class_is_omap1()) {
- omap_cfg_reg(I2C_SCL);
- omap_cfg_reg(I2C_SDA);
- } else if (cpu_is_omap24xx()) {
- omap_cfg_reg(M19_24XX_I2C1_SCL);
- omap_cfg_reg(L15_24XX_I2C1_SDA);
- }
- break;
- case 2:
- if (cpu_is_omap24xx()) {
- omap_cfg_reg(J15_24XX_I2C2_SCL);
- omap_cfg_reg(H19_24XX_I2C2_SDA);
- }
- break;
+ int scl, sda;
+
+ if (cpu_class_is_omap1()) {
+ scl = I2C_SCL;
+ sda = I2C_SDA;
+ } else if (cpu_is_omap24xx()) {
+ scl = omap24xx_pins[bus][0];
+ sda = omap24xx_pins[bus][1];
+ } else if (cpu_is_omap34xx()) {
+ scl = omap34xx_pins[bus][0];
+ sda = omap34xx_pins[bus][1];
+ } else {
+ return;
}
+
+ omap_cfg_reg(sda);
+ omap_cfg_reg(scl);
}
int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
@@ -142,6 +159,6 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
res[1].start = irq;
}
- omap_i2c_mux_pins(bus_id);
+ omap_i2c_mux_pins(bus_id - 1);
return platform_device_register(pdev);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: OMAP3: LDP: Add Ethernet device support to make ldp boot succeess
From: Stanley.Miao [EMAIL PROTECTED] Add Ethernet device support in board-ldp.c to make ldp can boot and mount nfs successfully. Signed-off-by: Stanley.Miao [EMAIL PROTECTED] --- arch/arm/configs/omap_ldp_defconfig | 148 +++ arch/arm/mach-omap2/board-ldp.c | 57 ++ arch/arm/plat-omap/include/mach/board-ldp.h |5 + 3 files changed, 208 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig index 948a212..b77d054 100644 --- a/arch/arm/configs/omap_ldp_defconfig +++ b/arch/arm/configs/omap_ldp_defconfig @@ -316,7 +316,82 @@ CONFIG_BINFMT_MISC=y # # CONFIG_PM is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y -# CONFIG_NET is not set +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=y +# CONFIG_PACKET_MMAP is not set +CONFIG_UNIX=y +CONFIG_XFRM=y +CONFIG_XFRM_USER=y +# CONFIG_XFRM_SUB_POLICY is not set +CONFIG_XFRM_MIGRATE=y +# CONFIG_XFRM_STATISTICS is not set +CONFIG_NET_KEY=y +CONFIG_NET_KEY_MIGRATE=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_IP_MROUTE is not set +# CONFIG_ARPD is not set +# CONFIG_SYN_COOKIES is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_XFRM_TUNNEL is not set +# CONFIG_INET_TUNNEL is not set +CONFIG_INET_XFRM_MODE_TRANSPORT=y +CONFIG_INET_XFRM_MODE_TUNNEL=y +CONFIG_INET_XFRM_MODE_BEET=y +# CONFIG_INET_LRO is not set +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG=cubic +# CONFIG_TCP_MD5SIG is not set +# CONFIG_IPV6 is not set +# CONFIG_NETWORK_SECMARK is not set +# CONFIG_NETFILTER is not set +# CONFIG_IP_DCCP is not set +# CONFIG_IP_SCTP is not set +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_NET_DSA is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_CAN is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_AF_RXRPC is not set +# CONFIG_PHONET is not set +# CONFIG_WIRELESS is not set +# CONFIG_RFKILL is not set +# CONFIG_NET_9P is not set # # Device Drivers @@ -332,6 +407,8 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set +CONFIG_CONNECTOR=y +CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y @@ -390,6 +467,54 @@ CONFIG_SCSI_LOWLEVEL=y # CONFIG_SCSI_DH is not set # CONFIG_ATA is not set # CONFIG_MD is not set +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_MACVLAN is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set +# CONFIG_VETH is not set +# CONFIG_PHYLIB is not set +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_AX88796 is not set +# CONFIG_SMC91X is not set +# CONFIG_DM9000 is not set +# CONFIG_ENC28J60 is not set +CONFIG_SMC911X=y +# CONFIG_IBM_NEW_EMAC_ZMII is not set +# CONFIG_IBM_NEW_EMAC_RGMII is not set +# CONFIG_IBM_NEW_EMAC_TAH is not set +# CONFIG_IBM_NEW_EMAC_EMAC4 is not set +# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set +# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set +# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set +# CONFIG_B44 is not set +CONFIG_NETDEV_1000=y +CONFIG_NETDEV_1=y + +# +# Wireless LAN +# +# CONFIG_WLAN_PRE80211 is not set +# CONFIG_WLAN_80211 is not set +# CONFIG_IWLWIFI_LEDS is not set + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +# CONFIG_WAN is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set +# CONFIG_ISDN is not set # # Input device support @@ -816,6 +941,27 @@ CONFIG_TMPFS=y # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set +CONFIG_NETWORK_FILESYSTEMS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V3=y +CONFIG_NFS_V3_ACL=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y +# CONFIG_NFSD is not set +CONFIG_LOCKD=y +CONFIG_LOCKD_V4=y +CONFIG_NFS_ACL_SUPPORT=y +CONFIG_NFS_COMMON=y +CONFIG_SUNRPC=y +CONFIG_SUNRPC_GSS=y +# CONFIG_SUNRPC_REGISTER_V4 is not set +CONFIG_RPCSEC_GSS_KRB5=y +# CONFIG_RPCSEC_GSS_SPKM3 is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +#
[PATCH 4/6] ARM: OMAP3: DMA: Fix for sDMA Errata 1.113
From: Santosh Shilimkar [EMAIL PROTECTED]
SDMA channel is not disabled after transaction error. So explicitly disable it.
Signed-off-by: Santosh Shilimkar [EMAIL PROTECTED]
Acked By : Nishant kamat [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
arch/arm/plat-omap/dma.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 50f8b4a..3df3740 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1848,9 +1848,22 @@ static int omap2_dma_handle_ch(int ch)
printk(KERN_INFO
DMA synchronization event drop occurred with device
%d\n, dma_chan[ch].dev_id);
- if (unlikely(status OMAP2_DMA_TRANS_ERR_IRQ))
+ if (unlikely(status OMAP2_DMA_TRANS_ERR_IRQ)) {
printk(KERN_INFO DMA transaction error with device %d\n,
dma_chan[ch].dev_id);
+ if (cpu_class_is_omap2()) {
+ /* Errata: sDMA Channel is not disabled
+* after a transaction error. So we explicitely
+* disable the channel
+*/
+ u32 ccr;
+
+ ccr = dma_read(CCR(ch));
+ ccr = ~OMAP_DMA_CCR_EN;
+ dma_write(ccr, CCR(ch));
+ dma_chan[ch].flags = ~OMAP_DMA_ACTIVE;
+ }
+ }
if (unlikely(status OMAP2_DMA_SECURE_ERR_IRQ))
printk(KERN_INFO DMA secure error with device %d\n,
dma_chan[ch].dev_id);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: OMAP3: Add basic support for Pandora handheld console
From: Grazvydas Ignotas [EMAIL PROTECTED] This patch adds support for basic features: nand, uarts, i2c, and rtc. Also includes defconfig. Signed-off-by: Grazvydas Ignotas [EMAIL PROTECTED] Signed-off-by: Tony Lindgren [EMAIL PROTECTED] --- arch/arm/configs/omap3_pandora_defconfig | 1409 ++ arch/arm/mach-omap2/Kconfig |4 arch/arm/mach-omap2/Makefile |1 arch/arm/mach-omap2/board-omap3pandora.c | 281 ++ 4 files changed, 1695 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/omap3_pandora_defconfig create mode 100644 arch/arm/mach-omap2/board-omap3pandora.c diff --git a/arch/arm/configs/omap3_pandora_defconfig b/arch/arm/configs/omap3_pandora_defconfig new file mode 100644 index 000..09543f4 --- /dev/null +++ b/arch/arm/configs/omap3_pandora_defconfig @@ -0,0 +1,1409 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.28-rc7 +# Fri Dec 5 11:54:09 2008 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_MMU=y +# CONFIG_NO_IOPORT is not set +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_KMOD=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_CLASSIC_RCU=y +# CONFIG_FREEZER is not set + +# +# System Type +# +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS7500 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KIRKWOOD is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_LOKI is not set +# CONFIG_ARCH_MV78XX0 is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +#
[PATCH 6/6] ARM: OMAP3: Pin multiplexing updates for 24xx and 34xx
From: Arun KS [EMAIL PROTECTED]
This patch adds some new pin multiplexing options
for McBSP and McSPI from Arun KS. Also add two more
GPIOs from David Brownell.
Also mark omap24xx_cfg_reg() static.
Signed-off-by: Arun KS [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
---
arch/arm/mach-omap2/mux.c | 44 -
arch/arm/plat-omap/include/mach/mux.h | 41 +++
2 files changed, 84 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index b139367..dacb41f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -203,6 +203,15 @@ MUX_CFG_24XX(AE9_2430_USB0HS_NXT,0x13D, 0,
0, 0, 1)
MUX_CFG_24XX(AC7_2430_USB0HS_DATA7, 0x13E, 0, 0, 0, 1)
/* 2430 McBSP */
+MUX_CFG_24XX(AD6_2430_MCBSP_CLKS,0x011E, 0, 0, 0, 1)
+
+MUX_CFG_24XX(AB2_2430_MCBSP1_CLKR, 0x011A, 0, 0, 0, 1)
+MUX_CFG_24XX(AD5_2430_MCBSP1_FSR,0x011B, 0, 0, 0, 1)
+MUX_CFG_24XX(AA1_2430_MCBSP1_DX, 0x011C, 0, 0, 0, 1)
+MUX_CFG_24XX(AF3_2430_MCBSP1_DR, 0x011D, 0, 0, 0, 1)
+MUX_CFG_24XX(AB3_2430_MCBSP1_FSX,0x011F, 0, 0, 0, 1)
+MUX_CFG_24XX(Y9_2430_MCBSP1_CLKX,0x0120, 0, 0, 0, 1)
+
MUX_CFG_24XX(AC10_2430_MCBSP2_FSX, 0x012E, 1, 0, 0, 1)
MUX_CFG_24XX(AD16_2430_MCBSP2_CLX, 0x012F, 1, 0, 0, 1)
MUX_CFG_24XX(AE13_2430_MCBSP2_DX,0x0130, 1, 0, 0, 1)
@@ -211,6 +220,31 @@ MUX_CFG_24XX(AC10_2430_MCBSP2_FSX_OFF,0x012E,0,
0, 0, 1)
MUX_CFG_24XX(AD16_2430_MCBSP2_CLX_OFF,0x012F,0, 0, 0,
1)
MUX_CFG_24XX(AE13_2430_MCBSP2_DX_OFF,0x0130, 0, 0, 0,
1)
MUX_CFG_24XX(AD13_2430_MCBSP2_DR_OFF,0x0131, 0, 0, 0,
1)
+
+MUX_CFG_24XX(AC9_2430_MCBSP3_CLKX, 0x0103, 0, 0, 0, 1)
+MUX_CFG_24XX(AE4_2430_MCBSP3_FSX,0x0104, 0, 0, 0, 1)
+MUX_CFG_24XX(AE2_2430_MCBSP3_DR, 0x0105, 0, 0, 0, 1)
+MUX_CFG_24XX(AF4_2430_MCBSP3_DX, 0x0106, 0, 0, 0, 1)
+
+MUX_CFG_24XX(N3_2430_MCBSP4_CLKX,0x010B, 1, 0, 0, 1)
+MUX_CFG_24XX(AD23_2430_MCBSP4_DR,0x010C, 1, 0, 0, 1)
+MUX_CFG_24XX(AB25_2430_MCBSP4_DX,0x010D, 1, 0, 0, 1)
+MUX_CFG_24XX(AC25_2430_MCBSP4_FSX, 0x010E, 1, 0, 0, 1)
+
+MUX_CFG_24XX(AE16_2430_MCBSP5_CLKX, 0x00ED, 1, 0, 0, 1)
+MUX_CFG_24XX(AF12_2430_MCBSP5_FSX, 0x00ED, 1, 0, 0, 1)
+MUX_CFG_24XX(K7_2430_MCBSP5_DX, 0x00EF, 1, 0, 0, 1)
+MUX_CFG_24XX(M1_2430_MCBSP5_DR, 0x00F0, 1, 0, 0, 1)
+
+/* 2430 MCSPI1 */
+MUX_CFG_24XX(Y18_2430_MCSPI1_CLK,0x010F, 0, 0, 0, 1)
+MUX_CFG_24XX(AD15_2430_MCSPI1_SIMO, 0x0110, 0, 0, 0, 1)
+MUX_CFG_24XX(AE17_2430_MCSPI1_SOMI, 0x0111, 0, 0, 0, 1)
+MUX_CFG_24XX(U1_2430_MCSPI1_CS0, 0x0112, 0, 0, 0, 1)
+
+/* Touchscreen GPIO */
+MUX_CFG_24XX(AF19_2430_GPIO_85, 0x0113, 3, 0, 0, 1)
+
};
#define OMAP24XX_PINS_SZ ARRAY_SIZE(omap24xx_pins)
@@ -417,6 +451,14 @@ MUX_CFG_34XX(AD2_3430_USB3FS_PHY_MM3_TXDAT, 0x188,
MUX_CFG_34XX(AC1_3430_USB3FS_PHY_MM3_TXEN_N, 0x18a,
OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
+
+/* 34XX GPIO - bidirectional, unless the name has an _OUT suffix.
+ * No internal pullup/pulldown without _UP or _DOWN suffix.
+ */
+MUX_CFG_34XX(AH8_34XX_GPIO29, 0x5fa,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX(J25_34XX_GPIO170, 0x1c6,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
@@ -452,7 +494,7 @@ static void __init_or_module omap2_cfg_debug(const struct
pin_config *cfg, u16 r
#endif
#ifdef CONFIG_ARCH_OMAP24XX
-int __init_or_module omap24xx_cfg_reg(const struct pin_config *cfg)
+static int __init_or_module omap24xx_cfg_reg(const struct pin_config *cfg)
{
static DEFINE_SPINLOCK(mux_spin_lock);
unsigned long flags;
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 6bbf178..f4362b8 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -632,6 +632,15 @@ enum omap24xx_index {
AC7_2430_USB0HS_DATA7,
/* 2430 McBSP */
+ AD6_2430_MCBSP_CLKS,
+
+ AB2_2430_MCBSP1_CLKR,
+ AD5_2430_MCBSP1_FSR,
+ AA1_2430_MCBSP1_DX,
+ AF3_2430_MCBSP1_DR,
+ AB3_2430_MCBSP1_FSX,
+ Y9_2430_MCBSP1_CLKX,
+
AC10_2430_MCBSP2_FSX,
AD16_2430_MCBSP2_CLX,
AE13_2430_MCBSP2_DX,
@@ -641,6 +650,30 @@ enum omap24xx_index {
AE13_2430_MCBSP2_DX_OFF,
AD13_2430_MCBSP2_DR_OFF,
Re: [irda-users] [PATCH] OMAP IrDA driver
Hi,
Just one comment below.
* Trilok Soni [EMAIL PROTECTED] [081205 01:48]:
Hi Samuel,
On Fri, Dec 5, 2008 at 2:58 PM, [EMAIL PROTECTED] wrote:
Hi,
On Fri, 5 Dec 2008 12:04:29 +0530, Trilok Soni [EMAIL PROTECTED]
wrote:
This time adding LKML too.
Could you please inline the patch so that we can have an easier review ?
I don't have proper git-send-email integration with gmail, so I am
going to copy/paste this patch here:
snip
diff --git a/drivers/net/irda/omap-ir.c b/drivers/net/irda/omap-ir.c
new file mode 100644
index 000..bf29585
--- /dev/null
+++ b/drivers/net/irda/omap-ir.c
@@ -0,0 +1,893 @@
snip
+
+/*
+ * Set the IrDA communications speed.
+ * Interrupt have to be disabled here.
+ */
+static int omap_irda_startup(struct net_device *dev)
+{
+ struct omap_irda *omap_ir = netdev_priv(dev);
+
+ /* FIXME: use clk_* apis for UART3 clock*/
+ /* Enable UART3 clock and set UART3 to IrDA mode */
+ if (machine_is_omap_h2() || machine_is_omap_h3())
+ omap_writel(omap_readl(MOD_CONF_CTRL_0) | (1 31) | (1 15),
+ MOD_CONF_CTRL_0);
+
+ /* Only for H2?
+ */
+ if (omap_ir-pdata-transceiver_mode machine_is_omap_h2()) {
+ /* Is it select_irda on H2 ? */
+ omap_writel(omap_readl(FUNC_MUX_CTRL_A) | 7,
+ FUNC_MUX_CTRL_A);
+ omap_ir-pdata-transceiver_mode(omap_ir-dev, IR_SIRMODE);
+ }
+
It would be best to get rid of the machine_is this or that code in the
drivers, and pass the necessary flags in the platform_data.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Putting TPS6235x into the power regulator framework
I second the comment on splitting this patch up into its constituent chunks. It'll be practical to review each of them properly at that point. Like ... it seems wrong to teach plat-omap/devices.c about EVM-specific stuff; it should stay generic. And those EVM-specific bits are done wrong too; those regulators are I2C devices, not platform devices! Plus, their constraints should be board-specific, not generic. Move all that into the omap3evm board code. You still didn't remove the drivers/i2c/chips stuff. Move the *ENTIRE* driver to drivers/regulator, and get rid of all the platform_device stuff. Good to see this driver start moving into its proper home, though. :) On Thursday 04 December 2008, [EMAIL PROTECTED] wrote: Not fixed comments: Not clear on how to implement runtime check for PR785 and would require some inputs on implementing the same. The TPS driver should not know or care about the PR785 card; it should just respond to the various requests. If there's any knowledge of PR785 in drivers/anything/* you should treat that as a bug (and fix it before merge). Since the chips are pretty much the same other than some bit interpretations, just use the driver_data in the i2c_device_id to describe whatever differences the driver needs to know about. With respect to runtime checking, first make sure the OMAP3 EVM init code is able to cleanly choose between the two power card options. Once that's done you can try turning that into a runtime check. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [irda-users] [PATCH] OMAP IrDA driver
On Fri, Dec 05, 2008 at 03:18:10PM +0530, Trilok Soni wrote:
+struct omap_irda {
+ unsigned char open;
+ int speed; /* Current IrDA speed */
+ int newspeed;
+
+ struct net_device_stats stats;
+ struct irlap_cb *irlap;
+ struct qos_info qos;
+
+ int rx_dma_channel;
+ int tx_dma_channel;
+
+ dma_addr_t rx_buf_dma_phys; /* Physical address of RX DMA buffer */
+ dma_addr_t tx_buf_dma_phys; /* Physical address of TX DMA buffer */
+
+ void *rx_buf_dma_virt; /* Virtual address of RX DMA buffer */
+ void *tx_buf_dma_virt; /* Virtual address of TX DMA buffer */
should these two be void __iomem * ?
+
+ struct device *dev;
+ struct omap_irda_config *pdata;
+};
+
+static inline void uart_reg_out(int idx, u8 val)
+{
+ omap_writeb(val, idx);
__raw_writeb(), pass a reference to struct omap_irda here so you'd have
access to a void __iomem *base (read below).
+}
+
+static inline u8 uart_reg_in(int idx)
+{
+ u8 b = omap_readb(idx);
ditto.
+ return b;
+}
+
+/* forward declarations */
+static int omap_irda_set_speed(struct net_device *dev, int speed);
+
+static void omap_irda_start_rx_dma(struct omap_irda *omap_ir)
+{
+ /* Configure DMA */
+ omap_set_dma_src_params(omap_ir-rx_dma_channel, 0x3, 0x0,
+ omap_ir-pdata-src_start,
+ 0, 0);
+
+ omap_enable_dma_irq(omap_ir-rx_dma_channel, 0x01);
+
+ omap_set_dma_dest_params(omap_ir-rx_dma_channel, 0x0, 0x1,
+ omap_ir-rx_buf_dma_phys,
+ 0, 0);
+
+ omap_set_dma_transfer_params(omap_ir-rx_dma_channel, 0x0,
+ IRDA_SKB_MAX_MTU, 0x1,
+ 0x0, omap_ir-pdata-rx_trigger, 0);
+
+ omap_start_dma(omap_ir-rx_dma_channel);
+}
+
+static void omap_start_tx_dma(struct omap_irda *omap_ir, int size)
+{
+ /* Configure DMA */
+ omap_set_dma_dest_params(omap_ir-tx_dma_channel, 0x03, 0x0,
+ omap_ir-pdata-dest_start, 0, 0);
+
+ omap_enable_dma_irq(omap_ir-tx_dma_channel, 0x01);
+
+ omap_set_dma_src_params(omap_ir-tx_dma_channel, 0x0, 0x1,
+ omap_ir-tx_buf_dma_phys,
+ 0, 0);
+
+ omap_set_dma_transfer_params(omap_ir-tx_dma_channel, 0x0, size, 0x1,
+ 0x0, omap_ir-pdata-tx_trigger, 0);
+
+ /* Start DMA */
+ omap_start_dma(omap_ir-tx_dma_channel);
+}
+
+/* DMA RX callback - normally, we should not go here,
+ * it calls only if something is going wrong
+ */
+static void omap_irda_rx_dma_callback(int lch, u16 ch_status, void *data)
+{
+ struct net_device *dev = data;
+ struct omap_irda *omap_ir = netdev_priv(dev);
+
+ printk(KERN_ERR RX Transfer error or very big frame\n);
you have a device pointer in omap_ir, use it and convert these to
dev_dbg() calls.
ditto to all below.
+static int omap_irda_startup(struct net_device *dev)
+{
+ struct omap_irda *omap_ir = netdev_priv(dev);
+
+ /* FIXME: use clk_* apis for UART3 clock*/
+ /* Enable UART3 clock and set UART3 to IrDA mode */
+ if (machine_is_omap_h2() || machine_is_omap_h3())
+ omap_writel(omap_readl(MOD_CONF_CTRL_0) | (1 31) | (1 15),
+ MOD_CONF_CTRL_0);
+
+ /* Only for H2?
+ */
+ if (omap_ir-pdata-transceiver_mode machine_is_omap_h2()) {
+ /* Is it select_irda on H2 ? */
+ omap_writel(omap_readl(FUNC_MUX_CTRL_A) | 7,
+ FUNC_MUX_CTRL_A);
__raw_writel/__raw_readl.
+static int omap_irda_probe(struct platform_device *pdev)
+{
+ struct net_device *dev;
+ struct omap_irda *omap_ir;
+ struct omap_irda_config *pdata = pdev-dev.platform_data;
+ unsigned int baudrate_mask;
+ int err = 0;
+ int irq = NO_IRQ;
you should probably have a struct resource *res = platform_get_resource(pdev,
IORESOURCE_MEM, 0);
and use it to ioremap() the base address. Then you can stop using the
omap_read[bsl]/omap_write[bsl] calls and switch over to standard
__raw_read[bsl]/__raw_write[bsl] ones.
+
+ if (!pdata) {
+ printk(KERN_ERR IrDA Platform data not supplied\n);
dev_dbg(pdev-dev, ..);
+ return -ENOENT;
+ }
+
+ if (!pdata-rx_channel || !pdata-tx_channel) {
+ printk(KERN_ERR IrDA invalid rx/tx channel value\n);
dev_dbg(pdev-dev, ..);
+ return -ENOENT;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq = 0) {
+ printk(KERN_WARNING no irq for IrDA\n);
dev_dbg(pdev-dev, ..);
+ return -ENOENT;
+ }
+
+ dev = alloc_irdadev(sizeof(struct omap_irda));
+ if (!dev)
+ goto err_mem_1;
+
+
one
Re: Setting dss1_alwon_fck rate
On Fri, Dec 5, 2008 at 1:02 AM, [EMAIL PROTECTED] wrote: Hi, Any comments on these two patches from Mans, that enable setting dss1_alwon_fck? I've been using them with the new DSS, works fine for me. I've been using them on recent Overo builds (using current DSS) and they work for me too. Steve http://marc.info/?l=linux-omapm=122454507816731w=2 Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock34xx.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) http://marc.info/?l=linux-omapm=122454507816734w=2 This makes clk_get_parent() work on OMAP2/3. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock.c |5 + arch/arm/mach-omap2/clock.h |1 + arch/arm/mach-omap2/clock24xx.c |1 + arch/arm/mach-omap2/clock34xx.c |1 + 4 files changed, 8 insertions(+), 0 deletions(-) Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: enabling USB-TLL fclk
On Fri, Oct 24, 2008 at 4:19 PM, Pandita, Vikram [EMAIL PROTECTED] wrote:
Paul
I was debugging why EHCI is not coming up and getting stuck in infinite loop
for TLL not enabling.
EHCI is still broken on the current top of tree -- same infinite loop.
Have anyone figured out what is going wrong here?
Steve
I found that there is issue with clock framework in enabling usbtll_fck
clock.
On enabling tll-fck clock, the framework returns error for the node:
static struct clk dpll5_ck = {
.name = dpll5_ck,
.parent = sys_ck,
.prcm_mod = PLL_MOD,
.dpll_data = dpll5_dd,
.flags = CLOCK_IN_OMAP3430ES2 | RATE_PROPAGATES,
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
.round_rate = omap2_dpll_round_rate,
.set_rate = omap3_noncore_dpll_set_rate,
.clkdm = { .name = dpll5_clkdm },
.recalc = omap3_dpll_recalc,
};
If I set the FCLK for USB-TLL directly as per following patch, EHCI works
fine.
Please check what is wrong with the above clock node.
---
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 419e70a..96b9df5 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -236,10 +236,9 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
#endif
/* Configure TLL for 60Mhz clk for ULPI */
- ehci_clocks-usbtll_fck_clk = clk_get(dev-dev, USBHOST_TLL_FCLK);
- if (IS_ERR(ehci_clocks-usbtll_fck_clk))
- return PTR_ERR(ehci_clocks-usbtll_fck_clk);
- clk_enable(ehci_clocks-usbtll_fck_clk);
+
+ /* Force enable FCLK for USB-TLL */
+ omap_writel(12, 0x48004A08); /* CM_FCLKEN3_CORE */
ehci_clocks-usbtll_ick_clk = clk_get(dev-dev, USBHOST_TLL_ICKL);
if (IS_ERR(ehci_clocks-usbtll_ick_clk))
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setting dss1_alwon_fck rate
* Steve Sakoman [EMAIL PROTECTED] [081205 14:57]: On Fri, Dec 5, 2008 at 1:02 AM, [EMAIL PROTECTED] wrote: Hi, Any comments on these two patches from Mans, that enable setting dss1_alwon_fck? I've been using them with the new DSS, works fine for me. I've been using them on recent Overo builds (using current DSS) and they work for me too. Paul, have you had a chance to look at Mans' patches? Tony Steve http://marc.info/?l=linux-omapm=122454507816731w=2 Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock34xx.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) http://marc.info/?l=linux-omapm=122454507816734w=2 This makes clk_get_parent() work on OMAP2/3. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] --- arch/arm/mach-omap2/clock.c |5 + arch/arm/mach-omap2/clock.h |1 + arch/arm/mach-omap2/clock24xx.c |1 + arch/arm/mach-omap2/clock34xx.c |1 + 4 files changed, 8 insertions(+), 0 deletions(-) Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP Zoom kernel ALSA build problem
On Thursday 04 December 2008, Tony Lindgren wrote:
So for example the NAND acceleration stuff seems to have gone
nowhere ... while that ZOOM fork may have some updates, they've not
gotten into the main OMAP tree, or into mainline.
That is frustrating. People at TI _should_ be working on sending
patches from zoom to upstream.
Or even just getting their goodness into the linux-omap tree,
as a first step towards getting upstream.
I used the OMAP3 NAND stuff as an example, since we saw a few
(unmergeable) patches but then everything seemed to fizzle.
Sure the other people can also
produce patches against the mainline and linux-omap kernel out
of the zoom tree.
That would require people to track the ZOOM kernels, as well
as mainline and linux-omap (and their own patch queues).
Not too realistic.
In general, here's how the patch flow needs to happen:
- All driver patches need to be posted to the right driver mailing
lists with linux-omap mailing list Cc'd. The patches need need
to be against the mainline kernel tree. The recent developments
with the ASoC and the new fb/v4l code is a good example how this
is working.
Yes. And in the case of stuff like NAND, where there's a ZOOM
driver and a Linux-OMAP driver but nothing in mainline, I suggest
syncing those two *before* pushing to mainline ... though there
may well be a case for involving the relevant mainline team at
that point too, or ignoring one driver.
- All core omap code needs to be posted to linux-omap for review
and will then be queued up into going into the mainline tree.
For any patches that apply already into the mainline kernel,
the patches need to be against the mainline kernel. For any
more complex patches, also linux-arm-kernel and maybe LKML lists
should be Cc'd.
Yep, that's straightforward. By core I presume you mean
arch/arm/plat-omap or maybe mach-omap{1,2}.
Soonish the linux-omap tree will become just a queue for patches
for the merge windows. So essentially we'll be using the mainline
kernel with some branches automerged hopefully real-soon-now.
That sounds like an interesting plan. It'll cause some level
of disruption ... which we probably need to have, since without
it folk seem to have little incentive to track mainline.
A slightly different spin: treat every divergence from mainline
as a bug that needs fixing. Those branches should mostly have
fairly short lifespans...
I think the right time to make that switch after Paul's clock
patches are integrated into the mainline kernel. Then we'll move
the non-mainline code into their own branches, or just drop it
if nobody wants to maintain it.
Sounds like a plan. Let's see how different the OMAP tree is
from mainline at that point, and see what the branches will be.
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()
On Tue, 21 Oct 2008, Mans Rullgard wrote: Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Måns, sorry this took so long, these two patches slipped through the cracks here. - Paul
Re: [PATCH 2/2] OMAP: Add clk_get_parent() for OMAP2/3
On Tue, 21 Oct 2008, Mans Rullgard wrote: This makes clk_get_parent() work on OMAP2/3. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()
* Paul Walmsley [EMAIL PROTECTED] [081205 15:52]: On Tue, 21 Oct 2008, Mans Rullgard wrote: Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Måns, sorry this took so long, these two patches slipped through the cracks here. Pushing both to l-o tree today. Paul, I take it you will queue these up for mainline via your clock series? Måns, I heard you have some display patches? How about queuing up those on the fbdev list? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/3 clock: fix DPLL rate calculation
* Paul Walmsley [EMAIL PROTECTED] [081130 23:44]:
From: Tero Kristo [EMAIL PROTECTED]
Noncore dpll can enter autoidle state, in which case the rate calculation
fails. Fixed by checking dpll mode instead of idle status.
Also, previously, the OMAP2xxx code returned the wrong value for the
DPLL rate under some conditions. Move the CORE_CLK rate recalculation
to clock24xx.c:omap2xxx_clk_get_core_rate().
This patch is a collaboration between Tero Kristo [EMAIL PROTECTED]
and Paul Walmsley [EMAIL PROTECTED]. Thanks to Peter de Schrijver
[EMAIL PROTECTED] for help debugging and Kevin Hilman
[EMAIL PROTECTED] for reporting the OMAP2 build problems with
an earlier version of this patch.
Pushing to l-o tree today.
Tony
Signed-off-by: Tero Kristo [EMAIL PROTECTED]
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
Cc: Kevin Hilman [EMAIL PROTECTED]
Cc: Peter de Schrijver [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock.c | 21 +++--
arch/arm/mach-omap2/clock.h | 15
arch/arm/mach-omap2/clock24xx.c | 39
+--
arch/arm/mach-omap2/clock24xx.h |4 ++-
arch/arm/mach-omap2/clock34xx.c |7 +++---
arch/arm/mach-omap2/sdrc2xxx.c |2 ++
arch/arm/plat-omap/include/mach/clock.h | 13 +++---
7 files changed, 62 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 42af286..e7fa9b0 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -71,10 +71,6 @@
#define DPLL_FINT_UNDERFLOW -1
#define DPLL_FINT_INVALID-2
-/* Some OMAP2xxx CM_CLKSEL_PLL.ST_CORE_CLK bits - for omap2_get_dpll_rate()
*/
-#define ST_CORE_CLK_REF 0x1
-#define ST_CORE_CLK_32K 0x3
-
/* Bitmask to isolate the register type of clk.enable_reg */
#define PRCM_REGTYPE_MASK0xf0
/* various CM register type options */
@@ -267,19 +263,20 @@ u32 omap2_get_dpll_rate(struct clk *clk)
return 0;
/* Return bypass rate if DPLL is bypassed */
- v = cm_read_mod_reg(clk-prcm_mod, dd-idlest_reg);
- v = dd-idlest_mask;
- v = __ffs(dd-idlest_mask);
+ v = cm_read_mod_reg(clk-prcm_mod, dd-control_reg);
+ v = dd-enable_mask;
+ v = __ffs(dd-enable_mask);
+
if (cpu_is_omap24xx()) {
- if (v == ST_CORE_CLK_REF)
- return clk-parent-rate; /* sys_clk */
- else if (v == ST_CORE_CLK_32K)
- return 32768;
+ if (v == OMAP2XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP2XXX_EN_DPLL_FRBYPASS)
+ return clk-parent-rate;
} else if (cpu_is_omap34xx()) {
- if (!v)
+ if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP3XXX_EN_DPLL_FRBYPASS)
return dd-bypass_clk-rate;
}
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index bcb0c03..c95e48c 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -21,6 +21,21 @@
/* The maximum error between a target DPLL rate and the rounded rate in Hz */
#define DEFAULT_DPLL_RATE_TOLERANCE 5
+/* CM_CLKSEL2_PLL.CORE_CLK_SRC bits (2XXX) */
+#define CORE_CLK_SRC_32K 0x0
+#define CORE_CLK_SRC_DPLL0x1
+#define CORE_CLK_SRC_DPLL_X2 0x2
+
+/* OMAP2xxx CM_CLKEN_PLL.EN_DPLL bits - for omap2_get_dpll_rate() */
+#define OMAP2XXX_EN_DPLL_LPBYPASS0x1
+#define OMAP2XXX_EN_DPLL_FRBYPASS0x2
+#define OMAP2XXX_EN_DPLL_LOCKED 0x3
+
+/* OMAP3xxx CM_CLKEN_PLL*.EN_*_DPLL bits - for omap2_get_dpll_rate() */
+#define OMAP3XXX_EN_DPLL_LPBYPASS0x5
+#define OMAP3XXX_EN_DPLL_FRBYPASS0x6
+#define OMAP3XXX_EN_DPLL_LOCKED 0x7
+
int omap2_clk_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 32f6632..4bd21dd 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -60,19 +60,32 @@ static struct clk *sclk;
* Omap24xx specific clock functions
*-*/
-/* This actually returns the rate of core_ck, not dpll_ck. */
-static u32 omap2_get_dpll_rate_24xx(struct clk *tclk)
+/**
+ * omap2xxx_clk_get_core_rate - return the CORE_CLK rate
+ * @clk: pointer to the combined dpll_ck + core_ck (currently dpll_ck)
+ *
+ * Returns the CORE_CLK rate. CORE_CLK can have one of three rate
+ * sources on OMAP2xxx: the DPLL CLKOUT rate, DPLL CLKOUTX2, or 32KHz
+ * (the latter is unusual). This currently should be called with
+ * struct clk *dpll_ck, which is a composite clock of dpll_ck
Re: [PATCH v2 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot
* Kevin Hilman [EMAIL PROTECTED] [081201 08:23]:
The bootloader may leave the MMC in a state which prevents hitting
retention. Even when MMC is not compiled in, each MMC module needs to
be forced into reset.
Pushing to l-o tree, and adding omap mmc queue for mainline.
Tony
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
arch/arm/mach-omap2/devices.c | 85
+
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 241e418..423647e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -14,6 +14,7 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/clk.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -358,6 +359,89 @@ static inline void omap_init_sha1_md5(void) { }
/*-*/
+#ifdef CONFIG_ARCH_OMAP3
+
+#define MMCHS_SYSCONFIG 0x0010
+#define MMCHS_SYSCONFIG_SWRESET (1 1)
+#define MMCHS_SYSSTATUS 0x0014
+#define MMCHS_SYSSTATUS_RESETDONE(1 0)
+
+static struct platform_device dummy_pdev = {
+ .dev = {
+ .bus = platform_bus_type,
+ },
+};
+
+/**
+ * omap_hsmmc_reset() - Full reset of each HS-MMC controller
+ *
+ * Ensure that each MMC controller is fully reset. Controllers
+ * left in an unknown state (by bootloader) may prevent retention
+ * or OFF-mode. This is especially important in cases where the
+ * MMC driver is not enabled, _or_ built as a module.
+ *
+ * In order for reset to work, interface, functional and debounce
+ * clocks must be enabled. The debounce clock comes from func_32k_clk
+ * and is not under SW control, so we only enable i- and f-clocks.
+ **/
+static void __init omap_hsmmc_reset(void)
+{
+ u32 i, nr_controllers = cpu_is_omap34xx() ? OMAP34XX_NR_MMC :
+ OMAP24XX_NR_MMC;
+
+ for (i = 0; i nr_controllers; i++) {
+ u32 v, base = 0;
+ struct clk *iclk, *fclk;
+ struct device *dev = dummy_pdev.dev;
+
+ switch (i) {
+ case 0:
+ base = OMAP2_MMC1_BASE;
+ break;
+ case 1:
+ base = OMAP2_MMC2_BASE;
+ break;
+ case 2:
+ base = OMAP3_MMC3_BASE;
+ break;
+ }
+
+ dummy_pdev.id = i;
+ iclk = clk_get(dev, mmchs_ick);
+ if (iclk clk_enable(iclk))
+ iclk = NULL;
+
+ fclk = clk_get(dev, mmchs_fck);
+ if (fclk clk_enable(fclk))
+ fclk = NULL;
+
+ if (!iclk || !fclk) {
+ printk(KERN_WARNING
+%s: Unable to enable clocks for MMC%d,
+cannot reset.\n, __func__, i);
+ break;
+ }
+
+ omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
+ v = omap_readl(base + MMCHS_SYSSTATUS);
+ while (!(omap_readl(base + MMCHS_SYSSTATUS)
+ MMCHS_SYSSTATUS_RESETDONE))
+ cpu_relax();
+
+ if (fclk) {
+ clk_disable(fclk);
+ clk_put(fclk);
+ }
+ if (iclk) {
+ clk_disable(iclk);
+ clk_put(iclk);
+ }
+ }
+}
+#else
+static inline void omap_hsmmc_reset(void) {}
+#endif
+
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
@@ -477,6 +561,7 @@ static int __init omap2_init_devices(void)
/* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
+ omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
--
1.6.0.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
mmc broken?
I attempted an Overo build this afternoon with fb3d15c023ff08c879155db630895f38526b95f6. I set bootargs for rootfs on mmc. The boot progresses normally and then hangs waiting for the rootfs to mount. Where I previously got: Waiting for root device /dev/mmcblk0p2... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address ee21 mmcblk0: mmc0:ee21 SU02G 1.89 GiB mmcblk0: p1 p2 I now get: Waiting for root device /dev/mmcblk0p2... Has anyone else seen mmc issues with rc7? Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[FYI PATCH] ASOC:TWL4030 Audio capture fix
A couple of folks have noticed an issue with audio capture -- the
capture result is always silence.
The patch below is a quick fix for those with this issue. There are
substantial changes to the codec driver that will be trickling down
from ASoC, and they deal with this issue differently.
So consider this as a bandaid for those who don't want to wait for the
trickle down :-)
Steve
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index ee2f0d3..8b4aafb 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -45,8 +45,8 @@ static const u8 twl4030_reg[TWL4030_CACHEREGNUM] = {
0xc3, /* REG_OPTION (0x2) */
0x00, /* REG_UNKNOWN(0x3) */
0x00, /* REG_MICBIAS_CTL(0x4) */
- 0x24, /* REG_ANAMICL(0x5) */
- 0x04, /* REG_ANAMICR(0x6) */
+ 0x34, /* REG_ANAMICL(0x5) */
+ 0x14, /* REG_ANAMICR(0x6) */
0x0a, /* REG_AVADC_CTL (0x7) */
0x00, /* REG_ADCMICSEL (0x8) */
0x00, /* REG_DIGMIXING (0x9) */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmc broken?
* Tony Lindgren [EMAIL PROTECTED] [081205 16:34]:
* Steve Sakoman [EMAIL PROTECTED] [081205 16:31]:
I attempted an Overo build this afternoon with
fb3d15c023ff08c879155db630895f38526b95f6.
I set bootargs for rootfs on mmc. The boot progresses normally and
then hangs waiting for the rootfs to mount.
Where I previously got:
Waiting for root device /dev/mmcblk0p2...
mmc0: host does not support reading read-only switch. assuming
write-enable.
mmc0: new SD card at address ee21
mmcblk0: mmc0:ee21 SU02G 1.89 GiB
mmcblk0: p1 p2
I now get:
Waiting for root device /dev/mmcblk0p2...
Has anyone else seen mmc issues with rc7?
I think I did it again while cleaning up.. Can you try this patch?
The name was conflicting with the other MMC omap driver.
Actually now it breaks for earlier omaps, it needs to be like this
patch instead.
Tony
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 25c6d10..2c3c72f 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -204,9 +204,15 @@ int __init omap_mmc_add(int id, unsigned long base, unsigned long size,
{
struct platform_device *pdev;
struct resource res[OMAP_MMC_NR_RES];
+ char *name;
int ret;
- pdev = platform_device_alloc(mmci-omap, id);
+ if (cpu_class_is_omap1() || cpu_is_omap242x())
+ name = mmci-omap;
+ else
+ name = mmci-omap-hs;
+
+ pdev = platform_device_alloc(name, id);
if (!pdev)
return -ENOMEM;
Re: mmc broken?
On Fri, Dec 5, 2008 at 4:49 PM, Tony Lindgren [EMAIL PROTECTED] wrote: * Tony Lindgren [EMAIL PROTECTED] [081205 16:34]: * Steve Sakoman [EMAIL PROTECTED] [081205 16:31]: I attempted an Overo build this afternoon with fb3d15c023ff08c879155db630895f38526b95f6. I set bootargs for rootfs on mmc. The boot progresses normally and then hangs waiting for the rootfs to mount. Where I previously got: Waiting for root device /dev/mmcblk0p2... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address ee21 mmcblk0: mmc0:ee21 SU02G 1.89 GiB mmcblk0: p1 p2 I now get: Waiting for root device /dev/mmcblk0p2... Has anyone else seen mmc issues with rc7? I think I did it again while cleaning up.. Can you try this patch? The name was conflicting with the other MMC omap driver. Actually now it breaks for earlier omaps, it needs to be like this patch instead. Heh, isn't that how it always goes! Two steps forward, one step back :-) I tested your first patch and it did indeed solve the issue. Looks like your second patch will also work. I'll verify this later this evening. Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()
On Fri, 5 Dec 2008, Tony Lindgren wrote: Pushing both to l-o tree today. Paul, I take it you will queue these up for mainline via your clock series? Yes, and that will go for any other clock patches that you push into l-o between now and the time that I send that series to Russell. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()
* Paul Walmsley [EMAIL PROTECTED] [081205 17:04]: On Fri, 5 Dec 2008, Tony Lindgren wrote: Pushing both to l-o tree today. Paul, I take it you will queue these up for mainline via your clock series? Yes, and that will go for any other clock patches that you push into l-o between now and the time that I send that series to Russell. OK, so I'll push the clock patches from Kevin's queue posted on Monday to l-o, and then at some point we'll switch to your clock queue for l-o tree. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmc broken?
* Steve Sakoman [EMAIL PROTECTED] [081205 17:01]: On Fri, Dec 5, 2008 at 4:49 PM, Tony Lindgren [EMAIL PROTECTED] wrote: * Tony Lindgren [EMAIL PROTECTED] [081205 16:34]: * Steve Sakoman [EMAIL PROTECTED] [081205 16:31]: I attempted an Overo build this afternoon with fb3d15c023ff08c879155db630895f38526b95f6. I set bootargs for rootfs on mmc. The boot progresses normally and then hangs waiting for the rootfs to mount. Where I previously got: Waiting for root device /dev/mmcblk0p2... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address ee21 mmcblk0: mmc0:ee21 SU02G 1.89 GiB mmcblk0: p1 p2 I now get: Waiting for root device /dev/mmcblk0p2... Has anyone else seen mmc issues with rc7? I think I did it again while cleaning up.. Can you try this patch? The name was conflicting with the other MMC omap driver. Actually now it breaks for earlier omaps, it needs to be like this patch instead. Heh, isn't that how it always goes! Two steps forward, one step back :-) :) I tested your first patch and it did indeed solve the issue. Looks like your second patch will also work. I'll verify this later this evening. Pushed it already, seems to work. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP Zoom kernel ALSA build problem
* David Brownell [EMAIL PROTECTED] [081205 15:36]:
On Thursday 04 December 2008, Tony Lindgren wrote:
So for example the NAND acceleration stuff seems to have gone
nowhere ... while that ZOOM fork may have some updates, they've not
gotten into the main OMAP tree, or into mainline.
That is frustrating. People at TI _should_ be working on sending
patches from zoom to upstream.
Or even just getting their goodness into the linux-omap tree,
as a first step towards getting upstream.
I used the OMAP3 NAND stuff as an example, since we saw a few
(unmergeable) patches but then everything seemed to fizzle.
Well if somebody does a nand branch against the mainline tree
that we can automerge to l-o tree on daily basis, sure :)
Sure the other people can also
produce patches against the mainline and linux-omap kernel out
of the zoom tree.
That would require people to track the ZOOM kernels, as well
as mainline and linux-omap (and their own patch queues).
Not too realistic.
Yeah well drivers are easier as they should be just patches
against the mainline tree.
In general, here's how the patch flow needs to happen:
- All driver patches need to be posted to the right driver mailing
lists with linux-omap mailing list Cc'd. The patches need need
to be against the mainline kernel tree. The recent developments
with the ASoC and the new fb/v4l code is a good example how this
is working.
Yes. And in the case of stuff like NAND, where there's a ZOOM
driver and a Linux-OMAP driver but nothing in mainline, I suggest
syncing those two *before* pushing to mainline ... though there
may well be a case for involving the relevant mainline team at
that point too, or ignoring one driver.
Sure.
- All core omap code needs to be posted to linux-omap for review
and will then be queued up into going into the mainline tree.
For any patches that apply already into the mainline kernel,
the patches need to be against the mainline kernel. For any
more complex patches, also linux-arm-kernel and maybe LKML lists
should be Cc'd.
Yep, that's straightforward. By core I presume you mean
arch/arm/plat-omap or maybe mach-omap{1,2}.
Yup.
Soonish the linux-omap tree will become just a queue for patches
for the merge windows. So essentially we'll be using the mainline
kernel with some branches automerged hopefully real-soon-now.
That sounds like an interesting plan. It'll cause some level
of disruption ... which we probably need to have, since without
it folk seem to have little incentive to track mainline.
A slightly different spin: treat every divergence from mainline
as a bug that needs fixing. Those branches should mostly have
fairly short lifespans...
Yeah, and they should be against the mainline tree so they're
ready for merging when the time is right.
I think the right time to make that switch after Paul's clock
patches are integrated into the mainline kernel. Then we'll move
the non-mainline code into their own branches, or just drop it
if nobody wants to maintain it.
Sounds like a plan. Let's see how different the OMAP tree is
from mainline at that point, and see what the branches will be.
Sounds like clocks and pm branches, then maybe usb, nand, alsa
as needed. And dspgateway branch and dspbridge branch. And then
maybe also twl4030 branch, hehe :)
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()
Tony Lindgren [EMAIL PROTECTED] writes: * Paul Walmsley [EMAIL PROTECTED] [081205 15:52]: On Tue, 21 Oct 2008, Mans Rullgard wrote: Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Måns, sorry this took so long, these two patches slipped through the cracks here. Pushing both to l-o tree today. Paul, I take it you will queue these up for mainline via your clock series? Måns, I heard you have some display patches? How about queuing up those on the fbdev list? It looks like Tomi's driver is shaping up nicely, so it's probably not worthwhile spending any significant time on the current driver. If anyone is interested, everything I have is in my git tree. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Branch for fbdriver (Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate())
* Måns Rullgård [EMAIL PROTECTED] [081205 17:40]: Tony Lindgren [EMAIL PROTECTED] writes: * Paul Walmsley [EMAIL PROTECTED] [081205 15:52]: On Tue, 21 Oct 2008, Mans Rullgard wrote: Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Måns, sorry this took so long, these two patches slipped through the cracks here. Pushing both to l-o tree today. Paul, I take it you will queue these up for mainline via your clock series? Måns, I heard you have some display patches? How about queuing up those on the fbdev list? It looks like Tomi's driver is shaping up nicely, so it's probably not worthwhile spending any significant time on the current driver. If anyone is interested, everything I have is in my git tree. OK, good to know. Tomi, do you have a git branch against the mainline kernel for your driver? We could start mirroring it on linux-omap and then start automerging it on daily basis to linux-omap for testing (Assuming it does not cause problems with other stuff :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] OMAP3: PM: Force IVA2 into idle during bootup
Hi Kevin,
one quick comment.
On Mon, 1 Dec 2008, Kevin Hilman wrote:
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
arch/arm/mach-omap2/pm34xx.c | 55
+
arch/arm/plat-omap/include/mach/control.h |5 +++
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bd74183..6ff6449 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
#include mach/pm.h
#include mach/clockdomain.h
#include mach/powerdomain.h
+#include mach/control.h
#include cm.h
#include cm-regbits-34xx.h
@@ -363,6 +364,58 @@ static struct platform_suspend_ops omap_pm_ops = {
.valid = suspend_valid_only_mem,
};
+
+/**
+ * omap3_iva_idle(): ensure IVA is in idle so it can be put into
+ * retention
+ *
+ * In cases where IVA2 is activated by bootcode, it may prevent
+ * full-chip retention or off-mode because it is not idle. This
+ * function forces the IVA2 into idle state so it can go
+ * into retention/off and thus allow full-chip retention/off.
+ *
+ **/
+static void __init omap3_iva_idle(void)
+{
+ struct clk *iva2_ck;
+
+ iva2_ck = clk_get(NULL, iva2_fclk);
This should be iva2_fck, right?
+ if (!iva2_ck) {
+ pr_err(Unable to get IVA2 fclk: cannot force idle.\n);
+ return;
+ }
+
+ /* Disable IVA2 clock */
+ clk_disable(iva2_ck);
+
+ /* Reset IVA2 */
+ prm_write_mod_reg(OMAP3430_RST1_IVA2 |
+ OMAP3430_RST2_IVA2 |
+ OMAP3430_RST3_IVA2,
+ OMAP3430_IVA2_MOD, RM_RSTCTRL);
+
+ /* Enable IVA2 clock */
+ clk_enable(iva2_ck);
+
+ /* Set IVA2 boot mode to 'idle' */
+ omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
+ OMAP343X_CONTROL_IVA2_BOOTMOD);
+
+ /* Un-reset IVA2 */
+ prm_write_mod_reg(0, OMAP3430_IVA2_MOD, RM_RSTCTRL);
+
+ /* Disable IVA2 clocks */
+ clk_disable(iva2_ck);
+
+ /* Reset IVA2 */
+ prm_write_mod_reg(OMAP3430_RST1_IVA2 |
+ OMAP3430_RST2_IVA2 |
+ OMAP3430_RST3_IVA2,
+ OMAP3430_IVA2_MOD, RM_RSTCTRL);
+
+ clk_put(iva2_ck);
+}
+
static void __init prcm_setup_regs(void)
{
/* XXX Reset all wkdeps. This should be done when initializing
@@ -514,6 +567,8 @@ static void __init prcm_setup_regs(void)
* it is selected to mpu wakeup goup */
prm_write_mod_reg(OMAP3430_IO_EN | OMAP3430_WKUP_EN,
OCP_MOD, OMAP2_PRM_IRQENABLE_MPU_OFFSET);
+
+ omap3_iva_idle();
}
static int __init pwrdms_setup(struct powerdomain *pwrdm)
diff --git a/arch/arm/plat-omap/include/mach/control.h
b/arch/arm/plat-omap/include/mach/control.h
index ee3c39e..b51f7fd 100644
--- a/arch/arm/plat-omap/include/mach/control.h
+++ b/arch/arm/plat-omap/include/mach/control.h
@@ -208,6 +208,11 @@
#define OMAP2_PBIASLITEPWRDNZ0 (1 1)
#define OMAP2_PBIASLITEVMODE0(1 0)
+/* CONTROL_IVA2_BOOTMOD bits */
+#define OMAP3_IVA2_BOOTMOD_SHIFT 0
+#define OMAP3_IVA2_BOOTMOD_MASK (0xf 0)
+#define OMAP3_IVA2_BOOTMOD_IDLE (0x1 0)
+
#ifndef __ASSEMBLY__
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
extern void __iomem *omap_ctrl_base_get(void);
--
1.6.0.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] OMAP3: PM: HSMMC: force MMC module reset on boot
Hi Kevin,
another quick comment ...
On Mon, 1 Dec 2008, Kevin Hilman wrote:
The bootloader may leave the MMC in a state which prevents hitting
retention. Even when MMC is not compiled in, each MMC module needs to
be forced into reset.
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
arch/arm/mach-omap2/devices.c | 85
+
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 241e418..423647e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -14,6 +14,7 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/clk.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -358,6 +359,89 @@ static inline void omap_init_sha1_md5(void) { }
/*-*/
+#ifdef CONFIG_ARCH_OMAP3
+
+#define MMCHS_SYSCONFIG 0x0010
+#define MMCHS_SYSCONFIG_SWRESET (1 1)
+#define MMCHS_SYSSTATUS 0x0014
+#define MMCHS_SYSSTATUS_RESETDONE(1 0)
+
+static struct platform_device dummy_pdev = {
+ .dev = {
+ .bus = platform_bus_type,
+ },
+};
+
+/**
+ * omap_hsmmc_reset() - Full reset of each HS-MMC controller
+ *
+ * Ensure that each MMC controller is fully reset. Controllers
+ * left in an unknown state (by bootloader) may prevent retention
+ * or OFF-mode. This is especially important in cases where the
+ * MMC driver is not enabled, _or_ built as a module.
+ *
+ * In order for reset to work, interface, functional and debounce
+ * clocks must be enabled. The debounce clock comes from func_32k_clk
+ * and is not under SW control, so we only enable i- and f-clocks.
+ **/
+static void __init omap_hsmmc_reset(void)
+{
+ u32 i, nr_controllers = cpu_is_omap34xx() ? OMAP34XX_NR_MMC :
+ OMAP24XX_NR_MMC;
+
+ for (i = 0; i nr_controllers; i++) {
+ u32 v, base = 0;
+ struct clk *iclk, *fclk;
+ struct device *dev = dummy_pdev.dev;
+
+ switch (i) {
+ case 0:
+ base = OMAP2_MMC1_BASE;
+ break;
+ case 1:
+ base = OMAP2_MMC2_BASE;
+ break;
+ case 2:
+ base = OMAP3_MMC3_BASE;
+ break;
+ }
+
+ dummy_pdev.id = i;
+ iclk = clk_get(dev, mmchs_ick);
+ if (iclk clk_enable(iclk))
+ iclk = NULL;
+
+ fclk = clk_get(dev, mmchs_fck);
+ if (fclk clk_enable(fclk))
+ fclk = NULL;
+
+ if (!iclk || !fclk) {
+ printk(KERN_WARNING
+%s: Unable to enable clocks for MMC%d,
+cannot reset.\n, __func__, i);
+ break;
+ }
+
+ omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
+ v = omap_readl(base + MMCHS_SYSSTATUS);
+ while (!(omap_readl(base + MMCHS_SYSSTATUS)
+ MMCHS_SYSSTATUS_RESETDONE))
+ cpu_relax();
I think Tony is trying to banish omap_{read,write}*(); so these should
probably be __raw_{read,write}l() with IO_ADDRESS() or maybe ioremap().
+
+ if (fclk) {
+ clk_disable(fclk);
+ clk_put(fclk);
+ }
+ if (iclk) {
+ clk_disable(iclk);
+ clk_put(iclk);
+ }
+ }
+}
+#else
+static inline void omap_hsmmc_reset(void) {}
+#endif
+
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
@@ -477,6 +561,7 @@ static int __init omap2_init_devices(void)
/* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
+ omap_hsmmc_reset();
omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
--
1.6.0.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] OMAP3: PM: Add D2D clocks and auto-idle setup to PRCM init
On Mon, 1 Dec 2008, Kevin Hilman wrote: Add D2D clocks (modem_fck, sad2d_ick, mad2d_ick) to clock framework, and also ensure that auto-idle bits are set for these clocks during PRCM init. Signed-off-by: Kevin Hilman [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] OMAP3: PM: D2D clockdomain supports SW supervised transitions
On Mon, 1 Dec 2008, Kevin Hilman wrote:
Signed-off-by: Kevin Hilman [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clockdomains.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index bafa650..49a5774 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -198,7 +198,7 @@ static struct clockdomain sgx_clkdm = {
static struct clockdomain d2d_clkdm = {
.name = d2d_clkdm,
.pwrdm = { .name = core_pwrdm },
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES1_CLKTRCTRL_D2D_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
Acked-by: Paul Walmsley [EMAIL PROTECTED]
might be nice to have a short commit msg.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP2: PM: fix fault in enter_full_retention()
In omap24xx_cpu_suspend assembly routine, the r2 register which holds the address of the SDRC_POWER reg is set to zero before the value is written back triggering a fault due to writing to address zero. It's hard to tell where this change was introduced since this file has been moved and merged. While this fix prevents a crash, suspend on my n810 is broken with current kernels. I never come out of suspend. Signed-off-by: Kevin Hilman [EMAIL PROTECTED] --- arch/arm/mach-omap2/sleep24xx.S |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S index 43336b9..bf9e961 100644 --- a/arch/arm/mach-omap2/sleep24xx.S +++ b/arch/arm/mach-omap2/sleep24xx.S @@ -93,9 +93,8 @@ ENTRY(omap24xx_cpu_suspend) orr r4, r4, #0x40 @ enable self refresh on idle req mov r5, #0x2000 @ set delay (DPLL relock + DLL relock) str r4, [r2]@ make it so - mov r2, #0 nop - mcr p15, 0, r2, c7, c0, 4 @ wait for interrupt + mcr p15, 0, r3, c7, c0, 4 @ wait for interrupt nop loop: subsr5, r5, #0x1@ awake, wait just a bit -- 1.6.0.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
