[PATCH v9 05/16] clk: exynos: add gate clock descriptions of System MMU

[Cho KyongHo]

This adds gate clocks of all System MMUs and their master IPs
that are not apeared in clk-exynos5250.c
Also fixes GATE_IP_ACP to 0x18800 and changed GATE_DA to GATE
for System MMU clocks in clk-exynos4.c

Signed-off-by: Cho KyongHo 
---
 .../devicetree/bindings/clock/exynos5250-clock.txt |   26 +
 drivers/clk/samsung/clk-exynos4.c  |   27 +++--
 drivers/clk/samsung/clk-exynos5250.c   |   57 
 3 files changed, 82 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 24765c1..9c76710 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -159,6 +159,32 @@ clock which they consume.
   mixer343
   hdmi 344
   g2d  345
+  smmu_fimc_lite0  346
+  smmu_fimc_lite1  347
+  smmu_fimc_lite2  348
+  smmu_tv  349
+  smmu_fimd1   350
+  smmu_2d  351
+  fimc_isp 352
+  fimc_drc 353
+  fimc_fd  354
+  fimc_scc 355
+  fimc_scp 356
+  fimc_mcuctl  357
+  fimc_odc 358
+  fimc_dis 359
+  fimc_3dnr360
+  smmu_fimc_isp361
+  smmu_fimc_drc362
+  smmu_fimc_fd 363
+  smmu_fimc_scc364
+  smmu_fimc_scp365
+  smmu_fimc_mcuctl 366
+  smmu_fimc_odc367
+  smmu_fimc_dis0   368
+  smmu_fimc_dis1   369
+  smmu_fimc_3dnr   370
+  camif_top371
 
 
[Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 68f9a4a..92dcf03 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -705,29 +705,20 @@ static struct samsung_gate_clock exynos4_gate_clks[] 
__initdata = {
GATE_IP_CAM, 4, 0, 0, "fimc"),
GATE_DA(csis1, "s5p-mipi-csis.1", "csis1", "aclk160",
GATE_IP_CAM, 5, 0, 0, "fimc"),
-   GATE_DA(smmu_fimc0, "exynos-sysmmu.5", "smmu_fimc0", "aclk160",
-   GATE_IP_CAM, 7, 0, 0, "sysmmu"),
-   GATE_DA(smmu_fimc1, "exynos-sysmmu.6", "smmu_fimc1", "aclk160",
-   GATE_IP_CAM, 8, 0, 0, "sysmmu"),
-   GATE_DA(smmu_fimc2, "exynos-sysmmu.7", "smmu_fimc2", "aclk160",
-   GATE_IP_CAM, 9, 0, 0, "sysmmu"),
-   GATE_DA(smmu_fimc3, "exynos-sysmmu.8", "smmu_fimc3", "aclk160",
-   GATE_IP_CAM, 10, 0, 0, "sysmmu"),
-   GATE_DA(smmu_jpeg, "exynos-sysmmu.3", "smmu_jpeg", "aclk160",
-   GATE_IP_CAM, 11, 0, 0, "sysmmu"),
+   GATE(smmu_fimc0, "smmu_fimc0", "aclk160", GATE_IP_CAM, 7, 0, 0),
+   GATE(smmu_fimc1, "smmu_fimc1", "aclk160", GATE_IP_CAM, 8, 0, 0),
+   GATE(smmu_fimc2, "smmu_fimc2", "aclk160", GATE_IP_CAM, 9, 0, 0),
+   GATE(smmu_fimc3, "smmu_fimc3", "aclk160", GATE_IP_CAM, 10, 0, 0),
+   GATE(smmu_jpeg, "smmu_jpeg", "aclk160", GATE_IP_CAM, 11, 0, 0),
GATE(pixelasyncm0, "pxl_async0", "aclk160", GATE_IP_CAM, 17, 0, 0),
GATE(pixelasyncm1, "pxl_async1", "aclk160", GATE_IP_CAM, 18, 0, 0),
-   GATE_DA(smmu_tv, "exynos-sysmmu.2", "smmu_tv", "aclk160",
-   GATE_IP_TV, 4, 0, 0, "sysmmu"),
+   GATE(smmu_tv, "smmu_tv", "aclk160", GATE_IP_TV, 4, 0, 0),
GATE_DA(mfc, "s5p-mfc", "mfc", "aclk100", GATE_IP_MFC, 0, 0, 0, "mfc"),
-   GATE_DA(smmu_mfcl, "exynos-sysmmu.0", "smmu_mfcl", "aclk100",
-   GATE_IP_MFC, 1, 0, 0, "sysmmu"),
-   GATE_DA(smmu_mfcr, "exynos-sysmmu.1", "smmu_mfcr", "aclk100",
-   GATE_IP_MFC, 2, 0, 0, "sysmmu"),
+   GATE(smmu_mfcl, "smmu_mfcl", "aclk100", GATE_IP_MFC, 1, 0, 0),
+   GATE(smmu_mfcr, "smmu_mfcr", "aclk100", GATE_IP_MFC, 2, 0, 0),
GATE_DA(fimd0, "exynos4-fb.0", "fimd0", "aclk160",
GATE_IP_LCD0, 0, 0, 0, "fimd"),
-   GATE_DA(smmu_fimd0, "exynos-sysmmu.10", "smmu_fimd0", "aclk160",
-   GATE_IP_LCD0, 4, 0, 0, "sysmmu"),
+   GATE(smmu_fimd0, "smmu_fimd0", "aclk160", GATE_IP_LCD0, 4, 0, 0),
GATE_DA(pdma0, "dma-pl330.0", "pdma0", "aclk133",
GATE_IP_FSYS, 0, 0, 0, "dma"),
GATE_DA(pdma1, "dma-pl330.1", "pdma1", "aclk133",
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index df3628c..e945fcf 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -64,6 +64,8 @@
 #define DIV_PERIC3 0x10564
 #define DIV_PERIC4 0x10568
 #define DIV_PERIC5 0x1056c
+#define GATE_IP_ISP0   0x0C800
+#define GATE_IP_ISP1   0x0C800
 #define GATE_IP_GSCL   0x10920
 #define GATE_IP_MFC   

[PATCH v3 1/1] input: ideapad_slidebar: new input driver

[Andrey Moiseev]

v3: i8042 filter instead of direct keyboard access

ideapad_slidebar is a new driver which enables slidebars on some
Lenovo IdeaPad laptops (the slidebars work with SlideNav/Desktop
Navigator under Windows)

Fixes this: https://bugzilla.kernel.org/show_bug.cgi?id=16004

Registers 'IdeaPad Slidebar' input device and
/sys/devices/platform/ideapad_slidebar/slidebar_mode
for switching slidebar's modes.

Now works on:
IdeaPad Y550, Y550P.

May work on (testing and adding new models is needed):
Ideapad Y560, Y460, Y450, Y650,
and, probably, some others.

Driver source: https://github.com/o2genum/ideapad-slidebar.git

Patch is generated against current mainline kernel.

Signed-off-by: Andrey Moiseev 
---
 MAINTAINERS   |   7 +
 drivers/input/misc/Kconfig|   9 +
 drivers/input/misc/Makefile   |   1 +
 drivers/input/misc/ideapad_slidebar.c | 377 ++
 4 files changed, 394 insertions(+)
 create mode 100644 drivers/input/misc/ideapad_slidebar.c

diff --git a/MAINTAINERS b/MAINTAINERS
index defc053..2ff3dd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4096,6 +4096,13 @@ W:   http://launchpad.net/ideapad-laptop
 S: Maintained
 F: drivers/platform/x86/ideapad-laptop.c
 
+IDEAPAD LAPTOP SLIDEBAR DRIVER
+M: Andrey Moiseev 
+L: linux-in...@vger.kernel.org
+W: https://github.com/o2genum/ideapad-slidebar
+S: Maintained
+F: drivers/input/misc/ideapad_slidebar.c
+
 IDE/ATAPI DRIVERS
 M: Borislav Petkov 
 L: linux-...@vger.kernel.org
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 0b541cd..45729a9 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -647,4 +647,13 @@ config INPUT_SIRFSOC_ONKEY
 
  If unsure, say N.
 
+config INPUT_IDEAPAD_SLIDEBAR
+   tristate "IdeaPad Laptop Slidebar"
+   depends on INPUT
+   help
+ Input driver for slidebars on some Lenovo IdeaPad laptops.
+
+ If you have an IdeaPad laptop with a slidebar, say Y or M here.
+ Module name is ideapad_slidebar.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 829de43..0ebfb6d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -61,3 +61,4 @@ obj-$(CONFIG_INPUT_WISTRON_BTNS)  += wistron_btns.o
 obj-$(CONFIG_INPUT_WM831X_ON)  += wm831x-on.o
 obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
 obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
+obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)   += ideapad_slidebar.o
diff --git a/drivers/input/misc/ideapad_slidebar.c 
b/drivers/input/misc/ideapad_slidebar.c
new file mode 100644
index 000..c5b201f
--- /dev/null
+++ b/drivers/input/misc/ideapad_slidebar.c
@@ -0,0 +1,377 @@
+/*
+ * Input driver for slidebars on some Lenovo IdeaPad laptops
+ *
+ * Copyright (C) 2013 Andrey Moiseev 
+ *
+ * Reverse-engineered from Lenovo SlideNav software (SBarHook.dll).
+ *
+ * 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 (at your option)
+ * any later version.
+ *
+ * Trademarks are the property of their respective owners.
+ */
+
+/* Currently tested and works on:
+ * Lenovo IdeaPad Y550
+ * Lenovo IdeaPad Y550P
+ *
+ * Other models can be added easily. To test,
+ * load with 'force' parameter set 'true'.
+ *
+ * LEDs blinking and input mode are managed via sysfs,
+ * (hex, unsigned byte value):
+ * /sys/devices/platform/ideapad_slidebar/slidebar_mode
+ *
+ * The value is in byte range, however, I only figured out
+ * how bits 0b10011001 work. Some other bits, probably,
+ * are meaningfull too.
+ *
+ * Possible states:
+ *
+ * STD_INT, ONMOV_INT, OFF_INT, LAST_POLL, OFF_POLL
+ *
+ * Meaning:
+ *   released  touched
+ * STD   'heartbeat'   lights follow the finger
+ * ONMOV no lights lights follow the finger
+ * LAST  at last pos   lights follow the finger
+ * OFF   no lights no lights
+ *
+ * INT   all input events are generated, interrupts are used
+ * POLL  no input events by default, to get them,
+ *  send 0b1000 (read below)
+ *
+ * Commands: write
+ *
+ * All  |  0b01001 -> STD_INT
+ * possible |  0b10001 -> ONMOV_INT
+ * states   |  0b01000 -> OFF_INT
+ *
+ *  |  0b0 -> LAST_POLL
+ * STD_INT or ONMOV_INT |
+ *  |  0b1 -> STD_INT
+ *
+ *  |  0b0 -> OFF_POLL
+ * OFF_INT or OFF_POLL  |
+ *  |  0b1 -> OFF_INT
+ *
+ * Any state |   0b1000 ->  if the slidebar has updated data,
+ * produce one input event (last position),
+ * switch to respective POLL mode
+ * (like 0x0), if not in POLL mode yet.
+ *
+ * Get current state: read
+ *
+ * masked by 0x11 read 

[PATCH v9 02/16] iommu/exynos: add missing cache flush for removed page table entries

[Cho KyongHo]

This commit adds cache flush for removed small and large page entries
in exynos_iommu_unmap(). Missing cache flush of removed page table
entries can cause missing page fault interrupt when a master IP
accesses an unmapped area.

Tested-by: Grant Grundler 
Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 233f382..d545a25 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1002,6 +1002,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
if (lv2ent_small(ent)) {
*ent = 0;
size = SPAGE_SIZE;
+   pgtable_flush(ent, ent + 1);
priv->lv2entcnt[lv1ent_offset(iova)] += 1;
goto done;
}
@@ -1010,6 +1011,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
BUG_ON(size < LPAGE_SIZE);
 
memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
+   pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
 
size = LPAGE_SIZE;
priv->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 01/16] iommu/exynos: do not include removed header

[Cho KyongHo]

This commit remove  which is removed.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 3f32d64..233f382 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -12,6 +12,7 @@
 #define DEBUG
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -29,8 +30,6 @@
 #include 
 #include 
 
-#include 
-
 /* We does not consider super section mapping (16MB) */
 #define SECT_ORDER 20
 #define LPAGE_ORDER 16
-- 
1.7.2.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 03/16] iommu/exynos: fix page table maintenance

[Cho KyongHo]

This prevents allocating lv2 page table for the lv1 page table entry
that already has 1MB page mapping. In addition, changed to BUG_ON
instead of returning -EADDRINUSE.

Signed-off-by: Cho KyongHo 
---
 drivers/iommu/exynos-iommu.c |   68 -
 1 files changed, 40 insertions(+), 28 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index d545a25..d90e6fa 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -52,11 +52,11 @@
 #define lv2ent_large(pent) ((*(pent) & 3) == 1)
 
 #define section_phys(sent) (*(sent) & SECT_MASK)
-#define section_offs(iova) ((iova) & 0xF)
+#define section_offs(iova) ((iova) & ~SECT_MASK)
 #define lpage_phys(pent) (*(pent) & LPAGE_MASK)
-#define lpage_offs(iova) ((iova) & 0x)
+#define lpage_offs(iova) ((iova) & ~LPAGE_MASK)
 #define spage_phys(pent) (*(pent) & SPAGE_MASK)
-#define spage_offs(iova) ((iova) & 0xFFF)
+#define spage_offs(iova) ((iova) & ~SPAGE_MASK)
 
 #define lv1ent_offset(iova) ((iova) >> SECT_ORDER)
 #define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER)
@@ -856,13 +856,15 @@ finish:
 static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long iova,
short *pgcounter)
 {
+   BUG_ON(lv1ent_section(sent));
+
if (lv1ent_fault(sent)) {
unsigned long *pent;
 
pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
BUG_ON((unsigned long)pent & (LV2TABLE_SIZE - 1));
if (!pent)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
*sent = mk_lv1ent_page(__pa(pent));
*pgcounter = NUM_LV2ENTRIES;
@@ -875,15 +877,11 @@ static unsigned long *alloc_lv2entry(unsigned long *sent, 
unsigned long iova,
 
 static int lv1set_section(unsigned long *sent, phys_addr_t paddr, short *pgcnt)
 {
-   if (lv1ent_section(sent))
-   return -EADDRINUSE;
+   BUG_ON(lv1ent_section(sent));
 
if (lv1ent_page(sent)) {
-   if (*pgcnt != NUM_LV2ENTRIES)
-   return -EADDRINUSE;
-
+   BUG_ON(*pgcnt != NUM_LV2ENTRIES);
kfree(page_entry(sent, 0));
-
*pgcnt = 0;
}
 
@@ -894,24 +892,24 @@ static int lv1set_section(unsigned long *sent, 
phys_addr_t paddr, short *pgcnt)
return 0;
 }
 
+static void clear_page_table(unsigned long *ent, int n)
+{
+   if (n > 0)
+   memset(ent, 0, sizeof(*ent) * n);
+}
+
 static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
short *pgcnt)
 {
if (size == SPAGE_SIZE) {
-   if (!lv2ent_fault(pent))
-   return -EADDRINUSE;
-
+   BUG_ON(!lv2ent_fault(pent));
*pent = mk_lv2ent_spage(paddr);
pgtable_flush(pent, pent + 1);
*pgcnt -= 1;
} else { /* size == LPAGE_SIZE */
int i;
for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
-   if (!lv2ent_fault(pent)) {
-   memset(pent, 0, sizeof(*pent) * i);
-   return -EADDRINUSE;
-   }
-
+   BUG_ON(!lv2ent_fault(pent));
*pent = mk_lv2ent_lpage(paddr);
}
pgtable_flush(pent - SPAGES_PER_LPAGE, pent);
@@ -944,17 +942,16 @@ static int exynos_iommu_map(struct iommu_domain *domain, 
unsigned long iova,
pent = alloc_lv2entry(entry, iova,
>lv2entcnt[lv1ent_offset(iova)]);
 
-   if (!pent)
-   ret = -ENOMEM;
+   if (IS_ERR(pent))
+   ret = PTR_ERR(pent);
else
ret = lv2set_page(pent, paddr, size,
>lv2entcnt[lv1ent_offset(iova)]);
}
 
-   if (ret) {
-   pr_debug("%s: Failed to map iova 0x%lx/0x%x bytes\n",
-   __func__, iova, size);
-   }
+   if (ret)
+   pr_err("%s: Failed(%d) to map 0x%#x bytes @ %#lx\n",
+   __func__, ret, size, iova);
 
spin_unlock_irqrestore(>pgtablelock, flags);
 
@@ -968,6 +965,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
struct sysmmu_drvdata *data;
unsigned long flags;
unsigned long *ent;
+   size_t err_pgsize;
 
BUG_ON(priv->pgtable == NULL);
 
@@ -976,7 +974,10 @@ static size_t exynos_iommu_unmap(struct iommu_domain 
*domain,
ent = section_entry(priv->pgtable, iova);
 
if (lv1ent_section(ent)) {
-   BUG_ON(size < SECT_SIZE);
+   if (WARN_ON(size < SECT_SIZE)) {
+   err_pgsize = 

[PATCH v9 00/16] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

[Cho KyongHo]

The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because a System MMU resides in the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.

This set of changes solves the above problem with setting each System MMUs
as the parent of the device which owns the System MMU to receive the
information when the device is turned off or turned on.

Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt

In addition, this patchset also includes several bug fixes and enhancements
of the current driver.

Change log:
v9:
- Rebased on the following branches
  git.linaro.org/git-ro/people/mturquette/linux.git/clk-next
  git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/samsung-next
  git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master (3.11-rc4)
- Split "add bus notifier for registering System MMU" into 5 patches
- Call clk_prepare() that was missing in v8.
- Fixed base address of sysmmu_tv in exynos4210.dtsi
- BUG_ON() instead of return -EADDRINUSE when trying mapping on an mapped area
- Moved camif_top to 317 in drivers/clk/samsung/clk-exynos5250.c
- Removed 'iommu' property from 'codec'(mfc) node
- Does not make 'master' clock to be the parent of 'sysmmu' clock.
   'master' clock is enabled before accessing control registers of System MMU
   and disabled after the access.

v8:
- Reordered patch list: moved "change rwloc to spinlock" to the last.
- Fixed remained bug in "fix page table maintenance".
- Always return 0 from exynos_iommu_attach_device().
- Removed prefetch buffer setting when System MMU is enabled
  due to the restriction of prefetch buffers:
  A prefetch buffer must not hit from more than one DMA.
  For instance with GScalers, if a single prefetch buffer is initialized
  with 0x0 ~ 0x and a GScaler works on source buffer at 0x1000
  and target buffer @ 0x2000, the System MMU may be got deadlock.
  Clients must initialize prefetch buffers with custom function defined
  in exynos-iommu drivers whenever they need to enable prefetch buffers.
- The clock of System MMU has no relationship with the clock of its master H/W.
  The clock of master H/W is always enabled when exynos-iommu driver needs to
  access MMIO area and disabled as soon as the access finishes.
- Removed err_page variable used in exynos_iommu_unmap() in the previous patch
  "fix page table maintenance".
- Split a big patch "add bus notifier for registering System MMU".
   Extracted the following 2 patches: 9/12 and 10/12.
- And some additional fixes...

v7:
- Rebased on the stable 3.10
- Registered PM domains and gate clocks with DT
- Changed connection method between a System MMU and its master H/W
   'mmu-master' property in the node of System MMU
   --> 'iommu' property in the node of master H/W
- Marking device descriptor of master H/W of a System MMU with bus notifier.
- Power management (PM_RUNTIME, PM_SLEEP) of System MMUs with gpd_dev_ops
   of Generic IO Powerdomain. gpd_dev_ops are set to the master H/Ws
   before they are probed in the bus notifier.
- Removed additional debugging features like debugfs entries and
   version names.
- Removed support for advanced features of System MMU 3.2 and 3.3
   the current IOMMU API cannot handle the feature
  (A kind of L2 TLB that fetches several consequence page table entries.
   It must be initialized by the driver of master H/W whenever it works.)

v6:
- Rebased on the branch, next/iommu-exynos of
  git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git

v5:
- new bugfix: patch 01
- Reordered patches
  * patch 01 ~ 05: Bugfix and enhancements of the existing driver
  * patch 06 ~ 10: Device Tree support and callbacks for power management
  * patch 11 : System MMU 3.2 and 3.3 support
  * patch 12 ~ 14: Debugging features
- Additional code compaction

v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
  Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to client
  device if the client device has multiple System MMUs.
  Thanks to Rahul Sharma.

v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
  Thanks to Prathyush.

v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction

Patch summary:

Diffstats:
 .../devicetree/bindings/clock/exynos5250-clock.txt |   26 +
 .../bindings/iommu/samsung,exynos4210-sysmmu.txt   |  103 ++
 arch/arm/boot/dts/exynos4.dtsi |  122 +++
 

[PATCH 4/6] ARM: at91/dt: define sama5d3xek's main clk frequency

[Boris BREZILLON]

Define the main clock frequency for the new main clock node
in sama5d3xcm.dtsi.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3xcm.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3xcm.dtsi 
b/arch/arm/boot/dts/sama5d3xcm.dtsi
index 6a1871b..f19d5bf 100644
--- a/arch/arm/boot/dts/sama5d3xcm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xcm.dtsi
@@ -38,6 +38,12 @@
macb0: ethernet@f0028000 {
phy-mode = "rgmii";
};
+
+   pmc: pmc@fc00 {
+   main: mainck {
+   clock-frequency = <1200>;
+   };
+   };
};
 
nand0: nand@6000 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4] drivers/rtc/rtc-palmas.c: support for backup battery charging

[Mark Rutland]

On Wed, Aug 07, 2013 at 07:46:11PM +0100, Laxman Dewangan wrote:
> On Wednesday 07 August 2013 10:08 PM, Mark Rutland wrote:
> > On Wed, Aug 07, 2013 at 11:29:52AM +0100, Laxman Dewangan wrote:
> >> +Optional properties:
> >> +- ti,back-battery-charge-enable: The Palmas series device like TPS65913 or
> >> +  TPS80036 supports the battery backup for powering the RTC when main
> >> +  battery is removed or in very low power state. This flag will enable
> >> +  the backup battery charging.
> > I don't like the wording here as it implies that an OS *must* charge the
> > device, rather than that it *can* charge the device. How about:
> >
> >   - ti,backup-battery-chargeable: There is a chargeable backup battery
> >   present.
> >
> 
> The *org* property tells whether charging should be enable or not. This 
> is enabled during init and it is not the runtime configuration for 
> enable/disable.
> By saying "backup-battery-chargeable" means it need other 
> interface/calls to start charging. It does not reflect that charging 
> will be enabled by default.

It doesn't mean that the OS needs to provide some interface to control
charging. It simply means that it's up to the OS as to whether it
charges it (for which Linux's choice can be to always charge the
battery). An OS may choose not implement any charging code at all...

> 
> 
> 
> >> +- ti,back-battery-charge-low-current: Configure lower charging current. 
> >> Device
> >> +  supports the charging current as < 100mA or >100mA. Low current will
> >> +  set as <100mA.
> > This is somewhat unclear as it reads as a runtime configuration choice,
> > rather than some instances of the device only support being changed at
> > low currents (as I assume is the case?). How about:
> >
> >- ti,backup-battery-low-current: The backup battery is only chargeable
> > at currents below 100mA.
> 
> Hmm.. I think even if battery can be charge for more than 100mA, there 
> is choice of configure it for less than 100mA.

Ok.

> 
> > What happens if we charge at the wrong current?
> Not much sure but I think it can create battery damage.

If we charge a battery supporting >100mA at a current <100mA, will that
cause damage? Or only if we charge above it's supported current?

If the latter's true, it might make sense to invert the condition and
describe that the battery may be charged at a higher current, with the
default being <100mA. That way a missing property in the dt will only
result in sub-optimal charging rather than battery damage.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] ARM: at91/dt: define sama5d3 clocks

[Boris BREZILLON]

Define sama5d3 clocks in sama5d3 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3.dtsi  |  331 ++-
 arch/arm/boot/dts/sama5d3_can.dtsi  |   19 ++
 arch/arm/boot/dts/sama5d3_emac.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_gmac.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_lcd.dtsi  |   17 ++
 arch/arm/boot/dts/sama5d3_mci2.dtsi |   11 ++
 arch/arm/boot/dts/sama5d3_tcb1.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_uart.dtsi |   19 ++
 8 files changed, 431 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index f0ca1ba..e2791c5 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -14,6 +14,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 / {
model = "Atmel SAMA5D3 family SoC";
@@ -52,6 +56,14 @@
reg = <0x2000 0x800>;
};
 
+   clocks {
+   adc_op_clk: adc_op_clk{
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2000>;
+   };
+   };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
@@ -75,6 +87,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_HSMCI0>;
+   clock-names = "mci_clk";
};
 
spi0: spi@f0004000 {
@@ -88,6 +102,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <_spi0>;
+   clocks = < SAMA5D3_ID_SPI0>;
+   clock-names = "spi_clk";
status = "disabled";
};
 
@@ -97,6 +113,8 @@
interrupts = ;
pinctrl-names = "default";
pinctrl-0 = <_ssc0_tx _ssc0_rx>;
+   clocks = < SAMA5D3_ID_SSC0>;
+   clock-names = "pclk";
status = "disabled";
};
 
@@ -104,6 +122,8 @@
compatible = "atmel,at91sam9x5-tcb";
reg = <0xf001 0x100>;
interrupts = ;
+   clocks = < SAMA5D3_ID_TC0>;
+   clock-names = "t0_clk";
};
 
i2c0: i2c@f0014000 {
@@ -117,6 +137,7 @@
pinctrl-0 = <_i2c0>;
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_TWI0>;
status = "disabled";
};
 
@@ -131,6 +152,7 @@
pinctrl-0 = <_i2c1>;
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_TWI1>;
status = "disabled";
};
 
@@ -140,6 +162,8 @@
interrupts = ;
pinctrl-names = "default";
pinctrl-0 = <_usart0>;
+   clocks = < SAMA5D3_ID_USART0>;
+   clock-names = "usart";
status = "disabled";
};
 
@@ -149,6 +173,8 @@
interrupts = ;
pinctrl-names = "default";
pinctrl-0 = <_usart1>;
+   clocks = < SAMA5D3_ID_USART1>;
+   clock-names = "usart";
status = "disabled";
};
 
@@ -170,6 +196,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_HSMCI1>;
+   clock-names = "mci_clk";
};
 
spi1: spi@f8008000 {
@@ -183,6 +211,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <_spi1>;
+   clocks = < SAMA5D3_ID_SPI1>;
+   clock-names = "spi_clk";
status = 

[PATCH 2/6] ARM: at91: prepare common clk transition for sama5d3 SoC

[Boris BREZILLON]

This patch enclose sama5d3 old clk registration in
"#if defined(CONFIG_OLD_CLK_AT91) #endif" sections.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/sama5d3.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
index 0003949..3426098 100644
--- a/arch/arm/mach-at91/sama5d3.c
+++ b/arch/arm/mach-at91/sama5d3.c
@@ -19,9 +19,10 @@
 
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
+#if defined(CONFIG_OLD_CLK_AT91)
+#include "clock.h"
 /* 
  *  Clocks
  *  */
@@ -361,6 +362,7 @@ static void __init sama5d3_register_clocks(void)
clk_register();
clk_register();
 }
+#endif
 
 /* 
  *  AT91SAM9x5 processor initialization
@@ -373,5 +375,7 @@ static void __init sama5d3_map_io(void)
 
 AT91_SOC_START(sama5d3)
.map_io = sama5d3_map_io,
+#if defined(CONFIG_OLD_CLK_AT91)
.register_clocks = sama5d3_register_clocks,
+#endif
 AT91_SOC_END
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] omap: Avoid crashes in the case of hwmod misconfiguration

[Pantelis Antoniou]

Hi Kevin,

On Aug 8, 2013, at 12:15 AM, Kevin Hilman wrote:

> Pantelis Antoniou  writes:
> 
>> omap hwmod is really sensitive to hwmod misconfiguration.
>> Getting a minor clock wrong always ended up in a crash.
>> Attempt to be more resilient by not assigning variables with
>> error codes and then attempting to use them.
>> 
>> Without this patch, missing a clock ends up with something like this:
>> omap_hwmod: ehrpwm0: cannot clk_get opt_clk ehrpwm0_tbclk!
> 
> Definitely agree we should not be crashing when given bad data.
> 
> nit Re: "missing clock".  I don't think there will be any crash if a
> clock is missing.  This looks to me more like the clock name is wrong
> (tbclk instead of dbclk?), not missing.
> 

Yes, I'll rephrase.

> [...]
> 
>> index 7341eff..42cb7d4 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -784,7 +784,9 @@ static int _init_interface_clks(struct omap_hwmod *oh)
>>  if (IS_ERR(c)) {
>>  pr_warning("omap_hwmod: %s: cannot clk_get 
>> interface_clk %s\n",
>> oh->name, os->clk);
>> -ret = -EINVAL;
>> +if (ret == 0)
>> +ret = -EINVAL;
>> +continue;
> 
> the 'if (ret == 0)' adds confusion IMO.  If we don't care additional
> failures, errors, then just add a 'break' instead of these 3 lines.
> 
> [...]
> 


I tried to carry on as much as possible even on the presence of errors.
The remaining clocks won't be initialized, but that might be OK.

> Kevin

Regards

-- Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] hwmon: (lm90) Add power control

[Wei Ni]

On 08/08/2013 03:13 PM, Alexander Shiyan wrote:
>> The device lm90 can be controlled by the vdd rail.
>> Adding the power control support to power on/off the vdd rail.
>> And make sure that power is enabled before accessing the device.
>>
>> Signed-off-by: Wei Ni 
>> ---
>>  drivers/hwmon/lm90.c |   49 
>> +
>>  1 file changed, 49 insertions(+)
>>
>> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
> [...]
>> +static void lm90_power_control(struct i2c_client *client, bool is_enable)
>> +{
>> +struct lm90_data *data = i2c_get_clientdata(client);
>> +int ret;
>> +
>> +if (!data->lm90_reg)
>> +return;
>> +
>> +mutex_lock(>update_lock);
>> +
>> +if (is_enable)
>> +ret = regulator_enable(data->lm90_reg);
>> +else
>> +ret = regulator_disable(data->lm90_reg);
>> +
>> +if (ret < 0)
>> +dev_err(>dev,
>> +"Error in %s rail vdd, error %d\n",
>> +(is_enable) ? "enabling" : "disabling", ret);
>> +else
>> +dev_info(>dev, "success in %s rail vdd\n",
>> + (is_enable) ? "enabling" : "disabling");
> 
> dev_dbg() ?

As Guenter said, I will remove these messages, and remove this function,
the code will be more clean.

> 
>> +
>> +mutex_unlock(>update_lock);
>> +}
>> +
>>  static int lm90_probe(struct i2c_client *client,
>>const struct i2c_device_id *id)
>>  {
>> @@ -1406,6 +1434,20 @@ static int lm90_probe(struct i2c_client *client,
>>  i2c_set_clientdata(client, data);
>>  mutex_init(>update_lock);
>>  
>> +data->lm90_reg = regulator_get(>dev, "vdd");
>> +if (IS_ERR_OR_NULL(data->lm90_reg)) {
> 
> What about deferred probe?
> if (PTR_ERR(data->lm90_reg) == -EPROBE_DEFER)
> return -EPROBE_DEFER;

Oh, yes, I should add it.

> 
>> +if (PTR_ERR(data->lm90_reg) == -ENODEV)
>> +dev_info(>dev,
>> + "No regulator found for vdd. Assuming vdd is 
>> always powered.");
> 
> On my opinion it is unnecessary message.
> 
>> +else
>> +dev_warn(>dev,
>> + "Error [%ld] in getting the regulator handle 
>> for vdd.\n",
>> + PTR_ERR(data->lm90_reg));
> 
> Ditto.

I will remove these log messages.

> 
>> +data->lm90_reg = NULL;
> 
> You can just use !IS_ERR(data->lm90_reg) macro in the future,
> rather than set this to NULL.

Yes, it's better, I will do it.

> 
> [...]
> 
> ---
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3 v5] usb: phy-samsung-usb: Simplify PMU register handling

[Mark Rutland]

On Wed, Aug 07, 2013 at 06:06:05PM +0100, Julius Werner wrote:
> > This breaks compatibility, both for an old kernel and a new dt and a new
> > kernel with an old dt. Is anyone using these bindings?
> 
> They only affect Samsung SoCs and have only been upstream for half a
> year, so I doubt it's heavily used.

I'm not sure everyone will be happy with that line.

> 
> > Why are we describing fewer registers now? Are they described elsewhere?
> >
> > The dt should describe the device, not only the portion of it Linux
> > wants to use right now.
> 
> This only ever described a small section of the huge set of PMU
> registers anyway. Before it described up to three registers
> controlling different PHYs (using hardcoded offsets in the code to
> later find the right one)... with my patch every PHY's DT entry only
> describes the one register concerning itself, which makes more sense
> in my opinion. It will also prevent the register descriptions in
> different DT entries from overlapping.
> 

I'm not sure I understand. The old documentation referred to the
USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
your new version only refers to (usb device) PHY_CONTROL. Regardless of
multiple phys, you're suggesting that we describe less of each phy.
That seems like taking away usable information. Unless I've
misunderstood?

Ideally, we'd describe the whole set of registers and linkages to phys,
even if Linux doesn't ahppen to use that information right now.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] omap: Properly handle resources for omap_devices

[Pantelis Antoniou]

Hi Kevin,

On Aug 7, 2013, at 9:45 PM, Kevin Hilman wrote:

> [fixing address for Benoit]
> 
> Pantelis Antoniou  writes:
> 
>> omap_device relies on the platform notifier callbacks managing resources
>> behind the scenes. The resources were not properly linked causing crashes
>> when removing the device.
>> 
>> Rework the resource modification code so that linking is performed properly,
>> and make sure that no resources that have no parent (which can happen for DMA
>> & IRQ resources) are ever left for cleanup by the core resource layer.
>> 
>> Signed-off-by: Pantelis Antoniou 
> 
> This one failed my "took more than 15 minutes to understand" test.  The
> changelog is rather vague (especially about what "properly" means), and
> the combination of moving code and changing it makes the patch rather
> clunky to read, so I remain a bit confused about what the actual problem
> is.  Please elaborate.
> 
> Also, could you share a crash dump as well as details about how to
> reproduce this problem?
> 
> Thanks,
> 
> Kevin

It's the full patchset that fixes the problem:

Let me illustrate:

The kernel I use is located at:

g...@github.com:pantoniou/linux-beagle-track-mainline.git
branch: merge-20130806 (there are topic branches for other stuff too)

The DT overlay we're loading:

> /*
>  * Copyright (C) 2013 CircuitCo
>  *
>  * Virtual cape for UART1 on connector pins P9.24 P9.26
>  *
>  * 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.
>  */
> /dts-v1/;
> /plugin/;
> 
> / {
>   compatible = "ti,beaglebone", "ti,beaglebone-black";
> 
>   /* identification */
>   part-number = "BB-UART1";
>   version = "00A0";
> 
>   /* state the resources this cape uses */
>   exclusive-use =
>   /* the pin header uses */
>   "P9.24",/* uart1_txd */
>   "P9.26",/* uart1_rxd */
>   /* the hardware ip uses */
>   "uart1";
> 
>   fragment@0 {
>   target = <_pinmux>;
>   __overlay__ {
>   bb_uart1_pins: pinmux_bb_uart1_pins {
>   pinctrl-single,pins = <
>   0x184 0x20 /* P9.24 uart1_txd.uart1_txd 
>  OUTPUT  */
>   0x180 0x20 /* P9.26 uart1_rxd.uart1_rxd 
>  INPUT  */
>   >;
>   };
>   };
>   };
> 
>   fragment@1 {
>   target = <>;  /* really uart1 */
>   __overlay__ {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_uart1_pins>;
>   };
>   };
> };
> 

Nothing complicated; just a serial device.

With the full patchset on a beaglebone and loading a simple case of a UART 
'cape'.

> root@beaglebone:/sys/devices/bone_capemgr.4# echo BB-UART1 >slots 
> [   58.546947] bone-capemgr bone_capemgr.4: part_number 'BB-UART1', version 
> 'N/A'
> [   58.578374] bone-capemgr bone_capemgr.4: slot #4: generic override
> [   58.584925] bone-capemgr bone_capemgr.4: bone: Using override eeprom data 
> at slot 4
> [   58.593086] bone-capemgr bone_capemgr.4: slot #4: 'Override Board 
> Name,00A0,Override Manuf,BB-UART1'
> [   58.618455] bone-capemgr bone_capemgr.4: slot #4: Requesting part 
> number/version based 'BB-UART1-00A0.dtbo
> [   58.638258] bone-capemgr bone_capemgr.4: slot #4: Requesting firmware 
> 'BB-UART1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [   58.681259] bone-capemgr bone_capemgr.4: slot #4: dtbo 
> 'BB-UART1-00A0.dtbo' loaded; converting to live tree
> [   58.705075] bone-capemgr bone_capemgr.4: slot #4: #2 overlays
> [   58.735058] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP 
> UART1
> [   58.757834] bone-capemgr bone_capemgr.4: slot #4: Applied #2 overlays.
> root@beaglebone:/sys/devices/bone_capemgr.4# echo -4 >slots 
> [   62.362519] bone-capemgr bone_capemgr.4: Removed slot #4
> 

Revert "omap: Properly handle resources for omap_devices"
Revert "of: Link platform device resources properly."
Revert "pdev: Fix platform device resource linking"

> root@beaglebone:/sys/devices/bone_capemgr.4# echo BB-UART1 >slots 
> [   39.317978] bone-capemgr bone_capemgr.4: part_number 'BB-UART1', version 
> 'N/A'
> [   39.325630] bone-capemgr bone_capemgr.4: slot #4: generic override
> [   39.332248] bone-capemgr bone_capemgr.4: bone: Using override eeprom data 
> at slot 4
> [   39.340336] bone-capemgr bone_capemgr.4: slot #4: 'Override Board 
> Name,00A0,Override Manuf,BB-UART1'
> [   39.378854] bone-capemgr bone_capemgr.4: slot #4: Requesting part 
> number/version based 'BB-UART1-00A0.dtbo
> [   39.396013] bone-capemgr bone_capemgr.4: slot #4: Requesting firmware 
> 'BB-UART1-00A0.dtbo' for board-name 'Override Board Name', 

Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy

[Mel Gorman]

On Thu, Aug 08, 2013 at 12:16:23AM -0400, Johannes Weiner wrote:
> On Wed, Aug 07, 2013 at 11:37:43AM -0400, Johannes Weiner wrote:
> > On Wed, Aug 07, 2013 at 03:58:28PM +0100, Mel Gorman wrote:
> > > On Fri, Aug 02, 2013 at 11:37:26AM -0400, Johannes Weiner wrote:
> > > > @@ -352,6 +352,7 @@ struct zone {
> > > >  * free areas of different sizes
> > > >  */
> > > > spinlock_t  lock;
> > > > +   int alloc_batch;
> > > > int all_unreclaimable; /* All pages pinned 
> > > > */
> > > >  #if defined CONFIG_COMPACTION || defined CONFIG_CMA
> > > > /* Set to true when the PG_migrate_skip bits should be cleared 
> > > > */
> > > 
> > > This adds a dirty cache line that is updated on every allocation even if
> > > it's from the per-cpu allocator. I am concerned that this will introduce
> > > noticable overhead in the allocator paths on large machines running
> > > allocator intensive workloads.
> > > 
> > > Would it be possible to move it into the per-cpu pageset? I understand
> > > that hte round-robin nature will then depend on what CPU is running and
> > > the performance characterisics will be different. There might even be an
> > > adverse workload that uses all the batches from all available CPUs until
> > > it is essentially the same problem but that would be a very worst case.
> > > I would hope that in general it would work without adding a big source of
> > > dirty cache line bouncing in the middle of the allocator.
> > 
> > Rik made the same suggestion.  The per-cpu error is one thing, the
> > problem is if the allocating task and kswapd run on the same CPU and
> > bypass the round-robin allocator completely, at which point we are
> > back to square one.  We'd have to reduce the per-cpu lists from a pool
> > to strict batching of frees and allocs without reuse in between.  That
> > might be doable, I'll give this another look.
> 
> I found a way.  It's still in the fast path, but I'm using vmstat
> percpu counters and can stick the update inside the same irq-safe
> section that does the other statistic updates.
> 

Ok, there will be some drift as those counters are only updated
periodically or if they overflow. Offhand I think your worst case is
being off by (nr_cpu_in_node * 127 - default_batch) but I doubt it'll be
noticable.

> On a two socket system with a small Normal zone, the results are as
> follows (unfair: mmotm without the fairness allocator, fairpcp: the
> fair allocator + the vmstat optimization):
> 
> ---
> 
> pft
>  mmotm mmotm
> unfair   fairpcp
> User   1   0.0258 (  0.00%)   0.0254 (  1.40%)
> User   2   0.0264 (  0.00%)   0.0263 (  0.21%)
> User   3   0.0271 (  0.00%)   0.0277 ( -2.36%)
> User   4   0.0287 (  0.00%)   0.0280 (  2.33%)
> System 1   0.4904 (  0.00%)   0.4919 ( -0.29%)
> System 2   0.6141 (  0.00%)   0.6183 ( -0.68%)
> System 3   0.7346 (  0.00%)   0.7349 ( -0.04%)
> System 4   0.8700 (  0.00%)   0.8704 ( -0.05%)
> Elapsed1   0.5164 (  0.00%)   0.5182 ( -0.35%)
> Elapsed2   0.3213 (  0.00%)   0.3235 ( -0.67%)
> Elapsed3   0.2800 (  0.00%)   0.2800 (  0.00%)
> Elapsed4   0.2304 (  0.00%)   0.2303 (  0.01%)
> Faults/cpu 1  392724.3239 (  0.00%)  391558.5131 ( -0.30%)
> Faults/cpu 2  319357.5074 (  0.00%)  317577.8745 ( -0.56%)
> Faults/cpu 3  265703.1420 (  0.00%)  265668.3579 ( -0.01%)
> Faults/cpu 4  225516.0058 (  0.00%)  225474.1508 ( -0.02%)
> Faults/sec 1  392051.3043 (  0.00%)  390880.8201 ( -0.30%)
> Faults/sec 2  635360.7045 (  0.00%)  631819.1117 ( -0.56%)
> Faults/sec 3  725535.2889 (  0.00%)  725525.1280 ( -0.00%)
> Faults/sec 4  883307.5047 (  0.00%)  884026.1721 (  0.08%)
> 
> The overhead appears to be negligible, if not noise.
> 

Certainly small enough to not care considering what you're balancing
it against. Mind you, I do note that 4 clients is almost certainly not
enought to load a 2-socket machine. As the test is not memory intensive I
suspect that this test ran entirely within a single socket that would have
avoided the worst costs of dirty cache line bouncing anyway. As the number
of clients grow I predict that the results will become more variable as
it'll depend on scheduling.

>mmotm   mmotm
>   unfair fairpcp
> User   39.90   39.70
> System   1070.93 1069.50
> Elapsed   557.47  556.86
> 

And there is nothing suspicious in the system CPU time.

> 
> parallelio
>   mmotm   
> mmotm
>  unfair 
> fairpcp
> Ops memcachetest-0M  28012.00 (  0.00%)  27887.00 ( 
> -0.45%)
> Ops memcachetest-1877M   22366.00 (  0.00%)   

[PATCH 1/6] ARM: at91: prepare sama5 dt boards transition to common clk

[Boris BREZILLON]

This patch prepare the transition to common clk for sama5 dt boards by
replacing the timer init callback.

Clocks registration cannot be done in early init callback (as formerly done
by the old clk implementation) because it requires dynamic allocation
which is not ready yet during early init.

In the other hand, at91 clocks must be registered before
at91sam926x_pit_init is called because PIT (Periodic Interval Timer) driver
request the master clk (mck).

A new function (at91sama5_dt_timer_init) is created to fullfil these needs.
This function registers all at91 clks using the dt definition before
calling the PIT init function.
The device tree clock registration is enabled only if common clk is
selected. Else the old clk registration is been done during
at91_dt_initialize call.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/board-dt-sama5.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/board-dt-sama5.c 
b/arch/arm/mach-at91/board-dt-sama5.c
index ad95f6a..10b6913 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -26,6 +27,13 @@
 #include "at91_aic.h"
 #include "generic.h"
 
+static void __init sama5_dt_timer_init(void)
+{
+#if defined(CONFIG_COMMON_CLK)
+   of_clk_init(NULL);
+#endif
+   at91sam926x_pit_init();
+}
 
 static const struct of_device_id irq_of_match[] __initconst = {
 
@@ -77,7 +85,7 @@ static const char *sama5_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(sama5_dt, "Atmel SAMA5 (Device Tree)")
/* Maintainer: Atmel */
-   .init_time  = at91sam926x_pit_init,
+   .init_time  = sama5_dt_timer_init,
.map_io = at91_map_io,
.handle_irq = at91_aic5_handle_irq,
.init_early = at91_dt_initialize,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 7 [ call-trace on suspend: ext4 | pm related ? ]

[Sedat Dilek]

+0x5b9/0x600
>> [  125.336238]  [] ? fuse_dev_read+0x68/0x80
>> [  125.336242]  [] do_signal+0x58/0x8f0
>> [  125.336246]  [] ? acct_account_cputime+0x1c/0x20
>> [  125.336249]  [] ? do_raw_spin_unlock+0x5d/0xb0
>> [  125.336252]  [] ? _raw_spin_unlock+0xe/0x10
>> [  125.336255]  [] ? vtime_account_user+0x6d/0x80
>> [  125.336258]  [] do_notify_resume+0x88/0xc0
>> [  125.336261]  [] int_signal+0x12/0x17
>> [  125.336263] loop0   D 81811820 0   310  2 
>> 0x
>> [  125.336265]  8800d573d968 0002 
>> 8800d57aeb80
>> [  125.336268]  880118bda740 8800d573dfd8 8800d573dfd8
>> 8800d573dfd8
>> [  125.336270]  880119f98340 880118bda740 8800d573d968
>> 88011fad5118
>> [  125.336273] Call Trace:
>> [  125.336278]  [] ? __lock_page+0x70/0x70
>> [  125.336280]  [] schedule+0x29/0x70
>> [  125.336283]  [] io_schedule+0x8f/0xd0
>> [  125.336286]  [] sleep_on_page+0xe/0x20
>> [  125.336288]  [] __wait_on_bit_lock+0x5d/0xc0
>> [  125.336291]  [] __lock_page+0x67/0x70
>> [  125.336294]  [] ? wake_atomic_t_function+0x40/0x40
>> [  125.336298]  [] __generic_file_splice_read+0x59f/0x5d0
>> [  125.336302]  [] ? cpumask_next_and+0x38/0x50
>> [  125.336305]  [] ? update_sd_lb_stats+0x123/0x610
>> [  125.336309]  [] ? x2apic_send_IPI_mask+0x13/0x20
>> [  125.336312]  [] ? native_smp_send_reschedule+0x4b/0x60
>> [  125.336315]  [] ? resched_task+0x76/0x80
>> [  125.336318]  [] ? page_cache_pipe_buf_release+0x30/0x30
>> [  125.336321]  [] generic_file_splice_read+0x3e/0x80
>> [  125.336324]  [] do_splice_to+0x7b/0xa0
>> [  125.336326]  [] splice_direct_to_actor+0xa7/0x1c0
>> [  125.336330]  [] ? loop_thread+0x2a0/0x2a0
>> [  125.336333]  [] do_bio_filebacked+0xf2/0x340
>> [  125.336336]  [] ? do_raw_spin_lock+0x4c/0x120
>> [  125.336339]  [] loop_thread+0xe5/0x2a0
>> [  125.336341]  [] ? __init_waitqueue_head+0x40/0x40
>> [  125.336344]  [] ? do_bio_filebacked+0x340/0x340
>> [  125.336346]  [] kthread+0xd8/0xe0
>> [  125.336348]  [] ? flush_kthread_worker+0xe0/0xe0
>> [  125.336351]  [] ret_from_fork+0x7c/0xb0
>> [  125.336353]  [] ? flush_kthread_worker+0xe0/0xe0
>> [  125.336354] jbd2/loop0-8D  0   312  2 
>> 0x
>> [  125.336357]  8800d56c7b08 0002 8800d56c7ab8
>> 8137a90d
>> [  125.336359]  880037ba4240 8800d56c7fd8 8800d56c7fd8
>> 8800d56c7fd8
>> [  125.336362]  88010d33e5c0 880037ba4240 8800d56c7b08
>> 88011fad5118
>> [  125.336364] Call Trace:
>> [  125.336367]  [] ? do_raw_spin_unlock+0x5d/0xb0
>> [  125.336369]  [] ? __wait_on_buffer+0x30/0x30
>> [  125.336371]  [] schedule+0x29/0x70
>> [  125.336374]  [] io_schedule+0x8f/0xd0
>> [  125.336376]  [] sleep_on_buffer+0xe/0x20
>> [  125.336378]  [] __wait_on_bit+0x62/0x90
>> [  125.336380]  [] ? __wait_on_buffer+0x30/0x30
>> [  125.336382]  [] out_of_line_wait_on_bit+0x7c/0x90
>> [  125.336384]  [] ? wake_atomic_t_function+0x40/0x40
>> [  125.336386]  [] __wait_on_buffer+0x2e/0x30
>> [  125.336390]  []
>> jbd2_journal_commit_transaction+0x1051/0x1c60
>> [  125.336393]  [] ? load_balance+0x14b/0x870
>> [  125.336397]  [] ? _raw_spin_lock_irqsave+0x24/0x30
>> [  125.336399]  [] ? try_to_del_timer_sync+0x4f/0x70
>> [  125.336402]  [] kjournald2+0x11b/0x350
>> [  125.336405]  [] ? __schedule+0x3e5/0x850
>> [  125.336407]  [] ? __init_waitqueue_head+0x40/0x40
>> [  125.336410]  [] ? jbd2_journal_clear_features+0x90/0x90
>> [  125.336412]  [] kthread+0xd8/0xe0
>> [  125.336414]  [] ? flush_kthread_worker+0xe0/0xe0
>> [  125.336416]  [] ret_from_fork+0x7c/0xb0
>> [  125.336418]  [] ? flush_kthread_worker+0xe0/0xe0

My 1st suspend try with next-20130808 shows same isssue (w/o your "hack" patch):

[   98.026982] PM: Syncing filesystems ... done.
[   98.321181] PM: Preparing system for mem sleep
[   98.321736] Freezing user space processes ...
[  118.320817] Freezing of tasks failed after 20.003 seconds (1 tasks
refusing to freeze, wq_busy=0):
[  118.320838] apt-check   D  0  2636   2456 0x0004
[  118.320841]  880109631c98 0002 
88005c044280
[  118.320845]  88005c1d4640 880109631fd8 880109631fd8
880109631fd8
[  118.320847]  880119f440c0 88005c1d4640 880109631c98
88011fa15118
[  118.320850] Call Trace:
[  118.320859]  [] ? sleep_on_page+0x20/0x20
[  118.320863]  [] schedule+0x29/0x70
[  118.320865]  [] io_schedule+0x8f/0xd0
[  118.320868]  [] sleep_on_page_killable+0xe/0x40
[  118.320871]  [] __wait_on_bit_lock+0x5d/0xc0
[  118.320874]  [] __lock_page_killable+0x67/0x70
[  118.320877]  [] ? wake_atomic_t_function+0x40/0x40
[  118.320880]  [] generic_file_aio_read+0x47e/0x720
[  118.320883]  [] do_sync_read+0x5a/0x90
[  118.320885]  [] vfs_read+0xb4/0x180
[  118.320887]  [] SyS_read+0x52/0xa0
[  118.320891]  [] tracesys+0xe1/0xe6
[  118.320892]
[  118.320893] Restarting tasks ... done.

I walked trough my scripts-dir... is run_pm-test.sh an appropriate
test-case/use-case?

- Sedat -


run_pm-test.sh
Description: Bourne shell script

Re: [RFC 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core

[Mark Rutland]

On Tue, Aug 06, 2013 at 03:36:33PM +0100, Ivan T. Ivanov wrote:
> Hi,
> 
> On Tue, 2013-08-06 at 15:03 +0100, Mark Rutland wrote:
> > On Tue, Aug 06, 2013 at 12:53:10PM +0100, Ivan T. Ivanov wrote:
> > > From: "Ivan T. Ivanov" 
> > >
> > > Signed-off-by: Ivan T. Ivanov 
> > > ---
> > >  .../devicetree/bindings/usb/msm-ssusb.txt  |   49 +++
> > >  drivers/usb/phy/Kconfig|   11 +
> > >  drivers/usb/phy/Makefile   |2 +
> > >  drivers/usb/phy/phy-msm-dwc3-usb2.c|  342 
> > > +
> > >  drivers/usb/phy/phy-msm-dwc3-usb3.c|  389 
> > > 
> > >  5 files changed, 793 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > >  create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
> > >  create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt 
> > > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > > new file mode 100644
> > > index 000..550b496
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > > @@ -0,0 +1,49 @@
> > > +MSM SuperSpeed USB3.0 SoC controllers
> > > +
> > > +Required properities :
> > > +- compatible sould be "qcom,dwc3-usb2";
> > > +- reg : offset and length of the register set in the memory map
> > > +- clocks: <>, <_phy_sleep_cxc>;
> > 
> > Huh? That doesn't describe what these are. These would be better
> > explained with a reference to clock-names and a basic description as to
> > what the input's called, what it drives, etc, as you've done done for
> > the *-supply properties.
> 
> Ok, I will fix this.
> 
> > 
> > > +- clock-names: "xo", "sleep_a_clk";
> > > +-supply: phandle to the regulator device tree node
> > > +Required "supply-name" examples are:
> > > +   "v1p8" : 1.8v supply for HSPHY
> > > +   "v3p3" : 3.3v supply for HSPHY
> > > +   "vbus" : vbus supply for host mode
> > > +   "vddcx" : vdd supply for HS-PHY digital circuit operation
> > > +
> > > +Required properities :
> > > +- compatible sould be "qcom,dwc3-usb3";
> > > +- reg : offset and length of the register set in the memory map
> > > +- clocks: <>, <_mock_utmi_cxc>;
> > 
> > Similarly, this doesn't describe what the clocks are.
> 
> Understood.
> 
> > 
> > > +- clock-names: "xo", "ref_clk";
> > > +-supply: phandle to the regulator device tree node
> > > +Required "supply-name" examples are:
> > > +   "v1p8" : 1.8v supply for SS-PHY
> > > +   "vddcx" : vdd supply for SS-PHY digital circuit operation
> > > +
> > > +Example device nodes:
> > > +
> > > +   dwc3_usb2: phy@f92f8800 {
> > > +   compatible = "qcom,dwc3-usb2";
> > > +   reg = <0xf92f8800 0x30>;
> > > +
> > > +   clocks = <>, <_phy_sleep_cxc>;
> > > +   clock-names = "xo", "sleep_a_clk";
> > > +
> > > +   vbus-supply = <>;
> > > +   vddcx-supply = <>;
> > > +   v1p8-supply = <>;
> > > +   v3p3-supply = <>;
> > > +   };
> > > +
> > > +   dwc3_usb3: phy@f92f8830 {
> > > +   compatible = "qcom,dwc3-usb3";
> > > +   reg = <0xf92f8830 0x30>;
> > > +
> > > +   clocks = <>, <_mock_utmi_cxc>;
> > > +   clock-names = "xo", "ref_clk";
> > > +
> > > +   vddcx-supply = <>;
> > > +   v1p8-supply = <>;
> > > +   };
> > 
> > 
> > Those regster banks look suspiciously close. Are these the same IP
> > block? Can they ever appear separately?
> > 
> 
> They are part of the wrapper Qualcomm logic around Synopsys USB3 core.
> In this sense they are part of the one IP, I believe. Manage them from
> separate drivers simplify code.

Hmmm. I'm not entirely certain on this. On the one hand, they're
separate IP blocks, and have lgoically separate drivers, so describing
them as two devices makes sense. On the other hand, they've been fused
into one IP block with shared resources. Describing them as two devices
probably makes sense given you have the wrapper driver.

> 
> > Do the drivers not trample each other when messing with shared clocks
> > and regulators?
> > 
> 
> Regulators and clocks have reference counting, right?, so this should
> be safe. Even if they are part of the one driver, clocks and regulators
> could be switched off only if both PHY's do not use them.

Ok, I just wanted to be sure this had been considered :)

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3]hrtimer: Fix a performance regression by disable reprogramming in remove_hrtimer

[ethan.zhao]

在 2013-8-8，下午5:04，"ethan.zhao"  写道：

> Kernel 3.11-rc1 +Peterz' patch+ Mike's patch, No C-states in BIOS, got the 
> same result as only Peter's patch.

Typo   3.11-rc3
> Of course , No C states to enter, make sense.
> [root@localhost ~]# time ./pip1m
> 
> real  0m4.381s
> user  0m0.099s
> sys   0m2.784s
> [root@localhost ~]# time ./pip1m
> 
> real  0m4.436s
> user  0m0.093s
> sys   0m2.809s
> [root@localhost ~]# 
> 
> Retest with C-states enabled in BIOS
> [root@localhost ~]# time ./pip1m
> 
> real  0m8.670s
> user  0m0.203s
> sys   0m5.459s
> [root@localhost ~]# time ./pip1m
> 
> real  0m8.489s
> user  0m0.184s
> sys   0m5.360s
> [root@localhost ~]# 
> 
> So the result is Peter's patch working or Mike's ?  Compared with default 
> 3.11-rc3
> result of test case 1 as following, looks great.
> [root@localhost ~]# time ./pip1m
> 
> real  0m10.683s
> user  0m0.204s
> sys   0m6.597s
> [root@localhost ~]# time ./pip1m
> 
> real  0m10.629s
> user  0m0.185s
> sys   0m6.546s
> 
> So revert Mike's patch and retest, got
> [root@localhost ~]# time ./pip1m
> 
> real  0m8.606s
> user  0m0.193s
> sys   0m5.449s
> [root@localhost ~]# time ./pip1m
> 
> real  0m8.655s
> user  0m0.198s
> sys   0m5.519s
> [root@localhost ~]# 
> 
> So, it's Peter's patch working………
> 
> The result of kernel 3.11-rc3 + Peter's patch + no rescheduling IPI and no 
> C-states in BIOS is :
> [root@localhost ~]# time ./pip1m
> 
> real  0m3.915s
> user  0m0.088s
> sys   0m2.487s
> [root@localhost ~]# time ./pip1m
> 
> real  0m3.929s
> user  0m0.082s
> sys   0m2.560s
> [root@localhost ~]# time ./pip1m
> 
> Got about 0.5 sec better than only Peter's patch, but it is strange, only no 
> rescheduling IPI almost got the
> same result.
> 
> 
> Thanks,
> Ethan
> 
> 
> 在 2013-8-8，下午12:31，ethan.zhao  写道：
 
 sched: ratelimit nohz
 
 Entering nohz code on every micro-idle is too expensive to bear.
 
 Signed-off-by: Mike Galbraith 
 
 ---
 include/linux/sched.h|5 +
 kernel/sched/core.c  |5 +
 kernel/time/tick-sched.c |2 +-
 3 files changed, 11 insertions(+), 1 deletion(-)
 
 --- a/include/linux/sched.h
 +++ b/include/linux/sched.h
 @@ -235,9 +235,14 @@ extern int runqueue_is_locked(int cpu);
 extern void nohz_balance_enter_idle(int cpu);
 extern void set_cpu_sd_state_idle(void);
 extern int get_nohz_timer_target(void);
 +extern int sched_needs_cpu(int cpu);
 #else
 static inline void nohz_balance_enter_idle(int cpu) { }
 static inline void set_cpu_sd_state_idle(void) { }
 +static inline int sched_needs_cpu(int cpu)
 +{
 +  return 0;
 +}
 #endif
 
 /*
 --- a/kernel/sched/core.c
 +++ b/kernel/sched/core.c
 @@ -650,6 +650,11 @@ static inline bool got_nohz_idle_kick(vo
return false;
 }
 
 +int sched_needs_cpu(int cpu)
 +{
 +  return  cpu_rq(cpu)->avg_idle < sysctl_sched_migration_cost;
 +}
 +
 #else /* CONFIG_NO_HZ_COMMON */
 
 static inline bool got_nohz_idle_kick(void)
 --- a/kernel/time/tick-sched.c
 +++ b/kernel/time/tick-sched.c
 @@ -548,7 +548,7 @@ static ktime_t tick_nohz_stop_sched_tick
time_delta = timekeeping_max_deferment();
} while (read_seqretry(_lock, seq));
 
 -  if (rcu_needs_cpu(cpu, _delta_jiffies) ||
 +  if (sched_needs_cpu(cpu) || rcu_needs_cpu(cpu, _delta_jiffies) ||
arch_needs_cpu(cpu) || irq_work_needs_cpu()) {
next_jiffies = last_jiffies + 1;
delta_jiffies = 1;
 
 
>>> 
>>> 
>> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] mfd: sec: Add clock cell for s2mps11

[Lee Jones]

On Wed, 07 Aug 2013, Mike Turquette wrote:

> Quoting Yadwinder Singh Brar (2013-07-07 04:44:21)
> > This patch adds clock to list of mfd cells for s2mps11 and DT documentation
> > for clock part.
> > 
> > Signed-off-by: Yadwinder Singh Brar 
> 
> Reviewed-by: Mike Turquette 

Thanks Mike.

Patch applied, thanks.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/4] gpio: add LP3943 I2C GPIO expander driver

[Lee Jones]

On Wed, 07 Aug 2013, Linus Walleij wrote:

> On Tue, Jul 30, 2013 at 2:42 AM, Kim, Milo  wrote:
> 
> > This is one of LP3943 MFD driver.
> > LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
> >
> > * Application note: how to configure LP3943 as a GPIO expander
> >   http://www.ti.com/lit/an/snva287a/snva287a.pdf
> >
> > * Supported GPIO controller operations
> >   request, free, direction_input, direction_output, get and set
> >
> > * GPIO direction register not supported
> >   LP3943 doesn't have the GPIO direction register. It only provides input 
> > and
> >   output status registers.
> >   So, private data for the direction should be handled manually.
> >   This variable is updated whenever the direction is changed and
> >   used in 'get' operation.
> >
> > * Pin assignment
> >   A driver data, 'pin_used' is checked when a GPIO is requested.
> >   If the GPIO is already assigned, then returns as failure.
> >   If the GPIO is available, 'pin_used' is set.
> >   When the GPIO is not used anymore, then it is cleared.
> >   It is defined as unsigned long type for atomic bit operation APIs,
> >   but only LSB 16bits are used because LP3943 has 16 outputs.
> >
> > Cc: Linus Walleij 
> > Signed-off-by: Milo Kim 
> > ---
> > * Patch v2
> >   Use bitops macros for bit manipulations.
> >   Support device tree structure for the GPIO controller.
> >   Add request() and free() for the pin assignment.
> 
> This adresses all my concerns, nice driver.
> Reviewed-by: Linus Walleij 
> 
> I guess this will be merged through the MFD tree along
> with the MFD core patch? That needs to go in first anyway.

That's fine, but first:

1/4 Needs Linus to review
4/4 Needs Thierry's PWM Ack

After that please send v3 with Linus' Rev-By on this patch.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3]hrtimer: Fix a performance regression by disable reprogramming in remove_hrtimer

[ethan.zhao]

Kernel 3.11-rc1 +Peterz' patch+ Mike's patch, No C-states in BIOS, got the same 
result as only Peter's patch.
Of course , No C states to enter, make sense.
[root@localhost ~]# time ./pip1m

real0m4.381s
user0m0.099s
sys 0m2.784s
[root@localhost ~]# time ./pip1m

real0m4.436s
user0m0.093s
sys 0m2.809s
[root@localhost ~]# 

Retest with C-states enabled in BIOS
[root@localhost ~]# time ./pip1m

real0m8.670s
user0m0.203s
sys 0m5.459s
[root@localhost ~]# time ./pip1m

real0m8.489s
user0m0.184s
sys 0m5.360s
[root@localhost ~]# 

So the result is Peter's patch working or Mike's ?  Compared with default 
3.11-rc3
result of test case 1 as following, looks great.
[root@localhost ~]# time ./pip1m

real0m10.683s
user0m0.204s
sys 0m6.597s
[root@localhost ~]# time ./pip1m

real0m10.629s
user0m0.185s
sys 0m6.546s

So revert Mike's patch and retest, got
[root@localhost ~]# time ./pip1m

real0m8.606s
user0m0.193s
sys 0m5.449s
[root@localhost ~]# time ./pip1m

real0m8.655s
user0m0.198s
sys 0m5.519s
[root@localhost ~]# 

So, it's Peter's patch working………

The result of kernel 3.11-rc3 + Peter's patch + no rescheduling IPI and no 
C-states in BIOS is :
[root@localhost ~]# time ./pip1m

real0m3.915s
user0m0.088s
sys 0m2.487s
[root@localhost ~]# time ./pip1m

real0m3.929s
user0m0.082s
sys 0m2.560s
[root@localhost ~]# time ./pip1m

Got about 0.5 sec better than only Peter's patch, but it is strange, only no 
rescheduling IPI almost got the
same result.


Thanks,
Ethan


在 2013-8-8，下午12:31，ethan.zhao  写道：
>>> 
>>> sched: ratelimit nohz
>>> 
>>> Entering nohz code on every micro-idle is too expensive to bear.
>>> 
>>> Signed-off-by: Mike Galbraith 
>>> 
>>> ---
>>> include/linux/sched.h|5 +
>>> kernel/sched/core.c  |5 +
>>> kernel/time/tick-sched.c |2 +-
>>> 3 files changed, 11 insertions(+), 1 deletion(-)
>>> 
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -235,9 +235,14 @@ extern int runqueue_is_locked(int cpu);
>>> extern void nohz_balance_enter_idle(int cpu);
>>> extern void set_cpu_sd_state_idle(void);
>>> extern int get_nohz_timer_target(void);
>>> +extern int sched_needs_cpu(int cpu);
>>> #else
>>> static inline void nohz_balance_enter_idle(int cpu) { }
>>> static inline void set_cpu_sd_state_idle(void) { }
>>> +static inline int sched_needs_cpu(int cpu)
>>> +{
>>> +   return 0;
>>> +}
>>> #endif
>>> 
>>> /*
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -650,6 +650,11 @@ static inline bool got_nohz_idle_kick(vo
>>> return false;
>>> }
>>> 
>>> +int sched_needs_cpu(int cpu)
>>> +{
>>> +   return  cpu_rq(cpu)->avg_idle < sysctl_sched_migration_cost;
>>> +}
>>> +
>>> #else /* CONFIG_NO_HZ_COMMON */
>>> 
>>> static inline bool got_nohz_idle_kick(void)
>>> --- a/kernel/time/tick-sched.c
>>> +++ b/kernel/time/tick-sched.c
>>> @@ -548,7 +548,7 @@ static ktime_t tick_nohz_stop_sched_tick
>>> time_delta = timekeeping_max_deferment();
>>> } while (read_seqretry(_lock, seq));
>>> 
>>> -   if (rcu_needs_cpu(cpu, _delta_jiffies) ||
>>> +   if (sched_needs_cpu(cpu) || rcu_needs_cpu(cpu, _delta_jiffies) ||
>>> arch_needs_cpu(cpu) || irq_work_needs_cpu()) {
>>> next_jiffies = last_jiffies + 1;
>>> delta_jiffies = 1;
>>> 
>>> 
>> 
>> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH part3 2/5] x86, acpi: Split acpi_table_init() into two parts.

[Tang Chen]

This patch splits acpi_table_init() into two steps.

Since acpi_table_init() is used not just in x86, also used in ia64,
we introduce two new functions:
acpi_table_init_firmware() and acpi_table_init_override(),
which work just the same as acpi_table_init() if they are called
in sequence. This will keep acpi_table_init() works as before on
other platforms, and we only call these new functions in Linux.

Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
---
 drivers/acpi/tables.c |   26 --
 include/linux/acpi.h  |2 ++
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index c8f2d01..4913a85 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -336,6 +336,23 @@ static void __init check_multiple_madt(void)
return;
 }
 
+int __init acpi_table_init_firmware(void)
+{
+   acpi_status status;
+
+   status = acpi_initialize_tables_firmware(initial_tables,
+ACPI_MAX_TABLES, 0);
+   if (ACPI_FAILURE(status))
+   return 1;
+
+   return 0;
+}
+
+void __init acpi_table_init_override(void)
+{
+   acpi_initialize_tables_override();
+}
+
 /*
  * acpi_table_init()
  *
@@ -347,16 +364,13 @@ static void __init check_multiple_madt(void)
 
 int __init acpi_table_init(void)
 {
-   acpi_status status;
-
-   status = acpi_initialize_tables_firmware(initial_tables,
-ACPI_MAX_TABLES, 0);
-   if (ACPI_FAILURE(status))
+   if (acpi_table_init_firmware())
return 1;
 
-   acpi_initialize_tables_override();
+   acpi_table_init_override();
 
check_multiple_madt();
+
return 0;
 }
 
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 353ba25..9704179 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -95,6 +95,8 @@ void acpi_boot_table_init (void);
 int acpi_mps_check (void);
 int acpi_numa_init (void);
 
+int acpi_table_init_firmware(void);
+void acpi_table_init_override(void);
 int acpi_table_init (void);
 int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
 int __init acpi_table_parse_entries(char *id, unsigned long table_size,
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH part3 4/5] x86, acpi: Split acpi_boot_table_init() into two parts.

[Tang Chen]

This patch splits acpi_boot_table_init() into two steps,
so that we can do each step separately in later patches.

Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
---
 arch/x86/kernel/acpi/boot.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 2627a81..ddb0bc1 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1529,11 +1529,15 @@ void __init acpi_boot_table_init(void)
/*
 * Initialize the ACPI boot-time table parser.
 */
-   if (acpi_table_init()) {
+   if (acpi_table_init_firmware()) {
disable_acpi();
return;
}
 
+   acpi_table_init_override();
+
+   acpi_check_multiple_madt();
+
acpi_table_parse(ACPI_SIG_BOOT, acpi_parse_sbf);
 
/*
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH part3 1/5] x86, acpi: Call two new functions instead of acpi_initialize_tables() in acpi_table_init().

[Tang Chen]

The previous patches introduces two new functions:
acpi_initialize_tables_firmware() and acpi_initialize_tables_override(),
which work just the same as acpi_initialize_tables() if they are called
in sequence.

In order to split acpi_table_init() on acpi side, call these two functions
in acpi_table_init().

Since acpi_table_init() is also used in ia64, we keep it works as before.

Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
---
 drivers/acpi/tables.c |5 -
 include/acpi/acpixf.h |4 
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index d67a1fe..c8f2d01 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -349,10 +349,13 @@ int __init acpi_table_init(void)
 {
acpi_status status;
 
-   status = acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
+   status = acpi_initialize_tables_firmware(initial_tables,
+ACPI_MAX_TABLES, 0);
if (ACPI_FAILURE(status))
return 1;
 
+   acpi_initialize_tables_override();
+
check_multiple_madt();
return 0;
 }
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 22d497e..99c9d7b 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -115,6 +115,10 @@ extern u32 acpi_rsdt_forced;
  * Initialization
  */
 acpi_status
+acpi_initialize_tables_firmware(struct acpi_table_desc *initial_storage,
+   u32 initial_table_count, u8 allow_resize);
+void acpi_initialize_tables_override(void);
+acpi_status
 acpi_initialize_tables(struct acpi_table_desc *initial_storage,
   u32 initial_table_count, u8 allow_resize);
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH part3 3/5] x86, acpi: Rename check_multiple_madt() and make it global.

[Tang Chen]

Since we split acpi_table_init() into two steps, and want to do
the two steps separately, we need to do check_multiple_madt() after
acpi_table_init_override().

But we also have to keep acpi_table_init() as before because it
is also used in ia64, we have to do check_multiple_madt() directly
in acpi_boot_table_init() in x86.

This patch make check_multiple_madt() global, and rename it to
acpi_check_multiple_madt() because all interfaces provided by
drivers/acpi/tables.c begins with "acpi_".

Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
---
 drivers/acpi/tables.c |4 ++--
 include/linux/acpi.h  |1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 4913a85..45727b2 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -314,7 +314,7 @@ int __init acpi_table_parse(char *id, 
acpi_tbl_table_handler handler)
  * but some report two.  Provide a knob to use either.
  * (don't you wish instance 0 and 1 were not the same?)
  */
-static void __init check_multiple_madt(void)
+void __init acpi_check_multiple_madt(void)
 {
struct acpi_table_header *table = NULL;
acpi_size tbl_size;
@@ -369,7 +369,7 @@ int __init acpi_table_init(void)
 
acpi_table_init_override();
 
-   check_multiple_madt();
+   acpi_check_multiple_madt();
 
return 0;
 }
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 9704179..44a3e5f 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -95,6 +95,7 @@ void acpi_boot_table_init (void);
 int acpi_mps_check (void);
 int acpi_numa_init (void);
 
+void acpi_check_multiple_madt(void);
 int acpi_table_init_firmware(void);
 void acpi_table_init_override(void);
 int acpi_table_init (void);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH part3 5/5] x86, acpi: Initialize acpi golbal root table list earlier.

[Tang Chen]

As the previous patches split the acpi_gbl_root_table_list initialization
procedure into two steps: install and override, this patch does the "install"
steps earlier, right after memblock is ready.

In this way, we are able to find SRAT in firmware earlier. And then, we can
prevent memblock from allocating hotpluggable memory for the kernel.

Signed-off-by: Tang Chen 
Reviewed-by: Zhang Yanfei 
---
 arch/x86/kernel/acpi/boot.c |   30 +-
 arch/x86/kernel/setup.c |8 +++-
 include/linux/acpi.h|1 +
 3 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index ddb0bc1..30daefd 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1497,6 +1497,23 @@ static struct dmi_system_id __initdata 
acpi_dmi_table_late[] = {
{}
 };
 
+void __init early_acpi_boot_table_init(void)
+{
+   dmi_check_system(acpi_dmi_table);
+
+   /*
+* If acpi_disabled, bail out
+*/
+   if (acpi_disabled)
+   return; 
+
+   /*
+* Initialize the ACPI boot-time table parser.
+*/
+   if (acpi_table_init_firmware())
+   disable_acpi();
+}
+
 /*
  * acpi_boot_table_init() and acpi_boot_init()
  *  called from setup_arch(), always.
@@ -1504,9 +1521,6 @@ static struct dmi_system_id __initdata 
acpi_dmi_table_late[] = {
  * 2. enumerates lapics
  * 3. enumerates io-apics
  *
- * acpi_table_init() is separate to allow reading SRAT without
- * other side effects.
- *
  * side effects of acpi_boot_init:
  * acpi_lapic = 1 if LAPIC found
  * acpi_ioapic = 1 if IOAPIC found
@@ -1518,22 +1532,12 @@ static struct dmi_system_id __initdata 
acpi_dmi_table_late[] = {
 
 void __init acpi_boot_table_init(void)
 {
-   dmi_check_system(acpi_dmi_table);
-
/*
 * If acpi_disabled, bail out
 */
if (acpi_disabled)
return; 
 
-   /*
-* Initialize the ACPI boot-time table parser.
-*/
-   if (acpi_table_init_firmware()) {
-   disable_acpi();
-   return;
-   }
-
acpi_table_init_override();
 
acpi_check_multiple_madt();
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f8ec578..fdb5a26 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1074,6 +1074,12 @@ void __init setup_arch(char **cmdline_p)
memblock_x86_fill();
 
/*
+* Parse the ACPI tables from firmware for possible boot-time SMP
+* configuration.
+*/
+   early_acpi_boot_table_init();
+
+   /*
 * The EFI specification says that boot service code won't be called
 * after ExitBootServices(). This is, in fact, a lie.
 */
@@ -1130,7 +1136,7 @@ void __init setup_arch(char **cmdline_p)
io_delay_init();
 
/*
-* Parse the ACPI tables for possible boot-time SMP configuration.
+* Finish parsing the ACPI tables.
 */
acpi_boot_table_init();
 
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 44a3e5f..c5e7b2a 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -91,6 +91,7 @@ char * __acpi_map_table (unsigned long phys_addr, unsigned 
long size);
 void __acpi_unmap_table(char *map, unsigned long size);
 int early_acpi_boot_init(void);
 int acpi_boot_init (void);
+void early_acpi_boot_table_init (void);
 void acpi_boot_table_init (void);
 int acpi_mps_check (void);
 int acpi_numa_init (void);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] ARM: at91: prepare common clk transition for sama5d3 SoC

[Boris BREZILLON]

This patch enclose sama5d3 old clk registration in
"#if defined(CONFIG_OLD_CLK_AT91) #endif" sections.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/sama5d3.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/sama5d3.c b/arch/arm/mach-at91/sama5d3.c
index 0003949..3426098 100644
--- a/arch/arm/mach-at91/sama5d3.c
+++ b/arch/arm/mach-at91/sama5d3.c
@@ -19,9 +19,10 @@
 
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
+#if defined(CONFIG_OLD_CLK_AT91)
+#include "clock.h"
 /* 
  *  Clocks
  *  */
@@ -361,6 +362,7 @@ static void __init sama5d3_register_clocks(void)
clk_register();
clk_register();
 }
+#endif
 
 /* 
  *  AT91SAM9x5 processor initialization
@@ -373,5 +375,7 @@ static void __init sama5d3_map_io(void)
 
 AT91_SOC_START(sama5d3)
.map_io = sama5d3_map_io,
+#if defined(CONFIG_OLD_CLK_AT91)
.register_clocks = sama5d3_register_clocks,
+#endif
 AT91_SOC_END
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] ARM: at91: move sama5d3 SoC to common clk

[Boris BREZILLON]

This patch removes the selection of AT91_USE_OLD_CLK when selecting sama5d3
SoC support. This will enable automatically enable COMMON_CLK_AT91 option
and add support for at91 common clk implementation.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/Kconfig |1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 97033f7..b4f7d6f 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -86,7 +86,6 @@ config SOC_SAMA5D3
select SOC_SAMA5
select HAVE_FB_ATMEL
select HAVE_AT91_DBGU1
-   select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
select HAVE_AT91_SMD
select HAVE_AT91_USB_CLK
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH part3 0/5] acpi, acpica: Initialize acpi_gbl_root_table_list earlier and override it later.

[Tang Chen]

In order to prevent bootmem allocator (memblock) from allocating hotpluggable 
memory for the kernel, we need to obtain SRAT earlier.

In part1 patch-set, we have split acpi_gbl_root_table_list initialization into
two steps: install and override.

This patch-set will do install step earlier. This will help us to find SRAT 
provided 
by firmware earlier in later patches. 

The current kernel looks like this:

setup_arch()
 |->acpi_initrd_override() /* Find all tables specified by users in 
initrd,
 |and store them in acpi_tables_addr array. 
*/
 |..
 |->acpi_boot_table_init() /* Find all tables in firmware and install 
them
  into acpi_gbl_root_table_list. Check 
acpi_tables_addr,
  if any table needs to be overrided, 
override it. */

After this patch-set, the kernel will look like this:

setup_arch()
 |->early_acpi_boot_table_init()   /* Find all tables in firmware and install 
them 
 |into acpi_gbl_root_table_list. No 
override. */
 |
 |->acpi_initrd_override() /* Find all tables specified by users in 
initrd,
 |and store them in acpi_tables_addr array. 
*/
 |..
 |->acpi_boot_table_init() /* Check acpi_tables_addr, if any table 
needs to 
  be overrided, override it. */


Tang Chen (5):
  x86, acpi: Call two new functions instead of acpi_initialize_tables()
in acpi_table_init().
  x86, acpi: Split acpi_table_init() into two parts.
  x86, acpi: Rename check_multiple_madt() and make it global.
  x86, acpi: Split acpi_boot_table_init() into two parts.
  x86, acpi: Initialize acpi golbal root table list earlier.

 arch/x86/kernel/acpi/boot.c |   32 
 arch/x86/kernel/setup.c |8 +++-
 drivers/acpi/tables.c   |   29 +++--
 include/acpi/acpixf.h   |4 
 include/linux/acpi.h|4 
 5 files changed, 58 insertions(+), 19 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

readahead: make context readahead more conservative

[Fengguang Wu]

This helps performance on moderately dense random reads on SSD.

Transaction-Per-Second numbers provided by Taobao:

QPS case
---
7536disable context readahead totally
w/ patch:   7129slower size rampup and start RA on the 3rd read
6717slower size rampup
w/o patch:  5581unmodified context readahead

Before, readahead will be started whenever reading page N+1 when it
happen to read N recently. After patch, we'll only start readahead
when *three* random reads happen to access pages N, N+1, N+2. The
probability of this happening is extremely low for pure random reads,
unless they are very dense, which actually deserves some readahead.

Also start with a smaller readahead window. The impact to interleaved
sequential reads should be small, because for a long run stream, the
the small readahead window rampup phase is negletable.

The context readahead actually benefits clustered random reads on HDD
whose seek cost is pretty high. However as SSD is increasingly used
for random read workloads it's better for the context readahead to
concentrate on interleaved sequential reads.

Another SSD rand read test from Miao

# file size:2GB
# read IO amount: 625MB
sysbench --test=fileio  \
--max-requests=1\
--num-threads=1 \
--file-num=1\
--file-block-size=64K   \
--file-test-mode=rndrd  \
--file-fsync-freq=0 \
--file-fsync-end=offrun

shows the performance of btrfs grows up from 69MB/s to 121MB/s,
ext4 from 104MB/s to 121MB/s.

Tested-by: Tao Ma 
Tested-by: Miao Xie 
Signed-off-by: Wu Fengguang 
---
 mm/readahead.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-next.orig/mm/readahead.c  2013-08-08 16:21:29.675286154 +0800
+++ linux-next/mm/readahead.c   2013-08-08 16:21:33.851286019 +0800
@@ -371,10 +371,10 @@ static int try_context_readahead(struct
size = count_history_pages(mapping, ra, offset, max);
 
/*
-* no history pages:
+* not enough history pages:
 * it could be a random read
 */
-   if (!size)
+   if (size <= req_size)
return 0;
 
/*
@@ -385,8 +385,8 @@ static int try_context_readahead(struct
size *= 2;
 
ra->start = offset;
-   ra->size = get_init_ra_size(size + req_size, max);
-   ra->async_size = ra->size;
+   ra->size = min(size + req_size, max);
+   ra->async_size = 1;
 
return 1;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: device thermal limits represented in device tree nodes

[Mark Rutland]

On Wed, Aug 07, 2013 at 09:18:29PM +0100, Eduardo Valentin wrote:
> Pawel, all,
> 
> On 06-08-2013 07:14, Pawel Moll wrote:
> > Apologies about the delay, I was "otherwise engaged" for a week...
> > 
> 
> I do also excuse for my delay, as I was also "engaged" for a week or so.
> 
> > I hope you haven't lost all motivation to work on this subject, as it's
> > really worth the while!
> 
> Not really! quite the opposite. Although I was looking at some other
> stuff, I got this series also tested on different boards and wrote down
> a couple of improvements I will be working in the coming days. Indeed,
> it is worth moving forward with this work.
> 
> > 
> > On Fri, 2013-07-26 at 20:55 +0100, Eduardo Valentin wrote:
> >> On 25-07-2013 13:33, Pawel Moll wrote:
> >>> On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
> >>thermal_zone {
> >>type = "CPU";
> >
> > So what does this exactly mean? What is so special about CPU? What other
> > types you've got there? (Am I just lazy not looking at the numerous
> > links you provided? ;-)
> 
>  Hehehe. OK. Type is supposed to describe what your zone is representing.
> >>>
> >>> As in "a name"? So, for example "The board", "PSU"? What I meant to ask
> >>> was: does the string carry any meaning?
> > 
> > You haven't commended on this...
> 
> The string is supposed to carry meaning, yes. Couple of common used:
> CPU, GPU, PCB, LCD

I think the point Pawel was getting at is that the string doesn't have a
*well-defined* meaning that always allows an OS to figure out the set of
relevant devices. If we have a thermal zone for "LCD", and have multiple
LCDs, which LCDs are covered? If we have a "PCB" zone, does this cover all
the devices attached to the PCB, a subset thereof, or the substrate of
the PCB itself?

A phandle list to the concerned devices for example would *always* allow
the OS to figure out the set of concerned devices.

> 
> > 
> >>trips {
> >>alert@10{
> >>temperature = <10>; /* milliCelsius
> >>hysteresis = <2000>; /* milliCelsius */
> >>type = ;
> >>};
> >>crit@125000{
> >>temperature = <125000>; /* milliCelsius
> >>hysteresis = <2000>; /* milliCelsius */
> >>type = ;
> >>};
> >>};
> >>bind_params {
> >>action@0{
> >>cooling_device = "thermal-cpufreq";
> >
> > Why is it a string? It seems very Linux-y... (cpufreq) Is there any
> > particular reason not to have phandles to the fans that have any impact
> > on the zone? 
> 
>  Because fans are not the only way to cool your system, specially those
>  systems that don't feature fans. Managing the speed of your CPU is one
>  example of lowering temperature without fans. Managing the load on your
>  system is another way. These are obviously, virtual concepts. And
>  because we have physical ways and logical ways to cool the zone, then I
>  didnt put a phandle to a device there.
> >>>
> >>> "virtual concepts"... This is where my problem lies... It's not hardware
> >>> so it doesn't seem to belong in the tree at the first sight. Shouldn't
> >>
> >> Yeah, in fact, this is exactly the point that creates most of the
> >> disagreement. You may check Guenter's arguments against this proposal
> >> (in my original RFC email, there is a link to it).
> >>
> >> Well, if one don't want to see this as a 'virtual concept' it could say
> >> the cooling device is the cpu itself:
> >>cooling_device = <>;
> > 
> > Would this create any particular problem at the driver/framework side?
> 
> In this case, I believe CPUfreq driver must be thermal aware in this
> case. And we need to cook a way to, whenever there is such link, the
> cpufreq driver instantiates the cooling mechanism. But I need to think a
> little bit more on this, will come back on this point soon.

For the CPU case at least, if we have a thermal zone with an attached
sensor and no real thermal device, I don't think it's too much of a
stretch for the OS to figure out that the only thing it can do is some
cpufreq-like scaling and limiting to attempt to keep below the limits.

I don't think we need to describe the cpu as a cooling device for a cpu,
and I certainly don't think we need to describe a particular mechanism
by which the thermal limits should be maintained (though when we have a
fan, or other active cooling device, describing to the OS that this may
be used is sensible).

> 
> > 
> >>> it focus on "physical data" instead? As in: point at devices that have
> >>> some impact on the conditions? For 

Re: [PATCH] extable: Skip sorting if the table is empty

[Uwe Kleine-König]

Hello,

[adding akpm to Cc:]

On Wed, Jul 17, 2013 at 09:55:11AM +0200, Uwe Kleine-König wrote:
> At least on ARM no-MMU the extable is empty and so there is nothing to
> sort. So add a check for the table to be empty which effectively only
> changes that the misleading pr_notice is suppressed.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
> Hello,
> 
> I first tried to select BUILDTIME_EXTABLE_SORT for ARM no-MMU, too, but that
> failed to build with
> 
>   no __ex_table in  file: vmlinux
> 
> . I didn't dig deeper for the reasons, but maybe this is worth fixing, too?
this doesn't appear in current next and I didn't get any feed back yet.

What do you think?

Thanks
Uwe

>  kernel/extable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/extable.c b/kernel/extable.c
> index 67460b9..832cb28 100644
> --- a/kernel/extable.c
> +++ b/kernel/extable.c
> @@ -41,7 +41,7 @@ u32 __initdata main_extable_sort_needed = 1;
>  /* Sort the kernel's built-in exception table */
>  void __init sort_main_extable(void)
>  {
> - if (main_extable_sort_needed) {
> + if (main_extable_sort_needed && __stop___ex_table > __start___ex_table) 
> {
>   pr_notice("Sorting __ex_table...\n");
>   sort_extable(__start___ex_table, __stop___ex_table);
>   }

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] ARM: at91/dt: remove old main clk definition from sama5d3xcm.dtsi

[Boris BREZILLON]

This patch removes the old main clk node which is now useless as sama5d3
SoCs and boards are no longer compatible with the old at91 clk
implementations.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3xcm.dtsi |   11 ---
 1 file changed, 11 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3xcm.dtsi 
b/arch/arm/boot/dts/sama5d3xcm.dtsi
index f19d5bf..81c3957 100644
--- a/arch/arm/boot/dts/sama5d3xcm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xcm.dtsi
@@ -18,17 +18,6 @@
reg = <0x2000 0x2000>;
};
 
-   clocks {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
-
-   main_clock: clock@0 {
-   compatible = "atmel,osc", "fixed-clock";
-   clock-frequency = <1200>;
-   };
-   };
-
ahb {
apb {
spi0: spi@f0004000 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [v2] Enhanced support for MPC8xx/8xxx watchdog

[Guenter Roeck]

On 08/07/2013 10:50 PM, leroy christophe wrote:

Le 26/06/2013 01:04, Scott Wood a écrit :

On Thu, Feb 28, 2013 at 09:52:22AM +0100, LEROY Christophe wrote:

This patch modifies the behaviour of the MPC8xx/8xxx watchdog. On the MPC8xx,
at 133Mhz, the maximum timeout of the watchdog timer is 1s, which means it must
be pinged twice a second. This is not in line with the Linux watchdog concept
which is based on a default watchdog timeout around 60s.
This patch introduces an intermediate layer between the CPU and the userspace.
The kernel pings the watchdog at the required frequency at the condition that
userspace tools refresh it regularly.
Existing parameter 'timeout' is renamed 'hw_time'.
The new parameter 'timeout' allows to set up the userspace timeout.
The driver also implements the WDIOC_SETTIMEOUT ioctl.

Signed-off-by: Christophe Leroy 


diff -ur linux-3.7.9/drivers/watchdog/mpc8xxx_wdt.c 
linux/drivers/watchdog/mpc8xxx_wdt.c
--- linux-3.7.9/drivers/watchdog/mpc8xxx_wdt.c2013-02-17 19:53:32.0 
+0100
+++ linux/drivers/watchdog/mpc8xxx_wdt.c2013-02-27 16:00:07.0 +0100
@@ -52,10 +52,17 @@
  static struct mpc8xxx_wdt __iomem *wd_base;
  static int mpc8xxx_wdt_init_late(void);
-static u16 timeout = 0x;
-module_param(timeout, ushort, 0);
+#define WD_TIMO 10/* Default timeout = 10 seconds */

If the default Linux watchdog timeout is normally 60 seconds, why is it 10
here?

Looks like each driver has its own default value, but agreed, I change it to 60 
seconds


+static uint timeout = WD_TIMO;
+module_param(timeout, uint, 0);
  MODULE_PARM_DESC(timeout,
-"Watchdog timeout in ticks. (0
hw_timeout would be more legibile -- this is a public interface.

Ok



  static bool reset = 1;
  module_param(reset, bool, 0);
@@ -72,10 +79,12 @@
   * to 0
   */
  static int prescale = 1;
-static unsigned int timeout_sec;
+static unsigned int hw_timo_sec;
+static int wdt_auto = 1;

bool, and add a comment indicating what this means.

Ok



  static unsigned long wdt_is_open;
  static DEFINE_SPINLOCK(wdt_spinlock);
+static unsigned long wdt_last_ping;
  static void mpc8xxx_wdt_keepalive(void)
  {
@@ -91,9 +100,20 @@
  static void mpc8xxx_wdt_timer_ping(unsigned long arg)
  {
-mpc8xxx_wdt_keepalive();
-/* We're pinging it twice faster than needed, just to be sure. */
-mod_timer(_timer, jiffies + HZ * timeout_sec / 2);
+if (wdt_auto)
+wdt_last_ping = jiffies;
+
+if (jiffies - wdt_last_ping <= timeout * HZ) {

So timeout cannot be more than UINT_MAX / HZ...  Might want to check for
that, just in case.

Ok.


What happens if there's a race?  If another CPU updates wdt_last_ping in
parallel, then you could see wdt_last_ping greater than the value you


Using the watchdog infrastructure (which has a mutex to avoid the problem)
would help avoiding this race.


read for jiffies.  Since this is an unsigned comparison, it will fail to
call keepalive.  You might get saved by pinging it twice as often as
necessary, but you shouldn't rely on that.

Euh ... This watchdog is integrated inside the CPU, so there is no chance that 
any external CPU get access to it.


Unless I am missing something, neither jiffies nor wdt_last_ping nor timeout
is integrated inside a CPU.

There are macros for well defined time comparison which you possibly
might want to consider using (such as time_after() and time_before() etc).

My overall feedback is that I believe it would make more sense to convert
the driver to the watchdog infrastructure first, then add the softdog as
second patch.

Guenter




+mpc8xxx_wdt_keepalive();
+/* We're pinging it twice faster than needed, to be sure. */
+mod_timer(_timer, jiffies + HZ * hw_timo_sec / 2);
+}
+}
+
+static void mpc8xxx_wdt_sw_keepalive(void)
+{
+wdt_last_ping = jiffies;
+mpc8xxx_wdt_timer_ping(0);
  }

This isn't new with this patch, but it looks like
mpc8xxx_wdt_keepalive() can be called either from timer context, or with
interrupts enabled... yet it uses a bare spin_lock() rather than an
irq-safe version.  This should be fixed.

Ok, I'll propose another patch for that. Indeed, is the spin_lock needed at all 
? If we get two writes interleaved, it will make it anyway.

Christophe

--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] leds-pca9633: Unique naming of the LEDs

[Ricardo Ribalda Delgado]

If there are more than one pca963x chips on the system and there are
some LEDs without platform_data names, the driver wont be able to
provide unique naming to them.

This will cause led_class_dev_register to fail, unregistering all the
LEDs of the chip.

This patch adds the i2c adress to the name of the unnamed LEDs, making
them unique.

[  555.346827] [ cut here ]
[  555.346844] WARNING: at /build/linux-voe0Su/linux-3.9.8/fs/sysfs/dir.c:536 
sysfs_add_one+0x8b/0x9d()
[  555.346847] Hardware name: QT5022
[  555.346850] sysfs: cannot create duplicate filename '/class/leds/pca9633:6'
[  555.346853] Modules linked in: qt5038_platform(O+) leds_pca9633(O) 
hid_generic ledtrig_default_on rfcomm bnep bluetooth binfmt_misc nfsd 
auth_rpcgss nfs_acl nfs lockd dns_resolver fscache sunrpc nls_utf8 nls_cp437 
vfat fat loop fuse joydev hid_multitouch usbhid hid acpi_cpufreq mperf kvm_amd 
kvm evdev pn533 nfc arc4 microcode pcspkr efivars k10temp ath9k ath9k_common 
ath9k_hw ath fglrx(PO) mac80211 cfg80211 video rfkill processor thermal_sys 
sp5100_tco button i2c_piix4 ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif ahci 
libahci igb i2c_algo_bit i2c_core dca ptp pps_core ehci_pci ohci_hcd ehci_hcd 
libata usbcore usb_common scsi_mod [last unloaded: leds_pca963x]
[  555.346940] Pid: 4766, comm: insmod Tainted: PW  O 3.9-1-amd64 #1 
Debian 3.9.8-1
[  555.346943] Call Trace:
[  555.346956]  [] ? warn_slowpath_common+0x76/0x8c
[  555.346962]  [] ? warn_slowpath_fmt+0x47/0x49
[  555.346968]  [] ? sysfs_pathname+0x3b/0x41
[  555.346973]  [] ? sysfs_add_one+0x8b/0x9d
[  555.346978]  [] ? sysfs_do_create_link_sd+0xe8/0x174
[  555.346985]  [] ? device_add+0x243/0x5ab
[  555.346991]  [] ? complete_all+0x31/0x40
[  555.346998]  [] ? init_timer_key+0xc/0x56
[  555.347004]  [] ? device_create_vargs+0x82/0xb6
[  555.347009]  [] ? device_create+0x2f/0x31
[  555.347014]  [] ? should_resched+0x5/0x23
[  555.347021]  [] ? led_classdev_register+0x24/0x103
[  555.347028]  [] ? pca9633_probe+0x173/0x239 [leds_pca9633]
[  555.347035]  [] ? __driver_attach+0x73/0x73
[  555.347049]  [] ? i2c_device_probe+0x63/0x88 [i2c_core]
[  555.347057]  [] ? driver_probe_device+0x92/0x1b0
[  555.347064]  [] ? bus_for_each_drv+0x43/0x7d
[  555.347070]  [] ? device_attach+0x68/0x83
[  555.347078]  [] ? bus_probe_device+0x25/0x8d
[  555.347083]  [] ? device_add+0x3ea/0x5ab
[  555.347088]  [] ? complete_all+0x31/0x40
[  555.347094]  [] ? init_timer_key+0xc/0x56
[  555.347104]  [] ? i2c_new_device+0x10d/0x179 [i2c_core]
[  555.347112]  [] ? qt5038_init+0x36/0x1000 [qt5038_platform]
[  555.347119]  [] ? 0xa008efff
[  555.347125]  [] ? do_one_initcall+0x74/0x128
[  555.347131]  [] ? 0xa008efff
[  555.347137]  [] ? load_module+0x1af7/0x1dfc
[  555.347144]  [] ? free_notes_attrs+0x3c/0x3c
[  555.347150]  [] ? sys_init_module+0x9e/0xab
[  555.347157]  [] ? system_call_fastpath+0x16/0x1b
[  555.347161] ---[ end trace ad00b85794e0de4d ]---
[  555.347448] leds-pca9633: probe of 0-006b failed with error -17

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/leds/leds-pca9633.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/leds/leds-pca9633.c b/drivers/leds/leds-pca9633.c
index 070358a..4dd7793 100644
--- a/drivers/leds/leds-pca9633.c
+++ b/drivers/leds/leds-pca9633.c
@@ -159,10 +159,11 @@ static int pca9633_probe(struct i2c_client *client,
if (pdata->leds.leds[i].default_trigger)
pca9633[i].led_cdev.default_trigger =
pdata->leds.leds[i].default_trigger;
-   } else {
-   snprintf(pca9633[i].name, sizeof(pca9633[i].name),
-"pca9633:%d", i);
}
+   if (!pdata || i >= pdata->leds.num_leds ||
+   !pdata->leds.leds[i].name)
+   snprintf(pca9633[i].name, sizeof(pca9633[i].name),
+"pca9633:%.2x:%d", client->addr, i);
 
pca9633[i].led_cdev.name = pca9633[i].name;
pca9633[i].led_cdev.brightness_set = pca9633_led_set;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] PCA9633: Add support to PCA9634 and fix some problems

[Ricardo Ribalda Delgado]

Add Support for the PCA9634 chip. Simimart to the 9633, but with 8 outputs 
instead of 4.
Fix bug when 2 chips where present on the system, the ledclass will fail and 
the chip wont probe.
Protect ledout register with a mutex to support updates of more than leds at 
the same time

Ricardo Ribalda Delgado (3):
  leds-pca9633: Add support for PCA9634
  leds-pca9633: Unique naming of the LEDs
  leds-pca9633: Add mutex to the ledout register

 drivers/leds/Kconfig|7 +--
 drivers/leds/leds-pca9633.c |  112 ---
 2 files changed, 87 insertions(+), 32 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] ARM: at91/dt: define sama5d3 clocks

[Boris BREZILLON]

Define sama5d3 clocks in sama5d3 device tree.
Add references to the appropriate clocks in each peripheral.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3.dtsi  |  331 ++-
 arch/arm/boot/dts/sama5d3_can.dtsi  |   19 ++
 arch/arm/boot/dts/sama5d3_emac.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_gmac.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_lcd.dtsi  |   17 ++
 arch/arm/boot/dts/sama5d3_mci2.dtsi |   11 ++
 arch/arm/boot/dts/sama5d3_tcb1.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_uart.dtsi |   19 ++
 8 files changed, 431 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index f0ca1ba..e2791c5 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -14,6 +14,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 / {
model = "Atmel SAMA5D3 family SoC";
@@ -52,6 +56,14 @@
reg = <0x2000 0x800>;
};
 
+   clocks {
+   adc_op_clk: adc_op_clk{
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2000>;
+   };
+   };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
@@ -75,6 +87,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_HSMCI0>;
+   clock-names = "mci_clk";
};
 
spi0: spi@f0004000 {
@@ -88,6 +102,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <_spi0>;
+   clocks = < SAMA5D3_ID_SPI0>;
+   clock-names = "spi_clk";
status = "disabled";
};
 
@@ -97,6 +113,8 @@
interrupts = ;
pinctrl-names = "default";
pinctrl-0 = <_ssc0_tx _ssc0_rx>;
+   clocks = < SAMA5D3_ID_SSC0>;
+   clock-names = "pclk";
status = "disabled";
};
 
@@ -104,6 +122,8 @@
compatible = "atmel,at91sam9x5-tcb";
reg = <0xf001 0x100>;
interrupts = ;
+   clocks = < SAMA5D3_ID_TC0>;
+   clock-names = "t0_clk";
};
 
i2c0: i2c@f0014000 {
@@ -117,6 +137,7 @@
pinctrl-0 = <_i2c0>;
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_TWI0>;
status = "disabled";
};
 
@@ -131,6 +152,7 @@
pinctrl-0 = <_i2c1>;
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_TWI1>;
status = "disabled";
};
 
@@ -140,6 +162,8 @@
interrupts = ;
pinctrl-names = "default";
pinctrl-0 = <_usart0>;
+   clocks = < SAMA5D3_ID_USART0>;
+   clock-names = "usart";
status = "disabled";
};
 
@@ -149,6 +173,8 @@
interrupts = ;
pinctrl-names = "default";
pinctrl-0 = <_usart1>;
+   clocks = < SAMA5D3_ID_USART1>;
+   clock-names = "usart";
status = "disabled";
};
 
@@ -170,6 +196,8 @@
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+   clocks = < SAMA5D3_ID_HSMCI1>;
+   clock-names = "mci_clk";
};
 
spi1: spi@f8008000 {
@@ -183,6 +211,8 @@
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <_spi1>;
+   clocks = < SAMA5D3_ID_SPI1>;
+   clock-names = "spi_clk";
status = 

[PATCH 3/3] leds-pca9633: Add mutex to the ledout register

[Ricardo Ribalda Delgado]

To update an LED a register has to be read, updated and writen. If
another LED whas been updated at the same time, this could lead into
wrong updates.

This patch addes a common mutex to all the leds of the same chip to
protect the ledout register.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/leds/leds-pca9633.c |   63 ---
 1 file changed, 41 insertions(+), 22 deletions(-)

diff --git a/drivers/leds/leds-pca9633.c b/drivers/leds/leds-pca9633.c
index 4dd7793..5e3d36f 100644
--- a/drivers/leds/leds-pca9633.c
+++ b/drivers/leds/leds-pca9633.c
@@ -65,9 +65,17 @@ static const struct i2c_device_id pca9633_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pca9633_id);
 
-struct pca9633_led {
-   struct i2c_client *client;
+struct pca9633_led;
+
+struct pca9633 {
struct pca9633_chipdef *chipdef;
+   struct mutex mutex;
+   struct i2c_client *client;
+   struct pca9633_led *leds;
+};
+
+struct pca9633_led {
+   struct pca9633 *chip;
struct work_struct work;
enum led_brightness brightness;
struct led_classdev led_cdev;
@@ -79,29 +87,32 @@ static void pca9633_led_work(struct work_struct *work)
 {
struct pca9633_led *pca9633 = container_of(work,
struct pca9633_led, work);
-   u8 ledout_addr = pca9633->chipdef->ledout_base + (pca9633->led_num / 4);
+   u8 ledout_addr = pca9633->chip->chipdef->ledout_base
+   + (pca9633->led_num / 4);
u8 ledout;
int shift = 2 * (pca9633->led_num % 4);
u8 mask = 0x3 << shift;
 
-   ledout = i2c_smbus_read_byte_data(pca9633->client, ledout_addr);
+   mutex_lock(>chip->mutex);
+   ledout = i2c_smbus_read_byte_data(pca9633->chip->client, ledout_addr);
switch (pca9633->brightness) {
case LED_FULL:
-   i2c_smbus_write_byte_data(pca9633->client, ledout_addr,
+   i2c_smbus_write_byte_data(pca9633->chip->client, ledout_addr,
(ledout & ~mask) | (PCA9633_LED_ON << shift));
break;
case LED_OFF:
-   i2c_smbus_write_byte_data(pca9633->client, ledout_addr,
+   i2c_smbus_write_byte_data(pca9633->chip->client, ledout_addr,
ledout & ~mask);
break;
default:
-   i2c_smbus_write_byte_data(pca9633->client,
+   i2c_smbus_write_byte_data(pca9633->chip->client,
PCA9633_PWM_BASE + pca9633->led_num,
pca9633->brightness);
-   i2c_smbus_write_byte_data(pca9633->client, ledout_addr,
+   i2c_smbus_write_byte_data(pca9633->chip->client, ledout_addr,
(ledout & ~mask) | (PCA9633_LED_PWM << shift));
break;
}
+   mutex_unlock(>chip->mutex);
 }
 
 static void pca9633_led_set(struct led_classdev *led_cdev,
@@ -123,6 +134,7 @@ static void pca9633_led_set(struct led_classdev *led_cdev,
 static int pca9633_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
+   struct pca9633 *pca9633_chip;
struct pca9633_led *pca9633;
struct pca9633_platform_data *pdata;
struct pca9633_chipdef *chip;
@@ -138,17 +150,30 @@ static int pca9633_probe(struct i2c_client *client,
return -EINVAL;
}
 
+   pca9633_chip = devm_kzalloc(>dev, sizeof(*pca9633_chip),
+   GFP_KERNEL);
+   if (!pca9633_chip)
+   return -ENOMEM;
pca9633 = devm_kzalloc(>dev, chip->n_leds * sizeof(*pca9633),
GFP_KERNEL);
if (!pca9633)
return -ENOMEM;
 
-   i2c_set_clientdata(client, pca9633);
+   i2c_set_clientdata(client, pca9633_chip);
+
+   mutex_init(_chip->mutex);
+   pca9633_chip->chipdef = chip;
+   pca9633_chip->client = client;
+   pca9633_chip->leds = pca9633;
+
+   /* Turn off LEDs by default*/
+   i2c_smbus_write_byte_data(client, chip->ledout_base, 0x00);
+   if (chip->n_leds > 4)
+   i2c_smbus_write_byte_data(client, chip->ledout_base + 1, 0x00);
 
for (i = 0; i < chip->n_leds; i++) {
-   pca9633[i].client = client;
pca9633[i].led_num = i;
-   pca9633[i].chipdef = chip;
+   pca9633[i].chip = pca9633_chip;
 
/* Platform data can specify LED names and default triggers */
if (pdata && i < pdata->leds.num_leds) {
@@ -182,11 +207,6 @@ static int pca9633_probe(struct i2c_client *client,
if (pdata && pdata->outdrv == PCA9633_OPEN_DRAIN)
i2c_smbus_write_byte_data(client, PCA9633_MODE2, 0x01);
 
-   /* Turn off LEDs */
-   i2c_smbus_write_byte_data(client, chip->ledout_base, 0x00);
-   if (chip->n_leds > 4)
-   

[PATCH 4/6] ARM: at91/dt: define sama5d3xek's main clk frequency

[Boris BREZILLON]

Define the main clock frequency for the new main clock node
in sama5d3xcm.dtsi.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3xcm.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3xcm.dtsi 
b/arch/arm/boot/dts/sama5d3xcm.dtsi
index 6a1871b..f19d5bf 100644
--- a/arch/arm/boot/dts/sama5d3xcm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xcm.dtsi
@@ -38,6 +38,12 @@
macb0: ethernet@f0028000 {
phy-mode = "rgmii";
};
+
+   pmc: pmc@fc00 {
+   main: mainck {
+   clock-frequency = <1200>;
+   };
+   };
};
 
nand0: nand@6000 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] ARM: at91: prepare sama5 dt boards transition to common clk

[Boris BREZILLON]

This patch prepare the transition to common clk for sama5 dt boards by
replacing the timer init callback.

Clocks registration cannot be done in early init callback (as formerly done
by the old clk implementation) because it requires dynamic allocation
which is not ready yet during early init.

In the other hand, at91 clocks must be registered before
at91sam926x_pit_init is called because PIT (Periodic Interval Timer) driver
request the master clk (mck).

A new function (at91sama5_dt_timer_init) is created to fullfil these needs.
This function registers all at91 clks using the dt definition before
calling the PIT init function.
The device tree clock registration is enabled only if common clk is
selected. Else the old clk registration is been done during
at91_dt_initialize call.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/board-dt-sama5.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/board-dt-sama5.c 
b/arch/arm/mach-at91/board-dt-sama5.c
index ad95f6a..10b6913 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -26,6 +27,13 @@
 #include "at91_aic.h"
 #include "generic.h"
 
+static void __init sama5_dt_timer_init(void)
+{
+#if defined(CONFIG_COMMON_CLK)
+   of_clk_init(NULL);
+#endif
+   at91sam926x_pit_init();
+}
 
 static const struct of_device_id irq_of_match[] __initconst = {
 
@@ -77,7 +85,7 @@ static const char *sama5_dt_board_compat[] __initdata = {
 
 DT_MACHINE_START(sama5_dt, "Atmel SAMA5 (Device Tree)")
/* Maintainer: Atmel */
-   .init_time  = at91sam926x_pit_init,
+   .init_time  = sama5_dt_timer_init,
.map_io = at91_map_io,
.handle_irq = at91_aic5_handle_irq,
.init_early = at91_dt_initialize,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] leds-pca9633: Add support for PCA9634

[Ricardo Ribalda Delgado]

Add support for PCA9634 chip, which belongs to the same family as the
9633 but with support for 8 outputs instead of 4.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/leds/Kconfig|7 ++--
 drivers/leds/leds-pca9633.c |   74 +++
 2 files changed, 58 insertions(+), 23 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e43402d..023af58 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -280,12 +280,13 @@ config LEDS_PCA955X
  devices include PCA9550, PCA9551, PCA9552, and PCA9553.
 
 config LEDS_PCA9633
-   tristate "LED support for PCA9633 I2C chip"
+   tristate "LED support for PCA963x I2C chip"
depends on LEDS_CLASS
depends on I2C
help
- This option enables support for LEDs connected to the PCA9633
- LED driver chip accessed via the I2C bus.
+ This option enables support for LEDs connected to the PCA963x
+ LED driver chip accessed via the I2C bus. Supported
+ devices include PCA9633 and PCA9634
 
 config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
diff --git a/drivers/leds/leds-pca9633.c b/drivers/leds/leds-pca9633.c
index 9aae567..070358a 100644
--- a/drivers/leds/leds-pca9633.c
+++ b/drivers/leds/leds-pca9633.c
@@ -1,7 +1,9 @@
 /*
  * Copyright 2011 bct electronic GmbH
+ * Copyright 2013 Qtechnology/AS
  *
  * Author: Peter Meerwald 
+ * Author: Ricardo Ribalda 
  *
  * Based on leds-pca955x.c
  *
@@ -10,6 +12,7 @@
  * directory of this archive for more details.
  *
  * LED driver for the PCA9633 I2C LED driver (7-bit slave address 0x62)
+ * LED driver for the PCA9634 I2C LED driver (7-bit slave address set by hw.)
  *
  */
 
@@ -33,20 +36,42 @@
 #define PCA9633_MODE1  0x00
 #define PCA9633_MODE2  0x01
 #define PCA9633_PWM_BASE   0x02
-#define PCA9633_LEDOUT 0x08
+
+enum pca9633_type {
+   pca9633,
+   pca9634,
+};
+
+struct pca9633_chipdef {
+   u8  ledout_base;
+   int n_leds;
+};
+
+static struct pca9633_chipdef pca9633_chipdefs[] = {
+   [pca9633] = {
+   .ledout_base= 0x8,
+   .n_leds = 4,
+   },
+   [pca9634] = {
+   .ledout_base= 0xc,
+   .n_leds = 8,
+   },
+};
 
 static const struct i2c_device_id pca9633_id[] = {
-   { "pca9633", 0 },
+   { "pca9633", pca9633 },
+   { "pca9634", pca9634 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, pca9633_id);
 
 struct pca9633_led {
struct i2c_client *client;
+   struct pca9633_chipdef *chipdef;
struct work_struct work;
enum led_brightness brightness;
struct led_classdev led_cdev;
-   int led_num; /* 0 .. 3 potentially */
+   int led_num; /* 0 .. 7 potentially */
char name[32];
 };
 
@@ -54,24 +79,26 @@ static void pca9633_led_work(struct work_struct *work)
 {
struct pca9633_led *pca9633 = container_of(work,
struct pca9633_led, work);
-   u8 ledout = i2c_smbus_read_byte_data(pca9633->client, PCA9633_LEDOUT);
-   int shift = 2 * pca9633->led_num;
+   u8 ledout_addr = pca9633->chipdef->ledout_base + (pca9633->led_num / 4);
+   u8 ledout;
+   int shift = 2 * (pca9633->led_num % 4);
u8 mask = 0x3 << shift;
 
+   ledout = i2c_smbus_read_byte_data(pca9633->client, ledout_addr);
switch (pca9633->brightness) {
case LED_FULL:
-   i2c_smbus_write_byte_data(pca9633->client, PCA9633_LEDOUT,
+   i2c_smbus_write_byte_data(pca9633->client, ledout_addr,
(ledout & ~mask) | (PCA9633_LED_ON << shift));
break;
case LED_OFF:
-   i2c_smbus_write_byte_data(pca9633->client, PCA9633_LEDOUT,
+   i2c_smbus_write_byte_data(pca9633->client, ledout_addr,
ledout & ~mask);
break;
default:
i2c_smbus_write_byte_data(pca9633->client,
PCA9633_PWM_BASE + pca9633->led_num,
pca9633->brightness);
-   i2c_smbus_write_byte_data(pca9633->client, PCA9633_LEDOUT,
+   i2c_smbus_write_byte_data(pca9633->client, ledout_addr,
(ledout & ~mask) | (PCA9633_LED_PWM << shift));
break;
}
@@ -98,26 +125,30 @@ static int pca9633_probe(struct i2c_client *client,
 {
struct pca9633_led *pca9633;
struct pca9633_platform_data *pdata;
+   struct pca9633_chipdef *chip;
int i, err;
 
+   chip = _chipdefs[id->driver_data];
pdata = client->dev.platform_data;
 
-   if (pdata) {
-   if (pdata->leds.num_leds <= 0 || pdata->leds.num_leds > 4) {
-   dev_err(>dev, "board info must claim at most 4 
LEDs");
-   return -EINVAL;
-   }
+   

[PATCH 0/6] ARM: at91: use new at91 clks for samad3 SoCs

[Boris BREZILLON]

Hello,

This patch series was formerly part of the
"ARM: at91: move to common clk framework" patch series.

It moves sama5d3 SoCs and boards to the new at91 clks (clk implementation
using common clk framework).

This patch series depends on following patch series (they must be applied in
this order):
1) "ARM: at91/dt: split sama5d3 definition" (v1)
2) "ARM: at91/dt: make use of periph id macros" (v2, not submitted yet)
3) "ARM: at91: move to common clk framework" (v3)

I will answer to this mail and join this patch series' dependencies in
attachments.

Best Regards,

Boris

Boris BREZILLON (6):
  ARM: at91: prepare sama5 dt boards transition to common clk
  ARM: at91: prepare common clk transition for sama5d3 SoC
  ARM: at91/dt: define sama5d3 clocks
  ARM: at91/dt: define sama5d3xek's main clk frequency
  ARM: at91: move sama5d3 SoC to common clk
  ARM: at91/dt: remove old main clk definition from sama5d3xcm.dtsi

 arch/arm/boot/dts/sama5d3.dtsi  |  331 ++-
 arch/arm/boot/dts/sama5d3_can.dtsi  |   19 ++
 arch/arm/boot/dts/sama5d3_emac.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_gmac.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_lcd.dtsi  |   17 ++
 arch/arm/boot/dts/sama5d3_mci2.dtsi |   11 ++
 arch/arm/boot/dts/sama5d3_tcb1.dtsi |   12 ++
 arch/arm/boot/dts/sama5d3_uart.dtsi |   19 ++
 arch/arm/boot/dts/sama5d3xcm.dtsi   |   17 +-
 arch/arm/mach-at91/Kconfig  |1 -
 arch/arm/mach-at91/board-dt-sama5.c |   10 +-
 arch/arm/mach-at91/sama5d3.c|6 +-
 12 files changed, 451 insertions(+), 16 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 7 [ call-trace on suspend: ext4 | pm related ? ]

[Sedat Dilek]

On Thu, Aug 8, 2013 at 3:12 AM, Colin Cross  wrote:
> On Wed, Aug 7, 2013 at 6:01 PM, Sedat Dilek  wrote:
>> On Thu, Aug 8, 2013 at 1:34 AM, Colin Cross  wrote:
>>> On Wed, Aug 7, 2013 at 4:15 PM, Sedat Dilek  wrote:
 On Thu, Aug 8, 2013 at 12:58 AM, Colin Cross  wrote:
> Can you try add a call to show_state_filter(TASK_UNINTERRUPTIBLE) in
> the error path of try_to_freeze_tasks(), where it prints the "refusing
> to freeze" message?  It will print the stack trace of every thread
> since they are all in the freezer, so the output will be very long.
>

 If you provide a patch, I will give it a try.
>>>
>>> Try the attached patch.
>>
>> This time I do not see ext4 related messages.
>>
>> - Sedat -
>
> Can you describe your filesystem setup?  It looks like you have an
> ntfs fuse filesystem and a loopback ext4 mount?  Is the file backing
> the loopback ext4 filesystem located on the ntfs filesystem?
>

[ CC fuse folks ]

This is a Ubuntu/precise AMD64 installed in a WUBI environment (rootfs
is an image on my Win7-partition and thus uses fuse/ntfs/loop).

$ cat /etc/fstab
# /etc/fstab: static file system information.

# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).

#   
   
proc/proc   proc
nodev,noexec,nosuid 0   0
/host/ubuntu/disks/root.disk/   ext4
loop,errors=remount-ro  0   1
/host/ubuntu/disks/swap.disknoneswaploop,sw
 0   0

$ df -T
DateisystemTyp  1K-Blöcke   Benutzt Verfügbar Verw% Eingehängt auf
rootfs rootfs17753424  11598008   5230540   69% / <---
18GiB file-image
udev   devtmpfs   1969240 4   19692361% /dev
tmpfs  tmpfs   789036   8847881521% /run
/dev/sda2  fuseblk  465546236 107358584 358187652   24% /host <--- Win7-OS
/dev/loop0 ext4  17753424  11598008   5230540   69% /
none   tmpfs 5120 0  51200% /run/lock
none   tmpfs  1972588   200   19723881% /run/shm

$ sudo LC_ALL=C fdisk -l /dev/sda

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xcb9885ab

   Device Boot  Start End  Blocks   Id  System
/dev/sda1   *2048  206847  1024007  HPFS/NTFS/exFAT
/dev/sda2  206848   931299327   4655462407  HPFS/NTFS/exFAT
/dev/sda3   931299328   97677311922736896   27  Hidden NTFS WinRE

[ /etc/grub.d/40_custom ]
...
menuentry "Ubuntu/precise AMD64, WUBI-system with Ubuntu-kernel"
--class ubuntu --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ntfs
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root 001AADA61AAD9964
loopback loop0 /ubuntu/disks/root.disk
set root=(loop0)
linux /vmlinuz root=UUID=001AADA61AAD9964
loop=/ubuntu/disks/root.disk ro
initrd /initrd.img
}
...

So, no "native" Linux installation here.

- Sedat -

[1] https://wiki.ubuntu.com/WubiGuide

> This looks like the interesting part, the process backing the fuse
> filesystem is frozen (through the normal freeze path, not any of my
> new freeze points), and the loop0 processes are blocked on it.  It
> doesn't seem related to my patches.
>
> [  125.336205] mount.ntfs  D 81811820 0   303  1 
> 0x0004
> [  125.336209]  8800d3e95d18 0002 37a6b000
> 8800d57a66b8
> [  125.336212]  8801185286c0 8800d3e95fd8 8800d3e95fd8
> 8800d3e95fd8
> [  125.336214]  81c144a0 8801185286c0 8800d3e95d08
> 8801185286c0
> [  125.336217] Call Trace:
> [  125.336225]  [] schedule+0x29/0x70
> [  125.336230]  [] __refrigerator+0x43/0xe0
> [  125.336234]  [] get_signal_to_deliver+0x5b9/0x600
> [  125.336238]  [] ? fuse_dev_read+0x68/0x80
> [  125.336242]  [] do_signal+0x58/0x8f0
> [  125.336246]  [] ? acct_account_cputime+0x1c/0x20
> [  125.336249]  [] ? do_raw_spin_unlock+0x5d/0xb0
> [  125.336252]  [] ? _raw_spin_unlock+0xe/0x10
> [  125.336255]  [] ? vtime_account_user+0x6d/0x80
> [  125.336258]  [] do_notify_resume+0x88/0xc0
> [  125.336261]  [] int_signal+0x12/0x17
> [  125.336263] loop0   D 81811820 0   310  2 
> 0x
> [  125.336265]  8800d573d968 0002 
> 8800d57aeb80
> [  125.336268]  880118bda740 8800d573dfd8 8800d573dfd8
> 8800d573dfd8
> [  125.336270]  880119f98340 880118bda740 8800d573d968
> 88011fad5118
> [  125.336273] Call Trace:
> [  125.336278]  [] ? __lock_page+0x70/0x70
> 

Re: [PATCH 01/23] radix-tree: implement preload for multiple contiguous elements

[Kirill A. Shutemov]

Kirill A. Shutemov wrote:
> In this case it should use 39 nodes, but it uses only 38. I can't understand 
> why. :(

Okay, I've got it. We share one 2nd level node.

Patch is below. Please review.

>From 35ba5687ea7aea98645da34ddd0be01a9de8b32d Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" 
Date: Wed, 9 Jan 2013 13:25:47 +0200
Subject: [PATCH] radix-tree: implement preload for multiple contiguous
 elements

The radix tree is variable-height, so an insert operation not only has
to build the branch to its corresponding item, it also has to build the
branch to existing items if the size has to be increased (by
radix_tree_extend).

The worst case is a zero height tree with just a single item at index 0,
and then inserting an item at index ULONG_MAX. This requires 2 new branches
of RADIX_TREE_MAX_PATH size to be created, with only the root node shared.

Radix tree is usually protected by spin lock. It means we want to
pre-allocate required memory before taking the lock.

Currently radix_tree_preload() only guarantees enough nodes to insert
one element. It's a hard limit. For transparent huge page cache we want
to insert HPAGE_PMD_NR (512 on x86-64) entries to address_space at once.

This patch introduces radix_tree_preload_count(). It allows to
preallocate nodes enough to insert a number of *contiguous* elements.
The feature costs about 9KiB per-CPU on x86_64, details below.

Preload uses per-CPU array to store nodes. The total cost of preload is
"array size" * sizeof(void*) * NR_CPUS. We want to increase array size
to be able to handle 512 entries at once.

Size of array depends on system bitness and on RADIX_TREE_MAP_SHIFT.

We have three possible RADIX_TREE_MAP_SHIFT:

 #ifdef __KERNEL__
 #define RADIX_TREE_MAP_SHIFT   (CONFIG_BASE_SMALL ? 4 : 6)
 #else
 #define RADIX_TREE_MAP_SHIFT   3   /* For more stressful testing */
 #endif

We are not going to use transparent huge page cache on small machines or
in userspace, so we are interested in RADIX_TREE_MAP_SHIFT=6.

On 64-bit system old array size is 21, new is 37. Per-CPU feature
overhead is
 for preload array:
   (37 - 21) * sizeof(void*) = 128 bytes
 plus, if the preload array is full
   (37 - 21) * sizeof(struct radix_tree_node) = 16 * 560 = 8960 bytes
 total: 9088 bytes

On 32-bit system old array size is 11, new is 22. Per-CPU feature
overhead is
 for preload array:
   (22 - 11) * sizeof(void*) = 44 bytes
 plus, if the preload array is full
   (22 - 11) * sizeof(struct radix_tree_node) = 11 * 296 = 3256 bytes
 total: 3300 bytes

Since only THP uses batched preload at the moment, we disable (set max
preload to 1) it if !CONFIG_TRANSPARENT_HUGEPAGE_PAGECACHE. This can be
changed in the future.

Signed-off-by: Matthew Wilcox 
Signed-off-by: Kirill A. Shutemov 
Acked-by: Dave Hansen 
---
 include/linux/radix-tree.h | 11 ++
 lib/radix-tree.c   | 89 +-
 2 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
index 4039407..3bf0b3e 100644
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h
@@ -83,6 +83,16 @@ do { 
\
(root)->rnode = NULL;   \
 } while (0)
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE_PAGECACHE
+/*
+ * At the moment only THP uses preload for more then on item for batched
+ * pagecache manipulations.
+ */
+#define RADIX_TREE_PRELOAD_NR  512
+#else
+#define RADIX_TREE_PRELOAD_NR  1
+#endif
+
 /**
  * Radix-tree synchronization
  *
@@ -232,6 +242,7 @@ unsigned long radix_tree_prev_hole(struct radix_tree_root 
*root,
unsigned long index, unsigned long max_scan);
 int radix_tree_preload(gfp_t gfp_mask);
 int radix_tree_maybe_preload(gfp_t gfp_mask);
+int radix_tree_maybe_preload_contig(unsigned size, gfp_t gfp_mask);
 void radix_tree_init(void);
 void *radix_tree_tag_set(struct radix_tree_root *root,
unsigned long index, unsigned int tag);
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 7811ed3..980e4c4 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -84,14 +84,54 @@ static struct kmem_cache *radix_tree_node_cachep;
  * of RADIX_TREE_MAX_PATH size to be created, with only the root node shared.
  * Hence:
  */
-#define RADIX_TREE_PRELOAD_SIZE (RADIX_TREE_MAX_PATH * 2 - 1)
+#define RADIX_TREE_PRELOAD_MIN (RADIX_TREE_MAX_PATH * 2 - 1)
+
+/*
+ * Inserting N contiguous items is more complex. To simplify calculation, let's
+ * limit N (validated in radix_tree_init()):
+ *  - N is multiplier of RADIX_TREE_MAP_SIZE (or 1);
+ *  - N <= number of items 2-level tree can contain:
+ *1UL << (2 * RADIX_TREE_MAP_SHIFT).
+ *
+ * No limitation on insert index alignment.
+ *
+ * Then the worst case is tree with only one element at index 0 and we add N
+ * items where at least one index requires max tree high and we cross boundary
+ * between items in 

Re: [PATCH 1/3] dmatest: make module parameters writable

[Andy Shevchenko]

On Fri, 2013-08-02 at 17:49 +, Dan Williams wrote: 
> 
> On 7/31/13 7:28 AM, "Andy Shevchenko" 
> wrote:
> 
> >On Tue, 2013-07-23 at 18:36 +0300, Andy Shevchenko wrote:
> >> The debugfs interface brought a copy of the test case parameters. This
> >>makes
> >> different set of values under /sys/module/dmatest/parameters/ and
> >> /sys/kernel/debug/dmatest/. The user might be confused by the
> >>divergence of
> >> values.
> >> 
> >> The proposed solution in this patch is to make module parameters
> >>writable and
> >> remove them from the debugfs. Though we're still using debugfs to
> >>control test
> >> runner and getting results.
> >> 
> >> Documentation part is updated accordingly.
> >> 
> >> Signed-off-by: Andy Shevchenko 
> >> Suggested-by: Dan Williams 
> >
> >Dan, do you have any comments against this series?
> >I'd like to have this incorporated into v3.12.
> 
> I like this direction, and these can go in as is.  

So, could it be considered as your ACK?
If so, I think it would be better to push it early to be in time for
v3.12

> But I think with a bit
> more work we can eventually trim the Œresults' file and the
> thread_{add|get}_result infrastructure.  Ideally we could move all result
> reporting to ftrace and let a module parameter control which errors are
> reported.
> 
> However, unless I missed it, I don¹t see this support[1] upstream yet.
> 
> 
> --
> Dan
> 
> [1]: https://lwn.net/Articles/432186/
> 

-- 
Andy Shevchenko 
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] hwmon: (lm90) Add power control

[Guenter Roeck]

On 08/07/2013 11:56 PM, Wei Ni wrote:

The device lm90 can be controlled by the vdd rail.
Adding the power control support to power on/off the vdd rail.
And make sure that power is enabled before accessing the device.

Signed-off-by: Wei Ni 
---
  drivers/hwmon/lm90.c |   49 +
  1 file changed, 49 insertions(+)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index cdff742..306a348 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -89,6 +89,7 @@
  #include 
  #include 
  #include 
+#include 

  /*
   * Addresses to scan
@@ -302,6 +303,7 @@ static const struct lm90_params lm90_params[] = {
  struct lm90_data {
struct device *hwmon_dev;
struct mutex update_lock;
+   struct regulator *lm90_reg;
char valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
int kind;
@@ -1391,6 +1393,32 @@ static void lm90_init_client(struct i2c_client *client)
i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1, config);
  }

+static void lm90_power_control(struct i2c_client *client, bool is_enable)
+{
+   struct lm90_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   if (!data->lm90_reg)
+   return;
+
+   mutex_lock(>update_lock);
+


This is only called during probe and remove, so the mutex is unnecessary.


+   if (is_enable)
+   ret = regulator_enable(data->lm90_reg);
+   else
+   ret = regulator_disable(data->lm90_reg);
+
+   if (ret < 0)
+   dev_err(>dev,
+   "Error in %s rail vdd, error %d\n",
+   (is_enable) ? "enabling" : "disabling", ret);
+   else
+   dev_info(>dev, "success in %s rail vdd\n",
+(is_enable) ? "enabling" : "disabling");
+

which reduces the function to (pretty much unnecessary) messages and an if 
statement
which you only need because you have the function.

You should just call regulator_enable in probe and regulator_disable in remove.

Guenter


+   mutex_unlock(>update_lock);
+}
+
  static int lm90_probe(struct i2c_client *client,
  const struct i2c_device_id *id)
  {
@@ -1406,6 +1434,20 @@ static int lm90_probe(struct i2c_client *client,
i2c_set_clientdata(client, data);
mutex_init(>update_lock);

+   data->lm90_reg = regulator_get(>dev, "vdd");


You should use devm_regulator_get(). Then you also don't need the call to 
regulator_put().


+   if (IS_ERR_OR_NULL(data->lm90_reg)) {


The function never returns NULL except if the regulator subsystem is not 
configured,
so IS_ERR() is more appropriate.

If the regulator subsystem is not configured, you especially don't need or want
to pollute the log with an error message.


+   if (PTR_ERR(data->lm90_reg) == -ENODEV)
+   dev_info(>dev,
+"No regulator found for vdd. Assuming vdd is always 
powered.");
+   else
+   dev_warn(>dev,
+"Error [%ld] in getting the regulator handle for 
vdd.\n",
+PTR_ERR(data->lm90_reg));


I consider the messages unnecessary and confusing. You are polluting the log
of pretty much every PC user who has one of the supported chips in the system,
and of everyone else not using regulators for this chip.


+   data->lm90_reg = NULL;


As pointed out, this is unnecessary, and you should handle -EPROBE_DEFER 
correctly.


+   }
+
+   lm90_power_control(client, true);
+
/* Set the device type */
data->kind = id->driver_data;
if (data->kind == adm1032) {
@@ -1473,6 +1515,10 @@ exit_remove_files:
lm90_remove_files(client, data);
  exit_restore:
lm90_restore_conf(client, data);
+   lm90_power_control(client, false);
+   if (data->lm90_reg)
+   regulator_put(data->lm90_reg);
+
return err;
  }

@@ -1483,6 +1529,9 @@ static int lm90_remove(struct i2c_client *client)
hwmon_device_unregister(data->hwmon_dev);
lm90_remove_files(client, data);
lm90_restore_conf(client, data);
+   lm90_power_control(client, false);
+   if (data->lm90_reg)
+   regulator_put(data->lm90_reg);

return 0;
  }



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] Export the ecc step size to user applications

[Huang Shijie]

Hi Artem & Brian:
> In order to implement the NAND boot for some Freescale's chips, such as
> imx23/imx28/imx50/imx6, we use a tool (called kobs-ng) to burn the uboot
> and some metadata to nand chip. And the ROM code will use the metadata to
> configrate the BCH, and to find the uboot.
>
> The ECC information(ecc step size, ecc strength) which is used to configrate
> the BCH is part of the metadata. The kobs-ng can gets the ecc strength from
> the sys node /sys/*/mtdX/ecc_strength now. But it can't gets the ecc step 
> size.
>
> This patch set is used to export the ecc step size to user applications.
> With this patch set, the kobs-ng can gets the ecc step size now.
>
> v1 --> v2:
>   [1] rename the ecc_size to ecc_step.
>   [2] rebase on the latest l2-mtd.
>
> Huang Shijie (4):
>   mtd: add a new field to mtd_info{}
>   mtd: add a new sys node to show the ecc step size
>   mtd: set the ecc step size for master/slave mtd_info
>   mtd: gpmi: update the ecc step size for mtd_info{}
>
>  drivers/mtd/mtdcore.c  |   11 +++
>  drivers/mtd/mtdpart.c  |1 +
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |1 +
>  drivers/mtd/nand/nand_base.c   |1 +
>  include/linux/mtd/mtd.h|3 +++
>  5 files changed, 17 insertions(+), 0 deletions(-)
>
Could you merge this patch set ?

thanks
Huang Shijie


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] Tegra: Use cpufreq-cpu0 driver

[Viresh Kumar]

On 8 August 2013 14:01, Richard Zhao  wrote:
> On Wed, Aug 7, 2013 at 10:46 PM, Viresh Kumar  wrote:
>> Hi Stephen,
>>
>> This is the first attempt to get rid of tegra-cpufreq driver. This patchset
>> tries to add supporting infrastructure for tegra to use cpufreq-cpu0 driver.
>
> If tegra has only 4-core fast cpu, I would agree with the patch set. But now
> I'm not so sure. Tegra cpuquiet driver and cluster switch may need special
> settings of cpufreq driver.

I am not familiar with the latest happenings.. This change should be good
enough for not breaking anything that is working with current tegra cpufreq
driver.. If there is a new SoC with different needs then we can talk about it
separately.. As that might not be able to use tegra-cpufreq driver anyway..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 00/10] mtd: add datasheet's ECC information to nand_chip{}

[Huang Shijie]

Hi Artem & Brian:

Hi Huang and others,

On Thu, May 16, 2013 at 8:17 PM, Huang Shijie  wrote:

1.) Why add the ECC information to the nand_chip{} ?
Each nand chip has its requirement for the ECC correctability, such as
"4bit ECC for each 512Byte" or "40bit ECC for each 1024Byte".
This ECC info is very important to the nand controller, such as gpmi.

Take the Micron MT29F64G08CBABA for example, its geometry is
8k page size, 744 bytes oob size and it requires 40bit ECC per 1K bytes.
If we do not provide the ECC info to the gpmi nand driver, it has to
calculate the ECC correctability itself. The gpmi driver will gets the 56bit
ECC for per 1K bytes which is beyond its BCH's 40bit ecc capibility.
The gpmi will quits in this case. But in actually, the gpmi can supports
this nand chip if it can get the right ECC info.

2.) About the patch set:
2.1) patch 1:
   The keynote patch.

2.2) patch 2 ~ patch 6:
These patches are for ONFI nand.
Parse out the ecc info from the parameter page if we can, else
parse out the ecc info from the extended parameter page.

2.2) patch 7 ~ patch 9:
Add the ECC info for full-id nand, and parse it out.

2.3) patch 10
The gpmi uses the ecc info to set the BCH module. and with this
patch set, the gpmi can supports the MT29F64G08CBABA now.

What's the status on this patch set? Surely by v6 we have some
reasonable stable state on things like naming. Does anyone have any
other objections? Unfortunately, I've been awfully distracted, and on
top of that, I'm running into some bugs with my NAND controller
sending the ONFI parameter read/change column commands. But any time
my controller actually outputs a correct parameter page + extended
parameter page, this series has worked for me.

I've put my 2 cents in on most of the issues I had, and I tested the
whole series on my driver at around v5. The only issues I have with it
are somewhat cosmetic and not worth bikeshedding. So for all the
non-GPMI specific stuff I'll give my:

Reviewed-by: Brian Norris
Tested-by: Brian Norris

Thanks for the work Huang.

Brian


Could you please merge this patch set?


thanks

Huang Shijie


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] Tegra: Use cpufreq-cpu0 driver

[Richard Zhao]

On Wed, Aug 7, 2013 at 10:46 PM, Viresh Kumar  wrote:
> Hi Stephen,
>
> This is the first attempt to get rid of tegra-cpufreq driver. This patchset
> tries to add supporting infrastructure for tegra to use cpufreq-cpu0 driver.

If tegra has only 4-core fast cpu, I would agree with the patch set. But now
I'm not so sure. Tegra cpuquiet driver and cluster switch may need special
settings of cpufreq driver.

Thanks
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 02/11] tracing: add basic event trigger framework

[Masami Hiramatsu]

(2013/07/30 1:40), Tom Zanussi wrote:
> +struct event_command {
> + struct list_headlist;
> + char*name;
> + enum trigger_mode   trigger_mode;
> + boolpost_trigger;
> + int (*func)(struct event_command *cmd_ops,
> + void *cmd_data, char *glob, char *cmd,
> + char *params, int enable);
> + int (*reg)(char *glob,
> +struct event_trigger_ops *trigger_ops,
> +void *trigger_data, void *cmd_data);
> + void(*unreg)(char *glob,
> +  struct event_trigger_ops *trigger_ops,
> +  void *trigger_data, void *cmd_data);
> + int (*set_filter)(char *filter_str,
> +   void *trigger_data,
> +   void *cmd_data);

I think you should pass trace_event_file *file (see below) instead of ambiguous
void *cmd_data, because all handler implementations expect that.


[...]
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "trace.h"
> +
> +static LIST_HEAD(trigger_commands);
> +static DEFINE_MUTEX(trigger_cmd_mutex);
> +
> +struct event_trigger_data {
> + struct ftrace_event_file*file;
> + unsigned long   count;
> + int ref;
> + boolenable;
> + struct event_trigger_ops*ops;
> + enum trigger_mode   mode;
> + struct event_filter *filter;
> + char*filter_str;
> + struct list_headlist;
> +};
> +
> +struct trigger_iterator {
> + struct ftrace_event_file*file;
> +};

Why would you define this trigger_iterator even if it has
only one member? This means all iterators can be replaced
by the file. I'd like to keep it simple.

> +
> +void event_triggers_call(struct ftrace_event_file *file)
> +{
> + struct event_trigger_data *data;
> +
> + if (list_empty(>triggers))
> + return;
> +
> + preempt_disable_notrace();
> + list_for_each_entry_rcu(data, >triggers, list)
> + data->ops->func((void **));
> + preempt_enable_notrace();
> +}
> +EXPORT_SYMBOL_GPL(event_triggers_call);
> +
> +static void *trigger_next(struct seq_file *m, void *t, loff_t *pos)
> +{
> + struct trigger_iterator *iter = m->private;
> +
> + return seq_list_next(t, >file->triggers, pos);
> +}
> +
> +static void *trigger_start(struct seq_file *m, loff_t *pos)
> +{
> + struct trigger_iterator *iter = m->private;
> +
> + mutex_lock(_mutex);
> +
> + return seq_list_start(>file->triggers, *pos);
> +}

By Oleg's bugfixes, we are now using event_file_data(filp)
please refer the f_start/trace_format_open implementation
which is the closest usage of the trigger file.


> +static int event_trigger_regex_open(struct inode *inode, struct file *file)
> +{
> + struct trigger_iterator *iter;
> + int ret = 0;
> +
> + iter = kzalloc(sizeof(*iter), GFP_KERNEL);
> + if (!iter)
> + return -ENOMEM;
> +
> + mutex_lock(_mutex);
> +
> + iter->file = inode->i_private;
> +
> + if (file->f_mode & FMODE_READ) {
> + ret = seq_open(file, _triggers_seq_ops);
> + if (!ret) {
> + struct seq_file *m = file->private_data;
> + m->private = iter;
> + } else {
> + /* Failed */
> + kfree(iter);
> + }
> + } else
> + file->private_data = iter;
> +
> + mutex_unlock(_mutex);
> +
> + return ret;
> +}

As you can see in trace_format_open(), now file->private_data and
m->private will point struct file *, don't need to allocate something.

> +static ssize_t event_trigger_regex_write(struct file *file,
> +  const char __user *ubuf,
> +  size_t cnt, loff_t *ppos, int enable)
> +{
> + struct trigger_iterator *iter = file->private_data;
> + ssize_t ret;
> + char *buf;
> +
> + if (!cnt)
> + return 0;
> +
> + if (cnt >= PAGE_SIZE)
> + return -EINVAL;
> +
> + if (file->f_mode & FMODE_READ) {
> + struct seq_file *m = file->private_data;
> + iter = m->private;
> + } else
> + iter = file->private_data;
> +
> + buf = (char *)__get_free_page(GFP_TEMPORARY);
> + if (!buf)
> + return -ENOMEM;
> +
> + if (copy_from_user(buf, ubuf, cnt)) {
> + free_page((unsigned long) buf);
> + return -EFAULT;
> + }
> + buf[cnt] = '\0';
> + strim(buf);
> +
> + ret = trigger_process_regex(iter, buf, enable);

You also need to 

[PATCH v3 19/19] ARM: at91: add new compatible strings for pmc driver

[Boris BREZILLON]

This patch adds new compatible string for PMC node to prepare the
transition to common clk.

These compatible string come from pmc driver in clk subsystem and are
needed to provide new device tree compatibility with old at91 clks
(device tree using common clks will use the new compatible strings).

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/clock.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index 5f02aea..4d4463a 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c
@@ -884,6 +884,12 @@ static int __init at91_pmc_init(unsigned long main_clock)
 #if defined(CONFIG_OF)
 static struct of_device_id pmc_ids[] = {
{ .compatible = "atmel,at91rm9200-pmc" },
+   { .compatible = "atmel,at91sam9260-pmc" },
+   { .compatible = "atmel,at91sam9g45-pmc" },
+   { .compatible = "atmel,at91sam9n12-pmc" },
+   { .compatible = "atmel,at91sam9x5-pmc" },
+   { .compatible = "atmel,at91sam9g35-pmc" },
+   { .compatible = "atmel,sama5d3-pmc" },
{ /*sentinel*/ }
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 18/19] ARM: at91: move pit timer to common clk framework

[Boris BREZILLON]

Use device tree to get the source clock of the PIT (Periodic Interval Timer).
If the clock is not found in device tree (or dt is not enabled) we'll try to
get it using clk_lookup definitions.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/at91sam926x_time.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/at91sam926x_time.c 
b/arch/arm/mach-at91/at91sam926x_time.c
index 3a4bc2e..8ac976a 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -39,6 +39,7 @@
 static u32 pit_cycle;  /* write-once */
 static u32 pit_cnt;/* access only w/system irq blocked */
 static void __iomem *pit_base_addr __read_mostly;
+static struct clk *mck;
 
 static inline unsigned int pit_read(unsigned int reg_offset)
 {
@@ -195,10 +196,14 @@ static int __init of_at91sam926x_pit_init(void)
if (!pit_base_addr)
goto node_err;
 
+   mck = of_clk_get(np, 0);
+
/* Get the interrupts property */
ret = irq_of_parse_and_map(np, 0);
if (!ret) {
pr_crit("AT91: PIT: Unable to get IRQ from DT\n");
+   if (!IS_ERR(mck))
+   clk_put(mck);
goto ioremap_err;
}
at91sam926x_pit_irq.irq = ret;
@@ -230,6 +235,8 @@ void __init at91sam926x_pit_init(void)
unsignedbits;
int ret;
 
+   mck = ERR_PTR(-ENOENT);
+
/* For device tree enabled device: initialize here */
of_at91sam926x_pit_init();
 
@@ -237,7 +244,12 @@ void __init at91sam926x_pit_init(void)
 * Use our actual MCK to figure out how many MCK/16 ticks per
 * 1/HZ period (instead of a compile-time constant LATCH).
 */
-   pit_rate = clk_get_rate(clk_get(NULL, "mck")) / 16;
+   if (IS_ERR(mck))
+   mck = clk_get(NULL, "mck");
+
+   if (IS_ERR(mck))
+   panic("AT91: PIT: Unable to get mck clk\n");
+   pit_rate = clk_get_rate(mck) / 16;
pit_cycle = (pit_rate + HZ/2) / HZ;
WARN_ON(((pit_cycle - 1) & ~AT91_PIT_PIV) != 0);
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/1 resend] i2c: rcar: modify I2C driver

[Wolfram Sang]

On Thu, Aug 08, 2013 at 10:13:16AM +0900, Nguyen Viet Dung wrote:

> Difference between H2 and H1 in hardware is only CDF bit of ICCCR register.

No IP version register? Sigh...

> If this method is not a common method, please tell me about common method.

Use a new platform_device_id and populate the driver_data with the info
needed to distinguish between the revisions. Check i2c-imx.c for an
example.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Does PVOPS guest os support online "suspend/resume"?

[Peter Huang(Peng)]

While suspend and resume a PVOPS guest os while it's running, we found that it
would get its block/net io stucked. However, non-PVOPS guest os has no such
problem.

In non-PVOPS guest os, although they don't have blkfront SUSPEND method either,
their xen-driver doesn't resume blkfront device, thus, they would't have any 
problem
after suspend/resume.


I'm wondering why the 2 types of driver(PVOPS and non-PVOPS) are different here.
Is that because:
1) PVOPS kernel doesn't take this situation into accont, and has a bug here?
or
2) PVOPS has other ways to avoid such problem?

thank you in advance.

reproduce steps:
---
1/1

Steps to reproduce:
--
1)suspend guest os
Note: do not migrate/shutdown the guest os.
2)resume guest os

(Think about rolling-back(resume) during core-dumping(suspend) a guest, such
problem would cause the guest os unoprationable.)


we found warning messages in guest os:

Aug 2 10:17:34 localhost kernel: [38592.985159] platform pcspkr: resume
Aug 2 10:17:34 localhost kernel: [38592.989890] platform vesafb.0: resume
Aug 2 10:17:34 localhost kernel: [38592.996075] input input0: type resume
Aug 2 10:17:34 localhost kernel: [38593.001330] input input1: type resume
Aug 2 10:17:34 localhost kernel: [38593.005496] vbd vbd-51712: legacy resume
Aug 2 10:17:34 localhost kernel: [38593.011506] WARNING: g.e. still in use!
Aug 2 10:17:34 localhost kernel: [38593.016909] WARNING: leaking g.e. and page 
still in use!
Aug 2 10:17:34 localhost kernel: [38593.026204] xen vbd-51760: legacy resume
Aug 2 10:17:34 localhost kernel: [38593.033070] vif vif-0: legacy resume
Aug 2 10:17:34 localhost kernel: [38593.039327] WARNING: g.e. still in use!
Aug 2 10:17:34 localhost kernel: [38593.045304] WARNING: leaking g.e. and page 
still in use!
Aug 2 10:17:34 localhost kernel: [38593.052101] WARNING: g.e. still in use!
Aug 2 10:17:34 localhost kernel: [38593.057965] WARNING: leaking g.e. and page 
still in use!
Aug 2 10:17:34 localhost kernel: [38593.066795] serial8250 serial8250: resume
Aug 2 10:17:34 localhost kernel: [38593.073556] input input2: type resume
Aug 2 10:17:34 localhost kernel: [38593.079385] platform Fixed MDIO bus.0: 
resume
Aug 2 10:17:34 localhost kernel: [38593.086285] usb usb1: type resume
--

which means that we refers to a grant-table while it's in use.

The reason results in that:
suspend/resume codes:

//drivers/xen/manage.c
static void do_suspend(void)
{
int err;
struct suspend_info si;

shutting_down = SHUTDOWN_SUSPEND;

……
err = dpm_suspend_start(PMSG_FREEZE);
……
dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE);

if (err) {
pr_err("failed to start xen_suspend: %d\n", err);
si.cancelled = 1;
}
//NOTE: si.cancelled = 1

out_resume:
if (!si.cancelled) {
xen_arch_resume();
xs_resume();
} else
xs_suspend_cancel();

dpm_resume_end(si.cancelled ? PMSG_THAW : PMSG_RESTORE); //blkfront device got 
resumed here.

out_thaw:
#ifdef CONFIG_PREEMPT
thaw_processes();
out:
#endif
shutting_down = SHUTDOWN_INVALID;
}


Func "dpm_suspend_start" suspends devices, and "dpm_resume_end" resumes devices.
However, we found that the device "blkfront" has no SUSPEND method but RESUME 
method.

-
//drivers/block/xen-blkfront.c
static DEFINE_XENBUS_DRIVER(blkfront, ,
.probe = blkfront_probe,
.remove = blkfront_remove,
.resume = blkfront_resume, // only RESUME method found here.
.otherend_changed = blkback_changed,
.is_ready = blkfront_is_ready,
);
--

It resumes blkfront device when it didn't get suspended, which caused the 
prolem above.


=
In order to check whether it's the problem of PVOPS or hypervisor(xen)/dom0, we 
suspend/resume
other non-PVOPS guest oses, no such problem occured.

Other non-PVOPS are using their own xen drivers, as shown in 
https://github.com/jpaton/xen-4.1-LJX1/
blob/master/unmodified_drivers/linux-2.6/platform-pci/machine_reboot.c :

int __xen_suspend(int fast_suspend, void (*resume_notifier)(int))
{
int err, suspend_cancelled, nr_cpus;
struct ap_suspend_info info;

xenbus_suspend();


preempt_enable();

if (!suspend_cancelled)
xenbus_resume(); //when the guest os get resumed, suspend_cancelled == 1, thus 
it wouldn't
enter xenbus_resume_uvp here.
else
xenbus_suspend_cancel(); //It gets here. so the blkfront wouldn't resume.

return 0;
}



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/10] leds: lp5521: restore legacy device attributes

[Milo Kim]

git commit 9ce7cb170f97f83a78dc948bf7d25690f15e1328
may cause an application confict, engineN_mode and engineN_load.
This interface should be maintained for compatibility.

Restored device attributes are 'engineN_mode' and 'engineN_load'.
A 'selftest' attribute macro is replaced with LP55xx common macro.

Use a mutex in lp5521_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5521_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.

'led_pattern' attribute is not included
: engineN_mode and _load were created for custom user-application.
'led_pattern' is an exception. I added this attribute not for custom application
but for simple test. Now it is used only in LP5562 driver, not LP5521.

Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp5521.c |  104 ++--
 1 file changed, 100 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 9e28dd0..c00f922 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -251,10 +251,20 @@ static int lp5521_update_program_memory(struct 
lp55xx_chip *chip,
goto err;
 
program_size = i;
-   for (i = 0; i < program_size; i++)
-   lp55xx_write(chip, addr[idx] + i, pattern[i]);
 
-   return 0;
+   mutex_lock(>lock);
+
+   for (i = 0; i < program_size; i++) {
+   ret = lp55xx_write(chip, addr[idx] + i, pattern[i]);
+   if (ret) {
+   mutex_unlock(>lock);
+   return -EINVAL;
+   }
+   }
+
+   mutex_unlock(>lock);
+
+   return size;
 
 err:
dev_err(>cl->dev, "wrong pattern format\n");
@@ -365,6 +375,80 @@ static void lp5521_led_brightness_work(struct work_struct 
*work)
mutex_unlock(>lock);
 }
 
+static ssize_t show_engine_mode(struct device *dev,
+   struct device_attribute *attr,
+   char *buf, int nr)
+{
+   struct lp55xx_led *led = i2c_get_clientdata(to_i2c_client(dev));
+   struct lp55xx_chip *chip = led->chip;
+   enum lp55xx_engine_mode mode = chip->engines[nr - 1].mode;
+
+   switch (mode) {
+   case LP55XX_ENGINE_RUN:
+   return sprintf(buf, "run\n");
+   case LP55XX_ENGINE_LOAD:
+   return sprintf(buf, "load\n");
+   case LP55XX_ENGINE_DISABLED:
+   default:
+   return sprintf(buf, "disabled\n");
+   }
+}
+show_mode(1)
+show_mode(2)
+show_mode(3)
+
+static ssize_t store_engine_mode(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len, int nr)
+{
+   struct lp55xx_led *led = i2c_get_clientdata(to_i2c_client(dev));
+   struct lp55xx_chip *chip = led->chip;
+   struct lp55xx_engine *engine = >engines[nr - 1];
+
+   mutex_lock(>lock);
+
+   chip->engine_idx = nr;
+
+   if (!strncmp(buf, "run", 3)) {
+   lp5521_run_engine(chip, true);
+   engine->mode = LP55XX_ENGINE_RUN;
+   } else if (!strncmp(buf, "load", 4)) {
+   lp5521_stop_engine(chip);
+   lp5521_load_engine(chip);
+   engine->mode = LP55XX_ENGINE_LOAD;
+   } else if (!strncmp(buf, "disabled", 8)) {
+   lp5521_stop_engine(chip);
+   engine->mode = LP55XX_ENGINE_DISABLED;
+   }
+
+   mutex_unlock(>lock);
+
+   return len;
+}
+store_mode(1)
+store_mode(2)
+store_mode(3)
+
+static ssize_t store_engine_load(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len, int nr)
+{
+   struct lp55xx_led *led = i2c_get_clientdata(to_i2c_client(dev));
+   struct lp55xx_chip *chip = led->chip;
+
+   mutex_lock(>lock);
+
+   chip->engine_idx = nr;
+   lp5521_load_engine(chip);
+
+   mutex_unlock(>lock);
+
+   return lp5521_update_program_memory(chip, buf, len);
+}
+store_load(1)
+store_load(2)
+store_load(3)
+
 static ssize_t lp5521_selftest(struct device *dev,
   struct device_attribute *attr,
   char *buf)
@@ -381,9 +465,21 @@ static ssize_t lp5521_selftest(struct device *dev,
 }
 
 /* device attributes */
-static DEVICE_ATTR(selftest, S_IRUGO, lp5521_selftest, NULL);
+static LP55XX_DEV_ATTR_RW(engine1_mode, show_engine1_mode, store_engine1_mode);
+static LP55XX_DEV_ATTR_RW(engine2_mode, show_engine2_mode, store_engine2_mode);
+static LP55XX_DEV_ATTR_RW(engine3_mode, 

[PATCH 01/10] leds: lp55xx: add common data structure for program

[Milo Kim]

LP55xx family devices have internal three program engines which are used for
loading LED patterns.
To maintain legacy device attributes, specific data structure is used, 'mode'
and 'led_mux'.
The mode is used for showing/storing current engine mode such like disabled,
load and run.
Then led_mux is used for showing/storing current output LED selection.
This is only for LP5523/55231.

Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp55xx-common.h |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/leds/leds-lp55xx-common.h 
b/drivers/leds/leds-lp55xx-common.h
index dbbf86d..04c1d4f 100644
--- a/drivers/leds/leds-lp55xx-common.h
+++ b/drivers/leds/leds-lp55xx-common.h
@@ -20,6 +20,13 @@ enum lp55xx_engine_index {
LP55XX_ENGINE_1,
LP55XX_ENGINE_2,
LP55XX_ENGINE_3,
+   LP55XX_ENGINE_MAX = LP55XX_ENGINE_3,
+};
+
+enum lp55xx_engine_mode {
+   LP55XX_ENGINE_DISABLED,
+   LP55XX_ENGINE_LOAD,
+   LP55XX_ENGINE_RUN,
 };
 
 struct lp55xx_led;
@@ -72,6 +79,16 @@ struct lp55xx_device_config {
 };
 
 /*
+ * struct lp55xx_engine
+ * @mode   : Engine mode
+ * @led_mux: Mux bits for LED selection. Only used in LP5523
+ */
+struct lp55xx_engine {
+   enum lp55xx_engine_mode mode;
+   u16 led_mux;
+};
+
+/*
  * struct lp55xx_chip
  * @cl : I2C communication for access registers
  * @pdata  : Platform specific data
@@ -79,6 +96,7 @@ struct lp55xx_device_config {
  * @num_leds   : Number of registered LEDs
  * @cfg: Device specific configuration data
  * @engine_idx : Selected engine number
+ * @engines: Engine structure for the device attribute R/W interface
  * @fw : Firmware data for running a LED pattern
  */
 struct lp55xx_chip {
@@ -89,6 +107,7 @@ struct lp55xx_chip {
int num_leds;
struct lp55xx_device_config *cfg;
enum lp55xx_engine_index engine_idx;
+   struct lp55xx_engine engines[LP55XX_ENGINE_MAX];
const struct firmware *fw;
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/10] leds: lp5523: make separate API for loading engine

[Milo Kim]

lp5523_load_engine()
  It is called whenever the operation mode is changed to 'load'.
  It is used for simple operation mode change.
  It will be used when engine mode and LED selection is updated in later patch.

lp5523_load_engine_and_select_page()
  Change the operation mode to 'load' and select program page number.
  This is used for programming a LED pattern at a time.
  So load_engine() is replaced with new API, load_engine_and_select_page()
  in lp5523_firmware_loaded().

Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp5523.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 72c10e2..b509480 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -152,15 +152,21 @@ static void lp5523_load_engine(struct lp55xx_chip *chip)
[LP55XX_ENGINE_3] = LP5523_LOAD_ENG3,
};
 
+   lp55xx_update_bits(chip, LP5523_REG_OP_MODE, mask[idx], val[idx]);
+
+   lp5523_wait_opmode_done();
+}
+
+static void lp5523_load_engine_and_select_page(struct lp55xx_chip *chip)
+{
+   enum lp55xx_engine_index idx = chip->engine_idx;
u8 page_sel[] = {
[LP55XX_ENGINE_1] = LP5523_PAGE_ENG1,
[LP55XX_ENGINE_2] = LP5523_PAGE_ENG2,
[LP55XX_ENGINE_3] = LP5523_PAGE_ENG3,
};
 
-   lp55xx_update_bits(chip, LP5523_REG_OP_MODE, mask[idx], val[idx]);
-
-   lp5523_wait_opmode_done();
+   lp5523_load_engine(chip);
 
lp55xx_write(chip, LP5523_REG_PROG_PAGE_SEL, page_sel[idx]);
 }
@@ -290,7 +296,7 @@ static void lp5523_firmware_loaded(struct lp55xx_chip *chip)
 *  2) write firmware data into program memory
 */
 
-   lp5523_load_engine(chip);
+   lp5523_load_engine_and_select_page(chip);
lp5523_update_program_memory(chip, fw->data, fw->size);
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/10] leds: lp5521: remove unnecessary writing commands

[Milo Kim]

This patch reduces the number of programming commands.

(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32

Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.

Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp5521.c |   14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index c00f922..0518835 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -220,17 +220,11 @@ static int lp5521_update_program_memory(struct 
lp55xx_chip *chip,
};
unsigned cmd;
char c[3];
-   int program_size;
int nrchars;
-   int offset = 0;
int ret;
-   int i;
-
-   /* clear program memory before updating */
-   for (i = 0; i < LP5521_PROGRAM_LENGTH; i++)
-   lp55xx_write(chip, addr[idx] + i, 0);
+   int offset = 0;
+   int i = 0;
 
-   i = 0;
while ((offset < size - 1) && (i < LP5521_PROGRAM_LENGTH)) {
/* separate sscanfs because length is working only for %s */
ret = sscanf(data + offset, "%2s%n ", c, );
@@ -250,11 +244,9 @@ static int lp5521_update_program_memory(struct lp55xx_chip 
*chip,
if (i % 2)
goto err;
 
-   program_size = i;
-
mutex_lock(>lock);
 
-   for (i = 0; i < program_size; i++) {
+   for (i = 0; i < LP5521_PROGRAM_LENGTH; i++) {
ret = lp55xx_write(chip, addr[idx] + i, pattern[i]);
if (ret) {
mutex_unlock(>lock);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/10] leds: lp5523: restore legacy device attributes

[Milo Kim]

git commit db6eaf8388a413a5ee1b4547ce78506b9c6456b0
(leds-lp5523: use generic firmware interface) causes an application conflict.
This interface should be maintained for compatibility.

Restored device attributes are 'engineN_mode', 'engineN_load' and
'engineN_leds'. (N = 1, 2 or 3)
A 'selftest' attribute macro is replaced with LP55xx common macro.
Those are accessed when a LED pattern is run by an application.

Use a mutex in lp5523_update_program_memory()
: This function is called when an user-application writes a 'engineN_load' file
or pattern data is loaded from generic firmware interface.
So, writing program memory should be protected.
If an error occurs on accessing this area, just it returns as -EINVAL quickly.
This error code is exact same as old driver function, lp5523_do_store_load()
because it should be kept for an user-application compatibility.
Even the driver is changed, we can use the application without re-compiling
sources.

Reported-by: Pali Rohár 
Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp5523.c |  227 +++-
 1 file changed, 223 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 29c8b19..9b8be6f6 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -74,6 +74,9 @@
 #define LP5523_PAGE_ENG1   0
 #define LP5523_PAGE_ENG2   1
 #define LP5523_PAGE_ENG3   2
+#define LP5523_PAGE_MUX1   3
+#define LP5523_PAGE_MUX2   4
+#define LP5523_PAGE_MUX3   5
 
 /* Program Memory Operations */
 #define LP5523_MODE_ENG1_M 0x30/* Operation Mode Register */
@@ -98,6 +101,8 @@
 #define LP5523_RUN_ENG20x08
 #define LP5523_RUN_ENG30x02
 
+#define LED_ACTIVE(mux, led)   (!!(mux & (0x0001 << led)))
+
 enum lp5523_chip_id {
LP5523,
LP55231,
@@ -338,10 +343,20 @@ static int lp5523_update_program_memory(struct 
lp55xx_chip *chip,
goto err;
 
update_size = i;
-   for (i = 0; i < update_size; i++)
-   lp55xx_write(chip, LP5523_REG_PROG_MEM + i, pattern[i]);
 
-   return 0;
+   mutex_lock(>lock);
+
+   for (i = 0; i < update_size; i++) {
+   ret = lp55xx_write(chip, LP5523_REG_PROG_MEM + i, pattern[i]);
+   if (ret) {
+   mutex_unlock(>lock);
+   return -EINVAL;
+   }
+   }
+
+   mutex_unlock(>lock);
+
+   return size;
 
 err:
dev_err(>cl->dev, "wrong pattern format\n");
@@ -368,6 +383,192 @@ static void lp5523_firmware_loaded(struct lp55xx_chip 
*chip)
lp5523_update_program_memory(chip, fw->data, fw->size);
 }
 
+static ssize_t show_engine_mode(struct device *dev,
+   struct device_attribute *attr,
+   char *buf, int nr)
+{
+   struct lp55xx_led *led = i2c_get_clientdata(to_i2c_client(dev));
+   struct lp55xx_chip *chip = led->chip;
+   enum lp55xx_engine_mode mode = chip->engines[nr - 1].mode;
+
+   switch (mode) {
+   case LP55XX_ENGINE_RUN:
+   return sprintf(buf, "run\n");
+   case LP55XX_ENGINE_LOAD:
+   return sprintf(buf, "load\n");
+   case LP55XX_ENGINE_DISABLED:
+   default:
+   return sprintf(buf, "disabled\n");
+   }
+}
+show_mode(1)
+show_mode(2)
+show_mode(3)
+
+static ssize_t store_engine_mode(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len, int nr)
+{
+   struct lp55xx_led *led = i2c_get_clientdata(to_i2c_client(dev));
+   struct lp55xx_chip *chip = led->chip;
+   struct lp55xx_engine *engine = >engines[nr - 1];
+
+   mutex_lock(>lock);
+
+   chip->engine_idx = nr;
+
+   if (!strncmp(buf, "run", 3)) {
+   lp5523_run_engine(chip, true);
+   engine->mode = LP55XX_ENGINE_RUN;
+   } else if (!strncmp(buf, "load", 4)) {
+   lp5523_stop_engine(chip);
+   lp5523_load_engine(chip);
+   engine->mode = LP55XX_ENGINE_LOAD;
+   } else if (!strncmp(buf, "disabled", 8)) {
+   lp5523_stop_engine(chip);
+   engine->mode = LP55XX_ENGINE_DISABLED;
+   }
+
+   mutex_unlock(>lock);
+
+   return len;
+}
+store_mode(1)
+store_mode(2)
+store_mode(3)
+
+static int lp5523_mux_parse(const char *buf, u16 *mux, size_t len)
+{
+   u16 tmp_mux = 0;
+   int i;
+
+   len = min_t(int, len, LP5523_MAX_LEDS);
+
+   for (i = 0; i < len; i++) {
+   switch (buf[i]) {
+   case '1':
+   tmp_mux |= (1 << i);
+   break;
+   case '0':
+   break;
+   case '\n':
+   i = len;
+   break;
+   

[PATCH 08/10] leds: lp5523: remove unnecessary writing commands

[Milo Kim]

This patch reduces the number of programming commands.

(Count of sending commands)
Old code: 32 + program size (32 counts for clearing program memory)
New code: 32

Pattern buffer is initialized to 0 in this function.
Just update new program data and remaining buffers are filled with 0.
So it's needless to clear whole area.

Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp5523.c |   14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 9b8be6f6..fe3bcbb 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -312,17 +312,11 @@ static int lp5523_update_program_memory(struct 
lp55xx_chip *chip,
u8 pattern[LP5523_PROGRAM_LENGTH] = {0};
unsigned cmd;
char c[3];
-   int update_size;
int nrchars;
-   int offset = 0;
int ret;
-   int i;
-
-   /* clear program memory before updating */
-   for (i = 0; i < LP5523_PROGRAM_LENGTH; i++)
-   lp55xx_write(chip, LP5523_REG_PROG_MEM + i, 0);
+   int offset = 0;
+   int i = 0;
 
-   i = 0;
while ((offset < size - 1) && (i < LP5523_PROGRAM_LENGTH)) {
/* separate sscanfs because length is working only for %s */
ret = sscanf(data + offset, "%2s%n ", c, );
@@ -342,11 +336,9 @@ static int lp5523_update_program_memory(struct lp55xx_chip 
*chip,
if (i % 2)
goto err;
 
-   update_size = i;
-
mutex_lock(>lock);
 
-   for (i = 0; i < update_size; i++) {
+   for (i = 0; i < LP5523_PROGRAM_LENGTH; i++) {
ret = lp55xx_write(chip, LP5523_REG_PROG_MEM + i, pattern[i]);
if (ret) {
mutex_unlock(>lock);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/10] leds: lp5523: LED MUX configuration on initializing

[Milo Kim]

LED MUX start and stop address should be updated in the program memory
on LP5523 initialization.
LED pattern doesn't work without additional MUX address configuration.
This handling is done by new function, lp5523_init_program_engine().
Eventually, it's called during device initialization, lp5523_post_init_device().

This is a conflict after git commit 632418bf65503405df3f9a6a1616f5a95f91db85
(leds-lp5523: clean up lp5523_configure()).
So it should be fixed.

Cc: Pali Rohár 
Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp5523.c |   70 +++-
 1 file changed, 69 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index b509480..29c8b19 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -49,6 +49,9 @@
 #define LP5523_REG_RESET   0x3D
 #define LP5523_REG_LED_TEST_CTRL   0x41
 #define LP5523_REG_LED_TEST_ADC0x42
+#define LP5523_REG_CH1_PROG_START  0x4C
+#define LP5523_REG_CH2_PROG_START  0x4D
+#define LP5523_REG_CH3_PROG_START  0x4E
 #define LP5523_REG_PROG_PAGE_SEL   0x4F
 #define LP5523_REG_PROG_MEM0x50
 
@@ -65,6 +68,7 @@
 #define LP5523_RESET   0xFF
 #define LP5523_ADC_SHORTCIRC_LIM   80
 #define LP5523_EXT_CLK_USED0x08
+#define LP5523_ENG_STATUS_MASK 0x07
 
 /* Memory Page Selection */
 #define LP5523_PAGE_ENG1   0
@@ -99,6 +103,8 @@ enum lp5523_chip_id {
LP55231,
 };
 
+static int lp5523_init_program_engine(struct lp55xx_chip *chip);
+
 static inline void lp5523_wait_opmode_done(void)
 {
usleep_range(1000, 2000);
@@ -134,7 +140,11 @@ static int lp5523_post_init_device(struct lp55xx_chip 
*chip)
if (ret)
return ret;
 
-   return lp55xx_write(chip, LP5523_REG_ENABLE_LEDS_LSB, 0xff);
+   ret = lp55xx_write(chip, LP5523_REG_ENABLE_LEDS_LSB, 0xff);
+   if (ret)
+   return ret;
+
+   return lp5523_init_program_engine(chip);
 }
 
 static void lp5523_load_engine(struct lp55xx_chip *chip)
@@ -233,6 +243,64 @@ static void lp5523_run_engine(struct lp55xx_chip *chip, 
bool start)
lp55xx_update_bits(chip, LP5523_REG_ENABLE, LP5523_EXEC_M, exec);
 }
 
+static int lp5523_init_program_engine(struct lp55xx_chip *chip)
+{
+   int i;
+   int j;
+   int ret;
+   u8 status;
+   /* one pattern per engine setting LED MUX start and stop addresses */
+   static const u8 pattern[][LP5523_PROGRAM_LENGTH] =  {
+   { 0x9c, 0x30, 0x9c, 0xb0, 0x9d, 0x80, 0xd8, 0x00, 0},
+   { 0x9c, 0x40, 0x9c, 0xc0, 0x9d, 0x80, 0xd8, 0x00, 0},
+   { 0x9c, 0x50, 0x9c, 0xd0, 0x9d, 0x80, 0xd8, 0x00, 0},
+   };
+
+   /* hardcode 32 bytes of memory for each engine from program memory */
+   ret = lp55xx_write(chip, LP5523_REG_CH1_PROG_START, 0x00);
+   if (ret)
+   return ret;
+
+   ret = lp55xx_write(chip, LP5523_REG_CH2_PROG_START, 0x10);
+   if (ret)
+   return ret;
+
+   ret = lp55xx_write(chip, LP5523_REG_CH3_PROG_START, 0x20);
+   if (ret)
+   return ret;
+
+   /* write LED MUX address space for each engine */
+   for (i = LP55XX_ENGINE_1; i <= LP55XX_ENGINE_3; i++) {
+   chip->engine_idx = i;
+   lp5523_load_engine_and_select_page(chip);
+
+   for (j = 0; j < LP5523_PROGRAM_LENGTH; j++) {
+   ret = lp55xx_write(chip, LP5523_REG_PROG_MEM + j,
+   pattern[i - 1][j]);
+   if (ret)
+   goto out;
+   }
+   }
+
+   lp5523_run_engine(chip, true);
+
+   /* Let the programs run for couple of ms and check the engine status */
+   usleep_range(3000, 6000);
+   lp55xx_read(chip, LP5523_REG_STATUS, );
+   status &= LP5523_ENG_STATUS_MASK;
+
+   if (status != LP5523_ENG_STATUS_MASK) {
+   dev_err(>cl->dev,
+   "cound not configure LED engine, status = 0x%.2x\n",
+   status);
+   ret = -1;
+   }
+
+out:
+   lp5523_stop_engine(chip);
+   return ret;
+}
+
 static int lp5523_update_program_memory(struct lp55xx_chip *chip,
const u8 *data, size_t size)
 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/10] Documentation: leds-lp5521,lp5523: update device attribute information

[Milo Kim]

Now, all legacy application interfaces are restored.
Each driver documentation is updated.

Cc: Pali Rohár 
Signed-off-by: Milo Kim 
---
 Documentation/leds/leds-lp5521.txt |   20 +++-
 Documentation/leds/leds-lp5523.txt |   21 -
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/Documentation/leds/leds-lp5521.txt 
b/Documentation/leds/leds-lp5521.txt
index 79e4c2e..d08d8c1 100644
--- a/Documentation/leds/leds-lp5521.txt
+++ b/Documentation/leds/leds-lp5521.txt
@@ -18,7 +18,25 @@ All three channels can be also controlled using the engine 
micro programs.
 More details of the instructions can be found from the public data sheet.
 
 LP5521 has the internal program memory for running various LED patterns.
-For the details, please refer to 'firmware' section in leds-lp55xx.txt
+There are two ways to run LED patterns.
+
+1) Legacy interface - enginex_mode and enginex_load
+  Control interface for the engines:
+  x is 1 .. 3
+  enginex_mode : disabled, load, run
+  enginex_load : store program (visible only in engine load mode)
+
+  Example (start to blink the channel 2 led):
+  cd   /sys/class/leds/lp5521:channel2/device
+  echo "load" > engine3_mode
+  echo "037f4d0003ff6000" > engine3_load
+  echo "run" > engine3_mode
+
+  To stop the engine:
+  echo "disabled" > engine3_mode
+
+2) Firmware interface - LP55xx common interface
+  For the details, please refer to 'firmware' section in leds-lp55xx.txt
 
 sysfs contains a selftest entry.
 The test communicates with the chip and checks that
diff --git a/Documentation/leds/leds-lp5523.txt 
b/Documentation/leds/leds-lp5523.txt
index 899fdad..5b3e91d 100644
--- a/Documentation/leds/leds-lp5523.txt
+++ b/Documentation/leds/leds-lp5523.txt
@@ -28,7 +28,26 @@ If both fields are NULL, 'lp5523' is used by default.
 /sys/class/leds/lp5523:channelN  (N: 0 ~ 8)
 
 LP5523 has the internal program memory for running various LED patterns.
-For the details, please refer to 'firmware' section in leds-lp55xx.txt
+There are two ways to run LED patterns.
+
+1) Legacy interface - enginex_mode, enginex_load and enginex_leds
+  Control interface for the engines:
+  x is 1 .. 3
+  enginex_mode : disabled, load, run
+  enginex_load : microcode load (visible only in load mode)
+  enginex_leds : led mux control (visible only in load mode)
+
+  cd /sys/class/leds/lp5523:channel2/device
+  echo "load" > engine3_mode
+  echo "9d8044ff05ff437f" > engine3_load
+  echo "1" > engine3_leds
+  echo "run" > engine3_mode
+
+  To stop the engine:
+  echo "disabled" > engine3_mode
+
+2) Firmware interface - LP55xx common interface
+  For the details, please refer to 'firmware' section in leds-lp55xx.txt
 
 Selftest uses always the current from the platform data.
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/10] leds: lp5562: use LP55xx common macros for device attributes

[Milo Kim]

Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp5562.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/leds-lp5562.c b/drivers/leds/leds-lp5562.c
index a2c7398..2585cfd 100644
--- a/drivers/leds/leds-lp5562.c
+++ b/drivers/leds/leds-lp5562.c
@@ -477,8 +477,8 @@ static ssize_t lp5562_store_engine_mux(struct device *dev,
return len;
 }
 
-static DEVICE_ATTR(led_pattern, S_IWUSR, NULL, lp5562_store_pattern);
-static DEVICE_ATTR(engine_mux, S_IWUSR, NULL, lp5562_store_engine_mux);
+static LP55XX_DEV_ATTR_WO(led_pattern, lp5562_store_pattern);
+static LP55XX_DEV_ATTR_WO(engine_mux, lp5562_store_engine_mux);
 
 static struct attribute *lp5562_attributes[] = {
_attr_led_pattern.attr,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/10] leds: lp55xx: add common macros for device attributes

[Milo Kim]

This patch provides common macros for LP5521 and LP5523 device attributes and
functions.

(Device attributes)
LP5521: 'mode', 'load' and 'selftest'
LP5523: 'mode', 'load', 'leds' and 'selftest'

(Permissions)
mode: R/W
load: Write-only
leds: R/W
selftest: Read-only

Couple of lines are duplicate, so use these macros for adding device attributes
in LP5521 and LP5523 drivers.

Signed-off-by: Milo Kim 
---
 drivers/leds/leds-lp55xx-common.h |   47 +
 1 file changed, 47 insertions(+)

diff --git a/drivers/leds/leds-lp55xx-common.h 
b/drivers/leds/leds-lp55xx-common.h
index 04c1d4f..cceab48 100644
--- a/drivers/leds/leds-lp55xx-common.h
+++ b/drivers/leds/leds-lp55xx-common.h
@@ -29,6 +29,53 @@ enum lp55xx_engine_mode {
LP55XX_ENGINE_RUN,
 };
 
+#define LP55XX_DEV_ATTR_RW(name, show, store)  \
+   DEVICE_ATTR(name, S_IRUGO | S_IWUSR, show, store)
+#define LP55XX_DEV_ATTR_RO(name, show) \
+   DEVICE_ATTR(name, S_IRUGO, show, NULL)
+#define LP55XX_DEV_ATTR_WO(name, store)\
+   DEVICE_ATTR(name, S_IWUSR, NULL, store)
+
+#define show_mode(nr)  \
+static ssize_t show_engine##nr##_mode(struct device *dev,  \
+   struct device_attribute *attr,  \
+   char *buf)  \
+{  \
+   return show_engine_mode(dev, attr, buf, nr);\
+}
+
+#define store_mode(nr) \
+static ssize_t store_engine##nr##_mode(struct device *dev, \
+struct device_attribute *attr, \
+const char *buf, size_t len)   \
+{  \
+   return store_engine_mode(dev, attr, buf, len, nr);  \
+}
+
+#define show_leds(nr)  \
+static ssize_t show_engine##nr##_leds(struct device *dev,  \
+   struct device_attribute *attr,  \
+   char *buf)  \
+{  \
+   return show_engine_leds(dev, attr, buf, nr);\
+}
+
+#define store_leds(nr) \
+static ssize_t store_engine##nr##_leds(struct device *dev, \
+struct device_attribute *attr, \
+const char *buf, size_t len)   \
+{  \
+   return store_engine_leds(dev, attr, buf, len, nr);  \
+}
+
+#define store_load(nr) \
+static ssize_t store_engine##nr##_load(struct device *dev, \
+struct device_attribute *attr, \
+const char *buf, size_t len)   \
+{  \
+   return store_engine_load(dev, attr, buf, len, nr);  \
+}
+
 struct lp55xx_led;
 struct lp55xx_chip;
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/10] leds: lp5521,5523: restore device attributes for running LED patterns

[Milo Kim]

This patch-set resolves the application conflict by restoring sysfs files.

For LP5521
  engine1/2/3_mode
  engine1/2/3_load

For LP5523
  engine1/2/3_mode
  engine1/2/3_load
  engine1/2/3_leds

Those attributes are accessed when LED pattern is run by custom application.
Those were removed when LED pattern interface was changed to generic firmware
interface. Please refer to commits below.

  git commit 9ce7cb170f97f83a78dc948bf7d25690f15e1328
  (leds-lp5521: use generic firmware interface)

  git commit db6eaf8388a413a5ee1b4547ce78506b9c6456b0
  (leds-lp5523: use generic firmware interface)

Necessary attributes are restored in this patch-set.

(Other changes)
New data structure is added for handling values from/to an application.
Few code fixes for reducing writing I2C commands.
Add LP55xx common macros for code refactoring.
Documentation updates.

You can also pull from the location below
This branch is based on 'for-next' of linux-leds.

  https://github.com/milokim/lp55xx.git resolve-missing-sysfs

Milo Kim (10):
  leds: lp55xx: add common data structure for program
  leds: lp55xx: add common macros for device attributes
  leds: lp5521: restore legacy device attributes
  leds: lp5521: remove unnecessary writing commands
  leds: lp5523: make separate API for loading engine
  leds: lp5523: LED MUX configuration on initializing
  leds: lp5523: restore legacy device attributes
  leds: lp5523: remove unnecessary writing commands
  Documentation: leds-lp5521,lp5523: update device attribute
information
  leds: lp5562: use LP55xx common macros for device attributes

 Documentation/leds/leds-lp5521.txt |   20 ++-
 Documentation/leds/leds-lp5523.txt |   21 ++-
 drivers/leds/leds-lp5521.c |  114 +++--
 drivers/leds/leds-lp5523.c |  321 ++--
 drivers/leds/leds-lp5562.c |4 +-
 drivers/leds/leds-lp55xx-common.h  |   66 
 6 files changed, 511 insertions(+), 35 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] drivers/crypto/nx: saves chaining value from co-processor

[Michael Ellerman]

Hi Fin,

I don't know anything about crypto so I can only critique you on your
patch submission technique :)  ...

On Wed, Aug 07, 2013 at 06:15:50PM -0500, Fionnuala Gunter wrote:
> This patch fixes a bug that is triggered when cts(cbc(aes)) is used with
> nx-crypto driver on input larger than 32 bytes.
> 
> The chaining value from co-processor was not being saved. This value is
> needed because it is used as the IV by cts(cbc(aes)).
> 
> Signed-off-by: Fionnuala Gunter 
> Reviewed-by: Marcelo Cerri 
> ---
> v2. changed signed-off-by to reviewed-by and added more details to
> description
> 
> This bug appeared in the original submission (v3.5)

Ideally this should identify the commit, so:

  This bug was introduced in the original submission (v3.5), commit
  856d673 "powerpc/crypto: AES-CBC mode routines for nx encryption".

Including the subject of the commit is handy in case the patch has been
backported somewhere, in which case the commit sha will be different.

It should definitely be part of the commit message, not below the "---".

And Ben might disagree but I think with a clear cut bug fix like this it
should include the CC to stable, so:

Cc: sta...@vger.kernel.org # 3.5+

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PREEMPT_RT vs bcache

[Kent Overstreet]

On Thu, Aug 08, 2013 at 12:26:23AM -0700, Christoph Hellwig wrote:
> On Wed, Aug 07, 2013 at 10:28:18PM +0200, Ben Hutchings wrote:
> > As Kent said back in 2011 (commit 84759c6d18c5), bcache needs
> > {down,up}_read_non_owner().  But these are not implemented by the -rt
> > patchset when PREEMPT_RT_FULL is enabled.  Can they be added, or is
> > there a fundamental conflict here?
> 
> How did they get back in at all?  I'm pretty sure I removed them for
> good reason.

I seem to recall from looking at the logs that you just removed them
because all the old users could be and were converted to something
saner, for what they were doing (using them as completions, I want to
say?)

Bcache isn't using the rw sem as a completion though, it really is a
read/write lock that protects a specific data structure, and  where
we're taking a read lock for the duration of write IOs - and since bios
are asynchronous, that's why we need the non_owner() bit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] btrfs: cleanup: removed unused 'btrfs_reada_detach'

[Arne Jansen]

On 07.08.2013 23:43, Sergei Trofimovich wrote:
> From: Sergei Trofimovich 
> 
> Found by uselex.rb:
>> btrfs_reada_detach: [R]: exported from: fs/btrfs/btrfs.o fs/btrfs/built-in.o 
>> fs/btrfs/reada.o

even though the function is currently unused, I'm hesitating to remove it
as it's part of the reada-API and might be handy for anyone going to use
the API in the future.

-Arne

> 
> Signed-off-by: Sergei Trofimovich 
> ---
>  fs/btrfs/ctree.h | 1 -
>  fs/btrfs/reada.c | 9 +
>  2 files changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index e91ab9e..f35e086 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -3861,7 +3861,6 @@ struct reada_control {
>  struct reada_control *btrfs_reada_add(struct btrfs_root *root,
> struct btrfs_key *start, struct btrfs_key *end);
>  int btrfs_reada_wait(void *handle);
> -void btrfs_reada_detach(void *handle);
>  int btree_readahead_hook(struct btrfs_root *root, struct extent_buffer *eb,
>u64 start, int err);
>  
> diff --git a/fs/btrfs/reada.c b/fs/btrfs/reada.c
> index 1031b69..c41d470 100644
> --- a/fs/btrfs/reada.c
> +++ b/fs/btrfs/reada.c
> @@ -37,7 +37,7 @@
>   * To trigger a readahead, btrfs_reada_add must be called. It will start
>   * a read ahead for the given range [start, end) on tree root. The returned
>   * handle can either be used to wait on the readahead to finish
> - * (btrfs_reada_wait), or to send it to the background (btrfs_reada_detach).
> + * (btrfs_reada_wait).
>   *
>   * The read ahead works as follows:
>   * On btrfs_reada_add, the root of the tree is inserted into a radix_tree.
> @@ -979,10 +979,3 @@ int btrfs_reada_wait(void *handle)
>   return 0;
>  }
>  #endif
> -
> -void btrfs_reada_detach(void *handle)
> -{
> - struct reada_control *rc = handle;
> -
> - kref_put(>refcnt, reada_control_release);
> -}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 15/19] clk: at91: add PMC usb clock

[Boris BREZILLON]

This patch adds new at91 usb clock implementation using common clk framework.
This clock is used to clock usb ports (ohci, ehci and udc).

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/Kconfig |   11 ++
 drivers/clk/at91/Makefile  |1 +
 drivers/clk/at91/clk-usb.c |  323 
 drivers/clk/at91/pmc.c |   11 ++
 drivers/clk/at91/pmc.h |7 +
 5 files changed, 353 insertions(+)
 create mode 100644 drivers/clk/at91/clk-usb.c

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 6ad37da..b76dc4c 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -3,6 +3,9 @@ if ARCH_AT91
 config HAVE_AT91_UTMI
bool
 
+config HAVE_AT91_USB_CLK
+   bool
+
 config HAVE_AT91_DBGU0
bool
 
@@ -82,6 +85,7 @@ config SOC_SAMA5D3
select HAVE_AT91_DBGU1
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+   select HAVE_AT91_USB_CLK
help
  Select this if you are using one of Atmel's SAMA5D3 family SoC.
  This support covers SAMA5D31, SAMA5D33, SAMA5D34, SAMA5D35.
@@ -96,12 +100,14 @@ config SOC_AT91RM9200
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
select AT91_USE_OLD_CLK
+   select HAVE_AT91_USB_CLK
 
 config SOC_AT91SAM9260
bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
select HAVE_AT91_DBGU0
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+   select HAVE_AT91_USB_CLK
help
  Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
  or AT91SAM9G20 SoC.
@@ -112,6 +118,7 @@ config SOC_AT91SAM9261
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+   select HAVE_AT91_USB_CLK
help
  Select this if you are using one of Atmel's AT91SAM9261 or 
AT91SAM9G10 SoC.
 
@@ -121,6 +128,7 @@ config SOC_AT91SAM9263
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+   select HAVE_AT91_USB_CLK
 
 config SOC_AT91SAM9RL
bool "AT91SAM9RL"
@@ -137,6 +145,7 @@ config SOC_AT91SAM9G45
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+   select HAVE_AT91_USB_CLK
help
  Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
  This support covers AT91SAM9G45, AT91SAM9G46, AT91SAM9M10 and 
AT91SAM9M11.
@@ -148,6 +157,7 @@ config SOC_AT91SAM9X5
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+   select HAVE_AT91_USB_CLK
help
  Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
  This means that your SAM9 name finishes with a '5' (except if it is
@@ -161,6 +171,7 @@ config SOC_AT91SAM9N12
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+   select HAVE_AT91_USB_CLK
help
  Select this if you are using Atmel's AT91SAM9N12 SoC.
 
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index a824883..61db058 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -8,3 +8,4 @@ obj-y += clk-system.o clk-peripheral.o
 
 obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
 obj-$(CONFIG_HAVE_AT91_UTMI)   += clk-utmi.o
+obj-$(CONFIG_HAVE_AT91_USB_CLK)+= clk-usb.o
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
new file mode 100644
index 000..12c20a0
--- /dev/null
+++ b/drivers/clk/at91/clk-usb.c
@@ -0,0 +1,323 @@
+/*
+ * drivers/clk/at91/clk-usb.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON 
+ *
+ * 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
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pmc.h"
+
+#define USB_SOURCE_MAX 2
+
+#define to_at91sam9x5_clk_usb(hw) \
+   container_of(hw, struct at91sam9x5_clk_usb, hw)
+struct at91sam9x5_clk_usb {
+   struct clk_hw hw;
+   struct at91_pmc *pmc;
+   u8 usbs0_unused; /* sam9n12 uses usbs0 to disable usb clock */
+};
+
+#define to_at91rm9200_clk_usb(hw) \
+   container_of(hw, struct at91rm9200_clk_usb, hw)
+struct at91rm9200_clk_usb {
+   struct clk_hw hw;
+   struct at91_pmc *pmc;
+   u32 divisors[4];
+};
+
+static unsigned long at91sam9x5_clk_usb_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   u32 tmp;
+   u8 usbdiv;
+   struct at91sam9x5_clk_usb *usb = to_at91sam9x5_clk_usb(hw);
+   struct at91_pmc *pmc = usb->pmc;
+
+   tmp = pmc_read(pmc, AT91_PMC_USB);
+   usbdiv = (tmp & AT91_PMC_OHCIUSBDIV) >> 8;
+   return parent_rate / (usbdiv + 1);
+}
+
+static long 

Re: [PATCH V3]hrtimer: Fix a performance regression by disable reprogramming in remove_hrtimer

[ethan.zhao]

Kernel 3.11-rc3 With peter's patch and disable C-state in BIOS, got 1 second 
better performance !
[root@localhost ~]# time ./pip1m

real0m4.399s
user0m0.092s
sys 0m2.775s
[root@localhost ~]# time ./pip1m

real0m4.352s
user0m0.099s
sys 0m2.751s
[root@localhost ~]# time ./pip1m

real0m4.328s
user0m0.102s
sys 0m2.731s

Compared with default kernel 3.11-rc3 and disable C-states in BIOS, test case 4
4. Disable C1E C3 C6 C-states and SpeedStep in BIOS, default configuration of 
kernel 3.11-rc3.
[root@localhost ~]# time ./pip1m

real0m5.371s
user0m0.102s
sys 0m3.253s
[root@localhost ~]# time ./pip1m

real0m5.329s
user0m0.075s
sys 0m3.254s
 

That is great improvement, So it is worth to merge. 


Thanks
Ethan

 

在 2013-7-29，下午7:57，Peter Zijlstra  写道：
> 
> So aside from the complete mess posted; how about something like this?
> 
> *completely untested etc..*
> 
> ---
> include/linux/hrtimer.h |  5 +
> kernel/hrtimer.c| 60 +++--
> 2 files changed, 33 insertions(+), 32 deletions(-)
> 
> diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
> index d19a5c2..f2bcb9c 100644
> --- a/include/linux/hrtimer.h
> +++ b/include/linux/hrtimer.h
> @@ -185,6 +185,7 @@ struct hrtimer_cpu_base {
>   ktime_t expires_next;
>   int hres_active;
>   int hang_detected;
> + int timers_removed;
>   unsigned long   nr_events;
>   unsigned long   nr_retries;
>   unsigned long   nr_hangs;
> @@ -261,6 +262,8 @@ static inline ktime_t hrtimer_expires_remaining(const 
> struct hrtimer *timer)
> #ifdef CONFIG_HIGH_RES_TIMERS
> struct clock_event_device;
> 
> +extern void hrtimer_enter_idle(void);
> +
> extern void hrtimer_interrupt(struct clock_event_device *dev);
> 
> /*
> @@ -296,6 +299,8 @@ extern void clock_was_set_delayed(void);
> # define MONOTONIC_RES_NSEC   LOW_RES_NSEC
> # define KTIME_MONOTONIC_RES  KTIME_LOW_RES
> 
> +static inline void hrtimer_enter_idle(void) { }
> +
> static inline void hrtimer_peek_ahead_timers(void) { }
> 
> /*
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index f0f4fe2..ffb16d3 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -673,6 +673,27 @@ static inline ktime_t hrtimer_update_base(struct 
> hrtimer_cpu_base *base)
>   return ktime_get_update_offsets(offs_real, offs_boot, offs_tai);
> }
> 
> +static void __hrtimer_reprogram_all(struct hrtimer_cpu_base *base)
> +{
> + if (!hrtimer_hres_active())
> + return;
> +
> + raw_spin_lock(>lock);
> + hrtimer_update_base(base);
> + hrtimer_force_reprogram(base, 0);
> + raw_spin_unlock(>lock);
> +}
> +
> +void hrtimer_enter_idle(void)
> +{
> + struct hrtimer_cpu_base *base = &__get_cpu_var(hrtimer_bases);
> +
> + if (base->timers_removed) {
> + base->timers_removed = 0;
> + __hrtimer_reprogramm_all(base);
> + }
> +}
> +
> /*
>  * Retrigger next event is called after clock was set
>  *
> @@ -682,13 +703,7 @@ static void retrigger_next_event(void *arg)
> {
>   struct hrtimer_cpu_base *base = &__get_cpu_var(hrtimer_bases);
> 
> - if (!hrtimer_hres_active())
> - return;
> -
> - raw_spin_lock(>lock);
> - hrtimer_update_base(base);
> - hrtimer_force_reprogram(base, 0);
> - raw_spin_unlock(>lock);
> + __hrtimer_reprogram_all(base);
> }
> 
> /*
> @@ -907,7 +922,7 @@ static int enqueue_hrtimer(struct hrtimer *timer,
>  */
> static void __remove_hrtimer(struct hrtimer *timer,
>struct hrtimer_clock_base *base,
> -  unsigned long newstate, int reprogram)
> +  unsigned long newstate)
> {
>   struct timerqueue_node *next_timer;
>   if (!(timer->state & HRTIMER_STATE_ENQUEUED))
> @@ -915,19 +930,10 @@ static void __remove_hrtimer(struct hrtimer *timer,
> 
>   next_timer = timerqueue_getnext(>active);
>   timerqueue_del(>active, >node);
> - if (>node == next_timer) {
> #ifdef CONFIG_HIGH_RES_TIMERS
> - /* Reprogram the clock event device. if enabled */
> - if (reprogram && hrtimer_hres_active()) {
> - ktime_t expires;
> -
> - expires = ktime_sub(hrtimer_get_expires(timer),
> - base->offset);
> - if (base->cpu_base->expires_next.tv64 == expires.tv64)
> - hrtimer_force_reprogram(base->cpu_base, 1);
> - }
> + if (hrtimer_hres_active() && >node == next_timer)
> + base->cpu_base->timers_removed++;
> #endif
> - }
>   if (!timerqueue_getnext(>active))
>   base->cpu_base->active_bases &= ~(1 << base->index);
> out:
> @@ -942,26 +948,16 @@ remove_hrtimer(struct hrtimer 

[PATCH v3 16/19] clk: at91: add PMC smd clock

[Boris BREZILLON]

This patch adds at91 smd (Soft Modem) clock implementation using common clk
framework.

Not used by any driver right now.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/Kconfig |5 ++
 drivers/clk/at91/Makefile  |1 +
 drivers/clk/at91/clk-smd.c |  171 
 drivers/clk/at91/pmc.c |7 ++
 drivers/clk/at91/pmc.h |5 ++
 5 files changed, 189 insertions(+)
 create mode 100644 drivers/clk/at91/clk-smd.c

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index b76dc4c..97033f7 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -39,6 +39,9 @@ config AT91_SAM9G45_RESET
 config AT91_SAM9_TIME
bool
 
+config HAVE_AT91_SMD
+   bool
+
 config SOC_AT91SAM9
bool
select AT91_SAM9_TIME
@@ -85,6 +88,7 @@ config SOC_SAMA5D3
select HAVE_AT91_DBGU1
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+   select HAVE_AT91_SMD
select HAVE_AT91_USB_CLK
help
  Select this if you are using one of Atmel's SAMA5D3 family SoC.
@@ -157,6 +161,7 @@ config SOC_AT91SAM9X5
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
select HAVE_AT91_UTMI
+   select HAVE_AT91_SMD
select HAVE_AT91_USB_CLK
help
  Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 61db058..0e92b71 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -9,3 +9,4 @@ obj-y += clk-system.o clk-peripheral.o
 obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
 obj-$(CONFIG_HAVE_AT91_UTMI)   += clk-utmi.o
 obj-$(CONFIG_HAVE_AT91_USB_CLK)+= clk-usb.o
+obj-$(CONFIG_HAVE_AT91_SMD)+= clk-smd.o
diff --git a/drivers/clk/at91/clk-smd.c b/drivers/clk/at91/clk-smd.c
new file mode 100644
index 000..a7cf14a
--- /dev/null
+++ b/drivers/clk/at91/clk-smd.c
@@ -0,0 +1,171 @@
+/*
+ * drivers/clk/at91/clk-smd.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON 
+ *
+ * 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
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pmc.h"
+
+#define SMD_SOURCE_MAX 2
+
+#define to_at91sam9x5_clk_smd(hw) \
+   container_of(hw, struct at91sam9x5_clk_smd, hw)
+struct at91sam9x5_clk_smd {
+   struct clk_hw hw;
+   struct at91_pmc *pmc;
+};
+
+static unsigned long at91sam9x5_clk_smd_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   u32 tmp;
+   u8 smddiv;
+   struct at91sam9x5_clk_smd *smd = to_at91sam9x5_clk_smd(hw);
+   struct at91_pmc *pmc = smd->pmc;
+
+   tmp = pmc_read(pmc, AT91_PMC_SMD);
+   smddiv = (tmp & AT91_PMC_SMD_DIV) >> 8;
+   return parent_rate / (smddiv + 1);
+}
+
+static long at91sam9x5_clk_smd_round_rate(struct clk_hw *hw, unsigned long 
rate,
+ unsigned long *parent_rate)
+{
+   unsigned long div;
+   unsigned long bestrate;
+   unsigned long tmp;
+
+   if (rate >= *parent_rate)
+   return *parent_rate;
+
+   div = *parent_rate / rate;
+   if (div > 15)
+   return *parent_rate / 16;
+
+   bestrate = *parent_rate / div;
+   tmp = *parent_rate / (div + 1);
+   if (bestrate - rate > rate - tmp)
+   bestrate = tmp;
+
+   return bestrate;
+}
+
+static int at91sam9x5_clk_smd_set_parent(struct clk_hw *hw, u8 index)
+{
+   u32 tmp;
+   struct at91sam9x5_clk_smd *smd = to_at91sam9x5_clk_smd(hw);
+   struct at91_pmc *pmc = smd->pmc;
+
+   if (index > 1)
+   return -EINVAL;
+   tmp = pmc_read(pmc, AT91_PMC_SMD) & ~AT91_PMC_SMDS;
+   if (index)
+   tmp |= AT91_PMC_SMDS;
+   pmc_write(pmc, AT91_PMC_SMD, tmp);
+   return 0;
+}
+
+static u8 at91sam9x5_clk_smd_get_parent(struct clk_hw *hw)
+{
+   struct at91sam9x5_clk_smd *smd = to_at91sam9x5_clk_smd(hw);
+   struct at91_pmc *pmc = smd->pmc;
+
+   return pmc_read(pmc, AT91_PMC_SMD) & AT91_PMC_SMDS;
+}
+
+static int at91sam9x5_clk_smd_set_rate(struct clk_hw *hw, unsigned long rate,
+  unsigned long parent_rate)
+{
+   u32 tmp;
+   struct at91sam9x5_clk_smd *smd = to_at91sam9x5_clk_smd(hw);
+   struct at91_pmc *pmc = smd->pmc;
+   unsigned long div = parent_rate / rate;
+
+   if (parent_rate % rate || div < 1 || div > 16)
+   return -EINVAL;
+   tmp = pmc_read(pmc, AT91_PMC_SMD) & ~AT91_PMC_SMD_DIV;
+   tmp |= (div - 1) << 8;
+   pmc_write(pmc, AT91_PMC_SMD, tmp);
+
+   return 0;
+}
+
+static const struct clk_ops 

Re: [RFC PATCH 3/4] mm: add zbud flag to page flags

[Krzysztof Kozlowski]

Hi,

On wto, 2013-08-06 at 09:58 -0700, Dave Hansen wrote:
> On 08/05/2013 11:42 PM, Krzysztof Kozlowski wrote:
> > +#ifdef CONFIG_ZBUD
> > +   /* Allocated by zbud. Flag is necessary to find zbud pages to unuse
> > +* during migration/compaction.
> > +*/
> > +   PG_zbud,
> > +#endif
> 
> Do you _really_ need an absolutely new, unshared page flag?
> The zbud code doesn't really look like it uses any of the space in
> 'struct page'.
> 
> I think you could pretty easily alias PG_zbud=PG_slab, then use the
> page->{private,slab_cache} (or some other unused field) in 'struct page'
> to store a cookie to differentiate slab and zbud pages.

How about using page->_mapcount with negative value (-129)? Just like
PageBuddy()?


Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PREEMPT_RT vs bcache

[Christoph Hellwig]

On Wed, Aug 07, 2013 at 10:28:18PM +0200, Ben Hutchings wrote:
> As Kent said back in 2011 (commit 84759c6d18c5), bcache needs
> {down,up}_read_non_owner().  But these are not implemented by the -rt
> patchset when PREEMPT_RT_FULL is enabled.  Can they be added, or is
> there a fundamental conflict here?

How did they get back in at all?  I'm pretty sure I removed them for
good reason.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 17/19] clk: at91: add PMC clk device tree binding doc.

[Boris BREZILLON]

This patch adds new at91 clks dt bindings documentation.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/clock/at91-clock.txt   |  312 
 1 file changed, 312 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/at91-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt 
b/Documentation/devicetree/bindings/clock/at91-clock.txt
new file mode 100644
index 000..04739da
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -0,0 +1,312 @@
+Device Tree Clock bindings for arch-at91
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+   "atmel,at91rm9200-pmc" or
+   "atmel,at91sam9g45-pmc" or
+   "atmel,at91sam9n12-pmc" or
+   "atmel,at91sam9x5-pmc" or
+   "atmel,at91sam9g35-pmc" or
+   "atmel,sama5d3-pmc":
+   at91 PMC (Power Management Controller)
+   All at91 specific clocks (clocks defined below) must be child
+   node of the PMC node.
+
+   "atmel,at91rm9200-clk-main":
+   at91 main oscillator
+
+   "atmel,at91rm9200-clk-master" or
+   "atmel,at91sam9x5-clk-master":
+   at91 master clock
+
+   "atmel,at91sam9x5-clk-peripheral" or
+   "atmel,at91rm9200-clk-peripheral":
+   at91 peripheral clocks
+
+   "atmel,at91rm9200-clk-pll" or
+   "atmel,at91sam9g45-clk-pll" or
+   "atmel,at91sam9g20-clk-pllb" or
+   "atmel,sama5d3-clk-pll":
+   at91 pll clocks
+
+   "atmel,at91sam9x5-clk-plldiv":
+   at91 plla divisor
+
+   "atmel,at91rm9200-clk-programmable" or
+   "atmel,at91sam9g45-clk-programmable" or
+   "atmel,at91sam9x5-clk-programmable":
+   at91 programmable clocks
+
+   "atmel,at91sam9x5-clk-smd":
+   at91 SMD (Soft Modem) clock
+
+   "atmel,at91rm9200-clk-system":
+   at91 system clocks
+
+   "atmel,at91rm9200-clk-usb" or
+   "atmel,at91sam9x5-clk-usb":
+   at91 usb clock
+
+   "atmel,at91sam9x5-clk-utmi":
+   at91 utmi clock
+
+Required properties for PMC node:
+- reg : defines the IO memory reserved for the PMC.
+- interrupts : shall be set to PMC interrupt line.
+- interrupt-controller : tell that the PMC is an interrupt controller 
+- #interrupt-cells : must be set to 2. The first cell encodes the interrupt id
+the second cell encodes the interrupt type.
+For example:
+   pmc: pmc@fc00 {
+   compatible = "atmel,sama5d3-pmc";
+   interrupts = ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   /* put at91 clocks here */
+   };
+
+Required properties for main clock:
+- interrupt-parent : must reference the PMC node.
+- interrupts : shall be set to "".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks (optional if clock-frequency is provided) : shall be the slow clock
+   phandle. This clock is used to compute the main clock rate if
+   "clock-frequency" is not provided.
+- clock-frequency: the main oscillator frequency.Prefer the use of
+   "clock-frequency" over automatic clock rate computation.
+
+For example:
+   main: mainck {
+   compatible = "atmel,at91rm9200-clk-main";
+   interrupt-parent = <>;
+   interrupts = ;
+   #clock-cells = <0>;
+   clocks = <>;
+   clock-frequency = <18432000>;
+   };
+
+Required properties for master clock:
+- interrupt-parent : must reference the PMC node.
+- interrupts : shall be set to "".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the master clock sources (see atmel datasheet) phandles.
+   e.g. "<>, <>, <>, <>".
+- atmel,clk-output-range : minimum and maximum clock frequency (two u32
+  fields).
+  e.g. output = <0 13300>; <=> 0 to 133MHz.
+- atmel,clk-divisors : master clock divisors table (four u32 fields).
+   0 <=> reserved value.
+   e.g. divisors = <1 2 4 6>;
+- atmel,master-clk-have-div3-pres : some SoC use the reserved value 7 in the
+   PRES field as CLOCK_DIV3 (e.g sam9x5).
+
+For example:
+   mck: mck {
+   compatible = "atmel,at91rm9200-clk-master";
+   interrupt-parent = <>;
+   interrupts = ;
+   #clock-cells = <0>;
+   atmel,clk-output-range = <0 13300>;
+   atmel,clk-divisors = <1 2 4 0>;
+   };
+
+Required properties for peripheral clocks:
+- #clock-cells : from common clock binding; shall be set to 1. The second cell
+   is used to encode the peripheral id. Peripheral ids are defined in
+   atmel's SoC datasheets.
+- clocks 

Re: [PATCH 5/5] arm: omap: Proper cleanups for omap_device

[Tony Lindgren]

* Pantelis Antoniou  [130807 09:31]:
> Hi Tony,
> 
> On Aug 7, 2013, at 7:15 PM, Tony Lindgren wrote:
> 
> > * Pantelis Antoniou  [130806 02:44]:
> >> On Aug 6, 2013, at 12:33 PM, Greg Kroah-Hartman wrote:
> >>> On Tue, Aug 06, 2013 at 10:53:44AM +0300, Pantelis Antoniou wrote:
>  +
>  static int _omap_device_notifier_call(struct notifier_block *nb,
> unsigned long event, void *dev)
>  {
>  @@ -185,9 +211,13 @@ static int _omap_device_notifier_call(struct 
>  notifier_block *nb,
>   struct omap_device *od;
>  
>   switch (event) {
>  -case BUS_NOTIFY_DEL_DEVICE:
>  +case BUS_NOTIFY_UNBOUND_DRIVER:
>  +/* NOTIFY_DEL_DEVICE is not the right call...
>  + * we use a callback here, to make sure no-one is going 
>  to
>  + * try to use the omap_device data after they're deleted
>  + */
>   if (pdev->archdata.od)
>  -omap_device_delete(pdev->archdata.od);
>  +device_schedule_callback(dev, 
>  _omap_device_cleanup);
> >>> 
> >>> Really?  This is one sign that you are totally using the driver core
> >>> incorrectly.  You shouldn't have to rely on notifier callbacks to handle
> >>> device removals, your bus code should do that for you directly.
> >>> 
> >>> I don't like this at all, sorry.
> >>> 
> >> 
> >> Don't shoot the messenger please...
> > 
> > As you're inititalizing capebus with DT, let's figure out what if
> > anything you actually need from omap_device. I'd much rather remove
> > dependencies than add more.
> > 
> 
> There is no such thing as capebus anymore. This is just the path of
> removing a platform device, which happens to also be an omap_device.

OK, so let's figure out the minimal fixes needed.
 
> >> This is all about fixing a crash without messing too many things.
> > 
> > It seems this fix is only needed for supporting out-of-tree code?
> > These features with omap_device we may not even want to support in
> > the mainline tree as is being discussed..
> > 
> 
> What out of tree code? The only thing this patch does is make sure we
> don't crash when a perfectly valid call to platform_device_unregister() 
> happens.
> 
> Drivers that don't use omap_device work just fine.

So what's the minimal set of fixes then?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] hwmon: (lm90) Add power control

[Alexander Shiyan]

> The device lm90 can be controlled by the vdd rail.
> Adding the power control support to power on/off the vdd rail.
> And make sure that power is enabled before accessing the device.
> 
> Signed-off-by: Wei Ni 
> ---
>  drivers/hwmon/lm90.c |   49 +
>  1 file changed, 49 insertions(+)
> 
> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
[...]
> +static void lm90_power_control(struct i2c_client *client, bool is_enable)
> +{
> + struct lm90_data *data = i2c_get_clientdata(client);
> + int ret;
> +
> + if (!data->lm90_reg)
> + return;
> +
> + mutex_lock(>update_lock);
> +
> + if (is_enable)
> + ret = regulator_enable(data->lm90_reg);
> + else
> + ret = regulator_disable(data->lm90_reg);
> +
> + if (ret < 0)
> + dev_err(>dev,
> + "Error in %s rail vdd, error %d\n",
> + (is_enable) ? "enabling" : "disabling", ret);
> + else
> + dev_info(>dev, "success in %s rail vdd\n",
> +  (is_enable) ? "enabling" : "disabling");

dev_dbg() ?

> +
> + mutex_unlock(>update_lock);
> +}
> +
>  static int lm90_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
>  {
> @@ -1406,6 +1434,20 @@ static int lm90_probe(struct i2c_client *client,
>   i2c_set_clientdata(client, data);
>   mutex_init(>update_lock);
>  
> + data->lm90_reg = regulator_get(>dev, "vdd");
> + if (IS_ERR_OR_NULL(data->lm90_reg)) {

What about deferred probe?
if (PTR_ERR(data->lm90_reg) == -EPROBE_DEFER)
return -EPROBE_DEFER;

> + if (PTR_ERR(data->lm90_reg) == -ENODEV)
> + dev_info(>dev,
> +  "No regulator found for vdd. Assuming vdd is 
> always powered.");

On my opinion it is unnecessary message.

> + else
> + dev_warn(>dev,
> +  "Error [%ld] in getting the regulator handle 
> for vdd.\n",
> +  PTR_ERR(data->lm90_reg));

Ditto.

> + data->lm90_reg = NULL;

You can just use !IS_ERR(data->lm90_reg) macro in the future,
rather than set this to NULL.

[...]

---

[PATCH v3 14/19] clk: at91: add PMC utmi clock

[Boris BREZILLON]

This adds new at91 utmi clock implementation using common clk framework.

This clock is a pll with a fixed factor (x40).
It is used as a source for usb clock.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/Kconfig  |7 ++
 drivers/clk/at91/Makefile   |1 +
 drivers/clk/at91/clk-utmi.c |  161 +++
 drivers/clk/at91/pmc.c  |7 ++
 drivers/clk/at91/pmc.h  |5 ++
 5 files changed, 181 insertions(+)
 create mode 100644 drivers/clk/at91/clk-utmi.c

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 85b53a4..6ad37da 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -1,5 +1,8 @@
 if ARCH_AT91
 
+config HAVE_AT91_UTMI
+   bool
+
 config HAVE_AT91_DBGU0
bool
 
@@ -78,6 +81,7 @@ config SOC_SAMA5D3
select HAVE_FB_ATMEL
select HAVE_AT91_DBGU1
select AT91_USE_OLD_CLK
+   select HAVE_AT91_UTMI
help
  Select this if you are using one of Atmel's SAMA5D3 family SoC.
  This support covers SAMA5D31, SAMA5D33, SAMA5D34, SAMA5D35.
@@ -124,6 +128,7 @@ config SOC_AT91SAM9RL
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+   select HAVE_AT91_UTMI
 
 config SOC_AT91SAM9G45
bool "AT91SAM9G45 or AT91SAM9M10 families"
@@ -131,6 +136,7 @@ config SOC_AT91SAM9G45
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+   select HAVE_AT91_UTMI
help
  Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
  This support covers AT91SAM9G45, AT91SAM9G46, AT91SAM9M10 and 
AT91SAM9M11.
@@ -141,6 +147,7 @@ config SOC_AT91SAM9X5
select HAVE_FB_ATMEL
select SOC_AT91SAM9
select AT91_USE_OLD_CLK
+   select HAVE_AT91_UTMI
help
  Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
  This means that your SAM9 name finishes with a '5' (except if it is
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 3873b62..a824883 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -7,3 +7,4 @@ obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
 obj-y += clk-system.o clk-peripheral.o
 
 obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
+obj-$(CONFIG_HAVE_AT91_UTMI)   += clk-utmi.o
diff --git a/drivers/clk/at91/clk-utmi.c b/drivers/clk/at91/clk-utmi.c
new file mode 100644
index 000..244ff9e
--- /dev/null
+++ b/drivers/clk/at91/clk-utmi.c
@@ -0,0 +1,161 @@
+/*
+ * drivers/clk/at91/clk-utmi.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON 
+ *
+ * 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
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pmc.h"
+
+#define to_clk_utmi(hw) container_of(hw, struct clk_utmi, hw)
+
+struct clk_utmi {
+   struct clk_hw hw;
+   struct at91_pmc *pmc;
+   unsigned int irq;
+   wait_queue_head_t wait;
+};
+
+static irqreturn_t clk_utmi_irq_handler(int irq, void *dev_id)
+{
+   struct clk_utmi *utmi = (struct clk_utmi *)dev_id;
+
+   wake_up(>wait);
+   disable_irq_nosync(utmi->irq);
+
+   return IRQ_HANDLED;
+}
+
+static int clk_utmi_prepare(struct clk_hw *hw)
+{
+   struct clk_utmi *utmi = to_clk_utmi(hw);
+   struct at91_pmc *pmc = utmi->pmc;
+   u32 tmp = at91_pmc_read(AT91_CKGR_UCKR) | AT91_PMC_UPLLEN |
+ AT91_PMC_UPLLCOUNT | AT91_PMC_BIASEN;
+
+   pmc_write(pmc, AT91_CKGR_UCKR, tmp);
+
+   while (!(pmc_read(pmc, AT91_PMC_SR) & AT91_PMC_LOCKU)) {
+   enable_irq(utmi->irq);
+   wait_event(utmi->wait,
+  pmc_read(pmc, AT91_PMC_SR) & AT91_PMC_LOCKU);
+   }
+
+   return 0;
+}
+
+static int clk_utmi_is_ready(struct clk_hw *hw)
+{
+   struct clk_utmi *utmi = to_clk_utmi(hw);
+   struct at91_pmc *pmc = utmi->pmc;
+
+   return !!(pmc_read(pmc, AT91_PMC_SR) & AT91_PMC_LOCKU);
+}
+
+static void clk_utmi_disable(struct clk_hw *hw)
+{
+   struct clk_utmi *utmi = to_clk_utmi(hw);
+   struct at91_pmc *pmc = utmi->pmc;
+   u32 tmp = at91_pmc_read(AT91_CKGR_UCKR) & ~AT91_PMC_UPLLEN;
+
+   pmc_write(pmc, AT91_CKGR_UCKR, tmp);
+}
+
+static unsigned long clk_utmi_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+   return parent_rate * 40;
+}
+
+static const struct clk_ops utmi_ops = {
+   .prepare = clk_utmi_prepare,
+   .is_prepared = clk_utmi_is_ready,
+   .disable = clk_utmi_disable,
+   .is_enabled = clk_utmi_is_ready,
+   .recalc_rate = clk_utmi_recalc_rate,
+};
+
+static struct clk * 

Re: [PATCH V5] pci: exynos: split into two parts such as Synopsys part and Exynos part

[Jingoo Han]

On Thursday, August 08, 2013 2:05 AM, Bjorn Helgaas wrote:
> On Tue, Aug 6, 2013 at 10:13 PM, Jingoo Han  wrote:
> > On Wednesday, July 31, 2013 5:14 PM, Jingoo Han  wrote:
> >> Exynos PCIe IP consists of Synopsys specific part and Exynos
> >> specific part. Only core block is a Synopsys designware part;
> >> other parts are Exynos specific.
> >> Also, the Synopsys designware part can be shared with other
> >> platforms; thus, it can be split two parts such as Synopsys
> >> designware part and Exynos specific part.
> >>
> >> Signed-off-by: Jingoo Han 
> >> Cc: Pratyush Anand 
> >> Cc: Mohit KUMAR 
> >
> > Hi Bjorn Helgaas,
> >
> > There is no comment for last 2 weeks.
> > Will you accept this patch?
> 
> I don't have any problem with this, since it's really arch code.  Do
> you want me to merge it, or do you have a standard path for merging
> Exynos and/or Designware changes?

Hi Bjorn,

I want you to merge it. :)
Thank you.

Best regards,
Jingoo Han

> 
> Bjorn
> 
> In case you need it:
> 
> Acked-by: Bjorn Helgaas 
> 
> >> ---
> >> Changes since v4:
> >> - fixed section mismatch warnings
> >> - fixed sparse warnings
> >>
> >>  .../devicetree/bindings/pci/designware-pcie.txt|3 +
> >>  arch/arm/boot/dts/exynos5440.dtsi  |2 +
> >>  drivers/pci/host/Makefile  |3 +-
> >>  drivers/pci/host/pci-exynos.c  |  530 ++
> >>  drivers/pci/host/pcie-designware.c | 1011 
> >> ++--
> >>  drivers/pci/host/pcie-designware.h |   65 ++
> >>  6 files changed, 874 insertions(+), 740 deletions(-)
> >>  create mode 100644 drivers/pci/host/pci-exynos.c
> >>  create mode 100644 drivers/pci/host/pcie-designware.h
> >

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] f2fs: fix a build failure due to missing the kobject header

[Namjae Jeon]

2013/8/8, Jaegeuk Kim :
> This patch should resolve the following error reported by kbuild test
> robot.
>
> All error/warnings:
>
>In file included from fs/f2fs/dir.c:13:0:
>>> fs/f2fs/f2fs.h:435:17: error: field 's_kobj' has incomplete type
> struct kobject s_kobj;
>
> The failure was caused by missing the kobject header file in dir.c.
> So, this patch move the header file to the right location, f2fs.h.
>
> CC: Namjae Jeon 
> Signed-off-by: Jaegeuk Kim 
Oops.. Looks good :)
Thanks Jaegeuk!

> ---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 13/19] clk: at91: add PMC programmable clocks

[Boris BREZILLON]

This patch adds new at91 programmable clocks implementation using common clk
framework.
A programmable clock is a clock which can be exported on a given pin to clock
external devices.
Each programmable clock is given an id (from 0 to 8).
The number of available programmable clocks depends on the SoC you're using.
Programmable clock driver only implements the clock setting (clock rate and
parent setting). It must be chained to a system clock in order to
enable/disable the generated clock.
The PCKX pins used to output the clock signals must be assigned to the
appropriate peripheral (see atmel's datasheets).

Signed-off-by: Boris BREZILLON 
---
 drivers/clk/at91/Makefile   |2 +
 drivers/clk/at91/clk-programmable.c |  419 +++
 drivers/clk/at91/pmc.c  |   15 ++
 drivers/clk/at91/pmc.h  |9 +
 4 files changed, 445 insertions(+)
 create mode 100644 drivers/clk/at91/clk-programmable.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 04deba3..3873b62 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -5,3 +5,5 @@
 obj-y += pmc.o
 obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o
 obj-y += clk-system.o clk-peripheral.o
+
+obj-$(CONFIG_AT91_PROGRAMMABLE_CLOCKS) += clk-programmable.o
diff --git a/drivers/clk/at91/clk-programmable.c 
b/drivers/clk/at91/clk-programmable.c
new file mode 100644
index 000..f40de6a
--- /dev/null
+++ b/drivers/clk/at91/clk-programmable.c
@@ -0,0 +1,419 @@
+/*
+ * drivers/clk/at91/clk-programmable.c
+ *
+ *  Copyright (C) 2013 Boris BREZILLON 
+ *
+ * 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
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pmc.h"
+
+#define PROG_SOURCE_MAX5
+#define PROG_MAX   8
+
+struct clk_programmable_layout {
+   u8 pres_shift;
+   u8 css_mask;
+   u8 have_slck_mck;
+};
+
+#define to_clk_programmable(hw) container_of(hw, struct clk_programmable, hw)
+struct clk_programmable {
+   struct clk_hw hw;
+   struct at91_pmc *pmc;
+   unsigned int irq;
+   wait_queue_head_t wait;
+   u8 id;
+   u8 css;
+   u8 pres;
+   u8 slckmck;
+   const struct clk_programmable_layout *layout;
+};
+
+static irqreturn_t clk_programmable_irq_handler(int irq, void *dev_id)
+{
+   struct clk_programmable *prog = (struct clk_programmable *)dev_id;
+
+   wake_up(>wait);
+
+   return IRQ_HANDLED;
+}
+
+static int clk_programmable_prepare(struct clk_hw *hw)
+{
+   u32 tmp;
+   struct clk_programmable *prog = to_clk_programmable(hw);
+   struct at91_pmc *pmc = prog->pmc;
+   const struct clk_programmable_layout *layout = prog->layout;
+
+   tmp = prog->css | (prog->pres << layout->pres_shift);
+   if (layout->have_slck_mck && prog->slckmck)
+   tmp |= 1 << 8;
+
+   pmc_write(pmc, AT91_PMC_PCKR(prog->id), tmp);
+
+   while (!(pmc_read(pmc, AT91_PMC_SR) & (1 << (prog->id + 8
+   wait_event(prog->wait,
+  pmc_read(pmc, AT91_PMC_SR) & (1 << (prog->id + 8)));
+
+   return 0;
+}
+
+static int clk_programmable_is_ready(struct clk_hw *hw)
+{
+   struct clk_programmable *prog = to_clk_programmable(hw);
+   struct at91_pmc *pmc = prog->pmc;
+
+   return !!(pmc_read(pmc, AT91_PMC_SR) & (1 << (prog->id + 8)));
+}
+
+static unsigned long clk_programmable_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+   u32 tmp;
+   struct clk_programmable *prog = to_clk_programmable(hw);
+   struct at91_pmc *pmc = prog->pmc;
+   const struct clk_programmable_layout *layout = prog->layout;
+
+   tmp = pmc_read(pmc, AT91_PMC_PCKR(prog->id));
+   prog->pres = (tmp >> layout->pres_shift) & 0x7;
+
+   return parent_rate >> prog->pres;
+}
+
+static long clk_programmable_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *parent_rate)
+{
+   unsigned long best_rate = *parent_rate;
+   unsigned long best_diff;
+   unsigned long new_diff;
+   unsigned long cur_rate;
+   int shift = shift;
+
+   if (rate > *parent_rate)
+   return *parent_rate;
+   else
+   best_diff = *parent_rate - rate;
+
+   if (!best_diff)
+   return best_rate;
+
+   for (shift = 1; shift < 7; shift++) {
+   cur_rate = *parent_rate >> shift;
+
+   if (cur_rate > rate)
+   new_diff = cur_rate - rate;
+   else
+   new_diff = rate - cur_rate;
+
+   if 

[PATCH v3 12/19] clk: at91: add peripheral clk macros for peripheral clk dt bindings

[Boris BREZILLON]

This patch adds the peripheral divisors macros (for sam9x5 compatible IPs)
which will be used by peripheral clk dt definitions.

Signed-off-by: Boris BREZILLON 
---
 .../clk/at91/at91sam9x5/clk-peripheral.h   |   15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 include/dt-bindings/clk/at91/at91sam9x5/clk-peripheral.h

diff --git a/include/dt-bindings/clk/at91/at91sam9x5/clk-peripheral.h 
b/include/dt-bindings/clk/at91/at91sam9x5/clk-peripheral.h
new file mode 100644
index 000..a6dd506
--- /dev/null
+++ b/include/dt-bindings/clk/at91/at91sam9x5/clk-peripheral.h
@@ -0,0 +1,15 @@
+/*
+ * This header provides constants for AT91 peripheral clks.
+ *
+ * The constants defined in this header are being used in dts.
+ */
+
+#ifndef _DT_BINDINGS_CLK_AT91SAM9X5_PERIPH_H
+#define _DT_BINDINGS_CLK_AT91SAM9X5_PERIPH_H
+
+#define AT91SAM9X5_PERIPH_CLK_DIV1 0
+#define AT91SAM9X5_PERIPH_CLK_DIV2 1
+#define AT91SAM9X5_PERIPH_CLK_DIV4 2
+#define AT91SAM9X5_PERIPH_CLK_DIV8 3
+
+#endif
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] pinctrl: pinconf_generic: add utility functions for add map/configs

[Laxman Dewangan]

On Wednesday 07 August 2013 11:57 PM, Linus Walleij wrote:

On Fri, Jul 26, 2013 at 7:36 PM, Stephen Warren  wrote:

On 07/26/2013 04:15 AM, Laxman Dewangan wrote:

Some of pincontrol driver needs the utility function to create map
list. The utility function needed for adding mux, configs etc.

It is a noble goal to unify this and thank you *very* much for taking
it on.


Thanks Linus,
There is 3 patches of version 3 of same series, if it gets 
concluded/applied then I will have some more patches for removing 
duplicate code from individual driver.





I don't think those are the correct files for this code. Presumably
there's no reason at all why a pinctrl driver that doesn't require
CONFIG_GENERIC_PINCONF can't use these basic utility functions. Perhaps
add a new pinctrl-utils file?

Agree with Stephen, we need to put this in a separate file, such at
pinctrl-dt.c or just put it into core.c.


Version 3 address all these.
Thanks,,
Laxman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Aug 8

[Stephen Rothwell]

Hi all,

Changes since 20130807:

The mvebu tree lost its build failure and gained a conflict against the
i2c tree.

The renesas tree gained a conflict against the leds tree.



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" as mentioned in the FAQ on the wiki
(see below).

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 for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 222 trees (counting Linus' and 30 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

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.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (b7bc9e7 Merge tag 'trace-fixes-3.11-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace)
Merging fixes/master (b3a3a9c Merge tag 'trace-3.11-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace)
Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1)
Merging arc-current/for-curr (c095ba7 Linux 3.11-rc4)
Merging arm-current/fixes (e35ac62 Merge branch 'security-fixes' into fixes)
Merging m68k-current/for-linus (ad81f05 Linux 3.11-rc1)
Merging metag-fixes/fixes (dfe248b MAINTAINERS: add linux-metag mailing list)
Merging powerpc-merge/merge (fe956a1 powerpc/windfarm: Fix noisy slots-fan on 
Xserve (rm31))
Merging sparc/master (1c2696c sparc64: Fix ITLB handler of null page)
Merging net/master (3e3be27 ipv6: don't stop backtracking in fib6_lookup_1 if 
subtree does not match)
Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling)
Merging sound-current/for-linus (ddb6b5a ALSA: 6fire: fix DMA issues with URB 
transfer_buffer usage)
Merging pci-current/for-linus (36dd1f3 PCI: mvebu: Disable prefetchable memory 
support in PCI-to-PCI bridge)
Merging wireless/master (5a6e0cf cw1200: Fix spurious BUG_ON() trigger when 
starting AP mode.)
Merging driver-core.current/driver-core-linus (5ae90d8 Linux 3.11-rc3)
Merging tty.current/tty-linus (c095ba7 Linux 3.11-rc4)
Merging usb.current/usb-linus (444ce9d MAINTAINERS: Add separate section for 
USB NETWORKING DRIVERS)
Merging staging.current/staging-linus (cefe8a3 Merge tag 'iio-fixes-for-3.11b' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (5ae90d8 Linux 3.11-rc3)
Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus)
Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' 
and 'recovery'.)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (e70308e Revert "crypto: crct10dif - Wrap 
crc_t10dif function all to use crypto transform framework")
Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j 
option")
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct 
resource to 0 in of_irq_to_resource())
Merging rr-fixes/fixes (aa52aee virtio-scsi: Fix virtqueue affinity setup)
Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work 
without pdata)
Merging vfio-fixes/for-linus (d24cdbf vfio-pci: Avoid deadlock on remove)
Merging drm-intel-fixes/drm-intel-fixes (3f57757 drm/i915: do not disable 
backlight on vgaswitcheroo switch off)
Merging asm-generic/master (fb9de7e xtensa: Use generic asm/mmu.h for 

Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity

[Paul E. McKenney]

On Thu, Aug 08, 2013 at 01:27:55PM +0800, Lai Jiangshan wrote:
> On 08/08/2013 12:18 PM, Paul E. McKenney wrote:
> > On Thu, Aug 08, 2013 at 11:10:47AM +0800, Lai Jiangshan wrote:
> >> On 08/08/2013 10:33 AM, Paul E. McKenney wrote:
> >>> On Thu, Aug 08, 2013 at 10:33:15AM +0800, Lai Jiangshan wrote:
>  On 08/08/2013 10:12 AM, Steven Rostedt wrote:
> > On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
> >
> >>> [  393.641012]CPU0
> >>> [  393.641012]
> >>> [  393.641012]   lock(>wait_lock);
> >>> [  393.641012]   
> >>> [  393.641012] lock(>wait_lock);
> >>
> >> Patch2 causes it!
> >> When I found all lock which can (chained) nested in 
> >> rcu_read_unlock_special(),
> >> I didn't notice rtmutex's lock->wait_lock is not nested in 
> >> irq-disabled.
> >>
> >> Two ways to fix it:
> >> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
> >> 2) revert my patch2
> >
> > Your patch 2 states:
> >
> > "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
> > in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
> > when preemption)"
> 
>  Patch5 adds "special & RCU_READ_UNLOCK_BLOCKED" back in irq nor softirq.
>  This new thing is handle in patch5 if I did not do wrong things in 
>  patch5.
>  (I don't notice rtmutex's lock->wait_lock is not irqs-disabled in patch5)
> 
> >
> > But then below we have:
> >
> >
> >>
> >>> [  393.641012] 
> >>> [  393.641012]  *** DEADLOCK ***
> >>> [  393.641012] 
> >>> [  393.641012] no locks held by rcu_torture_rea/697.
> >>> [  393.641012] 
> >>> [  393.641012] stack backtrace:
> >>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 
> >>> 3.11.0-rc1+ #1
> >>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> >>> [  393.641012]  8586fea0 88001fcc3a78 8187b4cb 
> >>> 8104a261
> >>> [  393.641012]  88001e1a20c0 88001fcc3ad8 818773e4 
> >>> 
> >>> [  393.641012]  8800 8801 81010a0a 
> >>> 0001
> >>> [  393.641012] Call Trace:
> >>> [  393.641012][] dump_stack+0x4f/0x84
> >>> [  393.641012]  [] ? console_unlock+0x291/0x410
> >>> [  393.641012]  [] print_usage_bug+0x1f5/0x206
> >>> [  393.641012]  [] ? save_stack_trace+0x2a/0x50
> >>> [  393.641012]  [] mark_lock+0x283/0x2e0
> >>> [  393.641012]  [] ? 
> >>> print_irq_inversion_bug.part.40+0x1f0/0x1f0
> >>> [  393.641012]  [] __lock_acquire+0x906/0x1d40
> >>> [  393.641012]  [] ? __lock_acquire+0x2eb/0x1d40
> >>> [  393.641012]  [] ? __lock_acquire+0x2eb/0x1d40
> >>> [  393.641012]  [] lock_acquire+0x95/0x210
> >>> [  393.641012]  [] ? rt_mutex_unlock+0x53/0x100
> >>> [  393.641012]  [] _raw_spin_lock+0x36/0x50
> >>> [  393.641012]  [] ? rt_mutex_unlock+0x53/0x100
> >>> [  393.641012]  [] rt_mutex_unlock+0x53/0x100
> > 
> > The really strange thing here is that I thought that your passing false
> > in as the new second parameter to rcu_read_unlock_special() was supposed
> > to prevent rt_mutex_unlock() from being called.
> > 
> > But then why is the call from rcu_preempt_note_context_switch() also
> > passing false?  I would have expected that one to pass true.  Probably
> > I don't understand your intent with the "unlock" argument.
> > 
> >>> [  393.641012]  [] 
> >>> rcu_read_unlock_special+0x17a/0x2a0
> >>> [  393.641012]  [] rcu_check_callbacks+0x313/0x950
> >>> [  393.641012]  [] ? hrtimer_run_queues+0x1d/0x180
> >>> [  393.641012]  [] ? trace_hardirqs_off+0xd/0x10
> >>> [  393.641012]  [] update_process_times+0x43/0x80
> >>> [  393.641012]  [] 
> >>> tick_sched_handle.isra.10+0x31/0x40
> >>> [  393.641012]  [] tick_sched_timer+0x47/0x70
> >>> [  393.641012]  [] __run_hrtimer+0x7c/0x490
> >>> [  393.641012]  [] ? 
> >>> ktime_get_update_offsets+0x4d/0xe0
> >>> [  393.641012]  [] ? tick_nohz_handler+0xa0/0xa0
> >>> [  393.641012]  [] hrtimer_interrupt+0x107/0x260
> >
> > The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
> > Did it first call a rt_mutex_lock?
> >
> > If patch two was the culprit, I'm thinking the idea behind patch two is
> > wrong. The only option is to remove patch number two!
> 
>  removing patch number two can solve the problem found be Paul, but it is 
>  not the best.
>  because I can't declare that rcu is deadlock-immunity
>  (it will be deadlock if rcu read site overlaps with rtmutex's 
>  lock->wait_lock
>  if I only remove patch2)
>  I must do more things, but I think it is still better than changing 
>  rtmutex's lock->wait_lock.
> >>>
> >>> NP, I will remove your current patches and wait for 

[PATCH] f2fs: fix a build failure due to missing the kobject header

[Jaegeuk Kim]

This patch should resolve the following error reported by kbuild test robot.

All error/warnings:

   In file included from fs/f2fs/dir.c:13:0:
   >> fs/f2fs/f2fs.h:435:17: error: field 's_kobj' has incomplete type
struct kobject s_kobj;

The failure was caused by missing the kobject header file in dir.c.
So, this patch move the header file to the right location, f2fs.h.

CC: Namjae Jeon 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h  | 1 +
 fs/f2fs/super.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 13db10b..d8e386ce 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * For mount options
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 94c0e20..66d1ec1 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "f2fs.h"
-- 
1.8.3.1.437.g0dbd812

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] ARM: dt: t114 dalmore: add dt entry for nct1008

[Wei Ni]

Enable thermal sensor nct1008 for t114 dalmore.

Signed-off-by: Wei Ni 
---
 arch/arm/boot/dts/tegra114-dalmore.dts |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
b/arch/arm/boot/dts/tegra114-dalmore.dts
index b5a42f0..9d4d2b2 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -738,6 +738,14 @@
realtek,ldo1-en-gpios =
< TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
};
+
+   nct1008 {
+   compatible = "onnn,nct1008";
+   reg = <0x4c>;
+   vdd-supply = <_ldo6_reg>;
+   interrupt-parent = <>;
+   interrupts = ;
+   };
};
 
i2c@7000d000 {
@@ -945,7 +953,7 @@
regulator-max-microvolt = 
<180>;
};
 
-   ldo6 {
+   palmas_ldo6_reg: ldo6 {
regulator-name = 
"vdd-sensor-2v85";
regulator-min-microvolt = 
<285>;
regulator-max-microvolt = 
<285>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] hwmon: (lm90) Add power control

[Wei Ni]

The device lm90 can be controlled by the vdd rail.
Adding the power control support to power on/off the vdd rail.
And make sure that power is enabled before accessing the device.

Signed-off-by: Wei Ni 
---
 drivers/hwmon/lm90.c |   49 +
 1 file changed, 49 insertions(+)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index cdff742..306a348 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -89,6 +89,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Addresses to scan
@@ -302,6 +303,7 @@ static const struct lm90_params lm90_params[] = {
 struct lm90_data {
struct device *hwmon_dev;
struct mutex update_lock;
+   struct regulator *lm90_reg;
char valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
int kind;
@@ -1391,6 +1393,32 @@ static void lm90_init_client(struct i2c_client *client)
i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1, config);
 }
 
+static void lm90_power_control(struct i2c_client *client, bool is_enable)
+{
+   struct lm90_data *data = i2c_get_clientdata(client);
+   int ret;
+
+   if (!data->lm90_reg)
+   return;
+
+   mutex_lock(>update_lock);
+
+   if (is_enable)
+   ret = regulator_enable(data->lm90_reg);
+   else
+   ret = regulator_disable(data->lm90_reg);
+
+   if (ret < 0)
+   dev_err(>dev,
+   "Error in %s rail vdd, error %d\n",
+   (is_enable) ? "enabling" : "disabling", ret);
+   else
+   dev_info(>dev, "success in %s rail vdd\n",
+(is_enable) ? "enabling" : "disabling");
+
+   mutex_unlock(>update_lock);
+}
+
 static int lm90_probe(struct i2c_client *client,
  const struct i2c_device_id *id)
 {
@@ -1406,6 +1434,20 @@ static int lm90_probe(struct i2c_client *client,
i2c_set_clientdata(client, data);
mutex_init(>update_lock);
 
+   data->lm90_reg = regulator_get(>dev, "vdd");
+   if (IS_ERR_OR_NULL(data->lm90_reg)) {
+   if (PTR_ERR(data->lm90_reg) == -ENODEV)
+   dev_info(>dev,
+"No regulator found for vdd. Assuming vdd is 
always powered.");
+   else
+   dev_warn(>dev,
+"Error [%ld] in getting the regulator handle 
for vdd.\n",
+PTR_ERR(data->lm90_reg));
+   data->lm90_reg = NULL;
+   }
+
+   lm90_power_control(client, true);
+
/* Set the device type */
data->kind = id->driver_data;
if (data->kind == adm1032) {
@@ -1473,6 +1515,10 @@ exit_remove_files:
lm90_remove_files(client, data);
 exit_restore:
lm90_restore_conf(client, data);
+   lm90_power_control(client, false);
+   if (data->lm90_reg)
+   regulator_put(data->lm90_reg);
+
return err;
 }
 
@@ -1483,6 +1529,9 @@ static int lm90_remove(struct i2c_client *client)
hwmon_device_unregister(data->hwmon_dev);
lm90_remove_files(client, data);
lm90_restore_conf(client, data);
+   lm90_power_control(client, false);
+   if (data->lm90_reg)
+   regulator_put(data->lm90_reg);
 
return 0;
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] Documentation: dt: hwmon: add OF document for lm90

[Wei Ni]

Add OF document for lm90 in Documentation/devicetree/.

Signed-off-by: Wei Ni 
---
 Documentation/devicetree/bindings/hwmon/lm90.txt |   20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/lm90.txt

diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt 
b/Documentation/devicetree/bindings/hwmon/lm90.txt
new file mode 100644
index 000..8024f11
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lm90.txt
@@ -0,0 +1,20 @@
+* LM90 series thermometer.
+
+Required node properties:
+- compatible: manufacture and chip name,
+  which are listed in the Documentation/hwmon/lm90
+- reg: I2C bus address of the device
+
+Optional properties:
+- vdd-supply: vdd regulator for the supply voltage. If this is not set,
+  assuming vdd is always powered.
+- interrupts: lm90 can support interrupt mode, you can set interrupt here.
+
+Example lm90 node:
+
+nct1008 {
+   compatible = "onnn,nct1008";
+   reg = <0x4c>;
+   vdd-supply = <_ldo6_reg>;
+   interrupt-parent = <>;
+   interrupts = ;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/3] Add power control for lm90

[Wei Ni]

The device lm90 can be controlled by the vdd rail.
Add function to power on/off the vdd.
Enable the nct1008 on Tegra114 Dalmore board, and set the vdd-regulator.

This series is v2, previous version patches:
[v1]: http://www.mail-archive.com/linux-tegra@vger.kernel.org/msg12034.html

Changes from v1:
1. if get regulator failed, we should continue to run probe function,
not return fail.
2. call regulator_put() in error handler and remove function.
3. add LM90 DT binding document.

Wei Ni (3):
  hwmon: (lm90) Add power control
  ARM: dt: t114 dalmore: add dt entry for nct1008
  Documentation: dt: hwmon: add OF document for lm90

 Documentation/devicetree/bindings/hwmon/lm90.txt |   20 +
 arch/arm/boot/dts/tegra114-dalmore.dts   |   10 -
 drivers/hwmon/lm90.c |   49 ++
 3 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/lm90.txt

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional

[Gilad Ben-Yossef]

On Thu, Jun 20, 2013 at 5:05 PM, Christoph Lameter  wrote:
>
> On Wed, 19 Jun 2013, Gilad Ben-Yossef wrote:
>
> > +static void vmstat_update(struct work_struct *w)
> > +{
> > + int cpu, this_cpu = smp_processor_id();
> > +
> > + if (unlikely(this_cpu == vmstat_monitor_cpu))
> > + for_each_cpu_not(cpu, _cpus)
> > + if (need_vmstat(cpu))
> > + start_cpu_timer(cpu);
> > +
> > + if (likely(refresh_cpu_vm_stats(this_cpu) || (this_cpu ==
> > vmstat_monitor_cpu)))
> > + schedule_delayed_work(&__get_cpu_var(vmstat_work),
> > +
> > round_jiffies_relative(sysctl_stat_interval));
> > + else
> > + cpumask_clear_cpu(this_cpu, _cpus);
>
> The clearing of vmstat_cpus could be avoided if this processor is not
> running tickless. Frequent updates to vmstat_cpus could become an issue.

I like the idea of tying the vmstat disabling to the tickless logic
but I seem to have run
into a bit of a chicken and egg problem here:

vmstat_update runs from the vmstat work queue item by the workqueue
kernel thread.

If this code is running, it means there are at least two schedulable tasks:
1. The workqueue kernel thread, because it is running.
2. At least one more task, otherwise were were in idle and the
workqueue kernel thread
would not execute this work item.

Unfortunately, having two schedulable tasks means we're not running
tickless, so the check
will never trigger - or have I've missed something obvious?

Thanks,
Gilad


--
Gilad Ben-Yossef
Chief Coffee Drinker
gi...@benyossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a situation
where the homework eats your dog?"
 -- Jean-Baptiste Queru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: Add device tree binding file for MOXA ART SoCs interrupt controller

[Jonas Jensen]

Hi Mark,

On 2 August 2013 11:35, Mark Rutland  wrote:
>> The MOXA ART irqchip driver was added without accompanying devicetree 
>> document.
>> ( in next-20130716   drivers/irqchip/irq-moxart.c )
>
> Aaargh. That should not have happened >:(

Sorry about this, my plan was to submit all documents along with
moxart platform support. At the time I did not know it is more normal
to push the binding along with the driver.

>> +- interrupt-mask: Specifies if the interrupt is edge or level-triggered
>> +  each bit represent an interrupt 0-31 where 1 signify edge
>
> For the GIC, this gets descrbied in the interrupt sepcifier rather than
> on the interrupt controller's root node. Is there a reason to do this
> differently here?

The reason is, IRQ types must be written to the controller as two u32
registers (IRQ_MODE_REG and IRQ_LEVEL_REG). I could not find an easier
way (that uses generic things) to do it.

It's true that "interrupt-mask" is redundant, DT "interrupts" hold the
same information. I just never found nice way to collect it from DT.

See registers written on line 111:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/irqchip/irq-moxart.c#n111


Best regards,
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] perf tools: Setup GTK browser dynamically

[Namhyung Kim]

Call setup/exit GTK browser function using libdl.

Cc: Andi Kleen 
Reviewed-by: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/gtk/gtk.h |  3 +++
 tools/perf/ui/setup.c   | 50 +++--
 tools/perf/ui/ui.h  | 12 +---
 3 files changed, 52 insertions(+), 13 deletions(-)

diff --git a/tools/perf/ui/gtk/gtk.h b/tools/perf/ui/gtk/gtk.h
index 3d96785ef155..09b7a062fd48 100644
--- a/tools/perf/ui/gtk/gtk.h
+++ b/tools/perf/ui/gtk/gtk.h
@@ -20,6 +20,9 @@ struct perf_gtk_context {
guint statbar_ctx_id;
 };
 
+int perf_gtk__init(void);
+void perf_gtk__exit(bool wait_for_ok);
+
 extern struct perf_gtk_context *pgctx;
 
 static inline bool perf_gtk__is_active_context(struct perf_gtk_context *ctx)
diff --git a/tools/perf/ui/setup.c b/tools/perf/ui/setup.c
index 47d9a571f261..8c03741b 100644
--- a/tools/perf/ui/setup.c
+++ b/tools/perf/ui/setup.c
@@ -1,10 +1,56 @@
 #include 
+#include 
 
 #include "../util/cache.h"
 #include "../util/debug.h"
 #include "../util/hist.h"
 
 pthread_mutex_t ui__lock = PTHREAD_MUTEX_INITIALIZER;
+void *perf_gtk_handle;
+
+#ifdef GTK2_SUPPORT
+static int setup_gtk_browser(void)
+{
+   int (*perf_ui_init)(void);
+
+   perf_gtk_handle = dlopen("libperf-gtk.so", RTLD_LAZY);
+   if (perf_gtk_handle == NULL)
+   return -1;
+
+   perf_ui_init = dlsym(perf_gtk_handle, "perf_gtk__init");
+   if (perf_ui_init == NULL)
+   goto out_close;
+
+   if (perf_ui_init() == 0)
+   return 0;
+
+out_close:
+   dlclose(perf_gtk_handle);
+   return -1;
+}
+
+static void exit_gtk_browser(bool wait_for_ok)
+{
+   void (*perf_ui_exit)(bool);
+
+   if (perf_gtk_handle == NULL)
+   return;
+
+   perf_ui_exit = dlsym(perf_gtk_handle, "perf_gtk__exit");
+   if (perf_ui_exit == NULL)
+   goto out_close;
+
+   perf_ui_exit(wait_for_ok);
+
+out_close:
+   dlclose(perf_gtk_handle);
+
+   perf_gtk_handle = NULL;
+}
+#else
+static inline int setup_gtk_browser(void) { return -1; }
+static inline void exit_gtk_browser(bool wait_for_ok __maybe_unused) {}
+#endif
 
 void setup_browser(bool fallback_to_pager)
 {
@@ -17,7 +63,7 @@ void setup_browser(bool fallback_to_pager)
 
switch (use_browser) {
case 2:
-   if (perf_gtk__init() == 0)
+   if (setup_gtk_browser() == 0)
break;
/* fall through */
case 1:
@@ -39,7 +85,7 @@ void exit_browser(bool wait_for_ok)
 {
switch (use_browser) {
case 2:
-   perf_gtk__exit(wait_for_ok);
+   exit_gtk_browser(wait_for_ok);
break;
 
case 1:
diff --git a/tools/perf/ui/ui.h b/tools/perf/ui/ui.h
index 70cb0d4eb8aa..4f7cbe6a2608 100644
--- a/tools/perf/ui/ui.h
+++ b/tools/perf/ui/ui.h
@@ -6,6 +6,7 @@
 #include 
 
 extern pthread_mutex_t ui__lock;
+extern void *perf_gtk_handle;
 
 extern int use_browser;
 
@@ -23,17 +24,6 @@ static inline int ui__init(void)
 static inline void ui__exit(bool wait_for_ok __maybe_unused) {}
 #endif
 
-#ifdef GTK2_SUPPORT
-int perf_gtk__init(void);
-void perf_gtk__exit(bool wait_for_ok);
-#else
-static inline int perf_gtk__init(void)
-{
-   return -1;
-}
-static inline void perf_gtk__exit(bool wait_for_ok __maybe_unused) {}
-#endif
-
 void ui__refresh_dimensions(bool force);
 
 #endif /* _PERF_UI_H_ */
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH/RFC 0/3] perf ui/gtk: Separate out GTK code to a shared object (v3)

[Namhyung Kim]

Hi,

This is v3 of gtk code separation patchset to reduce library
dependencies of the perf executable.

I only built libperf-gtk.so with -fPIC, and it's not linked to libperf
at build time.  All unresolved symbols used for perf should be
resolved at runtime via perf executable (so libperf.a) - I didn't know
that the linker permits unresolved symbols in a shared library at
build time.

Tested on my x86-64 machine only.  It seems work well for me.

v3 changes:
 * fix build failure on O= option
 * fix build failure on NO_GTK2= option
 * add Reviewed-by tag from Pekka
 * patch 1 of previous series already merged

You can find it on my 'perf/separate-v3' branch in my tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git


Any comments are welcome, thanks
Namhyung


Cc: Pekka Enberg 
Cc: Andi Kleen 

Namhyung Kim (3):
  perf tools: Separate out GTK codes to libperf-gtk.so
  perf tools: Setup GTK browser dynamically
  perf tools: Run dynamic loaded GTK browser

 tools/perf/Makefile   | 39 +++--
 tools/perf/builtin-annotate.c | 26 +++---
 tools/perf/builtin-report.c   | 16 --
 tools/perf/config/Makefile| 12 ---
 tools/perf/ui/gtk/annotate.c  | 13 ---
 tools/perf/ui/gtk/gtk.h   | 16 ++
 tools/perf/ui/setup.c | 50 +--
 tools/perf/ui/ui.h| 12 +--
 tools/perf/util/annotate.h| 24 -
 tools/perf/util/hist.h| 15 -
 10 files changed, 149 insertions(+), 74 deletions(-)

-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] perf tools: Run dynamic loaded GTK browser

[Namhyung Kim]

Run GTK hist and annotation browser using libdl.

Cc: Andi Kleen 
Reviewed-by: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-annotate.c | 26 +++---
 tools/perf/builtin-report.c   | 16 ++--
 tools/perf/config/Makefile|  2 +-
 tools/perf/ui/gtk/annotate.c  | 13 ++---
 tools/perf/ui/gtk/gtk.h   | 13 +
 tools/perf/util/annotate.h| 24 
 tools/perf/util/hist.h| 15 ---
 7 files changed, 61 insertions(+), 48 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index db491e9a812b..82469b3ead07 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -30,6 +30,7 @@
 #include "util/tool.h"
 #include "arch/common.h"
 
+#include 
 #include 
 
 struct perf_annotate {
@@ -143,8 +144,18 @@ find_next:
 
if (use_browser == 2) {
int ret;
+   int (*annotate)(struct hist_entry *he,
+   struct perf_evsel *evsel,
+   struct hist_browser_timer *hbt);
+
+   annotate = dlsym(perf_gtk_handle,
+"hist_entry__gtk_annotate");
+   if (annotate == NULL) {
+   ui__error("GTK browser not found!\n");
+   return;
+   }
 
-   ret = hist_entry__gtk_annotate(he, evsel, NULL);
+   ret = annotate(he, evsel, NULL);
if (!ret || !ann->skip_missing)
return;
 
@@ -246,8 +257,17 @@ static int __cmd_annotate(struct perf_annotate *ann)
goto out_delete;
}
 
-   if (use_browser == 2)
-   perf_gtk__show_annotations();
+   if (use_browser == 2) {
+   void (*show_annotations)(void);
+
+   show_annotations = dlsym(perf_gtk_handle,
+"perf_gtk__show_annotations");
+   if (show_annotations == NULL) {
+   ui__error("GTK browser not found!\n");
+   goto out_delete;
+   }
+   show_annotations();
+   }
 
 out_delete:
/*
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index d785d89ed226..05c0e80c8ae4 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -35,6 +35,7 @@
 #include "util/hist.h"
 #include "arch/common.h"
 
+#include 
 #include 
 
 struct perf_report {
@@ -592,8 +593,19 @@ static int __cmd_report(struct perf_report *rep)
ret = 0;
 
} else if (use_browser == 2) {
-   perf_evlist__gtk_browse_hists(session->evlist, help,
- NULL, rep->min_percent);
+   int (*hist_browser)(struct perf_evlist *,
+   const char *,
+   struct hist_browser_timer *,
+   float min_pcnt);
+
+   hist_browser = dlsym(perf_gtk_handle,
+"perf_evlist__gtk_browse_hists");
+   if (hist_browser == NULL) {
+   ui__error("GTK browser not found!\n");
+   return ret;
+   }
+   hist_browser(session->evlist, help, NULL,
+rep->min_percent);
}
} else
perf_evlist__tty_browse_hists(session->evlist, rep, help);
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 6bdfd0302c4e..1b6ccb242609 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -269,7 +269,7 @@ ifndef NO_GTK2
 ifeq ($(call 
try-cc,$(SOURCE_GTK2_INFOBAR),$(FLAGS_GTK2),-DHAVE_GTK_INFO_BAR),y)
   GTK_CFLAGS := -DHAVE_GTK_INFO_BAR
 endif
-GTK_CFLAGS += -DGTK2_SUPPORT
+CFLAGS += -DGTK2_SUPPORT
 GTK_CFLAGS += $(shell pkg-config --cflags gtk+-2.0 2>/dev/null)
 GTK_LIBS := $(shell pkg-config --libs gtk+-2.0 2>/dev/null)
   endif
diff --git a/tools/perf/ui/gtk/annotate.c b/tools/perf/ui/gtk/annotate.c
index f538794615db..9c7ff8d31b27 100644
--- a/tools/perf/ui/gtk/annotate.c
+++ b/tools/perf/ui/gtk/annotate.c
@@ -154,9 +154,9 @@ static int perf_gtk__annotate_symbol(GtkWidget *window, 
struct symbol *sym,
return 0;
 }
 
-int symbol__gtk_annotate(struct symbol *sym, struct map *map,
-struct perf_evsel *evsel,
-struct hist_browser_timer *hbt)
+static int symbol__gtk_annotate(struct symbol *sym, struct map *map,
+   struct perf_evsel *evsel,
+   struct 

[PATCH 1/3] perf tools: Separate out GTK codes to libperf-gtk.so

[Namhyung Kim]

Separate out GTK codes to a shared object called libperf-gtk.so.  This
time only GTK codes are built with -fPIC and libperf remains as is.

Cc: Andi Kleen 
Reviewed-by: Pekka Enberg 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Makefile| 39 ---
 tools/perf/config/Makefile | 14 ++
 2 files changed, 38 insertions(+), 15 deletions(-)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index e0d3d9f96771..dba23d201f27 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -113,6 +113,7 @@ SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
 BUILTIN_OBJS =
 LIB_H =
 LIB_OBJS =
+GTK_OBJS =
 PYRF_OBJS =
 SCRIPT_SH =
 
@@ -485,13 +486,19 @@ ifndef NO_SLANG
 endif
 
 ifndef NO_GTK2
-  LIB_OBJS += $(OUTPUT)ui/gtk/browser.o
-  LIB_OBJS += $(OUTPUT)ui/gtk/hists.o
-  LIB_OBJS += $(OUTPUT)ui/gtk/setup.o
-  LIB_OBJS += $(OUTPUT)ui/gtk/util.o
-  LIB_OBJS += $(OUTPUT)ui/gtk/helpline.o
-  LIB_OBJS += $(OUTPUT)ui/gtk/progress.o
-  LIB_OBJS += $(OUTPUT)ui/gtk/annotate.o
+  ALL_PROGRAMS += $(OUTPUT)libperf-gtk.so
+
+  GTK_OBJS += $(OUTPUT)ui/gtk/browser.o
+  GTK_OBJS += $(OUTPUT)ui/gtk/hists.o
+  GTK_OBJS += $(OUTPUT)ui/gtk/setup.o
+  GTK_OBJS += $(OUTPUT)ui/gtk/util.o
+  GTK_OBJS += $(OUTPUT)ui/gtk/helpline.o
+  GTK_OBJS += $(OUTPUT)ui/gtk/progress.o
+  GTK_OBJS += $(OUTPUT)ui/gtk/annotate.o
+
+install-gtk: $(OUTPUT)libperf-gtk.so
+   $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(libdir_SQ)'
+   $(INSTALL) $(OUTPUT)libperf-gtk.so '$(DESTDIR_SQ)$(libdir_SQ)'
 endif
 
 ifndef NO_LIBPERL
@@ -545,6 +552,12 @@ $(OUTPUT)perf: $(OUTPUT)perf.o $(BUILTIN_OBJS) $(PERFLIBS)
$(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(OUTPUT)perf.o \
$(BUILTIN_OBJS) $(LIBS) -o $@
 
+$(GTK_OBJS): $(OUTPUT)%.o: %.c $(LIB_H)
+   $(QUIET_CC)$(CC) -o $@ -c -fPIC $(CFLAGS) $(GTK_CFLAGS) $<
+
+$(OUTPUT)libperf-gtk.so: $(GTK_OBJS) $(PERFLIBS)
+   $(QUIET_LINK)$(CC) -o $@ -shared $(ALL_LDFLAGS) $(filter %.o,$^) 
$(GTK_LIBS)
+
 $(OUTPUT)builtin-help.o: builtin-help.c $(OUTPUT)common-cmds.h 
$(OUTPUT)PERF-CFLAGS
$(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) \
'-DPERF_HTML_PATH="$(htmldir_SQ)"' \
@@ -763,7 +776,9 @@ check: $(OUTPUT)common-cmds.h
 
 ### Installation rules
 
-install-bin: all
+install-gtk:
+
+install-bin: all install-gtk
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) $(OUTPUT)perf '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 
'$(DESTDIR_SQ)$(perfexec_instdir_SQ)/scripts/perl/Perf-Trace-Util/lib/Perf/Trace'
@@ -796,15 +811,17 @@ $(INSTALL_DOC_TARGETS):
 ### Cleaning rules
 
 clean: $(LIBTRACEEVENT)-clean $(LIBLK)-clean
-   $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) $(LIB_FILE) $(OUTPUT)perf-archive 
$(OUTPUT)perf.o $(LANG_BINDINGS)
+   $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) $(LIB_FILE) $(GTK_OBJS)
+   $(RM) $(OUTPUT)perf-archive $(OUTPUT)perf.o $(LANG_BINDINGS)
$(RM) $(ALL_PROGRAMS) perf
-   $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS 
tags cscope*
+   $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo
+   $(RM) $(OUTPUT)common-cmds.h TAGS tags cscope*
$(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean
$(RM) $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)PERF-CFLAGS
$(RM) $(OUTPUT)util/*-bison*
$(RM) $(OUTPUT)util/*-flex*
$(python-clean)
 
-.PHONY: all install clean strip $(LIBTRACEEVENT) $(LIBLK)
+.PHONY: all install clean strip $(LIBTRACEEVENT) $(LIBLK) install-gtk
 .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
 .PHONY: .FORCE-PERF-VERSION-FILE TAGS tags cscope .FORCE-PERF-CFLAGS
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 214e17e97e5c..6bdfd0302c4e 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -267,11 +267,11 @@ ifndef NO_GTK2
 NO_GTK2 := 1
   else
 ifeq ($(call 
try-cc,$(SOURCE_GTK2_INFOBAR),$(FLAGS_GTK2),-DHAVE_GTK_INFO_BAR),y)
-  CFLAGS += -DHAVE_GTK_INFO_BAR
+  GTK_CFLAGS := -DHAVE_GTK_INFO_BAR
 endif
-CFLAGS += -DGTK2_SUPPORT
-CFLAGS += $(shell pkg-config --cflags gtk+-2.0 2>/dev/null)
-EXTLIBS += $(shell pkg-config --libs gtk+-2.0 2>/dev/null)
+GTK_CFLAGS += -DGTK2_SUPPORT
+GTK_CFLAGS += $(shell pkg-config --cflags gtk+-2.0 2>/dev/null)
+GTK_LIBS := $(shell pkg-config --libs gtk+-2.0 2>/dev/null)
   endif
 endif
 
@@ -456,7 +456,12 @@ else
 sysconfdir = $(prefix)/etc
 ETC_PERFCONFIG = etc/perfconfig
 endif
+ifeq ($(IS_X86_64),1)
+lib = lib64
+else
 lib = lib
+endif
+libdir = $(prefix)/$(lib)
 
 # Shell quote (do not use $(call) to accommodate ancient setups);
 ETC_PERFCONFIG_SQ = $(subst ','\'',$(ETC_PERFCONFIG))
@@ -469,6 +474,7 @@ template_dir_SQ = $(subst ','\'',$(template_dir))
 htmldir_SQ = $(subst ','\'',$(htmldir))
 prefix_SQ = $(subst ','\'',$(prefix))
 sysconfdir_SQ = $(subst ','\'',$(sysconfdir))
+libdir_SQ = $(subst ','\'',$(libdir))
 
 ifneq ($(filter /%,$(firstword $(perfexecdir))),)
 

Re: [PATCH] [TRIVIAL] ARM: msm: fix compilation error in gpiomux

[Krzysztof Kozlowski]

On śro, 2013-08-07 at 14:08 -0700, Stephen Boyd wrote:
> On 08/07, David Brown wrote:
> > On Wed, Aug 07, 2013 at 08:34:39AM +0200, Krzysztof Kozlowski wrote:
> > >Fix compilation error in gpiomux (CONFIG_MSM_GPIOMUX=y):
> > >arch/arm/mach-msm/gpiomux.c:24:13: error: static declaration of
> > >   ???__msm_gpiomux_write??? follows non-static declaration
> > >arch/arm/mach-msm/gpiomux.h:85:6: note: previous declaration of
> > >   ???__msm_gpiomux_write??? was here
> > >
> > >Signed-off-by: Krzysztof Kozlowski 
> > 
> > Thanks, I'll pull this in.
> > 
> >  
> > 
> 
> I believe this is fixed by Rohit's patch that has already been
> taken in a pull request?
> 
> https://lkml.org/lkml/2013/7/26/608

Yes, Rohit's patch fixes the problem so this is already in linux-msm
tree.


Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] Enhanced support for MPC8xx/8xxx watchdog

[Christophe Leroy]

This patch modifies the behaviour of the MPC8xx/8xxx watchdog. On the MPC8xx,
at 133Mhz, the maximum timeout of the watchdog timer is 1s, which means it must
be pinged twice a second. This is not in line with the Linux watchdog concept
which is based on a default watchdog timeout around 60s.
This patch introduces an intermediate layer between the CPU and the userspace.
The kernel pings the watchdog at the required frequency at the condition that
userspace tools refresh it regularly.
Existing parameter 'timeout' is renamed 'hw_timeout'.
The new parameter 'timeout' allows to set up the userspace timeout.
This patch also adds the WDIOC_SETTIMEOUT ioctl to the driver.

Signed-off-by: Christophe Leroy 

--- linux-3.8.13/drivers/watchdog/mpc8xxx_wdt.c 2013-05-11 22:57:46.0 
+0200
+++ linux/drivers/watchdog/mpc8xxx_wdt.c2013-08-08 02:12:15.0 
+0200
@@ -52,10 +52,18 @@
 static struct mpc8xxx_wdt __iomem *wd_base;
 static int mpc8xxx_wdt_init_late(void);
 
-static u16 timeout = 0x;
-module_param(timeout, ushort, 0);
+#define WD_TIMO 60 /* Default timeout = 60 seconds */
+
+static uint timeout = WD_TIMO;
+module_param(timeout, uint, 0);
 MODULE_PARM_DESC(timeout,
-   "Watchdog timeout in ticks. (0swcrr, tmp);
 
-   del_timer_sync(_timer);
+   wdt_auto = 0;
 
return nonseekable_open(inode, file);
 }
@@ -138,7 +163,8 @@
 static int mpc8xxx_wdt_release(struct inode *inode, struct file *file)
 {
if (!nowayout)
-   mpc8xxx_wdt_timer_ping(0);
+   wdt_auto = 1;
+
else
mpc8xxx_wdt_pr_warn("watchdog closed");
clear_bit(0, _is_open);
@@ -155,6 +181,7 @@
.firmware_version = 1,
.identity = "MPC8xxx",
};
+   int r;
 
switch (cmd) {
case WDIOC_GETSUPPORT:
@@ -163,10 +190,15 @@
case WDIOC_GETBOOTSTATUS:
return put_user(0, p);
case WDIOC_KEEPALIVE:
-   mpc8xxx_wdt_keepalive();
+   mpc8xxx_wdt_sw_keepalive();
return 0;
case WDIOC_GETTIMEOUT:
-   return put_user(timeout_sec, p);
+   return put_user(timeout, p);
+   case WDIOC_SETTIMEOUT:
+   r = get_user(timeout, p);
+   if (timeout > UINT_MAX / HZ)
+   timeout = UINT_MAX / HZ;
+   return r;
default:
return -ENOTTY;
}
@@ -215,21 +247,26 @@
ret = -ENOSYS;
goto err_unmap;
}
+   if (enabled)
+   hw_timeout = in_be32(_base->swcrr) >> 16;
 
/* Calculate the timeout in seconds */
if (prescale)
-   timeout_sec = (timeout * wdt_type->prescaler) / freq;
+   hw_timeout_sec = (hw_timeout * wdt_type->prescaler) / freq;
else
-   timeout_sec = timeout / freq;
+   hw_timeout_sec = hw_timeout / freq;
 
+   /* Make sure the timeout is not too big */
+   if (timeout > UINT_MAX / HZ)
+   timeout = UINT_MAX / HZ;
 #ifdef MODULE
ret = mpc8xxx_wdt_init_late();
if (ret)
goto err_unmap;
 #endif
 
-   pr_info("WDT driver for MPC8xxx initialized. mode:%s timeout=%d (%d 
seconds)\n",
-   reset ? "reset" : "interrupt", timeout, timeout_sec);
+   pr_info("WDT driver for MPC8xxx initialized. mode:%s timeout = %d (%d 
seconds)\n",
+   reset ? "reset" : "interrupt", hw_timeout, hw_timeout_sec);
 
/*
 * If the watchdog was previously enabled or we're running on
@@ -273,6 +310,7 @@
.compatible = "fsl,mpc823-wdt",
.data = &(struct mpc8xxx_wdt_type) {
.prescaler = 0x800,
+   .hw_enabled = true,
},
},
{},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/7] perf, x86: Save/resotre LBR stack during context switch

[Yan, Zheng]

On 07/05/2013 08:31 PM, Peter Zijlstra wrote:
> On Fri, Jul 05, 2013 at 04:51:33PM +0800, Yan, Zheng wrote:
 the LBR is shared resource, can be used by multiple events at the same 
 time.
>>>
>>> Yeah so? There's tons of shared resources in the PMU already.
>>
>> we should restore the LBR callstack only when task schedule in. restoring 
>> the LBR
>> callstack at any other time will make the LBR callstack and actual callchain 
>> of program
>> mismatch. this property make the LBR different from counters.
> 
> But it doesn't change the fact that the LBR is controlled through
> events.
> 
>> yes，on both sides we'd have the LBR running. but there is no need to 
>> save/restore
>> the LBR stack in this case. we should save the LBR stack only when task 
>> schedule out,
>> and restore the LBR stack when task schedule in. So I think it's more 
>> natural to
>> manage the LBR state when switching perf task context.
> 
> And I never said we shouldn't, I just said we should push it down into the PMU
> driver and not have a hook out into the generic code. The generic code should
> ideally not know anything about LBR, it should only care about events.
> 
> Something like the below... although I'm still not entirely happy with that
> either.

Sorry for the delay.

How about the patch below. It introduces a pmu sched_ctx() callback and uses 
the callback
to flush LBR stack. The sched_ctx() callback can also be used to save/restore 
the lBR stack.

Thanks.
Yan, Zheng

---
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 8355c84..e5cb20d 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1846,10 +1846,10 @@ static const struct attribute_group 
*x86_pmu_attr_groups[] = {
NULL,
 };
 
-static void x86_pmu_flush_branch_stack(void)
+static void x86_pmu_sched_ctx(struct perf_event_context *ctx, bool sched_in)
 {
-   if (x86_pmu.flush_branch_stack)
-   x86_pmu.flush_branch_stack();
+   if (x86_pmu.sched_ctx)
+   x86_pmu.sched_ctx(ctx, sched_in);
 }
 
 void perf_check_microcode(void)
@@ -1878,7 +1878,7 @@ static struct pmu pmu = {
.commit_txn = x86_pmu_commit_txn,
 
.event_idx  = x86_pmu_event_idx,
-   .flush_branch_stack = x86_pmu_flush_branch_stack,
+   .sched_ctx  = x86_pmu_sched_ctx,
 };
 
 void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 97e557b..1320376 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -150,6 +150,7 @@ struct cpu_hw_events {
 * Intel LBR bits
 */
int lbr_users;
+   int lbr_sys_users;
void*lbr_context;
struct perf_branch_stacklbr_stack;
struct perf_branch_entrylbr_entries[MAX_LBR_ENTRIES];
@@ -411,7 +412,8 @@ struct x86_pmu {
void(*cpu_dead)(int cpu);
 
void(*check_microcode)(void);
-   void(*flush_branch_stack)(void);
+   void(*sched_ctx)(struct perf_event_context *ctx,
+bool sched_in);
 
/*
 * Intel Arch Perfmon v2+
@@ -663,6 +665,8 @@ void intel_pmu_pebs_disable_all(void);
 
 void intel_ds_init(void);
 
+void intel_pmu_lbr_sched_ctx(struct perf_event_context *ctx, bool sched_in);
+
 void intel_pmu_lbr_reset(void);
 
 void intel_pmu_lbr_enable(struct perf_event *event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index fbc9210..c8f0318 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1849,16 +1849,15 @@ static void intel_pmu_cpu_dying(int cpu)
fini_debug_store_on_cpu(cpu);
 }
 
-static void intel_pmu_flush_branch_stack(void)
+static void intel_pmu_sched_ctx(struct perf_event_context *ctx, bool sched_in)
 {
/*
 * Intel LBR does not tag entries with the
 * PID of the current task, then we need to
 * flush it on ctxsw
-* For now, we simply reset it
 */
if (x86_pmu.lbr_nr)
-   intel_pmu_lbr_reset();
+   intel_pmu_lbr_sched_ctx(ctx, sched_in);
 }
 
 PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
@@ -1912,7 +1911,7 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_starting   = intel_pmu_cpu_starting,
.cpu_dying  = intel_pmu_cpu_dying,
.guest_get_msrs = intel_guest_get_msrs,
-   .flush_branch_stack = intel_pmu_flush_branch_stack,
+   .sched_ctx  = intel_pmu_sched_ctx,
 };
 
 static __init void intel_clovertown_quirk(void)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c 
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index