LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4] powernv: Dynamic Frequency Scaling Enablement
From: Gautham R. Shenoy @ 2014-03-26 16:55 UTC (permalink / raw)
  To: Viresh Kumar, benh
  Cc: Gautham R. Shenoy, Linux PM list, linuxppc-dev, Anton Blanchard,
	srivatsa.bhat

From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>

Hi,

This is the v4 of the patchset to enable Dynamic Frequency Scaling
on IBM PowerNV Platforms. I have incorporated the review comments
from the previous version (can be found at [1]). 

In this version, 

  * Multiple patches from the previous version have been into a single
    patch, since the higher numbered patches implemented some helper
    functions and the driver methods which should have been a part of
    the first patch to begin with.

  * Use the generic helpers provided by the cpufreq core available in
    the latest linux-next tree.

  * Fix the code to avoid casting integer pointers to void.

The patch is based on top of the commit:06ed26d1de59ce7cbbe68378b7e470be169750e5
of the linux-next tree.


[1]: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg76675.html

Vaidyanathan Srinivasan (1):
  powernv, cpufreq: cpufreq driver for powernv platform

 arch/powerpc/configs/pseries_defconfig    |   1 +
 arch/powerpc/configs/pseries_le_defconfig |   1 +
 arch/powerpc/include/asm/reg.h            |   4 +
 arch/powerpc/platforms/powernv/Kconfig    |   6 +
 drivers/cpufreq/Kconfig.powerpc           |   8 +
 drivers/cpufreq/Makefile                  |   1 +
 drivers/cpufreq/powernv-cpufreq.c         | 372 ++++++++++++++++++++++++++++++
 7 files changed, 393 insertions(+)
 create mode 100644 drivers/cpufreq/powernv-cpufreq.c

-- 
1.8.3.1

^ permalink raw reply

* [RFC PATCH] hugetlb: ensure hugepage access is denied if hugepages are not supported
From: Nishanth Aravamudan @ 2014-03-26 15:58 UTC (permalink / raw)
  To: linux-mm; +Cc: paulus, linuxppc-dev, anton, nyc
In-Reply-To: <20140324230256.GA18778@linux.vnet.ibm.com>

On 24.03.2014 [16:02:56 -0700], Nishanth Aravamudan wrote:
> In KVM guests on Power, if the guest is not backed by hugepages, we see
> the following in the guest:
> 
> AnonHugePages:         0 kB
> HugePages_Total:       0
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        0
> Hugepagesize:         64 kB
> 
> This seems like a configuration issue -- why is a hstate of 64k being
> registered?
> 
> I did some debugging and found that the following does trigger,
> mm/hugetlb.c::hugetlb_init():
> 
>         /* Some platform decide whether they support huge pages at boot
>          * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
>          * there is no such support
>          */
>         if (HPAGE_SHIFT == 0)
>                 return 0;
> 
> That check is only during init-time. So we don't support hugepages, but
> none of the hugetlb APIs actually check this condition (HPAGE_SHIFT ==
> 0), so /proc/meminfo above falsely indicates there is a valid hstate (at
> least one). But note that there is no /sys/kernel/mm/hugepages meaning
> no hstate was actually registered.
> 
> Further, it turns out that huge_page_order(default_hstate) is 0, so
> hugetlb_report_meminfo is doing:
> 
> 1UL << (huge_page_order(h) + PAGE_SHIFT - 10)
> 
> which ends up just doing 1 << (PAGE_SHIFT - 10) and since the base page
> size is 64k, we report a hugepage size of 64k... And allow the user to
> allocate hugepages via the sysctl, etc.
> 
> What's the right thing to do here?
> 
> 1) Should we add checks for HPAGE_SHIFT == 0 to all the hugetlb APIs? It
> seems like HPAGE_SHIFT == 0 should be the equivalent, functionally, of
> the config options being off. This seems like a lot of overhead, though,
> to put everywhere, so maybe I can do it in an arch-specific macro, that
> in asm-generic defaults to 0 (and so will hopefully be compiled out?).
> 
> 2) What should hugetlbfs do when HPAGE_SHIFT == 0? Should it be
> mountable? Obviously if it's mountable, we can't great files there
> (since the fs will report insufficient space). [1]

Here is my solution to this. Comments appreciated!

In KVM guests on Power, in a guest not backed by hugepages, we see the
following:

AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:         64 kB

HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
are not supported at boot-time, but this is only checked in
hugetlb_init(). Extract the check to a helper function, and use it in a
few relevant places.

This does make hugetlbfs not supported in this environment. I believe
this is fine, as there are no valid hugepages and that won't change at
runtime.

Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index d19b30a..c7aa477 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1017,6 +1017,11 @@ static int __init init_hugetlbfs_fs(void)
 	int error;
 	int i;
 
+	if (!hugepages_supported()) {
+		printk(KERN_ERR "hugetlbfs: Disabling because there are no supported page sizes\n");
+		return -ENOTSUPP;
+	}
+
 	error = bdi_init(&hugetlbfs_backing_dev_info);
 	if (error)
 		return error;
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8c43cc4..0aea8de 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -450,4 +450,14 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
 	return ptl;
 }
 
+static inline bool hugepages_supported(void)
+{
+	/*
+	 * Some platform decide whether they support huge pages at boot
+	 * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
+	 * there is no such support
+	 */
+	return HPAGE_SHIFT != 0;
+}
+
 #endif /* _LINUX_HUGETLB_H */
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c01cb9f..1c99585 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1949,11 +1949,7 @@ module_exit(hugetlb_exit);
 
 static int __init hugetlb_init(void)
 {
-	/* Some platform decide whether they support huge pages at boot
-	 * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
-	 * there is no such support
-	 */
-	if (HPAGE_SHIFT == 0)
+	if (!hugepages_supported())
 		return 0;
 
 	if (!size_to_hstate(default_hstate_size)) {
@@ -2069,6 +2065,9 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
 	unsigned long tmp;
 	int ret;
 
+	if (!hugepages_supported())
+		return -ENOTSUPP;
+
 	tmp = h->max_huge_pages;
 
 	if (write && h->order >= MAX_ORDER)
@@ -2122,6 +2121,9 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
 	unsigned long tmp;
 	int ret;
 
+	if (!hugepages_supported())
+		return -ENOTSUPP;
+
 	tmp = h->nr_overcommit_huge_pages;
 
 	if (write && h->order >= MAX_ORDER)
@@ -2147,6 +2149,8 @@ out:
 void hugetlb_report_meminfo(struct seq_file *m)
 {
 	struct hstate *h = &default_hstate;
+	if (!hugepages_supported())
+		return;
 	seq_printf(m,
 			"HugePages_Total:   %5lu\n"
 			"HugePages_Free:    %5lu\n"
@@ -2163,6 +2167,8 @@ void hugetlb_report_meminfo(struct seq_file *m)
 int hugetlb_report_node_meminfo(int nid, char *buf)
 {
 	struct hstate *h = &default_hstate;
+	if (!hugepages_supported())
+		return 0;
 	return sprintf(buf,
 		"Node %d HugePages_Total: %5u\n"
 		"Node %d HugePages_Free:  %5u\n"
@@ -2177,6 +2183,9 @@ void hugetlb_show_meminfo(void)
 	struct hstate *h;
 	int nid;
 
+	if (!hugepages_supported())
+		return;
+
 	for_each_node_state(nid, N_MEMORY)
 		for_each_hstate(h)
 			pr_info("Node %d hugepages_total=%u hugepages_free=%u hugepages_surp=%u hugepages_size=%lukB\n",

^ permalink raw reply related

* [PATCH] bootmem/powerpc: Unify bootmem initialization
From: Emil Medve @ 2014-03-26 13:52 UTC (permalink / raw)
  To: benh, paulus, linuxppc-dev; +Cc: Emil Medve

Unify the low/highmem code path from do_init_bootmem() by using (the)
lowmem related variables/parameters even when the low/highmem split
is not needed (64-bit) or configured. In such cases the "lowmem"
variables/parameters continue to observe the definition by referring
to memory directly mapped by the kernel

Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
 arch/powerpc/mm/mem.c | 36 ++++++++++++++++--------------------
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 32202c9..807a950 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -188,27 +188,31 @@ EXPORT_SYMBOL_GPL(walk_system_ram_range);
 void __init do_init_bootmem(void)
 {
 	unsigned long start, bootmap_pages;
-	unsigned long total_pages;
 	struct memblock_region *reg;
 	int boot_mapsize;
+	phys_addr_t _total_lowmem;
+	phys_addr_t _lowmem_end_addr;
 
-	max_low_pfn = max_pfn = memblock_end_of_DRAM() >> PAGE_SHIFT;
-	total_pages = (memblock_end_of_DRAM() - memstart_addr) >> PAGE_SHIFT;
-#ifdef CONFIG_HIGHMEM
-	total_pages = total_lowmem >> PAGE_SHIFT;
-	max_low_pfn = lowmem_end_addr >> PAGE_SHIFT;
+#ifndef CONFIG_HIGHMEM
+	_lowmem_end_addr = memblock_end_of_DRAM();
+#else
+	_lowmem_end_addr = lowmem_end_addr;
 #endif
+	_total_lowmem = _lowmem_end_addr - memstart_addr;
+
+	max_pfn = memblock_end_of_DRAM() >> PAGE_SHIFT;
+	max_low_pfn = _lowmem_end_addr >> PAGE_SHIFT;
+	min_low_pfn = MEMORY_START >> PAGE_SHIFT;
 
 	/*
 	 * Find an area to use for the bootmem bitmap.  Calculate the size of
 	 * bitmap required as (Total Memory) / PAGE_SIZE / BITS_PER_BYTE.
 	 * Add 1 additional page in case the address isn't page-aligned.
 	 */
-	bootmap_pages = bootmem_bootmap_pages(total_pages);
+	bootmap_pages = bootmem_bootmap_pages(_total_lowmem >> PAGE_SHIFT);
 
 	start = memblock_alloc(bootmap_pages << PAGE_SHIFT, PAGE_SIZE);
 
-	min_low_pfn = MEMORY_START >> PAGE_SHIFT;
 	boot_mapsize = init_bootmem_node(NODE_DATA(0), start >> PAGE_SHIFT, min_low_pfn, max_low_pfn);
 
 	/* Place all memblock_regions in the same node and merge contiguous
@@ -219,26 +223,18 @@ void __init do_init_bootmem(void)
 	/* Add all physical memory to the bootmem map, mark each area
 	 * present.
 	 */
-#ifdef CONFIG_HIGHMEM
-	free_bootmem_with_active_regions(0, lowmem_end_addr >> PAGE_SHIFT);
+	free_bootmem_with_active_regions(0, max_low_pfn);
 
 	/* reserve the sections we're already using */
 	for_each_memblock(reserved, reg) {
-		unsigned long top = reg->base + reg->size - 1;
-		if (top < lowmem_end_addr)
+		if (reg->base + reg->size - 1 < _lowmem_end_addr)
 			reserve_bootmem(reg->base, reg->size, BOOTMEM_DEFAULT);
-		else if (reg->base < lowmem_end_addr) {
-			unsigned long trunc_size = lowmem_end_addr - reg->base;
+		else if (reg->base < _lowmem_end_addr) {
+			unsigned long trunc_size = _lowmem_end_addr - reg->base;
 			reserve_bootmem(reg->base, trunc_size, BOOTMEM_DEFAULT);
 		}
 	}
-#else
-	free_bootmem_with_active_regions(0, max_pfn);
 
-	/* reserve the sections we're already using */
-	for_each_memblock(reserved, reg)
-		reserve_bootmem(reg->base, reg->size, BOOTMEM_DEFAULT);
-#endif
 	/* XXX need to clip this if using highmem? */
 	sparse_memory_present_with_active_regions(0);
 
-- 
1.9.1

^ permalink raw reply related

* Re: [PATCH v2] powerpc/powernv: Platform dump interface
From: Vasant Hegde @ 2014-03-26 14:14 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20140325165243.22c0109d@kryten>

On 03/25/2014 11:22 AM, Anton Blanchard wrote:
> Hi Vasant,
>
>> On 02/09/2014 02:50 AM, Anton Blanchard wrote:
>>>
>>> Hi Vasant,
>>>
>>>> +static void free_dump_sg_list(struct opal_sg_list *list)
>>>> +{
>>>> +	struct opal_sg_list *sg1;
>>>> +	while (list) {
>>>> +		sg1 = list->next;
>>>> +		kfree(list);
>>>> +		list = sg1;
>>>> +	}
>>>> +	list = NULL;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Build dump buffer scatter gather list
>>>> + */
>>>> +static struct opal_sg_list *dump_data_to_sglist(void)
>>>> +{
>>>> +	struct opal_sg_list *sg1, *list = NULL;
>>>> +	void *addr;
>>>> +	int64_t size;
>>>> +
>>>> +	addr = dump_record.buffer;
>>>> +	size = dump_record.size;
>>>> +
>>>> +	sg1 = kzalloc(PAGE_SIZE, GFP_KERNEL);
>>>> +	if (!sg1)
>>>> +		goto nomem;
>>>> +
>>>> +	list = sg1;
>>>> +	sg1->num_entries = 0;
>>>> +	while (size > 0) {
>>>> +		/* Translate virtual address to physical address
>>>> */
>>>> +		sg1->entry[sg1->num_entries].data =
>>>> +			(void *)(vmalloc_to_pfn(addr) <<
>>>> PAGE_SHIFT); +
>>>> +		if (size > PAGE_SIZE)
>>>> +			sg1->entry[sg1->num_entries].length =
>>>> PAGE_SIZE;
>>>> +		else
>>>> +			sg1->entry[sg1->num_entries].length =
>>>> size; +
>>>> +		sg1->num_entries++;
>>>> +		if (sg1->num_entries >= SG_ENTRIES_PER_NODE) {
>>>> +			sg1->next = kzalloc(PAGE_SIZE,
>>>> GFP_KERNEL);
>>>> +			if (!sg1->next)
>>>> +				goto nomem;
>>>> +
>>>> +			sg1 = sg1->next;
>>>> +			sg1->num_entries = 0;
>>>> +		}
>>>> +		addr += PAGE_SIZE;
>>>> +		size -= PAGE_SIZE;
>>>> +	}
>>>> +	return list;
>>>> +
>>>> +nomem:
>>>> +	pr_err("%s : Failed to allocate memory\n", __func__);
>>>> +	free_dump_sg_list(list);
>>>> +	return NULL;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Translate sg list address to absolute
>>>> + */
>>>> +static void sglist_to_phy_addr(struct opal_sg_list *list)
>>>> +{
>>>> +	struct opal_sg_list *sg, *next;
>>>> +
>>>> +	for (sg = list; sg; sg = next) {
>>>> +		next = sg->next;
>>>> +		/* Don't translate NULL pointer for last entry */
>>>> +		if (sg->next)
>>>> +			sg->next = (struct opal_sg_list
>>>> *)__pa(sg->next);
>>>> +		else
>>>> +			sg->next = NULL;
>>>> +
>>>> +		/* Convert num_entries to length */
>>>> +		sg->num_entries =
>>>> +			sg->num_entries * sizeof(struct
>>>> opal_sg_entry) + 16;
>>>> +	}
>>>> +}
>>>> +
>>>> +static void free_dump_data_buf(void)
>>>> +{
>>>> +	vfree(dump_record.buffer);
>>>> +	dump_record.size = 0;
>>>> +}
>>>
>>
>> Anton,
>>
>>> This looks identical to the code in opal-flash.c. Considering how
>>> complicated it is, can we put it somewhere common?
>>
>> Thanks for the review.. Will look into it next week.
>

Anton,

> This doesn't appear to have been fixed in the version that went into
> next.
>

Stewart rewrote dump interface.. That set of patch went into next, not my 
original patch..
Yes.. SG list separation is not yet done.. Never got a chance to look into this 
one.. Will try to
do it soon.

-Vasant

> Anton
>

^ permalink raw reply

* RE: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: David Laight @ 2014-03-26 11:59 UTC (permalink / raw)
  To: 'Nicolin Chen', broonie@kernel.org,
	Li.Xiubo@freescale.com
  Cc: alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <1395834517-16426-1-git-send-email-Guangyu.Chen@freescale.com>

RnJvbTogTmljb2xpbiBDaGVuDQo+IEl0J3MgcXVpdGUgY3JpY2lhbCB0byBjbGVhciBlcnJvciBm
bGFncyBiZWNhdXNlIFNBSSBtaWdodCBoYW5nIGlmIGdldHRpbmcNCj4gRklGTyB1bmRlcnJ1biBk
dXJpbmcgcGxheWJhY2sgKEkgaGF2ZW4ndCBjb25maXJtZWQgdGhlIHNhbWUgaXNzdWUgb24gUngN
Cj4gb3ZlcmZsb3cgdGhvdWdoKS4NCj4gDQo+IFNvIHRoaXMgcGF0Y2ggZW5hYmxlcyB0aG9zZSBp
cnEgYW5kIGFkZHMgaXNyKCkgdG8gY2xlYXIgdGhlIGZsYWdzIHNvIGFzIHRvDQo+IGtlZXAgcGxh
eWJhY2sgZW50aXJlbHkgc2FmZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IE5pY29saW4gQ2hlbiA8
R3Vhbmd5dS5DaGVuQGZyZWVzY2FsZS5jb20+DQo+IC0tLQ0KPiAgc291bmQvc29jL2ZzbC9mc2xf
c2FpLmMgfCA2OSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
LS0tDQo+ICBzb3VuZC9zb2MvZnNsL2ZzbF9zYWkuaCB8ICA5ICsrKysrKysNCj4gIDIgZmlsZXMg
Y2hhbmdlZCwgNzUgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1n
aXQgYS9zb3VuZC9zb2MvZnNsL2ZzbF9zYWkuYyBiL3NvdW5kL3NvYy9mc2wvZnNsX3NhaS5jDQo+
IGluZGV4IGM0YTQyMzEuLjVmOTFhZmYgMTAwNjQ0DQo+IC0tLSBhL3NvdW5kL3NvYy9mc2wvZnNs
X3NhaS5jDQo+ICsrKyBiL3NvdW5kL3NvYy9mc2wvZnNsX3NhaS5jDQo+IEBAIC0yMyw2ICsyMyw1
NSBAQA0KPiANCj4gICNpbmNsdWRlICJmc2xfc2FpLmgiDQo+IA0KPiArI2RlZmluZSBGU0xfU0FJ
X0ZMQUdTIChGU0xfU0FJX0NTUl9TRUlFIHxcDQo+ICsJCSAgICAgICBGU0xfU0FJX0NTUl9GRUlF
IHxcDQo+ICsJCSAgICAgICBGU0xfU0FJX0NTUl9GV0lFKQ0KPiArDQo+ICtzdGF0aWMgaXJxcmV0
dXJuX3QgZnNsX3NhaV9pc3IoaW50IGlycSwgdm9pZCAqZGV2aWQpDQo+ICt7DQo+ICsJc3RydWN0
IGZzbF9zYWkgKnNhaSA9IChzdHJ1Y3QgZnNsX3NhaSAqKWRldmlkOw0KPiArCXN0cnVjdCBkZXZp
Y2UgKmRldiA9ICZzYWktPnBkZXYtPmRldjsNCj4gKwl1MzIgeGNzcjsNCj4gKw0KPiArCXJlZ21h
cF9yZWFkKHNhaS0+cmVnbWFwLCBGU0xfU0FJX1RDU1IsICZ4Y3NyKTsNCj4gKwlyZWdtYXBfd3Jp
dGUoc2FpLT5yZWdtYXAsIEZTTF9TQUlfVENTUiwgeGNzcik7DQoNCkFzc3VtaW5nIHRoZXNlIGFy
ZSAnd3JpdGUgdG8gY2xlYXInIGJpdHMsIHlvdSBtaWdodCB3YW50DQp0byBtYWtlIHRoZSB3cml0
ZSAoYWJvdmUpIGFuZCBhbGwgdGhlIHRyYWNlcyAoYmVsb3cpDQpjb25kaXRpb25hbCBvbiB0aGUg
dmFsdWUgYmVpbmcgbm9uLXplcm8uDQoNCj4gKwlpZiAoeGNzciAmIEZTTF9TQUlfQ1NSX1dTRikN
Cj4gKwkJZGV2X2RiZyhkZXYsICJpc3I6IFN0YXJ0IG9mIFR4IHdvcmQgZGV0ZWN0ZWRcbiIpOw0K
PiArDQo+ICsJaWYgKHhjc3IgJiBGU0xfU0FJX0NTUl9TRUYpDQo+ICsJCWRldl9kYmcoZGV2LCAi
aXNyOiBUeCBGcmFtZSBzeW5jIGVycm9yIGRldGVjdGVkXG4iKTsNCj4gKw0KPiArCWlmICh4Y3Ny
ICYgRlNMX1NBSV9DU1JfRkVGKQ0KPiArCQlkZXZfZGJnKGRldiwgImlzcjogVHJhbnNtaXQgdW5k
ZXJydW4gZGV0ZWN0ZWRcbiIpOw0KPiArDQo+ICsJaWYgKHhjc3IgJiBGU0xfU0FJX0NTUl9GV0Yp
DQo+ICsJCWRldl9kYmcoZGV2LCAiaXNyOiBFbmFibGVkIHRyYW5zbWl0IEZJRk8gaXMgZW1wdHlc
biIpOw0KPiArDQo+ICsJaWYgKHhjc3IgJiBGU0xfU0FJX0NTUl9GUkYpDQo+ICsJCWRldl9kYmco
ZGV2LCAiaXNyOiBUcmFuc21pdCBGSUZPIHdhdGVybWFyayBoYXMgYmVlbiByZWFjaGVkXG4iKTsN
Cg0KU29tZSBvZiB0aG9zZSBsb29rIGxpa2UgJ25vcm1hbCcgaW50ZXJydXB0cywgb3RoZXJzIGFy
ZSBjbGVhcmx5DQphYm5vcm1hbCBjb25kaXRpb25zLg0KTWF5YmUgdGhlIHRyYWNpbmcgc2hvdWxk
IHJlZmxlY3QgdGhpcy4NCg0KPiArDQo+ICsJcmVnbWFwX3JlYWQoc2FpLT5yZWdtYXAsIEZTTF9T
QUlfUkNTUiwgJnhjc3IpOw0KPiArCXJlZ21hcF93cml0ZShzYWktPnJlZ21hcCwgRlNMX1NBSV9S
Q1NSLCB4Y3NyKTsNCg0KU2FtZSBjb21tZW50cyBhcHBseS4uLg0KDQoJRGF2aWQNCg0K

^ permalink raw reply

* [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Nicolin Chen @ 2014-03-26 11:48 UTC (permalink / raw)
  To: broonie, Li.Xiubo; +Cc: alsa-devel, linuxppc-dev, linux-kernel

It's quite cricial to clear error flags because SAI might hang if getting
FIFO underrun during playback (I haven't confirmed the same issue on Rx
overflow though).

So this patch enables those irq and adds isr() to clear the flags so as to
keep playback entirely safe.

Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
---
 sound/soc/fsl/fsl_sai.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++---
 sound/soc/fsl/fsl_sai.h |  9 +++++++
 2 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index c4a4231..5f91aff 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -23,6 +23,55 @@
 
 #include "fsl_sai.h"
 
+#define FSL_SAI_FLAGS (FSL_SAI_CSR_SEIE |\
+		       FSL_SAI_CSR_FEIE |\
+		       FSL_SAI_CSR_FWIE)
+
+static irqreturn_t fsl_sai_isr(int irq, void *devid)
+{
+	struct fsl_sai *sai = (struct fsl_sai *)devid;
+	struct device *dev = &sai->pdev->dev;
+	u32 xcsr;
+
+	regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
+	regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
+
+	if (xcsr & FSL_SAI_CSR_WSF)
+		dev_dbg(dev, "isr: Start of Tx word detected\n");
+
+	if (xcsr & FSL_SAI_CSR_SEF)
+		dev_dbg(dev, "isr: Tx Frame sync error detected\n");
+
+	if (xcsr & FSL_SAI_CSR_FEF)
+		dev_dbg(dev, "isr: Transmit underrun detected\n");
+
+	if (xcsr & FSL_SAI_CSR_FWF)
+		dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
+
+	if (xcsr & FSL_SAI_CSR_FRF)
+		dev_dbg(dev, "isr: Transmit FIFO watermark has been reached\n");
+
+	regmap_read(sai->regmap, FSL_SAI_RCSR, &xcsr);
+	regmap_write(sai->regmap, FSL_SAI_RCSR, xcsr);
+
+	if (xcsr & FSL_SAI_CSR_WSF)
+		dev_dbg(dev, "isr: Start of Rx word detected\n");
+
+	if (xcsr & FSL_SAI_CSR_SEF)
+		dev_dbg(dev, "isr: Rx Frame sync error detected\n");
+
+	if (xcsr & FSL_SAI_CSR_FEF)
+		dev_dbg(dev, "isr: Receive overflow detected\n");
+
+	if (xcsr & FSL_SAI_CSR_FWF)
+		dev_dbg(dev, "isr: Enabled receive FIFO is full\n");
+
+	if (xcsr & FSL_SAI_CSR_FRF)
+		dev_dbg(dev, "isr: Receive FIFO watermark has been reached\n");
+
+	return IRQ_HANDLED;
+}
+
 static int fsl_sai_set_dai_sysclk_tr(struct snd_soc_dai *cpu_dai,
 		int clk_id, unsigned int freq, int fsl_dir)
 {
@@ -373,8 +422,8 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
 {
 	struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev);
 
-	regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0xffffffff, 0x0);
-	regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0xffffffff, 0x0);
+	regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0xffffffff, FSL_SAI_FLAGS);
+	regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0xffffffff, FSL_SAI_FLAGS);
 	regmap_update_bits(sai->regmap, FSL_SAI_TCR1, FSL_SAI_CR1_RFW_MASK,
 			   FSL_SAI_MAXBURST_TX * 2);
 	regmap_update_bits(sai->regmap, FSL_SAI_RCR1, FSL_SAI_CR1_RFW_MASK,
@@ -490,12 +539,14 @@ static int fsl_sai_probe(struct platform_device *pdev)
 	struct fsl_sai *sai;
 	struct resource *res;
 	void __iomem *base;
-	int ret;
+	int irq, ret;
 
 	sai = devm_kzalloc(&pdev->dev, sizeof(*sai), GFP_KERNEL);
 	if (!sai)
 		return -ENOMEM;
 
+	sai->pdev = pdev;
+
 	sai->big_endian_regs = of_property_read_bool(np, "big-endian-regs");
 	if (sai->big_endian_regs)
 		fsl_sai_regmap_config.val_format_endian = REGMAP_ENDIAN_BIG;
@@ -514,6 +565,18 @@ static int fsl_sai_probe(struct platform_device *pdev)
 		return PTR_ERR(sai->regmap);
 	}
 
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "no irq for node %s\n", np->full_name);
+		return irq;
+	}
+
+	ret = devm_request_irq(&pdev->dev, irq, fsl_sai_isr, 0, np->name, sai);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to claim irq %u\n", irq);
+		return ret;
+	}
+
 	sai->dma_params_rx.addr = res->start + FSL_SAI_RDR;
 	sai->dma_params_tx.addr = res->start + FSL_SAI_TDR;
 	sai->dma_params_rx.maxburst = FSL_SAI_MAXBURST_RX;
diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h
index e432260..05d1a1f 100644
--- a/sound/soc/fsl/fsl_sai.h
+++ b/sound/soc/fsl/fsl_sai.h
@@ -37,7 +37,15 @@
 
 /* SAI Transmit/Recieve Control Register */
 #define FSL_SAI_CSR_TERE	BIT(31)
+#define FSL_SAI_CSR_WSF		BIT(20)
+#define FSL_SAI_CSR_SEF		BIT(19)
+#define FSL_SAI_CSR_FEF		BIT(18)
 #define FSL_SAI_CSR_FWF		BIT(17)
+#define FSL_SAI_CSR_FRF		BIT(16)
+#define FSL_SAI_CSR_WSIE	BIT(12)
+#define FSL_SAI_CSR_SEIE	BIT(11)
+#define FSL_SAI_CSR_FEIE	BIT(10)
+#define FSL_SAI_CSR_FWIE	BIT(9)
 #define FSL_SAI_CSR_FRIE	BIT(8)
 #define FSL_SAI_CSR_FRDE	BIT(0)
 
@@ -99,6 +107,7 @@
 #define FSL_SAI_MAXBURST_RX 6
 
 struct fsl_sai {
+	struct platform_device *pdev;
 	struct regmap *regmap;
 
 	bool big_endian_regs;
-- 
1.8.4

^ permalink raw reply related

* Re: [PATCH 00/33] Build ppc64le kernel using ABIv2
From: Anton Blanchard @ 2014-03-26 11:20 UTC (permalink / raw)
  To: Ulrich Weigand; +Cc: mikey, amodra, rusty, mjw, paulus, linuxppc-dev
In-Reply-To: <OF5605E77F.F2B0528E-ONC1257CA6.00487EE5-C1257CA6.00491690@de.ibm.com>


Hi Uli,

> You probably should have two different macros _GLOBAL_TOC vs. _GLOBAL
> (or _GLOBAL vs. _GLOBAL_NOTOC), and use the variant that provides a
> global entry point setting up the TOC only with those functions that
> actually require a TOC.

I was worried that we might introduce subtle bugs by forgetting to use
the right version, but I agree it seems to be the only way.

> When I looked at this last time, I remarked:
> 
> >./platforms/pseries/hvCall.S:
> >./platforms/cell/beat_hvCall.S:
> >Looks safe since all functions are called via varargs prototypes
> >(or > 8 integer arguments).
> 
> Checking again, this still seems true.  These are the prototypes
> for all the functions in hvCall.S:

You are right, I forgot about your previous review. Thanks!

Anton

^ permalink raw reply

* Re: [PATCH 27/33] powerpc: Handle new ELFv2 module relocations
From: Alan Modra @ 2014-03-26 10:28 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: mikey, rusty, ulrich.weigand, mjw, paulus, linuxppc-dev
In-Reply-To: <1395747879-5948-28-git-send-email-anton@samba.org>

On Tue, Mar 25, 2014 at 10:44:33PM +1100, Anton Blanchard wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> +		case R_PPC64_REL16_HA:
> +			/* Subtract location pointer */
> +			value -= (unsigned long)location;
> +			value = ((value + 0x8000) >> 16);
> +			*((uint16_t *) location)
> +				= (*((uint16_t *) location) & ~0xffff)
> +				| (value & 0xffff);

There's not much point reading the uint16_t.

			*(uint16_t *) location = value;

> +			break;
> +
> +		case R_PPC64_REL16_LO:
> +			/* Subtract location pointer */
> +			value -= (unsigned long)location;
> +			*((uint16_t *) location)
> +				= (*((uint16_t *) location) & ~0xffff)
> +				| (value & 0xffff);

and again.

> +			break;
> +
>  		default:
>  			printk("%s: Unknown ADD relocation: %lu\n",
>  			       me->name,

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply

* Re: [PATCH 15/33] powerpc: Fix ABIv2 issues with stack offsets in assembly code
From: Alan Modra @ 2014-03-26 10:06 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: mikey, rusty, ulrich.weigand, mjw, paulus, linuxppc-dev
In-Reply-To: <20140326100449.GN18201@bubble.grove.modra.org>

On Wed, Mar 26, 2014 at 08:34:49PM +1030, Alan Modra wrote:
> On Tue, Mar 25, 2014 at 10:44:21PM +1100, Anton Blanchard wrote:
> > Fix STK_PARAM and use it instead of hardcoding ABIv1 offsets.
> 
> >  _GLOBAL(memcpy)
> >  BEGIN_FTR_SECTION
> > -	std	r3,48(r1)	/* save destination pointer for return value */
> > +	std	r3,STK_PARAM(R3)(r1)	/* save destination pointer for return value */
> 
> Here and elsewhere you're assuming you have a parameter save area.
> That won't be true with ELFv2 for calls to functions like memcpy.

Nevermind, I see you fixed that with the next patch..

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply

* Re: [PATCH 15/33] powerpc: Fix ABIv2 issues with stack offsets in assembly code
From: Alan Modra @ 2014-03-26 10:04 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: mikey, rusty, ulrich.weigand, mjw, paulus, linuxppc-dev
In-Reply-To: <1395747879-5948-16-git-send-email-anton@samba.org>

On Tue, Mar 25, 2014 at 10:44:21PM +1100, Anton Blanchard wrote:
> Fix STK_PARAM and use it instead of hardcoding ABIv1 offsets.

>  _GLOBAL(memcpy)
>  BEGIN_FTR_SECTION
> -	std	r3,48(r1)	/* save destination pointer for return value */
> +	std	r3,STK_PARAM(R3)(r1)	/* save destination pointer for return value */

Here and elsewhere you're assuming you have a parameter save area.
That won't be true with ELFv2 for calls to functions like memcpy.

typedef __SIZE_TYPE__ size_t;
extern void *memcpy (void *dest, const void *src, size_t n);

void foo (void *dest, const void *src, size_t n)
{
  memcpy (dest, src, n);
}

foo:
0:	addis 2,12,.TOC.-0b@ha
	addi 2,2,.TOC.-0b@l
	.localentry	foo,.-foo
	mflr 0
	std 0,16(1)
	stdu 1,-32(1)   # <========
	bl memcpy
	nop
	addi 1,1,32
	ld 0,16(1)
	mtlr 0
	blr

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply

* RE: [PATCH v4 09/11] powerpc/perf: add support for the hv 24x7 interface
From: David Laight @ 2014-03-26  9:43 UTC (permalink / raw)
  To: 'Cody P Schafer', Anton Blanchard
  Cc: Peter Zijlstra, LKML, Michael Ellerman, Ingo Molnar,
	Paul Mackerras, Arnaldo Carvalho de Melo, scottwood@freescale.com,
	Linux PPC
In-Reply-To: <5331CBB0.8080500@linux.vnet.ibm.com>

RnJvbTogQ29keSBQIFNjaGFmZXINCj4gT24gMDMvMjUvMjAxNCAwMzo0MyBBTSwgQW50b24gQmxh
bmNoYXJkIHdyb3RlOg0KPiA+DQo+ID4gSGkgQ29keSwNCj4gPg0KPiA+IGh2LTI0eDc6IGNvdWxk
IG5vdCBvYnRhaW4gY2FwYWJpbGl0aWVzLCBlcnJvciAweA0KPiBmZmZmZmZmZmZmZmZmZmZlLCBu
b3QgZW5hYmxpbmcNCj4gPiBodi1ncGNpOiBjb3VsZCBub3Qgb2J0YWluIGNhcGFiaWxpdGllcywg
ZXJyb3IgMHgNCj4gZmZmZmZmZmZmZmZmZmZmZSwgbm90IGVuYWJsaW5nDQo+ID4NCj4gPj4gKwkJ
cHJfaW5mbygiY291bGQgbm90IG9idGFpbiBjYXBhYmlsaXRpZXMsIGVycm9yIDB4JTgwbHgsIG5v
dCBlbmFibGluZ1xuIiwNCj4gPg0KPiA+IFRoYXQncyBhIGxvdCBvZiBwYWRkaW5nIDopDQo+ID4N
Cj4gPiBJIHRoaW5rIHRoaXMgc2hvdWxkIGFsc28gYmUgYSBwcl9kZWJ1ZywgY29uc2lkZXJpbmcg
dGhpcyBpcyBub3QgcmVsZXZhbnQNCj4gPiB0byBtb3N0IHBwYzY0IGJveGVzLg0KPiANCj4gWWVw
LCBzL2luZm8vZGVidWcvIG1ha2VzIHNlbnNlLiBUaGUgZm9ybWF0IHNob3VsZCBoYXZlIGJlZW4g
IiUwOGx4IiBub3QNCj4gIiU4MGx4Iiwgbm90IHN1cmUgd2hlbiBJIHNjcmV3ZWQgdGhhdCB1cC4N
Cg0KVXNpbmcgIiUjeCIgaXMgYW4gYWx0ZXJuYXRpdmUgLSB1bmxlc3MgeW91IHJlYWxseSBuZWVk
IGZpeGVkIHdpZHRoLg0KDQpIb3dldmVyIGluIHRoaXMgY2FzZSAiJWxkIiBtaWdodCBiZSBtb3Jl
IGFwcHJvcHJpYXRlIQ0KSWYgdGhlIHZhbHVlIGlzIGEgLXZlIGVycm5vIG9uZSwgbWF5YmUgZXZl
biAiZXJybm8gJWQiIGFuZCBuZWdhdGUgdGhlIHZhbHVlLg0KDQoJRGF2aWQNCg0K

^ permalink raw reply

* Re: [PATCH 10/33] powerpc: Ignore TOC relocations
From: Alan Modra @ 2014-03-26  9:36 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: mikey, rusty, ulrich.weigand, mjw, paulus, linuxppc-dev
In-Reply-To: <1395747879-5948-11-git-send-email-anton@samba.org>

On Tue, Mar 25, 2014 at 10:44:16PM +1100, Anton Blanchard wrote:
> The linker fixes up TOC. relocations, so prom_init_check.sh should
> ignore them.

Err, .TOC. you mean.  Presumably something strips off the leading dot
somewhere?

> -btext_setup_display"
> +btext_setup_display TOC."

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply

* Re: Build regressions/improvements in v3.14-rc8
From: Geert Uytterhoeven @ 2014-03-26  7:55 UTC (permalink / raw)
  To: linux-kernel@vger.kernel.org; +Cc: linuxppc-dev@lists.ozlabs.org, Linux-sh list
In-Reply-To: <1395820064-19148-1-git-send-email-geert@linux-m68k.org>

On Wed, Mar 26, 2014 at 8:47 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.14-rc8[1]  to v3.14-rc7[3], the summaries are:
>   - build errors: +6/-1

  + /scratch/kisskb/src/arch/powerpc/include/asm/io.h: error:
'virt_phys_offset' undeclared (first use in this function):  =>
814:16, 807:16, 770:9, 787:17
  + /scratch/kisskb/src/include/linux/mm.h: error: 'virt_phys_offset'
undeclared (first use in this function):  => 890:9, 1402:20, 494:22

powerpc-randconfig

  + /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_HIGH_MASK' undeclared (first use in this function):  => 98:12
  + /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_HIGH_SHIFT' undeclared (first use in this function):  =>
98:34, 145:10
  + /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_LOW_MASK' undeclared (first use in this function):  => 97:21
  + /scratch/kisskb/src/arch/sh/drivers/dma/dma-sh.c: error:
'CHCR_TS_LOW_SHIFT' undeclared (first use in this function):  =>
97:42, 145:10

sh-randconfig

> [1] http://kisskb.ellerman.id.au/kisskb/head/7303/ (all 119 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7277/ (all 119 configs)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

^ permalink raw reply

* Re: [PATCH 6/7] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
From: Vinod Koul @ 2014-03-26  7:01 UTC (permalink / raw)
  To: hongbo.zhang
  Cc: vinod.koul, linux-kernel, scottwood, dmaengine, dan.j.williams,
	linuxppc-dev
In-Reply-To: <1389851246-8564-7-git-send-email-hongbo.zhang@freescale.com>

On Thu, 2014-01-16 at 13:47 +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
> 
> The usage of spin_lock_irqsave() is a stronger locking mechanism than is
> required throughout the driver. The minimum locking required should be used
> instead. Interrupts will be turned off and context will be saved, it is
> unnecessary to use irqsave.
> 
> This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
> manipulation of protected fields is done using tasklet context or weaker, which
> makes spin_lock_bh() the correct choice.
> 
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> ---
>  drivers/dma/fsldma.c |   25 ++++++++++---------------
>  1 file changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index bbace54..437794e 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -396,10 +396,9 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
>  	struct fsldma_chan *chan = to_fsl_chan(tx->chan);
>  	struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
>  	struct fsl_desc_sw *child;
> -	unsigned long flags;
>  	dma_cookie_t cookie = -EINVAL;
>  
> -	spin_lock_irqsave(&chan->desc_lock, flags);
> +	spin_lock_bh(&chan->desc_lock);
>  
>  	/*
>  	 * assign cookies to all of the software descriptors
> @@ -412,7 +411,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
>  	/* put this transaction onto the tail of the pending queue */
>  	append_ld_queue(chan, desc);
>  
> -	spin_unlock_irqrestore(&chan->desc_lock, flags);
> +	spin_unlock_bh(&chan->desc_lock);
>  
>  	return cookie;
>  }
> @@ -731,15 +730,14 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
>  static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
>  {
>  	struct fsldma_chan *chan = to_fsl_chan(dchan);
> -	unsigned long flags;
>  
>  	chan_dbg(chan, "free all channel resources\n");
> -	spin_lock_irqsave(&chan->desc_lock, flags);
> +	spin_lock_bh(&chan->desc_lock);
>  	fsldma_cleanup_descriptors(chan);
>  	fsldma_free_desc_list(chan, &chan->ld_pending);
>  	fsldma_free_desc_list(chan, &chan->ld_running);
>  	fsldma_free_desc_list(chan, &chan->ld_completed);
> -	spin_unlock_irqrestore(&chan->desc_lock, flags);
> +	spin_unlock_bh(&chan->desc_lock);
>  
>  	dma_pool_destroy(chan->desc_pool);
>  	chan->desc_pool = NULL;
> @@ -958,7 +956,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
>  {
>  	struct dma_slave_config *config;
>  	struct fsldma_chan *chan;
> -	unsigned long flags;
>  	int size;
>  
>  	if (!dchan)
> @@ -968,7 +965,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
>  
>  	switch (cmd) {
>  	case DMA_TERMINATE_ALL:
> -		spin_lock_irqsave(&chan->desc_lock, flags);
> +		spin_lock_bh(&chan->desc_lock);
>  
>  		/* Halt the DMA engine */
>  		dma_halt(chan);
> @@ -979,7 +976,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
>  		fsldma_free_desc_list(chan, &chan->ld_completed);
>  		chan->idle = true;
>  
> -		spin_unlock_irqrestore(&chan->desc_lock, flags);
> +		spin_unlock_bh(&chan->desc_lock);
>  		return 0;
>  
>  	case DMA_SLAVE_CONFIG:
> @@ -1021,11 +1018,10 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
>  static void fsl_dma_memcpy_issue_pending(struct dma_chan *dchan)
>  {
>  	struct fsldma_chan *chan = to_fsl_chan(dchan);
> -	unsigned long flags;
>  
> -	spin_lock_irqsave(&chan->desc_lock, flags);
> +	spin_lock_bh(&chan->desc_lock);
>  	fsl_chan_xfer_ld_queue(chan);
> -	spin_unlock_irqrestore(&chan->desc_lock, flags);
> +	spin_unlock_bh(&chan->desc_lock);
>  }
>  
>  /**
> @@ -1124,11 +1120,10 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
>  static void dma_do_tasklet(unsigned long data)
>  {
>  	struct fsldma_chan *chan = (struct fsldma_chan *)data;
> -	unsigned long flags;
>  
>  	chan_dbg(chan, "tasklet entry\n");
>  
> -	spin_lock_irqsave(&chan->desc_lock, flags);
> +	spin_lock_bh(&chan->desc_lock);
okay here is the problem :(

You moved to _bh variant. So if you grab the lock in rest of the code
and irq gets triggered then here we will be spinning to grab the lock.
So effectively you made right locking solution into deadlock situation!

>  
>  	/* the hardware is now idle and ready for more */
>  	chan->idle = true;
> @@ -1136,7 +1131,7 @@ static void dma_do_tasklet(unsigned long data)
>  	/* Run all cleanup for descriptors which have been completed */
>  	fsldma_cleanup_descriptors(chan);
>  
> -	spin_unlock_irqrestore(&chan->desc_lock, flags);
> +	spin_unlock_bh(&chan->desc_lock);
>  
>  	chan_dbg(chan, "tasklet exit\n");
>  }


-- 
Vinod Koul
Intel Corp.

^ permalink raw reply

* [PATCH] phy/at8031: enable at8031 to work on interrupt mode
From: Zhao Qiang @ 2014-03-26  6:45 UTC (permalink / raw)
  To: linuxppc-dev, B07421; +Cc: Zhao Qiang, R63061

The at8031 can work on polling mode and interrupt mode.
Add ack_interrupt and config intr funcs to enable
interrupt mode for it.

Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
 drivers/net/phy/at803x.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index bc71947..d034ef5 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -27,6 +27,9 @@
 #define AT803X_MMD_ACCESS_CONTROL		0x0D
 #define AT803X_MMD_ACCESS_CONTROL_DATA		0x0E
 #define AT803X_FUNC_DATA			0x4003
+#define AT803X_INER				0x0012
+#define AT803X_INER_INIT			0xec00
+#define AT803X_INSR				0x0013
 #define AT803X_DEBUG_ADDR			0x1D
 #define AT803X_DEBUG_DATA			0x1E
 #define AT803X_DEBUG_SYSTEM_MODE_CTRL		0x05
@@ -191,6 +194,31 @@ static int at803x_config_init(struct phy_device *phydev)
 	return 0;
 }
 
+static int at803x_ack_interrupt(struct phy_device *phydev)
+{
+	int err;
+
+	err = phy_read(phydev, AT803X_INSR);
+
+	return (err < 0) ? err : 0;
+}
+
+static int at803x_config_intr(struct phy_device *phydev)
+{
+	int err;
+	int value;
+
+	value = phy_read(phydev, AT803X_INER);
+
+	if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+		err = phy_write(phydev, AT803X_INER,
+				(value | AT803X_INER_INIT));
+	else
+		err = phy_write(phydev, AT803X_INER, value);
+
+	return err;
+}
+
 static struct phy_driver at803x_driver[] = {
 {
 	/* ATHEROS 8035 */
@@ -240,6 +268,8 @@ static struct phy_driver at803x_driver[] = {
 	.flags		= PHY_HAS_INTERRUPT,
 	.config_aneg	= genphy_config_aneg,
 	.read_status	= genphy_read_status,
+	.ack_interrupt  = &at803x_ack_interrupt,
+	.config_intr    = &at803x_config_intr,
 	.driver		= {
 		.owner = THIS_MODULE,
 	},
-- 
1.8.5

^ permalink raw reply related

* Re: [RFC PATCH] Remove CONFIG_DCACHE_WORD_ACCESS
From: Joe Perches @ 2014-03-26  4:54 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Anton Blanchard
  Cc: linux-arch, Russell King, Catalin Marinas, x86, Will Deacon,
	linux-kernel, Ingo Molnar, Paul Mackerras, Alexander Viro,
	H. Peter Anvin, linux-fsdevel, Thomas Gleixner, linuxppc-dev,
	linux-arm-kernel
In-Reply-To: <1394570240.4840.48.camel@pasglop>

On Wed, 2014-03-12 at 07:37 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2014-03-04 at 12:23 -0800, Joe Perches wrote:
> > It seems to duplicate CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > so use that instead.
> > 
> > This changes the !CPU_LITTLE_ENDIAN powerpc arch to use unaligned
> > accesses in fs/dcache.c and fs/namei.c as
> > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is enabled for that arch.
> > 
> > Remove the now unused DCACHE_WORD_ACCESS defines & uses.
> 
> Interesting.. we have word-at-a-time but we never enabled
> DCACHE_WORD_ACCESS, I wonder why that is. In fact, we should
> probably do it for LE as well for P8 if we can make a P8
> only config option...
> 
> Anton, what do you reckon here ?

Anton, do you have an opinion here?

> Cheers,
> Ben.
> 
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> >  arch/arm/Kconfig                      | 1 -
> >  arch/arm/include/asm/word-at-a-time.h | 4 ++--
> >  arch/arm64/Kconfig                    | 1 -
> >  arch/x86/Kconfig                      | 1 -
> >  fs/Kconfig                            | 4 ----
> >  fs/dcache.c                           | 2 +-
> >  fs/namei.c                            | 2 +-
> >  7 files changed, 4 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 623a272..d5a2e60 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -12,7 +12,6 @@ config ARM
> >  	select BUILDTIME_EXTABLE_SORT if MMU
> >  	select CLONE_BACKWARDS
> >  	select CPU_PM if (SUSPEND || CPU_IDLE)
> > -	select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  	select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> >  	select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> >  	select GENERIC_IDLE_POLL_SETUP
> > diff --git a/arch/arm/include/asm/word-at-a-time.h b/arch/arm/include/asm/word-at-a-time.h
> > index a6d0a29..778b2ad 100644
> > --- a/arch/arm/include/asm/word-at-a-time.h
> > +++ b/arch/arm/include/asm/word-at-a-time.h
> > @@ -54,7 +54,7 @@ static inline unsigned long find_zero(unsigned long mask)
> >  #include <asm-generic/word-at-a-time.h>
> >  #endif
> >  
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  
> >  /*
> >   * Load an unaligned word from kernel space.
> > @@ -94,5 +94,5 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)
> >  	return ret;
> >  }
> >  
> > -#endif	/* DCACHE_WORD_ACCESS */
> > +#endif	/* HAVE_EFFICIENT_UNALIGNED_ACCESS */
> >  #endif /* __ASM_ARM_WORD_AT_A_TIME_H */
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 764d682..2d6978c 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -13,7 +13,6 @@ config ARM64
> >  	select CLONE_BACKWARDS
> >  	select COMMON_CLK
> >  	select CPU_PM if (SUSPEND || CPU_IDLE)
> > -	select DCACHE_WORD_ACCESS
> >  	select GENERIC_CLOCKEVENTS
> >  	select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> >  	select GENERIC_IOMAP
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index abb261e..60cfa073 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -98,7 +98,6 @@ config X86
> >  	select CLKEVT_I8253
> >  	select ARCH_HAVE_NMI_SAFE_CMPXCHG
> >  	select GENERIC_IOMAP
> > -	select DCACHE_WORD_ACCESS
> >  	select GENERIC_SMP_IDLE_THREAD
> >  	select ARCH_WANT_IPC_PARSE_VERSION if X86_32
> >  	select HAVE_ARCH_SECCOMP_FILTER
> > diff --git a/fs/Kconfig b/fs/Kconfig
> > index 312393f..7511271 100644
> > --- a/fs/Kconfig
> > +++ b/fs/Kconfig
> > @@ -4,10 +4,6 @@
> >  
> >  menu "File systems"
> >  
> > -# Use unaligned word dcache accesses
> > -config DCACHE_WORD_ACCESS
> > -       bool
> > -
> >  if BLOCK
> >  
> >  source "fs/ext2/Kconfig"
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 265e0ce..4e3c195 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -163,7 +163,7 @@ int proc_nr_dentry(ctl_table *table, int write, void __user *buffer,
> >   * Compare 2 name strings, return 0 if they match, otherwise non-zero.
> >   * The strings are both count bytes long, and count is non-zero.
> >   */
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  
> >  #include <asm/word-at-a-time.h>
> >  /*
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 385f781..1ee33ca 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -1618,7 +1618,7 @@ static inline int nested_symlink(struct path *path, struct nameidata *nd)
> >   *   the final mask". Again, that could be replaced with a
> >   *   efficient population count instruction or similar.
> >   */
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  
> >  #include <asm/word-at-a-time.h>

^ permalink raw reply

* Re: Ask for help about fsl ppc toolchian issue "Illegal instruction"
From: Scott Wood @ 2014-03-25 23:05 UTC (permalink / raw)
  To: wyang; +Cc: 许久成, linuxppc-dev@ozlabs.org
In-Reply-To: <533114A4.4080608@gmail.com>

On Tue, 2014-03-25 at 13:31 +0800, wyang wrote:
> 
> On 03/25/2014 10:17 AM, 许久成 wrote:
> 
> > Hi All, 
> > 
> > 
> > We run into an issue when use e500mc toolchain  g++ to compile c++
> > code for p2020 platform,  the code as below:
> 
> Hmm, p2020 should be e500 core rather than e500mc. Additionally, you
> should use gdb to debug it, and check which instruction is illegal.

It's probably a floating point instruction.  e500v2 (and thus p2020)
does not support normal PPC floating point.  You need to use the right
toolchain.

-Scott

^ permalink raw reply

* [PATCH 1/5] powerpc: Convert last uses of __FUNCTION__ to __func__
From: Joe Perches @ 2014-03-25 19:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <cover.1395775901.git.joe@perches.com>

Just about all of these have been converted to __func__,
so convert the last uses.

Signed-off-by: Joe Perches <joe@perches.com>
---
 arch/powerpc/platforms/pseries/nvram.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c
index d7096f2..0cc240b 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -298,13 +298,13 @@ int nvram_write_os_partition(struct nvram_os_partition *part, char * buff,
 
 	rc = ppc_md.nvram_write((char *)&info, sizeof(struct err_log_info), &tmp_index);
 	if (rc <= 0) {
-		pr_err("%s: Failed nvram_write (%d)\n", __FUNCTION__, rc);
+		pr_err("%s: Failed nvram_write (%d)\n", __func__, rc);
 		return rc;
 	}
 
 	rc = ppc_md.nvram_write(buff, length, &tmp_index);
 	if (rc <= 0) {
-		pr_err("%s: Failed nvram_write (%d)\n", __FUNCTION__, rc);
+		pr_err("%s: Failed nvram_write (%d)\n", __func__, rc);
 		return rc;
 	}
 	
@@ -351,15 +351,14 @@ int nvram_read_partition(struct nvram_os_partition *part, char *buff,
 					sizeof(struct err_log_info),
 					&tmp_index);
 		if (rc <= 0) {
-			pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__,
-									rc);
+			pr_err("%s: Failed nvram_read (%d)\n", __func__, rc);
 			return rc;
 		}
 	}
 
 	rc = ppc_md.nvram_read(buff, length, &tmp_index);
 	if (rc <= 0) {
-		pr_err("%s: Failed nvram_read (%d)\n", __FUNCTION__, rc);
+		pr_err("%s: Failed nvram_read (%d)\n", __func__, rc);
 		return rc;
 	}
 
@@ -869,7 +868,7 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
 		break;
 	default:
 		pr_err("%s: ignoring unrecognized KMSG_DUMP_* reason %d\n",
-						__FUNCTION__, (int) reason);
+		       __func__, (int) reason);
 		return;
 	}
 
-- 
1.8.1.2.459.gbcd45b4.dirty

^ permalink raw reply related

* [PATCH 0/5] Convert last few uses of __FUNCTION__ to __func__
From: Joe Perches @ 2014-03-25 19:35 UTC (permalink / raw)
  To: linux-kernel
  Cc: intel-gfx, dri-devel, linux-mm, xen-devel, linuxppc-dev,
	drbd-user

Outside of staging, there aren't any more uses of __FUNCTION__ now...

Joe Perches (5):
  powerpc: Convert last uses of __FUNCTION__ to __func__
  x86: Convert last uses of __FUNCTION__ to __func__
  block: Convert last uses of __FUNCTION__ to __func__
  i915: Convert last uses of __FUNCTION__ to __func__
  slab: Convert last uses of __FUNCTION__ to __func__

 arch/powerpc/platforms/pseries/nvram.c       | 11 +++++------
 arch/x86/kernel/hpet.c                       |  2 +-
 arch/x86/kernel/rtc.c                        |  4 ++--
 arch/x86/platform/intel-mid/intel_mid_vrtc.c |  2 +-
 drivers/block/drbd/drbd_int.h                |  8 ++++----
 drivers/block/xen-blkfront.c                 |  4 ++--
 drivers/gpu/drm/i915/dvo_ns2501.c            | 15 ++++++---------
 mm/slab.h                                    |  2 +-
 8 files changed, 22 insertions(+), 26 deletions(-)

-- 
1.8.1.2.459.gbcd45b4.dirty

^ permalink raw reply

* Re: Bug in reclaim logic with exhausted nodes?
From: Nishanth Aravamudan @ 2014-03-25 18:37 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <alpine.DEB.2.10.1403251323030.26744@nuc>

On 25.03.2014 [13:25:30 -0500], Christoph Lameter wrote:
> On Tue, 25 Mar 2014, Nishanth Aravamudan wrote:
> 
> > On power, very early, we find the 16G pages (gpages in the powerpc arch
> > code) in the device-tree:
> >
> > early_setup ->
> > 	early_init_mmu ->
> > 		htab_initialize ->
> > 			htab_init_page_sizes ->
> > 				htab_dt_scan_hugepage_blocks ->
> > 					memblock_reserve
> > 						which marks the memory
> > 						as reserved
> > 					add_gpage
> > 						which saves the address
> > 						off so future calls for
> > 						alloc_bootmem_huge_page()
> >
> > hugetlb_init ->
> > 		hugetlb_init_hstates ->
> > 			hugetlb_hstate_alloc_pages ->
> > 				alloc_bootmem_huge_page
> >
> > > Not sure if I understand that correctly.
> >
> > Basically this is present memory that is "reserved" for the 16GB usage
> > per the LPAR configuration. We honor that configuration in Linux based
> > upon the contents of the device-tree. It just so happens in the
> > configuration from my original e-mail that a consequence of this is that
> > a NUMA node has memory (topologically), but none of that memory is free,
> > nor will it ever be free.
> 
> Well dont do that

I appreciate the help you're offering, but that's really not an option.
The customer/user has configured the system in such a way so they can
leverage the gigantic pages. And *most* everything seems to work fine
except for the case I mentioned in my original e-mail. I guess we could
fewer 16GB pages if it would exhaust a NUMA node, but ... I think the
underlying mapping would be a 16GB one, so it will not be accurate from
a performance perspective (although it should perform better).

> > Perhaps, in this case, we could just remove that node from the N_MEMORY
> > mask? Memory allocations will never succeed from the node, and we can
> > never free these 16GB pages. It is really not any different than a
> > memoryless node *except* when you are using the 16GB pages.
> 
> That looks to be the correct way to handle things. Maybe mark the node as
> offline or somehow not present so that the kernel ignores it.

Ok, I'll consider these options. Thanks!

-Nish

^ permalink raw reply

* Re: [PATCH v4 09/11] powerpc/perf: add support for the hv 24x7 interface
From: Cody P Schafer @ 2014-03-25 18:32 UTC (permalink / raw)
  To: Anton Blanchard
  Cc: Peter Zijlstra, LKML, Michael Ellerman, Ingo Molnar,
	Paul Mackerras, Arnaldo Carvalho de Melo, scottwood, Linux PPC
In-Reply-To: <20140325214356.4a2f7d95@kryten>

On 03/25/2014 03:43 AM, Anton Blanchard wrote:
>
> Hi Cody,
>
> hv-24x7: could not obtain capabilities, error 0x                                                                fffffffffffffffe, not enabling
> hv-gpci: could not obtain capabilities, error 0x                                                                fffffffffffffffe, not enabling
>
>> +		pr_info("could not obtain capabilities, error 0x%80lx, not enabling\n",
>
> That's a lot of padding :)
>
> I think this should also be a pr_debug, considering this is not relevant
> to most ppc64 boxes.

Yep, s/info/debug/ makes sense. The format should have been "%08lx" not 
"%80lx", not sure when I screwed that up.

^ permalink raw reply

* Re: Bug in reclaim logic with exhausted nodes?
From: Christoph Lameter @ 2014-03-25 18:25 UTC (permalink / raw)
  To: Nishanth Aravamudan; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <20140325181010.GB29977@linux.vnet.ibm.com>

On Tue, 25 Mar 2014, Nishanth Aravamudan wrote:

> On power, very early, we find the 16G pages (gpages in the powerpc arch
> code) in the device-tree:
>
> early_setup ->
> 	early_init_mmu ->
> 		htab_initialize ->
> 			htab_init_page_sizes ->
> 				htab_dt_scan_hugepage_blocks ->
> 					memblock_reserve
> 						which marks the memory
> 						as reserved
> 					add_gpage
> 						which saves the address
> 						off so future calls for
> 						alloc_bootmem_huge_page()
>
> hugetlb_init ->
> 		hugetlb_init_hstates ->
> 			hugetlb_hstate_alloc_pages ->
> 				alloc_bootmem_huge_page
>
> > Not sure if I understand that correctly.
>
> Basically this is present memory that is "reserved" for the 16GB usage
> per the LPAR configuration. We honor that configuration in Linux based
> upon the contents of the device-tree. It just so happens in the
> configuration from my original e-mail that a consequence of this is that
> a NUMA node has memory (topologically), but none of that memory is free,
> nor will it ever be free.

Well dont do that

> Perhaps, in this case, we could just remove that node from the N_MEMORY
> mask? Memory allocations will never succeed from the node, and we can
> never free these 16GB pages. It is really not any different than a
> memoryless node *except* when you are using the 16GB pages.

That looks to be the correct way to handle things. Maybe mark the node as
offline or somehow not present so that the kernel ignores it.

^ permalink raw reply

* Re: [PATCH v4 09/11] powerpc/perf: add support for the hv 24x7 interface
From: Cody P Schafer @ 2014-03-25 18:19 UTC (permalink / raw)
  To: Anton Blanchard
  Cc: Peter Zijlstra, LKML, Michael Ellerman, Ingo Molnar,
	Paul Mackerras, Arnaldo Carvalho de Melo, scottwood, Linux PPC
In-Reply-To: <20140325214356.4a2f7d95@kryten>

On 03/25/2014 03:43 AM, Anton Blanchard wrote:
>
> Hi Cody,
>
> hv-24x7: could not obtain capabilities, error 0x                                                                fffffffffffffffe, not enabling
> hv-gpci: could not obtain capabilities, error 0x                                                                fffffffffffffffe, not enabling
>
>> +		pr_info("could not obtain capabilities, error 0x%80lx, not enabling\n",
>
> That's a lot of padding :)
>
> I think this should also be a pr_debug, considering this is not relevant
> to most ppc64 boxes.

I'm fine with that. It should probably be "0x%08lx" not "0x%80lx", not 
sure when I screwed that up.

^ permalink raw reply

* Re: Bug in reclaim logic with exhausted nodes?
From: Nishanth Aravamudan @ 2014-03-25 18:10 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <alpine.DEB.2.10.1403251152250.16870@nuc>

On 25.03.2014 [11:53:48 -0500], Christoph Lameter wrote:
> On Tue, 25 Mar 2014, Nishanth Aravamudan wrote:
> 
> > On 25.03.2014 [11:17:57 -0500], Christoph Lameter wrote:
> > > On Mon, 24 Mar 2014, Nishanth Aravamudan wrote:
> > >
> > > > Anyone have any ideas here?
> > >
> > > Dont do that? Check on boot to not allow exhausting a node with huge
> > > pages?
> >
> > Gigantic hugepages are allocated by the hypervisor (not the Linux VM),
> 
> Ok so the kernel starts booting up and then suddenly the hypervisor takes
> the 2 16G pages before even the slab allocator is working?

There is nothing "sudden" about it.

On power, very early, we find the 16G pages (gpages in the powerpc arch
code) in the device-tree:

early_setup ->
	early_init_mmu ->
		htab_initialize ->
			htab_init_page_sizes ->
				htab_dt_scan_hugepage_blocks ->
					memblock_reserve
						which marks the memory
						as reserved
					add_gpage
						which saves the address
						off so future calls for
						alloc_bootmem_huge_page()

hugetlb_init ->
		hugetlb_init_hstates ->
			hugetlb_hstate_alloc_pages ->
				alloc_bootmem_huge_page

> Not sure if I understand that correctly.

Basically this is present memory that is "reserved" for the 16GB usage
per the LPAR configuration. We honor that configuration in Linux based
upon the contents of the device-tree. It just so happens in the
configuration from my original e-mail that a consequence of this is that
a NUMA node has memory (topologically), but none of that memory is free,
nor will it ever be free.

Perhaps, in this case, we could just remove that node from the N_MEMORY
mask? Memory allocations will never succeed from the node, and we can
never free these 16GB pages. It is really not any different than a
memoryless node *except* when you are using the 16GB pages.

Thanks,
Nish

^ permalink raw reply

* Re: [PATCH 1/1] mm: move FAULT_AROUND_ORDER to arch/
From: Dave Hansen @ 2014-03-25 17:50 UTC (permalink / raw)
  To: Kirill A. Shutemov, Madhavan Srinivasan
  Cc: linux-arch, riel, rusty, peterz, x86, linux-kernel, linux-mm, ak,
	paulus, mgorman, akpm, linuxppc-dev, mingo, kirill.shutemov
In-Reply-To: <20140325173605.GA21411@node.dhcp.inet.fi>

On 03/25/2014 10:36 AM, Kirill A. Shutemov wrote:
>> > +/*
>> > + * Fault around order is a control knob to decide the fault around pages.
>> > + * Default value is set to 0UL (disabled), but the arch can override it as
>> > + * desired.
>> > + */
>> > +#ifndef FAULT_AROUND_ORDER
>> > +#define FAULT_AROUND_ORDER	0UL
>> > +#endif
> FAULT_AROUND_ORDER == 0 case should be handled separately in
> do_read_fault(): no reason to go to do_fault_around() if we are going to
> fault in only one page.

Isn't this the kind of thing we want to do in Kconfig?

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox