[PATCH v12 08/15] powerpc/PCI: Keep resource idx order with bridge register number

2016-06-03 Thread Yinghai Lu 
Same as sparc version.

Make resource with consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.

Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.

Signed-off-by: Yinghai Lu 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/kernel/pci_of_scan.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index 526ac67..719f225 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -252,7 +252,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
bus->resource[i] = res;
++res;
}
-   i = 1;
+   i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
flags = pci_parse_of_flags(of_read_number(ranges, 1), 1);
size = of_read_number([6], 2);
@@ -265,6 +265,12 @@ void of_scan_pci_bridge(struct pci_dev *dev)
   " for bridge %s\n", node->full_name);
continue;
}
+   } else if ((flags & IORESOURCE_PREFETCH) &&
+  !bus->resource[2]->flags) {
+   res = bus->resource[2];
+   } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+   IORESOURCE_MEM) && !bus->resource[1]->flags) {
+   res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
-- 
2.8.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: running qemu for powerpc (32bits) architecture

2016-06-03 Thread Scott Wood 
On Mon, 2016-05-30 at 10:04 +0100, Marwa Hamza wrote:
> hello everyone
> I'm trying to run qemu for powerpc architecture but either
> 1/ i got a black screen with this sentence " QEMU 2.4.0.1 monitor - type
> help for more information"
>(QEMU)
> if i run this command ./ppc-softmmu/qemu-system-ppc -M ppce500 -kernel
> ../linux-4.4.1/arch/powerpc/boot/zImage -initrd powerpc/busybox
> -1.21.0/rootfs.img.gz -append "root=/dev/ram rdinit=/bin/sh"

I can't help with the other platforms, but for ppce500, make sure you have
CONFIG_PPC_QEMU_E500 enabled in the kernel (and that it's an e500 build, of
course), pass either uImage or vmlinux (not zImage) to -kernel, and specify
the desired cpu type on the QEMU command line (using -cpu) to match the type
of kernel you built.  I recommend using e500mc rather than older e500 because
then you get standard floating point which your RFS may depend on.

Also note that this target will have a serial port for output, not a display,
so configure QEMU appropriately with -serial for how you want to access that.

If you need more help (especially with other PPC platforms) I suggest the 
qemu-...@nongnu.org mailing list.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v12 02/15] PCI: Let pci_mmap_page_range() take resource address

2016-06-03 Thread Yinghai Lu 
In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
to check exposed value with resource start/end in proc mmap path.

|start = vma->vm_pgoff;
|size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
|pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
|pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
|if (start >= pci_start && start < pci_start + size &&
|start + nr <= pci_start + size)

That breaks sparc that exposed value is BAR value, and need to be offseted
to resource address.

Original pci_mmap_page_range() is taking PCI BAR value aka usr_address.

Bjorn found out that it would be much simple to pass resource address
directly and avoid extra those __pci_mmap_make_offset.

In this patch:
1. in proc path: proc_bus_pci_mmap, try convert back to resource
   before calling pci_mmap_page_range
2. in sysfs path: pci_mmap_resource will just offset with resource start.
3. all pci_mmap_page_range will have vma->vm_pgoff with in resource
   range instead of BAR value.
4. remove __pci_mmap_make_offset, as the checking is done
   in pci_mmap_fits().

-v2: add pci_user_to_resource and remove __pci_mmap_make_offset
-v3: pass resource pointer with pci_mmap_page_range()

Signed-off-by: Yinghai Lu 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
---
 arch/microblaze/pci/pci-common.c |  78 +++---
 arch/powerpc/kernel/pci-common.c |  78 +++---
 arch/sparc/kernel/pci.c  | 117 ---
 arch/xtensa/kernel/pci.c |  75 -
 drivers/pci/pci-sysfs.c  |  33 ---
 drivers/pci/proc.c   |  63 ++---
 6 files changed, 104 insertions(+), 340 deletions(-)

diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 95146b0..4e21993 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -156,69 +156,6 @@ void pcibios_set_master(struct pci_dev *dev)
  */
 
 /*
- * Adjust vm_pgoff of VMA such that it is the physical page offset
- * corresponding to the 32-bit pci bus offset for DEV requested by the user.
- *
- * Basically, the user finds the base address for his device which he wishes
- * to mmap.  They read the 32-bit value from the config space base register,
- * add whatever PAGE_SIZE multiple offset they wish, and feed this into the
- * offset parameter of mmap on /proc/bus/pci/XXX for that device.
- *
- * Returns negative error code on failure, zero on success.
- */
-static struct resource *__pci_mmap_make_offset(struct pci_dev *dev,
-  resource_size_t *offset,
-  enum pci_mmap_state mmap_state)
-{
-   struct pci_controller *hose = pci_bus_to_host(dev->bus);
-   unsigned long io_offset = 0;
-   int i, res_bit;
-
-   if (!hose)
-   return NULL;/* should never happen */
-
-   /* If memory, add on the PCI bridge address offset */
-   if (mmap_state == pci_mmap_mem) {
-#if 0 /* See comment in pci_resource_to_user() for why this is disabled */
-   *offset += hose->pci_mem_offset;
-#endif
-   res_bit = IORESOURCE_MEM;
-   } else {
-   io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
-   *offset += io_offset;
-   res_bit = IORESOURCE_IO;
-   }
-
-   /*
-* Check that the offset requested corresponds to one of the
-* resources of the device.
-*/
-   for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
-   struct resource *rp = >resource[i];
-   int flags = rp->flags;
-
-   /* treat ROM as memory (should be already) */
-   if (i == PCI_ROM_RESOURCE)
-   flags |= IORESOURCE_MEM;
-
-   /* Active and same type? */
-   if ((flags & res_bit) == 0)
-   continue;
-
-   /* In the range of this resource? */
-   if (*offset < (rp->start & PAGE_MASK) || *offset > rp->end)
-   continue;
-
-   /* found it! construct the final physical address */
-   if (mmap_state == pci_mmap_io)
-   *offset += hose->io_base_phys - io_offset;
-   return rp;
-   }
-
-   return NULL;
-}
-
-/*
  * Set vm_page_prot of VMA, as appropriate for this architecture, for a pci
  * device mapping.
  */
@@ -310,12 +247,15 @@ int pci_mmap_page_range(struct pci_dev *dev, struct 
resource *rp,
 {
resource_size_t offset =
((resource_size_t)vma->vm_pgoff) << PAGE_SHIFT;
-   struct resource *rp;
int ret;
 
-   rp = __pci_mmap_make_offset(dev, , mmap_state);
-   if (rp == NULL)
-   return -EINVAL;
+   if

[PATCH v12 01/15] PCI: Let pci_mmap_page_range() take extra resource pointer

2016-06-03 Thread Yinghai Lu 
This one is preparing patch for next one:
  PCI: Let pci_mmap_page_range() take resource addr

We need to pass extra resource pointer to avoid searching that again
for powerpc and microblaze prot set operation.

Signed-off-by: Yinghai Lu 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-cris-ker...@axis.com
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-am33-l...@redhat.com
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
---
 arch/arm/include/asm/pci.h  | 2 --
 arch/arm/kernel/bios32.c| 3 ++-
 arch/cris/arch-v32/drivers/pci/bios.c   | 3 ++-
 arch/cris/include/asm/pci.h | 3 ---
 arch/ia64/include/asm/pci.h | 2 --
 arch/ia64/pci/pci.c | 3 ++-
 arch/microblaze/include/asm/pci.h   | 3 ---
 arch/microblaze/pci/pci-common.c| 3 ++-
 arch/mips/include/asm/pci.h | 3 ---
 arch/mips/pci/pci.c | 3 ++-
 arch/mn10300/include/asm/pci.h  | 3 ---
 arch/mn10300/unit-asb2305/pci-asb2305.c | 3 ++-
 arch/parisc/include/asm/pci.h   | 3 ---
 arch/parisc/kernel/pci.c| 3 ++-
 arch/powerpc/include/asm/pci.h  | 3 ---
 arch/powerpc/kernel/pci-common.c| 3 ++-
 arch/sh/drivers/pci/pci.c   | 3 ++-
 arch/sh/include/asm/pci.h   | 2 --
 arch/sparc/include/asm/pci_64.h | 4 
 arch/sparc/kernel/pci.c | 3 ++-
 arch/unicore32/include/asm/pci.h| 2 --
 arch/unicore32/kernel/pci.c | 3 ++-
 arch/x86/include/asm/pci.h  | 4 
 arch/x86/pci/i386.c | 3 ++-
 arch/xtensa/include/asm/pci.h   | 4 
 arch/xtensa/kernel/pci.c| 3 ++-
 drivers/pci/pci-sysfs.c | 2 +-
 drivers/pci/pci.h   | 2 +-
 drivers/pci/proc.c  | 2 +-
 include/linux/pci.h | 6 ++
 30 files changed, 35 insertions(+), 54 deletions(-)

diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
index 057d381..51118a0 100644
--- a/arch/arm/include/asm/pci.h
+++ b/arch/arm/include/asm/pci.h
@@ -29,8 +29,6 @@ static inline int pci_proc_domain(struct pci_bus *bus)
 #define PCI_DMA_BUS_IS_PHYS (1)
 
 #define HAVE_PCI_MMAP
-extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
-   enum pci_mmap_state mmap_state, int 
write_combine);
 
 static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
 {
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 05e61a2..d3245d1 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -602,7 +602,8 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
return pci_enable_resources(dev, mask);
 }
 
-int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
+int pci_mmap_page_range(struct pci_dev *dev, struct resource *res,
+   struct vm_area_struct *vma,
enum pci_mmap_state mmap_state, int write_combine)
 {
if (mmap_state == pci_mmap_io)
diff --git a/arch/cris/arch-v32/drivers/pci/bios.c 
b/arch/cris/arch-v32/drivers/pci/bios.c
index 64a5fb9..082efb9 100644
--- a/arch/cris/arch-v32/drivers/pci/bios.c
+++ b/arch/cris/arch-v32/drivers/pci/bios.c
@@ -14,7 +14,8 @@ void pcibios_set_master(struct pci_dev *dev)
pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
 }
 
-int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
+int pci_mmap_page_range(struct pci_dev *dev, struct resource *res,
+   struct vm_area_struct *vma,
enum pci_mmap_state mmap_state, int write_combine)
 {
unsigned long prot;
diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
index b1b289d..65198cb 100644
--- a/arch/cris/include/asm/pci.h
+++ b/arch/cris/include/asm/pci.h
@@ -42,9 +42,6 @@ struct pci_dev;
 #define PCI_DMA_BUS_IS_PHYS(1)
 
 #define HAVE_PCI_MMAP
-extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
-  enum pci_mmap_state mmap_state, int 
write_combine);
-
 
 #endif /* __KERNEL__ */
 
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index c0835b0..6a2f5d8 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@ -51,8 +51,6 @@ extern unsigned long ia64_max_iommu_merge_mask;
 #define PCI_DMA_BUS_IS_PHYS(ia64_max_iommu_merge_mask == ~0UL)
 
 #define HAVE_PCI_MMAP
-extern int pci_mmap_page_range (struct pci_dev *dev, struct vm_area_struct 
*vma,
-   enum pci_mmap_state mmap_state, int 
write_combine);
 #define HAVE_PCI_LEGACY
 extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
  struct vm_area_struct

[PATCH v12 09/15] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

2016-06-03 Thread Yinghai Lu 
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.

This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource
flags parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Gavin Shan 
Cc: Yijing Wang 
Cc: Anton Blanchard 
Cc: linuxppc-dev@lists.ozlabs.org
---
 arch/powerpc/kernel/pci_of_scan.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index 719f225..476b8ac5 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -44,8 +44,10 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
 
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
-   flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+   if (addr0 & 0x0100)
+   flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
 | PCI_BASE_ADDRESS_MEM_PREFETCH;
-- 
2.8.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Status of DPAA integration for NXP QoriQ?

2016-06-03 Thread Scott Wood 
On Mon, 2016-05-09 at 10:29 +0200, Sebastian Huber wrote:
> Hello,
> 
> the "fman" Ethernet driver was integrated in mainline Linux Dezember 
> 2015 ("drivers/net/ethernet/freescale/fman"). It seems that the other 
> parts, e.g. BMan, QMan ("drivers/soc/fsl/qbman") and basic DPAA Ethernet 
> support ("drivers/net/ethernet/freescale/dpaa") are still missing. Are 
> there any plans to integrate them? I didn't notice any activity on the 
> mailing list in the last couple of months in this respect.

Yes, we are still planning to integrate the other components.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: on a MPC8360 system, how can i read the *actual* bus frequencies?

2016-06-03 Thread Scott Wood 
On Tue, 2016-05-10 at 17:11 -0400, Robert P. J. Day wrote:
>   bit of a conundrum here ... we have a legacy MPC8360 system here, on
> which we installed linux built with wind river linux 8. we obviously
> want to push the various bus frequencies to their max for best
> performance, and the device tree that was being used for this system
> assigned rather slow speeds (266MHz) for the various buses.
> 
>   i wasn't sure how to view the bus frequencies that were *actually*
> being used. first, i thought that anything you found under
> /proc/devicetree simply showed the device tree values as they were
> passed to the kernel, so i wasn't going to trust those.
> 
>   also, i thought that anything under /sys would show the genuine
> frequency values and, after searching, i found various PPC bus
> frequencies under /sys/firmware/..., but they *also* showed fairly
> slow speeds.
> 
>   finally, someone wrote a program that read directly from the
> system registers:
> 
> tempVal = *M83XX_SPMR(vxCCSBARGet());
> lbcm   = M83XX_SPMR_LBCM_VAL(tempVal);
> ddrcm = M83XX_SPMR_DDRCM_VAL(tempVal);
> spmf   = M83XX_SPMR_SPMF_VAL(tempVal);
> clkDiv  = M83XX_SPMR_CLKID_VAL(tempVal);
> corePll = M83XX_SPMR_COREPLL_VAL(tempVal);
> cepdf  = M83XX_SPMR_CEPDF_VAL(tempVal);
> cepmf  = M83XX_SPMR_CEPMF_VAL(tempVal);
> 
> which, surprisingly, showed what appears to be the maximum allowable
> bus frequencies; for example
> 
>   Enter mcd command -> sysGetCoreSpeed
>   value = 52800 = 0x1fca0340
> 
> so i'm willing to believe that the system really is running at max
> speed, but is there no easier way to see the bus frequencies that are
> actually in use, rather than having to dig into the system registers?
> 
>   why would the values under /sys not reflect the actual bus
> frequencies, and not (as it appears) just the ones passed to the
> kernel which were obviously not used?

I'm not familiar with /sys/firmware but I don't think there's anything in the
kernel that cares about CPU speed on these chips (no cpufreq or clock driver),
so why would it do anything other than trust the device tree?  If the device
tree is wrong, fix that.

If you want the core frequency, look in the CPU node, not the speed of
"various buses".

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: problem with cuImage.mpc834x_mds image

2016-06-03 Thread Scott Wood 
On Fri, 2016-05-27 at 23:12 +0200, Giuseppe Lippolis wrote:
> Dear All,
> I'm trying with buildroot to build the linux-4.4.3 for an iomega 150d
> machine mounting the mpc8347E sys.
> Due the old U-Boot version is not possible to use the standard uImage, but
> it is needed to set the cuImage target (the one embedding the device tree).
> 
> I start using the default configuration
> arch/powerpc/configs/mpc83xx_defconfig,
> and the default device tree mpc834x_mds.
> 
> In order to enable the console  output during the first linux boot stage I
> added the following line at the end of the device tree file:
> 
> chosen {
> linux,stdout-path = "/soc8349/serial at 4500";
> };
> 
> The kernel is compiled and I get the cuImage.mpc834x_mds image.
> 
> Then I load it on the machine and execute:
> 
> tftp 0x1000 cuImage.mpc834x_mds
> Speed: 1000, full duplex
> Using Freescale TSEC0 device
> TFTP from server 192.168.178.36; our IP address is 192.168.178.10
> Filename 'cuImage.mpc834x_mds'.
> Load address: 0x1000
> Loading: #
>  #
>  #
>  #
>  #
>  #
>  
> done
> Bytes transferred = 2157489 (20ebb1 hex)
> IOMEGA=> bootm 0x1000
> ## Booting image at 1000 ...
>Image Name:   Linux-4.4.3
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:2157425 Bytes =  2.1 MB
>Load Address: 0050
>Entry Point:  005001f8
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
> Memory <- <0x0 0x2000> (512MB)
> ethernet0: local-mac-address <- 00:d0:b8:01:d1:9f
> ethernet1: local-mac-address <- 9b:e3:00:01:72:6f
> CPU clock-frequency <- 0x179a7b00 (396MHz)
> CPU timebase-frequency <- 0x3ef1480 (66MHz)
> CPU bus-frequency <- 0xfbc5200 (264MHz)
> 
> zImage starting: loaded at 0x0050 (sp: 0x1ffb2ce8)
> Allocating 0x439a88 bytes for kernel ...
> gunzipping (0x <- 0x0050e000:0x00940fe8)...done 0x422920 bytes
> 
> Linux/PowerPC load: root=/dev/mtdblock1 ro rootfstype=cramfs devfs=mount
> console=ttyS0,115200 init=/linuxrc
> Finalizing device tree... flat tree at 0x94d120
> 
> 
> But at this point the process crash and the system is reset.
> It should be something near the handover between the first kenel boot stage
> and the vmlinux start, but I do not have a jtag to proceed the
> investigation.
>
> In any case it seems that the execution never entry the vmlinux start
> (head_32.S).
> 
> I try to add this macro at the begin of the file:
> 
> .equ cnsladdr, 0xe0004500 (console address txreg)
> 
> .macro dbg_prnt nid
> lis r24, cnsladdr at ha
> addir24, r24, cnsladdr at l
> li  r25, 'd'
> stb r25, 0(r24)
> li  r25, 'b'
> stb r25, 0(r24)
> li  r25, 'g'
> stb r25, 0(r24)
> li  r25, '0'
> addir25, r25, \nid
> stb r25, 0(r24)
> li  r25, '\n'
> stb r25, 0(r24)
> .endm
> 
> 
> But I do not see anything in the console.

Have you tried inserting a loop to wait until the transmitter is empty before
sending a character?

> The problem seems releted to the vmlinux call in arc/powerpc/boot/main.c
> 
> kentry = (kernel_entry_t) vmlinux.addr;
> 
> 
> Any suggestion?

Check (with serial output) that flow control reaches the very end of the
bootwrapper before it jumps to Linux.  Use the same code that you use in
head.S (with loop added in both cases).  Print the entry address, and some
bytes loaded from that address to confirm the image is there.  Check that the
BATs are set up correctly, etc.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

2016-06-03 Thread Steve Muckle 
On Fri, Jun 03, 2016 at 07:05:14PM +0530, Viresh Kumar wrote:
...
> @@ -468,20 +469,15 @@ unsigned int acpi_cpufreq_fast_switch(struct 
> cpufreq_policy *policy,
>   struct acpi_cpufreq_data *data = policy->driver_data;
>   struct acpi_processor_performance *perf;
>   struct cpufreq_frequency_table *entry;
> - unsigned int next_perf_state, next_freq, freq;
> + unsigned int next_perf_state, next_freq, index;
>  
>   /*
>* Find the closest frequency above target_freq.
> -  *
> -  * The table is sorted in the reverse order with respect to the
> -  * frequency and all of the entries are valid (see the initialization).
>*/
> - entry = policy->freq_table;
> - do {
> - entry++;
> - freq = entry->frequency;
> - } while (freq >= target_freq && freq != CPUFREQ_TABLE_END);
> - entry--;
> + index = cpufreq_frequency_table_target(policy, target_freq,
> +CPUFREQ_RELATION_L);

Can we call cpufreq_find_index_l directly here? Seems like we could
phase out cpufreq_frequency_table_target() for the most part and call
the helpers directly. It would avoid some code bloat, an unnecessary
switch statement and an error check for an invalid frequency table which
seems unnecessary for every frequency table lookup.

thanks,
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/3] mm: Change the interface for __tlb_remove_page

2016-06-03 Thread kbuild test robot 
Hi,

[auto build test ERROR on arm/for-next]
[also build test ERROR on v4.7-rc1 next-20160603]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/mm-hugetlb-Simplify-hugetlb-unmap/20160603-211611
base:   http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
config: sh-titan_defconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

Note: the 
linux-review/Aneesh-Kumar-K-V/mm-hugetlb-Simplify-hugetlb-unmap/20160603-211611 
HEAD d6ef168b95ef6261d48eff011e532d6a8798f4cd builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   mm/memory.c: In function 'zap_pte_range':
>> mm/memory.c:1210:4: error: implicit declaration of function 
>> '__tlb_adjust_range' [-Werror=implicit-function-declaration]
   __tlb_adjust_range(tlb, tlb->addr);
   ^
>> mm/memory.c:1210:31: error: 'struct mmu_gather' has no member named 'addr'
   __tlb_adjust_range(tlb, tlb->addr);
  ^
   cc1: some warnings being treated as errors

vim +/__tlb_adjust_range +1210 mm/memory.c

  1204   */
  1205  if (force_flush) {
  1206  force_flush = 0;
  1207  tlb_flush_mmu_free(tlb);
  1208  if (pending_page) {
  1209  /* remove the page with new size */
> 1210  __tlb_adjust_range(tlb, tlb->addr);
  1211  __tlb_remove_page(tlb, pending_page);
  1212  pending_page = NULL;
  1213  }

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


.config.gz
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

2016-06-03 Thread Viresh Kumar 
The drivers aren't required to provide a sorted frequency table today,
and its not optimal to work on an unsorted frequency tables.

To simplify and improve code performance, always keep policy->freq_table
sorted in ascending order.

Now that freq_table is sorted, update cpufreq_frequency_table_target()
to make it more efficient with help of new helpers.

As these helpers will be used by scheduler hotpath later on, keep them
in a new header cpufreq_table.h to avoid unnecessary function calls.

Also update acpi-cpufreq driver to use the efficient
cpufreq_frequency_table_target() routine, as we can't assume the
descending order of frequencies in freq_table anymore.

Tested on Exynos board with both ondemand and schedutil governor and
confirmed with help of various print messages that we are eventually
switching to the desired frequency based on a target frequency.

Signed-off-by: Viresh Kumar 
---
 MAINTAINERS|   1 +
 drivers/cpufreq/acpi-cpufreq.c |  16 ++--
 drivers/cpufreq/cpufreq.c  |  20 +++--
 drivers/cpufreq/cpufreq_ondemand.h |   1 +
 drivers/cpufreq/freq_table.c   | 163 +++--
 drivers/cpufreq/powernv-cpufreq.c  |   1 +
 drivers/cpufreq/s3c24xx-cpufreq.c  |   1 +
 drivers/cpufreq/s5pv210-cpufreq.c  |   1 +
 include/linux/cpufreq.h|   3 -
 include/linux/cpufreq_table.h  | 139 +++
 10 files changed, 227 insertions(+), 119 deletions(-)
 create mode 100644 include/linux/cpufreq_table.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7304d2e37a98..315d49d68500 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3205,6 +3205,7 @@ T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
 T: git git://git.linaro.org/people/vireshk/linux.git (For ARM Updates)
 F: drivers/cpufreq/
 F: include/linux/cpufreq.h
+F: include/linux/cpufreq_table.h
 
 CPU FREQUENCY DRIVERS - ARM BIG LITTLE
 M: Viresh Kumar 
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 32a15052f363..364b86119f3f 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -468,20 +469,15 @@ unsigned int acpi_cpufreq_fast_switch(struct 
cpufreq_policy *policy,
struct acpi_cpufreq_data *data = policy->driver_data;
struct acpi_processor_performance *perf;
struct cpufreq_frequency_table *entry;
-   unsigned int next_perf_state, next_freq, freq;
+   unsigned int next_perf_state, next_freq, index;
 
/*
 * Find the closest frequency above target_freq.
-*
-* The table is sorted in the reverse order with respect to the
-* frequency and all of the entries are valid (see the initialization).
 */
-   entry = policy->freq_table;
-   do {
-   entry++;
-   freq = entry->frequency;
-   } while (freq >= target_freq && freq != CPUFREQ_TABLE_END);
-   entry--;
+   index = cpufreq_frequency_table_target(policy, target_freq,
+  CPUFREQ_RELATION_L);
+
+   entry = >freq_table[index];
next_freq = entry->frequency;
next_perf_state = entry->driver_data;
 
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 9ae58a18ccb9..91f33bc28fa4 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1137,6 +1138,16 @@ static void cpufreq_policy_free(struct cpufreq_policy 
*policy, bool notify)
kfree(policy);
 }
 
+static void cpufreq_policy_exit(struct cpufreq_policy *policy)
+{
+   if (!cpufreq_driver->exit)
+   return;
+
+   cpufreq_driver->exit(policy);
+   kfree(policy->freq_table);
+   policy->freq_table = NULL;
+}
+
 static int cpufreq_online(unsigned int cpu)
 {
struct cpufreq_policy *policy;
@@ -1291,9 +1302,7 @@ static int cpufreq_online(unsigned int cpu)
 
 out_exit_policy:
up_write(>rwsem);
-
-   if (cpufreq_driver->exit)
-   cpufreq_driver->exit(policy);
+   cpufreq_policy_exit(policy);
 out_free_policy:
cpufreq_policy_free(policy, !new_policy);
return ret;
@@ -1378,10 +1387,7 @@ static void cpufreq_offline(unsigned int cpu)
 * since this is a core component, and is essential for the
 * subsequent light-weight ->init() to succeed.
 */
-   if (cpufreq_driver->exit) {
-   cpufreq_driver->exit(policy);
-   policy->freq_table = NULL;
-   }
+   cpufreq_policy_exit(policy);
 
 unlock:
up_write(>rwsem);
diff --git a/drivers/cpufreq/cpufreq_ondemand.h 
b/drivers/cpufreq/cpufreq_ondemand.h
index 640ea4e97106..dc90c07ace8e 100644
--- a/drivers/cpufreq/cpufreq_ondemand.h

Re: [PATCH v2 1/3] mm/hugetlb: Simplify hugetlb unmap

2016-06-03 Thread Aneesh Kumar K.V 

Hi Andrew,

The updated version includes a build fix for [PATCH 2/3. I also dropped the
powerpc related changes from the series because that have dependencies
against other patches not yet merged upstream. I am adding the same
below for reference.

From 1f0975adfd3138f3709b2dec8771065ddc38de40 Mon Sep 17 00:00:00 2001
From: "Aneesh Kumar K.V" 
Date: Tue, 10 May 2016 12:24:34 +0530
Subject: [PATCH 4/4] powerpc/mm/radix: Implement tlb mmu gather flush
 efficiently

Now that we track page size in mmu_gather, we can use address based
tlbie format when doing a tlb_flush(). We don't do this if we are
invalidating the full address space.

Signed-off-by: Aneesh Kumar K.V 
---
 .../powerpc/include/asm/book3s/64/tlbflush-radix.h |  2 +
 arch/powerpc/mm/tlb-radix.c| 73 +-
 2 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h 
b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 3fa94fcac628..862c8fa50268 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -10,6 +10,8 @@ static inline int mmu_get_ap(int psize)
return mmu_psize_defs[psize].ap;
 }
 
+extern void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long 
start,
+unsigned long end, int psize);
 extern void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long 
start,
unsigned long end);
 extern void radix__flush_tlb_kernel_range(unsigned long start, unsigned long 
end);
diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
index 231e3ed2e684..03e719ee6747 100644
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -279,9 +279,80 @@ void radix__flush_tlb_range(struct vm_area_struct *vma, 
unsigned long start,
 }
 EXPORT_SYMBOL(radix__flush_tlb_range);
 
+static int radix_get_mmu_psize(int page_size)
+{
+   int psize;
+
+   if (page_size == (1UL << mmu_psize_defs[mmu_virtual_psize].shift))
+   psize = mmu_virtual_psize;
+   else if (page_size == (1UL << mmu_psize_defs[MMU_PAGE_2M].shift))
+   psize = MMU_PAGE_2M;
+   else if (page_size == (1UL << mmu_psize_defs[MMU_PAGE_1G].shift))
+   psize = MMU_PAGE_1G;
+   else
+   return -1;
+   return psize;
+}
 
 void radix__tlb_flush(struct mmu_gather *tlb)
 {
+   int psize = 0;
struct mm_struct *mm = tlb->mm;
-   radix__flush_tlb_mm(mm);
+   int page_size = tlb->page_size;
+
+   psize = radix_get_mmu_psize(page_size);
+   /*
+* if page size is not something we understand, do a full mm flush
+*/
+   if (psize != -1 && !tlb->fullmm && !tlb->need_flush_all)
+   radix__flush_tlb_range_psize(mm, tlb->start, tlb->end, psize);
+   else
+   radix__flush_tlb_mm(mm);
+}
+
+#define TLB_FLUSH_ALL -1UL
+/*
+ * Number of pages above which we will do a bcast tlbie. Just a
+ * number at this point copied from x86
+ */
+static unsigned long tlb_single_page_flush_ceiling __read_mostly = 33;
+
+void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long start,
+ unsigned long end, int psize)
+{
+   unsigned long pid;
+   unsigned long addr;
+   int local = mm_is_core_local(mm);
+   unsigned long ap = mmu_get_ap(psize);
+   int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+   unsigned long page_size = 1UL << mmu_psize_defs[psize].shift;
+
+
+   preempt_disable();
+   pid = mm ? mm->context.id : 0;
+   if (unlikely(pid == MMU_NO_CONTEXT))
+   goto err_out;
+
+   if (end == TLB_FLUSH_ALL ||
+   (end - start) > tlb_single_page_flush_ceiling * page_size) {
+   if (local)
+   _tlbiel_pid(pid, RIC_FLUSH_TLB);
+   else
+   _tlbie_pid(pid, RIC_FLUSH_TLB);
+   goto err_out;
+   }
+   for (addr = start; addr < end; addr += page_size) {
+
+   if (local)
+   _tlbiel_va(addr, pid, ap, RIC_FLUSH_TLB);
+   else {
+   if (lock_tlbie)
+   raw_spin_lock(_tlbie_lock);
+   _tlbie_va(addr, pid, ap, RIC_FLUSH_TLB);
+   if (lock_tlbie)
+   raw_spin_unlock(_tlbie_lock);
+   }
+   }
+err_out:
+   preempt_enable();
 }
-- 
2.7.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 1/3] mm/hugetlb: Simplify hugetlb unmap

2016-06-03 Thread Aneesh Kumar K.V 
For hugetlb like THP (and unlike regular page), we do tlb flush after
dropping ptl. Because of the above, we don't need to track force_flush
like we do now. Instead we can simply call tlb_remove_page() which
will do the flush if needed.

No functionality change in this patch.

Signed-off-by: Aneesh Kumar K.V 
---
 mm/hugetlb.c | 54 +-
 1 file changed, 21 insertions(+), 33 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d26162e81fea..741429d01668 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3138,7 +3138,6 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, 
struct vm_area_struct *vma,
unsigned long start, unsigned long end,
struct page *ref_page)
 {
-   int force_flush = 0;
struct mm_struct *mm = vma->vm_mm;
unsigned long address;
pte_t *ptep;
@@ -3157,19 +3156,22 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, 
struct vm_area_struct *vma,
tlb_start_vma(tlb, vma);
mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
address = start;
-again:
for (; address < end; address += sz) {
ptep = huge_pte_offset(mm, address);
if (!ptep)
continue;
 
ptl = huge_pte_lock(h, mm, ptep);
-   if (huge_pmd_unshare(mm, , ptep))
-   goto unlock;
+   if (huge_pmd_unshare(mm, , ptep)) {
+   spin_unlock(ptl);
+   continue;
+   }
 
pte = huge_ptep_get(ptep);
-   if (huge_pte_none(pte))
-   goto unlock;
+   if (huge_pte_none(pte)) {
+   spin_unlock(ptl);
+   continue;
+   }
 
/*
 * Migrating hugepage or HWPoisoned hugepage is already
@@ -3177,7 +3179,8 @@ again:
 */
if (unlikely(!pte_present(pte))) {
huge_pte_clear(mm, address, ptep);
-   goto unlock;
+   spin_unlock(ptl);
+   continue;
}
 
page = pte_page(pte);
@@ -3187,9 +3190,10 @@ again:
 * are about to unmap is the actual page of interest.
 */
if (ref_page) {
-   if (page != ref_page)
-   goto unlock;
-
+   if (page != ref_page) {
+   spin_unlock(ptl);
+   continue;
+   }
/*
 * Mark the VMA as having unmapped its page so that
 * future faults in this VMA will fail rather than
@@ -3205,30 +3209,14 @@ again:
 
hugetlb_count_sub(pages_per_huge_page(h), mm);
page_remove_rmap(page, true);
-   force_flush = !__tlb_remove_page(tlb, page);
-   if (force_flush) {
-   address += sz;
-   spin_unlock(ptl);
-   break;
-   }
-   /* Bail out after unmapping reference page if supplied */
-   if (ref_page) {
-   spin_unlock(ptl);
-   break;
-   }
-unlock:
+
spin_unlock(ptl);
-   }
-   /*
-* mmu_gather ran out of room to batch pages, we break out of
-* the PTE lock to avoid doing the potential expensive TLB invalidate
-* and page-free while holding it.
-*/
-   if (force_flush) {
-   force_flush = 0;
-   tlb_flush_mmu(tlb);
-   if (address < end && !ref_page)
-   goto again;
+   tlb_remove_page(tlb, page);
+   /*
+* Bail out after unmapping reference page if supplied
+*/
+   if (ref_page)
+   break;
}
mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
tlb_end_vma(tlb, vma);
-- 
2.7.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 3/3] mm/mmu_gather: Track page size with mmu gather and force flush if page size change

2016-06-03 Thread Aneesh Kumar K.V 
This allows arch which need to do special handing with respect to
different page size when flushing tlb to implement the same in mmu gather

Signed-off-by: Aneesh Kumar K.V 
---
 arch/arm/include/asm/tlb.h  | 18 ++
 arch/ia64/include/asm/tlb.h | 18 ++
 arch/s390/include/asm/tlb.h | 18 ++
 arch/sh/include/asm/tlb.h   | 18 ++
 arch/um/include/asm/tlb.h   | 18 ++
 include/asm-generic/tlb.h   | 37 +++--
 mm/huge_memory.c|  2 +-
 mm/hugetlb.c|  2 +-
 mm/memory.c | 13 ++---
 9 files changed, 133 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 45dea952b0e6..1e25cd80589e 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -225,6 +225,24 @@ static inline void tlb_remove_page(struct mmu_gather *tlb, 
struct page *page)
}
 }
 
+static inline bool __tlb_remove_page_size(struct mmu_gather *tlb,
+ struct page *page, int page_size)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline bool __tlb_remove_pte_page(struct mmu_gather *tlb,
+struct page *page)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline void tlb_remove_page_size(struct mmu_gather *tlb,
+   struct page *page, int page_size)
+{
+   return tlb_remove_page(tlb, page);
+}
+
 static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t pte,
unsigned long addr)
 {
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index 85005ab513e9..77e541cf0e5d 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -242,6 +242,24 @@ static inline void tlb_remove_page(struct mmu_gather *tlb, 
struct page *page)
}
 }
 
+static inline bool __tlb_remove_page_size(struct mmu_gather *tlb,
+ struct page *page, int page_size)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline bool __tlb_remove_pte_page(struct mmu_gather *tlb,
+struct page *page)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline void tlb_remove_page_size(struct mmu_gather *tlb,
+   struct page *page, int page_size)
+{
+   return tlb_remove_page(tlb, page);
+}
+
 /*
  * Remove TLB entry for PTE mapped at virtual address ADDRESS.  This is called 
for any
  * PTE, not just those pointing to (normal) physical memory.
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index 6b98cb3601d5..15711de10403 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -98,6 +98,24 @@ static inline void tlb_remove_page(struct mmu_gather *tlb, 
struct page *page)
free_page_and_swap_cache(page);
 }
 
+static inline bool __tlb_remove_page_size(struct mmu_gather *tlb,
+ struct page *page, int page_size)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline bool __tlb_remove_pte_page(struct mmu_gather *tlb,
+struct page *page)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline void tlb_remove_page_size(struct mmu_gather *tlb,
+   struct page *page, int page_size)
+{
+   return tlb_remove_page(tlb, page);
+}
+
 /*
  * pte_free_tlb frees a pte table and clears the CRSTE for the
  * page table from the tlb.
diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index 3dec5e0734f5..025cdb1032f6 100644
--- a/arch/sh/include/asm/tlb.h
+++ b/arch/sh/include/asm/tlb.h
@@ -109,6 +109,24 @@ static inline void tlb_remove_page(struct mmu_gather *tlb, 
struct page *page)
__tlb_remove_page(tlb, page);
 }
 
+static inline bool __tlb_remove_page_size(struct mmu_gather *tlb,
+ struct page *page, int page_size)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline bool __tlb_remove_pte_page(struct mmu_gather *tlb,
+struct page *page)
+{
+   return __tlb_remove_page(tlb, page);
+}
+
+static inline void tlb_remove_page_size(struct mmu_gather *tlb,
+   struct page *page, int page_size)
+{
+   return tlb_remove_page(tlb, page);
+}
+
 #define pte_free_tlb(tlb, ptep, addr)  pte_free((tlb)->mm, ptep)
 #define pmd_free_tlb(tlb, pmdp, addr)  pmd_free((tlb)->mm, pmdp)
 #define pud_free_tlb(tlb, pudp, addr)  pud_free((tlb)->mm, pudp)
diff --git a/arch/um/include/asm/tlb.h b/arch/um/include/asm/tlb.h
index c6638f8e5e90..821ff0acfe17 100644
--- a/arch/um/include/asm/tlb.h
+++ b/arch/um/include/asm/tlb.h
@@ -110,6 +110,24 @@ static inline void tlb_remove_page(struct

[PATCH v2 2/3] mm: Change the interface for __tlb_remove_page

2016-06-03 Thread Aneesh Kumar K.V 
This update the generic and arch specific implementation to return true
if we need to do a tlb flush. That means if a __tlb_remove_page indicate
a flush is needed, the page we try to remove need to be tracked and
added again after the flush. We need to track it because we have already
update the pte to none and we can't just loop back.

This changes is done to enable us to do a tlb_flush when we try to flush
a range that consists of different page sizes. For architectures like
ppc64, we can do a range based tlb flush and we need to track page size
for that. When we try to remove a huge page, we will force a tlb flush
and starts a new mmu gather.

Signed-off-by: Aneesh Kumar K.V 
---
changes from V1:
* Fix build error

 arch/arm/include/asm/tlb.h  | 11 +++
 arch/ia64/include/asm/tlb.h | 13 -
 arch/s390/include/asm/tlb.h |  4 ++--
 arch/sh/include/asm/tlb.h   |  2 +-
 arch/um/include/asm/tlb.h   |  2 +-
 include/asm-generic/tlb.h   | 36 +---
 mm/memory.c | 20 ++--
 7 files changed, 58 insertions(+), 30 deletions(-)

diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 3cadb726ec88..45dea952b0e6 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -209,17 +209,20 @@ tlb_end_vma(struct mmu_gather *tlb, struct vm_area_struct 
*vma)
tlb_flush(tlb);
 }
 
-static inline int __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
+static inline bool __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
 {
+   if (tlb->nr == tlb->max)
+   return true;
tlb->pages[tlb->nr++] = page;
-   VM_BUG_ON(tlb->nr > tlb->max);
-   return tlb->max - tlb->nr;
+   return false;
 }
 
 static inline void tlb_remove_page(struct mmu_gather *tlb, struct page *page)
 {
-   if (!__tlb_remove_page(tlb, page))
+   if (__tlb_remove_page(tlb, page)) {
tlb_flush_mmu(tlb);
+   __tlb_remove_page(tlb, page);
+   }
 }
 
 static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t pte,
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index 39d64e0df1de..85005ab513e9 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -205,17 +205,18 @@ tlb_finish_mmu(struct mmu_gather *tlb, unsigned long 
start, unsigned long end)
  * must be delayed until after the TLB has been flushed (see comments at the 
beginning of
  * this file).
  */
-static inline int __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
+static inline bool __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
 {
+   if (tlb->nr == tlb->max)
+   return true;
+
tlb->need_flush = 1;
 
if (!tlb->nr && tlb->pages == tlb->local)
__tlb_alloc_page(tlb);
 
tlb->pages[tlb->nr++] = page;
-   VM_BUG_ON(tlb->nr > tlb->max);
-
-   return tlb->max - tlb->nr;
+   return false;
 }
 
 static inline void tlb_flush_mmu_tlbonly(struct mmu_gather *tlb)
@@ -235,8 +236,10 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
 
 static inline void tlb_remove_page(struct mmu_gather *tlb, struct page *page)
 {
-   if (!__tlb_remove_page(tlb, page))
+   if (__tlb_remove_page(tlb, page)) {
tlb_flush_mmu(tlb);
+   __tlb_remove_page(tlb, page);
+   }
 }
 
 /*
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index 7a92e69c50bc..6b98cb3601d5 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -87,10 +87,10 @@ static inline void tlb_finish_mmu(struct mmu_gather *tlb,
  * tlb_ptep_clear_flush. In both flush modes the tlb for a page cache page
  * has already been freed, so just do free_page_and_swap_cache.
  */
-static inline int __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
+static inline bool __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
 {
free_page_and_swap_cache(page);
-   return 1; /* avoid calling tlb_flush_mmu */
+   return false; /* avoid calling tlb_flush_mmu */
 }
 
 static inline void tlb_remove_page(struct mmu_gather *tlb, struct page *page)
diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index 62f80d2a9df9..3dec5e0734f5 100644
--- a/arch/sh/include/asm/tlb.h
+++ b/arch/sh/include/asm/tlb.h
@@ -101,7 +101,7 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
 static inline int __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
 {
free_page_and_swap_cache(page);
-   return 1; /* avoid calling tlb_flush_mmu */
+   return false; /* avoid calling tlb_flush_mmu */
 }
 
 static inline void tlb_remove_page(struct mmu_gather *tlb, struct page *page)
diff --git a/arch/um/include/asm/tlb.h b/arch/um/include/asm/tlb.h
index 16eb63fac57d..c6638f8e5e90 100644
--- a/arch/um/include/asm/tlb.h
+++ b/arch/um/include/asm/tlb.h
@@ -102,7

Re: [RFC v3 22/45] powerpc: dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Krzysztof Kozlowski 
On 06/03/2016 01:56 PM, Michael Ellerman wrote:
> On Thu, 2016-06-02 at 17:39 +0200, Krzysztof Kozlowski wrote:
> 
>> diff --git a/arch/powerpc/platforms/cell/iommu.c 
>> b/arch/powerpc/platforms/cell/iommu.c
>> index 0c2794d2b6c0..5d1a7ef3fdee 100644
>> --- a/arch/powerpc/platforms/cell/iommu.c
>> +++ b/arch/powerpc/platforms/cell/iommu.c
>> @@ -166,7 +166,7 @@ static void invalidate_tce_cache(struct cbe_iommu 
>> *iommu, unsigned long *pte,
>>  
>>  static int tce_build_cell(struct iommu_table *tbl, long index, long npages,
>>  unsigned long uaddr, enum dma_data_direction direction,
>> -struct dma_attrs *attrs)
>> +unsigned long attrs)
>>  {
>>  int i;
>>  unsigned long *io_pte, base_pte;
> 
> You missed the call site:

Right, thanks!

Best regards,
Krzysztof

> diff --git a/arch/powerpc/platforms/cell/iommu.c 
> b/arch/powerpc/platforms/cell/iommu.c
> index 2018e562d124..6128bdb428b2 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -526,7 +526,7 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct 
> device_node *np,
>  
>   __set_bit(0, window->table.it_map);
>   tce_build_cell(>table, window->table.it_offset, 1,
> -(unsigned long)iommu->pad_page, DMA_TO_DEVICE, NULL);
> +(unsigned long)iommu->pad_page, DMA_TO_DEVICE, 0);
>  
>   return window;
>  }
> 
> 
> cheers
> 
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[GIT PULL] Please pull powerpc/linux.git powerpc-4.7-2 tag

2016-06-03 Thread Michael Ellerman 
Hi Linus,

Please pull the first batch of powerpc fixes for 4.7:

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.7-2

for you to fetch changes up to 7cc851039d643a2ee7df4d18177150f2c3a484f5:

  powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support 
call (2016-06-01 13:47:34 +1000)


powerpc fixes for 4.7

 - Handle RTAS delay requests in configure_bridge from Russell Currey
 - Refactor the configure_bridge RTAS tokens from Russell Currey
 - Fix definition of SIAR and SDAR registers from Thomas Huth
 - Use privileged SPR number for MMCR2 from Thomas Huth
 - Update LPCR only if it is powernv from Aneesh Kumar K.V
 - Fix the reference bit update when handling hash fault from Aneesh Kumar K.V
 - Add missing tlb flush from Aneesh Kumar K.V
 - Add POWER8NVL support to ibm,client-architecture-support call from Thomas 
Huth


Aneesh Kumar K.V (3):
  powerpc/mm/radix: Update LPCR only if it is powernv
  powerpc/mm/hash: Fix the reference bit update when handling hash fault
  powerpc/mm/radix: Add missing tlb flush

Russell Currey (2):
  powerpc/pseries/eeh: Handle RTAS delay requests in configure_bridge
  powerpc/pseries/eeh: Refactor the configure_bridge RTAS tokens

Thomas Huth (3):
  powerpc: Fix definition of SIAR and SDAR registers
  powerpc: Use privileged SPR number for MMCR2
  powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support 
call

 arch/powerpc/include/asm/reg.h   |  6 ++--
 arch/powerpc/kernel/prom_init.c  |  1 +
 arch/powerpc/mm/hash_utils_64.c  | 22 +++--
 arch/powerpc/mm/pgtable-book3s64.c   |  5 +--
 arch/powerpc/mm/pgtable-radix.c  | 23 ++---
 arch/powerpc/platforms/pseries/eeh_pseries.c | 49 +++-
 6 files changed, 68 insertions(+), 38 deletions(-)


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v3 22/45] powerpc: dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Michael Ellerman 
On Thu, 2016-06-02 at 17:39 +0200, Krzysztof Kozlowski wrote:

> diff --git a/arch/powerpc/platforms/cell/iommu.c 
> b/arch/powerpc/platforms/cell/iommu.c
> index 0c2794d2b6c0..5d1a7ef3fdee 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -166,7 +166,7 @@ static void invalidate_tce_cache(struct cbe_iommu *iommu, 
> unsigned long *pte,
>  
>  static int tce_build_cell(struct iommu_table *tbl, long index, long npages,
>   unsigned long uaddr, enum dma_data_direction direction,
> - struct dma_attrs *attrs)
> + unsigned long attrs)
>  {
>   int i;
>   unsigned long *io_pte, base_pte;

You missed the call site:

diff --git a/arch/powerpc/platforms/cell/iommu.c 
b/arch/powerpc/platforms/cell/iommu.c
index 2018e562d124..6128bdb428b2 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -526,7 +526,7 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct 
device_node *np,
 
__set_bit(0, window->table.it_map);
tce_build_cell(>table, window->table.it_offset, 1,
-  (unsigned long)iommu->pad_page, DMA_TO_DEVICE, NULL);
+  (unsigned long)iommu->pad_page, DMA_TO_DEVICE, 0);
 
return window;
 }


cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc/nvram: Fix an incorrect partition merge

2016-06-03 Thread Michael Ellerman 
On Thu, 2015-10-12 at 07:30:02 UTC, xinhui wrote:
> From: Pan Xinhui 
> 
> When we merge two contiguous partitions whose signatures are marked
> NVRAM_SIG_FREE, We need update prev's length and checksum, then write it
> to nvram, not cur's. So lets fix this mistake now.
> 
> Also use memset instead of strncpy to set the partition's name. It's
> more readable if we want to fill up with duplicate chars .

Does this ever happen in practice? ie. should we backport the fix to stable
kernels?

Has it always been broken?

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/7] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042

2016-06-03 Thread Jia Hongtao 
SoC compatible string and endianness property are added according to the
new bindings.

Signed-off-by: Jia Hongtao 
---
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 507649e..089eb56 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -526,7 +526,7 @@
 
   0x0003 0x0012
   0x00030001 0x001d>;
-   #thermal-sensor-cells = <0>;
+   #thermal-sensor-cells = <1>;
};
 
thermal-zones {
@@ -534,7 +534,7 @@
polling-delay-passive = <1000>;
polling-delay = <5000>;
 
-   thermal-sensors = <>;
+   thermal-sensors = < 2>;
 
trips {
cpu_alert: cpu-alert {
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v3 10/45] cris: dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Jesper Nilsson 
On Thu, Jun 02, 2016 at 05:39:12PM +0200, Krzysztof Kozlowski wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.

Acked-by: Jesper Nilsson 

> Signed-off-by: Krzysztof Kozlowski 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v3 01/45] powerpc: dma-mapping: Don't hard-code the value of DMA_ATTR_WEAK_ORDERING

2016-06-03 Thread Krzysztof Kozlowski 
On 06/02/2016 05:39 PM, Krzysztof Kozlowski wrote:
> Hard-coded value of DMA_ATTR_WEAK_ORDERING is then compared with the
> symbol.  This will stop matching if the value of symbol is changed (when
> switching DMA attributes to unsigned long).
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/powerpc/platforms/cell/iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/cell/iommu.c 
> b/arch/powerpc/platforms/cell/iommu.c
> index 14a582b21274..0c2794d2b6c0 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -1162,7 +1162,7 @@ static int __init setup_iommu_fixed(char *str)
>   pciep = of_find_node_by_type(NULL, "pcie-endpoint");
>  
>   if (strcmp(str, "weak") == 0 || (pciep && strcmp(str, "strong") != 0))
> - iommu_fixed_is_weak = 1;
> + iommu_fixed_is_weak = DMA_ATTR_WEAK_ORDERING;

After some more thoughts given to this, I think my fix is not correct.
The 'iommu_fixed_is_weak' stores the bool and it is used to compare with
result of test_bit().

Please ignore this patch.

Best regards,
Krzysztof
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v3 02/45] dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Krzysztof Kozlowski 
On 06/03/2016 09:17 AM, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Thu, Jun 2, 2016 at 5:39 PM, Krzysztof Kozlowski
>  wrote:
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -5,13 +5,25 @@
> 
>> +/**
>> + * List of possible attributes associated with a DMA mapping. The semantics
>> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
>> + */
>> +#define DMA_ATTR_WRITE_BARRIER (1UL << 1)
> 
> Any particular reason they start at 2, not 1?

No reason. I'll fix this in next version (and trim Cc-list). Anyway the
values of constants won't match old ones but that should not be problem
(unless they are hard-coded somewhere).

Best regards,
Krzysztof


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v3 29/45] m68k: dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Geert Uytterhoeven 
On Thu, Jun 2, 2016 at 5:39 PM, Krzysztof Kozlowski
 wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.
>
> Signed-off-by: Krzysztof Kozlowski 

Looks good.

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v3 02/45] dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Geert Uytterhoeven 
Hi Krzysztof,

On Thu, Jun 2, 2016 at 5:39 PM, Krzysztof Kozlowski
 wrote:
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -5,13 +5,25 @@

> +/**
> + * List of possible attributes associated with a DMA mapping. The semantics
> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
> + */
> +#define DMA_ATTR_WRITE_BARRIER (1UL << 1)

Any particular reason they start at 2, not 1?

> +#define DMA_ATTR_WEAK_ORDERING (1UL << 2)
> +#define DMA_ATTR_WRITE_COMBINE (1UL << 3)
> +#define DMA_ATTR_NON_CONSISTENT(1UL << 4)
> +#define DMA_ATTR_NO_KERNEL_MAPPING (1UL << 5)
> +#define DMA_ATTR_SKIP_CPU_SYNC (1UL << 6)
> +#define DMA_ATTR_FORCE_CONTIGUOUS  (1UL << 7)
> +#define DMA_ATTR_ALLOC_SINGLE_PAGES(1UL << 8)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 5/7] arm64:dt:ls1043a: Add TMU device tree support for LS1043A

2016-06-03 Thread Jia Hongtao 
Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 78 +++
 3 files changed, 80 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index 9d3e9fe..fa447b6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -45,7 +45,7 @@
  */
 
 /dts-v1/;
-/include/ "fsl-ls1043a.dtsi"
+#include "fsl-ls1043a.dtsi"
 
 / {
model = "LS1043A QDS Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index f895fc0..6015d88 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -45,7 +45,7 @@
  */
 
 /dts-v1/;
-/include/ "fsl-ls1043a.dtsi"
+#include "fsl-ls1043a.dtsi"
 
 / {
model = "LS1043A RDB Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index de0323b..4004273 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -44,6 +44,8 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
+
 / {
compatible = "fsl,ls1043a";
interrupt-parent = <>;
@@ -65,6 +67,7 @@
compatible = "arm,cortex-a53";
reg = <0x0 0x0>;
clocks = < 1 0>;
+   #cooling-cells = <2>;
};
 
cpu1: cpu@1 {
@@ -196,6 +199,81 @@
bus-width = <4>;
};
 
+   tmu: tmu@1f0 {
+   compatible = "fsl,qoriq-tmu";
+   reg = <0x0 0x1f0 0x0 0x1>;
+   interrupts = <0 33 0x4>;
+   fsl,tmu-range = <0xb 0x9002a 0x6004c 0x30062>;
+   fsl,tmu-calibration = <0x 0x0026
+  0x0001 0x002d
+  0x0002 0x0032
+  0x0003 0x0039
+  0x0004 0x003f
+  0x0005 0x0046
+  0x0006 0x004d
+  0x0007 0x0054
+  0x0008 0x005a
+  0x0009 0x0061
+  0x000a 0x006a
+  0x000b 0x0071
+
+  0x0001 0x0025
+  0x00010001 0x002c
+  0x00010002 0x0035
+  0x00010003 0x003d
+  0x00010004 0x0045
+  0x00010005 0x004e
+  0x00010006 0x0057
+  0x00010007 0x0061
+  0x00010008 0x006b
+  0x00010009 0x0076
+
+  0x0002 0x0029
+  0x00020001 0x0033
+  0x00020002 0x003d
+  0x00020003 0x0049
+  0x00020004 0x0056
+  0x00020005 0x0061
+  0x00020006 0x006d
+
+  0x0003 0x0021
+  0x00030001 0x002a
+  0x00030002 0x003c
+  0x00030003 0x004e>;
+   #thermal-sensor-cells = <1>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+
+   thermal-sensors = < 3>;
+
+   trips {
+   cpu_alert: cpu-alert {
+   temperature = <85000>;
+

[PATCH 7/7] thermal: qoriq: Add thermal management support

2016-06-03 Thread Jia Hongtao 
This driver add thermal management support by enabling TMU (Thermal
Monitoring Unit) on QorIQ platform.

It's based on thermal of framework:
- Trip points defined in device tree.
- Cpufreq as cooling device registered in qoriq cpufreq driver.

Signed-off-by: Jia Hongtao 
---
 drivers/thermal/Kconfig |   9 ++
 drivers/thermal/Makefile|   1 +
 drivers/thermal/qoriq_thermal.c | 328 
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/thermal/qoriq_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..bef26cd 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -195,6 +195,15 @@ config IMX_THERMAL
  cpufreq is used as the cooling device to throttle CPUs when the
  passive trip is crossed.
 
+config QORIQ_THERMAL
+   tristate "QorIQ Thermal Monitoring Unit"
+   depends on THERMAL_OF
+   help
+ Support for Thermal Monitoring Unit (TMU) found on QorIQ platforms.
+ It supports one critical trip point and one passive trip point. The
+ cpufreq is used as the cooling device to throttle CPUs when the
+ passive trip is crossed.
+
 config SPEAR_THERMAL
tristate "SPEAr thermal sensor driver"
depends on PLAT_SPEAR || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..6662232 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_DB8500_THERMAL)  += db8500_thermal.o
 obj-$(CONFIG_ARMADA_THERMAL)   += armada_thermal.o
 obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
 obj-$(CONFIG_IMX_THERMAL)  += imx_thermal.o
+obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
 obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   += db8500_cpufreq_cooling.o
 obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
new file mode 100644
index 000..644ba52
--- /dev/null
+++ b/drivers/thermal/qoriq_thermal.c
@@ -0,0 +1,328 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "thermal_core.h"
+
+#define SITES_MAX  16
+
+/*
+ * QorIQ TMU Registers
+ */
+struct qoriq_tmu_site_regs {
+   u32 tritsr; /* Immediate Temperature Site Register */
+   u32 tratsr; /* Average Temperature Site Register */
+   u8 res0[0x8];
+};
+
+struct qoriq_tmu_regs {
+   u32 tmr;/* Mode Register */
+#define TMR_DISABLE0x0
+#define TMR_ME 0x8000
+#define TMR_ALPF   0x0c00
+   u32 tsr;/* Status Register */
+   u32 tmtmir; /* Temperature measurement interval Register */
+#define TMTMIR_DEFAULT 0x000f
+   u8 res0[0x14];
+   u32 tier;   /* Interrupt Enable Register */
+#define TIER_DISABLE   0x0
+   u32 tidr;   /* Interrupt Detect Register */
+   u32 tiscr;  /* Interrupt Site Capture Register */
+   u32 ticscr; /* Interrupt Critical Site Capture Register */
+   u8 res1[0x10];
+   u32 tmhtcrh;/* High Temperature Capture Register */
+   u32 tmhtcrl;/* Low Temperature Capture Register */
+   u8 res2[0x8];
+   u32 tmhtitr;/* High Temperature Immediate Threshold */
+   u32 tmhtatr;/* High Temperature Average Threshold */
+   u32 tmhtactr;   /* High Temperature Average Crit Threshold */
+   u8 res3[0x24];
+   u32 ttcfgr; /* Temperature Configuration Register */
+   u32 tscfgr; /* Sensor Configuration Register */
+   u8 res4[0x78];
+   struct qoriq_tmu_site_regs site[SITES_MAX];
+   u8 res5[0x9f8];
+   u32 ipbrr0; /* IP Block Revision Register 0 */
+   u32 ipbrr1; /* IP Block Revision Register 1 */
+   u8 res6[0x310];
+   u32 ttr0cr; /* Temperature Range 0 Control Register */
+   u32 ttr1cr; /* Temperature Range 1 Control Register */
+   u32 ttr2cr; /* Temperature Range 2 Control Register */
+   u32 ttr3cr; /* Temperature Range 3 Control Register */
+};
+
+/*
+ * Thermal zone data
+ */
+struct qoriq_tmu_data {
+   struct thermal_zone_device *tz;
+   struct qoriq_tmu_regs __iomem

[PATCH 6/7] arm64:dt:ls2080a: Add TMU device tree support for LS2080A

2016-06-03 Thread Jia Hongtao 
Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao 
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts  |   2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts  |   2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts |   2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 116 +++--
 4 files changed, 111 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
index e8801fa..18e99f4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
@@ -46,7 +46,7 @@
 
 /dts-v1/;
 
-/include/ "fsl-ls2080a.dtsi"
+#include "fsl-ls2080a.dtsi"
 
 / {
model = "Freescale Layerscape 2080a QDS Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
index e127f0b..f1c8115 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
@@ -46,7 +46,7 @@
 
 /dts-v1/;
 
-/include/ "fsl-ls2080a.dtsi"
+#include "fsl-ls2080a.dtsi"
 
 / {
model = "Freescale Layerscape 2080a RDB Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
index 505d038..290604b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
@@ -46,7 +46,7 @@
 
 /dts-v1/;
 
-/include/ "fsl-ls2080a.dtsi"
+#include "fsl-ls2080a.dtsi"
 
 / {
model = "Freescale Layerscape 2080a software Simulator model";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 3187c82..5cc27df 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -44,6 +44,8 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
+
 / {
compatible = "fsl,ls2080a";
interrupt-parent = <>;
@@ -62,56 +64,60 @@
 */
 
/* We have 4 clusters having 2 Cortex-A57 cores each */
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
clocks = < 1 0>;
+   #cooling-cells = <2>;
};
 
-   cpu@1 {
+   cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
clocks = < 1 0>;
};
 
-   cpu@100 {
+   cpu2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
clocks = < 1 1>;
+   #cooling-cells = <2>;
};
 
-   cpu@101 {
+   cpu3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
clocks = < 1 1>;
};
 
-   cpu@200 {
+   cpu4: cpu@200 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x200>;
clocks = < 1 2>;
+   #cooling-cells = <2>;
};
 
-   cpu@201 {
+   cpu5: cpu@201 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x201>;
clocks = < 1 2>;
};
 
-   cpu@300 {
+   cpu6: cpu@300 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x300>;
clocks = < 1 3>;
+   #cooling-cells = <2>;
};
 
-   cpu@301 {
+   cpu7: cpu@301 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x301>;
@@ -191,6 +197,100 @@
clocks = <>;
};
 
+   tmu: tmu@1f8 {
+   compatible = "fsl,qoriq-tmu";
+   reg = <0x0 0x1f8 0x0 0x1>;
+   interrupts = <0 23 0x4>;
+   fsl,tmu-range = <0xb 0x9002a 0x6004c 0x30062>;
+   fsl,tmu-calibration = <0x 0x0026
+  0x0001 0x002d
+  0x0002 0x0032
+

[PATCH 3/7] powerpc/mpc85xx: Update TMU device tree node for T1023/T1024

2016-06-03 Thread Jia Hongtao 
SoC compatible string and endianness property are added according to the
new bindings.

Signed-off-by: Jia Hongtao 
---
 arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index 6e0b489..bce762a 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -321,7 +321,7 @@
   0x00030001 0x000d
   0x00030002 0x0019
   0x00030003 0x0024>;
-   #thermal-sensor-cells = <0>;
+   #thermal-sensor-cells = <1>;
};
 
thermal-zones {
@@ -329,7 +329,7 @@
polling-delay-passive = <1000>;
polling-delay = <5000>;
 
-   thermal-sensors = <>;
+   thermal-sensors = < 0>;
 
trips {
cpu_alert: cpu-alert {
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/7] dt-bindings: Update QorIQ TMU thermal bindings

2016-06-03 Thread Jia Hongtao 
For different types of SoC the sensor id and endianness may vary.
"#thermal-sensor-cells" is used to provide sensor id information.
"little-endian" property is to tell the endianness of TMU.

Signed-off-by: Jia Hongtao 
---
 .../devicetree/bindings/thermal/qoriq-thermal.txt | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt 
b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
index 66223d5..8eeef80 100644
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
@@ -1,22 +1,28 @@
 * Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
 
 Required properties:
-- compatible : Must include "fsl,qoriq-tmu". The version of the device is
+- compatible: Must include "fsl,qoriq-tmu". The version of the device is
determined by the TMU IP Block Revision Register (IPBRR0) at
offset 0x0BF8.
-   Table of correspondences between IPBRR0 values and example  chips:
+   Table of correspondences between IPBRR0 values and example chips:
Value   Device
--  -
0x01900102  T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
+- reg: Address range of TMU registers.
+- interrupts: Contains the interrupt for TMU.
+- fsl,tmu-range: The values to be programmed into TTRnCR, as specified by
the SoC reference manual. The first cell is TTR0CR, the second is
TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
+- fsl,tmu-calibration: A list of cell pairs containing temperature
calibration data, as specified by the SoC reference manual.
The first cell of each pair is the value to be written to TTCFGR,
and the second is the value to be written to TSCFGR.
+- #thermal-sensor-cells: Must be 1. The sensor specifier is the monitoring
+   site ID, and represents the "n" in TRITSRn and TRATSRn.
+
+Optional property:
+- little-endian: If present, the TMU registers are little endian.  If absent,
+   the default is big endian.
 
 Example:
 
@@ -60,4 +66,5 @@ tmu@f {
 
   0x0003 0x0012
   0x00030001 0x001d>;
+   #thermal-sensor-cells = <1>;
 };
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 4/7] arm:dt:ls1021a: Add TMU device tree support for LS1021A

2016-06-03 Thread Jia Hongtao 
Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao 
---
 arch/arm/boot/dts/ls1021a.dtsi | 84 +-
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 5ae8e92..1bac9d8 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -47,6 +47,7 @@
 
 #include "skeleton64.dtsi"
 #include 
+#include 
 
 / {
compatible = "fsl,ls1021a";
@@ -70,14 +71,15 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@f00 {
+   cpu0: cpu@f00 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0xf00>;
clocks = <_clk>;
+   #cooling-cells = <2>;
};
 
-   cpu@f01 {
+   cpu1: cpu@f01 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0xf01>;
@@ -251,6 +253,84 @@
};
};
 
+   tmu: tmu@1f0 {
+   compatible = "fsl,qoriq-tmu";
+   reg = <0x0 0x1f0 0x0 0x1>;
+   interrupts = ;
+   fsl,tmu-range = <0xb 0xa0026 0x80048 0x30061>;
+   fsl,tmu-calibration = <0x 0x000f
+  0x0001 0x0017
+  0x0002 0x001e
+  0x0003 0x0026
+  0x0004 0x002e
+  0x0005 0x0035
+  0x0006 0x003d
+  0x0007 0x0044
+  0x0008 0x004c
+  0x0009 0x0053
+  0x000a 0x005b
+  0x000b 0x0064
+
+  0x0001 0x0011
+  0x00010001 0x001c
+  0x00010002 0x0024
+  0x00010003 0x002b
+  0x00010004 0x0034
+  0x00010005 0x0039
+  0x00010006 0x0042
+  0x00010007 0x004c
+  0x00010008 0x0051
+  0x00010009 0x005a
+  0x0001000a 0x0063
+
+  0x0002 0x0013
+  0x00020001 0x0019
+  0x00020002 0x0024
+  0x00020003 0x002c
+  0x00020004 0x0035
+  0x00020005 0x003d
+  0x00020006 0x0046
+  0x00020007 0x0050
+  0x00020008 0x0059
+
+  0x0003 0x0002
+  0x00030001 0x000d
+  0x00030002 0x0019
+  0x00030003 0x0024>;
+   #thermal-sensor-cells = <1>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+
+   thermal-sensors = < 0>;
+
+   trips {
+   cpu_alert: cpu-alert {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+   cpu_crit: cpu-crit {
+   temperature = <95000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+

Re: [PATCH v5 1/6] qspinlock: powerpc support qspinlock

2016-06-03 Thread xinhui 



On 2016年06月03日 12:33, Benjamin Herrenschmidt wrote:

On Fri, 2016-06-03 at 12:10 +0800, xinhui wrote:

On 2016年06月03日 09:32, Benjamin Herrenschmidt wrote:

On Fri, 2016-06-03 at 11:32 +1000, Benjamin Herrenschmidt wrote:

On Thu, 2016-06-02 at 17:22 +0800, Pan Xinhui wrote:


Base code to enable qspinlock on powerpc. this patch add some
#ifdef
here and there. Although there is no paravirt related code, we

can

successfully build a qspinlock kernel after apply this patch.

This is missing the IO_SYNC stuff ... It means we'll fail to do a
full
sync to order vs MMIOs.

You need to add that back in the unlock path.


Well, and in the lock path as well...


Oh, yes. I missed IO_SYNC stuff.

thank you, Ben :)


Ok couple of other things that would be nice from my perspective (and
Michael's) if you can produce them:

  - Some benchmarks of the qspinlock alone, without the PV stuff,
so we understand how much of the overhead is inherent to the
qspinlock and how much is introduced by the PV bits.

  - For the above, can you show (or describe) where the qspinlock
improves things compared to our current locks. While there's
theory and to some extent practice on x86, it would be nice to
validate the effects on POWER.

  - Comparative benchmark with the PV stuff in on a bare metal system
to understand the overhead there.

  - Comparative benchmark with the PV stuff under pHyp and KVM


Will do such benchmark tests in next days.
thanks for your kind suggestions. :)


Spinlocks are fiddly and a critical piece of infrastructure, it's
important we fully understand the performance implications before we
decide to switch to a new model.


yes, We really need understand how {pv}qspinlock works in more complex cases.

thanks
xinhui

Cheers,
Ben.



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev