* [PATCH 1/4] arm64: topology: Implement basic CPU topology support
From: Catalin Marinas @ 2014-02-12 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtATfnjP7R4ABSu_GDEYkVe3W6N2HU-ZkrQmT=nF31U4GA@mail.gmail.com>
On Wed, Feb 12, 2014 at 08:04:54AM +0000, Vincent Guittot wrote:
> On 11 February 2014 15:07, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Feb 11, 2014 at 01:18:56PM +0000, Vincent Guittot wrote:
> >> On 11 February 2014 11:34, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Tue, Feb 11, 2014 at 08:15:19AM +0000, Vincent Guittot wrote:
> >> >> On 10 February 2014 17:46, Mark Brown <broonie@kernel.org> wrote:
> >> >> > On Mon, Feb 10, 2014 at 04:22:31PM +0000, Catalin Marinas wrote:
> >> >> >> On Mon, Feb 10, 2014 at 01:02:01PM +0000, Mark Brown wrote:
> >> >> >
> >> >> >> > + if (cpu != cpuid)
> >> >> >> > + cpumask_set_cpu(cpu, &cpuid_topo->thread_sibling);
> >> >> >> > + }
> >> >> >> > + smp_wmb();
> >> >> >
> >> >> >> I now noticed there are a couple of smp_wmb() calls in this patch. What
> >> >> >> are they for?
> >> >> >
> >> >> > To be honest I mostly cargo culted them from the ARM implementation; I
> >> >> > did look a bit but didn't fully dig into it - it seemed they were
> >> >> > required to ensure that the updates for the new CPU are visible over all
> >> >> > CPUs. Vincent?
> >> >>
> >> >> Yes that's it. we must ensure that updates are made visible to other CPUs
> >> >
> >> > In relation to what? The smp_* barriers ensure ordering of observability
> >> > between a number of independent accesses, so you must be ensuring
> >> > ordering against something else. Also, you need to guarantee ordering on the
> >> > read-side too -- how is this achieved? I can't see any smp_rmb calls from a
> >> > quick grep, so I assume you're making use of address dependencies?
> >>
> >> The boot sequence ensures the rmb
> >
> > As Will said, smp_*mb() do not ensure absolute visibility, only relative
> > to subsequent memory accesses on the same processor. So just placing a
>
> It's my time to be a bit confused, if smp_*mb() do not ensure absolute
> visibility on other CPUs, how can we ensure that ?
smb_wmb()/smb_rmb() do not provide any waiting, they are not
synchronisation primitives. You have to use spinlocks or some other
polling (and of course, barriers for relative ordering of memory
reads/writes).
> > barrier at the end of a function does not mean much, it only shows half
> > of the problem it is trying to solve.
> >
> > How are the secondary CPUs using this information? AFAICT, secondaries
> > call smp_store_cpu_info() which also go through each CPU in
> > update_siblings_mask(). Is there any race here that smp_wmb() is trying
> > to solve?
>
> The fields will be used to construct topology so we must ensure their
> visibility
I wonder whether you need spinlocks around the topology updating code.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: vdso: clean up vdso_pagelist initialization
From: Will Deacon @ 2014-02-12 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392157722-6372-1-git-send-email-nathan_lynch@mentor.com>
On Tue, Feb 11, 2014 at 10:28:42PM +0000, Nathan Lynch wrote:
> Remove some unnecessary bits that were apparently carried over from
> another architecture's implementation:
>
> - No need to get_page() the vdso text/data - these are part of the
> kernel image.
> - No need for ClearPageReserved on the vdso text.
> - No need to vmap the first text page to check the ELF header - this
> can be done through &vdso_start.
>
> Also some minor cleanup:
> - Use kcalloc for vdso_pagelist array allocation.
> - Don't print on allocation failure, slab/slub will do that for us.
>
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Thanks Nathan, this cleans things up a bit.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 2/3] arm64: mm: Route pmd thp functions through pte equivalents
From: Steve Capper @ 2014-02-12 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212101423.GC29702@arm.com>
On Wed, Feb 12, 2014 at 10:14:23AM +0000, Catalin Marinas wrote:
> On Thu, Feb 06, 2014 at 02:16:10PM +0000, Steve Capper wrote:
> > Rather than have separate hugetlb and transparent huge page pmd
> > manipulation functions, re-wire our thp functions to simply call the
> > pte equivalents.
>
> That's one thing I don't like about hugetlb, casting pmds to ptes. Do we
> actually save much in terms of code clean-up by doing this?
Hi Catalin,
At the moment we have ptes and hugetlb ptes behaving in the same way so
they both make use of PTE_WRITE. I thought it would be more logical to
tie the THP code to the pte manipulation functions too rather than
duplicate the PTE_WRITE logic in a separate PMD_WRITE. This makes
future pte changes apply to THP too automatically (along with hugetlb).
Cheers,
--
Steve
^ permalink raw reply
* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Rutland @ 2014-02-12 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402111508.06267.arnd@arndb.de>
On Tue, Feb 11, 2014 at 02:08:06PM +0000, Arnd Bergmann wrote:
> On Tuesday 11 February 2014, Mark Brown wrote:
> > On Tue, Feb 11, 2014 at 11:37:09AM +0000, Mark Rutland wrote:
> >
> > > - pl022->clk = devm_clk_get(&adev->dev, NULL);
> > > + /*
> > > + * For compatibility with old DTBs and platform data, fall back to the
> > > + * first clock if there's not an explicitly named "sspclk" entry.
> > > + */
> > > + pl022->clk = devm_clk_get(&adev->dev, "sspclk");
> > > + if (IS_ERR(pl022->clk))
> > > + pl022->clk = devm_clk_get(&adev->dev, NULL);
> > > +
> >
> > I'll just have a bit of a grumble here and point out that this sort of
> > stuff always worries me with the convention of using nameless clocks -
> > it causes hassle adding further clocks.
>
> I think the best solution for this is to continue with anonymous clocks
> rather than adding names after the fact. This could be done (for DT-only
> drivers) using the of_clk_get() interface that takes an index, or
> we could add a generic dev_clk_get_index() or similar interface that
> has the same behavior but also works for clkdev.
That works, and if taken alone patch 7 would codify that existing
behaviour as the standard.
To me it feels odd to require the last clock in the list (apb_pclk) to
be named, and the rest to be in a particular order. For the dt case it
seems saner to add new clocks with names as it allows arbitrary subsets
of clocks to be wired up and described (though obviously in this case a
missing sspclk would be problematic).
For new bindings I'd really like to push people to always use named
clocks as it makes things far more flexible, but I appreciate that here
there are issues associated with modifying an existing binding.
Mark, do you have specific issues that named clocks cause that I could
look into?
Cheers,
Mark.
^ permalink raw reply
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
From: Catalin Marinas @ 2014-02-12 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiWsWXkQkb-_VZGco0gKNZPsHf3ubR88y4Pt4-umk5_Ww@mail.gmail.com>
On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote:
> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> > This patch adds support for Samsung GH7 SoC in arm64/Kconfig.
> >
> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
>
> The overhead of building one more device tree isn't very large, and I
> don't see any other need to have a Kconfig entry per SoC at this time.
> It's of course up to Catalin, but you might just want to always
> compile all dts files instead.
For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely,
only that I haven't heard any strong opinion either way (in which case
I'll do it, with a risk of single Image getting bigger and bigger and
people needing smaller Image can trim their .config).
--
Catalin
^ permalink raw reply
* [PATCH] arm64: fix psci power state pack
From: Prashant Gaikwad @ 2014-02-12 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212101946.GD13441@mudshark.cambridge.arm.com>
On Wed, 2014-02-12 at 15:49 +0530, Will Deacon wrote:
> On Wed, Feb 12, 2014 at 09:22:38AM +0000, Prashant Gaikwad wrote:
> > Values has to be shifted right to create pack.
>
> NAK. This doesn't make any sense to me.
>
> > Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
> > ---
> > arch/arm64/kernel/psci.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> > index 4f97db3..6e8f1df 100644
> > --- a/arch/arm64/kernel/psci.c
> > +++ b/arch/arm64/kernel/psci.c
> > @@ -87,11 +87,11 @@ static int psci_to_linux_errno(int errno)
> > static u32 psci_power_state_pack(struct psci_power_state state)
> > {
> > return ((state.id & PSCI_POWER_STATE_ID_MASK)
> > - << PSCI_POWER_STATE_ID_SHIFT) |
> > + >> PSCI_POWER_STATE_ID_SHIFT) |
> > ((state.type & PSCI_POWER_STATE_TYPE_MASK)
> > - << PSCI_POWER_STATE_TYPE_SHIFT) |
> > + >> PSCI_POWER_STATE_TYPE_SHIFT) |
>
> So for the type field, this becomes:
>
> (state.type & 0x1) >> 16
Ahhh, my bad. I got my mistake.
Thanks for the review Will!!
>
> Are you sure?
>
> Will
^ permalink raw reply
* [PATCH v4 1/8] at91: dt: Adds support for the bus matrix declaration in the DT
From: Gregory CLEMENT @ 2014-02-12 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392199607-27452-2-git-send-email-jjhiblot@traphandler.com>
Hi Jean-Jacques,
Thanks for this new series, I have one little comment:
On 12/02/2014 11:06, Jean-Jacques Hiblot wrote:
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/mach-at91/setup.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> index f7ca97b..b8d0b66 100644
> --- a/arch/arm/mach-at91/setup.c
> +++ b/arch/arm/mach-at91/setup.c
> @@ -487,6 +487,28 @@ end:
> of_node_put(np);
> }
>
> +static struct of_device_id matrix_ids[] = {
> + { .compatible = "atmel,at91sam9261-bus-matrix", },
> + { /*sentinel*/ }
> +};
> +
> +static void at91_dt_matrix(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_matching_node(NULL, matrix_ids);
> + if (!np) {
> + pr_debug("AT91: unable to find compatible bus matrix controller node in dtb\n");
I think that a panic here should be more consistent with the next check.
Indeed if it fails here then at91_matrix_base will be uninitialized too,
and it will make the kernel crash when at91_matrix_base will be accessed.
Thanks,
Gregory
> + return;
> + }
> +
> + at91_matrix_base = of_iomap(np, 0);
> + if (!at91_matrix_base)
> + panic("Impossible to ioremap at91_matrix_base\n");
> +
> + of_node_put(np);
> +}
> +
> void __init at91rm9200_dt_initialize(void)
> {
> at91_dt_ramc();
> @@ -506,6 +528,7 @@ void __init at91_dt_initialize(void)
> at91_dt_rstc();
> at91_dt_ramc();
> at91_dt_shdwc();
> + at91_dt_matrix();
>
> /* Init clock subsystem */
> at91_dt_clock_init();
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: imx6: fix !CONFIG_PM and !CONFIG_CPU_IDLE build
From: Lucas Stach @ 2014-02-12 10:45 UTC (permalink / raw)
To: linux-arm-kernel
When building a kernel with only CONFIG_CPU_IDLE, but no
CONFIG_PM we still need the functions to set the lpm mode
and chicken bits.
Also if both options are unset, we have to stub out the
set_lpm function, as this one is called from the clk
driver directly.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
This fix depends on an earlier one by Philipp:
"ARM: imx6: Initialize low-power mode early again"
Both should go to stable after a sensible sinking time.
---
arch/arm/mach-imx/Makefile | 9 +++-
arch/arm/mach-imx/common.h | 11 +++--
arch/arm/mach-imx/pm-imx6q.c | 112 ++++++++++++++++++++++---------------------
3 files changed, 72 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index befcaf5d0574..a8f2a1a1cbfc 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -102,9 +102,14 @@ obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o mach-imx6sl.o
ifeq ($(CONFIG_PM),y)
-obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
+obj-$(CONFIG_SOC_IMX6Q) += headsmp.o
# i.MX6SL reuses i.MX6Q code
-obj-$(CONFIG_SOC_IMX6SL) += pm-imx6q.o headsmp.o
+obj-$(CONFIG_SOC_IMX6SL) += headsmp.o
+endif
+
+ifeq ($(findstring y,$(CONFIG_CPU_IDLE) $(CONFIG_PM)),y)
+obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o
+obj-$(CONFIG_SOC_IMX6SL) += pm-imx6q.o
endif
# i.MX5 based machines
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 59c3b9b26bb4..9141277e143f 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -138,7 +138,6 @@ void imx_gpc_irq_unmask(struct irq_data *d);
void imx_anatop_init(void);
void imx_anatop_pre_suspend(void);
void imx_anatop_post_resume(void);
-int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode);
void imx6q_set_chicken_bit(void);
void imx_cpu_die(unsigned int cpu);
@@ -146,14 +145,20 @@ int imx_cpu_kill(unsigned int cpu);
#ifdef CONFIG_PM
void imx6q_pm_init(void);
-void imx6q_pm_set_ccm_base(void __iomem *base);
void imx5_pm_init(void);
#else
static inline void imx6q_pm_init(void) {}
-static inline void imx6q_pm_set_ccm_base(void __iomem *base) {}
static inline void imx5_pm_init(void) {}
#endif
+#if defined(CONFIG_PM) || defined(CONFIG_CPU_IDLE)
+void imx6q_pm_set_ccm_base(void __iomem *base);
+int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode);
+#else
+static inline void imx6q_pm_set_ccm_base(void __iomem *base) {}
+static inline int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode) { return 0; }
+#endif
+
#ifdef CONFIG_NEON
int mx51_neon_fixup(void);
#else
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index 7a9b98589db7..038091050e61 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -68,56 +68,6 @@ void imx6q_set_chicken_bit(void)
writel_relaxed(val, ccm_base + CGPR);
}
-static void imx6q_enable_rbc(bool enable)
-{
- u32 val;
-
- /*
- * need to mask all interrupts in GPC before
- * operating RBC configurations
- */
- imx_gpc_mask_all();
-
- /* configure RBC enable bit */
- val = readl_relaxed(ccm_base + CCR);
- val &= ~BM_CCR_RBC_EN;
- val |= enable ? BM_CCR_RBC_EN : 0;
- writel_relaxed(val, ccm_base + CCR);
-
- /* configure RBC count */
- val = readl_relaxed(ccm_base + CCR);
- val &= ~BM_CCR_RBC_BYPASS_COUNT;
- val |= enable ? BM_CCR_RBC_BYPASS_COUNT : 0;
- writel(val, ccm_base + CCR);
-
- /*
- * need to delay at least 2 cycles of CKIL(32K)
- * due to hardware design requirement, which is
- * ~61us, here we use 65us for safe
- */
- udelay(65);
-
- /* restore GPC interrupt mask settings */
- imx_gpc_restore_all();
-}
-
-static void imx6q_enable_wb(bool enable)
-{
- u32 val;
-
- /* configure well bias enable bit */
- val = readl_relaxed(ccm_base + CLPCR);
- val &= ~BM_CLPCR_WB_PER_AT_LPM;
- val |= enable ? BM_CLPCR_WB_PER_AT_LPM : 0;
- writel_relaxed(val, ccm_base + CLPCR);
-
- /* configure well bias count */
- val = readl_relaxed(ccm_base + CCR);
- val &= ~BM_CCR_WB_COUNT;
- val |= enable ? BM_CCR_WB_COUNT : 0;
- writel_relaxed(val, ccm_base + CCR);
-}
-
int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
{
struct irq_desc *iomuxc_irq_desc;
@@ -175,6 +125,62 @@ int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
return 0;
}
+void __init imx6q_pm_set_ccm_base(void __iomem *base)
+{
+ ccm_base = base;
+}
+
+#ifdef CONFIG_PM
+static void imx6q_enable_rbc(bool enable)
+{
+ u32 val;
+
+ /*
+ * need to mask all interrupts in GPC before
+ * operating RBC configurations
+ */
+ imx_gpc_mask_all();
+
+ /* configure RBC enable bit */
+ val = readl_relaxed(ccm_base + CCR);
+ val &= ~BM_CCR_RBC_EN;
+ val |= enable ? BM_CCR_RBC_EN : 0;
+ writel_relaxed(val, ccm_base + CCR);
+
+ /* configure RBC count */
+ val = readl_relaxed(ccm_base + CCR);
+ val &= ~BM_CCR_RBC_BYPASS_COUNT;
+ val |= enable ? BM_CCR_RBC_BYPASS_COUNT : 0;
+ writel(val, ccm_base + CCR);
+
+ /*
+ * need to delay at least 2 cycles of CKIL(32K)
+ * due to hardware design requirement, which is
+ * ~61us, here we use 65us for safe
+ */
+ udelay(65);
+
+ /* restore GPC interrupt mask settings */
+ imx_gpc_restore_all();
+}
+
+static void imx6q_enable_wb(bool enable)
+{
+ u32 val;
+
+ /* configure well bias enable bit */
+ val = readl_relaxed(ccm_base + CLPCR);
+ val &= ~BM_CLPCR_WB_PER_AT_LPM;
+ val |= enable ? BM_CLPCR_WB_PER_AT_LPM : 0;
+ writel_relaxed(val, ccm_base + CLPCR);
+
+ /* configure well bias count */
+ val = readl_relaxed(ccm_base + CCR);
+ val &= ~BM_CCR_WB_COUNT;
+ val |= enable ? BM_CCR_WB_COUNT : 0;
+ writel_relaxed(val, ccm_base + CCR);
+}
+
static int imx6q_suspend_finish(unsigned long val)
{
cpu_do_idle();
@@ -213,11 +219,6 @@ static const struct platform_suspend_ops imx6q_pm_ops = {
.valid = suspend_valid_only_mem,
};
-void __init imx6q_pm_set_ccm_base(void __iomem *base)
-{
- ccm_base = base;
-}
-
void __init imx6q_pm_init(void)
{
struct regmap *gpr;
@@ -239,3 +240,4 @@ void __init imx6q_pm_init(void)
suspend_set_ops(&imx6q_pm_ops);
}
+#endif
--
1.8.5.3
^ permalink raw reply related
* [RFC PATCH 2/3] mfd: syscon: Support early initialization
From: Michal Simek @ 2014-02-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212095424.GV15081@lee--X1>
On 02/12/2014 10:54 AM, Lee Jones wrote:
> On Mon, 10 Feb 2014, Michal Simek wrote:
>
>> Some platforms need to get system controller
>> ready as soon as possible.
>> The patch provides early_syscon_initialization
>> which create early mapping for all syscon compatible
>> devices in early_syscon_probe.
>> Regmap is get via syscon_early_regmap_lookup_by_phandle()
>>
>> Regular device probes attach device to regmap
>> via regmap_attach_dev().
>>
>> For early syscon initialization is necessary to extend
>> struct syscon and provide remove function
>> which unmap all early init structures.
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>> drivers/mfd/syscon.c | 126 +++++++++++++++++++++++++++++++++++++++------
>> include/linux/mfd/syscon.h | 11 ++++
>> 2 files changed, 120 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
>
> <snip>
>
>> struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
>> const char *property)
>> {
>> @@ -128,40 +149,110 @@ static int syscon_probe(struct platform_device *pdev)
>> struct device *dev = &pdev->dev;
>> struct syscon *syscon;
>> struct resource *res;
>> - void __iomem *base;
>>
>> - syscon = devm_kzalloc(dev, sizeof(*syscon), GFP_KERNEL);
>> + /* Early syscon init */
>> + if (pdev->dev.of_node && pdev->dev.of_node->data) {
>> + syscon = pdev->dev.of_node->data;
>> + res = &syscon->res;
>> + regmap_attach_dev(dev, syscon->regmap, &syscon_regmap_config);
>
> Instead of duplicating all of the init code with early and late
> versions of each, is there any reason why we can't always do the early
> stuff early and then connect it to the dev infrastructure when it
> becomes available?
I am waiting for Arnd and Mark opinions regarding this.
That's why it was just RFC.
There the next question is if this should still stay
in mfd or moved to base.
I wanted to keep this to be driver compatible
that's why I have done it in this way.
We will see.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/3f71a6b5/attachment.sig>
^ permalink raw reply
* [PATCH v4 1/8] at91: dt: Adds support for the bus matrix declaration in the DT
From: Nicolas Ferre @ 2014-02-12 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB50BB.5070603@free-electrons.com>
On 12/02/2014 11:45, Gregory CLEMENT :
> Hi Jean-Jacques,
>
> Thanks for this new series, I have one little comment:
>
> On 12/02/2014 11:06, Jean-Jacques Hiblot wrote:
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>> ---
>> arch/arm/mach-at91/setup.c | 23 +++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
>> index f7ca97b..b8d0b66 100644
>> --- a/arch/arm/mach-at91/setup.c
>> +++ b/arch/arm/mach-at91/setup.c
>> @@ -487,6 +487,28 @@ end:
>> of_node_put(np);
>> }
>>
>> +static struct of_device_id matrix_ids[] = {
>> + { .compatible = "atmel,at91sam9261-bus-matrix", },
>> + { /*sentinel*/ }
I think that we can introduce this compatible string with sam9260
product: "atmel,at91sam9260-bus-matrix".
In addition, can you add this new binding in the documentation file:
Documentation/devicetree/bindings/arm/atmel-at91.txt
(in another patch with the "dt: bindings: " subject prefix + add the DT
mailing-list: devicetree at vger.kernel.org).
>> +};
>> +
>> +static void at91_dt_matrix(void)
>> +{
>> + struct device_node *np;
>> +
>> + np = of_find_matching_node(NULL, matrix_ids);
>> + if (!np) {
>> + pr_debug("AT91: unable to find compatible bus matrix controller node in dtb\n");
>
> I think that a panic here should be more consistent with the next check.
> Indeed if it fails here then at91_matrix_base will be uninitialized too,
> and it will make the kernel crash when at91_matrix_base will be accessed.
Yes.
> Thanks,
>
> Gregory
>
>
>> + return;
>> + }
>> +
>> + at91_matrix_base = of_iomap(np, 0);
>> + if (!at91_matrix_base)
>> + panic("Impossible to ioremap at91_matrix_base\n");
>> +
>> + of_node_put(np);
>> +}
>> +
>> void __init at91rm9200_dt_initialize(void)
>> {
>> at91_dt_ramc();
>> @@ -506,6 +528,7 @@ void __init at91_dt_initialize(void)
>> at91_dt_rstc();
>> at91_dt_ramc();
>> at91_dt_shdwc();
>> + at91_dt_matrix();
>>
>> /* Init clock subsystem */
>> at91_dt_clock_init();
>>
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Brown @ 2014-02-12 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212103329.GC21992@e106331-lin.cambridge.arm.com>
On Wed, Feb 12, 2014 at 10:33:29AM +0000, Mark Rutland wrote:
> For new bindings I'd really like to push people to always use named
> clocks as it makes things far more flexible, but I appreciate that here
> there are issues associated with modifying an existing binding.
> Mark, do you have specific issues that named clocks cause that I could
> look into?
None, I actively prefer naming them (though Russell's point about people
picking names poorly pre-DT does make it clear why it makes sense that
we weren't doing that). I was just grumbling about the fact that
transitioning from unnamed to named is a bit ugly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140212/fc22f8a3/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/6] arm64: Add ftrace support
From: Arnd Bergmann @ 2014-02-12 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB5YjtCr2KL_q1FF8kO_VKe+feg7f9qFRKtwf3xj2h0ENwuB5g@mail.gmail.com>
On Wednesday 12 February 2014, Takahiro Akashi wrote:
> > If I build a large "randconfig" kernel or "allyesconfig", the kernel image
> > size exceeds 32MB, which means I can no longer link callers with a 26
> > bit signed immediate argument like the "bl _mcount" here. For any other
> > function calls, "gcc -mlong-calls" can be used to work around this, but
> > this particular instance is created by inserting assembly statements
> > into the output without considering the long-call options. Is there
> > a way to get the kernel to link anyway?
>
> I hope that this won't happen on arm64 because a branch offset range is
> +/- 128MB.
Yes, we should be safe for the next decade on arm64. My question was really
about arm32 here, hoping someone has an idea.
> > > +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> >
> > Here, again, you an remove the #ifdef by making the entire file built
> > only for CONFIG_FUNCTION_GRAPH_TRACER.
>
> You're right as far as patch [1/6] is concerned, but once patch [2/6] is
> applied,
> this file (ftrace.c) may be compiled even if CONFIG_FUNCTION_GRAPH_TRACER
> is not enabled. (That is CONFIG_DYNAMIC_FTRACE.)
> Sorry for any confusion by poorly-divided patchset.
No, that was my fault. I saw it later after I had already sent out the
message.
Arnd
^ permalink raw reply
* [PATCH 1/2] arm64: Add seccomp support
From: Arnd Bergmann @ 2014-02-12 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB5YjtB6XnXRd90AUw=rJCOBKyfcngTQd3Kxft33XLCK+K=Vuw@mail.gmail.com>
On Wednesday 12 February 2014, Takahiro Akashi wrote:
> Thank you for your comment.
> I'm afraid that I can't do so because how compat syscall numbers
> are named varies from arch to arch. __NR_compat_read is used
> only on arm64, while __NR_ia32_read on x86. On other archs,
> __NR_read is common to 32-bit and 64-bit tasks.
It's fine, I'm the maintainer for asm-generic ;-)
All future architectures are required to do it the same way as
arm64 and use the generic syscall ABI. It just means we won't be
able to share this header with x86 or other architectures that
use a nonstandard string. We should have it in the generic place
even if arm64 is the only user for now.
Arnd
^ permalink raw reply
* [PATCH] ARM: at91/DT: add NAND + DMA property
From: Nicolas Ferre @ 2014-02-12 11:06 UTC (permalink / raw)
To: linux-arm-kernel
Add the "atmel,nand-has-dma" property to NAND node for SoC that
can use the DMA to perform NAND accesses.
Use of this property was added in 1b7192658a08f70df0f290634fd7cd2ecb629fc9
(mtd: atmel_nand: add a new dt binding item for nand dma support).
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91sam9g45.dtsi | 1 +
arch/arm/boot/dts/at91sam9n12.dtsi | 1 +
arch/arm/boot/dts/at91sam9x5.dtsi | 1 +
arch/arm/boot/dts/sama5d3.dtsi | 1 +
4 files changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index cbcc058b26b4..9b6683f252cf 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -817,6 +817,7 @@
>;
atmel,nand-addr-offset = <21>;
atmel,nand-cmd-offset = <22>;
+ atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nand>;
gpios = <&pioC 8 GPIO_ACTIVE_HIGH
diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
index 394e6ce2afb7..9f04808fc697 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -570,6 +570,7 @@
atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
atmel,nand-addr-offset = <21>;
atmel,nand-cmd-offset = <22>;
+ atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nand>;
gpios = <&pioD 5 GPIO_ACTIVE_HIGH
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 174219de92fa..67e32067eb25 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -790,6 +790,7 @@
atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
atmel,nand-addr-offset = <21>;
atmel,nand-cmd-offset = <22>;
+ atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nand>;
gpios = <&pioD 5 GPIO_ACTIVE_HIGH
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index 3d5faf85f51b..d075c5326ce7 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1256,6 +1256,7 @@
interrupts = <5 IRQ_TYPE_LEVEL_HIGH 6>;
atmel,nand-addr-offset = <21>;
atmel,nand-cmd-offset = <22>;
+ atmel,nand-has-dma;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nand0_ale_cle>;
atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
--
1.8.2.2
^ permalink raw reply related
* [PATCH 07/12] mfd: syscon: Consider platform data a regmap config name
From: Pawel Moll @ 2014-02-12 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212082657.GK15081@lee--X1>
On Wed, 2014-02-12 at 08:26 +0000, Lee Jones wrote:
> > > Use the device platform data as a regmap config
> > > name. This is particularly useful in the regmap
> > > debugfs when there is more than one syscon device
> > > registered, to distinguish the register blocks.
> > >
> > > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > Cc: Lee Jones <lee.jones@linaro.org>
> > > Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> > > ---
> > ...
> > > syscon_regmap_config.max_register = res->end - res->start - 3;
> > > + syscon_regmap_config.name = dev_get_platdata(&pdev->dev);
> >
> > Is dev_name(&pdev->dev) can be used for such purpose?
>
> Yes of course.
>
> Either use the automatically generated name or over-ride with
> dev->init_name prior to registration or call dev_set_name()
> manually. Then retrieve with Alexander's suggestion.
>
> Is there any technical reason why this is not possible with your
> implementation?
Hold on, guys. Let me just point out that we're talking "non-DT"
platform devices here (either statically defined struct
platform_device-s or - my case - the MFD cells).
In this case device/driver matching relies completely on device name.
Either the pdev->name must be identical (strcmp) to pdrv->name, or the
pdev->name must be identical (strcmp again) to one of the pdev->id_table
entries. See platform_match() in driver/base/platform.c for more
details.
Therefore the dev_name(&pdev->dev) on a non-DT-originating sysconf
devince will always return "sysconf.*", unless you're ready to maintain
a growing syscon_ids[] list. If so, I will have to add three entries
there ("sys_id", "sys_misc" and "sys_procid"). I hope you are not
seriously considering this idea :-) After all that's what the
platform_data was invented for.
Pawel
^ permalink raw reply
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
From: Marc Zyngier @ 2014-02-12 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjE=zOStKoZQhYLhYtL_aWD73DcF4w6STboZPMfHkLtxA@mail.gmail.com>
On 11/02/14 23:36, Olof Johansson wrote:
> Hi,
>
> Besides what Mark Rutland already commented on:
>
> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> +/ {
>> + model = "SAMSUNG GH7";
>> + compatible = "samsung,gh7";
>
> Model and compatible in the dtsi should probably always be overridden
> by a dts that includes it, so there's little use in having it here.
>
>> + interrupt-parent = <&gic>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu at 000 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg = <0x0 0x000>;
>
> No need to zero-pad cpu numbers in unit address or reg.
>
>> + enable-method = "spin-table";
>> + cpu-release-addr = <0x0 0x8000fff8>;
>> + };
>> + cpu at 001 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg = <0x0 0x001>;
>> + enable-method = "spin-table";
>> + cpu-release-addr = <0x0 0x8000fff8>;
>> + };
>> + cpu at 002 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg = <0x0 0x002>;
>> + enable-method = "spin-table";
>> + cpu-release-addr = <0x0 0x8000fff8>;
>> + };
>> + cpu at 003 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg = <0x0 0x003>;
>> + enable-method = "spin-table";
>> + cpu-release-addr = <0x0 0x8000fff8>;
>> + };
>> + };
>> +
>> + gic: interrupt-controller at 1C000000 {
>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>
> This looks incorrect -- you should at the very least have a more
> specific one than a15-gic? Marc?
"arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the
virt extensions). This binding matches what the A15 GIC has, so
"arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2
driver has no compatible string for anything else.
Should we define something more generic (like "arm,gic-v2")? Or carry on
adding more compatible strings?
M.
>> + #interrupt-cells = <3>;
>> + #address-cells = <0>;
>> + interrupt-controller;
>> + reg = <0x0 0x1C001000 0 0x1000>, /* GIC Dist */
>> + <0x0 0x1C002000 0 0x1000>, /* GIC CPU */
>> + <0x0 0x1C004000 0 0x2000>, /* GIC VCPU Control */
>> + <0x0 0x1C006000 0 0x2000>; /* GIC VCPU */
>> + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */
>> + };
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm: vmlinux.lds.S: drop redundant .comment
From: Mark Rutland @ 2014-02-12 11:13 UTC (permalink / raw)
To: linux-arm-kernel
Commit 78d7530ac3 ("ARM: Clean up linker script using new linker script
macros.") modified the arm kernel linker script to use the STABS_DEBUG
macro, but left a .comment section definition. As STABS_DEBUG defines
the .comment section in an identical way, the second section definition
is redundant and can be removed.
This patch removes the redundant .comment section definition.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm/kernel/vmlinux.lds.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 7bcee5c..6f57cb9 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -318,7 +318,6 @@ SECTIONS
_end = .;
STABS_DEBUG
- .comment 0 : { *(.comment) }
}
/*
--
1.8.1.1
^ permalink raw reply related
* [PATCH v4 0/8] Device Tree support for the at91sam9261ek
From: Gregory CLEMENT @ 2014-02-12 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392199607-27452-1-git-send-email-jjhiblot@traphandler.com>
Hi Jean-Jacques,
On 12/02/2014 11:06, Jean-Jacques Hiblot wrote:
> This patch set aims at bringing a device tree support for the sam9261.
> It's mostly based on the sam9263 and sam9x5 stuff.
>
> Changes since V3:
> * Added support for the touchscreen
> * Added support for the spi dataflash
> * Activated the TCB by default
> * Reworked the patch organization to reduce the number of patchs
> * changed the default bootargs (no mem description, UBI on mtdpart 5)
> * Changed the xlate implementation of the at91 pinctrl driver to lock the GPIOs
> for IRQs instead of requesting them (needed for the touchscreen driver)
> * some stylistic changes
>
> Changes since V2:
> * removed the smc driver from the serie. It'll be posted in an independent
> serie later.
> * removed the DM9000 support (it'll come with the smc driver)
> * the sam9261 now supports the Common Clock Framework (CCF). Note: to enable
> the CCF you must remove from the kernel config the platforms that don't
> support it.
> * Added basic DT binding for the bus matrix
> * Added support for USB host
> * Added support for USB gadget
> * in dts(i), replaced interrupt-parent with interrupts-extended
> * changed the nand partition plan (same as for the sama5d3)
> * removed 'mem' parameter in command line
> * re-ordered dt-nodes in ascending address order.
> * split the lcd support patch in 2 parts (SOC and board)
>
>
> Change since V1:
> * changed the DT representation to use address translation and separate the
> timings' configuration from the device properties by adding a "simple-bus"
> inetrmediate node.
> * moved the smc driver from drivers/bus to drivers/memmory
> * smc driver now accepts timings in nanoseconds as well as raw register values
> * smc driver can clip the timings if they're out of bound and dump them to the
> console
> * DM9000 timings are now described in nanosecs (for the virtue of example)
>
> supported features are:
> * working with the Common Clock Framework and the old at91 clock implementation
> * dbgu
> * lcdc
> * usb host
> * usb gadget,
> * spi dataflash
> * nand flash
> * touchscreen
> * leds
> * user buttons
>
> In the TODO list:
> * dm9000 (ethernet)
> * audio
> * mmc
Besides the my comment on the 1st patch, all this series
seems pretty neat for me.
It's worth mentioning also that audio and mmc are in the
TODO list by lack of hardware to test it. So what I suggest
here is to send a follow-up patch set and to ask for a
Tested-By from people being able to test it.
For dm9000 the issue is (again) related to an ordering problem:
the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
the gpio driver initialization is called after the dm900 driver
initialization.
Thanks,
Gregory
>
> This serie relies on the following patchs:
> usb: at91-udc: fix irq and iomem resource retrieval
> ARM: at91: prepare sam9 dt boards transition to common
>
> Jean-Jacques
>
> Jean-Jacques Hiblot (8):
> at91: dt: Adds support for the bus matrix declaration in the DT
> at91: pinctrl: don't request GPIOs used for interrupts but lock them
> as IRQ
> at91: dt: Add at91sam9261 dt SoC support
> at91: dt: defconfig: Added the sam9261 to the list of DT-enabled SOCs
> at91: dt: sam9261: Device Tree support for the at91sam9261ek
> at91: updated the at91_dt_defconfig with support for the ADS7846
> ARM: at91: prepare common clk transition for sam9261 SoC
> ARM: at91: move sam9261 SoC to common clk
>
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/at91sam9261.dtsi | 740 ++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/at91sam9261ek.dts | 204 ++++++++++
> arch/arm/configs/at91_dt_defconfig | 2 +
> arch/arm/mach-at91/Kconfig | 1 -
> arch/arm/mach-at91/at91sam9261.c | 25 +-
> arch/arm/mach-at91/setup.c | 23 ++
> drivers/pinctrl/pinctrl-at91.c | 5 +-
> 8 files changed, 996 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
> create mode 100644 arch/arm/boot/dts/at91sam9261ek.dts
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 4/4] ARM: dts: imx6qdl: Add PU power-domain information to gpc node
From: Shawn Guo @ 2014-02-12 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392200455.5536.36.camel@pizza.hi.pengutronix.de>
On Wed, Feb 12, 2014 at 11:20:55AM +0100, Philipp Zabel wrote:
> > > @@ -598,9 +598,17 @@
> > > };
> > >
> > > gpc: gpc at 020dc000 {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > compatible = "fsl,imx6q-gpc";
> > > reg = <0x020dc000 0x4000>;
> > > interrupts = <0 89 0x04 0 90 0x04>;
> > > + pu-supply = <®_pu>;
> > > +
> > > + pd_pu: power-domain at 020dc260 {
> > > + compatible = "fsl,power-domain";
> > > + reg = <0x020dc260 0x10>;
> > > + };
> >
> > It's time to have a binding doc for gpc/pgc?
>
> Yes, I'll add one for the next version.
>
> > And I'm not sure
> > "fsl,power-domain" is a good compatible as it's so generic.
>
> fsl,imx6q-power-domain ?
It looks good to me.
Shawn
^ permalink raw reply
* [PATCH 1/2] arm64: Add seccomp support
From: Arnd Bergmann @ 2014-02-12 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402121205.10802.arnd@arndb.de>
On Wednesday 12 February 2014, Arnd Bergmann wrote:
>
> On Wednesday 12 February 2014, Takahiro Akashi wrote:
> > Thank you for your comment.
> > I'm afraid that I can't do so because how compat syscall numbers
> > are named varies from arch to arch. __NR_compat_read is used
> > only on arm64, while __NR_ia32_read on x86. On other archs,
> > __NR_read is common to 32-bit and 64-bit tasks.
>
> It's fine, I'm the maintainer for asm-generic ;-)
>
> All future architectures are required to do it the same way as
> arm64 and use the generic syscall ABI. It just means we won't be
> able to share this header with x86 or other architectures that
> use a nonstandard string. We should have it in the generic place
> even if arm64 is the only user for now.
>
Ok, I was wrong. The generic header file should only be used for
architectures on which both ABIs use the generic syscall numbers,
and arm64 obviously doesn't do that for arm32 compatibility.
The proper generic header file should contain
#if defined(CONFIG_COMPAT) && !defined(__NR_seccomp_read_32)
#define __NR_seccomp_read_32 __NR_read
#define __NR_seccomp_write_32 __NR_write
#define __NR_seccomp_exit_32 __NR_exit
#define __NR_seccomp_sigreturn_32 __NR_rt_sigreturn
#endif /* CONFIG_COMPAT && ! already defined */
#define __NR_seccomp_read __NR_read
#define __NR_seccomp_write __NR_write
#define __NR_seccomp_exit __NR_exit
#define __NR_seccomp_sigreturn __NR_rt_sigreturn
and then have arm64 override the first four by defining its
own. I would still prefer having it done this way, but it actually
doesn't gain us that much since this default wouldn't work on
any 64-bit architecture currently implementing seccomp. I'll leave
it up to you whether you want to do it or not.
Arnd
^ permalink raw reply
* [PATCH 07/12] mfd: syscon: Consider platform data a regmap config name
From: Lee Jones @ 2014-02-12 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392203209.3380.57.camel@hornet>
> > > > Use the device platform data as a regmap config
> > > > name. This is particularly useful in the regmap
> > > > debugfs when there is more than one syscon device
> > > > registered, to distinguish the register blocks.
> > > >
> > > > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > Cc: Lee Jones <lee.jones@linaro.org>
> > > > Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> > > > ---
> > > ...
> > > > syscon_regmap_config.max_register = res->end - res->start - 3;
> > > > + syscon_regmap_config.name = dev_get_platdata(&pdev->dev);
> > >
> > > Is dev_name(&pdev->dev) can be used for such purpose?
> >
> > Yes of course.
> >
> > Either use the automatically generated name or over-ride with
> > dev->init_name prior to registration or call dev_set_name()
> > manually. Then retrieve with Alexander's suggestion.
> >
> > Is there any technical reason why this is not possible with your
> > implementation?
>
> Hold on, guys. Let me just point out that we're talking "non-DT"
> platform devices here (either statically defined struct
> platform_device-s or - my case - the MFD cells).
>
> In this case device/driver matching relies completely on device name.
> Either the pdev->name must be identical (strcmp) to pdrv->name, or the
> pdev->name must be identical (strcmp again) to one of the pdev->id_table
> entries. See platform_match() in driver/base/platform.c for more
> details.
>
> Therefore the dev_name(&pdev->dev) on a non-DT-originating sysconf
> devince will always return "sysconf.*", unless you're ready to maintain
> a growing syscon_ids[] list. If so, I will have to add three entries
> there ("sys_id", "sys_misc" and "sys_procid"). I hope you are not
> seriously considering this idea :-) After all that's what the
> platform_data was invented for.
Ah, I see your predicament. I guess that is a limitation of the was
syscon works. Usually we'd use match tables to differentiate between
various supported devices, but I guess the 'supported devices' list
for syscon is pretty limitless. In which case I support your second
implementation (adding a platform_data container) for the use of
arbitrary/useful-common names.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 1/2] mfd: syscon: Add platform data with a regmap config name
From: Lee Jones @ 2014-02-12 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392141165-14338-1-git-send-email-pawel.moll@arm.com>
> Define syscon platform data structure that can be used
> to define a regmap config name. This is particularly useful
> in the regmap debugfs when there is more than one syscon
> device registered, to distinguish the register blocks.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> drivers/mfd/syscon.c | 4 ++++
> include/linux/platform_data/syscon.h | 8 ++++++++
> 2 files changed, 12 insertions(+)
> create mode 100644 include/linux/platform_data/syscon.h
<snip>
> +#ifndef PLATFORM_DATA_SYSCON_H
> +#define PLATFORM_DATA_SYSCON_H
> +
> +struct syscon_platform_data {
> + const char *label;
> +};
Provided you fix this up:
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 2/2] mfd: vexpress-sysreg: Add syscon labels as platform data
From: Lee Jones @ 2014-02-12 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392141165-14338-2-git-send-email-pawel.moll@arm.com>
> This patch adds platform data with label names for syscon
> registers in the relevant MFD cells.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> drivers/mfd/vexpress-sysreg.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Arnd Bergmann @ 2014-02-12 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212103329.GC21992@e106331-lin.cambridge.arm.com>
On Wednesday 12 February 2014, Mark Rutland wrote:
> To me it feels odd to require the last clock in the list (apb_pclk) to
> be named, and the rest to be in a particular order. For the dt case it
> seems saner to add new clocks with names as it allows arbitrary subsets
> of clocks to be wired up and described (though obviously in this case a
> missing sspclk would be problematic).
Yes, good point about the missing clocks, and I also agree mixing ordered
and named clocks in one device is rather odd and can lead to trouble.
I guess there isn't really a good way out here, and I certainly won't
ask for it to be done one way or the other if someone else has a
good argument which way it should be implemented.
Arnd
^ permalink raw reply
* [PATCH] MTD: atmel_nand: POI fall back is not an issue: change log level
From: Nicolas Ferre @ 2014-02-12 11:26 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/mtd/nand/atmel_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index c36e9b84487c..8d210f8a072d 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -430,7 +430,7 @@ err_dma:
dma_unmap_single(dma_dev->dev, phys_addr, len, dir);
err_buf:
if (err != 0)
- dev_warn(host->dev, "Fall back to CPU I/O\n");
+ dev_dbg(host->dev, "Fall back to CPU I/O\n");
return err;
}
--
1.8.2.2
^ permalink raw reply related
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