Re: [PATCH 3/4] ARM: mvebu: remove the workaround imprecise abort fault handler
Lucas, On Wed, 14 Oct 2015 16:48:32 +0200, Lucas Stach wrote: > This is not needed anymore. Handling a potentially pending imprecise external > abort left behind by the bootloader is now done in a slightly safer way inside > the common ARM startup code. > > Signed-off-by: Lucas Stach <l.st...@pengutronix.de> > --- > arch/arm/mach-mvebu/board-v7.c | 35 --- > 1 file changed, 35 deletions(-) Reviewed-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com> In fact this code is anyway no longer needed, since this workaround was only needed for the Armada 375 Z1 stepping, which we no longer support in mainline anyway. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] ARM: orion: use clkdev_create()
); - orion_clkdev_add(NULL, MV64XXX_I2C_CTLR_NAME .0, tclk); + clkdev_create(tclk, NULL, %s, orion_spi.0); + clkdev_create(tclk, NULL, %s, orion_spi.1); + clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .0); + clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .1); + clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .2); + clkdev_create(tclk, NULL, %s, MV643XX_ETH_NAME .3); + clkdev_create(tclk, NULL, %s, orion_wdt); + clkdev_create(tclk, NULL, %s, MV64XXX_I2C_CTLR_NAME .0); } /* Fill in the resources structure and link it into the platform diff --git a/arch/arm/plat-orion/include/plat/common.h b/arch/arm/plat-orion/include/plat/common.h index d9a24f6..7a06b6b 100644 --- a/arch/arm/plat-orion/include/plat/common.h +++ b/arch/arm/plat-orion/include/plat/common.h @@ -106,8 +106,5 @@ void __init orion_crypto_init(unsigned long mapbase, unsigned long sram_size, unsigned long irq); -void __init orion_clkdev_add(const char *con_id, const char *dev_id, -struct clk *clk); - void __init orion_clkdev_init(struct clk *tclk); #endif -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Dear Gupta, Pekon, On Thu, 5 Dec 2013 19:02:22 +, Gupta, Pekon wrote: From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. I had some reservations in doing so.. (as mentioned in previous email also [2]) I would rather like to understand long term benefits of such implementation. The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Isn't handling hardware constraints properly not a sufficient motivation for doing something? Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Dear Brian Norris, On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Isn't handling hardware constraints properly not a sufficient motivation for doing something? I'm not convinced your hardware constraints are reasonable or generally useful. But I could be convinced otherwise. They may not be reasonable, but they exist :) Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Solution [a] is both ugly and impractical. Solution [b] is only a little ugly but quite practical (you could flesh out a better user-space ECC library, then combine it with nanddump/nandwrite --noecc). Rewriting both the MTD and NAND layers is not exactly practical and may still yield something ugly. It's not practical because it wasn't thought like this originally, but technically speaking, being able to use a different ECC scheme for different areas of the NAND makes a lot of sense. That being said, it is true that having a good and reusable userspace tool to write data with arbitrary ECC schemes would be useful to workaround this situation. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Javier Martinez Canillas, On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 525e6d9..9043e97 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -59,7 +59,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; Tested this with 3.13-rc1, and it somewhat works, but causes some ECC error messages: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 10.423736] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 10.444671] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 10.472290] jffs2: mtd-read(0x100 bytes from 0x4) returned ECC error [ 10.480743] jffs2: mtd-read(0x100 bytes from 0x6) returned ECC error [ 10.489013] jffs2: mtd-read(0x100 bytes from 0x8) returned ECC error [ 10.497283] jffs2: mtd-read(0x100 bytes from 0xa) returned ECC error [ 10.505126] jffs2: mtd-read(0x100 bytes from 0xc) returned ECC error [ 10.513458] jffs2: mtd-read(0x100 bytes from 0xe) returned ECC error [ 10.521667] jffs2: mtd-read(0x100 bytes from 0x10) returned ECC error [ 10.529968] jffs2: mtd-read(0x100 bytes from 0x12) returned ECC error [ 10.538269] jffs2: mtd-read(0x100 bytes from 0x14) returned ECC error [ 10.546295] jffs2: mtd-read(0x100 bytes from 0x16) returned ECC error [ 10.554534] jffs2: mtd-read(0x100 bytes from 0x18) returned ECC error [ 10.563323] jffs2: mtd-read(0x100 bytes from 0x1a) returned ECC error [ 10.571685] jffs2: mtd-read(0x100 bytes from 0x1c) returned ECC error [ 10.579986] jffs2: mtd-read(0x100 bytes from 0x1e) returned ECC error [ 10.588287] jffs2: mtd-read(0x100 bytes from 0x20) returned ECC error [ 10.596313] jffs2: mtd-read(0x100 bytes from 0x22) returned ECC error [ 10.604522] jffs2: mtd-read(0x100 bytes from 0x24) returned ECC error [ 10.613037] jffs2: mtd-read(0x100 bytes from 0x26) returned ECC error [ 10.621307] jffs2: mtd-read(0x100 bytes from 0x28) returned ECC error [ 10.629608] jffs2: mtd-read(0x100 bytes from 0x2a) returned ECC error [ 10.637908] jffs2: mtd-read(0x100 bytes from 0x2c) returned ECC error [ 10.645843] jffs2: mtd-read(0x100 bytes from 0x2e) returned ECC error [ 10.654113] jffs2: notice: (851) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # # # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK This is with a JFFS2 image flashed after doing nandecc sw in U-Boot. Just a note that this binding property got renamed for v3.13 on commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc Author: Pekon Gupta pe...@ti.com Date: Thu Oct 24 18:20:18 2013 +0530 mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes so users using current v3.12 kernel or older should use ti,nand-ecc-opt = sw; instead. However, this works perfectly fine, with the same JFFS2 image, flashed in the same way in U-Boot: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 19.789306] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 19.810455] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 19.850860] jffs2: notice: (802) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Gupta, Pekon, On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote: A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). The crucial point here is that the interaction between the bootloader and the kernel. The use case I have is that I'm flashing a filesystem image from the bootloader, and mounting it from the kernel. Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in legacy mode (no Device Tree) works fine. Using the same 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, because the kernel disagrees with the bootloader on the ECC scheme to use. So I'm not saying that Hamming is better than BCH, certainly not. I'm just saying that changing ECC scheme in the kernel without looking at the more global picture of what support the bootloaders are offering is not nice. At least, the bootloader should provide a command, or option, to be able to use an ECC scheme that is compatible with what the kernel expects. The current result is that booting a mainline kernel with DT on existing bootloaders simply breaks existing configurations. Pekon, the old ti,nand-ecc-opt = sw should be replaced by ti,nand-ecc-opt = ham1 ? Should be the same ? In that case, why this different behavior ? In addition, please use HAM1 ecc-scheme on mainline u-boot also to flash. (following patches were accepted by domain maintainer 'Scott Woods'). http://lists.denx.de/pipermail/u-boot/2013-November/167548.html So, Kernel ham1 and u-boot ham1 should be in sync.. Once above is clean, you may like to pull another set of patches below (these are kernel equivalent of driver optimization for u-boot driver) http://lists.denx.de/pipermail/u-boot/2013-November/167445.html Also, for JFFS2, please erase the flash using -j option. '-j' option adds a clean marker to erased blocks. As said, I'm erasing/flashing from U-Boot, so flash_eraseall options are not really useful here :) Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Enric Balletbo Serra, On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote: Thanks for the explanations to all. Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Tom Rini, On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Of course, ideally, we should also be able to tell the kernel about the ECC scheme on a per-partition basis. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Which as I was saying, is a bit of shame. There is technically nothing that makes the ECC scheme something that needs to be applied globally on the entire flash. And we see real practical cases where being able to specify a different ECC scheme per partition would make sense: when the ROM code uses a weaker ECC scheme than the one used for most other partitions. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 3/9] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
Dear Jyri Sarha, On Tue, 19 Nov 2013 14:12:23 +0200, Jyri Sarha wrote: -- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx +- compatible : ti,da830-evm-audio : for DM365/DA8xx/OMAPL1x/AM33xx + ti,am33xx-beaglebone-black : for Beaglebone-black HDMI audio The compatible string namespace is a global namespace, and in the compatible string you've chosen, there's nothing that makes it specific to audio. ti,am33xx-beaglebone-black could be used for any other device, or even for the board as a whole, no? Maybe you need to suffix it with -audio, like the existing compatible string for audio in this driver. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap2: fix AM33xx hwmod infos for UART2
The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 01d8f32..9113251 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2006,6 +2006,13 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
},
};
+/* uart2 */
+static struct omap_hwmod_dma_info uart2_edma_reqs[] = {
+ { .name = tx, .dma_req = 28, },
+ { .name = rx, .dma_req = 29, },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_irq_info am33xx_uart2_irqs[] = {
{ .irq = 73 + OMAP_INTC_START, },
{ .irq = -1 },
@@ -2016,7 +2023,7 @@ static struct omap_hwmod am33xx_uart2_hwmod = {
.class = uart_class,
.clkdm_name = l4ls_clkdm,
.mpu_irqs = am33xx_uart2_irqs,
- .sdma_reqs = uart1_edma_reqs,
+ .sdma_reqs = uart2_edma_reqs,
.main_clk = dpll_per_m2_div4_ck,
.prcm = {
.omap4 = {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote: But it appears that shmobile prefer to get all resources using bus notifiers. So we need to form some kind of consensus ... or live with the fact that different systems do it different ways. Which will explode the day we need to use a driver on two systems, each using the other approach :-) I much prefer having drivers explicitly manage all their resources, which would mean that pinctrl calls need to be done on probe() and, if necessary, during suspend()/resume(). Using bus notifiers for that is quite a hack IMHO. Agreed. Just like drivers do their ioremap, request_irq and others, they should also request their pin resources using the pinctrl API. Hiding this behind a bus notifier is not nice. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, 23 Oct 2012 12:45:33 +0200, Linus Walleij wrote: Hm so I have had this idea of runtime PM core helping out with pins, so I could add something like pm_pins_fetch() pm_pins_default() pm_pins_idle() pm_pins_sleep() So if one is using the pin states defined in linux/pinctrl/pinctrl-state.h then the PM core can help out in keeping track of the pins and states, and the driver will just tell the PM core what to do and when. Would this fit the bill for everyone's code consolidation needs? It would sure work for us... That surely would work but is kind of non-obvious when reading a driver's code: that's the problem with bus notifier, they do things a bit behind your back without you noticing. Having the driver request its own pinctrl state, and switch between states upon suspend/resume is a lot more explicit, IMO. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Kevin, On Thu, 04 Oct 2012 16:06:27 -0700, Kevin Hilman wrote: It seems they are exactly the same, unless my eyes missed something, of course. The example I gave was only for the UART3 RX, you should dump the UART3 TX pins as. Using the omap_mux debugfs, you can see all of the potential pins where uart3_tx can be routed: Well, UART3 TX seems to be working fine. Do RX and TX have mutual influence in terms of pin muxing? Yes, that tells me where UART3 is expected to be mux'd on the board. So you can ignore the dss_data* and husb_data* files above and focus on uart3* So to summarize, in /sys/kernel/debug/omap_mux, just do a 'cat uart3*' on a working and non-working board and see if there are any differences. 3.2 (working) name: uart3_cts_rctx.uart3_cts_rctx (0x4800219a/0x16a = 0x0108), b h18, t NA mode: OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0 signals: uart3_cts_rctx | NA | NA | NA | gpio_163 | NA | NA | safe_mode name: uart3_rts_sd.uart3_rts_sd (0x4800219c/0x16c = 0x), b h19, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_rts_sd | NA | NA | NA | gpio_164 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: uart3_tx_irtx.uart3_tx_irtx (0x480021a0/0x170 = 0x), b h21, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode 3.6 (not working) name: uart3_cts_rctx.uart3_cts_rctx (0x4800219a/0x16a = 0x0108), b h18, t NA mode: OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0 signals: uart3_cts_rctx | NA | NA | NA | gpio_163 | NA | NA | safe_mode name: uart3_rts_sd.uart3_rts_sd (0x4800219c/0x16c = 0x), b h19, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_rts_sd | NA | NA | NA | gpio_164 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: uart3_tx_irtx.uart3_tx_irtx (0x480021a0/0x170 = 0x), b h21, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Fri, 5 Oct 2012 09:32:07 +0200, Javier Martinez Canillas wrote: As Enric said, u-boot has SPL and NAND support for IGEP since v2012.10-rc1. I just tried kernel a 3.6 with u-boot v2012.10-rc2 and it works for me. Ok, I'll try this out. But I agree that the kernel shouldn't do any assumptions about the bootloader setting correctly the omap mux. Could you please share your bootloader that makes the kernel to fail (or your IGEP NAND patches on top of u-boot U-boot 2011.12) so I can reproduce the issue and try to fix it? Ok, I'm using the X-Loader from git://git.igep.es/pub/scm/x-loader.git, tag v1.4.4-3, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/x-loader-1.4.4-3-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. In terms of U-Boot, I use U-Boot 2011.12, on top of which I apply http://git.free-electrons.com/training-materials/plain/lab-data/sysdev/u-boot/u-boot-2011.12-igep-nand-support.patch to add support for the NAND-based IGEPv2 rev6. To make things easier if you don't need to rebuild those, I've put online pre-built binaries of X-Loader and U-Boot I'm using: http://free-electrons.com/~thomas/pub/igep-serial-problem/. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Kevin,
Reviving an old thread.
On Fri, 04 May 2012 16:46:32 -0700, Kevin Hilman wrote:
Thomas Petazzoni thomas.petazz...@free-electrons.com writes:
I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3.
With 3.2 omap2plus_defconfig, the system boots fine and have a
working shell on ttyO2. On either 3.3, 3.4-rc5 or
arm-soc/for-next from Arnd, the system boots all the way up to
showing the shell prompt, but I can't type any character, as if
UART RX was broken.
On v3.4-rc, can you see if reverting
bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect?
That patch had some unfortunate side effects, but I haven't seen
the problem you see, so I'm not sure if it's related.
Reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 is a broken
solution like you mentioned. But if it helps, then the proper fix
is to add muxing to board-*.c files for the uart pins and use
omap_serial_init_port for each uart instead of omap_serial_init.
That should fix the wake-up issues too.
I agree on the final solution, but just wanted to see if the missing
mux (and thus disabled runtime PM) is what's causing the problem.
FWIW, I tried the recently released 3.6 kernel on this platform
(IGEPv2, OMAP3-based), and I still see the same problem. Upon Tony's
suggestion, I tried to add some code in board-igep0020.c similar to the
one in board-n8x0.c to do the appropriate UART2 muxing, but it doesn't
seem to improve the situation. I did the following change (note that I
tried with both .name = uart2_rx_irrx.uart2_rx_irrx and .name =
uart3_rx_irrx.uart3_rx_irrx). On this board, the console is on ttyO2.
This is with the plain omap2plus_defconfig, so CONFIG_OMAP_MUX is
enabled.
Any idea of things to try? This board has been broken since 3.2, so I'd
like to get it fixed at some point :-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 2821448..568f13e 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -558,6 +558,43 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(MCSPI1_CS2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+ {
+ .name = uart2_rx_irrx.uart2_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_MUX_MODE0,
+ .idle = OMAP_MUX_MODE3/* Mux as GPIO for idle */
+ },
+};
+
+static inline void board_serial_init(void)
+{
+ struct omap_board_data bdata;
+
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ bdata.id = 0;
+ omap_serial_init_port(bdata, NULL);
+
+ bdata.id = 1;
+ omap_serial_init_port(bdata, NULL);
+
+ bdata.id = 2;
+ bdata.pads = serial2_pads;
+ bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
+ omap_serial_init_port(bdata, NULL);
+}
+
+#else
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init();
+}
+
#endif
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
@@ -621,7 +658,7 @@ static void __init igep_init(void)
/* Register I2C busses and drivers */
igep_i2c_init();
platform_add_devices(igep_devices, ARRAY_SIZE(igep_devices));
- omap_serial_init();
+ board_serial_init();
omap_sdrc_init(m65kam_sdrc_params,
m65kam_sdrc_params);
usb_musb_init(NULL);
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Kevin, On Thu, 04 Oct 2012 10:18:04 -0700, Kevin Hilman wrote: Can you dump the UART mux registers on a working kernel and compare them to the broken one? (Table 7-4 in the 34xx public TRM[1] will list all the mux registers.) Maybe the bootloader code for that board will shed some light as well since it will be setting the muxing too. If the console uart is ttyO2 (UART3 in TI docs), then the interesting registers will be any of the padconf registers in that table that contain 'uart3'. e.g. for UART3 RX: CONTROL_PADCONF_DSS_DATA4 (mode 2) CONTROL_PADCONF_UART3_RTS_SD (mode 0) CONTROL_PADCONF_HSUSB0_DATA1 (mode 2) omap_mux has some useful debugfs output under debugfs/omap_mux. For example: # cd /sys/kernel/debug/omap_mux # cat dss_data4 # cat uart3_rx_irrx # cat hsusb0_data1 would provide a very useful comparison between a working kernel and a non-working one. It seems they are exactly the same, unless my eyes missed something, of course. Note: the 3.6 kernel is booted with the patch I posted earlier, but it doesn't make it work any better. Here is what I have : 3.6 (not working) = name: dss_data4.dss_data4 (0x480020e4/0x0b4 = 0x), b ag24, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: dss_data4 | NA | uart3_rx_irrx | NA | gpio_74 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: hsusb0_data1.hsusb0_data1 (0x480021ac/0x17c = 0x0100), b u28, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: hsusb0_data1 | NA | uart3_rx_irrx | NA | gpio_130 | NA | NA | safe_mode Complete boot log: http://code.bulix.org/76m2kn-82254?raw 3.2 (working) = name: dss_data4.dss_data4 (0x480020e4/0x0b4 = 0x), b ag24, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0 signals: dss_data4 | NA | uart3_rx_irrx | NA | gpio_74 | NA | NA | safe_mode name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode name: hsusb0_data1.hsusb0_data1 (0x480021ac/0x17c = 0x0100), b u28, t NA mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0 signals: hsusb0_data1 | NA | uart3_rx_irrx | NA | gpio_130 | NA | NA | safe_mode Complete boot log: http://code.bulix.org/kh0v71-82255?raw Regarding the bootloader, I am not 100% sure what are the relevant bits, but the UART3 related muxing for this board, done in U-Boot seems to be: MUX_VAL(CP(UART3_TX_IRTX), (IDIS | PTD | DIS | M0)) /* UART3_TX */\ MUX_VAL(CP(UART3_RX_IRRX), (IEN | PTD | DIS | M0)) /* UART3_RX */\ Does this helps? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
On Thu, 4 Oct 2012 22:30:58 +0200, Enric Balletbò i Serra wrote: I recently tested kernel 3.6-rc5 and worked for me. Let me check tomorrow kernel 3.6. Which u-boot version are you using? 2011.12 + a few patches to make the NAND of the IGEPv2 rev6 work. Let me try to build a recent U-Boot (which now includes the SPL for the IGEP) and see if it improves the situation. However, I believe that the rule is that the kernel shouldn't depend too much on initialization done by the bootloader, so it still seems like an issue to me. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Hello, I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3. With 3.2 omap2plus_defconfig, the system boots fine and have a working shell on ttyO2. On either 3.3, 3.4-rc5 or arm-soc/for-next from Arnd, the system boots all the way up to showing the shell prompt, but I can't type any character, as if UART RX was broken. All the kernel versions have been tested with identical bootloaders and identical setup, so there is apparently no misconfiguration of my serial terminal program regarding flow control or things like that. I have seen that there has been multiple changes to the OMAP UART code between 3.2 and 3.3, but a git bisect attempt has failed miserably due to numerous build issues in the OMAP code at various points of the bisection. I am attaching the boot logs for 3.2 (working), 3.3 (not working) and 3.4-rc5 (not working) in case this is of any help. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.2.0-2-g7892880 (thomas@skate) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #4 SMP Fri May 4 14:24:20 CEST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: IGEP v2 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/200/600 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c103d000 s10112 r8192 d14464 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: init=/bin/sh mtdparts=omap2-nand.0:6m(boot),6m(rootfs) rootfstype=jffs2 root=/dev/mtdblock1 console=ttyO2,115200 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 507236k/507236k available, 17052k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc060b388 (6157 kB) [0.00] .init : 0xc060c000 - 0xc0658780 ( 306 kB) [0.00] .data : 0xc065a000 - 0xc06e0970 ( 539 kB) [0.00].bss : 0xc06e0994 - 0xc0c34f20 (5458 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:410 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001068] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720) [0.085876] pid_max: default: 32768 minimum: 301 [0.086822] Security Framework initialized [0.087188] Mount-cache hash table entries: 512 [0.092681] CPU: Testing write buffer coherency: ok [0.093994] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [0.096527] Brought up 1 CPUs [0.096527] SMP: Total of 1 processors activated (597.64 BogoMIPS). [0.101379] devtmpfs: initialized [0.125549] print_constraints: dummy: [0.128540] NET: Registered protocol family 16 [0.130126] GPMC revision 5.0 [0.148162] OMAP GPIO hardware version 2.5 [0.171112] omap_mux_init: Add partition: #1: core, flags: 0 [0.174163] IGEP2: Hardware Revision C (B-NON compatible) [0.188110] Reprogramming SDRC clock to 2 Hz [0.188140] dpll3_m2_clk rate change failed: -22 [0.189605] IGEP: initializing NAND memory device [0.208648] hw-breakpoint: debug architecture 0x4 unsupported. [0.243743
Re: [PATCH 01/11] OMAP2+: Add SoC specific map_io functions
Hello Benoit, Le Fri, 23 Sep 2011 22:23:09 +0200, Benoit Cousson b-cous...@ti.com a écrit : Add SoC specific map_io function to be used by the generic DT board file. This is an intermediate step before having some generic DT aware map_io function. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Do you know if some progress has been made on having a generic DT aware map_io function, or is the per-SoC -map_io() function still the recommended way of handling SoC having different requirements of static mappings at boot time? Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] Add infrastructure for conditional code and data sections
On Thu, 23 Dec 2010 14:31:46 +0200 (EET)
Aaro Koskinen aaro.koski...@nokia.com wrote:
No not yet, will take a look after we're done with this upcoming
merge window..
I also think the idea is good, and this should be maybe posted to wider
audience than just linux-omap.
Yes, definitely. As the proof of concept implementation was
demonstrating usage on OMAP, I wanted to have some early comments of
a few kernel developers before going to a wider audience.
Yeah I don't know how much non-init data we have for each board-*.c
file. Maybe there is not much for each machine.
I took a quick look at omap2plus_defconfig kernel, and non-init text/data
for 29 boards takes 85K. If we would page align those memory consumption
would increase during init to 29*8=232K, but after other boards are
freed we would eventually save 85-8=77K.
Thanks for those numbers. 77K is nice, but is not really a huge saving.
Under mach-omap2, another big consumer is clock data which takes also
around 80 K, while e.g. on 2420 only 14 K is needed.
My patch 3/6 (which didn't make it to the list, since it was probably
too large) already marked some OMAP2 clock data.
Unfortunately, I haven't found a nice way of putting strings into a
separate sections. For example:
static struct foobar __omap2 foo = {
.name = blabla,
.id = 12,
};
The struct foobar goes into the OMAP2-specific section (8 bytes), but
the blabla string (6 bytes) remains in the global .rodata section,
without anyway from removing it. The only solution I see so far would
be :
static char __omap2 foo_name[] = blabla;
static struct foobar __omap2 foo = {
.name = foo_name,
.id = 12,
};
but it's really unpleasant.
Other ideas ?
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] Add infrastructure for conditional code and data sections
On Wed, 22 Dec 2010 10:28:41 -0800 Tony Lindgren t...@atomide.com wrote: Nice to see that the idea is welcome. Did you had a look at the implementation in patch 1/6 ? No not yet, will take a look after we're done with this upcoming merge window.. Great, thanks. Ideally the new sections would be arch/arm generic sections and not omap specific. I could see ARMv6 and ARMv7 sections being one way to group them, but that does not help to drop omap3 specific data on omap4. The mechanism is architecture independent, not OMAP-specific or even ARM-specific (the only architecture-dependent part is the modification of the kernel linker script, but it's trivial to adapt to other arches). You can put as many sections as you want, you just need to declare some macros: #define __something_data cond_data_section(something) #define __something_text cond_text_section(something) and then mark whatever you want with __something_data or __something_text. It will then be part of separate sections, that are page-aligned so that they can independently be freed. For the moment, the API allows to tell which sections you want to *free*, but I think I should turn it into an API that allows to tell which sections you want to *keep*. This way, if you have sections for 100 machines and you boot on a given machine, you only need to say I'm using this section. At the end of the kernel boot process, all sections that have not been marked as useful would be removed. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] omap: add macros to mark SoC-specific data/code
From: Thomas Petazzoni t-petazz...@ti.com Signed-off-by: Thomas Petazzoni t-petazz...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 3fd8b40..31f806e 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -31,6 +31,7 @@ #define __ASM_ARCH_OMAP_CPU_H #include linux/bitops.h +#include linux/condsections.h #include plat/multi.h /* @@ -470,4 +471,14 @@ OMAP3_HAS_FEATURE(isp, ISP) OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) +/* + * OMAP section markers + */ +#define __omap2_data cond_data_section(omap2) +#define __omap3_data cond_data_section(omap3) +#define __omap4_data cond_data_section(omap4) +#define __omap2_text cond_text_section(omap2) +#define __omap3_text cond_text_section(omap3) +#define __omap4_text cond_text_section(omap4) + #endif -- 1.7.0.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
[RFC] Infrastructure for dynamic removal of code and data sections
Hello, Here is a patchset that proposes a mechanism to get rid at runtime of unused data and code sections, depending on the SoC we are currently running on. WARNING: This is only a proof-of-concept, there are many known issues. The sole purpose of this patch is to get some feedback on whether the idea is useful or not, and whether it's worth cleaning up the remaining issues. It is for the moment presented on the linux-omap@ list only, as the usage is only demonstrated on OMAP, but the core infrastructure is mostly architecture-independent (except a modification in the architecture-specific linker script). A trend in the kernel support for SoC is to build a single kernel that works accross a wide range of SoC inside a SoC family, or even in the future SoC of different families. While this is very interesting to reduce the number of kernel images needed to support a large number of hardware platforms, it allows means that the kernel image size is increasing. Portions of code and data are specific to a given SoC (clock structures, hwmod structures on OMAP, etc.) and only the portion relevant for the current SoC the kernel is running on is actually useful. The rest of the code and data remains in memory forever. While __init and __initdata can solve some of those cases, it is not necessarly easy to use, since the code/data that is actually useful needs to be copied so that it is kept after the init memory cleanup. Therefore, we introduce an infrastructure that allows to put code and data into specific sections, called conditional sections. All those sections are compiled into the final kernel image, but at runtime, by calling a function, we can get rid of the unused sections. The first patch introduces the generic infrastructure. See the description of this patch for details on how it is implemented. The second patch introduces macros to mark code/data to be OMAP2/3/4-specific. The third, fourth and fith patches mark some clock and hwmod data as being OMAP2, OMAP3 or OMAP4 specific. Unfortunately, I haven't found a way of marking the strings inside the structures to be part of a particular section, so the memory used for those strings is not reclaimed. The sixth patch modifies the BeagleBoard board code to call the function that frees the OMAP2 and OMAP4 specific code and data. At boot, what I have is: Freeing unused conditional section: omap2 data 0xc09a9000 - 0c09b2000 (sz=36864) Freeing unused conditional section: omap4 data 0xc09ba000 - 0c09c2000 (sz=32768) Which means that 68 KB of memory has been freed. Obviously, I haven't marked all code/data, so higher gains can be expected. Regards, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] omap3: beagle: get rid of unused omap2/omap4 specific code/data
From: Thomas Petazzoni tpetazz...@ti.com Using the new condsections infrastructure, get rid of the unused code/data for OMAP2 and OMAP4 when booting on BeagleBoard OMAP3. Signed-off-by: Thomas Petazzoni t-petazz...@ti.com --- arch/arm/mach-omap2/board-omap3beagle.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 14f4224..900964a 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -23,6 +23,7 @@ #include linux/gpio.h #include linux/input.h #include linux/gpio_keys.h +#include linux/condsections.h #include linux/mtd/mtd.h #include linux/mtd/partitions.h @@ -581,6 +582,9 @@ static void __init omap3_beagle_init(void) omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT); beagle_display_init(); + + free_unused_cond_section(omap2); + free_unused_cond_section(omap4); } MACHINE_START(OMAP3_BEAGLE, OMAP3 Beagle Board) -- 1.7.0.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
Re: [PATCH 6/6] omap3: beagle: get rid of unused omap2/omap4 specific code/data
On Tue, 21 Dec 2010 13:15:23 -0600 Menon, Nishanth n...@ti.com wrote: Potentially a dumb idea: given that silicon wont change after boot, cant we make it independent of the board file - I mean some common file with cpu_is check and free of conditional sections accordingly? Yes, definitely. The current location in the BeagleBoard board code was just to make a quick test. It belongs somewhere in the CPU detection code. Thanks for your feedback! Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] Add infrastructure for conditional code and data sections
On Tue, 21 Dec 2010 11:27:35 -0800 Tony Lindgren t...@atomide.com wrote: Therefore, we introduce an infrastructure that allows to put code and data into specific sections, called conditional sections. All those sections are compiled into the final kernel image, but at runtime, by calling a function, we can get rid of the unused sections. Great, something is certainly needed to free the unused memory. Nice to see that the idea is welcome. Did you had a look at the implementation in patch 1/6 ? For example, on OMAP, you can declare data as being omap2 specific this way: static int __omap2_data foobar; Then, in the board code of an OMAP3 or OMAP4 platform, you can call: free_unused_cond_section(omap2); Sounds like this could be done after the cpu detection automatically? Yes, it definitely should. I don't know what the section limitations are, but it would be nice to have a separate section for each machine.. Then we could just free_unused_machines() during the init.. :) I don't think there are any specific limitations, so we can just create as many section as we want. However, in order to be able to free each section independently from another, I have to page align all those conditional sections. This means that having one section for only a tiny amount of data is going to waste space instead of saving space. So the conditional section should gather a sufficiently large amount of data ( 4 KB) to actually be valuable. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: prcm: switch to a chained IRQ handler mechanism
From: Thomas Petazzoni t-petazz...@ti.com
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.
arch/arm/mach-omap2/prcm.c implements the chained interrupt mechanism
itself, with individual PRCM events for OMAP3 and OMAP4 being
described in arch/arm/mach-omap2/prcm3xxx.c and
arch/arm/mach-omap2/prcm4xxx.c respectively. At initialization time,
the set of PRCM events is filtered against the SoC on which we are
running, keeping only the ones that are actually useful. All the logic
is written to be generic with regard to OMAP3/OMAP4, even though OMAP3
has single PRCM event registers and OMAP4 has two PRCM event
registers.
The wakeup and I/O PRCM events are now handled as two separate
interrupts, and their handler is registered with IRQF_NO_SUSPEND,
otherwise the IRQ gets disabled during suspend, which prevents resume.
Patch tested on OMAP3 BeagleBoard, with a suspend/resume cycle to both
retention and off mode. No test done on OMAP4.
Signed-off-by: Thomas Petazzoni t-petazz...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile |4 +
arch/arm/mach-omap2/pm34xx.c | 104 ++
arch/arm/mach-omap2/pm44xx.c |8 ++
arch/arm/mach-omap2/prcm.c | 186
arch/arm/mach-omap2/prcm3xxx.c | 117
arch/arm/mach-omap2/prcm4xxx.c | 146 +
arch/arm/plat-omap/include/plat/irqs.h |9 ++-
arch/arm/plat-omap/include/plat/prcm.h | 45
8 files changed, 548 insertions(+), 71 deletions(-)
create mode 100644 arch/arm/mach-omap2/prcm3xxx.c
create mode 100644 arch/arm/mach-omap2/prcm4xxx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7805545..a227f4d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -36,6 +36,10 @@ AFLAGS_sram242x.o:=-Wa,-march=armv6
AFLAGS_sram243x.o :=-Wa,-march=armv6
AFLAGS_sram34xx.o :=-Wa,-march=armv7-a
+# PRCM
+obj-$(CONFIG_ARCH_OMAP3)+= prcm3xxx.o
+obj-$(CONFIG_ARCH_OMAP4)+= prcm4xxx.o
+
# Pin multiplexing
obj-$(CONFIG_ARCH_OMAP2420)+= mux2420.o
obj-$(CONFIG_ARCH_OMAP2430)+= mux2430.o
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 1c716c8..ec1b7f6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -236,7 +236,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
}
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
{
int c;
@@ -248,64 +248,10 @@ static int _prcm_int_handle_wakeup(void)
c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
}
- return c;
-}
-
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
-{
- u32 irqenable_mpu, irqstatus_mpu;
- int c = 0;
-
- irqenable_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
- irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- do {
- if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
-OMAP3430_IO_ST_MASK)) {
- c = _prcm_int_handle_wakeup();
-
- /*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
-*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
Re: [PATCH v2] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no wakeup sources
] _prcm_int_handle_wakeup 377 : 0 [ 508.508819] prcm_irq_unmask 377 [ 508.508850] prcm_irq_handler pending=0x1 [ 508.508850] calling irq 368 [ 508.508880] prcm_irq_mask 368 [ 508.508880] prcm_irq_ack 368 [ 508.508911] _prcm_int_handle_wakeup 368 : 0 [ 508.508911] prcm_irq_unmask 368 [ 508.508941] prcm_irq_handler pending=0x0 [ 508.510955] PM: early resume of devices complete after 1.953 msecs [ 508.804077] PM: resume of devices complete after 292.754 msecs [ 508.930664] Restarting tasks ... done. / # echo 1 /debug/pm_debug/enable_off_mode / # echo mem /sys/power/state [ 515.526428] PM: Syncing filesystems ... done. [ 515.531677] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 515.559417] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 515.591400] Suspending console(s) (use no_console_suspend to debug) [ 515.714813] PM: suspend of devices complete after 112.121 msecs [ 515.718627] PM: late suspend of devices complete after 3.753 msecs [ 515.718658] Disabling non-boot CPUs ... [ 516.187805] Successfully put all powerdomains to target state [ 516.187988] prcm_irq_handler pending=0x200 [ 516.188018] calling irq 377 [ 516.188018] prcm_irq_mask 377 [ 516.188049] prcm_irq_ack 377 [ 516.188079] _prcm_int_handle_wakeup 377 : 1 [ 516.188079] prcm_irq_unmask 377 [ 516.188110] prcm_irq_handler pending=0x200 [ 516.188110] calling irq 377 [ 516.188140] prcm_irq_mask 377 [ 516.188140] prcm_irq_ack 377 [ 516.188171] _prcm_int_handle_wakeup 377 : 0 [ 516.188201] prcm_irq_unmask 377 [ 516.188201] prcm_irq_handler pending=0x0 [ 516.190338] PM: early resume of devices complete after 2.075 msecs [ 516.483612] PM: resume of devices complete after 292.999 msecs [ 516.570281] Restarting tasks ... done. -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Hello Mark,
On Fri, 3 Sep 2010 19:20:52 +0100
Mark Brown broo...@opensource.wolfsonmicro.com wrote:
Essentially all that needs doing is that when regulator_set_voltage() is
called instead of merging with the machine constraints and applying the
setting immediately we store the constraints that are specified in the
consumer then iterate over all enabled consumers applying all the
constraints that they've set in addition to those from the machine.
This results in a configuration which is the lowest possible voltage
which satisfies all the constraints that have been supplied and for
supplies with only one consumer it gives the same behaviour as we have
currently.
I went ahead and implemented this (without looking at previous existing
code since I couldn't find it). What about the following patch ?
I've tested it with a dummy platform driver and a dummy regulator
driver, making sure that the correct voltage gets set at the regulator
level. My testing had a device requesting a voltage [83, 833000]
and another device [822000, 831000]. Without the patch, as the
regulator_set_voltage() gets called for the second device last, the
voltage is set at 822000 which is not acceptable for the first device.
With the patch, the 83 voltage is kept, since it satisfies both
consumers. If the second device had [822000,828000] has its voltage
requirements, then regulator_set_voltage() would fail with -EINVAL since
it is not possible to find a voltage level that satisfies both
consumers.
If you're ok with it, I'll submit it the proper way.
Thanks,
Thomas
From fa0edfc1a4428aead4502fcba248084c1194da53 Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni t-petazz...@ti.com
Date: Wed, 24 Nov 2010 10:34:35 +0100
Subject: [PATCH] regulator: Take into account the requirements of all consumers
Extend the regulator_set_voltage() function to take into account the
voltage requirements of all consumers of the regulator being changed,
in order to set the voltage to the minimum voltage acceptable to all
consumers. The existing behaviour was that the latest
regulator_set_voltage() call would win over previous
regulator_set_voltage() calls even if setting the voltage to a
non-acceptable level from other consumers.
Signed-off-by: Thomas Petazzoni t-petazz...@ti.com
---
drivers/regulator/core.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f1d10c9..12a1cae 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -132,6 +132,28 @@ static int regulator_check_voltage(struct regulator_dev
*rdev,
return 0;
}
+/* Make sure we select a voltage that suits the needs of all
+ * regulator consumers
+ */
+static int regulator_check_consumers(struct regulator_dev *rdev,
+int *min_uV, int *max_uV)
+{
+ struct regulator *regulator;
+
+ list_for_each_entry(regulator, rdev-consumer_list, list)
+ {
+ if (*max_uV regulator-max_uV)
+ *max_uV = regulator-max_uV;
+ if (*min_uV regulator-min_uV)
+ *min_uV = regulator-min_uV;
+ }
+
+ if (*min_uV *max_uV)
+ return -EINVAL;
+
+ return 0;
+}
+
/* current constraint check */
static int regulator_check_current_limit(struct regulator_dev *rdev,
int *min_uA, int *max_uA)
@@ -1636,6 +1658,11 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
goto out;
regulator-min_uV = min_uV;
regulator-max_uV = max_uV;
+
+ ret = regulator_check_consumers(rdev, min_uV, max_uV);
+ if (ret 0)
+ goto out;
+
ret = rdev-desc-ops-set_voltage(rdev, min_uV, max_uV);
out:
--
1.7.0.4
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Hello Mark, On Fri, 3 Sep 2010 19:20:52 +0100 Mark Brown broo...@opensource.wolfsonmicro.com wrote: re-add? was it there at one point and removed? Any pointers to the old code? It was present in the pre-merge regulator API which you can find in the bowels of: git://opensource.wolfsonmicro.com/linux-2.6-audioplus but was removed to simplify review during the merge. It's fairly simple to do, it's just that there's been no demand. I'm finally taking the time to look more closely into this. I've tried to find the original implementation of multi-consumer tracking, but couldn't find it in the different branches of the linux-2.6-audioplus. Do you have a more specific pointer ? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
On Tue, 16 Nov 2010 08:16:07 -0800 Kevin Hilman khil...@deeprootsystems.com wrote: Yes, I'm not a big fan of the init function called multiple times either, but I really want to minimize what board files have to do. Historically, we tend to add all the init functions to every board file, and this is getting cumbersome to understand and maintain. What we need is for common code to take care of sensible defaults for all boards, and then only boards with non-default behavior have to have custom code. The other way is to have the board code register its customization into the OPP subsystem, and then when the OPP subsystem is initialized, it takes those customizations into account. But in that specific case, it's not clear how those customizations could easily be expressed, so maybe that multiple call strategy is the simplest solution. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: prcm: switch to a chained IRQ handler mechanism
From: Thomas Petazzoni t-petazz...@ti.com
Until this patch, the PRCM interrupt was handled through a normal,
single interrupt handler. However, the PRCM notifies various types of
events, which might be of interest to different drivers. In
preparation for the usage of the PRCM interrupt by those drivers, we
switch to a chained interrupt handler model, so that each driver will
be able to register its own interrupt handler on a particular
interrupt line, depending on the event the driver is interested in.
Signed-off-by: Thomas Petazzoni t-petazz...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 191 +---
arch/arm/plat-omap/include/plat/irqs.h | 38 ++-
2 files changed, 161 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d068348..77a9a49 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/delay.h
#include linux/slab.h
+#include linux/irq.h
#include plat/sram.h
#include plat/clockdomain.h
@@ -243,7 +244,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
}
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
{
int c;
@@ -255,64 +256,10 @@ static int _prcm_int_handle_wakeup(void)
c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
}
- return c;
-}
-
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
-{
- u32 irqenable_mpu, irqstatus_mpu;
- int c = 0;
-
- irqenable_mpu = prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
- irqstatus_mpu = prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- do {
- if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
-OMAP3430_IO_ST_MASK)) {
- c = _prcm_int_handle_wakeup();
-
- /*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
-*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
- } else {
- /* XXX we need to expand our PRCM interrupt handler */
- WARN(1, prcm: WARNING: PRCM interrupt received, but
-no code to handle it (%08x)\n, irqstatus_mpu);
- }
-
- prm_write_mod_reg(irqstatus_mpu, OCP_MOD,
- OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-
- irqstatus_mpu = prm_read_mod_reg(OCP_MOD,
- OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
- irqstatus_mpu = irqenable_mpu;
-
- } while (irqstatus_mpu);
-
- return IRQ_HANDLED;
+ if (c)
+ return IRQ_HANDLED;
+ else
+ return IRQ_NONE;
}
static void restore_control_register(u32 val)
@@ -998,11 +945,104 @@ void omap_push_sram_idle(void)
save_secure_ram_context_sz);
}
+static void prcm_irq_ack(unsigned irq)
+{
+ int prcm_irq = irq - OMAP_PRCM_IRQ_BASE;
+
+ prm_write_mod_reg((1 prcm_irq), OCP_MOD,
+ OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+}
+
+static void prcm_irq_mask(unsigned irq)
+{
+ int prcm_irq = irq - OMAP_PRCM_IRQ_BASE;
+
+ prm_rmw_mod_reg_bits((1 prcm_irq), 0, OCP_MOD,
+OMAP3_PRM_IRQENABLE_MPU_OFFSET);
+}
+
+static void prcm_irq_unmask(unsigned irq)
+{
+ int prcm_irq = irq - OMAP_PRCM_IRQ_BASE;
+
+ prm_rmw_mod_reg_bits(0, (1 prcm_irq), OCP_MOD,
+OMAP3_PRM_IRQENABLE_MPU_OFFSET
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello, On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon n...@ti.com wrote: + /* + * Allow multiple calls, but initialize only if not already initalized Minor: s/initalized/initialized/. + * even if the previous call failed, coz, no reason we'd succeed again + */ + if (omap_table_init) + return 0; + omap_table_init = 1; Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1). Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello, On Tue, 16 Nov 2010 05:54:50 -0600 Nishanth Menon n...@ti.com wrote: Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1). Yes, it is needed. The intent here is different. See the documentation that I put along with this patch - At times, board files may need to do customization to opps - like enable 1GHz on that platform alone - it can do it *only if* the defaults are registered, following which it can call opp_enable. when device_initcall follows this at a later point, it is still valid. Ah, right, I didn't catch that omapX_init_opp() could be called first from the board init function, and then later on as a device_initcall() callback. But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to omapX_init_opp() would be needed as a device_initcall() callback. Or, add a mechanism that allows the board file to register its customizations, that are later taken into account by the omapX_init_opp() function. Maybe it's just a matter of personal taste, but I really don't like this kind of let's call this function once, do some stuff, then call it again, since it'll know that it shouldn't do anything. btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok fine, system can still survive without cpufreq, no need to stop system operations because of that. I don't see why replacing: + if (omap_table_init) + return 0; + omap_table_init = 1; by BUG_ON(omap_table_init == 1); omap_table_init = 1; would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()). Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello, On Tue, 16 Nov 2010 07:10:36 -0600 Nishanth Menon n...@ti.com wrote: I feel you may have misunderstood the code, we DONOT oblige all boards to *have* to call omapX_init_opp. It is a device_initcall - so for the boards that dont call it, device_initcall will trigger and initialzie it. the hooks for the customization of the OPPs is in OPP layer itself. This is exactly what I have understood. the need we satisfy is this: if you need to support two sets of boards: a) boards that are happy with the defaults - most of the boards - dont do anything in the board file. (device_init_call with auto register the defaults) b) boards that need customization - these guys need to call omapX_init_opp(to register the defaults) before customizing the defaults. Does this explain the code and reason for the logic? if you do have a better mechanism, lets know. Yes, it explains the code and reason for the logic, but still doesn't make it pretty :-) would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()). HUH?? NULL table to a static function - what code are you talking about?? why are you so behind BUG_ON, when there are valid reasons for reentry into code. In the current design, yes, there are indeed valid reasons for reentry into the omapX_init_opp() function, and that's exactly the point I'm critizicing here. Regards! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin seemed happy with the change here: http://marc.info/?l=linux-omapm=127507237109393w=2 Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OMAP: powerdomain: Arch specific funcs for mem control
Hello,
On Tue, 16 Nov 2010 21:08:05 +0530
Rajendra Nayak rna...@ti.com wrote:
Define the following architecture specific funtions for omap2/3/4
funtions - functions.
+/* Common Internal functions used across OMAP rev's*/
+int _get_mem_bank_onstate_mask(u8 bank)
+{
+ switch (bank) {
+ case 0:
+ return OMAP_MEM0_ONSTATE_MASK;
+ case 1:
+ return OMAP_MEM1_ONSTATE_MASK;
+ case 2:
+ return OMAP_MEM2_ONSTATE_MASK;
+ case 3:
+ return OMAP_MEM3_ONSTATE_MASK;
+ case 4:
+ return OMAP_MEM4_ONSTATE_MASK;
+ default:
+ WARN_ON(1); /* should never happen */
+ return -EEXIST;
EEXIST is the error code for File exists, so here I would rather
expect something like ENOENT. But I understand that it was already
-EEXIST in the existing code.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] OMAP: powerdomain: Infrastructure to put arch specific code
On Tue, 16 Nov 2010 21:08:02 +0530
Rajendra Nayak rna...@ti.com wrote:
+struct pwrdm_functions {
+ int (*pwrdm_set_next_pwrst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_read_next_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_logic_retst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_set_mem_onst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_set_mem_retst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_read_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_logic_retst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_mem_pwrst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_read_prev_mem_pwrst)(struct powerdomain *pwrdm, u8
bank);
+ int (*pwrdm_read_mem_retst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_clear_all_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_enable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_disable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_lowpwrstchange)(struct powerdomain *pwrdm);
+ int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
+};
It would probably be great to have some short documentation on this
structure, to detail what are the different operations, what they
should do, etc.
By the way, would pwrdm_operations be more linux-ish than
pwrdm_functions ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
Hello, On Tue, 16 Nov 2010 14:59:30 -0800 Kevin Hilman khil...@deeprootsystems.com wrote: Hmm, using pm-core, I can hit full-chip retention in suspend on my Beagle C4. However, upgrading to a recent x-loader and u-boot, I can reproduce the problem. Ok, as you told me on IRC yesterday. The problem is an old one that seems to have resurfaced. Namely, u-boot leaves the MUSB block in a state that prevents it from idling, and thus prevents CORE from hitting RET. I have a series of hacks for this in the PM branch (see my pm-otg-reset branch) that fixes the problem, but is not clean. This will work until the omap_hwmod conversion for MUSB is done. One of the perks we get from omap_hwmod is that a reset is done for each hwmod ensuring that any (mis)configuration of the bootloader is cleared and the HW is in a known default state. Ah, that's nice indeed. Are the hwmod conversion patches of musb already available somewhere (even preliminary versions) ? Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
Hello, On Wed, 10 Nov 2010 09:32:53 -0800 Kevin Hilman khil...@deeprootsystems.com wrote: The other problem that I'm aware of so far I've only seen on boards with UART2 console (beagle, Overo, n900.) The printk messages that warn of 'new worst case [de]activate latency seem to be racing with UART disable code. This makes sense, since this printk is printed to the UART immediately after the UART is disabled, which is going to cause problems with the current approach to UART pm we have in mach-omap2/serial.c. I have not yet fully debugged this and found a workaround. Even if I comment the new worst case deactivate latency message, my BeagleBoard still doesn't wake-up from suspend. Here's what I do: # echo enabled /sys/class/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 227.685028] PM: Syncing filesystems ... done. [ 227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 227.880706] PM: suspend of devices complete after 117.767 msecs [ 227.889160] PM: late suspend of devices complete after 2.136 msecs [ 227.895782] Disabling non-boot CPUs ... Any idea ? Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
On Mon, 15 Nov 2010 11:50:05 +0100 Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: # echo enabled /sys/class/tty/ttyO2/power/wakeup # echo mem /sys/power/state [ 227.685028] PM: Syncing filesystems ... done. [ 227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 227.880706] PM: suspend of devices complete after 117.767 msecs [ 227.889160] PM: late suspend of devices complete after 2.136 msecs [ 227.895782] Disabling non-boot CPUs ... Any idea ? Removing no_console_suspend from my bootargs made it work. However, it was previously working with no_console_suspend, and that was very useful since I need to debug things happening fairly early in the resume procedure. Any clue on how to make no_console_suspend work again ? Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
Hello Govindraj, On Mon, 15 Nov 2010 19:24:05 +0530 Govindraj govindraj...@gmail.com wrote: Can you check if you have below two patches in the kernel you have? http://www.spinics.net/lists/linux-serial/msg02684.html http://www.spinics.net/lists/linux-serial/msg02683.html If not there can you check applying these two patch I have both of these patches in my kernel (I'm running the latest pm-core from Kevin's repository). See http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=history;f=drivers/serial/serial_core.c;h=c4ea14670d4486fc142df31d806c528d2752c238;hb=pm-core. Thanks for the hint, anyway. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon n...@ti.com wrote:
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ?
Unless I'm wrong, this means that if the opp3xxx_data.h file is
included in two different C files, the structures will be present twice.
As far as I could see, most of the kernel instantiate structure in C
files instead.
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
BeagleBoard not resuming from uart with latest pm-core ?
Hello, I've updated my tree to the last pm-core branch today (I'm at commit 42289e226ec996a13ab8a2aaef5ad9dda61ee57e), and I've built the omap2plus_defconfig with no change (except adding an initramfs). On my BeagleBoard, I enable the wakeup from UART in /sys/devices/platform/omap/omap-hsuart.2/tty/ttyO2/power/wakeup, then trigger suspend to RAM. It enters suspend to RAM, but then it doesn't wakeup when I send data through the UART. Is it a known problem, or is again a mistake on my side ? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 07/16] OMAP3: hwmod DSS: Create platform_driver for each DSS HW IP
Hello, On Fri, 8 Oct 2010 12:41:35 +0530 Guruswamy, Senthilvadivu svad...@ti.com wrote: [Senthil] I put it above as part of all the static methods and structures. Will look at the other omap drivers before I change. Yes, but the platform_driver structure, -probe() and -remove() methods are not usually at a random place with all the other static methods and structure definitions. They are located *just* above the module init/cleanup routines. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 05/16] OMAP3 DSS Driver register moved to mach_omap2
Hello,
The patch title is a bit misleading, maybe it should rather be
something like Move OMAP3 DSS driver registration to
mach-omap2/devices.c/
On Wed, 6 Oct 2010 16:44:48 +0530
Guruswamy Senthilvadivu svad...@ti.com wrote:
/*---*/
+#ifdef CONFIG_OMAP2_DSS
+
+static struct platform_device omap_display_device = {
+ .name = omapdisplay,
+ .id= -1,
+ .dev= {
+ .platform_data = NULL,
+ },
This .dev = {} part is useless. The compiler will automatically
initialize unset fields to zero.
+};
+
+void __init omap_display_init(struct omap_dss_board_info
+ *board_data)
*board_data should probably be on the same line as the argument type.
+{
+
The general kernel coding style seems to be that there shouldn't be
such empty newlines at the beginning of functions.
+ omap_display_device.dev.platform_data = board_data;
+
+ if (platform_device_register(omap_display_device) 0)
+ printk(KERN_ERR Unable to register OMAP-Display device\n);
+
+
Unneeded newlines.
+ return ;
This return is not needed, we are at the end of a void function.
@@ -712,7 +712,7 @@ static struct platform_driver omap_dss_driver = {
.suspend= omap_dss_suspend,
.resume = omap_dss_resume,
.driver = {
- .name = omapdss,
+ .name = omapdisplay,
.owner = THIS_MODULE,
},
};
There are other boards instantiating a platform_device with the omapdss
name, so I think this change is going to break those boards. In my
not-so-old linux-omap tree :
$ grep \.name.*omapdss *
board-3430sdp.c:.name = omapdss,
board-am3517evm.c: .name = omapdss,
board-cm-t35.c: .name = omapdss,
board-devkit8000.c: .name = omapdss,
board-igep0020.c: .name = omapdss,
board-omap3beagle.c:.name = omapdss,
board-omap3evm.c: .name = omapdss,
board-omap3pandora.c: .name = omapdss,
board-omap3stalker.c: .name = omapdss,
board-rx51-video.c: .name = omapdss,
Shouldn't these board files also be updated to use the new
omap_display_init() function ?
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 06/16] OMAP3: hwmod DSS: Build omap_device for each DSS HWIP
Hello Senthil,
On Wed, 6 Oct 2010 16:44:49 +0530
Guruswamy Senthilvadivu svad...@ti.com wrote:
void __init omap_display_init(struct omap_dss_board_info
*board_data)
{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ int l, i;
+ struct omap_display_platform_data pdata;
+ char *oh_name[] = {
+ dss_dss,
+ dss_dispc,
+ dss_dsi1,
+ dss_rfbi,
+ dss_venc
+ };
I think it's more common to write it this way:
char *oh_name[] = { dss_dss, dss_dispc, dss_dsi1,
dss_rfbi, dss_venc };
but I understand that this is just a matter of taste.
+
+ for (i = 0; i ARRAY_SIZE(oh_name); i++) {
+ l = snprintf(oh_name[i], MAX_OMAP_DSS_HWMOD_NAME_LEN,
+ oh_name[i]);
+ WARN(l = MAX_OMAP_DSS_HWMOD_NAME_LEN,
+ String buffer overflow in DSS device setup\n);
Using snprintf() just to get the length of a string is a bit overkill.
strlen() is part of the kernel API :-)
However, about the name, see below.
+
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name[i]);
+ return ;
No space needed between return and the semi-colon.
+ }
+ strncpy(pdata.name, oh_name[i], sizeof(oh_name[i]));
Why do you need this name into the platform_data ? omap_device_build()
will already fill the omap_device-platform_device-name field with
exactly oh_name[i]. So your drivers can just do platform_device-name
to get the name if they need it.
+ pdata.board_data= board_data;
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
+ pdata.device_enable= omap_device_enable;
+ pdata.device_idle = omap_device_idle;
+ pdata.device_shutdown = omap_device_shutdown;
pdata is defined outside of the loop, so you're passing the same pdata
address to each omap_device_build() call. Therefore, there's no need to
initialize pdata at each iteration of the loop.
+struct omap_display_platform_data {
+ char name[MAX_OMAP_DSS_HWMOD_NAME_LEN];
+ struct omap_dss_board_info *board_data;
+ int (*device_enable)(struct platform_device *pdev);
+ int (*device_shutdown)(struct platform_device *pdev);
+ int (*device_idle)(struct platform_device *pdev);
+};
I'm probably missing something, but I don't see those new
device_enable, device_shutdown, device_idle fields being used in the
following patches in your series. Did I look at the wrong place ?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 11/16] OMAP3: hwmod DSS: RFBI Move init,exit to driver
Hello Senthil,
On Wed, 6 Oct 2010 16:44:54 +0530
Guruswamy Senthilvadivu svad...@ti.com wrote:
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 23598ea..9bee39d 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -100,6 +100,7 @@ static int rfbi_convert_timings(struct rfbi_timings *t);
static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
static struct {
+ struct platform_device *pdev;
void __iomem*base;
unsigned long l4_khz;
@@ -142,11 +143,22 @@ static inline u32 rfbi_read_reg(const struct rfbi_reg
idx)
/* RFBI HW IP initialisation */
static int omap_rfbihw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ rfbi.pdev = pdev;
+
+ r = rfbi_init();
+ if (r) {
+ DSSERR(Failed to initialize rfbi\n);
+ goto err_rfbi;
+ }
+
+err_rfbi:
+ return r;
}
static int omap_rfbihw_remove(struct platform_device *pdev)
{
+ rfbi_exit();
return 0;
}
Instead of having probe() and remove() functions that call the existing
init() and exit(), why not making your driver look like most Linux
drivers here, and directly do the initialization in probe() and the
cleanup in remove() ?
Concerning the added pdev field to the rfbi structure, do you really it
at this point ?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 07/16] OMAP3: hwmod DSS: Create platform_driver for each DSS HW IP
Hello Senthil,
On Wed, 6 Oct 2010 16:44:50 +0530
Guruswamy Senthilvadivu svad...@ti.com wrote:
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .shutdown = NULL,
+ .suspend= NULL,
+ .resume = NULL,
Those are unneeded, the compiler will initialize those fields to zero
automatically if you don't specify any value.
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 12/16] OMAP3: hwmod DSS: DISPC Move init,exit to driver
Hello Senthil,
On Wed, 6 Oct 2010 16:44:55 +0530
Guruswamy Senthilvadivu svad...@ti.com wrote:
static struct {
+ struct platform_device *pdev;
void __iomem*base;
u32 fifo_size[3];
@@ -189,11 +190,22 @@ static inline u32 dispc_read_reg(const struct dispc_reg
idx)
/* DISPC HW IP initialisation */
static int omap_dispchw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dispc.pdev = pdev;
+
+ r = dispc_init();
+ if (r) {
+ DSSERR(Failed to initialize dispc\n);
+ goto err_dispc;
+ }
+
+err_dispc:
+ return r;
}
static int omap_dispchw_remove(struct platform_device *pdev)
{
+ dispc_exit();
return 0;
}
Same comments than the one for the patch on the RFBI driver.
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 07/16] OMAP3: hwmod DSS: Create platform_driver for each DSS HW IP
Hello Senthil,
I forgot one comment: in most Linux drivers, it is customary to put the
platform_driver definition just above the driver initialization
function, both of them at the end of the file. Of course, it's nothing
mandatory, but most of the drivers are organized this way, making it
easy for developers to find their way in all drivers.
So, in other words, this:
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .driver = {
+ .name = dss_dispc,
+ .owner = THIS_MODULE,
+ },
+};
Should be just above this:
+static int __init omap_dispc_init(void)
+{
+ return platform_driver_register(omap_dispchw_driver);
+}
+
+device_initcall(omap_dispc_init);
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 13/16] OMAP3: hwmod DSS: VENC Move init,exit to driver
Hello Senthil,
On Wed, 6 Oct 2010 16:44:56 +0530
Guruswamy Senthilvadivu svad...@ti.com wrote:
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index ec17b28..3a121cb 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -87,26 +87,6 @@
#define VENC_OUTPUT_TEST 0xC8
#define VENC_DAC_B__DAC_C0xC8
-/* VENC HW IP initialisation */
-static int omap_venchw_probe(struct platform_device *pdev)
-{
- return 0;
-}
-
-static int omap_venchw_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
-static struct platform_driver omap_venchw_driver = {
- .probe = omap_venchw_probe,
- .remove = omap_venchw_remove,
- .driver = {
- .name = dss_venc,
- .owner = THIS_MODULE,
- },
-};
Would be better in patch 7/16 to put this stuff at the correct place
(bottom of the file) so it does not need to be moved here.
+/* VENC HW IP initialisation */
+static int omap_venchw_probe(struct platform_device *pdev)
+{
+ int r;
+ venc.pdev = pdev;
+
+ r = venc_init(pdev);
+ if (r) {
+ DSSERR(Failed to initialize venc\n);
+ goto err_venc;
+ }
+
+err_venc:
+ return r;
+}
+
+static int omap_venchw_remove(struct platform_device *pdev)
+{
+ venc_exit();
+ return 0;
+}
Same comment as before: include the code of venc_init() and venc_exit()
directly in the -probe() and -remove() hooks respectively.
+struct regulator *dss_get_vdda_dac(void)
+{
+ struct regulator *reg;
+
+ if (venc.vdda_dac_reg != NULL)
+ return venc.vdda_dac_reg;
+
+ reg = regulator_get(venc.pdev-dev, vdda_dac);
+ if (!IS_ERR(reg))
+ venc.vdda_dac_reg = reg;
+ return reg;
+}
As far as I can see, this function is now only used in venc_init(),
which is in the same file, so the function should be static, and the
prototype removed from drivers/video/omap2/dss/core.h.
I'm also a bit skeptical about what this function does. It is called
this way in venc_init():
venc.vdda_dac_reg = dss_get_vdda_dac();
so it is dss_get_vdda_dac() responsability to set venc.vdda_dac_reg, or
is it the caller responsability ?
Moreover, the logic in dss_get_vdda_dac() that tests whether
venc.vdda_dac_reg is already initialized seems to indicate that this
function could be called several times. However, I only see it called
from venc_init(), which as far as I understand is called only once.
Isn't it possible to simplify this by removing the dss_get_vdda_dac()
function and just doing:
venc.vdda_dac_reg = regulator_get(venc.pdev-dev, vdda_dac);
in the venc_init() function (which should become the -probe() method).
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 14/16] OMAP3: hwmod DSS: DSI Move init, exit to driver
Hello Senthil, On Wed, 6 Oct 2010 16:44:57 +0530 Guruswamy Senthilvadivu svad...@ti.com wrote: Move init exit methods to its driver probe, remove. pdev member has to be maintained by its own drivers. regulator has to be privately handled in each driver. Same comments than the one for patch 13/16 about the contents of -probe() and -remove() methods, and the auxilliary dsi_get_vdds_dsi() function. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend to RAM broken on BeagleBoard ?
On Fri, 10 Sep 2010 14:54:23 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: It's the CPUfreq driver that's failing to suspend. Ok. Yes, CPUfreq is not supported in l-o master or pm-core (only in the full pm branch.) If you Kconfig out CPUfreq, this failure will go away. Aah, yes, I forgot about this. I know it's temporary, but wouldn't it be good to disable CPUfreq in omap3_defconfig in this case ? BTW, I'm now seeing: [ 37.830596] Powerdomain (core_pwrdm) didn't enter target state 1 [ 37.830627] Powerdomain (dss_pwrdm) didn't enter target state 1 when the system is woken up. Concerning the USB issue, no idea ? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Suspend to RAM broken on BeagleBoard ?
Hello, I've tested the current linux-omap Git tree and Kevin's pm-core branch on a BeagleBoard using the omap3_defconfig, and when trying a suspend to RAM, I get a Class driver suspend failed for cpu0 : # echo mem /sys/power/state [ 93.395050] PM: Syncing filesystems ... done. [ 93.410827] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 93.434570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 93.458557] Suspending console(s) (use no_console_suspend to debug) [ 93.590728] PM: suspend of devices complete after 119.629 msecs [ 93.593902] PM: late suspend of devices complete after 3.112 msecs [ 93.594421] Class driver suspend failed for cpu0 [ 93.595153] PM: early resume of devices complete after 0.518 msecs [ 93.887603] PM: resume of devices complete after 292.052 msecs [ 93.922851] Restarting tasks ... done. Is this a known issue ? I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend to RAM broken on BeagleBoard ?
On Fri, 10 Sep 2010 20:00:53 +0300 Felipe Balbi ba...@ti.com wrote: On Fri, Sep 10, 2010 at 10:48:14AM -0500, Thomas Petazzoni wrote: I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. is it attached to EHCI/OHCI or musb port ? It's a normal USB Ethernet adapter that is attached to the EHCI/OCHI port of the BeagleBoard. I have a revision C3. With older Git versions from the PM tree, it used to work, even if it wasn't 100% stable. But at least it was detected, and I was able to nfs mount the root filesystem. I don't know if I can easily bisect this, as I think the PM branches are constantly rebased. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Hello, On Wed, 01 Sep 2010 15:51:40 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: Looking closer at this, keeping track of a list of devices and constraints is what the regulator framework does as well. Before we get too far down this path, we need to start working with Thomas Petazzoni to better understand how we can use the regulator framework for much of the management levels of the voltage layer. Yes, as discussed on IRC with Kevin, I think that some of this voltage layer mechanisms would benefit from using the existing kernel regulator framework. The regulator framework already keeps tracks of consumers (in your patch set called vdd users), and for each consumer, keeps track of the requested voltage. The maximum requested voltage is then applied to the regulator. It seems to fit quite well some of the mechanisms you're introducing in this patch set. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
Hello Thara,
On Fri, 2 Jul 2010 15:48:25 +0530
Thara Gopinath th...@ti.com wrote:
#include plat/common.h
@@ -38,21 +39,45 @@
*/
struct omap_opp_def {
char *hwmod_name;
+ char *vdd_name;
unsigned long freq;
unsigned long u_volt;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+
bool enabled;
};
It looks strange to me that per-OPP methods are needed to set/get the
rate. These should only be needed at the device level, no ?
And indeed, in your patch 6/7, for every device, the same get/set rate
methods are used for all OPPs of a given device.
+struct device_opp {
+ struct list_head node;
+ char *vdd_name;
+
+ struct omap_hwmod *oh;
+ struct device *dev;
+ struct omap_volt_domain *volt_domain;
+
+ struct list_head opp_list;
+ u32 opp_count;
+ u32 enabled_opp_count;
+
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+};
I know this structure already exists, but do we really need a new
structure for this ? Couldn't these infos (OPP list, set/get rate
methods) be stored in an existing device-specific structure (omap_hwmod
for hardware-related things are omap_device for ~software-related
things) ?
For example, why aren't OPPs attached to the hwmod description of the
particular device ? These OPPs definitions really look like a
characteristic of a particular IP, don't they ?
Whatever choice is made, this structure probably needs a comment on top
of it explaining what it does, since the name isn't very obvious IMO.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Timekeeping issue on aggressive suspend/resume
Hello Suresh, On Wed, 9 Jun 2010 12:50:39 -0700 Suresh Rajashekara suresh.raj+linuxo...@gmail.com wrote: I have an application (running on 2.6.29-omap1) which puts an OMAP1 system to suspend aggressively. The system wakes up every 4 seconds and stays awake for about 35 milliseconds and sleeps again for another 4 seconds. This design is to save power on a battery operated device. This aggressive suspend resume action seems like creating an issue to other applications in the system waiting for some timeout to happen (especially an application which is waiting using the mq_timedreceive and is supposed to timeout every 30 seconds. It seems to wake up every 90 seconds). Seems like the timekeeping is not happening properly in side the kernel. If the suspend duration is changed from 4 second to 1 second, then things work somewhat better. On reducing it to 0.5 second (which was our earlier design on 2.6.16-rc3), the problem seems to disappear. I've done a relatively similar thing on different CPU architecture: in the idle loop, when the CPU is going to be idle for a sufficiently long period of time, I power down the CPU completely. Before that, I've programmed a RTC (clocked at 32 khz) to wake-up the CPU a little bit *before* the expiration of the next timer. When the CPU wakes-up, I adjust the clocksource (in this case the CPU cycle counter) to compensate the time spent while the CPU was off, and I reprogram the clockevents to make sure that the timer will actually expire at the correct time, also by compensating the time during which the CPU was off (note: when the CPU is off, the cycle counter stops incrementing, and the timer used as clockevents stops decrementing). This way, the CLOCK_MONOTONIC time continues to go forward even when the CPU is off. The goal was to make the CPU is off case just another idle state of the system, which should just be as transparent to the life of the system as other idle states. So an application that uses a periodic timer of say, 30 milliseconds, will see its timer actually fired every 30 milliseconds even though the CPU goes off between each timer expiration (we've done measurements with a scope, and the timer rely expires every 30 milliseconds as expected). FWIW, we do not use the normal suspend/resume infrastructure for this, because it was way too slow (in the order of ~100ms). On the particular hardware we're using, it takes roughly ~1ms to go OFF, and ~2ms to completely wake-up, so we can very aggressively put the CPU in the OFF state. However, the way we're doing the time compensation is quite hackish, and it would be great to hear Thomas Gleixner's ideas on how this should be implemented properly at the clocksource/clock_event_device level. Sincerely, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
On Mon, 31 May 2010 16:44:52 -0500
Arce, Abraham x0066...@ti.com wrote:
+ unsigned int length = 0, id = 0;
+ int hw_mod_name_len = 16;
+ char oh_name[hw_mod_name_len];
+ char *name = omap4-keypad;
+
+ length = snprintf(oh_name, hw_mod_name_len, kbd);
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -EIO;
+ }
Maybe I'm missing something here, but I don't see where length is
being used, and why the snprintf()/oh_name thing is needed. What about:
unsigned int id = 0;
char *name = omap4-keypad;
oh = omap_hwmod_lookup(kbd);
if (!oh) {
pr_err(Could not look up kbd\n);
return -EIO;
}
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration
On Wed, 2 Jun 2010 07:45:07 -0500 Arce, Abraham x0066...@ti.com wrote: I'll remove length variable and keep snprintf, below oh_name - kbd is used again, this will keep name defined in one single place WARN(IS_ERR(od), Could not build omap_device for %s %s\n, name, oh_name); In this case, why not: char *oh_name = kbd; There's really no point in using snprintf() for statically-defined strings. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
