Re: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for oprofile
Hi Siarhei,
Could you let me know the advantage of the this patch over timer interrupt
based profiling already supported by oprofile. I tested timer interrupt
based
profiling on omap3 platform and found that it works well.
Thanks
Hemanth
http://oprofile.sourceforge.net/doc/detailed-parameters.html#timer
4.3. OProfile in timer interrupt mode
Note
This section applies to 2.6 kernels and above only.
In 2.6 kernels on CPUs without OProfile support for the hardware performance
counters, the driver falls back to using the timer interrupt for profiling.
Like the RTC mode in 2.4 kernels, this is not able to profile code that has
interrupts disabled. Note that there are no configuration parameters for
setting this, unlike the RTC and hardware performance counter setup.
You can force use of the timer interrupt by using the timer=1 module
parameter (or oprofile.timer=1 on the boot command line if OProfile is
built-in).
- Original Message -
From: Siarhei Siamashka siarhei.siamas...@nokia.com
To: linux-arm-ker...@lists.arm.linux.org.uk
Cc: linux-omap@vger.kernel.org; oprofile-l...@lists.sourceforge.net
Sent: Thursday, January 29, 2009 8:51 AM
Subject: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for
oprofile
Signed-off-by: Siarhei Siamashka siarhei.siamas...@nokia.com
---
A second revision of gptimer oprofile patch
http://marc.info/?l=linux-omapm=123143937515088w=2
with the fixes suggested by Tony Lindgren
Timers from the CORE domain seem to work best on OMAP3.
Also tested the patch on Nokia 770 (OMAP1710).
Please let me know if anything else needs to be fixed.
arch/arm/Kconfig |6 ++
arch/arm/oprofile/Makefile|1 +
arch/arm/oprofile/common.c|5 ++
arch/arm/oprofile/op_arm_model.h |2 +
arch/arm/oprofile/op_model_omap_gptimer.c | 93
+
5 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/oprofile/op_model_omap_gptimer.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7fb201..8774136 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -160,6 +160,12 @@ config GENERIC_HARDIRQS_NO__DO_IRQ
if OPROFILE
+config OPROFILE_OMAP_GPTIMER
+ def_bool y
+ depends on ARCH_OMAP
+ select CONFIG_OMAP_32K_TIMER
+ select CONFIG_OMAP_DM_TIMER
+
config OPROFILE_ARMV6
def_bool y
depends on CPU_V6 !SMP
diff --git a/arch/arm/oprofile/Makefile b/arch/arm/oprofile/Makefile
index 88e31f5..fc2bc02 100644
--- a/arch/arm/oprofile/Makefile
+++ b/arch/arm/oprofile/Makefile
@@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
oprofile-$(CONFIG_CPU_XSCALE) += op_model_xscale.o
+oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER) += op_model_omap_gptimer.o
oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o
oprofile-$(CONFIG_OPROFILE_ARMV6) += op_model_v6.o
oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 3fcd752..add3cb4 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -133,6 +133,11 @@ int __init oprofile_arch_init(struct
oprofile_operations *ops)
ops-backtrace = arm_backtrace;
+/* comes first, so that it can be overrided by a better implementation */
+#ifdef CONFIG_OPROFILE_OMAP_GPTIMER
+ spec = op_omap_gptimer_spec;
+#endif
+
#ifdef CONFIG_CPU_XSCALE
spec = op_xscale_spec;
#endif
diff --git a/arch/arm/oprofile/op_arm_model.h
b/arch/arm/oprofile/op_arm_model.h
index 8c4e4f6..db936da 100644
--- a/arch/arm/oprofile/op_arm_model.h
+++ b/arch/arm/oprofile/op_arm_model.h
@@ -24,6 +24,8 @@ struct op_arm_model_spec {
extern struct op_arm_model_spec op_xscale_spec;
#endif
+extern struct op_arm_model_spec op_omap_gptimer_spec;
+
extern struct op_arm_model_spec op_armv6_spec;
extern struct op_arm_model_spec op_mpcore_spec;
extern struct op_arm_model_spec op_armv7_spec;
diff --git a/arch/arm/oprofile/op_model_omap_gptimer.c
b/arch/arm/oprofile/op_model_omap_gptimer.c
new file mode 100644
index 000..98f7d2b
--- /dev/null
+++ b/arch/arm/oprofile/op_model_omap_gptimer.c
@@ -0,0 +1,93 @@
+/**
+ * OMAP gptimer based event monitor driver for oprofile
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Siarhei Siamashka siarhei.siamas...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/types.h
+#include linux/oprofile.h
+#include linux/interrupt.h
+#include linux/irq.h
+
+#include mach/dmtimer.h
+
+#include op_counter.h
+#include op_arm_model.h
+
+static struct omap_dm_timer *gptimer;
+
+static int gptimer_init(void)
+{
+ return 0;
+}
+
+static int gptimer_setup(void)
+{
+ return 0;
+}
+
+static irqreturn_t gptimer_interrupt(int irq, void *arg)
+{
+ omap_dm_timer_write_status(gptimer,
Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2246,11 +2246,13 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device *pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2266,9 +2268,9 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_info.vid_dev = vid_dev;
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
- vout-vid_info.id = k + 1;
+ vout-vid_info.id = k + vout_count;
vid_dev-num_videos++;
/* Setup the default configuration for the video devices
@@ -2289,7 +2291,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count) 0) {
printk(KERN_ERR VOUT_NAME : could not register \
Video for Linux device\n);
vfd-minor = -1;
2009/4/22 Shah, Hardik hardik.s...@ti.com:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, April 22, 2009 1:53 PM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565
4. Supports Alpha blending.
5. Supports Color keying both source and destination.
6. Supports rotation with RGB565 and RGB32 pixels formats.
7. Supports cropping.
8. Supports Background color setting.
9. Works on latest DSS2 library from Tomi
http://www.bat.org/~tomba/git/linux-omap-dss.git/
10. 1/4x scaling added. Detail testing left
TODOS
1. Ioctls needs to be added for color space conversion matrix
coefficient programming.
2. To be tested on DVI resolutions.
Comments fixed from community.
1. V4L2 Driver for OMAP3/3 DSS.
2. Conversion of the custom ioctls to standard V4L2 ioctls like alpha
blending,
color keying, rotation and back ground color setting
3. Re-organised the code as per community comments.
4. Added proper copyright year.
5. Added module name in printk
6. Kconfig option copy/paste error
7. Module param desc addded.
8. Query control implemented using standard query_fill
9. Re-arranged if-else constructs.
10. Changed to use mutex instead of semaphore.
11. Removed dual usage of rotation angles.
12. Implemented function to convert the V4L2 angle to DSS angle.
13. Y-position was set half by video driver for TV output
Now its done by DSS so removed that.
14. Minor cleanup
15. Added support to pass the page offset to application.
14. Minor cleanup
15. Added support to pass the page
RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2246,11 +2246,13 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device
*pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2266,9 +2268,9 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_info.vid_dev = vid_dev;
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
- vout-vid_info.id = k + 1;
+ vout-vid_info.id = k + vout_count;
vid_dev-num_videos++;
/* Setup the default configuration for the video devices
@@ -2289,7 +2291,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count)
0) {
printk(KERN_ERR VOUT_NAME : could not register \
Video for Linux device\n);
vfd-minor = -1;
2009/4/22 Shah, Hardik hardik.s...@ti.com:
[Shah, Hardik] Yes this is correct,
I will apply this patch. I already found it and fixed it in different way but
any way I will apply your patch.
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, April 22, 2009 1:53 PM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565
4. Supports Alpha blending.
5. Supports Color keying both source and destination.
6. Supports rotation with RGB565 and RGB32 pixels formats.
7. Supports cropping.
8. Supports Background color setting.
9. Works on latest DSS2 library from Tomi
http://www.bat.org/~tomba/git/linux-omap-dss.git/
10. 1/4x scaling added. Detail testing left
TODOS
1. Ioctls needs to be added for color space conversion matrix
coefficient programming.
2. To be tested on DVI resolutions.
Comments fixed from community.
1. V4L2 Driver for OMAP3/3 DSS.
2. Conversion of the custom ioctls to standard V4L2 ioctls like alpha
blending,
color keying, rotation and back ground color setting
3. Re-organised the code as per community comments.
4. Added proper copyright year.
5. Added module name in printk
6. Kconfig option copy/paste
Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to gpmc-onenand.c
'gpmc-onenand.c' is still confusing name. This is not going to used in
all boards anyway.
On Thu, Apr 30, 2009 at 3:20 AM, Tony Lindgren t...@atomide.com wrote:
Rename board-n800-flash.c to gpmc-onenand.c.
Signed-off-by: Tony Lindgren t...@atommide.com
---
arch/arm/mach-omap2/Makefile |4 ++--
arch/arm/mach-omap2/gpmc-onenand.c |0
2 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/mach-omap2/{board-n800-flash.c = gpmc-onenand.c} (100%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 76acefa..9127a94 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -55,14 +55,14 @@ obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
board-apollon-mmc.o \
board-apollon-keys.o
-obj-$(CONFIG_MACH_NOKIA_N800) += board-n800.o board-n800-flash.o \
+obj-$(CONFIG_MACH_NOKIA_N800) += board-n800.o gpmc-onenand.o \
board-n800-mmc.o board-n800-bt.o \
board-n800-usb.o \
board-n800-dsp.o \
board-n800-camera.o
obj-$(CONFIG_MACH_NOKIA_N810) += board-n810.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
- board-n800-flash.o \
+ gpmc-onenand.o \
board-rx51-flash.o \
board-rx51-sdram.o \
board-rx51-video.o \
diff --git a/arch/arm/mach-omap2/board-n800-flash.c
b/arch/arm/mach-omap2/gpmc-onenand.c
similarity index 100%
rename from arch/arm/mach-omap2/board-n800-flash.c
rename to arch/arm/mach-omap2/gpmc-onenand.c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
---
Regards,
\/ | |\/| /-\ |_
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
Hi Kevin, Thank you for showing steady interest in this driver. On Tue, Apr 21, 2009 at 9:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Kyuwon, While I still like the concept of this driver, I'm still not quite happy about how it is implemented for various reasons. Most of which have to do with the fact that this driver does many things that really should be the job of other layers. In particular, the list of omap3_wake_events is a bit troubling. It really should be handled by the omapdev layer. You'll see that you are duplicating the data that is handled there. Rather, we should just extend the omapdev data to handle the wakeup events for that device. If you allow me to insert a new field whose name is mask in the omapdev struct, I think I can extend the omapdev to handle the wakeup events. Also, I still think the WKST register reading should be done in the PRCM interrupt handler. In your previous attempt, you were seeing a bunch of non-device wakeup related interrupts. Can you try again with the attached patch (thanks to Paul Walmseley) which should help us debug why you were seeing spurious PRCM interrupts. First of all, sorry for giving you the wrong information in the previous mail. I found that we actually have configured GPTIMER12 as the system timer. And I tried with the attached patch, but I can't see any debug message. However even now, PRCM interrupt handler is invoked quite often due to the system timer. As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new lower-latency C1 state] patch is applied, the system is in 'wfi' state in every idle state. So whenever the system timer wake up the system from idle, I think PRCM interrupt occurs. Do you think still the WKST register should be read in the PRCM interrupt handler? ;) Also, I know we discussed this before, but I think the GPIO wakeup source stuff really belongs in a separate patch, and if you think it is still useful, and cannot be done by just enabling a GPIO IRQ from the board file, I suggest you propose a patch to the generic GPIO layer to add this interface. OK, I will remove this GPIO wakeup feature. But I want to know more detailed information about wakeup event . So, instead of using the GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x registers. diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index cb1ae84..1f340aa 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -273,6 +273,10 @@ #define OMAP3430_ST_D2D_SHIFT3 #define OMAP3430_ST_D2D_MASK (1 3) +/* PM_WKST3_CORE, CM_IDLEST3_CORE shared bits */ +#define OMAP3430_ST_USBTLL_SHIFT 2 +#define OMAP3430_ST_USBTLL_MASK (1 2) + /* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */ #define OMAP3430_EN_GPIO1(1 3) #define OMAP3430_EN_GPIO1_SHIFT 3 diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h b/arch/arm/mach-omap2/prm-regbits-34xx.h index 06fee29..f0a6395 100644 --- a/arch/arm/mach-omap2/prm-regbits-34xx.h +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h @@ -332,6 +332,8 @@ /* PM_IVA2GRPSEL1_CORE specific bits */ /* PM_WKST1_CORE specific bits */ +#define OMAP3430_ST_MMC3_SHIFT 30 +#define OMAP3430_ST_MMC3_MASK(1 30) /* PM_PWSTCTRL_CORE specific bits */ #define OMAP3430_MEM2ONSTATE_SHIFT 18 @@ -432,6 +434,9 @@ /* PM_PREPWSTST_PER specific bits */ +/* PM_WKST_USBHOST specific bits */ +#define OMAP3430_ST_USBHOST (1 0) + /* RM_RSTST_EMU specific bits */ All these new bit defines should all be 3430ES2_*. OK, I will fix it. Thanks Regards, Kyuwon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for oprofile
On Thursday 30 April 2009 09:08:12 ext Hemanth V wrote:
Hi Siarhei,
Could you let me know the advantage of the this patch over timer interrupt
based profiling already supported by oprofile. I tested timer interrupt
based
profiling on omap3 platform and found that it works well.
A standard timer interrupt is reliable. But it only provides a single
non-configurable samples collection frequency, which is way too low for
the real practical use.
If you or anybody else knows a way to boost standard oprofile timer samples
collection frequency to something like 2-4KHz or higher without impacting the
rest of the system at all when oprofile is not active (and having very low
overhead when oprofile is used), this would solve all the problems.
Best regards,
Siarhei Siamashka
Thanks
Hemanth
http://oprofile.sourceforge.net/doc/detailed-parameters.html#timer
4.3. OProfile in timer interrupt mode
Note
This section applies to 2.6 kernels and above only.
In 2.6 kernels on CPUs without OProfile support for the hardware
performance counters, the driver falls back to using the timer interrupt
for profiling. Like the RTC mode in 2.4 kernels, this is not able to
profile code that has interrupts disabled. Note that there are no
configuration parameters for setting this, unlike the RTC and hardware
performance counter setup.
You can force use of the timer interrupt by using the timer=1 module
parameter (or oprofile.timer=1 on the boot command line if OProfile is
built-in).
- Original Message -
From: Siarhei Siamashka siarhei.siamas...@nokia.com
To: linux-arm-ker...@lists.arm.linux.org.uk
Cc: linux-omap@vger.kernel.org; oprofile-l...@lists.sourceforge.net
Sent: Thursday, January 29, 2009 8:51 AM
Subject: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for
oprofile
Signed-off-by: Siarhei Siamashka siarhei.siamas...@nokia.com
---
A second revision of gptimer oprofile patch
http://marc.info/?l=linux-omapm=123143937515088w=2
with the fixes suggested by Tony Lindgren
Timers from the CORE domain seem to work best on OMAP3.
Also tested the patch on Nokia 770 (OMAP1710).
Please let me know if anything else needs to be fixed.
arch/arm/Kconfig |6 ++
arch/arm/oprofile/Makefile|1 +
arch/arm/oprofile/common.c|5 ++
arch/arm/oprofile/op_arm_model.h |2 +
arch/arm/oprofile/op_model_omap_gptimer.c | 93
+
5 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/oprofile/op_model_omap_gptimer.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7fb201..8774136 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -160,6 +160,12 @@ config GENERIC_HARDIRQS_NO__DO_IRQ
if OPROFILE
+config OPROFILE_OMAP_GPTIMER
+ def_bool y
+ depends on ARCH_OMAP
+ select CONFIG_OMAP_32K_TIMER
+ select CONFIG_OMAP_DM_TIMER
+
config OPROFILE_ARMV6
def_bool y
depends on CPU_V6 !SMP
diff --git a/arch/arm/oprofile/Makefile b/arch/arm/oprofile/Makefile
index 88e31f5..fc2bc02 100644
--- a/arch/arm/oprofile/Makefile
+++ b/arch/arm/oprofile/Makefile
@@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
oprofile-$(CONFIG_CPU_XSCALE) += op_model_xscale.o
+oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER) += op_model_omap_gptimer.o
oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o
oprofile-$(CONFIG_OPROFILE_ARMV6) += op_model_v6.o
oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 3fcd752..add3cb4 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -133,6 +133,11 @@ int __init oprofile_arch_init(struct
oprofile_operations *ops)
ops-backtrace = arm_backtrace;
+/* comes first, so that it can be overrided by a better implementation
*/ +#ifdef CONFIG_OPROFILE_OMAP_GPTIMER
+ spec = op_omap_gptimer_spec;
+#endif
+
#ifdef CONFIG_CPU_XSCALE
spec = op_xscale_spec;
#endif
diff --git a/arch/arm/oprofile/op_arm_model.h
b/arch/arm/oprofile/op_arm_model.h
index 8c4e4f6..db936da 100644
--- a/arch/arm/oprofile/op_arm_model.h
+++ b/arch/arm/oprofile/op_arm_model.h
@@ -24,6 +24,8 @@ struct op_arm_model_spec {
extern struct op_arm_model_spec op_xscale_spec;
#endif
+extern struct op_arm_model_spec op_omap_gptimer_spec;
+
extern struct op_arm_model_spec op_armv6_spec;
extern struct op_arm_model_spec op_mpcore_spec;
extern struct op_arm_model_spec op_armv7_spec;
diff --git a/arch/arm/oprofile/op_model_omap_gptimer.c
b/arch/arm/oprofile/op_model_omap_gptimer.c
new file mode 100644
index 000..98f7d2b
--- /dev/null
+++ b/arch/arm/oprofile/op_model_omap_gptimer.c
@@ -0,0 +1,93 @@
+/**
+ * OMAP gptimer based event monitor driver for oprofile
+ *
+ *
Re: Overo broken with current top of tree
On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman sako...@gmail.com wrote: I tried an Overo build from the current top of tree and ran into a number of twl4030 platform data errors: twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030_gpio: use which platform_data? twl4030: gpio (irq 368) chaining IRQs 384..401 mmci-omap-hs.0: use which platform_data? mmci-omap-hs.1: use which platform_data? twl4030_usb: use which platform_data? twl4030_reg.6: use which platform_data? regulator: VMMC1: 1850 -- 3150 mV normal standby twl4030_reg.17: use which platform_data? set_machine_constraints: invalid 'VUSB1V5' voltage constraints twl4030_reg twl4030_reg.17: can't register VUSB1V5, -22 twl4030_reg: probe of twl4030_reg.17 failed with error -22 twl4030_reg.18: use which platform_data? set_machine_constraints: invalid 'VUSB1V8' voltage constraints twl4030_reg twl4030_reg.18: can't register VUSB1V8, -22 twl4030_reg: probe of twl4030_reg.18 failed with error -22 twl4030_reg.19: use which platform_data? set_machine_constraints: invalid 'VUSB3V1' voltage constraints twl4030_reg twl4030_reg.19: can't register VUSB3V1, -22 twl4030_reg: probe of twl4030_reg.19 failed with error -22 i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz SCSI subsystem initialized twl4030_usb twl4030_usb: ldo init failed Before I go digging, have there been any recent changes in 4030 init that require me to update the Overo board file? I get the same on pandora, although it continues booting fine after that. Maybe regulator folks will comment about regulator errors. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: sDMA: Correct the the omap_request_dma_chain() signature
From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Thursday, April 30, 2009 3:06 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: sDMA: Correct the the omap_request_dma_chain() signature On Thu, Apr 30, 2009 at 12:18 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Yor tow commentsI think I answered both.Just a correction you comment itself. You mean callback gets lch instead of chain_id as an argument? You mean callback returns *** lch instead of chain_id as an argument? I mean argument passed to the callback. Callback is void so not returning anything. if (likely(dma_chan[ch].callback != NULL)) dma_chan[ch].callback(ch, status, dma_chan[ch].data); My ***return ** was from the dma user point of view and not the fucntion return :). Anyway the point is callback first argument is dma channel nubmer and not chain_id. So User will get the channel number and not chain_id via callback. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Shah, Hardik
Sent: Thursday, April 30, 2009 11:51 AM
To: InKi Dae
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
-Original Message-
From: InKi Dae [mailto:daei...@gmail.com]
Sent: Thursday, April 30, 2009 11:48 AM
To: Shah, Hardik
Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
hello Shah, Hardik..
your omap_vout.c has the problem that it disables video1 or fb1.
so I have modified your code.
I defined and set platform_data for DSS2 in machine code.(or board file)
static struct omapfb_platform_data xxx_dss_platform_data = {
.mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[0].format_used=1,
.mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
.mem_desc.region[1].format_used=1,
.mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
.mem_desc.region[2].format_used=1,
};
omapfb_set_platform_data(xxx_dss_platform_data);
after that, omap_vout has resource count got referring to framebuffer count,
registers overlay as vout's one and would decide to use which overlay.
at that time, your code would face with impact on some overlay(fb or video).
this patch would solve that problem.
when it sets overlay to vout, vout would get overlay array index to
avoid overlapping with other overlay.
sighed-off-by: InKi Dae. inki@samsung.com
---
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 9b4a0d7..051298a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2246,11 +2246,13 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device
*pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
+ vout_count = 3 - pdev-num_resources;
+
for (k = 0; k pdev-num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2266,9 +2268,9 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout-vid = k;
vid_dev-vouts[k] = vout;
vout-vid_info.vid_dev = vid_dev;
- vout-vid_info.overlays[0] = vid_dev-overlays[k + 1];
+ vout-vid_info.overlays[0] = vid_dev-overlays[k + vout_count];
vout-vid_info.num_overlays = 1;
- vout-vid_info.id = k + 1;
+ vout-vid_info.id = k + vout_count;
vid_dev-num_videos++;
/* Setup the default configuration for the video devices
@@ -2289,7 +2291,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout-vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count)
0) {
printk(KERN_ERR VOUT_NAME : could not register \
Video for Linux device\n);
vfd-minor = -1;
2009/4/22 Shah, Hardik hardik.s...@ti.com:
[Shah, Hardik] Yes this is correct,
I will apply this patch. I already found it and fixed it in different way but
any way I will apply your patch.
[Shah, Hardik] Further on this inki. Solving this bug will give rise to couple
of more bugs related to global_alpha and pixel formats. That also is fixed. You
can refer
http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=summary
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, April 22, 2009 1:53 PM
To: Shah, Hardik
Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav,
Brijesh
R;
Hiremath, Vaibhav
Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
This is the version 5th of the Driver.
Following are the features supported.
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD and TV.
3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24,
RGB565
4. Supports Alpha blending.
5. Supports Color keying both source and destination.
6. Supports rotation with RGB565 and RGB32 pixels formats.
7. Supports
Re: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman sako...@gmail.com wrote:
set_machine_constraints: invalid 'VUSB1V5' voltage constraints
I get the same on pandora, although it continues booting fine after
that. Maybe regulator folks will comment about regulator errors.
I suspect this may be due to the buggy defaults that are provided when
no voltage constraints are given for a fixed voltage regulator. There's
a patch on its way to mainline fixing this:
commit 14d32bb077f7cc6f78bd012e5b1489899dddf749
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Tue Apr 28 11:09:38 2009 +0100
regulator: Fix default constraints for fixed voltage regulators
Default voltage constraints were being provided for fixed voltage
regulator where board constraints were not provided but these constraints
used INT_MIN as the default minimum voltage which is not a valid value
since it is less than zero. Use 1uV instead.
Also set the default values we set in the constraints themselves since
otherwise the max_uV constraint we determine will not be stored in the
actual constraint strucutre and will therefore not be used.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2f14c16..98c3a74 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -703,10 +703,13 @@ static int set_machine_constraints(struct regulator_dev
*rdev,
int cmin = constraints-min_uV;
int cmax = constraints-max_uV;
- /* it's safe to autoconfigure fixed-voltage supplies */
+ /* it's safe to autoconfigure fixed-voltage supplies
+ and the constraints are used by list_voltage. */
if (count == 1 !cmin) {
- cmin = INT_MIN;
+ cmin = 1;
cmax = INT_MAX;
+ constraints-min_uV = cmin;
+ constraints-max_uV = cmax;
}
/* voltage constraints are optional */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
On Thursday 30 April 2009, Grazvydas Ignotas wrote: I get the same on pandora, although it continues booting fine after that. Maybe regulator folks will comment about regulator errors. Does mainline 3e59091828ed5406c879b899b4257fcef7271e2c resolve it for you? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TVP514x: Migration to sub-device framework
From: Vaibhav Hiremath hvaib...@ti.com
This is first version of sub-device framework based
TVP514x decoder driver. Earlier version of TVP514x driver is based
on V4L2-int framework.
Initial version reviewed by Hans Verkuil.
NOTE: Please note that this patch has not been tested on any board,
only compilation/build tested.
I will consolidate all the review comments and will incorporate
in the next version, which should also be include validation
of these changes on any of the supported boards.
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration master driver to validate this driver.
- validate on Davinci and OMAP boards.
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
drivers/media/video/tvp514x.c | 787 ++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 310 insertions(+), 491 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4262e60..d42cef2 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,10 @@
#include linux/i2c.h
#include linux/delay.h
#include linux/videodev2.h
-#include media/v4l2-int-device.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
#include media/tvp514x.h
#include tvp514x_regs.h
@@ -49,10 +52,10 @@ static int debug;
module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, Debug level (0-1));
-#define dump_reg(client, reg, val) \
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n, reg, val); \
+ val = tvp514x_read_reg(sd, reg);\
+ v4l2_info(sd, Reg(0x%.2X): 0x%.2X\n, reg, val); \
} while (0)
/**
@@ -65,14 +68,6 @@ enum tvp514x_std {
};
/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
- STATE_NOT_DETECTED,
- STATE_DETECTED
-};
-
-/**
* struct tvp514x_std_info - Structure to store standard informations
* @width: Line width in pixels
* @height:Number of active lines
@@ -89,33 +84,27 @@ struct tvp514x_std_info {
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
/**
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
* @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @state: TVP5146/47 decoder state - enabled or disabled.
* @pix: Current pixel format
* @num_fmts: Number of formats
* @fmt_list: Format list
* @current_std: Current standard
* @num_stds: Number of standards
* @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device v4l2_int_device;
- struct v4l2_int_slave tvp514x_slave;
+ struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
- struct i2c_client *client;
-
- struct i2c_device_id *id;
int ver;
- enum tvp514x_state state;
+ int state;
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +113,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
- struct v4l2_routing route;
+ /*
+* Input and Output Routing parameters
+*/
+ unsigned int input;
+ unsigned int output;
};
/* TVP514x default register values */
@@ -240,35 +232,22 @@ static struct tvp514x_std_info tvp514x_std_list[] = {
},
/* Standard: need to add for additional standard */
};
-/*
- * Control structure for Auto Gain
- * This is temporary data, will get replaced once
- * v4l2_ctrl_query_fill supports it.
- */
-static const struct v4l2_queryctrl tvp514x_autogain_ctrl = {
- .id = V4L2_CID_AUTOGAIN,
- .name = Gain, Automatic,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .minimum = 0,
- .maximum = 1,
- .step = 1,
- .default_value = 1,
-};
/*
* Read a value from a register in an TVP5146/47 decoder device.
* Returns value read if successful, or non-zero (-1) otherwise.
*/
-static int
RE: [PATCH] OMAP: sDMA: Correct the the omap_request_dma_chain() signature
Yor tow commentsI think I answered both.Just a correction you comment itself. You mean callback gets lch instead of chain_id as an argument? You mean callback returns *** lch instead of chain_id as an argument? Two comments: Now callback returns logical channel number and not chain_id. You mean callback gets lch instead of chain_id as an argument? Yes. Comment below. Change also kernel-doc function comment for omap_request_dma_chain. I.e. those comment lines few lines before the function itself. Yes would do that and send the patch. Regards Santosh-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dss2 and dsi
On Wed, Apr 29, 2009 at 8:26 PM, Rebecca Schultz Zavin rebe...@android.com wrote: I have a question on the intended use of pan_display v. the update_window ioctl in dss2. I'm using a dsi panel and it seems like the only way I can get new data out to the display is by calling display-update. The only place that seems to be called is from a couple of the ioctls, mainly update_window. Is the intention that you use update_window to compose the screen? Android uses pan_display to flip between a front and back copy of the frame buffer, and if it's available on the hardware, to send a partial update. On the dss2 framework those calls never cause anything to be sent to the dsi panel. Should we be calling the update_window ioctl? I think Tomi asked to CC him (added) when mailing about DSS2 issues. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] onenand init: Pass configuration data from board-*.c files
* Adrian Hunter adrian.hun...@nokia.com [090429 22:52]: Tony Lindgren wrote: Pass configuration data from board-*.c files. Also remove support for the OMAP_TAG_PARTITION tag. If the partition info is passed, it should be passed from cmdline, and probably should be done in a generic way in the drivers/mtd. Signed-off-by: Tony Lindgren t...@atomide.com --- NAK This would break all our flashing infrastructure. The OMAP_TAG_PARTITION and others will have to go, the omap tags have been rejected several times by RMK. The right solution is to follow Linux standards and pass the options from the cmdline. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to gpmc-onenand.c
* vimal singh vimalsi...@ti.com [090429 23:33]:
'gpmc-onenand.c' is still confusing name. This is not going to used in
all boards anyway.
Why do you think this cannot be used for all boards?
The GPMC timings are totally based on the onenand chip features.
Regards,
Tony
On Thu, Apr 30, 2009 at 3:20 AM, Tony Lindgren t...@atomide.com wrote:
Rename board-n800-flash.c to gpmc-onenand.c.
Signed-off-by: Tony Lindgren t...@atommide.com
---
arch/arm/mach-omap2/Makefile |4 ++--
arch/arm/mach-omap2/gpmc-onenand.c |0
2 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/mach-omap2/{board-n800-flash.c = gpmc-onenand.c} (100%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 76acefa..9127a94 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -55,14 +55,14 @@ obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
board-apollon-mmc.o \
board-apollon-keys.o
-obj-$(CONFIG_MACH_NOKIA_N800) += board-n800.o board-n800-flash.o \
+obj-$(CONFIG_MACH_NOKIA_N800) += board-n800.o gpmc-onenand.o \
board-n800-mmc.o board-n800-bt.o \
board-n800-usb.o \
board-n800-dsp.o \
board-n800-camera.o
obj-$(CONFIG_MACH_NOKIA_N810) += board-n810.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
- board-n800-flash.o \
+ gpmc-onenand.o \
board-rx51-flash.o \
board-rx51-sdram.o \
board-rx51-video.o \
diff --git a/arch/arm/mach-omap2/board-n800-flash.c
b/arch/arm/mach-omap2/gpmc-onenand.c
similarity index 100%
rename from arch/arm/mach-omap2/board-n800-flash.c
rename to arch/arm/mach-omap2/gpmc-onenand.c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
---
Regards,
\/ | |\/| /-\ |_
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
Kyuwon, Kim Kyuwon chamm...@gmail.com writes: Hi Kevin, Thank you for showing steady interest in this driver. On Tue, Apr 21, 2009 at 9:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Kyuwon, While I still like the concept of this driver, I'm still not quite happy about how it is implemented for various reasons. Most of which have to do with the fact that this driver does many things that really should be the job of other layers. In particular, the list of omap3_wake_events is a bit troubling. It really should be handled by the omapdev layer. You'll see that you are duplicating the data that is handled there. Rather, we should just extend the omapdev data to handle the wakeup events for that device. If you allow me to insert a new field whose name is mask in the omapdev struct, I think I can extend the omapdev to handle the wakeup events. Extending omapdev would be fine. Also, I still think the WKST register reading should be done in the PRCM interrupt handler. In your previous attempt, you were seeing a bunch of non-device wakeup related interrupts. Can you try again with the attached patch (thanks to Paul Walmseley) which should help us debug why you were seeing spurious PRCM interrupts. First of all, sorry for giving you the wrong information in the previous mail. I found that we actually have configured GPTIMER12 as the system timer. And I tried with the attached patch, but I can't see any debug message. However even now, PRCM interrupt handler is invoked quite often due to the system timer. That's what I assumed was happening. As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new lower-latency C1 state] patch is applied, the system is in 'wfi' state in every idle state. So whenever the system timer wake up the system from idle, I think PRCM interrupt occurs. Do you think still the WKST register should be read in the PRCM interrupt handler? ;) Yes. The WKST registers are already being read in the handler so they can be properly cleared. All you are adding is the saving of them. In addition, you should not enter idle between the time the system wakes from resume and your resume handler runs so you should be able to get the correct WKST values. Also, I know we discussed this before, but I think the GPIO wakeup source stuff really belongs in a separate patch, and if you think it is still useful, and cannot be done by just enabling a GPIO IRQ from the board file, I suggest you propose a patch to the generic GPIO layer to add this interface. OK, I will remove this GPIO wakeup feature. But I want to know more detailed information about wakeup event . So, instead of using the GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x registers. That sounds OK. The current mux layer is lacking any knowledge of the wake bits in the PADCONF regs, so I'd be interested in any ideas you have of adding that support. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown broo...@sirena.org.uk wrote:
On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman sako...@gmail.com wrote:
set_machine_constraints: invalid 'VUSB1V5' voltage constraints
I get the same on pandora, although it continues booting fine after
that. Maybe regulator folks will comment about regulator errors.
I suspect this may be due to the buggy defaults that are provided when
no voltage constraints are given for a fixed voltage regulator. There's
a patch on its way to mainline fixing this:
Thanks Mark! This patch does indeed fix the regulator issues, and the
system seems to operate normally once again.
The platform data messages still appear, but a quick look at the code
that generates them shows that we are at the start of a transition in
how platform data is handled (both old and new style are handled at
the moment). Seems we will have a bit of work to do to adapt.
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030_gpio: use which platform_data?
twl4030: gpio (irq 368) chaining IRQs 384..401
mmci-omap-hs.0: use which platform_data?
mmci-omap-hs.1: use which platform_data?
twl4030_usb: use which platform_data?
twl4030_reg.6: use which platform_data?
regulator: VMMC1: 1850 -- 3150 mV normal standby
twl4030_reg.17: use which platform_data?
regulator: VUSB1V5: 1500 mV normal standby
twl4030_reg.18: use which platform_data?
regulator: VUSB1V8: 1800 mV normal standby
twl4030_reg.19: use which platform_data?
regulator: VUSB3V1: 3100 mV normal standby
Steve
commit 14d32bb077f7cc6f78bd012e5b1489899dddf749
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Tue Apr 28 11:09:38 2009 +0100
regulator: Fix default constraints for fixed voltage regulators
Default voltage constraints were being provided for fixed voltage
regulator where board constraints were not provided but these constraints
used INT_MIN as the default minimum voltage which is not a valid value
since it is less than zero. Use 1uV instead.
Also set the default values we set in the constraints themselves since
otherwise the max_uV constraint we determine will not be stored in the
actual constraint strucutre and will therefore not be used.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2f14c16..98c3a74 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -703,10 +703,13 @@ static int set_machine_constraints(struct regulator_dev
*rdev,
int cmin = constraints-min_uV;
int cmax = constraints-max_uV;
- /* it's safe to autoconfigure fixed-voltage supplies */
+ /* it's safe to autoconfigure fixed-voltage supplies
+ and the constraints are used by list_voltage. */
if (count == 1 !cmin) {
- cmin = INT_MIN;
+ cmin = 1;
cmax = INT_MAX;
+ constraints-min_uV = cmin;
+ constraints-max_uV = cmax;
}
/* voltage constraints are optional */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
* Steve Sakoman sako...@gmail.com [090430 08:10]:
On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown broo...@sirena.org.uk wrote:
On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman sako...@gmail.com wrote:
set_machine_constraints: invalid 'VUSB1V5' voltage constraints
I get the same on pandora, although it continues booting fine after
that. Maybe regulator folks will comment about regulator errors.
I suspect this may be due to the buggy defaults that are provided when
no voltage constraints are given for a fixed voltage regulator. There's
a patch on its way to mainline fixing this:
Thanks Mark! This patch does indeed fix the regulator issues, and the
system seems to operate normally once again.
Great. Looks like -rc4 is out, so I'll update our omap tree to that today,
and we'll get this patch in.
Tony
The platform data messages still appear, but a quick look at the code
that generates them shows that we are at the start of a transition in
how platform data is handled (both old and new style are handled at
the moment). Seems we will have a bit of work to do to adapt.
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030_gpio: use which platform_data?
twl4030: gpio (irq 368) chaining IRQs 384..401
mmci-omap-hs.0: use which platform_data?
mmci-omap-hs.1: use which platform_data?
twl4030_usb: use which platform_data?
twl4030_reg.6: use which platform_data?
regulator: VMMC1: 1850 -- 3150 mV normal standby
twl4030_reg.17: use which platform_data?
regulator: VUSB1V5: 1500 mV normal standby
twl4030_reg.18: use which platform_data?
regulator: VUSB1V8: 1800 mV normal standby
twl4030_reg.19: use which platform_data?
regulator: VUSB3V1: 3100 mV normal standby
Steve
commit 14d32bb077f7cc6f78bd012e5b1489899dddf749
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date: Tue Apr 28 11:09:38 2009 +0100
regulator: Fix default constraints for fixed voltage regulators
Default voltage constraints were being provided for fixed voltage
regulator where board constraints were not provided but these constraints
used INT_MIN as the default minimum voltage which is not a valid value
since it is less than zero. Use 1uV instead.
Also set the default values we set in the constraints themselves since
otherwise the max_uV constraint we determine will not be stored in the
actual constraint strucutre and will therefore not be used.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Liam Girdwood l...@slimlogic.co.uk
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2f14c16..98c3a74 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -703,10 +703,13 @@ static int set_machine_constraints(struct
regulator_dev *rdev,
int cmin = constraints-min_uV;
int cmax = constraints-max_uV;
- /* it's safe to autoconfigure fixed-voltage supplies */
+ /* it's safe to autoconfigure fixed-voltage supplies
+ and the constraints are used by list_voltage. */
if (count == 1 !cmin) {
- cmin = INT_MIN;
+ cmin = 1;
cmax = INT_MAX;
+ constraints-min_uV = cmin;
+ constraints-max_uV = cmax;
}
/* voltage constraints are optional */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Overo broken with current top of tree
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, April 30, 2009 8:55 PM To: Steve Sakoman Cc: Mark Brown; Grazvydas Ignotas; linux-omap@vger.kernel.org; David Brownell Subject: Re: Overo broken with current top of tree * Steve Sakoman sako...@gmail.com [090430 08:10]: On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown broo...@sirena.org.uk wrote: On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote: On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman sako...@gmail.com wrote: set_machine_constraints: invalid 'VUSB1V5' voltage constraints I get the same on pandora, although it continues booting fine after that. Maybe regulator folks will comment about regulator errors. I suspect this may be due to the buggy defaults that are provided when no voltage constraints are given for a fixed voltage regulator. There's a patch on its way to mainline fixing this: Thanks Mark! This patch does indeed fix the regulator issues, and the system seems to operate normally once again. Great. Looks like -rc4 is out, so I'll update our omap tree to that today, and we'll get this patch in. Still observing the problems on OMAP3EVM. My code is at 415f2c76e247f2e6a325621e54f0b1b5dc3669cd + the patch below. bootlog: [snip]--[snip] 6i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz 6twl4030: PIH (irq 7) chaining IRQs 368..375 6twl4030: power (irq 373) chaining IRQs 376..383 3twl4030_gpio: use which platform_data? 6twl4030: gpio (irq 368) chaining IRQs 384..401 4MUX: setup L8_34XX_GPIO63 (0xd80020ce): 0x0118 - 0x0104 3mmci-omap-hs.0: use which platform_data? 3twl4030_keypad: use which platform_data? 3twl4030_usb: use which platform_data? 3twl4030_reg.17: use which platform_data? 6regulator: VUSB1V5: 1500 mV normal standby 3twl4030_reg.18: use which platform_data? 6regulator: VUSB1V8: 1800 mV normal standby 3twl4030_reg.19: use which platform_data? 6regulator: VUSB3V1: 3100 mV normal standby 6i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz 6i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz 5SCSI subsystem initialized 6twl4030_usb twl4030_usb: Initialized TWL4030 USB module 6usbcore: registered new interface driver usbfs 6usbcore: registered new interface driver hub 6usbcore: registered new device driver usb 6musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 7Switched to high resolution mode on CPU 0 7musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X)) [snip]--[/snip] 6omapfb: configured for panel omap3evm 6omapfb: DISPC version 3.0 initialized 6omapfb: Framebuffer initialized. Total vram 614400 planes 1 6omapfb: Pixclock 25411 kHz hfreq 48.9 kHz vfreq 74.4 Hz 6Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled 6serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 Get too many 'funny' chars beyond this point: Tony The platform data messages still appear, but a quick look at the code that generates them shows that we are at the start of a transition in how platform data is handled (both old and new style are handled at the moment). Seems we will have a bit of work to do to adapt. i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030_gpio: use which platform_data? twl4030: gpio (irq 368) chaining IRQs 384..401 mmci-omap-hs.0: use which platform_data? mmci-omap-hs.1: use which platform_data? twl4030_usb: use which platform_data? twl4030_reg.6: use which platform_data? regulator: VMMC1: 1850 -- 3150 mV normal standby twl4030_reg.17: use which platform_data? regulator: VUSB1V5: 1500 mV normal standby twl4030_reg.18: use which platform_data? regulator: VUSB1V8: 1800 mV normal standby twl4030_reg.19: use which platform_data? regulator: VUSB3V1: 3100 mV normal standby Steve commit 14d32bb077f7cc6f78bd012e5b1489899dddf749 Author: Mark Brown broo...@opensource.wolfsonmicro.com Date: Tue Apr 28 11:09:38 2009 +0100 regulator: Fix default constraints for fixed voltage regulators Default voltage constraints were being provided for fixed voltage regulator where board constraints were not provided but these constraints used INT_MIN as the default minimum voltage which is not a valid value since it is less than zero. Use 1uV instead. Also set the default values we set in the constraints themselves since otherwise the max_uV constraint we determine will not be stored in the actual constraint strucutre and will therefore not be used. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com Signed-off-by: Liam Girdwood l...@slimlogic.co.uk diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 2f14c16..98c3a74 100644 ---
Re: Overo broken with current top of tree
On Thursday 30 April 2009, Steve Sakoman wrote: The platform data messages still appear, Those platform_data patches are getting reverted. Ignore the messages for now. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 10:41 AM, David Brownell davi...@pacbell.net wrote: On Thursday 30 April 2009, Steve Sakoman wrote: The platform data messages still appear, Those platform_data patches are getting reverted. Ignore the messages for now. Will do :-) There seem to be no ill side effects, so it seems safe to do so. I've also noticed that I now get occasional mmcblk0: retrying using single block read messages on the serial console. I haven't seen these before. Anyone see anything similar on their setup? Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Overo broken with current top of tree
On Thursday 30 April 2009, Steve Sakoman wrote: I've also noticed that I now get occasional mmcblk0: retrying using single block read messages on the serial console. I haven't seen these before. Anyone see anything similar on their setup? Yes. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] onenand_init: Allow disabling sync read and write based on flags (Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to gpmc-onenand.c)
* Tony Lindgren t...@atomide.com [090430 07:06]:
* vimal singh vimalsi...@ti.com [090429 23:33]:
'gpmc-onenand.c' is still confusing name. This is not going to used in
all boards anyway.
Why do you think this cannot be used for all boards?
The GPMC timings are totally based on the onenand chip features.
And these two patches make omap3430sdp to work with the gpmc-onenand
code. Sync mode does not work, but it seems like it was never enabled
for sdp anyways.
Similar patch should work for other boards too.
Tony
From 75b228c97d5df66ef5eba81bb6a25627e6e77941 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Thu, 30 Apr 2009 11:43:19 -0700
Subject: [PATCH] onenand_init: Allow disabling sync read and write based on flags
Allow disabling sync read and write based on flags
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index fc79183..e9ace8c 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -85,20 +85,24 @@ static void omap2_onenand_writew(unsigned short value, void __iomem *addr)
writew(value, addr);
}
-static void set_onenand_cfg(void __iomem *onenand_base, int latency,
- int sync_write, int hf)
+static void set_onenand_cfg(struct omap_onenand_platform_data *cfg,
+void __iomem *onenand_base,
+int latency, int hf)
{
u32 reg;
reg = omap2_onenand_readw(onenand_base + ONENAND_REG_SYS_CFG1);
reg = ~((0x7 ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 9));
reg |= (latency ONENAND_SYS_CFG1_BRL_SHIFT) |
- ONENAND_SYS_CFG1_SYNC_READ |
ONENAND_SYS_CFG1_BL_16;
- if (sync_write)
- reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
+ if (cfg-flags ONENAND_DIS_SYNC_READ)
+ reg = ~ONENAND_SYS_CFG1_SYNC_READ;
else
+ reg |= ONENAND_SYS_CFG1_SYNC_READ;
+ if (cfg-flags ONENAND_DIS_SYNC_WRITE)
reg = ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ else
+ reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
if (hf)
reg |= ONENAND_SYS_CFG1_HF;
else
@@ -106,8 +110,9 @@ static void set_onenand_cfg(void __iomem *onenand_base, int latency,
omap2_onenand_writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
}
-static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
- int freq)
+static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
+ void __iomem *onenand_base,
+ int freq)
{
struct gpmc_timings t;
const int t_cer = 15;
@@ -119,6 +124,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
int tick_ns, div, fclk_offset_ns, fclk_offset, gpmc_clk_ns, latency;
int err, ticks_cez, sync_write = 0, first_time = 0, hf = 0;
+ int cs = cfg-cs;
u32 reg;
if (!freq) {
@@ -160,7 +166,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
t_ach = 6;
t_aavdh = 6;
t_rdyo = 9;
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx() !(cfg-flags ONENAND_DIS_SYNC_WRITE))
sync_write = 1;
break;
case 66:
@@ -171,7 +177,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
t_ach = 6;
t_aavdh = 6;
t_rdyo = 11;
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx() !(cfg-flags ONENAND_DIS_SYNC_WRITE))
sync_write = 1;
break;
default:
@@ -198,7 +204,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
latency = 4;
if (first_time)
- set_onenand_cfg(onenand_base, latency, sync_write, hf);
+ set_onenand_cfg(cfg, onenand_base, latency, hf);
if (div == 1) {
reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
@@ -244,7 +250,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
ticks_cez);
/* Write */
- if (sync_write) {
+ if (!(cfg-flags ONENAND_DIS_SYNC_WRITE)) {
t.adv_wr_off = t.adv_rd_off;
t.we_on = 0;
t.we_off = t.cs_rd_off;
@@ -272,7 +278,8 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_WRAPBURST_SUPP |
GPMC_CONFIG1_READMULTIPLE_SUPP |
- GPMC_CONFIG1_READTYPE_SYNC |
+ ((cfg-flags ONENAND_DIS_SYNC_READ) ? 0 :
+GPMC_CONFIG1_READTYPE_SYNC) |
(sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
(sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset) |
@@ -288,7 +295,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
if (err)
return err;
- set_onenand_cfg(onenand_base, latency, sync_write, hf);
+ set_onenand_cfg(cfg, onenand_base, latency, hf);
return 0;
}
@@ -298,7 +305,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base, int freq)
struct device *dev = gpmc_onenand_device.dev;
/* Set sync timings in GPMC */
- if (omap2_onenand_set_sync_mode(gpmc_onenand_data-cs, onenand_base,
+ if (omap2_onenand_set_sync_mode(gpmc_onenand_data, onenand_base,
freq) 0) {
Re: [PATCH] OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
* Pierre Ossman pie...@ossman.eu [090428 12:38]:
Jarkko? Tony?
Hmm, we haven't heard from Jarkko for a while.. Adrian, care to take
a look at this patch?
Tony
On Tue, 21 Apr 2009 13:09:22 +0530
Gadiyar, Anand gadi...@ti.com wrote:
From: Anand Gadiyar gadi...@ti.com
OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
This considerably reduces the number of interrupts during a transfer
and ought to result in some power saving.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e62a22a..2d83807 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -70,6 +70,8 @@
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
#define INT_EN_MASK0x307F0033
+#define BWR_ENABLE (1 4)
+#define BRR_ENABLE (1 5)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -241,7 +243,12 @@ mmc_omap_start_command(struct mmc_omap_host *host,
struct mmc_command *cmd,
*/
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+
+ if (host-use_dma)
+ OMAP_HSMMC_WRITE(host-base, IE,
+INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
+ else
+ OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] onenand init: Convert omap3430sdp to use gpmc-onenand (Re: [PATCH] onenand_init: Allow disabling sync read and write based on flags (Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to
From b5c750c4d3f523df5759c3b7cbda321d056f7045 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Thu, 30 Apr 2009 11:46:41 -0700
Subject: [PATCH] onenand init: Convert omap3430sdp to use gpmc-onenand
Convert omap3430sdp to use gpmc-onenand. Note that sync mode
does not seem to work for some reason, so disable it with flags.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-3430sdp-flash.c b/arch/arm/mach-omap2/board-3430sdp-flash.c
index f0e25a4..ab3fc1a 100644
--- a/arch/arm/mach-omap2/board-3430sdp-flash.c
+++ b/arch/arm/mach-omap2/board-3430sdp-flash.c
@@ -103,8 +103,6 @@ static struct platform_device sdp_nor_device = {
.resource = sdp_nor_resource,
};
-static int sdp_onenand_setup(void __iomem *, int freq);
-
static struct mtd_partition sdp_onenand_partitions[] = {
{
.name = X-Loader-OneNAND,
@@ -138,30 +136,10 @@ static struct mtd_partition sdp_onenand_partitions[] = {
static struct omap_onenand_platform_data sdp_onenand_data = {
.parts = sdp_onenand_partitions,
.nr_parts = ARRAY_SIZE(sdp_onenand_partitions),
- .onenand_setup = sdp_onenand_setup,
.dma_channel = -1, /* disable DMA in OMAP OneNAND driver */
+ .flags = ONENAND_DIS_SYNC_READ | ONENAND_DIS_SYNC_WRITE,
};
-static struct platform_device sdp_onenand_device = {
- .name = omap2-onenand,
- .id = -1,
- .dev = {
- .platform_data = sdp_onenand_data,
- },
-};
-
-/*
- * sdp_onenand_setup - The function configures the onenand flash.
- * @onenand_base: Onenand base address
- *
- * @return int: Currently always returning zero.
- */
-static int sdp_onenand_setup(void __iomem *onenand_base, int freq)
-{
- /* Onenand setup does nothing at present */
- return 0;
-}
-
static struct mtd_partition sdp_nand_partitions[] = {
/* All the partition sizes are listed in terms of NAND block size */
{
@@ -262,7 +240,7 @@ void __init sdp3430_flash_init(void)
} else {
ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
if ((ret 0x3F) == (ONENAND_MAP 24))
- onenandcs = cs;
+onenandcs = cs;
}
cs++;
}
@@ -284,7 +262,6 @@ void __init sdp3430_flash_init(void)
if (onenandcs GPMC_CS_NUM) {
sdp_onenand_data.cs = onenandcs;
- if (platform_device_register(sdp_onenand_device) 0)
- printk(KERN_ERR Unable to register OneNAND device\n);
+ gpmc_onenand_init(sdp_onenand_data);
}
}
