Re: New project announcement: gst-dsp, with beagleboard demo image
It definitely seems to be a very nice effort that will be very useful to many projects. I will integrate on the Touch Book. Thanks, Grégoire On Tue, 2009-10-13 at 00:31 +0300, Felipe Contreras wrote: Hi, This is the first public release of gst-dsp; a native GStreamer plug-in to access Texas Instruments' DSP algorithms for OMAP3 platforms. The code came originally from a series of TI projects: tiopenmax[1], and libbridge[2]. gst-dsp replaces these two layers and talks directly to the DSP bridge driver. The main advantages are code simplification (5k vs 50k), and better performance (at least 4 times less CPU usage). However, not all of the codecs have been implemented, only MPEG-4 and H.263 video encoders and decoders, the JPEG encoder, and H.264 is partially supported. Currently it's used in the Nokia N900. In order to make it easier for people to try it out, I created a demo image for the beagleboard with all the required components: GStreamer, gst-dsp, DSP public binaries, and a kernel with DSS2 and DSP bridge driver. The linux kernel (DSS2 + dspbridge) is at the v2.6.32-felipec1 tag in: http://gitorious.org/~felipec/linux-omap/felipec The DSP algorithms are public, and come from tiopenmax: https://gforge.ti.com/gf/download/frsrelease/170/1399/tiopenmax-0.3.5.tar.gz Here's the demo rootfs with the kernel image and instructions: http://people.freedesktop.org/~felipec/beagle-2.6.32-rc3/ And here's the video showing it on action for both playback and recording: http://www.youtube.com/watch?v=SN-Nw_yDQUs The main repository is hosted on github: http://github.com/felipec/gst-dsp And there's also one specific for maemo: http://maemo.gitorious.org/maemo-multimedia/gst-dsp This code wouldn't have been possible without all the contributions and specially thanks to TI for making their code open source. Here's the shortlog for 0.6.0: Andriy Shevchenko (1): base: fix a crash on send codec data Felipe Contreras (180): Initial commit Register dsp node Add README Fix and update copyrights Add ALLOCATE_HEAP and ALLOCATE_SN to dsp_bridge Add handy dsp_send_message dummy: use dsp_send_message Rename gstdsp.* to plugin.* Makefile: cleanup dummy: trivial clanups Add log utility Use log utility dmm_buffer: size_t improvements dmm_buffer: always unmap when freeing dmm_buffer: use getpagesize() dmm_buffer: alignment improvements dmm_buffer: add user_data field Add MPEG-4 video decoder README: update mp4vdec: trivial cleanup mp4vdec: send signal to output_loop mp4vdec: flush output buffers too mp4vdec: reset output port mp4vdec: extra check for null buffer mp4vdec: use atomic operations for status mp4vdec: use more atomic operations for status mp4vdec: send stop signal before mp4vdec: re-use comm buffers dmm_buffer: reorganize a bit dmm_buffer: add dmm_buffer_reserve dmm_buffer: allow to re-reserve memory dmm_buffer: allow re-mapping mp4vdec: trivial cleanup dmm_buffer: unmap before unreserving mp4vdec: re-use mappings for output buffers mp4vdec: convert flush condition to semaphore Remove cond.h Rename mp4vdec to vdec vdec: trivial cleanup vdec: trivial reorganization vdec: prepare for multiple algos vdec: move create_node to dsp_start vdec: start dsp node after getting the caps vdec: initial support for H.264 vdec: add Juha to authors list README: update vdec: cleanup vdec: make dsp_thread static vdec: reorganize a bit New base class Add new video encoder base: handle more commands base: reorganize got_message a bit venc: improve jpeg args venc: send jpeg dynamic params base: cleanup setup_output_buffers base: remove unused buffer_count base: reorganize a bit base: add use_pad_alloc option base: free mapped buffers on dsp_stop() base: be more verbose on get_slot() README: update Makefile: check for missing symbols New utility gstdsp_register() base: detect dsp errors base: properly handle dsp errors base: post error in the bus base: extra check for status in outout_loop() base: free events array base: reinitialize state on NULL-READY base: use circular buffer for timestamps base: increase ts_array base: increase mapping cache dummy: reorganize map_buffer dummy: input buffers don't need alignment dummy: cleanup dummy: don't map buffers venc: increase framesize limit for jpeg base: add gstdsp_post_error() venc: allocate a buffer when framesize is unaligned base: decrease wait for events timeout
adding new board
Hi all, I'd like to send patches for OMAP3 based board. My question is what branch in linux-omap tree should I use as a base for my patches? -- Sincerely yours, Mike. -- 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: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
Tony, On Fri, Oct 9, 2009 at 11:16 PM, Tony Lindgren t...@atomide.com wrote: * G, Manjunath Kondaiah manj...@ti.com [091008 00:41]: Govind, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Govindraj Sent: Thursday, October 08, 2009 11:44 AM To: Tony Lindgren Cc: Raja, Govindraj; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux-ser...@vger.kernel.org Subject: Re: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support. On Thu, Oct 8, 2009 at 3:21 AM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [090924 03:29]: From: Govindraj R govindraj.r...@ti.com This patch adds support for OMAP3430-HIGH SPEED UART Controller. Signed-off-by: Govindraj R govindraj.r...@ti.com Reviewed-by: Alan Cox a...@lxorguk.ukuu.org.uk Reviewed-by: Tony Lindgren t...@atomide.com You should only add Reviewed-by if Alan or me have replied with it. So far I've only replied with some comments that have not yet been fixed, so we're few more steps from being Reviewd-by. snip diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 6553833..67a7129 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1359,6 +1359,53 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_OMAP + bool OMAP serial port support + depends on ARM ARCH_OMAP + select SERIAL_CORE + help + If you have a machine based on an Texas Instruments OMAP CPU you + can enable its onboard serial ports by enabling this option. + +config SERIAL_OMAP_CONSOLE + bool Console on OMAP serial port + depends on SERIAL_OMAP + select SERIAL_CORE_CONSOLE + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can make it the console by answering Y to this option. + + Even if you say Y here, the currently visible virtual console + (/dev/tty0) will still be used as the system console by default, but + you can alter that using a kernel command line option such as + console=ttyS0. (Try man bootparam or see the documentation of + your boot loader (lilo or loadlin) about how to pass options to the + kernel at boot time.) + +config SERIAL_OMAP_DMA_UART1 + bool UART1 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 1 by answering + to this option. + +config SERIAL_OMAP_DMA_UART2 + bool UART2 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 2 by answering + to this option. + +config SERIAL_OMAP_DMA_UART3 + bool UART3 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 3 by answering + to this option. + config SERIAL_OF_PLATFORM_NWPSERIAL tristate NWP serial port driver depends on PPC_OF PPC_DCR There's absolutely no need for having Kconfig options for the DMA support. Please pass that in platform_data from the board-*.c files. This is the third time I'm commenting on the same issue! What's the point of posting these patches for review if the issues don't get solved? The omap-serial uart driver is designed to work either in interrupt mode or in DMA mode, We have provided this option so that one can select interrupt mode or DMA mode based on the uart usage, if somebody is using uart as console then interrupt mode will do, else if used with bluetooth which does huge data transfer then DMA mode can be selected. Don't you think this should be a configurable option using kconfig rather than passing as platform data? Nope. I think it should be platform_data and should be possible to override vith a kernel cmdline option. That's because we support compiling in and booting many boards the same kernel binary. if used as platform data then one has to modify platform data to switch between the interrupt and DMA mode. How about set some kernel cmdline options if you want to override the default settings? Using cmdline options, will make specific UART switch dynamically between Non-DMA and DMA mode which is not handled in the driver. how abt using bootargs to share this Mode info ? Usage of UART is board dependent. It's usage will not change dynamically for a given board. This can be removed from Kconfig and move it to respective board file-
Re: omap3: ehci: trivial fix of a debug print
On Mon, Oct 12, 2009 at 07:20:20PM +0200, ext Anand Gadiyar wrote: omap3: ehci: trivial fix of a debug print We're interested in uhh_hostconfig, not uhh_base. While we are actually printing the former, we're calling it the latter. Signed-off-by: Anand Gadiyar gadi...@ti.com Acked-by: Felipe Balbi felipe.ba...@nokia.com --- diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 45b8a7c..73f0b3b 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -363,7 +363,7 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap, struct usb_hcd *hcd) } ehci_omap_writel(omap-uhh_base, OMAP_UHH_HOSTCONFIG, reg); - dev_dbg(omap-dev, UHH setup done, uhh_base=%x\n, reg); + dev_dbg(omap-dev, UHH setup done, uhh_hostconfig=%x\n, reg); if ((omap-port_mode[0] == EHCI_HCD_OMAP_MODE_TLL) || -- 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 -- balbi -- 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] OMAP: DSS2: RFBI driver update
On Mon, 2009-10-12 at 17:25 +0200, ext Christensen, Mikkel wrote:
On Mon, Oct 12, 2009 at 09:17:27, Tomi Valkeinen wrote:
Subject: RE: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Mon, 2009-10-12 at 16:03 +0200, ext Christensen, Mikkel wrote:
On Mon, Oct 12, 2009 at 03:25:27, Tomi Valkeinen wrote:
Subject: Re: [PATCH 1/1] OMAP: DSS2: RFBI driver update
On Fri, 2009-10-09 at 23:08 +0200, ext Mikkel Christensen wrote:
This patch adds suspend / resume functionality to the RFBI
driver along with missing callback functions needed by OMAP Frame
buffer.
Signed-off-by: Mikkel Christensen m...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 76
1 files changed, 76 insertions(+), 0 deletions(-)
snip
+static int rfbi_display_suspend(struct omap_dss_device
*dssdev) {
+ unsigned long l;
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return -EINVAL;
+
+ DSSDBG(rfbi_display_suspend\n);
+
+ if (dssdev-driver-suspend)
+ dssdev-driver-suspend(dssdev);
+
+ dispc_enable_lcd_out(0);
I don't think this is needed. DSS hardware disables
lcd_out when the
transfer has finished. Although for correct operation suspend()
should wait until the last transfer has been done before
disabling
clocks, which is something it currently doesn't.
This was done with reference to the DPI and SDI files that
do the same thing. It can be removed if not necessary.
DPI and SDI work quite differently than RFBI, you can't just copy
their functionality =).
It is more correct without disable/enable_lcd_out, but it's not
correct as there may be a transfer ongoing when suspend call comes.
That's why there should be some mechanism to wait until the transfer
has been done.
DSI tries to do this (and hopefully correctly does =).
OK. Thanks I will try to incorporate this. Where in the DSI driver is this
mechanism implemented?
It's the dsi_bus_lock mechanism. But it doesn't work as such for RFBI,
because the DSI uses a bit different mechanism for updates. But somehow
the suspend function needs to wait until the transfer has been
completed, and suspend only after that (and also make sure that no new
transfer starts before the suspend).
Tomi
--
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: RE: Memory performance / Cache problem
Can you upgrade to a newer u-boot? Either from the PSP release OR u-boot tree hosted at git.denx.de (atleast 2009.03)? Also, it will be good to see the sample program you are using. ~sanjeev There is no newer u-boot from TI available. There is a SDK 02.01.03.11 but it contains the same uboot 2008.10 with the only addition of the second generation of EVM boards with another network chip. So I checked the uboot from git, but this doesn't support Microns NAND Flash anymore. It is just working with ONENAND. I found a patch which shows the L2 Cache status while kernel boot and implemented it : L2 Cache seems to be already enabled - so this is not the reason. So any other ideas? -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- 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: Memory performance / Cache problem
The L2 cache is set and running. I don't know - can it be configured or misconfigured somehow? I just checked the output of 2.6.22 kernel and get these lines (which I don't have in newer kernels): CPU0: D VIPT write-through cache CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets Built 1 zonelists. Total pages: 32512 I am wondering what is this? First thought was L1 cache, but it's to small. The benchmark is running on same hardware, same uboot, same rootfs, just the kernel is different. On Monday 12 October 2009 10:54:09 ext e...@gmx.de wrote: I found the memory performance of newer kernels are quit poor on an EVM-Omap3 board. It works with 2-6 times performance on the old 2.6.22 kernel from TI's PSP. Possible reasons: - problem in config the kernel (did omap3_evm_defconfig) - problem in kernel - kernel expects some settings from uboot, which are not done there I have tried the 2.6.29rc3 (from TI's PSP) and the 2.6.31 from git-tree. Both behave quite simular: Transport in MByte: memcpy = 204.073, loop4 = 183.212, loop1 =81.693, rand = 4.534 while the 22 kernel: memcpy = 453.932, loop4 = 469.934, loop1 = 125.031, rand = 29.631 Can someone give me help or can at least confirm that? The numbers from 2.6.22 kernel look much better than anything I have ever seen with OMAP3. How are you doing benchmarking? Is source buffer properly initialized? The point is that if you just happen to allocate a large buffer without initializing it, it may end up having all the memory pages referencing to a single zero page in physical memory. In this case reading from this buffer will in fact be perfectly cached in L1 cache and memcpy would look fast. If it is not the case, investigating how to boost memory performance in the latest kernels is very interesting for sure. -- Best regards, Siarhei Siamashka -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02 -- 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: New project announcement: gst-dsp, with beagleboard demo image
On Tue, Oct 13, 2009 at 12:31 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Hi, This is the first public release of gst-dsp; a native GStreamer plug-in to access Texas Instruments' DSP algorithms for OMAP3 platforms. The code came originally from a series of TI projects: tiopenmax[1], and libbridge[2]. gst-dsp replaces these two layers and talks directly to the DSP bridge driver. The main advantages are code simplification (5k vs 50k), and better performance (at least 4 times less CPU usage). However, not all of the codecs have been implemented, only MPEG-4 and H.263 video encoders and decoders, the JPEG encoder, and H.264 is partially supported. Currently it's used in the Nokia N900. In order to make it easier for people to try it out, I created a demo image for the beagleboard with all the required components: GStreamer, gst-dsp, DSP public binaries, and a kernel with DSS2 and DSP bridge driver. The linux kernel (DSS2 + dspbridge) is at the v2.6.32-felipec1 tag in: http://gitorious.org/~felipec/linux-omap/felipec The DSP algorithms are public, and come from tiopenmax: https://gforge.ti.com/gf/download/frsrelease/170/1399/tiopenmax-0.3.5.tar.gz Here's the demo rootfs with the kernel image and instructions: http://people.freedesktop.org/~felipec/beagle-2.6.32-rc3/ And here's the video showing it on action for both playback and recording: http://www.youtube.com/watch?v=SN-Nw_yDQUs I removed the video because of a bug in YouTube and uploaded it again: http://www.youtube.com/watch?v=CjxkNIHBGdI 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 RESEND] I2C: OMAP: Add missing wakeup events
Hello, Sonasath, Moiz wrote: From: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com Include wake up events for receiver overflow and transmitter underflow in OMAP_I2C_WE_REG configuration. Also fix a small typo. Signed-off-by: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com --- drivers/i2c/busses/i2c-omap.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 827da08..34ea9ed 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -92,8 +92,10 @@ #define OMAP_I2C_STAT_AL (1 0) /* Arbitration lost int ena */ /* I2C WE wakeup enable register */ -#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakup */ +#define OMAP_I2C_WE_XDR_WE (1 14) /* TX drain wakeup */ #define OMAP_I2C_WE_RDR_WE (1 13) /* RX drain wakeup */ +#define OMAP_I2C_WE_ROVR_WE(1 11) /* RX overflow wakeup */ +#define OMAP_I2C_WE_XUDF_WE(1 10) /* TX underflow wakeup */ These bits are not documented in OMAP3430, they are reserved. How can they be used? Hmm, that's a valid point. I will have to check if I can find more info on the background of this patch. A. -- 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] [RFC] omap: 3630: default cpu_is_omap3630 to zero
Has anybody tried building latest linux-omap master ? The build is breaking for other OMAP processors. CC arch/arm/mach-omap2/id.o arch/arm/mach-omap2/id.c: In function 'omap3_cpuinfo': arch/arm/mach-omap2/id.c:269: error: implicit declaration of function 'cpu_is_omap3630' make[1]: *** [arch/arm/mach-omap2/id.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 This is because of 0a9b95f21995aa3cdda82ebc6e77b0b2ab401861 omap: Introduce OMAP3630 Below patch from Vikram fixes the build break. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Pandita, Vikram Sent: Tuesday, October 13, 2009 2:38 AM To: Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero -Original Message- From: Menon, Nishanth Sent: Monday, October 12, 2009 4:05 PM To: Pandita, Vikram Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero -Original Message- From: Pandita, Vikram Sent: Monday, October 12, 2009 3:51 PM make default cpu_is_omap3630() return zero Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat- omap/include/mach/cpu.h index da9e8f8..940946e 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 +#define cpu_is_omap3630() 0 /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) (omap3_has_sgx()) \ (!omap3_has_iva())) # define cpu_is_omap3530 (cpu_is_omap3430()) +# undef cpu_is_omap3630() # define cpu_is_omap3630()is_omap363x() #endif Dumb question: why is this needed? cpu_is_omap3530,15,25,03 don't seems to declare these.. If in some file, you want to distinguish between 3630 vs 3430, and the build is for 3430 only, then cpu_is_omap3630() should return 0. Eg: opp table allocation based on run time check Omap35xx may also need it for the opp in future I guess. -- 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] [RFC] omap: 3630: default cpu_is_omap3630 to zero
Shilimkar, Santosh said the following on 10/13/2009 05:03 AM: Has anybody tried building latest linux-omap master ? The build is breaking for other OMAP processors. CC arch/arm/mach-omap2/id.o arch/arm/mach-omap2/id.c: In function 'omap3_cpuinfo': arch/arm/mach-omap2/id.c:269: error: implicit declaration of function 'cpu_is_omap3630' make[1]: *** [arch/arm/mach-omap2/id.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 This is because of 0a9b95f21995aa3cdda82ebc6e77b0b2ab401861 omap: Introduce OMAP3630 Below patch from Vikram fixes the build break. ouch.. my bad.. thanks for answering my question. I am guessing we need this coz of is_omap3630() translation.. Ack for the patch from me. Regards, Nishanth Menon -- 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] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
Hello Nishanth,
Thanks for your feedback, I'll forward the patch correcting some things
2009/10/10 Nishanth Menon n...@ti.com:
could you add more details on where do we get more data on this platform?
More details will be in new patch and you can get more information here:
www.igep-platform.com
Regards,
Enric
2009/10/10 Nishanth Menon n...@ti.com:
Hi,
Thanks for the patch.. a few minor comments follow from a read through..
Enric Balletbò i Serra had written, on 10/09/2009 10:59 AM, the following:
This patch adds minimal IGEP v2 support.
could you add more details on where do we get more data on this platform?
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/configs/igep0020_defconfig | 1443
++
arch/arm/mach-omap2/Kconfig | 4 +
arch/arm/mach-omap2/Makefile | 2 +
arch/arm/mach-omap2/board-igep0020.c | 239 ++
4 files changed, 1688 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/configs/igep0020_defconfig
create mode 100644 arch/arm/mach-omap2/board-igep0020.c
[...]
--- /dev/null
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -0,0 +1,239 @@
+/*
[..]
+static inline void __init igep2_init_smsc911x(void)
+{
+ unsigned long cs_mem_base;
+
+ if (gpmc_cs_request(IGEP2_SMSC911X_CS, SZ_16M, cs_mem_base) 0)
{
+ printk(KERN_ERR Failed request for GPMC mem for
smsc911x\n);
+ return;
+ }
+
+ igep2_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ igep2_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if ((gpio_request(IGEP2_SMSC911X_GPIO, SMSC911X IRQ) == 0)
+ (gpio_direction_input(IGEP2_SMSC911X_GPIO) == 0)) {
+ gpio_export(IGEP2_SMSC911X_GPIO, 0);
+ } else {
could you run scripts/checkpatch --strict ../patchName after generating the
patch with git format-patch -s -M -o .. -1 ? one liners dont usually need a
{} also there are few warning inducing code below..
+ printk(KERN_ERR could not obtain gpio for SMSC911X
IRQ\n);
probably dumb question: should'nt we be moving to pr_err and family instead
of printks?
further, if this does not work.. are'nt you supposed to release the cs?
gpmc_cs_free perhaps?
+ return;
+ }
+
+ igep2_smsc911x_resources[1].start =
OMAP_GPIO_IRQ(IGEP2_SMSC911X_GPIO);
+ igep2_smsc911x_resources[1].end = 0;
+
+ platform_device_register(igep2_smsc911x_device);
+}
+
+#else
+
+static inline void __init igep2_init_smsc911x(void) { }
+
+#endif
+
[..]
+ .flags = I2C_CLIENT_WAKE,
+ .irq = INT_34XX_SYS_NIRQ,
+ .platform_data = igep2_twldata,
+ },
+};
+
+static int __init igep2_i2c_init(void)
+{
+ omap_register_i2c_bus(1, 2600, igep2_i2c_boardinfo,
+ ARRAY_SIZE(igep2_i2c_boardinfo));
you may want to step down to 2400
http://marc.info/?l=linux-omapm=125510664919890w=2 if you are using
26Mhz.. if you are using twl5030..
+ omap_register_i2c_bus(3, 400, NULL, 0);
+ return 0;
+}
+
+static void __init igep2_init(void)
+{
+ igep2_i2c_init();
+ omap_serial_init();
+ usb_musb_init();
+
+ igep2_init_smsc911x();
+
+ /* GPIO userspace leds */
+ if ((gpio_request(IGEP2_GPIO_LED_0_RED, GPIO_LED_0_RED) == 0)
(gpio_direction_output(IGEP2_GPIO_LED_0_RED, 1) == 0)) {
+ gpio_export(IGEP2_GPIO_LED_0_RED, 1);
+ } else {
+ printk(KERN_ERR could not obtain gpio for
GPIO_LED_0_RED\n);
do you really want to flag a an error for a led glow?
+ }
+ if ((gpio_request(IGEP2_GPIO_LED_0_GREEN, GPIO_LED_0_GREEN) ==
0)
(gpio_direction_output(IGEP2_GPIO_LED_0_GREEN, 1) == 0)) {
+ gpio_export(IGEP2_GPIO_LED_0_GREEN, 1);
+ } else {
+ printk(KERN_ERR could not obtain gpio for
GPIO_LED_0_GREEN\n);
+ }
+ if ((gpio_request(IGEP2_GPIO_LED_1_RED, GPIO_LED_1_RED) == 0)
(gpio_direction_output(IGEP2_GPIO_LED_1_RED, 1) == 0)) {
here is a an long line?
[...]
--
Regards,
Nishanth Menon
--
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] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
This patch adds minimal IGEP v2 support. The IGEP v2 board is a low-cost, fan-less and industrial temperature range single board computer that unleashes laptop-like performance and expandability without the bulk, expense, or noise of typical desktop machines. Its architecture shares much in common with other OMAP3 boards. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/configs/igep0020_defconfig | 1432 ++ arch/arm/mach-omap2/Kconfig |4 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-igep0020.c | 252 ++ 4 files changed, 1690 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/igep0020_defconfig create mode 100644 arch/arm/mach-omap2/board-igep0020.c diff --git a/arch/arm/configs/igep0020_defconfig b/arch/arm/configs/igep0020_defconfig new file mode 100644 index 000..e66dca4 --- /dev/null +++ b/arch/arm/configs/igep0020_defconfig @@ -0,0 +1,1432 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32-rc4 +# Tue Oct 13 12:53:15 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_COMPAT_BRK=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +# CONFIG_FREEZER is not set + +# +# System Type +# +CONFIG_MMU=y +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_NOMADIK is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is
patch: add omap730 / omap850 rtc support
Christopher Friedt chrisfri...@gmail.com
20091013: Add support for the OMAP730 and OMAP850 RTC.
==
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 0587d53..5163d67 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -22,6 +22,7 @@
#include linux/platform_device.h
#include asm/io.h
+#include mach/cpu.h
/* The OMAP1 RTC is a year/month/day/hours/minutes/seconds BCD clock
@@ -39,29 +40,80 @@
#define OMAP_RTC_BASE 0xfffb4800
-/* RTC registers */
-#define OMAP_RTC_SECONDS_REG 0x00
-#define OMAP_RTC_MINUTES_REG 0x04
-#define OMAP_RTC_HOURS_REG 0x08
-#define OMAP_RTC_DAYS_REG 0x0C
-#define OMAP_RTC_MONTHS_REG0x10
-#define OMAP_RTC_YEARS_REG 0x14
-#define OMAP_RTC_WEEKS_REG 0x18
-
-#define OMAP_RTC_ALARM_SECONDS_REG 0x20
-#define OMAP_RTC_ALARM_MINUTES_REG 0x24
-#define OMAP_RTC_ALARM_HOURS_REG 0x28
-#define OMAP_RTC_ALARM_DAYS_REG0x2c
-#define OMAP_RTC_ALARM_MONTHS_REG 0x30
-#define OMAP_RTC_ALARM_YEARS_REG 0x34
-
-#define OMAP_RTC_CTRL_REG 0x40
-#define OMAP_RTC_STATUS_REG0x44
-#define OMAP_RTC_INTERRUPTS_REG0x48
-
-#define OMAP_RTC_COMP_LSB_REG 0x4c
-#define OMAP_RTC_COMP_MSB_REG 0x50
-#define OMAP_RTC_OSC_REG 0x54
+enum omap_rtc_regs {
+ SECONDS_REG = 0,
+ MINUTES_REG,
+ HOURS_REG,
+ DAYS_REG,
+ MONTHS_REG,
+ YEARS_REG,
+ WEEKS_REG,
+ ALARM_SECONDS_REG,
+ ALARM_MINUTES_REG,
+ ALARM_HOURS_REG,
+ ALARM_DAYS_REG,
+ ALARM_MONTHS_REG,
+ ALARM_YEARS_REG,
+ CTRL_REG,
+ STATUS_REG,
+ INTERRUPTS_REG,
+ COMP_LSB_REG,
+ COMP_MSB_REG,
+};
+#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+static u8 omap_8bit_rtc_offsets[] = {
+ [SECONDS_REG] = 0x00,
+ [MINUTES_REG] = 0x01,
+ [HOURS_REG] = 0x02,
+ [DAYS_REG] = 0x03,
+ [MONTHS_REG]= 0x04,
+ [YEARS_REG] = 0x05,
+ [WEEKS_REG] = 0x06,
+ /* 0x07 reserved */
+ [ALARM_SECONDS_REG] = 0x08,
+ [ALARM_MINUTES_REG] = 0x09,
+ [ALARM_HOURS_REG] = 0x0a,
+ [ALARM_DAYS_REG]= 0x0b,
+ [ALARM_MONTHS_REG] = 0x0c,
+ [ALARM_YEARS_REG] = 0x0d,
+ /* 0x0e reserved */
+ /* 0x0f reserved */
+ [CTRL_REG] = 0x10,
+ [STATUS_REG]= 0x11,
+ [INTERRUPTS_REG]= 0x12,
+ [COMP_LSB_REG] = 0x13,
+ [COMP_MSB_REG] = 0x14,
+};
+#else
+#define omap_8bit_rtc_offsets NULL
+#endif
+#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
+static u8 omap_32bit_rtc_offsets[] = {
+ [SECONDS_REG] = 0x00,
+ [MINUTES_REG] = 0x04,
+ [HOURS_REG] = 0x08,
+ [DAYS_REG] = 0x0c,
+ [MONTHS_REG]= 0x10,
+ [YEARS_REG] = 0x14,
+ [WEEKS_REG] = 0x18,
+ [ALARM_SECONDS_REG] = 0x20,
+ [ALARM_MINUTES_REG] = 0x24,
+ [ALARM_HOURS_REG] = 0x28,
+ [ALARM_DAYS_REG]= 0x2c,
+ [ALARM_MONTHS_REG] = 0x30,
+ [ALARM_YEARS_REG] = 0x34,
+ [CTRL_REG] = 0x40,
+ [STATUS_REG]= 0x44,
+ [INTERRUPTS_REG]= 0x48,
+ [COMP_LSB_REG] = 0x4c,
+ [COMP_MSB_REG] = 0x50,
+};
+#else
+#define omap_32bit_rtc_offsets NULL
+#endif
+
+// set to 32bit or 8bit rtc offsets by omap_rtc_probe()
+static u8 *rtc_offsets;
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
@@ -87,10 +139,8 @@
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
-
-#define rtc_read(addr) omap_readb(OMAP_RTC_BASE + (addr))
-#define rtc_write(val, addr) omap_writeb(val, OMAP_RTC_BASE + (addr))
-
+#define rtc_read(reg) omap_readb(OMAP_RTC_BASE + rtc_offsets[reg])
+#define rtc_write(val, reg)omap_writeb(val, OMAP_RTC_BASE +
rtc_offsets[reg])
/* we rely on the rtc framework to handle locking (rtc-ops_lock),
* so the only other requirement is that register accesses which
@@ -103,7 +153,7 @@ static void rtc_wait_not_busy(void)
/* BUSY may stay active for 1/32768 second (~30 usec) */
for (count = 0; count 50; count++) {
- status = rtc_read(OMAP_RTC_STATUS_REG);
+ status = rtc_read(STATUS_REG);
if ((status (u8)OMAP_RTC_STATUS_BUSY) == 0)
break;
udelay(1);
@@ -116,11 +166,11 @@ static irqreturn_t rtc_irq(int irq, void *rtc)
unsigned long events = 0;
u8
DSS2 frame buffer problem
I have a new board that I'd like to run a frame buffer 800x600x24 When I boot, I get this error: omapfb: failed to allocate framebuffer This board is derived from a board I'm already running DSS2 at 800x600x16 on. What do I need to change to get this to work? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 frame buffer problem
On Tue, 2009-10-13 at 14:55 +0200, ext Gary Thomas wrote: I have a new board that I'd like to run a frame buffer 800x600x24 When I boot, I get this error: omapfb: failed to allocate framebuffer This board is derived from a board I'm already running DSS2 at 800x600x16 on. What do I need to change to get this to work? Most likely you need to allocate more VRAM with vram boot option, in board file or kernel config option (CONFIG_OMAP2_VRAM_SIZE). Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2 frame buffer problem
On 10/13/2009 06:59 AM, Tomi Valkeinen wrote: On Tue, 2009-10-13 at 14:55 +0200, ext Gary Thomas wrote: I have a new board that I'd like to run a frame buffer 800x600x24 When I boot, I get this error: omapfb: failed to allocate framebuffer This board is derived from a board I'm already running DSS2 at 800x600x16 on. What do I need to change to get this to work? Most likely you need to allocate more VRAM with vram boot option, in board file or kernel config option (CONFIG_OMAP2_VRAM_SIZE). Thanks, that was it. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: Broken cpuidle on PM branch?
Hello Amit, On Mon, Oct 12, 2009 at 09:23:47PM +0200, ext Amit Kucheria wrote: Hi, I am testing twl4030 script optimisations on the current PM branch. But I am seeing the board (RX51) freeze when CPU_IDLE is enabled in the config. Is it known to work on other boards? I'm actually seeing this same behavior. But the board actually does not freeze. If you keep a key pressed of send a sysrq through serial line then you eventually get it back. It seams to be something related to serial driver and wakeup ? Regards, Amit -- - Amit Kucheria, Kernel Developer, Verdurent - -- 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 -- Eduardo Valentin -- 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: Broken cpuidle on PM branch?
Amit Kucheria amit.kuche...@verdurent.com writes: Hi, I am testing twl4030 script optimisations on the current PM branch. But I am seeing the board (RX51) freeze when CPU_IDLE is enabled in the config. Is it known to work on other boards? Yes, and it works for me on RX51 as well, output of the maemo powertop below. For a known working defconfig, start from omap3_pm_defconfig and change the low-level debug UART from UART1 to UART3. There is a known UART bug in the current PM branch where if you don't 'echo 1 /debug/pm_debug/sleep_while_idle', the UART eventually locks up when the inactivity timer expires. I'm still looking into this one. Kevin / # powertop Powertop 1.13.1 status: Unable to send message: Connection refused Mounting debugfs...Success Sleeping for 11 seconds before sampling Collecting data for 30 seconds Sample interval was 00m 30s 20569us C# | Ratio | Avg/dura | Frequency | Ratio ++--+---+-- C0 | 83.4% | | 600 MHz | 0.0% C1 | 16.6% | 832.4ms | 550 MHz | 0.0% C2 | 0.0% | | 500 MHz | 100.0% C3 | 0.0% | | 250 MHz | 0.0% C4 | 0.0% | | 125 MHz | 0.0% IRQ#| Activity | Type | Name +++--- 37 | 27 | INTC | gp 11 | 23 | INTC | prcm 12 | 4 | INTC | DMA 225 | 2 | GPIO | omap2-onenand PID#| Activity | Name | Function Entry (Expire) +++--- 0 | 16 | kernel core | hrtimer_start (tick_sched_timer) 93 | 5 |bdi-default | bdi_forker_task (process_timeout) 483 | 5 |flush-ubifs_0_0 | schedule_timeout_interruptible (process) 0 | 4 | kernel core | arm_supers_timer (sync_supers_timer_fn) 5 | 3 | events/0 | queue_delayed_work (delayed_work_timer_) 483 | 1 |flush-ubifs_0_0 | hrtimer_start_range_ns (wbuf_timer_call) 483 | 1 |flush-ubifs_0_0 | hrtimer_start_range_ns (wbuf_timer_call) 484 | 1 | powertop | hrtimer_start_range_ns (hrtimer_wakeup) Power domain activity breakdown Domain | % of time spent in states +-+-+-+-+-- usbhost |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) sgx |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF) per |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) dss |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) cam |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) core |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) neon |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) mpu |OFF: 0%|RET: 83%|INA: 0%| ON: 16%| now:(ON) iva2 |OFF: 0%|RET: 100%|INA: 0%| ON: 0%| now:(RET) Clock activity breakdown at end of period Domain | Active clocks +---+---+-- core | SDRC | OMAPCTRL | UART1 | UART2 | core3 | USBTLL wkup | GPT1 | 32KSYNC |
Re: adding new board
Hi, * Mike Rapoport m...@compulab.co.il [091013 00:07]: Hi all, I'd like to send patches for OMAP3 based board. My question is what branch in linux-omap tree should I use as a base for my patches? Please do all the patches against the most recent mainline revision. Regards, 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: adding new board
Tony Lindgren wrote: Hi, * Mike Rapoport m...@compulab.co.il [091013 00:07]: Hi all, I'd like to send patches for OMAP3 based board. My question is what branch in linux-omap tree should I use as a base for my patches? Please do all the patches against the most recent mainline revision. Do you mean Linus' tree or linux-omap/master? Regards, Tony -- Sincerely yours, Mike. -- 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] OMAP3: PM: SmartReflex: Fix scheduled while atomic problem
Eduardo Valentin eduardo.valen...@nokia.com writes:
This patch moves clock lookup from get_vdd[1,2]_opp to
initialization procedure. Also adds a field in omap_sr
structure to store these clocks for later usage.
Calling clk_get inside get_vdd[1,2]_opp would cause
a scheduled while atomic problem while entering in idle
state (interrupts disabled).
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Thanks, will pull into next PM branch. Note that SR is in the middle
of a complete rewrite, so Nishanth, please ensure this fix is included
or verify that it is not needed in your rewrite.
Thanks,
Kevin
---
arch/arm/mach-omap2/smartreflex.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 8660863..8946e7c 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -43,6 +43,7 @@ struct omap_sr {
int is_sr_reset;
int is_autocomp_active;
struct clk *clk;
+ struct clk *vdd_opp_clk;
u32 clk_length;
u32 req_opp_no;
u32 opp1_nvalue, opp2_nvalue, opp3_nvalue, opp4_nvalue;
@@ -170,28 +171,24 @@ static u16 get_opp(struct omap_opp *opp_freq_table,
static u16 get_vdd1_opp(void)
{
u16 opp;
- struct clk *clk;
- clk = clk_get(NULL, dpll1_ck);
-
- if (clk == NULL || IS_ERR(clk) || mpu_opps == NULL)
+ if (sr1.vdd_opp_clk == NULL || IS_ERR(sr1.vdd_opp_clk) ||
+ mpu_opps == NULL)
return 0;
- opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk-rate);
+ opp = get_opp(mpu_opps + MAX_VDD1_OPP, sr1.vdd_opp_clk-rate);
return opp;
}
static u16 get_vdd2_opp(void)
{
u16 opp;
- struct clk *clk;
-
- clk = clk_get(NULL, l3_ick);
- if (clk == NULL || IS_ERR(clk) || l3_opps == NULL)
+ if (sr2.vdd_opp_clk == NULL || IS_ERR(sr2.vdd_opp_clk) ||
+ l3_opps == NULL)
return 0;
- opp = get_opp(l3_opps + MAX_VDD2_OPP, clk-rate);
+ opp = get_opp(l3_opps + MAX_VDD2_OPP, sr2.vdd_opp_clk-rate);
return opp;
}
@@ -999,6 +996,8 @@ static int __init omap3_sr_init(void)
sr1.clk = clk_get(NULL, sr1_fck);
sr2.clk = clk_get(NULL, sr2_fck);
}
+ sr1.vdd_opp_clk = clk_get(NULL, dpll1_ck);
+ sr2.vdd_opp_clk = clk_get(NULL, l3_ick);
sr_set_clk_length(sr1);
sr_set_clk_length(sr2);
--
1.6.4.183.g04423
--
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
ARM: SMP: BUG with PREEMPT enabled
Russell,
On the latest ARM kernel(v2.6.32-rc4),I have observed a BUG() dump when PREEMPT
is enabled.
Attached is the detailed log for your reference.
snip
**
BUG: using smp_processor_id() in preemptible [] code: init/1
caller is flush_tlb_mm+0x44/0x70
Backtrace:
[c00225c4] (dump_backtrace+0x0/0x110) from [c01713a0] (dump_stack+0x18/0x1c)
r7: r6:c00234f0 r5:0001 r4:c7828000
[c0171388] (dump_stack+0x0/0x1c) from [c0135364]
(debug_smp_processor_id+0xc0/0xf0)
[c01352a4] (debug_smp_processor_id+0x0/0xf0) from [c00234f0]
(flush_tlb_mm+0x44/0x70)
r7: r6:c60b41a0 r5:c60b4154 r4:0001
[c00234ac] (flush_tlb_mm+0x0/0x70) from [c0039568] (dup_mm+0x304/0x38c)
r5:c1f09058 r4:
[c0039264] (dup_mm+0x0/0x38c) from [c0039de4] (copy_process+0x7b8/0xeb0)
[c003962c] (copy_process+0x0/0xeb0) from [c003a638] (do_fork+0x15c/0x29c)
[c003a4dc] (do_fork+0x0/0x29c) from [c0021df0] (sys_clone+0x34/0x3c)
[c0021dbc] (sys_clone+0x0/0x3c) from [c001efa0] (ret_fast_syscall+0x0/0x2c)
**
As evident from the log smp_processor_id is used in preemptible code. This
gets triggered from
flush_tlb_mm() --
local_flush_tlb_mm()
{
if (cpu_isset(smp_processor_id(), vma-vm_mm-cpu_vm_mask)) ^^
}
This can be guuarded using get_cpu/put_cpu pair which can make it preemption
safe but I am not sure whether that is the right fix.
Let me know your remarks !!
Regards,
Santosh
preempt.log
Description: preempt.log
Re: [PATCH] OMAP35x: Add support for 720MHz part
Hi,
* Sanjeev Premi pr...@ti.com [091012 06:00]:
This patch adds support for ARM running at 720MHz part.
The 720MHz capability can be probed run-time by reading the
PRODID.SKUID[3:0] at 0x4830A20C.
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/clock34xx.c |6 ++
arch/arm/mach-omap2/id.c | 11 +++
arch/arm/plat-omap/include/mach/control.h |7 +++
arch/arm/plat-omap/include/mach/cpu.h |2 ++
4 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 489556e..9b56af3 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -1096,6 +1096,12 @@ static int __init omap2_clk_arch_init(void)
if (!mpurate)
return -EINVAL;
+ if ((mpurate == 72000) !omap3_has_720mhz()) {
+ printk(KERN_ERR *** Silicon doesn't support 720MHz\n);
+
+ mpurate = 6; /* Set to highest supported */
+ }
+
/* REVISIT: not yet ready for 343x */
if (clk_set_rate(dpll1_ck, mpurate))
printk(KERN_ERR *** Unable to set MPU rate\n);
To me it seems like this should be limited in clk_set_rate()
instead.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d4d563b..e0b427a 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -79,6 +79,7 @@ EXPORT_SYMBOL(omap_type);
#define OMAP_TAP_DIE_ID_20x0220
#define OMAP_TAP_DIE_ID_30x0224
+
#define read_tap_reg(reg)__raw_readl(tap_base + (reg))
struct omap_id {
@@ -180,6 +181,15 @@ void __init omap3_check_features(void)
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
+
+ /*
+ * Does it support 720MHz?
+ */
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
+ if (status OMAP3_SKUID_720MHZ) {
+ omap3_features |= OMAP3_HAS_720MHZ;
+ }
}
void __init omap3_check_revision(void)
How would 720MHz speed be any different from other speeds?
@@ -296,6 +306,7 @@ void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(sgx);
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
+ OMAP3_SHOW_FEATURE(720mhz);
}
/*
diff --git a/arch/arm/plat-omap/include/mach/control.h
b/arch/arm/plat-omap/include/mach/control.h
index fdb6300..e886bb6 100644
--- a/arch/arm/plat-omap/include/mach/control.h
+++ b/arch/arm/plat-omap/include/mach/control.h
@@ -238,6 +238,13 @@
#define FEAT_NEON 0
#define FEAT_NEON_NONE 1
+/*
+ * Product ID register
+ */
+#define OMAP3_PRODID 0x020C
+
+#define OMAP3_SKUID_MASK 0x0f
+#define OMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index 8d0841b..12b91f7 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -472,6 +472,7 @@ extern u32 omap3_features;
#define OMAP3_HAS_SGXBIT(2)
#define OMAP3_HAS_NEON BIT(3)
#define OMAP3_HAS_ISPBIT(4)
+#define OMAP3_HAS_720MHZ BIT(5)
#define OMAP3_HAS_FEATURE(feat,flag) \
static inline unsigned int omap3_has_ ##feat(void) \
@@ -484,5 +485,6 @@ OMAP3_HAS_FEATURE(sgx, SGX)
OMAP3_HAS_FEATURE(iva, IVA)
OMAP3_HAS_FEATURE(neon, NEON)
OMAP3_HAS_FEATURE(isp, ISP)
+OMAP3_HAS_FEATURE(720mhz, 720MHZ)
#endif
I think we should rather implement a function omap_get_max_rate()
or similar, and then the clock framework initializes the clocks
based on that. This way clk_set_rate() can limit the speed
as needed.
Regards,
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
[PATCH 1/2] ARM: OMAP3: add CompuLab CM-T35 module
This patch adds basic support for CompuLab CM-T35 module.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-cm-t35.c | 476
3 files changed, 482 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-cm-t35.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 75b1c7e..f80439e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -85,6 +85,10 @@ config MACH_OMAP_ZOOM2
bool OMAP3 Zoom2 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+config MACH_CM_T35
+ bool CompuLab CM-T35 module
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8cb1677..7468505 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -74,6 +74,8 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
mmc-twl4030.o \
board-zoom-debugboard.o
+obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
+ mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
new file mode 100644
index 000..2aeb44f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -0,0 +1,476 @@
+/*
+ * board-cm-t35.c (CompuLab CM-T35 module)
+ *
+ * Copyright (C) 2009 CompuLab, Ltd.
+ * Author: Mike Rapoport m...@compulab.co.il
+ *
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/delay.h
+
+#include linux/i2c/at24.h
+#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include mach/board.h
+#include mach/common.h
+#include mach/hardware.h
+#include mach/gpio.h
+#include mach/mux.h
+#include mach/nand.h
+#include mach/keypad.h
+#include mach/gpmc.h
+#include mach/usb.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+#include mmc-twl4030.h
+
+#define CM_T35_GPIO_PENDOWN57
+
+#define CM_T35_SMSC911X_CS 5
+#define CM_T35_SMSC911X_GPIO 163
+
+#define NAND_BLOCK_SIZESZ_128K
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS0_BASE_ADDR (OMAP34XX_GPMC_VIRT + GPMC_CS0_BASE)
+
+#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
+#include linux/smsc911x.h
+
+static struct resource cm_t35_smsc911x_resources[] = {
+ {
+ .name = smsc911x-memory,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP_GPIO_IRQ(CM_T35_SMSC911X_GPIO),
+ .end= OMAP_GPIO_IRQ(CM_T35_SMSC911X_GPIO),
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
+static struct smsc911x_platform_config cm_t35_smsc911x_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
+static struct platform_device cm_t35_smsc911x_device = {
+ .name = smsc911x,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(cm_t35_smsc911x_resources),
+ .resource = cm_t35_smsc911x_resources,
+ .dev= {
+ .platform_data = cm_t35_smsc911x_config,
+ },
+};
+
+static void __init cm_t35_init_smsc911x(void)
+{
+ unsigned long cs_mem_base;
+
+ if (gpmc_cs_request(CM_T35_SMSC911X_CS, SZ_16M, cs_mem_base) 0) {
+ pr_err(CM-T35: Failed request for GPMC mem for smsc911x\n);
+ return;
+ }
+
+ cm_t35_smsc911x_resources[0].start = cs_mem_base + 0x0;
+ cm_t35_smsc911x_resources[0].end = cs_mem_base + 0xff;
+
+ if ((gpio_request(CM_T35_SMSC911X_GPIO, CM ETH IRQ) == 0)
+
[PATCH v2 2/2] OMAP3: add platform devices for ETM and ETB
This enables on-chip tracing components found in omap3xxx.
Signed-off-by: Alexander Shishkin virtu...@slind.org
---
Changes:
v2 -- use emu_src clock for etb; feed it from sys_ck
arch/arm/mach-omap2/Kconfig |7 +++
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/emu.c| 95 ++
3 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/emu.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 15cb529..4fbbb39 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -96,3 +96,10 @@ config MACH_OMAP_ZOOM2
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
+
+config OMAP3_EMU
+ bool OMAP3 debugging peripherals
+ depends on ARCH_OMAP3 OC_ETM
+ help
+ Say Y here to enable debugging hardware of omap3
+
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9e63562..d1e172b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -44,6 +44,9 @@ obj-$(CONFIG_ARCH_OMAP4) += cm4xxx.o
obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o
obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o
+# EMU periferals
+obj-$(CONFIG_OMAP3_EMU)+= emu.o
+
iommu-y+= iommu2.o
iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o
diff --git a/arch/arm/mach-omap2/emu.c b/arch/arm/mach-omap2/emu.c
new file mode 100644
index 000..d2f03a9
--- /dev/null
+++ b/arch/arm/mach-omap2/emu.c
@@ -0,0 +1,95 @@
+/*
+ * emu.c
+ *
+ * ETM and ETB CoreSight components' resources as found in OMAP3xxx.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ * Alexander Shishkin
+ *
+ * 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/kernel.h
+#include linux/init.h
+#include linux/types.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Alexander Shishkin);
+
+/* Cortex CoreSight components within omap3xxx EMU */
+#define ETM_BASE (L4_EMU_34XX_PHYS + 0x1)
+#define DBG_BASE (L4_EMU_34XX_PHYS + 0x11000)
+#define ETB_BASE (L4_EMU_34XX_PHYS + 0x1b000)
+#define DAPCTL (L4_EMU_34XX_PHYS + 0x1d000)
+
+static struct resource omap3_etb_resource = {
+ .start = ETB_BASE,
+ .end = ETB_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3_etb_device = {
+ .name = etb,
+ .id = -1,
+ .num_resources = 1,
+ .resource = omap3_etb_resource,
+};
+
+static struct resource omap3_etm_resource = {
+ .start = ETM_BASE,
+ .end = ETM_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device omap3_etm_device = {
+ .name = etm,
+ .id = -1,
+ .num_resources = 1,
+ .resource = omap3_etm_resource,
+};
+
+static struct platform_device *omap3_trace_devices[] = {
+ omap3_etm_device,
+ omap3_etb_device,
+};
+
+static int __init emu_init(void)
+{
+ struct clk *emu_clk, *sys_clk;
+
+ platform_add_devices(omap3_trace_devices,
+ ARRAY_SIZE(omap3_trace_devices));
+
+ sys_clk = clk_get(omap3_etb_device.dev, sys_ck);
+ if (IS_ERR(sys_clk)) {
+ dev_dbg(omap3_etb_device.dev, Failed to obtain sys_ck.\n);
+ return -EFAULT;
+ }
+
+ emu_clk = clk_get(omap3_etb_device.dev, emu_src_ck);
+ if (IS_ERR(emu_clk)) {
+ dev_dbg(omap3_etb_device.dev,
+ Failed to obtain emu_src_ck.\n);
+ return -EFAULT;
+ }
+
+ if (clk_set_parent(emu_clk, sys_clk)) {
+ dev_dbg(omap3_etb_device.dev, clk_set_parent failed.\n);
+ return -EFAULT;
+ }
+
+ /* looks like we could use IORESOURCE_CLOCK */
+ platform_device_add_data(omap3_etb_device, emu_clk, sizeof(emu_clk));
+
+ return 0;
+}
+
+subsys_initcall(emu_init);
+
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP3: add CompuLab CM-T35 module
* Mike Rapoport m...@compulab.co.il [091013 10:00]:
This patch adds basic support for CompuLab CM-T35 module.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
snip
+static struct ehci_hcd_omap_platform_data ehci_pdata = {
+
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = -EINVAL,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
This ehci stuff should be done in a separate patch, it's not in
the mainline tree yet.
Can you please check that your patch will compile OK with the
mainline tree?
Regards,
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
[PATCH v2 1/2] arm: a driver for on-chip ETM and ETB
This driver implements support for on-chip Embedded Tracing Macrocell and
Embedded Trace Buffer. It allows to trigger tracing of kernel execution flow
and exporting trace output to userspace via character device and a sysrq
combo.
Trace output can then be decoded by a fairly simple open source tool [1]
which is already sufficient to get the idea of what the kernel is doing.
[1]: http://github.com/virtuoso/etm2human
Signed-off-by: Alexander Shishkin virtu...@slind.org
---
Changes:
v2 -- major update:
* fixes according to comments from Linus Walleij and Anand Gadiyar
* omap3 clock-related stuff moved to platform device
v1 -- fixed comments from Juha Leppanen
v0 -- initial implementation, has been sent to linux-omap only
arch/arm/Kconfig.debug|8 +
arch/arm/include/asm/hardware/coresight.h | 164
arch/arm/kernel/Makefile |2 +
arch/arm/kernel/etm.c | 593 +
4 files changed, 767 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/hardware/coresight.h
create mode 100644 arch/arm/kernel/etm.c
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 1a6f70e..3c20e7f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -83,6 +83,14 @@ config DEBUG_ICEDCC
It does include a timeout to ensure that the system does not
totally freeze when there is nothing connected to read.
+config OC_ETM
+ bool On-chip ETM and ETB
+ depends on ARCH_OMAP3
+ help
+ Enables the on-chip embedded trace macrocell and embedded trace
+ buffer driver that will allow you to collect traces of the
+ kernel code.
+
config DEBUG_DC21285_PORT
bool Kernel low-level debugging messages via footbridge serial port
depends on DEBUG_LL FOOTBRIDGE
diff --git a/arch/arm/include/asm/hardware/coresight.h
b/arch/arm/include/asm/hardware/coresight.h
new file mode 100644
index 000..3ba99c1
--- /dev/null
+++ b/arch/arm/include/asm/hardware/coresight.h
@@ -0,0 +1,164 @@
+/*
+ * linux/arch/arm/include/asm/hardware/coresight.h
+ *
+ * CoreSight components' registers
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ * Alexander Shishkin
+ *
+ * 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.
+ */
+
+#ifndef __ASM_HARDWARE_CORESIGHT_H
+#define __ASM_HARDWARE_CORESIGHT_H
+
+#define TRACER_ACCESSED_BIT0
+#define TRACER_RUNNING_BIT 1
+#define TRACER_CYCLE_ACC_BIT 2
+#define TRACER_ACCESSEDBIT(TRACER_ACCESSED_BIT)
+#define TRACER_RUNNING BIT(TRACER_RUNNING_BIT)
+#define TRACER_CYCLE_ACC BIT(TRACER_CYCLE_ACC_BIT)
+
+struct tracectx {
+ unsigned intetb_bufsz;
+ void __iomem*etb_regs;
+ void __iomem*etm_regs;
+ unsigned long flags;
+ int ncmppairs;
+ int etm_portsz;
+ struct device *dev;
+ struct mutexmutex;
+};
+
+#define TRACER_TIMEOUT 1
+
+#define etm_writel(t, v, x) \
+ (__raw_writel((v), (t)-etm_regs + (x)))
+#define etm_readl(t, x) (__raw_readl((t)-etm_regs + (x)))
+
+/* CoreSight Management Registers */
+#define CSMR_LOCKACCESS 0xfb0
+#define CSMR_LOCKSTATUS 0xfb4
+#define CSMR_AUTHSTATUS 0xfb8
+#define CSMR_DEVID 0xfc8
+#define CSMR_DEVTYPE 0xfcc
+/* CoreSight Component Registers */
+#define CSCR_CLASS 0xff4
+
+#define CSCR_PRSR 0x314
+
+#define UNLOCK_MAGIC 0xc5acce55
+
+/* ETM control register, ETM Architecture, 3.3.1 */
+#define ETMR_CTRL 0
+#define ETMCTRL_POWERDOWN 1
+#define ETMCTRL_PROGRAM(1 10)
+#define ETMCTRL_PORTSEL(1 11)
+#define ETMCTRL_DO_CONTEXTID (3 14)
+#define ETMCTRL_PORTMASK1 (7 4)
+#define ETMCTRL_PORTMASK2 (1 21)
+#define ETMCTRL_PORTMASK (ETMCTRL_PORTMASK1 | ETMCTRL_PORTMASK2)
+#define ETMCTRL_PORTSIZE(x) x) 7) 4) | (!!((x) 8)) 21)
+#define ETMCTRL_DO_CPRT(1 1)
+#define ETMCTRL_DATAMASK (3 2)
+#define ETMCTRL_DATA_DO_DATA (1 2)
+#define ETMCTRL_DATA_DO_ADDR (1 3)
+#define ETMCTRL_DATA_DO_BOTH (ETMCTRL_DATA_DO_DATA | ETMCTRL_DATA_DO_ADDR)
+#define ETMCTRL_BRANCH_OUTPUT (1 8)
+#define ETMCTRL_CYCLEACCURATE (1 12)
+
+/* ETM configuration code register */
+#define ETMR_CONFCODE (0x04)
+
+/* ETM trace start/stop resource control register */
+#define ETMR_TRACESSCTRL (0x18)
+
+/* ETM trigger event register */
+#define ETMR_TRIGEVT (0x08)
+
+/* address access type register bits, ETM architecture,
+ * table 3-27 */
+/* - access type */
+#define ETMAAT_IFETCH 0
+#define ETMAAT_IEXEC 1
+#define ETMAAT_IEXECPASS 2
+#define ETMAAT_IEXECFAIL 3
+#define ETMAAT_DLOADSTORE 4
+#define ETMAAT_DLOAD 5
+#define ETMAAT_DSTORE 6
+/* -
Re: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero
* Nishanth Menon menon.nisha...@gmail.com [091013 03:44]: Shilimkar, Santosh said the following on 10/13/2009 05:03 AM: Has anybody tried building latest linux-omap master ? The build is breaking for other OMAP processors. CC arch/arm/mach-omap2/id.o arch/arm/mach-omap2/id.c: In function 'omap3_cpuinfo': arch/arm/mach-omap2/id.c:269: error: implicit declaration of function 'cpu_is_omap3630' make[1]: *** [arch/arm/mach-omap2/id.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 This is because of 0a9b95f21995aa3cdda82ebc6e77b0b2ab401861 omap: Introduce OMAP3630 Below patch from Vikram fixes the build break. ouch.. my bad.. thanks for answering my question. I am guessing we need this coz of is_omap3630() translation.. Ack for the patch from me. To me it looks like all the 35x defines need the same treatment. 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] [RFC] omap: 3630: default cpu_is_omap3630 to zero
* Vikram Pandita vikram.pand...@ti.com [091012 14:31]: make default cpu_is_omap3630() return zero Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index da9e8f8..940946e 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423()0 #define cpu_is_omap2430()0 #define cpu_is_omap3430()0 +#define cpu_is_omap3630()0 /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) (omap3_has_sgx()) \ (!omap3_has_iva())) # define cpu_is_omap3530 (cpu_is_omap3430()) +# undef cpu_is_omap3630() # define cpu_is_omap3630() is_omap363x() #endif This undef should be just undef cpu_is_omap3630 instead of cpu_is_omap3630(). 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
[PATCH] omap: Fix 35xx detection (Re: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero)
* Tony Lindgren t...@atomide.com [091013 10:18]: * Vikram Pandita vikram.pand...@ti.com [091012 14:31]: make default cpu_is_omap3630() return zero Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index da9e8f8..940946e 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 +#define cpu_is_omap3630() 0 /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) (omap3_has_sgx()) \ (!omap3_has_iva())) # define cpu_is_omap3530 (cpu_is_omap3430()) +# undef cpu_is_omap3630() # define cpu_is_omap3630() is_omap363x() #endif This undef should be just undef cpu_is_omap3630 instead of cpu_is_omap3630(). Also looking at the 35xx detection code, should it not be like this? omap: Fix 35xx detection Should use instead of Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index 111f29a..a67a95c 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -377,14 +377,14 @@ IS_OMAP_TYPE(3430, 0x3430) # undef cpu_is_omap3525 # undef cpu_is_omap3530 # define cpu_is_omap3430() is_omap3430() -# define cpu_is_omap3503 (cpu_is_omap3430() \ - (!omap3_has_iva()) \ +# define cpu_is_omap3503 (cpu_is_omap3430() \ + (!omap3_has_iva()) \ (!omap3_has_sgx())) -# define cpu_is_omap3515 (cpu_is_omap3430() \ - (omap3_has_iva()) \ +# define cpu_is_omap3515 (cpu_is_omap3430() \ + (omap3_has_iva()) \ (!omap3_has_sgx())) -# define cpu_is_omap3525 (cpu_is_omap3430() \ - (omap3_has_sgx()) \ +# define cpu_is_omap3525 (cpu_is_omap3430() \ + (omap3_has_sgx()) \ (!omap3_has_iva())) # define cpu_is_omap3530 (cpu_is_omap3430()) # undef cpu_is_omap3630
Re: [PATCH] ARM: OMAP3: Add support for the IGEP v2 board (rev B)
* Enric Balletbò i Serra eballe...@gmail.com [091009 09:18]: This patch adds minimal IGEP v2 support. Can you please move the defconfig into a separate patch when you resubmit? It makes it easier for people to read the patch. Regards, 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
[PATCH] omap: Fix cpu_is_omap35xx default defines (Re: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero)
* Tony Lindgren t...@atomide.com [091013 10:15]: * Nishanth Menon menon.nisha...@gmail.com [091013 03:44]: Shilimkar, Santosh said the following on 10/13/2009 05:03 AM: Has anybody tried building latest linux-omap master ? The build is breaking for other OMAP processors. CC arch/arm/mach-omap2/id.o arch/arm/mach-omap2/id.c: In function 'omap3_cpuinfo': arch/arm/mach-omap2/id.c:269: error: implicit declaration of function 'cpu_is_omap3630' make[1]: *** [arch/arm/mach-omap2/id.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 This is because of 0a9b95f21995aa3cdda82ebc6e77b0b2ab401861 omap: Introduce OMAP3630 Below patch from Vikram fixes the build break. ouch.. my bad.. thanks for answering my question. I am guessing we need this coz of is_omap3630() translation.. Ack for the patch from me. To me it looks like all the 35x defines need the same treatment. And here's the patch to do that. omap: Fix cpu_is_omap35xx default defines Otherwise compilation on other processors will fail if these are used in the code. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index a67a95c..770cb60 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -322,6 +322,10 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 #define cpu_is_omap3430() 0 +#define cpu_is_omap3503() 0 +#define cpu_is_omap3515() 0 +#define cpu_is_omap3525() 0 +#define cpu_is_omap3530() 0 #define cpu_is_omap3630() 0 /*
Re: [PATCH v2 1/2] arm: a driver for on-chip ETM and ETB
On Tue, Oct 13, 2009 at 08:06:50PM +0300, Alexander Shishkin wrote: Changes: v2 -- major update: * fixes according to comments from Linus Walleij and Anand Gadiyar * omap3 clock-related stuff moved to platform device And so what about my comments? -- 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 1/2] arm: a driver for on-chip ETM and ETB
On Tue, Oct 13, 2009 at 08:06:50PM +0300, Alexander Shishkin wrote: + emu_clk = *(struct clk **)pdev-dev.platform_data; + if (emu_clk) + clk_enable(emu_clk); + Definitely no way this is going to be acceptable. Never EVER pass clk pointers around like this. And you've ignored the comments about it being a platform driver. Sorry, but the answer to this patch is a firm NAK. Please make it an AMBA primecell driver. Also make it follow the clk API correctly, and claim the three clocks for that primecell *only*. -- 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
[APPLIED] [PATCH] ehci: fix port connect status programming
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: ehci Initial commit ID (Likely to change): b353e8445b1ad54e744b8452573b82c5a220d43e PatchWorks http://patchwork.kernel.org/patch/53393/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b353e8445b1ad54e744b8452573b82c5a220d43e -- 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
[APPLIED] [PATCH] ARM: OMAP: McBSP: Fix incorrect receiver stop in
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 9fd9fe496604919d9d23f284ebd4a84cb2f97066 PatchWorks http://patchwork.kernel.org/patch/53005/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=9fd9fe496604919d9d23f284ebd4a84cb2f97066 -- 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
[APPLIED] omap3: ehci: trivial fix of a debug print
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: ehci Initial commit ID (Likely to change): 8499e54cb25e8d9d16e97e17b0da145d8ed32577 PatchWorks http://patchwork.kernel.org/patch/53179/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=8499e54cb25e8d9d16e97e17b0da145d8ed32577 -- 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] rx51: add wl1251 wlan driver support
Kalle Valo kalle.v...@iki.fi writes: From: Kalle Valo kalle.v...@nokia.com wl1251 is connected to the SPI bus in rx51, add support for this. Signed-off-by: Kalle Valo kalle.v...@nokia.com This is intended for 2.6.33. Also to really work it needs this patch: wl1251: rename spi device to wl1251 http://www.spinics.net/lists/linux-wireless/msg40740.html The patch should be in wireless-testing within next few days and finally it will go to 2.6.33. (Please note that the two patches have no compile time dependency so they can go to mainline via separate trees.) -- Kalle Valo -- 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] OMAP: DSS2: RFBI driver update
Mikkel Christensen m...@ti.com writes:
This patch adds suspend / resume functionality to the RFBI driver along with
missing callback functions needed by OMAP Frame buffer.
Signed-off-by: Mikkel Christensen m...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 76
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 9dd2349..ddfc472 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1181,6 +1181,7 @@ int rfbi_init(void)
/* Enable autoidle and smart-idle */
l = rfbi_read_reg(RFBI_SYSCONFIG);
+ l = ~((0x03 3)|(0x01 0));
Please use symbolic names for these SYSCONFIG values. I realize you inherited
this from other drivers, but it should be fixed.
While you're at it, fixing the others would be nice too. You could do
a cleanup patch before your actual driver update.
Ideally, DSS needs to create an omap_hwmod, but in the meantime you could
use the defines from mach/omap_hwmod.h
l |= (1 0) | (2 3);
rfbi_write_reg(RFBI_SYSCONFIG, l);
@@ -1208,6 +1209,9 @@ static int rfbi_display_update(struct omap_dss_device
*dssdev,
{
int rfbi_module;
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return 0;
+
if (w == 0 || h == 0)
return 0;
@@ -1239,6 +1243,18 @@ static int rfbi_display_enable_te(struct
omap_dss_device *dssdev, bool enable)
return 0;
}
+static enum omap_dss_update_mode rfbi_display_get_update_mode(
+ struct omap_dss_device *dssdev)
+{
+ return OMAP_DSS_UPDATE_MANUAL;
+}
+
+static int rfbi_display_set_update_mode(struct omap_dss_device *dssdev,
+ enum omap_dss_update_mode mode)
+{
+ return 0;
+}
+
static int rfbi_display_enable(struct omap_dss_device *dssdev)
{
int r;
@@ -1269,6 +1285,7 @@ static int rfbi_display_enable(struct omap_dss_device
*dssdev)
rfbi_set_timings(dssdev-phy.rfbi.channel,
dssdev-ctrl.rfbi_timings);
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
if (dssdev-driver-enable) {
r = dssdev-driver-enable(dssdev);
@@ -1288,12 +1305,67 @@ err0:
static void rfbi_display_disable(struct omap_dss_device *dssdev)
{
+ dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
+
dssdev-driver-disable(dssdev);
omap_dispc_unregister_isr(framedone_callback, NULL,
DISPC_IRQ_FRAMEDONE);
omap_dss_stop_device(dssdev);
}
+static int rfbi_display_suspend(struct omap_dss_device *dssdev)
+{
+ unsigned long l;
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ return -EINVAL;
+
+ DSSDBG(rfbi_display_suspend\n);
+
+ if (dssdev-driver-suspend)
+ dssdev-driver-suspend(dssdev);
+
+ dispc_enable_lcd_out(0);
+
+ /* Force idle */
+ rfbi_enable_clocks(1);
+ l = rfbi_read_reg(RFBI_SYSCONFIG);
+ l = ~(0x03 3);
Again, use SYSC_SIDLEMODE_SHIFT, SYSC_SIDLEMODE_MASK.
More of these follow.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM Add sysfs entry for EFuse values
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes:
This patch exports the smartreflex efuse values for all 5 OPPs via
sysfs. This can be useful to track down silicon specific problems.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
These should be exported via debugfs instead of sysfs.
Also, the SR rewrite is underway and will be merged shortly, so I
recommend waiting until that is in place before we add this. Unless
Nishanth wants to add it sooner.
Kevin
---
arch/arm/mach-omap2/smartreflex.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9fa033d..3c506d1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -759,7 +759,24 @@ static struct kobj_attribute sr_vdd2_autocomp = {
.store = omap_sr_vdd2_autocomp_store,
};
+static ssize_t omap_sr_opp1_efuse_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, %08x\n%08x\n%08x\n%08x\n%08x\n, sr1.opp1_nvalue,
+ sr1.opp2_nvalue,
+ sr1.opp3_nvalue,
+ sr1.opp4_nvalue,
+ sr1.opp5_nvalue);
+}
+static struct kobj_attribute sr_efuse = {
+ .attr = {
+ .name = Efuse,
+ .mode = 0444,
+ },
+ .show = omap_sr_opp1_efuse_show,
+};
static int __init omap3_sr_init(void)
{
@@ -807,6 +824,11 @@ static int __init omap3_sr_init(void)
if (ret)
printk(KERN_ERR sysfs_create_file failed: %d\n, ret);
+ ret = sysfs_create_file(power_kobj, sr_efuse.attr);
+ if (ret)
+ printk(KERN_ERR sysfs_create_file failed for OPP data: %d\n,
+ ret);
+
return 0;
}
--
1.6.2.4
--
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] OMAP3 PM export chip IDCODE, Production ID and Die ID
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes:
From: De-Schrijver Peter (Nokia-D/Helsinki) peter.de-schrij...@nokia.com
This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via
sysfs. This can be used to track down silicon specific issues. The info is
exported via sysfs because it should be possible to include this in corematic
dumps.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Please export these via debugfs.
Kevin
---
arch/arm/mach-omap2/id.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2c5e0a3..97670e2 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -70,6 +70,10 @@ EXPORT_SYMBOL(omap_type);
/**/
#define OMAP_TAP_IDCODE 0x0204
+#define OMAP_TAP_PROD_ID_0 0x0208
+#define OMAP_TAP_PROD_ID_1 0x020c
+#define OMAP_TAP_PROD_ID_2 0x0210
+#define OMAP_TAP_PROD_ID_3 0x0214
#define OMAP_TAP_DIE_ID_00x0218
#define OMAP_TAP_DIE_ID_10x021C
#define OMAP_TAP_DIE_ID_20x0220
@@ -77,6 +81,10 @@ EXPORT_SYMBOL(omap_type);
#define read_tap_reg(reg)__raw_readl(tap_base + (reg))
+static ssize_t idcode_show(struct kobject *, struct kobj_attribute *, char
*);
+static struct kobj_attribute idcode_attr = __ATTR(idcode, 0444, idcode_show,
+ NULL);
+
struct omap_id {
u16 hawkeye;/* Silicon type (Hawkeye id) */
u8 dev;/* Device type from production_id reg */
@@ -96,6 +104,23 @@ static struct omap_id omap_ids[] __initdata = {
static void __iomem *tap_base;
static u16 tap_prod_id;
+static ssize_t idcode_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, IDCODE: %08x\nProduction ID: %08x %08x %08x %08x\n
+ Die ID: %08x %08x %08x %08x\n,
+ read_tap_reg(OMAP_TAP_IDCODE),
+ read_tap_reg(OMAP_TAP_PROD_ID_0),
+ read_tap_reg(OMAP_TAP_PROD_ID_1),
+ read_tap_reg(OMAP_TAP_PROD_ID_2),
+ read_tap_reg(OMAP_TAP_PROD_ID_3),
+ read_tap_reg(OMAP_TAP_DIE_ID_0),
+ read_tap_reg(OMAP_TAP_DIE_ID_1),
+ read_tap_reg(OMAP_TAP_DIE_ID_2),
+ read_tap_reg(OMAP_TAP_DIE_ID_3));
+
+}
+
void __init omap24xx_check_revision(void)
{
int i, j;
@@ -259,3 +284,14 @@ void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+void __init export_omapid(void)
+{
+ int error;
+
+ error = sysfs_create_file(power_kobj, idcode_attr.attr);
+ if (error)
+ printk(KERN_ERR sysfs_create_file failed: %d\n, error);
+}
+
+late_initcall(export_omapid);
--
1.6.2.4
--
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] omap-pm: Fixes behaviour of some shared resource framework functions
Dasgupta, Romit ro...@ti.com writes: (Tested on Zoom2). 'omap_pm_dsp_set_min_opp' 'omap_pm_cpu_set_freq' were using their own struct device *. This is a problem because invoking these functions from different clients would result in setting of the resource level as requested by the last caller. Fixes this by introducing a struct device * to the parameter list for these functions. Signed-off-by: Romit Dasgupta ro...@ti.com This looks like the right fix to me. Paul, any comments? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: Fix 35xx detection (Re: [PATCH] [RFC] omap: 3630: default cpu_is_omap3630 to zero)
* Tony Lindgren t...@atomide.com [091013 11:01]: * Tony Lindgren t...@atomide.com [091013 10:18]: * Vikram Pandita vikram.pand...@ti.com [091012 14:31]: make default cpu_is_omap3630() return zero Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/include/mach/cpu.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/cpu.h b/arch/arm/plat-omap/include/mach/cpu.h index da9e8f8..940946e 100644 --- a/arch/arm/plat-omap/include/mach/cpu.h +++ b/arch/arm/plat-omap/include/mach/cpu.h @@ -322,6 +322,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap2423()0 #define cpu_is_omap2430()0 #define cpu_is_omap3430()0 +#define cpu_is_omap3630()0 /* * Whether we have MULTI_OMAP1 or not, we still need to distinguish @@ -386,6 +387,7 @@ IS_OMAP_TYPE(3430, 0x3430) (omap3_has_sgx()) \ (!omap3_has_iva())) # define cpu_is_omap3530 (cpu_is_omap3430()) +# undef cpu_is_omap3630() # define cpu_is_omap3630() is_omap363x() #endif This undef should be just undef cpu_is_omap3630 instead of cpu_is_omap3630(). Also looking at the 35xx detection code, should it not be like this? I've merged all these fixes into the 35xx and 36xx detection patches in omap for-next branch, can you guys please check? Regards, 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] OMAP35x: Add support for 720MHz part
Sanjeev Premi pr...@ti.com writes:
This patch adds support for ARM running at 720MHz part.
The 720MHz capability can be probed run-time by reading the
PRODID.SKUID[3:0] at 0x4830A20C.
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/clock34xx.c |6 ++
arch/arm/mach-omap2/id.c | 11 +++
arch/arm/plat-omap/include/mach/control.h |7 +++
arch/arm/plat-omap/include/mach/cpu.h |2 ++
4 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 489556e..9b56af3 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -1096,6 +1096,12 @@ static int __init omap2_clk_arch_init(void)
if (!mpurate)
return -EINVAL;
+ if ((mpurate == 72000) !omap3_has_720mhz()) {
+ printk(KERN_ERR *** Silicon doesn't support 720MHz\n);
+
+ mpurate = 6; /* Set to highest supported */
+ }
+
This is very platform specific check here. We're not checking for any
other valid mpurate values here. I think we should leave it to the
(forthcoming) OPP layer to to validate the frequency etc.
I recommend just dropping the clock34xx.c changes and posting a patch
which just adds the new speed as a feature.
/* REVISIT: not yet ready for 343x */
if (clk_set_rate(dpll1_ck, mpurate))
printk(KERN_ERR *** Unable to set MPU rate\n);
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index d4d563b..e0b427a 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -79,6 +79,7 @@ EXPORT_SYMBOL(omap_type);
#define OMAP_TAP_DIE_ID_20x0220
#define OMAP_TAP_DIE_ID_30x0224
+
stray whitespace change
#define read_tap_reg(reg)__raw_readl(tap_base + (reg))
struct omap_id {
@@ -180,6 +181,15 @@ void __init omap3_check_features(void)
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
+
+ /*
+ * Does it support 720MHz?
+ */
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
Some comment here that the runtime detection of this feature is only
available on 35xx parts would be useful too.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM restore observability settings after off mode
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes:
This patch restores the observability settings after resuming from off mode.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Thanks, pulling this into PM branch.
Kevin
---
arch/arm/mach-omap2/debobs.c |9 +
arch/arm/mach-omap2/pm34xx.c |4
arch/arm/plat-omap/include/mach/debobs.h |1 +
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/debobs.c b/arch/arm/mach-omap2/debobs.c
index 4fbabef..d25b9a2 100644
--- a/arch/arm/mach-omap2/debobs.c
+++ b/arch/arm/mach-omap2/debobs.c
@@ -190,6 +190,15 @@ static inline int __init _new_debobs_pad(struct
debobs_pad *pad, char *name,
/* Public functions */
+void debobs_restore(void)
+{
+ struct debobs_pad *p = debobs_pads[0];
+ int i;
+
+ for (i = 0; i NUM_OF_DEBOBS_PADS; i++, p++)
+ debobs_set(p-core_obs, p-core_obs.value);
+}
+
void debug_gpio_set(unsigned gpio, int value)
{
if (!debobs_initialized)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 553fe02..20c7ea2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -42,6 +42,7 @@
#include mach/dma.h
#include mach/gpmc.h
#include mach/dma.h
+#include mach/debobs.h
#include asm/tlbflush.h
#include cm.h
@@ -124,6 +125,9 @@ static void omap3_core_restore_context(void)
/* Restore the interrupt controller context */
omap3_intc_restore_context();
omap_dma_global_context_restore();
+ /* restore debobs context */
+ debobs_restore();
+
}
static void omap3_save_secure_ram_context(u32 target_mpu_state)
diff --git a/arch/arm/plat-omap/include/mach/debobs.h
b/arch/arm/plat-omap/include/mach/debobs.h
index 67f765d..1e04bcd 100644
--- a/arch/arm/plat-omap/include/mach/debobs.h
+++ b/arch/arm/plat-omap/include/mach/debobs.h
@@ -3,5 +3,6 @@
void debug_gpio_set(unsigned gpio, int value);
int debug_gpio_get(unsigned gpio);
+void debobs_restore(void);
#endif
--
1.6.2.4
--
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 0/3] OMAP3: PM: Make PRM setup times and CPUidle latencies/threshold board specific
Nayak, Rajendra rna...@ti.com writes: The setup times to be programmed in the PRM module on OMAP (for clksetup, voltsetup etc) are board specific. They depend heavily on the PMIC used and even on different boards with the same PMIC, they vary based on the sleep/wake sequence used, system clock speed et al. The CPUidle latencies and hence thresholds (derived from latencies and Power consumption numbers) and very much dependent on these setup values and hence also need to be board specific. This patchset makes it possible for the PRM setup times and the CPUidle latencies/threshold numbers to be configured from board files, and some default values are used if nothing gets passed from board files. Only the 3430SDP board file is currently been modifed to pass these values and the rest of the 3430 based board's still pass NULL and hence use the default values defined. Hi Rajendra, Thanks for making these changes. I'm very much for the approach you've taken in these patches to make these more configurable. One other comment that would require one more spin: Since we may be moving the OPP tables from board code to SoC common code, let's separate the rate tables from the VC and cpudle parameters. How about an optional omap3_pm_init_vc() for the setup times. and omap3_pm_init_cpuidle() for the CPUidle values. This way only the board files that don't want the defaults have to call them. The other benefit of having optional calls is that we don't have to keep touching every single board file to make these kinds of changes. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] OMAP3: PM: Configure PRM setup times from board files
Rajendra Nayak rna...@ti.com writes:
The setup times to be programmed in the PRM module on OMAP
(for clksetup, voltsetup etc) are board specific.
They depend heavily on the PMIC used and even on different boards
with the same PMIC, they vary based on the sleep/wake
sequence used, system clock speed et al.
This patch makes it possible for these setup values to be
configured from different board files.
Signed-off-by: Rajendra Nayak rna...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2242d23..6f2fb51 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1084,6 +1084,9 @@ int omap3_pm_set_suspend_state(struct powerdomain
*pwrdm, int state)
void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc)
{
+ if (!setup_vc)
+ return;
+
prm_setup.clksetup = setup_vc-clksetup;
prm_setup.voltsetup_time1 = setup_vc-voltsetup_time1;
prm_setup.voltsetup_time2 = setup_vc-voltsetup_time2;
@@ -1285,13 +1288,15 @@ static void __init configure_vc(void)
void omap3_pm_early_init(struct omap_opp *mpu_opps,
struct omap_opp *dsp_opps,
- struct omap_opp *l3_opps)
+ struct omap_opp *l3_opps,
+ struct prm_setup_vc *setup_times)
{
prm_clear_mod_reg_bits(OMAP3430_OFFMODE_POL, OMAP3430_GR_MOD,
OMAP3_PRM_POLCTRL_OFFSET);
configure_vc();
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+ omap3_set_prm_setup_vc(setup_times);
I think there's an ordering problem here since the configure_vc()
which uses the values is called before the setup_vc().
Also, if setup_times is passed as NULL, configure_vc() will be writing
wrong values with undefined results to the VC.
Also, if my proposed omap3_pm_init_vc() approach is taken and it is
optional, some sort of defaults should probably be set.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
* Kevin Hilman khil...@deeprootsystems.com [091013 12:09]:
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes:
From: De-Schrijver Peter (Nokia-D/Helsinki) peter.de-schrij...@nokia.com
This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace
via
sysfs. This can be used to track down silicon specific issues. The info is
exported via sysfs because it should be possible to include this in
corematic
dumps.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Please export these via debugfs.
I don't think we want to export unique chip identifiers by default.
Please search CPU serial number disabled for some earlier handling
of things like these for x86, and see function
squash_the_stupid_serial_number(struct cpuinfo_x86 *c) in
arch/x86/kernel/cpu/common.c :)
Regards,
Tony
Kevin
---
arch/arm/mach-omap2/id.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2c5e0a3..97670e2 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -70,6 +70,10 @@ EXPORT_SYMBOL(omap_type);
/**/
#define OMAP_TAP_IDCODE0x0204
+#define OMAP_TAP_PROD_ID_0 0x0208
+#define OMAP_TAP_PROD_ID_1 0x020c
+#define OMAP_TAP_PROD_ID_2 0x0210
+#define OMAP_TAP_PROD_ID_3 0x0214
#define OMAP_TAP_DIE_ID_0 0x0218
#define OMAP_TAP_DIE_ID_1 0x021C
#define OMAP_TAP_DIE_ID_2 0x0220
@@ -77,6 +81,10 @@ EXPORT_SYMBOL(omap_type);
#define read_tap_reg(reg) __raw_readl(tap_base + (reg))
+static ssize_t idcode_show(struct kobject *, struct kobj_attribute *, char
*);
+static struct kobj_attribute idcode_attr = __ATTR(idcode, 0444,
idcode_show,
+ NULL);
+
struct omap_id {
u16 hawkeye;/* Silicon type (Hawkeye id) */
u8 dev;/* Device type from production_id reg */
@@ -96,6 +104,23 @@ static struct omap_id omap_ids[] __initdata = {
static void __iomem *tap_base;
static u16 tap_prod_id;
+static ssize_t idcode_show(struct kobject *kobj, struct kobj_attribute
*attr,
+ char *buf)
+{
+ return sprintf(buf, IDCODE: %08x\nProduction ID: %08x %08x %08x %08x\n
+ Die ID: %08x %08x %08x %08x\n,
+ read_tap_reg(OMAP_TAP_IDCODE),
+ read_tap_reg(OMAP_TAP_PROD_ID_0),
+ read_tap_reg(OMAP_TAP_PROD_ID_1),
+ read_tap_reg(OMAP_TAP_PROD_ID_2),
+ read_tap_reg(OMAP_TAP_PROD_ID_3),
+ read_tap_reg(OMAP_TAP_DIE_ID_0),
+ read_tap_reg(OMAP_TAP_DIE_ID_1),
+ read_tap_reg(OMAP_TAP_DIE_ID_2),
+ read_tap_reg(OMAP_TAP_DIE_ID_3));
+
+}
+
void __init omap24xx_check_revision(void)
{
int i, j;
@@ -259,3 +284,14 @@ void __init omap2_set_globals_tap(struct omap_globals
*omap2_globals)
else
tap_prod_id = 0x0208;
}
+
+void __init export_omapid(void)
+{
+ int error;
+
+ error = sysfs_create_file(power_kobj, idcode_attr.attr);
+ if (error)
+ printk(KERN_ERR sysfs_create_file failed: %d\n, error);
+}
+
+late_initcall(export_omapid);
--
1.6.2.4
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [091013 12:09]: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: From: De-Schrijver Peter (Nokia-D/Helsinki) peter.de-schrij...@nokia.com This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via sysfs. This can be used to track down silicon specific issues. The info is exported via sysfs because it should be possible to include this in corematic dumps. Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Please export these via debugfs. I don't think we want to export unique chip identifiers by default. Right, which is why I suggested using debugfs, which is something that probably wouldn't be enabled/exported on default production kernels. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Discussion: OMAP: PM: opp table handling
Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx Thanks to all the community members for taking time for this discussion. This will aid upsteaming of 35xx/36xx/44xx in coming future. Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, Rajendra, Benoit, Vikram Problem Statement: OMAP34xx has certain opp requirements (3420/3430/3440) OMAP35xx reuses the opp's from 34xx OMAP36xx has a totally new set of opps OMAP44xx has a totally new set of opps Solution: Align on a common approach to take for the Opp table definitions. Define Separate Tables for each family as follows: Step 1: Go with this approach: 3420(65nm) : new arrays [defer for now] 3430/35xx(65nm) : new arrays ** 3440(65nm) : new arrays [defer for now] 3630(45nm) : new arrays Omap4(45nm) : new arrays * new arrays = (mpu, dsp, l3) ** Check this valid flag. Kevin can take this base on comments http://marc.info/?l=linux-omapm=125512448216071w=2 between 3430/35xx, opp's can be managed with a flag and same table re-used 35xx has requirement for 720Mhz opp Step 2: Kevin suggestion: Define accessor APIs get the OPPs Check Users of accessor API DVFS constraints sysfs debug Define accessor api's eg: index = get_opp(VDD1_OPP1); num = get_max_opp(VDD1); set_opp(index); Step 3: Paul suggestion: VSEL values in opp table should be in terms of voltage Non TWL IC's need this Step4: Paul suggestion: VDD1 VDD2 dependencies for different chips Inter-connect load predictor is absent on omap3 and hence VDD1-vdd2 dependency OMAP4 interconnect loading can be measured from registers Multi-cores dependency Step 5: Paul suggestion: Board files adding OPPs, Modifying OPPs Eg: Pendora passing its own opp Regards, Vikram -- 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: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support.
* kishore kadiyala kishorek.kadiy...@gmail.com [091012 23:54]: Tony, On Fri, Oct 9, 2009 at 11:16 PM, Tony Lindgren t...@atomide.com wrote: * G, Manjunath Kondaiah manj...@ti.com [091008 00:41]: Govind, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Govindraj Sent: Thursday, October 08, 2009 11:44 AM To: Tony Lindgren Cc: Raja, Govindraj; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux-ser...@vger.kernel.org Subject: Re: [PATCHv1 1/3] OMAP UART: Adds omap-serial driver support. On Thu, Oct 8, 2009 at 3:21 AM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [090924 03:29]: From: Govindraj R govindraj.r...@ti.com This patch adds support for OMAP3430-HIGH SPEED UART Controller. Signed-off-by: Govindraj R govindraj.r...@ti.com Reviewed-by: Alan Cox a...@lxorguk.ukuu.org.uk Reviewed-by: Tony Lindgren t...@atomide.com You should only add Reviewed-by if Alan or me have replied with it. So far I've only replied with some comments that have not yet been fixed, so we're few more steps from being Reviewd-by. snip diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 6553833..67a7129 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -1359,6 +1359,53 @@ config SERIAL_OF_PLATFORM Currently, only 8250 compatible ports are supported, but others can easily be added. +config SERIAL_OMAP + bool OMAP serial port support + depends on ARM ARCH_OMAP + select SERIAL_CORE + help + If you have a machine based on an Texas Instruments OMAP CPU you + can enable its onboard serial ports by enabling this option. + +config SERIAL_OMAP_CONSOLE + bool Console on OMAP serial port + depends on SERIAL_OMAP + select SERIAL_CORE_CONSOLE + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can make it the console by answering Y to this option. + + Even if you say Y here, the currently visible virtual console + (/dev/tty0) will still be used as the system console by default, but + you can alter that using a kernel command line option such as + console=ttyS0. (Try man bootparam or see the documentation of + your boot loader (lilo or loadlin) about how to pass options to the + kernel at boot time.) + +config SERIAL_OMAP_DMA_UART1 + bool UART1 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 1 by answering + to this option. + +config SERIAL_OMAP_DMA_UART2 + bool UART2 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 2 by answering + to this option. + +config SERIAL_OMAP_DMA_UART3 + bool UART3 DMA support + depends on SERIAL_OMAP + help + If you have enabled the serial port on the Texas Instruments OMAP + CPU you can enable the DMA transfer on UART 3 by answering + to this option. + config SERIAL_OF_PLATFORM_NWPSERIAL tristate NWP serial port driver depends on PPC_OF PPC_DCR There's absolutely no need for having Kconfig options for the DMA support. Please pass that in platform_data from the board-*.c files. This is the third time I'm commenting on the same issue! What's the point of posting these patches for review if the issues don't get solved? The omap-serial uart driver is designed to work either in interrupt mode or in DMA mode, We have provided this option so that one can select interrupt mode or DMA mode based on the uart usage, if somebody is using uart as console then interrupt mode will do, else if used with bluetooth which does huge data transfer then DMA mode can be selected. Don't you think this should be a configurable option using kconfig rather than passing as platform data? Nope. I think it should be platform_data and should be possible to override vith a kernel cmdline option. That's because we support compiling in and booting many boards the same kernel binary. if used as platform data then one has to modify platform data to switch between the interrupt and DMA mode. How about set some kernel cmdline options if you want to override the default settings? Using cmdline options, will make specific UART switch dynamically between Non-DMA and DMA mode which is not handled in the driver. Switching between dma
RE: Discussion: OMAP: PM: opp table handling
-Original Message- From: Pandita, Vikram Sent: Wednesday, October 14, 2009 1:53 AM To: linux-omap@vger.kernel.org Cc: Kevin Hilman; Menon, Nishanth; Nataraju, Kiran; Premi, Sanjeev; Shilimkar, Santosh; Chikkature Rajashekar, Madhusudhan; Tony Lindgren; Sawant, Anand; Joshi, Rhishi; Giles, Rick; Sripathy, Vishwanath; Paul Walmsley; Cousson, Benoit; Nayak, Rajendra Subject: Discussion: OMAP: PM: opp table handling Proposals for OPP table handling for OMAP34xx/35xx/36xx/44xx Thanks to all the community members for taking time for this discussion. This will aid upsteaming of 35xx/36xx/44xx in coming future. Attendees: Kevin Hilman, Paul, Nishant M, Santosh, Madhu, Benoit, Rajendra, Benoit, Vikram [sp] Adding myself to attendees ~sanjeev Problem Statement: OMAP34xx has certain opp requirements (3420/3430/3440) OMAP35xx reuses the opp's from 34xx OMAP36xx has a totally new set of opps OMAP44xx has a totally new set of opps Solution: Align on a common approach to take for the Opp table definitions. Define Separate Tables for each family as follows: Step 1: Go with this approach: 3420(65nm) : new arrays [defer for now] 3430/35xx(65nm) : new arrays ** 3440(65nm) : new arrays [defer for now] 3630(45nm) : new arrays Omap4(45nm) : new arrays * new arrays = (mpu, dsp, l3) ** Check this valid flag. Kevin can take this base on comments http://marc.info/?l=linux-omapm=125512448216071w=2 between 3430/35xx, opp's can be managed with a flag and same table re-used 35xx has requirement for 720Mhz opp Step 2: Kevin suggestion: Define accessor APIs get the OPPs Check Users of accessor API DVFS constraints sysfs debug Define accessor api's eg: index = get_opp(VDD1_OPP1); num = get_max_opp(VDD1); set_opp(index); Step 3: Paul suggestion: VSEL values in opp table should be in terms of voltage Non TWL IC's need this Step4: Paul suggestion: VDD1 VDD2 dependencies for different chips Inter-connect load predictor is absent on omap3 and hence VDD1-vdd2 dependency OMAP4 interconnect loading can be measured from registers Multi-cores dependency Step 5: Paul suggestion: Board files adding OPPs, Modifying OPPs Eg: Pendora passing its own opp Regards, Vikram -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3 PM restore observability settings after off mode
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: This patch restores the observability settings after resuming from off mode. Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com I decided not to pull this one into PM branch, because... diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 553fe02..20c7ea2 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -42,6 +42,7 @@ #include mach/dma.h #include mach/gpmc.h #include mach/dma.h +#include mach/debobs.h #include asm/tlbflush.h #include cm.h @@ -124,6 +125,9 @@ static void omap3_core_restore_context(void) /* Restore the interrupt controller context */ omap3_intc_restore_context(); omap_dma_global_context_restore(); + /* restore debobs context */ + debobs_restore(); + of compile failure when CONFIG_PM_DEBOBS is not enabled. And, debobs should now go upstream indepenent of PM branch. When I posted my PM debug series for the last merge window, I originally included the debobs series. It recieved some comments on the list that need to be addressed before this can go upstream. Now that the main PM debug stuff is in mainline, this series has no more dependencies on the PM branch. I think you should address the the comments/questions raised on the list[1,2] and resubmit as a series against mainline. A quick test shows that the current set of 3 debobs patches currently in the PM branch rebase easily against omap/master so should be easy to rework for upstream acceptance. Thanks, Kevin [1] http://marc.info/?l=linux-omapm=125049645823777w=2 [2] http://marc.info/?l=linux-omapm=125049651623911w=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: FEATURES prints
Nishanth Menon n...@ti.com writes:
Folks,
With the addition of FEATURES in l-o, the following prints:
- l2cache : Y
- iva : Y
- sgx : Y
- neon : Y
- isp : Y
comes up on SDP3430 - now that we will introduce half a dozen
features here and there, we will soon clutter this up. we should
introduce a sysfs entry + remove the above noise..
Like Nishanth, I don't like the multi-line noise here. The patch
below results in a single line output like this instead
OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp )
Not sure why we need to dump features that are not there, but if that
s considered important, maybe prefixing each feature with a '+' or '-'
would still allow this to be collapsed into a single line.
Even with this, I think adding the display of these features into an
OMAP-specific section of /proc/cpuinfo would be even better.
Comments?
Kevin
commit 24f7422bad970cea2ed71d71e3994eeed70f175f
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Tue Oct 13 14:42:00 2009 -0700
OMAP3: collapse chip feature prints to single line
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 71d5568..b90fcf1 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -249,11 +249,8 @@ void __init omap3_check_revision(void)
}
#define OMAP3_SHOW_FEATURE(feat) \
- if (omap3_has_ ##feat()) { \
- pr_info ( - #feat : Y); \
- } else {\
- pr_info ( - #feat : N); \
- }
+ if (omap3_has_ ##feat())\
+ printk (#feat ); \
void __init omap3_cpuinfo(void)
{
@@ -307,13 +304,14 @@ void __init omap3_cpuinfo(void)
/*
* Print verbose information
*/
- pr_info(OMAP%s ES%s\n, cpu_name, cpu_rev);
+ pr_info(OMAP%s ES%s (, cpu_name, cpu_rev);
OMAP3_SHOW_FEATURE(l2cache);
OMAP3_SHOW_FEATURE(iva);
OMAP3_SHOW_FEATURE(sgx);
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
+ printk()\n);
}
/*
--
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: FEATURES prints
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, October 14, 2009 3:17 AM
To: Menon, Nishanth
Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: Re: FEATURES prints
Nishanth Menon n...@ti.com writes:
Folks,
With the addition of FEATURES in l-o, the following prints:
- l2cache : Y
- iva : Y
- sgx : Y
- neon : Y
- isp : Y
comes up on SDP3430 - now that we will introduce half a dozen
features here and there, we will soon clutter this up. we should
introduce a sysfs entry + remove the above noise..
Like Nishanth, I don't like the multi-line noise here. The patch
below results in a single line output like this instead
OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp )
Not sure why we need to dump features that are not there, but if that
s considered important, maybe prefixing each feature with a '+' or '-'
would still allow this to be collapsed into a single line.
Even with this, I think adding the display of these features into an
OMAP-specific section of /proc/cpuinfo would be even better.
[sp] Single line prints look good. We can also add details in cpuinfo.
~sanjeev
Comments?
Kevin
commit 24f7422bad970cea2ed71d71e3994eeed70f175f
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Tue Oct 13 14:42:00 2009 -0700
OMAP3: collapse chip feature prints to single line
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 71d5568..b90fcf1 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -249,11 +249,8 @@ void __init omap3_check_revision(void)
}
#define OMAP3_SHOW_FEATURE(feat) \
- if (omap3_has_ ##feat()) { \
- pr_info ( - #feat : Y); \
- } else {\
- pr_info ( - #feat : N); \
- }
+ if (omap3_has_ ##feat())\
+ printk (#feat ); \
void __init omap3_cpuinfo(void)
{
@@ -307,13 +304,14 @@ void __init omap3_cpuinfo(void)
/*
* Print verbose information
*/
- pr_info(OMAP%s ES%s\n, cpu_name, cpu_rev);
+ pr_info(OMAP%s ES%s (, cpu_name, cpu_rev);
OMAP3_SHOW_FEATURE(l2cache);
OMAP3_SHOW_FEATURE(iva);
OMAP3_SHOW_FEATURE(sgx);
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
+ printk()\n);
}
/*
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: SRF: Fix latency resource target value computations
Rajendra Nayak rna...@ti.com writes:
The Shared resource framework currently considers the highest requested
level for a resource as the target level to be set. This works for OPP
and frequency resources as they are used to model performace based
constraints. However for latency based constraints/resources the least
requested
level should be the one considered for the target level. This patch fixes
the issue by having an additional flag to identify the different types
of resources. Currently supported ones are Performace resources and
latency resources.
Signed-off-by: Rajendra Nayak rna...@ti.com
Thanks, pulling into PM branch.
Kevin
---
arch/arm/mach-omap2/resource34xx.c |4 ++--
arch/arm/mach-omap2/resource34xx.h | 16
arch/arm/plat-omap/include/mach/resource.h |9 -
arch/arm/plat-omap/resource.c | 20 ++--
4 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 491e1dc..e1a540e 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -41,7 +41,7 @@
void init_latency(struct shared_resource *resp)
{
resp-no_of_users = 0;
- resp-curr_level = RES_DEFAULTLEVEL;
+ resp-curr_level = RES_LATENCY_DEFAULTLEVEL;
*((u8 *)resp-resource_data) = 0;
return;
}
@@ -65,7 +65,7 @@ int set_latency(struct shared_resource *resp, u32 latency)
resp-curr_level = latency;
pm_qos_req_added = resp-resource_data;
- if (latency == RES_DEFAULTLEVEL)
+ if (latency == RES_LATENCY_DEFAULTLEVEL)
/* No more users left, remove the pm_qos_req if present */
if (*pm_qos_req_added) {
pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,
diff --git a/arch/arm/mach-omap2/resource34xx.h
b/arch/arm/mach-omap2/resource34xx.h
index 3c70eef..918a76c 100644
--- a/arch/arm/mach-omap2/resource34xx.h
+++ b/arch/arm/mach-omap2/resource34xx.h
@@ -49,6 +49,7 @@ static struct shared_resource_ops lat_res_ops = {
static struct shared_resource mpu_latency = {
.name = mpu_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = mpu_qos_req_added,
.ops= lat_res_ops,
};
@@ -56,6 +57,7 @@ static struct shared_resource mpu_latency = {
static struct shared_resource core_latency = {
.name = core_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = core_qos_req_added,
.ops= lat_res_ops,
};
@@ -91,6 +93,7 @@ static struct shared_resource_ops pd_lat_res_ops = {
static struct shared_resource core_pwrdm_latency = {
.name = core_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = core_qos_req_added,
.ops= lat_res_ops,
};
@@ -106,6 +109,7 @@ static struct pd_latency_db iva2_pwrdm_lat_db = {
static struct shared_resource iva2_pwrdm_latency = {
.name = iva2_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = iva2_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -129,6 +133,7 @@ static struct pd_latency_db sgx_pwrdm_lat_db = {
static struct shared_resource gfx_pwrdm_latency = {
.name = gfx_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1),
+ .flags = RES_TYPE_LATENCY,
.resource_data = gfx_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -136,6 +141,7 @@ static struct shared_resource gfx_pwrdm_latency = {
static struct shared_resource sgx_pwrdm_latency = {
.name = sgx_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
+ .flags = RES_TYPE_LATENCY,
.resource_data = sgx_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -151,6 +157,7 @@ static struct pd_latency_db dss_pwrdm_lat_db = {
static struct shared_resource dss_pwrdm_latency = {
.name = dss_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = dss_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -166,6 +173,7 @@ static struct pd_latency_db cam_pwrdm_lat_db = {
static struct shared_resource cam_pwrdm_latency = {
.name = cam_pwrdm_latency,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = RES_TYPE_LATENCY,
.resource_data = cam_pwrdm_lat_db,
.ops= pd_lat_res_ops,
};
@@ -181,6 +189,7 @@ static struct pd_latency_db
RE: [PATCH RESEND] I2C: OMAP: Add missing wakeup events
Hello Aaro! -Original Message- From: Aaro Koskinen [mailto:aaro.koski...@nokia.com] Sent: Tuesday, October 13, 2009 4:52 AM To: Sonasath, Moiz Cc: ben-li...@fluff.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org Subject: Re: [PATCH RESEND] I2C: OMAP: Add missing wakeup events Hello, Sonasath, Moiz wrote: From: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com Include wake up events for receiver overflow and transmitter underflow in OMAP_I2C_WE_REG configuration. Also fix a small typo. Signed-off-by: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com --- drivers/i2c/busses/i2c-omap.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c- omap.c index 827da08..34ea9ed 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -92,8 +92,10 @@ #define OMAP_I2C_STAT_AL (1 0)/* Arbitration lost int ena */ /* I2C WE wakeup enable register */ -#define OMAP_I2C_WE_XDR_WE(1 14) /* TX drain wakup */ +#define OMAP_I2C_WE_XDR_WE(1 14) /* TX drain wakeup */ #define OMAP_I2C_WE_RDR_WE(1 13) /* RX drain wakeup */ +#define OMAP_I2C_WE_ROVR_WE (1 11) /* RX overflow wakeup */ +#define OMAP_I2C_WE_XUDF_WE (1 10) /* TX underflow wakeup */ These bits are not documented in OMAP3430, they are reserved. How can they be used? Hmm, that's a valid point. I will have to check if I can find more info on the background of this patch. AFAIK, these bits have been introduced in OMAP3630 as it has a new IP block for I2C. But these bits are reserved bits for OMAP3430. A. -- 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] rtc: make rtc-omap driver ioremap its register space
On Wed, Sep 16, 2009 at 05:04:58PM -0700, Mark A. Greer wrote: From: Mark A. Greer mgr...@mvista.com The rtc-omap driver currently assumes that the rtc's registers are at a fixed address and already mapped into virtual memory space. Remove those assumptions so the same driver can be used for similar devices that reside at different physical addresses (e.g., TI's DA8xx/OMAP-L13x SoC's). Also allow the possibility for the timer and alarm interrupts to use the same IRQ. Signed-off-by: Mark A. Greer mgr...@mvista.com CC: David Brownell davi...@pacbell.net --- Ping? Just wondering if this patch was noticed. FYI, the following were added by subsequent emails: Acked-by: David Brownell dbrown...@users.sourceforge.net Acked-by: Kevin Hilman khil...@deeprootsystems.com Acked-by: Tony Lindgren t...@atomide.com Thanks, Mark -- -- 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: [rtc-linux] Re: [PATCH v2] rtc: make rtc-omap driver ioremap its register space
On Tue, 13 Oct 2009 16:00:23 -0700 Mark A. Greer mgr...@mvista.com wrote: Ping? Just wondering if this patch was noticed. noticed. it's in the queue for the next submission set, which means after upstream merges all of current pending patches (which are now in -mm) . -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- 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 0/6] omap fixes for v2.6.32-rc4
Hi all, Here are few omap fixes for review. Regards, Tony --- Aaro Koskinen (1): omap: RX-51: Drop I2C-1 speed to 2200 Anuj Aggarwal (1): omap: SDMA: Fixing bug in omap_dma_set_global_params() Jarkko Nikula (1): omap: McBSP: Fix incorrect receiver stop in omap_mcbsp_stop Roel Kluin (1): omap: Fix Unlikely(x) y Sanjeev Premi (1): omap: CONFIG_ISP1301_OMAP redefined in Beagle defconfig Teerth Reddy (1): omap: Initialization of SDRC params on Zoom2 arch/arm/configs/omap3_beagle_defconfig |1 - arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom2.c|4 +++- arch/arm/plat-omap/dma.c | 15 +-- arch/arm/plat-omap/gpio.c|2 +- arch/arm/plat-omap/mcbsp.c |2 +- 6 files changed, 15 insertions(+), 11 deletions(-) -- Signature -- 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/6] omap: Fix Unlikely(x) y
From: Roel Kluin roel.kl...@gmail.com
The closing parenthesis was not on the right location.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 71ebd7f..7c345b7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -373,7 +373,7 @@ static inline int gpio_valid(int gpio)
static int check_gpio(int gpio)
{
- if (unlikely(gpio_valid(gpio)) 0) {
+ if (unlikely(gpio_valid(gpio) 0)) {
printk(KERN_ERR omap-gpio: invalid GPIO %d\n, gpio);
dump_stack();
return -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 2/6] omap: CONFIG_ISP1301_OMAP redefined in Beagle defconfig
From: Sanjeev Premi pr...@ti.com The symbol CONFIG_ISP1301_OMAP was defined twice in the defconfig. This was causing the warning: arch/arm/configs/omap3_beagle_defconfig:972:warning: override: reassigning to symbol ISP1301_OMAP Signed-off-by: Sanjeev Premi pr...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap3_beagle_defconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap3_beagle_defconfig b/arch/arm/configs/omap3_beagle_defconfig index 357d402..b3c8cce 100644 --- a/arch/arm/configs/omap3_beagle_defconfig +++ b/arch/arm/configs/omap3_beagle_defconfig @@ -969,7 +969,6 @@ CONFIG_USB_ETH_RNDIS=y # CONFIG_USB_OTG_UTILS=y # CONFIG_USB_GPIO_VBUS is not set -# CONFIG_ISP1301_OMAP is not set CONFIG_TWL4030_USB=y # CONFIG_NOP_USB_XCEIV is not set CONFIG_MMC=y -- 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/6] omap: SDMA: Fixing bug in omap_dma_set_global_params()
From: Anuj Aggarwal anuj.aggar...@ti.com Argument tparams was not being used to program global register GCR.HI_THREAD_RESERVED. This patch fixes the same. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/dma.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index fd3154a..0eb676d 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -829,10 +829,10 @@ EXPORT_SYMBOL(omap_free_dma); * * @param arb_rate * @param max_fifo_depth - * @param tparams - Number of thereads to reserve : DMA_THREAD_RESERVE_NORM - * DMA_THREAD_RESERVE_ONET - * DMA_THREAD_RESERVE_TWOT - * DMA_THREAD_RESERVE_THREET + * @param tparams - Number of threads to reserve : DMA_THREAD_RESERVE_NORM + *DMA_THREAD_RESERVE_ONET + *DMA_THREAD_RESERVE_TWOT + *DMA_THREAD_RESERVE_THREET */ void omap_dma_set_global_params(int arb_rate, int max_fifo_depth, int tparams) @@ -844,11 +844,14 @@ omap_dma_set_global_params(int arb_rate, int max_fifo_depth, int tparams) return; } + if (max_fifo_depth == 0) + max_fifo_depth = 1; if (arb_rate == 0) arb_rate = 1; - reg = (arb_rate 0xff) 16; - reg |= (0xff max_fifo_depth); + reg = 0xff max_fifo_depth; + reg |= (0x3 tparams) 12; + reg |= (arb_rate 0xff) 16; dma_write(reg, GCR); } -- 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/6] omap: RX-51: Drop I2C-1 speed to 2200
From: Aaro Koskinen aaro.koski...@nokia.com The I2C-1 bus frequency on RX-51 should be 2.2 MHz. The speed is limited by TWL5030/GAIA; a higher speed could lead to errors on the interface. The maximum speed depends on the system clock for GAIA: 2.2 MHz (if 19.2 MHz), 2.4 MHz (26 MHz) or 2.9 MHz (38.4 MHz). Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index c1af532..2b0eb1b 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -444,7 +444,7 @@ static int __init rx51_i2c_init(void) rx51_twldata.vaux3 = rx51_vaux3_cam; rx51_twldata.vmmc2 = rx51_vmmc2; } - omap_register_i2c_bus(1, 2600, rx51_peripherals_i2c_board_info_1, + omap_register_i2c_bus(1, 2200, rx51_peripherals_i2c_board_info_1, ARRAY_SIZE(rx51_peripherals_i2c_board_info_1)); omap_register_i2c_bus(2, 100, NULL, 0); omap_register_i2c_bus(3, 400, NULL, 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
[PATCH 5/6] omap: Initialization of SDRC params on Zoom2
From: Teerth Reddy tee...@ti.com
This patch initializes the correct SDRC settings required
for DVFS on Zoom2.
Signed-off-by: Teerth Reddy tee...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-zoom2.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index b7b3220..fd3369d 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -25,6 +25,7 @@
#include mach/keypad.h
#include mmc-twl4030.h
+#include sdram-micron-mt46h32m32lf-6.h
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -213,7 +214,8 @@ static void __init omap_zoom2_init_irq(void)
{
omap_board_config = zoom2_config;
omap_board_config_size = ARRAY_SIZE(zoom2_config);
- omap2_init_common_hw(NULL, NULL);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
+mt46h32m32lf6_sdrc_params);
omap_init_irq();
omap_gpio_init();
}
--
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 6/6] omap: McBSP: Fix incorrect receiver stop in omap_mcbsp_stop
From: Jarkko Nikula jhnik...@gmail.com
This small typo written by author causes that McBSP receiver is disabled on
OMAP2430 and OMAP3430 even if only transmitter is stopped. This was noted
with ALSA SoC where simultaneous recording halted if playback was stopped
first.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 88ac976..e664b91 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -595,7 +595,7 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
rx = 1;
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
w = OMAP_MCBSP_READ(io_base, RCCR);
- w |= (tx ? RDISABLE : 0);
+ w |= (rx ? RDISABLE : 0);
OMAP_MCBSP_WRITE(io_base, RCCR, w);
}
w = OMAP_MCBSP_READ(io_base, SPCR1);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] OMAP1: Massive clean up of omap730/omap850 code
* Tony Lindgren t...@atomide.com [091007 10:57]: * Alistair Buxton a.j.bux...@gmail.com [090928 14:19]: 2009/9/23 Tony Lindgren t...@atomide.com: Thanks, looks good to me. Can you please rebase against the mainline 2.6.32-rc1 once it gets tagged? Then please keep your branch around until it all gets merged into the mainline tree. There should not be any need for you to rebase it, but I may need to pull it several times as I rebase the various upstream queues after each -rc. Done. ZMC has now reviewed it, and I've mirrored it to a proper hosted server too: git://robotfuzz.com/linwizard-kernel.git branch: omap7xx-fortony-rc1 Confirmed booting to a shell with the addition of the patches in branch omap7xx-test2 - but those patches aren't ready to go as we still need workarounds for a serial bug in order to know that we have booted. Can you please rebase on v2.6.32-rc3 and let me know when you have your new branch ready? There's one merge conflict merging that branch from -rc1, I've kind of tweaked my scripts to work around that but it still needs manual merging ;) Thanks for doing that, I don't think there any more need to rebase your set. And I finally got my merge scripts sorted out to rebuild the linux-omap tree cleanly. One more request: Can you please repost your whole series one more time to linux-arm-ker...@lists.infradead.org with linux-omap@vger.kernel.org list Cc'd? This is to make sure everybody who wants to review these patches gets a chance. And that way I don't have to repost your series for review since the series will get merged directly from your tree anyways :) Regards, 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: FEATURES prints
Sanjeev, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Wednesday, October 14, 2009 3:26 AM To: Kevin Hilman; Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: RE: FEATURES prints -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, October 14, 2009 3:17 AM To: Menon, Nishanth Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: FEATURES prints Nishanth Menon n...@ti.com writes: Folks, With the addition of FEATURES in l-o, the following prints: - l2cache : Y - iva : Y - sgx : Y - neon : Y - isp : Y comes up on SDP3430 - now that we will introduce half a dozen features here and there, we will soon clutter this up. we should introduce a sysfs entry + remove the above noise.. Like Nishanth, I don't like the multi-line noise here. The patch below results in a single line output like this instead OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) Not sure why we need to dump features that are not there, but if that s considered important, maybe prefixing each feature with a '+' or '-' would still allow this to be collapsed into a single line. Even with this, I think adding the display of these features into an OMAP-specific section of /proc/cpuinfo would be even better. [sp] Single line prints look good. We can also add details in cpuinfo. If you are ok with proc entry then we don't even need this noise at all in the boot. It's just that adding proc entries is discouraged to some extent. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
