* [PATCH] ARM: shmobile: r8a7778 dtsi: Remove duplicate i2c nodes
From: Simon Horman @ 2014-02-13 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392039739-22571-1-git-send-email-geert+renesas@linux-m68k.org>
On Mon, Feb 10, 2014 at 02:42:19PM +0100, Geert Uytterhoeven wrote:
> "ARM: shmobile: r8a7778: add I2C support on DTSI" was applied twice:
>
> commit ae4273ec7b25c8b9c895a4aae31f2fced980b7bf
> commit 3acb51b9215bd99da403ecf8200f8425176b1926
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH] ARM: shmobile: Remove legacy r8a7790 DT clocks
From: Simon Horman @ 2014-02-13 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212040937.9955.38466.sendpatchset@w520>
On Wed, Feb 12, 2014 at 01:09:37PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> The DT device case is handled by CCF these days, so get
> rid of DT devices from the legacy clocks for r8a7790.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
Thanks, I have queued this up.
^ permalink raw reply
* [PATCH v3 7/7] devicetree: bindings: Document PM8921/8058 PMICs
From: Stephen Boyd @ 2014-02-13 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211092937.GG32042@lee--X1>
On 02/11, Lee Jones wrote:
>
> > +- interrupts:
> > + Usage: required
> > + Value type: <prop-encoded-array>
>
> Either provide an example or a comment to see the description of
> #interrupt-cells
It is part of the example. We also state that the format is
defined by the interrupt parent binding.
>
> > + Definition: specifies the interrupt that indicates a subdevice
> > + has generated an interrupt (summary interrupt). The
> > + format of the specifier is defined by the binding document
> > + describing the node's interrupt parent.
> > +
> > +- #interrupt-cells:
> > + Usage: required
> > + Value type : <u32>
> > + Definition: must be 2. Specifies the number of cells needed to encode
> > + an interrupt source. The 1st cell contains the interrupt
> > + number. The 2nd cell is the trigger type and level flags
> > + encoded as follows:
> > +
> > + 1 = low-to-high edge triggered
> > + 2 = high-to-low edge triggered
> > + 4 = active high level-sensitive
> > + 8 = active low level-sensitive
>
> Actually I'd prefer if you used the definitions in:
> dt-bindings/interrupt-controller/irq.h
These match the #defines in that file. I'd like to be explicit
about the numbers to prevent people from thinking they have to
use #defines and to match what other irq controllers have done
(gic, atmel-aic, etc.)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 0/7] ARM: shmobile: r8a7790/Lager QSPI SoC/board integration
From: Simon Horman @ 2014-02-13 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoQZBTYXwDcfzxqs9X-o2Yftvr=TM4dLgeMagr-LGdm1uw@mail.gmail.com>
On Wed, Feb 12, 2014 at 02:01:01PM +0900, Magnus Damm wrote:
> Hi Geert, Simon,
>
> On Mon, Feb 10, 2014 at 7:47 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > Hi Simon, Magnus,
> >
> > The following patch series completes r8a7790 SoC and Lager board
> > integration for the Renesas Quad Serial Peripheral Interface. It brings
> > r8a7790/Lager to the same support level as r8a7791/Koelsch, allowing access
> > to the Spansion s25fl512s SPI FLASH for both legacy and multi-platform
> > kernels.
> >
> > [1/7] pinctrl: sh-pfc: r8a7790: Add QSPI pin groups
> > [2/7] ARM: shmobile: lager legacy: Add QSPI pinmux
> > [3/7] ARM: shmobile: r8a7790 dtsi: Add QSPI node
> > [4/7] ARM: shmobile: lager dts: Add QSPI nodes
> > [5/7] ARM: shmobile: lager defconfig: Enable RSPI and MTD_M25P80
>
> Thanks a lot for this! All patches included in this series look great to me.
>
> I noticed that 1/7 turned into a v2, so feel free to omit or include
> the below ack.
>
> Acked-by: Magnus Damm <damm@opensource.se>
>
> > [6/7] ARM: shmobile: lager legacy: Enable Quad SPI transfers for the SPI
> > FLASH
> > [7/7] ARM: shmobile: lager dts: Enable Quad SPI transfers for the SPI
> > FLASH
> >
> > Please do _not_ apply patches [6/7] and [7/7] yet, as these have a runtime
> > dependency on Quad SPI support in the RSPI/QSPI driver, which is queued up
> > in the linux-spi tree for v3.15.
>
> That makes sense, thanks for pointing that out. You still have my Ack
> though, so please include that when you resend.
>
> Simon, can you please pick up 2-5?
Done.
^ permalink raw reply
* [PATCH] ARM: shmobile: koelsch: Enable SDHI in defconfig
From: Simon Horman @ 2014-02-13 5:19 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/configs/koelsch_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/koelsch_defconfig b/arch/arm/configs/koelsch_defconfig
index 9561139..f4e221f 100644
--- a/arch/arm/configs/koelsch_defconfig
+++ b/arch/arm/configs/koelsch_defconfig
@@ -73,6 +73,8 @@ CONFIG_THERMAL=y
CONFIG_RCAR_THERMAL=y
# CONFIG_HID is not set
# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHI=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
# CONFIG_IOMMU_SUPPORT is not set
--
1.8.5.2
^ permalink raw reply related
* [PATCH] input: sirfsoc-onkey - report onkey untouch event by detecting pin status
From: Dmitry Torokhov @ 2014-02-13 3:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4wzQYmNkd421vzau5BiTyewRX=vzEiy=BiSnttb+rEC8Q@mail.gmail.com>
On February 12, 2014 6:32:03 PM PST, Barry Song <21cnbao@gmail.com> wrote:
>2014-02-13 7:11 GMT+08:00 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
>> Hi Barry,
>>
>> On Mon, Feb 10, 2014 at 06:07:39PM +0800, Barry Song wrote:
>>>
>>> static int sirfsoc_pwrc_remove(struct platform_device *pdev)
>>> {
>>> + struct sirfsoc_pwrc_drvdata *pwrcdrv =
>dev_get_drvdata(&pdev->dev);
>>> +
>>> device_init_wakeup(&pdev->dev, 0);
>>>
>>> + cancel_delayed_work_sync(&pwrcdrv->work);
>>> +
>>
>> This is racy: interrupt is freed later and can schedule work again.
>
>thanks, Dmitry. i will do a manual devm_free_irq() before cancelling
>the work and before devres removes the resources.
Another option would be to use devm custom action to ensure that work is canceled after freeing IRQ.
--
Dmitry
^ permalink raw reply
* [PATCH v1 2/2] clocksource: mct: cleanup, remove non-dt stuff from mct
From: Tarek Dakhran @ 2014-02-13 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392260923-31659-1-git-send-email-t.dakhran@samsung.com>
mct_init not used anywhere, remove this non-dt stuff.
also remove declaration of mct_init
in arch/arm/mach-exynos/common.h
Signed-off-by: Tarek Dakhran <t.dakhran@samsung.com>
---
arch/arm/mach-exynos/common.h | 2 --
drivers/clocksource/exynos_mct.c | 17 +----------------
2 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index f76967b..8945170 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -15,8 +15,6 @@
#include <linux/reboot.h>
#include <linux/of.h>
-void mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1);
-
struct map_desc;
void exynos_init_io(void);
void exynos4_restart(enum reboot_mode mode, const char *cmd);
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 1cde3de..a94a908 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -548,18 +548,6 @@ out_irq:
free_percpu_irq(mct_irqs[MCT_L0_IRQ], &percpu_mct_tick);
}
-void __init mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1)
-{
- mct_irqs[MCT_G0_IRQ] = irq_g0;
- mct_irqs[MCT_L0_IRQ] = irq_l0;
- mct_irqs[MCT_L1_IRQ] = irq_l1;
- mct_int_type = MCT_INT_SPI;
-
- exynos4_timer_resources(NULL, base);
- exynos4_clocksource_init();
- exynos4_clockevent_init();
-}
-
static void __init mct_init_dt(struct device_node *np, unsigned int int_type)
{
u32 nr_irqs, i;
@@ -574,11 +562,8 @@ static void __init mct_init_dt(struct device_node *np, unsigned int int_type)
* timer irqs are specified after the four global timer
* irqs are specified.
*/
-#ifdef CONFIG_OF
nr_irqs = of_irq_count(np);
-#else
- nr_irqs = 0;
-#endif
+
for (i = MCT_L0_IRQ; i < nr_irqs; i++)
mct_irqs[i] = irq_of_parse_and_map(np, i);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v1 1/2] clocksource: mct: remove request_irq from exynos4_local_timer_setup
From: Tarek Dakhran @ 2014-02-13 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392260923-31659-1-git-send-email-t.dakhran@samsung.com>
exynos4_local_timer_setup called on the secondary cpu before
irqs are enabled. request_irq can sleep, which produces next warning:
BUG: sleeping function called from invalid context at mm/slub.c:965
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/3
Call setup_irq for each local timer in exynos4_timer_resources,
and only call enable_irq during percpu timer setup.
Signed-off-by: Tarek Dakhran <t.dakhran@samsung.com>
---
drivers/clocksource/exynos_mct.c | 38 ++++++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 48f76bc..1cde3de 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -82,6 +82,7 @@ static void __iomem *reg_base;
static unsigned long clk_rate;
static unsigned int mct_int_type;
static int mct_irqs[MCT_NR_IRQS];
+static struct irqaction __percpu *mct_LX_irqaction;
struct mct_clock_event_device {
struct clock_event_device evt;
@@ -402,6 +403,25 @@ static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static void exynos4_setup_irqaction_spi(unsigned int cpu)
+{
+ struct irqaction *pcpu_irqaction = per_cpu_ptr(mct_LX_irqaction, cpu);
+ unsigned int irq = mct_irqs[MCT_L0_IRQ + cpu];
+ int err;
+
+ pcpu_irqaction->name = per_cpu(percpu_mct_tick, cpu).name;
+ pcpu_irqaction->flags = IRQF_TIMER | IRQF_NOBALANCING;
+ pcpu_irqaction->handler = exynos4_mct_tick_isr;
+ pcpu_irqaction->dev_id = &per_cpu(percpu_mct_tick, cpu);
+
+ err = setup_irq(irq, pcpu_irqaction);
+ if (err) {
+ pr_err("MCT: can't setup IRQ %d (%d)\n", irq, err);
+ return;
+ }
+ disable_irq(irq);
+}
+
static int exynos4_local_timer_setup(struct clock_event_device *evt)
{
struct mct_clock_event_device *mevt;
@@ -425,13 +445,7 @@ static int exynos4_local_timer_setup(struct clock_event_device *evt)
if (mct_int_type == MCT_INT_SPI) {
evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
- if (request_irq(evt->irq, exynos4_mct_tick_isr,
- IRQF_TIMER | IRQF_NOBALANCING,
- evt->name, mevt)) {
- pr_err("exynos-mct: cannot register IRQ %d\n",
- evt->irq);
- return -EIO;
- }
+ enable_irq(evt->irq);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -443,7 +457,7 @@ static void exynos4_local_timer_stop(struct clock_event_device *evt)
{
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
if (mct_int_type == MCT_INT_SPI)
- free_irq(evt->irq, this_cpu_ptr(&percpu_mct_tick));
+ disable_irq(evt->irq);
else
disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
}
@@ -485,9 +499,12 @@ static struct notifier_block exynos4_mct_cpu_nb = {
static void __init exynos4_timer_resources(struct device_node *np, void __iomem *base)
{
int err;
+ u32 i, cpu, nr_irqs;
struct mct_clock_event_device *mevt = this_cpu_ptr(&percpu_mct_tick);
struct clk *mct_clk, *tick_clk;
+ nr_irqs = of_irq_count(np);
+
tick_clk = np ? of_clk_get_by_name(np, "fin_pll") :
clk_get(NULL, "fin_pll");
if (IS_ERR(tick_clk))
@@ -511,6 +528,11 @@ static void __init exynos4_timer_resources(struct device_node *np, void __iomem
WARN(err, "MCT: can't request IRQ %d (%d)\n",
mct_irqs[MCT_L0_IRQ], err);
} else {
+ mct_LX_irqaction = alloc_percpu(struct irqaction);
+ BUG_ON(!mct_LX_irqaction);
+
+ for (i = MCT_L0_IRQ, cpu = 0; i < nr_irqs; i++, cpu++)
+ exynos4_setup_irqaction_spi(cpu);
irq_set_affinity(mct_irqs[MCT_L0_IRQ], cpumask_of(0));
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH v1 0/2] exynos_mct driver: fix irq allocation and cleanup
From: Tarek Dakhran @ 2014-02-13 3:08 UTC (permalink / raw)
To: linux-arm-kernel
exynos4_local_timer_setup called on the secondary cpu before
irqs are enabled. request_irq can sleep, which produces next warning:
on boot:
[ 0.370000] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.370000] Setting up static identity map for 0x403b5700 - 0x403b5758
[ 0.395000] CPU1: Booted secondary processor
[ 0.395000] ------------[ cut here ]------------
[ 0.395000] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2742 lockdep_trace_alloc+0xe0/0xfc()
[ 0.395000] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[ 0.395000] Modules linked in:
[ 0.395000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-rc2-00004-g0db95f4 #128
[ 0.395000] [<c0014308>] (unwind_backtrace) from [<c0011690>] (show_stack+0x10/0x14)
[ 0.395000] [<c0011690>] (show_stack) from [<c03ae7d0>] (dump_stack+0x6c/0xb8)
[ 0.395000] [<c03ae7d0>] (dump_stack) from [<c001d504>] (warn_slowpath_common+0x68/0x8c)
[ 0.395000] [<c001d504>] (warn_slowpath_common) from [<c001d5bc>] (warn_slowpath_fmt+0x30/0x40)
[ 0.395000] [<c001d5bc>] (warn_slowpath_fmt) from [<c0059824>] (lockdep_trace_alloc+0xe0/0xfc)
[ 0.395000] [<c0059824>] (lockdep_trace_alloc) from [<c00bee24>] (kmem_cache_alloc+0x24/0x160)
[ 0.395000] [<c00bee24>] (kmem_cache_alloc) from [<c0068174>] (request_threaded_irq+0x64/0x130)
[ 0.395000] [<c0068174>] (request_threaded_irq) from [<c02efaf8>] (exynos4_local_timer_setup+0xd0/0x124)
[ 0.395000] [<c02efaf8>] (exynos4_local_timer_setup) from [<c02efc34>] (exynos4_mct_cpu_notify+0x78/0xf0)
[ 0.395000] [<c02efc34>] (exynos4_mct_cpu_notify) from [<c003d318>] (notifier_call_chain+0x44/0x84)
[ 0.395000] [<c003d318>] (notifier_call_chain) from [<c001d61c>] (__cpu_notify+0x24/0x40)
[ 0.395000] [<c001d61c>] (__cpu_notify) from [<c0013314>] (secondary_start_kernel+0xe4/0x134)
[ 0.395000] [<c0013314>] (secondary_start_kernel) from [<40008624>] (0x40008624)
[ 0.395000] ---[ end trace 347890460e745f50 ]---
[ 0.420000] CPU1: update cpu_power 1024
[ 0.420000] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
on hotplug:
[ 108.040000] CPU3: Booted secondary processor
[ 108.040000] BUG: sleeping function called from invalid context at mm/slub.c:965
[ 108.040000] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/3
[ 108.040000] INFO: lockdep is turned off.
[ 108.040000] irq event stamp: 0
[ 108.040000] hardirqs last enabled at (0): [< (null)>] (null)
[ 108.040000] hardirqs last disabled at (0): [<c001b768>] copy_process.part.2+0x2a4/0x12f4
[ 108.040000] softirqs last enabled at (0): [<c001b768>] copy_process.part.2+0x2a4/0x12f4
[ 108.040000] softirqs last disabled at (0): [< (null)>] (null)
[ 108.040000] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G W 3.14.0-rc2-00004-g0db95f4 #128
[ 108.040000] [<c0014308>] (unwind_backtrace) from [<c0011690>] (show_stack+0x10/0x14)
[ 108.040000] [<c0011690>] (show_stack) from [<c03ae7d0>] (dump_stack+0x6c/0xb8)
[ 108.040000] [<c03ae7d0>] (dump_stack) from [<c00beed4>] (kmem_cache_alloc+0xd4/0x160)
[ 108.040000] [<c00beed4>] (kmem_cache_alloc) from [<c0068174>] (request_threaded_irq+0x64/0x130)
[ 108.040000] [<c0068174>] (request_threaded_irq) from [<c02efaf8>] (exynos4_local_timer_setup+0xd0/0x124)
[ 108.040000] [<c02efaf8>] (exynos4_local_timer_setup) from [<c02efc34>] (exynos4_mct_cpu_notify+0x78/0xf0)
[ 108.040000] [<c02efc34>] (exynos4_mct_cpu_notify) from [<c003d318>] (notifier_call_chain+0x44/0x84)
[ 108.040000] [<c003d318>] (notifier_call_chain) from [<c001d61c>] (__cpu_notify+0x24/0x40)
[ 108.040000] [<c001d61c>] (__cpu_notify) from [<c0013314>] (secondary_start_kernel+0xe4/0x134)
[ 108.040000] [<c0013314>] (secondary_start_kernel) from [<40008624>] (0x40008624)
First patch fixes this problem by removing request_irq from exynos4_local_timer_setup
Second removes non-dt stuff.
Tested on linux kernel v3.14-rc2.
Comments and additions would be appreciated.
Thank you.
Tarek.
Tarek Dakhran (2):
clocksource: mct: remove request_irq from exynos4_local_timer_setup
clocksource: mct: cleanup, remove non-dt stuff from mct
arch/arm/mach-exynos/common.h | 2 --
drivers/clocksource/exynos_mct.c | 55 +++++++++++++++++++++-----------------
2 files changed, 31 insertions(+), 26 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH] input: sirfsoc-onkey - report onkey untouch event by detecting pin status
From: Barry Song @ 2014-02-13 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212231131.GA29769@core.coreip.homeip.net>
2014-02-13 7:11 GMT+08:00 Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> Hi Barry,
>
> On Mon, Feb 10, 2014 at 06:07:39PM +0800, Barry Song wrote:
>>
>> static int sirfsoc_pwrc_remove(struct platform_device *pdev)
>> {
>> + struct sirfsoc_pwrc_drvdata *pwrcdrv = dev_get_drvdata(&pdev->dev);
>> +
>> device_init_wakeup(&pdev->dev, 0);
>>
>> + cancel_delayed_work_sync(&pwrcdrv->work);
>> +
>
> This is racy: interrupt is freed later and can schedule work again.
thanks, Dmitry. i will do a manual devm_free_irq() before cancelling
the work and before devres removes the resources.
>
> Thanks.
>
> --
> Dmitry
-barry
^ permalink raw reply
* [PATCH v2 0/9] ARM: multi-platform kconfig cleanup and mach-virt removal
From: Stephen Warren @ 2014-02-13 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392153119-23248-1-git-send-email-robherring2@gmail.com>
On 02/11/2014 02:11 PM, Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> This series removes common kconfig options required by multi-platform
> builds out of individual platforms as they are redundant. Patches 2 and
> 3 make SMP and CACHE_L2X0 config options visible on MULTI_V7 builds as
> most platforms enable these options and all platforms can run with them
> enabled.
>
> The previous version [1] was mainly a discussion about v6 vs. v6K.
> Several platforms have this wrong and incorrectly select v6 when the
> more optimal v6K option could be used. After more research, my memory
> about i.MX31 was wrong and it does need to remain v6. I've tested the
> v6K change on Rasp Pi. The default change to v6K for MULTI_V6 does not
> switch any platforms. I don't plan to submit the v6K changes for
> platforms without platform maintainers acks or testing.
>
> Finally, patch 8 removes mach-virt as it is no longer needed. The core
> ARM code can handle all the necessary initialization and mach-virt is
> left as a kconfig option. Although not really related to this series,
> it would otherwise conflict with it.
For mach-bcm2835, the series,
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
And patch 5/9 also now,
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
^ permalink raw reply
* [PATCH 1/2] ARM: tegra: enable I2C Mux driver for PCA9546 in defconfig
From: Bryan Wu @ 2014-02-13 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FC2A1A.2070305@wwwdotorg.org>
On Wed, Feb 12, 2014 at 6:12 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 02/12/2014 04:23 PM, Bryan Wu wrote:
> ...
>> Sure, I think I just missed to set the author as @nvidia.com but SOB
>> is @nvidia.com in this patchset. And I still should use --from "Bryan
>> Wu <cooloney@gmail.com>" for sending out email from gmail server.
>> Right?
>
> I think you want the following in ~/.gitconfig:
>
> [user]
> name = Bryan Wu
> email = pengw at nvidia.com
I have these settings in my company machine.
> [sendemail]
> from = Bryan Wu <cooloney@gmail.com>
>
> I assume "--from xxx" is the same as setting the last variable I listed
> above.
Yeah, I didn't put this in my .gitconfig but put them in my script
with "git send-mail".
Thanks,
-Bryan
^ permalink raw reply
* [PATCH] ARM: tegra: dalmore: fix irq trigger type
From: Stephen Warren @ 2014-02-13 2:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FC1BF2.8020003@nvidia.com>
On 02/12/2014 06:12 PM, Joseph Lo wrote:
> On 02/13/2014 03:39 AM, Stephen Warren wrote:
>> On 02/11/2014 02:21 PM, Stefan Agner wrote:
>>> Am 2014-02-11 21:47, schrieb Thierry Reding:
>>>> On Tue, Feb 11, 2014 at 09:11:32PM +0100, Stefan Agner wrote:
>>>>> Trigger type needs to be IRQ_TYPE_LEVEL_HIGH since the interrupt
>>>>> signal gets inverted by the PMC (configured by the invert-interrupt
>>>>> property).
...
>> For me, applying this patch actually *causes* an interrupt storm, rather
>> than preventing one. Yet without it, no interrupts occur at all. I
>> wonder if the driver has a bug where it's not correctly clearing all
>> interrupt status (e.g. something pre-existing before boot), so once the
>> polarity is set up correctly, the interrupt is stuck?
>>
>> Joseph,
>>
>> As the author of the patch that's being reverted, can you please comment
>> here?
>>
>
> I had explained why I fixed this here.
> https://patchwork.kernel.org/patch/2832646/
Looking back at that conversation, I'm not convinced by your explanation.
Some questions:
What does the PMIC output for an IRQ signal? It sounds like SW can
select either active-high level, or active-low level. Which of those is
the HW default? Does the Linux kernel driver attempt to program the HW
to select one or the other? If so, how does it determine which option to
choose, and where's the code that does that?
For now, let's not worry about system suspend issues, what the GIC
supports, etc. I only want to know about the PMIC for now.
Once we know the answer to that question, we can correctly configure the DT.
^ permalink raw reply
* [PATCHv3 2/2] arm: Get rid of meminfo
From: Laura Abbott @ 2014-02-13 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB8E91.8030400@ti.com>
On 2/12/2014 7:09 AM, Grygorii Strashko wrote:
> Hi Laura,
>
> On 02/11/2014 11:14 PM, Laura Abbott wrote:
>> memblock is now fully integrated into the kernel and is the prefered
>> method for tracking memory. Rather than reinvent the wheel with
>> meminfo, migrate to using memblock directly instead of meminfo as
>> an intermediate.
>>
>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>> ---
>> arch/arm/include/asm/mach/arch.h | 4 +-
>> arch/arm/include/asm/memblock.h | 3 +-
>> arch/arm/include/asm/setup.h | 23 ------
>> arch/arm/kernel/atags_parse.c | 5 +-
>> arch/arm/kernel/devtree.c | 5 --
>> arch/arm/kernel/setup.c | 30 ++------
>> arch/arm/mach-clps711x/board-clep7312.c | 7 +-
>> arch/arm/mach-clps711x/board-edb7211.c | 10 +--
>> arch/arm/mach-clps711x/board-p720t.c | 2 +-
>> arch/arm/mach-footbridge/cats-hw.c | 2 +-
>> arch/arm/mach-footbridge/netwinder-hw.c | 2 +-
>> arch/arm/mach-msm/board-halibut.c | 6 --
>> arch/arm/mach-msm/board-mahimahi.c | 13 +---
>> arch/arm/mach-msm/board-msm7x30.c | 3 +-
>> arch/arm/mach-msm/board-sapphire.c | 13 ++--
>> arch/arm/mach-msm/board-trout.c | 8 +--
>> arch/arm/mach-orion5x/common.c | 3 +-
>> arch/arm/mach-orion5x/common.h | 3 +-
>> arch/arm/mach-pxa/cm-x300.c | 3 +-
>> arch/arm/mach-pxa/corgi.c | 10 +--
>> arch/arm/mach-pxa/eseries.c | 9 +--
>> arch/arm/mach-pxa/poodle.c | 8 +--
>> arch/arm/mach-pxa/spitz.c | 8 +--
>> arch/arm/mach-pxa/tosa.c | 8 +--
>> arch/arm/mach-realview/core.c | 11 +--
>> arch/arm/mach-realview/core.h | 3 +-
>> arch/arm/mach-realview/realview_pb1176.c | 8 +--
>> arch/arm/mach-realview/realview_pbx.c | 17 ++---
>> arch/arm/mach-s3c24xx/mach-smdk2413.c | 8 +--
>> arch/arm/mach-s3c24xx/mach-vstms.c | 8 +--
>> arch/arm/mach-sa1100/assabet.c | 2 +-
>> arch/arm/mm/init.c | 67 +++++++-----------
>> arch/arm/mm/mmu.c | 115 +++++++++---------------------
>
> The arch/arm/mm/nommu.c has to be updated too :)
>
Sure does.
> [...]
>
> I've tested your change on keystone (with some additional printouts in sanity_check_meminfo())
> and got following results:
>
> - without your change + HIGHMEM=ON
> [ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
>
> - without your change + HIGHMEM=OFF
> [ 0.000000] Truncating RAM at 80000000-bfffffff to -af7fffff (vmalloc region overlap).
> [ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
>
> - with your change + HIGHMEM=ON
> [ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
>
> - with your change + HIGHMEM=OFF
> [ 0.000000] Truncating RAM at 0x0000000080000000-0x00000000c0000000 to -0x0000000010800000
> ^printout changed
> [ 0.000000] ==== memblock_limit0x00000000af800000, arm_lowmem_limit0x00000000af800000 high_memoryef800000 vmalloc_limit0x00000000af800000
>
> Keystone mem defined as: from at 0x80000000 size at 0x40000000 (LPAE=OFF)
>
> As result, i have few comments regarding sanity_check_meminfo() changes as I think there are
> some issues &side effects changes at least in printouts - see below.
>
>> memblock_reserve(__pa(_sdata), _end - _sdata);
>> @@ -413,54 +397,53 @@ free_memmap(unsigned long start_pfn, unsigned long end_pfn)
>> /*
>> * The mem_map array can get very big. Free the unused area of the memory map.
>> */
>> -static void __init free_unused_memmap(struct meminfo *mi)
>> +static void __init free_unused_memmap(void)
>> {
>> - unsigned long bank_start, prev_bank_end = 0;
>> - unsigned int i;
>> + unsigned long start, prev_end = 0;
>> + struct memblock_region *reg;
>>
>> /*
>> * This relies on each bank being in address order.
>> * The banks are sorted previously in bootmem_init().
>> */
>> - for_each_bank(i, mi) {
>> - struct membank *bank = &mi->bank[i];
>> -
>> - bank_start = bank_pfn_start(bank);
>> + for_each_memblock(memory, reg) {
>> + start = __phys_to_pfn(reg->base);
>
> memblock_region_memory_base_pfn() can be used here.
>
Okay
>>
>> #ifdef CONFIG_SPARSEMEM
>> /*
>> * Take care not to free memmap entries that don't exist
>> * due to SPARSEMEM sections which aren't present.
>> */
>> - bank_start = min(bank_start,
>> - ALIGN(prev_bank_end, PAGES_PER_SECTION));
>> + start = min(start,
>> + ALIGN(prev_end, PAGES_PER_SECTION));
>> #else
>> /*
>> * Align down here since the VM subsystem insists that the
>> * memmap entries are valid from the bank start aligned to
>> * MAX_ORDER_NR_PAGES.
>> */
>> - bank_start = round_down(bank_start, MAX_ORDER_NR_PAGES);
>> + start = round_down(start, MAX_ORDER_NR_PAGES);
>> #endif
>> /*
>> * If we had a previous bank, and there is a space
>> * between the current bank and the previous, free it.
>> */
>> - if (prev_bank_end && prev_bank_end < bank_start)
>> - free_memmap(prev_bank_end, bank_start);
>> + if (prev_end && prev_end < start)
>> + free_memmap(prev_end, start);
>>
>> /*
>> * Align up here since the VM subsystem insists that the
>> * memmap entries are valid from the bank end aligned to
>> * MAX_ORDER_NR_PAGES.
>> */
>> - prev_bank_end = ALIGN(bank_pfn_end(bank), MAX_ORDER_NR_PAGES);
>> + prev_end = ALIGN(start + __phys_to_pfn(reg->size),
>
> I think, start + __phys_to_pfn(reg->size) can be replaced by
> memblock_region_memory_end_pfn().
>
Okay
>> + MAX_ORDER_NR_PAGES);
>> }
>>
>> #ifdef CONFIG_SPARSEMEM
>> - if (!IS_ALIGNED(prev_bank_end, PAGES_PER_SECTION))
>> - free_memmap(prev_bank_end,
>> - ALIGN(prev_bank_end, PAGES_PER_SECTION));
>> + if (!IS_ALIGNED(prev_end, PAGES_PER_SECTION))
>> + free_memmap(prev_end,
>> + ALIGN(prev_end, PAGES_PER_SECTION));
>> #endif
>> }
>>
>> @@ -536,7 +519,7 @@ void __init mem_init(void)
>> set_max_mapnr(pfn_to_page(max_pfn) - mem_map);
>>
>> /* this will put all unused low memory onto the freelists */
>> - free_unused_memmap(&meminfo);
>> + free_unused_memmap();
>> free_all_bootmem();
>>
>> #ifdef CONFIG_SA1111
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index 4f08c13..23433ef 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -1046,74 +1046,44 @@ phys_addr_t arm_lowmem_limit __initdata = 0;
>> void __init sanity_check_meminfo(void)
>> {
>> phys_addr_t memblock_limit = 0;
>> - int i, j, highmem = 0;
>> + int highmem = 0;
>> phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
>> + struct memblock_region *reg;
>>
>> - for (i = 0, j = 0; i < meminfo.nr_banks; i++) {
>> - struct membank *bank = &meminfo.bank[j];
>> - phys_addr_t size_limit;
>> -
>> - *bank = meminfo.bank[i];
>> - size_limit = bank->size;
>> + for_each_memblock(memory, reg) {
>> + phys_addr_t block_start = reg->base;
>> + phys_addr_t block_end = reg->base + reg->size;
>> + phys_addr_t size_limit = reg->size;
>>
>> - if (bank->start >= vmalloc_limit)
>> + if (reg->base >= vmalloc_limit)
>> highmem = 1;
>> else
>> - size_limit = vmalloc_limit - bank->start;
>> + size_limit = vmalloc_limit - reg->base;
>>
>> - bank->highmem = highmem;
>>
>> -#ifdef CONFIG_HIGHMEM
>> - /*
>> - * Split those memory banks which are partially overlapping
>> - * the vmalloc area greatly simplifying things later.
>> - */
>> - if (!highmem && bank->size > size_limit) {
>> - if (meminfo.nr_banks >= NR_BANKS) {
>> - printk(KERN_CRIT "NR_BANKS too low, "
>> - "ignoring high memory\n");
>> - } else {
>> - memmove(bank + 1, bank,
>> - (meminfo.nr_banks - i) * sizeof(*bank));
>> - meminfo.nr_banks++;
>> - i++;
>> - bank[1].size -= size_limit;
>> - bank[1].start = vmalloc_limit;
>> - bank[1].highmem = highmem = 1;
>> - j++;
>> + if (!IS_ENABLED(CONFIG_HIGHMEM) || cache_is_vipt_aliasing()) {
>> +
>> + if (highmem) {
>> + pr_notice("Ignoring ram at %pa-%pa (!CONFIG_HIGHMEM)\n",
>> + &block_start, &block_end);
>> + memblock_remove(block_start, block_end);
>
> The wrong size is used here, should be => memblock_remove(block_start, reg->size);
> or => memblock_remove(block_start, size_limit);
>
Yes, you are correct. I'm guessing I meant to do block_end-block_start
and missed the last part.
>> + continue;
>> }
>> - bank->size = size_limit;
>> - }
>> -#else
>> - /*
>> - * Highmem banks not allowed with !CONFIG_HIGHMEM.
>> - */
>> - if (highmem) {
>> - printk(KERN_NOTICE "Ignoring RAM at %.8llx-%.8llx "
>> - "(!CONFIG_HIGHMEM).\n",
>> - (unsigned long long)bank->start,
>> - (unsigned long long)bank->start + bank->size - 1);
>> - continue;
>> - }
>>
>> - /*
>> - * Check whether this memory bank would partially overlap
>> - * the vmalloc area.
>> - */
>> - if (bank->size > size_limit) {
>> - printk(KERN_NOTICE "Truncating RAM at %.8llx-%.8llx "
>> - "to -%.8llx (vmalloc region overlap).\n",
>> - (unsigned long long)bank->start,
>> - (unsigned long long)bank->start + bank->size - 1,
>> - (unsigned long long)bank->start + size_limit - 1);
>> - bank->size = size_limit;
>> + if (reg->size > size_limit) {
>> + phys_addr_t overlap_size = reg->size - size_limit;
>> +
>> + pr_notice("Truncating RAM at %pa-%pa to -%pa",
>> + &block_start, &block_end, &overlap_size);
>
> Pls, change it back to show new RAM limit instead of size.
> pr_notice("Truncating RAM at %pa-%pa to -%pa",
> &block_start, &block_end, &vmalloc_limit);
>
>
>> + memblock_remove(vmalloc_limit, overlap_size);
>> + block_end = vmalloc_limit;
>> + }
>> }
>> -#endif
>> - if (!bank->highmem) {
>> - phys_addr_t bank_end = bank->start + bank->size;
>>
>> - if (bank_end > arm_lowmem_limit)
>> - arm_lowmem_limit = bank_end;
>> + if (!highmem) {
>> + if (block_end > arm_lowmem_limit)
>> + arm_lowmem_limit = reg->base + size_limit;
>> +
>
> if !highmem then size_limit will be calculated as vmalloc_limit - reg->base
> which in turn can be greater than reg->size. So, arm_lowmem_limit can point on
> non existent memory address.
>
> Seems, it should be:
> arm_lowmem_limit = block_end;
>
Yes, I believe so. I will review it.
>>
>> /*
>> * Find the first non-section-aligned page, and point
>> @@ -1129,35 +1099,16 @@ void __init sanity_check_meminfo(void)
>> * occurs before any free memory is mapped.
>> */
>> if (!memblock_limit) {
>> - if (!IS_ALIGNED(bank->start, SECTION_SIZE))
>> - memblock_limit = bank->start;
>> - else if (!IS_ALIGNED(bank_end, SECTION_SIZE))
>> - memblock_limit = bank_end;
> [...]
>
> Thanks for your patience :)
>
Thanks for the review and debugging!
> Regards,
> -grygorii
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH V2 1/2] ARM: dts: imx6q: add 852MHz setpoint for CPU freq
From: Shawn Guo @ 2014-02-13 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392199023-29880-1-git-send-email-b20788@freescale.com>
On Wed, Feb 12, 2014 at 05:57:02PM +0800, Anson Huang wrote:
> According to datasheet, i.MX6Q has setpoint of 852MHz
> which is exclusive with 996MHz, the fuse map of speed_grading
> defines the max speed of ARM, here we add this 852MHz
> setpoint opp info, kernel will check the speed_grading
> fuse and remove all illegal setpoints.
>
> Signed-off-by: Anson Huang <b20788@freescale.com>
Applied both, thanks.
^ permalink raw reply
* [PATCH 1/2] ARM: tegra: enable I2C Mux driver for PCA9546 in defconfig
From: Stephen Warren @ 2014-02-13 2:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK5ve-LHktOUNUYRZccvmmYwcAhvQiPQYoxEWkVU6kUHr4aTUQ@mail.gmail.com>
On 02/12/2014 04:23 PM, Bryan Wu wrote:
...
> Sure, I think I just missed to set the author as @nvidia.com but SOB
> is @nvidia.com in this patchset. And I still should use --from "Bryan
> Wu <cooloney@gmail.com>" for sending out email from gmail server.
> Right?
I think you want the following in ~/.gitconfig:
[user]
name = Bryan Wu
email = pengw at nvidia.com
[sendemail]
from = Bryan Wu <cooloney@gmail.com>
I assume "--from xxx" is the same as setting the last variable I listed
above.
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Shawn Guo @ 2014-02-13 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DMbmh56AOZjRSB062o6u6y3TrFFk507ufd_QL9nr8gSQ@mail.gmail.com>
On Wed, Feb 12, 2014 at 03:22:05PM -0200, Fabio Estevam wrote:
> On Wed, Feb 12, 2014 at 1:20 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > On Wed, Feb 12, 2014 at 01:57:36PM +0000, Mark Rutland wrote:
> >> As it stands, the dts are buggy. I can appreciate that you don't feel
> >> this is important, but I do. It's not just an IMX issue, there is
> >> widespread misunderstanding and abuse of simple-bus.
> >>
> >> Said abuse is relying on current Linux implementation details, and that
> >> can and will create problems if and when probing code is changed.
> >
> > The reality is the code already gets no chance to change on this regard,
> > considering the requirement that we need to maintain the interface
> > between kernel and DT as ABI. The dts have been there like this for
> > 10 kernel releases or so.
>
> What breakage do you see with this patch?
I'm not talking about this patch. I'm replying to Mark's comment saying
some day the kernel probing code is changed.
Shawn
^ permalink raw reply
* [PATCH] ARM: dts: imx27-phytec-phycard-s-som: Rename file to .dtsi
From: Shawn Guo @ 2014-02-13 1:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392144262-9839-1-git-send-email-shc_work@mail.ru>
On Tue, Feb 11, 2014 at 10:44:22PM +0400, Alexander Shiyan wrote:
> PCA-100 module cannot be used standalone. This patch renames
> module file to .dtsi and excludes it from compilation.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Applied, thanks.
^ permalink raw reply
* [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Sebastian Capella @ 2014-02-13 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392128273-8614-4-git-send-email-lorenzo.pieralisi@arm.com>
Quoting Lorenzo Pieralisi (2014-02-11 06:17:53)
> + - cpu-idle-states
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition:
> + # List of phandles to cpu idle state nodes supported
> + by this cpu [1].
> +
Should cpu idle be hyphenated in the definition like:
"List of phandles to cpu-idle state nodes supported"
Is anything implied in the ordering of this list?
Or is this a non-ordered array of phandles?
Would it be a good idea to select a different name for this property vs.
the node? It seems to get confusing sometimes.
> +According to the Server Base System Architecture document (SBSA, [3]), the
> +power states an ARM CPU can be put into are identified by the following list:
> +
> +1 - Running
> +2 - Idle_standby
> +3 - Idle_retention
> +4 - Sleep
> +5 - Off
Are these states used in the state->index value?
Might it be helpful to number these starting with 0?
> +ARM platforms implement the power states specified in the SBSA through power
> +management schemes that allow an OS PM implementation to put the processor in
> +different idle states (which include states 1 to 4 above; "off" state is not
> +an idle state since it does not have wake-up capabilities, hence it is not
> +considered in this document).
Might an implementation have both sleep and off states where they have
different latencies in the case a cpu can wake itself vs. a coprocessor
waking the cpu?
> +
> +Idle state parameters (eg entry latency) are platform specific and need to be
> +characterized with bindings that provide the required information to OSPM
> +code so that it can build the required tables and use them at runtime.
> +
> +The device tree binding definition for ARM idle states is the subject of this
> +document.
During last connect, we'd discussed that the small set of
states here could apply to a single node, which can represent a cpu, a
cluster with cache etc. Then the complexities of the system power state
would be represented using a heirarchy, with each node in the
tree having its own state from the list above. This would allow
a fairly rich system state while having just a few power states defined
at each level. Is this how you're intending these bindings to go?
> +===========================================
> +2 - state node
> +===========================================
should the section numbering be incremented here? Or is this a
subsection? 2.1?
Also, would it be nice to have a name field for each state?
> + A state node can contain state child nodes. A state node with
> + children represents a hierarchical state, which is a superset of
> + the child states. Hierarchical states require all CPUs on which
> + they are valid to request the state in order for it to be entered.
Is it possible for a cpu to request a deeper state and unblock other cpus
from entering this state?
"all CPUs on which they are valid" is this determined by seeing which
state's phandle is in each cpu->cpu-idle-states?
> +
> + A state node defines the following properties:
...
> + - index
> + Usage: Required
> + Value type: <u32>
> + Definition: It represents an idle state index, starting from 2.
> + Index 0 represents the processor state "running"
> + and index 1 represents processor mode
> + "idle_standby", entered by executing a wfi
> + instruction (SBSA,[3]); indexes 0 and 1 are
> + standard ARM states that need not be described.
Do you think maybe something like this might be clearer?
Definition: It represents an idle state index.
Index 0 and 1 shall not be specified and are reserved for ARM
states where index 0 is running, and index 1 is idle_standby
entered by executing a wfi instruction (SBSA,[3])
What mechanism is used to order the power states WRT power consumption?
> + - entry-method
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Describes the method by which a CPU enters the
> + idle state. This property is required and must be
> + one of:
> +
> + - "arm,psci-cpu-suspend"
> + ARM PSCI firmware interface, CPU suspend
> + method[2].
Can psci-cpu-suspend be assumed if entry-method is omitted?
Can this field be used to combine both psci and non-psci states in any order?
> + - power-state
> + Usage: See definition.
> + Value type: <u32>
> + Definition: Depends on the entry-method property value.
> + If entry-method is "arm,psci-cpu-suspend":
> + # Property is required and represents
> + psci-power-state parameter. Please refer to
> + [2] for PSCI bindings definition.
Examples use psci-power-state..
If we call this something like entry-method-param rather than power-state,
would this allow the field to be more flexible? Is flexibility here a goal?
- power-state
Usage: See definition.
Value type: <u32>
Definition: Parameter to pass to the entry method when
this state is being entered.
If entry-method is "arm,psci-cpu-suspend",
this parameter represents the psci-power-state
parameter. Please refer to [2] for PSCI bindings
definition.
> + - power-domains
> + Usage: Optional
> + Value type: <prop-encoded-array>
> + Definition: List of power domain specifiers ([1]) describing
> + the power domains that are affected by the idle
> + state entry.
How do you expect this information should be used?
I assume psci will be turning off the powerdomains not Linux right?
If so, is the structure above helpful for psci to associate the cpu
requesting a state to the specific power domain in the power-domains list?
Or is this all encoded in the parameter to PSCI suspend? In that case,
what is the utility?
> + - cache-state-retained
> + Usage: See definition
> + Value type: <none>
> + Definition: if present cache memory is retained on power down,
> + otherwise it is lost.
> +
> + - processor-state-retained
> + Usage: See definition
> + Value type: <none>
> + Definition: if present CPU processor logic is retained on
> + power down, otherwise it is lost.
I don't see a good example of these two retained state properties.
Isn't this the purpose of idle_retained state? In the explanations, is
the term 'power down' the same as sleep or off?
> +
> +cpus {
> + #size-cells = <0>;
> + #address-cells = <2>;
> +
> + cpu-idle-states {
> +
> + STATE0: state0 {
> + compatible = "arm,cpu-idle-state";
> + index = <3>;
Are the index fields of nested states independent of each other or
sequential?
ie:
- does index=3 here mean pd_cluster is sleep state, and index=2
below mean the cpu cluster is idle_retention? (both SBSA states)
- Or does index=3 here mean this state is the next cpu-idle state after
STATE0_1 below, which has index=2? In this case, are the indexes
implied to be increasing in order of most power savings?
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x1010000>;
> + entry-latency = <500>;
> + exit-latency = <1000>;
> + min-residency = <2500>;
> + power-domains = <&pd_clusters 0>;
> + STATE0_1: state0 {
Should this be STATE0_0?
> + compatible = "arm,cpu-idle-state";
> + index = <2>;
> + entry-method = "arm,psci-cpu-suspend";
> + psci-power-state = <0x0010000>;
> + entry-latency = <200>;
> + exit-latency = <400>;
> + min-residency = <300>;
> + power-domains = <&pd_cores 0>,
> + <&pd_cores 1>,
...
> + <&pd_cores 7>;
> + };
> + };
Would it be possible to add an example illustrating more
complex cluster/cpu power states? Maybe where both the cpus and
cluster have multiple states (sleep/retention)?
The current example seems to show just the cpu idle_retention state,
and the cluster off state.
Maybe an example of how you'd represent something like this with the new
bindings:
(in increasing order of power saving)
+-----------------+--------------------+-----------------------------------+
| cpu | cluster | Notes
+-----------------+--------------------+-----------------------------------+
| running | running | not specified running
| idle_standby | running | not specified WFI
| idle_retention | running |
| idle_retention | idle_retention |
| sleep | idle_retention |
| sleep | sleep |
+-----------------|--------------------+-----------------------------------+
The CPU has 4 states: running, idle standby, idle_retention and sleep.
the first two are not specified per the instructions.
Then the cluster has 3 states: running, retention and sleep.
Maybe a complex case like this would be helpful to understand how the
bindings should be used.
Thanks,
Sebastian
^ permalink raw reply
* [PATCH] ARM: tegra: dalmore: fix irq trigger type
From: Joseph Lo @ 2014-02-13 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FBCDFD.1040902@wwwdotorg.org>
On 02/13/2014 03:39 AM, Stephen Warren wrote:
> On 02/11/2014 02:21 PM, Stefan Agner wrote:
>> Am 2014-02-11 21:47, schrieb Thierry Reding:
>>> On Tue, Feb 11, 2014 at 09:11:32PM +0100, Stefan Agner wrote:
>>>> Trigger type needs to be IRQ_TYPE_LEVEL_HIGH since the interrupt
>>>> signal gets inverted by the PMC (configured by the invert-interrupt
>>>> property).
>>>
>>> Isn't the reason the other way around? The PMIC generates a low-level
>>> interrupt, but the GIC can only be configured to accept high-level (or
>>> rising edge) and therefore the nvidia,invert-interrupt property needs to
>>> be set in the PMC node?
>> Hm yes agreed. I should also write the whole story here, maybe this:
>>
>> The GIC only support high-active interrupts. When using a PMIC with
>> low-active interrupt, the PMC has to be configured by using the
>> nvidia,invert-interrupt property in its node.
>>
>> This fix sets the GIC back to high-active and reverts commit
>> eca8f98e404934027f84f72882c5e92ffbd9e5f5.
>
> (Trimming CC lists)
>
> Stefan,
>
> It'd be best to include the commit subject rather than just the commit
> hash, i.e.:
>
> ... and reverts commit eca8f98e4049 "ARM: tegra: dalmore: fix the irq
> trigger type of Palmas MFD device".
>
> It may also be helpful for the commit description to quote the kernel
> boot message which this patch solves:
>
>> [ 0.215178] genirq: Setting trigger mode 8 for irq 118 failed (gic_set_type+0x0/0xf4)
>
> For me, applying this patch actually *causes* an interrupt storm, rather
> than preventing one. Yet without it, no interrupts occur at all. I
> wonder if the driver has a bug where it's not correctly clearing all
> interrupt status (e.g. something pre-existing before boot), so once the
> polarity is set up correctly, the interrupt is stuck?
>
> Joseph,
>
> As the author of the patch that's being reverted, can you please comment
> here?
>
I had explained why I fixed this here.
https://patchwork.kernel.org/patch/2832646/
By checking the PMU_INT signal in the schematic of Dalmore, it only
supports active low. It was connected to !PWR_INT of Tegra114 that will
cause the system wake up automatically when syspended to LP0 if active
high.
That's why my change is setting the IRQ type of PMIC to active low and
keep the "nvidia,invert-interrupt". And it can make the LP0/1/2 work
proper.
So this patch will make the PMIC not working on Dalmore and break the
suspend function.
-Joseph
^ permalink raw reply
* [RFC/PATCH 2/3] arm: Add ARCH_WANT_OF_RANDOMNESS
From: Laura Abbott @ 2014-02-13 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212164907.0E958C407C9@trevor.secretlab.ca>
On 2/12/2014 8:49 AM, Grant Likely wrote:
> On Tue, 11 Feb 2014 17:33:24 -0800, Laura Abbott <lauraa@codeaurora.org> wrote:
>> The stack canary for ARM is currently the same across reboots
>> due to lack of randomness early enough. Add ARCH_WANT_OF_RANDOMNESS
>> to allow devices to add whatever randomness they need.
>>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>
> Do you have a draft patch for a user of this yet?
>
I had a particular patch in mind but I need to re-work it to work with
the upstream tree. I wanted to at least send out the infrastructure to
see how open people were to the idea. After reading the comments, I have
a couple more ideas of users as well. I'll see if I can work that in for v2.
> g.
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 08/14] net: axienet: Removed checkpatch errors/warnings
From: Joe Perches @ 2014-02-13 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <75b669c0a947effe74b291093abfa8c71f83736a.1392220536.git.michal.simek@xilinx.com>
On Wed, 2014-02-12 at 16:55 +0100, Michal Simek wrote:
> From: Srikanth Thokala <srikanth.thokala@xilinx.com>
trivia:
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> + netdev_err(lp->ndev,
> + "axienet_device_reset DMA reset timeout!\n");
could you please align multi-line arguments to the
appropriate open parenthesis?
netdev_err(lp->ndev,
"axienet_device_reset DMA reset timeout!\n");
or maybe:
netdev_err(lp->ndev, "%s: "DMA reset timeout!\n",
__func__);
> @@ -484,8 +484,8 @@ static void axienet_device_reset(struct net_device *ndev)
> }
>
> if (axienet_dma_bd_init(ndev)) {
> - dev_err(&ndev->dev, "axienet_device_reset descriptor "
> - "allocation failed\n");
> + netdev_err(ndev,
> + "axienet_device_reset descriptor allocation failed\n");
etc, et al.
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
[]
> @@ -161,19 +161,19 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np)
>
> np1 = of_find_node_by_name(NULL, "cpu");
> if (!np1) {
> - printk(KERN_WARNING "%s(): Could not find CPU device node.",
> - __func__);
> - printk(KERN_WARNING "Setting MDIO clock divisor to "
> - "default %d\n", DEFAULT_CLOCK_DIVISOR);
> + netdev_warn(lp->ndev, "Could not find CPU device node.");
missing trailing "\n" to terminate message.
> + netdev_warn(lp->ndev,
> + "Could not find clock ethernet controller property.");
here too. (and alignment)
^ permalink raw reply
* [PATCH 0/14] Xilinx axi ethernet patches
From: David Miller @ 2014-02-13 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>
From: Michal Simek <michal.simek@xilinx.com>
Date: Wed, 12 Feb 2014 16:55:34 +0100
> I have exctracted patches which I have in our
> xilinx git tree which are missing in the mainline.
>
> The first two patches fix compilation error and
> warnings. Then 5 feature patches
> and the rest is OF cleanup and with kernel-doc
> and checkpatch problems.
You should not combine bug fix and feature patches.
Rather, you should submit bug fixes against the 'net' tree. Then when
those bug fixes get applied and propagate to the 'net-next' tree you
can submit the feature patches and cleanups against the 'net-next'
tree.
^ permalink raw reply
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Laura Abbott @ 2014-02-13 0:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402121251.06280.arnd@arndb.de>
On 2/12/2014 3:51 AM, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Laura Abbott wrote:
>> This is an RFC to seed the random number pool earlier when using devicetree.
>> The big issue this is trying to solve is the fact that the stack canary for
>> ARM tends to be the same across bootups of the same device. This is because
>> the random number pools do not get initialized until after the canary has
>> been set up. The canary can be moved later, but in general there is still
>> no way to reliably get random numbers early for other features (e.g. vector
>> randomization).
>
> Implementation-wise this looks reasonable, and it obviously addresses a
> very real problem.
>
>> The goal here is to allow devices to add to the random pools via
>> add_device_randomness or some other method of their chosing at FDT time.
>> I realize that ARCH_RANDOM is already available but this didn't work because
>> 1) ARCH_RANDOM is not multi-platform compatible without added
>> infrastructure to ARM
>
> That could certainly be done, but I agree that a more generic
> approach like you did is nicer. One thing that might be useful
> would be to wire up your OF_RANDOM infrastructure as a generic
> implementation of ARCH_RANDOM, and merge your header file into
> include/asm-generic/archrandom.h, with an added way to call
> arch_get_random_long() for the devices you add.
>
I originally tried that approach but ran into some hiccups related to
mapping for access to the HWRNG. early_ioremap would be needed to access
hardware registers but on ARM early_ioremap does not persist across
paging init. I couldn't come up with a sufficiently not terrible way to
unmap the early mapping and re-map with a proper ioremap.
>> The big reason to skip ARCH_RANDOM though is that the random number generation
>> we have would be reasonable if only seeded earlier.
>
> Yes, makes sense.
>
> I also wonder if we should add a 'trivial' implementation that just
> reads a DT property full of random numbers to use as either an initial
> seed, or to feed into arch_get_random_long(). This would allow the
> boot loader to pass any entropy it has already gathered into the kernel,
> but leaves the danger that people might pass static not-so-random data
> through a precompiled dtb file ;-). If we get the boot loaders to be
> smart enough, doing only this would be a much simpler kernel implementation
> than your suggestion, but I'm not sure how far I want to trust boot loaders.
>
This was similar to an option discussed internally (passing a seed on
the command line). Ultimately, it was concluded that relying on the
bootloader to do this would be too much overhead vs. doing all the work
in the kernel.
> Another possibilitiy is to mix in the any contents of a "local-mac-address"
> property into the entropy at early DT probing, which would still be
> deterministic for a given machine and should not count as entropty,
> but at least give each machine with this property a unique seed in the
> absence of any other entropy source.
Is this typically updated by the bootloader as well? I'm looking at the
tree and most of the instances of local-mac-address I see are all zero.
>
> Arnd
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
From: Rob Herring @ 2014-02-12 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1882539.R1gpoLLYks@wuerfel>
On Wed, Feb 12, 2014 at 1:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
>> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
>> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
>> > > I brought this up at last weeks devicetree irc meeting. My goal is to
>> > > provide early randomness for kaslr on ARM. Currently, my idea is modify
>> > > the init script to save an additional random seed from /dev/urandom to
>> > > /boot/random-seed.
>> > >
>> > > The bootloader would then load this file into ram, and pass the
>> > > address/size to the kernel either via dt, or commandline. kaslr (run in
>> > > the decompressor) would consume some of this randomness, and then
>> > > random.c would consume the rest in a non-crediting initialization.
>> >
>> > I like the idea, but wouldn't it be easier to pass actual random data
>> > using DT, rather than the address/size?
>>
>> I thought about that at first, but that requires either that the
>> bootloader be upgraded to insert the data, or that userspace is
>> modifying the dtb at least twice per boot.
>>
>> I chose address/size to facilitate modifying existing/fielded devices.
>> The user could modify the dtb once, and modify the bootloader
>> environment to load X amount to Y address. As a fallback, it could be
>> expressed on the commandline for non-DT bootloaders.
>
> Ah, so you are interested in boot loaders that can be scripted to do
> what you had in mind but cannot be scripted to add or modify a DT
> property. I hadn't considered that, but you are probably right that
> this is at least 90% of the systems you'd find in the wild today.
>
> Thinking this a bit further, I wonder if (at least upstream) u-boot
> has a way to modify DT properties in a scripted way that would allow
> the direct property. It sounds like a generally useful feature not
> just for randomness, so if that doesn't already work, maybe someone
> can implement it. In the simplest case, you'd only need to find the
> address of an existing property in the dtb and load a file to
> that location.
You would be referring to the u-boot fdt command which can read and
set properties. Of course, like all u-boot commands, that may or may
not be enabled by a vendor's u-boot. :(
Rob
^ 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