Re: [PATCH] PERF(kernel): Cleanup power events V2
* Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far enough
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend
C-state/idle accounting events:
power:power_start
power:power_end
are replaced with:
power:processor_idle
and
power:power_frequency
is replaced with:
power:processor_frequency
Could you please name it power:cpu_idle and power:cpu_frequency instead, for
shortness? We generally use 'cpu' in the kernel and for events.
power:machine_suspend
How will future PCI (or other device) power saving tracepoints be called?
Might be more consistent to use:
power:cpu_idle
power:machine_idle
power:device_idle
Where machine_idle is the suspend event.
the type= field got removed from both, it was never
used and the type is differed by the event type itself.
+#define PWR_EVENT_EXIT 0x
Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1,
+ POWER_PSTATE = 2,
+};
+#endif
Since we are cleaning up all these events, those enum definitions dont really
look
logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
Plus:
+DECLARE_EVENT_CLASS(processor,
+
+ TP_PROTO(unsigned int state, unsigned int cpu_id),
+
+ TP_ARGS(state, cpu_id),
+
+ TP_STRUCT__entry(
+ __field(u32,state )
+ __field(u32,cpu_id )
Trace entries can carry a cpu_id of the current processor already. Can this
cpu_id
ever be different from that CPU id?
+ ),
+
+ TP_fast_assign(
+ __entry-state = state;
+ __entry-cpu_id = cpu_id;
+ ),
+
+ TP_printk(state=%lu cpu_id=%lu, (unsigned long)__entry-state,
+ (unsigned long)__entry-cpu_id)
+);
+
+DEFINE_EVENT(processor, processor_idle,
+
+ TP_PROTO(unsigned int state, unsigned int cpu_id),
+
+ TP_ARGS(state, cpu_id)
+);
+
+#define PWR_EVENT_EXIT 0x
+
+DEFINE_EVENT(processor, processor_frequency,
+
+ TP_PROTO(unsigned int frequency, unsigned int cpu_id),
+
+ TP_ARGS(frequency, cpu_id)
+);
So, we have a 'state' field in the class, which is used as 'state' by the
power::cpu_idle event, and as 'frequency' by the power::cpu_freq event?
Are there any architectures that track frequency in Hz, not in kHz? If yes,
might
there ever be a need for the frequency value to be larger than 4.29 GHz? If
yes,
then it wont fit into u32.
Also, might there be a future need to express different types of frequencies?
For
example, should we decide to track turbo frequencies in Intel CPUs, how would
that
be expressed via these events? Are there any architectures and CPUs that
somehow
have some extra attribute to the frequency value?
+TRACE_EVENT(machine_suspend,
+
+ TP_PROTO(unsigned int state),
+
+ TP_ARGS(state),
+
+ TP_STRUCT__entry(
+ __field(u32,state )
+ ),
Hm, this event is not used anywhere in the submitted patches. Where is the
patch
that adds usage, and what are the possible values for 'state'?
Ingo
--
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
[GIT PULL] omap DSS changes for 2.6.27
Hi Linus, Please pull OMAP display subsystem changes: The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00: Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-linus Archit Taneja (2): OMAP: DSS2: Introduce dss_features files OMAP: DSS2: Use dss_features framework on DSS2 code Grazvydas Ignotas (1): OMAP: DSS2: make filter coefficient tables human readable Jarkko Nikula (1): OMAP: DSS2: Add SPI dependency to Kconfig of ACX565AKM panel Nicolas Kaiser (2): video/omap: remove mux.h include arm/omap: simplify conditional Senthilvadivu Guruswamy (4): OMAP: DSS2: DSI: Remove extra iounmap in error path OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3 OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3 Stanley.Miao (1): OMAP: DSS2: don't power off a panel twice Tasslehoff Kjappfot (1): OMAP: DSS2: OMAPFB: swap front and back porches for both hsync and vsync Uwe Kleine-König (3): ARM: omap/fb: move omap_init_fb to .init.text ARM: omap/fb: move omapfb_reserve_sram to .init.text ARM: omap/fb: move get_fbmem_region() to .init.text arch/arm/plat-omap/fb.c| 14 +- arch/arm/plat-omap/include/plat/display.h | 31 --- arch/arm/plat-omap/include/plat/vrfb.h | 16 ++ drivers/video/omap/lcd_omap3beagle.c |2 - drivers/video/omap2/displays/Kconfig |2 +- drivers/video/omap2/displays/panel-acx565akm.c |6 + drivers/video/omap2/displays/panel-generic.c |6 + .../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 + .../video/omap2/displays/panel-toppoly-tdo35s.c|6 + .../video/omap2/displays/panel-tpo-td043mtea1.c|6 + drivers/video/omap2/dss/Makefile |2 +- drivers/video/omap2/dss/core.c |3 + drivers/video/omap2/dss/dispc.c| 270 +--- drivers/video/omap2/dss/dsi.c |1 - drivers/video/omap2/dss/dss_features.c | 191 ++ drivers/video/omap2/dss/dss_features.h | 50 drivers/video/omap2/dss/manager.c | 33 ++-- drivers/video/omap2/dss/overlay.c | 24 +- drivers/video/omap2/omapfb/Kconfig |2 +- drivers/video/omap2/omapfb/omapfb-main.c | 26 ++- 21 files changed, 475 insertions(+), 228 deletions(-) create mode 100644 drivers/video/omap2/dss/dss_features.c create mode 100644 drivers/video/omap2/dss/dss_features.h -- 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] PERF(kernel): Cleanup power events V2
On Tue, Oct 26, 2010 at 1:33 AM, Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far enough
New power trace events:
power:processor_idle
power:processor_frequency
power:machine_suspend
C-state/idle accounting events:
power:power_start
power:power_end
are replaced with:
power:processor_idle
and
power:power_frequency
is replaced with:
power:processor_frequency
power:machine_suspend
is newly introduced, a first implementation
comes from the ARM side, but it's easy to add these events
in X86 as well if needed.
This will come as a separate patch, which fits all platforms. Cf.
http://marc.info/?l=linux-omapm=128620575300682w=2.
...
@@ -481,10 +484,12 @@ static void mwait_idle(void)
static void poll_idle(void)
{
trace_power_start(POWER_CSTATE, 0, smp_processor_id());
+ trace_processor_idle(1, smp_processor_id());
Should that be:
+ trace_processor_idle(0, smp_processor_id());
instead?
Since state '0' is for the CPU active in polling mode and
PWR_EVENT_EXIT means 'exit from any idle state'.
local_irq_enable();
while (!need_resched())
cpu_relax();
- trace_power_end(0);
+ trace_power_end(smp_processor_id());
+ trace_processor_idle(PWR_EVENT_EXIT, smp_processor_id());
}
/*
...
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
...
Regards,
Jean
--
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] PERF(kernel): Cleanup power events V2
Ingo,
On Tue, Oct 26, 2010 at 9:10 AM, Ingo Molnar mi...@elte.hu wrote:
* Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far enough
...
+#define PWR_EVENT_EXIT 0x
Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1,
+ POWER_PSTATE = 2,
+};
+#endif
Since we are cleaning up all these events, those enum definitions dont really
look
logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
The enum belongs to the deprecated API so I would rather not touch it.
Keeping the deprecated code isolated will make it easier to remove
later.
Plus:
+DECLARE_EVENT_CLASS(processor,
+
+ TP_PROTO(unsigned int state, unsigned int cpu_id),
+
+ TP_ARGS(state, cpu_id),
+
+ TP_STRUCT__entry(
+ __field( u32, state )
+ __field( u32, cpu_id )
Trace entries can carry a cpu_id of the current processor already. Can this
cpu_id
ever be different from that CPU id?
I have no evidence of that (powr mgt on SMP ARM is coming real
soon...) but one can imagine one of the CPUs being the master for PM
decisions.
+ ),
+
+ TP_fast_assign(
+ __entry-state = state;
+ __entry-cpu_id = cpu_id;
+ ),
+
+ TP_printk(state=%lu cpu_id=%lu, (unsigned long)__entry-state,
+ (unsigned long)__entry-cpu_id)
+);
+
+DEFINE_EVENT(processor, processor_idle,
+
+ TP_PROTO(unsigned int state, unsigned int cpu_id),
+
+ TP_ARGS(state, cpu_id)
+);
+
+#define PWR_EVENT_EXIT 0x
+
+DEFINE_EVENT(processor, processor_frequency,
+
+ TP_PROTO(unsigned int frequency, unsigned int cpu_id),
+
+ TP_ARGS(frequency, cpu_id)
+);
So, we have a 'state' field in the class, which is used as 'state' by the
power::cpu_idle event, and as 'frequency' by the power::cpu_freq event?
Are there any architectures that track frequency in Hz, not in kHz? If yes,
might
there ever be a need for the frequency value to be larger than 4.29 GHz? If
yes,
then it wont fit into u32.
Also, might there be a future need to express different types of frequencies?
For
example, should we decide to track turbo frequencies in Intel CPUs, how would
that
be expressed via these events? Are there any architectures and CPUs that
somehow
have some extra attribute to the frequency value?
+TRACE_EVENT(machine_suspend,
+
+ TP_PROTO(unsigned int state),
+
+ TP_ARGS(state),
+
+ TP_STRUCT__entry(
+ __field( u32, state )
+ ),
Hm, this event is not used anywhere in the submitted patches. Where is the
patch
that adds usage, and what are the possible values for 'state'?
This will come as a separate patch, which fits all platforms. Cf.
http://marc.info/?l=linux-omapm=128620575300682w=2.
The state field is of type suspend_state_t, cf. include/linux/suspend.h
Ingo
Jean
--
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: [GIT PULL] omap DSS changes for 2.6.27
Tomi, Did you mean '[GIT PULL] omap DSS changes for 2.6.37' and not '[GIT PULL] omap DSS changes for 2.6.27'? -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen Sent: Tuesday, October 26, 2010 1:24 PM To: Linus Torvalds Cc: linux-kernel; linux-omap@vger.kernel.org; ext Tony Lindgren Subject: [GIT PULL] omap DSS changes for 2.6.27 Hi Linus, Please pull OMAP display subsystem changes: The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00: Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-linus Archit Taneja (2): OMAP: DSS2: Introduce dss_features files OMAP: DSS2: Use dss_features framework on DSS2 code Grazvydas Ignotas (1): OMAP: DSS2: make filter coefficient tables human readable Jarkko Nikula (1): OMAP: DSS2: Add SPI dependency to Kconfig of ACX565AKM panel Nicolas Kaiser (2): video/omap: remove mux.h include arm/omap: simplify conditional Senthilvadivu Guruswamy (4): OMAP: DSS2: DSI: Remove extra iounmap in error path OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3 OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3 Stanley.Miao (1): OMAP: DSS2: don't power off a panel twice Tasslehoff Kjappfot (1): OMAP: DSS2: OMAPFB: swap front and back porches for both hsync and vsync Uwe Kleine-König (3): ARM: omap/fb: move omap_init_fb to .init.text ARM: omap/fb: move omapfb_reserve_sram to .init.text ARM: omap/fb: move get_fbmem_region() to .init.text arch/arm/plat-omap/fb.c| 14 +- arch/arm/plat-omap/include/plat/display.h | 31 --- arch/arm/plat-omap/include/plat/vrfb.h | 16 ++ drivers/video/omap/lcd_omap3beagle.c |2 - drivers/video/omap2/displays/Kconfig |2 +- drivers/video/omap2/displays/panel-acx565akm.c |6 + drivers/video/omap2/displays/panel-generic.c |6 + .../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 + .../video/omap2/displays/panel-toppoly-tdo35s.c|6 + .../video/omap2/displays/panel-tpo-td043mtea1.c|6 + drivers/video/omap2/dss/Makefile |2 +- drivers/video/omap2/dss/core.c |3 + drivers/video/omap2/dss/dispc.c| 270 +-- - drivers/video/omap2/dss/dsi.c |1 - drivers/video/omap2/dss/dss_features.c | 191 ++ drivers/video/omap2/dss/dss_features.h | 50 drivers/video/omap2/dss/manager.c | 33 ++-- drivers/video/omap2/dss/overlay.c | 24 +- drivers/video/omap2/omapfb/Kconfig |2 +- drivers/video/omap2/omapfb/omapfb-main.c | 26 ++- 21 files changed, 475 insertions(+), 228 deletions(-) create mode 100644 drivers/video/omap2/dss/dss_features.c create mode 100644 drivers/video/omap2/dss/dss_features.h -- 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: [GIT PULL] omap DSS changes for 2.6.27
Hi, Oo-ops. Right, the pull request is for 2.6.37. Missed the key, there... Tomi On Tue, 2010-10-26 at 10:14 +0200, ext Shilimkar, Santosh wrote: Tomi, Did you mean '[GIT PULL] omap DSS changes for 2.6.37' and not '[GIT PULL] omap DSS changes for 2.6.27'? -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen Sent: Tuesday, October 26, 2010 1:24 PM To: Linus Torvalds Cc: linux-kernel; linux-omap@vger.kernel.org; ext Tony Lindgren Subject: [GIT PULL] omap DSS changes for 2.6.27 Hi Linus, Please pull OMAP display subsystem changes: The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00: Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-linus Archit Taneja (2): OMAP: DSS2: Introduce dss_features files OMAP: DSS2: Use dss_features framework on DSS2 code Grazvydas Ignotas (1): OMAP: DSS2: make filter coefficient tables human readable Jarkko Nikula (1): OMAP: DSS2: Add SPI dependency to Kconfig of ACX565AKM panel Nicolas Kaiser (2): video/omap: remove mux.h include arm/omap: simplify conditional Senthilvadivu Guruswamy (4): OMAP: DSS2: DSI: Remove extra iounmap in error path OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3 OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3 Stanley.Miao (1): OMAP: DSS2: don't power off a panel twice Tasslehoff Kjappfot (1): OMAP: DSS2: OMAPFB: swap front and back porches for both hsync and vsync Uwe Kleine-König (3): ARM: omap/fb: move omap_init_fb to .init.text ARM: omap/fb: move omapfb_reserve_sram to .init.text ARM: omap/fb: move get_fbmem_region() to .init.text arch/arm/plat-omap/fb.c| 14 +- arch/arm/plat-omap/include/plat/display.h | 31 --- arch/arm/plat-omap/include/plat/vrfb.h | 16 ++ drivers/video/omap/lcd_omap3beagle.c |2 - drivers/video/omap2/displays/Kconfig |2 +- drivers/video/omap2/displays/panel-acx565akm.c |6 + drivers/video/omap2/displays/panel-generic.c |6 + .../video/omap2/displays/panel-sharp-lq043t1dg01.c |6 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 + .../video/omap2/displays/panel-toppoly-tdo35s.c|6 + .../video/omap2/displays/panel-tpo-td043mtea1.c|6 + drivers/video/omap2/dss/Makefile |2 +- drivers/video/omap2/dss/core.c |3 + drivers/video/omap2/dss/dispc.c| 270 +-- - drivers/video/omap2/dss/dsi.c |1 - drivers/video/omap2/dss/dss_features.c | 191 ++ drivers/video/omap2/dss/dss_features.h | 50 drivers/video/omap2/dss/manager.c | 33 ++-- drivers/video/omap2/dss/overlay.c | 24 +- drivers/video/omap2/omapfb/Kconfig |2 +- drivers/video/omap2/omapfb/omapfb-main.c | 26 ++- 21 files changed, 475 insertions(+), 228 deletions(-) create mode 100644 drivers/video/omap2/dss/dss_features.c create mode 100644 drivers/video/omap2/dss/dss_features.h -- 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: [PATCH 1/1] mtd: OneNAND: fix bufferram management when chip has 2-planes.
On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote: This patch adds code that I think was lost when it was applied the commit 5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support Test case: 1. Stress a jffs2 filesystem using bonnie++ -u 0:0 -s 32 -m 16 -r 16 2. dmesg shows various 'Header CRC failed' errors like: Header CRC failed on REF_PRISTINE node at 0x1e81315c: Read 0x00e0, calculated 0x564fc9e8 Tested on IGEP v2 board with a Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58) with 2 planes from Numonyx and CONFIG_MTD_ONENAND_2X_PROGRAM set to y Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com Kyungmin, would be nice to have your ack/nack. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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] PERF(kernel): Cleanup power events V2
On 10/26/2010 12:10 AM, Ingo Molnar wrote: + + TP_STRUCT__entry( + __field(u32,state ) + __field(u32,cpu_id ) Trace entries can carry a cpu_id of the current processor already. Can this cpu_id ever be different from that CPU id? yes esp cpu frequency you can change cross cpu originally we did not have this in the API but Thomas added it for that reason some time ago. -- 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 12/14] drivers/video/omap/blizzard.c: delete double assignment
From: Julia Lawall ju...@diku.dk Delete successive assignments to the same location. Initialize the out_y field as well as the out_x field, rather than initializing the out_x field twice. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // smpl @@ expression i; @@ *i = ...; i = ...; // /smpl Signed-off-by: Julia Lawall ju...@diku.dk --- This changes the semantics and has not been tested. drivers/video/omap/blizzard.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap/blizzard.c b/drivers/video/omap/blizzard.c index 2ffb34a..87785c2 100644 --- a/drivers/video/omap/blizzard.c +++ b/drivers/video/omap/blizzard.c @@ -1590,7 +1590,7 @@ static int blizzard_init(struct omapfb_device *fbdev, int ext_mode, blizzard.auto_update_window.width = fbdev-panel-x_res; blizzard.auto_update_window.height = fbdev-panel-y_res; blizzard.auto_update_window.out_x = 0; - blizzard.auto_update_window.out_x = 0; + blizzard.auto_update_window.out_y = 0; blizzard.auto_update_window.out_width = fbdev-panel-x_res; blizzard.auto_update_window.out_height = fbdev-panel-y_res; blizzard.auto_update_window.format = 0; -- 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] PERF(kernel): Cleanup power events V2
* Arjan van de Ven ar...@linux.intel.com wrote: On 10/26/2010 12:10 AM, Ingo Molnar wrote: + + TP_STRUCT__entry( + __field(u32,state ) + __field(u32,cpu_id ) Trace entries can carry a cpu_id of the current processor already. Can this cpu_id ever be different from that CPU id? yes esp cpu frequency you can change cross cpu originally we did not have this in the API but Thomas added it for that reason some time ago. Ok, good! Maybe add this as a comment? Thanks, Ingo -- 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/1] mtd: OneNAND: fix bufferram management when chip has 2-planes.
On Tue, Oct 26, 2010 at 6:36 PM, Artem Bityutskiy artem.bityuts...@nokia.com wrote: On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote: This patch adds code that I think was lost when it was applied the commit 5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support Test case: 1. Stress a jffs2 filesystem using bonnie++ -u 0:0 -s 32 -m 16 -r 16 2. dmesg shows various 'Header CRC failed' errors like: Header CRC failed on REF_PRISTINE node at 0x1e81315c: Read 0x00e0, calculated 0x564fc9e8 Tested on IGEP v2 board with a Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58) with 2 planes from Numonyx and CONFIG_MTD_ONENAND_2X_PROGRAM set to y Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com Kyungmin, would be nice to have your ack/nack. Sorry for late reply One more check, it seems to use the invalidate instead of update bufferram. In case of 2X PROGRAM, it always uses the BUFFERRAM0 so invalidate another bufferram. Don't set the bufferram index. Thank you, Kyungmin Park -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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: [PATCH] PERF(kernel): Cleanup power events V2
On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote: * Thomas Renninger tr...@suse.de wrote: Changes in V2: - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state - Use u32 instead of u64 for cpuid, state which is by far enough New power trace events: power:processor_idle power:processor_frequency power:machine_suspend C-state/idle accounting events: power:power_start power:power_end are replaced with: power:processor_idle and power:power_frequency is replaced with: power:processor_frequency Could you please name it power:cpu_idle and power:cpu_frequency instead, for shortness? We generally use 'cpu' in the kernel and for events. Sure. power:machine_suspend How will future PCI (or other device) power saving tracepoints be called? Might be more consistent to use: power:cpu_idle power:machine_idle power:device_idle device idle is not true. Those may be low power modes like reduced network throughput, reduced wlan range, the device needs not to be idle. Device power states is probably the most complex area, if such a thing gets introduced, it should makes sense to state the interface experimental for some time until a wider range of devices uses it (in contrast to these new ones which should not change that soon anymore...). Also machine_idle may be true, but machine_suspend sounds more familiar and everyone immediately knows what the event is about. - *_idle convention is not really worth it. Where machine_idle is the suspend event. Here you name it. You talk about machine_idle but you mean the suspend event, better just name it what it is. the type= field got removed from both, it was never used and the type is differed by the event type itself. +#define PWR_EVENT_EXIT 0x Shouldnt this be part of the POWER_ enum? (and you can write -1 there) No, below enum will vanish, but -1 is nicer. ... Plus: +DECLARE_EVENT_CLASS(processor, + + TP_PROTO(unsigned int state, unsigned int cpu_id), + + TP_ARGS(state, cpu_id), + + TP_STRUCT__entry( + __field(u32,state ) + __field(u32,cpu_id ) Trace entries can carry a cpu_id of the current processor already. Can this cpu_id ever be different from that CPU id? Yes. A core's frequency can depend on another one which will get switched as well (by one command/MSR). Compare with commit 6f4f2723d08534fd4e407e1e. This can theoretically also be the case for sleep states. Afaik such HW does not exist yet, but ACPI spec already provides interfaces to pass these dependency from BIOS to OS. - We want a stable ABI and should be prepared for such stuff. + ), + + TP_fast_assign( + __entry-state = state; + __entry-cpu_id = cpu_id; + ), + + TP_printk(state=%lu cpu_id=%lu, (unsigned long)__entry-state, + (unsigned long)__entry-cpu_id) +); + +DEFINE_EVENT(processor, processor_idle, + + TP_PROTO(unsigned int state, unsigned int cpu_id), + +TP_ARGS(state, cpu_id) +); + +#define PWR_EVENT_EXIT 0x + +DEFINE_EVENT(processor, processor_frequency, + + TP_PROTO(unsigned int frequency, unsigned int cpu_id), + + TP_ARGS(frequency, cpu_id) +); So, we have a 'state' field in the class, which is used as 'state' by the power::cpu_idle event, and as 'frequency' by the power::cpu_freq event? Yes, is this a problem? Definitions are a bit shorter having one power processor class. As frequency is stated in frequency event definition everything should be obvious and this one looks like the more elegant way to me. Are there any architectures that track frequency in Hz, not in kHz? If yes, might there ever be a need for the frequency value to be larger than 4.29 GHz? If yes, then it wont fit into u32. drivers/cpufreq subsystem is fixed to unsigned int (cmp. include/linux/cpufreq.h): unsigned intmin;/* in kHz */ unsigned intmax;/* in kHz */ unsigned intcur;/* in kHz, ... that should be fine. Also, might there be a future need to express different types of frequencies? For example, should we decide to track turbo frequencies in Intel CPUs, how would that be expressed via these events? Are there any architectures and CPUs that somehow have some extra attribute to the frequency value? I wonder whether this ever can/will work in a sane way. Userspace can compare with: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq everything above is turbo. So I do not think it's ever needed. But adding an additional value at the end does not violate userspace compatibility. This has been done with the cpuid as well. +TRACE_EVENT(machine_suspend, + + TP_PROTO(unsigned int state), + + TP_ARGS(state), + + TP_STRUCT__entry( + __field(
Re: [PATCH v2 08/11] OMAP4: Adding dev atrributes to OMAP4 smartreflex hwmod data
On 9/25/2010 2:51 PM, Gopinath, Thara wrote:
This patch adds dev attributes for smartreflex modules
in the OMAP4 hwmod database. This patch also updates the
smartreflex rev in the smartreflex class data structure
in the OMAP4 hwmod database.
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 56
arch/arm/plat-omap/include/plat/control.h | 12 ++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba3c215..82657b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,8 @@
#includeplat/omap_hwmod.h
#includeplat/cpu.h
+#includeplat/smartreflex.h
+#includeplat/control.h
#include omap_hwmod_common_data.h
@@ -474,6 +476,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_smartreflex_sysc = {
static struct omap_hwmod_class omap44xx_smartreflex_hwmod_class = {
.name = smartreflex,
.sysc =omap44xx_smartreflex_sysc,
+ .rev = 2,
};
/* smartreflex_core */
@@ -505,6 +508,22 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_core_slaves[] = {
omap44xx_l4_cfg__smartreflex_core,
};
+static u32 omap44xx_sr_core_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_CORE_OPP50, OMAP44XX_CONTROL_FUSE_CORE_OPP100,
+};
+
+static u32 omap44xx_sr_core_test_nvalues[] = {
+ 0x0, 0x0
+};
At first, I thought it was a good idea to put such data here, but now
after the discussion about timer hwmod data, I realize I was wrong.
These informations belong to omap_volt_data. For each OPP you should
provide the efuse offset an the SW nvalues.
BTW, you should not call them test Nvalues, these are perfectly valid
and can be potentially used in production. There are just not as
optimized as a efuse Nvalue.
Benoit
+
+static struct omap_sr_dev_data omap44xx_sr_core_dev_attr = {
+ .efuse_nvalues_offs = omap44xx_sr_core_efuse_offs,
+ .test_sennenable= 0x1,
+ .test_senpenable= 0x1,
+ .test_nvalues = omap44xx_sr_core_test_nvalues,
+ .vdd_name = core
+};
+
static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
.name = smartreflex_core,
.class =omap44xx_smartreflex_hwmod_class,
@@ -518,6 +537,7 @@ static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
},
.slaves = omap44xx_smartreflex_core_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_core_slaves),
+ .dev_attr =omap44xx_sr_core_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -550,6 +570,23 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_iva_slaves[] = {
omap44xx_l4_cfg__smartreflex_iva,
};
+static u32 omap44xx_sr_iva_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_IVA_OPP50, OMAP44XX_CONTROL_FUSE_IVA_OPP100,
+ OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO,
+};
+
+static u32 omap44xx_sr_iva_test_nvalues[] = {
+ 0x0, 0x0, 0x0, 0x0
+};
+
+static struct omap_sr_dev_data omap44xx_sr_iva_dev_attr = {
+ .efuse_nvalues_offs = omap44xx_sr_iva_efuse_offs,
+ .test_sennenable= 0x1,
+ .test_senpenable= 0x1,
+ .test_nvalues = omap44xx_sr_iva_test_nvalues,
+ .vdd_name = iva
+};
+
static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
.name = smartreflex_iva,
.class =omap44xx_smartreflex_hwmod_class,
@@ -563,6 +600,7 @@ static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
},
.slaves = omap44xx_smartreflex_iva_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_smartreflex_iva_slaves),
+ .dev_attr =omap44xx_sr_iva_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -595,6 +633,23 @@ static struct omap_hwmod_ocp_if
*omap44xx_smartreflex_mpu_slaves[] = {
omap44xx_l4_cfg__smartreflex_mpu,
};
+static u32 omap44xx_sr_mpu_efuse_offs[] = {
+ OMAP44XX_CONTROL_FUSE_MPU_OPP50, OMAP44XX_CONTROL_FUSE_MPU_OPP100,
+ OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO,
+};
+
+static u32 omap44xx_sr_mpu_test_nvalues[] = {
+ 0x0, 0x0, 0x0, 0x0
+};
+
+static struct omap_sr_dev_data omap44xx_sr_mpu_dev_attr = {
+ .efuse_nvalues_offs = omap44xx_sr_mpu_efuse_offs,
+ .test_sennenable= 0x1,
+ .test_senpenable= 0x1,
+ .test_nvalues = omap44xx_sr_mpu_test_nvalues,
+ .vdd_name = mpu
+};
+
static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod = {
.name = smartreflex_mpu,
.class =omap44xx_smartreflex_hwmod_class,
@@ -608,6 +663,7 @@ static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod = {
},
.slaves =
Re: [PATCH] PERF(kernel): Cleanup power events V2
* Thomas Renninger tr...@suse.de wrote: On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote: * Thomas Renninger tr...@suse.de wrote: Changes in V2: - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state - Use u32 instead of u64 for cpuid, state which is by far enough New power trace events: power:processor_idle power:processor_frequency power:machine_suspend C-state/idle accounting events: power:power_start power:power_end are replaced with: power:processor_idle and power:power_frequency is replaced with: power:processor_frequency Could you please name it power:cpu_idle and power:cpu_frequency instead, for shortness? We generally use 'cpu' in the kernel and for events. Sure. power:machine_suspend How will future PCI (or other device) power saving tracepoints be called? Might be more consistent to use: power:cpu_idle power:machine_idle power:device_idle device idle is not true. Those may be low power modes like reduced network throughput, reduced wlan range, the device needs not to be idle. Device power states is probably the most complex area, if such a thing gets introduced, it should makes sense to state the interface experimental for some time until a wider range of devices uses it (in contrast to these new ones which should not change that soon anymore...). Ok. Also machine_idle may be true, but machine_suspend sounds more familiar and everyone immediately knows what the event is about. Ok - fair enough. +#define PWR_EVENT_EXIT 0x Shouldnt this be part of the POWER_ enum? (and you can write -1 there) No, below enum will vanish, but -1 is nicer. When it vanishes what will replace it? ... Plus: +DECLARE_EVENT_CLASS(processor, + + TP_PROTO(unsigned int state, unsigned int cpu_id), + + TP_ARGS(state, cpu_id), + + TP_STRUCT__entry( + __field(u32,state ) + __field(u32,cpu_id ) Trace entries can carry a cpu_id of the current processor already. Can this cpu_id ever be different from that CPU id? Yes. A core's frequency can depend on another one which will get switched as well (by one command/MSR). Compare with commit 6f4f2723d08534fd4e407e1e. This can theoretically also be the case for sleep states. Afaik such HW does not exist yet, but ACPI spec already provides interfaces to pass these dependency from BIOS to OS. - We want a stable ABI and should be prepared for such stuff. + ), + + TP_fast_assign( + __entry-state = state; + __entry-cpu_id = cpu_id; + ), + + TP_printk(state=%lu cpu_id=%lu, (unsigned long)__entry-state, + (unsigned long)__entry-cpu_id) +); + +DEFINE_EVENT(processor, processor_idle, + + TP_PROTO(unsigned int state, unsigned int cpu_id), + + TP_ARGS(state, cpu_id) +); + +#define PWR_EVENT_EXIT 0x + +DEFINE_EVENT(processor, processor_frequency, + + TP_PROTO(unsigned int frequency, unsigned int cpu_id), + + TP_ARGS(frequency, cpu_id) +); So, we have a 'state' field in the class, which is used as 'state' by the power::cpu_idle event, and as 'frequency' by the power::cpu_freq event? Yes, is this a problem? Definitions are a bit shorter having one power processor class. As frequency is stated in frequency event definition everything should be obvious and this one looks like the more elegant way to me. Are there any architectures that track frequency in Hz, not in kHz? If yes, might there ever be a need for the frequency value to be larger than 4.29 GHz? If yes, then it wont fit into u32. drivers/cpufreq subsystem is fixed to unsigned int (cmp. include/linux/cpufreq.h): unsigned intmin;/* in kHz */ unsigned intmax;/* in kHz */ unsigned intcur;/* in kHz, ... that should be fine. ok, good - so we should be fine up to 4 THz CPUs. Also, might there be a future need to express different types of frequencies? For example, should we decide to track turbo frequencies in Intel CPUs, how would that be expressed via these events? Are there any architectures and CPUs that somehow have some extra attribute to the frequency value? I wonder whether this ever can/will work in a sane way. Userspace can compare with: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq everything above is turbo. So I do not think it's ever needed. But adding an additional value at the end does not violate userspace compatibility. This has been done with the cpuid as well. +TRACE_EVENT(machine_suspend, + + TP_PROTO(unsigned int state), + + TP_ARGS(state), + + TP_STRUCT__entry( + __field(u32,state ) + ),
Re: [PATCH] PERF(kernel): Cleanup power events V2
* Jean Pihet jean.pi...@newoldbits.com wrote:
Ingo,
On Tue, Oct 26, 2010 at 9:10 AM, Ingo Molnar mi...@elte.hu wrote:
* Thomas Renninger tr...@suse.de wrote:
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far enough
...
+#define PWR_EVENT_EXIT 0x
Shouldnt this be part of the POWER_ enum? (and you can write -1 there)
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1,
+ POWER_PSTATE = 2,
+};
+#endif
Since we are cleaning up all these events, those enum definitions dont
really look
logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
The enum belongs to the deprecated API so I would rather not touch it.
Keeping the deprecated code isolated will make it easier to remove
later.
So what will replace it? We still have a state field.
Passing in platform specific codes is a step backwards.
+TRACE_EVENT(machine_suspend,
+
+ TP_PROTO(unsigned int state),
+
+ TP_ARGS(state),
+
+ TP_STRUCT__entry(
+ __field( u32, state )
+ ),
Hm, this event is not used anywhere in the submitted patches. Where is the
patch
that adds usage, and what are the possible values for 'state'?
This will come as a separate patch, which fits all platforms. Cf.
http://marc.info/?l=linux-omapm=128620575300682w=2.
The state field is of type suspend_state_t, cf. include/linux/suspend.h
Ok, that's at least generic. Needs the review of Rafael, to determine whether
this
state value is all we want to know when we enter suspend.
Thanks,
Ingo
--
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/8] staging: tidspbridge - remove req_addr from proc_map
On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: The device address is assigned by tidspbridge no need for that parameter anymore. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com This would break the API with user-space, right? I think this change should be delayed, preferably after we have a working tidspbridge. -- Felipe Contreras -- 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] PERF(kernel): Cleanup power events V2
On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
..
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1,
+ POWER_PSTATE = 2,
+};
+#endif
Since we are cleaning up all these events, those enum definitions dont
really look
logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
The enum belongs to the deprecated API so I would rather not touch it.
Keeping the deprecated code isolated will make it easier to remove
later.
So what will replace it? We still have a state field.
Nothing, this is part of the cleanup.
As you state above: POWER_NONE does not make sense at all.
The whole thing (type= attribute that vanishes now) is
passed to userspace, but never gets used there because the
same info is in the event name:
cpu_frequency - frequency_switch - PSTATE
cpu_idle - power_start/power_end - CSTATE
I expect that there was an initial power_start/end which
was also used for frequency switching.
Then it got realized that _start/_end does not work out and
frequency_switch got introduced.
To stay compatible the whole power_start/end was not renamed
to cpu_idle and the type= field was kept.
This is a guess without even looking at the git history.
Therefore my partly harsh comments about the sanity of the
current power tracing events.
Passing in platform specific codes is a step backwards.
+TRACE_EVENT(machine_suspend,
+
+ TP_PROTO(unsigned int state),
+
+ TP_ARGS(state),
+
+ TP_STRUCT__entry(
+ __field(u32,state )
+ ),
Hm, this event is not used anywhere in the submitted patches. Where is
the patch
that adds usage, and what are the possible values for 'state'?
This will come as a separate patch, which fits all platforms. Cf.
http://marc.info/?l=linux-omapm=128620575300682w=2.
The state field is of type suspend_state_t, cf. include/linux/suspend.h
Ok, that's at least generic. Needs the review of Rafael, to determine
whether this state value is all we want to know when we enter suspend.
He already gave an acked-by on this generic one here:
Re: [PATCH 3/4] perf: add calls to suspend trace point
Oh now, that was on the X86 specific part which depends on this one.
One should expect that he's fine with the generic part as well then,
but I agree that he should definitely have a look at this and sign it off.
So as they got signed-off already, I'll send the X86 suspend events
on top, once I find these in a tree...
Thomas
--
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] omap: add hwspinlock device
On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren t...@atomide.com wrote: if you feel that (2) is justifiable/desirable, I would be more than happy to submit that version. Yes (2) please. I would assume there will be more use of this. And then we (or probably me again!) don't have to deal with cleaning up the drivers again in the future. Sounds good. Or do you mean a variation of (2) with only the specific locking bits coming from pdata func pointers ? I guess that in this case we just might as well go with the full (2). Yes variation of (2) where you only pass the locking function via platform data would be best. It feels a bit funky to me because we would still have code that is omap-specific inside the common probe()/remove() calls. I suggest to move everything that is omap-specific to a small omap module that, once probed, would register itself with the common hwspinlock framework (after initializing its hardware). That small platfom-specific module probably doesn't have to sit in the arch/ folder; we can follow established conventions like mmc/i2c/gpio/spi/etc.. With that in hand, the hwspinlock would really be hardware-agnostic, and then applying s/omap_hwspin/hwspin/ would be justified. Does this sound reasonable to you ? Thanks, Ohad. -- 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] PERF(kernel): Cleanup power events V2
* Thomas Renninger tr...@suse.de wrote:
On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
..
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1,
+ POWER_PSTATE = 2,
+};
+#endif
Since we are cleaning up all these events, those enum definitions dont
really look
logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
The enum belongs to the deprecated API so I would rather not touch it.
Keeping the deprecated code isolated will make it easier to remove
later.
So what will replace it? We still have a state field.
Nothing, this is part of the cleanup.
I mean, what will go into the state field of the power:cpu_idle event?
As you state above: POWER_NONE does not make sense at all.
The whole thing (type= attribute that vanishes now) is
passed to userspace, but never gets used there because the
same info is in the event name:
cpu_frequency - frequency_switch - PSTATE
cpu_idle - power_start/power_end - CSTATE
Ah, i see, so this 'state' enum went into the type field.
So my question is, and ignore this particular enum for now, what values go into
the
state field, which field is still kept in the new events as well.
[ I'd like to avoid us having to define a third set of power events a few years
down
the road ;-) ]
Thanks,
Ingo
--
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 v2] OMAP2+: PM: omap_device: API for set/get MSTANDBY mode
Certain errata's in OMAP2+ processors will require disabling
master standby mode before completing on going operation. Without
this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
This API is required for multiple DMA errata's which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata's:
1. Errata ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Errata ID: i541(all omap2plus except omap4)
sDMA FIFO draining does not finish
3. Errata ID: i88(only omap3430 ES1.0)
Special programming model needed to disable DMA before end
of block
4. OMAP3430 ES1.0(Errata ID:i88) will require DMA to be put in
no mstandby mode before disabling the channel after completing
the data transfer operation.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
Changes from v1 to v2:
- updated patch description with relevant errata id's.
- API name changed to master_standbymode from master_idlemode
arch/arm/mach-omap2/omap_hwmod.c | 83 +
arch/arm/plat-omap/include/plat/omap_device.h |3 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +
arch/arm/plat-omap/omap_device.c | 36 +++
4 files changed, 124 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..e3f7490 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -250,6 +250,35 @@ static int _set_master_standbymode(struct omap_hwmod *oh,
u8 standbymode,
}
/**
+ * _get_master_standbymode: get the OCP_SYSCONFIG MIDLEMODE field in @midlemode
+ * @oh: struct omap_hwmod *
+ * @standbymode: pointer to get mstandby mode bits(shifted to bit 0)
+ *
+ * Get the master standby mode bits in @midlemode for the @oh hwmod.
+ * Does not fetch the data from the hardware instead returns value
+ * from sysc_cache. Returns -EINVAL upon error or 0 upon success.
+ */
+static int _get_master_standbymode(struct omap_hwmod *oh, u32 *midlemode)
+{
+ u32 mstandby_mask;
+ u8 mstandby_shift;
+
+ if (!oh-class-sysc ||
+ !(oh-class-sysc-sysc_flags SYSC_HAS_MIDLEMODE))
+ return -EINVAL;
+
+ if (!oh-class-sysc-sysc_fields) {
+ WARN(1, omap_hwmod: %s: offset struct for sysconfig not
+provided in class\n, oh-name);
+ return -EINVAL;
+ }
+
+ *midlemode = ((oh-_sysc_cache) mstandby_mask) mstandby_shift;
+
+ return 0;
+}
+
+/**
* _set_slave_idlemode: set the OCP_SYSCONFIG SIDLEMODE field in @v
* @oh: struct omap_hwmod *
* @idlemode: SIDLEMODE field bits
@@ -1427,6 +1456,60 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP master idlemode
+ * @oh: struct omap_hwmod *
+ * @midlemode: MIDLEMODE field bits (shifted to bit 0)
+ *
+ * Sets the IP block's OCP master idlemode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u32 midlemode)
+{
+ u32 v;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+
+ retval = _set_master_standbymode(oh, midlemode, v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
+/**
+ * omap_hwmod_get_master_idlemode - set the hwmod's OCP master idlemode
+ * @oh: struct omap_hwmod *
+ * @midlemode: pointer to get MIDLEMODE field bits (shifted to bit 0)
+ *
+ * Gets the IP block's OCP master idlemode from our local copy. Intended
+ * to be used by drivers that have some erratum that requires direct
+ * manipulation of the MIDLEMODE bits. Returns -EINVAL if @oh is null,
+ * or passes along the return value from _get_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_get_master_standbymode(struct omap_hwmod *oh, u32 *midlemode)
+{
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ retval = _get_master_standbymode(oh, midlemode);
+
+ return
Re: [PATCH 12/14] drivers/video/omap/blizzard.c: delete double assignment
* Julia Lawall ju...@diku.dk: Delete successive assignments to the same location. Initialize the out_y field as well as the out_x field, rather than initializing the out_x field twice. Hi there! An identical patch is already in the -mm tree: The patch titled drivers/video/omap/blizzard.c: suspected typo in assignment has been added to the -mm tree. Its filename is video-omap-suspected-typo-in-assignment.patch See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ -- Subject: drivers/video/omap/blizzard.c: suspected typo in assignment From: Nicolas Kaiser ni...@nikai.net Untested, but looks like an obvious typo to me. Signed-off-by: Nicolas Kaiser ni...@nikai.net Cc: Tomi Valkeinen tomi.valkei...@nokia.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Andrew Morton a...@linux-foundation.org Best regards, Nicolas Kaiser -- 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] PERF(kernel): Cleanup power events V2
On Tuesday 26 October 2010 13:54:22 Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
..
As you state above: POWER_NONE does not make sense at all.
The whole thing (type= attribute that vanishes now) is
passed to userspace, but never gets used there because the
same info is in the event name:
cpu_frequency - frequency_switch - PSTATE
cpu_idle - power_start/power_end - CSTATE
Ah, i see, so this 'state' enum went into the type field.
So my question is, and ignore this particular enum for now, what values go
into the
state field, which field is still kept in the new events as well.
Same as before:
cpu_idle:
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+ trace_processor_idle(1, smp_processor_id());
(Ooops found a copy and paste bug in my patch where I reverted
the poll_idle event, but it should be zero...).
State in cpu_idle is identical with cpuidle registered
state. If cpuidle got registered, one should be able to calculate the
same C-state residency time and usage via state=X (cpu_idle event)
which you can grab via:
cat /sys/devices/system/cpu/cpu0/cpuidle/stateX/{time,usage}
The cpu_idle event additionally gives you the timestamps of the state
changes.
This is rather nice as userspace can grab additional info from
cpuidle sysfs layer like:
/sys/devices/system/cpu/cpu0/cpuidle/stateX/{desc,power,name}
If cpuidle is not registered, the events you get are arch specific.
I mean they are arch specific anyway, but with cpuidle you can
build up an arch independent userspace framework nicely by looking
up name/desc/power/... of an cpu_idle event in cpuidle sysfs as
described above.
Thomas
--
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 v3 03/13] OMAP: DMA: Introduce DMA device attributes
This patch introduces OMAP DMA device attributes for using the same in
DMA platform driver for all OMAP's and HWMOD database(OMAP2PLUS onwards)
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/include/plat/dma.h | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 5e28d26..9757b22 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -296,6 +296,22 @@
#define DMA_ERRATA_i88 (1 4)
#define DMA_ERRATA_3_3 (1 5)
+/* Attributes for OMAP DMA Contrllers */
+#define ENABLE_1510_MODE (1 0x0)
+#define DMA_LINKED_LCH (1 0x1)
+#define GLOBAL_PRIORITY(1 0x2)
+#define RESERVE_CHANNEL(1 0x3)
+#define SRC_PORT (1 0x4)
+#define DST_PORT (1 0x5)
+#define IS_CSSA_32 (1 0x6)
+#define IS_CDSA_32 (1 0x7)
+#define SRC_INDEX (1 0x8)
+#define DST_INDEX (1 0x9)
+#define IS_BURST_ONLY4 (1 0xA)
+#define CLEAR_CSR_ON_READ (1 0xB)
+#define IS_WORD_16 (1 0xC)
+#define IS_RW_PRIORITY (1 0xD)
+
enum omap_dma_burst_mode {
OMAP_DMA_DATA_BURST_DIS = 0,
OMAP_DMA_DATA_BURST_4,
@@ -361,6 +377,10 @@ struct omap_dma_channel_params {
#endif
};
+struct omap_dma_dev_attr {
+ u32 dev_caps;
+ u16 lch_count;
+};
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
extern int omap_request_dma(int dev_id, const char *dev_name,
--
1.7.1
--
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 v3 01/13] OMAP: DMA: Replace read/write macros with functions
The low level read/write macros are replaced with static inline functions
and register offsets are handled through static register offset tables
mapped through enumeration constants.
The objective of this patch is to prepare for omap dma driver cleanup
and dma hwmod implementation. The code optimization and moving machine
specific code to respective mach-omapx dma file will be handled in the
rest of this patch series.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dma.c | 739 ++---
arch/arm/plat-omap/include/plat/dma.h | 120 --
2 files changed, 497 insertions(+), 362 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f5c5b8d..77241e2 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,147 @@
#undef DEBUG
+enum {
+ GCR1 = 0, GSCR, GRST, HW_ID,
+ PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
+ PCHD_ID,CAPS1_0_U, CAPS1_0_L, CAPS1_1_U,
+ CAPS1_1_L, CAPS1_2,CAPS1_3,CAPS1_4,
+ PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,
+
+ OMAP1_CH_COMMON_START,
+
+ /* Common Registers */
+ CSDP1, CCR1, CICR1, CSR1,
+ CEN1, CFN1, CSFI1, CSEI1,
+ CPC,CSAC1, CDAC1, CDEI1,
+ CDFI1, CLNK_CTRL1,
+
+ /* Channel specific register offsets */
+ CSSA_L, CSSA_U, CDSA_L, CDSA_U,
+ COLOR_L,COLOR_U,CCR1_2, LCH_CTRL,
+
+ OMAP1_CH_COMMON_END,
+};
+
+static u16 reg_map_omap1[] = {
+ [GCR1] = 0x400,
+ [GSCR] = 0x404,
+ [GRST] = 0x408,
+ [HW_ID] = 0x442,
+ [PCH2_ID] = 0x444,
+ [PCH0_ID] = 0x446,
+ [PCH1_ID] = 0x448,
+ [PCHG_ID] = 0x44a,
+ [PCHD_ID] = 0x44c,
+ [CAPS1_0_U] = 0x44e,
+ [CAPS1_0_L] = 0x450,
+ [CAPS1_1_U] = 0x452,
+ [CAPS1_1_L] = 0x454,
+ [CAPS1_2] = 0x456,
+ [CAPS1_3] = 0x458,
+ [CAPS1_4] = 0x45a,
+ [PCH2_SR] = 0x460,
+ [PCH0_SR] = 0x480,
+ [PCH1_SR] = 0x482,
+ [PCHD_SR] = 0x4c0,
+
+ /* Common Registers */
+ [CSDP1] = 0x00,
+ [CCR1] = 0x02,
+ [CICR1] = 0x04,
+ [CSR1] = 0x06,
+ [CEN1] = 0x10,
+ [CFN1] = 0x12,
+ [CSFI1] = 0x14,
+ [CSEI1] = 0x16,
+ [CPC] = 0x18, /* 15xx only */
+ [CSAC1] = 0x18,
+ [CDAC1] = 0x1a,
+ [CDEI1] = 0x1c,
+ [CDFI1] = 0x1e,
+ [CLNK_CTRL1]= 0x28,
+
+ /* Channel specific register offsets */
+ [CSSA_L]= 0x08,
+ [CSSA_U]= 0x0a,
+ [CDSA_L]= 0x0c,
+ [CDSA_U]= 0x0e,
+ [COLOR_L] = 0x20,
+ [COLOR_U] = 0x22,
+ [CCR1_2]= 0x24,
+ [LCH_CTRL] = 0x2a,
+};
+
+enum {
+ REVISION = 0, GCR2, IRQSTATUS_L0, IRQSTATUS_L1,
+ IRQSTATUS_L2, IRQSTATUS_L3, IRQENABLE_L0, IRQENABLE_L1,
+ IRQENABLE_L2, IRQENABLE_L3, SYSSTATUS, OCP_SYSCONFIG,
+ CAPS2_0,CAPS2_2,CAPS2_3,CAPS2_4,
+
+ OMAP2_CH_COMMON_START,
+
+ /* Common register offsets */
+ CCR2, CLNK_CTRL2, CICR2, CSR2,
+ CSDP2, CEN2, CFN2, CSEI2,
+ CSFI2, CDEI2, CDFI2, CSAC2,
+ CDAC2,
+
+ /* Channel specific register offsets */
+ CSSA, CDSA, CCEN, CCFN,
+ COLOR,
+
+ /* OMAP4 specific registers */
+ CDP,CNDP, CCDN,
+
+ OMAP2_CH_COMMON_END,
+};
+
+static u16 reg_map_omap2[] = {
+ [REVISION] = 0x00,
+ [GCR2] = 0x78,
+ [IRQSTATUS_L0] = 0x08,
+ [IRQSTATUS_L1] = 0x0c,
+ [IRQSTATUS_L2] = 0x10,
+ [IRQSTATUS_L3] = 0x14,
+ [IRQENABLE_L0] = 0x18,
+ [IRQENABLE_L1] = 0x1c,
+ [IRQENABLE_L2] = 0x20,
+ [IRQENABLE_L3] = 0x24,
+ [SYSSTATUS] = 0x28,
+ [OCP_SYSCONFIG] = 0x2c,
+ [CAPS2_0] = 0x64,
+ [CAPS2_2] = 0x6c,
+ [CAPS2_3] = 0x70,
+ [CAPS2_4] = 0x74,
+
+ /* Common register offsets */
+ [CCR2] = 0x80,
+ [CLNK_CTRL2]= 0x84,
+ [CICR2] = 0x88,
+ [CSR2]
[PATCH v3 02/13] OMAP: DMA: Introduce errata handling feature
Implement errata handling to use flags instead of cpu_is_*
and cpu_class_* in the code.
The errata flags are initialized at init time and during runtime
we are using the errata variable (via the IS_DMA_ERRATA macro)
to execute the required errata workaround.
Reused errata handling patch from Peter Ujfalusi peter.ujfal...@nokia.com
https://patchwork.kernel.org/patch/231191/
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dma.c | 134 ++--
arch/arm/plat-omap/include/plat/dma.h | 11 +++
2 files changed, 103 insertions(+), 42 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 77241e2..0ff82d0 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -195,6 +195,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
static int enable_1510_mode;
+static u32 errata;
static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -1216,12 +1217,8 @@ void omap_start_dma(int lch)
cur_lch = next_lch;
} while (next_lch != -1);
- } else if (cpu_is_omap242x() ||
- (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0)) {
-
- /* Errata: Need to write lch even if not using chaining */
+ } else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS))
dma_write(lch, CLNK_CTRL2, lch);
- }
omap_enable_channel_irq(lch);
@@ -1231,17 +1228,8 @@ void omap_start_dma(int lch)
dma_write(l, CCR1, lch);
} else {
l = dma_read(CCR2, lch);
- /*
-* Errata: Inter Frame DMA buffering issue (All OMAP2420 and
-* OMAP2430ES1.0): DMA will wrongly buffer elements if packing
-* and bursting is enabled. This might result in data gets
-* stalled in FIFO at the end of the block.
-* Workaround: DMA channels must have BUFFERING_DISABLED bit
-* set to guarantee no data will stay in the DMA FIFO in case
-* inter frame buffering occurs.
-*/
- if (cpu_is_omap2420() || (cpu_is_omap2430()
- (omap_type() == OMAP2430_REV_ES1_0)))
+
+ if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
l |= OMAP_DMA_CCR_EN;
@@ -1253,14 +1241,14 @@ EXPORT_SYMBOL(omap_start_dma);
void omap_stop_dma(int lch)
{
- u32 l;
+ u32 l = 0;
/* Disable all interrupts on the channel */
if (cpu_class_is_omap1())
dma_write(0, CICR1, lch);
- /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
- if (cpu_is_omap34xx() (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+ if (IS_DMA_ERRATA(DMA_ERRATA_i541)
+ (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
u32 sys_cf;
@@ -1367,11 +1355,7 @@ dma_addr_t omap_get_dma_src_pos(int lch)
else
offset = dma_read(CSAC2, lch);
- /*
-* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
-* read before the DMA controller finished disabling the channel.
-*/
- if (!cpu_is_omap15xx() offset == 0) {
+ if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0) {
if (cpu_class_is_omap1())
offset = dma_read(CSAC1, lch);
else
@@ -1966,7 +1950,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
{
int *channels;
u32 l, i;
- u32 sys_cf;
+ u32 sys_cf = 0;
/* Check for input params */
if (unlikely((chain_id 0 || chain_id = dma_lch_count))) {
@@ -1981,15 +1965,13 @@ int omap_stop_dma_chain_transfers(int chain_id)
}
channels = dma_linked_lch[chain_id].linked_dmach_q;
- /*
-* DMA Errata:
-* Special programming model needed to disable DMA before end of block
-*/
- sys_cf = dma_read(OCP_SYSCONFIG, 0);
- l = sys_cf;
- /* Middle mode reg set no Standby */
- l = ~((1 12)|(1 13));
- dma_write(l, OCP_SYSCONFIG, 0);
+ if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
+ sys_cf = dma_read(OCP_SYSCONFIG, 0);
+ l = sys_cf;
+ /* Middle mode reg set no Standby */
+ l = ~((1 12)|(1 13));
+ dma_write(l, OCP_SYSCONFIG, 0);
+ }
for (i = 0; i dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
@@ -2008,8 +1990,8 @@ int omap_stop_dma_chain_transfers(int chain_id)
/* Reset the Queue pointers */
OMAP_DMA_CHAIN_QINIT(chain_id);
- /*
[PATCH v3 04/13] OMAP2420: DMA: hwmod: add system DMA
Add OMAP2420 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..3a51392 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -38,6 +38,7 @@ static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -557,6 +558,89 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/* system dma */
+static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap2420_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32,
+ .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
+ { .name = 0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = 1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = 2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = 3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
+ .master = omap2420_dma_system_hwmod,
+ .slave = omap2420_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
+ omap2420_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap2420_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
+ omap2420_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2420_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2420_dma_hwmod_class,
+ .mpu_irqs = omap2420_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .slaves = omap2420_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
+ .masters= omap2420_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -569,6 +653,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_uart3_hwmod,
omap2420_i2c1_hwmod,
omap2420_i2c2_hwmod,
+ omap2420_dma_system_hwmod,
NULL,
};
--
1.7.1
--
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 v3 00/13] OMAP: DMA: hwmod and DMA as platform device
This patch series converts DMA library into platform device and hwmod adaptation is done for omap2+ processors. It also replaces cpu_*is* checks by moving omap1 and omap2+ processor code into repsective mach-omapx directories. The common code in plat-omap will use device attributes for differentiating omap1 and omap2 code. Build Report: omap1: Success for omap_h2_1610_defconfig omap2+: Success for omap2plus_defconfig Test Report: omap2+:(multiboot defconfig boots on all the omap2+ boards listed below): OMAP4BLAZE: http://pastebin.com/HVnim30G OMAP3630ZOOM3: http://pastebin.com/JJwrtP4F OMAP243SDP: http://pastebin.com/mz7cVQL3 omap1 : Not tested Test cases executed: 1. All applicable TI DMA tests which are located at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=dma/test_code;h=0d00de3c0fe6933b405c62da63f694883f3e4b8f;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253 2. Use case tests : TI MMC tests are executed with differenct types of files systems such as DOS, ext2, ext3 etc on omap4 blaze and omap3630 zoom3. More information can be found at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=mmc/test_code;h=d0bc1984eef46ac45719efb02b5c1f4193422a1b;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253 Dependencies: This patch series has dependency on omap_device patch: https://patchwork.kernel.org/patch/282212/ This patch series applies on: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Branch: master commit a83d12a47c9a8c78a184910150797045d69a1570 Merge: f9f47f5 c1fb8df Author: Tony Lindgren t...@atomide.com Date: Fri Oct 22 11:21:08 2010 -0700 Linux-omap rebuilt: Updated to v2.6.36, add 24xx uart fix Changelist summary: v3: Review comments fixed: http://www.listware.net/201008/linux-omap/89002-patch-v2-0011-omap-dma-hwmod-and-dma-as-platform-driver.html - created and tested on latest linux-omap master branch(2.6.36 kernel) v2: The review comments which are fixed can be found at: http://www.spinics.net/lists/linux-omap/msg34291.html http://www.spinics.net/lists/linux-omap/msg34292.html http://www.spinics.net/lists/linux-omap/msg34078.html http://www.spinics.net/lists/linux-omap/msg34083.html v1: These changes are based on comments received during internal discussions which has changes(compared to previous version) such as: - Code optimization - Patches are rearranged in more meaningful way so that git bisect works at any intermediate patch in the series. - Build tested for all omap's(OMAP1 and OMAP2PLUS) - Boot tested for OMAP3 and OMAP4(appreciate if some one tests on OMAP1/2) - Applicalbe tests are executed on OMAP3 and OMAP4 boards - Rebased and added descriptor autoloading feature(only for omap3630 and omap4) Benoit Cousson (1): OMAP4: DMA: hwmod: add system DMA G, Manjunath Kondaiah (12): OMAP: DMA: Replace read/write macros with functions OMAP: DMA: Introduce errata handling feature OMAP: DMA: Introduce DMA device attributes OMAP2420: DMA: hwmod: add system DMA OMAP2430: DMA: hwmod: add system DMA OMAP3: DMA: hwmod: add system DMA OMAP1: DMA: Introduce DMA driver as platform device OMAP2+: DMA: hwmod: Device registration OMAP: DMA: Convert DMA library into DMA platform Driver OMAP: DMA: Use DMA device attributes sDMA: descriptor autoloading feature OMAP: PM: DMA: Enable runtime pm arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 665 ++ arch/arm/mach-omap1/include/mach/dma.h | 51 + arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 1579 arch/arm/mach-omap2/include/mach/dma.h | 86 ++ arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 93 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 ++ arch/arm/plat-omap/dma.c | 1850 arch/arm/plat-omap/include/plat/dma.h | 387 --- 12 files changed, 3207 insertions(+), 1777 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap1/include/mach/dma.h create mode 100644 arch/arm/mach-omap2/dma.c create mode 100644 arch/arm/mach-omap2/include/mach/dma.h Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/13] OMAP2430: DMA: hwmod: add system DMA
Add OMAP2430 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 85
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..d3b7239 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -38,6 +38,7 @@ static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
static struct omap_hwmod omap2430_wd_timer2_hwmod;
+static struct omap_hwmod omap2430_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -569,6 +570,89 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/* dma_system */
+static struct omap_hwmod_class_sysconfig omap2430_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap2430_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+ .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_irq_info omap2430_dma_system_irqs[] = {
+ { .name = 0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = 1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = 2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = 3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap2430_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
+ .master = omap2430_dma_system_hwmod,
+ .slave = omap2430_l3_main_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_masters[] = {
+ omap2430_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap2430_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_slaves[] = {
+ omap2430_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2430_dma_system_hwmod = {
+ .name = dma,
+ .class = omap2430_dma_hwmod_class,
+ .mpu_irqs = omap2430_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .slaves = omap2430_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_dma_system_slaves),
+ .masters= omap2430_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap2430_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+ .flags = HWMOD_NO_IDLEST,
+};
+
static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_l3_main_hwmod,
omap2430_l4_core_hwmod,
@@ -581,6 +665,7 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_uart3_hwmod,
omap2430_i2c1_hwmod,
omap2430_i2c2_hwmod,
+ omap2430_dma_system_hwmod,
NULL,
};
--
1.7.1
--
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 v3 06/13] OMAP3: DMA: hwmod: add system DMA
Add OMAP3 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 93
1 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ed6bf4a..4a5231c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -45,6 +45,7 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
static struct omap_hwmod omap3xxx_i2c1_hwmod;
static struct omap_hwmod omap3xxx_i2c2_hwmod;
static struct omap_hwmod omap3xxx_i2c3_hwmod;
+static struct omap_hwmod omap3xxx_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -736,6 +737,97 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap3xxx_dma_system__l3 = {
+ .master = omap3xxx_dma_system_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= core_l3_ick,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+ .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap3xxx_dma_sysc,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap3xxx_dma_system_irqs[] = {
+ { .name = 0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = 1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = 2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = 3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_masters[] = {
+ omap3xxx_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dma_system = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_dma_system_hwmod,
+ .clk= core_l4_ick,
+ .addr = omap3xxx_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_slaves[] = {
+ omap3xxx_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+ .name = dma,
+ .class = omap3xxx_dma_hwmod_class,
+ .mpu_irqs = omap3xxx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+ .main_clk = core_l3_ick,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id= 1,
+ .module_bit = OMAP3430_ST_SDMA_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit= OMAP3430_ST_SDMA_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+ .masters= omap3xxx_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -751,6 +843,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_i2c1_hwmod,
omap3xxx_i2c2_hwmod,
omap3xxx_i2c3_hwmod,
+ omap3xxx_dma_system_hwmod,
NULL,
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
[PATCH v3 07/13] OMAP4: DMA: hwmod: add system DMA
From: Benoit Cousson b-cous...@ti.com
Add OMAP4 DMA hwmod structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99
1 files changed, 99 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0d5c6eb..f749f0d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#include plat/omap_hwmod.h
#include plat/cpu.h
+#include plat/dma.h
#include omap_hwmod_common_data.h
@@ -35,6 +36,7 @@
#define OMAP44XX_DMA_REQ_START 1
/* Backward references (IPs with Bus Master capability) */
+static struct omap_hwmod omap44xx_dma_system_hwmod;
static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
static struct omap_hwmod omap44xx_l3_instr_hwmod;
@@ -215,6 +217,14 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_1__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* dma_system - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
+ .master = omap44xx_dma_system_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
.master = omap44xx_l4_cfg_hwmod,
@@ -226,6 +236,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2
= {
/* l3_main_2 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
omap44xx_l3_main_1__l3_main_2,
+ omap44xx_dma_system__l3_main_2,
omap44xx_l4_cfg__l3_main_2,
};
@@ -1043,6 +1054,92 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap44xx_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+ .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
+ { .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
+ { .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
+ { .name = 2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
+ { .name = 3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
+ {
+ .pa_start = 0x4a056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_masters[] = {
+ omap44xx_dma_system__l3_main_2,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dma_system = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_dma_system_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_slaves[] = {
+ omap44xx_l4_cfg__dma_system,
+};
+
+static struct omap_hwmod omap44xx_dma_system_hwmod = {
+ .name = dma_system,
+ .class = omap44xx_dma_hwmod_class,
+ .mpu_irqs = omap44xx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_SDMA_SDMA_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_dma_system_slaves,
+
[PATCH v3 08/13] OMAP1: DMA: Introduce DMA driver as platform device
Register OMAP1 DMA driver as platform device and add support
for registering through platform device layer using resource
structures.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/dma.c | 182
arch/arm/mach-omap1/include/mach/dma.h | 29 +
2 files changed, 211 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap1/dma.c
create mode 100644 arch/arm/mach-omap1/include/mach/dma.h
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
new file mode 100644
index 000..e756069
--- /dev/null
+++ b/arch/arm/mach-omap1/dma.c
@@ -0,0 +1,182 @@
+/*
+ * dma.c - OMAP1/OMAP7xx-specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@ti.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/err.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/io.h
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/device.h
+
+#include plat/dma.h
+#include plat/tc.h
+
+#define OMAP1_DMA_BASE (0xfffed800)
+
+static struct resource res[] __initdata = {
+ [0] = {
+ .start = OMAP1_DMA_BASE,
+ .end= OMAP1_DMA_BASE + SZ_2K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .name = 0,
+ .start = INT_DMA_CH0_6,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .name = 1,
+ .start = INT_DMA_CH1_7,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .name = 2,
+ .start = INT_DMA_CH2_8,
+ .flags = IORESOURCE_IRQ,
+ },
+ [4] = {
+ .name = 3,
+ .start = INT_DMA_CH3,
+ .flags = IORESOURCE_IRQ,
+ },
+ [5] = {
+ .name = 4,
+ .start = INT_DMA_CH4,
+ .flags = IORESOURCE_IRQ,
+ },
+ [6] = {
+ .name = 5,
+ .start = INT_DMA_CH5,
+ .flags = IORESOURCE_IRQ,
+ },
+ [7] = {
+ .name = 6,
+ .start = INT_DMA_LCD,
+ .flags = IORESOURCE_IRQ,
+ },
+ /* irq's for omap16xx and omap7xx */
+ [8] = {
+ .name = 7,
+ .start = 53 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [9] = {
+ .name = 8,
+ .start = 54 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [10] = {
+ .name = 9,
+ .start = 55 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [11] = {
+ .name = 10,
+ .start = 56 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [12] = {
+ .name = 11,
+ .start = 57 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [13] = {
+ .name = 12,
+ .start = 58 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [14] = {
+ .name = 13,
+ .start = 59 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [15] = {
+ .name = 14,
+ .start = 60 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [16] = {
+ .name = 15,
+ .start = 61 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+ [17] = {
+ .name = 16,
+ .start = 62 + IH2_BASE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static int __init omap1_system_dma_init(void)
+{
+ struct omap_system_dma_plat_info*p;
+ struct platform_device *pdev;
+ int ret;
+
+ pdev = platform_device_alloc(omap_dma_system, 0);
+ if (!pdev) {
+ pr_err(%s: Unable to device alloc for dma\n,
+ __func__);
+ return -ENOMEM;
+ }
+
[PATCH v3 09/13] OMAP2+: DMA: hwmod: Device registration
Prepare omap2+ dma driver to use hwmod infrastructure
so that DMA driver can register as platform device.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/dma.c | 86
arch/arm/mach-omap2/include/mach/dma.h | 32
2 files changed, 118 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/dma.c
create mode 100644 arch/arm/mach-omap2/include/mach/dma.h
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
new file mode 100644
index 000..30b20cd
--- /dev/null
+++ b/arch/arm/mach-omap2/dma.c
@@ -0,0 +1,86 @@
+/*
+ * dma.c - OMAP2 specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@ti.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/err.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/io.h
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/device.h
+
+#include plat/irqs.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/dma.h
+
+static struct omap_device_pm_latency omap2_dma_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+/* One time initializations */
+static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void
*unused)
+{
+ struct omap_device *od;
+ struct omap_system_dma_plat_info*p;
+ char*name = omap_system_dma;
+
+ p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
+ if (!p) {
+ pr_err(%s: Unable to allocate pdata for %s:%s\n,
+ __func__, name, oh-name);
+ return -ENOMEM;
+ }
+ od = omap_device_build(name, 0, oh, p, sizeof(*p),
+ omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
+
+ if (IS_ERR(od)) {
+ pr_err(%s: Cant build omap_device for %s:%s.\n,
+ __func__, name, oh-name);
+ kfree(p);
+ return IS_ERR(od);
+ }
+ kfree(p);
+
+ return 0;
+}
+
+static int __init omap2_system_dma_init(void)
+{
+ int ret;
+
+ ret = omap_hwmod_for_each_by_class(dma,
+ omap2_system_dma_init_dev, NULL);
+
+ return ret;
+}
+arch_initcall(omap2_system_dma_init);
diff --git a/arch/arm/mach-omap2/include/mach/dma.h
b/arch/arm/mach-omap2/include/mach/dma.h
new file mode 100644
index 000..d0a7d5b
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/dma.h
@@ -0,0 +1,32 @@
+/*
+ * OMAP DMA controller register offsets.
+ *
+ * Copyright (C) 2003 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __ASM_ARCH_OMAP2_DMA_H
+#define __ASM_ARCH_OMAP2_DMA_H
+
+#endif /* __ASM_ARCH_OMAP2_DMA_H */
--
1.7.1
--
[PATCH v3 10/13] OMAP: DMA: Convert DMA library into DMA platform Driver
Convert DMA library into DMA platform driver and make use
of platform data provided by HWMOD data base for OMAP2PLUS onwards.
For OMAP1 processors, the DMA driver in mach-omap uses resource
structures for getting platform data.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/dma.c | 180 ++-
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dma.c | 209 +-
arch/arm/mach-omap2/include/mach/dma.h |3 +
arch/arm/plat-omap/dma.c | 321 +++-
arch/arm/plat-omap/include/plat/dma.h | 50 --
7 files changed, 538 insertions(+), 229 deletions(-)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9a304d8..b7dfc54 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o dma.o
obj-y += clock.o clock_data.o opp_data.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index e756069..38a7294 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -35,6 +35,81 @@
#include plat/tc.h
#define OMAP1_DMA_BASE (0xfffed800)
+#define OMAP1_LOGICAL_DMA_CH_COUNT 17
+
+static u32 errata;
+static u32 enable_1510_mode;
+
+enum {
+ GCR1 = 0, GSCR, GRST, HW_ID,
+ PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
+ PCHD_ID,CAPS_0_U, CAPS_0_L, CAPS_1_U,
+ CAPS_1_L, CAPS_2, CAPS_3, CAPS_4,
+ PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,
+
+ CH_COMMON_START,
+
+ /* Common Registers */
+ CSDP1, CCR1, CICR1, CSR1,
+ CEN1, CFN1, CSFI1, CSEI1,
+ CPC,CSAC1, CDAC1, CDEI1,
+ CDFI1, CLNK_CTRL1,
+
+ /* Channel specific register offsets */
+ CSSA_L, CSSA_U, CDSA_L, CDSA_U,
+ COLOR_L,COLOR_U,CCR1_2, LCH_CTRL,
+
+ CH_COMMON_END,
+};
+
+static u16 reg_map[] = {
+ [GCR1] = 0x400,
+ [GSCR] = 0x404,
+ [GRST] = 0x408,
+ [HW_ID] = 0x442,
+ [PCH2_ID] = 0x444,
+ [PCH0_ID] = 0x446,
+ [PCH1_ID] = 0x448,
+ [PCHG_ID] = 0x44a,
+ [PCHD_ID] = 0x44c,
+ [CAPS_0_U] = 0x44e,
+ [CAPS_0_L] = 0x450,
+ [CAPS_1_U] = 0x452,
+ [CAPS_1_L] = 0x454,
+ [CAPS_2]= 0x456,
+ [CAPS_3]= 0x458,
+ [CAPS_4]= 0x45a,
+ [PCH2_SR] = 0x460,
+ [PCH0_SR] = 0x480,
+ [PCH1_SR] = 0x482,
+ [PCHD_SR] = 0x4c0,
+
+ /* Common Registers */
+ [CSDP1] = 0x00,
+ [CCR1] = 0x02,
+ [CICR1] = 0x04,
+ [CSR1] = 0x06,
+ [CEN1] = 0x10,
+ [CFN1] = 0x12,
+ [CSFI1] = 0x14,
+ [CSEI1] = 0x16,
+ [CPC] = 0x18, /* 15xx only */
+ [CSAC1] = 0x18,
+ [CDAC1] = 0x1a,
+ [CDEI1] = 0x1c,
+ [CDFI1] = 0x1e,
+ [CLNK_CTRL1]= 0x28,
+
+ /* Channel specific register offsets */
+ [CSSA_L]= 0x08,
+ [CSSA_U]= 0x0a,
+ [CDSA_L]= 0x0c,
+ [CDSA_U]= 0x0e,
+ [COLOR_L] = 0x20,
+ [COLOR_U] = 0x22,
+ [CCR1_2]= 0x24,
+ [LCH_CTRL] = 0x2a,
+};
static struct resource res[] __initdata = {
[0] = {
@@ -130,9 +205,64 @@ static struct resource res[] __initdata = {
},
};
+static void __iomem *dma_base;
+static inline void dma_write(u16 val, int reg, int lch)
+{
+ if (reg CH_COMMON_START)
+ __raw_writew(val, dma_base + (reg_map[reg] + 0x40 * lch));
+ else
+ __raw_writew(val, dma_base + reg_map[reg]);
+}
+
+static inline u16 dma_read(int reg, int lch)
+{
+ if (reg CH_COMMON_START)
+ return __raw_readw(dma_base + (reg_map[reg] + 0x40 * lch));
+ else
+ return __raw_readw(dma_base + reg_map[reg]);
+}
+
+static void omap1_show_dma_caps(void)
+{
+ if (enable_1510_mode) {
+ printk(KERN_INFO DMA support for OMAP15xx initialized\n);
+ } else {
+ u16 w;
+ printk(KERN_INFO OMAP DMA hardware version %d\n,
+ dma_read(HW_ID, 0));
+ printk(KERN_INFO DMA
[PATCH v3 12/13] OMAP2+: DMA: descriptor autoloading feature
Add sDMA driver support for descriptor autoloading feature.
Descriptor autoloading is OMAP sDMA v5 hardware capability that can be
exploited for scatter gather scenarios, currently available in OMAP3630
and OMAP4430.
The feature works as described below.
1. A sDMA channel is programmed to be in 'linked list' mode.
2) The client (sDMA user) provides a list of descriptors in a linked
list format
3) Each of the 'descriptor' (element in the linked list) contains an
updated set of DMA configuration register values.
4) Client starts DMA transfer.
5) sDMA controller loads the first element to its register configuration
memory and executes the transfer.
6) After completion, loads the next element (in linked list) to
configuration memory and executes the transfer, without MCU
intervention.
7) Interrupt is generated after all transfers are completed; this can be
configured to be done differently.
Configurations and additional features
1) Fast mode non-fast mode
Fast mode/non-fast decides on how the first transfer begins. In non-fast
mode, the first element in the linked list is loaded only after
completing the
transfer according to the configurations already in the sDMA channel
registers.
In fast mode, the loading of the first element precedes the transfer.
2) Pause / resume of transfers
A transfer can be paused after a descriptor set has been loaded,
provided the pause bit' is set in the linked list element.
An ongoing transfer cannot be paused. If the 'pause bit' is set,
transfer is not started after loading the register set from memory.
Such a transfer can be resumed later.
3) Descriptor types
Three possible configurations of descriptors (initialized as linked list
elements) are possible.
Type 1 provides the maximum flexibility, which contains most register
definitions of a DMA logical channel.
Fewer options are present in type 2.
Type 3 can just modify source/destinations address of transfers. In all
transfers, unmodified registers settings are maintained for the next
transfer.
Patch provides options / API for
1) Setting up a descriptor loading for DMA channel for sg type transfers
2) configuration with linked list elements
3) Starting / pause and resume of the said transfers, query state
4) Clearing the sglist mode
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/dma.c | 257 +
arch/arm/plat-omap/dma.c |1 +
arch/arm/plat-omap/include/plat/dma.h | 111 ++-
3 files changed, 368 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 6df4835..397e90e 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -41,6 +41,7 @@
static u32 errata;
static int dma_chan_count;
+static int dma_caps0_status;
static struct omap_dma_dev_attr *d;
static struct dma_link_info *dma_linked_lch;
@@ -240,6 +241,76 @@ static inline void omap2_disable_lnk(int lch)
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
}
+static inline void omap_dma_list_set_ntype(struct omap_dma_sglist_node *node,
+ int value)
+{
+ node-num_of_elem |= ((value) 29);
+}
+
+static void omap_set_dma_sglist_pausebit(
+ struct omap_dma_list_config_params *lcfg, int nelem, int set)
+{
+ struct omap_dma_sglist_node *sgn = lcfg-sghead;
+
+ if (nelem 0 nelem lcfg-num_elem) {
+ lcfg-pausenode = nelem;
+ sgn += nelem;
+
+ if (set)
+ sgn-next_desc_add_ptr |= DMA_LIST_DESC_PAUSE;
+ else
+ sgn-next_desc_add_ptr = ~(DMA_LIST_DESC_PAUSE);
+ }
+}
+
+static int dma_sglist_set_phy_params(struct omap_dma_sglist_node *sghead,
+ dma_addr_t phyaddr, int nelem)
+{
+ struct omap_dma_sglist_node *sgcurr, *sgprev;
+ dma_addr_t elem_paddr = phyaddr;
+
+ for (sgprev = sghead;
+ sgprev sghead + nelem;
+ sgprev++) {
+
+ sgcurr = sgprev + 1;
+ sgprev-next = sgcurr;
+ elem_paddr += (int)sizeof(*sgcurr);
+ sgprev-next_desc_add_ptr = elem_paddr;
+
+ switch (sgcurr-desc_type) {
+ case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
+ omap_dma_list_set_ntype(sgprev, 1);
+ break;
+
+ case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
+ /* intentional no break */
+ case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
+ omap_dma_list_set_ntype(sgprev, 2);
+ break;
+
+ case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3a:
+ /* intentional no break */
+ case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3b:
+
[PATCH v3 13/13] OMAP: PM: DMA: Enable runtime pm
Enable runtime pm and use pm_runtime_get and pm_runtime_put
for OMAP DMA driver.
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/dma.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 41b14b0..feac7ee 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -35,6 +35,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/delay.h
+#include linux/pm_runtime.h
#include asm/system.h
#include mach/hardware.h
@@ -367,6 +368,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
chan = dma_chan + free_ch;
chan-dev_id = dev_id;
+ pm_runtime_get(pd-dev);
+
if (d-dev_caps IS_WORD_16)
p-clear_lch_regs(free_ch);
else
@@ -452,6 +455,7 @@ void omap_free_dma(int lch)
omap_clear_dma(lch);
p-clear_dma_sglist_mode(lch);
}
+ pm_runtime_put(pd-dev);
spin_lock_irqsave(dma_chan_lock, flags);
dma_chan[lch].dev_id = -1;
dma_chan[lch].next_lch = -1;
@@ -819,6 +823,11 @@ static int __devinit omap_system_dma_probe(struct
platform_device *pdev)
dma_chan_count = d-chan_count;
dma_chan= d-chan;
+ /* Enable run time PM */
+ pm_runtime_enable(pd-dev);
+
+ /* Accessing hw registers, get clock */
+ pm_runtime_get(pd-dev);
for (ch = 0; ch dma_chan_count; ch++) {
unsigned long flags;
omap_clear_dma(ch);
@@ -846,6 +855,10 @@ static int __devinit omap_system_dma_probe(struct
platform_device *pdev)
dma_chan[0].dev_id = 0;
dma_chan[1].dev_id = 1;
}
+
+ if (!omap_dma_reserve_channels)
+ pm_runtime_put(pd-dev);
+
return 0;
exit_release_region:
--
1.7.1
--
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] PERF(kernel): Cleanup power events V2
On Tuesday 26 October 2010 15:17:43 Thomas Renninger wrote: On Tuesday 26 October 2010 13:54:22 Ingo Molnar wrote: * Thomas Renninger tr...@suse.de wrote: ... If cpuidle is not registered, the events you get are arch specific. I mean they are arch specific anyway, but with cpuidle you can build up an arch independent userspace framework nicely by looking up name/desc/power/... of an cpu_idle event in cpuidle sysfs as described above. About cpuidle and cpu_idle events: There is some oddness that: arch specific code which registers for cpuidle has to throw the cpu_idle enter sleep state X event and the generic cpuidle framework triggers the exit event. So as there are only cpu_idle events in drivers/idle/intel_idle.c, but not in drivers/acpi/processor_idle.c, I expect that processor.ko idle driver is broken and only exit states are sent. Ideally all cpuidle events should be thrown in cpuidle.c like this: trace_processor_idle(target_state, smp_processor_id()); dev-last_residency = target_state-enter(dev, target_state); trace_processor_idle(PWR_EVENT_EXIT, smp_processor_id()); My patches do not touch this behavior. If, it was broken before. I'll look at it separately. Thomas -- 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] tidspbridge: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns
On Tue, Oct 26, 2010 at 12:43 AM, Paul Walmsley p...@pwsan.com wrote: arch/arm/mach-omap2/dsp.c | 4 arch/arm/plat-omap/include/plat/dsp.h | 4 drivers/staging/tidspbridge/core/tiomap3430.c | 13 ++--- Could you please split the tiomap3430.c change into a separate patch? That should go in via the staging tree once this series is accepted. No problem. Regards, Omar -- 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 0/8] staging: tidspbridge - misc fixes
gre...@suse.de wrote: On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote: This set of patches fix some issues found in lastest tree. Fernando Guzman Lugo (8): staging: tidspbridge - remove req_addr from proc_map staging: tidspbridge - add kconfig parameter for DMM size staging: tidspbridge - change mmufault tasklet to a workqueue staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow staging: tidspbridge - use GTP7 for DSP stack dump staging: tidspbridge - remove disabling twl when printing DSP stack staging: tidspbridge - fix some issues after iommu patches staging: tidspbridge - make sync_wait_on_event interruptible Are any of these really applicable for .37 after .37-rc1? Or can they wait for .38? As of right now the dspbridge doesn't work, and there's a mess of dependencies to get it working. - omap iommu: linux-omap pull request has already been sent, and there's no target when the omap iommu pull request will be sent... right Hiroshi? - linux-arm: some patches are needed, and it's not clear if they'll make it to .37-rc1, or .37 at all. So, no, I don't think these patches should considered as of right now. In fact, these affect mostly iommu, and I think until those other dependencies are resolved, we should revert back to a previous point where the driver was actually working. What is guideline in staging when a driver is broken like this? Cheers. -- Felipe Contreras -- 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 v3 01/13] OMAP: DMA: Replace read/write macros with functions
G, Manjunath Kondaiah had written, on 10/26/2010 08:25 AM, the following:
[...]
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index f5c5b8d..77241e2 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,147 @@
#undef DEBUG
+enum {
+ GCR1 = 0, GSCR, GRST, HW_ID,
+ PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
+ PCHD_ID,CAPS1_0_U, CAPS1_0_L, CAPS1_1_U,
+ CAPS1_1_L, CAPS1_2,CAPS1_3,CAPS1_4,
+ PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,
[...]
+};
+
+static u16 reg_map_omap1[] = {
+ [GCR1] = 0x400,
+ [GSCR] = 0x404,
+ [GRST] = 0x408,
+ [HW_ID] = 0x442,
+ [PCH2_ID] = 0x444,
+ [PCH0_ID] = 0x446,
+ [PCH1_ID] = 0x448,
+ [PCHG_ID] = 0x44a,
+ [PCHD_ID] = 0x44c,
[...]
+ [LCH_CTRL] = 0x2a,
+};
+
+enum {
+ REVISION = 0, GCR2, IRQSTATUS_L0, IRQSTATUS_L1,
+ IRQSTATUS_L2, IRQSTATUS_L3, IRQENABLE_L0, IRQENABLE_L1,
[...]
+
+ /* OMAP4 specific registers */
+ CDP,CNDP, CCDN,
+
+ OMAP2_CH_COMMON_END,
+};
+
+static u16 reg_map_omap2[] = {
+ [REVISION] = 0x00,
+ [GCR2] = 0x78,
+ [IRQSTATUS_L0] = 0x08,
+ [IRQSTATUS_L1] = 0x0c,
[..]
+ /* OMAP4 specific registers */
+ [CDP] = 0xd0,
+ [CNDP] = 0xd4,
+ [CCDN] = 0xd8,
+};
+
dumb question: any reason why a struct wont do?
struct reg_map_omap2 {
u16 revision;
...
...
}
[..]
-#define dma_read(reg) \
-({ \
- u32 __val; \
- if (cpu_class_is_omap1()) \
- __val = __raw_readw(omap_dma_base + OMAP1_DMA_##reg); \
- else\
- __val = __raw_readl(omap_dma_base + OMAP_DMA4_##reg); \
- __val; \
-})
-
-#define dma_write(val, reg)\
-({ \
- if (cpu_class_is_omap1()) \
- __raw_writew((u16)(val), omap_dma_base + OMAP1_DMA_##reg); \
- else\
- __raw_writel((val), omap_dma_base + OMAP_DMA4_##reg); \
-})
+static inline void dma_write(u32 val, int reg, int lch)
+{
+ if (cpu_class_is_omap1()) {
+ if (reg OMAP1_CH_COMMON_START)
+ __raw_writew(val, dma_base +
+ (reg_map_omap1[reg] + 0x40 * lch));
+ else
+ __raw_writew(val, dma_base + reg_map_omap1[reg]);
+ } else {
+ if (reg OMAP2_CH_COMMON_START)
+ __raw_writel(val, dma_base +
+ (reg_map_omap2[reg] + 0x60 * lch));
+ else
+ __raw_writel(val, dma_base + reg_map_omap2[reg]);
+ }
+}
+
+static inline u32 dma_read(int reg, int lch)
+{
+ u32 val;
+
+ if (cpu_class_is_omap1()) {
+ if (reg OMAP1_CH_COMMON_START)
+ val = __raw_readw(dma_base +
+ (reg_map_omap1[reg] + 0x40 * lch));
+ else
+ val = __raw_readw(dma_base + reg_map_omap1[reg]);
+ } else {
+ if (reg OMAP2_CH_COMMON_START)
+ val = __raw_readl(dma_base +
+ (reg_map_omap2[reg] + 0x60 * lch));
+ else
+ val = __raw_readl(dma_base + reg_map_omap2[reg]);
+ }
+ return val;
+}
What is the benefit of using inline function here? would'nt we increase
code size? cant we use a function pointer initialized to class1 or rest?
Quote from CodingStyle (15):
A reasonable rule of thumb is to not put inline at functions that have more
than 3 lines of code in them. An exception to this rule are the cases where
a parameter is known to be a compiletime constant, and as a result of this
constantness you *know* the compiler will be able to optimize most of your
function away at compile time. For a good example of this later case, see
the kmalloc() inline function.
is the expectation that cpu_class_is_omap1 compile time constant hence
the actual compiled in code is smaller -candidate for inline?
#ifdef CONFIG_ARCH_OMAP15XX
/* Returns 1 if the DMA module is in OMAP1510-compatible mode, 0 otherwise */
@@ -209,11
Re: [PATCH 0/8] staging: tidspbridge - misc fixes
On Tue, Oct 26, 2010 at 9:43 AM, Felipe Contreras felipe.contre...@nokia.com wrote: gre...@suse.de wrote: On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote: This set of patches fix some issues found in lastest tree. Fernando Guzman Lugo (8): staging: tidspbridge - remove req_addr from proc_map staging: tidspbridge - add kconfig parameter for DMM size staging: tidspbridge - change mmufault tasklet to a workqueue staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow staging: tidspbridge - use GTP7 for DSP stack dump staging: tidspbridge - remove disabling twl when printing DSP stack staging: tidspbridge - fix some issues after iommu patches staging: tidspbridge - make sync_wait_on_event interruptible Are any of these really applicable for .37 after .37-rc1? Or can they wait for .38? As of right now the dspbridge doesn't work, and there's a mess of dependencies to get it working. Just to note that there will be one more dependency for SCM changes[1] that will fix compilation, as these need to climb from linux-omap (if accepted) before applying tidspbridge chunks. Regards, Omar --- [1] http://marc.info/?l=linux-omapm=128779652429922w=2 -- 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] PERF(kernel): Cleanup power events V2
On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnar mi...@elte.hu wrote:
How will future PCI (or other device) power saving tracepoints be called?
Might be more consistent to use:
power:cpu_idle
power:machine_idle
power:device_idle
Agree with this.
FYI, I have a runtime_pm tracepoint currently cooking. Here is
preliminary patch.
Can this be a candidate for a power:device_idle tracepoint?
Regards,
Pierre
From 3d5e03405f590d470ecfa59c8b9759915bf29307 Mon Sep 17 00:00:00 2001
From: Pierre Tardy pierre.ta...@intel.com
Date: Fri, 22 Oct 2010 03:07:07 -0500
Subject: [PATCH] trace/runtime_pm: add runtime_pm trace event
based on the recent hook from Arjan for powertop statistics
we add a tracepoint in order for pytimechart to display
the runtime_pm activity over time, and versus other events.
Signed-off-by: Pierre Tardy pierre.ta...@intel.com
---
drivers/base/power/runtime.c |3 ++-
include/trace/events/power.h | 35 +++
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index b78c401..0f38447 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -9,6 +9,7 @@
#include linux/sched.h
#include linux/pm_runtime.h
#include linux/jiffies.h
+#include trace/events/power.h
static int __pm_runtime_resume(struct device *dev, bool from_wq);
static int __pm_request_idle(struct device *dev);
@@ -159,9 +160,9 @@ void update_pm_runtime_accounting(struct device *dev)
static void __update_runtime_status(struct device *dev, enum rpm_status status)
{
update_pm_runtime_accounting(dev);
+ trace_runtime_pm_status(dev, status);
dev-power.runtime_status = status;
}
-
/**
* __pm_runtime_suspend - Carry out run-time suspend of given device.
* @dev: Device to suspend.
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 286784d..dd57c29 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -6,6 +6,7 @@
#include linux/ktime.h
#include linux/tracepoint.h
+#include linux/device.h
#ifndef _TRACE_POWER_ENUM_
#define _TRACE_POWER_ENUM_
@@ -75,6 +76,40 @@ TRACE_EVENT(power_end,
);
+#ifdef CONFIG_PM_RUNTIME
+#define rpm_status_name(status) { RPM_##status, #status }
+#define show_rpm_status_name(val) \
+ __print_symbolic(val, \
+ rpm_status_name(SUSPENDED), \
+ rpm_status_name(SUSPENDING),\
+ rpm_status_name(RESUMING), \
+ rpm_status_name(ACTIVE) \
+ )
+TRACE_EVENT(runtime_pm_status,
+
+ TP_PROTO(struct device *dev, int new_status),
+
+ TP_ARGS(dev, new_status),
+
+ TP_STRUCT__entry(
+ __string(devname,dev_name(dev))
+ __string(drivername,dev_driver_string(dev))
+ __field(u32, prev_status)
+ __field(u32, status)
+ ),
+
+ TP_fast_assign(
+ __assign_str(devname, dev_name(dev));
+ __assign_str(drivername, dev_driver_string(dev));
+ __entry-prev_status = (u32)dev-power.runtime_status;
+ __entry-status = (u32)new_status;
+ ),
+
+ TP_printk(driver=%s dev=%s prev_status=%s status=%s,
__get_str(drivername),__get_str(devname),
+ show_rpm_status_name(__entry-prev_status),
show_rpm_status_name(__entry-status))
+);
+#endif /* CONFIG_PM_RUNTIME */
+
/*
* The clock events are used for clock enable/disable and for
* clock rate change
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8] staging: tidspbridge - misc fixes
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@nokia.com] Sent: Tuesday, October 26, 2010 9:44 AM To: gre...@suse.de; Guzman Lugo, Fernando Cc: hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 0/8] staging: tidspbridge - misc fixes gre...@suse.de wrote: On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote: This set of patches fix some issues found in lastest tree. Fernando Guzman Lugo (8): staging: tidspbridge - remove req_addr from proc_map staging: tidspbridge - add kconfig parameter for DMM size staging: tidspbridge - change mmufault tasklet to a workqueue staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow staging: tidspbridge - use GTP7 for DSP stack dump staging: tidspbridge - remove disabling twl when printing DSP stack staging: tidspbridge - fix some issues after iommu patches staging: tidspbridge - make sync_wait_on_event interruptible Are any of these really applicable for .37 after .37-rc1? Or can they wait for .38? I would like to merge as soon as they can becase most of them Some fixes, However the patch 2/7 has a dependency on an iommu Patch and if it is no merged first the compilation will be broken. So maybe they can be marged as soon as iommu patches are merged. As of right now the dspbridge doesn't work, and there's a mess of dependencies to get it working. - omap iommu: linux-omap pull request has already been sent, and there's no target when the omap iommu pull request will be sent... right Hiroshi? - linux-arm: some patches are needed, and it's not clear if they'll make it to .37-rc1, or .37 at all. So, no, I don't think these patches should considered as of right now. In fact, these affect mostly iommu, and I think until those other dependencies are resolved, we should revert back to a previous point where the driver was actually working. That looks like double work, having the revert now to merge after. If Someone needs tidspbridge withouts those patche, they can go back to A previous commit. The issues will be fixed as soon as the dependencies Are merged. Regards, Fernando. What is guideline in staging when a driver is broken like this? Cheers. -- Felipe Contreras -- 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 8/8] staging: tidspbridge - make sync_wait_on_event interruptible
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Monday, October 25, 2010 7:59 PM To: Guzman Lugo, Fernando Cc: gre...@suse.de; felipe.contre...@nokia.com; hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: So that avoid non-killable process. It would be useful to interrupt these tasks from user-space. A separate ioctl to do that would be needed. I don't see use case where that could be needed. It is only To avoid a nonkillable task in the case the user pass an infinite Timeout. If you have some test case where that ioctl would be needed Please share it in order to find the best solution. Regards, Fernando. -- Felipe Contreras -- 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/8] staging: tidspbridge - remove req_addr from proc_map
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Tuesday, October 26, 2010 6:46 AM To: Guzman Lugo, Fernando Cc: gre...@suse.de; felipe.contre...@nokia.com; hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: The device address is assigned by tidspbridge no need for that parameter anymore. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com This would break the API with user-space, right? Yes, user-space needs to be changed accordingly. I think this change should be delayed, preferably after we have a working tidspbridge. The issue you were seeing must be fixed with patch 2/8, and Having all the dependencies tidspbridge has to be working Properly. Regards, Fernando. -- Felipe Contreras -- 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] PERF(kernel): Cleanup power events V2
On 10/26/2010 8:32 AM, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 2:10 AM, Ingo Molnarmi...@elte.hu wrote: How will future PCI (or other device) power saving tracepoints be called? Might be more consistent to use: power:cpu_idle power:machine_idle power:device_idle Agree with this. FYI, I have a runtime_pm tracepoint currently cooking. Here is preliminary patch. Can this be a candidate for a power:device_idle tracepoint? I would like to see a slightly more advanced tracepoint do the runtime pm framework; specifically I'd like to see the comm of the process that's taking a refcount on a device (that way, powertop can track which process keeps a device busy) -- 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 v2 4/4] staging: tidspbridge: use new SCM DSP boot control fns
From: Paul Walmsley p...@pwsan.com Use the new functions from SCM layer instead of handling registers directly with __raw_writel, as explained in: http://marc.info/?l=linux-omapm=128779652429922w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/staging/tidspbridge/core/tiomap3430.c | 13 ++--- 1 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c index f22bc12..b91d911 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430.c +++ b/drivers/staging/tidspbridge/core/tiomap3430.c @@ -23,7 +23,7 @@ #include dspbridge/host_os.h #include linux/mm.h #include linux/mmzone.h -#include plat/control.h +#include plat/iva2_dsp.h /* --- DSP/BIOS Bridge */ #include dspbridge/dbdefs.h @@ -293,6 +293,7 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt, u32 clk_cmd; struct io_mgr *hio_mgr; u32 ul_load_monitor_timer; + u8 bootmode; struct omap_dsp_platform_data *pdata = omap_dspbridge_dev-dev.platform_data; @@ -334,15 +335,13 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt, OMAP3430_RST1_IVA2_MASK, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL); /* Mask address with 1K for compatibility */ - __raw_writel(dsp_addr OMAP3_IVA2_BOOTADDR_MASK, - OMAP343X_CTRL_REGADDR( - OMAP343X_CONTROL_IVA2_BOOTADDR)); + dsp_addr = OMAP3_IVA2_BOOTADDR_MASK; + (*pdata-set_dsp_bootaddr)(dsp_addr); /* * Set bootmode to self loop if dsp_debug flag is true */ - __raw_writel((dsp_debug) ? OMAP3_IVA2_BOOTMOD_IDLE : 0, - OMAP343X_CTRL_REGADDR( - OMAP343X_CONTROL_IVA2_BOOTMOD)); + bootmode = dsp_debug ? OMAP_IVA2_DSP_BOOTMODE_IDLE : 0; + (*pdata-set_dsp_bootmode)(bootmode); } } -- 1.7.1 -- 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 v2 2/4] OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions
From: Paul Walmsley p...@pwsan.com
Update the DSP reset code in pm34xx.c to use one of the new SCM DSP
boot control functions, omap2430_ctrl_set_dsp_bootmode().
This reset code should be moved out to a separate function to be
called by the hwmod reset process at some point. Also, 2430
should be initializing the DSP in a similar fashion.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm34xx.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8c8f1ac..b90b1fb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -37,6 +37,7 @@
#include plat/prcm.h
#include plat/gpmc.h
#include plat/dma.h
+#include plat/iva2_dsp.h
#include asm/tlbflush.h
@@ -614,6 +615,7 @@ static struct platform_suspend_ops omap_pm_ops = {
* function forces the IVA2 into idle state so it can go
* into retention/off and thus allow full-chip retention/off.
*
+ * XXX This should be handled by the hwmod.
**/
static void __init omap3_iva_idle(void)
{
@@ -635,9 +637,7 @@ static void __init omap3_iva_idle(void)
cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK,
OMAP3430_IVA2_MOD, CM_FCLKEN);
- /* Set IVA2 boot mode to 'idle' */
- omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
-OMAP343X_CONTROL_IVA2_BOOTMOD);
+ omap2430_ctrl_set_dsp_bootmode(OMAP_IVA2_DSP_BOOTMODE_IDLE);
/* Un-reset IVA2 */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
--
1.7.1
--
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 v3 3/4] OMAP: dsp: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns
From: Paul Walmsley p...@pwsan.com
DSPBridge currently tries to __raw_writel() to the System Control
Module to control the DSP boot process. This is a layering violation;
this is SoC-specific code, and belongs in a file in
arch/arm/mach-omap2/*. None of those CM and PRM register accesses
through struct platform_data belong under drivers/. (Nor would they
belong in DSP platform init code in arch/arm/mach-omap2/* - such code
must use the clock, clockdomain, powerdomain, omap_device, and
omap_hwmod layers that are provided for this purpose.)
The immediate problem, however, is that after commit
346a5c890a55495c718394b74214be1de9303cf6, this code can no longer compile.
So to fix this immediate problem, convert the DSP boot control code to
use platform_data function pointers.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: fernando.l...@ti.com
---
arch/arm/mach-omap2/dsp.c |4
arch/arm/plat-omap/include/plat/dsp.h |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index 6feeeae..307f67a 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -12,6 +12,7 @@
*/
#include linux/platform_device.h
+#include control.h
#include prm.h
#include cm.h
#ifdef CONFIG_BRIDGE_DVFS
@@ -31,6 +32,9 @@ static struct omap_dsp_platform_data omap_dsp_pdata
__initdata = {
.cpu_set_freq = omap_pm_cpu_set_freq,
.cpu_get_freq = omap_pm_cpu_get_freq,
#endif
+ .set_dsp_bootaddr = omap2430_ctrl_set_dsp_bootaddr,
+ .set_dsp_bootmode = omap2430_ctrl_set_dsp_bootmode,
+
.dsp_prm_read = prm_read_mod_reg,
.dsp_prm_write = prm_write_mod_reg,
.dsp_prm_rmw_bits = prm_rmw_mod_reg_bits,
diff --git a/arch/arm/plat-omap/include/plat/dsp.h
b/arch/arm/plat-omap/include/plat/dsp.h
index 9c604b3..34e2bd8 100644
--- a/arch/arm/plat-omap/include/plat/dsp.h
+++ b/arch/arm/plat-omap/include/plat/dsp.h
@@ -10,7 +10,11 @@ struct omap_dsp_platform_data {
unsigned long (*cpu_get_freq) (void);
unsigned long mpu_speed[6];
+ void (*set_dsp_bootaddr)(u32 pa);
+ void (*set_dsp_bootmode)(u8 mode);
+
/* functions to write and read PRCM registers */
+ /* XXX None of this should be here */
void (*dsp_prm_write)(u32, s16 , u16);
u32 (*dsp_prm_read)(s16 , u16);
u32 (*dsp_prm_rmw_bits)(u32, u32, s16, s16);
--
1.7.1
--
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 v2 0/4] tidspbridge: SCM layer violation fixes
This is the patch series shared by Paul, for a short term fix to a compile break due SCM layer layer violations from tidspbridge driver, where the latter is used to write directly into registers and use SCM layer macros, among other layer bypassing. patch: staging: tidspbridge: use new SCM DSP boot control fns was split from its original version, it is meant to be on hold until the rest of the series gets upstreamed and can be found in the staging tree (unless best advice is given). Paul Walmsley (4): OMAP: control: add functions for DSP boot address/mode control OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions OMAP: dsp: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns staging: tidspbridge: use new SCM DSP boot control fns arch/arm/mach-omap2/control.c | 51 ++ arch/arm/mach-omap2/control.h | 16 --- arch/arm/mach-omap2/dsp.c |4 ++ arch/arm/mach-omap2/pm34xx.c |6 +- arch/arm/plat-omap/include/plat/dsp.h |4 ++ arch/arm/plat-omap/include/plat/iva2_dsp.h| 56 + drivers/staging/tidspbridge/core/tiomap3430.c | 13 +++--- 7 files changed, 133 insertions(+), 17 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h -- 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 v2 1/4] OMAP: control: add functions for DSP boot address/mode control
From: Paul Walmsley p...@pwsan.com
Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control. These
registers wound up in the System Control Module. Other kernel code
that wishes to control the DSP's boot process should now use these
functions to do so; subsequent patches implement this in the two
in-tree users of these functions.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/control.c | 51 +
arch/arm/mach-omap2/control.h | 16 ---
arch/arm/plat-omap/include/plat/iva2_dsp.h | 56
3 files changed, 116 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..90fae36 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,6 +209,57 @@ void omap4_ctrl_pad_writel(u32 val, u16 offset)
__raw_writel(val, OMAP4_CTRL_PAD_REGADDR(offset));
}
+/*
+ * OMAP3 DSP control functions
+ */
+
+/**
+ * omap2430_ctrl_set_dsp_bootaddr - set the DSP's boot address
+ * @pa: DSP boot address (in physical memory)
+ *
+ * Set the DSP's boot address. This is an address in physical memory.
+ * No return value. XXX The TRM claims that this is an index to a
+ * 4kByte page. If so, why is the bitfield 21 bits wide, rather than
+ * 20?
+ */
+void omap2430_ctrl_set_dsp_bootaddr(u32 pa)
+{
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+ WARN(1, control: %s: not supported on this SoC\n, __func__);
+ return;
+ }
+
+ WARN(pa ~OMAP_CTRL_DSP_BOOTADDR_MASK,
+control: %s: invalid DSP boot address %08x\n, __func__, pa);
+
+ omap_ctrl_writel(pa, OMAP243X_CONTROL_IVA2_BOOTADDR);
+}
+
+/**
+ * omap2430_ctrl_set_dsp_bootmode - set the DSP's boot mode
+ * @mode: DSP boot mode (described below)
+ *
+ * Sets the DSP boot mode - see OMAP3 TRM revision ZH section 7.4.7.4
+ * IVA2.2 Boot Registers. Known values of @mode include 0, to boot
+ * directly to the address supplied by omap2_ctrl_set_dsp_bootaddr();
+ * 1, to boot to the DSP's ROM code and idle, waiting for interrupts;
+ * 2, to boot to the DSP's ROM code and spin in an idle loop; 3, to
+ * copy the user's bootstrap code from the DSP's internal memory and
+ * execute it (XXX how does the DSP know where to copy from?); and 4,
+ * to execute the DSP ROM code's context restore code. No return
+ * value.
+ */
+void omap2430_ctrl_set_dsp_bootmode(u8 mode)
+{
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+ WARN(1, control: %s: not supported on this SoC\n, __func__);
+ return;
+ }
+
+ omap_ctrl_writel(mode, OMAP243X_CONTROL_IVA2_BOOTMOD);
+}
+
+
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
/*
* Clears the scratchpad contents in case of cold boot-
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..ac14e0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -258,11 +258,6 @@
/* CONTROL_PROG_IO1 bits */
#define OMAP3630_PRG_SDMMC1_SPEEDCTRL (1 20)
-/* CONTROL_IVA2_BOOTMOD bits */
-#define OMAP3_IVA2_BOOTMOD_SHIFT 0
-#define OMAP3_IVA2_BOOTMOD_MASK(0xf 0)
-#define OMAP3_IVA2_BOOTMOD_IDLE(0x1 0)
-
/* CONTROL_PADCONF_X bits */
#define OMAP3_PADCONF_WAKEUPEVENT0 (1 15)
#define OMAP3_PADCONF_WAKEUPENABLE0(1 14)
@@ -280,7 +275,7 @@
#define AM35XX_CPGMAC_FCLK_SHIFT9
#define AM35XX_VPFE_FCLK_SHIFT 10
-/*AM35XX CONTROL_LVL_INTR_CLEAR bits*/
+/* AM35XX CONTROL_LVL_INTR_CLEAR bits */
#define AM35XX_CPGMAC_C0_MISC_PULSE_CLRBIT(0)
#define AM35XX_CPGMAC_C0_RX_PULSE_CLR BIT(1)
#define AM35XX_CPGMAC_C0_RX_THRESH_CLR BIT(2)
@@ -290,7 +285,7 @@
#define AM35XX_VPFE_CCDC_VD1_INT_CLR BIT(6)
#define AM35XX_VPFE_CCDC_VD2_INT_CLR BIT(7)
-/*AM35XX CONTROL_IP_SW_RESET bits*/
+/* AM35XX CONTROL_IP_SW_RESET bits */
#define AM35XX_USBOTGSS_SW_RST BIT(0)
#define AM35XX_CPGMACSS_SW_RST BIT(1)
#define AM35XX_VPFE_VBUSP_SW_RST BIT(2)
@@ -330,6 +325,10 @@
#defineFEAT_NEON 0
#defineFEAT_NEON_NONE 1
+/*
+ * DSP booting-related constants
+ */
+#define OMAP_CTRL_DSP_BOOTADDR_MASK0xfc00
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
@@ -351,6 +350,9 @@ extern u32 omap3_arm_context[128];
extern void omap3_control_save_context(void);
extern void omap3_control_restore_context(void);
+extern void omap2430_ctrl_set_dsp_bootaddr(u32 pa);
+extern void omap2430_ctrl_set_dsp_bootmode(u8 mode);
+
#else
#define omap_ctrl_base_get() 0
#define omap_ctrl_readb(x) 0
diff --git a/arch/arm/plat-omap/include/plat/iva2_dsp.h
b/arch/arm/plat-omap/include/plat/iva2_dsp.h
new file mode 100644
index 000..495c6a9
--- /dev/null
+++
omap-pcm audio playback skips couple frames at first interrupt
Hi, I am using 2.6.32 with omap3evm board. The audio skips a couple of frames at the first interrupt on palyback (TWL4030) when I use small period size (10msec). But the same parameters work fine on capture. With large period/frame size, it works fine also. The skip causes extra delays (30msec at 16kHz) which I tried to minimize. From omap-pcm.c the similar parameters are used to setup DMA for both playback and capture, but why only playback does the skip? The following are logs with xrun_debug=9: r...@omap3evm:~# aplay -f S16_LE -r 16000 -c 2 -d 1 -F 1 -B 8 -R 1 -T 16 /dev/urandom Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x280/0xa0/0x500, hwptr=0x0, hw_base=0x0, hw_intr=0x0 Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:334: PCM: Lost interrupts? (stream=0, delta=480, intr_ptr=160) Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x3c0/0xa0/0x500, hwptr=0x320, hw_base=0x0, hw_intr=0x320 Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x0/0xa0/0x500, hwptr=0x460, hw_base=0x0, hw_intr=0x460 Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x140/0xa0/0x500, hwptr=0x5a0, hw_base=0x500, hw_intr=0x5a0 Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x280/0xa0/0x500, hwptr=0x6e0, hw_base=0x500, hw_intr=0x6e0 Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x3c0/0xa0/0x500, hwptr=0x820, hw_base=0x500, hw_intr=0x820 Oct 26 11:04:11 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x0/0xa0/0x500, hwptr=0x960, hw_base=0x500, hw_intr=0x960 r...@omap3evm:~# arecord -f S16_LE -r 16000 -c 2 -d 1 -F 1 -B 8 -R 1 -T 16 /tmp/test.pcm Oct 26 11:04:13 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0c:0: pos=0x140/0xa0/0x500, hwptr=0xa0, hw_base=0x0, hw_intr=0xa0 Oct 26 11:04:13 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0c:0: pos=0x280/0xa0/0x500, hwptr=0x1e0, hw_base=0x0, hw_intr=0x1e0 Oct 26 11:04:13 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0c:0: pos=0x3c0/0xa0/0x500, hwptr=0x320, hw_base=0x0, hw_intr=0x320 r...@omap3evm:~# aplay -f S16_LE -r 16000 -c 2 -d 1 -F 4 -B 32 -R 4 -T 64 /dev/urandom Oct 26 11:18:46 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x400/0x200/0x1400, hwptr=0x200, hw_base=0x0, hw_intr=0x200 Oct 26 11:18:46 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0x800/0x200/0x1400, hwptr=0x600, hw_base=0x0, hw_intr=0x600 Oct 26 11:18:46 omap3evm user.debug kernel: ALSA sound/core/pcm_lib.c:250: period_update: pcmC0D0p:0: pos=0xc00/0x200/0x1400, hwptr=0xa00, hw_base=0x0, hw_intr=0xa00 Best regards, Ying Lin -- 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] PERF(kernel): Cleanup power events V2
I would like to see a slightly more advanced tracepoint do the runtime pm
framework;
specifically I'd like to see the comm of the process that's taking a
refcount on a device
(that way, powertop can track which process keeps a device busy)
Yes, the comm for this tracepoint should be the runtime_pm workqueue.
To track responsabilities, I'm making another tracepoint, that traces
the rpm_get/put.
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 0f38447..54d9911 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -792,7 +792,7 @@ EXPORT_SYMBOL_GPL(pm_request_resume);
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
@@ -813,6 +813,7 @@ int __pm_runtime_put(struct device *dev, bool sync)
{
int retval = 0;
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)-1);
if (atomic_dec_and_test(dev-power.usage_count))
retval = sync ? pm_runtime_idle(dev) : pm_request_idle(dev);
@@ -1065,6 +1066,7 @@ void pm_runtime_forbid(struct device *dev)
goto out;
dev-power.runtime_auto = false;
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
__pm_runtime_resume(dev, false);
@@ -1086,6 +1088,7 @@ void pm_runtime_allow(struct device *dev)
goto out;
dev-power.runtime_auto = true;
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)-1);
if (atomic_dec_and_test(dev-power.usage_count))
__pm_runtime_idle(dev);
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index ea514eb..813229c 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -100,6 +100,29 @@ TRACE_EVENT(runtime_pm_status,
TP_printk(driver=%s dev=%s prev_status=%s status=%s,
__get_str(drivername),__get_str(devname),
show_rpm_status_name(__entry-prev_status),
show_rpm_status_name(__entry-status))
);
+TRACE_EVENT(runtime_pm_usage,
+
+ TP_PROTO(struct device *dev, int new_usage),
+
+ TP_ARGS(dev, new_usage),
+
+ TP_STRUCT__entry(
+ __string(devname,dev_name(dev))
+ __string(drivername,dev_driver_string(dev))
+ __field(u32, prev_usage)
+ __field(u32, usage)
+ ),
+
+ TP_fast_assign(
+ __assign_str(devname, dev_name(dev));
+ __assign_str(drivername, dev_driver_string(dev));
+ __entry-prev_usage = (u32)atomic_read(dev-power.usage_count);
+ __entry-usage = (u32)new_usage;
+ ),
+
+ TP_printk(driver=%s dev=%s prev_usage=%d usage=%s,
__get_str(drivername),__get_str(devname),
+ __entry-prev_usage, __entry-usage)
+);
--
Pierre
--
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 8/8] staging: tidspbridge - make sync_wait_on_event interruptible
fernando.l...@ti.com wrote: On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: So that avoid non-killable process. It would be useful to interrupt these tasks from user-space. A separate ioctl to do that would be needed. I don't see use case where that could be needed. It is only To avoid a nonkillable task in the case the user pass an infinite Timeout. If you have some test case where that ioctl would be needed Please share it in order to find the best solution. Well, imagine the application is using a library to access the DSP, and the library has a dedicated thread listening for DSP events in a loop. This happens to be how libomxil-ti and gst-dsp work. Now, the thread received the last message, but has set a timeout of 10s, or even worst, no timeout at all. After realizing that was the last message, the main thread decides to shut down, but it has to wait for the DSP thread to join. Unfortunately the DSP thread is stuck waiting for events, and there's nothing that can be done. However, if we have a separate ioctl to interrupt that task, then the main thread can issue that ioctl, and unlock the DSP thread without having to wait 10s, or forever. Does that make sense? -- Felipe Contreras -- 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/8] staging: tidspbridge - remove req_addr from proc_map
fernando.l...@ti.com wrote: On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: The device address is assigned by tidspbridge no need for that parameter anymore. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com This would break the API with user-space, right? Yes, user-space needs to be changed accordingly. Wouldn't it make sense to avoid stuffing so many changes at once including ABI breakage? Does user-space really _needs_ to be changed? Can't you just ignore that argument? I think this change should be delayed, preferably after we have a working tidspbridge. The issue you were seeing must be fixed with patch 2/8, and Having all the dependencies tidspbridge has to be working Properly. Yes, which might not happen at .37. If we revert the iommu stuff, we might have a chance at having a working bridge on .37. -- Felipe Contreras -- 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 v2 0/4] tidspbridge: SCM layer violation fixes
On Tue, Oct 26, 2010 at 7:15 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: This is the patch series shared by Paul, for a short term fix to a compile break due SCM layer layer violations from tidspbridge driver, where the latter is used to write directly into registers and use SCM layer macros, among other layer bypassing. patch: staging: tidspbridge: use new SCM DSP boot control fns was split from its original version, it is meant to be on hold until the rest of the series gets upstreamed and can be found in the staging tree (unless best advice is given). Paul Walmsley (4): OMAP: control: add functions for DSP boot address/mode control OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions OMAP: dsp: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns staging: tidspbridge: use new SCM DSP boot control fns arch/arm/mach-omap2/control.c | 51 ++ arch/arm/mach-omap2/control.h | 16 --- arch/arm/mach-omap2/dsp.c | 4 ++ arch/arm/mach-omap2/pm34xx.c | 6 +- arch/arm/plat-omap/include/plat/dsp.h | 4 ++ arch/arm/plat-omap/include/plat/iva2_dsp.h | 56 + Why not use the already existing dsp.h? -- Felipe Contreras -- 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 v2 0/4] tidspbridge: SCM layer violation fixes
On Tue, Oct 26, 2010 at 12:13 PM, Felipe Contreras felipe.contre...@gmail.com wrote: arch/arm/plat-omap/include/plat/iva2_dsp.h | 56 + Why not use the already existing dsp.h? Good point, I guess when the patch was made dsp.h didn't exist, but since the user of those defines is pm34xx.c too, including it in dsp.h would include the declaration of everything inside dsp.h; however I don't see that as an impediment for dma.h or gpmc.h to be included. Regards, Omar -- 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 8/8] staging: tidspbridge - make sync_wait_on_event interruptible
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@nokia.com] Sent: Tuesday, October 26, 2010 12:03 PM To: Guzman Lugo, Fernando; felipe.contre...@gmail.com Cc: gre...@suse.de; hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible fernando.l...@ti.com wrote: On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: So that avoid non-killable process. It would be useful to interrupt these tasks from user-space. A separate ioctl to do that would be needed. I don't see use case where that could be needed. It is only To avoid a nonkillable task in the case the user pass an infinite Timeout. If you have some test case where that ioctl would be needed Please share it in order to find the best solution. Well, imagine the application is using a library to access the DSP, and the library has a dedicated thread listening for DSP events in a loop. This happens to be how libomxil-ti and gst-dsp work. Now, the thread received the last message, but has set a timeout of 10s, or even worst, no timeout at all. After realizing that was the last message, the main thread decides to shut down, but it has to wait for the DSP thread to join. Unfortunately the DSP thread is stuck waiting for events, and there's nothing that can be done. However, if we have a separate ioctl to interrupt that task, then the main thread can issue that ioctl, and unlock the DSP thread without having to wait 10s, or forever. Does that make sense? Maybe sending a signal to yourselft and having a dummy signal Handle should work, it that would not like good. I am thinking On having a ioctl to create and set an event the you could Something like this: struct dsp_notification events[3]; proc_register_notify(proc, event_type, events[0]); ... proc_register_notify(proc, event_type, events[1]); ... Sync_open_event(events[2]); second thread: mgr_wait_for_bridge_events(proc, events, 3, index); if (index == 2) /* main thread force exit */ Main thread: /* if some execption happened then finish the second thread */ sync_set_event(events[2]); pthread_join(...); However it is in progess a task for change replacing dspbridge sync.c Module with event_fd to signal events to userspace. Where now simple File descriptor will be used as event elements. So the mgr_wait_for_bridge_events Will be implemented using select system call inside to wait for multiple events. So you will be able to do something like this: int events[3]; proc_register_notify(proc, event_type, events[0]); ... proc_register_notify(proc, event_type, events[1]); ... events[2] = eventfd(0, 0); second thread: mgr_wait_for_bridge_events(proc, events, 3, index); if (index == 2) /* main thread force exit */ Main thread: /* if some execption happened then finish the second thread */ write(events[2], s, 1); pthread_join(...); You won't need any aditional ioctl in order to do what you want to do. So, I think it is not worth to make much changes to some module that will Dissapear (my patch is just a fix it is not implementing something new), It is just a matter of time to that task is finished and tested properly And then send to LO. Regards, Fernando. -- Felipe Contreras -- 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] PERF(kernel): Cleanup power events V2
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote: + trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1); atomic_inc(dev-power.usage_count); That's terribly racy.. -- 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/8] staging: tidspbridge - remove req_addr from proc_map
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@nokia.com] Sent: Tuesday, October 26, 2010 12:08 PM To: Guzman Lugo, Fernando; felipe.contre...@gmail.com Cc: gre...@suse.de; hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map fernando.l...@ti.com wrote: On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: The device address is assigned by tidspbridge no need for that parameter anymore. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com This would break the API with user-space, right? Yes, user-space needs to be changed accordingly. Wouldn't it make sense to avoid stuffing so many changes at once including ABI breakage? Does user-space really _needs_ to be changed? Can't you just ignore that argument? Actually, I had a previous version of that patch where I only Ignored that paramteter. But after thinking again and seeing How the long time ago depreacted function are still there I Removed the parameter in order to force apps to make the change. You can ignore that argument at API level, so all users of the API not need to have change (in that momment). That should be Only few line change. I think this change should be delayed, preferably after we have a working tidspbridge. The issue you were seeing must be fixed with patch 2/8, and Having all the dependencies tidspbridge has to be working Properly. Yes, which might not happen at .37. If we revert the iommu stuff, we might have a chance at having a working bridge on .37. But havi that merged in tidspbridge make more pressure to merged The dependencies, if not maybe that wont have event for .38. But That is just my opinion if you all are agree revert is the best Option I am ok, but I looks like more work reverting and rebaseing specially because it is a big change. Thanks and regards, Fernando. -- Felipe Contreras -- 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] PERF(kernel): Cleanup power events V2
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all these
inc/dec are protected with mutexes or spinlocks, in which case one might wonder
why atomic operations are used at all, or it's a racy mess. (I vote for the
second option)
kref should certainly be used there.
About the instrumentation, well... the only way to have something that's not
racy would be to instrument kref directly, and use atomic_add_return() in both
the get/put paths. But I fear that the performance impact on many architectures
might be significant (turning atomic_add + smp_mb() into a cmpxchg()). Maybe it
could be acceptable as a kernel debug option.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency RD Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PERF(kernel): Cleanup power events V2
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote: + trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1); atomic_inc(dev-power.usage_count); That's terribly racy.. I know. I'm not proud of this.. As I said, this is preliminary patch. We dont really need to have this prev_usage. This is just for debug. It mayprobably endup with something like: atomic_inc(dev-power.usage_count); + trace_power_device_usage(dev); -- Pierre -- 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: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all these
inc/dec are protected with mutexes or spinlocks, in which case one might
wonder
why atomic operations are used at all, or it's a racy mess. (I vote for the
second option)
I don't understand. What's the problem? The inc/dec are atomic
because they are not protected by spinlocks, but everything else is
(aside from the tracepoint, which is new).
kref should certainly be used there.
What for?
Alan Stern
--
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] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Thomas Renninger wrote: Changes in V2: - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state - Use u32 instead of u64 for cpuid, state which is by far enough New power trace events: power:processor_idle power:processor_frequency power:machine_suspend C-state/idle accounting events: power:power_start power:power_end are replaced with: power:processor_idle and power:power_frequency is replaced with: power:processor_frequency power:machine_suspend is newly introduced, a first implementation comes from the ARM side, but it's easy to add these events in X86 as well if needed. As I said already somewhere else, I think this one should be done at the core level rather than in arch-specific code. Thanks, Rafael -- 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] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Thomas Renninger wrote:
On Tuesday 26 October 2010 13:21:29 Ingo Molnar wrote:
* Jean Pihet jean.pi...@newoldbits.com wrote:
..
+#ifndef _TRACE_POWER_ENUM_
+#define _TRACE_POWER_ENUM_
+enum {
+ POWER_NONE = 0,
+ POWER_CSTATE = 1,
+ POWER_PSTATE = 2,
+};
+#endif
Since we are cleaning up all these events, those enum definitions dont
really look
logical. For example, what is 'POWER_NONE'? Can a CPU have 'no power'?
The enum belongs to the deprecated API so I would rather not touch it.
Keeping the deprecated code isolated will make it easier to remove
later.
So what will replace it? We still have a state field.
Nothing, this is part of the cleanup.
As you state above: POWER_NONE does not make sense at all.
The whole thing (type= attribute that vanishes now) is
passed to userspace, but never gets used there because the
same info is in the event name:
cpu_frequency - frequency_switch - PSTATE
cpu_idle - power_start/power_end - CSTATE
I expect that there was an initial power_start/end which
was also used for frequency switching.
Then it got realized that _start/_end does not work out and
frequency_switch got introduced.
To stay compatible the whole power_start/end was not renamed
to cpu_idle and the type= field was kept.
This is a guess without even looking at the git history.
Therefore my partly harsh comments about the sanity of the
current power tracing events.
Passing in platform specific codes is a step backwards.
+TRACE_EVENT(machine_suspend,
+
+ TP_PROTO(unsigned int state),
+
+ TP_ARGS(state),
+
+ TP_STRUCT__entry(
+ __field(u32,state )
+ ),
Hm, this event is not used anywhere in the submitted patches. Where is
the patch
that adds usage, and what are the possible values for 'state'?
This will come as a separate patch, which fits all platforms. Cf.
http://marc.info/?l=linux-omapm=128620575300682w=2.
The state field is of type suspend_state_t, cf. include/linux/suspend.h
Ok, that's at least generic. Needs the review of Rafael, to determine
whether this state value is all we want to know when we enter suspend.
He already gave an acked-by on this generic one here:
Re: [PATCH 3/4] perf: add calls to suspend trace point
Oh now, that was on the X86 specific part which depends on this one.
One should expect that he's fine with the generic part as well then,
but I agree that he should definitely have a look at this and sign it off.
What patch exactly do you mean? I'm not quite sure from your comment above.
Rafael
--
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] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Ingo Molnar wrote: * Thomas Renninger tr...@suse.de wrote: On Tuesday 26 October 2010 09:10:20 Ingo Molnar wrote: * Thomas Renninger tr...@suse.de wrote: Changes in V2: - Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state - Use u32 instead of u64 for cpuid, state which is by far enough New power trace events: power:processor_idle power:processor_frequency power:machine_suspend C-state/idle accounting events: power:power_start power:power_end are replaced with: power:processor_idle and power:power_frequency is replaced with: power:processor_frequency Could you please name it power:cpu_idle and power:cpu_frequency instead, for shortness? We generally use 'cpu' in the kernel and for events. Sure. power:machine_suspend How will future PCI (or other device) power saving tracepoints be called? Might be more consistent to use: power:cpu_idle power:machine_idle power:device_idle device idle is not true. Those may be low power modes like reduced network throughput, reduced wlan range, the device needs not to be idle. Device power states is probably the most complex area, if such a thing gets introduced, it should makes sense to state the interface experimental for some time until a wider range of devices uses it (in contrast to these new ones which should not change that soon anymore...). Ok. Also machine_idle may be true, but machine_suspend sounds more familiar and everyone immediately knows what the event is about. Ok - fair enough. +#define PWR_EVENT_EXIT 0x Shouldnt this be part of the POWER_ enum? (and you can write -1 there) No, below enum will vanish, but -1 is nicer. When it vanishes what will replace it? ... Plus: +DECLARE_EVENT_CLASS(processor, + + TP_PROTO(unsigned int state, unsigned int cpu_id), + + TP_ARGS(state, cpu_id), + + TP_STRUCT__entry( + __field(u32,state ) + __field(u32,cpu_id ) Trace entries can carry a cpu_id of the current processor already. Can this cpu_id ever be different from that CPU id? Yes. A core's frequency can depend on another one which will get switched as well (by one command/MSR). Compare with commit 6f4f2723d08534fd4e407e1e. This can theoretically also be the case for sleep states. Afaik such HW does not exist yet, but ACPI spec already provides interfaces to pass these dependency from BIOS to OS. - We want a stable ABI and should be prepared for such stuff. + ), + + TP_fast_assign( + __entry-state = state; + __entry-cpu_id = cpu_id; + ), + + TP_printk(state=%lu cpu_id=%lu, (unsigned long)__entry-state, + (unsigned long)__entry-cpu_id) +); + +DEFINE_EVENT(processor, processor_idle, + + TP_PROTO(unsigned int state, unsigned int cpu_id), + +TP_ARGS(state, cpu_id) +); + +#define PWR_EVENT_EXIT 0x + +DEFINE_EVENT(processor, processor_frequency, + + TP_PROTO(unsigned int frequency, unsigned int cpu_id), + + TP_ARGS(frequency, cpu_id) +); So, we have a 'state' field in the class, which is used as 'state' by the power::cpu_idle event, and as 'frequency' by the power::cpu_freq event? Yes, is this a problem? Definitions are a bit shorter having one power processor class. As frequency is stated in frequency event definition everything should be obvious and this one looks like the more elegant way to me. Are there any architectures that track frequency in Hz, not in kHz? If yes, might there ever be a need for the frequency value to be larger than 4.29 GHz? If yes, then it wont fit into u32. drivers/cpufreq subsystem is fixed to unsigned int (cmp. include/linux/cpufreq.h): unsigned intmin;/* in kHz */ unsigned intmax;/* in kHz */ unsigned intcur;/* in kHz, ... that should be fine. ok, good - so we should be fine up to 4 THz CPUs. Also, might there be a future need to express different types of frequencies? For example, should we decide to track turbo frequencies in Intel CPUs, how would that be expressed via these events? Are there any architectures and CPUs that somehow have some extra attribute to the frequency value? I wonder whether this ever can/will work in a sane way. Userspace can compare with: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq everything above is turbo. So I do not think it's ever needed. But adding an
Re: [PATCH] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all these
inc/dec are protected with mutexes or spinlocks, in which case one might
wonder
why atomic operations are used at all, or it's a racy mess. (I vote for the
second option)
No, it isn't.
kref should certainly be used there.
No, it shouldn't.
Please try to understand the code you're commenting on first.
Thanks,
Rafael
--
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] omap: add hwspinlock device
* Ohad Ben-Cohen o...@wizery.com [101026 04:45]: On Mon, Oct 25, 2010 at 9:02 PM, Tony Lindgren t...@atomide.com wrote: if you feel that (2) is justifiable/desirable, I would be more than happy to submit that version. Yes (2) please. I would assume there will be more use of this. And then we (or probably me again!) don't have to deal with cleaning up the drivers again in the future. Sounds good. Or do you mean a variation of (2) with only the specific locking bits coming from pdata func pointers ? I guess that in this case we just might as well go with the full (2). Yes variation of (2) where you only pass the locking function via platform data would be best. It feels a bit funky to me because we would still have code that is omap-specific inside the common probe()/remove() calls. I suggest to move everything that is omap-specific to a small omap module that, once probed, would register itself with the common hwspinlock framework (after initializing its hardware). That small platfom-specific module probably doesn't have to sit in the arch/ folder; we can follow established conventions like mmc/i2c/gpio/spi/etc.. With that in hand, the hwspinlock would really be hardware-agnostic, and then applying s/omap_hwspin/hwspin/ would be justified. Does this sound reasonable to you ? Sounds good to me. 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] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote: + trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1); atomic_inc(dev-power.usage_count); That's terribly racy.. I know. I'm not proud of this.. As I said, this is preliminary patch. We dont really need to have this prev_usage. This is just for debug. It mayprobably endup with something like: atomic_inc(dev-power.usage_count); + trace_power_device_usage(dev); Well, please tell me what you're trying to achieve. Thanks, Rafael -- 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 8/8] staging: tidspbridge - make sync_wait_on_event interruptible
fernando.l...@ti.com wrote: fernando.l...@ti.com wrote: On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: So that avoid non-killable process. It would be useful to interrupt these tasks from user-space. A separate ioctl to do that would be needed. I don't see use case where that could be needed. It is only To avoid a nonkillable task in the case the user pass an infinite Timeout. If you have some test case where that ioctl would be needed Please share it in order to find the best solution. Well, imagine the application is using a library to access the DSP, and the library has a dedicated thread listening for DSP events in a loop. This happens to be how libomxil-ti and gst-dsp work. Now, the thread received the last message, but has set a timeout of 10s, or even worst, no timeout at all. After realizing that was the last message, the main thread decides to shut down, but it has to wait for the DSP thread to join. Unfortunately the DSP thread is stuck waiting for events, and there's nothing that can be done. However, if we have a separate ioctl to interrupt that task, then the main thread can issue that ioctl, and unlock the DSP thread without having to wait 10s, or forever. Does that make sense? Maybe sending a signal to yourselft and having a dummy signal Handle should work, it that would not like good. Signals on libraries is a no-no. I am thinking On having a ioctl to create and set an event the you could Something like this: struct dsp_notification events[3]; proc_register_notify(proc, event_type, events[0]); ... proc_register_notify(proc, event_type, events[1]); ... Sync_open_event(events[2]); second thread: mgr_wait_for_bridge_events(proc, events, 3, index); if (index == 2) /* main thread force exit */ Main thread: /* if some execption happened then finish the second thread */ sync_set_event(events[2]); pthread_join(...); However it is in progess a task for change replacing dspbridge sync.c Module with event_fd to signal events to userspace. Where now simple File descriptor will be used as event elements. So the mgr_wait_for_bridge_events Will be implemented using select system call inside to wait for multiple events. So you will be able to do something like this: int events[3]; proc_register_notify(proc, event_type, events[0]); ... proc_register_notify(proc, event_type, events[1]); ... events[2] = eventfd(0, 0); second thread: mgr_wait_for_bridge_events(proc, events, 3, index); if (index == 2) /* main thread force exit */ Main thread: /* if some execption happened then finish the second thread */ write(events[2], s, 1); pthread_join(...); You won't need any aditional ioctl in order to do what you want to do. So, I think it is not worth to make much changes to some module that will Dissapear (my patch is just a fix it is not implementing something new), It is just a matter of time to that task is finished and tested properly And then send to LO. All right, that makes sense. I just wanted to make suere you are aware of that need. -- Felipe Contreras -- 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/8] staging: tidspbridge - remove req_addr from proc_map
fernando.l...@ti.com wrote: fernando.l...@ti.com wrote: On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: The device address is assigned by tidspbridge no need for that parameter anymore. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com This would break the API with user-space, right? Yes, user-space needs to be changed accordingly. Wouldn't it make sense to avoid stuffing so many changes at once including ABI breakage? Does user-space really _needs_ to be changed? Can't you just ignore that argument? Actually, I had a previous version of that patch where I only Ignored that paramteter. But after thinking again and seeing How the long time ago depreacted function are still there I Removed the parameter in order to force apps to make the change. Again, can we concentrate on first getting this thing to work? We can think on breaking things again later. You can ignore that argument at API level, so all users of the API not need to have change (in that momment). That should be Only few line change. Yes, that's what I'm proposing. I think this change should be delayed, preferably after we have a working tidspbridge. The issue you were seeing must be fixed with patch 2/8, and Having all the dependencies tidspbridge has to be working Properly. Yes, which might not happen at .37. If we revert the iommu stuff, we might have a chance at having a working bridge on .37. But havi that merged in tidspbridge make more pressure to merged The dependencies, if not maybe that wont have event for .38. Those patches have been there for a while and there's no sign of when they'll be merged. Also, remember that the fact that the patches have been sent doesn't guarantee they would be on this, or even the next cycle. Besides, the rule followed here is: it's ready when it's ready. In the meantime the driver should work, and we can do that rather easily. But That is just my opinion if you all are agree revert is the best Option I am ok, but I looks like more work reverting and rebaseing specially because it is a big change. git makes this easy. The hard part is for the people out there that are trying to use this driver and have to hunt mailing lists and multiple repos just to get this to work. Moving to staging was supposed to make this easier, not harder. -- Felipe Contreras -- 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 8/8] staging: tidspbridge - make sync_wait_on_event interruptible
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@nokia.com] Sent: Tuesday, October 26, 2010 2:27 PM To: Guzman Lugo, Fernando; felipe.contre...@gmail.com Cc: gre...@suse.de; hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible fernando.l...@ti.com wrote: fernando.l...@ti.com wrote: On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo x0095...@ti.com wrote: So that avoid non-killable process. It would be useful to interrupt these tasks from user-space. A separate ioctl to do that would be needed. I don't see use case where that could be needed. It is only To avoid a nonkillable task in the case the user pass an infinite Timeout. If you have some test case where that ioctl would be needed Please share it in order to find the best solution. Well, imagine the application is using a library to access the DSP, and the library has a dedicated thread listening for DSP events in a loop. This happens to be how libomxil-ti and gst-dsp work. Now, the thread received the last message, but has set a timeout of 10s, or even worst, no timeout at all. After realizing that was the last message, the main thread decides to shut down, but it has to wait for the DSP thread to join. Unfortunately the DSP thread is stuck waiting for events, and there's nothing that can be done. However, if we have a separate ioctl to interrupt that task, then the main thread can issue that ioctl, and unlock the DSP thread without having to wait 10s, or forever. Does that make sense? Maybe sending a signal to yourselft and having a dummy signal Handle should work, it that would not like good. Signals on libraries is a no-no. I am thinking On having a ioctl to create and set an event the you could Something like this: struct dsp_notification events[3]; proc_register_notify(proc, event_type, events[0]); ... proc_register_notify(proc, event_type, events[1]); ... Sync_open_event(events[2]); second thread: mgr_wait_for_bridge_events(proc, events, 3, index); if (index == 2) /* main thread force exit */ Main thread: /* if some execption happened then finish the second thread */ sync_set_event(events[2]); pthread_join(...); However it is in progess a task for change replacing dspbridge sync.c Module with event_fd to signal events to userspace. Where now simple File descriptor will be used as event elements. So the mgr_wait_for_bridge_events Will be implemented using select system call inside to wait for multiple events. So you will be able to do something like this: int events[3]; proc_register_notify(proc, event_type, events[0]); ... proc_register_notify(proc, event_type, events[1]); ... events[2] = eventfd(0, 0); second thread: mgr_wait_for_bridge_events(proc, events, 3, index); if (index == 2) /* main thread force exit */ Main thread: /* if some execption happened then finish the second thread */ write(events[2], s, 1); pthread_join(...); You won't need any aditional ioctl in order to do what you want to do. So, I think it is not worth to make much changes to some module that will Dissapear (my patch is just a fix it is not implementing something new), It is just a matter of time to that task is finished and tested properly And then send to LO. All right, that makes sense. I just wanted to make suere you are aware of that need. Sure, that need will cover soon. Thanks and regards, Fernando. -- Felipe Contreras -- 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/8] staging: tidspbridge - remove req_addr from proc_map
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
Sent: Tuesday, October 26, 2010 2:38 PM
To: Guzman Lugo, Fernando; felipe.contre...@gmail.com
Cc: gre...@suse.de; hiroshi.d...@nokia.com;
linux-ker...@vger.kernel.org; andy.shevche...@gmail.com;
linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: RE: [PATCH 1/8] staging: tidspbridge - remove
req_addr from proc_map
fernando.l...@ti.com wrote:
fernando.l...@ti.com wrote:
On Tue, Oct 26, 2010 at 3:51 AM, Fernando Guzman Lugo
x0095...@ti.com wrote:
The device address is assigned by tidspbridge no need for
that parameter anymore.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
This would break the API with user-space, right?
Yes, user-space needs to be changed accordingly.
Wouldn't it make sense to avoid stuffing so many changes at once
including ABI breakage?
Does user-space really _needs_ to be changed? Can't you
just ignore
that argument?
Actually, I had a previous version of that patch where I
only Ignored
that paramteter. But after thinking again and seeing How
the long time
ago depreacted function are still there I Removed the parameter in
order to force apps to make the change.
Again, can we concentrate on first getting this thing to work?
If to make it work for 37 the iommu migration patch will be revert
These set of patches will have to wait until the patches are merged
Again. So the dspbridge would be fix first a then the patches would
Be merged.
We can think on breaking things again later.
You can ignore that argument at API level, so all users of
the API not
need to have change (in that momment). That should be Only few line
change.
Yes, that's what I'm proposing.
I meant userspace api or library level:
Example:
Dsp_proc_map(proc, mpu_addr, req_addr, *dsp_addr, attr) {
...
struct proc_map args = {
.map_addr = mpu_addr;
/* ignore req_addr */
.dsp_addr = dsp_addr;
.attr = attr;
}
ret = ioctl(handle, PROCMAP_CMD, args)
...
}
I think this change should be delayed, preferably
after we have
a working tidspbridge.
The issue you were seeing must be fixed with patch 2/8, and
Having all
the dependencies tidspbridge has to be working Properly.
Yes, which might not happen at .37. If we revert the
iommu stuff, we
might have a chance at having a working bridge on .37.
But havi that merged in tidspbridge make more pressure to
merged The
dependencies, if not maybe that wont have event for .38.
Those patches have been there for a while and there's no sign
of when they'll be merged. Also, remember that the fact that
the patches have been sent doesn't guarantee they would be on
this, or even the next cycle.
Besides, the rule followed here is: it's ready when it's
ready. In the meantime the driver should work, and we can do
that rather easily.
I don't have much experience in this kind of situacion if it is
believed it is the best solution then ok for me.
But That is just my opinion if you all are agree revert is the best
Option I am ok, but I looks like more work reverting and rebaseing
specially because it is a big change.
git makes this easy.
Till we need to fix all the conflics, make sure everything work
Properly and then send it again to review. That can take a while,
But it seems someone else is agree to revert the changes, so maybe
That is the best to do in this situacion.
Thanks and regards,
Fernando.
The hard part is for the people out there that are trying to
use this driver and have to hunt mailing lists and multiple
repos just to get this to work. Moving to staging was
supposed to make this easier, not harder.
--
Felipe Contreras
--
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] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Tuesday, October 26, 2010, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote: + trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1); atomic_inc(dev-power.usage_count); That's terribly racy.. I know. I'm not proud of this.. As I said, this is preliminary patch. We dont really need to have this prev_usage. This is just for debug. It mayprobably endup with something like: atomic_inc(dev-power.usage_count); + trace_power_device_usage(dev); Well, please tell me what you're trying to achieve. Please see attached the kind of pytimechart output I'm trying to achieve (yes, this chart is not coherent, seems I'm still missing some traces) We basically want to have a trace point eachtime the usage_counter changes, so that I can display nice timecharts, and Arjan can have the comm of the process that eventually generated the rpm_get, in order to pinpoint it in powertop. What you dont see in the above two lines is that trace_power_device_usage(dev); actually reads the usage_count, as well as the driver and device name. I'm afraid that for this to really work you'd need to put usage_count under a spinlock along with your trace point, which I'm not really sure I like. Besides, I'm not really sure the manipulations of usage_count are worth tracing. Thanks, Rafael -- 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] PERF(kernel): Cleanup power events V2
On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote: On Tuesday, October 26, 2010, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysockir...@sisk.pl wrote: On Tuesday, October 26, 2010, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstrapet...@infradead.org wrote: On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote: + trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1); atomic_inc(dev-power.usage_count); That's terribly racy.. I know. I'm not proud of this.. As I said, this is preliminary patch. We dont really need to have this prev_usage. This is just for debug. It mayprobably endup with something like: atomic_inc(dev-power.usage_count); + trace_power_device_usage(dev); Well, please tell me what you're trying to achieve. Please see attached the kind of pytimechart output I'm trying to achieve (yes, this chart is not coherent, seems I'm still missing some traces) We basically want to have a trace point eachtime the usage_counter changes, so that I can display nice timecharts, and Arjan can have the comm of the process that eventually generated the rpm_get, in order to pinpoint it in powertop. What you dont see in the above two lines is that trace_power_device_usage(dev); actually reads the usage_count, as well as the driver and device name. I'm afraid that for this to really work you'd need to put usage_count under a spinlock along with your trace point, which I'm not really sure I like. Besides, I'm not really sure the manipulations of usage_count are worth tracing. what's most interesting is the 0-1 and 1-0 transitions. -- 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] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Arjan van de Ven wrote: On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote: On Tuesday, October 26, 2010, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysockir...@sisk.pl wrote: On Tuesday, October 26, 2010, Pierre Tardy wrote: On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstrapet...@infradead.org wrote: On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote: + trace_runtime_pm_usage(dev, atomic_read(dev-power.usage_count)+1); atomic_inc(dev-power.usage_count); That's terribly racy.. I know. I'm not proud of this.. As I said, this is preliminary patch. We dont really need to have this prev_usage. This is just for debug. It mayprobably endup with something like: atomic_inc(dev-power.usage_count); + trace_power_device_usage(dev); Well, please tell me what you're trying to achieve. Please see attached the kind of pytimechart output I'm trying to achieve (yes, this chart is not coherent, seems I'm still missing some traces) We basically want to have a trace point eachtime the usage_counter changes, so that I can display nice timecharts, and Arjan can have the comm of the process that eventually generated the rpm_get, in order to pinpoint it in powertop. What you dont see in the above two lines is that trace_power_device_usage(dev); actually reads the usage_count, as well as the driver and device name. I'm afraid that for this to really work you'd need to put usage_count under a spinlock along with your trace point, which I'm not really sure I like. Besides, I'm not really sure the manipulations of usage_count are worth tracing. what's most interesting is the 0-1 and 1-0 transitions. But they are only meaningful in specific situations. For example, if someone does pm_runtime_get_noresume() when the device is active, there may be a device suspend already under way at the same time. So IMO what really is interesting is when rpm_resume() is called with usage_count 0 and then perhaps when rpm_idle() or rpm_suspend() is called after usage_count drops back to 0. There are some other interesting cases, but they all need to be checked under -power.lock and you need to do that cleverly, so that the _functionality_ is not harmed. Overall, I think that adding tracepoints to the runtime PM core code is really premature at this point, given that we've just reworked it quite a bit recently. Thanks, Rafael -- 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 1/5] omap: mailbox: initial hwmod support for omap3
From: Felipe Contreras felipe.contre...@gmail.com
HWMOD support for omap3.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/devices.c | 100 ---
arch/arm/mach-omap2/mailbox.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 +++
3 files changed, 70 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index eaf3799..d977572 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -141,95 +141,25 @@ static inline void omap_init_camera(void)
#endif
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#define MBOX_REG_SIZE 0x120
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_mbox_resources[] = {
- {
- .start = OMAP24XX_MAILBOX_BASE,
- .end= OMAP24XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = dsp,
- },
- {
- .start = INT_24XX_MAIL_U3_MPU,
- .flags = IORESOURCE_IRQ,
- .name = iva,
- },
-};
-static int omap2_mbox_resources_sz = ARRAY_SIZE(omap2_mbox_resources);
-#else
-#define omap2_mbox_resources NULL
-#define omap2_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_mbox_resources[] = {
- {
- .start = OMAP34XX_MAILBOX_BASE,
- .end= OMAP34XX_MAILBOX_BASE + MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = dsp,
- },
-};
-static int omap3_mbox_resources_sz = ARRAY_SIZE(omap3_mbox_resources);
-#else
-#define omap3_mbox_resources NULL
-#define omap3_mbox_resources_sz0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-
-#define OMAP4_MBOX_REG_SIZE0x130
-static struct resource omap4_mbox_resources[] = {
- {
- .start = OMAP44XX_MAILBOX_BASE,
- .end= OMAP44XX_MAILBOX_BASE +
- OMAP4_MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP44XX_IRQ_MAIL_U0,
- .flags = IORESOURCE_IRQ,
- .name = mbox,
- },
-};
-static int omap4_mbox_resources_sz = ARRAY_SIZE(omap4_mbox_resources);
-#else
-#define omap4_mbox_resources NULL
-#define omap4_mbox_resources_sz0
-#endif
-
-static struct platform_device mbox_device = {
- .name = omap-mailbox,
- .id = -1,
-};
-
static inline void omap_init_mbox(void)
{
- if (cpu_is_omap24xx()) {
- mbox_device.resource = omap2_mbox_resources;
- mbox_device.num_resources = omap2_mbox_resources_sz;
- } else if (cpu_is_omap34xx()) {
- mbox_device.resource = omap3_mbox_resources;
- mbox_device.num_resources = omap3_mbox_resources_sz;
- } else if (cpu_is_omap44xx()) {
- mbox_device.resource = omap4_mbox_resources;
- mbox_device.num_resources = omap4_mbox_resources_sz;
- } else {
- pr_err(%s: platform not supported\n, __func__);
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+
+ oh = omap_hwmod_lookup(mailbox);
+ if (!oh) {
+ pr_err(%s: unable to find hwmod\n, __func__);
+ return;
+ }
+
+ od = omap_device_build(omap-mailbox, -1, oh,
+ NULL, 0,
+ NULL, 0,
+ 0);
+ if (!od) {
+ pr_err(%s: could not build device\n, __func__);
return;
}
- platform_device_register(mbox_device);
}
#else
static inline void omap_init_mbox(void) { }
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 40ddeca..1ddb82d 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include plat/mailbox.h
+#include plat/omap_hwmod.h
#include mach/irqs.h
#define MAILBOX_REVISION 0x000
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ed6bf4a..9e9e843 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -45,6 +45,7 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
static struct
[PATCH 4/5] omap: mailbox: fix detection for previously supported chips
Fix the mailbox detection for OMAP3630 and 2430, also minor
cleanup on conditional ifdef's that could affect it.
Given that 2430 has an iva too include it, as the same steps
for omap3 apply.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 61f2149..b8fd120 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -277,7 +277,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
/* FIXME: the following structs should be filled automatically by the user id
*/
-#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -302,7 +302,7 @@ struct omap_mbox mbox_dsp_info = {
};
#endif
-#if defined(CONFIG_ARCH_OMAP3430)
+#if defined(CONFIG_ARCH_OMAP3)
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
@@ -390,15 +390,19 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (false)
;
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
+#if defined(CONFIG_ARCH_OMAP3)
+ else if (cpu_is_omap34xx()) {
list = omap3_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
}
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
- else if (cpu_is_omap2420()) {
+#if defined(CONFIG_ARCH_OMAP2)
+ else if (cpu_is_omap2430()) {
+ list = omap2_mboxes;
+
+ list[0]-irq = platform_get_irq_byname(pdev, dsp);
+ } else if (cpu_is_omap2420()) {
list = omap2_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
--
1.7.1
--
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 3/5] omap: mailbox: add omap_device latency information
From: Felipe Contreras felipe.contre...@gmail.com
So that we can enable the main clock.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/devices.c | 19 +--
arch/arm/mach-omap2/mailbox.c | 21 +
arch/arm/plat-omap/include/plat/mailbox.h |6 ++
3 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d977572..337fd7a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,7 @@
#include plat/dma.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
+#include plat/mailbox.h
#include mux.h
#include control.h
@@ -141,10 +142,20 @@ static inline void omap_init_camera(void)
#endif
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+static struct omap_device_pm_latency mbox_latencies[] = {
+ [0] = {
+ .activate_func = omap_device_enable_clocks,
+ .activate_lat = 5, /* FIXME random value */
+ .deactivate_func = omap_device_enable_clocks,
+ .deactivate_lat = 5, /* FIXME random value */
+ },
+};
+
static inline void omap_init_mbox(void)
{
struct omap_hwmod *oh;
struct omap_device *od;
+ struct omap_mbox_platform_data pdata;
oh = omap_hwmod_lookup(mailbox);
if (!oh) {
@@ -152,10 +163,14 @@ static inline void omap_init_mbox(void)
return;
}
+ pdata.device_enable = omap_device_enable;
+ pdata.device_disable = omap_device_idle;
+
od = omap_device_build(omap-mailbox, -1, oh,
- NULL, 0,
- NULL, 0,
+ pdata, sizeof(pdata),
+ mbox_latencies, ARRAY_SIZE(mbox_latencies),
0);
+
if (!od) {
pr_err(%s: could not build device\n, __func__);
return;
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 1ddb82d..61f2149 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -53,6 +53,7 @@
#define OMAP4_MBOX_NR_REGS (OMAP4_MBOX_REG_SIZE / sizeof(u32))
static void __iomem *mbox_base;
+static struct platform_device *mbox_pdev;
struct omap_mbox2_fifo {
unsigned long msg;
@@ -71,8 +72,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
};
-static struct clk *mbox_ick_handle;
-
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq);
@@ -91,14 +90,10 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
{
u32 l;
unsigned long timeout;
+ struct omap_mbox_platform_data *pdata = mbox_pdev-dev.platform_data;
- mbox_ick_handle = clk_get(NULL, mailboxes_ick);
- if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR Could not get mailboxes_ick: %ld\n,
- PTR_ERR(mbox_ick_handle));
- return PTR_ERR(mbox_ick_handle);
- }
- clk_enable(mbox_ick_handle);
+ if (pdata-device_enable)
+ pdata-device_enable(mbox_pdev);
if (cpu_is_omap44xx()) {
mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
@@ -144,9 +139,9 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
static void omap2_mbox_shutdown(struct omap_mbox *mbox)
{
- clk_disable(mbox_ick_handle);
- clk_put(mbox_ick_handle);
- mbox_ick_handle = NULL;
+ struct omap_mbox_platform_data *pdata = mbox_pdev-dev.platform_data;
+ if (pdata-device_disable)
+ pdata-device_disable(mbox_pdev);
}
/* Mailbox FIFO handle functions */
@@ -428,6 +423,8 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
+ mbox_pdev = pdev;
+
ret = omap_mbox_register(pdev-dev, list);
if (ret) {
iounmap(mbox_base);
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..59443b1 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -11,6 +11,7 @@
typedef u32 mbox_msg_t;
struct omap_mbox;
+struct platform_device;
typedef int __bitwise omap_mbox_irq_t;
#define IRQ_TX ((__force omap_mbox_irq_t) 1)
@@ -59,6 +60,11 @@ struct omap_mbox {
void*priv;
};
+struct omap_mbox_platform_data {
+ int (*device_enable)(struct platform_device *pdev);
+ int (*device_disable)(struct platform_device *pdev);
+};
+
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH 2/5] omap: mailbox: initial hwmod support for omap2
HWMOD support for omap2430 and 2420.
Compiled tested only.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 55
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 54 +++
2 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..e417fb4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -81,6 +81,7 @@ static struct omap_hwmod omap2420_uart2_hwmod;
static struct omap_hwmod omap2420_uart3_hwmod;
static struct omap_hwmod omap2420_i2c1_hwmod;
static struct omap_hwmod omap2420_i2c2_hwmod;
+static struct omap_hwmod omap2420_mailbox_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -557,6 +558,59 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/* Mailbox */
+
+static struct omap_hwmod_class omap2420_mailbox_hwmod_class = {
+ .name = mailbox,
+};
+
+static struct omap_hwmod_irq_info omap2420_mailbox_irqs[] = {
+ { .name = dsp, .irq = INT_24XX_MAIL_U0_MPU },
+ { .name = iva, .irq = INT_24XX_MAIL_U3_MPU },
+};
+
+static struct omap_hwmod_addr_space omap2420_mailbox_addrs[] = {
+ {
+ .pa_start = OMAP24XX_MAILBOX_BASE,
+ .pa_end = OMAP24XX_MAILBOX_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* L4_CORE - Mailbox */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mailbox = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mailbox_hwmod,
+ .addr = omap2420_mailbox_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mailbox_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* Mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mailbox_slaves[] = {
+ omap2420_l4_core__mailbox,
+};
+
+static struct omap_hwmod omap2420_mailbox_hwmod = {
+ .name = mailbox,
+ .class = omap2420_mailbox_hwmod_class,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MAILBOXES_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
+ },
+ },
+ .main_clk = mailboxes_ick,
+ .mpu_irqs = omap2420_mailbox_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mailbox_irqs),
+ .slaves = omap2420_mailbox_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_mailbox_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -569,6 +623,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_uart3_hwmod,
omap2420_i2c1_hwmod,
omap2420_i2c2_hwmod,
+ omap2420_mailbox_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..1a7d2d9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -81,6 +81,7 @@ static struct omap_hwmod omap2430_uart2_hwmod;
static struct omap_hwmod omap2430_uart3_hwmod;
static struct omap_hwmod omap2430_i2c1_hwmod;
static struct omap_hwmod omap2430_i2c2_hwmod;
+static struct omap_hwmod omap2430_mailbox_hwmod;
/* I2C IP block address space length (in bytes) */
#define OMAP2_I2C_AS_LEN 128
@@ -569,6 +570,58 @@ static struct omap_hwmod omap2430_i2c2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/* Mailbox */
+
+static struct omap_hwmod_class omap2430_mailbox_hwmod_class = {
+ .name = mailbox,
+};
+
+static struct omap_hwmod_irq_info omap2430_mailbox_irqs[] = {
+ { .name = dsp, .irq = INT_24XX_MAIL_U0_MPU },
+};
+
+static struct omap_hwmod_addr_space omap2430_mailbox_addrs[] = {
+ {
+ .pa_start = OMAP24XX_MAILBOX_BASE,
+ .pa_end = OMAP24XX_MAILBOX_BASE + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* L4_CORE - Mailbox */
+static struct omap_hwmod_ocp_if omap2430_l4_core__mailbox = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mailbox_hwmod,
+ .addr = omap2430_mailbox_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_mailbox_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* Mailbox slave ports */
+static struct omap_hwmod_ocp_if *omap2430_mailbox_slaves[] = {
+ omap2430_l4_core__mailbox,
+};
+
+static struct
[PATCH 5/5] omap: mailbox: remove unreachable return
Remove unreachable return statement. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/mailbox.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index b8fd120..2dd0e07 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -435,8 +435,6 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev) return ret; } return 0; - - return ret; } static int __devexit omap2_mbox_remove(struct platform_device *pdev) -- 1.7.1 -- 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: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all these
inc/dec are protected with mutexes or spinlocks, in which case one might
wonder
why atomic operations are used at all, or it's a racy mess. (I vote for
the
second option)
I don't understand. What's the problem? The inc/dec are atomic
because they are not protected by spinlocks, but everything else is
(aside from the tracepoint, which is new).
kref should certainly be used there.
What for?
kref has the following get:
atomic_inc(kref-refcount);
smp_mb__after_atomic_inc();
What seems to be missing in __pm_runtime_get() and pm_runtime_get_noresume()
is
the memory barrier after the atomic increment. The atomic increment is free to
be reordered into the following spinlock (within pm_request_resume or
pm_request
resume execution) because taking a spinlock only acts as a memory barrier with
acquire semantic, not a full memory barrier.
So AFAIU, the failure scenario would be as follows (sorry for the 80+
columns):
initial conditions: usage_count = 1
CPU A CPU B
1) __pm_runtime_get() (sync = true)
2) atomic_inc(usage_count) (not committed to memory yet)
3) pm_runtime_resume()
4) spin_lock_irqsave(dev-power.lock, flags);
5) retval = __pm_request_resume(dev);
If sync = true this is
retval = __pm_runtime_resume(dev);
which drops and reacquires the spinlock. In the meantime it sets
-power.runtime_status so that __pm_runtime_idle() will fail if run at this
point.
6) (execute the body of __pm_request_resume and return)
7)
__pm_runtime_put() (sync = true)
8) if
(atomic_dec_and_test(dev-power.usage_count))
(still see
usage_count == 1 before decrement,
thus decrement
to 0)
9)
pm_runtime_idle()
10) spin_unlock_irqrestore(dev-power.lock, flags)
11)
spin_lock_irq(dev-power.lock);
12)retval =
__pm_runtime_idle(dev);
Moreover, __pm_runtime_idle() checks -power.usage_count under the spinlock,
so it will see it's been incremented in the meantime and it will back off.
13)
spin_unlock_irq(dev-power.lock);
So we end up in a situation where CPU A expects the device to be resumed, but
the last action performed has been to bring it to idle.
A smp_mb__after_atomic_inc() between lines 2 and 3 would fix this.
I don't think this particular race is possible. However, there is another one
that seems to be possible (in a different function) that an explicit barrier
will prevent from happening.
It's related to pm_runtime_get_noresume(), but I think it's better to put the
barrier where it's necessary rather than into pm_runtime_get_noresume() itself.
Thanks,
Rafael
--
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] PERF(kernel): Cleanup power events V2
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all these
inc/dec are protected with mutexes or spinlocks, in which case one might
wonder
why atomic operations are used at all, or it's a racy mess. (I vote for
the
second option)
No, it isn't.
kref should certainly be used there.
No, it shouldn't.
Please try to understand the code you're commenting on first.
Please see my reply to Alan Stern:
http://www.spinics.net/lists/linux-omap/msg39382.html
I have and I'm still unimpressed. :-)
Please see my reply to that message.
Thanks,
Rafael
--
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: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
On Wednesday, October 27, 2010, Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all
these
inc/dec are protected with mutexes or spinlocks, in which case one
might wonder
why atomic operations are used at all, or it's a racy mess. (I vote for
the
second option)
I don't understand. What's the problem? The inc/dec are atomic
because they are not protected by spinlocks, but everything else is
(aside from the tracepoint, which is new).
kref should certainly be used there.
What for?
kref has the following get:
atomic_inc(kref-refcount);
smp_mb__after_atomic_inc();
What seems to be missing in __pm_runtime_get() and
pm_runtime_get_noresume() is
the memory barrier after the atomic increment. The atomic increment is free
to
be reordered into the following spinlock (within pm_request_resume or
pm_request
resume execution) because taking a spinlock only acts as a memory barrier
with
acquire semantic, not a full memory barrier.
So AFAIU, the failure scenario would be as follows (sorry for the 80+
columns):
initial conditions: usage_count = 1
CPU A CPU B
1) __pm_runtime_get() (sync = true)
2) atomic_inc(usage_count) (not committed to memory yet)
3) pm_runtime_resume()
4) spin_lock_irqsave(dev-power.lock, flags);
5) retval = __pm_request_resume(dev);
If sync = true this is
retval = __pm_runtime_resume(dev);
which drops and reacquires the spinlock. In the meantime it sets
-power.runtime_status so that __pm_runtime_idle() will fail if run at this
point.
6) (execute the body of __pm_request_resume and return)
7)
__pm_runtime_put() (sync = true)
8) if
(atomic_dec_and_test(dev-power.usage_count))
(still see
usage_count == 1 before decrement,
thus
decrement to 0)
9)
pm_runtime_idle()
10) spin_unlock_irqrestore(dev-power.lock, flags)
11)
spin_lock_irq(dev-power.lock);
12)retval =
__pm_runtime_idle(dev);
Moreover, __pm_runtime_idle() checks -power.usage_count under the spinlock,
so it will see it's been incremented in the meantime and it will back off.
13)
spin_unlock_irq(dev-power.lock);
So we end up in a situation where CPU A expects the device to be resumed,
but
the last action performed has been to bring it to idle.
A smp_mb__after_atomic_inc() between lines 2 and 3 would fix this.
I don't think this particular race is possible. However, there is another one
that seems to be possible (in a different function) that an explicit barrier
will prevent from happening.
It's related to pm_runtime_get_noresume(), but I think it's better to put the
barrier where it's necessary rather than into pm_runtime_get_noresume()
itself.
Actually, no. Since rpm_idle() and rpm_suspend() both check usage_count under
the spinlock, the race I was thinking about doesn't appear to be possible after
all.
Thanks,
Rafael
--
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 4/4] PERF: fix power:cpu_idle double end events
cpu_idle events (transition into sleep state and exiting) are both fired in pm_idle(). Entering sleep state and exiting should always get fired inside pm_idle() already. This is a revert of commit c882e0feb937af4e5b991cbd1c Signed-off-by: Thomas Renninger tr...@suse.de CC: Robert Schoene robert.scho...@tu-dresden.de CC: Arjan van de Ven ar...@linux.intel.com CC: Ingo Molnar mi...@elte.hu --- arch/x86/kernel/process_32.c |4 arch/x86/kernel/process_64.c |6 -- 2 files changed, 0 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c index 4b9befa..8d12878 100644 --- a/arch/x86/kernel/process_32.c +++ b/arch/x86/kernel/process_32.c @@ -57,8 +57,6 @@ #include asm/syscalls.h #include asm/debugreg.h -#include trace/events/power.h - asmlinkage void ret_from_fork(void) __asm__(ret_from_fork); /* @@ -113,8 +111,6 @@ void cpu_idle(void) stop_critical_timings(); pm_idle(); start_critical_timings(); - trace_power_end(smp_processor_id()); - trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()); } tick_nohz_restart_sched_tick(); preempt_enable_no_resched(); diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 28153a9..d7b3e95 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -51,8 +51,6 @@ #include asm/syscalls.h #include asm/debugreg.h -#include trace/events/power.h - asmlinkage extern void ret_from_fork(void); DEFINE_PER_CPU(unsigned long, old_rsp); @@ -141,10 +139,6 @@ void cpu_idle(void) pm_idle(); start_critical_timings(); - trace_power_end(smp_processor_id()); - trace_cpu_idle(PWR_EVENT_EXIT, - smp_processor_id()); - /* In many cases the interrupt that ended idle has already called exit_idle. But some idle loops can be woken up without interrupt. */ -- 1.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] PERF: Do not export power_frequency, but power_start event
power_frequency moved to drivers/cpufreq/cpufreq.c which has
to be compiled in, no need to export it.
intel_idle can a be module though...
Signed-off-by: Thomas Renninger tr...@suse.de
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
CC: r...@sisk.pl
---
drivers/idle/intel_idle.c |2 --
kernel/trace/power-traces.c |2 +-
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index c37ef64..21ac077 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -201,9 +201,7 @@ static int intel_idle(struct cpuidle_device *dev, struct
cpuidle_state *state)
kt_before = ktime_get_real();
stop_critical_timings();
-#ifndef MODULE
trace_power_start(POWER_CSTATE, (eax 4) + 1, cpu);
-#endif
if (!need_resched()) {
__monitor((void *)current_thread_info()-flags, 0, 0);
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index a22582a..0e0497d 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -13,5 +13,5 @@
#define CREATE_TRACE_POINTS
#include trace/events/power.h
-EXPORT_TRACEPOINT_SYMBOL_GPL(power_frequency);
+EXPORT_TRACEPOINT_SYMBOL_GPL(power_start);
--
1.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] PERF(userspace): Adjust perf timechart to the new power events V3
Changes in V3:
- PWR_EVENT_EXIT is -1 now instead of 0x
- Use cpu_{idle,frequency} instead of processor_{idle,frequency}
events
Changes in V2:
- Hanlde PWR_EVENT_EXIT instead of 0 to recon non-power state
The transition was rather smooth, only part I had to fiddle
some time was the check whether a tracepoint/event is
supported by the running kernel.
builtin-timechart must only pass -e power:xy events which
are supported by the running kernel.
For this I added the tiny helper function:
int is_valid_tracepoint(const char *event_string)
to parse-events.[hc]
which could be more generic as an interface and support
hardware/software/... events, not only tracepoints, but someone
else could extend that if needed...
Signed-off-by: Thomas Renninger tr...@suse.de
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
CC: r...@sisk.pl
---
tools/perf/builtin-timechart.c | 89 ---
tools/perf/util/parse-events.c | 43 +++-
tools/perf/util/parse-events.h |1 +
3 files changed, 116 insertions(+), 17 deletions(-)
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 9bcc38f..bcc16b0 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -32,6 +32,10 @@
#include util/session.h
#include util/svghelper.h
+#define SUPPORT_OLD_POWER_EVENTS 1
+#define PWR_EVENT_EXIT 0x
+
+
static charconst *input_name = perf.data;
static charconst *output_name = output.svg;
@@ -298,12 +302,25 @@ struct trace_entry {
int lock_depth;
};
-struct power_entry {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+struct power_entry_old {
struct trace_entry te;
u64 type;
u64 value;
u64 cpu_id;
};
+#endif
+
+struct power_processor_entry {
+ struct trace_entry te;
+ u64 state;
+ u64 cpu_id;
+};
+
+struct power_suspend_entry {
+ struct trace_entry te;
+ u64 state;
+};
#define TASK_COMM_LEN 16
struct wakeup_entry {
@@ -489,29 +506,46 @@ static int process_sample_event(event_t *event, struct
perf_session *session)
te = (void *)data.raw_data;
if (session-sample_type PERF_SAMPLE_RAW data.raw_size 0) {
char *event_str;
- struct power_entry *pe;
-
- pe = (void *)te;
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+ struct power_entry_old *peo;
+ peo = (void *)te;
+#endif
event_str = perf_header__find_event(te-type);
if (!event_str)
return 0;
- if (strcmp(event_str, power:power_start) == 0)
- c_state_start(pe-cpu_id, data.time, pe-value);
-
- if (strcmp(event_str, power:power_end) == 0)
- c_state_end(pe-cpu_id, data.time);
+ if (strcmp(event_str, power:cpu_idle) == 0) {
+ struct power_processor_entry *ppe = (void *)te;
+ if (ppe-state == PWR_EVENT_EXIT)
+ c_state_end(ppe-cpu_id, data.time);
+ else
+ c_state_start(ppe-cpu_id, data.time,
+ ppe-state);
+ }
- if (strcmp(event_str, power:power_frequency) == 0)
- p_state_change(pe-cpu_id, data.time, pe-value);
+ else if (strcmp(event_str, power:cpu_frequency) == 0) {
+ struct power_processor_entry *ppe = (void *)te;
+ p_state_change(ppe-cpu_id, data.time, ppe-state);
+ }
- if (strcmp(event_str, sched:sched_wakeup) == 0)
+ else if (strcmp(event_str, sched:sched_wakeup) == 0)
sched_wakeup(data.cpu, data.time, data.pid, te);
- if (strcmp(event_str, sched:sched_switch) == 0)
+ else if (strcmp(event_str, sched:sched_switch) == 0)
sched_switch(data.cpu, data.time, te);
+
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+ else if (strcmp(event_str, power:power_start) == 0)
+ c_state_start(peo-cpu_id, data.time, peo-value);
+
+ else if (strcmp(event_str, power:power_end) == 0)
+ c_state_end(peo-cpu_id, data.time);
+
+ else if (strcmp(event_str, power:power_frequency) == 0)
+ p_state_change(peo-cpu_id, data.time, peo-value);
+#endif
}
return 0;
}
@@ -968,7 +1002,8 @@ static const char * const timechart_usage[] = {
NULL
};
-static const char *record_args[] = {
+#if defined(SUPPORT_OLD_POWER_EVENTS)
+static const char
[PATCH 2/4] PERF(kernel): Cleanup power events V3
Changes in V3:
- PWR_EVENT_EXIT is -1 now instead of 0x
- Use cpu_{idle,frequency} instead of processor_{idle,frequency}
events
- Fixed a copy and paste bug (poll_idle should throw and event
state of zero, not 1)
Changes in V2:
- Introduce PWR_EVENT_EXIT instead of 0 to mark non-power state
- Use u32 instead of u64 for cpuid, state which is by far enough
New power trace events:
power:cpu_idle
power:cpu_frequency
power:machine_suspend
C-state/idle accounting events:
power:power_start
power:power_end
are replaced with:
power:cpu_idle
and
power:power_frequency
is replaced with:
power:cpu_frequency
power:machine_suspend
is newly introduced, a first implementation
comes from the ARM side, but it's easy to add these events
in X86 as well if needed.
the type= field got removed from both, it was never
used and the type is differed by the event type itself.
perf timechart
userspace tool gets adjusted in a separate patch.
Signed-off-by: Thomas Renninger tr...@suse.de
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
CC: linux-omap@vger.kernel.org
CC: linux...@lists.linux-foundation.org
CC: linux-trace-us...@vger.kernel.org
CC: Jean Pihet jean.pi...@newoldbits.com
CC: Arjan van de Ven ar...@linux.intel.com
CC: Ingo Molnar mi...@elte.hu
CC: r...@sisk.pl
---
arch/x86/kernel/process.c|7 +++-
arch/x86/kernel/process_32.c |2 +-
arch/x86/kernel/process_64.c |2 +
drivers/cpufreq/cpufreq.c|1 +
drivers/cpuidle/cpuidle.c|1 +
drivers/idle/intel_idle.c|1 +
include/trace/events/power.h | 87 +-
kernel/trace/Kconfig | 14 +++
kernel/trace/power-traces.c |3 +
9 files changed, 115 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 57d1868..155d975 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -374,6 +374,7 @@ void default_idle(void)
{
if (hlt_use_halt()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+ trace_cpu_idle(1, smp_processor_id());
current_thread_info()-status = ~TS_POLLING;
/*
* TS_POLLING-cleared state must be visible before we
@@ -444,6 +445,7 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
void mwait_idle_with_hints(unsigned long ax, unsigned long cx)
{
trace_power_start(POWER_CSTATE, (ax4)+1, smp_processor_id());
+ trace_cpu_idle((ax4)+1, smp_processor_id());
if (!need_resched()) {
if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
@@ -460,6 +462,7 @@ static void mwait_idle(void)
{
if (!need_resched()) {
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+ trace_cpu_idle(1, smp_processor_id());
if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR))
clflush((void *)current_thread_info()-flags);
@@ -481,10 +484,12 @@ static void mwait_idle(void)
static void poll_idle(void)
{
trace_power_start(POWER_CSTATE, 0, smp_processor_id());
+ trace_cpu_idle(0, smp_processor_id());
local_irq_enable();
while (!need_resched())
cpu_relax();
- trace_power_end(0);
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
/*
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 96586c3..4b9befa 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -113,8 +113,8 @@ void cpu_idle(void)
stop_critical_timings();
pm_idle();
start_critical_timings();
-
trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
}
tick_nohz_restart_sched_tick();
preempt_enable_no_resched();
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3d9ea53..28153a9 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -142,6 +142,8 @@ void cpu_idle(void)
start_critical_timings();
trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT,
+ smp_processor_id());
/* In many cases the interrupt that ended idle
has already called exit_idle. But some idle
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 199dcb9..ed4919e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -355,6 +355,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs,
unsigned int state)
dprintk(FREQ: %lu - CPU: %lu, (unsigned
Re: [PATCH] PERF(kernel): Cleanup power events V2
On Tuesday 26 October 2010 08:57:01 pm Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Thomas Renninger wrote:
Ok, that's at least generic. Needs the review of Rafael, to determine
whether this state value is all we want to know when we enter suspend.
He already gave an acked-by on this generic one here:
Re: [PATCH 3/4] perf: add calls to suspend trace point
Oh now, that was on the X86 specific part which depends on this one.
One should expect that he's fine with the generic part as well then,
but I agree that he should definitely have a look at this and sign it off.
What patch exactly do you mean? I'm not quite sure from your comment above.
Eh, Jean's patch, sorry about that.
Needs a tiny change to use PWR_EVENT_EXIT instead of 0 with
my new patch series:
Signed-off-by: Jean Pihet j-pi...@ti.com
CC: Thomas Renninger tr...@suse.de
Acked-by: Rafael J. Wysocki r...@sisk.pl
---
kernel/power/suspend.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 7335952..10cad5c 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
#include linux/mm.h
#include linux/slab.h
#include linux/suspend.h
+#include trace/events/power.h
#include power.h
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) pm_check_wakeup_events()) {
+ trace_machine_suspend(state);
error = suspend_ops-enter(state);
+ trace_machine_suspend(0);
events_check_enabled = false;
}
sysdev_resume();
--
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: [linux-pm] [PATCH] PERF(kernel): Cleanup power events V2
* Rafael J. Wysocki (r...@sisk.pl) wrote:
On Tuesday, October 26, 2010, Mathieu Desnoyers wrote:
* Alan Stern (st...@rowland.harvard.edu) wrote:
On Tue, 26 Oct 2010, Mathieu Desnoyers wrote:
* Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
That's terribly racy..
Looking at the original code, it looks racy even without considering the
tracepoint:
int __pm_runtime_get(struct device *dev, bool sync)
{
int retval;
+ trace_runtime_pm_usage(dev,
atomic_read(dev-power.usage_count)+1);
atomic_inc(dev-power.usage_count);
retval = sync ? pm_runtime_resume(dev) : pm_request_resume(dev);
There is no implied memory barrier after atomic_inc. So either all
these
inc/dec are protected with mutexes or spinlocks, in which case one
might wonder
why atomic operations are used at all, or it's a racy mess. (I vote for
the
second option)
I don't understand. What's the problem? The inc/dec are atomic
because they are not protected by spinlocks, but everything else is
(aside from the tracepoint, which is new).
kref should certainly be used there.
What for?
kref has the following get:
atomic_inc(kref-refcount);
smp_mb__after_atomic_inc();
What seems to be missing in __pm_runtime_get() and
pm_runtime_get_noresume() is
the memory barrier after the atomic increment. The atomic increment is free
to
be reordered into the following spinlock (within pm_request_resume or
pm_request
resume execution) because taking a spinlock only acts as a memory barrier
with
acquire semantic, not a full memory barrier.
So AFAIU, the failure scenario would be as follows (sorry for the 80+
columns):
initial conditions: usage_count = 1
CPU A CPU B
1) __pm_runtime_get() (sync = true)
2) atomic_inc(usage_count) (not committed to memory yet)
3) pm_runtime_resume()
4) spin_lock_irqsave(dev-power.lock, flags);
5) retval = __pm_request_resume(dev);
If sync = true this is
retval = __pm_runtime_resume(dev);
which drops and reacquires the spinlock.
Let's see. Upon entry in __pm_runtime_resume, the following condition holds
(remember, the initial condition is that usage_count == 1):
dev-power.runtime_status == RPM_ACTIVE
so retval is set to 1, which goto directly to out, without setting parent.
So there does not seem to be any spinlock reacquire on this path, or am I
misunderstanding how the runtime_status works ?
In the meantime it sets
-power.runtime_status so that __pm_runtime_idle() will fail if run at this
point.
runtime_status will be left at RPM_ACTIVE, which is the appropriate value
expected by __pm_runtime_idle.
6) (execute the body of __pm_request_resume and return)
7)
__pm_runtime_put() (sync = true)
8) if
(atomic_dec_and_test(dev-power.usage_count))
(still see
usage_count == 1 before decrement,
thus
decrement to 0)
9)
pm_runtime_idle()
10) spin_unlock_irqrestore(dev-power.lock, flags)
11)
spin_lock_irq(dev-power.lock);
12)retval =
__pm_runtime_idle(dev);
Moreover, __pm_runtime_idle() checks -power.usage_count under the spinlock,
so it will see it's been incremented in the meantime and it will back off.
This is a subtle but important point. Yes, my scenario seems to be dealt with by
the extra usage_count check while the spinlock is held.
How about adding a comment under this atomic_inc() stating that the memory
barriers are implicitely dealt with by the following spinlock release and the
extra check while spinlock is held ?
Commenting memory barriers is important, but commenting why memory barriers are
not needed due to a subtle corner-case looks even more important.
(hrm, but more below considering pm_runtime_get_noresume())
13)
spin_unlock_irq(dev-power.lock);
So we end up in a situation where CPU A expects the device to be resumed,
but
the last action performed has been to bring it to idle.
A smp_mb__after_atomic_inc() between lines 2 and 3 would fix this.
I don't think this particular race is possible. However, there is another one
that seems to be possible (in a
RE: [PATCH v3 01/13] OMAP: DMA: Replace read/write macros with functions
-Original Message-
From: Menon, Nishanth
Sent: Tuesday, October 26, 2010 8:19 PM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; Cousson, Benoit; Kevin
Hilman; Shilimkar, Santosh
Subject: Re: [PATCH v3 01/13] OMAP: DMA: Replace read/write
macros with functions
G, Manjunath Kondaiah had written, on 10/26/2010 08:25 AM,
the following:
[...]
diff --git a/arch/arm/plat-omap/dma.c
b/arch/arm/plat-omap/dma.c index
f5c5b8d..77241e2 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,147 @@
[...]
+static u16 reg_map_omap2[] = {
+ [REVISION] = 0x00,
+ [GCR2] = 0x78,
+ [IRQSTATUS_L0] = 0x08,
+ [IRQSTATUS_L1] = 0x0c,
[..]
+ /* OMAP4 specific registers */
+ [CDP] = 0xd0,
+ [CNDP] = 0xd4,
+ [CCDN] = 0xd8,
+};
+
dumb question: any reason why a struct wont do?
struct reg_map_omap2 {
u16 revision;
...
...
}
This approach is as per i2c driver as suggested by kevin.
http://www.spinics.net/lists/linux-omap/msg36446.html
[..]
-#define dma_read(reg)
\
-({
\
- u32 __val;
\
- if (cpu_class_is_omap1())
\
- __val = __raw_readw(omap_dma_base +
OMAP1_DMA_##reg); \
- else
\
- __val = __raw_readl(omap_dma_base +
OMAP_DMA4_##reg); \
- __val;
\
-})
-
-#define dma_write(val, reg)
\
-({
\
- if (cpu_class_is_omap1())
\
- __raw_writew((u16)(val), omap_dma_base +
OMAP1_DMA_##reg); \
- else
\
- __raw_writel((val), omap_dma_base +
OMAP_DMA4_##reg); \
-})
+static inline void dma_write(u32 val, int reg, int lch) {
+ if (cpu_class_is_omap1()) {
+ if (reg OMAP1_CH_COMMON_START)
+ __raw_writew(val, dma_base +
+ (reg_map_omap1[reg] + 0x40 * lch));
+ else
+ __raw_writew(val, dma_base +
reg_map_omap1[reg]);
+ } else {
+ if (reg OMAP2_CH_COMMON_START)
+ __raw_writel(val, dma_base +
+ (reg_map_omap2[reg] + 0x60 * lch));
+ else
+ __raw_writel(val, dma_base +
reg_map_omap2[reg]);
+ }
+}
+
+static inline u32 dma_read(int reg, int lch) {
+ u32 val;
+
+ if (cpu_class_is_omap1()) {
+ if (reg OMAP1_CH_COMMON_START)
+ val = __raw_readw(dma_base +
+ (reg_map_omap1[reg]
+ 0x40 * lch));
+ else
+ val = __raw_readw(dma_base +
reg_map_omap1[reg]);
+ } else {
+ if (reg OMAP2_CH_COMMON_START)
+ val = __raw_readl(dma_base +
+ (reg_map_omap2[reg]
+ 0x60 * lch));
+ else
+ val = __raw_readl(dma_base +
reg_map_omap2[reg]);
+ }
+ return val;
+}
What is the benefit of using inline function here? would'nt
we increase code size? cant we use a function pointer
initialized to class1 or rest?
Quote from CodingStyle (15):
A reasonable rule of thumb is to not put inline at functions
that have more than 3 lines of code in them. An exception to
this rule are the cases where a parameter is known to be a
compiletime constant, and as a result of this constantness
you *know* the compiler will be able to optimize most of your
function away at compile time. For a good example of this
later case, see the kmalloc() inline function.
is the expectation that cpu_class_is_omap1 compile time
constant hence the actual compiled in code is smaller
-candidate for inline?
Detailed discussion and alignment can be found at:
http://www.spinics.net/lists/linux-omap/thrd6.html
Search for:
[PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
#ifdef CONFIG_ARCH_OMAP15XX
/* Returns 1 if the DMA module is in OMAP1510-compatible mode, 0
if (cpu_class_is_omap1()) {
[...]
u16 ccr;
- ccr = dma_read(CCR(lch));
+ l = dma_read(CSDP1, lch);
+ l = ~0x03;
+
RE: [PATCH v3 00/13] OMAP: DMA: hwmod and DMA as platform device
Hi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah Sent: Tuesday, October 26, 2010 6:55 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; Cousson, Benoit; Kevin Hilman; Shilimkar, Santosh Subject: [PATCH v3 00/13] OMAP: DMA: hwmod and DMA as platform device This patch series converts DMA library into platform device and hwmod adaptation is done for omap2+ processors. [...] G, Manjunath Kondaiah (12): [...] OMAP: DMA: Use DMA device attributes Looks like this patch is not getting posted due to its size(~105 KB) The patch is available for review comments at: http://dev.omapzoom.org/?p=manju/kernel-omap3-dev.git;a=commitdiff;h=7457a6b4248772aaa52dfb13a170f891596a512a -Manjunath-- 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/5] omap: mailbox: fix detection for previously supported chips
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Ramirez Luna, Omar
Sent: Wednesday, October 27, 2010 3:23 AM
To: Tony Lindgren; Hiroshi DOYU
Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez
Luna, Omar; Anna, Suman; Paul Walmsley; Cousson, Benoit;
Raja, Govindraj; C.A, Subramaniam; linux-omap@vger.kernel.org
Subject: [PATCH 4/5] omap: mailbox: fix detection for
previously supported chips
Fix the mailbox detection for OMAP3630 and 2430, also minor
cleanup on conditional ifdef's that could affect it.
Given that 2430 has an iva too include it, as the same steps
for omap3 apply.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/mailbox.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c
b/arch/arm/mach-omap2/mailbox.c
index 61f2149..b8fd120 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -277,7 +277,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
/* FIXME: the following structs should be filled
automatically by the user id */
-#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
/* DSP */
static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -302,7 +302,7 @@ struct omap_mbox mbox_dsp_info = {
};
#endif
-#if defined(CONFIG_ARCH_OMAP3430)
+#if defined(CONFIG_ARCH_OMAP3)
struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
#endif
@@ -390,15 +390,19 @@ static int __devinit
omap2_mbox_probe(struct platform_device *pdev)
if (false)
;
-#if defined(CONFIG_ARCH_OMAP3430)
- else if (cpu_is_omap3430()) {
+#if defined(CONFIG_ARCH_OMAP3)
+ else if (cpu_is_omap34xx()) {
Use cpu_is_* check only. No need to have #if CONFIG_ARCH_* checks.
list = omap3_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
}
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
- else if (cpu_is_omap2420()) {
+#if defined(CONFIG_ARCH_OMAP2)
+ else if (cpu_is_omap2430()) {
+ list = omap2_mboxes;
+
+ list[0]-irq = platform_get_irq_byname(pdev, dsp);
+ } else if (cpu_is_omap2420()) {
Ditto
list = omap2_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
--
1.7.1
--
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: [PATCH 2/5] omap: mailbox: initial hwmod support for omap2
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Omar Ramirez Luna Sent: Wednesday, October 27, 2010 3:23 AM To: Tony Lindgren; Hiroshi DOYU Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez Luna, Omar; Anna, Suman; Paul Walmsley; Cousson, Benoit; Raja, Govindraj; C.A, Subramaniam; linux-omap@vger.kernel.org Subject: [PATCH 2/5] omap: mailbox: initial hwmod support for omap2 HWMOD support for omap2430 and 2420. It is preferred to use the following $Subject while adding hwmod data OMAP2: hwmod data: Add mailbox -V Charulatha snip-- 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/5] omap: mailbox: initial hwmod support for omap3
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Ramirez Luna, Omar
Sent: Wednesday, October 27, 2010 3:23 AM
To: Tony Lindgren; Hiroshi DOYU
Cc: Felipe Contreras; Dmitry Kasatkin; Kevin Hilman; Ramirez
Luna, Omar; Anna, Suman; Paul Walmsley; Cousson, Benoit;
Raja, Govindraj; C.A, Subramaniam; linux-omap@vger.kernel.org
Subject: [PATCH 1/5] omap: mailbox: initial hwmod support for omap3
From: Felipe Contreras felipe.contre...@gmail.com
HWMOD support for omap3.
Use hwmod.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/mach-omap2/devices.c | 100
---
arch/arm/mach-omap2/mailbox.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 +++
3 files changed, 70 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index eaf3799..d977572 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -141,95 +141,25 @@ static inline void omap_init_camera(void)
#endif
#if defined(CONFIG_OMAP_MBOX_FWK) ||
defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-
-#define MBOX_REG_SIZE 0x120
-
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_mbox_resources[] = {
- {
- .start = OMAP24XX_MAILBOX_BASE,
- .end= OMAP24XX_MAILBOX_BASE +
MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = dsp,
- },
- {
- .start = INT_24XX_MAIL_U3_MPU,
- .flags = IORESOURCE_IRQ,
- .name = iva,
- },
-};
-static int omap2_mbox_resources_sz =
ARRAY_SIZE(omap2_mbox_resources);
-#else
-#define omap2_mbox_resources NULL
-#define omap2_mbox_resources_sz 0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_mbox_resources[] = {
- {
- .start = OMAP34XX_MAILBOX_BASE,
- .end= OMAP34XX_MAILBOX_BASE +
MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = INT_24XX_MAIL_U0_MPU,
- .flags = IORESOURCE_IRQ,
- .name = dsp,
- },
-};
-static int omap3_mbox_resources_sz =
ARRAY_SIZE(omap3_mbox_resources);
-#else
-#define omap3_mbox_resources NULL
-#define omap3_mbox_resources_sz 0
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-
-#define OMAP4_MBOX_REG_SIZE 0x130
-static struct resource omap4_mbox_resources[] = {
- {
- .start = OMAP44XX_MAILBOX_BASE,
- .end= OMAP44XX_MAILBOX_BASE +
- OMAP4_MBOX_REG_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP44XX_IRQ_MAIL_U0,
- .flags = IORESOURCE_IRQ,
- .name = mbox,
- },
-};
-static int omap4_mbox_resources_sz =
ARRAY_SIZE(omap4_mbox_resources);
-#else
-#define omap4_mbox_resources NULL
-#define omap4_mbox_resources_sz 0
-#endif
-
-static struct platform_device mbox_device = {
- .name = omap-mailbox,
- .id = -1,
-};
-
static inline void omap_init_mbox(void)
{
- if (cpu_is_omap24xx()) {
- mbox_device.resource = omap2_mbox_resources;
- mbox_device.num_resources = omap2_mbox_resources_sz;
- } else if (cpu_is_omap34xx()) {
- mbox_device.resource = omap3_mbox_resources;
- mbox_device.num_resources = omap3_mbox_resources_sz;
- } else if (cpu_is_omap44xx()) {
- mbox_device.resource = omap4_mbox_resources;
- mbox_device.num_resources = omap4_mbox_resources_sz;
- } else {
- pr_err(%s: platform not supported\n, __func__);
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+
+ oh = omap_hwmod_lookup(mailbox);
+ if (!oh) {
+ pr_err(%s: unable to find hwmod\n, __func__);
+ return;
+ }
+
+ od = omap_device_build(omap-mailbox, -1, oh,
+ NULL, 0,
+ NULL, 0,
+ 0);
This patch series breaks OMAP4 support.
OMAP2 support is broken with this patch and the same is fixed
in the next patch. Hence patch 2 should be ordered before patch 1.
+ if (!od) {
+ pr_err(%s: could not build device\n, __func__);
return;
}
- platform_device_register(mbox_device);
}
#else
static inline void omap_init_mbox(void) { }
diff --git
