* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-14 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478584614-12054-2-git-send-email-peter.chen@nxp.com>
On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
> It is the 10th processor in the well-known imx6 series, and derived
> from imx6ul but cost optimized. The more information about imx6ull
> can be found at:
>
> http://www.nxp.com/products/microcontrollers-and-processors/
> arm-processors/i.mx-applications-processors/i.mx-6-processors
> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
> :i.MX6ULL
>
> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
> for board part (imx6ul/imx6ull 14x14 evk), it has a common board
> file imx6u-14x14-evk.dtsi, and this file is included by both
> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487 ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479 +------------------------------
What's the real change between imx6u-14x14-evk.dtsi and
imx6ul-14x14-evk.dts? Instead of renaming the file, I would like to
have imx6ull-14x14-evk.dts include imx6ul-14x14-evk.dts directly, if we
can work out the difference within imx6ull-14x14-evk.dts.
Shawn
> arch/arm/boot/dts/imx6ull-14x14-evk.dts | 55 ++++
> arch/arm/boot/dts/imx6ull-pinfunc.h | 56 ++++
> arch/arm/boot/dts/imx6ull.dtsi | 43 +++
> 6 files changed, 644 insertions(+), 479 deletions(-)
> create mode 100644 arch/arm/boot/dts/imx6u-14x14-evk.dtsi
> create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
> create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
> create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-14 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111031903.GB15997@arm.com>
On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote:
> On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote:
> > Will,
> > (+ Cc: Dennis)
> >
> > On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote:
> > > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote:
> > > > Add memblock_cap_memory_range() which will remove all the memblock regions
> > > > except the range specified in the arguments.
> > > >
> > > > This function, like memblock_mem_limit_remove_map(), will not remove
> > > > memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> > > > later as "device memory."
> > > > See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> > > > address the mem limit issue").
> > > >
> > > > This function is used, in a succeeding patch in the series of arm64 kdump
> > > > suuport, to limit the range of usable memory, System RAM, on crash dump
> > > > kernel.
> > > > (Please note that "mem=" parameter is of little use for this purpose.)
> > > >
> > > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > > Cc: linux-mm at kvack.org
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > > > include/linux/memblock.h | 1 +
> > > > mm/memblock.c | 28 ++++++++++++++++++++++++++++
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > > index 5b759c9..0e770af 100644
> > > > --- a/include/linux/memblock.h
> > > > +++ b/include/linux/memblock.h
> > > > @@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
> > > > phys_addr_t memblock_end_of_DRAM(void);
> > > > void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> > > > void memblock_mem_limit_remove_map(phys_addr_t limit);
> > > > +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> > > > bool memblock_is_memory(phys_addr_t addr);
> > > > int memblock_is_map_memory(phys_addr_t addr);
> > > > int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
> > > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > > index 7608bc3..eb53876 100644
> > > > --- a/mm/memblock.c
> > > > +++ b/mm/memblock.c
> > > > @@ -1544,6 +1544,34 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> > > > (phys_addr_t)ULLONG_MAX);
> > > > }
> > > >
> > > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> > > > +{
> > > > + int start_rgn, end_rgn;
> > > > + int i, ret;
> > > > +
> > > > + if (!size)
> > > > + return;
> > > > +
> > > > + ret = memblock_isolate_range(&memblock.memory, base, size,
> > > > + &start_rgn, &end_rgn);
> > > > + if (ret)
> > > > + return;
> > > > +
> > > > + /* remove all the MAP regions */
> > > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + for (i = start_rgn - 1; i >= 0; i--)
> > > > + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> > > > + memblock_remove_region(&memblock.memory, i);
> > > > +
> > > > + /* truncate the reserved regions */
> > > > + memblock_remove_range(&memblock.reserved, 0, base);
> > > > + memblock_remove_range(&memblock.reserved,
> > > > + base + size, (phys_addr_t)ULLONG_MAX);
> > > > +}
> > >
> > > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can
> > > you not implement that in terms of your new, more general, function? e.g.
> > > by passing base == 0, and size == limit?
> >
> > Obviously it's possible.
> > I actually talked to Dennis before about merging them,
> > but he was against my idea.
> >
> Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html
> So feel free to do that as Will'll do
OK, but I found that the two functions have a bit different semantics
in clipping memory range, in particular, when the range [base,base+size)
goes across several regions with a gap.
(This does not happen in my arm64 kdump, though.)
That is, 'limit' in memblock_mem_limit_remove_map() means total size of
available memory, while 'size' in memblock_cap_memory_range() indicates
the size of _continuous_ memory range.
So I added an extra argument, exact, to a common function to specify
distinct behaviors. Confusing? Please see the patch below.
If nobody objects to this merge, I will submit a whole patchset of kdump
again.
Thanks,
-Takahiro AKASHI
===8<===
include/linux/memblock.h | 1 +
mm/memblock.c | 91 +++++++++++++++++++++++++++++++++++-------------
2 files changed, 68 insertions(+), 24 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9..0e770af 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
phys_addr_t memblock_end_of_DRAM(void);
void memblock_enforce_memory_limit(phys_addr_t memory_limit);
void memblock_mem_limit_remove_map(phys_addr_t limit);
+void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
bool memblock_is_memory(phys_addr_t addr);
int memblock_is_map_memory(phys_addr_t addr);
int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..5f849a9 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1473,9 +1473,10 @@ phys_addr_t __init_memblock memblock_end_of_DRAM(void)
return (memblock.memory.regions[idx].base + memblock.memory.regions[idx].size);
}
-static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
+static phys_addr_t __init_memblock __find_max_addr(phys_addr_t min,
+ phys_addr_t limit)
{
- phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX;
+ phys_addr_t max_addr = (phys_addr_t)ULLONG_MAX, base, size;
struct memblock_region *r;
/*
@@ -1484,11 +1485,22 @@ static phys_addr_t __init_memblock __find_max_addr(phys_addr_t limit)
* of those regions, max_addr will keep original value ULLONG_MAX
*/
for_each_memblock(memory, r) {
- if (limit <= r->size) {
- max_addr = r->base + limit;
+ if (min >= r->base + r->size)
+ continue;
+
+ if (r->base <= min) {
+ base = min;
+ size = r->base + r->size - min;
+ } else {
+ base = r->base;
+ size = r->size;
+ }
+
+ if (limit <= size) {
+ max_addr = base + limit;
break;
}
- limit -= r->size;
+ limit -= size;
}
return max_addr;
@@ -1501,7 +1513,7 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
if (!limit)
return;
- max_addr = __find_max_addr(limit);
+ max_addr = __find_max_addr(0, limit);
/* @limit exceeds the total size of the memory, do nothing */
if (max_addr == (phys_addr_t)ULLONG_MAX)
@@ -1514,34 +1526,65 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
(phys_addr_t)ULLONG_MAX);
}
-void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+/*
+ * __memblock_cap_memory_range - cap memblock regions
+ * @base: lowest address to clip
+ * @size: size of memory range
+ * @exact: true or false
+ *
+ * If @exact is true, the exact range [@base, @base+ at size) of memory with
+ * kernel direct mapping is clipped from memblock.memory. Otherwise, total
+ * of @size of memory is clipped starting from @base.
+ */
+static void __init __memblock_cap_memory_range(phys_addr_t base,
+ phys_addr_t size, bool exact)
{
- struct memblock_type *type = &memblock.memory;
- phys_addr_t max_addr;
- int i, ret, start_rgn, end_rgn;
+ int start_rgn, end_rgn;
+ int i, ret;
- if (!limit)
+ if (!size)
return;
- max_addr = __find_max_addr(limit);
+ if (!exact) {
+ phys_addr_t max_addr;
- /* @limit exceeds the total size of the memory, do nothing */
- if (max_addr == (phys_addr_t)ULLONG_MAX)
- return;
+ max_addr = __find_max_addr(base, size);
+ /* @size exceeds the total size of the memory, do nothing */
+ if (max_addr == (phys_addr_t)ULLONG_MAX)
+ return;
+
+ /* recalc the size to clip the exact range [@base, max_addr) */
+ size = max_addr - base;
+ }
- ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
- &start_rgn, &end_rgn);
+ ret = memblock_isolate_range(&memblock.memory, base, size,
+ &start_rgn, &end_rgn);
if (ret)
return;
- /* remove all the MAP regions above the limit */
- for (i = end_rgn - 1; i >= start_rgn; i--) {
- if (!memblock_is_nomap(&type->regions[i]))
- memblock_remove_region(type, i);
- }
+ /* remove all the other MAP regions */
+ for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ for (i = start_rgn - 1; i >= 0; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
/* truncate the reserved regions */
- memblock_remove_range(&memblock.reserved, max_addr,
- (phys_addr_t)ULLONG_MAX);
+ memblock_remove_range(&memblock.reserved, 0, base);
+ memblock_remove_range(&memblock.reserved,
+ base + size, (phys_addr_t)ULLONG_MAX);
+}
+
+void __init memblock_mem_limit_remove_map(phys_addr_t limit)
+{
+ __memblock_cap_memory_range(0, limit, false);
+}
+
+void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
+{
+ __memblock_cap_memory_range(base, size, true);
}
static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
--
2.10.0
===>8===
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > > Will
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: Add level for cpu dt node for exynos7
From: Alim Akhtar @ 2016-11-14 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc5aJi9nVv4rd3pB_dkkoJWUjmkEyXF2Kxtp+6Y7VZdWg@mail.gmail.com>
Hi Krzysztof,
On 11/13/2016 12:43 AM, Krzysztof Kozlowski wrote:
> On Sat, Nov 12, 2016 at 6:00 PM, Alim Akhtar <alim.akhtar@gmail.com> wrote:
>> Hi Javier,
>>
>> On Sat, Nov 12, 2016 at 7:54 PM, Javier Martinez Canillas
>> <javier@osg.samsung.com> wrote:
>>> Hello Alim,
>>>
>>> On 11/12/2016 07:17 AM, Alim Akhtar wrote:
>>>> This patch adds level for cpu dt node, so that these levels can be used
>>>
>>> Do you mean s/level/label here? I'm asking because you are using level
>>> consistently in the subject line and commit message but I'm not sure
>>> what it means in this context.
>>>
>>
>> Ah!! my bad. Its __label__. If required, will respin.
>> Thanks for review.
>
> I think there is no need of respin because this should be squashed
> with previous patch. This is quite small and there are no functional
> changes here (labels are transparent, except of course conflict
> cases). Without the 2/2, this patch does not have much sense yet.
>
The reason why I kept the _label_ changes are separate patch is to keep
git bisect happy. If you think there won't be a case for that, then lets
merge the two in single patch.
Let me know if you want me to respin or you will take care.
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 5:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114054833.GG3310@dragon>
Best regards,
Peter Chen
>-----Original Message-----
>From: Shawn Guo [mailto:shawnguo at kernel.org]
>Sent: Monday, November 14, 2016 1:49 PM
>To: Peter Chen <peter.chen@nxp.com>
>Cc: sboyd at codeaurora.org; mturquette at baylibre.com; linux-arm-
>kernel at lists.infradead.org; kernel at pengutronix.de; devicetree at vger.kernel.org;
>robh+dt at kernel.org; Fabio Estevam <fabio.estevam@nxp.com>;
>mark.rutland at arm.com; linux-clk at vger.kernel.org
>Subject: Re: [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
>
>On Tue, Nov 08, 2016 at 01:56:52PM +0800, Peter Chen wrote:
>> It is the 10th processor in the well-known imx6 series, and derived
>> from imx6ul but cost optimized. The more information about imx6ull can
>> be found at:
>>
>> http://www.nxp.com/products/microcontrollers-and-processors/
>> arm-processors/i.mx-applications-processors/i.mx-6-processors
>> /i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
>> :i.MX6ULL
>>
>> In this patch, for SoC part, the imx6ull.dtsi includes imx6ul.dtsi;
>> for board part (imx6ul/imx6ull 14x14 evk), it has a common board file
>> imx6u-14x14-evk.dtsi, and this file is included by both
>> imx6ul-14x14-evk.dts and imx6ull-14x14-evk.dts.
>>
>> Signed-off-by: Peter Chen <peter.chen@nxp.com>
>> ---
>> arch/arm/boot/dts/Makefile | 3 +-
>> arch/arm/boot/dts/imx6u-14x14-evk.dtsi | 487
>> ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/imx6ul-14x14-evk.dts | 479
>> +------------------------------
>
>What's the real change between imx6u-14x14-evk.dtsi and imx6ul-14x14-evk.dts?
>Instead of renaming the file, I would like to have imx6ull-14x14-evk.dts include
>imx6ul-14x14-evk.dts directly, if we can work out the difference within imx6ull-
>14x14-evk.dts.
>
The main difference is compatible string, I can't include two compatible strings in one dts file,
the dts build will fail for that.
imx6ull-14x14-evk.dts
/ {
model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
};
imx6ul-14x14-evk.dts
/ {
model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
};
Peter
^ permalink raw reply
* [PATCH 09/16] ARM: BCM: use generic API for enabling SCU
From: Florian Fainelli @ 2016-11-14 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-10-git-send-email-pankaj.dubey@samsung.com>
Le 13/11/2016 ? 21:02, Pankaj Dubey a ?crit :
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
>
> CC: Florian Fainelli <f.fainelli@gmail.com>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Scott Branden <sbranden@broadcom.com>
> CC: bcm-kernel-feedback-list at broadcom.com
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Let me know if I need to pick this and submit via ARM SoC pull requests,
thanks!
--
Florian
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Jisheng Zhang @ 2016-11-14 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-2-git-send-email-pankaj.dubey@samsung.com>
Hi Pankaj,
On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
> Many platforms are duplicating code for enabling SCU, lets add
> common code to enable SCU by parsing SCU device node so the duplication
> in each platform can be avoided.
>
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> CC: Jisheng Zhang <jszhang@marvell.com>
> CC: Russell King <linux@armlinux.org.uk>
> CC: Dinh Nguyen <dinguyen@opensource.altera.com>
> CC: Patrice Chotard <patrice.chotard@st.com>
> CC: Linus Walleij <linus.walleij@linaro.org>
> CC: Liviu Dudau <liviu.dudau@arm.com>
> CC: Ray Jui <rjui@broadcom.com>
> CC: Stephen Warren <swarren@wwwdotorg.org>
> CC: Heiko Stuebner <heiko@sntech.de>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Michal Simek <michal.simek@xilinx.com>
> CC: Wei Xu <xuwei5@hisilicon.com>
> CC: Andrew Lunn <andrew@lunn.ch>
> CC: Jun Nie <jun.nie@linaro.org>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/include/asm/smp_scu.h | 4 +++
> arch/arm/kernel/smp_scu.c | 56 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> index bfe163c..fdeec07 100644
> --- a/arch/arm/include/asm/smp_scu.h
> +++ b/arch/arm/include/asm/smp_scu.h
> @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, unsigned int mode)
>
> #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> void scu_enable(void __iomem *scu_base);
> +void __iomem *of_scu_get_base(void);
> +int of_scu_enable(void);
> #else
> static inline void scu_enable(void __iomem *scu_base) {}
> +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> +static inline int of_scu_enable(void) {return 0; }
> #endif
>
> #endif
> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> index 72f9241..d0ac3ed 100644
> --- a/arch/arm/kernel/smp_scu.c
> +++ b/arch/arm/kernel/smp_scu.c
> @@ -10,6 +10,7 @@
> */
> #include <linux/init.h>
> #include <linux/io.h>
> +#include <linux/of_address.h>
>
> #include <asm/smp_plat.h>
> #include <asm/smp_scu.h>
> @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> */
> flush_cache_all();
> }
> +
> +static const struct of_device_id scu_match[] = {
> + { .compatible = "arm,cortex-a9-scu", },
> + { .compatible = "arm,cortex-a5-scu", },
> + { }
> +};
> +
> +/*
> + * Helper API to get SCU base address
> + * In case platform DT do not have SCU node, or iomap fails
> + * this call will fallback and will try to map via call to
> + * scu_a9_get_base.
> + * This will return ownership of scu_base to the caller
> + */
> +void __iomem *of_scu_get_base(void)
> +{
> + unsigned long base = 0;
> + struct device_node *np;
> + void __iomem *scu_base;
> +
> + np = of_find_matching_node(NULL, scu_match);
could we check np before calling of_iomap()?
> + scu_base = of_iomap(np, 0);
> + of_node_put(np);
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base via DT\n", __func__);
For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
what does it mean, but it may confuse normal users. In current version,
berlin doesn't complain like this for non-ca9 SoCs
> + if (scu_a9_has_base()) {
> + base = scu_a9_get_base();
> + scu_base = ioremap(base, SZ_4K);
> + }
> + if (!scu_base) {
> + pr_err("%s failed to map scu_base\n", __func__);
ditto
> + return IOMEM_ERR_PTR(-ENOMEM);
> + }
> + }
> + return scu_base;
> +}
> +
> +/*
> + * Enable SCU via mapping scu_base DT
> + * If scu_base mapped successfully scu will be enabled and in case of
> + * failure if will return non-zero error code
> + */
> +int of_scu_enable(void)
> +{
> + void __iomem *scu_base;
> +
> + scu_base = of_scu_get_base();
> + if (!IS_ERR(scu_base)) {
> + scu_enable(scu_base);
> + iounmap(scu_base);
> + return 0;
> + }
> + return PTR_ERR(scu_base);
> +}
> +
> #endif
>
> /*
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Shawn Guo @ 2016-11-14 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR04MB14509BFD0CBA838BC1EA7D598BBC0@HE1PR04MB1450.eurprd04.prod.outlook.com>
On Mon, Nov 14, 2016 at 05:59:01AM +0000, Peter Chen wrote:
> The main difference is compatible string, I can't include two compatible strings in one dts file,
> the dts build will fail for that.
>
> imx6ull-14x14-evk.dts
> / {
> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
> };
>
> imx6ul-14x14-evk.dts
> / {
> model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
> };
I created imx6ull-14x14-evk.dts like below, and DTC seems happy with it.
#include "imx6ul-14x14-evk.dts"
/ {
model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
};
Shawn
^ permalink raw reply
* [RESEND][PATCH 6/6] arm64: Add DTS support for FSL's LS2088A SoC
From: Shawn Guo @ 2016-11-14 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478597664-14799-7-git-send-email-abhimanyu.saini@nxp.com>
On Tue, Nov 08, 2016 at 03:04:24PM +0530, Abhimanyu Saini wrote:
> This patch adds the device tree support for FSL LS2088A SoC based on
> ARMv8 architecture.
>
> Following levels of DTSI/DTS files have been created for the LS2088A
> SoC family:
>
> - fsl-ls2088a.dtsi:
> DTS-Include file for FSL LS2088A SoC.
>
> - fsl-ls2088a-qds.dts:
> DTS file for FSL LS2088A QDS board.
>
> - fsl-ls2088a-rdb.dts:
> DTS file for FSL LS2088A RDB board.
I compared the following files.
fsl-ls2088a.dtsi vs. fsl-ls2080a.dtsi
fsl-ls2088a-qds.dtsi vs. fsl-ls2080a-qds.dtsi
fsl-ls2088a-rdb.dtsi vs. fsl-ls2080a-rdb.dtsi
They are basically identical except a couple of small changes. Can we
do something to have these SoCs share the dts files at some level to
avoid maintaining duplicated files?
Shawn
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts | 211 +++++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts | 166 +++++
> arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi | 703 ++++++++++++++++++++++
> 4 files changed, 1082 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2088a.dtsi
^ permalink raw reply
* [PATCH v2 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114061311.GA14956@dragon>
>On Mon, Nov 14, 2016 at 05:59:01AM +0000, Peter Chen wrote:
>> The main difference is compatible string, I can't include two
>> compatible strings in one dts file, the dts build will fail for that.
>>
>> imx6ull-14x14-evk.dts
>> / {
>> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
>> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull"; };
>>
>> imx6ul-14x14-evk.dts
>> / {
>> model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
>> compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul"; };
>
>I created imx6ull-14x14-evk.dts like below, and DTC seems happy with it.
>
>#include "imx6ul-14x14-evk.dts"
>
>/ {
> model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
> compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull"; };
>
Thanks for trying it, the problem why my dtc building fail is I have two
" /dts-v1/;" at dts file (one is from imx6ul-14x14-evk.dts) . I will follow your suggestion.
Peter
^ permalink raw reply
* [PATCH] arm: imx6qp: correct LDB clock inputs
From: Shawn Guo @ 2016-11-14 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108165536.19656-1-l.stach@pengutronix.de>
On Tue, Nov 08, 2016 at 05:55:36PM +0100, Lucas Stach wrote:
> On i.MX6QP the LDB clock tree has changed to move the clk gate
> before the divider, to prevent clock glitches propagating downstream.
>
> A consequence of this change is that the clk divider is now the
> parent of the LDB inputs. Reflect this change in the devicetree
> to allow the LDB driver to properly configure the display clocks.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-pinfunc: fix UART pinmux defines
From: Shawn Guo @ 2016-11-14 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109024456.1832-1-stefan@agner.ch>
On Tue, Nov 08, 2016 at 06:44:56PM -0800, Stefan Agner wrote:
> The UART pinmux defines for the pins which are part of the LPSR
> pinmux controller are wrong: Output signals configure the input
> sel value and the pinmux defines allow not to distinguish between
> DCE/DTE mode. Follow the usual pattern using DTE/DCE as part of
> the define to denote the two UART configuration options.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied, thanks.
^ permalink raw reply
* [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid
From: Shawn Guo @ 2016-11-14 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478709850-9361-1-git-send-email-andrew.smirnov@gmail.com>
On Wed, Nov 09, 2016 at 08:44:10AM -0800, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
I updated subject prefix a bit and applied the patch.
Shawn
^ permalink raw reply
* [PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid
From: Stefan Agner @ 2016-11-14 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478709850-9361-1-git-send-email-andrew.smirnov@gmail.com>
On 2016-11-09 17:44, Andrey Smirnov wrote:
> According to the datasheet, VF610 uses revision r3p2 of the L2C-310
> block, same as i.MX6Q+, which does not require a software workaround for
> ARM errata 769419.
FWIW, r3p2 is also the revision according to the cache registers...
Acked-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> arch/arm/mach-imx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 9155b63..936c59d 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -557,7 +557,6 @@ config SOC_VF610
> bool "Vybrid Family VF610 support"
> select ARM_GIC if ARCH_MULTI_V7
> select PINCTRL_VF610
> - select PL310_ERRATA_769419 if CACHE_L2X0
>
> help
> This enables support for Freescale Vybrid VF610 processor.
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Jisheng Zhang @ 2016-11-14 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114141251.7ea86e7a@xhacker>
On Mon, 14 Nov 2016 14:12:51 +0800 Jisheng Zhang wrote:
> Hi Pankaj,
>
> On Mon, 14 Nov 2016 10:31:56 +0530 Pankaj Dubey wrote:
>
> > Many platforms are duplicating code for enabling SCU, lets add
> > common code to enable SCU by parsing SCU device node so the duplication
> > in each platform can be avoided.
> >
> > CC: Krzysztof Kozlowski <krzk@kernel.org>
> > CC: Jisheng Zhang <jszhang@marvell.com>
> > CC: Russell King <linux@armlinux.org.uk>
> > CC: Dinh Nguyen <dinguyen@opensource.altera.com>
> > CC: Patrice Chotard <patrice.chotard@st.com>
> > CC: Linus Walleij <linus.walleij@linaro.org>
> > CC: Liviu Dudau <liviu.dudau@arm.com>
> > CC: Ray Jui <rjui@broadcom.com>
> > CC: Stephen Warren <swarren@wwwdotorg.org>
> > CC: Heiko Stuebner <heiko@sntech.de>
> > CC: Shawn Guo <shawnguo@kernel.org>
> > CC: Michal Simek <michal.simek@xilinx.com>
> > CC: Wei Xu <xuwei5@hisilicon.com>
> > CC: Andrew Lunn <andrew@lunn.ch>
> > CC: Jun Nie <jun.nie@linaro.org>
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> > ---
> > arch/arm/include/asm/smp_scu.h | 4 +++
> > arch/arm/kernel/smp_scu.c | 56 ++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 60 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
> > index bfe163c..fdeec07 100644
> > --- a/arch/arm/include/asm/smp_scu.h
> > +++ b/arch/arm/include/asm/smp_scu.h
> > @@ -39,8 +39,12 @@ static inline int scu_power_mode(void __iomem *scu_base, unsigned int mode)
> >
> > #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> > void scu_enable(void __iomem *scu_base);
> > +void __iomem *of_scu_get_base(void);
> > +int of_scu_enable(void);
> > #else
> > static inline void scu_enable(void __iomem *scu_base) {}
> > +static inline void __iomem *of_scu_get_base(void) {return NULL; }
> > +static inline int of_scu_enable(void) {return 0; }
> > #endif
> >
> > #endif
> > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > index 72f9241..d0ac3ed 100644
> > --- a/arch/arm/kernel/smp_scu.c
> > +++ b/arch/arm/kernel/smp_scu.c
> > @@ -10,6 +10,7 @@
> > */
> > #include <linux/init.h>
> > #include <linux/io.h>
> > +#include <linux/of_address.h>
> >
> > #include <asm/smp_plat.h>
> > #include <asm/smp_scu.h>
> > @@ -70,6 +71,61 @@ void scu_enable(void __iomem *scu_base)
> > */
> > flush_cache_all();
> > }
> > +
> > +static const struct of_device_id scu_match[] = {
> > + { .compatible = "arm,cortex-a9-scu", },
> > + { .compatible = "arm,cortex-a5-scu", },
> > + { }
> > +};
> > +
> > +/*
> > + * Helper API to get SCU base address
> > + * In case platform DT do not have SCU node, or iomap fails
> > + * this call will fallback and will try to map via call to
> > + * scu_a9_get_base.
> > + * This will return ownership of scu_base to the caller
> > + */
> > +void __iomem *of_scu_get_base(void)
> > +{
> > + unsigned long base = 0;
> > + struct device_node *np;
> > + void __iomem *scu_base;
> > +
> > + np = of_find_matching_node(NULL, scu_match);
>
> could we check np before calling of_iomap()?
>
> > + scu_base = of_iomap(np, 0);
> > + of_node_put(np);
> > + if (!scu_base) {
> > + pr_err("%s failed to map scu_base via DT\n", __func__);
>
> For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> what does it mean, but it may confuse normal users. In current version,
> berlin doesn't complain like this for non-ca9 SoCs
oops, I just realized that the non-ca9 berlin arm SoC version isn't upstreamed.
Below is the draft version I planed. Basically speaking, the code tries to
find "arm,cortex-a9-scu" node from DT, if can't, we think we don't need to
worry about SCU. Is there any elegant solution for my situation?
Thanks,
Jisheng
------------8<-------------------
--- a/arch/arm/mach-berlin/platsmp.c
+++ b/arch/arm/mach-berlin/platsmp.c
@@ -56,22 +56,25 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
void __iomem *vectors_base;
np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
- scu_base = of_iomap(np, 0);
- of_node_put(np);
- if (!scu_base)
- return;
+ if (np) {
+ scu_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!scu_base)
+ return;
+ scu_enable(scu_base);
+ iounmap(scu_base);
+ }
np = of_find_compatible_node(NULL, NULL, "marvell,berlin-cpu-ctrl");
cpu_ctrl = of_iomap(np, 0);
of_node_put(np);
if (!cpu_ctrl)
- goto unmap_scu;
+ return;
vectors_base = ioremap(CONFIG_VECTORS_BASE, SZ_32K);
if (!vectors_base)
- goto unmap_scu;
+ return;
- scu_enable(scu_base);
flush_cache_all();
/*
@@ -87,8 +90,6 @@ static void __init berlin_smp_prepare_cpus(unsigned int max_cpus)
writel(virt_to_phys(secondary_startup), vectors_base + SW_RESET_ADDR);
iounmap(vectors_base);
-unmap_scu:
- iounmap(scu_base);
}
static struct smp_operations berlin_smp_ops __initdata = {
>
> > + if (scu_a9_has_base()) {
> > + base = scu_a9_get_base();
> > + scu_base = ioremap(base, SZ_4K);
> > + }
> > + if (!scu_base) {
> > + pr_err("%s failed to map scu_base\n", __func__);
>
> ditto
>
> > + return IOMEM_ERR_PTR(-ENOMEM);
> > + }
> > + }
> > + return scu_base;
> > +}
> > +
> > +/*
> > + * Enable SCU via mapping scu_base DT
> > + * If scu_base mapped successfully scu will be enabled and in case of
> > + * failure if will return non-zero error code
> > + */
> > +int of_scu_enable(void)
> > +{
> > + void __iomem *scu_base;
> > +
> > + scu_base = of_scu_get_base();
> > + if (!IS_ERR(scu_base)) {
> > + scu_enable(scu_base);
> > + iounmap(scu_base);
> > + return 0;
> > + }
> > + return PTR_ERR(scu_base);
> > +}
> > +
> > #endif
> >
> > /*
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/2] phy: rockchip-inno-usb2: correct 480MHz clk_ops callbacks and stable time
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
This series try to correct the 480MHz output clock of USB2 PHY
clk_ops callback and fix the delay time. It aims to make the
480MHz clock more sensible and stable.
Tested on rk3366/rk3399 EVB board.
William Wu (2):
phy: rockchip-inno-usb2: correct clk_ops callback
phy: rockchip-inno-usb2: correct 480MHz output clock stable time
drivers/phy/phy-rockchip-inno-usb2.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--
2.0.0
^ permalink raw reply
* [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-1-git-send-email-wulf@rock-chips.com>
Since we needs to delay ~1ms to wait for 480MHz output clock
of USB2 PHY to become stable after turn on it, the delay time
is pretty long for something that's supposed to be "atomic"
like a clk_enable(). Consider that clk_enable() will disable
interrupt and that a 1ms interrupt latency is not sensible.
The 480MHz output clock should be handled in prepare callbacks
which support gate a clk if the operation may sleep.
Signed-off-by: William Wu <wulf@rock-chips.com>
---
drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..365e077 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -153,7 +153,7 @@ static inline bool property_enabled(struct rockchip_usb2phy *rphy,
return tmp == reg->enable;
}
-static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -172,7 +172,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
return 0;
}
-static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
+static void rockchip_usb2phy_clk480m_unprepare(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -181,7 +181,7 @@ static void rockchip_usb2phy_clk480m_disable(struct clk_hw *hw)
property_enable(rphy, &rphy->phy_cfg->clkout_ctl, false);
}
-static int rockchip_usb2phy_clk480m_enabled(struct clk_hw *hw)
+static int rockchip_usb2phy_clk480m_prepared(struct clk_hw *hw)
{
struct rockchip_usb2phy *rphy =
container_of(hw, struct rockchip_usb2phy, clk480m_hw);
@@ -197,9 +197,9 @@ rockchip_usb2phy_clk480m_recalc_rate(struct clk_hw *hw,
}
static const struct clk_ops rockchip_usb2phy_clkout_ops = {
- .enable = rockchip_usb2phy_clk480m_enable,
- .disable = rockchip_usb2phy_clk480m_disable,
- .is_enabled = rockchip_usb2phy_clk480m_enabled,
+ .prepare = rockchip_usb2phy_clk480m_prepare,
+ .unprepare = rockchip_usb2phy_clk480m_unprepare,
+ .is_prepared = rockchip_usb2phy_clk480m_prepared,
.recalc_rate = rockchip_usb2phy_clk480m_recalc_rate,
};
--
2.0.0
^ permalink raw reply related
* [PATCH v2 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: William Wu @ 2016-11-14 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-1-git-send-email-wulf@rock-chips.com>
We found that the system crashed due to 480MHz output clock of
USB2 PHY was unstable after clock had been enabled by gpu module.
Theoretically, 1 millisecond is a critical value for 480MHz
output clock stable time, so we try to change the delay time
to 1.2 millisecond to avoid this issue.
And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
clk_ops callback") used prepare callbacks instead of enable
callbacks to support gate a clk if the operation may sleep. So
we can switch from delay to sleep functions.
Signed-off-by: William Wu <wulf@rock-chips.com>
---
Changes in v2:
- use usleep_range() function instead of mdelay()
drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index 365e077..578290b 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
return ret;
/* waitting for the clk become stable */
- mdelay(1);
+ usleep_range(1200);
}
return 0;
--
2.0.0
^ permalink raw reply related
* [PATCH v3 0/3] imx: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shawn,
In this series, it adds support for imx6ull SoC which is a derived SoC
from imx6ul, and imx6ull is pin-to-pin compatible with imx6ul, the
basic functions are tested at imx6ull 14x14 evk, and imx6ul 14x14 evk
is tested too to avoid regression.
Changes for v3:
- Keep imx6ul-14x14-evk.dts unchanging, and let imx6ull-14x14-evk.dts
include it. [Patch 1/3]
Changes for v2:
- Keep imx6ul.dtsi unchanging, and using GPL/X11 dual license
for new dts file. [Patch 1/3]
- Using IMX6ULL prefix for both imx6ull dedicated pin and clock name.
[Patch 1/3, 3/3]
- Delete useless changes for patch 2/3.
- Delete blank line for patch 3/3.
- Using assigned-clocks for imx6ull 14x14 evk. [Patch 1/3, 3/3]
Bai Ping (1):
clk: imx: clk-imx6ul: add clk support for imx6ull
Peter Chen (2):
ARM: imx6ull: add imx6ull support
ARM: imx: mach-imx6ul: add imx6ull support
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/imx6ull-14x14-evk.dts | 52 +++++++++++++++++++++++
arch/arm/boot/dts/imx6ull-pinfunc.h | 56 +++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull.dtsi | 43 +++++++++++++++++++
arch/arm/mach-imx/mach-imx6ul.c | 1 +
drivers/clk/imx/clk-imx6ul.c | 72 +++++++++++++++++++++++++++-----
include/dt-bindings/clock/imx6ul-clock.h | 15 ++++++-
7 files changed, 229 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107062-15365-1-git-send-email-peter.chen@nxp.com>
It is the 10th processor in the well-known imx6 series, and derived
from imx6ul but cost optimized. The more information about imx6ull
can be found at:
http://www.nxp.com/products/microcontrollers-and-processors/
arm-processors/i.mx-applications-processors/i.mx-6-processors
/i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
:i.MX6ULL
imx6ul.dtsi is the SoC common stuff for both imx6ul and imx6ull;
imx6ul-14x14-evk.dts is the board common stuff for both imx6ul
and imx6ull 14x14 evk. In this patch, for SoC part, the
imx6ull.dtsi includes imx6ul.dtsi; for board part, imx6ull-14x14-evk.dts
includes imx6ul-14x14-evk.dts.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/imx6ull-14x14-evk.dts | 52 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull-pinfunc.h | 56 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull.dtsi | 43 +++++++++++++++++++++++++
4 files changed, 153 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..3d6e199 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -423,7 +423,8 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
- imx6ul-tx6ul-mainboard.dtb
+ imx6ul-tx6ul-mainboard.dtb \
+ imx6ull-14x14-evk.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-cl-som-imx7.dtb \
imx7d-colibri-eval-v3.dtb \
diff --git a/arch/arm/boot/dts/imx6ull-14x14-evk.dts b/arch/arm/boot/dts/imx6ull-14x14-evk.dts
new file mode 100644
index 0000000..db5bc07
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-14x14-evk.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul-14x14-evk.dts"
+
+/ {
+ model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
+ compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6UL_CLK_PLL3_PFD2>;
+ assigned-clock-rates = <320000000>;
+};
diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h
new file mode 100644
index 0000000..580b5c3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#ifndef __DTS_IMX6ULL_PINFUNC_H
+#define __DTS_IMX6ULL_PINFUNC_H
+
+#include "imx6ul-pinfunc.h"
+/*
+ * The pin function ID is a tuple of
+ * <mux_reg conf_reg input_reg mux_mode input_val>
+ */
+#define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO08 0x00E4 0x0370 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO09 0x00E8 0x0374 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC 0x0378 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_DATA0__EPDC_SDDO11 0x00F0 0x037C 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_DATA1__EPDC_SDDO12 0x00F4 0x0380 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_EN__EPDC_SDDO13 0x00F8 0x0384 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_CLK__EPDC_SDDO14 0x00FC 0x0388 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_ER__EPDC_SDDO15 0x0100 0x038C 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_CLK__EPDC_SDCLK 0x0104 0x0390 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_ENABLE__EPDC_SDLE 0x0108 0x0394 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_HSYNC__EPDC_SDOE 0x010C 0x0398 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_VSYNC__EPDC_SDCE0 0x0110 0x039C 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_RESET__EPDC_GDOE 0x0114 0x03A0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA00__EPDC_SDDO00 0x0118 0x03A4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA01__EPDC_SDDO01 0x011C 0x03A8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA02__EPDC_SDDO02 0x0120 0x03AC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA03__EPDC_SDDO03 0x0124 0x03B0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA04__EPDC_SDDO04 0x0128 0x03B4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA05__EPDC_SDDO05 0x012C 0x03B8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA06__EPDC_SDDO06 0x0130 0x03BC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA07__EPDC_SDDO07 0x0134 0x03C0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA14__EPDC_SDSHR 0x0150 0x03DC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA15__EPDC_GDRL 0x0154 0x03E0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 0x03E4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C 0x03E8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C 0x03F8 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 0x0460 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 0x0464 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX1 0x01DC 0x0468 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_HSYNC__ESAI_TX1 0x01E0 0x046C 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA00__ESAI_TX_HF_CLK 0x01E4 0x0470 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA01__ESAI_RX_HF_CLK 0x01E8 0x0474 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA02__ESAI_RX_FS 0x01EC 0x0478 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA03__ESAI_RX_CLK 0x01F0 0x047C 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA04__ESAI_TX_FS 0x01F4 0x0480 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK 0x01F8 0x0484 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0 0x01FC 0x0488 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA07__ESAI_T0 0x0200 0x048C 0x0000 0x9 0x0
+
+#endif /* __DTS_IMX6ULL_PINFUNC_H */
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
new file mode 100644
index 0000000..dee8ab8
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul.dtsi"
+#include "imx6ull-pinfunc.h"
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] ARM: imx: mach-imx6ul: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107062-15365-1-git-send-email-peter.chen@nxp.com>
imx6ull is derived SoC from imx6ul.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
arch/arm/mach-imx/mach-imx6ul.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/mach-imx6ul.c b/arch/arm/mach-imx/mach-imx6ul.c
index 58a2b88..6cb8a22 100644
--- a/arch/arm/mach-imx/mach-imx6ul.c
+++ b/arch/arm/mach-imx/mach-imx6ul.c
@@ -89,6 +89,7 @@ static void __init imx6ul_init_late(void)
static const char * const imx6ul_dt_compat[] __initconst = {
"fsl,imx6ul",
+ "fsl,imx6ull",
NULL,
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107062-15365-1-git-send-email-peter.chen@nxp.com>
From: Bai Ping <ping.bai@nxp.com>
imx6ull is the derived SoC from imx6ul
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Bai Ping <ping.bai@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
drivers/clk/imx/clk-imx6ul.c | 72 +++++++++++++++++++++++++++-----
include/dt-bindings/clock/imx6ul-clock.h | 15 ++++++-
2 files changed, 75 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index d1d7787..75c35fb 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -64,6 +64,10 @@ static const char *perclk_sels[] = { "ipg", "osc", };
static const char *lcdif_sels[] = { "lcdif_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
static const char *csi_sels[] = { "osc", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
static const char *sim_sels[] = { "sim_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
+/* epdc_pre_sels, epdc_sels, esai_sels only exists on i.MX6ULL */
+static const char *epdc_pre_sels[] = { "pll2_bus", "pll3_usb_otg", "pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd2_508m", };
+static const char *esai_sels[] = { "pll4_audio_div", "pll3_pfd2_508m", "pll5_video_div", "pll3_usb_otg", };
+static const char *epdc_sels[] = { "epdc_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
static struct clk *clks[IMX6UL_CLK_END];
static struct clk_onecell_data clk_data;
@@ -102,6 +106,17 @@ static u32 share_count_audio;
static u32 share_count_sai1;
static u32 share_count_sai2;
static u32 share_count_sai3;
+static u32 share_count_esai;
+
+static inline int clk_on_imx6ul(void)
+{
+ return of_machine_is_compatible("fsl,imx6ul");
+}
+
+static inline int clk_on_imx6ull(void)
+{
+ return of_machine_is_compatible("fsl,imx6ull");
+}
static void __init imx6ul_clocks_init(struct device_node *ccm_node)
{
@@ -238,12 +253,19 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
clks[IMX6UL_CLK_QSPI1_SEL] = imx_clk_mux("qspi1_sel", base + 0x1c, 7, 3, qspi1_sels, ARRAY_SIZE(qspi1_sels));
clks[IMX6UL_CLK_PERCLK_SEL] = imx_clk_mux("perclk_sel", base + 0x1c, 6, 1, perclk_sels, ARRAY_SIZE(perclk_sels));
clks[IMX6UL_CLK_CAN_SEL] = imx_clk_mux("can_sel", base + 0x20, 8, 2, can_sels, ARRAY_SIZE(can_sels));
+ if (clk_on_imx6ull())
+ clks[IMX6ULL_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", base + 0x20, 19, 2, esai_sels, ARRAY_SIZE(esai_sels));
clks[IMX6UL_CLK_UART_SEL] = imx_clk_mux("uart_sel", base + 0x24, 6, 1, uart_sels, ARRAY_SIZE(uart_sels));
clks[IMX6UL_CLK_ENFC_SEL] = imx_clk_mux("enfc_sel", base + 0x2c, 15, 3, enfc_sels, ARRAY_SIZE(enfc_sels));
clks[IMX6UL_CLK_LDB_DI0_SEL] = imx_clk_mux("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di0_sels, ARRAY_SIZE(ldb_di0_sels));
clks[IMX6UL_CLK_SPDIF_SEL] = imx_clk_mux("spdif_sel", base + 0x30, 20, 2, spdif_sels, ARRAY_SIZE(spdif_sels));
- clks[IMX6UL_CLK_SIM_PRE_SEL] = imx_clk_mux("sim_pre_sel", base + 0x34, 15, 3, sim_pre_sels, ARRAY_SIZE(sim_pre_sels));
- clks[IMX6UL_CLK_SIM_SEL] = imx_clk_mux("sim_sel", base + 0x34, 9, 3, sim_sels, ARRAY_SIZE(sim_sels));
+ if (clk_on_imx6ul()) {
+ clks[IMX6UL_CLK_SIM_PRE_SEL] = imx_clk_mux("sim_pre_sel", base + 0x34, 15, 3, sim_pre_sels, ARRAY_SIZE(sim_pre_sels));
+ clks[IMX6UL_CLK_SIM_SEL] = imx_clk_mux("sim_sel", base + 0x34, 9, 3, sim_sels, ARRAY_SIZE(sim_sels));
+ } else if (clk_on_imx6ull()) {
+ clks[IMX6ULL_CLK_EPDC_PRE_SEL] = imx_clk_mux("epdc_pre_sel", base + 0x34, 15, 3, epdc_pre_sels, ARRAY_SIZE(epdc_pre_sels));
+ clks[IMX6ULL_CLK_EPDC_SEL] = imx_clk_mux("epdc_sel", base + 0x34, 9, 3, epdc_sels, ARRAY_SIZE(epdc_sels));
+ }
clks[IMX6UL_CLK_ECSPI_SEL] = imx_clk_mux("ecspi_sel", base + 0x38, 18, 1, ecspi_sels, ARRAY_SIZE(ecspi_sels));
clks[IMX6UL_CLK_LCDIF_PRE_SEL] = imx_clk_mux("lcdif_pre_sel", base + 0x38, 15, 3, lcdif_pre_sels, ARRAY_SIZE(lcdif_pre_sels));
clks[IMX6UL_CLK_LCDIF_SEL] = imx_clk_mux("lcdif_sel", base + 0x38, 9, 3, lcdif_sels, ARRAY_SIZE(lcdif_sels));
@@ -276,6 +298,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
clks[IMX6UL_CLK_SAI3_PODF] = imx_clk_divider("sai3_podf", "sai3_pred", base + 0x28, 16, 6);
clks[IMX6UL_CLK_SAI1_PRED] = imx_clk_divider("sai1_pred", "sai1_sel", base + 0x28, 6, 3);
clks[IMX6UL_CLK_SAI1_PODF] = imx_clk_divider("sai1_podf", "sai1_pred", base + 0x28, 0, 6);
+ if (clk_on_imx6ull()) {
+ clks[IMX6ULL_CLK_ESAI_PRED] = imx_clk_divider("esai_pred", "esai_sel", base + 0x28, 9, 3);
+ clks[IMX6ULL_CLK_ESAI_PODF] = imx_clk_divider("esai_podf", "esai_pred", base + 0x28, 25, 3);
+ }
clks[IMX6UL_CLK_ENFC_PRED] = imx_clk_divider("enfc_pred", "enfc_sel", base + 0x2c, 18, 3);
clks[IMX6UL_CLK_ENFC_PODF] = imx_clk_divider("enfc_podf", "enfc_pred", base + 0x2c, 21, 6);
clks[IMX6UL_CLK_SAI2_PRED] = imx_clk_divider("sai2_pred", "sai2_sel", base + 0x2c, 6, 3);
@@ -298,9 +324,15 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
clks[IMX6UL_CLK_APBHDMA] = imx_clk_gate2("apbh_dma", "bch_podf", base + 0x68, 4);
clks[IMX6UL_CLK_ASRC_IPG] = imx_clk_gate2_shared("asrc_ipg", "ahb", base + 0x68, 6, &share_count_asrc);
clks[IMX6UL_CLK_ASRC_MEM] = imx_clk_gate2_shared("asrc_mem", "ahb", base + 0x68, 6, &share_count_asrc);
- clks[IMX6UL_CLK_CAAM_MEM] = imx_clk_gate2("caam_mem", "ahb", base + 0x68, 8);
- clks[IMX6UL_CLK_CAAM_ACLK] = imx_clk_gate2("caam_aclk", "ahb", base + 0x68, 10);
- clks[IMX6UL_CLK_CAAM_IPG] = imx_clk_gate2("caam_ipg", "ipg", base + 0x68, 12);
+ if (clk_on_imx6ul()) {
+ clks[IMX6UL_CLK_CAAM_MEM] = imx_clk_gate2("caam_mem", "ahb", base + 0x68, 8);
+ clks[IMX6UL_CLK_CAAM_ACLK] = imx_clk_gate2("caam_aclk", "ahb", base + 0x68, 10);
+ clks[IMX6UL_CLK_CAAM_IPG] = imx_clk_gate2("caam_ipg", "ipg", base + 0x68, 12);
+ } else if (clk_on_imx6ull()) {
+ clks[IMX6ULL_CLK_DCP_CLK] = imx_clk_gate2("dcp", "ahb", base + 0x68, 10);
+ clks[IMX6UL_CLK_ENET] = imx_clk_gate2("enet", "ipg", base + 0x68, 12);
+ clks[IMX6UL_CLK_ENET_AHB] = imx_clk_gate2("enet_ahb", "ahb", base + 0x68, 12);
+ }
clks[IMX6UL_CLK_CAN1_IPG] = imx_clk_gate2("can1_ipg", "ipg", base + 0x68, 14);
clks[IMX6UL_CLK_CAN1_SERIAL] = imx_clk_gate2("can1_serial", "can_podf", base + 0x68, 16);
clks[IMX6UL_CLK_CAN2_IPG] = imx_clk_gate2("can2_ipg", "ipg", base + 0x68, 18);
@@ -309,7 +341,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
clks[IMX6UL_CLK_GPT2_SERIAL] = imx_clk_gate2("gpt2_serial", "perclk", base + 0x68, 26);
clks[IMX6UL_CLK_UART2_IPG] = imx_clk_gate2("uart2_ipg", "ipg", base + 0x68, 28);
clks[IMX6UL_CLK_UART2_SERIAL] = imx_clk_gate2("uart2_serial", "uart_podf", base + 0x68, 28);
- clks[IMX6UL_CLK_AIPSTZ3] = imx_clk_gate2("aips_tz3", "ahb", base + 0x68, 30);
+ if (clk_on_imx6ul())
+ clks[IMX6UL_CLK_AIPSTZ3] = imx_clk_gate2("aips_tz3", "ahb", base + 0x68, 30);
+ else if (clk_on_imx6ull())
+ clks[IMX6UL_CLK_AIPSTZ3] = imx_clk_gate2("aips_tz3", "ahb", base + 0x80, 18);
/* CCGR1 */
clks[IMX6UL_CLK_ECSPI1] = imx_clk_gate2("ecspi1", "ecspi_podf", base + 0x6c, 0);
@@ -328,6 +363,11 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
clks[IMX6UL_CLK_UART4_SERIAL] = imx_clk_gate2("uart4_serail", "uart_podf", base + 0x6c, 24);
/* CCGR2 */
+ if (clk_on_imx6ull()) {
+ clks[IMX6ULL_CLK_ESAI_EXTAL] = imx_clk_gate2_shared("esai_extal", "esai_podf", base + 0x70, 0, &share_count_esai);
+ clks[IMX6ULL_CLK_ESAI_IPG] = imx_clk_gate2_shared("esai_ipg", "ahb", base + 0x70, 0, &share_count_esai);
+ clks[IMX6ULL_CLK_ESAI_MEM] = imx_clk_gate2_shared("esai_mem", "ahb", base + 0x70, 0, &share_count_esai);
+ }
clks[IMX6UL_CLK_CSI] = imx_clk_gate2("csi", "csi_podf", base + 0x70, 2);
clks[IMX6UL_CLK_I2C1] = imx_clk_gate2("i2c1", "perclk", base + 0x70, 6);
clks[IMX6UL_CLK_I2C2] = imx_clk_gate2("i2c2", "perclk", base + 0x70, 8);
@@ -340,8 +380,13 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
/* CCGR3 */
clks[IMX6UL_CLK_UART5_IPG] = imx_clk_gate2("uart5_ipg", "ipg", base + 0x74, 2);
clks[IMX6UL_CLK_UART5_SERIAL] = imx_clk_gate2("uart5_serial", "uart_podf", base + 0x74, 2);
- clks[IMX6UL_CLK_ENET] = imx_clk_gate2("enet", "ipg", base + 0x74, 4);
- clks[IMX6UL_CLK_ENET_AHB] = imx_clk_gate2("enet_ahb", "ahb", base + 0x74, 4);
+ if (clk_on_imx6ul()) {
+ clks[IMX6UL_CLK_ENET] = imx_clk_gate2("enet", "ipg", base + 0x74, 4);
+ clks[IMX6UL_CLK_ENET_AHB] = imx_clk_gate2("enet_ahb", "ahb", base + 0x74, 4);
+ } else if (clk_on_imx6ull()) {
+ clks[IMX6ULL_CLK_EPDC_ACLK] = imx_clk_gate2("epdc_aclk", "axi", base + 0x74, 4);
+ clks[IMX6ULL_CLK_EPDC_PIX] = imx_clk_gate2("epdc_pix", "epdc_podf", base + 0x74, 4);
+ }
clks[IMX6UL_CLK_UART6_IPG] = imx_clk_gate2("uart6_ipg", "ipg", base + 0x74, 6);
clks[IMX6UL_CLK_UART6_SERIAL] = imx_clk_gate2("uart6_serial", "uart_podf", base + 0x74, 6);
clks[IMX6UL_CLK_LCDIF_PIX] = imx_clk_gate2("lcdif_pix", "lcdif_podf", base + 0x74, 10);
@@ -385,8 +430,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
clks[IMX6UL_CLK_USBOH3] = imx_clk_gate2("usboh3", "ipg", base + 0x80, 0);
clks[IMX6UL_CLK_USDHC1] = imx_clk_gate2("usdhc1", "usdhc1_podf", base + 0x80, 2);
clks[IMX6UL_CLK_USDHC2] = imx_clk_gate2("usdhc2", "usdhc2_podf", base + 0x80, 4);
- clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
- clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
+ if (clk_on_imx6ul()) {
+ clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
+ clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
+ }
clks[IMX6UL_CLK_EIM] = imx_clk_gate2("eim", "eim_slow_podf", base + 0x80, 10);
clks[IMX6UL_CLK_PWM8] = imx_clk_gate2("pwm8", "perclk", base + 0x80, 16);
clks[IMX6UL_CLK_UART8_IPG] = imx_clk_gate2("uart8_ipg", "ipg", base + 0x80, 14);
@@ -441,7 +488,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
}
clk_set_parent(clks[IMX6UL_CLK_CAN_SEL], clks[IMX6UL_CLK_PLL3_60M]);
- clk_set_parent(clks[IMX6UL_CLK_SIM_PRE_SEL], clks[IMX6UL_CLK_PLL3_USB_OTG]);
+ if (clk_on_imx6ul())
+ clk_set_parent(clks[IMX6UL_CLK_SIM_PRE_SEL], clks[IMX6UL_CLK_PLL3_USB_OTG]);
+ else if (clk_on_imx6ull())
+ clk_set_parent(clks[IMX6ULL_CLK_EPDC_PRE_SEL], clks[IMX6UL_CLK_PLL3_PFD2]);
clk_set_parent(clks[IMX6UL_CLK_ENFC_SEL], clks[IMX6UL_CLK_PLL2_PFD2]);
}
diff --git a/include/dt-bindings/clock/imx6ul-clock.h b/include/dt-bindings/clock/imx6ul-clock.h
index fd8aee8..ee9f1a5 100644
--- a/include/dt-bindings/clock/imx6ul-clock.h
+++ b/include/dt-bindings/clock/imx6ul-clock.h
@@ -236,6 +236,19 @@
#define IMX6UL_CLK_PLL3_120M 223
#define IMX6UL_CLK_KPP 224
-#define IMX6UL_CLK_END 225
+/* For i.MX6ULL */
+#define IMX6ULL_CLK_ESAI_PRED 225
+#define IMX6ULL_CLK_ESAI_PODF 226
+#define IMX6ULL_CLK_ESAI_EXTAL 227
+#define IMX6ULL_CLK_ESAI_MEM 228
+#define IMX6ULL_CLK_ESAI_IPG 229
+#define IMX6ULL_CLK_DCP_CLK 230
+#define IMX6ULL_CLK_EPDC_PRE_SEL 231
+#define IMX6ULL_CLK_EPDC_SEL 232
+#define IMX6ULL_CLK_EPDC_PODF 233
+#define IMX6ULL_CLK_EPDC_ACLK 234
+#define IMX6ULL_CLK_EPDC_PIX 235
+#define IMX6ULL_CLK_ESAI_SEL 236
+#define IMX6UL_CLK_END 237
#endif /* __DT_BINDINGS_CLOCK_IMX6UL_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs
From: Huang Shijie @ 2016-11-14 7:07 UTC (permalink / raw)
To: linux-arm-kernel
(1) Background
For the arm64, the hugetlb page size can be 32M (PMD + Contiguous bit).
In the 4K page environment, the max page order is 10 (max_order - 1),
so 32M page is the gigantic page.
The arm64 MMU supports a Contiguous bit which is a hint that the TTE
is one of a set of contiguous entries which can be cached in a single
TLB entry. Please refer to the arm64v8 mannul :
DDI0487A_f_armv8_arm.pdf (in page D4-1811)
(2) The bug
After I tested the libhugetlbfs, I found the test case "counter.sh"
will fail with the gigantic page (32M page in arm64 board).
This patch set adds support for gigantic surplus hugetlb pages,
allowing the counter.sh unit test to pass.
v1 -- > v2:
1.) fix the compiler error in X86.
2.) add new patches for NUMA.
The patch #2 ~ #5 are new patches.
Huang Shijie (6):
mm: hugetlb: rename some allocation functions
mm: hugetlb: add a new parameter for some functions
mm: hugetlb: change the return type for alloc_fresh_gigantic_page
mm: mempolicy: intruduce a helper huge_nodemask()
mm: hugetlb: add a new function to allocate a new gigantic page
mm: hugetlb: support gigantic surplus pages
include/linux/mempolicy.h | 8 +++
mm/hugetlb.c | 128 ++++++++++++++++++++++++++++++++++++----------
mm/mempolicy.c | 20 ++++++++
3 files changed, 130 insertions(+), 26 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH v2 1/6] mm: hugetlb: rename some allocation functions
From: Huang Shijie @ 2016-11-14 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-1-git-send-email-shijie.huang@arm.com>
After a future patch, the __alloc_buddy_huge_page() will not necessarily
use the buddy allocator.
So this patch removes the "buddy" from these functions:
__alloc_buddy_huge_page -> __alloc_huge_page
__alloc_buddy_huge_page_no_mpol -> __alloc_huge_page_no_mpol
__alloc_buddy_huge_page_with_mpol -> __alloc_huge_page_with_mpol
This patch makes preparation for the later patch.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
mm/hugetlb.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3edb759..496b703 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1157,6 +1157,10 @@ static int alloc_fresh_gigantic_page(struct hstate *h,
static inline bool gigantic_page_supported(void) { return true; }
#else
+static inline struct page *alloc_gigantic_page(int nid, unsigned int order)
+{
+ return NULL;
+}
static inline bool gigantic_page_supported(void) { return false; }
static inline void free_gigantic_page(struct page *page, unsigned int order) { }
static inline void destroy_compound_gigantic_page(struct page *page,
@@ -1568,7 +1572,7 @@ static struct page *__hugetlb_alloc_buddy_huge_page(struct hstate *h,
* For (2), we ignore 'vma' and 'addr' and use 'nid' exclusively. This
* implies that memory policies will not be taken in to account.
*/
-static struct page *__alloc_buddy_huge_page(struct hstate *h,
+static struct page *__alloc_huge_page(struct hstate *h,
struct vm_area_struct *vma, unsigned long addr, int nid)
{
struct page *page;
@@ -1649,21 +1653,21 @@ static struct page *__alloc_buddy_huge_page(struct hstate *h,
* anywhere.
*/
static
-struct page *__alloc_buddy_huge_page_no_mpol(struct hstate *h, int nid)
+struct page *__alloc_huge_page_no_mpol(struct hstate *h, int nid)
{
unsigned long addr = -1;
- return __alloc_buddy_huge_page(h, NULL, addr, nid);
+ return __alloc_huge_page(h, NULL, addr, nid);
}
/*
* Use the VMA's mpolicy to allocate a huge page from the buddy.
*/
static
-struct page *__alloc_buddy_huge_page_with_mpol(struct hstate *h,
+struct page *__alloc_huge_page_with_mpol(struct hstate *h,
struct vm_area_struct *vma, unsigned long addr)
{
- return __alloc_buddy_huge_page(h, vma, addr, NUMA_NO_NODE);
+ return __alloc_huge_page(h, vma, addr, NUMA_NO_NODE);
}
/*
@@ -1681,7 +1685,7 @@ struct page *alloc_huge_page_node(struct hstate *h, int nid)
spin_unlock(&hugetlb_lock);
if (!page)
- page = __alloc_buddy_huge_page_no_mpol(h, nid);
+ page = __alloc_huge_page_no_mpol(h, nid);
return page;
}
@@ -1711,7 +1715,7 @@ static int gather_surplus_pages(struct hstate *h, int delta)
retry:
spin_unlock(&hugetlb_lock);
for (i = 0; i < needed; i++) {
- page = __alloc_buddy_huge_page_no_mpol(h, NUMA_NO_NODE);
+ page = __alloc_huge_page_no_mpol(h, NUMA_NO_NODE);
if (!page) {
alloc_ok = false;
break;
@@ -2027,7 +2031,7 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
page = dequeue_huge_page_vma(h, vma, addr, avoid_reserve, gbl_chg);
if (!page) {
spin_unlock(&hugetlb_lock);
- page = __alloc_buddy_huge_page_with_mpol(h, vma, addr);
+ page = __alloc_huge_page_with_mpol(h, vma, addr);
if (!page)
goto out_uncharge_cgroup;
if (!avoid_reserve && vma_has_reserves(vma, gbl_chg)) {
@@ -2285,7 +2289,7 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
* First take pages out of surplus state. Then make up the
* remaining difference by allocating fresh huge pages.
*
- * We might race with __alloc_buddy_huge_page() here and be unable
+ * We might race with __alloc_huge_page() here and be unable
* to convert a surplus huge page to a normal huge page. That is
* not critical, though, it just means the overall size of the
* pool might be one hugepage larger than it needs to be, but
@@ -2331,7 +2335,7 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
* By placing pages into the surplus state independent of the
* overcommit value, we are allowing the surplus pool size to
* exceed overcommit. There are few sane options here. Since
- * __alloc_buddy_huge_page() is checking the global counter,
+ * __alloc_huge_page() is checking the global counter,
* though, we'll note that we're not allowed to exceed surplus
* and won't grow the pool anywhere else. Not until one of the
* sysctls are changed, or the surplus pages go out of use.
--
2.5.5
^ permalink raw reply related
* [PATCH v2 2/6] mm: hugetlb: add a new parameter for some functions
From: Huang Shijie @ 2016-11-14 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-1-git-send-email-shijie.huang@arm.com>
This patch adds a new parameter, the "no_init", for these functions:
alloc_fresh_gigantic_page_node()
alloc_fresh_gigantic_page()
The prep_new_huge_page() does some initialization for the new page.
But sometime, we do not need it to do so, such as in the surplus case
in later patch.
With this parameter, the prep_new_huge_page() can be called by needed:
If the "no_init" is false, calls the prep_new_huge_page() in
the alloc_fresh_gigantic_page_node();
This patch makes preparation for the later patches.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
mm/hugetlb.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 496b703..db0177b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1127,27 +1127,29 @@ static struct page *alloc_gigantic_page(int nid, unsigned int order)
static void prep_new_huge_page(struct hstate *h, struct page *page, int nid);
static void prep_compound_gigantic_page(struct page *page, unsigned int order);
-static struct page *alloc_fresh_gigantic_page_node(struct hstate *h, int nid)
+static struct page *alloc_fresh_gigantic_page_node(struct hstate *h,
+ int nid, bool no_init)
{
struct page *page;
page = alloc_gigantic_page(nid, huge_page_order(h));
if (page) {
prep_compound_gigantic_page(page, huge_page_order(h));
- prep_new_huge_page(h, page, nid);
+ if (!no_init)
+ prep_new_huge_page(h, page, nid);
}
return page;
}
static int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed)
+ nodemask_t *nodes_allowed, bool no_init)
{
struct page *page = NULL;
int nr_nodes, node;
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
- page = alloc_fresh_gigantic_page_node(h, node);
+ page = alloc_fresh_gigantic_page_node(h, node, no_init);
if (page)
return 1;
}
@@ -1166,7 +1168,7 @@ static inline void free_gigantic_page(struct page *page, unsigned int order) { }
static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
static inline int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed) { return 0; }
+ nodemask_t *nodes_allowed, bool no_init) { return 0; }
#endif
static void update_and_free_page(struct hstate *h, struct page *page)
@@ -2313,7 +2315,8 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
cond_resched();
if (hstate_is_gigantic(h))
- ret = alloc_fresh_gigantic_page(h, nodes_allowed);
+ ret = alloc_fresh_gigantic_page(h, nodes_allowed,
+ false);
else
ret = alloc_fresh_huge_page(h, nodes_allowed);
spin_lock(&hugetlb_lock);
--
2.5.5
^ permalink raw reply related
* [PATCH v2 3/6] mm: hugetlb: change the return type for alloc_fresh_gigantic_page
From: Huang Shijie @ 2016-11-14 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-1-git-send-email-shijie.huang@arm.com>
This patch changes the return type to "struct page*" for
alloc_fresh_gigantic_page().
This patch makes preparation for later patch.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
mm/hugetlb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index db0177b..6995087 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1142,7 +1142,7 @@ static struct page *alloc_fresh_gigantic_page_node(struct hstate *h,
return page;
}
-static int alloc_fresh_gigantic_page(struct hstate *h,
+static struct page *alloc_fresh_gigantic_page(struct hstate *h,
nodemask_t *nodes_allowed, bool no_init)
{
struct page *page = NULL;
@@ -1151,10 +1151,10 @@ static int alloc_fresh_gigantic_page(struct hstate *h,
for_each_node_mask_to_alloc(h, nr_nodes, node, nodes_allowed) {
page = alloc_fresh_gigantic_page_node(h, node, no_init);
if (page)
- return 1;
+ return page;
}
- return 0;
+ return NULL;
}
static inline bool gigantic_page_supported(void) { return true; }
@@ -1167,8 +1167,8 @@ static inline bool gigantic_page_supported(void) { return false; }
static inline void free_gigantic_page(struct page *page, unsigned int order) { }
static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
-static inline int alloc_fresh_gigantic_page(struct hstate *h,
- nodemask_t *nodes_allowed, bool no_init) { return 0; }
+static inline struct page *alloc_fresh_gigantic_page(struct hstate *h,
+ nodemask_t *nodes_allowed, bool no_init) { return NULL; }
#endif
static void update_and_free_page(struct hstate *h, struct page *page)
@@ -2315,7 +2315,7 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
cond_resched();
if (hstate_is_gigantic(h))
- ret = alloc_fresh_gigantic_page(h, nodes_allowed,
+ ret = !!alloc_fresh_gigantic_page(h, nodes_allowed,
false);
else
ret = alloc_fresh_huge_page(h, nodes_allowed);
--
2.5.5
^ 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