* [PATCH 00/11] mtd/nand: fsmc driver updates
From: Artem Bityutskiy @ 2012-10-17 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1349778820.git.vipin.kumar@st.com>
On Tue, 2012-10-09 at 16:14 +0530, Vipin Kumar wrote:
> This patch-set contains several fixes and a few enhancements in fsmc driver.
> Modifications include
OK, picked some patches from your series, some do not apply. Please,
send v2 against the l2-mtd.git tree:
git://git.infradead.org/users/dedekind/l2-mtd.git
Thanks!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121017/d73a2a7b/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: multiplatform: Add a defconfig for multi_v5
From: Arnd Bergmann @ 2012-10-17 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350461444-22832-1-git-send-email-linux@prisktech.co.nz>
On Wednesday 17 October 2012, Tony Prisk wrote:
> This patch adds a simple multi_v5_defconfig for arch-vt8500
> multiplatform.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
>
> I expect there will be a bit of comment regarding this as others will
> need to add their requirements as well, and it seems overly basic.
Right now, I think we only need to add imx1 and imx2, basically
taking everything from arch/arm/configs/imx_v4_v5_defconfig.
Shawn and Sascha, let us know if you have other preferences here.
Arnd
^ permalink raw reply
* [PATCH v2 0/2] Add DMA and device tree support to the flash controller FLCTL
From: Bastian Hecht @ 2012-10-17 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350473030.5769.137.camel@sauron.fi.intel.com>
Hi Artem,
> Hi, I used to be able to compile MTD stuff for mackerel board with the
> defconfig attached, but now it fails with 3.7-rc1 with as error:
>
> /tmp/cc2Nr7AN.s: Error: bad immediate value for 8-bit offset (1024)
>
> It fails for dogc4.c, but if I disable DOCG4, it fails for other drivers
> with a similar error.
>
> I've tried (arm) gcc 4.6.3 and the latest Linaro 4.7 build.
>
> Any idea? I did not dig this, is this a known issue? Could you try to
> reproduce this in your setup?
>
I can reproduce the error with the following output:
/tmp/ccYAbker.s: Assembler messages:
/tmp/ccYAbker.s: Error: bad immediate value for 8-bit offset (2048)
make[3]: *** [drivers/mtd/nand/docg4.o] Error 1
The compiler version is: gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
I usually use: gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) and
can compile things without problems.
I found some old bug reports (from 2005) on the same issue with arm gcc.
Do we want to send a bug report? I've read in the gnu gcc docs about
reporting and they want the minimal set of data to reproduce this bug.
Hmmmm....
The command line used (with --save-temps added as they want it) is:
arm-linux-gnueabi-gcc -Wp,-MD,drivers/mtd/nand/.docg4.o.d -nostdinc
-isystem /usr/lib/gcc/arm-linux-gnueabi/4.6/include
-I$KERNEL_DIR/arch/arm/include -Iarch/arm/include/generated -Iinclude
-I$KERNEL_DIR/arch/arm/include/uapi -Iarch/arm/include/generated/uapi
-I$KERNEL_DIR/include/uapi -Iinclude/generated/uapi -include
$KERNEL_DIR/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian
-Iarch/arm/mach-shmobile/include -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -O2 -marm -fno-dwarf2-cfi-asm
-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux
-mno-thumb-interwork -D__LINUX_ARM_ARCH__=7 -march=armv7-a
-msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector
-Wno-unused-but-set-variable -fno-omit-frame-pointer
-fno-optimize-sibling-calls -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DMODULE
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(docg4)"
-D"KBUILD_MODNAME=KBUILD_STR(docg4)" --save-temps -c -o
drivers/mtd/nand/docg4.o drivers/mtd/nand/docg4.c
This generates docg4.i.
The only way for them to reproduce it would be getting the kernel as a
whole with the .config, no?
cheers,
Bastian
^ permalink raw reply
* PDF documentation
From: Constantine Shulyupin @ 2012-10-17 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016140555.12139.qmail@stuge.se>
On Tue, Oct 16, 2012 at 4:05 PM, Peter Stuge <peter@stuge.se> wrote:
> Constantine Shulyupin wrote:
>> - what PDF documentation do you use? (You can just drop a link to PDF,
>> for example http://www.ti.com/lit/ds/symlink/omap4430.pdf)
>
> I don't understand what you want to know. I have thousands of data
> sheets for parts that I have used, use, or plan to use.
> //Peter
Peter, can you please just send me some links to most frequently used
online PDF?
I would like to convert them to html and see how usable it is.
--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci
^ permalink raw reply
* [PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type
From: Arnd Bergmann @ 2012-10-17 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003a01cdac3f$08fe40d0$1afac270$%kim@samsung.com>
On Wednesday 17 October 2012, Kukjin Kim wrote:
> BTW, don't we need following accordingly?
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 1a81c90..a0bb55e 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -1067,11 +1067,11 @@ static int __devinit s3c64xx_spi_get_dmares(
>
> if (tx) {
> dma_data = &sdd->tx_dma;
> - dma_data->direction = DMA_TO_DEVICE;
> + dma_data->direction = DMA_MEM_TO_DEV;
> chan_str = "tx";
> } else {
> dma_data = &sdd->rx_dma;
> - dma_data->direction = DMA_FROM_DEVICE;
> + dma_data->direction = DMA_DEV_TO_MEM;
> chan_str = "rx";
> }
>
Yes, you are absolutely right, sorry for not seeing that earlier.
New version below.
Arnd
>From c10356b9846b13651a8a24c3a31e029ffe6eafd9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 30 Apr 2012 16:31:27 +0000
Subject: [PATCH] spi/s3c64xx: use correct dma_transfer_direction type
There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
'enum dma_data_direction' and 'enum dma_transfer_direction' [-Wenum-compare]
As pointed out by Kukjin Kim, this also changes the use of constants
from DMA_FROM_DEVICE/DMA_TO_DEVICE to DMA_DEV_TO_MEM/DMA_MEM_TO_DEV.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..cd43b4b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
struct s3c64xx_spi_dma_data {
unsigned ch;
- enum dma_data_direction direction;
+ enum dma_transfer_direction direction;
enum dma_ch dmach;
struct property *dma_prop;
};
@@ -1065,11 +1065,11 @@ static int __devinit s3c64xx_spi_get_dmares(
if (tx) {
dma_data = &sdd->tx_dma;
- dma_data->direction = DMA_TO_DEVICE;
+ dma_data->direction = DMA_MEM_TO_DEV;
chan_str = "tx";
} else {
dma_data = &sdd->rx_dma;
- dma_data->direction = DMA_FROM_DEVICE;
+ dma_data->direction = DMA_DEV_TO_MEM;
chan_str = "rx";
}
^ permalink raw reply related
* [PATCH 1/1] Documentation: Describe Device Tree bindings for GPIO Regulator driver
From: Mark Brown @ 2012-10-17 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350374553-12678-1-git-send-email-lee.jones@linaro.org>
On Tue, Oct 16, 2012 at 09:02:33AM +0100, Lee Jones wrote:
> Here we specify all non-standard bindings which can be used when
> requesting the use of an GPIO controlled regulator from Device Tree.
Applied both patches squashed together, thanks. Please don't split
documentation from the code like this where the code is just a single
change - it's sensible where the code is a big series but for single
patch it's not helpful.
Given the subject line I'd be extremely likely to delete this patch
unread, Documentation: says "this isn't relevant".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121017/7cb1b9e3/attachment-0001.sig>
^ permalink raw reply
* [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
From: Lokesh Vutla @ 2012-10-17 13:28 UTC (permalink / raw)
To: linux-arm-kernel
When building omap_l3_noc/smx drivers as modules, the following
warning appears:
CC [M] drivers/bus/omap_l3_smx.o
drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class
drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync'
drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration
drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
CC [M] drivers/bus/omap_l3_noc.o
drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class
drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync'
drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration
drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used
Adding module_init() and macros in omap_l3_noc/smx drivers when building
as modules to remove the above warning.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/bus/omap_l3_noc.c | 9 +++++++++
drivers/bus/omap_l3_smx.c | 10 ++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index d15225f..8222a33 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -257,10 +257,19 @@ static int __init omap4_l3_init(void)
{
return platform_driver_register(&omap4_l3_driver);
}
+#ifndef CONFIG_OMAP_INTERCONNECT_MODULE
postcore_initcall_sync(omap4_l3_init);
+#else
+module_init(omap4_l3_init);
+#endif
static void __exit omap4_l3_exit(void)
{
platform_driver_unregister(&omap4_l3_driver);
}
module_exit(omap4_l3_exit);
+
+MODULE_ALIAS("platform: omap_l3_noc");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("OMAP4XXX L3 Interconnect Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc2164..00f712d 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -22,6 +22,7 @@
* USA
*/
+#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
@@ -288,10 +289,19 @@ static int __init omap3_l3_init(void)
{
return platform_driver_probe(&omap3_l3_driver, omap3_l3_probe);
}
+#ifndef CONFIG_OMAP_INTERCONNECT_MODULE
postcore_initcall_sync(omap3_l3_init);
+#else
+module_init(omap3_l3_init);
+#endif
static void __exit omap3_l3_exit(void)
{
platform_driver_unregister(&omap3_l3_driver);
}
module_exit(omap3_l3_exit);
+
+MODULE_ALIAS("platform: omap_l3_smx");
+MODULE_AUTHOR("Texas Instruments Inc.");
+MODULE_DESCRIPTION("OMAP3XXX L3 Interconnect Driver");
+MODULE_LICENSE("GPL v2");
--
1.7.10.4
^ permalink raw reply related
* [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
From: Santosh Shilimkar @ 2012-10-17 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350480519-1890-1-git-send-email-lokeshvutla@ti.com>
(Looping Arnd and Olof)
On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:
> When building omap_l3_noc/smx drivers as modules, the following
> warning appears:
>
> CC [M] drivers/bus/omap_l3_smx.o
> drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class
> drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync'
> drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration
> drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
> CC [M] drivers/bus/omap_l3_noc.o
> drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class
> drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync'
> drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration
> drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used
>
> Adding module_init() and macros in omap_l3_noc/smx drivers when building
> as modules to remove the above warning.
>
> Reported-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
Thanks for the fix Lokesh. Looks fine to me.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: shiraz hashim @ 2012-10-17 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017101244.71A572029CB@gemini.denx.de>
Dear Wolfgang,
On Wed, Oct 17, 2012 at 3:42 PM, Wolfgang Denk <wd@denx.de> wrote:
> We use Foswiki for capabilities like this. Note that I definitely
> don't want to start a "my wiki is better than your wiki" religous war
> here ;-)
I like documentation maintained on denx site. However, have you tried
light markup language like asciidoc for documentation.
The good thing is that it is powerful enough to convert into docbook and
then onto pdf, html or other formats, at the same time clean enough to
be readable in txt format itself.
The text base provides an opportunity to use git or other version tools and
apply same worklow as that of code development.
--
regards
Shiraz Hashim
^ permalink raw reply
* [PATCH 1/2] mmc: core: Support all MMC capabilities when booting from Device Tree
From: Arnd Bergmann @ 2012-10-17 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015160740.GC7662@gmail.com>
On Monday 15 October 2012, Lee Jones wrote:
> > and so on. What are you actually missing in the properties that
> > are already there?
>
> MMC_CAP_ERASE
This one seems to be set unconditionally on some controllers but
not on others. Why would it need to be configurable?
> MMC_CAP_UHS_SDR12
> MMC_CAP_UHS_SDR25
> MMC_CAP_UHS_DDR50
Could this be derived from max-frequency?
> MMC_CAP_1_8V_DDR
Right, I suppose we need this. Should we have a minimum and maximum
voltage added to the common properties for this?
> MMC_CAP2_DETECT_ON_ERR
> MMC_CAP2_NO_SLEEP_CMD
I don't see these ones being set anywhere, but they were both
added by Ulf. Maybe he can comment on if or why they are needed
in devicetree, rather than being set by the driver unconditionally
or for specific versions of the host controller.
Arnd
^ permalink raw reply
* [PATCH 1/1] arm: at91: drop duplicated config SOC_AT91SAM9 entry
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-17 13:41 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/Kconfig | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index b142071..0436242 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -21,19 +21,13 @@ config SOC_AT91SAM9
bool
select CPU_ARM926T
select GENERIC_CLOCKEVENTS
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
menu "Atmel AT91 System-on-Chip"
comment "Atmel AT91 Processor"
-config SOC_AT91SAM9
- bool
- select AT91_SAM9_SMC
- select AT91_SAM9_TIME
- select CPU_ARM926T
- select MULTI_IRQ_HANDLER
- select SPARSE_IRQ
-
config SOC_AT91RM9200
bool "AT91RM9200"
select CPU_ARM920T
--
1.7.10.4
^ permalink raw reply related
* [GIT PULL] Renesas ARM-based SoC defconfig for v3.8
From: Arnd Bergmann @ 2012-10-17 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350448698-26985-1-git-send-email-horms@verge.net.au>
On Wednesday 17 October 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following defconfig enhancements for 3.8.
These look good to me, but I wonder what happened to the plan to reduce
the number of defconfig files we discussed before. Since you can build
a combined kernel that runs on all (or most) of the supported boards,
can you add a combined shmobile_defconfig that is able to work on
a wide variety of hardware and drop some of the less common defconfig
files?
Most of the modern platforms nowadays have just one defconfig that
covers everything.
Arnd
^ permalink raw reply
* [PATCH 1/1] arm: at91: drop duplicated config SOC_AT91SAM9 entry
From: Nicolas Ferre @ 2012-10-17 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350481291-32579-1-git-send-email-plagnioj@jcrosoft.com>
On 10/17/2012 03:41 PM, Jean-Christophe PLAGNIOL-VILLARD :
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/mach-at91/Kconfig | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index b142071..0436242 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -21,19 +21,13 @@ config SOC_AT91SAM9
> bool
> select CPU_ARM926T
> select GENERIC_CLOCKEVENTS
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
>
> menu "Atmel AT91 System-on-Chip"
>
> comment "Atmel AT91 Processor"
>
> -config SOC_AT91SAM9
> - bool
> - select AT91_SAM9_SMC
> - select AT91_SAM9_TIME
> - select CPU_ARM926T
> - select MULTI_IRQ_HANDLER
> - select SPARSE_IRQ
> -
> config SOC_AT91RM9200
> bool "AT91RM9200"
> select CPU_ARM920T
>
--
Nicolas Ferre
^ permalink raw reply
* RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support")
From: Felipe Balbi @ 2012-10-17 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ipaanljt.fsf_-_@deeprootsystems.com>
Hi,
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
> + peterz, tglx
>
> Felipe Balbi <balbi@ti.com> writes:
>
> [...]
>
> > The problem I see is that even though we properly return IRQ_WAKE_THREAD
> > and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
> > the thread is never scheduled. To make things even worse, ouw irq thread
> > runs once, but doesn't run on a consecutive call. Here's some (rather
> > nasty) debug prints showing the problem:
>
> [...]
>
> >> [ 88.721923] try_to_wake_up 1411
> >> [ 88.725189] ===> irq_wake_thread 139: IRQ 72 wake_up_process 0
> >> [ 88.731292] [sched_delayed] sched: RT throttling activated
>
> This throttling message is the key one.
>
> With RT throttling activated, the IRQ thread will not be run (it
> eventually will be allowed much later on, but by then, the I2C xfers
> have timed out.)
>
> As a quick hack, the throttling can be disabled by seeting the
> sched_rt_runtime to RUNTIME_INF:
>
> # sysctl -w kernel.sched_rt_runtime_us=-1
>
> and a quick test shows that things go back to working as expected. But
> we still need to figure out why the throttling is hapenning...
>
> So I started digging into why the RT runtime was so high, and noticed
> that time spent in suspend was being counted as RT runtime!
>
> So spending time in suspend anywhere near sched_rt_runtime (0.95s) will
> cause the RT throttling to always be triggered, and thus prevent IRQ
> threads from running in the resume path. Ouch.
>
> I think I'm already in over my head in the RT runtime stuff, but
> counting the time spent in suspend as RT runtime smells like a bug to
> me. no?
>
> Peter? Thomas?
it looks like removing console output completely (echo 0 >
/proc/sysrq-trigger) I don't see the issue anymore. Let me just run for
a few more iterations to make sure what I'm saying is correct.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121017/2f7fda6f/attachment.sig>
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Arnd Bergmann @ 2012-10-17 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350328024-30485-3-git-send-email-swarren@wwwdotorg.org>
On Monday 15 October 2012, Stephen Warren wrote:
> Rob, Arnd, Olof, I'd particularly like feedback on whether the following:
>
> #include "../../mach-tegra/iomap.h"
>
> in arch/arm/include/debug/tegra.S is acceptable. I'd really like to
> continue to #include a header to share the defines to Tegra physical
> memory layout and virtual based addresses with Tegra's io.c's struct
> map_desc entries, so they can't get out of sync. So, the include can
> either use the relative path as quoted above (which I don't think will
> cause any significant maintenance issue), or Tegra's iomap.h would have
> to be moved somewhere public so e.g. <tegra-iomap.h> could be included.
I don't have a good answer for this unfortunately. I wouldn't want relative
include paths to take over because they can paper over a lot of other
problems when people get lazy.
> Second, is the Kconfig.debug change reasonable? I guess I could remove
> the second choice menu I added, and just put all the options in the main
> "Kernel low-level debugging port" choice. However, that would make the
> "if" statements in "config DEBUG_LL_INCLUDE" rather more unwieldy.
It looks ok to me in principle, but you could also solve this by making
DEBUG_TEGRA_UART a silent option like this:
@@ -345,6 +345,46 @@ choice
Say Y here if you want kernel low-level debugging support
on SOCFPGA based platforms.
+ config DEBUG_TEGRA_UARTA
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTA for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTB
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTB for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTC
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTC for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTD
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTD for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
+ config DEBUG_TEGRA_UARTE
+ depends on ARCH_TEGRA
+ select DEBUG_TEGRA_UART
+ bool "Use Tegra UARTE for low-level debug"
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Tegra based platforms.
+
config DEBUG_VEXPRESS_UART0_DETECT
bool "Autodetect UART0 on Versatile Express Cortex-A core tiles"
depends on ARCH_VEXPRESS && CPU_CP15_MMU
@@ -409,6 +416,36 @@ choice
endchoice
+config DEBUG_TEGRA_UART
+ bool
I don't have a strong preference either way.
ARnd
^ permalink raw reply
* [PATCH] ARM: mach-imx: Let ARCH_MXC select HAVE_IMX_SRC
From: Fabio Estevam @ 2012-10-17 14:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit c5a0d497(ARM: imx: enable multi-platform build),
ARCH_MXC is selected by the following logic:
config ARCH_MXC
def_bool y if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V
, which causes build error on vexpress_defconfig:
arch/arm/mach-imx/hotplug.c:49: undefined reference to `imx_enable_cpu'
arch/arm/mach-imx/platsmp.c:57: undefined reference to `imx_set_cpu_jump'
arch/arm/mach-imx/platsmp.c:58: undefined reference to `imx_enable_cpu'
These missing functions are provided by arch/arm/mach-imx/src.c, which is
selected via HAVE_IMX_SRC.
Currently only SOC_IMX6Q selects HAVE_IMX_SRC, so let ARCH_MXC select it and fix
the build error.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 892631f..856482d 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -7,6 +7,7 @@ config ARCH_MXC
select CLKSRC_MMIO
select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
+ select HAVE_IMX_SRC
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
select USE_OF
@@ -837,7 +838,6 @@ config SOC_IMX6Q
select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
- select HAVE_IMX_SRC
select HAVE_SMP
select MFD_SYSCON
select PINCTRL
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] ARM: mach-imx: Let ARCH_MXC select HAVE_IMX_SRC
From: Fabio Estevam @ 2012-10-17 14:27 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit c5a0d497(ARM: imx: enable multi-platform build),
ARCH_MXC is selected by the following logic:
config ARCH_MXC
def_bool y if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
As vexpress_defconfig selects ARCH_MULTI_V6_V7, this leads to the following
build error when building for vexpress_defconfig:
arch/arm/mach-imx/hotplug.c:49: undefined reference to `imx_enable_cpu'
arch/arm/mach-imx/platsmp.c:57: undefined reference to `imx_set_cpu_jump'
arch/arm/mach-imx/platsmp.c:58: undefined reference to `imx_enable_cpu'
These missing functions are provided by arch/arm/mach-imx/src.c, which is
selected via HAVE_IMX_SRC.
Currently only SOC_IMX6Q selects HAVE_IMX_SRC, so let ARCH_MXC select it and fix
the build error.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Fix typo in commit message and improve it a bit
arch/arm/mach-imx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 892631f..856482d 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -7,6 +7,7 @@ config ARCH_MXC
select CLKSRC_MMIO
select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
+ select HAVE_IMX_SRC
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
select USE_OF
@@ -837,7 +838,6 @@ config SOC_IMX6Q
select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
- select HAVE_IMX_SRC
select HAVE_SMP
select MFD_SYSCON
select PINCTRL
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/8] [media] s5p-fimc: Use clk_prepare_enable and clk_disable_unprepare
From: Sylwester Nawrocki @ 2012-10-17 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350472311-9748-1-git-send-email-sachin.kamat@linaro.org>
Hi Sachin,
On 10/17/2012 01:11 PM, Sachin Kamat wrote:
> Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
> as required by the common clock framework.
I think this statement is misleading. In my understanding it is not the
common clock framework requirement to use clk_{enable/disable}_prepare
in place of clk_enable/disable. The requirement is to call clk_prepare
before first clk_enable call and to call clk_unprepare after clk_disable
and before clk_put.
You need to be careful with those replacements, since the clk *_(un)prepare
functions may sleep, i.e. they must not be called from atomic context.
Most of the s5p-* drivers have already added support for clk_(un)prepare.
Thus most of your changes in this patch are not needed. I seem to have only
missed fimc-mdevice.c, other modules are already reworked
$ git grep -5 clk_prepare -- drivers/media/platform/s5p-fimc
drivers/media/platform/s5p-fimc/fimc-core.c-
drivers/media/platform/s5p-fimc/fimc-core.c- for (i = 0; i < MAX_FIMC_CLOCKS; i++) {
drivers/media/platform/s5p-fimc/fimc-core.c- fimc->clock[i] = clk_get(&fimc->pdev->dev, fimc_clocks[i]);
drivers/media/platform/s5p-fimc/fimc-core.c- if (IS_ERR(fimc->clock[i]))
drivers/media/platform/s5p-fimc/fimc-core.c- goto err;
drivers/media/platform/s5p-fimc/fimc-core.c: ret = clk_prepare(fimc->clock[i]);
drivers/media/platform/s5p-fimc/fimc-core.c- if (ret < 0) {
drivers/media/platform/s5p-fimc/fimc-core.c- clk_put(fimc->clock[i]);
drivers/media/platform/s5p-fimc/fimc-core.c- fimc->clock[i] = NULL;
drivers/media/platform/s5p-fimc/fimc-core.c- goto err;
drivers/media/platform/s5p-fimc/fimc-core.c- }
--
drivers/media/platform/s5p-fimc/fimc-lite.c-
drivers/media/platform/s5p-fimc/fimc-lite.c- fimc->clock = clk_get(&fimc->pdev->dev, FLITE_CLK_NAME);
drivers/media/platform/s5p-fimc/fimc-lite.c- if (IS_ERR(fimc->clock))
drivers/media/platform/s5p-fimc/fimc-lite.c- return PTR_ERR(fimc->clock);
drivers/media/platform/s5p-fimc/fimc-lite.c-
drivers/media/platform/s5p-fimc/fimc-lite.c: ret = clk_prepare(fimc->clock);
drivers/media/platform/s5p-fimc/fimc-lite.c- if (ret < 0) {
drivers/media/platform/s5p-fimc/fimc-lite.c- clk_put(fimc->clock);
drivers/media/platform/s5p-fimc/fimc-lite.c- fimc->clock = NULL;
drivers/media/platform/s5p-fimc/fimc-lite.c- }
drivers/media/platform/s5p-fimc/fimc-lite.c- return ret;
--
drivers/media/platform/s5p-fimc/mipi-csis.c-
drivers/media/platform/s5p-fimc/mipi-csis.c- for (i = 0; i < NUM_CSIS_CLOCKS; i++) {
drivers/media/platform/s5p-fimc/mipi-csis.c- state->clock[i] = clk_get(dev, csi_clock_name[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c- if (IS_ERR(state->clock[i]))
drivers/media/platform/s5p-fimc/mipi-csis.c- goto err;
drivers/media/platform/s5p-fimc/mipi-csis.c: ret = clk_prepare(state->clock[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c- if (ret < 0) {
drivers/media/platform/s5p-fimc/mipi-csis.c- clk_put(state->clock[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c- state->clock[i] = NULL;
drivers/media/platform/s5p-fimc/mipi-csis.c- goto err;
drivers/media/platform/s5p-fimc/mipi-csis.c- }
I would prefer you have added the required changes at fimc_md_get_clocks()
and fimc_md_put_clocks() functions.
Please make sure you don't add those clk_(un)prepare calls where it is
net needed.
$ git grep "clk_prepare\|clk_unprepare" -- drivers/media/platform/s5p-*
drivers/media/platform/s5p-fimc/fimc-core.c: clk_unprepare(fimc->clock[i]);
drivers/media/platform/s5p-fimc/fimc-core.c: ret = clk_prepare(fimc->clock[i]);
drivers/media/platform/s5p-fimc/fimc-lite.c: clk_unprepare(fimc->clock);
drivers/media/platform/s5p-fimc/fimc-lite.c: ret = clk_prepare(fimc->clock);
drivers/media/platform/s5p-fimc/mipi-csis.c: clk_unprepare(state->clock[i]);
drivers/media/platform/s5p-fimc/mipi-csis.c: ret = clk_prepare(state->clock[i]);
drivers/media/platform/s5p-g2d/g2d.c: ret = clk_prepare(dev->clk);
drivers/media/platform/s5p-g2d/g2d.c: ret = clk_prepare(dev->gate);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev->gate);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev->clk);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev->gate);
drivers/media/platform/s5p-g2d/g2d.c: clk_unprepare(dev->clk);
drivers/media/platform/s5p-jpeg/jpeg-core.c: clk_prepare_enable(jpeg->clk);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c: ret = clk_prepare(pm->clock_gate);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c: ret = clk_prepare(pm->clock);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c: clk_unprepare(pm->clock_gate);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c: clk_unprepare(pm->clock_gate);
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c: clk_unprepare(pm->clock);
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/media/platform/s5p-fimc/fimc-core.c | 10 +++++-----
> drivers/media/platform/s5p-fimc/fimc-lite.c | 4 ++--
> drivers/media/platform/s5p-fimc/fimc-mdevice.c | 4 ++--
> drivers/media/platform/s5p-fimc/mipi-csis.c | 10 +++++-----
> 4 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-fimc/fimc-core.c b/drivers/media/platform/s5p-fimc/fimc-core.c
> index 8d0d2b9..92308ba 100644
> --- a/drivers/media/platform/s5p-fimc/fimc-core.c
> +++ b/drivers/media/platform/s5p-fimc/fimc-core.c
> @@ -827,7 +827,7 @@ static int fimc_clk_get(struct fimc_dev *fimc)
> fimc->clock[i] = clk_get(&fimc->pdev->dev, fimc_clocks[i]);
> if (IS_ERR(fimc->clock[i]))
> goto err;
> - ret = clk_prepare(fimc->clock[i]);
> + ret = clk_prepare_enable(fimc->clock[i]);
> if (ret < 0) {
> clk_put(fimc->clock[i]);
> fimc->clock[i] = NULL;
> @@ -925,7 +925,7 @@ static int fimc_probe(struct platform_device *pdev)
> if (ret)
> return ret;
> clk_set_rate(fimc->clock[CLK_BUS], drv_data->lclk_frequency);
> - clk_enable(fimc->clock[CLK_BUS]);
> + clk_prepare_enable(fimc->clock[CLK_BUS]);
>
> ret = devm_request_irq(&pdev->dev, res->start, fimc_irq_handler,
> 0, dev_name(&pdev->dev), fimc);
> @@ -970,7 +970,7 @@ static int fimc_runtime_resume(struct device *dev)
> dbg("fimc%d: state: 0x%lx", fimc->id, fimc->state);
>
> /* Enable clocks and perform basic initalization */
> - clk_enable(fimc->clock[CLK_GATE]);
> + clk_prepare_enable(fimc->clock[CLK_GATE]);
> fimc_hw_reset(fimc);
>
> /* Resume the capture or mem-to-mem device */
> @@ -990,7 +990,7 @@ static int fimc_runtime_suspend(struct device *dev)
> else
> ret = fimc_m2m_suspend(fimc);
> if (!ret)
> - clk_disable(fimc->clock[CLK_GATE]);
> + clk_disable_unprepare(fimc->clock[CLK_GATE]);
>
> dbg("fimc%d: state: 0x%lx", fimc->id, fimc->state);
> return ret;
> @@ -1045,7 +1045,7 @@ static int __devexit fimc_remove(struct platform_device *pdev)
> fimc_unregister_capture_subdev(fimc);
> vb2_dma_contig_cleanup_ctx(fimc->alloc_ctx);
>
> - clk_disable(fimc->clock[CLK_BUS]);
> + clk_disable_unprepare(fimc->clock[CLK_BUS]);
> fimc_clk_put(fimc);
>
> dev_info(&pdev->dev, "driver unloaded\n");
> diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c b/drivers/media/platform/s5p-fimc/fimc-lite.c
> index 70bcf39..4a12847 100644
> --- a/drivers/media/platform/s5p-fimc/fimc-lite.c
> +++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
> @@ -1479,7 +1479,7 @@ static int fimc_lite_runtime_resume(struct device *dev)
> {
> struct fimc_lite *fimc = dev_get_drvdata(dev);
>
> - clk_enable(fimc->clock);
> + clk_prepare_enable(fimc->clock);
> return 0;
> }
>
> @@ -1487,7 +1487,7 @@ static int fimc_lite_runtime_suspend(struct device *dev)
> {
> struct fimc_lite *fimc = dev_get_drvdata(dev);
>
> - clk_disable(fimc->clock);
> + clk_disable_unprepare(fimc->clock);
> return 0;
> }
>
> diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
> index 61fab00..e1f7cbe 100644
> --- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
> +++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
> @@ -779,7 +779,7 @@ static int __fimc_md_set_camclk(struct fimc_md *fmd,
> if (camclk->use_count++ == 0) {
> clk_set_rate(camclk->clock, pdata->clk_frequency);
> camclk->frequency = pdata->clk_frequency;
> - ret = clk_enable(camclk->clock);
> + ret = clk_prepare_enable(camclk->clock);
> dbg("Enabled camclk %d: f: %lu", pdata->clk_id,
> clk_get_rate(camclk->clock));
> }
> @@ -790,7 +790,7 @@ static int __fimc_md_set_camclk(struct fimc_md *fmd,
> return 0;
>
> if (--camclk->use_count == 0) {
> - clk_disable(camclk->clock);
> + clk_disable_unprepare(camclk->clock);
> dbg("Disabled camclk %d", pdata->clk_id);
> }
> return ret;
> diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c b/drivers/media/platform/s5p-fimc/mipi-csis.c
> index 4c961b1..f02c95b 100644
> --- a/drivers/media/platform/s5p-fimc/mipi-csis.c
> +++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
> @@ -710,7 +710,7 @@ static int __devinit s5pcsis_probe(struct platform_device *pdev)
> if (ret)
> goto e_clkput;
>
> - clk_enable(state->clock[CSIS_CLK_MUX]);
> + clk_prepare_enable(state->clock[CSIS_CLK_MUX]);
> if (pdata->clk_rate)
> clk_set_rate(state->clock[CSIS_CLK_MUX], pdata->clk_rate);
> else
> @@ -754,7 +754,7 @@ static int __devinit s5pcsis_probe(struct platform_device *pdev)
> e_regput:
> regulator_bulk_free(CSIS_NUM_SUPPLIES, state->supplies);
> e_clkput:
> - clk_disable(state->clock[CSIS_CLK_MUX]);
> + clk_disable_unprepare(state->clock[CSIS_CLK_MUX]);
> s5pcsis_clk_put(state);
> return ret;
> }
> @@ -779,7 +779,7 @@ static int s5pcsis_pm_suspend(struct device *dev, bool runtime)
> state->supplies);
> if (ret)
> goto unlock;
> - clk_disable(state->clock[CSIS_CLK_GATE]);
> + clk_disable_unprepare(state->clock[CSIS_CLK_GATE]);
> state->flags &= ~ST_POWERED;
> if (!runtime)
> state->flags |= ST_SUSPENDED;
> @@ -816,7 +816,7 @@ static int s5pcsis_pm_resume(struct device *dev, bool runtime)
> state->supplies);
> goto unlock;
> }
> - clk_enable(state->clock[CSIS_CLK_GATE]);
> + clk_prepare_enable(state->clock[CSIS_CLK_GATE]);
> }
> if (state->flags & ST_STREAMING)
> s5pcsis_start_stream(state);
> @@ -858,7 +858,7 @@ static int __devexit s5pcsis_remove(struct platform_device *pdev)
>
> pm_runtime_disable(&pdev->dev);
> s5pcsis_pm_suspend(&pdev->dev, false);
> - clk_disable(state->clock[CSIS_CLK_MUX]);
> + clk_disable_unprepare(state->clock[CSIS_CLK_MUX]);
> pm_runtime_set_suspended(&pdev->dev);
> s5pcsis_clk_put(state);
> regulator_bulk_free(CSIS_NUM_SUPPLIES, state->supplies);
>
--
Thanks,
Sylwester
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Rob Herring @ 2012-10-17 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350328024-30485-3-git-send-email-swarren@wwwdotorg.org>
On 10/15/2012 02:07 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Move Tegra's debug-macro.S over to the common debug macro directory.
>
> Move Tegra's debug UART selection menu into ARM's Kconfig.debug, so that
> all related options are selected in the same place.
>
> Tegra's uncompress.h is left in mach-tegra/include/mach; it will be
> removed whenever Tegra is converted to multi-platform.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> Rob, Arnd, Olof, I'd particularly like feedback on whether the following:
>
> #include "../../mach-tegra/iomap.h"
>
> in arch/arm/include/debug/tegra.S is acceptable. I'd really like to
> continue to #include a header to share the defines to Tegra physical
> memory layout and virtual based addresses with Tegra's io.c's struct
> map_desc entries, so they can't get out of sync. So, the include can
> either use the relative path as quoted above (which I don't think will
> cause any significant maintenance issue), or Tegra's iomap.h would have
> to be moved somewhere public so e.g. <tegra-iomap.h> could be included.
We already have a way to get the phys and virt addresses at runtime with
addruart macro. Couldn't we wrap this with a proper function and setup
the mapping at runtime. This would move it out of the platforms.
I'd also like to make the virtual address the same on all platforms (but
different offsets within a 1MB section) and make the phys address a
kconfig option. This would also eliminate the need for the platform
include and potentially addruart for that matter.
Rob
^ permalink raw reply
* [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-17 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016212647.GM15569@atomide.com>
On 10/16/2012 04:26 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [121016 14:00]:
>> Hi Tony,
>>
>> On 10/16/2012 12:48 PM, Tony Lindgren wrote:
>>> * Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
>>>> From: hvaibhav at ti.com <hvaibhav@ti.com>
>>>>
>>>> With recent changes in omap gpmc driver code, in case of DT
>>>> boot mode, where bootloader does not configure gpmc cs space
>>>> will result into kernel BUG() inside gpmc_mem_init() function,
>>>> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
>>>> gpmc_config7[0].baseaddress is set to '0' on reset.
>>>>
>>>> This use-case is applicable for any board/EVM which doesn't have
>>>> any peripheral connected to gpmc cs0, for example BeagleXM and
>>>> BeagleBone, so DT boot mode fails.
>>>>
>>>> This patch adds of_have_populated_dt() check before creating
>>>> device, so that for DT boot mode, gpmc probe will not be called
>>>> which is expected behavior, as gpmc is not supported yet from DT.
>>>
>>> I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
>>>
>>> Next time, please also cc linux-omap at vger.kernel.org for series
>>> like this. I'm sure the people reading the omap list are interested
>>> in these.
>>
>> This patch appears to be masking an underlying issue. How about
>> something like the following ...
>
> OK that looks good to me. I'll drop the earlier fix and use
> yours instead.
Hi Tony, sorry but I realised now that in my patch that I need to
take care of releasing and memory and clocks that were acquired
during the probe. Here is a V2. If you prefer I can create a delta
patch also with the previous.
Cheers
Jon
>From 91f5234d567c07ce1579b50e52de1a1e06ce5c68 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Tue, 16 Oct 2012 15:22:58 -0500
Subject: [PATCH V2] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to
reserve memory
Currently, if the GPMC driver fails to reserve memory when probed we will
call BUG() and the kernel will not boot. Instead of calling BUG(), return
an error from probe and allow kernel to boot.
Boot tested on AM335x beagle bone board and OMAP4430 Panda board.
V2 changes:
- Ensure that clock and memory resources are released on error.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/gpmc.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..92b5718 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void)
}
-static void __devinit gpmc_mem_init(void)
+static int __devinit gpmc_mem_init(void)
{
- int cs;
+ int cs, rc;
unsigned long boot_rom_space = 0;
/* never allocate the first page, to facilitate bug detection;
@@ -890,13 +890,21 @@ static void __devinit gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, &base, &size);
- if (gpmc_cs_insert_mem(cs, base, size) < 0)
- BUG();
+ rc = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(rc)) {
+ while (--cs >= 0)
+ if (gpmc_cs_mem_enabled(cs))
+ gpmc_cs_delete_mem(cs);
+ return rc;
+ }
}
+
+ return 0;
}
static __devinit int gpmc_probe(struct platform_device *pdev)
{
+ int rc;
u32 l;
struct resource *res;
@@ -936,7 +944,13 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- gpmc_mem_init();
+ rc = gpmc_mem_init();
+ if (IS_ERR_VALUE(rc)) {
+ clk_disable_unprepare(gpmc_l3_clk);
+ clk_put(gpmc_l3_clk);
+ dev_err(gpmc_dev, "failed to reserve memory\n");
+ return rc;
+ }
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
--
1.7.9.5
^ permalink raw reply related
* RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support")
From: Felipe Balbi @ 2012-10-17 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017140002.GI11394@arwen.pp.htv.fi>
Hi,
On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
> > + peterz, tglx
> >
> > Felipe Balbi <balbi@ti.com> writes:
> >
> > [...]
> >
> > > The problem I see is that even though we properly return IRQ_WAKE_THREAD
> > > and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
> > > the thread is never scheduled. To make things even worse, ouw irq thread
> > > runs once, but doesn't run on a consecutive call. Here's some (rather
> > > nasty) debug prints showing the problem:
> >
> > [...]
> >
> > >> [ 88.721923] try_to_wake_up 1411
> > >> [ 88.725189] ===> irq_wake_thread 139: IRQ 72 wake_up_process 0
> > >> [ 88.731292] [sched_delayed] sched: RT throttling activated
> >
> > This throttling message is the key one.
> >
> > With RT throttling activated, the IRQ thread will not be run (it
> > eventually will be allowed much later on, but by then, the I2C xfers
> > have timed out.)
> >
> > As a quick hack, the throttling can be disabled by seeting the
> > sched_rt_runtime to RUNTIME_INF:
> >
> > # sysctl -w kernel.sched_rt_runtime_us=-1
> >
> > and a quick test shows that things go back to working as expected. But
> > we still need to figure out why the throttling is hapenning...
> >
> > So I started digging into why the RT runtime was so high, and noticed
> > that time spent in suspend was being counted as RT runtime!
> >
> > So spending time in suspend anywhere near sched_rt_runtime (0.95s) will
> > cause the RT throttling to always be triggered, and thus prevent IRQ
> > threads from running in the resume path. Ouch.
> >
> > I think I'm already in over my head in the RT runtime stuff, but
> > counting the time spent in suspend as RT runtime smells like a bug to
> > me. no?
> >
> > Peter? Thomas?
>
> it looks like removing console output completely (echo 0 >
> /proc/sysrq-trigger) I don't see the issue anymore. Let me just run for
> a few more iterations to make sure what I'm saying is correct.
Yeah, really looks like removing console output makes the problem go
away. Ran a few iterations and it always worked fine. Full logs attached
BTW, In the meantime I think I might have found some problems with
omap_device's PM implementation. I'll test the patchset a little longer
and send an RFC.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom.cap
Type: application/vnd.tcpdump.pcap
Size: 278902 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121017/d10ab2e6/attachment-0001.cap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121017/d10ab2e6/attachment-0001.sig>
^ permalink raw reply
* [PATCH 9/9] ARM: add uprobes support
From: Jon Medhurst (Tixy) @ 2012-10-17 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015174450.GB18614@linaro.org>
On Mon, 2012-10-15 at 18:44 +0100, Dave Martin wrote:
> On Mon, Oct 15, 2012 at 01:44:55PM +0200, Rabin Vincent wrote:
> > 2012/10/15 Dave Martin <dave.martin@linaro.org>:
> > > On Sun, Oct 14, 2012 at 09:23:13PM +0200, Rabin Vincent wrote:
> > >> Add basic uprobes support for ARM.
> > >>
> > >> perf probe --exec and SystemTap's userspace probing work. The ARM
> > >> kprobes test code has also been run in a userspace harness to test the
> > >> uprobe instruction decoding.
> > >
> > > The assumption that the target code is ARM appears to be buried all over
> > > the place.
> >
> > Right, as stated:
> >
> > >> Caveats:
> > >> - Thumb is not supported
> >
> > > Certainly this code as currently written must depend on !THUMB2_KERNEL.
> >
> > Why? It currently works for ARM userspace even if the kernel is
> > Thumb-2.
>
> My bad, I misread what was happening in the Makefile changes.
>
> My concern is about whether we can build the ARM and Thumb-2 kprobes
> code into the same kernel. If so, no problem, but I believe this is
> not a tested configuration for kprobes itself.
When reworking kprobes I originally started by having ARM instruction
support in Thumb kernels (with all test cases working) and, if I
remember correct, this got dropped because we had difficulty in coming
up with a robust way of specifying whether a probe pointer was in Thumb
code or not. (Different methods of getting pointers to Thumb code didn't
always set bit 0 so we 'solved' this by ignoring bit 0 and assuming all
code in Thumb kernels was Thumb.)
<snip>
> General question which I'm not sure I understand yet: is is possible
> to combine uprobes/kprobes decode more completely? It's not obvious
> to me whether the uprobes-specific decoding only relates to features
> which architecturally execute differently in user mode versus
> privileged mode. Some explanation somewhere could be helpful.
I just been looking at the decoding changes in patch 8 and had similar
thoughts. The patch as it stands looks rather bolted on the side and
makes the resulting code rather messy. My initial thoughts are that
either:
a) uprobes is similar enough to kprobes that the existing code can be
morphed into something that cleanly supports both, or
b) the similarities aren't close enough and that we should factor out
the similarities into a more generalised decoding base, which the
{u,k}probe code can then build on.
c) some mix of a) and b)
I can't help but think of the various calls over the past year or so for
a general ARM/Thumb instruction decoding framework (the last one only a
few weeks ago on the linux-arm-kernel list). Perhaps b) would be a small
step towards that.
I hope to find some time to understand the uprobe patches in more
detail, so I can try and come up with some sensible suggestions on a
cleaner solution; because I feel that as they stand they aren't really
suitable for inclusion in the kernel.
Rabin, what tree/commit are your patches based on? (They don't seem to
apply cleanly to 3.6 or 3.7-rc1.) I want to apply them locally so I can
use my favourite visualisation tool and to play with them.
Thanks
--
Tixy
^ permalink raw reply
* [PATCH v4] Add basic address decoding support for Marvell 370/XP
From: Jason Cooper @ 2012-10-17 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120921210438.0e485888@skate>
On Fri, Sep 21, 2012 at 09:04:38PM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Fri, 21 Sep 2012 15:14:41 +0200, Andrew Lunn wrote:
>
> > I boot tested it on a kirkwood and an orion5x. No obvious smoke, the
> > ethernet interfaces still work, etc....
> >
> > Tested-by: Andrew Lunn <andrew@lunn.ch>
>
> Excellent, thanks!
>
> I'll be posting early next week the DT binding documentation that Arnd
> has rightfully requested. I was waiting for other comments, but it
> looks like it is the only that I have received on this series, so I'll
> got ahead and sent just a separate DT binding documentation patch.
>
Thomas,
What is the status of this?
thx,
Jason.
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC fixes for v3.7
From: Olof Johansson @ 2012-10-17 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017044011.GA27684@verge.net.au>
On Tue, Oct 16, 2012 at 9:40 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 17, 2012 at 01:36:23PM +0900, Simon Horman wrote:
>> Hi Olof, Hi Arnd,
>>
>> please consider the following fix for the KZM-A9-GT board for 3.6.
>
> Sorry, cut-and paste error. The line above should read:
>
> please consider the following fixes for 3.7.
>
>> They both resolve fallout from recent IOMEM() changes.
>>
>> ----------------------------------------------------------------
>> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>>
>> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git fixes
Pulled into fixes, thanks!
-Olof
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Daniel Mack @ 2012-10-17 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507E455F.7060703@ti.com>
Hi Afzal,
On 17.10.2012 07:42, Afzal Mohammed wrote:
> On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
>> I certainly don't think it is easier, rather tougher, cleaner
>> as well. One thing that worried me was, if we pursue the
>> auxdata path (a last resort option) and later if it is
>> objected, we would be back to square one.
>
> I commented on auxdata usage without visualising in more
> detail how it can be implemented, it was bad of me.
>
> I doubt whether auxdata would help here, it seems using
> compatible field alone would help in deciding relevant
> custom timing routine. Whether we want this kind of
> peripheral knowledge in gpmc driver instead of using
> generic timing routine has to be decided though.
Maybe slightly off-topic, but still:
When GPMC is used for driving NAND chips that comply to CFI, the timings
could actually be derived from the connected peripheral as well. I
believe a slowest-possible-mode will have to be selected first for the
identication phase.
Another thing that might be worth thinking about is that apart from the
GPMC host controller and the peripherals, there could be other
components like level shifters or series resistors on the board that
limit the maximum speed of transactions. So in fact we might be better
off storing all that timing details in the DT, as they are in fact
highly application specific.
Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox