* Re: [PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory
From: Steve Capper @ 2014-10-28 10:41 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Andrea Arcangeli, linux-arch, linux-kernel, linux-mm, akpm,
linuxppc-dev
In-Reply-To: <1414233860-7683-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Sat, Oct 25, 2014 at 04:14:19PM +0530, Aneesh Kumar K.V wrote:
> Update generic gup implementation with powerpc specific details.
> On powerpc at pmd level we can have hugepte, normal pmd pointer
> or a pointer to the hugepage directory.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
Hi,
Apologies for not getting to this yesterday.
I have some comments below:
> Changes from V3:
> * Explain pgd_huge, also move the definition to linux/hugetlb.h.
> Both pgd_huge and is_hugepd are related to hugepages and hugetlb.h
> is the right header
>
> arch/arm/include/asm/pgtable.h | 2 +
> arch/arm64/include/asm/pgtable.h | 2 +
> arch/powerpc/include/asm/page.h | 1 +
> include/linux/hugetlb.h | 30 +++++++++++
> include/linux/mm.h | 7 +++
> mm/gup.c | 113 +++++++++++++++++++--------------------
> 6 files changed, 96 insertions(+), 59 deletions(-)
>
> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
> index 3b30062..c52d261 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -181,6 +181,8 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
> /* to find an entry in a kernel page-table-directory */
> #define pgd_offset_k(addr) pgd_offset(&init_mm, addr)
>
> +#define pgd_huge(pgd) (0)
> +
Please remove this from the patch as it is no longer needed due to
some changes below.
> #define pmd_none(pmd) (!pmd_val(pmd))
> #define pmd_present(pmd) (pmd_val(pmd))
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 41a43bf..f532a14 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -464,6 +464,8 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
> extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
> extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
>
> +#define pgd_huge(pgd) (0)
> +
This too can be removed (see below)...
> /*
> * Encode and decode a swap entry:
> * bits 0-1: present (must be zero)
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 26fe1ae..f973fce 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -380,6 +380,7 @@ static inline int hugepd_ok(hugepd_t hpd)
> #endif
>
> #define is_hugepd(pdep) (hugepd_ok(*((hugepd_t *)(pdep))))
> +#define pgd_huge pgd_huge
> int pgd_huge(pgd_t pgd);
> #else /* CONFIG_HUGETLB_PAGE */
> #define is_hugepd(pdep) 0
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 6e6d338..de63dbc 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -175,6 +175,36 @@ static inline void __unmap_hugepage_range(struct mmu_gather *tlb,
> }
>
> #endif /* !CONFIG_HUGETLB_PAGE */
> +/*
> + * hugepages at page global directory. If arch support
> + * hugepages at pgd level, they need to define this.
> + */
> +#ifndef pgd_huge
> +#define pgd_huge(x) 0
> +#endif
This sequence now means we no longer need per-arch non-trivial
definitions of pgd_huge. i.e. it makes the arch/arm and arch/arm64
changes above superfluous.
> +
> +#ifndef is_hugepd
> +/*
> + * Some architectures requires a hugepage directory format that is
> + * required to support multiple hugepage sizes. For example
> + * a4fe3ce7699bfe1bd88f816b55d42d8fe1dac655 introduced the same
> + * on powerpc. This allows for a more flexible hugepage pagetable
> + * layout.
> + */
> +typedef struct { unsigned long pd; } hugepd_t;
> +#define is_hugepd(hugepd) (0)
> +#define __hugepd(x) ((hugepd_t) { (x) })
> +static inline int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
> + unsigned pdshift, unsigned long end,
> + int write, struct page **pages, int *nr)
> +{
> + return 0;
> +}
> +#else
> +extern int gup_huge_pd(hugepd_t hugepd, unsigned long addr,
> + unsigned pdshift, unsigned long end,
> + int write, struct page **pages, int *nr);
> +#endif
>
> #define HUGETLB_ANON_FILE "anon_hugepage"
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 02d11ee..31d7fac 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1219,6 +1219,13 @@ long get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> struct vm_area_struct **vmas);
> int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> struct page **pages);
> +
> +#ifdef CONFIG_HAVE_GENERIC_RCU_GUP
> +extern int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
> + unsigned long sz, unsigned long end, int write,
> + struct page **pages, int *nr);
> +#endif
> +
> struct kvec;
> int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
> struct page **pages);
> diff --git a/mm/gup.c b/mm/gup.c
> index cd62c8c..30773f3 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -786,65 +786,31 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
> }
> #endif /* __HAVE_ARCH_PTE_SPECIAL */
>
> -static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
> - unsigned long end, int write, struct page **pages, int *nr)
> +int gup_huge_pte(pte_t orig, pte_t *ptep, unsigned long addr,
> + unsigned long sz, unsigned long end, int write,
> + struct page **pages, int *nr)
> {
> - struct page *head, *page, *tail;
> int refs;
> + unsigned long pte_end;
> + struct page *head, *page, *tail;
>
> - if (write && !pmd_write(orig))
> - return 0;
> -
> - refs = 0;
> - head = pmd_page(orig);
> - page = head + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
> - tail = page;
> - do {
> - VM_BUG_ON_PAGE(compound_head(page) != head, page);
> - pages[*nr] = page;
> - (*nr)++;
> - page++;
> - refs++;
> - } while (addr += PAGE_SIZE, addr != end);
>
> - if (!page_cache_add_speculative(head, refs)) {
> - *nr -= refs;
> + if (write && !pte_write(orig))
> return 0;
> - }
>
> - if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
> - *nr -= refs;
> - while (refs--)
> - put_page(head);
> + if (!pte_present(orig))
> return 0;
> - }
>
> - /*
> - * Any tail pages need their mapcount reference taken before we
> - * return. (This allows the THP code to bump their ref count when
> - * they are split into base pages).
> - */
> - while (refs--) {
> - if (PageTail(tail))
> - get_huge_page_tail(tail);
> - tail++;
> - }
> -
> - return 1;
> -}
> -
> -static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
> - unsigned long end, int write, struct page **pages, int *nr)
> -{
> - struct page *head, *page, *tail;
> - int refs;
> + pte_end = (addr + sz) & ~(sz-1);
> + if (pte_end < end)
> + end = pte_end;
>
> - if (write && !pud_write(orig))
> - return 0;
> + /* hugepages are never "special" */
> + VM_BUG_ON(!pfn_valid(pte_pfn(orig)));
>
> refs = 0;
> - head = pud_page(orig);
> - page = head + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
> + head = pte_page(orig);
> + page = head + ((addr & (sz-1)) >> PAGE_SHIFT);
> tail = page;
> do {
> VM_BUG_ON_PAGE(compound_head(page) != head, page);
> @@ -859,13 +825,18 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
> return 0;
> }
>
> - if (unlikely(pud_val(orig) != pud_val(*pudp))) {
> + if (unlikely(pte_val(orig) != pte_val(*ptep))) {
> *nr -= refs;
> while (refs--)
> put_page(head);
> return 0;
> }
>
> + /*
> + * Any tail pages need their mapcount reference taken before we
> + * return. (This allows the THP code to bump their ref count when
> + * they are split into base pages).
> + */
> while (refs--) {
> if (PageTail(tail))
> get_huge_page_tail(tail);
> @@ -898,10 +869,19 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
> if (pmd_numa(pmd))
> return 0;
>
> - if (!gup_huge_pmd(pmd, pmdp, addr, next, write,
> - pages, nr))
> + if (!gup_huge_pte(__pte(pmd_val(pmd)), (pte_t *)pmdp,
> + addr, PMD_SIZE, next,
> + write, pages, nr))
> return 0;
>
> + } else if (unlikely(is_hugepd(__hugepd(pmd_val(pmd))))) {
> + /*
> + * architecture have different format for hugetlbfs
> + * pmd format and THP pmd format
> + */
> + if (!gup_huge_pd(__hugepd(pmd_val(pmd)), addr,
> + PMD_SHIFT, next, write, pages, nr))
> + return 0;
> } else if (!gup_pte_range(pmd, addr, next, write, pages, nr))
> return 0;
> } while (pmdp++, addr = next, addr != end);
> @@ -909,22 +889,27 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
> return 1;
> }
The new definition of gup_huge_pte does get rid of a lot of code
duplication, but it also introduces the assumption that HugeTLB pages
and THPs can have their attributes referenced by pte_ accessors (rather
than something like pmd_write for instance). Please add this assumption
to the list in the file above.
This will probably be important for pte_pfn and pte_page in case an
architecture packs more attribute bits into what would normally be the
lower address bits of a pte. (for arm and arm64 these bits are
currently unused and expected to be zero so this code works).
>
> -static int gup_pud_range(pgd_t *pgdp, unsigned long addr, unsigned long end,
> +static int gup_pud_range(pgd_t pgd, unsigned long addr, unsigned long end,
> int write, struct page **pages, int *nr)
> {
> unsigned long next;
> pud_t *pudp;
>
> - pudp = pud_offset(pgdp, addr);
> + pudp = pud_offset(&pgd, addr);
> do {
> pud_t pud = ACCESS_ONCE(*pudp);
>
> next = pud_addr_end(addr, end);
> if (pud_none(pud))
> return 0;
> - if (pud_huge(pud)) {
> - if (!gup_huge_pud(pud, pudp, addr, next, write,
> - pages, nr))
> + if (unlikely(pud_huge(pud))) {
> + if (!gup_huge_pte(__pte(pud_val(pud)), (pte_t *)pudp,
> + addr, PUD_SIZE, next,
> + write, pages, nr))
> + return 0;
> + } else if (unlikely(is_hugepd(__hugepd(pud_val(pud))))) {
> + if (!gup_huge_pd(__hugepd(pud_val(pud)), addr,
> + PUD_SHIFT, next, write, pages, nr))
> return 0;
> } else if (!gup_pmd_range(pud, addr, next, write, pages, nr))
> return 0;
> @@ -970,10 +955,21 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
> local_irq_save(flags);
> pgdp = pgd_offset(mm, addr);
> do {
> + pgd_t pgd = ACCESS_ONCE(*pgdp);
> +
> next = pgd_addr_end(addr, end);
> - if (pgd_none(*pgdp))
> + if (pgd_none(pgd))
> break;
> - else if (!gup_pud_range(pgdp, addr, next, write, pages, &nr))
> + if (unlikely(pgd_huge(pgd))) {
> + if (!gup_huge_pte(__pte(pgd_val(pgd)), (pte_t *)pgdp,
> + addr, PGDIR_SIZE, next,
> + write, pages, &nr))
> + break;
> + } else if (unlikely(is_hugepd(__hugepd(pgd_val(pgd))))) {
> + if (!gup_huge_pd(__hugepd(pgd_val(pgd)), addr,
> + PGDIR_SHIFT, next, write, pages, &nr))
> + break;
> + } else if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
> break;
> } while (pgdp++, addr = next, addr != end);
> local_irq_restore(flags);
> @@ -1028,5 +1024,4 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
>
> return ret;
> }
> -
> #endif /* CONFIG_HAVE_GENERIC_RCU_GUP */
> --
With the above changes (remove the arch/arm and arch/arm64 changes and
add an extra assumption to the list for gup_huge_pte):
Acked-by: Steve Capper <steve.capper@linaro.org>
Also, I've tested this on an Arndale board (arm) and a Juno board
(arm64); running a custom futex on THP tail test.
Cheers,
--
Steve
^ permalink raw reply
* Re: [PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory
From: Steve Capper @ 2014-10-28 10:44 UTC (permalink / raw)
To: Andrew Morton
Cc: Andrea Arcangeli, linux-arch, linux-kernel, linux-mm,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20141027183241.a5339085.akpm@linux-foundation.org>
On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote:
> On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> > On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
> > > On Sat, 25 Oct 2014 16:14:19 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > >
> > > > Update generic gup implementation with powerpc specific details.
> > > > On powerpc at pmd level we can have hugepte, normal pmd pointer
> > > > or a pointer to the hugepage directory.
> > >
> > > I grabbed these. It would be better if they were merged into the powerpc
> > > tree where they'll get more testing than in linux-next alone.
> >
> > Fine by me. Can I get an ack from you and/or someone else on CC?
> >
>
> Only arm and arm64 use this code. Steve, could you please look it over
> and check that arm is still happy?
Hi Andrew,
I've tested it and posted some comments on it.
If the arch/arm and arch/arm64 changes are removed and a comment about
an assumption made by the new gup_huge_pte code is added then I'm happy.
Cheers,
--
Steve
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
From: Mark Brown @ 2014-10-28 10:47 UTC (permalink / raw)
To: Nicolin Chen; +Cc: alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20141028042603.GA5548@Asurada>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On Mon, Oct 27, 2014 at 09:26:26PM -0700, Nicolin Chen wrote:
> On Tue, Oct 28, 2014 at 12:19:04AM +0000, Mark Brown wrote:
> > It's not a bug, it's not reasonable to default allocations to atomic and
> > we can't really tell what context we're in. Anything used inside a
> > heavily locked path should either have a default provided or arrange for
> > a prior write to set up the cache.
> I've a little trouble to understand the prior write over here. Inside my
> probe() there's a register_init() call which has a set of regmap_write().
> And then the first regmap_write() results the dump. Does that mean this
> regmap_write() isn't prior write? If so, how should I do if not setting
Oh, bother. We fixed things so that we're now always running with the
spinlock held... never mind.
> default values here -- Some IPs may have default value 0 for registers.
> And this would make reg_defaults tedious since there's nothing special
> to assign.
Write a small script then, or a little bit of code to create the
defaults dynamically.
> And actually I remember I haven't seen any dump when I sent the initial
> patch for the whole ASRC driver but it manifested last month. I thought
> it might be a partially-merging issue and it would be fixed after merge
> window's done.....
Nothing has changed here for a while as far as I remember.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH v3] PowerPC: boot: Parse chosen/cmdline-timeout parameter
From: Simon Kågström @ 2014-10-28 11:19 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev, grant.likely, geert, scottwood
A 5 second timeout during boot might be too long, so make it
configurable. Run the loop at least once to let the user stop the boot
by holding a key pressed. If the timeout is set to 0, don't wait for
input, which can be used as a workaround if the boot hangs on random
data coming in on the serial port.
Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
---
I googled for it, and can't find v2 applied anywhere. I've made an
improvement to the patch: If the timeout is 0, don't wait for input. We
have a board where the serial port gives garbage when it's not
connected - this board would then hang in the bootloader.
If someone (Michael Ellerman?) has already applied it somewhere, I can
send a separate patch for that particular change.
ChangeLog:
v3:
- Don't wait for input if the timeout is 0
v2:
- Rename the property linux,cmdline-timeout (Grant Likely)
- Run the loop at least once to allow (Grant Likely)
arch/powerpc/boot/main.c | 13 +++++++++++--
arch/powerpc/boot/ops.h | 2 +-
arch/powerpc/boot/serial.c | 6 +++---
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index a28f021..acd0414 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -144,13 +144,22 @@ static char cmdline[COMMAND_LINE_SIZE]
static void prep_cmdline(void *chosen)
{
+ unsigned int getline_timeout = 5000;
+ int v;
+ int n;
+
+ /* Wait-for-input time */
+ n = getprop(chosen, "linux,cmdline-timeout", &v, sizeof(v));
+ if (n == sizeof(v))
+ getline_timeout = v;
+
if (cmdline[0] == '\0')
getprop(chosen, "bootargs", cmdline, COMMAND_LINE_SIZE-1);
printf("\n\rLinux/PowerPC load: %s", cmdline);
/* If possible, edit the command line */
- if (console_ops.edit_cmdline)
- console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE);
+ if (console_ops.edit_cmdline && getline_timeout)
+ console_ops.edit_cmdline(cmdline, COMMAND_LINE_SIZE, getline_timeout);
printf("\n\r");
/* Put the command line back into the devtree for the kernel */
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index b3218ce..c42ea70 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -58,7 +58,7 @@ extern struct dt_ops dt_ops;
struct console_ops {
int (*open)(void);
void (*write)(const char *buf, int len);
- void (*edit_cmdline)(char *buf, int len);
+ void (*edit_cmdline)(char *buf, int len, unsigned int getline_timeout);
void (*close)(void);
void *data;
};
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index f2156f0..167ee94 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -33,7 +33,7 @@ static void serial_write(const char *buf, int len)
scdp->putc(*buf++);
}
-static void serial_edit_cmdline(char *buf, int len)
+static void serial_edit_cmdline(char *buf, int len, unsigned int timeout)
{
int timer = 0, count;
char ch, *cp;
@@ -44,7 +44,7 @@ static void serial_edit_cmdline(char *buf, int len)
cp = &buf[count];
count++;
- while (timer++ < 5*1000) {
+ do {
if (scdp->tstc()) {
while (((ch = scdp->getc()) != '\n') && (ch != '\r')) {
/* Test for backspace/delete */
@@ -70,7 +70,7 @@ static void serial_edit_cmdline(char *buf, int len)
break; /* Exit 'timer' loop */
}
udelay(1000); /* 1 msec */
- }
+ } while (timer++ < timeout);
*cp = 0;
}
--
1.7.9.6
^ permalink raw reply related
* Handling of multiple MSI Vecotrs on Freescale P1022
From: Johannes Thumshirn @ 2014-10-28 12:13 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I've a question regarding the handling of multiple MSI Vectors on a Freescale
P1022. In arch_setup_msi_irqs (arch/powerpc/kernel/msi.c) there is a comment
that PowerPC doesn't support multiple MSI yet.
What is the reason for this comment and is there anything I can do to enable
multiple MSI IRQs?
Thanks,
Johannes
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Kumar Gala @ 2014-10-28 14:36 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, linuxppc-dev, robh+dt, scottwood
In-Reply-To: <1413986972-621-1-git-send-email-Emilian.Medve@Freescale.com>
On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> =
wrote:
> The Buffer Manager is part of the Data-Path Acceleration Architecture =
(DPAA).
> BMan supports hardware allocation and deallocation of buffers =
belonging to
> pools originally created by software with configurable depletion =
thresholds.
> This binding covers the CCSR space programming model
>=20
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
> ---
> .../devicetree/bindings/powerpc/fsl/bman.txt | 98 =
++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren=92t you guys using =
this on ARM SoCs as well?
I can=92t remember if the TI guys had a HW allocator as part of their =
similar HW.
>=20
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt =
b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> new file mode 100644
> index 0000000..c30bdde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> @@ -0,0 +1,98 @@
> +QorIQ DPAA Buffer Manager Device Tree Bindings
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Node
> + - BMan Private Memory Node
> + - Example
> +
> +NOTE: The bindings described in this document are preliminary =
and subject to
> + change
> +
> +BMan Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must include "fsl,bman"
> + May include "fsl,<SoC>-bman"
> +
> +- reg
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: Registers region within the CCSR address space
> +
> +- fsl,liodn
> + Usage: See pamu.txt
> + Value type: <prop-encoded-array>
> + Definition: PAMU property used for static LIODN assignment
> +
> +- fsl,iommu-parent
> + Usage: See pamu.txt
> + Value type: <phandle>
> + Definition: PAMU property used for dynamic LIODN assignment
> +
> + For additional details about the PAMU/LIODN binding(s) see =
pamu.txt
> +
interrupts should be in this list.
> +BMan Private Memory Node
> +
> +BMan requires a contiguous range of physical memory used for the =
backing store
> +for BMan Free Buffer Proxy Records. This memory is reserved/allocated =
as a node
> +under the /reserved-memory node
> +
> +The BMan FBPR memory node must be named "bman-fbpr"
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must inclide "fsl,bman-fbpr"
> +
> +The following constraints are relevant to the FBPR private memory:
> + - The size must be 2^(size + 1), with size =3D 11..33. That is 4 =
KiB to
> + 16 GiB
> + - The alignment must be a muliptle of the memory size
> +
> +The size of the FBPR must be chosen by observing the hardware =
features configured
> +via the RCW and that are relevant to a specific board (e.g. number of =
MAC(s)
> +pinned-out, number of offline/host command FMan ports, etc.). The =
size configured
> +in the DT must reflect the hardware capabilities and not the specific =
needs of an
> +application
RCW doesn=92t have any context here
> +
> +If the memory reserved in the device tree proves to be larger then =
the needs of
> +the application a BMan driver may provide a method to release the =
extra memory
> +back to the OS
> +
> +For additional details about reserved memory regions see =
reserved-memory.txt
> +
> +EXAMPLE
> +
> +The example below shows a BMan FBPR dynamic allocation memory node
> +
> + reserved-memory {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + ranges;
> +
> + bman-fbpr {
> + compatible =3D "fsl,bman-fbpr";
> + alloc-ranges =3D <0 0 0xf 0xffffffff>;
> + size =3D <0 0x1000000>;
> + alignment =3D <0 0x1000000>;
> + };
> +
> + };
> +
> +The example below shows a (P4080) BMan CCSR-space node
> +
> + bman@31a000 {
> + compatible =3D "fsl,bman";
> + reg =3D <0x31a000 0x1000>;
> + interrupts =3D <16 2 1 2>;
> + fsl,liodn =3D <0x17>;
no fsl,iommu-parent in the example?
> + };
Do you not need a phandle between the bman and the memory node?
- k
--=20
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora =
Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Kumar Gala @ 2014-10-28 14:39 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, linuxppc-dev, grant.likely,
robh+dt, scottwood
In-Reply-To: <1414487751-31568-2-git-send-email-Emilian.Medve@Freescale.com>
On Oct 28, 2014, at 4:15 AM, Emil Medve <Emilian.Medve@freescale.com> =
wrote:
> The Buffer Manager is part of the Data-Path Acceleration Architecture =
(DPAA).
> BMan supports hardware allocation and deallocation of buffers =
belonging to
> pools originally created by software with configurable depletion =
thresholds.
> This binding covers the CCSR space programming model
>=20
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
> ---
> .../devicetree/bindings/powerpc/fsl/bman.txt | 95 =
++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren=92t you guys using =
this on ARM SoCs as well?
I can=92t remember if the TI guys had a HW allocator as part of their =
similar HW. If so, possibly worth while to see where they have their =
binding.
>=20
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt =
b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> new file mode 100644
> index 0000000..d3fd1e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> @@ -0,0 +1,95 @@
> +QorIQ DPAA Buffer Manager Device Tree Bindings
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Node
> + - BMan Private Memory Node
> + - Example
> +
> +BMan Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must include "fsl,bman"
> + May include "fsl,<SoC>-bman"
> +
> +- reg
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: Registers region within the CCSR address space
> +
> +- interrupts
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: Standard property. The error interrupt
> +
> +- fsl,liodn
> + Usage: See pamu.txt
> + Value type: <prop-encoded-array>
> + Definition: PAMU property used for static LIODN assignment
> +
> +- fsl,iommu-parent
> + Usage: See pamu.txt
> + Value type: <phandle>
> + Definition: PAMU property used for dynamic LIODN assignment
> +
> + For additional details about the PAMU/LIODN binding(s) see =
pamu.txt
> +
> +BMan Private Memory Node
> +
> +BMan requires a contiguous range of physical memory used for the =
backing store
> +for BMan Free Buffer Proxy Records. This memory is reserved/allocated =
as a node
=85 Proxy Records (FBPR). This
[ so we get context for the acronym used later ]
> +under the /reserved-memory node
> +
> +The BMan FBPR memory node must be named "bman-fbpr"
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must inclide "fsl,bman-fbpr"
> +
> +The following constraints are relevant to the FBPR private memory:
> + - The size must be 2^(size + 1), with size =3D 11..33. That is 4 =
KiB to
> + 16 GiB
> + - The alignment must be a muliptle of the memory size
> +
> +The size of the FBPR must be chosen by observing the hardware =
features configured
> +via the RCW and that are relevant to a specific board (e.g. number of =
MAC(s)
> +pinned-out, number of offline/host command FMan ports, etc.). The =
size configured
> +in the DT must reflect the hardware capabilities and not the specific =
needs of an
> +application
RCW doesn=92t have any context here
> +
> +For additional details about reserved memory regions see =
reserved-memory.txt
> +
> +EXAMPLE
> +
> +The example below shows a BMan FBPR dynamic allocation memory node
> +
> + reserved-memory {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + ranges;
> +
> + bman-fbpr {
> + compatible =3D "fsl,bman-fbpr";
> + alloc-ranges =3D <0 0 0xf 0xffffffff>;
> + size =3D <0 0x1000000>;
> + alignment =3D <0 0x1000000>;
> + };
> + };
> +
> +The example below shows a (P4080) BMan CCSR-space node
> +
> + bman@31a000 {
> + compatible =3D "fsl,bman";
> + reg =3D <0x31a000 0x1000>;
> + interrupts =3D <16 2 1 2>;
> + fsl,liodn =3D <0x17>;
no fsl,iommu-parent in the example?
> + };
Do you not need a phandle between the bman and the memory node?
- k
--=20
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora =
Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
From: Kumar Gala @ 2014-10-28 14:41 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, linuxppc-dev, grant.likely,
robh+dt, scottwood
In-Reply-To: <1414487751-31568-3-git-send-email-Emilian.Medve@Freescale.com>
On Oct 28, 2014, at 4:15 AM, Emil Medve <Emilian.Medve@freescale.com> =
wrote:
> Portals are memory mapped interfaces to BMan that allow low-latency,
> lock-less interaction by software running on processor cores, =
accelerators
> and network interfaces with the BMan
>=20
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
> ---
> .../bindings/powerpc/fsl/bman-portals.txt | 52 =
++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>=20
> diff --git =
a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt =
b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
similar comment about location of binding not being PPC specific.
> new file mode 100644
> index 0000000..02e0231
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> @@ -0,0 +1,52 @@
> +QorIQ DPAA Buffer Manager Portals Device Tree Binding
> +
Probably worth putting the text from the commit message here as well.
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Portal
> + - Example
> +
> +BMan Portal Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must include "fsl,bman-portal-<hardware =
revision>"
> + May include "fsl,<SoC>-bman-portal" or =
"fsl,bman-portal"
> +
> +- reg
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: Two regions. The first is the cache-enabled =
region of
> + the portal. The second is the cache-inhibited =
region of
> + the portal
> +
> +- interrupts
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: Standard property
> +
> +EXAMPLE
> +
> +The example below shows a (P4080) BMan portals container/bus node =
with two portals
> +
> + bman-portals@ff4000000 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "simple-bus";
> + ranges =3D <0 0xf 0xf4000000 0x200000>;
> +
> + bman-portal@0 {
> + compatible =3D "fsl,bman-portal-1.0.0", =
"fsl,bman-portal";
> + reg =3D <0x0 0x4000>, <0x100000 0x1000>;
> + interrupts =3D <105 2 0 0>;
> + };
> + bman-portal@4000 {
> + compatible =3D "fsl,bman-portal-1.0.0", =
"fsl,bman-portal";
> + reg =3D <0x4000 0x4000>, <0x101000 0x1000>;
> + interrupts =3D <107 2 0 0>;
> + };
> + };
> --=20
> 2.1.2
>=20
--=20
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora =
Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] ASoC: fsl-asoc-card: Don't bypass settings if cpu-dai is Master
From: Mark Brown @ 2014-10-28 16:05 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel, lgirdwood, b02247, linux-kernel, timur, Li.Xiubo,
linuxppc-dev
In-Reply-To: <1414194502-14052-1-git-send-email-nicoleotsuka@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
On Fri, Oct 24, 2014 at 04:48:11PM -0700, Nicolin Chen wrote:
> When cpu-dai is the DAI Master (CBM_CFx), it may need some configurations,
> set_sysclk() call for eample, for cpu-dai side in the hw_params(), even if
> the set_bias_level() has already taken care of the codec-dai side.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
From: Nicolin Chen @ 2014-10-28 16:37 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20141028104742.GP18557@sirena.org.uk>
On Tue, Oct 28, 2014 at 10:47:42AM +0000, Mark Brown wrote:
> On Mon, Oct 27, 2014 at 09:26:26PM -0700, Nicolin Chen wrote:
> > On Tue, Oct 28, 2014 at 12:19:04AM +0000, Mark Brown wrote:
>
> > > It's not a bug, it's not reasonable to default allocations to atomic and
> > > we can't really tell what context we're in. Anything used inside a
> > > heavily locked path should either have a default provided or arrange for
> > > a prior write to set up the cache.
>
> > I've a little trouble to understand the prior write over here. Inside my
> > probe() there's a register_init() call which has a set of regmap_write().
> > And then the first regmap_write() results the dump. Does that mean this
> > regmap_write() isn't prior write? If so, how should I do if not setting
>
> Oh, bother. We fixed things so that we're now always running with the
> spinlock held... never mind.
Okay...so only one choice left.
> > default values here -- Some IPs may have default value 0 for registers.
> > And this would make reg_defaults tedious since there's nothing special
> > to assign.
>
> Write a small script then, or a little bit of code to create the
> defaults dynamically.
It actually doesn't bother me at all. I just thought there might be
a simpler way. :)
Thank you
Nicolin
^ permalink raw reply
* FSL MSI Mapping
From: Johannes Thumshirn @ 2014-10-28 17:06 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: linuxppc-dev, 'David Engster'
Hi,
I got notified about your patch to support multiple MSI Vectors on Freescale
PowerPC platforms. Is there any reason why it wasn't applied until now? I
couldn't find anything about it in the list archives.
I think it would be a real benefit for all to have multiple MSI vecotrs on
PowerPCs.
Thanks in advance,
Johannes
^ permalink raw reply
* Re: [2/2] powerpc/numa: ensure per-cpu NUMA mappings are correct on topology update
From: Nishanth Aravamudan @ 2014-10-28 17:33 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Paul Mackerras, Michael Wang, Li Zhong, jstancek
In-Reply-To: <20141021043627.99A4F14008C@ozlabs.org>
Hi Michael,
On 21.10.2014 [15:36:27 +1100], Michael Ellerman wrote:
> On Sat, 2014-18-10 at 00:50:40 UTC, Nishanth Aravamudan wrote:
> > We received a report of warning in kernel/sched/core.c where the sched
> > group was NULL on an LPAR after a topology update. This seems to occur
> > because after the topology update has moved the CPUs, cpu_to_node is
> > returning the old value still, which ends up breaking the consistency of
> > the NUMA topology in the per-cpu maps. Ensure that we update the per-cpu
> > fields when we re-map CPUs.
>
> This looks like a bug fix, I assume you want it to go in for 3.18 ?
Yes, please!
Thanks,
Nish
^ permalink raw reply
* Re: [PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
From: Scott Wood @ 2014-10-28 18:09 UTC (permalink / raw)
To: Emil Medve
Cc: Mark Rutland, devicetree@vger.kernel.org, Pawel Moll,
ijc+devicetree@hellion.org.uk, Geoff.Thorpe@freescale.com,
corbet@lwn.net, linux-doc@vger.kernel.org,
linuxppc-dev@ozlabs.org, robh+dt@kernel.org, galak@codeaurora.org
In-Reply-To: <54480DE6.4090604@Freescale.com>
On Wed, 2014-10-22 at 15:04 -0500, Emil Medve wrote:
> Hello Mark,
>
>
> Thanks for having a look at this
>
> On 10/22/2014 09:29 AM, Mark Rutland wrote:
> > I'd feel rather uncomfortable accepting a
> > binding that we already believe to be insufficient to describe the
> > hardware.
> >
> > What do you expect to change?
>
> Related bindings seem incomplete. As such, the PAMU binding (pamu.txt)
> covers incompletely a dynamic LIODN assignment/programming model. The
> current driver uses a static assignment scheme that the binding needs to
> include. I also suspect that once the driver starts supporting the
> dynamic LIODN assignment/programming we might find some wrinkles
How is this different from any of the other QorIQ bindings that have
been merged without such a disclaimer? The static LIODN model is
already there, even if documentation is missing, and should continue to
be supported even if we eventually implement a dynamic LIODN model.
> >> +
> >> + bman-portals@ff4000000 {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + compatible = "simple-bus";
> >> + ranges = <0 0xf 0xf4000000 0x200000>;
> >> +
> >> + bman-portal@0 {
> >> + compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
> >> + reg = <0x0 0x4000 0x100000 0x1000>;
> >
> > It would be easier to read is each entry had its own set of brackets.
> > Initially this looked to me like a single 64-bit address/size pair.
>
> Something like <>, <>? It doesn't seem widely used but I agree is more
> readable. I can include it in the the next spin
The older PPC device trees haven't used it much but I think it's pretty
common in the newer ARM trees.
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Scott Wood @ 2014-10-28 18:19 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, linuxppc-dev, robh+dt, galak
In-Reply-To: <1413986972-621-1-git-send-email-Emilian.Medve@Freescale.com>
On Wed, 2014-10-22 at 09:09 -0500, Emil Medve wrote:
> The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
> BMan supports hardware allocation and deallocation of buffers belonging to
> pools originally created by software with configurable depletion thresholds.
> This binding covers the CCSR space programming model
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
> ---
> .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> new file mode 100644
> index 0000000..c30bdde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> @@ -0,0 +1,98 @@
> +QorIQ DPAA Buffer Manager Device Tree Bindings
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Node
> + - BMan Private Memory Node
> + - Example
> +
> +NOTE: The bindings described in this document are preliminary and subject to
> + change
> +
> +BMan Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must include "fsl,bman"
> + May include "fsl,<SoC>-bman"
> +
> +- reg
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: Registers region within the CCSR address space
Is there a version register in reg? It would be nice to point it out in
the binding along with an example chip for each version, similar to
Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt. This
would make it clear that the compatible needs to be changed if the
version register moves or no longer works the same way.
> +BMan Private Memory Node
> +
> +BMan requires a contiguous range of physical memory used for the backing store
> +for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a node
> +under the /reserved-memory node
> +
> +The BMan FBPR memory node must be named "bman-fbpr"
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must inclide "fsl,bman-fbpr"
> +
> +The following constraints are relevant to the FBPR private memory:
> + - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
> + 16 GiB
> + - The alignment must be a muliptle of the memory size
> +
> +The size of the FBPR must be chosen by observing the hardware features configured
> +via the RCW and that are relevant to a specific board (e.g. number of MAC(s)
> +pinned-out, number of offline/host command FMan ports, etc.). The size configured
> +in the DT must reflect the hardware capabilities and not the specific needs of an
> +application
What about accelerators?
> +If the memory reserved in the device tree proves to be larger then the needs of
> +the application a BMan driver may provide a method to release the extra memory
> +back to the OS
What if the memory reserved in the device tree proves to be smaller than
the needs of the application?
I think we should document this size as being a sane default for the
hardware, and add a way of describing that the size is tunable.
Below is the reserved-memory extension that I suggested to you
internally:
resizable (optional) - empty property
- Indicates that the size of the dynamic allocation is flexible. If
resizeable is present, the size property is optional. If both resizable
and size are present, the size property indicates a recommended default
size for this hardware.
pow2-aligned (optional) - empty property
- Only valid if resizable is present. Indicates that the size must
be a power of two, and the address must be aligned to its size. If both
pow2-aligned and alignment properties are present, pow2-aligned is used
if the region is resized, and the alignment property is used if the
region is not resized.
min-size (optional) - Only valid if resizable is present. Specifies a
minimum acceptable size.
max-size (optional) - Only valid if resizable is present. Specifies a
maximum acceptable size.
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
From: Scott Wood @ 2014-10-28 18:08 UTC (permalink / raw)
To: Kumar Gala
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, Emil Medve, linuxppc-dev,
robh+dt
In-Reply-To: <EA33D307-CCDA-4A30-9386-46FA832FE0CA@codeaurora.org>
On Tue, 2014-10-28 at 09:36 -0500, Kumar Gala wrote:
> On Oct 22, 2014, at 9:09 AM, Emil Medve <Emilian.Medve@freescale.com> wrote:
>
> > The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
> > BMan supports hardware allocation and deallocation of buffers belonging to
> > pools originally created by software with configurable depletion thresholds.
> > This binding covers the CCSR space programming model
> >
> > Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> > Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
> > ---
> > .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++++++++++++++++++++++
> > 1 file changed, 98 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
>
> Should these really be in bindings/powerpc/fsl, aren’t you guys using this on ARM SoCs as well?
The hardware on the ARM SoCs is different enough that I'm not sure the
same binding will cover it. That said, putting things under <arch>
should be a last resort if nowhere else fits.
-Scott
^ permalink raw reply
* Re: [PATCH 4/4] dt/bindings: Introduce the FSL QorIQ DPAA QMan portal(s)
From: Scott Wood @ 2014-10-28 18:27 UTC (permalink / raw)
To: Emil Medve
Cc: mark.rutland, devicetree, pawel.moll, ijc+devicetree,
Geoff.Thorpe, corbet, linux-doc, linuxppc-dev, robh+dt, galak
In-Reply-To: <1413986972-621-4-git-send-email-Emilian.Medve@Freescale.com>
On Wed, 2014-10-22 at 09:09 -0500, Emil Medve wrote:
> +- fsl,liodn
> + Usage: See pamu.txt
> + Value type: <prop-encoded-array>
> + Definition: PAMU property used for static LIODN assignment
There are two LIODNs on these nodes; you need to specifiy here which is
which. Likewise on the crypto subnode.
> +The currently support sub-nodes are:
> + * fman@0
> + * fman@1
> + * pme@0
> + * crypto@0
s/support/supported/
> +These subnodes should have the following properties:
> +
> +- fsl,liodn
> + Usage: See pamu.txt
> + Value type: <prop-encoded-array>
> + Definition: PAMU property used for static LIODN assignment
> +
> +- fsl,iommu-parent
> + Usage: See pamu.txt
> + Value type: <phandle>
> + Definition: PAMU property used for dynamic LIODN assignment
> +
> +- dev-handle
> + Usage: Required
> + Value type: <phandle>
> + Definition: The phandle to the particular hardware device that this
> + portal is connected to.
> +
> +DPAA QMan Pool Channel Nodes
> +
> +Pool Channels are defined with the following properties.
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type: <stringlist>
> + Definition: Must include "fsl,qman-pool-channel"
> + May include "fsl,<SoC>-qman-pool-channel"
> +
> +- fsl,qman-channel-id
> + Usage: Required
> + Value type: <u32>
> + Definition: The hardware index of the channel. This can also be
> + determined by dividing any of the channel's 8 work queue
> + IDs by 8
> +
> +EXAMPLE
> +
> +The example below shows a (P4080) BMan portals container/bus node with two portals
> +
> + qman-portals@ff4200000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges = <0 0xf 0xf4200000 0x200000>;
> +
> + qman-portal@0 {
> + cell-index = <0>;
> + compatible = "fsl,qman-portal-1.2.0", "fsl,qman-portal";
> + reg = <0 0x4000 0x100000 0x1000>;
> + interrupts = <104 2 0 0>;
> + fsl,liodn = <1 2>;
> + fsl,qman-channel-id = <0>;
> +
> + fman@0 {
> + fsl,liodn = <0x21>;
> + dev-handle = <&fman0>;
> + };
> + fman@1 {
> + fsl,liodn = <0xa1>;
> + dev-handle = <&fman1>;
> + };
> + crypto@0 {
> + fsl,liodn = <0x41 0x66>;
> + dev-handle = <&crypto>;
> + };
Shouldn't have unit address without reg; use fman0/fman1/crypto instead.
-Scott
^ permalink raw reply
* Re: FSL MSI Mapping
From: Scott Wood @ 2014-10-28 19:10 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: Sebastian Andrzej Siewior, linuxppc-dev, 'David Engster'
In-Reply-To: <20141028170604.GA1536@jtlinux>
On Tue, 2014-10-28 at 18:06 +0100, Johannes Thumshirn wrote:
> Hi,
>
> I got notified about your patch to support multiple MSI Vectors on Freescale
> PowerPC platforms. Is there any reason why it wasn't applied until now? I
> couldn't find anything about it in the list archives.
>
> I think it would be a real benefit for all to have multiple MSI vecotrs on
> PowerPCs.
Could you provide a patchwork link to the patch you're talking about?
-Scott
^ permalink raw reply
* Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
From: Randy Dunlap @ 2014-10-28 20:29 UTC (permalink / raw)
To: Tomi Valkeinen, Jani Nikula
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, Jingoo Han,
Daniel Drake, Jens Frederich, David Airlie, Greg Kroah-Hartman,
Jon Nettleton, linux-usb, linux-kernel, dri-devel,
platform-driver-x86, Lee Jones, Laurent Pinchart, Darren Hart,
Daniel Vetter, Bryan Wu, linuxppc-dev
In-Reply-To: <544E44E9.4040208@ti.com>
On 10/27/14 06:13, Tomi Valkeinen wrote:
> On 27/10/14 13:59, Jani Nikula wrote:
>
>>> While doing 'depends on' instead of 'select' is an "easy" fix for this,
>>> I do dislike it quite a bit. It's a major pain to go around the kernel
>>> config, trying to find all the dependencies that a particular driver
>>> wants. If I need fb-foobar, I should just be able to enable it, instead
>>> of first searching and selecting its minor dependencies individually.
>>
>> Agreed, but I don't think that's specific to this patch.
>
> Well, no, the generic problem is not specific to this patch, but we can
> avoid the issue with proper use of 'select' (at least in some cases),
> which is specific to this patch.
>
>>> So, not a NACK, but a "isn't there an another way to fix this?".
>>
>> I think the real answer would be to fix kconfig to also show menu items
>> whose dependencies are not met, and then recursively enabling the
>> dependencies when the item is enabled. Beyond my scope.
>>
>>> Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta"
>>> option, it only enables a Kconfig submenu.
>>>
>>> So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option.
>>> But if we do that, all the items in drivers/video/backlight/Kconfig with
>>> default 'y' or 'm' would get enabled by default, so I think we should
>>> remove the 'default's from that file. That makes sense in any case, as I
>>> don't see why "HP Jornada 700 series LCD Driver" should be "default y".
>>>
>>> BACKLIGHT_CLASS_DEVICE doesn't depend on anything except
>>> BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should
>>> be safe to 'select' BACKLIGHT_CLASS_DEVICE.
>>>
>>> BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in
>>> drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE
>>> could be made to select BACKLIGHT_CLASS_DEVICE instead.
>>
>> I think it should be possible to choose between y and m when it's
>
> If I'm not mistaken, if CONFIG_FOO is 'm', and it 'select's CONFIG_BAR,
> and CONFIG_BAR is tristate, then CONFIG_BAR will be set to 'm'.
>
>> selected, and it should be possible to enable it when it's not selected
>> by any drivers. I'm not sure a hidden option is good for that.
>
> Why would you want to enable it if no one uses it? Does
> BACKLIGHT_CLASS_DEVICE enable something even if no driver uses it?
>
>>> That doesn't exactly fix anything, but I think it makes sense as
>>> BACKLIGHT_CLASS_DEVICE is something that's selected from all around the
>>> kernel, so it should be a selectable "library" instead of a Kconfig menu
>>> option.
>>
>> At least for drm/i915 BACKLIGHT_CLASS_DEVICE is "an option". We use it
>> if it's enabled, but we are just fine if it's not. I've learned the way
>> to express that is
>>
>> depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
>>
>> but I don't think there's a way to express that in terms of select, is
>> there? The dependency above guarantees there's no DRM_I915=y and
>> BACKLIGHT_CLASS_DEVICE=m combo which would fail. And this, btw, is where
>> this whole patch got started, as select didn't handle that properly.
>
> If backlight support is considered an option for drm/i915, then I think
> there should be a Kconfig option for i915 to enable backlight support,
> which in turn selects BACKLIGHT_CLASS_DEVICE. And that select will force
> BACKLIGHT_CLASS_DEVICE to be built-in if drm/i915 is built-in.
>
> Oh, but it doesn't work optimally with modules. The new option needed
> for that would be boolean, so BACKLIGHT_CLASS_DEVICE would always be
> either y or n. Sigh...
>
>>> I didn't look at the ACPI_VIDEO side, so no idea how messy that is.
>>
>> Basically it's another dependency on BACKLIGHT_CLASS_DEVICE. I can only
>> imagine trying to solve this problem with select is going to end up in
>> recursive dependencies that spread out and need changing about as wide
>> as this patch.
>
> If ACPI_VIDEO uses select to enable BACKLIGHT_CLASS_DEVICE, then, I
> think, selecting ACPI_VIDEO will also select BACKLIGHT_CLASS_DEVICE. So
> I don't right away see any recursive dependencies. Or what did you have
> in mind?
>
>> In the end, I agree with the problem you have with this patch, but yet I
>> think it's the right thing to do in terms of expressing the
>> dependencies.
>
> Well, dri/i915 doesn't exactly depend on backlight, if I understood you
> correctly. Instead, backlight is an option for dri/i915, and you kind of
> hack it to be implemented with that 'depends on BACKLIGHT_CLASS_DEVICE
> || BACKLIGHT_CLASS_DEVICE=n'.
>
> I guess it's debatable whether drivers should automatically use features
> in the kernel if they happen to be enabled in the Kconfig, or should
> they be individually enabled for that driver. I personally like the
> latter option, as it allows more precise control, but it probably also
> depends on the feature in question.
>
> I also think the 'depends on BACKLIGHT_CLASS_DEVICE ||
> BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds
> like a hack to me =).
It does exactly what is needed and it is used in many places in kernel
Kconfig files.
--
~Randy
^ permalink raw reply
* Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
From: Scott Wood @ 2014-10-28 23:08 UTC (permalink / raw)
To: Valentin Longchamp
Cc: Rainer Boschung, Linux device trees, Holger Brunck,
Linux PowerPC Kernel, Linux I2C
In-Reply-To: <1413538026-15739-1-git-send-email-valentin.longchamp@keymile.com>
On Fri, 2014-10-17 at 11:27 +0200, Valentin Longchamp wrote:
> With "fsl-i2c" compatibility the i2c frequency is not set
> correctly, because it sets no prescaler. According to the AN2919 from
> Freescale and the QorIQ (P2041) documentation, the source clock is 1/2
> the platform clock. This implies that a prescaler of 2 must be used.
>
> This changes the compatibility of the qoriq-i2c .dtsi files to pick the
> mpc8543, which uses the same driver but sets the correct prescaler.
>
> Signed-off-by: Rainer Boschung <rainer.boschung@keymile.com>
> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
> ---
>
> arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi | 4 ++--
> arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
> index 5f9bf7d..aa6c366 100644
> --- a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
> @@ -36,7 +36,7 @@ i2c@118000 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> - compatible = "fsl-i2c";
> + compatible = "fsl,mpc8543-i2c", "fsl-i2c";
> reg = <0x118000 0x100>;
> interrupts = <38 2 0 0>;
> dfsrr;
> @@ -46,7 +46,7 @@ i2c@118100 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <1>;
> - compatible = "fsl-i2c";
> + compatible = "fsl,mpc8543-i2c", "fsl-i2c";
> reg = <0x118100 0x100>;
> interrupts = <38 2 0 0>;
> dfsrr;
Are all chips that use this dtsi 100% compatible with mpc8543's i2c, or
just in ways the Linux driver cares about?
What about fsl,mpc8544-i2c, which has additional special handling in the
driver, but is only used in socrates.dts (not mpc8544ds.dts)?
What about pq3-i2c-*.dtsi?
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/dts: Factorize the clock control node
From: Scott Wood @ 2014-10-28 23:21 UTC (permalink / raw)
To: Emil Medve; +Cc: yuantian.tang, linuxppc-dev, devicetree
In-Reply-To: <1413988937-27885-1-git-send-email-Emilian.Medve@Freescale.com>
On Wed, 2014-10-22 at 09:42 -0500, Emil Medve wrote:
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I25ce24a25862b4ca460164159867abefe00ccdd1
Please remove gerrit stuff prior to submitting.
> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
> new file mode 100644
> index 0000000..4871048
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi
> @@ -0,0 +1,78 @@
> +/*
> + * QorIQ clock control device tree stub [ controller @ offset 0xe1000 ]
> + *
> + * Copyright 2014 Freescale Semiconductor Inc.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions are met:
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in the
> + * documentation and/or other materials provided with the distribution.
> + * * Neither the name of Freescale Semiconductor nor the
> + * names of its contributors may be used to endorse or promote products
> + * derived from this software without specific prior written permission.
> + *
> + *
> + * ALTERNATIVELY, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") as published by the Free Software
> + * Foundation, either version 2 of that License or (at your option) any
> + * later version.
> + *
> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +global-utilities@e1000 {
> + compatible = "fsl,qoriq-clockgen-1.0";
> + ranges = <0x0 0xe1000 0x1000>;
> + reg = <0xe1000 0x1000>;
> + clock-frequency = <0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + sysclk: sysclk {
> + #clock-cells = <0>;
> + compatible = "fsl,qoriq-sysclk-1.0", "fixed-clock";
> + clock-output-names = "sysclk";
> + };
> + pll0: pll0@800 {
> + #clock-cells = <1>;
> + reg = <0x800 0x4>;
> + compatible = "fsl,qoriq-core-pll-1.0";
> + clocks = <&sysclk>;
> + clock-output-names = "pll0", "pll0-div2";
> + };
> + pll1: pll1@820 {
> + #clock-cells = <1>;
> + reg = <0x820 0x4>;
> + compatible = "fsl,qoriq-core-pll-1.0";
> + clocks = <&sysclk>;
> + clock-output-names = "pll1", "pll1-div2";
> + };
> + mux0: mux0@0 {
> + #clock-cells = <0>;
> + reg = <0x0 0x4>;
> + compatible = "fsl,qoriq-core-mux-1.0";
> + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
> + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
> + clock-output-names = "cmux0";
> + };
> + mux1: mux1@20 {
> + #clock-cells = <0>;
> + reg = <0x20 0x4>;
> + compatible = "fsl,qoriq-core-mux-1.0";
> + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
> + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
> + clock-output-names = "cmux1";
> + };
> +};
I don't think the mux stuff belongs here, given that clockgen2.dtsi
doesn't have it, and I saw at least one clockgen1 user needing to
supplement this with more muxes.
> @@ -1068,7 +1043,6 @@
> clocks = <&sysclk>;
> clock-output-names = "pll2", "pll2-div2", "pll2-div4";
> };
> -
> pll3: pll3@860 {
> #clock-cells = <1>;
> reg = <0x860 0x4>;
> @@ -1076,7 +1050,6 @@
> clocks = <&sysclk>;
> clock-output-names = "pll3", "pll3-div2", "pll3-div4";
> };
> -
> pll4: pll4@880 {
> #clock-cells = <1>;
> reg = <0x880 0x4>;
Why?
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] dt/bindings: qoriq-clock: Add binding for the platform PLL
From: Scott Wood @ 2014-10-28 23:23 UTC (permalink / raw)
To: Emil Medve; +Cc: yuantian.tang, linuxppc-dev, devicetree
In-Reply-To: <1413988937-27885-2-git-send-email-Emilian.Medve@Freescale.com>
On Wed, 2014-10-22 at 09:42 -0500, Emil Medve wrote:
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Change-Id: I7950afa9650d15ec7ce2cca89bb2a1e38586d4a5
> ---
> Documentation/devicetree/bindings/clock/qoriq-clock.txt | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index 5666812..407fb01 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -62,6 +62,8 @@ Required properties:
> It takes parent's clock-frequency as its clock.
> * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
> It takes parent's clock-frequency as its clock.
> + * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
> + * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
> - #clock-cells: From common clock binding. The number of cells in a
> clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
> clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
> @@ -94,7 +96,6 @@ Example for clock block and clock provider:
> compatible = "fsl,qoriq-sysclk-1.0";
> clock-output-names = "sysclk";
> };
> -
> pll0: pll0@800 {
> #clock-cells = <1>;
> reg = <0x800 0x4>;
> @@ -102,7 +103,6 @@ Example for clock block and clock provider:
> clocks = <&sysclk>;
> clock-output-names = "pll0", "pll0-div2";
> };
> -
> pll1: pll1@820 {
> #clock-cells = <1>;
> reg = <0x820 0x4>;
> @@ -110,7 +110,6 @@ Example for clock block and clock provider:
> clocks = <&sysclk>;
> clock-output-names = "pll1", "pll1-div2";
> };
> -
> mux0: mux0@0 {
> #clock-cells = <0>;
> reg = <0x0 0x4>;
Please don't make unrelated whitespace changes, especially when they're
changing something that's not obviously broken.
-Scott
^ permalink raw reply
* Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
From: Michael Ellerman @ 2014-10-29 3:04 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-fbdev, linux-usb, Daniel Drake, Jens Frederich, Jani Nikula,
Greg Kroah-Hartman, Jon Nettleton, Jingoo Han, linux-kernel,
dri-devel, platform-driver-x86, Bryan Wu, David Airlie,
Tomi Valkeinen, Laurent Pinchart, Daniel Vetter, Darren Hart,
Lee Jones, linuxppc-dev, Jean-Christophe Plagniol-Villard
In-Reply-To: <544FFC91.9040104@infradead.org>
On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote:
> On 10/27/14 06:13, Tomi Valkeinen wrote:
> > I also think the 'depends on BACKLIGHT_CLASS_DEVICE ||
> > BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds
> > like a hack to me =).
>
> It does exactly what is needed and it is used in many places in kernel
> Kconfig files.
Is there any reason you can't do:
depends on BACKLIGHT_CLASS_DEVICE != m
cheers
^ permalink raw reply
* Re: lockdep warning with 2d65a9f48fcdf7866aab6457bc707ca233e0c791
From: Paul Mackerras @ 2014-10-29 4:20 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, kvm-ppc@vger.kernel.org
In-Reply-To: <87d29tkzsi.fsf@linux.vnet.ibm.com>
On Wed, Oct 15, 2014 at 10:58:45PM +0530, Aneesh Kumar K.V wrote:
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 3.17.0+ #31 Not tainted
> ---------------------------------------------
> qemu-system-ppc/9112 is trying to acquire lock:
> (&(&vcpu->arch.tbacct_lock)->rlock){......}, at: [<d000000011591f84>] .vcore_stolen_time+0x44/0xb0 [kvm_hv]
>
> but task is already holding lock:
> (&(&vcpu->arch.tbacct_lock)->rlock){......}, at: [<d000000011592524>] .kvmppc_remove_runnable.part.2+0x34/0xd0 [kvm_hv]
This is actually harmless, because the lock taken in
vcore_stolen_time() is always a different lock from the one taken in
kvmppc_remove_runnable(). In vcore_stolen_time() we take the lock of
the runner vcpu if we are not the runner vcpu (if we are the runner,
we don't take any lock there). Nor is there any lock ordering
problem, because we always take the runner's lock last.
This is all a bit subtle, probably a bit too subtle. I have been
meaning to rework it but haven't had the time yet.
Paul.
^ permalink raw reply
* Re: [PATCH V3 1/2] mm: Update generic gup implementation to handle hugepage directory
From: Michael Ellerman @ 2014-10-29 4:46 UTC (permalink / raw)
To: Steve Capper
Cc: Andrea Arcangeli, linux-arch, linux-kernel, linux-mm,
Aneesh Kumar K.V, Andrew Morton, linuxppc-dev
In-Reply-To: <20141028104451.GB4187@linaro.org>
On Tue, 2014-10-28 at 10:44 +0000, Steve Capper wrote:
> On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote:
> > On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
> >
> > > On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
> > > > On Sat, 25 Oct 2014 16:14:19 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > > >
> > > > > Update generic gup implementation with powerpc specific details.
> > > > > On powerpc at pmd level we can have hugepte, normal pmd pointer
> > > > > or a pointer to the hugepage directory.
> > > >
> > > > I grabbed these. It would be better if they were merged into the powerpc
> > > > tree where they'll get more testing than in linux-next alone.
> > >
> > > Fine by me. Can I get an ack from you and/or someone else on CC?
> >
> > Only arm and arm64 use this code. Steve, could you please look it over
> > and check that arm is still happy?
>
> Hi Andrew,
> I've tested it and posted some comments on it.
>
> If the arch/arm and arch/arm64 changes are removed and a comment about
> an assumption made by the new gup_huge_pte code is added then I'm happy.
OK thanks Steve.
Aneesh can you do those changes and resend and I'll put it in powerpc next.
cheers
^ permalink raw reply
* Re: [v3] PowerPC: boot: Parse chosen/cmdline-timeout parameter
From: Michael Ellerman @ 2014-10-29 5:06 UTC (permalink / raw)
To: Simon Kagstrom, linuxppc-dev, grant.likely, geert, scottwood
In-Reply-To: <20141028121900.0f3bccc7@marrow.netinsight.se>
On Tue, 2014-28-10 at 11:19:00 UTC, Simon Kagstrom wrote:
> A 5 second timeout during boot might be too long, so make it
> configurable. Run the loop at least once to let the user stop the boot
> by holding a key pressed. If the timeout is set to 0, don't wait for
> input, which can be used as a workaround if the boot hangs on random
> data coming in on the serial port.
>
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
> ---
>
> I googled for it, and can't find v2 applied anywhere. I've made an
> improvement to the patch: If the timeout is 0, don't wait for input. We
> have a board where the serial port gives garbage when it's not
> connected - this board would then hang in the bootloader.
>
> If someone (Michael Ellerman?) has already applied it somewhere, I can
> send a separate patch for that particular change.
No I haven't applied it yet. I will put it in next in the next week or so for
3.19, you don't need to do anything.
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox