* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-09-29 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929092828.GE19318@S2100-06.ap.freescale.net>
On Thu, Sep 29, 2011 at 05:28:29PM +0800, Shawn Guo wrote:
> On Sun, Sep 25, 2011 at 08:26:09PM -0700, Barry Song wrote:
> > we save the l2x0 registers at the first initialization, and platform codes
> > can get them to restore l2x0 status after wakeup.
> >
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> > ---
> > -v2:
> > define the structure l2x0_regs to hold all saved registers;
> > make saved copy of registers non-static so that platform codes can access them;
> > add asm_offset for l2x0 saved regs(l2x0_regs struct) so that asm codes can use
> >
>
> I'm trying to migrate imx6q to this infrastructure, but seeing some
> facts that might stop me from the effort. Please help me understand
> these facts are correct.
>
> It seems to me that the only benefit that imx6q gains from the
> infrastructure is the register saving, and I fail to see any benefit
> on the restoring.
That's correct - because I believe that's the only part which is worth
doing in common code. The restoring tends to be platform dependent so
I don't see the point of having a bunch of code in common files to do
that which almost no one uses.
> * I still have to save physical base of l2x0 for register restoring.
That could be added to the structure.
> * I do not have the physical address of l2x0_saved_regs, and I have
> to manage to get it somehow.
That's true no matter what - we could store the physical address of
the struct somewhere, but then in order for you to obtain that, you'd
somehow need to know the physical address of _that_ location too - so
there's no benefit there.
It can be obtained simply by: __pa(l2x0_saved_regs) in C code, and
saving that in a location known to the platform prior to suspend.
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Shawn Guo @ 2011-09-29 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317007569-31213-1-git-send-email-Baohua.Song@csr.com>
On Sun, Sep 25, 2011 at 08:26:09PM -0700, Barry Song wrote:
> we save the l2x0 registers at the first initialization, and platform codes
> can get them to restore l2x0 status after wakeup.
>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> -v2:
> define the structure l2x0_regs to hold all saved registers;
> make saved copy of registers non-static so that platform codes can access them;
> add asm_offset for l2x0 saved regs(l2x0_regs struct) so that asm codes can use
>
I'm trying to migrate imx6q to this infrastructure, but seeing some
facts that might stop me from the effort. Please help me understand
these facts are correct.
It seems to me that the only benefit that imx6q gains from the
infrastructure is the register saving, and I fail to see any benefit
on the restoring.
* I still have to save physical base of l2x0 for register restoring.
* I do not have the physical address of l2x0_saved_regs, and I have
to manage to get it somehow.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Barry Song @ 2011-09-29 9:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Barry Song <baohua.song@csr.com>
Some devices like mmc are async detected very slow. For example,
drivers/mmc/host/sdhci.c launchs a 200ms delayed work to detect
mmc partitions then add disk.
we do have wait_for_device_probe and scsi_complete_async_scans
before calling swsusp_check, but it is not enough to wait mmc.
This patch adds resumewait kernel param just like rootwait so
that we have enough time to wait mmc ready. The differene is
here we wait for resume partition but rootwait waits for rootfs
partition.
This patch will make swsusp support many embedded products
without scsi devices but devices like mmc.
This was tested on one ARM platform with Frank Hofmann's patch.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
kernel/power/hibernate.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 8f7b1db..9f4b4f3 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -14,6 +14,7 @@
#include <linux/reboot.h>
#include <linux/string.h>
#include <linux/device.h>
+#include <linux/async.h>
#include <linux/kmod.h>
#include <linux/delay.h>
#include <linux/fs.h>
@@ -31,6 +32,7 @@
static int nocompress = 0;
static int noresume = 0;
+static int resume_wait = 0;
static char resume_file[256] = CONFIG_PM_STD_PARTITION;
dev_t swsusp_resume_device;
sector_t swsusp_resume_block;
@@ -732,6 +734,13 @@ static int software_resume(void)
* to wait for this to finish.
*/
wait_for_device_probe();
+
+ if (resume_wait) {
+ while ((swsusp_resume_device = name_to_dev_t(resume_file)) == 0)
+ msleep(10);
+ async_synchronize_full();
+ }
+
/*
* We can't depend on SCSI devices being available after loading
* one of their modules until scsi_complete_async_scans() is
@@ -1060,7 +1069,14 @@ static int __init noresume_setup(char *str)
return 1;
}
+static int __init resumewait_setup(char *str)
+{
+ resume_wait = 1;
+ return 1;
+}
+
__setup("noresume", noresume_setup);
__setup("resume_offset=", resume_offset_setup);
__setup("resume=", resume_setup);
__setup("hibernate=", hibernate_setup);
+__setup("resumewait", resumewait_setup);
--
1.7.1
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply related
* [PATCH v5 2/3] arm/tegra: add support for ventana pinmuxing
From: Russell King - ARM Linux @ 2011-09-29 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317248978-10829-3-git-send-email-pdeschrijver@nvidia.com>
On Thu, Sep 29, 2011 at 01:29:35AM +0300, Peter De Schrijver wrote:
> diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
> index f11b910..91a07e1 100644
> --- a/arch/arm/mach-tegra/Makefile
> +++ b/arch/arm/mach-tegra/Makefile
> @@ -31,6 +31,7 @@ obj-${CONFIG_MACH_SEABOARD} += board-seaboard-pinmux.o
>
> obj-${CONFIG_MACH_TEGRA_DT} += board-dt.o
> obj-${CONFIG_MACH_TEGRA_DT} += board-harmony-pinmux.o
> +obj-${CONFIG_MACH_TEGRA_DT} += board-seaboard-pinmux.o
Since when did Tegra start using braces instead of parens in its Makefile?
I note some of Tegra's makefile is using braces and some of it parens.
What's the reason for this alternative style to the rest of kbuild?
^ permalink raw reply
* [PATCHv2 02/10] ARM: vic: MULTI_IRQ_HANDLER handler
From: Jamie Iles @ 2011-09-29 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZKns-GraGp-YMD6jzOPETkvEpt9bC8HcYUmf3JUyCV3A@mail.gmail.com>
On Thu, Sep 29, 2011 at 08:55:08AM +0200, Linus Walleij wrote:
> On Wed, Sep 28, 2011 at 10:39 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>
> > Why isn't it simply written this way:
> >
> > ? ? ? ?stat = readl_relaxed(vic->base + VIC_IRQ_STATUS);
> > ? ? ? ?while (stat) {
> > ? ? ? ? ? ? ? ?irq = fls(stat) - 1;
> > ? ? ? ? ? ? ? ?handle_IRQ(irq_domain_to_irq(&vic->domain, irq), regs);
> > ? ? ? ? ? ? ? ?stat &= ~(1 << irq);
> > ? ? ? ?}
>
> That is indeed closer to the assembly loop most platforms have
> implemented.
>
> Jamie can you test this approach? And also use ffs() insteadof
> fls()...
OK, here it is (and it works)! That does make it a lot simpler, thanks
guys! I've updated the vic-dt branch in my repo too.
Jamie
8<------
From: Jamie Iles <jamie@jamieiles.com>
Subject: [PATCHv3] ARM: vic: MULTI_IRQ_HANDLER handler
Add a handler for the VIC that is suitable for MULTI_IRQ_HANDLER
platforms. This can replace the ASM entry macros for platforms that use
the VIC.
v3: - simplify irq handling loop as suggested by Grant
- service interrupts from msb->lsb order
v2: - allow the handler be used for !CONFIG_OF
- use irq_domain_to_irq()
Cc: Rob Herring <robherring2@gmail.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
arch/arm/common/vic.c | 22 ++++++++++++++++++++++
arch/arm/include/asm/hardware/vic.h | 4 ++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c
index 3f9c8f2..b22b83d 100644
--- a/arch/arm/common/vic.c
+++ b/arch/arm/common/vic.c
@@ -427,3 +427,25 @@ int __init vic_of_init(struct device_node *node, struct device_node *parent)
return -EIO;
}
#endif /* CONFIG OF */
+
+#ifdef CONFIG_MULTI_IRQ_HANDLER
+static void vic_single_handle_irq(struct vic_device *vic, struct pt_regs *regs)
+{
+ u32 stat, irq;
+
+ stat = readl_relaxed(vic->base + VIC_IRQ_STATUS);
+ while (stat) {
+ irq = ffs(stat) - 1;
+ handle_IRQ(irq_domain_to_irq(&vic->domain, irq), regs);
+ stat &= ~(1 << irq);
+ }
+}
+
+asmlinkage void __exception_irq_entry vic_handle_irq(struct pt_regs *regs)
+{
+ int i;
+
+ for (i = 0; i < vic_id; ++i)
+ vic_single_handle_irq(&vic_devices[i], regs);
+}
+#endif /* CONFIG_MULTI_IRQ_HANDLER */
diff --git a/arch/arm/include/asm/hardware/vic.h b/arch/arm/include/asm/hardware/vic.h
index 0135215..c02fd6f 100644
--- a/arch/arm/include/asm/hardware/vic.h
+++ b/arch/arm/include/asm/hardware/vic.h
@@ -45,11 +45,15 @@
#include <linux/types.h>
struct device_node;
+struct pt_regs;
+
void vic_init(void __iomem *base, unsigned int irq_start, u32 vic_sources, u32 resume_sources);
#ifdef CONFIG_OF
int vic_of_init(struct device_node *node, struct device_node *parent);
#endif /* CONFIG_OF */
+void vic_handle_irq(struct pt_regs *regs);
+
#endif /* __ASSEMBLY__ */
#endif
--
1.7.4.1
^ permalink raw reply related
* [PATCH v4 2/7] arm/imx6q: add core definitions and low-level debug uart
From: Russell King - ARM Linux @ 2011-09-29 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317200808-6275-3-git-send-email-shawn.guo@linaro.org>
On Wed, Sep 28, 2011 at 05:06:43PM +0800, Shawn Guo wrote:
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index 502e45f..e2e3e5a 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -29,6 +29,13 @@ config ARCH_MX5
> This enables support for machines using Freescale's i.MX50 and i.MX51
> processors.
>
> +config ARCH_MX6
> + bool "i.MX6"
> + select AUTO_ZRELADDR
This bars you from building a working kernel with ZBOOT_ROM=y. You can
still select ZBOOT_ROM=y but things won't work.
^ permalink raw reply
* [PATCH v4 3/7] arm/imx: add gic_handle_irq function
From: Russell King - ARM Linux @ 2011-09-29 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317200808-6275-4-git-send-email-shawn.guo@linaro.org>
On Wed, Sep 28, 2011 at 05:06:44PM +0800, Shawn Guo wrote:
> +#ifdef CONFIG_SMP
> + else if (irqnr < 16) {
> + writel_relaxed(irqstat, gic_cpu_base_addr +
> + GIC_CPU_EOI);
> + do_IPI(irqnr, regs);
> + }
> +#endif
> +#ifdef CONFIG_LOCAL_TIMERS
> + else if (irqnr == 29) {
> + writel_relaxed(irqstat, gic_cpu_base_addr +
> + GIC_CPU_EOI);
> + do_local_timer(regs);
> + }
> +#endif
As I've said for similar patches. neither of these two functions are
designed to be called from another C function (because they're marked
__exception or __exception_irq_entry). Both of these markers tell the
unwinder that a struct pt_regs is located directly above the functions
stack frame.
^ permalink raw reply
* [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
From: Will Deacon @ 2011-09-29 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929092102.GB25061@e102144-lin.cambridge.arm.com>
On Thu, Sep 29, 2011 at 10:21:02AM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2011 at 03:05:16AM +0100, Stephen Boyd wrote:
> > Chatting with David Brown made me realize that this patch now forces
> > ICEDCC for anybody who selects DEBUG_LL and hasn't moved to adding a
> > Kconfig in the choice menu. I'm not sure if that actually matters since
> > it may be incentive to put your machine of choice into this menu.
> >
> > Otherwise, we may want to drop this until a later point, or just leave
> > it out of the choice menu altogether.
>
> Given that the ICEDCC stuff shouldn't cause any other problems by having it
> enabled (that is, your kernel should still boot) then we should be alright
> leaving this as-is while platforms move over to the new scheme.
Bah, just took this for a spin on my Realview-PBX (Cortex-A9) platform and
the board won't boot unless I have a hardware debugger enabled that can
service the comms channel. This contradicts the Kconfig text which says:
It does include a timeout to ensure that the system does not
totally freeze when there is nothing connected to read.
so we certainly need to fix something!
Will
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Barry Song @ 2011-09-29 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929092828.GE19318@S2100-06.ap.freescale.net>
2011/9/29 Shawn Guo <shawn.guo@freescale.com>:
> On Sun, Sep 25, 2011 at 08:26:09PM -0700, Barry Song wrote:
>> we save the l2x0 registers at the first initialization, and platform codes
>> can get them to restore l2x0 status after wakeup.
>>
>> Cc: Shawn Guo <shawn.guo@linaro.org>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Signed-off-by: Barry Song <Baohua.Song@csr.com>
>> ---
>> ?-v2:
>> ?define the structure l2x0_regs to hold all saved registers;
>> ?make saved copy of registers non-static so that platform codes can access them;
>> ?add asm_offset for l2x0 saved regs(l2x0_regs struct) so that asm codes can use
>>
>
> I'm trying to migrate imx6q to this infrastructure, but seeing some
> facts that might stop me from the effort. ?Please help me understand
> these facts are correct.
>
> It seems to me that the only benefit that imx6q gains from the
> infrastructure is the register saving, and I fail to see any benefit
> on the restoring.
>
> ?* I still have to save physical base of l2x0 for register restoring.
> ?* I do not have the physical address of l2x0_saved_regs, and I have
> ? to manage to get it somehow.
well. the phyical address should be added so that mmu-off asm codes can get it.
>
> --
> Regards,
> Shawn
-barry
^ permalink raw reply
* [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
From: Russell King - ARM Linux @ 2011-09-29 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929094243.GC25061@e102144-lin.cambridge.arm.com>
On Thu, Sep 29, 2011 at 10:42:43AM +0100, Will Deacon wrote:
> Bah, just took this for a spin on my Realview-PBX (Cortex-A9) platform and
> the board won't boot unless I have a hardware debugger enabled that can
> service the comms channel. This contradicts the Kconfig text which says:
>
> It does include a timeout to ensure that the system does not
> totally freeze when there is nothing connected to read.
>
> so we certainly need to fix something!
One of the problems you'll encounter is that there's places where we
don't have any timer infrastructure (eg, decompressor) and software
timing loops won't work (they'll be too slow for the lower-end CPUs
and too fast for the upper-end CPUs.)
The best fix is probably to leave that as-is, but introduce a 'default'
output entry instead - so platforms which don't have any listed will
get that instead of the ICEDDC stuff.
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Lorenzo Pieralisi @ 2011-09-29 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8403BE.9050302@ti.com>
On Thu, Sep 29, 2011 at 06:35:58AM +0100, Santosh Shilimkar wrote:
> Barry,
>
> On Monday 26 September 2011 08:56 AM, Barry Song wrote:
> > we save the l2x0 registers at the first initialization, and platform codes
> > can get them to restore l2x0 status after wakeup.
> >
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> > ---
[...]
> > +
> > +struct l2x0_regs {
> > + unsigned long aux_ctrl;
> > + /*
> > + * Whether the following registers need to be saved/restored
> > + * depends on platform
> > + */
> > + unsigned long tag_latency;
> > + unsigned long data_latency;
> > + unsigned long filter_start;
> > + unsigned long filter_end;
> > +};
> > +
> You are missing POR register here which is available on
> PL310 versions. You should add that.
>
In latest versions there are Prefetch and Power control registers, but
it depends on the revision. What should we do in this case Santosh ?
PCR is a superset of POR from r3p0 onwards, but Power control ? Leave it
to platform code ?
> [...]
> > static inline void outer_inv_range(phys_addr_t start, phys_addr_t end)
> > diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> > index 16baba2..b8d72a8 100644
> > --- a/arch/arm/kernel/asm-offsets.c
> > +++ b/arch/arm/kernel/asm-offsets.c
> > @@ -20,6 +20,7 @@
> > #include <asm/thread_info.h>
> > #include <asm/memory.h>
> > #include <asm/procinfo.h>
> > +#include <asm/hardware/cache-l2x0.h>
> > #include <linux/kbuild.h>
> >
> > /*
> > @@ -92,6 +93,14 @@ int main(void)
> > DEFINE(S_OLD_R0, offsetof(struct pt_regs, ARM_ORIG_r0));
> > DEFINE(S_FRAME_SIZE, sizeof(struct pt_regs));
> > BLANK();
> > +#ifdef CONFIG_CACHE_L2X0
> > + DEFINE(L2X0_R_AUX_CTRL, offsetof(struct l2x0_regs, aux_ctrl));
> > + DEFINE(L2X0_R_TAG_LATENCY, offsetof(struct l2x0_regs, tag_latency));
> > + DEFINE(L2X0_R_DATA_LATENCY, offsetof(struct l2x0_regs, data_latency));
> > + DEFINE(L2X0_R_FILTER_START, offsetof(struct l2x0_regs, filter_start));
> > + DEFINE(L2X0_R_FILTER_END, offsetof(struct l2x0_regs, filter_end));
> Add POR as commented earlier.
See above.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Santosh Shilimkar @ 2011-09-29 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929102213.GB7453@e102568-lin.cambridge.arm.com>
On Thursday 29 September 2011 03:52 PM, Lorenzo Pieralisi wrote:
> On Thu, Sep 29, 2011 at 06:35:58AM +0100, Santosh Shilimkar wrote:
>> Barry,
>>
>> On Monday 26 September 2011 08:56 AM, Barry Song wrote:
>>> we save the l2x0 registers at the first initialization, and platform codes
>>> can get them to restore l2x0 status after wakeup.
>>>
>>> Cc: Shawn Guo <shawn.guo@linaro.org>
>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> Signed-off-by: Barry Song <Baohua.Song@csr.com>
>>> ---
>
> [...]
>
>>> +
>>> +struct l2x0_regs {
>>> + unsigned long aux_ctrl;
>>> + /*
>>> + * Whether the following registers need to be saved/restored
>>> + * depends on platform
>>> + */
>>> + unsigned long tag_latency;
>>> + unsigned long data_latency;
>>> + unsigned long filter_start;
>>> + unsigned long filter_end;
>>> +};
>>> +
>> You are missing POR register here which is available on
>> PL310 versions. You should add that.
>>
>
> In latest versions there are Prefetch and Power control registers, but
> it depends on the revision. What should we do in this case Santosh ?
> PCR is a superset of POR from r3p0 onwards, but Power control ? Leave it
> to platform code ?
>
Good point Lorenzo.
C code resume can be fixed by marking the validity based
on PL310 revision register.
The asm code restore with MMU OFF code, would be handled
with platform code with this patch and platform code can choose
restore of only supported registers.
Regards
Santosh
^ permalink raw reply
* [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
From: Will Deacon @ 2011-09-29 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929094602.GH23944@n2100.arm.linux.org.uk>
Hi Russell,
On Thu, Sep 29, 2011 at 10:46:02AM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 29, 2011 at 10:42:43AM +0100, Will Deacon wrote:
> > Bah, just took this for a spin on my Realview-PBX (Cortex-A9) platform and
> > the board won't boot unless I have a hardware debugger enabled that can
> > service the comms channel. This contradicts the Kconfig text which says:
> >
> > It does include a timeout to ensure that the system does not
> > totally freeze when there is nothing connected to read.
> >
> > so we certainly need to fix something!
>
> One of the problems you'll encounter is that there's places where we
> don't have any timer infrastructure (eg, decompressor) and software
> timing loops won't work (they'll be too slow for the lower-end CPUs
> and too fast for the upper-end CPUs.)
Agreed, software timing loops are the only option and it's impossible to get
them right everywhere. I think the Kconfig help text should be updated so
that the timeout paragraph is removed.
> The best fix is probably to leave that as-is, but introduce a 'default'
> output entry instead - so platforms which don't have any listed will
> get that instead of the ICEDDC stuff.
Ok. Rather than 'default' (which people will probably select in preference
to choosing the correct UART) how about something like below? I can split
this into two patches if you prefer.
Will
----8<----
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 32b1be4..bfdf86b 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -81,6 +81,14 @@ choice
prompt "Kernel low-level debugging port"
depends on DEBUG_LL
+ config DEBUG_LL_UART_NONE
+ bool "No low-level debugging UART"
+ help
+ Say Y here if your platform doesn't provide a UART option
+ below. This relies on your platform choosing the right UART
+ definition internally in order for low-level debugging to
+ work.
+
config DEBUG_ICEDCC
bool "Kernel low-level debugging via EmbeddedICE DCC channel"
help
@@ -89,8 +97,8 @@ choice
co-processor 14. This is known to work on the ARM9 style ICE
channel and on the XScale with the PEEDI.
- It does include a timeout to ensure that the system does not
- totally freeze when there is nothing connected to read.
+ Note that this may cause the system to hang during boot if
+ there is nothing to read from the DCC.
config DEBUG_FOOTBRIDGE_COM1
bool "Kernel low-level debugging messages via footbridge 8250@PCI COM1"
^ permalink raw reply related
* [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
From: Russell King - ARM Linux @ 2011-09-29 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929103939.GD25061@e102144-lin.cambridge.arm.com>
On Thu, Sep 29, 2011 at 11:39:39AM +0100, Will Deacon wrote:
> Ok. Rather than 'default' (which people will probably select in preference
> to choosing the correct UART) how about something like below? I can split
> this into two patches if you prefer.
Yup, that's what I meant.
^ permalink raw reply
* [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: Mark Brown @ 2011-09-29 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110928231410.GF2838@ponder.secretlab.ca>
On Wed, Sep 28, 2011 at 06:14:10PM -0500, Grant Likely wrote:
> For your question, I still think it is the driver that gets to make
> the decision. If it can proceed without a resource, then it should go
> ahead and succeed on the probe, and then arrange to either be notified
> of new gpio controller (or whatever) registrations, or poll for the
> resource to be set up.
Right, I do tend to agree. This is something we'll have to bear in mind
when deploying this stuff - drivers that are doing this sort of stuff
are going to get surprised.
^ permalink raw reply
* [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Valdis.Kletnieks at vt.edu @ 2011-09-29 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317288548-19560-1-git-send-email-Barry.Song@csr.com>
On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:
> This patch adds resumewait kernel param just like rootwait so
> that we have enough time to wait mmc ready. The differene is
> here we wait for resume partition but rootwait waits for rootfs
> partition.
OK, seems a reasonable idea...
> kernel/power/hibernate.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
We have a __setup() parameter, this patch appears to be missing
a hunk for Documentation/kernel-parameters.txt?
Fix that issue, and you can stick this on there:
Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110929/d6c2e289/attachment.sig>
^ permalink raw reply
* [PATCH] PM: HIBERNATION: add resume_wait param to support MMC-like devices as resume file
From: Barry Song @ 2011-09-29 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <59872.1317299401@turing-police.cc.vt.edu>
hi Valdis,
2011/9/29 <Valdis.Kletnieks@vt.edu>:
> On Thu, 29 Sep 2011 02:29:08 PDT, Barry Song said:
>
>> This patch adds resumewait kernel param just like rootwait so
>> that we have enough time to wait mmc ready. The differene is
>> here we wait for resume partition but rootwait waits for rootfs
>> partition.
>
> OK, seems a reasonable idea...
>
>> kernel/power/hibernate.c | ? 16 ++++++++++++++++
>> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> We have a __setup() parameter, this patch appears to be missing
> a hunk for Documentation/kernel-parameters.txt?
>
> Fix that issue, and you can stick this on there:
>
> Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
thanks. i'll add the document in v2.
-barry
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Shawn Guo @ 2011-09-29 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929092406.GD23944@n2100.arm.linux.org.uk>
On Thu, Sep 29, 2011 at 10:24:06AM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 29, 2011 at 05:28:29PM +0800, Shawn Guo wrote:
> > On Sun, Sep 25, 2011 at 08:26:09PM -0700, Barry Song wrote:
> > > we save the l2x0 registers at the first initialization, and platform codes
> > > can get them to restore l2x0 status after wakeup.
> > >
> > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> > > ---
> > > -v2:
> > > define the structure l2x0_regs to hold all saved registers;
> > > make saved copy of registers non-static so that platform codes can access them;
> > > add asm_offset for l2x0 saved regs(l2x0_regs struct) so that asm codes can use
> > >
> >
> > I'm trying to migrate imx6q to this infrastructure, but seeing some
> > facts that might stop me from the effort. Please help me understand
> > these facts are correct.
> >
> > It seems to me that the only benefit that imx6q gains from the
> > infrastructure is the register saving, and I fail to see any benefit
> > on the restoring.
>
> That's correct - because I believe that's the only part which is worth
> doing in common code. The restoring tends to be platform dependent so
> I don't see the point of having a bunch of code in common files to do
> that which almost no one uses.
>
> > * I still have to save physical base of l2x0 for register restoring.
>
> That could be added to the structure.
>
> > * I do not have the physical address of l2x0_saved_regs, and I have
> > to manage to get it somehow.
>
> That's true no matter what - we could store the physical address of
> the struct somewhere, but then in order for you to obtain that, you'd
> somehow need to know the physical address of _that_ location too - so
> there's no benefit there.
>
> It can be obtained simply by: __pa(l2x0_saved_regs) in C code, and
> saving that in a location known to the platform prior to suspend.
>
Yeah, that's why I want to get imx6q stay away from this infrastructure
right now. I do not see any simplicity and cleanup on imx6q current
code by migrating to this infrastructure.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-09-29 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929124419.GF19318@S2100-06.ap.freescale.net>
On Thu, Sep 29, 2011 at 08:44:20PM +0800, Shawn Guo wrote:
> Yeah, that's why I want to get imx6q stay away from this infrastructure
> right now. I do not see any simplicity and cleanup on imx6q current
> code by migrating to this infrastructure.
Why? If the data is already saved for you, then there's no reason not
to use it. The fact that some generic code doesn't give you _exactly_
everything you'd want is not a reason to avoid it.
The cleanup for imx6q is that it would no longer have to have its own
distinct code for saving the register values - and that's a danmed good
thing.
The idea here is that we consolidate what _can_ be consolidated (which
is the register saving.)
If you feel soo strongly that it's not worth doing, then let's stop
wasting time and review effort on this, and instead have _every_ SoC
implementing their own private L2 cache handling on resume.
^ permalink raw reply
* Long stalls during boot with -next
From: Mark Brown @ 2011-09-29 12:50 UTC (permalink / raw)
To: linux-arm-kernel
Since Tuesday I've been experiencing stalls on boot with -next kernels.
The boot appears to proceed normally but there appears to be a good ten
second delay somewhere around the late_initcall() stage with no
indication in the logs:
[ 3.110000] regulator_init_complete: PVDD_1V2: disabling
[ 3.120000] input: gpio-keys as /devices/platform/gpio-keys.0/input/input5
[ 3.120000] wm831x-rtc wm831x-rtc.10: hctosys: unable to read the hardware clock
[ 13.690000] kjournald starting. Commit interval 5 seconds
[ 13.690000] EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended
(which happens before or at about the time console output starts
appearing, I'd expect it to appear much earlier). I've had a poke
around and I didn't spot anything yet, none of the development I've
noticed going on recently looks suspicious.
^ permalink raw reply
* Long stalls during boot with -next
From: Takashi Iwai @ 2011-09-29 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929125035.GA2085@sirena.org.uk>
At Thu, 29 Sep 2011 13:50:36 +0100,
Mark Brown wrote:
>
> Since Tuesday I've been experiencing stalls on boot with -next kernels.
> The boot appears to proceed normally but there appears to be a good ten
> second delay somewhere around the late_initcall() stage with no
> indication in the logs:
>
> [ 3.110000] regulator_init_complete: PVDD_1V2: disabling
> [ 3.120000] input: gpio-keys as /devices/platform/gpio-keys.0/input/input5
> [ 3.120000] wm831x-rtc wm831x-rtc.10: hctosys: unable to read the hardware clock
> [ 13.690000] kjournald starting. Commit interval 5 seconds
> [ 13.690000] EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended
>
> (which happens before or at about the time console output starts
> appearing, I'd expect it to appear much earlier). I've had a poke
> around and I didn't spot anything yet, none of the development I've
> noticed going on recently looks suspicious.
Did you check with initcall_debug boot option?
Takashi
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Shawn Guo @ 2011-09-29 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929125026.GJ23944@n2100.arm.linux.org.uk>
On Thu, Sep 29, 2011 at 01:50:26PM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 29, 2011 at 08:44:20PM +0800, Shawn Guo wrote:
> > Yeah, that's why I want to get imx6q stay away from this infrastructure
> > right now. I do not see any simplicity and cleanup on imx6q current
> > code by migrating to this infrastructure.
>
> Why? If the data is already saved for you, then there's no reason not
> to use it. The fact that some generic code doesn't give you _exactly_
> everything you'd want is not a reason to avoid it.
>
> The cleanup for imx6q is that it would no longer have to have its own
> distinct code for saving the register values - and that's a danmed good
> thing.
>
It cleans up the register saving but requires additional code handling
physical address of l2x0_saved_regs.
> The idea here is that we consolidate what _can_ be consolidated (which
> is the register saving.)
>
> If you feel soo strongly that it's not worth doing, then let's stop
> wasting time and review effort on this, and instead have _every_ SoC
> implementing their own private L2 cache handling on resume.
>
This infrastructure is definitely good thing for platform that L2 will
be lost during suspend. But for imx6q which retains L2, I would not
migrate it until the physical base of L2 and l2x0_saved_regs itself can
be retrieved from infrastructure too.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2] ARM: cache-l2x0: add resume entry for l2 in secure mode
From: Russell King - ARM Linux @ 2011-09-29 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929131229.GG19318@S2100-06.ap.freescale.net>
On Thu, Sep 29, 2011 at 09:12:31PM +0800, Shawn Guo wrote:
> On Thu, Sep 29, 2011 at 01:50:26PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 29, 2011 at 08:44:20PM +0800, Shawn Guo wrote:
> > > Yeah, that's why I want to get imx6q stay away from this infrastructure
> > > right now. I do not see any simplicity and cleanup on imx6q current
> > > code by migrating to this infrastructure.
> >
> > Why? If the data is already saved for you, then there's no reason not
> > to use it. The fact that some generic code doesn't give you _exactly_
> > everything you'd want is not a reason to avoid it.
> >
> > The cleanup for imx6q is that it would no longer have to have its own
> > distinct code for saving the register values - and that's a danmed good
> > thing.
> >
> It cleans up the register saving but requires additional code handling
> physical address of l2x0_saved_regs.
>
> > The idea here is that we consolidate what _can_ be consolidated (which
> > is the register saving.)
> >
> > If you feel soo strongly that it's not worth doing, then let's stop
> > wasting time and review effort on this, and instead have _every_ SoC
> > implementing their own private L2 cache handling on resume.
> >
> This infrastructure is definitely good thing for platform that L2 will
> be lost during suspend. But for imx6q which retains L2, I would not
> migrate it until the physical base of L2 and l2x0_saved_regs itself can
> be retrieved from infrastructure too.
Putting the physical base of the L2 cache inside l2x0_saved_regs is
trivial (and I think will probably be done.)
What _can't_ be done - because it's _totally_ idiotic as I previously
described - is to do anything about the physical address of l2x0_saved_regs
itself.
Look - think about it for a moment. Let's say we do:
struct l2x0_saved_regs l2x0_saved_regs;
unsigned long phys_l2x0_saved_regs;
l2x0_init()
{
phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
}
Does this buy us anything? It most certainly does not - it actually
buys us additional complexity, because now we need to have platform
code knowing the _physical_ address of phys_l2x0_saved_regs in order to
get the _physical_ address of l2x0_saved_regs. Totally idiotic and
pointless - platform code might as well just use __pa(&l2x0_saved_regs)
directly in its suspend path to place it _somewhere_ that its own L2
resume code (which common code has no knowledge of) can access.
It's not that big a deal in any case - you can do this in your platform
code:
.data
.globl phys_l2x0_saved_regs
phys_l2x0_saved_regs:
.long 0
which the resume code can then access directly - and then obtain the values
directly from the l2x0_saved_reg structure.
And in your suspend initialization:
extern unsigned long phys_l2x0_saved_regs;
int my_suspend_init()
{
...
phys_l2x0_saved_regs = __pa(&l2x0_saved_regs);
}
So I think you're barking up the wrong tree if you think there's
*anything* which generic code can do to make access to l2x0_saved_regs
any easier than it is in this patch.
^ permalink raw reply
* [PATCH V2 11/16] mmc: omap_hsmmc: ensure pbias configuration is always done
From: T Krishnamoorthy, Balaji @ 2011-09-29 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1304673255-31634-12-git-send-email-adrian.hunter@nokia.com>
On Fri, May 6, 2011 at 2:44 PM, Adrian Hunter <adrian.hunter@nokia.com> wrote:
> Go through the driver's set_power() functions rather than
> calling regulator_enable/disable() directly because otherwise
> pbias configuration for MMC1 is not done.
Hi Chris,
Are you OK to queue this patch as bug fix. Rest of the patches of this
series is either
merged or not needed. Should I rebase and repost this alone ?
FWIW:
Acked-by: Balaji T K <balajitk@ti.com>
>
> Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
> ---
> ?drivers/mmc/host/omap_hsmmc.c | ? 17 ++++++++---------
> ?1 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 4f6e552..8aa9440 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -445,15 +445,14 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
> ? ? ? ? ? ? ? ?* framework is fixed, we need a workaround like this
> ? ? ? ? ? ? ? ?* (which is safe for MMC, but not in general).
> ? ? ? ? ? ? ? ?*/
> - ? ? ? ? ? ? ? if (regulator_is_enabled(host->vcc) > 0) {
> - ? ? ? ? ? ? ? ? ? ? ? regulator_enable(host->vcc);
> - ? ? ? ? ? ? ? ? ? ? ? regulator_disable(host->vcc);
> - ? ? ? ? ? ? ? }
> - ? ? ? ? ? ? ? if (host->vcc_aux) {
> - ? ? ? ? ? ? ? ? ? ? ? if (regulator_is_enabled(reg) > 0) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? regulator_enable(reg);
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? regulator_disable(reg);
> - ? ? ? ? ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? if (regulator_is_enabled(host->vcc) > 0 ||
> + ? ? ? ? ? ? ? ? ? (host->vcc_aux && regulator_is_enabled(host->vcc_aux))) {
> + ? ? ? ? ? ? ? ? ? ? ? int vdd = ffs(mmc_slot(host).ocr_mask) - 1;
> +
> + ? ? ? ? ? ? ? ? ? ? ? mmc_slot(host).set_power(host->dev, host->slot_id,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1, vdd);
> + ? ? ? ? ? ? ? ? ? ? ? mmc_slot(host).set_power(host->dev, host->slot_id,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0, 0);
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Long stalls during boot with -next
From: Mark Brown @ 2011-09-29 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <s5hfwjfa4df.wl%tiwai@suse.de>
On Thu, Sep 29, 2011 at 03:02:20PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:
> > (which happens before or at about the time console output starts
> > appearing, I'd expect it to appear much earlier). I've had a poke
> > around and I didn't spot anything yet, none of the development I've
> > noticed going on recently looks suspicious.
> Did you check with initcall_debug boot option?
Oh, I forgot to mention - that appears to make the 10s delay go down to
5s which isn't terribly helpful - it looks like the additional logging
causes some substantial reordering of some of the asynchronous parts of
boot, mainly the USB probe and accessory detection which previously
Completed earlier. It does also appear that some of the user visible
delay here is coming prior to the kernel taking over so probably some
ARM boot code is taking a chunk of time also.
[ 2.130000] wm831x-rtc wm831x-rtc.10: hctosys: unable to read the hardware clock
[ 2.130000] initcall rtc_hctosys+0x0/0x120 returned -22 after 0 usecs
[ 2.130000] initcall rtc_hctosys+0x0/0x120 returned with error code -22
[ 2.140000] calling net_secret_init+0x0/0x24 @ 1
[ 2.140000] initcall net_secret_init+0x0/0x24 returned 0 after 0 usecs
[ 2.140000] calling tcp_congestion_default+0x0/0x1c @ 1
[ 2.140000] initcall tcp_congestion_default+0x0/0x1c returned 0 after 0 usecs
[ 2.140000] calling ip_auto_config+0x0/0x224 @ 1
[ 2.140000] initcall ip_auto_config+0x0/0x224 returned 0 after 0 usecs
[ 2.140000] calling initialize_hashrnd+0x0/0x24 @ 1
[ 2.140000] initcall initialize_hashrnd+0x0/0x24 returned 0 after 0 usecs
[ 2.150000] async_waiting @ 1
[ 2.150000] async_continuing @ 1 after 0 usec
[ 2.240000] usb 1-1.1: udev 3, busnum 1, minor = 2
[ 2.240000] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2514
[ 2.240000] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber
=0
[ 2.250000] usb 1-1.1: usb_probe_device
[ 2.250000] usb 1-1.1: configuration #1 chosen from 1 choice
[ 2.250000] usb 1-1.1: adding 1-1.1:1.0 (config #1, interface 0)
[ 2.250000] hub 1-1.1:1.0: usb_probe_interface
[ 2.250000] hub 1-1.1:1.0: usb_probe_interface - got id
[ 2.250000] hub 1-1.1:1.0: USB hub found
[ 2.260000] hub 1-1.1:1.0: 4 ports detected
[ 2.260000] hub 1-1.1:1.0: standalone hub
[ 2.260000] hub 1-1.1:1.0: individual port power switching
[ 2.260000] hub 1-1.1:1.0: individual port over-current protection
[ 2.260000] hub 1-1.1:1.0: power on to power good time: 100ms
[ 2.260000] hub 1-1.1:1.0: local power source is good
[ 2.260000] hub 1-1.1:1.0: enabling power on all ports
[ 2.270000] drivers/usb/core/inode.c: creating file '003'
[ 2.270000] hub 1-1:1.0: state 7 ports 4 chg 0000 evt 0002
[ 2.370000] hub 1-1.1:1.0: state 7 ports 4 chg 0000 evt 0000
[ 2.970000] wm8996 1-001a: Microphone event: 402
[ 2.970000] wm8996 1-001a: Jack removal detected
[ 9.270000] kjournald starting. Commit interval 5 seconds
^ 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