* [PATCH 1/3] arm64: mm: Remove PMD_BIT_FUNC macro
From: Steve Capper @ 2014-02-06 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391696171-8922-1-git-send-email-steve.capper@linaro.org>
Expand out the pmd thp manipulation functions. This makes our life
easier when using things like tags and cscope.
Signed-off-by: Steve Capper <steve.capper@linaro.org>
---
arch/arm64/include/asm/pgtable.h | 51 ++++++++++++++++++++++++++++++++--------
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b524dcd..a3fb1e4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -247,16 +247,47 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
#define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING)
#endif
-#define PMD_BIT_FUNC(fn,op) \
-static inline pmd_t pmd_##fn(pmd_t pmd) { pmd_val(pmd) op; return pmd; }
-
-PMD_BIT_FUNC(wrprotect, |= PMD_SECT_RDONLY);
-PMD_BIT_FUNC(mkold, &= ~PMD_SECT_AF);
-PMD_BIT_FUNC(mksplitting, |= PMD_SECT_SPLITTING);
-PMD_BIT_FUNC(mkwrite, &= ~PMD_SECT_RDONLY);
-PMD_BIT_FUNC(mkdirty, |= PMD_SECT_DIRTY);
-PMD_BIT_FUNC(mkyoung, |= PMD_SECT_AF);
-PMD_BIT_FUNC(mknotpresent, &= ~PMD_TYPE_MASK);
+static inline pmd_t pmd_wrprotect(pmd_t pmd)
+{
+ pmd_val(pmd) |= PMD_SECT_RDONLY;
+ return pmd;
+}
+
+static inline pmd_t pmd_mkold(pmd_t pmd)
+{
+ pmd_val(pmd) &= ~PMD_SECT_AF;
+ return pmd;
+}
+
+static inline pmd_t pmd_mksplitting(pmd_t pmd)
+{
+ pmd_val(pmd) |= PMD_SECT_SPLITTING;
+ return pmd;
+}
+
+static inline pmd_t pmd_mkwrite(pmd_t pmd)
+{
+ pmd_val(pmd) &= ~PMD_SECT_RDONLY;
+ return pmd;
+}
+
+static inline pmd_t pmd_mkdirty(pmd_t pmd)
+{
+ pmd_val(pmd) |= PMD_SECT_DIRTY;
+ return pmd;
+}
+
+static inline pmd_t pmd_mkyoung(pmd_t pmd)
+{
+ pmd_val(pmd) |= PMD_SECT_AF;
+ return pmd;
+}
+
+static inline pmd_t pmd_mknotpresent(pmd_t pmd)
+{
+ pmd_val(pmd) &= ~PMD_TYPE_MASK;
+ return pmd;
+}
#define pmd_mkhuge(pmd) (__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
--
1.8.1.4
^ permalink raw reply related
* [PATCH 2/3] arm64: mm: Route pmd thp functions through pte equivalents
From: Steve Capper @ 2014-02-06 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391696171-8922-1-git-send-email-steve.capper@linaro.org>
Rather than have separate hugetlb and transparent huge page pmd
manipulation functions, re-wire our thp functions to simply call the
pte equivalents.
This allows THP to take advantage of the new PTE_WRITE logic introduced
in:
c2c93e5 arm64: mm: Introduce PTE_WRITE
To represent splitting THPs we use the PTE_SPECIAL bit as this is not
used for pmds.
Signed-off-by: Steve Capper <steve.capper@linaro.org>
---
arch/arm64/include/asm/pgtable.h | 67 +++++++++++++++++++++-------------------
1 file changed, 35 insertions(+), 32 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index a3fb1e4..a5d5832 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -228,59 +228,65 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
#define __HAVE_ARCH_PTE_SPECIAL
/*
- * Software PMD bits for THP
- */
-
-#define PMD_SECT_DIRTY (_AT(pmdval_t, 1) << 55)
-#define PMD_SECT_SPLITTING (_AT(pmdval_t, 1) << 57)
-
-/*
* THP definitions.
*/
-#define pmd_young(pmd) (pmd_val(pmd) & PMD_SECT_AF)
-
#define __HAVE_ARCH_PMD_WRITE
-#define pmd_write(pmd) (!(pmd_val(pmd) & PMD_SECT_RDONLY))
+static inline long pmd_write(pmd_t pmd)
+{
+ pte_t pte = __pte(pmd_val(pmd));
+ return pte_write(pte);
+}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
#define pmd_trans_huge(pmd) (pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT))
-#define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING)
+
+static inline long pmd_trans_splitting(pmd_t pmd)
+{
+ pte_t pte = __pte(pmd_val(pmd));
+ return pte_special(pte);
+}
#endif
+static inline long pmd_young(pmd_t pmd)
+{
+ pte_t pte = __pte(pmd_val(pmd));
+ return pte_young(pte);
+}
+
static inline pmd_t pmd_wrprotect(pmd_t pmd)
{
- pmd_val(pmd) |= PMD_SECT_RDONLY;
- return pmd;
+ pte_t pte = pte_wrprotect(__pte(pmd_val(pmd)));
+ return __pmd(pte_val(pte));
}
static inline pmd_t pmd_mkold(pmd_t pmd)
{
- pmd_val(pmd) &= ~PMD_SECT_AF;
- return pmd;
+ pte_t pte = pte_mkold(__pte(pmd_val(pmd)));
+ return __pmd(pte_val(pte));
}
static inline pmd_t pmd_mksplitting(pmd_t pmd)
{
- pmd_val(pmd) |= PMD_SECT_SPLITTING;
- return pmd;
+ pte_t pte = pte_mkspecial(__pte(pmd_val(pmd)));
+ return __pmd(pte_val(pte));
}
static inline pmd_t pmd_mkwrite(pmd_t pmd)
{
- pmd_val(pmd) &= ~PMD_SECT_RDONLY;
- return pmd;
+ pte_t pte = pte_mkwrite(__pte(pmd_val(pmd)));
+ return __pmd(pte_val(pte));
}
static inline pmd_t pmd_mkdirty(pmd_t pmd)
{
- pmd_val(pmd) |= PMD_SECT_DIRTY;
- return pmd;
+ pte_t pte = pte_mkdirty(__pte(pmd_val(pmd)));
+ return __pmd(pte_val(pte));
}
static inline pmd_t pmd_mkyoung(pmd_t pmd)
{
- pmd_val(pmd) |= PMD_SECT_AF;
- return pmd;
+ pte_t pte = pte_mkyoung(__pte(pmd_val(pmd)));
+ return __pmd(pte_val(pte));
}
static inline pmd_t pmd_mknotpresent(pmd_t pmd)
@@ -297,15 +303,6 @@ static inline pmd_t pmd_mknotpresent(pmd_t pmd)
#define pmd_page(pmd) pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
-static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
-{
- const pmdval_t mask = PMD_SECT_USER | PMD_SECT_PXN | PMD_SECT_UXN |
- PMD_SECT_RDONLY | PMD_SECT_PROT_NONE |
- PMD_SECT_VALID;
- pmd_val(pmd) = (pmd_val(pmd) & ~mask) | (pgprot_val(newprot) & mask);
- return pmd;
-}
-
#define set_pmd_at(mm, addr, pmdp, pmd) set_pmd(pmdp, pmd)
static inline int has_transparent_hugepage(void)
@@ -414,6 +411,12 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
return pte;
}
+static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
+{
+ pte_t pte = pte_modify(__pte(pmd_val(pmd)), newprot);
+ return __pmd(pte_val(pte));
+}
+
extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
--
1.8.1.4
^ permalink raw reply related
* [PATCH 3/3] arm64: mm: Correct definition of pmd_mknotpresent
From: Steve Capper @ 2014-02-06 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391696171-8922-1-git-send-email-steve.capper@linaro.org>
pmd_mknotpresent currently creates a faulting pmd by clearing the valid
bit. Unfortunately pmd_present(.) will report such pmds as being
present!
This patch re-defines pmd_mknotpresent such that __pmd(0) is returned
instead.
Signed-off-by: Steve Capper <steve.capper@linaro.org>
---
arch/arm64/include/asm/pgtable.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index a5d5832..5d266e4 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -291,8 +291,7 @@ static inline pmd_t pmd_mkyoung(pmd_t pmd)
static inline pmd_t pmd_mknotpresent(pmd_t pmd)
{
- pmd_val(pmd) &= ~PMD_TYPE_MASK;
- return pmd;
+ return __pmd(0);
}
#define pmd_mkhuge(pmd) (__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
--
1.8.1.4
^ permalink raw reply related
* [PATCH 1/2] PPC: powernv: remove redundant cpuidle_idle_call()
From: Nicolas Pitre @ 2014-02-06 14:16 UTC (permalink / raw)
To: linux-arm-kernel
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/powerpc/platforms/powernv/setup.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index 21166f65c9..a932feb290 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -26,7 +26,6 @@
#include <linux/of_fdt.h>
#include <linux/interrupt.h>
#include <linux/bug.h>
-#include <linux/cpuidle.h>
#include <asm/machdep.h>
#include <asm/firmware.h>
@@ -217,16 +216,6 @@ static int __init pnv_probe(void)
return 1;
}
-void powernv_idle(void)
-{
- /* Hook to cpuidle framework if available, else
- * call on default platform idle code
- */
- if (cpuidle_idle_call()) {
- power7_idle();
- }
-}
-
define_machine(powernv) {
.name = "PowerNV",
.probe = pnv_probe,
@@ -236,7 +225,7 @@ define_machine(powernv) {
.show_cpuinfo = pnv_show_cpuinfo,
.progress = pnv_progress,
.machine_shutdown = pnv_shutdown,
- .power_save = powernv_idle,
+ .power_save = power7_idle,
.calibrate_decr = generic_calibrate_decr,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH 2/2] ARM64: powernv: remove redundant cpuidle_idle_call()
From: Nicolas Pitre @ 2014-02-06 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391696188-14540-1-git-send-email-nicolas.pitre@linaro.org>
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/arm64/kernel/process.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 1c0a9be2ff..9cce0098f4 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -33,7 +33,6 @@
#include <linux/kallsyms.h>
#include <linux/init.h>
#include <linux/cpu.h>
-#include <linux/cpuidle.h>
#include <linux/elfcore.h>
#include <linux/pm.h>
#include <linux/tick.h>
@@ -94,10 +93,8 @@ void arch_cpu_idle(void)
* This should do all the clock switching and wait for interrupt
* tricks
*/
- if (cpuidle_idle_call()) {
- cpu_do_idle();
- local_irq_enable();
- }
+ cpu_do_idle();
+ local_irq_enable();
}
#ifdef CONFIG_HOTPLUG_CPU
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH 1/2] PPC: powernv: remove redundant cpuidle_idle_call()
From: Thomas Gleixner @ 2014-02-06 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391696188-14540-1-git-send-email-nicolas.pitre@linaro.org>
An Thu, 6 Feb 2014, Nicolas Pitre wrote:
> The core idle loop now takes care of it.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* [PATCH 2/2] ARM64: powernv: remove redundant cpuidle_idle_call()
From: Thomas Gleixner @ 2014-02-06 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391696188-14540-2-git-send-email-nicolas.pitre@linaro.org>
On Thu, 6 Feb 2014, Nicolas Pitre wrote:
> The core idle loop now takes care of it.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* [PATCH v5 1/3] clocksource: timer-keystone: introduce clocksource driver for Keystone
From: Thomas Gleixner @ 2014-02-06 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F3975B.2080806@ti.com>
On Thu, 6 Feb 2014, Ivan Khoronzhuk wrote:
> On 02/05/2014 10:27 PM, Thomas Gleixner wrote:
> > On Wed, 5 Feb 2014, Ivan Khoronzhuk wrote:
> > > + /* here we have to be sure the timer has been disabled */
> > Sigh. This is not a proper explanation for a barrier, really. You want
> > to explain what it serializes against what. i.e. you want to explain
> > why you are using the relaxed functions and avoid a separate non
> > relaxed variant in favour of an explicit barrier.
> >
> > > + __iowmb();
> > The proper thing is to have an inline function key_stone_barrier() and
> > a full explanation of the issue in exactly that place instead of
> > handwaving comments here and there.
> >
> > Thanks,
> >
> > tglx
>
> I can add new inline function like:
>
> /**
> * keystone_timer_barrier: write memory barrier
> * use explicit barrier to avoid using readl/writel non relaxed function
> * variants, because in our case relaxed variants hide the true places
> * where barrier is needed.
> */
> static inline void keystone_timer_barrier(void)
> {
> __iowmb();
> }
>
> and use it where it is needed.
> Are you OK with it?
>
> And I propose to leave comments under the barriers in order to be
> able to understand why they are used.
Sounds good.
^ permalink raw reply
* [PATCH 3/3] ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi
From: Nishanth Menon @ 2014-02-06 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391677818-21154-4-git-send-email-florian.vaussard@epfl.ch>
On 02/06/2014 03:10 AM, Florian Vaussard wrote:
> Unfortunatly the device tree for older OMAP35xx Overo cannot be used
Unfortunately ?
> with newer OMAP36xx and vice-versa. To address this issue, move most of
> the Tobi DTS to a common include file, and create model-specific Tobi
> DTS.
>
[...]
> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts b/arch/arm/boot/dts/omap3-overo-tobi.dts
> new file mode 100644
> index 0000000..2f82192
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Tobi expansion board is manufactured by Gumstix Inc.
> + */
> +
> +/dts-v1/;
> +
> +#include "omap34xx.dtsi"
> +#include "omap3-overo-tobi-common.dtsi"
> +
> +/ {
> + model = "OMAP35xx Gumstix Overo on Tobi";
> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3";
To reduce any future problems, I suggest:
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo",
"ti,omap3430", "ti,omap3";
> +};
> +
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/3] ARM: OMAP2+: AM43x: Add ID for ES1.1
From: Nishanth Menon @ 2014-02-06 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391676348-32339-3-git-send-email-lokeshvutla@ti.com>
On 02/06/2014 02:45 AM, Lokesh Vutla wrote:
> Adding ID for AM437x ES1.1 silicon.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/mach-omap2/id.c | 14 ++++++++++++--
> arch/arm/mach-omap2/soc.h | 3 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 9428c5f..8a05eaf 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -465,8 +465,18 @@ void __init omap3xxx_check_revision(void)
> }
> break;
> case 0xb98c:
> - omap_revision = AM437X_REV_ES1_0;
> - cpu_rev = "1.0";
> + switch (rev) {
> + case 0:
> + omap_revision = AM437X_REV_ES1_0;
> + cpu_rev = "1.0";
> + break;
> + case 1:
> + /* FALLTHROUGH */
> + default:
> + omap_revision = AM437X_REV_ES1_1;
> + cpu_rev = "1.1";
> + break;
> + }
> break;
> case 0xb8f2:
> switch (rev) {
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index 076bd90..30abcc8 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -438,7 +438,8 @@ IS_OMAP_TYPE(3430, 0x3430)
> #define AM335X_REV_ES2_1 (AM335X_CLASS | (0x2 << 8))
>
> #define AM437X_CLASS 0x43700000
> -#define AM437X_REV_ES1_0 AM437X_CLASS
> +#define AM437X_REV_ES1_0 (AM437X_CLASS | (0x10 << 8))
> +#define AM437X_REV_ES1_1 (AM437X_CLASS | (0x11 << 8))
>
> #define OMAP443X_CLASS 0x44300044
> #define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 << 8))
>
can you also check if socbus shows proper results?
I had http://slexy.org/view/s20e3OsIVx with v3.14-rc1
--
Regards,
Nishanth Menon
^ permalink raw reply
* [GIT PULL] ARM: imx: fixes for 3.14
From: Shawn Guo @ 2014-02-06 14:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The 3.13 stable tree will also need this fix. But since it does not
apply to 3.13 cleanly, we will need to send another one for 3.13
stable kernel, after this one hits mainline.
Shawn
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.14
for you to fetch changes up to 5d0a87ba5875794ec3df14aa74ee8e18ef47d6b4:
ARM: imx6: Initialize low-power mode early again (2014-02-06 20:26:26 +0800)
----------------------------------------------------------------
i.MX fixes for 3.14:
- Fix a regression (system hang) when preemption is enabled
(CONFIG_PREEMPT=y).
----------------------------------------------------------------
Philipp Zabel (1):
ARM: imx6: Initialize low-power mode early again
arch/arm/mach-imx/clk-imx6q.c | 3 +++
arch/arm/mach-imx/clk-imx6sl.c | 3 +++
arch/arm/mach-imx/pm-imx6q.c | 2 --
3 files changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* v3.14-rc1 locking bug in system suspend
From: Shawn Guo @ 2014-02-06 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205145408.GA3708@S2101-09.ap.freescale.net>
On Wed, Feb 05, 2014 at 10:54:10PM +0800, Shawn Guo wrote:
> I start seeing the following locking bug on IMX6 with suspend operation
> after moving to v3.14-rc1. Before I start looking into the issue, I
> would like to confirm if it's an IMX specific problem or one seen on
> other platforms. Please ask if you need more info.
Sorry. This is not a new bug of v3.14-rc1. It's been there with
v3.13-rc for a while. It looks like there is something wrong in the
use of power_lock in struct snd_card. Will dig into it.
Shawn
^ permalink raw reply
* [GIT PULL] ARM: imx: device tree changes for 3.15, take 1
From: Shawn Guo @ 2014-02-06 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402061445.06234.arnd@arndb.de>
On Thu, Feb 06, 2014 at 02:45:05PM +0100, Arnd Bergmann wrote:
> On Wednesday 05 February 2014, Shawn Guo wrote:
> > Hi arm-soc folks,
> >
> > This is basically imx-dt-3.14 pull request that missed the 3.14 merge
> > window with the pingrp removal series applied on top of. It also
> > includes a few additional board support I collected since imx-dt-3.14.
> > There will be another round of IMX DT changes for 3.15 later, but this
> > one should be the majority. Please pull, thanks.
>
> Hi Shawn,
>
> no objections to the stuff you add here, but the way it's organized
> is not good. Instead of adding the controversial patches first and
> then reverting them, please redo the series so you don't actually
> have the patches in the history. I see that you have rebased the
> patches on 3.14-rc1 already so there really shouldn't be any cross-
> tree dependencies that make it necessary to keep them in.
I haven't checked the patches one by one in the pull request, but it
probably means that I will have to redo most of the patches, because
every single new board dts and addition of device for existing board
have new pinctrl data along with them. I will look at the work/effort
closer tomorrow.
>
> Also, because of the pure size of the pull request:
>
> 105 files changed, 14073 insertions(+), 3127 deletions(-)
>
> it would be nice to split it up into smaller units. A good
> separation would be to have new board support in one pull
> request and the changes to existing boards in another one.
Ok, I will try.
Shawn
^ permalink raw reply
* [PATCH] ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
From: Roger Quadros @ 2014-02-06 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391612769-27890-1-git-send-email-illia.smyrnov@globallogic.com>
On 02/05/2014 05:06 PM, Illia Smyrnov wrote:
> Commit 313a76e (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced
> softreset bit cleaning right after set one. It is caused L3 error for
> OMAP4 ISS because ISS register write occurs when ISS reset process is in
> progress. Avoid this situation by cleaning softreset bit later, when reset
> process is successfully finished.
>
> Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com>
Acked-by: Roger Quadros <rogerq@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 20 +++++++++++---------
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 42d8188..1f33f5d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1947,29 +1947,31 @@ static int _ocp_softreset(struct omap_hwmod *oh)
> goto dis_opt_clks;
>
> _write_sysconfig(v, oh);
> - ret = _clear_softreset(oh, &v);
> - if (ret)
> - goto dis_opt_clks;
> -
> - _write_sysconfig(v, oh);
>
> if (oh->class->sysc->srst_udelay)
> udelay(oh->class->sysc->srst_udelay);
>
> c = _wait_softreset_complete(oh);
> - if (c == MAX_MODULE_SOFTRESET_WAIT)
> + if (c == MAX_MODULE_SOFTRESET_WAIT) {
> pr_warning("omap_hwmod: %s: softreset failed (waited %d usec)\n",
> oh->name, MAX_MODULE_SOFTRESET_WAIT);
> - else
> + ret = -ETIMEDOUT;
> + goto dis_opt_clks;
> + } else {
> pr_debug("omap_hwmod: %s: softreset in %d usec\n", oh->name, c);
> + }
> +
> + ret = _clear_softreset(oh, &v);
> + if (ret)
> + goto dis_opt_clks;
> +
> + _write_sysconfig(v, oh);
>
> /*
> * XXX add _HWMOD_STATE_WEDGED for modules that don't come back from
> * _wait_target_ready() or _reset()
> */
>
> - ret = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
> -
> dis_opt_clks:
> if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
> _disable_optional_clocks(oh);
>
^ permalink raw reply
* [PATCH] ARM: dts: imx6sl-evk: Add debug LED support
From: Fabio Estevam @ 2014-02-06 15:08 UTC (permalink / raw)
To: linux-arm-kernel
GPIO3_20 is connected to a debug LED.
Add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/dts/imx6sl-evk.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index 0001804..4d23e28 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -8,6 +8,7 @@
/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include "imx6sl.dtsi"
@@ -19,6 +20,18 @@
reg = <0x80000000 0x40000000>;
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+
+ user {
+ label = "debug";
+ gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -108,6 +121,12 @@
>;
};
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX6SL_PAD_HSIC_STROBE__GPIO3_IO20 0x17059
+ >;
+ };
+
pinctrl_kpp: kppgrp {
fsl,pins = <
MX6SL_PAD_KEY_ROW0__KEY_ROW0 0x1b010
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/4] Power: Reset: Generalize qnap-poweroff to with on Synology devices.
From: Jason Cooper @ 2014-02-06 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391634309-3123-2-git-send-email-andrew@lunn.ch>
+ Dmitry Eremin-Solenikov, David Woodhouse
On Wed, Feb 05, 2014 at 10:05:06PM +0100, Andrew Lunn wrote:
> The Synology NAS devices use a very similar mechanism to QNAP NAS
> devices to power off. Both send a single charactor command to a PIC,
> over the second serial port. However the baud rate and the command
> differ. Generalize the driver to support this.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> cc: Anton Vorontsov <anton@enomsg.org>
> ---
> .../bindings/power_supply/qnap-poweroff.txt | 5 ++-
> drivers/power/reset/qnap-poweroff.c | 46 +++++++++++++++-----
> 2 files changed, 40 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
> index 0347d8350d94..4ac3ee80dead 100644
> --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
> +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
> @@ -6,8 +6,11 @@ Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the
> microcontroller to turn the power off. This driver adds a handler to
> pm_power_off which is called to turn the power off.
>
> +Synology NAS devices use a similar scheme, but a different baud rate,
> +9660, and a different character, 1.
nit: s/9660/9600/
other than that,
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
> +
> Required Properties:
> -- compatible: Should be "qnap,power-off"
> +- compatible: Should be "qnap,power-off" or "synology,power-off"
>
> - reg: Address and length of the register set for UART1
> - clocks: tclk clock
> diff --git a/drivers/power/reset/qnap-poweroff.c b/drivers/power/reset/qnap-poweroff.c
> index 37f56f7ee926..10c91fa2466c 100644
> --- a/drivers/power/reset/qnap-poweroff.c
> +++ b/drivers/power/reset/qnap-poweroff.c
> @@ -1,5 +1,5 @@
> /*
> - * QNAP Turbo NAS Board power off
> + * QNAP Turbo NAS Board power off. Can also be used on Synology devices.
> *
> * Copyright (C) 2012 Andrew Lunn <andrew@lunn.ch>
> *
> @@ -25,17 +25,42 @@
>
> #define UART1_REG(x) (base + ((UART_##x) << 2))
>
> +struct power_off_cfg {
> + u32 baud;
> + char cmd;
> +};
> +
> +static const struct power_off_cfg qnap_power_off_cfg = {
> + .baud = 19200,
> + .cmd = 'A',
> +};
> +
> +static const struct power_off_cfg synology_power_off_cfg = {
> + .baud = 9600,
> + .cmd = '1',
> +};
> +
> +static const struct of_device_id qnap_power_off_of_match_table[] = {
> + { .compatible = "qnap,power-off",
> + .data = (void *) &qnap_power_off_cfg,
> + },
> + { .compatible = "synology,power-off",
> + .data = (void *) &synology_power_off_cfg,
> + },
> + {}
> +};
> +
> static void __iomem *base;
> static unsigned long tclk;
> +static struct power_off_cfg *cfg;
>
> static void qnap_power_off(void)
> {
> - /* 19200 baud divisor */
> - const unsigned divisor = ((tclk + (8 * 19200)) / (16 * 19200));
> + const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
>
> pr_err("%s: triggering power-off...\n", __func__);
>
> - /* hijack UART1 and reset into sane state (19200,8n1) */
> + /* hijack UART1 and reset into sane state */
> writel(0x83, UART1_REG(LCR));
> writel(divisor & 0xff, UART1_REG(DLL));
> writel((divisor >> 8) & 0xff, UART1_REG(DLM));
> @@ -44,16 +69,21 @@ static void qnap_power_off(void)
> writel(0x00, UART1_REG(FCR));
> writel(0x00, UART1_REG(MCR));
>
> - /* send the power-off command 'A' to PIC */
> - writel('A', UART1_REG(TX));
> + /* send the power-off command to PIC */
> + writel(cfg->cmd, UART1_REG(TX));
> }
>
> static int qnap_power_off_probe(struct platform_device *pdev)
> {
> + struct device_node *np = pdev->dev.of_node;
> struct resource *res;
> struct clk *clk;
> char symname[KSYM_NAME_LEN];
>
> + const struct of_device_id *match =
> + of_match_node(qnap_power_off_of_match_table, np);
> + cfg = (struct power_off_cfg *)match->data;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(&pdev->dev, "Missing resource");
> @@ -94,10 +124,6 @@ static int qnap_power_off_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct of_device_id qnap_power_off_of_match_table[] = {
> - { .compatible = "qnap,power-off", },
> - {}
> -};
> MODULE_DEVICE_TABLE(of, qnap_power_off_of_match_table);
>
> static struct platform_driver qnap_power_off_driver = {
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi
From: Florian Vaussard @ 2014-02-06 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F39DCC.8000006@ti.com>
On 02/06/2014 03:35 PM, Nishanth Menon wrote:
> On 02/06/2014 03:10 AM, Florian Vaussard wrote:
>> Unfortunatly the device tree for older OMAP35xx Overo cannot be used
> Unfortunately ?
Indeed
>> with newer OMAP36xx and vice-versa. To address this issue, move most of
>> the Tobi DTS to a common include file, and create model-specific Tobi
>> DTS.
>>
> [...]
>> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts b/arch/arm/boot/dts/omap3-overo-tobi.dts
>> new file mode 100644
>> index 0000000..2f82192
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts
>> @@ -0,0 +1,22 @@
>> +/*
>> + * Copyright (C) 2012 Florian Vaussard, EPFL Mobots group
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +/*
>> + * Tobi expansion board is manufactured by Gumstix Inc.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "omap34xx.dtsi"
>> +#include "omap3-overo-tobi-common.dtsi"
>> +
>> +/ {
>> + model = "OMAP35xx Gumstix Overo on Tobi";
>> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3";
> To reduce any future problems, I suggest:
> compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo",
> "ti,omap3430", "ti,omap3";
>
This was also my first thought, but "ti,omap3430" is not documented in
Documentation/devicetree/bindings/arm/omap/omap.txt. It is said that
"ti,omap3" defaults to OMAP3430. I do not know if omap35xx would be more
accurate, as these Overo are using OMAP3503 and OMAP3530.
Regards,
Florian
^ permalink raw reply
* [PATCH 3/3] ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi
From: Nishanth Menon @ 2014-02-06 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F3A681.9050300@epfl.ch>
On 02/06/2014 09:13 AM, Florian Vaussard wrote:
[...]
>>> +#include "omap34xx.dtsi"
>>> +#include "omap3-overo-tobi-common.dtsi"
>>> +
>>> +/ {
>>> + model = "OMAP35xx Gumstix Overo on Tobi";
>>> + compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3";
>> To reduce any future problems, I suggest:
>> compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo",
>> "ti,omap3430", "ti,omap3";
>>
>
> This was also my first thought, but "ti,omap3430" is not documented in
> Documentation/devicetree/bindings/arm/omap/omap.txt. It is said that
> "ti,omap3" defaults to OMAP3430. I do not know if omap35xx would be more
> accurate, as these Overo are using OMAP3503 and OMAP3530.
3430 should have been now documented with commit
89b6eef0d859bad4bcf7ad64560aa2891d6a37a0
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/omap/omap.txt#n64
We have not pulled out 3730 or 3530 separately out in linux as of
today as they are nothing but a packaging difference for larger board
community - there should be no internal differences - the only
functional variation has been am3517 - which got it's own compatible
property.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/4] DT: Vendor prefixes: Add ricoh, ssi and synology
From: Jason Cooper @ 2014-02-06 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391634309-3123-3-git-send-email-andrew@lunn.ch>
+ devicetree ML, DT maintainers.
On Wed, Feb 05, 2014 at 10:05:07PM +0100, Andrew Lunn wrote:
> The following patches make use of vendor names ricoh, ssi and
> synology. Add them to the vendor prefix list.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 3f900cd51bf0..1629e8f33578 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -69,6 +69,7 @@ ralink Mediatek/Ralink Technology Corp.
> ramtron Ramtron International
> realtek Realtek Semiconductor Corp.
> renesas Renesas Electronics Corporation
> +ricoh Richoh Co. Ltd.
s/Richoh/Ricoh/
other than that,
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
> rockchip Fuzhou Rockchip Electronics Co., Ltd
> samsung Samsung Semiconductor
> sbs Smart Battery System
> @@ -76,11 +77,13 @@ schindler Schindler
> sil Silicon Image
> silabs Silicon Laboratories
> simtek
> +sii Seiko Instruments, Inc.
> sirf SiRF Technology, Inc.
> snps Synopsys, Inc.
> st STMicroelectronics
> ste ST-Ericsson
> stericsson ST-Ericsson
> +synology Synology, Inc.
> ti Texas Instruments
> tlm Trusted Logic Mobility
> toshiba Toshiba Corporation
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 3/6] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Catalin Marinas @ 2014-02-06 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140206132643.GS26035@mudshark.cambridge.arm.com>
On Thu, Feb 06, 2014 at 01:26:44PM +0000, Will Deacon wrote:
> On Thu, Feb 06, 2014 at 12:23:40PM +0000, Catalin Marinas wrote:
> > On Thu, Feb 06, 2014 at 12:13:50PM +0000, Will Deacon wrote:
> > > Ok, so if we assume that a dsb(ishst) is sufficient because the CPU we're
> > > talking to is either (a) coherent in the inner-shareable domain or (b)
> > > incoherent, and we flushed everything to PoC, then why wouldn't a dmb(ishst)
> > > work?
> >
> > Because you want to guarantee the ordering between a store to Normal
> > Cacheable memory vs store to Device for the IPI (see the mailbox example
> > in the Barrier Litmus section ;)). The second is just a slave access, DMB
> > guarantees observability from the master access perspective.
>
> Ok, my reasoning is as follows:
>
> - CPU0 tries to message CPU1. It writes to a location in normal memory,
> then writes to the GICD to send the SGI
>
> - We need to ensure that CPU1 observes the write to normal memory before
> the write to GICD reaches the distributor. This is *not* about end-point
> ordering (the usual non-coherent DMA example).
>
> - A dmb ishst ensures that the two writes are observed in order by CPU1
> (and, in fact, the inner-shareable domain containing CPU0).
The last bullet point is not correct. DMB would only guarantee that the
two writes (memory and GICD) are observed by CPU1 if CPU1 actually read
the GICD (observability is defined for master accesses).
> so the only way this can break is if the GICD write reaches the distributor
> before being observed by CPU1 (otherwise, we know the mailbox write was
> observed by CPU1). I dread to think how you would build such a beast
> (dual-ported GICD with no serialisation to the same locations?)...
The above is possible because the CPU1 would never "observe" the GICD
write. It observes a side-effect of that write (interrupt) which is not
covered by DMB. You could argue that CPU1 reads GICC in the interrupt
handler but I'm not sure GICC vs GICD ordering is guaranteed (and I know
of hardware where not even accesses to the same GICD are guaranteed ;)).
> Furthermore, if we decide that device writes can reach their endpoints
Device writes are not observed according to the ARM ARM meaning of
"observability" (master accesses only; well, there is something about
Strongly Ordered memory and devices but it's not the case here and IIRC
refers to when a _device_ observes the write rather than a CPU observing
the write to that device, I need to read it again).
> before being observed by other inner-shareable observers, then doesn't that
> pose a potential problem for spinlocks? If I take a lock and write to a
> device, the write can hit the device before the lock appears to be taken.
> That doesn't sound right to me.
For simplicity, assuming that the lock acquiring was a simple STR, the
write to device can indeed hit the device before the STR is observed by
another CPU or device (that's why writel() has a DSB). This is however
not relevant as you don't care when it hit the device (unless you issue
IPIs). If considering master accesses, the below is valid even though B
could hit the device before A is observed by CPU1:
CPU0:
STR A, [Normal]
DMB
STR B, [Device]
CPU1:
LDR C, [Device]
DMB
LDR D, [Normal]
If on CPU1 C == B then D == A. The key here is that observability of
STR B, [Device] is done via another master access on CPU1 (LDR C,
[Device]) and not just the change to the device state.
When we talk about LDREX/STREX loop, I don't think the write to the
device can be issued before the STREX has been guaranteed to succeed
(not necessarily observed) and therefore the spinlock acquired (we don't
issue writes speculatively and the spinlock loop has a conditional
branch).
If we go to the definition of the STR observability (in short):
1. A load from a location returns the value written by the observed
store.
2. A store to a location changes the value written by the observed
store.
The "not observability" means _any_ of the above conditions is false. So
going back to your example, the write to the device can hit the device
_and_ the load of the spinlock value on another CPU1 still return the
unlocked value. However, a subsequent STREX on CPU1 would fail and the
LDREX restarted, eventually observing the STREX on CPU0.
If we talk about lock acquiring on another CPU and issuing of device
accesses, the DMB guarantees ordering (master accesses).
Another interesting scenario is the write to device followed by
spin_unlock and on another CPU spin_lock and device write. As per my
example above, I don't see any issue (change Normal with Device).
> Using a dsb(ishst) will ensure that we don't issue the GICD write until the
> mailbox is visible to CPU1, but may be overkill.
In the ARM ARM examples, the mailbox write generates the interrupt (it
is not visible to the other CPU at all).
--
Catalin
^ permalink raw reply
* [PATCH 3/4] DT: i2c: Trivial: Add sii,s35390a
From: Jason Cooper @ 2014-02-06 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391634309-3123-4-git-send-email-andrew@lunn.ch>
+ devicetree ML, DT maintainers
On Wed, Feb 05, 2014 at 10:05:08PM +0100, Andrew Lunn wrote:
> Add the Seiko Instruments Inc S35390a to the list of trivial i2c
> devices.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index 1a1ac2e560e9..e11ed0fe770c 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -58,6 +58,7 @@ plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ramtron,24c64 i2c serial eeprom (24cxx)
> ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
> samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
> +sii,s35390a 2-wire CMOS real-time clock
> st-micro,24c256 i2c serial eeprom (24cxx)
> stm,m41t00 Serial Access TIMEKEEPER
> stm,m41t62 Serial real-time clock (RTC) with alarm
> --
> 1.7.10.4
>
^ permalink raw reply
* [RFC/RFT 1/2] ARM: mm: introduce arch hooks for dma address translation routines
From: Dave Martin @ 2014-02-06 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402061332.00432.arnd@arndb.de>
On Thu, Feb 06, 2014 at 01:32:00PM +0100, Arnd Bergmann wrote:
> On Wednesday 05 February 2014, Dave Martin wrote:
> > On Tue, Feb 04, 2014 at 06:04:56PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 04 February 2014 11:38:32 Santosh Shilimkar wrote:
> > > > On Tuesday 04 February 2014 11:15 AM, Arnd Bergmann wrote:
> > > >
> > > > > 1. DMA is coherent
> > > > > 2. DMA space is offset from phys space
> > > > > 3. DMA space is smaller than 32-bit
> > > > > 4. DMA space is larger than 32-bit
> > > > > 5. DMA goes through an IOMMU
> >
> > As you explain above, these are properties of end-to-end paths between
> > a bus-mastering device and the destination. They aren't properties
> > of a device, or of a bus.
> >
> > For example, we can have the following system, which ePAPR can't describe
> > and wouldn't occur with PCI (or, at least would occur in a transparent
> > way so that software does not need to understand the difference between
> > this structure and a simple CPU->devices tree).
> >
> > C
> > |
> > v
> > I ---+
> > / \ \
> > / \ \
> > v v \
> > A ----> B \
> > \ v
> > +---------> D
> >
> > This follows from the unidirectional and minimalistic nature of ARM SoC
> > buses (AMBA family, AHB, APB etc. ... and most likely many others too).
> >
> > To describe A's DMA mappings correctly, the additional links must be
> > described, even though thay are irrelevant for direct CPU->device
> > transactions.
>
> Can you be more specific about what kind of hardware would use such
> a mapping? The interesting cases are normally all about accessing
> RAM, while your example seems to be for device-to-device DMA and
> that doesn't have to go through dma-ranges.
Imagine that D is RAM.
RAMs may be multi-ported, and it's possible that
Typical cases are where a DMA engine may have a dedicated path to RAM
which might or might not be coherent with other paths, or where there
are multiple, special-purpose RAMs in a system -- for example, some RAM
read by a display controller, which is also independently accessible by
>
> > dma-ranges does work for simpler cases. In particular, it works where all
> > bus-mastering children of a bus node can a) access each other using the
> > address space of the bus node, and b) all have the same view of the rest
> > of the system (which may be different from the view from outside the bus:
> > the dma-ranges property on the bus describes the difference).
> >
> > Sometimes, we may be able to describe an otherwise undescribable situation
> > by introducing additional fake bus nodes. But if there are cross-links
> > between devices, this won't always work.
> >
> >
> > This may not be the common case, but it does happen: we need to decide
> > whether to describe it propertly, or to describe a fantasy in the DT
> > and bodge around it elsewhere when it happens.
>
> Do you think this could be fully described if we add a "dma-parent"
> property that can redirect the "dma-ranges" parent address space to
> another node?
I don't think so. A "parent" property allows us to describe a DMA tree
that is different from the CPU->device tree. This works for interrupts,
which really are wired up as a tree. But it can't describe the cases
which aren't tree-like.
For example, in the above picture, B and D are both DMA-parents of A.
> If there are devices that have parts of their DMA address space on
> various buses, how about a "dma-ranges-ext" property that contains
> tuples of <&parent-phandle local-address parent-address size> rather
> than just <local-address parent-address size>?
In theory, that could work -- it solves my multiple-parents problem above.
But I do think the "parent" concept is being over-twisted here.
When a CPU acts as a bus master and access a device, we call the device
(recursively) a child of the CPU. So it's weird to use "parent" to
describe the same relationship when the master is a device, not a CPU.
I'm also not too keen on the "dma" name, since this implies that there
is something magically different about devices mastering devices as
compared with CPUs mastering devices, and may lead to inventing two
methods of describing master/slave linkage which are more different
than necessary.
However, I think this is primarily a disagreement about naming.
>
> > Similarly, for IOMMU, the ARM SMMU is an independent component which is
> > not directly associated with a bus: nor is there guaranteed to be a 1:1
> > correspondence. Simply wedging properties in a bus or device node to say
> > "this is associated with an IOMMU" is not always going to work: it is
> > what you flow through on a given device->device path that matters, and
> > that can vary from path to path.
>
> Right, I'm aware that the IOMMU may be per device rather than per-bus.
> This could be handled by faking extra buses, or possibly better with
> the dma-parent approach above, if that is allowed to point to either
> a bus or an IOMMU.
Indeed. One concept that could work is to treat every component that
transforms or routes transactions as a bus for DT purposes. This can
can complex, though: an IOMMU is all of:
a) a slave, accepting control transactions from CPUs and elsewhere
b) a master, generating transactions of its own to read translation
tables etc.
c) an interconnect, routing and transforming transactions from other
connected masters to other connected slaves.
d) an interrupt source
Note that the IOMMU may be in completely different places in the system
topology with regard to each role. This is a problem except for (d) where
already has a way to describe an independent topology for interrupts.
My own view is that devices of this type should be described using a
single node where all its relationships really do act at a single point
in the topology, and to split it up otherwise. So, an IOMMU would appear
as a bus node describing its interconnect role, which can most likely
describe the IOMMU's master role too, but with a separate node somewhere
describing its control interface, and a phandle linking them.
DMA address translation is then a matter of traversing links from the
mastering device to the destination device, or vice-versa. These
links may be described by dma-ranges where the mappings work as defined
by ePAPR, or a separate, phandle-based mechanism similar to the one
you describe, for the other cases.
There was some discussion of possible approaches in this thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215582.html
... but we didn't reach a conclusion yet.
Cheers
---Dave
^ permalink raw reply
* [PATCH v2] pwm: add CSR SiRFSoC PWM driver
From: Arnd Bergmann @ 2014-02-06 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xmtt2Pg_mHJmvt9uc3Y4gN7KUT1UOJhbr6FQYdiAH3qw@mail.gmail.com>
On Thursday 06 February 2014, Barry Song wrote:
> > How about modeling that other source as a fixed-rate clock in DT
> > then?
>
> sirfsoc clock drivers have a clock node for OSC whose index is "1".
> do you think the following is the right way to handle?
>
> in dts, put both pwm controller clock and OSC
> 672 pwm: pwm at b0130000 {
> 673 compatible = "sirf,prima2-pwm";
> 674 #pwm-cells = <2>;
> 675 reg = <0xb0130000 0x10000>;
> 676 clocks = <&clks 21>, <&clks 1>;
> 677 clock-names = "pwmc", "osc";
> 678 };
>
> and in pwm-sirf.c driver, use
> clk = clk_get(dev, "osc");
> clk_get_rate(clk);
>
> to get the rate in probe()?
Ah, if that's the right clock, it sounds great, yes.
Just make sure that the clock-names values make sense from the
point of view of the pwm node, rather than referring to the
name given in the clock provider.
Arnd
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Select CONFIG_SOC_DRA7XX
From: Nishanth Menon @ 2014-02-06 15:29 UTC (permalink / raw)
To: linux-arm-kernel
Select CONFIG_SOC_DRA7XX so that we can boot dra7-evm.
DRA7 family are A15 based processors that supports LPAE and an
evolutionary update to the OMAP5 generation of processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
based on v3.13-rc1 kernel tag - tested on v3.14-rc1 and next-20140206
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 845bc74..ee69829 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -29,6 +29,7 @@ CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP4=y
CONFIG_SOC_OMAP5=y
CONFIG_SOC_AM33XX=y
+CONFIG_SOC_DRA7XX=y
CONFIG_SOC_AM43XX=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_ARCH_SOCFPGA=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH V4 6/8] phy: st-miphy-40lp: Add SPEAr1310 and SPEAr1340 PCIe phy support
From: Arnd Bergmann @ 2014-02-06 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dca9c501de8386003142b463469c3d267a049eeb.1391661589.git.pratyush.anand@st.com>
On Thursday 06 February 2014, Pratyush Anand wrote:
> +static int spear1310_pcie_miphy_exit(struct st_miphy40lp_priv *phypriv)
> +{
> + u32 mask;
> +
> + switch (phypriv->id) {
> + case 0:
> + mask = SPEAR1310_PCIE_CFG_MASK(0);
> + break;
> + case 1:
> + mask = SPEAR1310_PCIE_CFG_MASK(1);
> + break;
> + case 2:
> + mask = SPEAR1310_PCIE_CFG_MASK(2);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + regmap_update_bits(phypriv->misc, SPEAR1310_PCIE_SATA_CFG,
> + SPEAR1310_PCIE_CFG_MASK(phypriv->id), 0);
> +
> + regmap_update_bits(phypriv->misc, SPEAR1310_PCIE_MIPHY_CFG_1,
> + SPEAR1310_PCIE_SATA_MIPHY_CFG_PCIE_MASK, 0);
> +
> + return 0;
> +}
hmm, you set the mask based on the id, but then use the macro below
and ignore the mask?
> +
> +static int pcie_miphy_init(struct st_miphy40lp_priv *phypriv)
> +{
> + if (of_device_is_compatible(phypriv->np, "st,spear1340-miphy"))
> + return spear1340_pcie_miphy_init(phypriv);
> + else if (of_device_is_compatible(phypriv->np, "st,spear1310-miphy"))
> + return spear1310_pcie_miphy_init(phypriv);
> + else
> + return -EINVAL;
> +}
> +
> +static int pcie_miphy_exit(struct st_miphy40lp_priv *phypriv)
> +{
> + if (of_device_is_compatible(phypriv->np, "st,spear1340-miphy"))
> + return spear1340_pcie_miphy_exit(phypriv);
> + else if (of_device_is_compatible(phypriv->np, "st,spear1310-miphy"))
> + return spear1310_pcie_miphy_exit(phypriv);
> + else
> + return -EINVAL;
> +}
I think it's better to make this code table-driven. Rather than checking
'of_device_is_compatible()', it's much easier to add a .data field to
the of_device_id array that describes the PHY. You can use .data to
point to a structure containing per-device function pointers or
(better) values and offsets to be used.
Arnd
^ 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