[git pull] drm fixes

[Dave Airlie]

Hi Linus,

This is mostly amdgpu/radeon fixes, and imx related fixes.

There are also one one TTM fix, one nouveau fix, and one hdlcd fix.

The AMD ones are some fixes for power management after suspend/resume
one some GPUs, and some vblank fixes.

The IMX ones are for more stricter plane checks and some cleanups.

I'm off until Monday, so therre might be some fixes early next week if 
anyone missed me.

Dave.

The following changes since commit 541d8f4d59d79f5d37c8c726f723d42ff307db57:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
(2016-04-05 16:16:00 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to fd8c61ebd4265ff1c5fa80ba351e8e1dd710fac0:

  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-04-07 07:08:46 +1000)


Alex Deucher (4):
  drm/amdgpu/gmc: move vram type fetching into sw_init
  drm/amdgpu/gmc: use proper register for vram type on Fiji
  drm/amdgpu: print vram type rather than just DDR
  drm/ttm: use phys_addr_t for ttm_bus_placement

Alexandre Courbot (1):
  drm/nouveau/tegra: acquire and enable reference clock if needed

Alexey Brodkin (1):
  drm: ARM HDLCD - get rid of devm_clk_put()

Christian König (1):
  drm/amdgpu: fix leaking fence in the pageflip code

Chunming Zhou (2):
  drm/amdgpu: fence wait old rcu slot
  drm/amdgpu: total vram size also reduces pin size

Dan Carpenter (1):
  drm: ARM HDLCD - fix an error code

Daniel Vetter (1):
  drm/imx: Don't set a gamma table size

Dave Airlie (4):
  Merge tag 'imx-drm-next-2016-04-01' of 
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge branch 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld into 
drm-fixes
  Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Douglas Anderson (2):
  drm/imx: dw_hdmi: Call drm_encoder_cleanup() in error path
  drm/imx: dw_hdmi: Don't call platform_set_drvdata()

Leo Liu (2):
  drm/amdgpu: save and restore UVD context with suspend and resume
  drm/amdgpu: save and restore the firwmware cache part when suspend resume

Liu Ying (4):
  gpu: ipu-v3: ipu-dmfc: Protect function ipu_dmfc_init_channel() with mutex
  gpu: ipu-v3: ipu-dmfc: Make function ipu_dmfc_init_channel() return void
  gpu: ipu-v3: ipu-dmfc: Rename ipu_dmfc_init_channel to 
ipu_dmfc_config_wait4eot
  drm/imx: ipuv3-plane: Configure DMFC wait4eot bit after slots are 
determined

Michel Dänzer (3):
  drm/radeon: Set vblank_disable_allowed = true
  drm/amdgpu: Set vblank_disable_allowed = true
  drm/radeon: Only call drm_vblank_on/off between drm_vblank_init/cleanup

Philipp Zabel (3):
  gpu: ipu-cpmem: modify ipu_cpmem_set_yuv_planar_full for better control
  drm/imx: ipuv3-plane: Add more thorough checks for plane parameter 
limitations
  drm/imx: ipuv3-plane: fix planar YUV 4:2:0 support

Rex Zhu (9):
  drm/amd/powerplay: fix segment fault issue in multi-display case.
  drm/amdgpu: add an cgs interface to notify amdgpu the dpm state.
  drm/amdgpu: Not support disable dpm in powerplay.
  drm/amd/powerplay: notify amdgpu whether dpm is enabled or not.
  drm/amdgpu: check dpm state before pm system fs initialized.
  drm/amd/powerplay: add new Fiji function for not setting same ps.
  drm/amd/powerplay: Need to change boot to performance state in resume.
  drm/amd/powerplay: fix issue that resume back, dpm can't work on FIJI.
  drm/amd/powerplay: add uvd/vce dpm enabling flag default.

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  24 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  15 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  58 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  16 +--
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  23 ++--
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   7 +-
 drivers/gpu/drm/amd/include/cgs_common.h   |   8 ++
 .../drm/amd/powerplay/eventmgr/eventactionchains.c |   4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   |  69 
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  |  16 ++-
 drivers/gpu/drm/arm/hdlcd_drv.c|  14 +--
 

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

This is mostly amdgpu/radeon fixes, and imx related fixes.

There are also one one TTM fix, one nouveau fix, and one hdlcd fix.

The AMD ones are some fixes for power management after suspend/resume
one some GPUs, and some vblank fixes.

The IMX ones are for more stricter plane checks and some cleanups.

I'm off until Monday, so therre might be some fixes early next week if 
anyone missed me.

Dave.

The following changes since commit 541d8f4d59d79f5d37c8c726f723d42ff307db57:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
(2016-04-05 16:16:00 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to fd8c61ebd4265ff1c5fa80ba351e8e1dd710fac0:

  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-04-07 07:08:46 +1000)


Alex Deucher (4):
  drm/amdgpu/gmc: move vram type fetching into sw_init
  drm/amdgpu/gmc: use proper register for vram type on Fiji
  drm/amdgpu: print vram type rather than just DDR
  drm/ttm: use phys_addr_t for ttm_bus_placement

Alexandre Courbot (1):
  drm/nouveau/tegra: acquire and enable reference clock if needed

Alexey Brodkin (1):
  drm: ARM HDLCD - get rid of devm_clk_put()

Christian König (1):
  drm/amdgpu: fix leaking fence in the pageflip code

Chunming Zhou (2):
  drm/amdgpu: fence wait old rcu slot
  drm/amdgpu: total vram size also reduces pin size

Dan Carpenter (1):
  drm: ARM HDLCD - fix an error code

Daniel Vetter (1):
  drm/imx: Don't set a gamma table size

Dave Airlie (4):
  Merge tag 'imx-drm-next-2016-04-01' of 
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Merge branch 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld into 
drm-fixes
  Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Douglas Anderson (2):
  drm/imx: dw_hdmi: Call drm_encoder_cleanup() in error path
  drm/imx: dw_hdmi: Don't call platform_set_drvdata()

Leo Liu (2):
  drm/amdgpu: save and restore UVD context with suspend and resume
  drm/amdgpu: save and restore the firwmware cache part when suspend resume

Liu Ying (4):
  gpu: ipu-v3: ipu-dmfc: Protect function ipu_dmfc_init_channel() with mutex
  gpu: ipu-v3: ipu-dmfc: Make function ipu_dmfc_init_channel() return void
  gpu: ipu-v3: ipu-dmfc: Rename ipu_dmfc_init_channel to 
ipu_dmfc_config_wait4eot
  drm/imx: ipuv3-plane: Configure DMFC wait4eot bit after slots are 
determined

Michel Dänzer (3):
  drm/radeon: Set vblank_disable_allowed = true
  drm/amdgpu: Set vblank_disable_allowed = true
  drm/radeon: Only call drm_vblank_on/off between drm_vblank_init/cleanup

Philipp Zabel (3):
  gpu: ipu-cpmem: modify ipu_cpmem_set_yuv_planar_full for better control
  drm/imx: ipuv3-plane: Add more thorough checks for plane parameter 
limitations
  drm/imx: ipuv3-plane: fix planar YUV 4:2:0 support

Rex Zhu (9):
  drm/amd/powerplay: fix segment fault issue in multi-display case.
  drm/amdgpu: add an cgs interface to notify amdgpu the dpm state.
  drm/amdgpu: Not support disable dpm in powerplay.
  drm/amd/powerplay: notify amdgpu whether dpm is enabled or not.
  drm/amdgpu: check dpm state before pm system fs initialized.
  drm/amd/powerplay: add new Fiji function for not setting same ps.
  drm/amd/powerplay: Need to change boot to performance state in resume.
  drm/amd/powerplay: fix issue that resume back, dpm can't work on FIJI.
  drm/amd/powerplay: add uvd/vce dpm enabling flag default.

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  24 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  15 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  58 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  16 +--
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  23 ++--
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   7 +-
 drivers/gpu/drm/amd/include/cgs_common.h   |   8 ++
 .../drm/amd/powerplay/eventmgr/eventactionchains.c |   4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   |  69 
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  |  16 ++-
 drivers/gpu/drm/arm/hdlcd_drv.c|  14 +--
 

PXA310 U2DC Controller support

[金鑫]

Hi, Robert
 I'm woking with a board which integrated PXA310 on it. While
Debugging U2DC controller, found that once U2DC Controller have been
started, It couldn't be stopped completely.  The windows shows unknown
device while Stopping U2DC and Usb line haven't been unplugged from PC

 Have you ever meet the problem? or could you give me some advice?
or you  have the right procedure to stop U2DC?

Thank you very much
waiting for your reply

-- 
Best Regards.

PXA310 U2DC Controller support

[金鑫]

Hi, Robert
 I'm woking with a board which integrated PXA310 on it. While
Debugging U2DC controller, found that once U2DC Controller have been
started, It couldn't be stopped completely.  The windows shows unknown
device while Stopping U2DC and Usb line haven't been unplugged from PC

 Have you ever meet the problem? or could you give me some advice?
or you  have the right procedure to stop U2DC?

Thank you very much
waiting for your reply

-- 
Best Regards.

[PATCH 04/10] powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB

[Anshuman Khandual]

This just adds user space exported ABI definitions for both 16MB and
16GB non default huge page sizes to be used with mmap() system call.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/include/uapi/asm/mman.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/include/uapi/asm/mman.h 
b/arch/powerpc/include/uapi/asm/mman.h
index 03c06ba..e78980b 100644
--- a/arch/powerpc/include/uapi/asm/mman.h
+++ b/arch/powerpc/include/uapi/asm/mman.h
@@ -29,4 +29,7 @@
 #define MAP_STACK  0x2 /* give out an address that is best 
suited for process/thread stacks */
 #define MAP_HUGETLB0x4 /* create a huge page mapping */
 
+#define MAP_HUGE_16MB  (24 << MAP_HUGE_SHIFT)  /* 16MB HugeTLB Page */
+#define MAP_HUGE_16GB  (34 << MAP_HUGE_SHIFT)  /* 16GB HugeTLB Page */
+
 #endif /* _UAPI_ASM_POWERPC_MMAN_H */
-- 
2.1.0

[PATCH 04/10] powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB

[Anshuman Khandual]

This just adds user space exported ABI definitions for both 16MB and
16GB non default huge page sizes to be used with mmap() system call.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/include/uapi/asm/mman.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/include/uapi/asm/mman.h 
b/arch/powerpc/include/uapi/asm/mman.h
index 03c06ba..e78980b 100644
--- a/arch/powerpc/include/uapi/asm/mman.h
+++ b/arch/powerpc/include/uapi/asm/mman.h
@@ -29,4 +29,7 @@
 #define MAP_STACK  0x2 /* give out an address that is best 
suited for process/thread stacks */
 #define MAP_HUGETLB0x4 /* create a huge page mapping */
 
+#define MAP_HUGE_16MB  (24 << MAP_HUGE_SHIFT)  /* 16MB HugeTLB Page */
+#define MAP_HUGE_16GB  (34 << MAP_HUGE_SHIFT)  /* 16GB HugeTLB Page */
+
 #endif /* _UAPI_ASM_POWERPC_MMAN_H */
-- 
2.1.0

[PATCH 06/10] powerpc/hugetlb: Split the function 'huge_pte_offset'

[Anshuman Khandual]

Currently the function 'huge_pte_offset' has just got one version for all
possible configurations and platforms. This change splits that function
into two versions, first one for ARCH_WANT_GENERAL_HUGETLB implementation
and the other one for everything else. This change is again one of the
prerequisites towards enabling ARCH_WANT_GENERAL_ HUGETLB config option
on POWER platform.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/mm/hugetlbpage.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index e453918..8fc6d23 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -53,11 +53,46 @@ static unsigned nr_gpages;
 
 #define hugepd_none(hpd)   ((hpd).pd == 0)
 
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
 {
/* Only called for hugetlbfs pages, hence can ignore THP */
return __find_linux_pte_or_hugepte(mm->pgd, addr, NULL, NULL);
 }
+#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+{
+   pgd_t pgd, *pgdp;
+   pud_t pud, *pudp;
+   pmd_t pmd, *pmdp;
+
+   pgdp = mm->pgd + pgd_index(addr);
+   pgd  = READ_ONCE(*pgdp);
+
+   if (pgd_none(pgd))
+   return NULL;
+
+   if (pgd_huge(pgd))
+   return (pte_t *)pgdp;
+
+   pudp = pud_offset(, addr);
+   pud  = READ_ONCE(*pudp);
+   if (pud_none(pud))
+   return NULL;
+
+   if (pud_huge(pud))
+   return (pte_t *)pudp;
+
+   pmdp = pmd_offset(, addr);
+   pmd  = READ_ONCE(*pmdp);
+   if (pmd_none(pmd))
+   return NULL;
+
+   if (pmd_huge(pmd))
+   return (pte_t *)pmdp;
+   return NULL;
+}
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 
 #ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
-- 
2.1.0

[PATCH 10/10] selfttest/powerpc: Add memory page migration tests

[Anshuman Khandual]

This adds two tests for memory page migration. One for normal page
migration which works for both 4K or 64K base page size kernel and
the other one is for huge page migration which works only on 64K
base page sized 16MB huge page implemention at the PMD level.

Signed-off-by: Anshuman Khandual 
---
 tools/testing/selftests/powerpc/mm/Makefile|  14 +-
 .../selftests/powerpc/mm/hugepage-migration.c  |  30 +++
 tools/testing/selftests/powerpc/mm/migration.h | 205 +
 .../testing/selftests/powerpc/mm/page-migration.c  |  33 
 tools/testing/selftests/powerpc/mm/run_mmtests | 104 +++
 5 files changed, 381 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/powerpc/mm/hugepage-migration.c
 create mode 100644 tools/testing/selftests/powerpc/mm/migration.h
 create mode 100644 tools/testing/selftests/powerpc/mm/page-migration.c
 create mode 100755 tools/testing/selftests/powerpc/mm/run_mmtests

diff --git a/tools/testing/selftests/powerpc/mm/Makefile 
b/tools/testing/selftests/powerpc/mm/Makefile
index ee179e2..c482614 100644
--- a/tools/testing/selftests/powerpc/mm/Makefile
+++ b/tools/testing/selftests/powerpc/mm/Makefile
@@ -1,12 +1,16 @@
 noarg:
$(MAKE) -C ../
 
-TEST_PROGS := hugetlb_vs_thp_test subpage_prot
-TEST_FILES := tempfile
+TEST_PROGS := run_mmtests
+TEST_FILES := hugetlb_vs_thp_test
+TEST_FILES += subpage_prot
+TEST_FILES += tempfile
+TEST_FILES += hugepage-migration
+TEST_FILES += page-migration
 
-all: $(TEST_PROGS) $(TEST_FILES)
+all: $(TEST_FILES)
 
-$(TEST_PROGS): ../harness.c
+$(TEST_FILES): ../harness.c
 
 include ../../lib.mk
 
@@ -14,4 +18,4 @@ tempfile:
dd if=/dev/zero of=tempfile bs=64k count=1
 
 clean:
-   rm -f $(TEST_PROGS) tempfile
+   rm -f $(TEST_FILES)
diff --git a/tools/testing/selftests/powerpc/mm/hugepage-migration.c 
b/tools/testing/selftests/powerpc/mm/hugepage-migration.c
new file mode 100644
index 000..b60bc10
--- /dev/null
+++ b/tools/testing/selftests/powerpc/mm/hugepage-migration.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2015, Anshuman Khandual, IBM Corporation.
+ *
+ * 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.
+ */
+#include "migration.h"
+
+static int hugepage_migration(void)
+{
+   int ret = 0;
+
+   if ((unsigned long)getpagesize() == 0x1000)
+   printf("Running on base page size 4K\n");
+
+   if ((unsigned long)getpagesize() == 0x1)
+   printf("Running on base page size 64K\n");
+
+   ret = test_huge_migration(16 * MEM_MB);
+   ret = test_huge_migration(256 * MEM_MB);
+   ret = test_huge_migration(512 * MEM_MB);
+
+   return ret;
+}
+
+int main(void)
+{
+   return test_harness(hugepage_migration, "hugepage_migration");
+}
diff --git a/tools/testing/selftests/powerpc/mm/migration.h 
b/tools/testing/selftests/powerpc/mm/migration.h
new file mode 100644
index 000..9d4e273
--- /dev/null
+++ b/tools/testing/selftests/powerpc/mm/migration.h
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2015, Anshuman Khandual, IBM Corporation.
+ *
+ * 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "utils.h"
+
+#define HPAGE_OFF  0
+#define HPAGE_ON   1
+
+#define PAGE_SHIFT_4K  12
+#define PAGE_SHIFT_64K 16
+#define PAGE_SIZE_4K   0x1000
+#define PAGE_SIZE_64K  0x1
+#define PAGE_SIZE_HUGE 16UL * 1024 * 1024
+
+#define MEM_GB 1024UL * 1024 * 1024
+#define MEM_MB 1024UL * 1024
+#define MME_KB 1024UL
+
+#define PMAP_FILE  "/proc/self/pagemap"
+#define PMAP_PFN   0x007FUL
+#define PMAP_SIZE  8
+
+#define SOFT_OFFLINE   "/sys/devices/system/memory/soft_offline_page"
+#define HARD_OFFLINE   "/sys/devices/system/memory/hard_offline_page"
+
+#define MMAP_LENGTH(256 * MEM_MB)
+#define MMAP_ADDR  (void *)(0x0UL)
+#define MMAP_PROT  (PROT_READ | PROT_WRITE)
+#define MMAP_FLAGS (MAP_PRIVATE | MAP_ANONYMOUS)
+#define MMAP_FLAGS_HUGE(MAP_SHARED)
+
+#define FILE_NAME  "huge/hugepagefile"
+
+static void write_buffer(char *addr, unsigned long length)
+{
+   unsigned long i;
+
+   for (i = 0; i < length; i++)
+   *(addr + i) = (char)i;
+}
+
+static int read_buffer(char *addr, unsigned long length)
+{
+   unsigned long i;
+
+   for (i = 0; i < length; i++) {
+   if (*(addr + i) != (char)i) {
+   printf("Data miscompare at addr[%lu]\n", i);
+   return 1;
+   }
+   }
+   return 0;
+}
+
+static unsigned long get_npages(unsigned long length, unsigned long size)
+{
+   unsigned int 

[PATCH 02/10] mm/hugetlb: Add PGD based implementation awareness

[Anshuman Khandual]

Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like
'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB
page implementation at the PGD level. This is also true for functions
like 'follow_page_mask' which is called from move_pages() system call.
This lack of PGD level huge page support prohibits some architectures
to use these generic HugeTLB functions.

This change adds the required PGD based implementation awareness and
with that, more architectures like POWER which implements 16GB pages
at the PGD level along with the 16MB pages at the PMD level can now
use ARCH_WANT_GENERAL_HUGETLB config option.

Signed-off-by: Anshuman Khandual 
---
 include/linux/hugetlb.h |  3 +++
 mm/gup.c|  6 ++
 mm/hugetlb.c| 20 
 3 files changed, 29 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 7d953c2..71832e1 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -115,6 +115,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm, unsigned 
long address,
pmd_t *pmd, int flags);
 struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
pud_t *pud, int flags);
+struct page *follow_huge_pgd(struct mm_struct *mm, unsigned long address,
+   pgd_t *pgd, int flags);
 int pmd_huge(pmd_t pmd);
 int pud_huge(pud_t pmd);
 unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
@@ -143,6 +145,7 @@ static inline void hugetlb_show_meminfo(void)
 }
 #define follow_huge_pmd(mm, addr, pmd, flags)  NULL
 #define follow_huge_pud(mm, addr, pud, flags)  NULL
+#define follow_huge_pgd(mm, addr, pgd, flags)  NULL
 #define prepare_hugepage_range(file, addr, len)(-EINVAL)
 #define pmd_huge(x)0
 #define pud_huge(x)0
diff --git a/mm/gup.c b/mm/gup.c
index fb87aea..9bac78c 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -234,6 +234,12 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
pgd = pgd_offset(mm, address);
if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
return no_page_table(vma, flags);
+   if (pgd_huge(*pgd) && vma->vm_flags & VM_HUGETLB) {
+   page = follow_huge_pgd(mm, address, pgd, flags);
+   if (page)
+   return page;
+   return no_page_table(vma, flags);
+   }
 
pud = pud_offset(pgd, address);
if (pud_none(*pud))
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 19d0d08..5ea3158 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4250,6 +4250,11 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte_t *pte = NULL;
 
pgd = pgd_offset(mm, addr);
+   if (sz == PGDIR_SIZE) {
+   pte = (pte_t *)pgd;
+   goto huge_pgd;
+   }
+
pud = pud_alloc(mm, pgd, addr);
if (pud) {
if (sz == PUD_SIZE) {
@@ -4262,6 +4267,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte = (pte_t *)pmd_alloc(mm, pud, addr);
}
}
+
+huge_pgd:
BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte));
 
return pte;
@@ -4275,6 +4282,8 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned 
long addr)
 
pgd = pgd_offset(mm, addr);
if (pgd_present(*pgd)) {
+   if (pgd_huge(*pgd))
+   return (pte_t *)pgd;
pud = pud_offset(pgd, addr);
if (pud_present(*pud)) {
if (pud_huge(*pud))
@@ -4343,6 +4352,17 @@ follow_huge_pud(struct mm_struct *mm, unsigned long 
address,
return pte_page(*(pte_t *)pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT);
 }
 
+struct page * __weak
+follow_huge_pgd(struct mm_struct *mm, unsigned long address,
+   pgd_t *pgd, int flags)
+{
+   if (flags & FOLL_GET)
+   return NULL;
+
+   return pte_page(*(pte_t *)pgd) +
+   ((address & ~PGDIR_MASK) >> PAGE_SHIFT);
+}
+
 #ifdef CONFIG_MEMORY_FAILURE
 
 /*
-- 
2.1.0

[PATCH 06/10] powerpc/hugetlb: Split the function 'huge_pte_offset'

[Anshuman Khandual]

Currently the function 'huge_pte_offset' has just got one version for all
possible configurations and platforms. This change splits that function
into two versions, first one for ARCH_WANT_GENERAL_HUGETLB implementation
and the other one for everything else. This change is again one of the
prerequisites towards enabling ARCH_WANT_GENERAL_ HUGETLB config option
on POWER platform.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/mm/hugetlbpage.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index e453918..8fc6d23 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -53,11 +53,46 @@ static unsigned nr_gpages;
 
 #define hugepd_none(hpd)   ((hpd).pd == 0)
 
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
 {
/* Only called for hugetlbfs pages, hence can ignore THP */
return __find_linux_pte_or_hugepte(mm->pgd, addr, NULL, NULL);
 }
+#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
+{
+   pgd_t pgd, *pgdp;
+   pud_t pud, *pudp;
+   pmd_t pmd, *pmdp;
+
+   pgdp = mm->pgd + pgd_index(addr);
+   pgd  = READ_ONCE(*pgdp);
+
+   if (pgd_none(pgd))
+   return NULL;
+
+   if (pgd_huge(pgd))
+   return (pte_t *)pgdp;
+
+   pudp = pud_offset(, addr);
+   pud  = READ_ONCE(*pudp);
+   if (pud_none(pud))
+   return NULL;
+
+   if (pud_huge(pud))
+   return (pte_t *)pudp;
+
+   pmdp = pmd_offset(, addr);
+   pmd  = READ_ONCE(*pmdp);
+   if (pmd_none(pmd))
+   return NULL;
+
+   if (pmd_huge(pmd))
+   return (pte_t *)pmdp;
+   return NULL;
+}
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 
 #ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
-- 
2.1.0

[PATCH 10/10] selfttest/powerpc: Add memory page migration tests

[Anshuman Khandual]

This adds two tests for memory page migration. One for normal page
migration which works for both 4K or 64K base page size kernel and
the other one is for huge page migration which works only on 64K
base page sized 16MB huge page implemention at the PMD level.

Signed-off-by: Anshuman Khandual 
---
 tools/testing/selftests/powerpc/mm/Makefile|  14 +-
 .../selftests/powerpc/mm/hugepage-migration.c  |  30 +++
 tools/testing/selftests/powerpc/mm/migration.h | 205 +
 .../testing/selftests/powerpc/mm/page-migration.c  |  33 
 tools/testing/selftests/powerpc/mm/run_mmtests | 104 +++
 5 files changed, 381 insertions(+), 5 deletions(-)
 create mode 100644 tools/testing/selftests/powerpc/mm/hugepage-migration.c
 create mode 100644 tools/testing/selftests/powerpc/mm/migration.h
 create mode 100644 tools/testing/selftests/powerpc/mm/page-migration.c
 create mode 100755 tools/testing/selftests/powerpc/mm/run_mmtests

diff --git a/tools/testing/selftests/powerpc/mm/Makefile 
b/tools/testing/selftests/powerpc/mm/Makefile
index ee179e2..c482614 100644
--- a/tools/testing/selftests/powerpc/mm/Makefile
+++ b/tools/testing/selftests/powerpc/mm/Makefile
@@ -1,12 +1,16 @@
 noarg:
$(MAKE) -C ../
 
-TEST_PROGS := hugetlb_vs_thp_test subpage_prot
-TEST_FILES := tempfile
+TEST_PROGS := run_mmtests
+TEST_FILES := hugetlb_vs_thp_test
+TEST_FILES += subpage_prot
+TEST_FILES += tempfile
+TEST_FILES += hugepage-migration
+TEST_FILES += page-migration
 
-all: $(TEST_PROGS) $(TEST_FILES)
+all: $(TEST_FILES)
 
-$(TEST_PROGS): ../harness.c
+$(TEST_FILES): ../harness.c
 
 include ../../lib.mk
 
@@ -14,4 +18,4 @@ tempfile:
dd if=/dev/zero of=tempfile bs=64k count=1
 
 clean:
-   rm -f $(TEST_PROGS) tempfile
+   rm -f $(TEST_FILES)
diff --git a/tools/testing/selftests/powerpc/mm/hugepage-migration.c 
b/tools/testing/selftests/powerpc/mm/hugepage-migration.c
new file mode 100644
index 000..b60bc10
--- /dev/null
+++ b/tools/testing/selftests/powerpc/mm/hugepage-migration.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2015, Anshuman Khandual, IBM Corporation.
+ *
+ * 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.
+ */
+#include "migration.h"
+
+static int hugepage_migration(void)
+{
+   int ret = 0;
+
+   if ((unsigned long)getpagesize() == 0x1000)
+   printf("Running on base page size 4K\n");
+
+   if ((unsigned long)getpagesize() == 0x1)
+   printf("Running on base page size 64K\n");
+
+   ret = test_huge_migration(16 * MEM_MB);
+   ret = test_huge_migration(256 * MEM_MB);
+   ret = test_huge_migration(512 * MEM_MB);
+
+   return ret;
+}
+
+int main(void)
+{
+   return test_harness(hugepage_migration, "hugepage_migration");
+}
diff --git a/tools/testing/selftests/powerpc/mm/migration.h 
b/tools/testing/selftests/powerpc/mm/migration.h
new file mode 100644
index 000..9d4e273
--- /dev/null
+++ b/tools/testing/selftests/powerpc/mm/migration.h
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2015, Anshuman Khandual, IBM Corporation.
+ *
+ * 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.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "utils.h"
+
+#define HPAGE_OFF  0
+#define HPAGE_ON   1
+
+#define PAGE_SHIFT_4K  12
+#define PAGE_SHIFT_64K 16
+#define PAGE_SIZE_4K   0x1000
+#define PAGE_SIZE_64K  0x1
+#define PAGE_SIZE_HUGE 16UL * 1024 * 1024
+
+#define MEM_GB 1024UL * 1024 * 1024
+#define MEM_MB 1024UL * 1024
+#define MME_KB 1024UL
+
+#define PMAP_FILE  "/proc/self/pagemap"
+#define PMAP_PFN   0x007FUL
+#define PMAP_SIZE  8
+
+#define SOFT_OFFLINE   "/sys/devices/system/memory/soft_offline_page"
+#define HARD_OFFLINE   "/sys/devices/system/memory/hard_offline_page"
+
+#define MMAP_LENGTH(256 * MEM_MB)
+#define MMAP_ADDR  (void *)(0x0UL)
+#define MMAP_PROT  (PROT_READ | PROT_WRITE)
+#define MMAP_FLAGS (MAP_PRIVATE | MAP_ANONYMOUS)
+#define MMAP_FLAGS_HUGE(MAP_SHARED)
+
+#define FILE_NAME  "huge/hugepagefile"
+
+static void write_buffer(char *addr, unsigned long length)
+{
+   unsigned long i;
+
+   for (i = 0; i < length; i++)
+   *(addr + i) = (char)i;
+}
+
+static int read_buffer(char *addr, unsigned long length)
+{
+   unsigned long i;
+
+   for (i = 0; i < length; i++) {
+   if (*(addr + i) != (char)i) {
+   printf("Data miscompare at addr[%lu]\n", i);
+   return 1;
+   }
+   }
+   return 0;
+}
+
+static unsigned long get_npages(unsigned long length, unsigned long size)
+{
+   unsigned int tmp1 = length, tmp2 = size;
+

[PATCH 02/10] mm/hugetlb: Add PGD based implementation awareness

[Anshuman Khandual]

Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like
'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB
page implementation at the PGD level. This is also true for functions
like 'follow_page_mask' which is called from move_pages() system call.
This lack of PGD level huge page support prohibits some architectures
to use these generic HugeTLB functions.

This change adds the required PGD based implementation awareness and
with that, more architectures like POWER which implements 16GB pages
at the PGD level along with the 16MB pages at the PMD level can now
use ARCH_WANT_GENERAL_HUGETLB config option.

Signed-off-by: Anshuman Khandual 
---
 include/linux/hugetlb.h |  3 +++
 mm/gup.c|  6 ++
 mm/hugetlb.c| 20 
 3 files changed, 29 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 7d953c2..71832e1 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -115,6 +115,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm, unsigned 
long address,
pmd_t *pmd, int flags);
 struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
pud_t *pud, int flags);
+struct page *follow_huge_pgd(struct mm_struct *mm, unsigned long address,
+   pgd_t *pgd, int flags);
 int pmd_huge(pmd_t pmd);
 int pud_huge(pud_t pmd);
 unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
@@ -143,6 +145,7 @@ static inline void hugetlb_show_meminfo(void)
 }
 #define follow_huge_pmd(mm, addr, pmd, flags)  NULL
 #define follow_huge_pud(mm, addr, pud, flags)  NULL
+#define follow_huge_pgd(mm, addr, pgd, flags)  NULL
 #define prepare_hugepage_range(file, addr, len)(-EINVAL)
 #define pmd_huge(x)0
 #define pud_huge(x)0
diff --git a/mm/gup.c b/mm/gup.c
index fb87aea..9bac78c 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -234,6 +234,12 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
pgd = pgd_offset(mm, address);
if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
return no_page_table(vma, flags);
+   if (pgd_huge(*pgd) && vma->vm_flags & VM_HUGETLB) {
+   page = follow_huge_pgd(mm, address, pgd, flags);
+   if (page)
+   return page;
+   return no_page_table(vma, flags);
+   }
 
pud = pud_offset(pgd, address);
if (pud_none(*pud))
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 19d0d08..5ea3158 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4250,6 +4250,11 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte_t *pte = NULL;
 
pgd = pgd_offset(mm, addr);
+   if (sz == PGDIR_SIZE) {
+   pte = (pte_t *)pgd;
+   goto huge_pgd;
+   }
+
pud = pud_alloc(mm, pgd, addr);
if (pud) {
if (sz == PUD_SIZE) {
@@ -4262,6 +4267,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte = (pte_t *)pmd_alloc(mm, pud, addr);
}
}
+
+huge_pgd:
BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte));
 
return pte;
@@ -4275,6 +4282,8 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned 
long addr)
 
pgd = pgd_offset(mm, addr);
if (pgd_present(*pgd)) {
+   if (pgd_huge(*pgd))
+   return (pte_t *)pgd;
pud = pud_offset(pgd, addr);
if (pud_present(*pud)) {
if (pud_huge(*pud))
@@ -4343,6 +4352,17 @@ follow_huge_pud(struct mm_struct *mm, unsigned long 
address,
return pte_page(*(pte_t *)pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT);
 }
 
+struct page * __weak
+follow_huge_pgd(struct mm_struct *mm, unsigned long address,
+   pgd_t *pgd, int flags)
+{
+   if (flags & FOLL_GET)
+   return NULL;
+
+   return pte_page(*(pte_t *)pgd) +
+   ((address & ~PGDIR_MASK) >> PAGE_SHIFT);
+}
+
 #ifdef CONFIG_MEMORY_FAILURE
 
 /*
-- 
2.1.0

[PATCH 05/10] powerpc/hugetlb: Split the function 'huge_pte_alloc'

[Anshuman Khandual]

Currently the function 'huge_pte_alloc' has got two versions, one for the
BOOK3S server and the other one for the BOOK3E embedded platforms. This
change splits only the BOOK3S server version into two parts, one for the
ARCH_WANT_GENERAL_HUGETLB config implementation and the other one for
everything else. This change is one of the prerequisites towards enabling
ARCH_WANT_GENERAL_HUGETLB config option on POWER platform.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/mm/hugetlbpage.c | 67 +++
 1 file changed, 43 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index d991b9e..e453918 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -59,6 +59,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long 
addr)
return __find_linux_pte_or_hugepte(mm->pgd, addr, NULL, NULL);
 }
 
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
   unsigned long address, unsigned pdshift, unsigned 
pshift)
 {
@@ -116,6 +117,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t 
*hpdp,
spin_unlock(>page_table_lock);
return 0;
 }
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 
 /*
  * These macros define how to determine which level of the page table holds
@@ -130,6 +132,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t 
*hpdp,
 #endif
 
 #ifdef CONFIG_PPC_BOOK3S_64
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 /*
  * At this point we do the placement change only for BOOK3S 64. This would
  * possibly work on other subarchs.
@@ -145,32 +148,23 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr, unsigned long sz
 
addr &= ~(sz-1);
pg = pgd_offset(mm, addr);
-
-   if (pshift == PGDIR_SHIFT)
-   /* 16GB huge page */
-   return (pte_t *) pg;
-   else if (pshift > PUD_SHIFT)
-   /*
-* We need to use hugepd table
-*/
+   if (pshift > PUD_SHIFT) {
hpdp = (hugepd_t *)pg;
-   else {
-   pdshift = PUD_SHIFT;
-   pu = pud_alloc(mm, pg, addr);
-   if (pshift == PUD_SHIFT)
-   return (pte_t *)pu;
-   else if (pshift > PMD_SHIFT)
-   hpdp = (hugepd_t *)pu;
-   else {
-   pdshift = PMD_SHIFT;
-   pm = pmd_alloc(mm, pu, addr);
-   if (pshift == PMD_SHIFT)
-   /* 16MB hugepage */
-   return (pte_t *)pm;
-   else
-   hpdp = (hugepd_t *)pm;
-   }
+   goto hugepd_search;
}
+
+   pdshift = PUD_SHIFT;
+   pu = pud_alloc(mm, pg, addr);
+   if (pshift > PMD_SHIFT) {
+   hpdp = (hugepd_t *)pu;
+   goto hugepd_search;
+   }
+
+   pdshift = PMD_SHIFT;
+   pm = pmd_alloc(mm, pu, addr);
+   hpdp = (hugepd_t *)pm;
+
+hugepd_search:
if (!hpdp)
return NULL;
 
@@ -182,6 +176,31 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr, unsigned long sz
return hugepte_offset(*hpdp, addr, pdshift);
 }
 
+#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long 
sz)
+{
+   pgd_t *pg;
+   pud_t *pu;
+   pmd_t *pm;
+   unsigned pshift = __ffs(sz);
+
+   addr &= ~(sz-1);
+   pg = pgd_offset(mm, addr);
+
+   if (pshift == PGDIR_SHIFT)  /* 16GB Huge Page */
+   return (pte_t *)pg;
+
+   pu = pud_alloc(mm, pg, addr);   /* NA, skipped */
+   if (pshift == PUD_SHIFT)
+   return (pte_t *)pu;
+
+   pm = pmd_alloc(mm, pu, addr);   /* 16MB Huge Page */
+   if (pshift == PMD_SHIFT)
+   return (pte_t *)pm;
+
+   return NULL;
+}
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 #else
 
 pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long 
sz)
-- 
2.1.0

[PATCH 05/10] powerpc/hugetlb: Split the function 'huge_pte_alloc'

[Anshuman Khandual]

Currently the function 'huge_pte_alloc' has got two versions, one for the
BOOK3S server and the other one for the BOOK3E embedded platforms. This
change splits only the BOOK3S server version into two parts, one for the
ARCH_WANT_GENERAL_HUGETLB config implementation and the other one for
everything else. This change is one of the prerequisites towards enabling
ARCH_WANT_GENERAL_HUGETLB config option on POWER platform.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/mm/hugetlbpage.c | 67 +++
 1 file changed, 43 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index d991b9e..e453918 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -59,6 +59,7 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long 
addr)
return __find_linux_pte_or_hugepte(mm->pgd, addr, NULL, NULL);
 }
 
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
   unsigned long address, unsigned pdshift, unsigned 
pshift)
 {
@@ -116,6 +117,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t 
*hpdp,
spin_unlock(>page_table_lock);
return 0;
 }
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 
 /*
  * These macros define how to determine which level of the page table holds
@@ -130,6 +132,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t 
*hpdp,
 #endif
 
 #ifdef CONFIG_PPC_BOOK3S_64
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 /*
  * At this point we do the placement change only for BOOK3S 64. This would
  * possibly work on other subarchs.
@@ -145,32 +148,23 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr, unsigned long sz
 
addr &= ~(sz-1);
pg = pgd_offset(mm, addr);
-
-   if (pshift == PGDIR_SHIFT)
-   /* 16GB huge page */
-   return (pte_t *) pg;
-   else if (pshift > PUD_SHIFT)
-   /*
-* We need to use hugepd table
-*/
+   if (pshift > PUD_SHIFT) {
hpdp = (hugepd_t *)pg;
-   else {
-   pdshift = PUD_SHIFT;
-   pu = pud_alloc(mm, pg, addr);
-   if (pshift == PUD_SHIFT)
-   return (pte_t *)pu;
-   else if (pshift > PMD_SHIFT)
-   hpdp = (hugepd_t *)pu;
-   else {
-   pdshift = PMD_SHIFT;
-   pm = pmd_alloc(mm, pu, addr);
-   if (pshift == PMD_SHIFT)
-   /* 16MB hugepage */
-   return (pte_t *)pm;
-   else
-   hpdp = (hugepd_t *)pm;
-   }
+   goto hugepd_search;
}
+
+   pdshift = PUD_SHIFT;
+   pu = pud_alloc(mm, pg, addr);
+   if (pshift > PMD_SHIFT) {
+   hpdp = (hugepd_t *)pu;
+   goto hugepd_search;
+   }
+
+   pdshift = PMD_SHIFT;
+   pm = pmd_alloc(mm, pu, addr);
+   hpdp = (hugepd_t *)pm;
+
+hugepd_search:
if (!hpdp)
return NULL;
 
@@ -182,6 +176,31 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long 
addr, unsigned long sz
return hugepte_offset(*hpdp, addr, pdshift);
 }
 
+#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long 
sz)
+{
+   pgd_t *pg;
+   pud_t *pu;
+   pmd_t *pm;
+   unsigned pshift = __ffs(sz);
+
+   addr &= ~(sz-1);
+   pg = pgd_offset(mm, addr);
+
+   if (pshift == PGDIR_SHIFT)  /* 16GB Huge Page */
+   return (pte_t *)pg;
+
+   pu = pud_alloc(mm, pg, addr);   /* NA, skipped */
+   if (pshift == PUD_SHIFT)
+   return (pte_t *)pu;
+
+   pm = pmd_alloc(mm, pu, addr);   /* 16MB Huge Page */
+   if (pshift == PMD_SHIFT)
+   return (pte_t *)pm;
+
+   return NULL;
+}
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 #else
 
 pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long 
sz)
-- 
2.1.0

[PATCH 01/10] mm/mmap: Replace SHM_HUGE_MASK with MAP_HUGE_MASK inside mmap_pgoff

[Anshuman Khandual]

The commit 091d0d55b286 ("shm: fix null pointer deref when userspace
specifies invalid hugepage size") had replaced MAP_HUGE_MASK with
SHM_HUGE_MASK. Though both of them contain the same numeric value of
0x3f, MAP_HUGE_MASK flag sounds more appropriate than the other one
in the context. Hence change it back.

Signed-off-by: Anshuman Khandual 
---
 mm/mmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index bd2e1a53..7d730a4 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1315,7 +1315,7 @@ SYSCALL_DEFINE6(mmap_pgoff, unsigned long, addr, unsigned 
long, len,
struct user_struct *user = NULL;
struct hstate *hs;
 
-   hs = hstate_sizelog((flags >> MAP_HUGE_SHIFT) & SHM_HUGE_MASK);
+   hs = hstate_sizelog((flags >> MAP_HUGE_SHIFT) & MAP_HUGE_MASK);
if (!hs)
return -EINVAL;
 
-- 
2.1.0

[PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race

[Anshuman Khandual]

follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
fetch the page struct during 'follow_page_mask' call. There are possible
race conditions faced by these functions which arise out of simultaneous
calls of move_pages() and freeing of huge pages. This was fixed partly
by the previous commit e66f17ff7177 ("mm/hugetlb: take page table lock
in follow_huge_pmd()") for only PMD based huge pages.

After implementing similar logic, functions like follow_huge_(pud|pgd)
are now safe from above mentioned race conditions and also can support
FOLL_GET. Generic version of the function 'follow_huge_addr' has been
left as it is and its upto the architecture to decide on it.

Signed-off-by: Anshuman Khandual 
---
 include/linux/mm.h | 33 +++
 mm/hugetlb.c   | 67 ++
 2 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ffcff53..734182a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1751,6 +1751,19 @@ static inline void pgtable_page_dtor(struct page *page)
NULL: pte_offset_kernel(pmd, address))
 
 #if USE_SPLIT_PMD_PTLOCKS
+static struct page *pgd_to_page(pgd_t *pgd)
+{
+   unsigned long mask = ~(PTRS_PER_PGD * sizeof(pgd_t) - 1);
+
+   return virt_to_page((void *)((unsigned long) pgd & mask));
+}
+
+static struct page *pud_to_page(pud_t *pud)
+{
+   unsigned long mask = ~(PTRS_PER_PUD * sizeof(pud_t) - 1);
+
+   return virt_to_page((void *)((unsigned long) pud & mask));
+}
 
 static struct page *pmd_to_page(pmd_t *pmd)
 {
@@ -1758,6 +1771,16 @@ static struct page *pmd_to_page(pmd_t *pmd)
return virt_to_page((void *)((unsigned long) pmd & mask));
 }
 
+static inline spinlock_t *pgd_lockptr(struct mm_struct *mm, pgd_t *pgd)
+{
+   return ptlock_ptr(pgd_to_page(pgd));
+}
+
+static inline spinlock_t *pud_lockptr(struct mm_struct *mm, pud_t *pud)
+{
+   return ptlock_ptr(pud_to_page(pud));
+}
+
 static inline spinlock_t *pmd_lockptr(struct mm_struct *mm, pmd_t *pmd)
 {
return ptlock_ptr(pmd_to_page(pmd));
@@ -1783,6 +1806,16 @@ static inline void pgtable_pmd_page_dtor(struct page 
*page)
 
 #else
 
+static inline spinlock_t *pgd_lockptr(struct mm_struct *mm, pgd_t *pgd)
+{
+   return >page_table_lock;
+}
+
+static inline spinlock_t *pud_lockptr(struct mm_struct *mm, pud_t *pud)
+{
+   return >page_table_lock;
+}
+
 static inline spinlock_t *pmd_lockptr(struct mm_struct *mm, pmd_t *pmd)
 {
return >page_table_lock;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5ea3158..e84e479 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4346,21 +4346,70 @@ struct page * __weak
 follow_huge_pud(struct mm_struct *mm, unsigned long address,
pud_t *pud, int flags)
 {
-   if (flags & FOLL_GET)
-   return NULL;
-
-   return pte_page(*(pte_t *)pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT);
+   struct page *page = NULL;
+   spinlock_t *ptl;
+retry:
+   ptl = pud_lockptr(mm, pud);
+   spin_lock(ptl);
+   /*
+* make sure that the address range covered by this pud is not
+* unmapped from other threads.
+*/
+   if (!pud_huge(*pud))
+   goto out;
+   if (pud_present(*pud)) {
+   page = pud_page(*pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT);
+   if (flags & FOLL_GET)
+   get_page(page);
+   } else {
+   if (is_hugetlb_entry_migration(huge_ptep_get((pte_t *)pud))) {
+   spin_unlock(ptl);
+   __migration_entry_wait(mm, (pte_t *)pud, ptl);
+   goto retry;
+   }
+   /*
+* hwpoisoned entry is treated as no_page_table in
+* follow_page_mask().
+*/
+   }
+out:
+   spin_unlock(ptl);
+   return page;
 }
 
 struct page * __weak
 follow_huge_pgd(struct mm_struct *mm, unsigned long address,
pgd_t *pgd, int flags)
 {
-   if (flags & FOLL_GET)
-   return NULL;
-
-   return pte_page(*(pte_t *)pgd) +
-   ((address & ~PGDIR_MASK) >> PAGE_SHIFT);
+   struct page *page = NULL;
+   spinlock_t *ptl;
+retry:
+   ptl = pgd_lockptr(mm, pgd);
+   spin_lock(ptl);
+   /*
+* make sure that the address range covered by this pgd is not
+* unmapped from other threads.
+*/
+   if (!pgd_huge(*pgd))
+   goto out;
+   if (pgd_present(*pgd)) {
+   page = pgd_page(*pgd) + ((address & ~PGDIR_MASK) >> PAGE_SHIFT);
+   if (flags & FOLL_GET)
+   get_page(page);
+   } else {
+   if (is_hugetlb_entry_migration(huge_ptep_get((pte_t *)pgd))) {
+   spin_unlock(ptl);
+   __migration_entry_wait(mm, (pte_t *)pgd, 

[PATCH 08/10] powerpc/hugetlb: Selectively enable ARCH_WANT_GENERAL_HUGETLB

[Anshuman Khandual]

This enables ARCH_WANT_GENERAL_HUGETLB config option only for BOOK3S
platforms with 64K page size implementation. Existing arch specific
functions for ARCH_WANT_GENERAL_HUGETLB config like 'huge_pte_alloc'
and 'huge_pte_offset' are no longer required and are removed with
this change.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/Kconfig  |  4 +++
 arch/powerpc/mm/hugetlbpage.c | 58 ---
 2 files changed, 4 insertions(+), 58 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7cd32c0..9b3ce18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -33,6 +33,10 @@ config HAVE_SETUP_PER_CPU_AREA
 config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool PPC64
 
+config ARCH_WANT_GENERAL_HUGETLB
+   depends on HUGETLB_PAGE && PPC_64K_PAGES && PPC_BOOK3S_64
+   def_bool y
+
 config NR_IRQS
int "Number of virtual interrupt numbers"
range 32 32768
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 4f44c62..bd0e584 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -59,39 +59,6 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long 
addr)
/* Only called for hugetlbfs pages, hence can ignore THP */
return __find_linux_pte_or_hugepte(mm->pgd, addr, NULL, NULL);
 }
-#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
-{
-   pgd_t pgd, *pgdp;
-   pud_t pud, *pudp;
-   pmd_t pmd, *pmdp;
-
-   pgdp = mm->pgd + pgd_index(addr);
-   pgd  = READ_ONCE(*pgdp);
-
-   if (pgd_none(pgd))
-   return NULL;
-
-   if (pgd_huge(pgd))
-   return (pte_t *)pgdp;
-
-   pudp = pud_offset(, addr);
-   pud  = READ_ONCE(*pudp);
-   if (pud_none(pud))
-   return NULL;
-
-   if (pud_huge(pud))
-   return (pte_t *)pudp;
-
-   pmdp = pmd_offset(, addr);
-   pmd  = READ_ONCE(*pmdp);
-   if (pmd_none(pmd))
-   return NULL;
-
-   if (pmd_huge(pmd))
-   return (pte_t *)pmdp;
-   return NULL;
-}
 #endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 
 #ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
@@ -210,31 +177,6 @@ hugepd_search:
 
return hugepte_offset(*hpdp, addr, pdshift);
 }
-
-#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
-pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long 
sz)
-{
-   pgd_t *pg;
-   pud_t *pu;
-   pmd_t *pm;
-   unsigned pshift = __ffs(sz);
-
-   addr &= ~(sz-1);
-   pg = pgd_offset(mm, addr);
-
-   if (pshift == PGDIR_SHIFT)  /* 16GB Huge Page */
-   return (pte_t *)pg;
-
-   pu = pud_alloc(mm, pg, addr);   /* NA, skipped */
-   if (pshift == PUD_SHIFT)
-   return (pte_t *)pu;
-
-   pm = pmd_alloc(mm, pu, addr);   /* 16MB Huge Page */
-   if (pshift == PMD_SHIFT)
-   return (pte_t *)pm;
-
-   return NULL;
-}
 #endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 #else
 
-- 
2.1.0

[PATCH 07/10] powerpc/hugetlb: Prepare arch functions for ARCH_WANT_GENERAL_HUGETLB

[Anshuman Khandual]

Arch override function 'follow_huge_addr' is called from 'follow_page_mask'
looking out for the associated page struct. Right now, it does not support
the FOLL_GET option.

With ARCH_WANTS_GENERAL_HUGETLB, we will need function 'follow_page_mask'
to use generic 'follow_huge_*' functions instead of the arch overrides. So,
here it modifies 'follow_huge_addr' function to return ERR_PTR(-EINVAL)
when ARCH_WANT_GENERAL_HUGETLB option is enabled. This also hides away all
the arch specific 'follow_huge_*' overrides allowing it to fall back on the
generic 'follow_huge_*' functions instead.

While here, this also implements the function 'pte_huge' which is required
by the generic call 'huge_pte_alloc'.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/include/asm/book3s/64/hash-64k.h | 10 ++
 arch/powerpc/mm/hugetlbpage.c | 14 ++
 2 files changed, 24 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h 
b/arch/powerpc/include/asm/book3s/64/hash-64k.h
index 0a7956a..3b6dff4 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -146,6 +146,16 @@ extern bool __rpte_sub_valid(real_pte_t rpte, unsigned 
long index);
  * Defined in such a way that we can optimize away code block at build time
  * if CONFIG_HUGETLB_PAGE=n.
  */
+#ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB
+static inline int pte_huge(pte_t pte)
+{
+   /*
+* leaf pte for huge page
+*/
+   return !!(pte_val(pte) & _PAGE_PTE);
+}
+#endif
+
 static inline int pmd_huge(pmd_t pmd)
 {
/*
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 8fc6d23..4f44c62 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -690,6 +690,10 @@ follow_huge_addr(struct mm_struct *mm, unsigned long 
address, int write)
unsigned long mask, flags;
struct page *page = ERR_PTR(-EINVAL);
 
+#ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB
+   return ERR_PTR(-EINVAL);
+#endif
+
local_irq_save(flags);
ptep = find_linux_pte_or_hugepte(mm->pgd, address, _thp, );
if (!ptep)
@@ -717,6 +721,7 @@ no_page:
return page;
 }
 
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 struct page *
 follow_huge_pmd(struct mm_struct *mm, unsigned long address,
pmd_t *pmd, int write)
@@ -733,6 +738,15 @@ follow_huge_pud(struct mm_struct *mm, unsigned long 
address,
return NULL;
 }
 
+struct page *
+follow_huge_pgd(struct mm_struct *mm, unsigned long address,
+   pgd_t *pgd, int write)
+{
+   BUG();
+   return NULL;
+}
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+
 static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
  unsigned long sz)
 {
-- 
2.1.0

[PATCH 01/10] mm/mmap: Replace SHM_HUGE_MASK with MAP_HUGE_MASK inside mmap_pgoff

[Anshuman Khandual]

The commit 091d0d55b286 ("shm: fix null pointer deref when userspace
specifies invalid hugepage size") had replaced MAP_HUGE_MASK with
SHM_HUGE_MASK. Though both of them contain the same numeric value of
0x3f, MAP_HUGE_MASK flag sounds more appropriate than the other one
in the context. Hence change it back.

Signed-off-by: Anshuman Khandual 
---
 mm/mmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index bd2e1a53..7d730a4 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1315,7 +1315,7 @@ SYSCALL_DEFINE6(mmap_pgoff, unsigned long, addr, unsigned 
long, len,
struct user_struct *user = NULL;
struct hstate *hs;
 
-   hs = hstate_sizelog((flags >> MAP_HUGE_SHIFT) & SHM_HUGE_MASK);
+   hs = hstate_sizelog((flags >> MAP_HUGE_SHIFT) & MAP_HUGE_MASK);
if (!hs)
return -EINVAL;
 
-- 
2.1.0

[PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race

[Anshuman Khandual]

follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
fetch the page struct during 'follow_page_mask' call. There are possible
race conditions faced by these functions which arise out of simultaneous
calls of move_pages() and freeing of huge pages. This was fixed partly
by the previous commit e66f17ff7177 ("mm/hugetlb: take page table lock
in follow_huge_pmd()") for only PMD based huge pages.

After implementing similar logic, functions like follow_huge_(pud|pgd)
are now safe from above mentioned race conditions and also can support
FOLL_GET. Generic version of the function 'follow_huge_addr' has been
left as it is and its upto the architecture to decide on it.

Signed-off-by: Anshuman Khandual 
---
 include/linux/mm.h | 33 +++
 mm/hugetlb.c   | 67 ++
 2 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ffcff53..734182a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1751,6 +1751,19 @@ static inline void pgtable_page_dtor(struct page *page)
NULL: pte_offset_kernel(pmd, address))
 
 #if USE_SPLIT_PMD_PTLOCKS
+static struct page *pgd_to_page(pgd_t *pgd)
+{
+   unsigned long mask = ~(PTRS_PER_PGD * sizeof(pgd_t) - 1);
+
+   return virt_to_page((void *)((unsigned long) pgd & mask));
+}
+
+static struct page *pud_to_page(pud_t *pud)
+{
+   unsigned long mask = ~(PTRS_PER_PUD * sizeof(pud_t) - 1);
+
+   return virt_to_page((void *)((unsigned long) pud & mask));
+}
 
 static struct page *pmd_to_page(pmd_t *pmd)
 {
@@ -1758,6 +1771,16 @@ static struct page *pmd_to_page(pmd_t *pmd)
return virt_to_page((void *)((unsigned long) pmd & mask));
 }
 
+static inline spinlock_t *pgd_lockptr(struct mm_struct *mm, pgd_t *pgd)
+{
+   return ptlock_ptr(pgd_to_page(pgd));
+}
+
+static inline spinlock_t *pud_lockptr(struct mm_struct *mm, pud_t *pud)
+{
+   return ptlock_ptr(pud_to_page(pud));
+}
+
 static inline spinlock_t *pmd_lockptr(struct mm_struct *mm, pmd_t *pmd)
 {
return ptlock_ptr(pmd_to_page(pmd));
@@ -1783,6 +1806,16 @@ static inline void pgtable_pmd_page_dtor(struct page 
*page)
 
 #else
 
+static inline spinlock_t *pgd_lockptr(struct mm_struct *mm, pgd_t *pgd)
+{
+   return >page_table_lock;
+}
+
+static inline spinlock_t *pud_lockptr(struct mm_struct *mm, pud_t *pud)
+{
+   return >page_table_lock;
+}
+
 static inline spinlock_t *pmd_lockptr(struct mm_struct *mm, pmd_t *pmd)
 {
return >page_table_lock;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5ea3158..e84e479 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4346,21 +4346,70 @@ struct page * __weak
 follow_huge_pud(struct mm_struct *mm, unsigned long address,
pud_t *pud, int flags)
 {
-   if (flags & FOLL_GET)
-   return NULL;
-
-   return pte_page(*(pte_t *)pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT);
+   struct page *page = NULL;
+   spinlock_t *ptl;
+retry:
+   ptl = pud_lockptr(mm, pud);
+   spin_lock(ptl);
+   /*
+* make sure that the address range covered by this pud is not
+* unmapped from other threads.
+*/
+   if (!pud_huge(*pud))
+   goto out;
+   if (pud_present(*pud)) {
+   page = pud_page(*pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT);
+   if (flags & FOLL_GET)
+   get_page(page);
+   } else {
+   if (is_hugetlb_entry_migration(huge_ptep_get((pte_t *)pud))) {
+   spin_unlock(ptl);
+   __migration_entry_wait(mm, (pte_t *)pud, ptl);
+   goto retry;
+   }
+   /*
+* hwpoisoned entry is treated as no_page_table in
+* follow_page_mask().
+*/
+   }
+out:
+   spin_unlock(ptl);
+   return page;
 }
 
 struct page * __weak
 follow_huge_pgd(struct mm_struct *mm, unsigned long address,
pgd_t *pgd, int flags)
 {
-   if (flags & FOLL_GET)
-   return NULL;
-
-   return pte_page(*(pte_t *)pgd) +
-   ((address & ~PGDIR_MASK) >> PAGE_SHIFT);
+   struct page *page = NULL;
+   spinlock_t *ptl;
+retry:
+   ptl = pgd_lockptr(mm, pgd);
+   spin_lock(ptl);
+   /*
+* make sure that the address range covered by this pgd is not
+* unmapped from other threads.
+*/
+   if (!pgd_huge(*pgd))
+   goto out;
+   if (pgd_present(*pgd)) {
+   page = pgd_page(*pgd) + ((address & ~PGDIR_MASK) >> PAGE_SHIFT);
+   if (flags & FOLL_GET)
+   get_page(page);
+   } else {
+   if (is_hugetlb_entry_migration(huge_ptep_get((pte_t *)pgd))) {
+   spin_unlock(ptl);
+   __migration_entry_wait(mm, (pte_t *)pgd, ptl);
+   

[PATCH 08/10] powerpc/hugetlb: Selectively enable ARCH_WANT_GENERAL_HUGETLB

[Anshuman Khandual]

This enables ARCH_WANT_GENERAL_HUGETLB config option only for BOOK3S
platforms with 64K page size implementation. Existing arch specific
functions for ARCH_WANT_GENERAL_HUGETLB config like 'huge_pte_alloc'
and 'huge_pte_offset' are no longer required and are removed with
this change.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/Kconfig  |  4 +++
 arch/powerpc/mm/hugetlbpage.c | 58 ---
 2 files changed, 4 insertions(+), 58 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7cd32c0..9b3ce18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -33,6 +33,10 @@ config HAVE_SETUP_PER_CPU_AREA
 config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool PPC64
 
+config ARCH_WANT_GENERAL_HUGETLB
+   depends on HUGETLB_PAGE && PPC_64K_PAGES && PPC_BOOK3S_64
+   def_bool y
+
 config NR_IRQS
int "Number of virtual interrupt numbers"
range 32 32768
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 4f44c62..bd0e584 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -59,39 +59,6 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long 
addr)
/* Only called for hugetlbfs pages, hence can ignore THP */
return __find_linux_pte_or_hugepte(mm->pgd, addr, NULL, NULL);
 }
-#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
-pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
-{
-   pgd_t pgd, *pgdp;
-   pud_t pud, *pudp;
-   pmd_t pmd, *pmdp;
-
-   pgdp = mm->pgd + pgd_index(addr);
-   pgd  = READ_ONCE(*pgdp);
-
-   if (pgd_none(pgd))
-   return NULL;
-
-   if (pgd_huge(pgd))
-   return (pte_t *)pgdp;
-
-   pudp = pud_offset(, addr);
-   pud  = READ_ONCE(*pudp);
-   if (pud_none(pud))
-   return NULL;
-
-   if (pud_huge(pud))
-   return (pte_t *)pudp;
-
-   pmdp = pmd_offset(, addr);
-   pmd  = READ_ONCE(*pmdp);
-   if (pmd_none(pmd))
-   return NULL;
-
-   if (pmd_huge(pmd))
-   return (pte_t *)pmdp;
-   return NULL;
-}
 #endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 
 #ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
@@ -210,31 +177,6 @@ hugepd_search:
 
return hugepte_offset(*hpdp, addr, pdshift);
 }
-
-#else /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
-pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long 
sz)
-{
-   pgd_t *pg;
-   pud_t *pu;
-   pmd_t *pm;
-   unsigned pshift = __ffs(sz);
-
-   addr &= ~(sz-1);
-   pg = pgd_offset(mm, addr);
-
-   if (pshift == PGDIR_SHIFT)  /* 16GB Huge Page */
-   return (pte_t *)pg;
-
-   pu = pud_alloc(mm, pg, addr);   /* NA, skipped */
-   if (pshift == PUD_SHIFT)
-   return (pte_t *)pu;
-
-   pm = pmd_alloc(mm, pu, addr);   /* 16MB Huge Page */
-   if (pshift == PMD_SHIFT)
-   return (pte_t *)pm;
-
-   return NULL;
-}
 #endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
 #else
 
-- 
2.1.0

[PATCH 07/10] powerpc/hugetlb: Prepare arch functions for ARCH_WANT_GENERAL_HUGETLB

[Anshuman Khandual]

Arch override function 'follow_huge_addr' is called from 'follow_page_mask'
looking out for the associated page struct. Right now, it does not support
the FOLL_GET option.

With ARCH_WANTS_GENERAL_HUGETLB, we will need function 'follow_page_mask'
to use generic 'follow_huge_*' functions instead of the arch overrides. So,
here it modifies 'follow_huge_addr' function to return ERR_PTR(-EINVAL)
when ARCH_WANT_GENERAL_HUGETLB option is enabled. This also hides away all
the arch specific 'follow_huge_*' overrides allowing it to fall back on the
generic 'follow_huge_*' functions instead.

While here, this also implements the function 'pte_huge' which is required
by the generic call 'huge_pte_alloc'.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/include/asm/book3s/64/hash-64k.h | 10 ++
 arch/powerpc/mm/hugetlbpage.c | 14 ++
 2 files changed, 24 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h 
b/arch/powerpc/include/asm/book3s/64/hash-64k.h
index 0a7956a..3b6dff4 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -146,6 +146,16 @@ extern bool __rpte_sub_valid(real_pte_t rpte, unsigned 
long index);
  * Defined in such a way that we can optimize away code block at build time
  * if CONFIG_HUGETLB_PAGE=n.
  */
+#ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB
+static inline int pte_huge(pte_t pte)
+{
+   /*
+* leaf pte for huge page
+*/
+   return !!(pte_val(pte) & _PAGE_PTE);
+}
+#endif
+
 static inline int pmd_huge(pmd_t pmd)
 {
/*
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 8fc6d23..4f44c62 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -690,6 +690,10 @@ follow_huge_addr(struct mm_struct *mm, unsigned long 
address, int write)
unsigned long mask, flags;
struct page *page = ERR_PTR(-EINVAL);
 
+#ifdef CONFIG_ARCH_WANT_GENERAL_HUGETLB
+   return ERR_PTR(-EINVAL);
+#endif
+
local_irq_save(flags);
ptep = find_linux_pte_or_hugepte(mm->pgd, address, _thp, );
if (!ptep)
@@ -717,6 +721,7 @@ no_page:
return page;
 }
 
+#ifndef CONFIG_ARCH_WANT_GENERAL_HUGETLB
 struct page *
 follow_huge_pmd(struct mm_struct *mm, unsigned long address,
pmd_t *pmd, int write)
@@ -733,6 +738,15 @@ follow_huge_pud(struct mm_struct *mm, unsigned long 
address,
return NULL;
 }
 
+struct page *
+follow_huge_pgd(struct mm_struct *mm, unsigned long address,
+   pgd_t *pgd, int write)
+{
+   BUG();
+   return NULL;
+}
+#endif /* !CONFIG_ARCH_WANT_GENERAL_HUGETLB */
+
 static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
  unsigned long sz)
 {
-- 
2.1.0

[PATCH 09/10] powerpc/hugetlb: Selectively enable ARCH_ENABLE_HUGEPAGE_MIGRATION

[Anshuman Khandual]

This change enables the config option ARCH_ENABLE_HUGEPAGE_MIGRATION
depending on whether the platform has got ARCH_WANT_GENERAL_HUGETLB
or not along with config option MIGRATION. In turn, it turns on the
'hugepage_migration_supported' function which is checked for feature
presence during HugeTLB page migration and clears the way.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9b3ce18..f2a45eb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -86,6 +86,10 @@ config GENERIC_HWEIGHT
 config ARCH_HAS_DMA_SET_COHERENT_MASK
 bool
 
+config ARCH_ENABLE_HUGEPAGE_MIGRATION
+   def_bool y
+   depends on ARCH_WANT_GENERAL_HUGETLB && MIGRATION
+
 config PPC
bool
default y
-- 
2.1.0

[PATCH 00/10] Enable HugeTLB page migration on POWER

[Anshuman Khandual]

This patch series enables HugeTLB page migration on POWER platform.
This series has some core VM changes (patch 1, 2, 3) and some powerpc
specific changes (patch 4, 5, 6, 7, 8, 9, 10). Comments, suggestions
and inputs are welcome.

Anshuman Khandual (10):
  mm/mmap: Replace SHM_HUGE_MASK with MAP_HUGE_MASK inside mmap_pgoff
  mm/hugetlb: Add PGD based implementation awareness
  mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race
  powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB
  powerpc/hugetlb: Split the function 'huge_pte_alloc'
  powerpc/hugetlb: Split the function 'huge_pte_offset'
  powerpc/hugetlb: Prepare arch functions for ARCH_WANT_GENERAL_HUGETLB
  powerpc/hugetlb: Selectively enable ARCH_WANT_GENERAL_HUGETLB
  powerpc/hugetlb: Selectively enable ARCH_ENABLE_HUGEPAGE_MIGRATION
  selfttest/powerpc: Add memory page migration tests

 arch/powerpc/Kconfig   |   8 +
 arch/powerpc/include/asm/book3s/64/hash-64k.h  |  10 +
 arch/powerpc/include/uapi/asm/mman.h   |   3 +
 arch/powerpc/mm/hugetlbpage.c  |  60 +++---
 include/linux/hugetlb.h|   3 +
 include/linux/mm.h |  33 
 mm/gup.c   |   6 +
 mm/hugetlb.c   |  75 +++-
 mm/mmap.c  |   2 +-
 tools/testing/selftests/powerpc/mm/Makefile|  14 +-
 .../selftests/powerpc/mm/hugepage-migration.c  |  30 +++
 tools/testing/selftests/powerpc/mm/migration.h | 205 +
 .../testing/selftests/powerpc/mm/page-migration.c  |  33 
 tools/testing/selftests/powerpc/mm/run_mmtests | 104 +++
 14 files changed, 552 insertions(+), 34 deletions(-)
 create mode 100644 tools/testing/selftests/powerpc/mm/hugepage-migration.c
 create mode 100644 tools/testing/selftests/powerpc/mm/migration.h
 create mode 100644 tools/testing/selftests/powerpc/mm/page-migration.c
 create mode 100755 tools/testing/selftests/powerpc/mm/run_mmtests

-- 
2.1.0

[PATCH 09/10] powerpc/hugetlb: Selectively enable ARCH_ENABLE_HUGEPAGE_MIGRATION

[Anshuman Khandual]

This change enables the config option ARCH_ENABLE_HUGEPAGE_MIGRATION
depending on whether the platform has got ARCH_WANT_GENERAL_HUGETLB
or not along with config option MIGRATION. In turn, it turns on the
'hugepage_migration_supported' function which is checked for feature
presence during HugeTLB page migration and clears the way.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9b3ce18..f2a45eb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -86,6 +86,10 @@ config GENERIC_HWEIGHT
 config ARCH_HAS_DMA_SET_COHERENT_MASK
 bool
 
+config ARCH_ENABLE_HUGEPAGE_MIGRATION
+   def_bool y
+   depends on ARCH_WANT_GENERAL_HUGETLB && MIGRATION
+
 config PPC
bool
default y
-- 
2.1.0

[PATCH 00/10] Enable HugeTLB page migration on POWER

[Anshuman Khandual]

This patch series enables HugeTLB page migration on POWER platform.
This series has some core VM changes (patch 1, 2, 3) and some powerpc
specific changes (patch 4, 5, 6, 7, 8, 9, 10). Comments, suggestions
and inputs are welcome.

Anshuman Khandual (10):
  mm/mmap: Replace SHM_HUGE_MASK with MAP_HUGE_MASK inside mmap_pgoff
  mm/hugetlb: Add PGD based implementation awareness
  mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race
  powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB
  powerpc/hugetlb: Split the function 'huge_pte_alloc'
  powerpc/hugetlb: Split the function 'huge_pte_offset'
  powerpc/hugetlb: Prepare arch functions for ARCH_WANT_GENERAL_HUGETLB
  powerpc/hugetlb: Selectively enable ARCH_WANT_GENERAL_HUGETLB
  powerpc/hugetlb: Selectively enable ARCH_ENABLE_HUGEPAGE_MIGRATION
  selfttest/powerpc: Add memory page migration tests

 arch/powerpc/Kconfig   |   8 +
 arch/powerpc/include/asm/book3s/64/hash-64k.h  |  10 +
 arch/powerpc/include/uapi/asm/mman.h   |   3 +
 arch/powerpc/mm/hugetlbpage.c  |  60 +++---
 include/linux/hugetlb.h|   3 +
 include/linux/mm.h |  33 
 mm/gup.c   |   6 +
 mm/hugetlb.c   |  75 +++-
 mm/mmap.c  |   2 +-
 tools/testing/selftests/powerpc/mm/Makefile|  14 +-
 .../selftests/powerpc/mm/hugepage-migration.c  |  30 +++
 tools/testing/selftests/powerpc/mm/migration.h | 205 +
 .../testing/selftests/powerpc/mm/page-migration.c  |  33 
 tools/testing/selftests/powerpc/mm/run_mmtests | 104 +++
 14 files changed, 552 insertions(+), 34 deletions(-)
 create mode 100644 tools/testing/selftests/powerpc/mm/hugepage-migration.c
 create mode 100644 tools/testing/selftests/powerpc/mm/migration.h
 create mode 100644 tools/testing/selftests/powerpc/mm/page-migration.c
 create mode 100755 tools/testing/selftests/powerpc/mm/run_mmtests

-- 
2.1.0

Re: [PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

[Marek Szyprowski]

Hello,

On 2016-04-06 22:33, Alison Schofield wrote:

On Wed, Apr 06, 2016 at 09:03:00AM +0200, Marek Szyprowski wrote:

Hello,

On 2016-04-06 07:15, Alison Schofield wrote:

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 

This patch changes the struct device which is used by the driver to report
errors. The driver used correctly the struct device associated with its
device tree node, while after the patch it will use device which is
associated with PMU regmap, which is a different device. PMU regmap is there
only to enable/disable the ADC block and it is not the regmap used to access
registers of the ADC device.

I would prefer to drop this patch.

Thanks Marek!  Please check my understanding.  Driver is not carrying
a duplicate struct device. The regmap in exynos_adc is *not* this
devices regmap. It belongs to the PMU, (power mgmt unit?)


Exactly.


It seemed excessive to carry around a struct device just for the
dev_err messages, but, we need that struct to extract the correct
iio_dev struct. Without a regmap belonging to this actual device,
no efficiencies can be gained in exynos, and the patch will be
dropped from set v2.


Thanks.


Now I need to be able to recognize such cases elsewhere. I'm going
back though other patches in this set looking for that, but I'm not
so sure I would recognize it.

Jonathan & all, Any hints on the rule of regmap?


You may check how the regmap is initialized. When it is retrieved by
phandle from device tree, then you might be almost sure that it refers
to the different device.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

[Marek Szyprowski]

Hello,

On 2016-04-06 22:33, Alison Schofield wrote:

On Wed, Apr 06, 2016 at 09:03:00AM +0200, Marek Szyprowski wrote:

Hello,

On 2016-04-06 07:15, Alison Schofield wrote:

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 

This patch changes the struct device which is used by the driver to report
errors. The driver used correctly the struct device associated with its
device tree node, while after the patch it will use device which is
associated with PMU regmap, which is a different device. PMU regmap is there
only to enable/disable the ADC block and it is not the regmap used to access
registers of the ADC device.

I would prefer to drop this patch.

Thanks Marek!  Please check my understanding.  Driver is not carrying
a duplicate struct device. The regmap in exynos_adc is *not* this
devices regmap. It belongs to the PMU, (power mgmt unit?)


Exactly.


It seemed excessive to carry around a struct device just for the
dev_err messages, but, we need that struct to extract the correct
iio_dev struct. Without a regmap belonging to this actual device,
no efficiencies can be gained in exynos, and the patch will be
dropped from set v2.


Thanks.


Now I need to be able to recognize such cases elsewhere. I'm going
back though other patches in this set looking for that, but I'm not
so sure I would recognize it.

Jonathan & all, Any hints on the rule of regmap?


You may check how the regmap is initialized. When it is retrieved by
phandle from device tree, then you might be almost sure that it refers
to the different device.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

[PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Direct Memory Access (AXI DMA)
core in the existing vdma driver, AXI DMA Core is a
soft Xilinx IP core that provides high-bandwidth
direct memory access between memory and AXI4-Stream
type target peripherals.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart

 drivers/dma/xilinx/xilinx_vdma.c | 474 +++
 include/linux/dma/xilinx_dma.h   |  12 +
 2 files changed, 444 insertions(+), 42 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index b805a11..6ecf731 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -16,6 +16,11 @@
  * video device (S2MM). Initialization, status, interrupt and management
  * registers are accessed through an AXI4-Lite slave interface.
  *
+ * The AXI Direct Memory Access (AXI DMA) core is a soft Xilinx IP core that
+ * provides high-bandwidth one dimensional direct memory access between memory
+ * and AXI4-Stream target peripherals. It supports one receive and one
+ * transmit channel, both of them optional at synthesis time.
+ *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation, either version 2 of the License, or
@@ -140,6 +145,19 @@
 /* Delay loop counter to prevent hardware failure */
 #define XILINX_DMA_LOOP_COUNT  100
 
+/* AXI DMA Specific Registers/Offsets */
+#define XILINX_DMA_REG_SRCDSTADDR  0x18
+#define XILINX_DMA_REG_BTT 0x28
+
+/* AXI DMA Specific Masks/Bit fields */
+#define XILINX_DMA_MAX_TRANS_LEN   GENMASK(22, 0)
+#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
+#define XILINX_DMA_CR_COALESCE_SHIFT   16
+#define XILINX_DMA_BD_SOP  BIT(27)
+#define XILINX_DMA_BD_EOP  BIT(26)
+#define XILINX_DMA_COALESCE_MAX255
+#define XILINX_DMA_NUM_APP_WORDS   5
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -162,6 +180,30 @@ struct xilinx_vdma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_desc_hw - Hardware Descriptor for AXI DMA
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @buf_addr: Buffer address @0x08
+ * @pad2: Reserved @0x0C
+ * @pad3: Reserved @0x10
+ * @pad4: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ * @app: APP Fields @0x20 - 0x30
+ */
+struct xilinx_axidma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 buf_addr;
+   u32 pad2;
+   u32 pad3;
+   u32 pad4;
+   u32 control;
+   u32 status;
+   u32 app[XILINX_DMA_NUM_APP_WORDS];
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -174,6 +216,18 @@ struct xilinx_vdma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_axidma_tx_segment {
+   struct xilinx_axidma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -210,6 +264,9 @@ struct xilinx_dma_tx_descriptor {
  * @desc_pendingcount: Descriptor pending count
  * @ext_addr: Indicates 64 bit addressing is supported by dma channel
  * @desc_submitcount: Descriptor h/w submitted count
+ * @residue: Residue for AXI DMA
+ * @seg_v: Statically allocated segments base
+ * @start_transfer: Differentiate b/w DMA IP's transfer
  */
 struct xilinx_dma_chan {
struct xilinx_dma_device *xdev;
@@ -235,6 +292,9 @@ struct xilinx_dma_chan {
u32 desc_pendingcount;
bool ext_addr;
u32 desc_submitcount;
+   u32 residue;
+   struct xilinx_axidma_tx_segment *seg_v;
+   void (*start_transfer)(struct xilinx_dma_chan *chan);
 };
 
 /**
@@ -246,6 +306,7 @@ struct xilinx_dma_chan {
  * @has_sg: Specifies whether Scatter-Gather is present or not
  * @flush_on_fsync: Flush on frame sync
  * @ext_addr: Indicates 64 bit addressing is supported by dma device
+ * @dmatype: DMA ip type
  */
 struct xilinx_dma_device {
void __iomem *regs;
@@ -255,6 +316,7 @@ struct xilinx_dma_device {
bool has_sg;
u32 flush_on_fsync;
bool ext_addr;
+   enum xdma_ip_type dmatype;
 };
 
 /* Macros */
@@ -354,6 +416,39 @@ xilinx_vdma_alloc_tx_segment(struct 

[PATCH v4 4/5] Documentation: DT: vdma: update binding doc for AXI CDMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI CDMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> Removed CDMA DT example from the patch as suggested by the Rob.
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index 3fb23fe..fcc2b65 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,8 +8,12 @@ target devices. It can be configured to have one channel or 
two channels.
 If configured as two channels, one is to transmit to the device and another
 is to receive from the device.
 
+Xilinx AXI CDMA engine, it does transfers between memory-mapped source
+address and a memory-mapped destination address.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a" or
+ "xlnx,axi-cdma-1.00.a""
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
-- 
2.1.2

[PATCH v4 2/5] Documentation: DT: vdma: update binding doc for AXI DMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI DMA.
Also this patch differentiates required properties b/w
DMA and VDMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> Removed AXI DMA DT example from the patch as suggested by Rob.
---> Differentiated required/optional properties for each DMA's
 as suggested by Rob.
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt  | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index a86737c..3fb23fe 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -3,20 +3,28 @@ It can be configured to have one channel or two channels. If 
configured
 as two channels, one is to transmit to the video device and another is
 to receive from the video device.
 
+Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
+target devices. It can be configured to have one channel or two channels.
+If configured as two channels, one is to transmit to the device and another
+is to receive from the device.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
-- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
 - xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
 - dma-ranges: Should be as the following .
 - dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
 
+Required properties for VDMA:
+- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
+
 Optional properties:
 - xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+Optional properties for VDMA:
 - xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
{1}, flush both channels
@@ -33,6 +41,7 @@ Required child node properties:
 Optional child node properties:
 - xlnx,include-dre: Tells hardware is configured for Data
Realignment Engine.
+Optional child node properties for VDMA:
 - xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
 
-- 
2.1.2

[PATCH v4 2/5] Documentation: DT: vdma: update binding doc for AXI DMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI DMA.
Also this patch differentiates required properties b/w
DMA and VDMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> Removed AXI DMA DT example from the patch as suggested by Rob.
---> Differentiated required/optional properties for each DMA's
 as suggested by Rob.
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt  | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index a86737c..3fb23fe 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -3,20 +3,28 @@ It can be configured to have one channel or two channels. If 
configured
 as two channels, one is to transmit to the video device and another is
 to receive from the video device.
 
+Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
+target devices. It can be configured to have one channel or two channels.
+If configured as two channels, one is to transmit to the device and another
+is to receive from the device.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
-- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
 - xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
 - dma-ranges: Should be as the following .
 - dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
 
+Required properties for VDMA:
+- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
+
 Optional properties:
 - xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+Optional properties for VDMA:
 - xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
{1}, flush both channels
@@ -33,6 +41,7 @@ Required child node properties:
 Optional child node properties:
 - xlnx,include-dre: Tells hardware is configured for Data
Realignment Engine.
+Optional child node properties for VDMA:
 - xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
 
-- 
2.1.2

[PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Direct Memory Access (AXI DMA)
core in the existing vdma driver, AXI DMA Core is a
soft Xilinx IP core that provides high-bandwidth
direct memory access between memory and AXI4-Stream
type target peripherals.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart

 drivers/dma/xilinx/xilinx_vdma.c | 474 +++
 include/linux/dma/xilinx_dma.h   |  12 +
 2 files changed, 444 insertions(+), 42 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index b805a11..6ecf731 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -16,6 +16,11 @@
  * video device (S2MM). Initialization, status, interrupt and management
  * registers are accessed through an AXI4-Lite slave interface.
  *
+ * The AXI Direct Memory Access (AXI DMA) core is a soft Xilinx IP core that
+ * provides high-bandwidth one dimensional direct memory access between memory
+ * and AXI4-Stream target peripherals. It supports one receive and one
+ * transmit channel, both of them optional at synthesis time.
+ *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation, either version 2 of the License, or
@@ -140,6 +145,19 @@
 /* Delay loop counter to prevent hardware failure */
 #define XILINX_DMA_LOOP_COUNT  100
 
+/* AXI DMA Specific Registers/Offsets */
+#define XILINX_DMA_REG_SRCDSTADDR  0x18
+#define XILINX_DMA_REG_BTT 0x28
+
+/* AXI DMA Specific Masks/Bit fields */
+#define XILINX_DMA_MAX_TRANS_LEN   GENMASK(22, 0)
+#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
+#define XILINX_DMA_CR_COALESCE_SHIFT   16
+#define XILINX_DMA_BD_SOP  BIT(27)
+#define XILINX_DMA_BD_EOP  BIT(26)
+#define XILINX_DMA_COALESCE_MAX255
+#define XILINX_DMA_NUM_APP_WORDS   5
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -162,6 +180,30 @@ struct xilinx_vdma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_desc_hw - Hardware Descriptor for AXI DMA
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @buf_addr: Buffer address @0x08
+ * @pad2: Reserved @0x0C
+ * @pad3: Reserved @0x10
+ * @pad4: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ * @app: APP Fields @0x20 - 0x30
+ */
+struct xilinx_axidma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 buf_addr;
+   u32 pad2;
+   u32 pad3;
+   u32 pad4;
+   u32 control;
+   u32 status;
+   u32 app[XILINX_DMA_NUM_APP_WORDS];
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -174,6 +216,18 @@ struct xilinx_vdma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_axidma_tx_segment {
+   struct xilinx_axidma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -210,6 +264,9 @@ struct xilinx_dma_tx_descriptor {
  * @desc_pendingcount: Descriptor pending count
  * @ext_addr: Indicates 64 bit addressing is supported by dma channel
  * @desc_submitcount: Descriptor h/w submitted count
+ * @residue: Residue for AXI DMA
+ * @seg_v: Statically allocated segments base
+ * @start_transfer: Differentiate b/w DMA IP's transfer
  */
 struct xilinx_dma_chan {
struct xilinx_dma_device *xdev;
@@ -235,6 +292,9 @@ struct xilinx_dma_chan {
u32 desc_pendingcount;
bool ext_addr;
u32 desc_submitcount;
+   u32 residue;
+   struct xilinx_axidma_tx_segment *seg_v;
+   void (*start_transfer)(struct xilinx_dma_chan *chan);
 };
 
 /**
@@ -246,6 +306,7 @@ struct xilinx_dma_chan {
  * @has_sg: Specifies whether Scatter-Gather is present or not
  * @flush_on_fsync: Flush on frame sync
  * @ext_addr: Indicates 64 bit addressing is supported by dma device
+ * @dmatype: DMA ip type
  */
 struct xilinx_dma_device {
void __iomem *regs;
@@ -255,6 +316,7 @@ struct xilinx_dma_device {
bool has_sg;
u32 flush_on_fsync;
bool ext_addr;
+   enum xdma_ip_type dmatype;
 };
 
 /* Macros */
@@ -354,6 +416,39 @@ xilinx_vdma_alloc_tx_segment(struct xilinx_dma_chan 

[PATCH v4 4/5] Documentation: DT: vdma: update binding doc for AXI CDMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI CDMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> Removed CDMA DT example from the patch as suggested by the Rob.
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index 3fb23fe..fcc2b65 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,8 +8,12 @@ target devices. It can be configured to have one channel or 
two channels.
 If configured as two channels, one is to transmit to the device and another
 is to receive from the device.
 
+Xilinx AXI CDMA engine, it does transfers between memory-mapped source
+address and a memory-mapped destination address.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a" or
+ "xlnx,axi-cdma-1.00.a""
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
-- 
2.1.2

[PATCH v4 0/5] dmaengine: vdma: AXI DMA's enhancments

[Kedareswara rao Appana]

This patch series does some enhancments to the VDMA driver
which includes
--> Adding support for AXI DMA IP.
--> Adding support for AXI CDMA IP.

Kedareswara rao Appana (5):
  dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma
  Documentation: DT: vdma: update binding doc for AXI DMA
  dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access
Engine
  Documentation: DT: vdma: update binding doc for AXI CDMA
  dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory
Access Engine

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |   17 +-
 drivers/dma/xilinx/xilinx_vdma.c   | 1326 ++--
 include/linux/dma/xilinx_dma.h |   14 +
 3 files changed, 1003 insertions(+), 354 deletions(-)

-- 
2.1.2

[PATCH v4 0/5] dmaengine: vdma: AXI DMA's enhancments

[Kedareswara rao Appana]

This patch series does some enhancments to the VDMA driver
which includes
--> Adding support for AXI DMA IP.
--> Adding support for AXI CDMA IP.

Kedareswara rao Appana (5):
  dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma
  Documentation: DT: vdma: update binding doc for AXI DMA
  dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access
Engine
  Documentation: DT: vdma: update binding doc for AXI CDMA
  dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory
Access Engine

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |   17 +-
 drivers/dma/xilinx/xilinx_vdma.c   | 1326 ++--
 include/linux/dma/xilinx_dma.h |   14 +
 3 files changed, 1003 insertions(+), 354 deletions(-)

-- 
2.1.2

[PATCH v4 5/5] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Central Direct Memory Access
(AXI CDMA) core to the existing vdma driver, AXI CDMA is a
soft Xilinx IP core that provides high-bandwidth
Direct Memory Access(DMA) between a memory-mapped
source address and a memory-mapped destination address.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 236 ++-
 include/linux/dma/xilinx_dma.h   |   2 +
 2 files changed, 236 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 6ecf731..ac1566b 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -21,6 +21,10 @@
  * and AXI4-Stream target peripherals. It supports one receive and one
  * transmit channel, both of them optional at synthesis time.
  *
+ * The AXI CDMA, is a soft IP, which provides high-bandwidth Direct Memory
+ * Access (DMA) between a memory-mapped source address and a memory-mapped
+ * destination address.
+ *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation, either version 2 of the License, or
@@ -158,6 +162,13 @@
 #define XILINX_DMA_COALESCE_MAX255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
+/* AXI CDMA Specific Registers/Offsets */
+#define XILINX_CDMA_REG_SRCADDR0x18
+#define XILINX_CDMA_REG_DSTADDR0x20
+
+/* AXI CDMA Specific Masks */
+#define XILINX_CDMA_CR_SGMODE  BIT(3)
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -204,6 +215,28 @@ struct xilinx_axidma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_desc_hw - Hardware Descriptor
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @src_addr: Source address @0x08
+ * @pad2: Reserved @0x0C
+ * @dest_addr: Destination address @0x10
+ * @pad3: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ */
+struct xilinx_cdma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 src_addr;
+   u32 pad2;
+   u32 dest_addr;
+   u32 pad3;
+   u32 control;
+   u32 status;
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -228,6 +261,18 @@ struct xilinx_axidma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_cdma_tx_segment {
+   struct xilinx_cdma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -416,6 +461,28 @@ xilinx_vdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 }
 
 /**
+ * xilinx_cdma_alloc_tx_segment - Allocate transaction segment
+ * @chan: Driver specific DMA channel
+ *
+ * Return: The allocated segment on success and NULL on failure.
+ */
+static struct xilinx_cdma_tx_segment *
+xilinx_cdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
+{
+   struct xilinx_cdma_tx_segment *segment;
+   dma_addr_t phys;
+
+   segment = dma_pool_alloc(chan->desc_pool, GFP_ATOMIC, );
+   if (!segment)
+   return NULL;
+
+   memset(segment, 0, sizeof(*segment));
+   segment->phys = phys;
+
+   return segment;
+}
+
+/**
  * xilinx_axidma_alloc_tx_segment - Allocate transaction segment
  * @chan: Driver specific DMA channel
  *
@@ -449,6 +516,17 @@ static void xilinx_dma_free_tx_segment(struct 
xilinx_dma_chan *chan,
 }
 
 /**
+ * xilinx_cdma_free_tx_segment - Free transaction segment
+ * @chan: Driver specific DMA channel
+ * @segment: DMA transaction segment
+ */
+static void xilinx_cdma_free_tx_segment(struct xilinx_dma_chan *chan,
+   struct xilinx_cdma_tx_segment *segment)
+{
+   dma_pool_free(chan->desc_pool, segment, segment->phys);
+}
+
+/**
  * xilinx_vdma_free_tx_segment - Free transaction segment
  * @chan: Driver specific DMA channel
  * @segment: DMA transaction segment
@@ -489,6 +567,7 @@ xilinx_dma_free_tx_descriptor(struct xilinx_dma_chan *chan,
   struct xilinx_dma_tx_descriptor *desc)
 {
struct xilinx_vdma_tx_segment *segment, *next;
+   struct xilinx_cdma_tx_segment *cdma_segment, *cdma_next;
struct xilinx_axidma_tx_segment 

[PATCH v4 5/5] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Central Direct Memory Access
(AXI CDMA) core to the existing vdma driver, AXI CDMA is a
soft Xilinx IP core that provides high-bandwidth
Direct Memory Access(DMA) between a memory-mapped
source address and a memory-mapped destination address.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 236 ++-
 include/linux/dma/xilinx_dma.h   |   2 +
 2 files changed, 236 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 6ecf731..ac1566b 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -21,6 +21,10 @@
  * and AXI4-Stream target peripherals. It supports one receive and one
  * transmit channel, both of them optional at synthesis time.
  *
+ * The AXI CDMA, is a soft IP, which provides high-bandwidth Direct Memory
+ * Access (DMA) between a memory-mapped source address and a memory-mapped
+ * destination address.
+ *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation, either version 2 of the License, or
@@ -158,6 +162,13 @@
 #define XILINX_DMA_COALESCE_MAX255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
+/* AXI CDMA Specific Registers/Offsets */
+#define XILINX_CDMA_REG_SRCADDR0x18
+#define XILINX_CDMA_REG_DSTADDR0x20
+
+/* AXI CDMA Specific Masks */
+#define XILINX_CDMA_CR_SGMODE  BIT(3)
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -204,6 +215,28 @@ struct xilinx_axidma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_desc_hw - Hardware Descriptor
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @src_addr: Source address @0x08
+ * @pad2: Reserved @0x0C
+ * @dest_addr: Destination address @0x10
+ * @pad3: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ */
+struct xilinx_cdma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 src_addr;
+   u32 pad2;
+   u32 dest_addr;
+   u32 pad3;
+   u32 control;
+   u32 status;
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -228,6 +261,18 @@ struct xilinx_axidma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_cdma_tx_segment {
+   struct xilinx_cdma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -416,6 +461,28 @@ xilinx_vdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 }
 
 /**
+ * xilinx_cdma_alloc_tx_segment - Allocate transaction segment
+ * @chan: Driver specific DMA channel
+ *
+ * Return: The allocated segment on success and NULL on failure.
+ */
+static struct xilinx_cdma_tx_segment *
+xilinx_cdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
+{
+   struct xilinx_cdma_tx_segment *segment;
+   dma_addr_t phys;
+
+   segment = dma_pool_alloc(chan->desc_pool, GFP_ATOMIC, );
+   if (!segment)
+   return NULL;
+
+   memset(segment, 0, sizeof(*segment));
+   segment->phys = phys;
+
+   return segment;
+}
+
+/**
  * xilinx_axidma_alloc_tx_segment - Allocate transaction segment
  * @chan: Driver specific DMA channel
  *
@@ -449,6 +516,17 @@ static void xilinx_dma_free_tx_segment(struct 
xilinx_dma_chan *chan,
 }
 
 /**
+ * xilinx_cdma_free_tx_segment - Free transaction segment
+ * @chan: Driver specific DMA channel
+ * @segment: DMA transaction segment
+ */
+static void xilinx_cdma_free_tx_segment(struct xilinx_dma_chan *chan,
+   struct xilinx_cdma_tx_segment *segment)
+{
+   dma_pool_free(chan->desc_pool, segment, segment->phys);
+}
+
+/**
  * xilinx_vdma_free_tx_segment - Free transaction segment
  * @chan: Driver specific DMA channel
  * @segment: DMA transaction segment
@@ -489,6 +567,7 @@ xilinx_dma_free_tx_descriptor(struct xilinx_dma_chan *chan,
   struct xilinx_dma_tx_descriptor *desc)
 {
struct xilinx_vdma_tx_segment *segment, *next;
+   struct xilinx_cdma_tx_segment *cdma_segment, *cdma_next;
struct xilinx_axidma_tx_segment *axidma_segment, 

[PATCH v4 1/5] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

[Kedareswara rao Appana]

This patch renames the xilinx_vdma_ prefix to xilinx_dma
for the API's and masks that will be shared b/w three DMA
IP cores.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
> Removed renaming of vdma-mm2s/vdma-s2mm channel names.
Changes for v3:
---> None.
Changes for v2:
---> New patch as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 632 +++
 1 file changed, 316 insertions(+), 316 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 3c5ce37..b805a11 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -39,106 +39,106 @@
 #include "../dmaengine.h"
 
 /* Register/Descriptor Offsets */
-#define XILINX_VDMA_MM2S_CTRL_OFFSET   0x
-#define XILINX_VDMA_S2MM_CTRL_OFFSET   0x0030
+#define XILINX_DMA_MM2S_CTRL_OFFSET0x
+#define XILINX_DMA_S2MM_CTRL_OFFSET0x0030
 #define XILINX_VDMA_MM2S_DESC_OFFSET   0x0050
 #define XILINX_VDMA_S2MM_DESC_OFFSET   0x00a0
 
 /* Control Registers */
-#define XILINX_VDMA_REG_DMACR  0x
-#define XILINX_VDMA_DMACR_DELAY_MAX0xff
-#define XILINX_VDMA_DMACR_DELAY_SHIFT  24
-#define XILINX_VDMA_DMACR_FRAME_COUNT_MAX  0xff
-#define XILINX_VDMA_DMACR_FRAME_COUNT_SHIFT16
-#define XILINX_VDMA_DMACR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMACR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMACR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMACR_MASTER_SHIFT 8
-#define XILINX_VDMA_DMACR_FSYNCSRC_SHIFT   5
-#define XILINX_VDMA_DMACR_FRAMECNT_EN  BIT(4)
-#define XILINX_VDMA_DMACR_GENLOCK_EN   BIT(3)
-#define XILINX_VDMA_DMACR_RESETBIT(2)
-#define XILINX_VDMA_DMACR_CIRC_EN  BIT(1)
-#define XILINX_VDMA_DMACR_RUNSTOP  BIT(0)
-#define XILINX_VDMA_DMACR_FSYNCSRC_MASKGENMASK(6, 5)
-
-#define XILINX_VDMA_REG_DMASR  0x0004
-#define XILINX_VDMA_DMASR_EOL_LATE_ERR BIT(15)
-#define XILINX_VDMA_DMASR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMASR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMASR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMASR_SOF_LATE_ERR BIT(11)
-#define XILINX_VDMA_DMASR_SG_DEC_ERR   BIT(10)
-#define XILINX_VDMA_DMASR_SG_SLV_ERR   BIT(9)
-#define XILINX_VDMA_DMASR_EOF_EARLY_ERRBIT(8)
-#define XILINX_VDMA_DMASR_SOF_EARLY_ERRBIT(7)
-#define XILINX_VDMA_DMASR_DMA_DEC_ERR  BIT(6)
-#define XILINX_VDMA_DMASR_DMA_SLAVE_ERRBIT(5)
-#define XILINX_VDMA_DMASR_DMA_INT_ERR  BIT(4)
-#define XILINX_VDMA_DMASR_IDLE BIT(1)
-#define XILINX_VDMA_DMASR_HALTED   BIT(0)
-#define XILINX_VDMA_DMASR_DELAY_MASK   GENMASK(31, 24)
-#define XILINX_VDMA_DMASR_FRAME_COUNT_MASK GENMASK(23, 16)
-
-#define XILINX_VDMA_REG_CURDESC0x0008
-#define XILINX_VDMA_REG_TAILDESC   0x0010
-#define XILINX_VDMA_REG_REG_INDEX  0x0014
-#define XILINX_VDMA_REG_FRMSTORE   0x0018
-#define XILINX_VDMA_REG_THRESHOLD  0x001c
-#define XILINX_VDMA_REG_FRMPTR_STS 0x0024
-#define XILINX_VDMA_REG_PARK_PTR   0x0028
-#define XILINX_VDMA_PARK_PTR_WR_REF_SHIFT  8
-#define XILINX_VDMA_PARK_PTR_RD_REF_SHIFT  0
-#define XILINX_VDMA_REG_VDMA_VERSION   0x002c
+#define XILINX_DMA_REG_DMACR   0x
+#define XILINX_DMA_DMACR_DELAY_MAX 0xff
+#define XILINX_DMA_DMACR_DELAY_SHIFT   24
+#define XILINX_DMA_DMACR_FRAME_COUNT_MAX   0xff
+#define XILINX_DMA_DMACR_FRAME_COUNT_SHIFT 16
+#define XILINX_DMA_DMACR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMACR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMACR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMACR_MASTER_SHIFT  8
+#define XILINX_DMA_DMACR_FSYNCSRC_SHIFT5
+#define XILINX_DMA_DMACR_FRAMECNT_EN   BIT(4)
+#define XILINX_DMA_DMACR_GENLOCK_ENBIT(3)
+#define XILINX_DMA_DMACR_RESET BIT(2)
+#define XILINX_DMA_DMACR_CIRC_EN   BIT(1)
+#define XILINX_DMA_DMACR_RUNSTOP   BIT(0)
+#define XILINX_DMA_DMACR_FSYNCSRC_MASK GENMASK(6, 5)
+
+#define XILINX_DMA_REG_DMASR   0x0004
+#define XILINX_DMA_DMASR_EOL_LATE_ERR  BIT(15)
+#define XILINX_DMA_DMASR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMASR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMASR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMASR_SOF_LATE_ERR  BIT(11)
+#define XILINX_DMA_DMASR_SG_DEC_ERRBIT(10)
+#define XILINX_DMA_DMASR_SG_SLV_ERRBIT(9)
+#define XILINX_DMA_DMASR_EOF_EARLY_ERR BIT(8)
+#define XILINX_DMA_DMASR_SOF_EARLY_ERR BIT(7)
+#define 

[PATCH v4 1/5] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

[Kedareswara rao Appana]

This patch renames the xilinx_vdma_ prefix to xilinx_dma
for the API's and masks that will be shared b/w three DMA
IP cores.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v4:
> Removed renaming of vdma-mm2s/vdma-s2mm channel names.
Changes for v3:
---> None.
Changes for v2:
---> New patch as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 632 +++
 1 file changed, 316 insertions(+), 316 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 3c5ce37..b805a11 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -39,106 +39,106 @@
 #include "../dmaengine.h"
 
 /* Register/Descriptor Offsets */
-#define XILINX_VDMA_MM2S_CTRL_OFFSET   0x
-#define XILINX_VDMA_S2MM_CTRL_OFFSET   0x0030
+#define XILINX_DMA_MM2S_CTRL_OFFSET0x
+#define XILINX_DMA_S2MM_CTRL_OFFSET0x0030
 #define XILINX_VDMA_MM2S_DESC_OFFSET   0x0050
 #define XILINX_VDMA_S2MM_DESC_OFFSET   0x00a0
 
 /* Control Registers */
-#define XILINX_VDMA_REG_DMACR  0x
-#define XILINX_VDMA_DMACR_DELAY_MAX0xff
-#define XILINX_VDMA_DMACR_DELAY_SHIFT  24
-#define XILINX_VDMA_DMACR_FRAME_COUNT_MAX  0xff
-#define XILINX_VDMA_DMACR_FRAME_COUNT_SHIFT16
-#define XILINX_VDMA_DMACR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMACR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMACR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMACR_MASTER_SHIFT 8
-#define XILINX_VDMA_DMACR_FSYNCSRC_SHIFT   5
-#define XILINX_VDMA_DMACR_FRAMECNT_EN  BIT(4)
-#define XILINX_VDMA_DMACR_GENLOCK_EN   BIT(3)
-#define XILINX_VDMA_DMACR_RESETBIT(2)
-#define XILINX_VDMA_DMACR_CIRC_EN  BIT(1)
-#define XILINX_VDMA_DMACR_RUNSTOP  BIT(0)
-#define XILINX_VDMA_DMACR_FSYNCSRC_MASKGENMASK(6, 5)
-
-#define XILINX_VDMA_REG_DMASR  0x0004
-#define XILINX_VDMA_DMASR_EOL_LATE_ERR BIT(15)
-#define XILINX_VDMA_DMASR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMASR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMASR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMASR_SOF_LATE_ERR BIT(11)
-#define XILINX_VDMA_DMASR_SG_DEC_ERR   BIT(10)
-#define XILINX_VDMA_DMASR_SG_SLV_ERR   BIT(9)
-#define XILINX_VDMA_DMASR_EOF_EARLY_ERRBIT(8)
-#define XILINX_VDMA_DMASR_SOF_EARLY_ERRBIT(7)
-#define XILINX_VDMA_DMASR_DMA_DEC_ERR  BIT(6)
-#define XILINX_VDMA_DMASR_DMA_SLAVE_ERRBIT(5)
-#define XILINX_VDMA_DMASR_DMA_INT_ERR  BIT(4)
-#define XILINX_VDMA_DMASR_IDLE BIT(1)
-#define XILINX_VDMA_DMASR_HALTED   BIT(0)
-#define XILINX_VDMA_DMASR_DELAY_MASK   GENMASK(31, 24)
-#define XILINX_VDMA_DMASR_FRAME_COUNT_MASK GENMASK(23, 16)
-
-#define XILINX_VDMA_REG_CURDESC0x0008
-#define XILINX_VDMA_REG_TAILDESC   0x0010
-#define XILINX_VDMA_REG_REG_INDEX  0x0014
-#define XILINX_VDMA_REG_FRMSTORE   0x0018
-#define XILINX_VDMA_REG_THRESHOLD  0x001c
-#define XILINX_VDMA_REG_FRMPTR_STS 0x0024
-#define XILINX_VDMA_REG_PARK_PTR   0x0028
-#define XILINX_VDMA_PARK_PTR_WR_REF_SHIFT  8
-#define XILINX_VDMA_PARK_PTR_RD_REF_SHIFT  0
-#define XILINX_VDMA_REG_VDMA_VERSION   0x002c
+#define XILINX_DMA_REG_DMACR   0x
+#define XILINX_DMA_DMACR_DELAY_MAX 0xff
+#define XILINX_DMA_DMACR_DELAY_SHIFT   24
+#define XILINX_DMA_DMACR_FRAME_COUNT_MAX   0xff
+#define XILINX_DMA_DMACR_FRAME_COUNT_SHIFT 16
+#define XILINX_DMA_DMACR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMACR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMACR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMACR_MASTER_SHIFT  8
+#define XILINX_DMA_DMACR_FSYNCSRC_SHIFT5
+#define XILINX_DMA_DMACR_FRAMECNT_EN   BIT(4)
+#define XILINX_DMA_DMACR_GENLOCK_ENBIT(3)
+#define XILINX_DMA_DMACR_RESET BIT(2)
+#define XILINX_DMA_DMACR_CIRC_EN   BIT(1)
+#define XILINX_DMA_DMACR_RUNSTOP   BIT(0)
+#define XILINX_DMA_DMACR_FSYNCSRC_MASK GENMASK(6, 5)
+
+#define XILINX_DMA_REG_DMASR   0x0004
+#define XILINX_DMA_DMASR_EOL_LATE_ERR  BIT(15)
+#define XILINX_DMA_DMASR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMASR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMASR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMASR_SOF_LATE_ERR  BIT(11)
+#define XILINX_DMA_DMASR_SG_DEC_ERRBIT(10)
+#define XILINX_DMA_DMASR_SG_SLV_ERRBIT(9)
+#define XILINX_DMA_DMASR_EOF_EARLY_ERR BIT(8)
+#define XILINX_DMA_DMASR_SOF_EARLY_ERR BIT(7)
+#define XILINX_DMA_DMASR_DMA_DEC_ERR   

linux-next: Tree for Apr 7

[Stephen Rothwell]

Hi all,

Changes since 20160406:

The akpm-current tree gained a build failure for which I applied a patch.

Non-merge commits (relative to Linus' tree): 2722
 2566 files changed, 106575 insertions(+), 66077 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c4004b02f8e5 x86: remove the kernel code/data/bss 
resources from /proc/iomem)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (b5cd46412eaa Revert "ARC: [plat-axs10x] add 
Ethernet PHY description in .dts")
Merging arm-current/fixes (0fc03d4c8761 ARM: SMP enable of cache maintanence 
broadcast)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (0a1a37b6d62e net: add the AF_KCM entries to family name 
tables)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (b4201cc4fc6e mac80211: fix "warning: ‘target_metric’ 
may be used uninitialized")
Merging sound-current/for-linus (f03b24a851d3 ALSA: usb-audio: Add a sample 
rate quirk for Phoenix Audio TMX320)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (5e00bbfbc5ec tty: Fix merge of "tty: Refactor 
tty_open()")
Merging usb.current/usb-linus (5a07975ad0a3 USB: digi_acceleport: do sanity 
checking for the number of ports)
Merging usb-gadget-fixes/fixes (adf9a3ab90eb usb: dwc3: keystone: drop dma_mask 
configuration)
Merging usb-serial-fixes/usb-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (53c43c5ca133 Revert "Staging: olpc_dcon: 
Remove obsolete driver")
Merging char-misc.current/char-misc-linus (1bb025f6db78 Merge tag 
'extcon-fixes-for-4.6-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus

linux-next: Tree for Apr 7

[Stephen Rothwell]

Hi all,

Changes since 20160406:

The akpm-current tree gained a build failure for which I applied a patch.

Non-merge commits (relative to Linus' tree): 2722
 2566 files changed, 106575 insertions(+), 66077 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c4004b02f8e5 x86: remove the kernel code/data/bss 
resources from /proc/iomem)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (b5cd46412eaa Revert "ARC: [plat-axs10x] add 
Ethernet PHY description in .dts")
Merging arm-current/fixes (0fc03d4c8761 ARM: SMP enable of cache maintanence 
broadcast)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (0a1a37b6d62e net: add the AF_KCM entries to family name 
tables)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (b4201cc4fc6e mac80211: fix "warning: ‘target_metric’ 
may be used uninitialized")
Merging sound-current/for-linus (f03b24a851d3 ALSA: usb-audio: Add a sample 
rate quirk for Phoenix Audio TMX320)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (5e00bbfbc5ec tty: Fix merge of "tty: Refactor 
tty_open()")
Merging usb.current/usb-linus (5a07975ad0a3 USB: digi_acceleport: do sanity 
checking for the number of ports)
Merging usb-gadget-fixes/fixes (adf9a3ab90eb usb: dwc3: keystone: drop dma_mask 
configuration)
Merging usb-serial-fixes/usb-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (53c43c5ca133 Revert "Staging: olpc_dcon: 
Remove obsolete driver")
Merging char-misc.current/char-misc-linus (1bb025f6db78 Merge tag 
'extcon-fixes-for-4.6-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus

bindat/connectat syscalls

[Daurnimator]

Related thread (2012): https://marc.info/?l=linux-netdev=133897212713981=2

FreeBSD[1] chose signatures of:
int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen);
int connectat(int fd, int s, const struct sockaddr *name,
socklen_t namelen);

An alternate implementation could instead augment `sockaddr_un`.

Also, if we're going to add a new bind and connect() syscalls, we
should also add a flags argument.

(Please CC on reply)

[1] https://www.freebsd.org/cgi/man.cgi?query=bindat=2
https://www.freebsd.org/cgi/man.cgi?query=connectat=2

bindat/connectat syscalls

[Daurnimator]

Related thread (2012): https://marc.info/?l=linux-netdev=133897212713981=2

FreeBSD[1] chose signatures of:
int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen);
int connectat(int fd, int s, const struct sockaddr *name,
socklen_t namelen);

An alternate implementation could instead augment `sockaddr_un`.

Also, if we're going to add a new bind and connect() syscalls, we
should also add a flags argument.

(Please CC on reply)

[1] https://www.freebsd.org/cgi/man.cgi?query=bindat=2
https://www.freebsd.org/cgi/man.cgi?query=connectat=2

linux-next: build warning after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (powerpc ppc44x_defconfig)
produced this warning:

mm/gup.c: In function 'get_user_pages_fast':
mm/gup.c:1510:20: warning: unused variable 'mm' [-Wunused-variable]
  struct mm_struct *mm = current->mm;
^

Introduced by commit

  dc8cfd957d85 ("mm/gup: Remove the macro overload API migration helpers from 
the get_user*() APIs")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (powerpc ppc44x_defconfig)
produced this warning:

mm/gup.c: In function 'get_user_pages_fast':
mm/gup.c:1510:20: warning: unused variable 'mm' [-Wunused-variable]
  struct mm_struct *mm = current->mm;
^

Introduced by commit

  dc8cfd957d85 ("mm/gup: Remove the macro overload API migration helpers from 
the get_user*() APIs")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

[Guenter Roeck]

On 04/06/2016 10:05 PM, Huang Rui wrote:

On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote:

On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote:


+static void do_read_registers_on_cu(void *_data)
+{
+   struct fam15h_power_data *data = _data;
+   int cpu, cu;
+
+   cpu = smp_processor_id();
+


Is this function now defined in non-SMP code ? If so, can you point me to the
patch or branch introducing it ? It doesn't seem to be in mainline or in -next
unless I am missing it.



In include/linux/smp.h


#else /* !SMP */

static inline void smp_send_stop(void) { }

/*
  *  These macros fold the SMP functionality into a single CPU system
  */
#define raw_smp_processor_id()  0

...

/*
  * smp_processor_id(): get the current CPU ID.
  *
  * if DEBUG_PREEMPT is enabled then we check whether it is
  * used in a preemption-safe way. (smp_processor_id() is safe
  * if it's used in a preemption-off critical section, or in
  * a thread that is bound to the current CPU.)
  *
  * NOTE: raw_smp_processor_id() is for internal use only
  * (smp_processor_id() is the preferred variant), but in rare
  * instances it might also be used to turn off false positives
  * (i.e. smp_processor_id() use that the debugging code reports but
  * which use for some reason is legal). Don't use this to hack around
  * the warning message, as your code might not work under PREEMPT.
  */
#ifdef CONFIG_DEBUG_PREEMPT
   extern unsigned int debug_smp_processor_id(void);
# define smp_processor_id() debug_smp_processor_id()
#else
# define smp_processor_id() raw_smp_processor_id()
#endif


Actually smp_processor_id() should returns 0 if we disable CONFIG_SMP.


+   /*
+* With the new x86 topology modelling, cpu core id actually
+* is compute unit id.
+*/
+   cu = cpu_data(cpu).cpu_core_id;
+
+   rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, >cu_acc_power[cu]);
+}
+
+/*
+ * This function is only able to be called when CPUID
+ * Fn8000_0007:EDX[12] is set.
+ */
+static int read_registers(struct fam15h_power_data *data)
+{
+   int this_cpu, ret, cpu;
+   int core, this_core;
+   cpumask_var_t mask;
+
+   ret = zalloc_cpumask_var(, GFP_KERNEL);
+   if (!ret)
+   return -ENOMEM;
+
+   get_online_cpus();
+   this_cpu = smp_processor_id();
+
+   /*
+* Choose the first online core of each compute unit, and then
+* read their MSR value of power and ptsc in a single IPI,
+* because the MSR value of CPU core represent the compute
+* unit's.
+*/
+   core = -1;
+
+   for_each_online_cpu(cpu) {
+   this_core = topology_core_id(cpu);
+
+   if (this_core == core)
+   continue;
+
+   core = this_core;
+

Sorry if I missed some context - is it guaranteed that all cores in the same
compute unit are returned next to each other from for_each_online_cpu() ?



Yes, there is a documentation which introduced from v4.6-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f7be8610bca88e59dd2fd5d98fcbc5031ef0e079

- topology_core_id();

 The ID of the core to which a thread belongs. It is also printed in 
/proc/cpuinfo
 "core_id."

...

   AMD nomenclature for CMT systems:

 [node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
  -> [Compute Unit Core 1] -> Linux CPU 1
  -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
  -> [Compute Unit Core 1] -> Linux CPU 3

ray@hr-ub:~/tip$ cat /proc/cpuinfo | grep "core id"
core id : 0
core id : 0
core id : 1
core id : 1

"this_core" here actually means the [Compute Unit] id which current
[Compute Unit Core] belongs to. And "cpu" here means the [Compute Unit Core].


Ok, thanks.

Guenter

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

[Guenter Roeck]

On 04/06/2016 10:05 PM, Huang Rui wrote:

On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote:

On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote:


+static void do_read_registers_on_cu(void *_data)
+{
+   struct fam15h_power_data *data = _data;
+   int cpu, cu;
+
+   cpu = smp_processor_id();
+


Is this function now defined in non-SMP code ? If so, can you point me to the
patch or branch introducing it ? It doesn't seem to be in mainline or in -next
unless I am missing it.



In include/linux/smp.h


#else /* !SMP */

static inline void smp_send_stop(void) { }

/*
  *  These macros fold the SMP functionality into a single CPU system
  */
#define raw_smp_processor_id()  0

...

/*
  * smp_processor_id(): get the current CPU ID.
  *
  * if DEBUG_PREEMPT is enabled then we check whether it is
  * used in a preemption-safe way. (smp_processor_id() is safe
  * if it's used in a preemption-off critical section, or in
  * a thread that is bound to the current CPU.)
  *
  * NOTE: raw_smp_processor_id() is for internal use only
  * (smp_processor_id() is the preferred variant), but in rare
  * instances it might also be used to turn off false positives
  * (i.e. smp_processor_id() use that the debugging code reports but
  * which use for some reason is legal). Don't use this to hack around
  * the warning message, as your code might not work under PREEMPT.
  */
#ifdef CONFIG_DEBUG_PREEMPT
   extern unsigned int debug_smp_processor_id(void);
# define smp_processor_id() debug_smp_processor_id()
#else
# define smp_processor_id() raw_smp_processor_id()
#endif


Actually smp_processor_id() should returns 0 if we disable CONFIG_SMP.


+   /*
+* With the new x86 topology modelling, cpu core id actually
+* is compute unit id.
+*/
+   cu = cpu_data(cpu).cpu_core_id;
+
+   rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, >cu_acc_power[cu]);
+}
+
+/*
+ * This function is only able to be called when CPUID
+ * Fn8000_0007:EDX[12] is set.
+ */
+static int read_registers(struct fam15h_power_data *data)
+{
+   int this_cpu, ret, cpu;
+   int core, this_core;
+   cpumask_var_t mask;
+
+   ret = zalloc_cpumask_var(, GFP_KERNEL);
+   if (!ret)
+   return -ENOMEM;
+
+   get_online_cpus();
+   this_cpu = smp_processor_id();
+
+   /*
+* Choose the first online core of each compute unit, and then
+* read their MSR value of power and ptsc in a single IPI,
+* because the MSR value of CPU core represent the compute
+* unit's.
+*/
+   core = -1;
+
+   for_each_online_cpu(cpu) {
+   this_core = topology_core_id(cpu);
+
+   if (this_core == core)
+   continue;
+
+   core = this_core;
+

Sorry if I missed some context - is it guaranteed that all cores in the same
compute unit are returned next to each other from for_each_online_cpu() ?



Yes, there is a documentation which introduced from v4.6-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f7be8610bca88e59dd2fd5d98fcbc5031ef0e079

- topology_core_id();

 The ID of the core to which a thread belongs. It is also printed in 
/proc/cpuinfo
 "core_id."

...

   AMD nomenclature for CMT systems:

 [node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
  -> [Compute Unit Core 1] -> Linux CPU 1
  -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
  -> [Compute Unit Core 1] -> Linux CPU 3

ray@hr-ub:~/tip$ cat /proc/cpuinfo | grep "core id"
core id : 0
core id : 0
core id : 1
core id : 1

"this_core" here actually means the [Compute Unit] id which current
[Compute Unit Core] belongs to. And "cpu" here means the [Compute Unit Core].


Ok, thanks.

Guenter

Re: linux-next: build failure after merge of the akpm-current tree

[Hugh Dickins]

On Thu, 7 Apr 2016, Stephen Rothwell wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/linux/linkage.h:4:0,
>  from include/linux/fs.h:4,
>  from mm/shmem.c:24:
> In function 'shmem_disband_hugeteam',
> inlined from 'shmem_getpage_gfp' at mm/shmem.c:3075:3:
> include/linux/compiler.h:510:38: error: call to '__compiletime_assert_1747' 
> declared with attribute error: BUILD_BUG failed
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>   ^
> include/linux/compiler.h:493:4: note: in definition of macro 
> '__compiletime_assert'
> prefix ## suffix();\
> ^
> include/linux/compiler.h:510:2: note: in expansion of macro 
> '_compiletime_assert'
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>   ^
> include/linux/bug.h:51:37: note: in expansion of macro 'compiletime_assert'
>  #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>  ^
> include/linux/bug.h:85:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>  ^
> mm/shmem.c:1747:2: note: in expansion of macro 'BUILD_BUG'
>   BUILD_BUG();
>   ^
> 
> Caused by commit
> 
>   ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")
> 
> I added the following (hacky, but builds for my compiler at least)
> patch for today:

Sorry about that, thanks a lot Stephen, your patch will do fine (though
what I'll do is simply delete that BUILD_BUG(), which isn't really
serving any useful purpose).  It certainly has been compiled before
on arm and without CONFIG_TRANSPARENT_HUGEPAGE, but I guess different
compiler versions make different optimizations, so I never noticed I
was unwittingly relying on too sophisticated an optimization there.

Hugh

> 
> From: Stephen Rothwell 
> Date: Thu, 7 Apr 2016 14:57:45 +1000
> Subject: [PATCH] huge tmpfs: fix build problem on arm
> 
> allocated_huge will never be non-NULL if CONFIG_TRANSPARENT_HUGEPAGE is not.
> 
> Fixes: ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a 
> team")
> Signed-off-by: Stephen Rothwell 
> ---
>  mm/shmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 5b9fecc9ce72..f2307d9630aa 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -3071,7 +3071,7 @@ unlock:
>   unlock_page(page);
>   put_page(page);
>   }
> - if (alloced_huge) {
> + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && alloced_huge) {
>   shmem_disband_hugeteam(alloced_huge);
>   alloced_huge = NULL;
>   }
> -- 

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

[Felipe Balbi]

HI

"Du, Changbin"  writes:
>> before I review your patches, one comment
>> 
>> changbin...@intel.com writes:
>> > From: "Du, Changbin" 
>> >
>> > The first patch removed unnecessary checking for debugfs api call;
>> > The second patch fix a memory leak issue;
>> > The third patch add one new entry to debufs.
>> >
>> > Du, Changbin (3):
>> >   usb: dwc3: make dwc3_debugfs_init return value be void
>> 
>> this is _not_ a fix
>> 
>> >   usb: dwc3: free dwc->regset on dwc3_debugfs_exit
>> 
>> but this is. Why isn't this, at least, the first patch in the list ? In
>> fact, it would be preferred that this patch be sent by itself and the
>> following two patches should be on another branch completely without any
>> dependencies to the memory leak fix.
>> 
>> --
>> Balbi
>
> Sure, Balbi. This will be better. I will send out patch v3 and another 
> independent
> patch. Also include changelog as Greg required. Thanks for checking.

thanks, that way we can get the fix during the -rc cycle and the other
two patches on next merge window ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the akpm-current tree

[Hugh Dickins]

On Thu, 7 Apr 2016, Stephen Rothwell wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/linux/linkage.h:4:0,
>  from include/linux/fs.h:4,
>  from mm/shmem.c:24:
> In function 'shmem_disband_hugeteam',
> inlined from 'shmem_getpage_gfp' at mm/shmem.c:3075:3:
> include/linux/compiler.h:510:38: error: call to '__compiletime_assert_1747' 
> declared with attribute error: BUILD_BUG failed
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>   ^
> include/linux/compiler.h:493:4: note: in definition of macro 
> '__compiletime_assert'
> prefix ## suffix();\
> ^
> include/linux/compiler.h:510:2: note: in expansion of macro 
> '_compiletime_assert'
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>   ^
> include/linux/bug.h:51:37: note: in expansion of macro 'compiletime_assert'
>  #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>  ^
> include/linux/bug.h:85:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>  ^
> mm/shmem.c:1747:2: note: in expansion of macro 'BUILD_BUG'
>   BUILD_BUG();
>   ^
> 
> Caused by commit
> 
>   ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")
> 
> I added the following (hacky, but builds for my compiler at least)
> patch for today:

Sorry about that, thanks a lot Stephen, your patch will do fine (though
what I'll do is simply delete that BUILD_BUG(), which isn't really
serving any useful purpose).  It certainly has been compiled before
on arm and without CONFIG_TRANSPARENT_HUGEPAGE, but I guess different
compiler versions make different optimizations, so I never noticed I
was unwittingly relying on too sophisticated an optimization there.

Hugh

> 
> From: Stephen Rothwell 
> Date: Thu, 7 Apr 2016 14:57:45 +1000
> Subject: [PATCH] huge tmpfs: fix build problem on arm
> 
> allocated_huge will never be non-NULL if CONFIG_TRANSPARENT_HUGEPAGE is not.
> 
> Fixes: ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a 
> team")
> Signed-off-by: Stephen Rothwell 
> ---
>  mm/shmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 5b9fecc9ce72..f2307d9630aa 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -3071,7 +3071,7 @@ unlock:
>   unlock_page(page);
>   put_page(page);
>   }
> - if (alloced_huge) {
> + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && alloced_huge) {
>   shmem_disband_hugeteam(alloced_huge);
>   alloced_huge = NULL;
>   }
> -- 

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

[Felipe Balbi]

HI

"Du, Changbin"  writes:
>> before I review your patches, one comment
>> 
>> changbin...@intel.com writes:
>> > From: "Du, Changbin" 
>> >
>> > The first patch removed unnecessary checking for debugfs api call;
>> > The second patch fix a memory leak issue;
>> > The third patch add one new entry to debufs.
>> >
>> > Du, Changbin (3):
>> >   usb: dwc3: make dwc3_debugfs_init return value be void
>> 
>> this is _not_ a fix
>> 
>> >   usb: dwc3: free dwc->regset on dwc3_debugfs_exit
>> 
>> but this is. Why isn't this, at least, the first patch in the list ? In
>> fact, it would be preferred that this patch be sent by itself and the
>> following two patches should be on another branch completely without any
>> dependencies to the memory leak fix.
>> 
>> --
>> Balbi
>
> Sure, Balbi. This will be better. I will send out patch v3 and another 
> independent
> patch. Also include changelog as Greg required. Thanks for checking.

thanks, that way we can get the fix during the -rc cycle and the other
two patches on next merge window ;-)

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

[Du, Changbin]

> before I review your patches, one comment
> 
> changbin...@intel.com writes:
> > From: "Du, Changbin" 
> >
> > The first patch removed unnecessary checking for debugfs api call;
> > The second patch fix a memory leak issue;
> > The third patch add one new entry to debufs.
> >
> > Du, Changbin (3):
> >   usb: dwc3: make dwc3_debugfs_init return value be void
> 
> this is _not_ a fix
> 
> >   usb: dwc3: free dwc->regset on dwc3_debugfs_exit
> 
> but this is. Why isn't this, at least, the first patch in the list ? In
> fact, it would be preferred that this patch be sent by itself and the
> following two patches should be on another branch completely without any
> dependencies to the memory leak fix.
> 
> --
> Balbi

Sure, Balbi. This will be better. I will send out patch v3 and another 
independent
patch. Also include changelog as Greg required. Thanks for checking.

Regards,
Du, Changbin

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

[Du, Changbin]

> before I review your patches, one comment
> 
> changbin...@intel.com writes:
> > From: "Du, Changbin" 
> >
> > The first patch removed unnecessary checking for debugfs api call;
> > The second patch fix a memory leak issue;
> > The third patch add one new entry to debufs.
> >
> > Du, Changbin (3):
> >   usb: dwc3: make dwc3_debugfs_init return value be void
> 
> this is _not_ a fix
> 
> >   usb: dwc3: free dwc->regset on dwc3_debugfs_exit
> 
> but this is. Why isn't this, at least, the first patch in the list ? In
> fact, it would be preferred that this patch be sent by itself and the
> following two patches should be on another branch completely without any
> dependencies to the memory leak fix.
> 
> --
> Balbi

Sure, Balbi. This will be better. I will send out patch v3 and another 
independent
patch. Also include changelog as Greg required. Thanks for checking.

Regards,
Du, Changbin

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/linux/linkage.h:4:0,
 from include/linux/fs.h:4,
 from mm/shmem.c:24:
In function 'shmem_disband_hugeteam',
inlined from 'shmem_getpage_gfp' at mm/shmem.c:3075:3:
include/linux/compiler.h:510:38: error: call to '__compiletime_assert_1747' 
declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/compiler.h:493:4: note: in definition of macro 
'__compiletime_assert'
prefix ## suffix();\
^
include/linux/compiler.h:510:2: note: in expansion of macro 
'_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:51:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 ^
include/linux/bug.h:85:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 ^
mm/shmem.c:1747:2: note: in expansion of macro 'BUILD_BUG'
  BUILD_BUG();
  ^

Caused by commit

  ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")

I added the following (hacky, but builds for my compiler at least)
patch for today:

From: Stephen Rothwell 
Date: Thu, 7 Apr 2016 14:57:45 +1000
Subject: [PATCH] huge tmpfs: fix build problem on arm

allocated_huge will never be non-NULL if CONFIG_TRANSPARENT_HUGEPAGE is not.

Fixes: ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a 
team")
Signed-off-by: Stephen Rothwell 
---
 mm/shmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index 5b9fecc9ce72..f2307d9630aa 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3071,7 +3071,7 @@ unlock:
unlock_page(page);
put_page(page);
}
-   if (alloced_huge) {
+   if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && alloced_huge) {
shmem_disband_hugeteam(alloced_huge);
alloced_huge = NULL;
}
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from include/linux/linkage.h:4:0,
 from include/linux/fs.h:4,
 from mm/shmem.c:24:
In function 'shmem_disband_hugeteam',
inlined from 'shmem_getpage_gfp' at mm/shmem.c:3075:3:
include/linux/compiler.h:510:38: error: call to '__compiletime_assert_1747' 
declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/compiler.h:493:4: note: in definition of macro 
'__compiletime_assert'
prefix ## suffix();\
^
include/linux/compiler.h:510:2: note: in expansion of macro 
'_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:51:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 ^
include/linux/bug.h:85:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
 ^
mm/shmem.c:1747:2: note: in expansion of macro 'BUILD_BUG'
  BUILD_BUG();
  ^

Caused by commit

  ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")

I added the following (hacky, but builds for my compiler at least)
patch for today:

From: Stephen Rothwell 
Date: Thu, 7 Apr 2016 14:57:45 +1000
Subject: [PATCH] huge tmpfs: fix build problem on arm

allocated_huge will never be non-NULL if CONFIG_TRANSPARENT_HUGEPAGE is not.

Fixes: ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a 
team")
Signed-off-by: Stephen Rothwell 
---
 mm/shmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index 5b9fecc9ce72..f2307d9630aa 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3071,7 +3071,7 @@ unlock:
unlock_page(page);
put_page(page);
}
-   if (alloced_huge) {
+   if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && alloced_huge) {
shmem_disband_hugeteam(alloced_huge);
alloced_huge = NULL;
}
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 2/3] usb: dwc3: free dwc->regset on dwc3_debugfs_exit

[Felipe Balbi]

changbin...@intel.com writes:

> From: "Du, Changbin" 
>

no commit log == no commit, sorry

> Signed-off-by: Du, Changbin 
> ---
>  drivers/usb/dwc3/debugfs.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> index 071b286..2d4f397 100644
> --- a/drivers/usb/dwc3/debugfs.c
> +++ b/drivers/usb/dwc3/debugfs.c
> @@ -657,4 +657,7 @@ void dwc3_debugfs_exit(struct dwc3 *dwc)
>  {
>   debugfs_remove_recursive(dwc->root);
>   dwc->root = NULL;
> +
> + kfree(dwc->regset);
> + dwc->regset = NULL;
>  }
> -- 
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 2/3] usb: dwc3: free dwc->regset on dwc3_debugfs_exit

[Felipe Balbi]

changbin...@intel.com writes:

> From: "Du, Changbin" 
>

no commit log == no commit, sorry

> Signed-off-by: Du, Changbin 
> ---
>  drivers/usb/dwc3/debugfs.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> index 071b286..2d4f397 100644
> --- a/drivers/usb/dwc3/debugfs.c
> +++ b/drivers/usb/dwc3/debugfs.c
> @@ -657,4 +657,7 @@ void dwc3_debugfs_exit(struct dwc3 *dwc)
>  {
>   debugfs_remove_recursive(dwc->root);
>   dwc->root = NULL;
> +
> + kfree(dwc->regset);
> + dwc->regset = NULL;
>  }
> -- 
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

[Felipe Balbi]

Hi,

before I review your patches, one comment

changbin...@intel.com writes:
> From: "Du, Changbin" 
>
> The first patch removed unnecessary checking for debugfs api call;
> The second patch fix a memory leak issue;
> The third patch add one new entry to debufs.
>
> Du, Changbin (3):
>   usb: dwc3: make dwc3_debugfs_init return value be void

this is _not_ a fix

>   usb: dwc3: free dwc->regset on dwc3_debugfs_exit

but this is. Why isn't this, at least, the first patch in the list ? In
fact, it would be preferred that this patch be sent by itself and the
following two patches should be on another branch completely without any
dependencies to the memory leak fix.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

[Felipe Balbi]

Hi,

before I review your patches, one comment

changbin...@intel.com writes:
> From: "Du, Changbin" 
>
> The first patch removed unnecessary checking for debugfs api call;
> The second patch fix a memory leak issue;
> The third patch add one new entry to debufs.
>
> Du, Changbin (3):
>   usb: dwc3: make dwc3_debugfs_init return value be void

this is _not_ a fix

>   usb: dwc3: free dwc->regset on dwc3_debugfs_exit

but this is. Why isn't this, at least, the first patch in the list ? In
fact, it would be preferred that this patch be sent by itself and the
following two patches should be on another branch completely without any
dependencies to the memory leak fix.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

[Huang Rui]

On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote:
> On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote:
> >  
> > +static void do_read_registers_on_cu(void *_data)
> > +{
> > +   struct fam15h_power_data *data = _data;
> > +   int cpu, cu;
> > +
> > +   cpu = smp_processor_id();
> > +
> 
> Is this function now defined in non-SMP code ? If so, can you point me to the
> patch or branch introducing it ? It doesn't seem to be in mainline or in -next
> unless I am missing it.
> 

In include/linux/smp.h


#else /* !SMP */

static inline void smp_send_stop(void) { }

/*
 *  These macros fold the SMP functionality into a single CPU system
 */
#define raw_smp_processor_id()  0

...

/*
 * smp_processor_id(): get the current CPU ID.
 *
 * if DEBUG_PREEMPT is enabled then we check whether it is
 * used in a preemption-safe way. (smp_processor_id() is safe
 * if it's used in a preemption-off critical section, or in
 * a thread that is bound to the current CPU.)
 *
 * NOTE: raw_smp_processor_id() is for internal use only
 * (smp_processor_id() is the preferred variant), but in rare
 * instances it might also be used to turn off false positives
 * (i.e. smp_processor_id() use that the debugging code reports but
 * which use for some reason is legal). Don't use this to hack around
 * the warning message, as your code might not work under PREEMPT.
 */
#ifdef CONFIG_DEBUG_PREEMPT
  extern unsigned int debug_smp_processor_id(void);
# define smp_processor_id() debug_smp_processor_id()
#else
# define smp_processor_id() raw_smp_processor_id()
#endif


Actually smp_processor_id() should returns 0 if we disable CONFIG_SMP.

> > +   /*
> > +* With the new x86 topology modelling, cpu core id actually
> > +* is compute unit id.
> > +*/
> > +   cu = cpu_data(cpu).cpu_core_id;
> > +
> > +   rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, >cu_acc_power[cu]);
> > +}
> > +
> > +/*
> > + * This function is only able to be called when CPUID
> > + * Fn8000_0007:EDX[12] is set.
> > + */
> > +static int read_registers(struct fam15h_power_data *data)
> > +{
> > +   int this_cpu, ret, cpu;
> > +   int core, this_core;
> > +   cpumask_var_t mask;
> > +
> > +   ret = zalloc_cpumask_var(, GFP_KERNEL);
> > +   if (!ret)
> > +   return -ENOMEM;
> > +
> > +   get_online_cpus();
> > +   this_cpu = smp_processor_id();
> > +
> > +   /*
> > +* Choose the first online core of each compute unit, and then
> > +* read their MSR value of power and ptsc in a single IPI,
> > +* because the MSR value of CPU core represent the compute
> > +* unit's.
> > +*/
> > +   core = -1;
> > +
> > +   for_each_online_cpu(cpu) {
> > +   this_core = topology_core_id(cpu);
> > +
> > +   if (this_core == core)
> > +   continue;
> > +
> > +   core = this_core;
> > +
> Sorry if I missed some context - is it guaranteed that all cores in the same
> compute unit are returned next to each other from for_each_online_cpu() ?
> 

Yes, there is a documentation which introduced from v4.6-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f7be8610bca88e59dd2fd5d98fcbc5031ef0e079

   - topology_core_id();

The ID of the core to which a thread belongs. It is also printed in 
/proc/cpuinfo
"core_id."

...

  AMD nomenclature for CMT systems:

[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
 -> [Compute Unit Core 1] -> Linux CPU 1
 -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
 -> [Compute Unit Core 1] -> Linux CPU 3

ray@hr-ub:~/tip$ cat /proc/cpuinfo | grep "core id"
core id : 0
core id : 0
core id : 1
core id : 1

"this_core" here actually means the [Compute Unit] id which current
[Compute Unit Core] belongs to. And "cpu" here means the [Compute Unit Core].

Thanks,
Rui

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

[Huang Rui]

On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote:
> On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote:
> >  
> > +static void do_read_registers_on_cu(void *_data)
> > +{
> > +   struct fam15h_power_data *data = _data;
> > +   int cpu, cu;
> > +
> > +   cpu = smp_processor_id();
> > +
> 
> Is this function now defined in non-SMP code ? If so, can you point me to the
> patch or branch introducing it ? It doesn't seem to be in mainline or in -next
> unless I am missing it.
> 

In include/linux/smp.h


#else /* !SMP */

static inline void smp_send_stop(void) { }

/*
 *  These macros fold the SMP functionality into a single CPU system
 */
#define raw_smp_processor_id()  0

...

/*
 * smp_processor_id(): get the current CPU ID.
 *
 * if DEBUG_PREEMPT is enabled then we check whether it is
 * used in a preemption-safe way. (smp_processor_id() is safe
 * if it's used in a preemption-off critical section, or in
 * a thread that is bound to the current CPU.)
 *
 * NOTE: raw_smp_processor_id() is for internal use only
 * (smp_processor_id() is the preferred variant), but in rare
 * instances it might also be used to turn off false positives
 * (i.e. smp_processor_id() use that the debugging code reports but
 * which use for some reason is legal). Don't use this to hack around
 * the warning message, as your code might not work under PREEMPT.
 */
#ifdef CONFIG_DEBUG_PREEMPT
  extern unsigned int debug_smp_processor_id(void);
# define smp_processor_id() debug_smp_processor_id()
#else
# define smp_processor_id() raw_smp_processor_id()
#endif


Actually smp_processor_id() should returns 0 if we disable CONFIG_SMP.

> > +   /*
> > +* With the new x86 topology modelling, cpu core id actually
> > +* is compute unit id.
> > +*/
> > +   cu = cpu_data(cpu).cpu_core_id;
> > +
> > +   rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, >cu_acc_power[cu]);
> > +}
> > +
> > +/*
> > + * This function is only able to be called when CPUID
> > + * Fn8000_0007:EDX[12] is set.
> > + */
> > +static int read_registers(struct fam15h_power_data *data)
> > +{
> > +   int this_cpu, ret, cpu;
> > +   int core, this_core;
> > +   cpumask_var_t mask;
> > +
> > +   ret = zalloc_cpumask_var(, GFP_KERNEL);
> > +   if (!ret)
> > +   return -ENOMEM;
> > +
> > +   get_online_cpus();
> > +   this_cpu = smp_processor_id();
> > +
> > +   /*
> > +* Choose the first online core of each compute unit, and then
> > +* read their MSR value of power and ptsc in a single IPI,
> > +* because the MSR value of CPU core represent the compute
> > +* unit's.
> > +*/
> > +   core = -1;
> > +
> > +   for_each_online_cpu(cpu) {
> > +   this_core = topology_core_id(cpu);
> > +
> > +   if (this_core == core)
> > +   continue;
> > +
> > +   core = this_core;
> > +
> Sorry if I missed some context - is it guaranteed that all cores in the same
> compute unit are returned next to each other from for_each_online_cpu() ?
> 

Yes, there is a documentation which introduced from v4.6-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f7be8610bca88e59dd2fd5d98fcbc5031ef0e079

   - topology_core_id();

The ID of the core to which a thread belongs. It is also printed in 
/proc/cpuinfo
"core_id."

...

  AMD nomenclature for CMT systems:

[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
 -> [Compute Unit Core 1] -> Linux CPU 1
 -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
 -> [Compute Unit Core 1] -> Linux CPU 3

ray@hr-ub:~/tip$ cat /proc/cpuinfo | grep "core id"
core id : 0
core id : 0
core id : 1
core id : 1

"this_core" here actually means the [Compute Unit] id which current
[Compute Unit Core] belongs to. And "cpu" here means the [Compute Unit Core].

Thanks,
Rui

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

[Felipe Balbi]

Hi,

Greg Kroah-Hartman  writes:
> On Wed, Apr 06, 2016 at 01:19:04PM +0300, Felipe Balbi wrote:
>> > What happened to getting internal help in designing this api?  This
>> > shouldn't be my job :)
>> 
>> I looked at this Baolu but, at least to me, it's unclear what you're
>> hinting here. Sure, the API is a bit odd in that we register a mux and
>> unregister a device (that has been fixed), but is there anything else ?
>
> I don't remember anymore, that was a few thousand emails ago...
>
> But the suggestion about using devm_* shows that the original author
> has very little understanding about how the driver model works at all,
> which doesn't give me much hope at the moment...

fair enough, that can also be 'fixed' with experience, right ? Just
takes time ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

[Felipe Balbi]

Hi,

Greg Kroah-Hartman  writes:
> On Wed, Apr 06, 2016 at 01:19:04PM +0300, Felipe Balbi wrote:
>> > What happened to getting internal help in designing this api?  This
>> > shouldn't be my job :)
>> 
>> I looked at this Baolu but, at least to me, it's unclear what you're
>> hinting here. Sure, the API is a bit odd in that we register a mux and
>> unregister a device (that has been fixed), but is there anything else ?
>
> I don't remember anymore, that was a few thousand emails ago...
>
> But the suggestion about using devm_* shows that the original author
> has very little understanding about how the driver model works at all,
> which doesn't give me much hope at the moment...

fair enough, that can also be 'fixed' with experience, right ? Just
takes time ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v9 2/4] gadget: Support for the usb charger framework

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> > In below change of usb_gadget_vbus_draw(), already can get charger
>> >> > type via usb_charger_get_type().
>> >> >
>> >> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget,
>> >> > unsigned mA)  {
>> >> > +   enum usb_charger_type type;
>> >> > +
>> >> > +   if (gadget->charger) {
>> >> > +   type = usb_charger_get_type(gadget->charger);
>> >> > +   usb_charger_set_cur_limit_by_type(gadget->charger, type,
>> >> mA);
>> >> > +   }
>> >> > +
>> >> > if (!gadget->ops->vbus_draw)
>> >> > return -EOPNOTSUPP;
>> >> > return gadget->ops->vbus_draw(gadget, mA);
>> >> >
>> >> > Could you detail in what situation gadget->ops-> get_charger_type() is
>> >> used?
>> >> 
>> >> isn't it right there in the code ? Isn't usb_gadget_vbus_draw() calling
>> >> it ? What did I miss here ?
>> >
>> > Well, that's true, so my real meaning is why gadget need get charger type
>> > via another new api gadget->ops->get_charger_type().
>> 
>> because of semantics. usb_gadget_vbus_draw() is *only* supposed to
>> connect a load across vbus and gnd so some battery can be charged. Also,
>> we need to abstract away this ->get_charger_type() operation because it
>> might be different for each UDC.
>
> In this patch set, there are two ->get_charger_type in below two
> structures, as my understanding, get_charger_type at struct usb_charger
> can be implemented at UDC drivers; But I don't see necessary we
> need to implement get_charger_type for usb_gadget_ops at UDC drivers
> again. What do you think?

I had missed that completely, nice catch. I agree with you, there should
be one place where this is implemented and struct usb_charger sounds
like it is that place.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

[Yong Li]

Galileo Gen2 board uses the PCAL9535 as the GPIO expansion,
it is different from PCA9535 and includes interrupt mask/status registers,
The current driver does not support the interrupt registers configuration,
it causes some gpio pins cannot trigger interrupt events,
this patch fix this issue. The original patch was submitted by
Josef Ahmad 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-quark/tree/recipes-kernel/linux/files/0015-Quark-GPIO-1-2-quark.patch

Signed-off-by: Yong Li 
---
 drivers/gpio/gpio-pca953x.c | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index e66084c..5e3be32 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -38,8 +38,13 @@
 #define PCA957X_MSK6
 #define PCA957X_INTS   7
 
+#define PCAL953X_IN_LATCH  34
+#define PCAL953X_INT_MASK  37
+#define PCAL953X_INT_STAT  38
+
 #define PCA_GPIO_MASK  0x00FF
 #define PCA_INT0x0100
+#define PCA_PCAL   0x0200
 #define PCA953X_TYPE   0x1000
 #define PCA957X_TYPE   0x2000
 #define PCA_TYPE_MASK  0xF000
@@ -77,7 +82,7 @@ static const struct i2c_device_id pca953x_id[] = {
 MODULE_DEVICE_TABLE(i2c, pca953x_id);
 
 static const struct acpi_device_id pca953x_acpi_ids[] = {
-   { "INT3491", 16 | PCA953X_TYPE | PCA_INT, },
+   { "INT3491", 16 | PCA953X_TYPE | PCA_INT | PCA_PCAL, },
{ }
 };
 MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
@@ -437,6 +442,18 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
struct pca953x_chip *chip = gpiochip_get_data(gc);
u8 new_irqs;
int level, i;
+   u8 invert_irq_mask[MAX_BANK];
+
+   if (chip->driver_data & PCA_PCAL) {
+   /* Enable latch on interrupt-enabled inputs */
+   pca953x_write_regs(chip, PCAL953X_IN_LATCH, chip->irq_mask);
+
+   for (i = 0; i < NBANK(chip); i++)
+   invert_irq_mask[i] = ~chip->irq_mask[i];
+
+   /* Unmask enabled interrupts */
+   pca953x_write_regs(chip, PCAL953X_INT_MASK, invert_irq_mask);
+   }
 
/* Look for any newly setup interrupt */
for (i = 0; i < NBANK(chip); i++) {
@@ -498,6 +515,29 @@ static bool pca953x_irq_pending(struct pca953x_chip *chip, 
u8 *pending)
u8 trigger[MAX_BANK];
int ret, i, offset = 0;
 
+   if (chip->driver_data & PCA_PCAL) {
+   /* Read the current interrupt status from the device */
+   ret = pca953x_read_regs(chip, PCAL953X_INT_STAT, trigger);
+   if (ret)
+   return false;
+
+   /* Check latched inputs and clear interrupt status */
+   ret = pca953x_read_regs(chip, PCA953X_INPUT, cur_stat);
+   if (ret)
+   return false;
+
+   for (i = 0; i < NBANK(chip); i++) {
+   /* Apply filter for rising/falling edge selection */
+   pending[i] = (~cur_stat[i] & chip->irq_trig_fall[i]) |
+   (cur_stat[i] & chip->irq_trig_raise[i]);
+   pending[i] &= trigger[i];
+   if (pending[i])
+   pending_seen = true;
+   }
+
+   return pending_seen;
+   }
+
switch (chip->chip_type) {
case PCA953X_TYPE:
offset = PCA953X_INPUT;
-- 
2.1.4

Re: [PATCH v9 2/4] gadget: Support for the usb charger framework

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> > In below change of usb_gadget_vbus_draw(), already can get charger
>> >> > type via usb_charger_get_type().
>> >> >
>> >> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget,
>> >> > unsigned mA)  {
>> >> > +   enum usb_charger_type type;
>> >> > +
>> >> > +   if (gadget->charger) {
>> >> > +   type = usb_charger_get_type(gadget->charger);
>> >> > +   usb_charger_set_cur_limit_by_type(gadget->charger, type,
>> >> mA);
>> >> > +   }
>> >> > +
>> >> > if (!gadget->ops->vbus_draw)
>> >> > return -EOPNOTSUPP;
>> >> > return gadget->ops->vbus_draw(gadget, mA);
>> >> >
>> >> > Could you detail in what situation gadget->ops-> get_charger_type() is
>> >> used?
>> >> 
>> >> isn't it right there in the code ? Isn't usb_gadget_vbus_draw() calling
>> >> it ? What did I miss here ?
>> >
>> > Well, that's true, so my real meaning is why gadget need get charger type
>> > via another new api gadget->ops->get_charger_type().
>> 
>> because of semantics. usb_gadget_vbus_draw() is *only* supposed to
>> connect a load across vbus and gnd so some battery can be charged. Also,
>> we need to abstract away this ->get_charger_type() operation because it
>> might be different for each UDC.
>
> In this patch set, there are two ->get_charger_type in below two
> structures, as my understanding, get_charger_type at struct usb_charger
> can be implemented at UDC drivers; But I don't see necessary we
> need to implement get_charger_type for usb_gadget_ops at UDC drivers
> again. What do you think?

I had missed that completely, nice catch. I agree with you, there should
be one place where this is implemented and struct usb_charger sounds
like it is that place.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

[Yong Li]

Galileo Gen2 board uses the PCAL9535 as the GPIO expansion,
it is different from PCA9535 and includes interrupt mask/status registers,
The current driver does not support the interrupt registers configuration,
it causes some gpio pins cannot trigger interrupt events,
this patch fix this issue. The original patch was submitted by
Josef Ahmad 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-quark/tree/recipes-kernel/linux/files/0015-Quark-GPIO-1-2-quark.patch

Signed-off-by: Yong Li 
---
 drivers/gpio/gpio-pca953x.c | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index e66084c..5e3be32 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -38,8 +38,13 @@
 #define PCA957X_MSK6
 #define PCA957X_INTS   7
 
+#define PCAL953X_IN_LATCH  34
+#define PCAL953X_INT_MASK  37
+#define PCAL953X_INT_STAT  38
+
 #define PCA_GPIO_MASK  0x00FF
 #define PCA_INT0x0100
+#define PCA_PCAL   0x0200
 #define PCA953X_TYPE   0x1000
 #define PCA957X_TYPE   0x2000
 #define PCA_TYPE_MASK  0xF000
@@ -77,7 +82,7 @@ static const struct i2c_device_id pca953x_id[] = {
 MODULE_DEVICE_TABLE(i2c, pca953x_id);
 
 static const struct acpi_device_id pca953x_acpi_ids[] = {
-   { "INT3491", 16 | PCA953X_TYPE | PCA_INT, },
+   { "INT3491", 16 | PCA953X_TYPE | PCA_INT | PCA_PCAL, },
{ }
 };
 MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
@@ -437,6 +442,18 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
struct pca953x_chip *chip = gpiochip_get_data(gc);
u8 new_irqs;
int level, i;
+   u8 invert_irq_mask[MAX_BANK];
+
+   if (chip->driver_data & PCA_PCAL) {
+   /* Enable latch on interrupt-enabled inputs */
+   pca953x_write_regs(chip, PCAL953X_IN_LATCH, chip->irq_mask);
+
+   for (i = 0; i < NBANK(chip); i++)
+   invert_irq_mask[i] = ~chip->irq_mask[i];
+
+   /* Unmask enabled interrupts */
+   pca953x_write_regs(chip, PCAL953X_INT_MASK, invert_irq_mask);
+   }
 
/* Look for any newly setup interrupt */
for (i = 0; i < NBANK(chip); i++) {
@@ -498,6 +515,29 @@ static bool pca953x_irq_pending(struct pca953x_chip *chip, 
u8 *pending)
u8 trigger[MAX_BANK];
int ret, i, offset = 0;
 
+   if (chip->driver_data & PCA_PCAL) {
+   /* Read the current interrupt status from the device */
+   ret = pca953x_read_regs(chip, PCAL953X_INT_STAT, trigger);
+   if (ret)
+   return false;
+
+   /* Check latched inputs and clear interrupt status */
+   ret = pca953x_read_regs(chip, PCA953X_INPUT, cur_stat);
+   if (ret)
+   return false;
+
+   for (i = 0; i < NBANK(chip); i++) {
+   /* Apply filter for rising/falling edge selection */
+   pending[i] = (~cur_stat[i] & chip->irq_trig_fall[i]) |
+   (cur_stat[i] & chip->irq_trig_raise[i]);
+   pending[i] &= trigger[i];
+   if (pending[i])
+   pending_seen = true;
+   }
+
+   return pending_seen;
+   }
+
switch (chip->chip_type) {
case PCA953X_TYPE:
offset = PCA953X_INPUT;
-- 
2.1.4

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Peter Chen  writes:
> On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Peter Chen  writes:
>> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
>> >> Peter Chen  writes:
>> >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
>> >> >> Peter Chen  writes:
>> >> >> > On Fri, Apr 01, 2016 at 03:21:49PM +0800, Baolin Wang wrote:
>> >> >> >  +
>> >> >> >> +static struct attribute *usb_charger_attrs[] = {
>> >> >> >> +   _attr_sdp_current.attr,
>> >> >> >> +   _attr_dcp_current.attr,
>> >> >> >> +   _attr_cdp_current.attr,
>> >> >> >> +   _attr_aca_current.attr,
>> >> >> >> +   _attr_charger_type.attr,
>> >> >> >> +   _attr_charger_state.attr,
>> >> >> >> +   NULL
>> >> >> >> +};
>> >> >> >
>> >> >> > The user may only care about current limit, type and state, why they
>> >> >> > need to care what type's current limit, it is the usb charger
>> >> >> > framework handles, the framework judge the current according to
>> >> >> > charger type and USB state (connect/configured/suspended).
>> >> >> 
>> >> >> it might be useful if we want to know that $this charger doesn't really
>> >> >> give us as much current as it advertises.
>> >> >> 
>> >> >
>> >> > As my understanding, the current limit is dynamic value, it should
>> >> > report the value the charger supports now, eg, it connects SDP, but
>> >> > the host is suspended now, then the value should be 2mA.
>> >> 
>> >> yes, and that's the limit. Now consider we connect to DCP or CDP and
>> >> limit is 2000mA but we're charging at 1000mA ;-)
>> >> 
>> >
>> > Does the user need to know the $this charger limit? Don't they only
>> > care about the current charging value? I have a USB cable which can
>> 
>> Why not ? UI might want to change the color of the battery charging icon
>> if we're charging @ 2000mA or @ 1000mA to give some visual feedback as
>> to "how fast" battery is supposed to be charged.
>> 
>> > show charging current value, it changes from time to time, when it
>> > connects to host pc, it shows 430mA; when it connects to dedicated
>> > charger, it shows 1000mA.
>> 
>> good for you, now what does that have to do with $subject ?
>> 
>
> +static struct attribute *usb_charger_attrs[] = {
> + _attr_sdp_current.attr,
> + _attr_dcp_current.attr,
> + _attr_cdp_current.attr,
> + _attr_aca_current.attr,
> + _attr_charger_type.attr,
> + _attr_charger_state.attr,
> + NULL
> +};
>
> Ok, even the users are interesting in current limit, we still have no
> necessary to know all kinds of chargers limit and current value, since
> we already have charger type user interface, the framework can show
> limit according to charger type.

Oh, now I get your comment and I totally agree. We already *know* the
detected charger type, there's no point in showing them all.

> I think below user interfaces are enough, who do you think?
>
> +static struct attribute *usb_charger_attrs[] = {
> + _attr_current.attr,
> + _attr_current_limit.attr,
> + _attr_charger_type.attr,
> + _attr_charger_state.attr,
> + NULL
> +};

agreed, const though.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Peter Chen  writes:
> On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Peter Chen  writes:
>> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote:
>> >> Peter Chen  writes:
>> >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote:
>> >> >> Peter Chen  writes:
>> >> >> > On Fri, Apr 01, 2016 at 03:21:49PM +0800, Baolin Wang wrote:
>> >> >> >  +
>> >> >> >> +static struct attribute *usb_charger_attrs[] = {
>> >> >> >> +   _attr_sdp_current.attr,
>> >> >> >> +   _attr_dcp_current.attr,
>> >> >> >> +   _attr_cdp_current.attr,
>> >> >> >> +   _attr_aca_current.attr,
>> >> >> >> +   _attr_charger_type.attr,
>> >> >> >> +   _attr_charger_state.attr,
>> >> >> >> +   NULL
>> >> >> >> +};
>> >> >> >
>> >> >> > The user may only care about current limit, type and state, why they
>> >> >> > need to care what type's current limit, it is the usb charger
>> >> >> > framework handles, the framework judge the current according to
>> >> >> > charger type and USB state (connect/configured/suspended).
>> >> >> 
>> >> >> it might be useful if we want to know that $this charger doesn't really
>> >> >> give us as much current as it advertises.
>> >> >> 
>> >> >
>> >> > As my understanding, the current limit is dynamic value, it should
>> >> > report the value the charger supports now, eg, it connects SDP, but
>> >> > the host is suspended now, then the value should be 2mA.
>> >> 
>> >> yes, and that's the limit. Now consider we connect to DCP or CDP and
>> >> limit is 2000mA but we're charging at 1000mA ;-)
>> >> 
>> >
>> > Does the user need to know the $this charger limit? Don't they only
>> > care about the current charging value? I have a USB cable which can
>> 
>> Why not ? UI might want to change the color of the battery charging icon
>> if we're charging @ 2000mA or @ 1000mA to give some visual feedback as
>> to "how fast" battery is supposed to be charged.
>> 
>> > show charging current value, it changes from time to time, when it
>> > connects to host pc, it shows 430mA; when it connects to dedicated
>> > charger, it shows 1000mA.
>> 
>> good for you, now what does that have to do with $subject ?
>> 
>
> +static struct attribute *usb_charger_attrs[] = {
> + _attr_sdp_current.attr,
> + _attr_dcp_current.attr,
> + _attr_cdp_current.attr,
> + _attr_aca_current.attr,
> + _attr_charger_type.attr,
> + _attr_charger_state.attr,
> + NULL
> +};
>
> Ok, even the users are interesting in current limit, we still have no
> necessary to know all kinds of chargers limit and current value, since
> we already have charger type user interface, the framework can show
> limit according to charger type.

Oh, now I get your comment and I totally agree. We already *know* the
detected charger type, there's no point in showing them all.

> I think below user interfaces are enough, who do you think?
>
> +static struct attribute *usb_charger_attrs[] = {
> + _attr_current.attr,
> + _attr_current_limit.attr,
> + _attr_charger_type.attr,
> + _attr_charger_state.attr,
> + NULL
> +};

agreed, const though.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

[Andy Lutomirski]

On Wed, Apr 6, 2016 at 7:02 AM, Waiman Long  wrote:
> On a large system with many CPUs, using HPET as the clock source can
> have a significant impact on the overall system performance because
> of the following reasons:
>  1) There is a single HPET counter shared by all the CPUs.
>  2) HPET counter reading is a very slow operation.
>
> Using HPET as the default clock source may happen when, for example,
> the TSC clock calibration exceeds the allowable tolerance. Something
> the performance slowdown can be so severe that the system may crash
> because of a NMI watchdog soft lockup, for example.
>
> This patch attempts to reduce HPET read contention by using the fact
> that if more than one task are trying to access HPET at the same time,
> it will be more efficient if one task in the group reads the HPET
> counter and shares it with the rest of the group instead of each
> group member reads the HPET counter individually.
>
> This is done by using a combination word with a sequence number and
> a bit lock. The task that gets the bit lock will be responsible for
> reading the HPET counter and update the sequence number. The others
> will monitor the change in sequence number and grab the HPET counter
> accordingly.
>
> On a 4-socket Haswell-EX box with 72 cores (HT off), running the
> AIM7 compute workload (1500 users) on a 4.6-rc1 kernel (HZ=1000)
> with and without the patch has the following performance numbers
> (with HPET or TSC as clock source):
>
> TSC = 646515 jobs/min
> HPET w/o patch  = 566708 jobs/min
> HPET with patch = 638791 jobs/min
>
> The perf profile showed a reduction of the %CPU time consumed by
> read_hpet from 4.99% without patch to 1.41% with patch.
>
> On a 16-socket IvyBridge-EX system with 240 cores (HT on), on the
> other hand, the performance numbers of the same benchmark were:
>
> TSC = 3145329 jobs/min
> HPET w/o patch  = 1108537 jobs/min
> HPET with patch = 3019934 jobs/min
>
> The corresponding perf profile showed a drop of CPU consumption of
> the read_hpet function from more than 34% to just 2.96%.
>
> Signed-off-by: Waiman Long 
> ---
>  arch/x86/kernel/hpet.c |  110 
> +++-
>  1 files changed, 109 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index a1f0e4a..9e3de73 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -759,11 +759,112 @@ static int hpet_cpuhp_notify(struct notifier_block *n,
>  #endif
>
>  /*
> + * Reading the HPET counter is a very slow operation. If a large number of
> + * CPUs are trying to access the HPET counter simultaneously, it can cause
> + * massive delay and slow down system performance dramatically. This may
> + * happen when HPET is the default clock source instead of TSC. For a
> + * really large system with hundreds of CPUs, the slowdown may be so
> + * severe that it may actually crash the system because of a NMI watchdog
> + * soft lockup, for example.
> + *
> + * If multiple CPUs are trying to access the HPET counter at the same time,
> + * we don't actually need to read the counter multiple times. Instead, the
> + * other CPUs can use the counter value read by the first CPU in the group.
> + *
> + * A sequence number whose lsb is a lock bit is used to control which CPU
> + * has the right to read the HPET counter directly and which CPUs are going
> + * to get the indirect value read by the lock holder. For the later group,
> + * if the sequence number differs from the expected locked value, they
> + * can assume that the saved HPET value is up-to-date and return it.
> + *
> + * This mechanism is only activated on system with a large number of CPUs.
> + * Currently, it is enabled when nr_cpus > 64.
> + */

Reading the HPET is so slow that all the atomic ops in the world won't
make a dent.  Why not just turn this optimization on unconditionally?

--Andy

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

[Andy Lutomirski]

On Wed, Apr 6, 2016 at 7:02 AM, Waiman Long  wrote:
> On a large system with many CPUs, using HPET as the clock source can
> have a significant impact on the overall system performance because
> of the following reasons:
>  1) There is a single HPET counter shared by all the CPUs.
>  2) HPET counter reading is a very slow operation.
>
> Using HPET as the default clock source may happen when, for example,
> the TSC clock calibration exceeds the allowable tolerance. Something
> the performance slowdown can be so severe that the system may crash
> because of a NMI watchdog soft lockup, for example.
>
> This patch attempts to reduce HPET read contention by using the fact
> that if more than one task are trying to access HPET at the same time,
> it will be more efficient if one task in the group reads the HPET
> counter and shares it with the rest of the group instead of each
> group member reads the HPET counter individually.
>
> This is done by using a combination word with a sequence number and
> a bit lock. The task that gets the bit lock will be responsible for
> reading the HPET counter and update the sequence number. The others
> will monitor the change in sequence number and grab the HPET counter
> accordingly.
>
> On a 4-socket Haswell-EX box with 72 cores (HT off), running the
> AIM7 compute workload (1500 users) on a 4.6-rc1 kernel (HZ=1000)
> with and without the patch has the following performance numbers
> (with HPET or TSC as clock source):
>
> TSC = 646515 jobs/min
> HPET w/o patch  = 566708 jobs/min
> HPET with patch = 638791 jobs/min
>
> The perf profile showed a reduction of the %CPU time consumed by
> read_hpet from 4.99% without patch to 1.41% with patch.
>
> On a 16-socket IvyBridge-EX system with 240 cores (HT on), on the
> other hand, the performance numbers of the same benchmark were:
>
> TSC = 3145329 jobs/min
> HPET w/o patch  = 1108537 jobs/min
> HPET with patch = 3019934 jobs/min
>
> The corresponding perf profile showed a drop of CPU consumption of
> the read_hpet function from more than 34% to just 2.96%.
>
> Signed-off-by: Waiman Long 
> ---
>  arch/x86/kernel/hpet.c |  110 
> +++-
>  1 files changed, 109 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index a1f0e4a..9e3de73 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -759,11 +759,112 @@ static int hpet_cpuhp_notify(struct notifier_block *n,
>  #endif
>
>  /*
> + * Reading the HPET counter is a very slow operation. If a large number of
> + * CPUs are trying to access the HPET counter simultaneously, it can cause
> + * massive delay and slow down system performance dramatically. This may
> + * happen when HPET is the default clock source instead of TSC. For a
> + * really large system with hundreds of CPUs, the slowdown may be so
> + * severe that it may actually crash the system because of a NMI watchdog
> + * soft lockup, for example.
> + *
> + * If multiple CPUs are trying to access the HPET counter at the same time,
> + * we don't actually need to read the counter multiple times. Instead, the
> + * other CPUs can use the counter value read by the first CPU in the group.
> + *
> + * A sequence number whose lsb is a lock bit is used to control which CPU
> + * has the right to read the HPET counter directly and which CPUs are going
> + * to get the indirect value read by the lock holder. For the later group,
> + * if the sequence number differs from the expected locked value, they
> + * can assume that the saved HPET value is up-to-date and return it.
> + *
> + * This mechanism is only activated on system with a large number of CPUs.
> + * Currently, it is enabled when nr_cpus > 64.
> + */

Reading the HPET is so slow that all the atomic ops in the world won't
make a dent.  Why not just turn this optimization on unconditionally?

--Andy

Re: [PATCH] of/platform: Allow secondary compatible match in of_dev_lookup

[Rob Herring]

On Fri, Apr 1, 2016 at 4:40 PM, Tony Lindgren  wrote:
> * Tony Lindgren  [160401 14:37]:
>> We currently try to match of_dev_auxdata based on compatible,
>> IO address, and device name. But in some cases we have multiple
>> instances of drivers that can use the same auxdata.
>>
>> Let's add an additional secondary lookup for generic compatible
>> match for auxdata if no device specific match is found. This does
>> not change the existing matching, and still allows adding device
>> specific auxdata.
>>
>> This simplifies things as specifying the IO address and device
>> name is prone errors as it requires maintaining an in kernel
>> database for each SoC.
>
> And here's what I can apply later on to get rid of some
> ifdeffery.
>
> I'm also planning to move some of the legacy omap hwmod
> functionality into proper device drivers, so can generic
> pdata for that too.

Why can't the platform data be moved into the driver given that it
appears to be only SoC family specific? Auxdata was somewhat intended
to be temporary. It appears there is already some per compatible match
data for these OMAP parts in the driver.

Rob

Re: [PATCH] of/platform: Allow secondary compatible match in of_dev_lookup

[Rob Herring]

On Fri, Apr 1, 2016 at 4:40 PM, Tony Lindgren  wrote:
> * Tony Lindgren  [160401 14:37]:
>> We currently try to match of_dev_auxdata based on compatible,
>> IO address, and device name. But in some cases we have multiple
>> instances of drivers that can use the same auxdata.
>>
>> Let's add an additional secondary lookup for generic compatible
>> match for auxdata if no device specific match is found. This does
>> not change the existing matching, and still allows adding device
>> specific auxdata.
>>
>> This simplifies things as specifying the IO address and device
>> name is prone errors as it requires maintaining an in kernel
>> database for each SoC.
>
> And here's what I can apply later on to get rid of some
> ifdeffery.
>
> I'm also planning to move some of the legacy omap hwmod
> functionality into proper device drivers, so can generic
> pdata for that too.

Why can't the platform data be moved into the driver given that it
appears to be only SoC family specific? Auxdata was somewhat intended
to be temporary. It appears there is already some per compatible match
data for these OMAP parts in the driver.

Rob

Re: [rfc patch 2/2] rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

[Mike Galbraith]

On Wed, 2016-04-06 at 14:00 +0200, Mike Galbraith wrote:
> It'll take a hotplug beating seemingly as well as any non-rt kernel,
> but big box NAKed it due to jitter, which can mean 1.0 things.. duh.

FWIW, the below turned big box NAK into ACK.  Stressing hotplug over
night, iteration completion time went from about 2 1/2 hours with
bandaids on the two identified rt sore spots, to an hour and 10 minutes
as well for some reason, but whatever..

There are other things like doing the downing on the cpu being taken
down that would likely be a good idea, but I suppose I'll now wait to
see what future devel trees look like.  I suspect Thomas will aim his
axe at the annoying lock too (and his makes clean cuts).  Meanwhile,
just reverting e24b142cfb4a makes hotplug as safe as it ever was (not
at all), slaughtering the lock seems to put current rt on par with non
-rt (iow other changes left not much rt trouble remaining), and the
below is one way to make e24b142cfb4a non-toxic.

-Mike

rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

I met a problem while testing shiny new hotplug machinery.

migrate_disable() -> pin_current_cpu() -> hotplug_lock() leads to..
BUG_ON(rt_mutex_real_waiter(task->pi_blocked_on));

Unpin before we block, and repin while still in atomic context
after acquisition.

Fixes: e24b142cfb4a rt/locking: Reenable migration accross schedule
Signed-off-by: Mike Galbraith 
---
 include/linux/cpu.h  |2 ++
 include/linux/preempt.h  |2 ++
 kernel/cpu.c |   13 +
 kernel/locking/rtmutex.c |   18 +++---
 kernel/sched/core.c  |7 +++
 5 files changed, 35 insertions(+), 7 deletions(-)

--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -231,6 +231,7 @@ extern void put_online_cpus(void);
 extern void cpu_hotplug_disable(void);
 extern void cpu_hotplug_enable(void);
 extern void pin_current_cpu(void);
+extern void pin_current_cpu_in_atomic(void);
 extern void unpin_current_cpu(void);
 #define hotcpu_notifier(fn, pri)   cpu_notifier(fn, pri)
 #define __hotcpu_notifier(fn, pri) __cpu_notifier(fn, pri)
@@ -250,6 +251,7 @@ static inline void cpu_hotplug_done(void
 #define cpu_hotplug_disable()  do { } while (0)
 #define cpu_hotplug_enable()   do { } while (0)
 static inline void pin_current_cpu(void) { }
+static inline void pin_current_cpu_in_atomic(void) { }
 static inline void unpin_current_cpu(void) { }
 #define hotcpu_notifier(fn, pri)   do { (void)(fn); } while (0)
 #define __hotcpu_notifier(fn, pri) do { (void)(fn); } while (0)
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -302,9 +302,11 @@ do { \
 # define preempt_enable_nort() barrier()
 # ifdef CONFIG_SMP
extern void migrate_disable(void);
+   extern void migrate_disable_in_atomic(void);
extern void migrate_enable(void);
 # else /* CONFIG_SMP */
 #  define migrate_disable()barrier()
+#  define migrate_disable_in_atomic()  barrier()
 #  define migrate_enable() barrier()
 # endif /* CONFIG_SMP */
 #else
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -204,6 +204,19 @@ void pin_current_cpu(void)
 }
 
 /**
+ * pin_current_cpu_in_atomic - Prevent the current cpu from being unplugged
+ *
+ * The caller is acquiring a lock, and must have a reference before leaving
+ * the preemption disabled region therein.
+ *
+ * Must be called with preemption disabled (preempt_count = 1)!
+ */
+void pin_current_cpu_in_atomic(void)
+{
+   this_cpu_ptr(_pcp)->refcount++;
+}
+
+/**
  * unpin_current_cpu - Allow unplug of current cpu
  *
  * Must be called with preemption or interrupts disabled!
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1002,11 +1002,17 @@ static void  noinline __sched rt_spin_lo
unsigned long flags;
int ret;
 
+   mg_off &= (self->migrate_disable == 1 && !self->state);
+   if (mg_off)
+   migrate_enable();
+
rt_mutex_init_waiter(, true);
 
raw_spin_lock_irqsave(>wait_lock, flags);
 
if (__try_to_take_rt_mutex(lock, self, NULL, STEAL_LATERAL)) {
+   if (mg_off)
+   migrate_disable_in_atomic();
raw_spin_unlock_irqrestore(>wait_lock, flags);
return;
}
@@ -1029,8 +1035,11 @@ static void  noinline __sched rt_spin_lo
 
for (;;) {
/* Try to acquire the lock again. */
-   if (__try_to_take_rt_mutex(lock, self, , STEAL_LATERAL))
+   if (__try_to_take_rt_mutex(lock, self, , STEAL_LATERAL)) 
{
+   if (mg_off)
+   migrate_disable_in_atomic();
break;
+   }
 
top_waiter = rt_mutex_top_waiter(lock);
lock_owner = rt_mutex_owner(lock);
@@ -1039,13 +1048,8 @@ static void  noinline __sched rt_spin_lo
 
debug_rt_mutex_print_deadlock();
 
-   if 

Re: [rfc patch 2/2] rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

[Mike Galbraith]

On Wed, 2016-04-06 at 14:00 +0200, Mike Galbraith wrote:
> It'll take a hotplug beating seemingly as well as any non-rt kernel,
> but big box NAKed it due to jitter, which can mean 1.0 things.. duh.

FWIW, the below turned big box NAK into ACK.  Stressing hotplug over
night, iteration completion time went from about 2 1/2 hours with
bandaids on the two identified rt sore spots, to an hour and 10 minutes
as well for some reason, but whatever..

There are other things like doing the downing on the cpu being taken
down that would likely be a good idea, but I suppose I'll now wait to
see what future devel trees look like.  I suspect Thomas will aim his
axe at the annoying lock too (and his makes clean cuts).  Meanwhile,
just reverting e24b142cfb4a makes hotplug as safe as it ever was (not
at all), slaughtering the lock seems to put current rt on par with non
-rt (iow other changes left not much rt trouble remaining), and the
below is one way to make e24b142cfb4a non-toxic.

-Mike

rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

I met a problem while testing shiny new hotplug machinery.

migrate_disable() -> pin_current_cpu() -> hotplug_lock() leads to..
BUG_ON(rt_mutex_real_waiter(task->pi_blocked_on));

Unpin before we block, and repin while still in atomic context
after acquisition.

Fixes: e24b142cfb4a rt/locking: Reenable migration accross schedule
Signed-off-by: Mike Galbraith 
---
 include/linux/cpu.h  |2 ++
 include/linux/preempt.h  |2 ++
 kernel/cpu.c |   13 +
 kernel/locking/rtmutex.c |   18 +++---
 kernel/sched/core.c  |7 +++
 5 files changed, 35 insertions(+), 7 deletions(-)

--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -231,6 +231,7 @@ extern void put_online_cpus(void);
 extern void cpu_hotplug_disable(void);
 extern void cpu_hotplug_enable(void);
 extern void pin_current_cpu(void);
+extern void pin_current_cpu_in_atomic(void);
 extern void unpin_current_cpu(void);
 #define hotcpu_notifier(fn, pri)   cpu_notifier(fn, pri)
 #define __hotcpu_notifier(fn, pri) __cpu_notifier(fn, pri)
@@ -250,6 +251,7 @@ static inline void cpu_hotplug_done(void
 #define cpu_hotplug_disable()  do { } while (0)
 #define cpu_hotplug_enable()   do { } while (0)
 static inline void pin_current_cpu(void) { }
+static inline void pin_current_cpu_in_atomic(void) { }
 static inline void unpin_current_cpu(void) { }
 #define hotcpu_notifier(fn, pri)   do { (void)(fn); } while (0)
 #define __hotcpu_notifier(fn, pri) do { (void)(fn); } while (0)
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -302,9 +302,11 @@ do { \
 # define preempt_enable_nort() barrier()
 # ifdef CONFIG_SMP
extern void migrate_disable(void);
+   extern void migrate_disable_in_atomic(void);
extern void migrate_enable(void);
 # else /* CONFIG_SMP */
 #  define migrate_disable()barrier()
+#  define migrate_disable_in_atomic()  barrier()
 #  define migrate_enable() barrier()
 # endif /* CONFIG_SMP */
 #else
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -204,6 +204,19 @@ void pin_current_cpu(void)
 }
 
 /**
+ * pin_current_cpu_in_atomic - Prevent the current cpu from being unplugged
+ *
+ * The caller is acquiring a lock, and must have a reference before leaving
+ * the preemption disabled region therein.
+ *
+ * Must be called with preemption disabled (preempt_count = 1)!
+ */
+void pin_current_cpu_in_atomic(void)
+{
+   this_cpu_ptr(_pcp)->refcount++;
+}
+
+/**
  * unpin_current_cpu - Allow unplug of current cpu
  *
  * Must be called with preemption or interrupts disabled!
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1002,11 +1002,17 @@ static void  noinline __sched rt_spin_lo
unsigned long flags;
int ret;
 
+   mg_off &= (self->migrate_disable == 1 && !self->state);
+   if (mg_off)
+   migrate_enable();
+
rt_mutex_init_waiter(, true);
 
raw_spin_lock_irqsave(>wait_lock, flags);
 
if (__try_to_take_rt_mutex(lock, self, NULL, STEAL_LATERAL)) {
+   if (mg_off)
+   migrate_disable_in_atomic();
raw_spin_unlock_irqrestore(>wait_lock, flags);
return;
}
@@ -1029,8 +1035,11 @@ static void  noinline __sched rt_spin_lo
 
for (;;) {
/* Try to acquire the lock again. */
-   if (__try_to_take_rt_mutex(lock, self, , STEAL_LATERAL))
+   if (__try_to_take_rt_mutex(lock, self, , STEAL_LATERAL)) 
{
+   if (mg_off)
+   migrate_disable_in_atomic();
break;
+   }
 
top_waiter = rt_mutex_top_waiter(lock);
lock_owner = rt_mutex_owner(lock);
@@ -1039,13 +1048,8 @@ static void  noinline __sched rt_spin_lo
 
debug_rt_mutex_print_deadlock();
 
-   if (top_waiter !=  || 

Re: [PATCH 1/2] perf/powerpc: Fix kprobe and kretprobe handling with kallsyms

[Ananth N Mavinakayanahalli]

On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote:

> + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
>   tev->point.offset += PPC64LE_LEP_OFFSET;

uprobes check against kallsysms? Am I missing something here?

Ananth

Re: [PATCH] cpufreq: Rearrange cpufreq_add_dev()

[Viresh Kumar]

On 07-04-16, 03:31, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Reorganize the code in cpufreq_add_dev() to avoid using the ret
> variable and reduce the indentation level in it.
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   26 --
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1311,26 +1311,24 @@ out_free_policy:
>   */
>  static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
>  {
> + struct cpufreq_policy *policy;
>   unsigned cpu = dev->id;
> - int ret;
>  
>   dev_dbg(dev, "%s: adding CPU%u\n", __func__, cpu);
>  
> - if (cpu_online(cpu)) {
> - ret = cpufreq_online(cpu);
> - } else {
> - /*
> -  * A hotplug notifier will follow and we will handle it as CPU
> -  * online then.  For now, just create the sysfs link, unless
> -  * there is no policy or the link is already present.
> -  */
> - struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> + if (cpu_online(cpu))
> + return cpufreq_online(cpu);
>  
> - ret = policy && !cpumask_test_and_set_cpu(cpu, 
> policy->real_cpus)
> - ? add_cpu_dev_symlink(policy, cpu) : 0;
> - }
> + /*
> +  * A hotplug notifier will follow and we will handle it as CPU online
> +  * then.  For now, just create the sysfs link, unless there is no policy
> +  * or the link is already present.
> +  */
> + policy = per_cpu(cpufreq_cpu_data, cpu);
> + if (!policy || cpumask_test_and_set_cpu(cpu, policy->real_cpus))
> + return 0;
>  
> - return ret;
> + return add_cpu_dev_symlink(policy, cpu);
>  }
>  
>  static void cpufreq_offline(unsigned int cpu)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/2] perf/powerpc: Fix kprobe and kretprobe handling with kallsyms

[Ananth N Mavinakayanahalli]

On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote:

> + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
>   tev->point.offset += PPC64LE_LEP_OFFSET;

uprobes check against kallsysms? Am I missing something here?

Ananth

Re: [PATCH] cpufreq: Rearrange cpufreq_add_dev()

[Viresh Kumar]

On 07-04-16, 03:31, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Reorganize the code in cpufreq_add_dev() to avoid using the ret
> variable and reduce the indentation level in it.
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   26 --
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1311,26 +1311,24 @@ out_free_policy:
>   */
>  static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
>  {
> + struct cpufreq_policy *policy;
>   unsigned cpu = dev->id;
> - int ret;
>  
>   dev_dbg(dev, "%s: adding CPU%u\n", __func__, cpu);
>  
> - if (cpu_online(cpu)) {
> - ret = cpufreq_online(cpu);
> - } else {
> - /*
> -  * A hotplug notifier will follow and we will handle it as CPU
> -  * online then.  For now, just create the sysfs link, unless
> -  * there is no policy or the link is already present.
> -  */
> - struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> + if (cpu_online(cpu))
> + return cpufreq_online(cpu);
>  
> - ret = policy && !cpumask_test_and_set_cpu(cpu, 
> policy->real_cpus)
> - ? add_cpu_dev_symlink(policy, cpu) : 0;
> - }
> + /*
> +  * A hotplug notifier will follow and we will handle it as CPU online
> +  * then.  For now, just create the sysfs link, unless there is no policy
> +  * or the link is already present.
> +  */
> + policy = per_cpu(cpufreq_cpu_data, cpu);
> + if (!policy || cpumask_test_and_set_cpu(cpu, policy->real_cpus))
> + return 0;
>  
> - return ret;
> + return add_cpu_dev_symlink(policy, cpu);
>  }
>  
>  static void cpufreq_offline(unsigned int cpu)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: Simplify switch () in cpufreq_cpu_callback()

[Viresh Kumar]

On 07-04-16, 03:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Merge two switch entries that do the same thing in
> cpufreq_cpu_callback().
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -2312,16 +2312,13 @@ static int cpufreq_cpu_callback(struct n
>  
>   switch (action & ~CPU_TASKS_FROZEN) {
>   case CPU_ONLINE:
> + case CPU_DOWN_FAILED:
>   cpufreq_online(cpu);
>   break;
>  
>   case CPU_DOWN_PREPARE:
>   cpufreq_offline(cpu);
>   break;
> -
> - case CPU_DOWN_FAILED:
> - cpufreq_online(cpu);
> - break;
>   }
>   return NOTIFY_OK;
>  }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: Simplify switch () in cpufreq_cpu_callback()

[Viresh Kumar]

On 07-04-16, 03:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Merge two switch entries that do the same thing in
> cpufreq_cpu_callback().
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -2312,16 +2312,13 @@ static int cpufreq_cpu_callback(struct n
>  
>   switch (action & ~CPU_TASKS_FROZEN) {
>   case CPU_ONLINE:
> + case CPU_DOWN_FAILED:
>   cpufreq_online(cpu);
>   break;
>  
>   case CPU_DOWN_PREPARE:
>   cpufreq_offline(cpu);
>   break;
> -
> - case CPU_DOWN_FAILED:
> - cpufreq_online(cpu);
> - break;
>   }
>   return NOTIFY_OK;
>  }

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

[Viresh Kumar]

On 07-04-16, 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Since governor operations are generally skipped if cpufreq_suspended
> is set, do nothing at all in cpufreq_start_governor() and
> cpufreq_exit_governor() in that case.
> 
> In particular, this prevents fast frequency switching from being
> disabled after a suspend-to-RAM cycle on all CPUs except for the
> boot one.

static int cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
{
int ret;

/* Don't start any governor operations if we are entering suspend */
if (cpufreq_suspended)
return 0;

...

}

Above already guarantees that we would start/stop governors. Why do we
need this change then ?


-- 
viresh

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

[Viresh Kumar]

On 07-04-16, 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Since governor operations are generally skipped if cpufreq_suspended
> is set, do nothing at all in cpufreq_start_governor() and
> cpufreq_exit_governor() in that case.
> 
> In particular, this prevents fast frequency switching from being
> disabled after a suspend-to-RAM cycle on all CPUs except for the
> boot one.

static int cpufreq_governor(struct cpufreq_policy *policy, unsigned int event)
{
int ret;

/* Don't start any governor operations if we are entering suspend */
if (cpufreq_suspended)
return 0;

...

}

Above already guarantees that we would start/stop governors. Why do we
need this change then ?


-- 
viresh

Haswell IOMMU bug that gets no response from maintainers

[Alexander E. Patrakov]

Hello.

In August 2013, I have reported this bug: 
https://bugzilla.kernel.org/show_bug.cgi?id=60769 . It has been 
determined on October 2013 to be a bug with IOMMU. The bug manifests 
itself as either unreliable or completely non-working HDMI audio on 
Haswell systems.


However, there have been no reaction of IOMMU experts to the bug, except 
two messages from David Woodhouse in November 2013. On PulseAudio 
mailing list and IRC channel we still have affected users (who blame 
PulseAudio and thus spread FUD), and I myself have to apply the 
"iommu=on,igfx_off" workaround.


Where and how do I escalate the bug? What other info (except DMAR dumps 
which are already in the bug) is needed?


--
Alexander E. Patrakov

Haswell IOMMU bug that gets no response from maintainers

[Alexander E. Patrakov]

Hello.

In August 2013, I have reported this bug: 
https://bugzilla.kernel.org/show_bug.cgi?id=60769 . It has been 
determined on October 2013 to be a bug with IOMMU. The bug manifests 
itself as either unreliable or completely non-working HDMI audio on 
Haswell systems.


However, there have been no reaction of IOMMU experts to the bug, except 
two messages from David Woodhouse in November 2013. On PulseAudio 
mailing list and IRC channel we still have affected users (who blame 
PulseAudio and thus spread FUD), and I myself have to apply the 
"iommu=on,igfx_off" workaround.


Where and how do I escalate the bug? What other info (except DMAR dumps 
which are already in the bug) is needed?


--
Alexander E. Patrakov

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

[Yakir Yang]

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
 };
 
 enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
 };
 
 struct video_info {
-- 
1.9.1

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

[Yakir Yang]

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
 };
 
 enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
 };
 
 struct video_info {
-- 
1.9.1

Re: [PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

[Yakir Yang]

Sorry for disturb, I make a mistaken about the
receive list, please ignore this email.

- Yakir

On 04/07/2016 12:15 PM, Yakir Yang wrote:

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
  };
  
  enum dp_irq_type {

-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
  };
  
  struct video_info {

Re: [PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

[Yakir Yang]

Sorry for disturb, I make a mistaken about the
receive list, please ignore this email.

- Yakir

On 04/07/2016 12:15 PM, Yakir Yang wrote:

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
  };
  
  enum dp_irq_type {

-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
  };
  
  struct video_info {

Re: [PATCH] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

[kbuild test robot]

Hi Yong,

[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.6-rc2 next-20160406]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Yong-Li/gpio-pca953x-add-PCAL9535-interrupt-support-for-Galileo-Gen2/20160407-102414
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpio/gpio-pca953x.c:522:10-11: WARNING: return of 0/1 in function 
>> 'pca953x_irq_pending' with return type bool

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

[kbuild test robot]

Hi Yong,

[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.6-rc2 next-20160406]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Yong-Li/gpio-pca953x-add-PCAL9535-interrupt-support-for-Galileo-Gen2/20160407-102414
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpio/gpio-pca953x.c:522:10-11: WARNING: return of 0/1 in function 
>> 'pca953x_irq_pending' with return type bool

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] gpio: pca953x: fix boolreturn.cocci warnings

[kbuild test robot]

drivers/gpio/gpio-pca953x.c:522:10-11: WARNING: return of 0/1 in function 
'pca953x_irq_pending' with return type bool

 Return statements in functions returning bool should use
 true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci

CC: Yong Li 
Signed-off-by: Fengguang Wu 
---

 gpio-pca953x.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -519,12 +519,12 @@ static bool pca953x_irq_pending(struct p
/* Read the current interrupt status from the device */
ret = pca953x_read_regs(chip, PCAL953X_INT_STAT, trigger);
if (ret)
-   return 0;
+   return false;
 
/* Check latched inputs and clear interrupt status */
ret = pca953x_read_regs(chip, PCA953X_INPUT, cur_stat);
if (ret)
-   return 0;
+   return false;
 
for (i = 0; i < NBANK(chip); i++) {
/* Apply filter for rising/falling edge selection */

[PATCH] gpio: pca953x: fix boolreturn.cocci warnings

[kbuild test robot]

drivers/gpio/gpio-pca953x.c:522:10-11: WARNING: return of 0/1 in function 
'pca953x_irq_pending' with return type bool

 Return statements in functions returning bool should use
 true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci

CC: Yong Li 
Signed-off-by: Fengguang Wu 
---

 gpio-pca953x.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -519,12 +519,12 @@ static bool pca953x_irq_pending(struct p
/* Read the current interrupt status from the device */
ret = pca953x_read_regs(chip, PCAL953X_INT_STAT, trigger);
if (ret)
-   return 0;
+   return false;
 
/* Check latched inputs and clear interrupt status */
ret = pca953x_read_regs(chip, PCA953X_INPUT, cur_stat);
if (ret)
-   return 0;
+   return false;
 
for (i = 0; i < NBANK(chip); i++) {
/* Apply filter for rising/falling edge selection */

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

[Yakir Yang]

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
 };
 
 enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
 };
 
 struct video_info {
-- 
1.9.1

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

[Yakir Yang]

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only
send drm hp event when the irq_type and the enum value is true.

if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...)
drm_helper_hpd_irq_event(dp->drm_dev);

So there would no drm hpd event when cable plug in, to fix that
just need to assign all hotplug enum with no-zero values.

Reported-by: Dan Carpenter 
Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index f09275d..b456380 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -127,10 +127,10 @@ enum analog_power_block {
 };
 
 enum dp_irq_type {
-   DP_IRQ_TYPE_HP_CABLE_IN,
-   DP_IRQ_TYPE_HP_CABLE_OUT,
-   DP_IRQ_TYPE_HP_CHANGE,
-   DP_IRQ_TYPE_UNKNOWN,
+   DP_IRQ_TYPE_HP_CABLE_IN  = BIT(0),
+   DP_IRQ_TYPE_HP_CABLE_OUT = BIT(1),
+   DP_IRQ_TYPE_HP_CHANGE= BIT(2),
+   DP_IRQ_TYPE_UNKNOWN  = BIT(3),
 };
 
 struct video_info {
-- 
1.9.1

Re: [PATCH 09/27] target: use bio_is_full()

[Ming Lei]

On Tue, Apr 5, 2016 at 9:02 PM, Christoph Hellwig  wrote:
> On Tue, Apr 05, 2016 at 07:56:54PM +0800, Ming Lei wrote:
>> +++ b/drivers/target/target_core_pscsi.c
>> @@ -951,7 +951,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist 
>> *sgl, u32 sgl_nents,
>>   pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
>>   bio->bi_vcnt, nr_vecs);
>>
>> - if (bio->bi_vcnt > nr_vecs) {
>> + if (bio_is_full(bio)) {
>>   pr_debug("PSCSI: Reached bio->bi_vcnt max:"
>>   " %d i: %d bio: %p, allocating another"
>>   " bio\n", bio->bi_vcnt, i, bio);
>
> This check should be removed entirely - bio_add_pc_page takes care of
> it.

OK.


-- 
Ming Lei

Re: [PATCH 09/27] target: use bio_is_full()

[Ming Lei]

On Tue, Apr 5, 2016 at 9:02 PM, Christoph Hellwig  wrote:
> On Tue, Apr 05, 2016 at 07:56:54PM +0800, Ming Lei wrote:
>> +++ b/drivers/target/target_core_pscsi.c
>> @@ -951,7 +951,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist 
>> *sgl, u32 sgl_nents,
>>   pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
>>   bio->bi_vcnt, nr_vecs);
>>
>> - if (bio->bi_vcnt > nr_vecs) {
>> + if (bio_is_full(bio)) {
>>   pr_debug("PSCSI: Reached bio->bi_vcnt max:"
>>   " %d i: %d bio: %p, allocating another"
>>   " bio\n", bio->bi_vcnt, i, bio);
>
> This check should be removed entirely - bio_add_pc_page takes care of
> it.

OK.


-- 
Ming Lei

RE: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Koul, Vinod [mailto:vinod.k...@intel.com]
> Sent: Thursday, April 07, 2016 5:53 AM
> To: Soren Brinkmann 
> Cc: l...@metafoo.de; linux-kernel@vger.kernel.org; pawel.m...@arm.com;
> Appana Durga Kedareswara Rao ;
> l...@debethencourt.com; moritz.fisc...@ettus.com; robh...@kernel.org;
> Srikanth Vemula ; Michal Simek ;
> Anirudha Sarangi ; devicet...@vger.kernel.org; Soren
> Brinkmann ; Williams, Dan J ;
> mark.rutl...@arm.com; ga...@codeaurora.org; ijc+devicet...@hellion.org.uk;
> dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> laurent.pinch...@ideasonboard.com
> Subject: Re: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan
> prefix to dma-chan
> 
> On Wed, 2016-04-06 at 16:00 -0700, Sören Brinkmann wrote:
> > On Wed, 2016-04-06 at 22:13:59 +, Koul, Vinod wrote:
> > > On Wed, 2016-04-06 at 23:16 +0200, Lars-Peter Clausen wrote:
> > > > On 04/06/2016 06:25 PM, Appana Durga Kedareswara Rao wrote:
> > > > > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > > > > +++
> > > > > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.t
> > > > > > > xt
> > > > > > > @@ -24,8 +24,8 @@ Optional properties:
> > > > > > >   {3}, flush s2mm channel
> > > > > > >
> > > > > > >  Required child node properties:
> > > > > > > -- compatible: It should be either "xlnx,axi-vdma-mm2s
> > > > > > > -channel"
> > > > > > > or
> > > > > > > - "xlnx,axi-vdma-s2mm-channel".
> > > > > > > +- compatible: It should be either "xlnx,axi-dma-mm2s
> > > > > > > -channel"
> > > > > > > or
> > > > > > > + "xlnx,axi-dma-s2mm-channel".
> > > > > >
> > > > > > This change is not backwards compatible and breaks every user
> > > > > > of the current binding.
> > > > >
> > > > > This commit
> > > > > http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-
> > > > >
> dma.git/commit/?h=next=8e66e7d682b04f7141f8ae666908c8dcd7fc0b
> > > > > fa
> > > > > Renames xilinx_vdma_ prefix to xilinx_dma which includes
> > > > > renaming of the above properties.
> > >
> > > That patch changes driver from vdma to dma. It does not change
> > > property name!
> >
> > It does. Unfortunately there are no line numbers on that website,
> > hence here an excerpt from the commit you mention:
> > @@ -1220,26 +1220,26 @@ static int xilinx_vdma_chan_probe(struct
> > xilinx_vdma_device *xdev,
> > if (!has_dre)
> > xdev->common.copy_align = fls(width - 1);
> >
> > -   if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s
> > -channel")) {
> > +   if (of_device_is_compatible(node, "xlnx,axi-dma-mm2s
> > -channel")) {
> > chan->direction = DMA_MEM_TO_DEV;
> > chan->id = 0;
> 
> Right, missed that somehow.
> 
> Am dropping the patch

Will fix this part and will include this patch in v4 series...

Regards,
Kedar.

> 
> --
> ~Vinod

RE: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Koul, Vinod [mailto:vinod.k...@intel.com]
> Sent: Thursday, April 07, 2016 5:53 AM
> To: Soren Brinkmann 
> Cc: l...@metafoo.de; linux-kernel@vger.kernel.org; pawel.m...@arm.com;
> Appana Durga Kedareswara Rao ;
> l...@debethencourt.com; moritz.fisc...@ettus.com; robh...@kernel.org;
> Srikanth Vemula ; Michal Simek ;
> Anirudha Sarangi ; devicet...@vger.kernel.org; Soren
> Brinkmann ; Williams, Dan J ;
> mark.rutl...@arm.com; ga...@codeaurora.org; ijc+devicet...@hellion.org.uk;
> dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> laurent.pinch...@ideasonboard.com
> Subject: Re: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan
> prefix to dma-chan
> 
> On Wed, 2016-04-06 at 16:00 -0700, Sören Brinkmann wrote:
> > On Wed, 2016-04-06 at 22:13:59 +, Koul, Vinod wrote:
> > > On Wed, 2016-04-06 at 23:16 +0200, Lars-Peter Clausen wrote:
> > > > On 04/06/2016 06:25 PM, Appana Durga Kedareswara Rao wrote:
> > > > > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > > > > +++
> > > > > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.t
> > > > > > > xt
> > > > > > > @@ -24,8 +24,8 @@ Optional properties:
> > > > > > >   {3}, flush s2mm channel
> > > > > > >
> > > > > > >  Required child node properties:
> > > > > > > -- compatible: It should be either "xlnx,axi-vdma-mm2s
> > > > > > > -channel"
> > > > > > > or
> > > > > > > - "xlnx,axi-vdma-s2mm-channel".
> > > > > > > +- compatible: It should be either "xlnx,axi-dma-mm2s
> > > > > > > -channel"
> > > > > > > or
> > > > > > > + "xlnx,axi-dma-s2mm-channel".
> > > > > >
> > > > > > This change is not backwards compatible and breaks every user
> > > > > > of the current binding.
> > > > >
> > > > > This commit
> > > > > http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-
> > > > >
> dma.git/commit/?h=next=8e66e7d682b04f7141f8ae666908c8dcd7fc0b
> > > > > fa
> > > > > Renames xilinx_vdma_ prefix to xilinx_dma which includes
> > > > > renaming of the above properties.
> > >
> > > That patch changes driver from vdma to dma. It does not change
> > > property name!
> >
> > It does. Unfortunately there are no line numbers on that website,
> > hence here an excerpt from the commit you mention:
> > @@ -1220,26 +1220,26 @@ static int xilinx_vdma_chan_probe(struct
> > xilinx_vdma_device *xdev,
> > if (!has_dre)
> > xdev->common.copy_align = fls(width - 1);
> >
> > -   if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s
> > -channel")) {
> > +   if (of_device_is_compatible(node, "xlnx,axi-dma-mm2s
> > -channel")) {
> > chan->direction = DMA_MEM_TO_DEV;
> > chan->id = 0;
> 
> Right, missed that somehow.
> 
> Am dropping the patch

Will fix this part and will include this patch in v4 series...

Regards,
Kedar.

> 
> --
> ~Vinod