gmane.linux.ports.ppc.embedded

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Cooper — 2013-05-22T18:58:35

Ahh, no, that was me.  I was contemplating adding the dt entries in this
merge window at one point and must've got my wires crossed.  Sorry for
the confusion.

thx,

Jason.

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Sebastian Hesselbarth — 2013-05-22T18:55:01

True. But there is no node for ethernet controllers in kirkwood.dtsi
yet. It will be there with mv643xx_eth DT patches applied and that is
when the corresponding replacement patch should also be taken in.

I was just confused about your referral to the merge window, because I
guess it is up to David Miller to decide when/whether to take
mv643xx_eth patches in.

Sebastian

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Sebastian Hesselbarth — 2013-05-22T18:51:26

I already thought about bootloaders not setting the register, but I will
not start parsing 1001 places for a valid MAC only for those. Also
reading the MAC address registers is default behavior of mv643xx_eth if
no MAC address is passed through platform_data.

But you are right, there is plenty of sanity checks in the workaround to
ensure that local-mac-address is only overwritten by it when
- you are on DT
- there is no valid MAC address in that node (of_get_mac_address)
- there is a local-mac-address property with a length of 6 bytes

So this workaround only applies on DT booted kernels with no mac set in
DT.

Sebastian

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Cooper — 2013-05-22T18:49:36

I thought you were replacing the unconditional ethernet clock grabbing
with reading the mac from the registers and updating the dtb?  In
mach-kirkwood/board-dt.c?

confused. :-/

Jason.

Re: Build regressions/improvements in v3.10-rc2

Geert Uytterhoeven — 2013-05-22T18:36:04

One false positive due to a line concatenation, and

  + error: drivers/built-in.o: undefined reference to `il_pm_ops':  => .data+0x51ce4)

powerpc-randconfig


Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert< at >linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Sebastian Hesselbarth — 2013-05-22T18:44:20

Which patch do you mean? The local-mac-address workaround will only be
available for DT mv643xx_eth because it uses the DT node to store the
MAC.

Anyway, I found the bit that caused the other issue. It is the
Clk125_Bypass_En bit in PORT_SERIAL_CONTROL1 register. What bothers me
about it is:
- Only Dove and Kirkwood have the bit, MV78x00 doesn't have it, Orion5x
   doesn't have the register at all. With ppc mv64x60 I can only guess,
   but think it is like in Orion5x.
- Reset value of that bit should be 0, but after gating clock on
   Kirkwood it is set to 1 causing wrong port clock to be selected.
   Also Thomas Petazzoni confirmed that it is set after reset so
   either FS is wrong about it or BootROM messes with it.
- Kirkwood and Dove FS tell me that port link must be down when you
   change the bit.

As I can't be sure about how mv643xx_eth will behave on other platforms
except Kirkwood and Dove when writing that register, I tend to force
that bit to zero in the driver but only for those two by #ifdef

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Gunthorpe — 2013-05-22T18:24:48

 

That sounds great, but, FWIW, our bootloaders don't set the MAC
address registers. Does the work around only trigger if the
local-mac-address property is 0?

Jason

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Cooper — 2013-05-22T17:48:15

Cool, chances are, we should be able to take that patch in by itself for
this merge window...

thx,

Jason.

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Sebastian Hesselbarth — 2013-05-22T17:42:36

Hmm, maybe a little bit too early. While restoring the MAC address now
works, another bug arises which I guess is related with phy setup
and aneg.

Will investigate and update patch set accordingly.

Sebastian

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Cooper — 2013-05-22T17:35:05

Sweet!


Please post, in-reply-to v4 is fine.

thx,

Jason.

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Sebastian Hesselbarth — 2013-05-22T17:32:51

Not neccessary anyway, after talking Jason C in a Kirkwood-only
workaround I prepared a patch that reads mac address registers early
and stores it in the local-mac-address property.

Just tested on Dockstar with gated clocks and modular DT mv643xx_eth.

Will append to the DT mv643xx_eth patch set if a v5 will be required
or as single patch prior Jason C taking in the ARM part of it
otherwise.

Sebastian

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Gunthorpe — 2013-05-22T16:59:08


Sorry, no, we don't use ATAGs here, our platforms start the kernel
with a correct DTB that has the correct mac address to use. My patch
was to have the driver accept it, and I think Sebastian has already
got that functionality...

Jason

Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes

Jason Cooper — 2013-05-22T17:01:57

Yes, you're right.

thx,

Jason.

[PATCH -V9 19/20] powerpc: use smp_rmb when looking at deposisted pgtable to store hash index

Aneesh Kumar K.V — 2013-05-22T16:57:51

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

We need to use smb_rmb when looking at hpte slot array. Otherwise we could
reorder the hpte_slot array load bfore even we marked the pmd trans huge.
Related smb_wmb()s is done in pgtable_trans_huge_deposit when we deposit
a pgtable.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/pgtable-ppc64.h | 15 +++++++++++++++
 arch/powerpc/mm/hugepage-hash64.c        |  6 +-----
 arch/powerpc/mm/pgtable_64.c             |  6 +-----
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index d046289..46db094 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
< at >< at > -10,6 +10,7 < at >< at >
 #else
 #include <asm/pgtable-ppc64-4k.h>
 #endif
+#include <asm/barrier.h>
 
 #define FIRST_USER_ADDRESS0
 
< at >< at > -393,6 +394,20 < at >< at > static inline void mark_hpte_slot_valid(unsigned char *hpte_slot_

[PATCH -V9 20/20] powerpc: split hugepage when using subpage protection

Aneesh Kumar K.V — 2013-05-22T16:57:52

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

We find all the overlapping vma and mark them such that we don't allocate
hugepage in that range. Also we split existing huge page so that the
normal page hash can be invalidated and new page faulted in with new
protection bits.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 arch/powerpc/mm/subpage-prot.c | 48 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
index 7c415dd..aa74acb 100644
--- a/arch/powerpc/mm/subpage-prot.c
+++ b/arch/powerpc/mm/subpage-prot.c
< at >< at > -130,6 +130,53 < at >< at > static void subpage_prot_clear(unsigned long addr, unsigned long len)
 up_write(&mm->mmap_sem);
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
+  unsigned long end, struct mm_walk *walk)
+{
+struct vm_area_struct *vma = walk->private;
+split_huge_page_pmd(vma, addr, pmd);
+ret

[PATCH -V9 18/20] powerpc: disable assert_pte_locked for collapse_huge_page

Aneesh Kumar K.V — 2013-05-22T16:57:50

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

With THP we set pmd to none, before we do pte_clear. Hence we can't
walk page table to get the pte lock ptr and verify whether it is locked.
THP do take pte lock before calling pte_clear. So we don't change the locking
rules here. It is that we can't use page table walking to check whether
pte locks are held with THP.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 arch/powerpc/mm/pgtable.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 214130a..edda589 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
< at >< at > -235,6 +235,14 < at >< at > void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
 pud = pud_offset(pgd, addr);
 BUG_ON(pud_none(*pud));
 pmd = pmd_offset(pud, addr);
+/*
+ * khugepaged to collapse normal pages to hugepage, first set
+ * pmd to none to force page fault/gup to take mmap_sem. After
+ * pmd is set to none, we d

[PATCH -V9 08/20] powerpc/THP: Implement transparent hugepages for ppc64

Aneesh Kumar K.V — 2013-05-22T16:57:40

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

We now have pmd entries covering 16MB range and the PMD table double its original size.
We use the second half of the PMD table to deposit the pgtable (PTE page).
The depoisted PTE page is further used to track the HPTE information. The information
include [ secondary group | 3 bit hidx | valid ]. We use one byte per each HPTE entry.
With 16MB hugepage and 64K HPTE we need 256 entries and with 4K HPTE we need
4096 entries. Both will fit in a 4K PTE page. On hugepage invalidate we need to walk
the PTE page and invalidate all valid HPTEs.

This patch implements necessary arch specific functions for THP support and also
hugepage invalidate logic. These PMD related functions are intentionally kept
similar to their PTE counter-part.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/pgtable-ppc64.h | 200 ++++++++++++++++-
 arch/powerpc/include/asm/pgtable.h       |   4 +
 arch/powerpc/include/asm/tlbflush.h

[PATCH -V9 13/20] powerpc/THP: Add code to handle HPTE faults for hugepages

Aneesh Kumar K.V — 2013-05-22T16:57:45

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

The deposted PTE page in the second half of the PMD table is used to
track the state on hash PTEs. After updating the HPTE, we mark the
coresponding slot in the deposted PTE page valid.

Reviewed-by: David Gibson <david< at >gibson.dropbear.id.au>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/mmu-hash64.h |  13 +++
 arch/powerpc/mm/Makefile              |   1 +
 arch/powerpc/mm/hash_utils_64.c       |  21 +++-
 arch/powerpc/mm/hugepage-hash64.c     | 176 ++++++++++++++++++++++++++++++++++
 4 files changed, 207 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/mm/hugepage-hash64.c

diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
index 2accc96..3d6fbb0 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
< at >< at > -340,6 +340,19 < at >< at > extern int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
 int _

[PATCH -V9 15/20] powerpc: Prevent gcc to re-read the pagetables

Aneesh Kumar K.V — 2013-05-22T16:57:47

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

GCC is very likely to read the pagetables just once and cache them in
the local stack or in a register, but it is can also decide to re-read
the pagetables. The problem is that the pagetable in those places can
change from under gcc.

With THP/hugetlbfs the pmd (and pgd for hugetlbfs giga pages) can
change under gup_fast. The pages won't be freed untill we finish
gup fast because we have irq disabled and we free these pages via
rcu callback.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 arch/powerpc/mm/gup.c         | 8 ++++----
 arch/powerpc/mm/hugetlbpage.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index 3d36fd7..4823e4d 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
< at >< at > -34,7 +34,7 < at >< at > static noinline int gup_pte_range(pmd_t pmd, unsigned long addr,
 
 ptep = pte_offset_kernel(&pmd, addr);
 do {
-pte_t pte = *ptep;
+pte_t pte =

[PATCH -V9 05/20] mm/THP: Don't use HPAGE_SHIFT in transparent hugepage code

Aneesh Kumar K.V — 2013-05-22T16:57:37

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

For architectures like powerpc that support multiple explicit hugepage
sizes, HPAGE_SHIFT indicate the default explicit hugepage shift. For
THP to work the hugepage size should be same as PMD_SIZE. So use
PMD_SHIFT directly. So move the define outside CONFIG_TRANSPARENT_HUGEPAGE
#ifdef because we want to use these defines in generic code with
if (pmd_trans_huge()) conditional.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 include/linux/huge_mm.h | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 528454c..cc276d2 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
< at >< at > -58,12 +58,11 < at >< at > extern pmd_t *page_check_address_pmd(struct page *page,
 
 #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
 #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
+#define HPAGE_PMD_SHIFT PMD_SHIFT
+#define HPAGE_PMD_SIZE((1UL) << HPAGE_PMD_SHIFT)
+#defin

[PATCH -V9 04/20] mm/THP: withdraw the pgtable after pmdp related operations

Aneesh Kumar K.V — 2013-05-22T16:57:36

From: "Aneesh Kumar K.V" <aneesh.kumar< at >linux.vnet.ibm.com>

For architectures like ppc64 we look at deposited pgtable when
calling pmdp_get_and_clear. So do the pgtable_trans_huge_withdraw
after finishing pmdp related operations.

Reviewed-by: Andrea Arcangeli <aarcange< at >redhat.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar< at >linux.vnet.ibm.com>
---
 mm/huge_memory.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6b785e1..5c4fac2 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
< at >< at > -1360,9 +1360,15 < at >< at > int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
 struct page *page;
 pgtable_t pgtable;
 pmd_t orig_pmd;
-pgtable = pgtable_trans_huge_withdraw(tlb->mm, pmd);
+/*
+ * For architectures like ppc64 we look at deposited pgtable
+ * when calling pmdp_get_and_clear. So do the
+ * pgtable_trans_huge_withdraw after finishing pmdp related
+ * operations.
+ */
 orig_pmd = pmdp_get_and_clear(tlb->mm, addr,