[PATCHv2] zswap: update docs for runtime-changeable attributes
Change the Documentation/vm/zswap.txt doc to indicate that the zpool and compressor params are now changeable at runtime. Cc: Vlastimil Babka vba...@suse.cz Signed-off-by: Dan Streetman ddstr...@ieee.org --- changes since v1: update doc on working of zbud per Vlastimil Babka's suggestion add explanation of how old pages are handled when changing zpool/compressor Documentation/vm/zswap.txt | 36 1 file changed, 28 insertions(+), 8 deletions(-) diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt index 8458c08..89fff7d 100644 --- a/Documentation/vm/zswap.txt +++ b/Documentation/vm/zswap.txt @@ -32,7 +32,7 @@ can also be enabled and disabled at runtime using the sysfs interface. An example command to enable zswap at runtime, assuming sysfs is mounted at /sys, is: -echo 1 /sys/modules/zswap/parameters/enabled +echo 1 /sys/module/zswap/parameters/enabled When zswap is disabled at runtime it will stop storing pages that are being swapped out. However, it will _not_ immediately write out or fault @@ -49,14 +49,26 @@ Zswap receives pages for compression through the Frontswap API and is able to evict pages from its own compressed pool on an LRU basis and write them back to the backing swap device in the case that the compressed pool is full. -Zswap makes use of zbud for the managing the compressed memory pool. Each -allocation in zbud is not directly accessible by address. Rather, a handle is +Zswap makes use of zpool for the managing the compressed memory pool. Each +allocation in zpool is not directly accessible by address. Rather, a handle is returned by the allocation routine and that handle must be mapped before being accessed. The compressed memory pool grows on demand and shrinks as compressed -pages are freed. The pool is not preallocated. +pages are freed. The pool is not preallocated. By default, a zpool of type +zbud is created, but it can be selected at boot time by setting the zpool +attribute, e.g. zswap.zpool=zbud. It can also be changed at runtime using the +sysfs zpool attribute, e.g. + +echo zbud /sys/module/zswap/parameters/zpool + +The zbud type zpool allocates exactly 1 page to store 2 compressed pages, which +means the compression ratio will always be 2:1 or worse (because of half-full +zbud pages). The zsmalloc type zpool has a more complex compressed page +storage method, and it can achieve greater storage densities. However, +zsmalloc does not implement compressed page eviction, so once zswap fills it +cannot evict the oldest page, it can only reject new pages. When a swap page is passed from frontswap to zswap, zswap maintains a mapping -of the swap entry, a combination of the swap type and swap offset, to the zbud +of the swap entry, a combination of the swap type and swap offset, to the zpool handle that references that compressed swap page. This mapping is achieved with a red-black tree per swap type. The swap offset is the search key for the tree nodes. @@ -74,9 +86,17 @@ controlled policy: * max_pool_percent - The maximum percentage of memory that the compressed pool can occupy. -Zswap allows the compressor to be selected at kernel boot time by setting the -“compressor” attribute. The default compressor is lzo. e.g. -zswap.compressor=deflate +The default compressor is lzo, but it can be selected at boot time by setting +the “compressor” attribute, e.g. zswap.compressor=lzo. It can also be changed +at runtime using the sysfs compressor attribute, e.g. + +echo lzo /sys/module/zswap/parameters/compressor + +When the zpool and/or compressor parameter is changed at runtime, any existing +compressed pages are not modified; they are left in their own zpool. When a +request is made for a page in an old zpool, it is uncompressed using its +original compressor. Once all pages are removed from an old zpool, the zpool +and its compressor are freed. A debugfs interface is provided for various statistic about pool size, number of pages stored, and various counters for the reasons pages are rejected. -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nfit, nd_blk: BLK status register is only 32 bits
On Mon, Aug 24, 2015 at 01:02:17PM -0400, Jeff Moyer wrote: Ross Zwisler ross.zwis...@linux.intel.com writes: Only read 32 bits for the BLK status register in read_blk_stat(). The format and size of this register is defined in the NVDIMM Driver Writer's guide: http://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf Signed-off-by: Ross Zwisler ross.zwis...@linux.intel.com Reported-by: Nicholas Moulin nicholas.w.mou...@linux.intel.com Looks fine, Reviewed-by: Jeff Moyer jmo...@redhat.com However, now that you've drawn attention to that code, I'll note that there is no checking of the pending or retry bits. In fact, ACPI_NFIT_CONTROL_BUFFERED isn't even checked upon loading the tables. Is this on a todo list somewhere? Yep, you're right, we do need to add support for each of these. I'm planning on doing it unless someone else gets to it first. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation/Intel-IOMMU.txt: Modify definition of DRHD
On Thu, 20 Aug 2015 18:17:10 +0800 Nan Xiao xiaonan830...@gmail.com wrote: According to Intel Virtualization Technology for Directed I/O specification, DRHD stands for DMA Remapping Hardware Unit Definition , not DMA Engine Reporting Structure. Applied to the docs tree, thanks. Note that this patch was line-wrapped by your mail client and required manual fixing; please configure your client to not do that (Documentation/email-clients.txt can be helpful) before sending any further patches. jon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] Use 2GB memory block size on large-memory x86-64 systems
On Fri, Aug 21, 2015 at 4:54 PM, Tony Luck tony.l...@gmail.com wrote: On Fri, Aug 21, 2015 at 1:50 PM, Yinghai Lu ying...@kernel.org wrote: Still stuff going on that I don't understand here. I increased the amount of mirrored memory in this machine which moved max_pfn to 0x756 and probe_memory_block_size() picked 512MB as the memory_block_size, which seemed plausible. But my kernel still crashed during boot with this value. :-( Forcing the block size to 128M made the system boot. Maybe all the holes in the e820 map matter too (specifically the alignment of the holes)? Then, what does the E820 look like? Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: acpi: Generic function for setting up PCI device DMA coherency
Hi, On 8/25/15 00:32, Bjorn Helgaas wrote: On Mon, Aug 24, 2015 at 9:41 AM, Suravee Suthikulpanit suravee.suthikulpa...@amd.com wrote: Hi, Ping. Does anyone have any comments or suggestions? Yes, I sent you some ideas a couple weeks ago. I'll resend them. Not sure how I missed that one. Sorry. Thanks again, Suravee -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes
Hello, Dave. On Fri, Aug 21, 2015 at 09:04:51AM +1000, Dave Chinner wrote: Maybe I'm misunderstanding the code but all xfs_writepage() calls are from unbound workqueues - the writeback workers - while xfs_setfilesize() are from bound workqueues, so I wondered why that was and looked at the code and the setsize functions are run off of a separate work item which is queued from the end_bio callback and I can't tell who would be waiting for them. Dave, what am I missing? xfs_setfilesize runs transactions, so it can't be run from IO completion context as it needs to block (i.e. on log space or inode locks). It also can't block log IO completion, nor metadata Io completion, as only log IO completion can free log space, and the inode lock might be waiting on metadata buffer IO completion (e.g. during delayed allocation). Hence we have multiple IO completion workqueues to keep these things separated and deadlock free. i.e. they all get punted to a workqueue where they are then processed in a context that can block safely. I'm still a bit confused. What prevents the following from happening? 1. io completion of last dirty page of an inode and work item for xfs_setfilesize() is queued. 2. inode removed from dirty list. 3. __sync_filesystem() invokes sync_inodes_sb(). There are no dirty pages, so it finishes. 4. xfs_fs_sync_fs() is called which calls _xfs_log_force() but the work item from #1 hasn't run yet, so the size update isn't written out. 5. Crash. Is it that _xfs_log_force() waits for the setfilesize transaction created during writepage? Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: Fix two races between usbnet_stop() and the BH
24.08.2015 20:43, David Miller пишет: From: Eugene Shatokhin eugene.shatok...@rosalab.ru Date: Wed, 19 Aug 2015 14:59:01 +0300 So the following might be possible, although unlikely: CPU0 CPU1 clear_bit: read dev-flags clear_bit: clear EVENT_RX_KILL in the read value dev-flags=0; clear_bit: write updated dev-flags As a result, dev-flags may become non-zero again. Is this really possible? On x86, it is not possible, so this is not a problem. Perhaps, for ARM too. As for the other architectures supported by the kernel - not sure, no common guarantees, it seems. Anyway, this is not a critical issue, I agree. OK, let us leave things as they are for this one and fix the rest. Stores really are atomic in the sense that the do their update in one indivisible operation. Atomic operations like clear_bit also will behave that way. If a clear_bit is in progress, the dev-flags=0 store will not be able to grab the cache line exclusively until the clear_bit is done. So I think the above sequent of events is completely impossible. Once a clear_bit starts, a write by another foreign agent on the bus is absolutely impossible to legally occur until the clear_bit completes. I think this is a non-issue. Regards, Eugene -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/asm] x86/asm/msr: Make wrmsrl() a function
On Sun, Aug 23, 2015 at 12:23 PM, H. Peter Anvin h...@zytor.com wrote: On 08/23/2015 04:45 AM, tip-bot for Andy Lutomirski wrote: Commit-ID: 47edb65178cb7056c2eea0b6c41a7d8c84547192 Gitweb: http://git.kernel.org/tip/47edb65178cb7056c2eea0b6c41a7d8c84547192 Author: Andy Lutomirski l...@kernel.org AuthorDate: Thu, 23 Jul 2015 12:14:40 -0700 Committer: Ingo Molnar mi...@kernel.org CommitDate: Sun, 23 Aug 2015 13:25:38 +0200 x86/asm/msr: Make wrmsrl() a function As of cf991de2f614 (x86/asm/msr: Make wrmsrl_safe() a function), wrmsrl_safe is a function, but wrmsrl is still a macro. The wrmsrl macro performs invalid shifts if the value argument is 32 bits. This makes it unnecessarily awkward to write code that puts an unsigned long into an MSR. Looking at this: where do you see an invalid shift? Everywhere I can see we do the proper casting. Still not side effect free, though. I'm having trouble reproducing it right now, but IIRC at one point I got wrmsrl to warn that a constant turned into zero as a result of a shift. --Andy -hpa -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/memblock: Typo fixed
Typo fixed - s/succees/success
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
mm/memblock.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index 87108e7..8742db8 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -758,7 +758,7 @@ int __init_memblock memblock_reserve(phys_addr_t base,
phys_addr_t size)
*
* This function isolates region [@base, @base + @size), and sets/clears flag
*
- * Return 0 on succees, -errno on failure.
+ * Return 0 on success, -errno on failure.
*/
static int __init_memblock memblock_setclr_flag(phys_addr_t base,
phys_addr_t size, int set, int flag)
@@ -785,7 +785,7 @@ static int __init_memblock memblock_setclr_flag(phys_addr_t
base,
* @base: the base phys addr of the region
* @size: the size of the region
*
- * Return 0 on succees, -errno on failure.
+ * Return 0 on success, -errno on failure.
*/
int __init_memblock memblock_mark_hotplug(phys_addr_t base, phys_addr_t size)
{
@@ -797,7 +797,7 @@ int __init_memblock memblock_mark_hotplug(phys_addr_t base,
phys_addr_t size)
* @base: the base phys addr of the region
* @size: the size of the region
*
- * Return 0 on succees, -errno on failure.
+ * Return 0 on success, -errno on failure.
*/
int __init_memblock memblock_clear_hotplug(phys_addr_t base, phys_addr_t size)
{
@@ -809,7 +809,7 @@ int __init_memblock memblock_clear_hotplug(phys_addr_t
base, phys_addr_t size)
* @base: the base phys addr of the region
* @size: the size of the region
*
- * Return 0 on succees, -errno on failure.
+ * Return 0 on success, -errno on failure.
*/
int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
{
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] x86, bitops, variable_test_bit should return 1 not -1 on a match
This issue was noticed while debugging a CPU hotplug issue. On x86
with (NR_CPUS 1) the cpu_online() define is cpumask_test_cpu().
cpumask_test_cpu() should return 1 if the cpu is set in cpumask and
0 otherwise.
However, cpumask_test_cpu() returns -1 if the cpu in the cpumask is
set and 0 otherwise. This happens because cpumask_test_cpu() calls
test_bit() which is a define that will call variable_test_bit().
variable_test_bit() calls the assembler instruction sbb (Subtract
with Borrow, Subtracts the source from the destination, and subtracts 1
extra if the Carry Flag is set. Results are returned in dest.)
A bit match results in -1 being returned from variable_test_bit() if a
match occurs, not 1 as the function is supposed to.
It looks like the code never does, for example, (test_bit() == 1) so this
change should not have any impact.
[v2]: hpa: Use setc, (Set if Carry, Sets the byte in the operand to 1 if
the Carry Flag is set, otherwise sets the operand to 0.) instead of !!
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Prarit Bhargava pra...@redhat.com
---
arch/x86/include/asm/bitops.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index cfe3b95..c0bff87 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -313,10 +313,10 @@ static __always_inline int constant_test_bit(long nr,
const volatile unsigned lo
static inline int variable_test_bit(long nr, volatile const unsigned long
*addr)
{
- int oldbit;
+ u8 oldbit;
asm volatile(bt %2,%1\n\t
-sbb %0,%0
+setc %0
: =r (oldbit)
: m (*(unsigned long *)addr), Ir (nr));
--
1.7.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory
On 8/22/2015 2:24 AM, Ingo Molnar wrote: * Jonathan (Zhixiong) Zhang zjzh...@codeaurora.org wrote: From: Jonathan (Zhixiong) Zhang zjzh...@codeaurora.org With ACPI APEI firmware first handling, generic hardware error record is updated by firmware in GHES memory region. On an arm64 platform, firmware updates GHES memory region with uncached access attribute, and then Linux reads stale data from cache. This paragraph *still* doesn't parse for me. It's not any English I can recognize: what is a 'With ACPI APEI firmware first handling'? APEI is ACPI Platform Error Interface; it is part of ACPI spec, defining the aspect of hardware error handling. firmware first handling is a terminology used in APEI. It describes such mechanism that when hardware error happens, firmware intersects/handles such hardware error, formulates hardware error record and writes the record to GHES memory region, notifies the kernel through NMI/interrupt, then the kernel GHES driver grabs the error record from the GHES memory region. With current code, GHES memory region is mapped with PAGE_KERNEL based on the assumption that cache coherency of GHES memory region is maintained by firmware on all platforms. This assumption is not true for above mentioned arm64 platform. Instead GHES memory region should be mapped with page protection type according to what is returned from arch_apei_get_mem_attribute(). ... plus what this changelog still doesn't mention is the most important part of any bug fix description: how does the user notice this in practice and why does he care? The changelog mentioned that Linux would read stale data from cache. When stale data is read, kernel reports there is no new hardware error when there actually is. This may lead to further damage in various scenarios, such as error propagation caused data corruption. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jonathan (Zhixiong) Zhang The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory
From: Jonathan (Zhixiong) Zhang zjzh...@codeaurora.org
GHES memory region is used as a communication buffer for reporting
hardware errors from the firmware to kernel. Essentially the
firmware writes hardware error records there, triggers an NMI/interrupt,
then the GHES driver goes off and grabs the error record from the
GHES region.
The kernel currently maps the GHES memory region as cacheable
(PAGE_KERNEL) for all architectures. However, on some arm64 platforms,
there is a mismatch between how the kernel maps the GHES region
(PAGE_KERNEL) and how the firmware maps it (EFI_MEMORY_UC, ie.
uncacheable), leading to the possibility of the kernel GHES driver
reading stale data from the cache when it receives the interrupt. With
stale data being read, kernel reports there is no new hardware error
when there actually is; this may lead to further damage in various
scenarios, such as error propagation caused data corruption.
Instead GHES memory region should be mapped with page protection type
according to what is returned from arch_apei_get_mem_attribute().
Reviewed-by: Matt Fleming m...@codeblueprint.co.uk
Acked-by: Borislav Petkov b...@suse.de
Signed-off-by: Jonathan (Zhixiong) Zhang zjzh...@codeaurora.org
---
drivers/acpi/apei/ghes.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 23981ac1c6c2..3dd9c462d22a 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -157,11 +157,15 @@ static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
{
- unsigned long vaddr;
+ unsigned long vaddr, paddr;
+ pgprot_t prot;
vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area-addr);
- ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
- pfn PAGE_SHIFT, PAGE_KERNEL);
+
+ paddr = pfn PAGE_SHIFT;
+ prot = arch_apei_get_mem_attribute(paddr);
+
+ ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
return (void __iomem *)vaddr;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] Documentation: dt: add Broadcom BCM7038 PWM controller binding
Add a binding documentation for the Broadcom BCM7038 PWM controller found in
BCM7xxx chips.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
.../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
new file mode 100644
index ..8b9bc43b561e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
@@ -0,0 +1,22 @@
+Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller)
+
+Required properties:
+
+- compatible: must be brcm,bcm7038-pwm
+- reg: physical base address and length for this controller
+- #pwm-cells: should be 2. See pwm.txt in this directory for a description
+ of the cells format.
+
+Optional properties:
+
+- clocks: a phandle to the reference clock for this block which is fed through
+ its internal variable clock frequency generator
+
+Example:
+
+ pwm: pwm@f0408000 {
+ compatible = brcm,bcm7038-pwm;
+ reg = 0xf0408000 0x28;
+ #pwm-cells = 2;
+ clocks = upg_fixed;
+ };
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v8 1/2] irqchip: imx-gpcv2: IMX GPCv2 driver for wakeup sources
On Mon, 24 Aug 2015, Shenwei Wang wrote: That's what you want achieve. Still you save the full content of the registers and restore the full content. That saves/restores the enabled and disabled interrupts. So enabled_irqs is a misnomer as you save the full state. How about change its name to saved_irq_mask? Way better. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
parse_args() is too unforgivable?
On 08/24, Oleg Nesterov wrote:
I booted the kernel with the additional patch below, and nothing bad has
happened,
Until I tried reboot it once with locktorture.verbose=true paramater.
It didn't boot.
This is because parse_args() just aborts after it hits the error, so other
arguments at the same initcall level are simply ignored.
Fixed by the patch below, but I simply can't believe nobody hit this (imo)
bug before.
Why does parse_args() do this?? I simply can't understand why parse_args()
adds more random and hard-to-understand problems if one of the args (=true
in this particular case) is wrong.
Yes, the patch below is probably oversimplified / incomplete but imho the
current behaviour is confusing. At least I was greatly confused ;) At least
(I think) it makes sense to let the user know that the rest of command line
was probably ignored.
Oleg.
---
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -220,19 +220,19 @@ char *parse_args(const char *doing,
doing, param);
switch (ret) {
+ case 0:
+ break;
case -ENOENT:
pr_err(%s: Unknown parameter `%s'\n, doing, param);
- return ERR_PTR(ret);
+ break;
case -ENOSPC:
pr_err(%s: `%s' too large for parameter `%s'\n,
doing, val ?: , param);
- return ERR_PTR(ret);
- case 0:
break;
default:
pr_err(%s: `%s' invalid for parameter `%s'\n,
doing, val ?: , param);
- return ERR_PTR(ret);
+ break;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/18] ARM: BCM: use const and __initconst for smp_operations
On 23/08/15 21:36, Masahiro Yamada wrote:
The smp_operations structure is not over-written, so add const
qualifier and replace __initdata with __initconst.
Also, add static to bcm63138_smp_ops.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
For bcm63xx and brcmstb:
Reviewed-by: Florian Fainelli f.faine...@gmail.com
---
arch/arm/mach-bcm/bcm63xx_smp.c | 2 +-
arch/arm/mach-bcm/kona_smp.c| 2 +-
arch/arm/mach-bcm/platsmp-brcmstb.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-bcm/bcm63xx_smp.c b/arch/arm/mach-bcm/bcm63xx_smp.c
index 19be904..9b6727e 100644
--- a/arch/arm/mach-bcm/bcm63xx_smp.c
+++ b/arch/arm/mach-bcm/bcm63xx_smp.c
@@ -161,7 +161,7 @@ static void __init bcm63138_smp_prepare_cpus(unsigned int
max_cpus)
}
}
-struct smp_operations bcm63138_smp_ops __initdata = {
+static const struct smp_operations bcm63138_smp_ops __initconst = {
.smp_prepare_cpus = bcm63138_smp_prepare_cpus,
.smp_boot_secondary = bcm63138_smp_boot_secondary,
};
diff --git a/arch/arm/mach-bcm/kona_smp.c b/arch/arm/mach-bcm/kona_smp.c
index 66a0465..da8328b 100644
--- a/arch/arm/mach-bcm/kona_smp.c
+++ b/arch/arm/mach-bcm/kona_smp.c
@@ -194,7 +194,7 @@ static int bcm_boot_secondary(unsigned int cpu, struct
task_struct *idle)
return -ENOSYS;
}
-static struct smp_operations bcm_smp_ops __initdata = {
+static const struct smp_operations bcm_smp_ops __initconst = {
.smp_prepare_cpus = bcm_smp_prepare_cpus,
.smp_boot_secondary = bcm_boot_secondary,
};
diff --git a/arch/arm/mach-bcm/platsmp-brcmstb.c
b/arch/arm/mach-bcm/platsmp-brcmstb.c
index 44d6bddf..40dc844 100644
--- a/arch/arm/mach-bcm/platsmp-brcmstb.c
+++ b/arch/arm/mach-bcm/platsmp-brcmstb.c
@@ -356,7 +356,7 @@ static int brcmstb_boot_secondary(unsigned int cpu,
struct task_struct *idle)
return 0;
}
-static struct smp_operations brcmstb_smp_ops __initdata = {
+static const struct smp_operations brcmstb_smp_ops __initconst = {
.smp_prepare_cpus = brcmstb_cpu_ctrl_setup,
.smp_boot_secondary = brcmstb_boot_secondary,
#ifdef CONFIG_HOTPLUG_CPU
--
Florian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cgroup: get a ref to source csses when migrating
On Sun, Aug 23, 2015 at 11:10:31PM +1000, Aleksa Sarai wrote:
Grab a ref to each source css being migrated from, otherwise it's
possible for the refcount to reach zero between -can_attach() and
-cancel_attach(). This means that operations on the task's old css
(such as container_of(...)) become unsafe, as we may be operating on a
different css.
Signed-off-by: Aleksa Sarai cyp...@cyphar.com
---
kernel/cgroup.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 4ec1b7ee5de8..6cbfbe36284d 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2305,6 +2305,17 @@ static int cgroup_migrate(struct cgroup *cgrp, struct
task_struct *leader,
if (list_empty(tset.src_csets))
return 0;
+ /*
+ * Fetch a ref of each css, so that the old task's css doesn't get
reaped
+ * between -can_attach() and -cancel_attach().
+ */
+ down_read(css_set_rwsem);
+ list_for_each_entry(cset, tset.src_csets, mg_node) {
+ for_each_e_css(css, i, cgrp)
+ css_get(cset-subsys[i]);
+ }
+ up_read(css_set_rwsem);
Have you verified that the scenario you're describing can actually
happen? AFAICS, cgroup_migrate_add_src() already does the pinning.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: Fix two races between usbnet_stop() and the BH
On Mon, 24 Aug 2015, David Miller wrote: From: Eugene Shatokhin eugene.shatok...@rosalab.ru Date: Wed, 19 Aug 2015 14:59:01 +0300 So the following might be possible, although unlikely: CPU0 CPU1 clear_bit: read dev-flags clear_bit: clear EVENT_RX_KILL in the read value dev-flags=0; clear_bit: write updated dev-flags As a result, dev-flags may become non-zero again. Is this really possible? Stores really are atomic in the sense that the do their update in one indivisible operation. Provided you use ACCESS_ONCE or WRITE_ONCE or whatever people like to call it now. Atomic operations like clear_bit also will behave that way. Are you certain about that? I couldn't find any mention of it in Documentation/atomic_ops.txt. In theory, an architecture could implement atomic bit operations using a spinlock to insure atomicity. I don't know if any architectures do this, but if they do then the scenario above could arise. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: Fix two races between usbnet_stop() and the BH
On Mon, 24 Aug 2015, Alan Stern wrote: On Mon, 24 Aug 2015, David Miller wrote: From: Eugene Shatokhin eugene.shatok...@rosalab.ru Date: Wed, 19 Aug 2015 14:59:01 +0300 So the following might be possible, although unlikely: CPU0 CPU1 clear_bit: read dev-flags clear_bit: clear EVENT_RX_KILL in the read value dev-flags=0; clear_bit: write updated dev-flags As a result, dev-flags may become non-zero again. Is this really possible? Stores really are atomic in the sense that the do their update in one indivisible operation. Provided you use ACCESS_ONCE or WRITE_ONCE or whatever people like to call it now. Atomic operations like clear_bit also will behave that way. Are you certain about that? I couldn't find any mention of it in Documentation/atomic_ops.txt. In theory, an architecture could implement atomic bit operations using a spinlock to insure atomicity. I don't know if any architectures do this, but if they do then the scenario above could arise. Now that I see this in writing, I realize it's not possible after all. clear_bit() et al. will work with a single unsigned long, which doesn't leave any place for spinlocks or other mechanisms. I was thinking of atomic_t. So never mind... Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v8 1/2] irqchip: imx-gpcv2: IMX GPCv2 driver for wakeup sources
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
+static int gpcv2_wakeup_source_save(void) {
+ struct gpcv2_irqchip_data *cd;
+ void __iomem *reg;
+ int i;
+
+ cd = imx_gpcv2_instance;
+ if (!cd)
+ return 0;
+
+ for (i = 0; i IMR_NUM; i++) {
+ reg = cd-gpc_base + cd-cpu2wakeup + i * 4;
+ cd-enabled_irqs[i] = readl_relaxed(reg);
You read the full state of the register and restore the full state.
So why enabled_irqs?
There are two user scenarios:
In CPU Idle state, the system need to be woke up by any enabled irqs,
not just the ones that marked as wakeup sources.
In Suspend State, they system will only be woke up by the one that
marked as a wakeup source. Enabled_irqs are used to save the values
before suspend, and restore them after resume.
That's what you want achieve. Still you save the full content of the
registers and
restore the full content. That saves/restores the enabled and disabled
interrupts.
So enabled_irqs is a misnomer as you save the full state.
How about change its name to saved_irq_mask?
set_wake() or leave it when they want to have resume functionality?
Each time system goes into the suspend state, it will call set_wake
(ON) again to configure the wakeup sources. Clearing wakeup_sources
here can make sure the system work as expected no matter that a driver
calls set_wake (OFF) during resume stage.
We rather make sure that the drivers call set_wake(OFF) as they are supposed
to,
because if they do not then the set_wake(ON) logic in the core code will see
the
counter != 0 and not invoke the irq callback.
Sounds reasonable. Then I will remove this line in new patch.
Thanks,
Shenwei
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: nand: pxa3xx-nand: prevent DFI bus lockup on removal
Ezequiel Garcia ezequ...@vanguardiasur.com.ar writes: Should we worry about having two definitions for the same bit? Would it be too ugly to mix the two meaning? Something like this: /* This bit has two different meanings on NFCv1 and NFCv2 */ #define NDCR_STOP_ON_UNCOR_ARB_CNTL (0x1 19) I don't find that very pretty, but if you want I can put that in the patch instead. @@ -1784,6 +1787,8 @@ static int pxa3xx_nand_remove(struct platform_device *pdev) free_irq(irq, info); pxa3xx_nand_free_buff(info); I think a comment here explaining how this disables DFI arbitration and how clearing it grants DFI access to SMC only. While here, we might want to document how the whole arbiter applies to PXA only, since the DFI bus is shared there. Ok, for v2. I take it that DFI bus is not shared on Armada, lucky you. Maybe something like : /* * In the pxa3xx case, the DFI bus is shared between the SMC and NFC. In order * to prevent a lockup of the system bus, the DFI bus arbitration is granted * to SMC upon driver removal. This is done by setting the x_ARB_CNTL bit, * which also prevents the NAND to have access to the bus anymore. */ Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] mm, page_alloc: Distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
On Mon, Aug 24, 2015 at 01:09:46PM +0100, Mel Gorman wrote:
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index f9ebe1c82060..c3775ee46cd6 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -188,7 +188,7 @@ radix_tree_node_alloc(struct radix_tree_root *root)
* preloading in the interrupt anyway as all the allocations have to
* be atomic. So just do normal allocation when in interrupt.
*/
- if (!(gfp_mask __GFP_WAIT) !in_interrupt()) {
+ if (!gfpflags_allow_blocking(gfp_mask) !in_interrupt()) {
struct radix_tree_preload *rtp;
/*
@@ -249,7 +249,7 @@ radix_tree_node_free(struct radix_tree_node *node)
* with preemption not disabled.
*
* To make use of this facility, the radix tree must be initialised without
- * __GFP_WAIT being passed to INIT_RADIX_TREE().
+ * __GFP_DIRECT_RECLAIM being passed to INIT_RADIX_TREE().
*/
static int __radix_tree_preload(gfp_t gfp_mask)
{
@@ -286,12 +286,12 @@ static int __radix_tree_preload(gfp_t gfp_mask)
* with preemption not disabled.
*
* To make use of this facility, the radix tree must be initialised without
- * __GFP_WAIT being passed to INIT_RADIX_TREE().
+ * __GFP_DIRECT_RECLAIM being passed to INIT_RADIX_TREE().
*/
int radix_tree_preload(gfp_t gfp_mask)
{
/* Warn on non-sensical use... */
- WARN_ON_ONCE(!(gfp_mask __GFP_WAIT));
+ WARN_ON_ONCE(gfpflags_allow_blocking(gfp_mask));
return __radix_tree_preload(gfp_mask);
}
EXPORT_SYMBOL(radix_tree_preload);
This was a last minute conversion related to fixing up direct usages of
__GFP_DIRECT_RECLAIM that is obviously wrong. It needs a
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index c3775ee46cd6..fcf5d98574ce 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -291,7 +291,7 @@ static int __radix_tree_preload(gfp_t gfp_mask)
int radix_tree_preload(gfp_t gfp_mask)
{
/* Warn on non-sensical use... */
- WARN_ON_ONCE(gfpflags_allow_blocking(gfp_mask));
+ WARN_ON_ONCE(!gfpflags_allow_blocking(gfp_mask));
return __radix_tree_preload(gfp_mask);
}
EXPORT_SYMBOL(radix_tree_preload);
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] pwm: Broadcom BCM7038 PWM controller (v2)
Hi, This patch series add PWM support for the Broadcom BCM7xxx chips which feature one or more PWM controllers capable of output periods from 148ns to ~622ms using a combination of variable and fixed frequency settings. The controller does not support setting a polarity. This is based on Thierry's pwm/next branch. Florian Fainelli (2): Documentation: dt: add Broadcom BCM7038 PWM controller binding pwm: Add Broadcom BCM7038 PWM controller support .../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt | 22 ++ drivers/pwm/Kconfig| 10 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-brcmstb.c | 338 + 4 files changed, 371 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt create mode 100644 drivers/pwm/pwm-brcmstb.c -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] pwm: Add Broadcom BCM7038 PWM controller support
Add support for the BCM7038-style PWM controller found in all BCM7xxx STB SoCs.
This controller has a hardcoded 2 channels per controller, and cascades a
variable frequency generator on top of a fixed frequency generator which offers
a range of a 148ns period all the way to ~622ms periods.
Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
Changes in v2:
- properly format comments
- utilize do_div instead of div64_u64
- avoid using a done variable for the while loop
- utilize a parameterized register accessor
- remove a bunch of unnecessary assignments
- provide a module author
- update depends to build on BMIPS_GENERIC (the other user)
- removed artificial padding
- removed used only once variable: dn
- utilize devm_ioremap_resource
- do not print success message
- removed THIS_MODULE from platform_driver structure
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-brcmstb.c | 338 ++
3 files changed, 349 insertions(+)
create mode 100644 drivers/pwm/pwm-brcmstb.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index b1541f40fd8d..363c22b22071 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -111,6 +111,16 @@ config PWM_CLPS711X
To compile this driver as a module, choose M here: the module
will be called pwm-clps711x.
+config PWM_BRCMSTB
+ tristate Broadcom STB PWM support
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC
+ help
+ Generic PWM framework driver for the Broadcom Set-top-Box
+ SoCs (BCM7xxx).
+
+ To compile this driver as a module, choose M Here: the module
+ will be called pwm-brcmstb.c.
+
config PWM_EP93XX
tristate Cirrus Logic EP93xx PWM support
depends on ARCH_EP93XX
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index ec50eb5b5a8f..dc7b1b82d47e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
+obj-$(CONFIG_PWM_BRCMSTB) += pwm-brcmstb.o
obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
obj-$(CONFIG_PWM_FSL_FTM) += pwm-fsl-ftm.o
diff --git a/drivers/pwm/pwm-brcmstb.c b/drivers/pwm/pwm-brcmstb.c
new file mode 100644
index ..ea6562090023
--- /dev/null
+++ b/drivers/pwm/pwm-brcmstb.c
@@ -0,0 +1,338 @@
+/*
+ * Broadcom BCM7038 PWM driver
+ * Author: Florian Fainelli
+ *
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME : fmt
+
+#include linux/clk.h
+#include linux/export.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pwm.h
+
+/* This block is the UPG clock domain which is hardcoded a 27Mhz */
+#define PWM_DEFAULT_FREQ 2700
+
+#define PWM_CTRL 0x00
+#define CTRL_STARTBIT(0)
+#define CTRL_OEB BIT(1)
+#define CTRL_FORCE_HIGH BIT(2)
+#define CTRL_OPENDRAINBIT(3)
+#define CTRL_CHAN_OFFS4
+
+#define PWM_CTRL2 0x04
+#define CTRL2_OUT_SELECT BIT(0)
+
+#define PWM_CWORD_MSB 0x08
+#define PWM_CWORD_LSB 0x0C
+
+#define PWM_CH_SIZE0x8
+
+/* Number of bits for the CWORD value */
+#define CWORD_BIT_SIZE 16
+
+/*
+ * Maximum control word value allowed when variable-frequency PWM is used as a
+ * clock for the constant-frequency PMW.
+ */
+#define CONST_VAR_F_MAX32768
+#define CONST_VAR_F_MIN1
+
+#define PWM_ON(ch) (0x18 + ((ch) * PWM_CH_SIZE))
+#define PWM_ON_MIN1
+#define PWM_PERIOD(ch) (0x1C + ((ch) * PWM_CH_SIZE))
+#define PWM_PERIOD_MIN0
+
+#define PWM_ON_PERIOD_MAX 0xff
+
+struct brcmstb_pwm_dev {
+ void __iomem *base;
+ struct clk *clk;
+ unsigned long rate;
+ struct pwm_chip chip;
+};
+
+static inline u32 pwm_readl(struct brcmstb_pwm_dev *p, u32 off)
+{
+ if (IS_ENABLED(CONFIG_MIPS) IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
+ return __raw_readl(p-base + off);
+ else
+ return readl_relaxed(p-base + off);
+}
+
+static inline void pwm_writel(struct brcmstb_pwm_dev
[PATCH RFC 2/2] staging: fbtft: fix 9-bit SPI support detection
Since bits_per_word isn't usually checked during SPI setup the 9-bit
support must be checked manually.
Signed-off-by: Stefan Wahren stefan.wah...@i2se.com
---
drivers/staging/fbtft/fbtft-core.c |7 +++
drivers/staging/fbtft/flexfb.c |7 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 3638554..bd71487 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -1438,6 +1438,13 @@ int fbtft_probe_common(struct fbtft_display *display,
if (par-spi display-buswidth == 9) {
par-spi-bits_per_word = 9;
ret = spi_setup(par-spi);
+ if (!ret) {
+ struct spi_master *ma = par-spi-master;
+
+ if (!(ma-bits_per_word_mask SPI_BPW_MASK(9)))
+ ret = -EINVAL;
+ }
+
if (ret) {
dev_warn(par-spi-dev,
9-bit SPI not available, emulating using
8-bit.\n);
diff --git a/drivers/staging/fbtft/flexfb.c b/drivers/staging/fbtft/flexfb.c
index 09fd15d..a54a8d9 100644
--- a/drivers/staging/fbtft/flexfb.c
+++ b/drivers/staging/fbtft/flexfb.c
@@ -465,6 +465,13 @@ static int flexfb_probe_common(struct spi_device *sdev,
par-fbtftops.write_vmem = fbtft_write_vmem16_bus9;
sdev-bits_per_word = 9;
ret = spi_setup(sdev);
+ if (!ret) {
+ struct spi_master *ma = par-spi-master;
+
+ if (!(ma-bits_per_word_mask SPI_BPW_MASK(9)))
+ ret = -EINVAL;
+ }
+
if (ret) {
dev_warn(dev,
9-bit SPI not available, emulating
using 8-bit.\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 1/2] staging: fbtft: replace master-setup() with spi_setup()
Calling the setup of the SPI master directly causes a NULL pointer
dereference with master drivers without a separate setup function.
This problem is reproduceable on ARM MXS platform.
So fix this issue by using spi_setup() instead.
Signed-off-by: Stefan Wahren stefan.wah...@i2se.com
---
drivers/staging/fbtft/fb_uc1611.c|2 +-
drivers/staging/fbtft/fb_watterott.c |4 ++--
drivers/staging/fbtft/fbtft-core.c |4 ++--
drivers/staging/fbtft/flexfb.c |4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/fbtft/fb_uc1611.c
b/drivers/staging/fbtft/fb_uc1611.c
index 32f3a9d..5cafa50 100644
--- a/drivers/staging/fbtft/fb_uc1611.c
+++ b/drivers/staging/fbtft/fb_uc1611.c
@@ -76,7 +76,7 @@ static int init_display(struct fbtft_par *par)
/* Set CS active high */
par-spi-mode |= SPI_CS_HIGH;
- ret = par-spi-master-setup(par-spi);
+ ret = spi_setup(par-spi);
if (ret) {
dev_err(par-info-device, Could not set SPI_CS_HIGH\n);
return ret;
diff --git a/drivers/staging/fbtft/fb_watterott.c
b/drivers/staging/fbtft/fb_watterott.c
index 88fb2c0..8eae6ef 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -169,7 +169,7 @@ static int init_display(struct fbtft_par *par)
/* enable SPI interface by having CS and MOSI low during reset */
save_mode = par-spi-mode;
par-spi-mode |= SPI_CS_HIGH;
- ret = par-spi-master-setup(par-spi); /* set CS inactive low */
+ ret = spi_setup(par-spi); /* set CS inactive low */
if (ret) {
dev_err(par-info-device, Could not set SPI_CS_HIGH\n);
return ret;
@@ -180,7 +180,7 @@ static int init_display(struct fbtft_par *par)
par-fbtftops.reset(par);
mdelay(1000);
par-spi-mode = save_mode;
- ret = par-spi-master-setup(par-spi);
+ ret = spi_setup(par-spi);
if (ret) {
dev_err(par-info-device, Could not restore SPI mode\n);
return ret;
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 23392eb..3638554 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -1437,12 +1437,12 @@ int fbtft_probe_common(struct fbtft_display *display,
/* 9-bit SPI setup */
if (par-spi display-buswidth == 9) {
par-spi-bits_per_word = 9;
- ret = par-spi-master-setup(par-spi);
+ ret = spi_setup(par-spi);
if (ret) {
dev_warn(par-spi-dev,
9-bit SPI not available, emulating using
8-bit.\n);
par-spi-bits_per_word = 8;
- ret = par-spi-master-setup(par-spi);
+ ret = spi_setup(par-spi);
if (ret)
goto out_release;
/* allocate buffer with room for dc bits */
diff --git a/drivers/staging/fbtft/flexfb.c b/drivers/staging/fbtft/flexfb.c
index c763efc..09fd15d 100644
--- a/drivers/staging/fbtft/flexfb.c
+++ b/drivers/staging/fbtft/flexfb.c
@@ -464,12 +464,12 @@ static int flexfb_probe_common(struct spi_device *sdev,
par-fbtftops.write_register = fbtft_write_reg8_bus9;
par-fbtftops.write_vmem = fbtft_write_vmem16_bus9;
sdev-bits_per_word = 9;
- ret = sdev-master-setup(sdev);
+ ret = spi_setup(sdev);
if (ret) {
dev_warn(dev,
9-bit SPI not available, emulating
using 8-bit.\n);
sdev-bits_per_word = 8;
- ret = sdev-master-setup(sdev);
+ ret = spi_setup(sdev);
if (ret)
goto out_release;
/* allocate buffer with room for dc bits */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/2] staging: fbtft: fix 9-bit SPI support
This patch series fixes the 9-bit SPI support of fbtft. Stefan Wahren (2): staging: fbtft: replace master-setup() with spi_setup() staging: fbtft: fix 9-bit SPI support detection drivers/staging/fbtft/fb_uc1611.c|2 +- drivers/staging/fbtft/fb_watterott.c |4 ++-- drivers/staging/fbtft/fbtft-core.c | 11 +-- drivers/staging/fbtft/flexfb.c | 11 +-- 4 files changed, 21 insertions(+), 7 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
h8300 build failures ijn linux-next
Hi, In linux-next as of today (0824), all h8300 builds fail for me with an internal compiler error. Building h8300:allnoconfig ... failed -- Error log: In file included from include/linux/rcupdate.h:429:0, from include/linux/rcusync.h:5, from kernel/rcu/sync.c:1: include/linux/rcutiny.h: In function ‘rcu_barrier_sched’: include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault static inline void rcu_barrier_sched(void) ^ I tried both gcc 5.1 and 5.2, built with the patch set available to me. Is there a more recent compiler / patch set available that might fix the problem ? Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: Fix two races between usbnet_stop() and the BH
From: Alan Stern st...@rowland.harvard.edu Date: Mon, 24 Aug 2015 14:06:15 -0400 (EDT) On Mon, 24 Aug 2015, David Miller wrote: Atomic operations like clear_bit also will behave that way. Are you certain about that? I couldn't find any mention of it in Documentation/atomic_ops.txt. In theory, an architecture could implement atomic bit operations using a spinlock to insure atomicity. I don't know if any architectures do this, but if they do then the scenario above could arise. Indeed, we do have platforms like 32-bit sparc and parisc that do this. So, taking that into consideration, this is a bit unfortunate and on such platforms we do have this problem. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] thermal: power_allocator: relax the requirement of a sustainable_power in tzp
On Thu, Aug 20, 2015 at 11:16:53PM +0100, Eduardo Valentin wrote:
On Mon, Aug 17, 2015 at 06:36:45PM +0100, Javi Merino wrote:
The power allocator governor currently requires that a sustainable power
is passed as part of the thermal zone's thermal zone parameters. If
that parameter is not provided, it doesn't register with the thermal
zone.
While this parameter is strongly recommended for optimal performance, it
doesn't need to be mandatory. Relax the requirement and allow the
governor to bind to thermal zones that don't provide it by estimating it
from the cooling devices' power model.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Signed-off-by: Javi Merino javi.mer...@arm.com
---
drivers/thermal/power_allocator.c | 62
+--
drivers/thermal/thermal_core.c| 28 ++
include/linux/thermal.h | 6
3 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/power_allocator.c
index 63a448f9d93b..7ec459780dff 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -73,6 +73,39 @@ struct power_allocator_params {
};
/**
+ * estimate_sustainable_power() - Estimate the sustainable power of a
thermal zone
+ * @tz: thermal zone we are operating in
+ *
+ * For thermal zones that don't provide a sustainable_power in their
+ * thermal_zone_params, estimate one. Calculate it using the minimum
+ * power of all the cooling devices as that gives a valid value that
+ * can give some degree of functionality. For optimal performance of
+ * this governor, provide a sustainable_power in the thermal zone's
+ * thermal_zone_params.
+ */
+static u32 estimate_sustainable_power(struct thermal_zone_device *tz)
+{
+ u32 sustainable_power = 0;
+ struct thermal_instance *instance;
+ struct power_allocator_params *params = tz-governor_data;
+
+ list_for_each_entry(instance, tz-thermal_instances, tz_node) {
+ struct thermal_cooling_device *cdev = instance-cdev;
+ u32 min_power;
+
+ if (instance-trip != params-trip_max_desired_temperature)
+ continue;
+
+ if (power_actor_get_min_power(cdev, tz, min_power))
+ continue;
+
+ sustainable_power += min_power;
+ }
+
+ return sustainable_power;
+}
+
+/**
* pid_controller() - PID controller
* @tz:thermal zone we are operating in
* @current_temp: the current temperature in millicelsius
@@ -98,6 +131,7 @@ static u32 pid_controller(struct thermal_zone_device *tz,
{
s64 p, i, d, power_range;
s32 err, max_power_frac;
+ u32 sustainable_power;
struct power_allocator_params *params = tz-governor_data;
max_power_frac = int_to_frac(max_allocatable_power);
@@ -138,8 +172,11 @@ static u32 pid_controller(struct thermal_zone_device
*tz,
power_range = p + i + d;
+ sustainable_power = tz-tzp-sustainable_power ?:
+ estimate_sustainable_power(tz);
+
/* feed-forward the known sustainable dissipatable power */
- power_range = tz-tzp-sustainable_power + frac_to_int(power_range);
+ power_range = sustainable_power + frac_to_int(power_range);
power_range = clamp(power_range, (s64)0, (s64)max_allocatable_power);
@@ -418,18 +455,18 @@ static int power_allocator_bind(struct
thermal_zone_device *tz)
int ret;
struct power_allocator_params *params;
unsigned long switch_on_temp, control_temp;
- u32 temperature_threshold;
+ u32 sustainable_power, temperature_threshold;
- if (!tz-tzp || !tz-tzp-sustainable_power) {
- dev_err(tz-device,
- power_allocator: missing sustainable_power\n);
+ if (!tz-tzp)
return -EINVAL;
- }
params = devm_kzalloc(tz-device, sizeof(*params), GFP_KERNEL);
if (!params)
return -ENOMEM;
+ if (!tz-tzp-sustainable_power)
+ dev_warn(tz-device, power_allocator: sustainable_power will
be estimated\n);
+
ret = get_governor_trips(tz, params);
if (ret) {
dev_err(tz-device,
@@ -448,13 +485,20 @@ static int power_allocator_bind(struct
thermal_zone_device *tz)
if (ret)
goto free;
+ /*
+* Provide an arbitrary sustainable_power to set the default
+* values of k_po and k_pu. We can not estimate sustainable_power
+* at this point because no cooling devices have been
+* registered yet. By providing an arbitrary value we get
+* better defaults than setting k_po and k_pu to 0.
+*/
+ sustainable_power = tz-tzp-sustainable_power ?: 2500;
I think having 2500 here may produce constants that are not sane for
most thermal zones.
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Mon, Aug 24, 2015 at 7:17 PM, Lars-Peter Clausen l...@metafoo.de wrote: On 08/06/2015 05:19 AM, Punnaiah Choudary Kalluri wrote: [...] +Optional properties: +- xlnx,include-sg: Indicates the controller to operate in simple or scatter +gather dma mode +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for + source AXI transaction +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data +- xlnx,src-issue: Number of AXI outstanding transactions on source side +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the + descriptor read are marked Non-coherent +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the + source descriptor payload are marked Non-coherent +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the + dst descriptor payload are marked Non-coherent +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch +- xlnx,src-axi-qos: AXI QOS bits to be used for data read +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch. +- xlnx,desc-axi-cache: AXI cache bits to be used for data read +- xlnx,desc-axi-cache: AXI cache bits to be used for data write +- xlnx,src-burst-len: AXI length for data read. Support only power of 2 values + i.e 1,2,4,8 and 16 +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 values + i.e 1,2,4,8 and 16 None of these really belong into the devicetree. This is all runtime configuration data. This is a general purpose dma and provides more flexibility to the user for configuring the descriptor, data and bus parameters. one way is as you said these parameters can be configured at runtime but i didn't find a way configuring the channel at runtime for mem to mem transfers. I have checked the device_config function description and it is strictly meant for slave operations only. So, i didn't see anything wrong having these parameter values from the device tree as these all are hw parameters. Regards, Punnaiah - Lars -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mtd: nand: pxa3xx-nand: switch to dmaengine
Now pxa architecture has a dmaengine driver, remove the access to direct
dma registers in favor of the more generic dmaengine code.
This should be also applicable for mmp and orion, provided they work in
device-tree environment.
This patch also removes the previous hack which was necessary to make
the driver work in a devicetree environment.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/mtd/nand/pxa3xx_nand.c | 223 -
1 file changed, 109 insertions(+), 114 deletions(-)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 34c9a60c8c5c..9c555276afc3 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -15,7 +15,9 @@
#include linux/module.h
#include linux/interrupt.h
#include linux/platform_device.h
+#include linux/dmaengine.h
#include linux/dma-mapping.h
+#include linux/dma/pxa-dma.h
#include linux/delay.h
#include linux/clk.h
#include linux/mtd/mtd.h
@@ -33,10 +35,6 @@
#define ARCH_HAS_DMA
#endif
-#ifdef ARCH_HAS_DMA
-#include mach/dma.h
-#endif
-
#include linux/platform_data/mtd-nand-pxa3xx.h
#defineCHIP_DELAY_TIMEOUT msecs_to_jiffies(200)
@@ -206,6 +204,10 @@ struct pxa3xx_nand_info {
unsigned intoob_buff_pos;
/* DMA information */
+ struct scatterlist sg;
+ enum dma_data_direction dma_dir;
+ struct dma_chan *dma_chan;
+ dma_cookie_tdma_cookie;
int drcmr_dat;
int drcmr_cmd;
@@ -213,8 +215,6 @@ struct pxa3xx_nand_info {
unsigned char *oob_buff;
dma_addr_t data_buff_phys;
int data_dma_ch;
- struct pxa_dma_desc *data_desc;
- dma_addr_t data_desc_addr;
struct pxa3xx_nand_host *host[NUM_CHIP_SELECT];
unsigned intstate;
@@ -473,6 +473,9 @@ static void pxa3xx_nand_stop(struct pxa3xx_nand_info *info)
ndcr = ~NDCR_ND_RUN;
nand_writel(info, NDCR, ndcr);
}
+ if (info-dma_chan)
+ dmaengine_terminate_all(info-dma_chan);
+
/* clear status bits */
nand_writel(info, NDSR, NDSR_MASK);
}
@@ -564,57 +567,62 @@ static void handle_data_pio(struct pxa3xx_nand_info *info)
info-data_size -= do_bytes;
}
-#ifdef ARCH_HAS_DMA
-static void start_data_dma(struct pxa3xx_nand_info *info)
+static void pxa3xx_nand_data_dma_irq(void *data)
{
- struct pxa_dma_desc *desc = info-data_desc;
- int dma_len = ALIGN(info-data_size + info-oob_size, 32);
+ struct pxa3xx_nand_info *info = data;
+ struct dma_tx_state state;
+ enum dma_status status;
+
+ status = dmaengine_tx_status(info-dma_chan, info-dma_cookie, state);
+ if (likely(status == DMA_COMPLETE)) {
+ info-state = STATE_DMA_DONE;
+ } else {
+ dev_err(info-pdev-dev, DMA error on data channel\n);
+ info-retcode = ERR_DMABUSERR;
+ }
+ dma_unmap_sg(info-dma_chan-device-dev,
+info-sg, 1, info-dma_dir);
- desc-ddadr = DDADR_STOP;
- desc-dcmd = DCMD_ENDIRQEN | DCMD_WIDTH4 | DCMD_BURST32 | dma_len;
+ nand_writel(info, NDSR, NDSR_WRDREQ | NDSR_RDDREQ);
+ enable_int(info, NDCR_INT_MASK);
+}
+
+static void start_data_dma(struct pxa3xx_nand_info *info)
+{
+ enum dma_data_direction direction;
+ struct dma_async_tx_descriptor *tx;
switch (info-state) {
case STATE_DMA_WRITING:
- desc-dsadr = info-data_buff_phys;
- desc-dtadr = info-mmio_phys + NDDB;
- desc-dcmd |= DCMD_INCSRCADDR | DCMD_FLOWTRG;
+ info-dma_dir = DMA_TO_DEVICE;
+ direction = DMA_MEM_TO_DEV;
break;
case STATE_DMA_READING:
- desc-dtadr = info-data_buff_phys;
- desc-dsadr = info-mmio_phys + NDDB;
- desc-dcmd |= DCMD_INCTRGADDR | DCMD_FLOWSRC;
+ info-dma_dir = DMA_FROM_DEVICE;
+ direction = DMA_DEV_TO_MEM;
break;
default:
dev_err(info-pdev-dev, %s: invalid state %d\n, __func__,
info-state);
BUG();
}
-
- DRCMR(info-drcmr_dat) = DRCMR_MAPVLD | info-data_dma_ch;
- DDADR(info-data_dma_ch) = info-data_desc_addr;
- DCSR(info-data_dma_ch) |= DCSR_RUN;
-}
-
-static void pxa3xx_nand_data_dma_irq(int channel, void *data)
-{
- struct pxa3xx_nand_info *info = data;
- uint32_t dcsr;
-
- dcsr = DCSR(channel);
- DCSR(channel) = dcsr;
-
- if (dcsr DCSR_BUSERR) {
- info-retcode = ERR_DMABUSERR;
+ info-sg.length = info-data_size +
+ (info-oob_size ? info-spare_size + info-ecc_size : 0);
+ dma_map_sg(info-dma_chan-device-dev, info-sg, 1,
Re: two RCU torture bugs
On Sun, Aug 23, 2015 at 10:29:15PM -0700, Paul E. McKenney wrote:
On Sun, Aug 23, 2015 at 10:07:49PM -0700, David Miller wrote:
1) Doc bug, documentation mentions torture_type such as rcu_sync,
but those don't seem to exist.
2) If you specify an unrecognized type, the module cannot be unloaded.
Amusingly it says that it cannot unload because the unrecognized
torture test type you requested is running :-)
Clearly Iftekhar was mutating the wrong code. ;-)
And clearly I need to occasionally test failure cases. There is code that
is supposed to unwind upon failure, but it has apparently bitrotted...
Do the following pair of untested patches help?
Thanx, Paul
commit d568705d102ceb61884a3a8b77a98168094acbca
Author: Paul E. McKenney paul...@linux.vnet.ibm.com
Date: Mon Aug 24 11:37:58 2015 -0700
rcutorture: Fix module unwind when bad torture_type specified
The rcutorture module has a list of torture types, and specifying a
type not on this list is supposed to cleanly fail the module load.
Unfortunately, the fail happens without the cleanly. This commit
therefore adds the needed clean-up after an incorrect torture_type.
Reported-by: David Miller da...@davemloft.net
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index f9ec6cbe77d3..9c4f5cd86532 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -695,7 +695,7 @@ static bool __maybe_unused torturing_tasks(void)
#define RCUTORTURE_TASKS_OPS
-static bool torturing_tasks(void)
+static bool __maybe_unused torturing_tasks(void)
{
return false;
}
@@ -1742,8 +1742,8 @@ rcu_torture_init(void)
for (i = 0; i ARRAY_SIZE(torture_ops); i++)
pr_alert( %s, torture_ops[i]-name);
pr_alert(\n);
- torture_init_end();
- return -EINVAL;
+ firsterr = -EINVAL;
+ goto unwind;
}
if (cur_ops-fqs == NULL fqs_duration != 0) {
pr_alert(rcu-torture: -fqs NULL and non-zero fqs_duration,
fqs disabled.\n);
commit 20f34145cfbba04b44b8fbd29689bdcc0ab0b303
Author: Paul E. McKenney paul...@linux.vnet.ibm.com
Date: Mon Aug 24 11:46:00 2015 -0700
documentation: Catch up list of torture_type options
This commit rids the documentation of long-obsolete torture_type options
such as rcu_sync and adds new ones such as tasks. Also add verbiage
noting the fact that rcutorture now concurrently tests the asynchrounous,
synchronous, expedited synchronous, and polling grace-period primitives.
Reported-by: David Miller da...@davemloft.net
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
index dac02a6219b1..118e7c176ce7 100644
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@@ -166,40 +166,27 @@ test_no_idle_hz Whether or not to test the ability of
RCU to operate in
torture_type The type of RCU to test, with string values as follows:
- rcu: rcu_read_lock(), rcu_read_unlock() and call_rcu().
-
- rcu_sync: rcu_read_lock(), rcu_read_unlock(), and
- synchronize_rcu().
-
- rcu_expedited: rcu_read_lock(), rcu_read_unlock(), and
- synchronize_rcu_expedited().
+ rcu: rcu_read_lock(), rcu_read_unlock() and call_rcu(),
+ along with expedited, synchronous, and polling
+ variants.
rcu_bh: rcu_read_lock_bh(), rcu_read_unlock_bh(), and
- call_rcu_bh().
-
- rcu_bh_sync: rcu_read_lock_bh(), rcu_read_unlock_bh(),
- and synchronize_rcu_bh().
+ call_rcu_bh(), along with expedited and synchronous
+ variants.
- rcu_bh_expedited: rcu_read_lock_bh(), rcu_read_unlock_bh(),
- and synchronize_rcu_bh_expedited().
+ rcu_busted: This tests an intentionally incorrect version
+ of RCU in order to help test rcutorture itself.
srcu: srcu_read_lock(), srcu_read_unlock() and
- call_srcu().
-
- srcu_sync: srcu_read_lock(), srcu_read_unlock() and
- synchronize_srcu().
-
- srcu_expedited: srcu_read_lock(), srcu_read_unlock() and
- synchronize_srcu_expedited().
+ call_srcu(), along with expedited and
+ synchronous variants.
sched: preempt_disable(),
Build failure due to Intel PT
I am trying to build perf tool on Powerpc and get this:
util/intel-pt-decoder/intel-pt-insn-decoder.c: In function
‘intel_pt_insn_decoder’:
util/intel-pt-decoder/intel-pt-insn-decoder.c:138:3: error: switch missing
default case [-Werror=switch-default]
switch (insn-immediate.nbytes) {
^
cc1: all warnings being treated as errors
Besides adding a 'default' case, can this file be skipped when building on
non-x86 architectures?
I am on the perf/core branch, with HEAD pointing to:
commit c0b4dffbc529244d3e4e3bd392f2bffa2d8531a7
Author: Arnaldo Carvalho de Melo a...@redhat.com
Date: Mon Aug 24 13:33:14 2015 -0300
perf annotate: Reset the dso find_symbol cache when removing symbols
Sukadev
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Wed, Aug 5, 2015 at 10:19 PM, Punnaiah Choudary Kalluri
punnaiah.choudary.kall...@xilinx.com wrote:
Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..e4f92b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,61 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible: Should be xlnx,zynqmp-dma-1.0
+- #dma-cells: Should be 1, a single cell holding a line request number
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain DMA channel interrupt
+- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
+
+Optional properties:
+- xlnx,include-sg: Indicates the controller to operate in simple or scatter
+ gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
+source AXI transaction
+- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data
+- xlnx,src-issue: Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
+ descriptor read are marked Non-coherent
+- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
+ source descriptor payload are marked Non-coherent
+- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
+ dst descriptor payload are marked Non-coherent
Do you really need 3? dma-coherent property doesn't work for you?
Not that it should dictate the binding, but the kernel doesn't support
a device needing both coherent and non-coherent DMA ops.
+- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
+- xlnx,src-axi-qos: AXI QOS bits to be used for data read
+- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
+- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
+- xlnx,desc-axi-cache: AXI cache bits to be used for data read
+- xlnx,desc-axi-cache: AXI cache bits to be used for data write
These signals are generally part of the coherent or not setting. This
allows for potentially invalid combinations.
Plus you have a copy/paste error.
+- xlnx,src-burst-len: AXI length for data read. Support only power of 2
values
+ i.e 1,2,4,8 and 16
+- xlnx,dst-burst-len: AXI length for data write. Support only power of 2
values
+ i.e 1,2,4,8 and 16
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+ compatible = xlnx,zynqmp-dma-1.0;
+ reg = 0x0 0xFD50 0x1000;
+ #dma_cells = 1;
+ interrupt-parent = gic;
+ interrupts = 0 117 4;
+ xlnx,bus-width = 128;
+ xlnx,include-sg;
+ xlnx,overfetch;
+ xlnx,ratectrl = 0;
+ xlnx,src-issue = 16;
+ xlnx,desc-axi-cohrnt;
+ xlnx,src-axi-cohrnt;
+ xlnx,dst-axi-cohrnt;
+ xlnx,desc-axi-qos = 0;
+ xlnx,desc-axi-cache = 0;
+ xlnx,src-axi-qos = 0;
+ xlnx,src-axi-cache = 2;
+ xlnx,dst-axi-qos = 0;
+ xlnx,dst-axi-cache = 2;
+ xlnx,src-burst-len = 4;
+ xlnx,dst-burst-len = 4;
+};
--
1.7.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/6] mm: Introduce VM_LOCKONFAULT
On Mon, Aug 24, 2015 at 8:00 PM, Eric B Munson emun...@akamai.com wrote: On Mon, 24 Aug 2015, Konstantin Khlebnikov wrote: On Mon, Aug 24, 2015 at 6:55 PM, Eric B Munson emun...@akamai.com wrote: On Mon, 24 Aug 2015, Konstantin Khlebnikov wrote: On Mon, Aug 24, 2015 at 6:09 PM, Eric B Munson emun...@akamai.com wrote: On Mon, 24 Aug 2015, Vlastimil Babka wrote: On 08/24/2015 03:50 PM, Konstantin Khlebnikov wrote: On Mon, Aug 24, 2015 at 4:30 PM, Vlastimil Babka vba...@suse.cz wrote: On 08/24/2015 12:17 PM, Konstantin Khlebnikov wrote: I am in the middle of implementing lock on fault this way, but I cannot see how we will hanlde mremap of a lock on fault region. Say we have the following: addr = mmap(len, MAP_ANONYMOUS, ...); mlock(addr, len, MLOCK_ONFAULT); ... mremap(addr, len, 2 * len, ...) There is no way for mremap to know that the area being remapped was lock on fault so it will be locked and prefaulted by remap. How can we avoid this without tracking per vma if it was locked with lock or lock on fault? remap can count filled ptes and prefault only completely populated areas. Does (and should) mremap really prefault non-present pages? Shouldn't it just prepare the page tables and that's it? As I see mremap prefaults pages when it extends mlocked area. Also quote from manpage : If the memory segment specified by old_address and old_size is locked : (using mlock(2) or similar), then this lock is maintained when the segment is : resized and/or relocated. As a consequence, the amount of memory locked : by the process may change. Oh, right... Well that looks like a convincing argument for having a sticky VM_LOCKONFAULT after all. Having mremap guess by scanning existing pte's would slow it down, and be unreliable (was the area completely populated because MLOCK_ONFAULT was not used or because the process aulted it already? Was it not populated because MLOCK_ONFAULT was used, or because mmap(MAP_LOCKED) failed to populate it all?). Given this, I am going to stop working in v8 and leave the vma flag in place. The only sane alternative is to populate always for mremap() of VM_LOCKED areas, and document this loss of MLOCK_ONFAULT information as a limitation of mlock2(MLOCK_ONFAULT). Which might or might not be enough for Eric's usecase, but it's somewhat ugly. I don't think that this is the right solution, I would be really surprised as a user if an area I locked with MLOCK_ONFAULT was then fully locked and prepopulated after mremap(). If mremap is the only problem then we can add opposite flag for it: MREMAP_NOPOPULATE - do not populate new segment of locked areas - do not copy normal areas if possible (anonymous/special must be copied) addr = mmap(len, MAP_ANONYMOUS, ...); mlock(addr, len, MLOCK_ONFAULT); ... addr2 = mremap(addr, len, 2 * len, MREMAP_NOPOPULATE); ... But with this, the user must remember what areas are locked with MLOCK_LOCKONFAULT and which are locked the with prepopulate so the correct mremap flags can be used. Yep. Shouldn't be hard. You anyway have to do some changes in user-space. Sorry if I wasn't clear enough in my last reply, I think forcing userspace to track this is the wrong choice. The VM system is responsible for tracking these attributes and should continue to be. Userspace tracks addresses and sizes of these areas. Plus mremap obviously works only with page granularity so memory allocator in userspace have to know a lot about these structures. So keeping one more bit isn't a rocket science. Much simpler for users-pace solution is a mm-wide flag which turns all further mlocks and MAP_LOCKED into lock-on-fault. Something like mlockall(MCL_NOPOPULATE_LOCKED). This set certainly adds the foundation for such a change if you think it would be useful. That particular behavior was not part of my inital use case though. This looks like much easier solution: you don't need new syscall and after enabling that lock-on-fault mode userspace still can get old behaviour simply by touching newly locked area. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] btrfs: Fixed declaration of old_len
old_len is used to store the return value of btrfs_item_size_nr(). The return value of btrfs_item_size_nr() is of type u32. To improve code correctness and avoid mixing signed and unsigned integers I've changed old_len to be of type u32 as well. Signed-off-by: Alexandru Moise 00moses.alexande...@gmail.com --- fs/btrfs/root-tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c index 360a728..024ea4f 100644 --- a/fs/btrfs/root-tree.c +++ b/fs/btrfs/root-tree.c @@ -141,7 +141,7 @@ int btrfs_update_root(struct btrfs_trans_handle *trans, struct btrfs_root int ret; int slot; unsigned long ptr; - int old_len; + u32 old_len; path = btrfs_alloc_path(); if (!path) -- 2.5.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: two RCU torture bugs
From: Paul E. McKenney paul...@linux.vnet.ibm.com
Date: Mon, 24 Aug 2015 11:50:36 -0700
@@ -695,7 +695,7 @@ static bool __maybe_unused torturing_tasks(void)
#define RCUTORTURE_TASKS_OPS
-static bool torturing_tasks(void)
+static bool __maybe_unused torturing_tasks(void)
{
return false;
}
This hunk gave a reject for me and I suspect was not intended to be included
in this fix?
I'll test the rest of the patch since that appears to be the important part.
:-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v2 1/5] mfd: 88pm800: Fix tabbing issue
Driver had coding style issues where spaces were used instead
of tabs. This patch fixes them all.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/mfd/88pm800.c | 125 --
1 file changed, 61 insertions(+), 64 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index f104a32..c4e097d 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -30,55 +30,55 @@
#include linux/of_device.h
/* Interrupt Registers */
-#define PM800_INT_STATUS1 (0x05)
+#define PM800_INT_STATUS1 0x05
#define PM800_ONKEY_INT_STS1 (1 0)
#define PM800_EXTON_INT_STS1 (1 1)
-#define PM800_CHG_INT_STS1 (1 2)
-#define PM800_BAT_INT_STS1 (1 3)
-#define PM800_RTC_INT_STS1 (1 4)
+#define PM800_CHG_INT_STS1 (1 2)
+#define PM800_BAT_INT_STS1 (1 3)
+#define PM800_RTC_INT_STS1 (1 4)
#define PM800_CLASSD_OC_INT_STS1 (1 5)
-#define PM800_INT_STATUS2 (0x06)
+#define PM800_INT_STATUS2 0x06
#define PM800_VBAT_INT_STS2(1 0)
#define PM800_VSYS_INT_STS2(1 1)
#define PM800_VCHG_INT_STS2(1 2)
#define PM800_TINT_INT_STS2(1 3)
-#define PM800_GPADC0_INT_STS2 (1 4)
+#define PM800_GPADC0_INT_STS2 (1 4)
#define PM800_TBAT_INT_STS2(1 5)
-#define PM800_GPADC2_INT_STS2 (1 6)
-#define PM800_GPADC3_INT_STS2 (1 7)
+#define PM800_GPADC2_INT_STS2 (1 6)
+#define PM800_GPADC3_INT_STS2 (1 7)
-#define PM800_INT_STATUS3 (0x07)
+#define PM800_INT_STATUS3 0x07
-#define PM800_INT_STATUS4 (0x08)
+#define PM800_INT_STATUS4 0x08
#define PM800_GPIO0_INT_STS4 (1 0)
#define PM800_GPIO1_INT_STS4 (1 1)
#define PM800_GPIO2_INT_STS4 (1 2)
#define PM800_GPIO3_INT_STS4 (1 3)
#define PM800_GPIO4_INT_STS4 (1 4)
-#define PM800_INT_ENA_1(0x09)
+#define PM800_INT_ENA_10x09
#define PM800_ONKEY_INT_ENA1 (1 0)
#define PM800_EXTON_INT_ENA1 (1 1)
-#define PM800_CHG_INT_ENA1 (1 2)
-#define PM800_BAT_INT_ENA1 (1 3)
-#define PM800_RTC_INT_ENA1 (1 4)
+#define PM800_CHG_INT_ENA1 (1 2)
+#define PM800_BAT_INT_ENA1 (1 3)
+#define PM800_RTC_INT_ENA1 (1 4)
#define PM800_CLASSD_OC_INT_ENA1 (1 5)
-#define PM800_INT_ENA_2(0x0A)
+#define PM800_INT_ENA_20x0A
#define PM800_VBAT_INT_ENA2(1 0)
#define PM800_VSYS_INT_ENA2(1 1)
#define PM800_VCHG_INT_ENA2(1 2)
#define PM800_TINT_INT_ENA2(1 3)
-#define PM800_INT_ENA_3(0x0B)
+#define PM800_INT_ENA_30x0B
#define PM800_GPADC0_INT_ENA3 (1 0)
#define PM800_GPADC1_INT_ENA3 (1 1)
#define PM800_GPADC2_INT_ENA3 (1 2)
#define PM800_GPADC3_INT_ENA3 (1 3)
#define PM800_GPADC4_INT_ENA3 (1 4)
-#define PM800_INT_ENA_4(0x0C)
+#define PM800_INT_ENA_40x0C
#define PM800_GPIO0_INT_ENA4 (1 0)
#define PM800_GPIO1_INT_ENA4 (1 1)
#define PM800_GPIO2_INT_ENA4 (1 2)
@@ -86,7 +86,7 @@
#define PM800_GPIO4_INT_ENA4 (1 4)
/* number of INT_ENA INT_STATUS regs */
-#define PM800_INT_REG_NUM (4)
+#define PM800_INT_REG_NUM 4
/* Interrupt Number in 88PM800 */
enum {
@@ -114,7 +114,7 @@ enum {
};
/* PM800: generation identification number */
-#define PM800_CHIP_GEN_ID_NUM 0x3
+#define PM800_CHIP_GEN_ID_NUM 0x3
static const struct i2c_device_id pm80x_id_table[] = {
{88PM800, 0},
@@ -129,47 +129,47 @@ static const struct of_device_id pm80x_of_match_table[] =
{
static struct resource rtc_resources[] = {
{
-.name = 88pm80x-rtc,
-.start = PM800_IRQ_RTC,
-.end = PM800_IRQ_RTC,
-.flags = IORESOURCE_IRQ,
-},
+ .name = 88pm80x-rtc,
+ .start = PM800_IRQ_RTC,
+ .end = PM800_IRQ_RTC,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct mfd_cell rtc_devs[] = {
{
-.name = 88pm80x-rtc,
-.of_compatible = marvell,88pm80x-rtc,
-.num_resources = ARRAY_SIZE(rtc_resources),
-.resources = rtc_resources[0],
-.id = -1,
-},
+ .name = 88pm80x-rtc,
+ .of_compatible = marvell,88pm80x-rtc,
+ .num_resources = ARRAY_SIZE(rtc_resources),
+ .resources = rtc_resources[0],
+ .id = -1,
+ },
};
static struct resource onkey_resources[] = {
{
-.name =
[PATCH-v2 0/5] clk: 88pm800: Add new clk provider driver for 88PM800 MFD
88PM800 family of devices provides multiple buffered 32.768 KHz clock output. 88PM800 : CLK32k_1, CLK32k_2 and CLK32k_3 88PM860 : CLK32k_1 and CLK32k_2 This patch-series adds new clock provider driver for enabling/disabling buffered 32Khz clock output from 88PM800 family of device. Adds clock device to MFD and updates the binding documentation. The PATCH [1/4], created separately, as it would be easy between maintainers to queue it. Note that, I have access to only 88PM800 and 88PM860 datasheet, so enabling support for only above two devices. Testing: - Boot tested on 88PM860 based platform - Clock enable/disable - Non PM860, to make sure that it won't lead to any issues V1 = V2: Link to V1: https://lkml.org/lkml/2015/7/21/298 - Added new patch to the series [1/5], fixing tabbing issue in the file - Removed unnecessary brackets around macro value - Used devm_kcalloc variants for array allocation instead of kzalloc. - Fixed all other trivial issues. Vaibhav Hiremath (5): mfd: 88pm800: Fix tabbing issue mfd: 88pm800: Update the header file with 32K clk related macros mfd: devicetree: bindings: Add clock subdevice node information clk: 88pm800: Add clk provider driver for 88pm800 family of devices mfd: 88pm800: Add support for clk subdevice Documentation/devicetree/bindings/mfd/88pm800.txt | 27 ++ drivers/clk/Kconfig | 8 + drivers/clk/Makefile | 1 + drivers/clk/clk-88pm800.c | 341 ++ drivers/mfd/88pm800.c | 150 ++ include/linux/mfd/88pm80x.h | 12 + 6 files changed, 475 insertions(+), 64 deletions(-) create mode 100644 drivers/clk/clk-88pm800.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v2 1/5] mfd: 88pm800: Fix tabbing issue
Driver had coding style issues where spaces were used instead
of tabs. This patch fixes them all.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/mfd/88pm800.c | 125 --
1 file changed, 61 insertions(+), 64 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index f104a32..c4e097d 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -30,55 +30,55 @@
#include linux/of_device.h
/* Interrupt Registers */
-#define PM800_INT_STATUS1 (0x05)
+#define PM800_INT_STATUS1 0x05
#define PM800_ONKEY_INT_STS1 (1 0)
#define PM800_EXTON_INT_STS1 (1 1)
-#define PM800_CHG_INT_STS1 (1 2)
-#define PM800_BAT_INT_STS1 (1 3)
-#define PM800_RTC_INT_STS1 (1 4)
+#define PM800_CHG_INT_STS1 (1 2)
+#define PM800_BAT_INT_STS1 (1 3)
+#define PM800_RTC_INT_STS1 (1 4)
#define PM800_CLASSD_OC_INT_STS1 (1 5)
-#define PM800_INT_STATUS2 (0x06)
+#define PM800_INT_STATUS2 0x06
#define PM800_VBAT_INT_STS2(1 0)
#define PM800_VSYS_INT_STS2(1 1)
#define PM800_VCHG_INT_STS2(1 2)
#define PM800_TINT_INT_STS2(1 3)
-#define PM800_GPADC0_INT_STS2 (1 4)
+#define PM800_GPADC0_INT_STS2 (1 4)
#define PM800_TBAT_INT_STS2(1 5)
-#define PM800_GPADC2_INT_STS2 (1 6)
-#define PM800_GPADC3_INT_STS2 (1 7)
+#define PM800_GPADC2_INT_STS2 (1 6)
+#define PM800_GPADC3_INT_STS2 (1 7)
-#define PM800_INT_STATUS3 (0x07)
+#define PM800_INT_STATUS3 0x07
-#define PM800_INT_STATUS4 (0x08)
+#define PM800_INT_STATUS4 0x08
#define PM800_GPIO0_INT_STS4 (1 0)
#define PM800_GPIO1_INT_STS4 (1 1)
#define PM800_GPIO2_INT_STS4 (1 2)
#define PM800_GPIO3_INT_STS4 (1 3)
#define PM800_GPIO4_INT_STS4 (1 4)
-#define PM800_INT_ENA_1(0x09)
+#define PM800_INT_ENA_10x09
#define PM800_ONKEY_INT_ENA1 (1 0)
#define PM800_EXTON_INT_ENA1 (1 1)
-#define PM800_CHG_INT_ENA1 (1 2)
-#define PM800_BAT_INT_ENA1 (1 3)
-#define PM800_RTC_INT_ENA1 (1 4)
+#define PM800_CHG_INT_ENA1 (1 2)
+#define PM800_BAT_INT_ENA1 (1 3)
+#define PM800_RTC_INT_ENA1 (1 4)
#define PM800_CLASSD_OC_INT_ENA1 (1 5)
-#define PM800_INT_ENA_2(0x0A)
+#define PM800_INT_ENA_20x0A
#define PM800_VBAT_INT_ENA2(1 0)
#define PM800_VSYS_INT_ENA2(1 1)
#define PM800_VCHG_INT_ENA2(1 2)
#define PM800_TINT_INT_ENA2(1 3)
-#define PM800_INT_ENA_3(0x0B)
+#define PM800_INT_ENA_30x0B
#define PM800_GPADC0_INT_ENA3 (1 0)
#define PM800_GPADC1_INT_ENA3 (1 1)
#define PM800_GPADC2_INT_ENA3 (1 2)
#define PM800_GPADC3_INT_ENA3 (1 3)
#define PM800_GPADC4_INT_ENA3 (1 4)
-#define PM800_INT_ENA_4(0x0C)
+#define PM800_INT_ENA_40x0C
#define PM800_GPIO0_INT_ENA4 (1 0)
#define PM800_GPIO1_INT_ENA4 (1 1)
#define PM800_GPIO2_INT_ENA4 (1 2)
@@ -86,7 +86,7 @@
#define PM800_GPIO4_INT_ENA4 (1 4)
/* number of INT_ENA INT_STATUS regs */
-#define PM800_INT_REG_NUM (4)
+#define PM800_INT_REG_NUM 4
/* Interrupt Number in 88PM800 */
enum {
@@ -114,7 +114,7 @@ enum {
};
/* PM800: generation identification number */
-#define PM800_CHIP_GEN_ID_NUM 0x3
+#define PM800_CHIP_GEN_ID_NUM 0x3
static const struct i2c_device_id pm80x_id_table[] = {
{88PM800, 0},
@@ -129,47 +129,47 @@ static const struct of_device_id pm80x_of_match_table[] =
{
static struct resource rtc_resources[] = {
{
-.name = 88pm80x-rtc,
-.start = PM800_IRQ_RTC,
-.end = PM800_IRQ_RTC,
-.flags = IORESOURCE_IRQ,
-},
+ .name = 88pm80x-rtc,
+ .start = PM800_IRQ_RTC,
+ .end = PM800_IRQ_RTC,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct mfd_cell rtc_devs[] = {
{
-.name = 88pm80x-rtc,
-.of_compatible = marvell,88pm80x-rtc,
-.num_resources = ARRAY_SIZE(rtc_resources),
-.resources = rtc_resources[0],
-.id = -1,
-},
+ .name = 88pm80x-rtc,
+ .of_compatible = marvell,88pm80x-rtc,
+ .num_resources = ARRAY_SIZE(rtc_resources),
+ .resources = rtc_resources[0],
+ .id = -1,
+ },
};
static struct resource onkey_resources[] = {
{
-.name =
[PATCH-v2 3/5] mfd: devicetree: bindings: Add clock subdevice node information
This patch updates the binding documentation for optional
clocks node and related information for buffered 32KHz clock.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Rob Herring r...@kernel.org
---
Documentation/devicetree/bindings/mfd/88pm800.txt | 27 +++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt
b/Documentation/devicetree/bindings/mfd/88pm800.txt
index 2c82fcb..bc6cb02 100644
--- a/Documentation/devicetree/bindings/mfd/88pm800.txt
+++ b/Documentation/devicetree/bindings/mfd/88pm800.txt
@@ -15,6 +15,26 @@ Optional properties :
Without this both BUCK1A and BUCK1B operates independently with 3A capacity.
(This property is only applicable to 88PM860)
+Optional nodes:
+- clocks: 88pm800 family of devices provide multiple buffered 32.768
+ KHz outputs, so to register these as clocks with common clock framework
+ instantiate a sub-node named clocks. It uses the common clock binding
+ documented in :
+ [Documentation/devicetree/bindings/clock/clock-bindings.txt]
+
+ - #clock-cells: should be 1.
+
+ - The following is the list of clocks generated by the controller. Each clock
+is assigned an identifier and client nodes use this identifier to specify
+the clock which they consume.
+Clock ID Devices
+--
+pm800_clk32k_1 0 88PM800 and 88PM860
+pm800_clk32k_2 1 88PM800 and 88PM860
+pm800_clk32k_3 2 88PM800
+
+ - compatible: Should be : marvell,88pm800-clk
+
88pm80x family of devices consists of varied group of sub-devices:
Device Supply Names Description
@@ -22,6 +42,7 @@ DeviceSupply Names Description
88pm80x-onkey : : On key
88pm80x-rtc: : RTC
88pm80x-regulator : : Regulators
+88pm80x-clk: : 32KHz Clk provider
Example:
@@ -33,6 +54,12 @@ Example:
interrupt-controller;
#interrupt-cells = 1;
+ pm800clk: clocks {
+ compatible = marvell,88pm800-clk;
+ #clock-cells = 1;
+ clock-output-names = xx, yy, zz;
+ };
+
regulators {
compatible = marvell,88pm80x-regulator;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v2 2/5] mfd: 88pm800: Update the header file with 32K clk related macros
Update header file with required macros for 32KHz buffered clock
output of 88PM800 family of device.
These macros will be used in clk provider driver.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
include/linux/mfd/88pm80x.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 122cfd2..0215d5f 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -91,6 +91,7 @@ enum {
/* Referance and low power registers */
#define PM800_LOW_POWER1 (0x20)
#define PM800_LOW_POWER2 (0x21)
+#define PM800_LOW_POWER2_XO_LJ_EN BIT(5)
#define PM800_LOW_POWER_CONFIG3(0x22)
#define PM800_LDOBK_FREEZE BIT(7)
@@ -138,6 +139,13 @@ enum {
#define PM800_ALARMBIT(5)
#define PM800_RTC1_USE_XO BIT(7)
+#define PM800_32K_OUTX_SEL_MASK0x3
+/* 32KHz clk output sel mode */
+#define PM800_32K_OUTX_SEL_ZERO0x0
+#define PM800_32K_OUTX_SEL_INT_32KHZ 0x1
+#define PM800_32K_OUTX_SEL_XO_32KHZ0x2
+#define PM800_32K_OUTX_SEL_HIZ 0x3
+
/* Regulator Control Registers: BUCK1,BUCK5,LDO1 have DVC */
/* buck registers */
@@ -208,6 +216,10 @@ enum {
#define PM800_PMOD_MEAS1 0x52
#define PM800_PMOD_MEAS2 0x53
+/* Oscillator control */
+#define PM800_OSC_CNTRL1 0x50
+#define PM800_OSC_CNTRL1_OSC_FREERUN_ENBIT(1)
+
#define PM800_GPADC0_MEAS1 0x54
#define PM800_GPADC0_MEAS2 0x55
#define PM800_GPADC1_MEAS1 0x56
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v2 5/5] mfd: 88pm800: Add support for clk subdevice
This patch adds mfd_cell/clk-subdevice for 88PM800 MFD
(and family of devices).
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/mfd/88pm800.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index c4e097d..a928eed 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -173,6 +173,14 @@ static const struct mfd_cell regulator_devs[] = {
},
};
+static struct mfd_cell clk_devs[] = {
+ {
+ .name = 88pm80x-clk,
+ .of_compatible = marvell,88pm800-clk,
+ .id = -1,
+ },
+};
+
static const struct regmap_irq pm800_irqs[] = {
/* INT0 */
[PM800_IRQ_ONKEY] = {
@@ -344,6 +352,17 @@ static int device_regulator_init(struct pm80x_chip *chip)
ARRAY_SIZE(regulator_devs), NULL, 0, NULL);
}
+static int device_clk_init(struct pm80x_chip *chip)
+{
+ if (chip-type == CHIP_PM800)
+ clk_devs[0].name = 88pm800-clk;
+ else if (chip-type == CHIP_PM860)
+ clk_devs[0].name = 88pm860-clk;
+
+ return mfd_add_devices(chip-dev, 0, clk_devs[0],
+ ARRAY_SIZE(clk_devs), NULL, 0, NULL);
+}
+
static int device_irq_init_800(struct pm80x_chip *chip)
{
struct regmap *map = chip-regmap;
@@ -511,6 +530,12 @@ static int device_800_init(struct pm80x_chip *chip)
goto out;
}
+ ret = device_clk_init(chip);
+ if (ret) {
+ dev_err(chip-dev, Failed to add clk subdev\n);
+ goto out;
+ }
+
return 0;
out_dev:
mfd_remove_devices(chip-dev);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v2 4/5] clk: 88pm800: Add clk provider driver for 88pm800 family of devices
88PM800 family of devices supports buffered 32KHz clock output,
for example,
88PM800: CLK32k_1, CLK32k_2 and CLK32k_3
88PM860: CLK32K_1 and CLK32K_2
This patch adds new clk provider driver to support enable/disable
of the 32KHz clock output from 88PM800 family of devices.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/clk/Kconfig | 8 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-88pm800.c | 341 ++
3 files changed, 350 insertions(+)
create mode 100644 drivers/clk/clk-88pm800.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 42f7120..c34c14d 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -167,6 +167,14 @@ config COMMON_CLK_CDCE706
---help---
This driver supports TI CDCE706 programmable 3-PLL clock synthesizer.
+config COMMON_CLK_88PM800
+ tristate Clock driver for 88PM800 MFD
+ depends on MFD_88PM800
+ ---help---
+ This driver supports 88PM800 88PM860 crystal oscillator
+ clock. These multi-function devices have two (88PM860) or three
+ (88PM800) fixed-rate output, clocked at 32KHz each.
+
source drivers/clk/bcm/Kconfig
source drivers/clk/hisilicon/Kconfig
source drivers/clk/qcom/Kconfig
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index c4cf075..5248cd3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_COMMON_CLK_88PM800) += clk-88pm800.o
diff --git a/drivers/clk/clk-88pm800.c b/drivers/clk/clk-88pm800.c
new file mode 100644
index 000..4c045e1
--- /dev/null
+++ b/drivers/clk/clk-88pm800.c
@@ -0,0 +1,341 @@
+/*
+ * clk-88pm800.c - Clock driver for 88PM800 family of devices
+ *
+ * This driver is created based on clk-s2mps11.c
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that 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 linux/module.h
+#include linux/err.h
+#include linux/of.h
+#include linux/clkdev.h
+#include linux/regmap.h
+#include linux/clk-provider.h
+#include linux/platform_device.h
+#include linux/mfd/88pm80x.h
+
+/* Number of clocks output from 88pm800 family of device */
+enum {
+ PM800_CLK32K_1 = 0,
+ PM800_CLK32K_2,
+ PM800_CLK32K_3,
+ PM800_CLKS_NUM,
+};
+
+struct pm800_clk {
+ struct pm80x_chip *chip;
+ struct device_node *clk_np;
+ struct clk_hw hw;
+ struct clk *clk;
+ struct clk_lookup *lookup;
+ u32 mask;
+ u32 shift;
+ unsigned int reg;
+};
+
+static struct pm800_clk *to_pm800_clk(struct clk_hw *hw)
+{
+ return container_of(hw, struct pm800_clk, hw);
+}
+
+static int pm800_clk_prepare(struct clk_hw *hw)
+{
+ struct pm800_clk *pm800 = to_pm800_clk(hw);
+
+ /* We always want to use XO clock */
+ return regmap_update_bits(pm800-chip-regmap,
+pm800-reg,
+pm800-mask,
+PM800_32K_OUTX_SEL_XO_32KHZ pm800-shift);
+}
+
+static void pm800_clk_unprepare(struct clk_hw *hw)
+{
+ struct pm800_clk *pm800 = to_pm800_clk(hw);
+
+ regmap_update_bits(pm800-chip-regmap, pm800-reg,
+ pm800-mask, ~pm800-mask);
+}
+
+static int pm800_clk_is_prepared(struct clk_hw *hw)
+{
+ int ret;
+ u32 val;
+ struct pm800_clk *pm800 = to_pm800_clk(hw);
+
+ ret = regmap_read(pm800-chip-regmap,
+ pm800-reg, val);
+ if (ret 0)
+ return -EINVAL;
+
+ return (val pm800-mask) pm800-shift;
+}
+
+static unsigned long pm800_clk_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return 32768;
+}
+
+static const struct clk_ops pm800_clk_ops = {
+ .prepare= pm800_clk_prepare,
+ .unprepare = pm800_clk_unprepare,
+ .is_prepared= pm800_clk_is_prepared,
+ .recalc_rate= pm800_clk_recalc_rate,
+};
+
+static struct clk_init_data pm800_clks_init[PM800_CLKS_NUM] = {
+ [PM800_CLK32K_1] = {
+ .name = pm800_clk32k_1,
+ .ops= pm800_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [PM800_CLK32K_2] = {
+ .name = pm800_clk32k_2,
+ .ops=
Re: [PATCH 2/2] cgroup: pids: fix invalid get/put usage
Hello,
On Sun, Aug 23, 2015 at 11:10:32PM +1000, Aleksa Sarai wrote:
Fix incorrect usage of css_get and css_put to put a different css in
pids_{cancel_,}attach() than the one grabbed in pids_can_attach(). This
could lead to quite serious memory leakage (and unsafe operations on the
putted css).
So, this patch looks correct to me but can you update the description
so that it notes that the source css doesn't go away while migration
is in progress and thus pinning is unnecessary to begin with?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/1] irqchip: imx-gpcv2: IMX GPCv2 driver for wakeup sources
IMX7D contains a new version of GPC IP block (GPCv2). It has two
major functions: power management and wakeup source management.
This patch adds a new irqchip driver to manage the interrupt wakeup
sources on IMX7D.
When the system is in WFI (wait for interrupt) mode, this GPC block
will be the first block on the platform to be activated and signaled.
Under normal wait mode during cpu idle, the system can be woke up
by any enabled interrupts. Under standby or suspend mode, the system
can only be woke up by the pre-defined wakeup sources.
Signed-off-by: Shenwei Wang shenwei.w...@freescale.com
Signed-off-by: Anson Huang b20...@freescale.com
---
Change log:
Renamed the enabled_irqs to saved_irq_mask in struct gpcv2_irqchip_data
Removed BUG_ON() in imx_gpcv2_irqchip_init to unify the error
handling codes.
drivers/irqchip/Kconfig | 7 +
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-imx-gpcv2.c | 275
3 files changed, 283 insertions(+)
create mode 100644 drivers/irqchip/irq-imx-gpcv2.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 120d815..3fc0fac 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -177,3 +177,10 @@ config RENESAS_H8300H_INTC
config RENESAS_H8S_INTC
bool
select IRQ_DOMAIN
+
+config IMX_GPCV2
+ bool
+ select IRQ_DOMAIN
+ help
+ Enables the wakeup IRQs for IMX platforms with GPCv2 block
+
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b8d4e96..8eb5f60 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
+obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
new file mode 100644
index 000..4a97afa
--- /dev/null
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/slab.h
+#include linux/irqchip.h
+#include linux/syscore_ops.h
+
+#define IMR_NUM4
+#define GPC_MAX_IRQS(IMR_NUM * 32)
+
+#define GPC_IMR1_CORE0 0x30
+#define GPC_IMR1_CORE1 0x40
+
+struct gpcv2_irqchip_data {
+ struct raw_spinlockrlock;
+ void __iomem *gpc_base;
+ u32 wakeup_sources[IMR_NUM];
+ u32 saved_irq_mask[IMR_NUM];
+ u32 cpu2wakeup;
+};
+
+static struct gpcv2_irqchip_data *imx_gpcv2_instance;
+
+u32 imx_gpcv2_get_wakeup_source(u32 **sources)
+{
+ if (!imx_gpcv2_instance)
+ return 0;
+
+ if (sources)
+ *sources = imx_gpcv2_instance-wakeup_sources;
+
+ return IMR_NUM;
+}
+
+static int gpcv2_wakeup_source_save(void)
+{
+ struct gpcv2_irqchip_data *cd;
+ void __iomem *reg;
+ int i;
+
+ cd = imx_gpcv2_instance;
+ if (!cd)
+ return 0;
+
+ for (i = 0; i IMR_NUM; i++) {
+ reg = cd-gpc_base + cd-cpu2wakeup + i * 4;
+ cd-saved_irq_mask[i] = readl_relaxed(reg);
+ writel_relaxed(cd-wakeup_sources[i], reg);
+ }
+
+ return 0;
+}
+
+static void gpcv2_wakeup_source_restore(void)
+{
+ struct gpcv2_irqchip_data *cd;
+ void __iomem *reg;
+ int i;
+
+ cd = imx_gpcv2_instance;
+ if (!cd)
+ return;
+
+ for (i = 0; i IMR_NUM; i++) {
+ reg = cd-gpc_base + cd-cpu2wakeup + i * 4;
+ writel_relaxed(cd-saved_irq_mask[i], reg);
+ }
+}
+
+static struct syscore_ops imx_gpcv2_syscore_ops = {
+ .suspend= gpcv2_wakeup_source_save,
+ .resume = gpcv2_wakeup_source_restore,
+};
+
+static int imx_gpcv2_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ struct gpcv2_irqchip_data *cd = d-chip_data;
+ unsigned int idx = d-hwirq / 32;
+ unsigned long flags;
+ void __iomem *reg;
+ u32 mask, val;
+
+ raw_spin_lock_irqsave(cd-rlock, flags);
+ reg = cd-gpc_base + cd-cpu2wakeup + idx * 4;
+ mask = 1 d-hwirq % 32;
+ val = cd-wakeup_sources[idx];
+
+ cd-wakeup_sources[idx] = on ? (val ~mask) : (val | mask);
+ raw_spin_unlock_irqrestore(cd-rlock, flags);
+
+ /*
+* Do *not* call into the parent, as the GIC doesn't have any
+* wake-up facility...
+*/
+
+ return 0;
+}
+
+static void imx_gpcv2_irq_unmask(struct irq_data *d)
+{
+ struct
[Fwd: Re: [PATCH v4 1/2] vTPM: support little endian guests]
Hi Peter, Did you the explanations in the following reply make sense to you? If you needed more clarifications, please advice. Thanks! Forwarded Message From: Hon Ching(Vicky) Lo hon...@linux.vnet.ibm.com To: Peter Hüwe peterhu...@gmx.de Cc: tpmdd-de...@lists.sourceforge.net, Ashley Lai ash...@ashleylai.com, Vicky Lo honclo2...@gmail.com, linux-kernel@vger.kernel.org, Joy Latten jmlat...@linux.vnet.ibm.com Subject: Re: [PATCH v4 1/2] vTPM: support little endian guests Date: Fri, 17 Jul 2015 16:07:50 -0400 On Thu, 2015-07-16 at 20:43 +0200, Peter Hüwe wrote: Hi Vicky, Am Donnerstag, 16. Juli 2015, 19:54:15 schrieb Hon Ching(Vicky) Lo: Hi Peter, On Mon, 2015-07-13 at 23:08 +0200, Peter Hüwe wrote: Hi Vicky, sorry for the late reply This patch makes the code endianness independent. We defined a macro do_endian_conversion to apply endianness to raw integers in the event entries so that they will be displayed properly. tpm_binary_bios_measurements_show() is modified for the display. Signed-off-by: Hon Ching(Vicky) Lo hon...@linux.vnet.ibm.com Signed-off-by: Joy Latten jmlat...@linux.vnet.ibm.com b/drivers/char/tpm/tpm_eventlog.h index e7da086..267bfbd 100644 --- a/drivers/char/tpm/tpm_eventlog.h +++ b/drivers/char/tpm/tpm_eventlog.h @@ -6,6 +6,12 @@ #define MAX_TEXT_EVENT 1000/* Max event string length */ #define ACPI_TCPA_SIG TCPA /* 0x41504354 /'TCPA' */ +#ifdef CONFIG_PPC64 +#define do_endian_conversion(x) be32_to_cpu(x) +#else +#define do_endian_conversion(x) x +#endif Why is this macro needed? shouldn't the be32_to_cpu macro already do correct thing? Or am I missing something here? Thanks, Peter The macro is defined to not do the conversion in the architecture that does not need it. Unfortunately I'm still not convinced this is needed? be32_to_cpu(x) should already do the right thing if no conversion is needed ? (being defined as (x)) Or is it not? Peter include/linux/byteorder/generic.h: #define be32_to_cpu __be32_to_cpu include/uapi/linux/byteorder/little_endian.h: #define __be32_to_cpu(x) __swab32((__force __u32)(__be32)(x)) include/uapi/linux/byteorder/big_endian.h: #define __be32_to_cpu(x) ((__force __u32)(__be32)(x)) The above defines show that be32_to_cpu(x) would do a byte swap on x. The defines for __be32_to_cpu(x) in both little_endian.h and big_endian.h are doing the right thing that you mentioned. However, with the architecture differences between ppc64 and x86 for instance, we need the new macro to not do the conversion. The power firmware will always be in BE. Therefore, firmware will pass BE data to an LE operating system, so the conversion is needed. Whereas for an x86 system, BIOS gives LE data to the LE OS. (i.e. the macro is needed for LE support. Does it make sense? Vicky -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes
On Mon 24-08-15 13:11:44, Tejun Heo wrote: Hello, On Mon, Aug 24, 2015 at 10:51:50AM -0400, Tejun Heo wrote: Bah, I see the problem and indeed it was introduced by commit e79729123f639 writeback: don't issue wb_writeback_work if clean. The problem is that we bail out of sync_inodes_sb() if there is no dirty IO. Which is wrong because we have to wait for any outstanding IO (i.e. call wait_sb_inodes()) regardless of dirty state! And that also explains why Tejun's patch fixes the problem because it backs out the change to the exit condition in sync_inodes_sb(). Dang, I'm an idiot sandwich. A question tho, so this means that an inode may contain dirty or writeback pages w/o the inode being on one of the dirty lists. Looking at the generic filesystem and writeback code, this doesn't seem true in general. Is this something xfs specific? Inode may contain writeback pages (but not dirty pages) without being on any of the dirty lists. That is correct. Josef Bacik had patches to create a list to track inodes with pages under writeback but they clashed with your patch series and they didn't get rebased yet AFAIR. Honza -- Jan Kara j...@suse.com SUSE Labs, CR -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: acpi: Generic function for setting up PCI device DMA coherency
Hi Bjorn,
On 8/25/15 00:32, Bjorn Helgaas wrote:
Here it is again.
On Thu, Aug 13, 2015 at 6:50 PM, Bjorn Helgaas bhelg...@google.com wrote:
Hi Suravee,
On Thu, Aug 13, 2015 at 04:58:45PM +0700, Suravee Suthikulpanit wrote:
This patch refactors of_pci_dma_configure() into a more generic
pci_dma_configure(), which can be reused by non-OF code.
Then, it adds support for setting up PCI device DMA coherency from
ACPI _CCA object that should normally be specified in the DSDT node
of its PCI host bridge..
Since this does two things:
1) Rename of_pci_dma_configure() and move it to PCI
2) Add _CCA support,
maybe it should be split into two patches?
Sure, I can take care of that and separate them into two patches.
There are a couple more comments below.
While looking at this, I thought some of the existing code could be
made simpler and easier to follow. I appended a couple possible patches;
you can incorporate them or ignore them, whatever seems best to you.
Bjorn
Please see my response below.
[...]
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cefd636..e2fcd3b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -6,12 +6,14 @@
#include linux/delay.h
#include linux/init.h
#include linux/pci.h
-#include linux/of_pci.h
+#include linux/of_device.h
#include linux/pci_hotplug.h
#include linux/slab.h
#include linux/module.h
#include linux/cpumask.h
#include linux/pci-aspm.h
+#include linux/acpi.h
+#include linux/property.h
#include asm-generic/pci-bridge.h
#include pci.h
@@ -1544,6 +1546,35 @@ static void pci_init_capabilities(struct pci_dev *dev)
pci_enable_acs(dev);
}
+/**
+ * pci_dma_configure - Setup DMA configuration
+ * @pci_dev: ptr to pci_dev struct of the PCI device
+ *
+ * Function to update PCI devices's DMA configuration using the same
+ * info from the OF node or ACPI node of host bridge's parent (if any).
+ */
+static void pci_dma_configure(struct pci_dev *pci_dev)
Almost all pci_dev pointers in probe.c are named dev, so I would use
that for this one, too. I probably would just drop the struct device
*dev below and use dev-dev the two places you need it. That's a
common idiom in PCI.
I'll take care of this.
+{
+ struct device *dev = pci_dev-dev;
+ struct device *bridge = pci_get_host_bridge_device(pci_dev);
+ struct acpi_device *adev;
+ bool coherent;
+
+ if (has_acpi_companion(bridge)) {
+ adev = to_acpi_node(bridge-fwnode);
+ if (acpi_check_dma(adev, coherent))
+ arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
+ } else {
+ struct device *host = bridge-parent;
+ if (!host)
+ return;
+
+ of_dma_configure(dev, host-of_node);
+ }
Why is this check reversed with respect to device_dma_is_coherent()?
In device_dma_is_coherent(), we first look for an OF property, then look
for ACPI _CCA. But here we check for _CCA, then for OF.
I was trying to save some additional logic. But, think again I should
not have done so. I'll fix this.
[...]
commit 18183957888f601807ca0e166516ae60f682eb62
Author: Bjorn Helgaas bhelg...@google.com
Date: Thu Aug 13 20:01:21 2015 -0500
ACPI / scan: Move _CCA comments to acpi_init_coherency()
Move the comments about how we handle _CCA to the code that looks at _CCA,
and fix a couple typos.
No functional change.
Signed-off-by: Bjorn Helgaas bhelg...@google.com
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index ec25635..a12e522 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2188,6 +2188,22 @@ static void acpi_init_coherency(struct acpi_device *adev)
acpi_status status;
struct acpi_device *parent = adev-parent;
+ /**
+* Currently, we only support _CCA=1 (i.e. coherent_dma=1)
+* This should be equivalent to specifying dma-coherent for
+* a device in OF.
+*
+* For the case when _CCA=0 (i.e. coherent_dma=0 cca_seen=1),
+* we have two choices:
+* case 1. Do not support and disable DMA.
+* case 2. Support but rely on arch-specific cache maintenance for
+* non-coherent DMA operations.
+* Currently, we implement case 1 above.
+*
+* For the case when _CCA is missing (i.e. cca_seen=0) and
+* platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
+* and fallback to arch-specific default handling.
+*/
if (parent parent-flags.cca_seen) {
/*
* From ACPI spec, OSPM will ignore _CCA if an ancestor
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 83061ca..718942b 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -389,24 +389,6 @@ static inline bool acpi_check_dma(struct acpi_device
*adev, bool *coherent)
if (!adev)
return ret;
- /**
-* Currently,
Re: [PATCH] staging: fbtft: Made into two lines
On Sun, Aug 23, 2015 at 07:00:23PM +0530, Aparna Karuthodi wrote: Oh! Sorry! I made the changes to correct the faults you figured out. Is it okay now? Resubmit it properly with PATCH v2 in the title and a good commit message. Signed-off-by: Aparna Karuthodi kdasapa...@gmail.com --- drivers/staging/fbtft/fb_pcd8544.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fb_pcd8544.c b/drivers/staging/fbtft/fb_pcd8544.c index cf87ce8..925511f 100644 --- a/drivers/staging/fbtft/fb_pcd8544.c +++ b/drivers/staging/fbtft/fb_pcd8544.c @@ -34,8 +34,8 @@ #define WIDTH 84 #define HEIGHT 48 #define TXBUFLEN (84*6) -#define DEFAULT_GAMMA 40 /* gamma is used to control contrast in this driver */ Isn't this comment supposed to be on the previous line (the removed line)? Check if you haven't messed this up +#define DEFAULT_GAMMA 40 static unsigned tc; module_param(tc, uint, 0); -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/11] x86/dma: RIP MTRR and dma write-combine API rename
From: Luis R. Rodriguez mcg...@suse.com Ingo, This is my pending series of patches for both write-combining and moving Linux' use of MTRR into the grave. It combines three set of straggler patch series which have been pending integration for a while now. The rename patches do not depend in any way with the MTRR patches but I've combined them here as they are all pending and relating to write-combining. I explain why integration of such patches has been delayed but also provide reasoning for why I believe its time to merge them. 1) The DMA API rename for write-combining goes with the old naming convention defines added as suggested by you for any possible stragglers which may come up as this goes through and gets merged. We can remove the old define mappings after a release once this gets sucked in and things settle. These patches have been in Boris tree for a while but I keep having to refresh them as the kernel moves on, the addition of the old mapping should allow us to merge this without any collateral. 2) The PCI driver changes go with Tomi Valkeinen's Acks as well as Arnd Bergmann's own Acks for the PCI and asm-generic changes. This series was technically acknowledged by Bjorn to be correct and acceptable but his preference was for this to not use EXPORT_SYMBOL_GPL() as not *all* write-combine APIs are using EXPORT_SYMBOL_GPL(). Our goal on x86 though is to not deal with bug reports for new PAT APIs [0] and since its now clear through documentation that its up to the maintainers / developers if they decide to use EXPORT_SYMBOL_GPL() for new *features* [1] I keep that practice in alignment with our own x86 goals to avoid bug reports and issues with proprietary drivers on new PAT interfaces. Bjorn was happy for this to go through someone else's tree, in particular Arnd's. Arnd Acked the series [2] but is unable to take these patches in at this time as he's out on paternal leave so sending these through you with the respective Acks. Boris has been hugely instrumental on helping review all MTRR related series, these were sitting on his queue for a while, but he's also unavailable now as he's on vacation. 3) Unexporting direct MTRR access. This is last patch, I had posted this first on March 2015 when [3] I originally had meshed up all the MTRR work into one giant series. I ending up splitting up all the work into *over* 12 series. Now that all the work is merged except these few patches I've combined that patch as the last part of this series. I've amended an obituary note for MTRR regarding platform firmware access to MTRR based on recent discussions [4] and updated the documentation to reflect the status quo for Linux. All of these patches have been tested by the 0-day bot machine. The only thing *new* here is just my obituary amended documentation note for platform firmware access to MTRRs on the last patch based hugely on review with Toshi. [0] http://lkml.kernel.org/r/1424961893.17007.139.ca...@misato.fc.hp.com [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=582ed8d51e2b6cb8a168c94852bca482685c2509 [2] http://lkml.kernel.org/r/2962702.QXZzP3RbKY@wuerfel [3] http://lkml.kernel.org/r/1426893517-2511-48-git-send-email-mcg...@do-not-panic.com [4] http://lkml.kernel.org/r/1438991330.3109.196.ca...@hp.com Luis R. Rodriguez (11): PCI: Add pci_ioremap_wc_bar() drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() drivers/video/fbdev/kyrofb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer PCI: Add pci_iomap_wc() variants drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc() drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc() drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc() drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style dma: rename dma_*_writecombine() to dma_*_wc() mtrr: bury MTRR - unexport mtrr_add() and mtrr_del() Documentation/x86/mtrr.txt| 20 -- arch/arm/mach-lpc32xx/phy3250.c | 13 +++--- arch/arm/mach-netx/fb.c | 14 +++ arch/arm/mach-nspire/clcd.c | 13 +++--- arch/avr32/include/asm/dma-mapping.h | 20 +- arch/avr32/mm/dma-coherent.c | 12 +++--- arch/metag/include/asm/dma-mapping.h | 4 +- arch/metag/kernel/dma.c | 6 +-- arch/x86/kernel/cpu/mtrr/main.c | 2 - drivers/dma/iop-adma.c| 9 +++-- drivers/dma/mv_xor.c | 4 +- drivers/dma/qcom_bam_dma.c| 14 +++ drivers/gpu/drm/drm_gem_cma_helper.c | 13 +++--- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 13 +++--- drivers/gpu/drm/omapdrm/omap_gem.c| 8 ++-- drivers/gpu/drm/sti/sti_cursor.c | 13 +++---
[PATCH v4 01/11] PCI: Add pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advantage of PAT when available. It should help
with the transition of converting video drivers over to ioremap_wc()
to help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache(), see:
de33c442ed2a (x86 PAT: fix performance drop for glx, use UC minus for
ioremap(),
ioremap_nocache() and pci_mmap_page_range())
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Arnd Bergmann a...@arndb.de
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: b...@kernel.crashing.org
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Davidlohr Bueso dbu...@suse.de
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Juergen Gross jgr...@suse.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mel Gorman mgor...@suse.de
Cc: m...@redhat.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Toshi Kani toshi.k...@hp.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Vlastimil Babka vba...@suse.cz
Link:
http://lkml.kernel.org/r/1435195342-26879-2-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/pci/pci.c | 14 ++
include/linux/pci.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8037c27beb05..33867b8a4bc9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -138,6 +138,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int
bar)
return ioremap_nocache(res-start, resource_size(res));
}
EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+ /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+ if (!(pci_resource_flags(pdev, bar) IORESOURCE_MEM)) {
+ WARN_ON(1);
+ return NULL;
+ }
+ return ioremap_wc(pci_resource_start(pdev, bar),
+ pci_resource_len(pdev, bar));
+}
+EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
#endif
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 88bee285b93d..2b2d7d44c21a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1701,6 +1701,7 @@ static inline void pci_mmcfg_late_init(void) { }
int pci_ext_cfg_avail(void);
void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar);
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar);
#ifdef CONFIG_PCI_IOV
int pci_iov_virtfn_bus(struct pci_dev *dev, int id);
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 04/11] drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but since we
know the framebuffer is isolated already on an ioremap() we can take
advantage of write combining for performance where possible.
In this case there are a few motivations for this:
a) Take advantage of PAT when available.
b) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()).
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Juergen Gross jgr...@suse.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rob Clark robdcl...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-5-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a02588..f19133a80e8c 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -662,7 +662,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
info-fix.smem_start = fb_phys;
info-fix.smem_len = pci_resource_len(pdev, 1);
- info-screen_base = pci_ioremap_bar(pdev, 1);
+ info-screen_base = pci_ioremap_wc_bar(pdev, 1);
if (!info-screen_base) {
dev_err(pdev-dev, gxt4500: cannot map framebuffer\n);
goto err_unmap_regs;
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc()
From: Luis R. Rodriguez mcg...@suse.com
Rename dma_*_writecombine() to dma_*_wc(), so that the naming
is coherent across the various write-combining APIs.
The following Coccinelle SmPL patch was used for this simple
transformation:
@ rename_dma_alloc_writecombine @
expression dev, size, dma_addr, gfp;
@@
-dma_alloc_writecombine(dev, size, dma_addr, gfp)
+dma_alloc_wc(dev, size, dma_addr, gfp)
@ rename_dma_free_writecombine @
expression dev, size, cpu_addr, dma_addr;
@@
-dma_free_writecombine(dev, size, cpu_addr, dma_addr)
+dma_free_wc(dev, size, cpu_addr, dma_addr)
@ rename_dma_mmap_writecombine @
expression dev, vma, cpu_addr, dma_addr, size;
@@
-dma_mmap_writecombine(dev, vma, cpu_addr, dma_addr, size)
+dma_mmap_wc(dev, vma, cpu_addr, dma_addr, size)
Generated-by: Coccinelle SmPL
Suggested-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
arch/arm/mach-lpc32xx/phy3250.c | 13 ++---
arch/arm/mach-netx/fb.c | 14 ++
arch/arm/mach-nspire/clcd.c | 13 ++---
arch/avr32/include/asm/dma-mapping.h | 20 ++--
arch/avr32/mm/dma-coherent.c | 12 ++--
arch/metag/include/asm/dma-mapping.h | 4 ++--
arch/metag/kernel/dma.c | 6 +++---
drivers/dma/iop-adma.c| 8
drivers/dma/mv_xor.c | 4 ++--
drivers/dma/qcom_bam_dma.c| 14 +++---
drivers/gpu/drm/drm_gem_cma_helper.c | 13 ++---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 13 ++---
drivers/gpu/drm/omapdrm/omap_gem.c| 8
drivers/gpu/drm/sti/sti_cursor.c | 13 ++---
drivers/gpu/drm/sti/sti_gdp.c | 3 +--
drivers/gpu/drm/sti/sti_hqvdp.c | 6 +++---
drivers/gpu/drm/tegra/gem.c | 11 +--
drivers/gpu/host1x/cdma.c | 8
drivers/gpu/host1x/job.c | 10 --
drivers/media/platform/coda/coda-bit.c| 10 +-
drivers/video/fbdev/acornfb.c | 4 ++--
drivers/video/fbdev/amba-clcd-versatile.c | 14 ++
drivers/video/fbdev/amba-clcd.c | 4 ++--
drivers/video/fbdev/atmel_lcdfb.c | 9 +
drivers/video/fbdev/ep93xx-fb.c | 9 +++--
drivers/video/fbdev/gbefb.c | 8
drivers/video/fbdev/imxfb.c | 12 ++--
drivers/video/fbdev/mx3fb.c | 9 -
drivers/video/fbdev/nuc900fb.c| 8
drivers/video/fbdev/omap/lcdc.c | 16
drivers/video/fbdev/pxa168fb.c| 8
drivers/video/fbdev/pxafb.c | 4 ++--
drivers/video/fbdev/s3c-fb.c | 7 +++
drivers/video/fbdev/s3c2410fb.c | 8
drivers/video/fbdev/sa1100fb.c| 8
include/linux/dma-mapping.h | 16
sound/arm/pxa2xx-pcm-lib.c| 20
sound/soc/fsl/imx-pcm-fiq.c | 10 --
sound/soc/nuc900/nuc900-pcm.c | 6 ++
sound/soc/omap/omap-pcm.c | 12
40 files changed, 183 insertions(+), 212 deletions(-)
diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index 77d6b1bab278..ee06fabdf60e 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -86,8 +86,8 @@ static int lpc32xx_clcd_setup(struct clcd_fb *fb)
{
dma_addr_t dma;
- fb-fb.screen_base = dma_alloc_writecombine(fb-dev-dev,
- PANEL_SIZE, dma, GFP_KERNEL);
+ fb-fb.screen_base = dma_alloc_wc(fb-dev-dev, PANEL_SIZE, dma,
+ GFP_KERNEL);
if (!fb-fb.screen_base) {
printk(KERN_ERR CLCD: unable to map framebuffer\n);
return -ENOMEM;
@@ -116,15 +116,14 @@ static int lpc32xx_clcd_setup(struct clcd_fb *fb)
static int lpc32xx_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
{
- return dma_mmap_writecombine(fb-dev-dev, vma,
- fb-fb.screen_base, fb-fb.fix.smem_start,
- fb-fb.fix.smem_len);
+ return dma_mmap_wc(fb-dev-dev, vma, fb-fb.screen_base,
+ fb-fb.fix.smem_start, fb-fb.fix.smem_len);
}
static void lpc32xx_clcd_remove(struct clcd_fb *fb)
{
- dma_free_writecombine(fb-dev-dev, fb-fb.fix.smem_len,
- fb-fb.screen_base, fb-fb.fix.smem_start);
+ dma_free_wc(fb-dev-dev, fb-fb.fix.smem_len, fb-fb.screen_base,
+ fb-fb.fix.smem_start);
}
/*
diff --git a/arch/arm/mach-netx/fb.c b/arch/arm/mach-netx/fb.c
index d122ee6ab991..8814ee5e98fd 100644
--- a/arch/arm/mach-netx/fb.c
+++ b/arch/arm/mach-netx/fb.c
@@ -42,8 +42,8 @@ int netx_clcd_setup(struct clcd_fb *fb)
fb-panel = netx_panel;
- fb-fb.screen_base =
[PATCH v4 02/11] drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that also
ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range())
The conversion done is expressed by the following Coccinelle SmPL
patch, it additionally required manual intervention to address all the
ifdeffery and removal of redundant things which arch_phys_wc_add()
already addresses such as verbose message about when MTRR fails and
doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: b...@kernel.crashing.org
Cc: Benoit Taine benoit.ta...@lip6.fr
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jingoo Han jg1@samsung.com
Cc: Juergen Gross jgr...@suse.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rob Clark robdcl...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-3-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/video/fbdev/i740fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/i740fb.c b/drivers/video/fbdev/i740fb.c
index a2b4204b42bb..452e1163ad02 100644
--- a/drivers/video/fbdev/i740fb.c
+++ b/drivers/video/fbdev/i740fb.c
@@ -27,24 +27,15 @@
#include linux/console.h
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
#include i740_reg.h
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
struct i740fb_par {
unsigned char __iomem *regs;
bool has_sgram;
-#ifdef CONFIG_MTRR
- int mtrr_reg;
-#endif
+ int wc_cookie;
bool ddc_registered;
struct i2c_adapter ddc_adapter;
struct i2c_algo_bit_data ddc_algo;
@@ -1040,7 +1031,7 @@ static int i740fb_probe(struct pci_dev *dev, const struct
pci_device_id *ent)
goto err_request_regions;
}
- info-screen_base = pci_ioremap_bar(dev, 0);
+ info-screen_base = pci_ioremap_wc_bar(dev, 0);
if (!info-screen_base) {
dev_err(info-device, error remapping base\n);
ret = -ENOMEM;
@@ -1144,13 +1135,9 @@ static int i740fb_probe(struct pci_dev *dev, const
struct pci_device_id *ent)
fb_info(info, %s frame buffer device\n, info-fix.id);
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
- if (mtrr) {
- par-mtrr_reg = -1;
- par-mtrr_reg = mtrr_add(info-fix.smem_start,
- info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ if (mtrr)
+ par-wc_cookie = arch_phys_wc_add(info-fix.smem_start,
+ info-fix.smem_len);
return 0;
err_reg_framebuffer:
@@ -1177,13 +1164,7 @@ static void i740fb_remove(struct pci_dev *dev)
if (info) {
[PATCH v4 09/11] drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style
From: Luis R. Rodriguez mcg...@suse.com
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Untangle both calls according to kernel coding style.
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Vinod Koul vinod.k...@intel.com
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams dan.j.willi...@intel.com
Cc: dmaeng...@vger.kernel.org
Cc: x...@kernel.org
Link:
http://lkml.kernel.org/r/1435258191-543-2-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/dma/iop-adma.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 998826854fdd..e4f43125e0fb 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -1300,10 +1300,11 @@ static int iop_adma_probe(struct platform_device *pdev)
* note: writecombine gives slightly better performance, but
* requires that we explicitly flush the writes
*/
- if ((adev-dma_desc_pool_virt = dma_alloc_writecombine(pdev-dev,
- plat_data-pool_size,
- adev-dma_desc_pool,
- GFP_KERNEL)) == NULL) {
+ adev-dma_desc_pool_virt = dma_alloc_writecombine(pdev-dev,
+ plat_data-pool_size,
+ adev-dma_desc_pool,
+ GFP_KERNEL);
+ if (!adev-dma_desc_pool_virt) {
ret = -ENOMEM;
goto err_free_adev;
}
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 07/11] drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()).
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jingoo Han jg1@samsung.com
Cc: Juergen Gross jgr...@suse.com
Cc: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-9-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/video/fbdev/s3fb.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a37f04..13b109073c63 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
#include linux/i2c.h
#include linux/i2c-algo-bit.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct s3fb_info {
int chip, rev, mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
static char *mode_option;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
-
static int fasttext = 1;
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
MODULE_PARM_DESC(mode_option, Default video mode ('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, Default video mode ('640x480-8@60', etc)
(deprecated));
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
module_param(fasttext, int, 0644);
MODULE_PARM_DESC(fasttext, Enable S3 fast text mode (1=enable, 0=disable,
default=1));
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info-fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -1365,12 +1354,9 @@
Re: [PATCH v9 1/1] irqchip: imx-gpcv2: IMX GPCv2 driver for wakeup sources
On Mon, 24 Aug 2015, Shenwei Wang wrote: Signed-off-by: Shenwei Wang shenwei.w...@freescale.com Signed-off-by: Anson Huang b20...@freescale.com Ok, last question. How is Anson related to this? He did not convey your patch and in the first posted versions his SOB was never there. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 11/11] mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
From: Luis R. Rodriguez mcg...@suse.com The crusade to replace mtrr_add() with architecture agnostic arch_phys_wc_add() is complete, this will ensure write-combining implementations (PAT on x86) is taken advantage instead of using MTRR. With the crusade done now, hide direct MTRR access for drivers. Update x86 documentation on MTRR to reflect the completion of the phasing out of direct access to MTRR, also add a note on platform firmware code use of MTRRs based on the obituary discussion of MTRRs on Linux [0]. [0] http://lkml.kernel.org/r/1438991330.3109.196.ca...@hp.com Cc: Toshi Kani toshi.k...@hp.com Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: Borislav Petkov b...@suse.de Cc: Dave Hansen dave.han...@linux.intel.com Cc: Suresh Siddha sbsid...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc: Juergen Gross jgr...@suse.com Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Andy Lutomirski l...@amacapital.net Cc: Dave Airlie airl...@redhat.com Cc: Antonino Daplas adap...@gmail.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Ville Syrjälä syrj...@sci.fi Cc: Mel Gorman mgor...@suse.de Cc: Vlastimil Babka vba...@suse.cz Cc: Davidlohr Bueso dbu...@suse.de Cc: Doug Ledford dledf...@redhat.com Cc: Andy Walls awa...@md.metrocast.net Cc: x...@kernel.org Cc: net...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez mcg...@suse.com --- Documentation/x86/mtrr.txt | 20 arch/x86/kernel/cpu/mtrr/main.c | 2 -- 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt index 860bc3adc223..8a0bdb6e7370 100644 --- a/Documentation/x86/mtrr.txt +++ b/Documentation/x86/mtrr.txt @@ -6,10 +6,22 @@ Luis R. Rodriguez mcg...@do-not-panic.com - April 9, 2015 === Phasing out MTRR use -MTRR use is replaced on modern x86 hardware with PAT. Over time the only type -of effective MTRR that is expected to be supported will be for write-combining. -As MTRR use is phased out device drivers should use arch_phys_wc_add() to make -MTRR effective on non-PAT systems while a no-op on PAT enabled systems. +MTRR use is replaced on modern x86 hardware with PAT. Direct MTRR use by +drivers on Linux is now completely phased out, device drivers should use +arch_phys_wc_add() in combination with ioremap_wc() to make MTRR effective on +non-PAT systems while a no-op but equally effective on PAT enabled systems. + +Even if Linux does not use MTRR directly some x86 platform firmware may still +set up MTRRs early before booting the OS, they do this as some platform +firmware may still have implemented access to MTRRs which would be controlled +and handled by the platform firmware directly. An example of platform use of +MTRR is through the use of SMI handlers, one case could be for fan control, +the platform code would need uncachable access to some of its fan control +registers. Such platform access does not need any Operating System MTRR code in +place other than mtrr_type_lookup() to ensure any OS specific mapping requests +are aligned with platform MTRR setup. If MTRRs are only set up by the platform +firmware code though and the OS does not make any specific MTRR mapping +requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID. For details refer to Documentation/x86/pat.txt. diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index e7ed0d8ebacb..f891b4750f04 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -448,7 +448,6 @@ int mtrr_add(unsigned long base, unsigned long size, unsigned int type, return mtrr_add_page(base PAGE_SHIFT, size PAGE_SHIFT, type, increment); } -EXPORT_SYMBOL(mtrr_add); /** * mtrr_del_page - delete a memory type region @@ -537,7 +536,6 @@ int mtrr_del(int reg, unsigned long base, unsigned long size) return -EINVAL; return mtrr_del_page(reg, base PAGE_SHIFT, size PAGE_SHIFT); } -EXPORT_SYMBOL(mtrr_del); /** * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable -- 2.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 08/11] drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()).
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jingoo Han jg1@samsung.com
Cc: Juergen Gross jgr...@suse.com
Cc: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Rob Clark robdcl...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-10-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/video/fbdev/vt8623fb.c | 31 ++-
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index 8bac309c24b9..dd0f18e42d3e 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
#include linux/console.h /* Why should fb driver call console functions?
because console_lock() */
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct vt8623fb_info {
char __iomem *mmio_base;
- int mtrr_reg;
+ int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
/* Module parameters */
static char *mode_option = 640x480-8@60;
-
-#ifdef CONFIG_MTRR
static int mtrr = 1;
-#endif
MODULE_AUTHOR((c) 2006 Ondrej Zajicek santi...@crfreenet.org);
MODULE_LICENSE(GPL);
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
MODULE_PARM_DESC(mode_option, Default video mode ('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0);
MODULE_PARM_DESC(mode, Default video mode e.g. '648x480-8@60' (deprecated));
-
-#ifdef CONFIG_MTRR
module_param(mtrr, int, 0444);
MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
/* - */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
info-fix.mmio_len = pci_resource_len(dev, 1);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
Re: [PATCH] Memory hot added,The memory can not been added to movable zone
Hi
On Thu, 20 Aug 2015 14:15:13 +0800
Changsheng Liu liuchangsh...@inspur.com wrote:
Hi Andrew Morton:
First, thanks very much for your review, I will update codes according
to your suggestio
在 2015/8/20 7:50, Andrew Morton 写道:
On Wed, 19 Aug 2015 04:18:26 -0400 Changsheng Liu
liuchangsh...@inspur.com wrote:
From: Changsheng Liu liuchangch...@inspur.com
When memory hot added, the function should_add_memory_movable
always return 0,because the movable zone is empty,
so the memory that hot added will add to normal zone even if
we want to remove the memory.
So we change the function should_add_memory_movable,if the user
config CONFIG_MOVABLE_NODE it will return 1 when
movable zone is empty
I cleaned this up a bit:
: Subject: mm: memory hot-add: memory can not been added to movable zone
:
: When memory is hot added, should_add_memory_movable() always returns 0
: because the movable zone is empty, so the memory that was hot added will
: add to the normal zone even if we want to remove the memory.
:
: So we change should_add_memory_movable(): if the user config
: CONFIG_MOVABLE_NODE it will return 1 when the movable zone is empty.
But I don't understand the even if we want to remove the memory.
This is hot-add, not hot-remove. What do you mean here?
After the system startup, we hot added one memory. After some time
we wanted to hot remove the memroy that was hot added,
but we could not offline some memory blocks successfully because
the memory was added to normal zone defaultly and the value of the file
named removable under some memory blocks is 0.
For this, we prepared online_movable. When memory is onlined by online_movable,
the memory move from ZONE_NORMAL to ZONE_MOVABLE.
Ex.
# echo online_movable /sys/devices/system/memory/memoryXXX/state
Thanks,
Yasuaki Ishimatsu
we checked the value of the file under some memory blocks as follows:
cat /sys/devices/system/memory/ memory***/removable
When memory being hot added we let the memory be added to movable
zone,
so we will be able to hot remove the memory that have been hot added
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1198,9 +1198,13 @@ static int should_add_memory_movable(int nid, u64
start, u64 size)
pg_data_t *pgdat = NODE_DATA(nid);
struct zone *movable_zone = pgdat-node_zones + ZONE_MOVABLE;
- if (zone_is_empty(movable_zone))
+ if (zone_is_empty(movable_zone)) {
+ #ifdef CONFIG_MOVABLE_NODE
+ return 1;
+ #else
return 0;
-
+ #endif
+ }
if (movable_zone-zone_start_pfn = start_pfn)
return 1;
Cleaner:
---
a/mm/memory_hotplug.c~memory-hot-addedthe-memory-can-not-been-added-to-movable-zone-fix
+++ a/mm/memory_hotplug.c
@@ -1181,13 +1181,9 @@ static int should_add_memory_movable(int
pg_data_t *pgdat = NODE_DATA(nid);
struct zone *movable_zone = pgdat-node_zones + ZONE_MOVABLE;
- if (zone_is_empty(movable_zone)) {
- #ifdef CONFIG_MOVABLE_NODE
- return 1;
- #else
- return 0;
- #endif
- }
+ if (zone_is_empty(movable_zone))
+ return IS_ENABLED(CONFIG_MOVABLE_NODE);
+
if (movable_zone-zone_start_pfn = start_pfn)
return 1;
_
.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 06/11] drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if
write-combining is available. In order to take advantage of that also
ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()).
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Juergen Gross jgr...@suse.com
Cc: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-8-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/video/fbdev/arkfb.c | 36 +---
1 file changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index b305a1e7cc76..6a317de7082c 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -26,13 +26,9 @@
#include linux/console.h /* Why should fb driver call console functions?
because console_lock() */
#include video/vga.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
struct arkfb_info {
int mclk_freq;
- int mtrr_reg;
+ int wc_cookie;
struct dac_info *dac;
struct vgastate state;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {
static char *mode_option = 640x480-8@60;
-#ifdef CONFIG_MTRR
-static int mtrr = 1;
-#endif
-
MODULE_AUTHOR((c) 2007 Ondrej Zajicek santi...@crfreenet.org);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(fbdev driver for ARK 2000PV);
@@ -115,11 +107,6 @@ MODULE_PARM_DESC(mode_option, Default video mode
('640x480-8@60', etc));
module_param_named(mode, mode_option, charp, 0444);
MODULE_PARM_DESC(mode, Default video mode ('640x480-8@60', etc)
(deprecated));
-#ifdef CONFIG_MTRR
-module_param(mtrr, int, 0444);
-MODULE_PARM_DESC(mtrr, Enable write-combining with MTRR (1=enable, 0=disable,
default=1));
-#endif
-
static int threshold = 4;
module_param(threshold, int, 0644);
@@ -1002,7 +989,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
info-fix.smem_len = pci_resource_len(dev, 0);
/* Map physical IO memory address into kernel space */
- info-screen_base = pci_iomap(dev, 0, 0);
+ info-screen_base = pci_iomap_wc(dev, 0, 0);
if (! info-screen_base) {
rc = -ENOMEM;
dev_err(info-device, iomap for framebuffer failed\n);
@@ -1057,14 +1044,8 @@ static int ark_pci_probe(struct pci_dev *dev, const
[PATCH v4 03/11] drivers/video/fbdev/kyrofb: Use arch_phys_wc_add() and pci_ioremap_wc_bar()
From: Luis R. Rodriguez mcg...@suse.com
Convert the driver from using the x86-specific MTRR code to the
architecture-agnostic arch_phys_wc_add(). It will avoid MTRR if
write-combining is available, in order to take advantage of that
also ensure the ioremapped area is requested as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture-specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range())
The conversion done is expressed by the following Coccinelle SmPL
patch, it additionally required manual intervention to address all the
ifdeffery and removal of redundant things which arch_phys_wc_add()
already addresses such as verbose message about when MTRR fails and
doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info-fix.smem_start, info-fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap_nocache(base, size);
+info-screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info-screen_base = ioremap(base, size);
+info-screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Jingoo Han jg1@samsung.com
Cc: Juergen Gross jgr...@suse.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: m...@redhat.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: toshi.k...@hp.com
Link:
http://lkml.kernel.org/r/1435195342-26879-4-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/video/fbdev/kyro/fbdev.c | 33 +++--
include/video/kyro.h | 4 +---
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index 65041e15fd59..5bb01533271e 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -22,9 +22,6 @@
#include linux/pci.h
#include asm/io.h
#include linux/uaccess.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
#include video/kyro.h
@@ -84,9 +81,7 @@ static device_info_t deviceInfo;
static char *mode_option = NULL;
static int nopan = 0;
static int nowrap = 1;
-#ifdef CONFIG_MTRR
static int nomtrr = 0;
-#endif
/* PCI driver prototypes */
static int kyrofb_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -570,10 +565,8 @@ static int __init kyrofb_setup(char *options)
nopan = 1;
} else if (strcmp(this_opt, nowrap) == 0) {
nowrap = 1;
-#ifdef CONFIG_MTRR
} else if (strcmp(this_opt, nomtrr) == 0) {
nomtrr = 1;
-#endif
} else {
mode_option = this_opt;
}
@@ -691,17 +684,16 @@ static int kyrofb_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
currentpar-regbase = deviceInfo.pSTGReg =
ioremap_nocache(kyro_fix.mmio_start, kyro_fix.mmio_len);
+ if (!currentpar-regbase)
+ goto out_free_fb;
- info-screen_base = ioremap_nocache(kyro_fix.smem_start,
- kyro_fix.smem_len);
+ info-screen_base = pci_ioremap_wc_bar(pdev, 0);
+ if (!info-screen_base)
+ goto out_unmap_regs;
-#ifdef CONFIG_MTRR
if (!nomtrr)
- currentpar-mtrr_handle =
- mtrr_add(kyro_fix.smem_start,
-
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
On Mon, 2015-08-24 at 13:04 -0400, Tejun Heo wrote: Hello, Austin. On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote: Just to learn more, what sort of hypervisor support threads are we talking about? They would have to consume considerable amount of cpu cycles for problems like this to be relevant and be dynamic in numbers in a way which letting them competing against vcpus makes sense. Do IO helpers meet these criteria? Depending on the configuration, yes they can. VirtualBox has some rather CPU intensive threads that aren't vCPU threads (their emulated APIC thread immediately comes to mind), and so does QEMU depending on the emulated And the number of those threads fluctuate widely and dynamically? hardware configuration (it gets more noticeable when the disk images are stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is pretty typical usage for large virtualization deployments). I've seen cases first hand where the vCPU's can make no reasonable progress because they are constantly getting crowded out by other threads. Hm. Serious CPU starvation would seem to require quite a few hungry threads, but even a few IO threads with kick butt hardware under them could easily tilt fairness heavily in favor of VPUs generating IO. That alone doesn't require hierarchical resource distribution tho. Setting nice levels reasonably is likely to alleviate most of the problem. Unless the CPU controller is in use. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 05/11] PCI: Add pci_iomap_wc() variants
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe, but they don't say
anything about write combining (WC). WC changes ordering rules and
allows writes to be collapsed, so it's not safe in general to use it on
a prefetchable region.
Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take advantage
of write combining when they know it's safe.
On architectures that don't fully support WC, e.g., x86 without PAT,
drivers for legacy framebuffers may get some of the benefit by using
arch_phys_wc_add() in addition to pci_iomap_wc(). But arch_phys_wc_add()
is unreliable and should be avoided in general. On x86, it uses MTRRs,
which are limited in number and size, so the results will vary based on
driver loading order.
The goals of adding pci_iomap_wc() are to:
- Give drivers an architecture-independent way to use WC so they can stop
using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
PAT when available).
- Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
on x86 on ioremap_nocache() (see de33c442ed2a (x86 PAT: fix
performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
and pci_mmap_page_range()).
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
Acked-by: Arnd Bergmann a...@arndb.de
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andy Lutomirski l...@amacapital.net
Cc: Antonino Daplas adap...@gmail.com
Cc: Arnd Bergmann a...@arndb.de
Cc: b...@kernel.crashing.org
Cc: bhelg...@google.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Davidlohr Bueso dbu...@suse.de
Cc: david.vra...@citrix.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: jbeul...@suse.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Juergen Gross jgr...@suse.com
Cc: konrad.w...@oracle.com
Cc: linux-a...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mel Gorman mgor...@suse.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Roger Pau Monné roger@citrix.com
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Toshi Kani toshi.k...@hp.com
Cc: venkatesh.pallip...@intel.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Vlastimil Babka vba...@suse.cz
Link:
http://lkml.kernel.org/r/1426893517-2511-6-git-send-email-mcg...@do-not-panic.com
Link:
http://lkml.kernel.org/r/1435195342-26879-6-git-send-email-mcg...@do-not-panic.com
[ Move IORESOURCE_IO check up, space out statements for better readability. ]
Signed-off-by: Borislav Petkov b...@suse.de
---
include/asm-generic/pci_iomap.h | 14 +
lib/pci_iomap.c | 66 +
2 files changed, 80 insertions(+)
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87116a0..b1e17fcee2d0 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long
max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long
max);
extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen);
/* Create a virtual mapping cookie for a port on a given PCI device.
* Do not call this directly, it exists to make it easier for architectures
* to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev,
int bar, unsigned lon
return NULL;
}
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar,
unsigned long max)
+{
+ return NULL;
+}
static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
{
return NULL;
}
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+ unsigned long offset,
+ unsigned long maxlen)
+{
+ return NULL;
+}
#endif
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index e1930dbab2da..c10fba461454 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -49,6 +49,51 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
EXPORT_SYMBOL(pci_iomap_range);
/**
+ *
linux-next: manual merge of the kvm-ppc tree with the tip tree
Hi Alexander,
Today's linux-next merge of the kvm-ppc tree got a conflict in:
arch/powerpc/kvm/book3s_hv.c
between commit:
c56dadf39761 (sched/preempt, powerpc, kvm: Use need_resched() instead of
should_resched())
from the tip tree and commit:
ec2571650826 (KVM: PPC: Book3S HV: Make use of unused threads when running
guests)
from the kvm-ppc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/powerpc/kvm/book3s_hv.c
index a9f753fb73a8,fad52f226c12..
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@@ -2178,11 -2670,12 +2670,13 @@@ static int kvmppc_run_vcpu(struct kvm_r
vc-runner = vcpu;
if (n_ceded == vc-n_runnable) {
kvmppc_vcore_blocked(vc);
- } else if (should_resched()) {
+ } else if (need_resched()) {
+ vc-vcore_state = VCORE_PREEMPT;
+ kvmppc_vcore_preempt(vc);
/* Let something else run */
cond_resched_lock(vc-lock);
- vc-vcore_state = VCORE_INACTIVE;
+ if (vc-vcore_state == VCORE_PREEMPT)
+ kvmppc_vcore_end_preempt(vc);
} else {
kvmppc_run_core(vc);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v5 RESEND 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
Driver will now supports enable/disable across msg xfer, which user
can control it by new DT property -
i2c-disable-after-xfer : If set, driver will disable I2C module after msg
xfer and enable it back before xfer.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..9657db5 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -18,6 +18,11 @@ Recommended properties :
status register of i2c controller instead.
- mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
+Optional properties :
+
+ - i2c-disable-after-xfer : If set, driver will disable I2C module
+ after msg xfer and enable it again before xfer.
+
Examples:
twsi1: i2c@d4011000 {
compatible = mrvl,mmp-twsi;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v5 RESEND 0/5] i2c: pxa: Add support for PXA910 family of device
Sorry for not following up on this aggressively, was quit busy with some other stuff. Resending this patch with Robert's Tested-By. This patch-series is subset of the original patch-series, submitted on 14 Jul 2015. Link to Original Patch-series - https://lkml.org/lkml/2015/7/14/80 The first six patches have been already queued up for upstream. So this patch-series is respin of remaining 5 patches. Testing: - Basic testing on PMIC device on I2C-0 interface - Boot tested on platform based on PXA1928 - Read few registers of PMIC (RTC, ID, etc...) during boot V4 = V5 === Link to V3: https://lkml.org/lkml/2015/7/14/80 - Dropped First 6 patches as they are already accepted, queued for upstream - Fixed a bug in PATCH [5/5], where for non PXA910 devices it as resulting into NULL pointer dereference. For the record, pasting all the details from original patch-series - V3 = V4 === Link to V3: http://www.spinics.net/lists/devicetree/msg85904.html - [PATCH 06/11] Removed unnecessary dev_err on devm_kzalloc() check - [PATCH 06/11] Removed return check on platform_get_resource(), as devm_ioremap_resource() does it for us. Also, brought up the devm_ioremap_resource() function call in the execution sequence, as no point in delaying it if we do not have resource. It make sense, after this change. - [PATCH 04/11] Typecast changed to 'enum pxa_i2c_types' Also updated the subject line Removed == Fix V2 = V3 === Link to V2: http://www.spinics.net/lists/linux-i2c/msg20059.html - Removed PATCH [4/12] related to reset of I2C module. Suggested by Robert Jarzmik - Updated commit description for, PATCH [11/12]: Mentioned reasoning about moment of clk_get code. PATCH [12/12]: for DT property node. - Added Acked by Robert Jarzmik to patched which he acked. V1 = V2: Link to V1 - http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/347012.html - Fixed all comments from Robert Jarzmik and Wolfram Sang - Dropped Patch 05/12: using core bus reset implementation - under work. 08/12: NAKed and dropped - Separated DT binding patch from driver changes, for easy merge Vaibhav Hiremath (4): Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa i2c: pxa: Add support for pxa910/988 new configuration features Documentation: binding: add sclk adjustment properties to i2c-pxa i2c: pxa: Add ILCR (tLow tHigh) configuration support Yi Zhang (1): i2c: pxa: enable/disable i2c module across msg xfer Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 18 +++ drivers/i2c/busses/i2c-pxa.c | 154 -- 2 files changed, 163 insertions(+), 9 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v5 RESEND 3/5] i2c: pxa: Add support for pxa910/988 new configuration features
TWSI_ILCR TWSI_IWCR registers are used to adjust clock rate
of standard fast mode in pxa910/988; so this patch adds these two new
entries to struct pxa_reg_layout and struct pxa_i2c.
As discussed in the previous patch-series, the idea here is to add standard
DT properties for ilcr and iwcr configuration fields.
In case of Master ilcr is used for low/high time and in case of slave mode
of operation iwcr is used for setup/hold time.
Signed-off-by: Jett.Zhou jtz...@marvell.com
Signed-off-by: Yi Zhang yizh...@marvell.com
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
Tested-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/i2c/busses/i2c-pxa.c | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index abf04f2..8d76197 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -46,12 +46,15 @@ struct pxa_reg_layout {
u32 icr;
u32 isr;
u32 isar;
+ u32 ilcr;
+ u32 iwcr;
};
enum pxa_i2c_types {
REGS_PXA2XX,
REGS_PXA3XX,
REGS_CE4100,
+ REGS_PXA910,
};
/*
@@ -79,12 +82,22 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.isr = 0x04,
/* no isar register */
},
+ [REGS_PXA910] = {
+ .ibmr = 0x00,
+ .idbr = 0x08,
+ .icr = 0x10,
+ .isr = 0x18,
+ .isar = 0x20,
+ .ilcr = 0x28,
+ .iwcr = 0x30,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
{ pxa2xx-i2c, REGS_PXA2XX },
{ pxa3xx-pwri2c, REGS_PXA3XX },
{ ce4100-i2c, REGS_CE4100 },
+ { pxa910-i2c, REGS_PXA910 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -124,6 +137,24 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ISR_SAD(1 9) /* slave address detected */
#define ISR_BED(1 10) /* bus error no ACK/NAK */
+/* bit field shift mask */
+#define ILCR_SLV_SHIFT 0
+#define ILCR_SLV_MASK (0x1FF ILCR_SLV_SHIFT)
+#define ILCR_FLV_SHIFT 9
+#define ILCR_FLV_MASK (0x1FF ILCR_FLV_SHIFT)
+#define ILCR_HLVL_SHIFT18
+#define ILCR_HLVL_MASK (0x1FF ILCR_HLVL_SHIFT)
+#define ILCR_HLVH_SHIFT27
+#define ILCR_HLVH_MASK (0x1F ILCR_HLVH_SHIFT)
+
+#define IWCR_CNT_SHIFT 0
+#define IWCR_CNT_MASK (0x1F IWCR_CNT_SHIFT)
+#define IWCR_HS_CNT1_SHIFT 5
+#define IWCR_HS_CNT1_MASK (0x1F IWCR_HS_CNT1_SHIFT)
+#define IWCR_HS_CNT2_SHIFT 10
+#define IWCR_HS_CNT2_MASK (0x1F IWCR_HS_CNT2_SHIFT)
+
+
struct pxa_i2c {
spinlock_t lock;
wait_queue_head_t wait;
@@ -150,6 +181,8 @@ struct pxa_i2c {
void __iomem*reg_icr;
void __iomem*reg_isr;
void __iomem*reg_isar;
+ void __iomem*reg_ilcr;
+ void __iomem*reg_iwcr;
unsigned long iobase;
unsigned long iosize;
@@ -169,6 +202,8 @@ struct pxa_i2c {
#define _ICR(i2c) ((i2c)-reg_icr)
#define _ISR(i2c) ((i2c)-reg_isr)
#define _ISAR(i2c) ((i2c)-reg_isar)
+#define _ILCR(i2c) ((i2c)-reg_ilcr)
+#define _IWCR(i2c) ((i2c)-reg_iwcr)
/*
* I2C Slave mode address
@@ -1135,7 +1170,7 @@ static const struct i2c_algorithm i2c_pxa_pio_algorithm =
{
static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = mrvl,pxa-i2c, .data = (void *)REGS_PXA2XX },
{ .compatible = mrvl,pwri2c, .data = (void *)REGS_PXA3XX },
- { .compatible = mrvl,mmp-twsi, .data = (void *)REGS_PXA2XX },
+ { .compatible = mrvl,mmp-twsi, .data = (void *)REGS_PXA910 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1243,6 +1278,11 @@ static int i2c_pxa_probe(struct platform_device *dev)
if (i2c_type != REGS_CE4100)
i2c-reg_isar = i2c-reg_base + pxa_reg_layout[i2c_type].isar;
+ if (i2c_type == REGS_PXA910) {
+ i2c-reg_ilcr = i2c-reg_base + pxa_reg_layout[i2c_type].ilcr;
+ i2c-reg_iwcr = i2c-reg_base + pxa_reg_layout[i2c_type].iwcr;
+ }
+
i2c-iobase = res-start;
i2c-iosize = resource_size(res);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v5 RESEND 2/5] i2c: pxa: enable/disable i2c module across msg xfer
From: Yi Zhang yizh...@marvell.com
Enable i2c module/unit before transmission and disable when it
finishes.
why?
It's because the i2c bus may be disturbed if the slave device,
typically a touch, powers on.
As we do not want to break slave mode support, this patch introduces
DT property to control disable of the I2C module after xfer in master
mode of operation.
i2c-disable-after-xfer : If set, driver will disable I2C module after
msg xfer
Signed-off-by: Yi Zhang yizh...@marvell.com
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/i2c/busses/i2c-pxa.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 66cf437..abf04f2 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -161,6 +161,7 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
boolhighmode_enter;
+ booldisable_after_xfer;
};
#define _IBMR(i2c) ((i2c)-reg_ibmr)
@@ -284,6 +285,24 @@ static void i2c_pxa_scream_blue_murder(struct pxa_i2c
*i2c, const char *why)
static void i2c_pxa_master_complete(struct pxa_i2c *i2c, int ret);
static irqreturn_t i2c_pxa_handler(int this_irq, void *dev_id);
+/* enable/disable i2c unit */
+static inline int i2c_pxa_is_enabled(struct pxa_i2c *i2c)
+{
+ return (readl(_ICR(i2c)) ICR_IUE);
+}
+
+static inline void i2c_pxa_enable(struct pxa_i2c *i2c, bool enable)
+{
+ if (enable) {
+ if (!i2c_pxa_is_enabled(i2c)) {
+ writel(readl(_ICR(i2c)) | ICR_IUE, _ICR(i2c));
+ udelay(100);
+ }
+ } else {
+ writel(readl(_ICR(i2c)) ~ICR_IUE, _ICR(i2c));
+ }
+}
+
static inline int i2c_pxa_is_slavemode(struct pxa_i2c *i2c)
{
return !(readl(_ICR(i2c)) ICR_SCLE);
@@ -480,8 +499,7 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
i2c_pxa_set_slave(i2c, 0);
/* enable unit */
- writel(readl(_ICR(i2c)) | ICR_IUE, _ICR(i2c));
- udelay(100);
+ i2c_pxa_enable(i2c, true);
}
@@ -832,6 +850,9 @@ static int i2c_pxa_pio_xfer(struct i2c_adapter *adap,
struct pxa_i2c *i2c = adap-algo_data;
int ret, i;
+ /* Enable i2c unit */
+ i2c_pxa_enable(i2c, true);
+
/* If the I2C controller is disabled we need to reset it
(probably due to a suspend/resume destroying state). We do
this here as we can then avoid worrying about resuming the
@@ -852,6 +873,11 @@ static int i2c_pxa_pio_xfer(struct i2c_adapter *adap,
ret = -EREMOTEIO;
out:
i2c_pxa_set_slave(i2c, ret);
+
+ /* disable i2c unit */
+ if (i2c-disable_after_xfer)
+ i2c_pxa_enable(i2c, false);
+
return ret;
}
@@ -1067,6 +1093,9 @@ static int i2c_pxa_xfer(struct i2c_adapter *adap, struct
i2c_msg msgs[], int num
struct pxa_i2c *i2c = adap-algo_data;
int ret, i;
+ /* Enable i2c unit */
+ i2c_pxa_enable(i2c, true);
+
for (i = adap-retries; i = 0; i--) {
ret = i2c_pxa_do_xfer(i2c, msgs, num);
if (ret != I2C_RETRY)
@@ -1080,6 +1109,10 @@ static int i2c_pxa_xfer(struct i2c_adapter *adap, struct
i2c_msg msgs[], int num
ret = -EREMOTEIO;
out:
i2c_pxa_set_slave(i2c, ret);
+ /* disable i2c unit */
+ if (i2c-disable_after_xfer)
+ i2c_pxa_enable(i2c, false);
+
return ret;
}
@@ -1120,6 +1153,9 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev,
struct pxa_i2c *i2c,
/* For device tree we always use the dynamic or alias-assigned ID */
i2c-adap.nr = -1;
+ i2c-disable_after_xfer = of_property_read_bool(np,
+ i2c-disable-after-xfer);
+
if (of_get_property(np, mrvl,i2c-polling, NULL))
i2c-use_pio = 1;
if (of_get_property(np, mrvl,i2c-fast-mode, NULL))
@@ -1264,6 +1300,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
platform_set_drvdata(dev, i2c);
+ if (i2c-disable_after_xfer)
+ i2c_pxa_enable(i2c, false);
+
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(i2c-adap.dev, PXA I2C adapter, slave address %d\n,
i2c-slave_addr);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v5 RESEND 4/5] Documentation: binding: add sclk adjustment properties to i2c-pxa
With addition of PXA910 family of devices, the TWSI module supports
new feature which allows us to adjust SCLK. i2c-pxa driver takes input
configuration in nsec and converts it to respective bit-fields,
- i2c-sclk-low-time-ns : SCLK low time (tlow)
This property is used along with mode selection.
- i2c-sclk-high-time-ns : SCLK high time (thigh)
- i2c-start-hold-time-ns : Used in case of high speed mode for start bit
hold/setup wait counter.
- i2c-stop-hold-time-ns : Used in case of high speed mode for stop bit
hold/setup wait counter.
- i2c-sda-hold-time-ns : Used to calculate hold/setup wait counter for
standard and fast mode.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 9657db5..bb4df60 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -23,12 +23,25 @@ Optional properties :
- i2c-disable-after-xfer : If set, driver will disable I2C module
after msg xfer and enable it again before xfer.
+ (Applicable to PXA910 family):
+
+ - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high
+ speed mode.
+ This property is used along with mode selection. Driver uses this property
+ to set low/high time for standard and fast speed mode, as HW counter
+ bit-field is same for both.
+ - i2c-sclk-high-time-ns : SCLK high time (thigh), Used in case of high speed
+ mode only.
+
Examples:
twsi1: i2c@d4011000 {
compatible = mrvl,mmp-twsi;
reg = 0xd4011000 0x1000;
interrupts = 7;
mrvl,i2c-fast-mode;
+
+ i2c-sclk-low-time-ns = 988;
+ i2c-sclk-high-time-ns = 988;
};
twsi2: i2c@d4025000 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH-v5 RESEND 5/5] i2c: pxa: Add ILCR (tLow tHigh) configuration support
With addition of PXA910 family of devices, the TWSI module supports
SCL clock adjustment using ILCR register.
This patch enables the control and configuration of ICLR through DT
properties,
i2c-sclk-high-time-ns:
SCLK high time (tHigh), for standard/fast/high speed mode
i2c-sclk-low-time-ns:
SCLK low time (tLow), for standard/fast/high speed mode
Note that in case of standard and fast mod, the tLow and tHigh counters
are same, and software will use tLow value.
Also, brought up devm_clk_get() fn above i2c_pxa_probe_dt(), as it
uses clk rate for timing calculations.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
Signed-off-by: Jett.Zhou jtz...@marvell.com
Signed-off-by: Yi Zhang yizh...@marvell.com
Tested-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/i2c/busses/i2c-pxa.c | 69
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 8d76197..6012ae5 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -195,6 +195,9 @@ struct pxa_i2c {
unsigned long rate;
boolhighmode_enter;
booldisable_after_xfer;
+
+ unsigned intsclk_thigh_load_cnt;
+ unsigned intsclk_tlow_load_cnt;
};
#define _IBMR(i2c) ((i2c)-reg_ibmr)
@@ -507,6 +510,36 @@ static void i2c_pxa_set_slave(struct pxa_i2c *i2c, int
errcode)
#define i2c_pxa_set_slave(i2c, err)do { } while (0)
#endif
+static void i2c_pxa_do_sclk_adj(struct pxa_i2c *i2c)
+{
+ unsigned int reg_ilcr;
+
+ if (!i2c-reg_ilcr)
+ return;
+
+ reg_ilcr = readl(_ILCR(i2c));
+
+ /* For standard/fast mode tlow and thigh counters are same */
+ if (i2c-sclk_tlow_load_cnt) {
+ unsigned int mask, shift;
+
+ mask = i2c-high_mode ? ILCR_HLVL_MASK :
+ i2c-fast_mode ? ILCR_FLV_MASK : ILCR_SLV_MASK;
+ shift = i2c-high_mode ? ILCR_HLVL_SHIFT :
+ i2c-fast_mode ? ILCR_FLV_SHIFT : ILCR_SLV_SHIFT;
+
+ reg_ilcr = ~mask;
+ reg_ilcr |= i2c-sclk_tlow_load_cnt shift;
+ }
+
+ if (i2c-high_mode i2c-sclk_thigh_load_cnt) {
+ reg_ilcr = ~ILCR_HLVH_MASK;
+ reg_ilcr |= i2c-sclk_thigh_load_cnt ILCR_HLVH_SHIFT;
+ }
+
+ writel(reg_ilcr, _ILCR(i2c));
+}
+
static void i2c_pxa_reset(struct pxa_i2c *i2c)
{
pr_debug(Resetting I2C Controller Unit\n);
@@ -526,6 +559,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(I2C_ICR_INIT | (i2c-fast_mode ? ICR_FM : 0), _ICR(i2c));
writel(readl(_ICR(i2c)) | (i2c-high_mode ? ICR_HS : 0), _ICR(i2c));
+ i2c_pxa_do_sclk_adj(i2c);
+
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(i2c-adap.dev, Enabling slave mode\n);
writel(readl(_ICR(i2c)) | ICR_SADIE | ICR_ALDIE | ICR_SSDIE, _ICR(i2c));
@@ -1198,6 +1233,26 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
*i2c_types = (enum pxa_i2c_types)(of_id-data);
+ /* optional properties */
+ if (of_device_is_compatible(np, mrvl,mmp-twsi)) {
+ unsigned int tlow = 0, thigh = 0;
+ unsigned int clk_ns;
+
+ /* clock time in nsec */
+ clk_ns = 100 / (i2c-rate / 1000);
+
+ of_property_read_u32(np, i2c-sclk-high-time-ns, thigh);
+ i2c-sclk_thigh_load_cnt = thigh / clk_ns;
+
+ of_property_read_u32(np, i2c-sclk-low-time-ns, tlow);
+ i2c-sclk_tlow_load_cnt = tlow / clk_ns;
+
+ /* For std/fast mode tlow thigh have same bit-fields */
+ if (!i2c-high_mode
+ (i2c-sclk_tlow_load_cnt != i2c-sclk_thigh_load_cnt))
+ dev_warn(i2c-adap.dev,
+ mismatch of tLow tHigh values, using
tLow\n);
+ }
return 0;
}
@@ -1248,6 +1303,14 @@ static int i2c_pxa_probe(struct platform_device *dev)
return irq;
}
+ i2c-clk = devm_clk_get(dev-dev, NULL);
+ if (IS_ERR(i2c-clk)) {
+ dev_err(dev-dev, failed to get the clk: %ld\n,
PTR_ERR(i2c-clk));
+ return PTR_ERR(i2c-clk);
+ }
+
+ i2c-rate = clk_get_rate(i2c-clk);
+
/* Default adapter num to device id; i2c_pxa_probe_dt can override. */
i2c-adap.nr = dev-id;
@@ -1265,12 +1328,6 @@ static int i2c_pxa_probe(struct platform_device *dev)
strlcpy(i2c-adap.name, pxa_i2c-i2c, sizeof(i2c-adap.name));
- i2c-clk = devm_clk_get(dev-dev, NULL);
- if (IS_ERR(i2c-clk)) {
- dev_err(dev-dev, failed to get the clk: %ld\n,
PTR_ERR(i2c-clk));
- return PTR_ERR(i2c-clk);
- }
-
i2c-reg_ibmr = i2c-reg_base + pxa_reg_layout[i2c_type].ibmr;
i2c-reg_idbr =
[PATCH] Fix bug in iommu_context_addr: Always get pointer to lower extended-context-table
Hi David joerg,
In iommu_context_addr() function, we always use lower extended-context-table
even though upper-half of the extended root-entry is present.
Signed-off-by: Nan Xiao nan.x...@hp.com
---
drivers/iommu/intel-iommu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0649b94..4213598 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -759,10 +759,11 @@ static inline struct context_entry
*iommu_context_addr(struct intel_iommu *iommu
if (devfn = 0x80) {
devfn -= 0x80;
entry = root-hi;
- }
+ } else
+ entry = root-lo;
devfn *= 2;
- }
- entry = root-lo;
+ } else
+ entry = root-lo;
if (*entry 1)
context = phys_to_virt(*entry VTD_PAGE_MASK);
else {
--
2.4.3
Best Regards
Nan Xiao
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
here it's fully set - triggering the bug I'm worried about. So what am I
missing, what prevents CONFIG_NO_HZ_FULL_ALL from crashing?
The boot CPU is excluded from tick_nohz_full_mask in tick_nohz_init(), which
is
called from tick_init() which is called from start_kernel() shortly after
rcu_init():
cpu = smp_processor_id();
if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) {
pr_warning(NO_HZ: Clearing %d from nohz_full range for
timekeeping\n, cpu);
cpumask_clear_cpu(cpu, tick_nohz_full_mask);
}
This happens after the call to tick_nohz_init_all() that does the
cpumask_setall() that you called out above.
Ah, indeed - I somehow missed that.
This brings up two other questions:
1)
the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a full mask
to
it (housekeeping_mask - a variable mask to begin with) and recover the
housekeeping CPU via:
+ return cpumask_any_and(housekeeping_mask, cpu_online_mask);
which can be pretty expensive, and which gets executed in two hotpaths:
kernel/time/hrtimer.c: return per_cpu(hrtimer_bases, get_nohz_timer_target());
kernel/time/timer.c:return per_cpu_ptr(tvec_bases,
get_nohz_timer_target());
... why not just use a single housekeeping_cpu which would be way faster to
pass
down to the timer code?
2)
What happens if the boot CPU is offlined? (under
CONFIG_BOOTPARAM_HOTPLUG_CPU0=y)
I don't see CPU hotplug callbacks fixing up the housekeeping_mask if the boot
CPU
is offlined.
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] doc: dt: Add interrupt parent to Xilinx AXI DMA instantation example.
On 08/21/2015 06:32 PM, Moritz Fischer wrote:
This patch adds 'interrupt-parent' properties to the instantation example in
the docs for the devicetree bindings of the Xilinx AXI DMA driver.
Signed-off-by: Moritz Fischer moritz.fisc...@ettus.com
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index 2291c40..7c956e9 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -19,6 +19,7 @@ Required child node properties:
- compatible: It should be either xlnx,axi-dma-mm2s-channel or
xlnx,axi-dma-s2mm-channel.
- interrupts: Should contain per channel DMA interrupts.
+- interrupt-parent: Should contain interrupt parent.
- xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
@@ -36,11 +37,13 @@ axi_dma_0: axidma@4040 {
dma-channel@4040 {
compatible = xlnx,axi-dma-mm2s-channel;
interrupts = 0 59 4 ;
+ interrupt-parent = intc;
xlnx,datawidth = 0x40;
} ;
dma-channel@40400030 {
compatible = xlnx,axi-dma-s2mm-channel;
interrupts = 0 58 4 ;
+ interrupt-parent = intc;
xlnx,datawidth = 0x40;
} ;
} ;
Acked-by: Michal Simek michal.si...@xilinx.com
Thanks,
Michal
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-v6 0/6] mfd: 88pm800: Add Device tree support
On Tuesday 14 July 2015 12:27 AM, Vaibhav Hiremath wrote: On Wednesday 08 July 2015 05:56 PM, Vaibhav Hiremath wrote: This patch-series adds support for Device tree to 88PM800 mfd driver. It also sets default configuration of irq clear method if board file doesn't exist. Testing:: - Boot tested on PXA1928 based platform. - probe of mfd, rtc and regulator function passing successfully. - Basic read operations on registers - irq clear configuration V5 = V6 === I hope this will be queued for 4.2 Lee, This patch-series is pending since long time, reviewed and acked. Request to queue it up for next merge window. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/math-emu: Add support for FCMOVcc and F[U]COMI[P] insns
* Ingo Molnar mi...@kernel.org wrote: * Denys Vlasenko dvlas...@redhat.com wrote: I propose the table to be commented like shown below: /*Opcode: d8 d9da db dc dd de df */ /*c0..f*/ fadd__, fld_i_, fcmovb, fcmovnb, fadd_i, ffree_, faddp_, _df_c0_, /*c8..f*/ fmul__, fxch_i, fcmove, fcmovne, fmul_i, _dd_c8_,fmulp_, _df_c8_, /*d0..7*/ fcom_st,fp_nop, fcmovbe,fcmovnbe,_dc_d0_,fst_i_, _de_d0_,_df_d0_, /*d8..f*/ fcompst,_d9_d8_, fcmovu, fcmovnu, _dc_d8_,fstp_i, fcompp, _df_d8_, /*e0..7*/ fsub__, FPU_etc, __BAD__,finit_, fsubri, fucom_, fsubrp, fstsw_, /*e8..f*/ fsubr_, fconst, fucompp,fucomi_, fsub_i, fucomp, fsubp_, fucomip, /*f0..7*/ fdiv__, FPU_triga,__BAD__,fcomi_, fdivri, __BAD__,fdivrp, fcomip, /*f8..f*/ fdivr_, FPU_trigb,__BAD__,__BAD__, fdiv_i, __BAD__,fdivp_, __BAD__, I agree with that, but please fix the vertical alignment (like my patch did), as the table is pretty hard to navigate in this form. and by that I mean to split each line into two, to have groups of 4 instructions and enough tabs between them. Also, the first patch in the series should remove the 'undocumented' #ifdef. That define was fully justified ~20 years ago but let's not complicate new code with it. The formerly undocumented opcodes could also grow real names. All in nicely separate patches. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the slave-dma tree
Hi Vinod, On Thu, Aug 06, 2015 at 08:30:27AM +0530, Vinod Koul wrote: On Thu, Aug 06, 2015 at 12:22:03PM +1000, Stephen Rothwell wrote: Hi Vinod, After merging the slave-dma tree, today's linux-next build (arm multi_v7_defconfig) failed like this: drivers/dma/at_hdmac.c: In function 'atc_prep_dma_memset': drivers/dma/at_hdmac.c:960:6: error: 'struct at_desc' has no member named 'tx_width' desc-tx_width = 2; ^ Caused by commit 25fed8c2fff1 (dmaengine: hdmac: Add memset capabilities) interacting with commit 93dce3a6434f (dmaengine: at_hdmac: fix residue computation) Thanks Stephen, I am dropping this commit now, it need to be fixed to take into account Cyrille work on remove tx_width and this patch should be updated to reflect that I'll send an updated version today, is there some time left for this to be part of 4.3? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH-v3] mfd: 88pm80x: Add 88pm860 chip type support
On Monday 20 July 2015 05:22 PM, Vaibhav Hiremath wrote: Add chip identification support for 88PM860 device to the pm80x_chip_mapping table. Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/mfd/88pm80x.c | 2 ++ include/linux/mfd/88pm80x.h | 1 + 2 files changed, 3 insertions(+) Mark, Last update/understanding which I have on this patch is, Lee is OK with taking this patch from regulator tree. Lee please let me know if you think otherwise. With this patch in, the build dependency will go away. Request to pick this patch into your topic/88pm800 branch and run build test. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V8 10/25] perf tools: Add example call-graph script
On 21/08/15 18:28, Arnaldo Carvalho de Melo wrote: Em Fri, Aug 21, 2015 at 12:21:25PM -0300, Arnaldo Carvalho de Melo escreveu: Em Fri, Aug 21, 2015 at 12:11:33PM -0300, Arnaldo Carvalho de Melo escreveu: [acme@zoo ~]$ perf script -s ~/libexec/perf-core/scripts/python/export-to-postgresql.py bts_example branches calls 2015-08-21 12:10:00.504126 Creating database... QSqlDatabase: QPSQL driver not loaded QSqlDatabase: available drivers: QSQLITE QSqlDatabase: an instance of QCoreApplication is required for loading driver plugins QSqlQuery::exec: database not open Traceback (most recent call last): File /home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py, line 87, in module do_query(query, 'CREATE DATABASE ' + dbname) File /home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py, line 78, in do_query raise Exception(Query failed: + q.lastError().text()) Exception: Query failed: Driver not loaded Driver not loaded Error running python script /home/acme/libexec/perf-core/scripts/python/export-to-postgresql.py [acme@zoo ~]$ A-ha, this was missing: [root@zoo ~]# rpm -ql qt-postgresql /usr/lib64/qt4/plugins/sqldrivers/libqsqlpsql.so [root@zoo ~]# [acme@zoo ~]$ perf script -s ~/libexec/perf-core/scripts/python/export-to-postgresql.py bts_example branches calls 2015-08-21 12:20:01.841677 Creating database... 2015-08-21 12:20:02.556853 Writing to intermediate files... 2015-08-21 12:20:03.262814 Copying to database... 2015-08-21 12:20:03.783109 Removing intermediate files... 2015-08-21 12:20:03.790282 Adding primary keys 2015-08-21 12:20:04.294342 Adding foreign keys 2015-08-21 12:20:04.718238 Done [acme@zoo ~]$ Now to the next steps... Lets see how this looks like with BTS... So, after running: [acme@zoo linux]$ python tools/perf/scripts/python/call-graph-from-postgresql.py bts_example I got a GUI and after expanding some callchains I took this screenshot: http://vger.kernel.org/~acme/perf/call_graph_example_intel_bts.png Cool stuff! But it seems the COMM got messed up? I.e. that 1380:1380 first level after ls. That is, in fact, correct. The top-level is the process (comm). The next level is the threads (pid/tid) for that process. Currently, each thread is reported separately. For the future, there ought to be an option to combine the data for all threads of a process, or all processes with the same comm. Also presently it is not tracking if a thread sets it's own comm (e.g. some multi-threaded applications name each thread). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/11] ARM: DTS: dra7-evm: Add fixed regulator to be used by aic3106's DVDD
TPS77018DBVT is used to create 1.8V from avm_3v3_sw's 3.3V connected to
aic3106's DVDD.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index de02cf5853a9..add77ac4f302 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -35,6 +35,15 @@
regulator-max-microvolt = 330;
};
+ aic_dvdd: fixedregulator-aic_dvdd {
+ /* TPS77018DBVT */
+ compatible = regulator-fixed;
+ regulator-name = aic_dvdd;
+ vin-supply = evm_3v3_sw;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
extcon_usb1: extcon_usb1 {
compatible = linux,extcon-usb-gpio;
id-gpio = pcf_gpio_21 1 GPIO_ACTIVE_HIGH;
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/11] ARM: DTS: dra72-evm: Add fixed regulator representing DVDD supply for aic3106
The DVDD is supplied via TPS77018DBVT fixed regulator from evm_3v3
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 6f6bd98c98df..ac3a29483791 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -30,6 +30,15 @@
regulator-max-microvolt = 330;
};
+ aic_dvdd: fixedregulator-aic_dvdd {
+ /* TPS77018DBVT */
+ compatible = regulator-fixed;
+ regulator-name = aic_dvdd;
+ vin-supply = evm_3v3;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ };
+
evm_3v3_sd: fixedregulator-sd {
compatible = regulator-fixed;
regulator-name = evm_3v3_sd;
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/11] ARM: DTS: dra7-evm: Audio support
The board uses tlv320aic3106 codec connected to McASP3. The master clock
for the codec and McASP3 is coming from ATL2.
McASP3 is the master on the I2S bus.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 113 +
1 file changed, 113 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 3694046c29eb..1a66d359f3e3 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -9,6 +9,7 @@
#include dra74x.dtsi
#include dt-bindings/gpio/gpio.h
+#include dt-bindings/clk/ti-dra7-atl.h
/ {
model = TI DRA742;
@@ -64,6 +65,40 @@
enable-active-high;
gpio = gpio7 11 GPIO_ACTIVE_HIGH;
};
+
+ sound0: sound@0 {
+ compatible = simple-audio-card;
+ simple-audio-card,name = DRA7xx-EVM;
+ simple-audio-card,widgets =
+ Headphone, Headphone Jack,
+ Line, Line Out,
+ Microphone, Mic Jack,
+ Line, Line In;
+ simple-audio-card,routing =
+ Headphone Jack, HPLOUT,
+ Headphone Jack, HPROUT,
+ Line Out, LLOUT,
+ Line Out, RLOUT,
+ MIC3L,Mic Jack,
+ MIC3R,Mic Jack,
+ Mic Jack, Mic Bias,
+ LINE1L, Line In,
+ LINE1R, Line In;
+ simple-audio-card,format = dsp_b;
+ simple-audio-card,bitclock-master = sound0_master;
+ simple-audio-card,frame-master = sound0_master;
+ simple-audio-card,bitclock-inversion;
+
+ sound0_master: simple-audio-card,cpu {
+ sound-dai = mcasp3;
+ system-clock-frequency = 5644800;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = tlv320aic3106;
+ clocks = atl_clkin2_ck;
+ };
+ };
};
dra7_pmx_core {
@@ -292,6 +327,31 @@
0x418 (MUX_MODE15 | PULL_UP) /* wakeup0.off */
;
};
+
+ atl_pins: pinmux_atl_pins {
+ pinctrl-single,pins =
+ 0x298 (PIN_OUTPUT | MUX_MODE5) /* xref_clk1.atl_clk1 */
+ 0x29c (PIN_OUTPUT | MUX_MODE5) /* xref_clk2.atl_clk2 */
+ ;
+ };
+
+ mcasp3_pins: pinmux_mcasp3_pins {
+ pinctrl-single,pins =
+ 0x324 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_aclkx
*/
+ 0x328 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_fsx */
+ 0x32c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr0
*/
+ 0x330 (PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr1
*/
+ ;
+ };
+
+ mcasp3_sleep_pins: pinmux_mcasp3_sleep_pins {
+ pinctrl-single,pins =
+ 0x324 (MUX_MODE15)
+ 0x328 (MUX_MODE15)
+ 0x32c (MUX_MODE15)
+ 0x330 (MUX_MODE15)
+ ;
+ };
};
i2c1 {
@@ -431,6 +491,20 @@
#interrupt-cells = 2;
};
+ tlv320aic3106: tlv320aic3106@19 {
+ #sound-dai-cells = 0;
+ compatible = ti,tlv320aic3106;
+ reg = 0x19;
+ adc-settle-ms = 40;
+ ai3x-micbias-vg = 1; /* 2.0V */
+ status = okay;
+
+ /* Regulators */
+ AVDD-supply = evm_3v3_sw;
+ IOVDD-supply = evm_3v3_sw;
+ DRVDD-supply = evm_3v3_sw;
+ DVDD-supply = aic_dvdd;
+ };
};
i2c2 {
@@ -730,3 +804,42 @@
pinctrl-1 = dcan1_pins_sleep;
pinctrl-2 = dcan1_pins_default;
};
+
+atl {
+ pinctrl-names = default;
+ pinctrl-0 = atl_pins;
+
+ assigned-clocks = abe_dpll_sys_clk_mux,
+ atl_gfclk_mux,
+ dpll_abe_ck,
+ dpll_abe_m2x2_ck,
+ atl_clkin2_ck;
+ assigned-clock-parents = sys_clkin2, dpll_abe_m2_ck;
+ assigned-clock-rates = 0, 0, 180633600, 361267200, 5644800;
+
+ status = okay;
+
+ atl2 {
+ bws = DRA7_ATL_WS_MCASP2_FSX;
+ aws = DRA7_ATL_WS_MCASP3_FSX;
+ };
+};
+
+mcasp3 {
+ #sound-dai-cells = 0;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = mcasp3_pins;
+ pinctrl-1 = mcasp3_sleep_pins;
+
+ assigned-clocks = mcasp3_ahclkx_mux;
+ assigned-clock-parents = atl_clkin2_ck;
+
+ status = okay;
+
+ op-mode = 0; /* MCASP_IIS_MODE */
+
Re: [PATCH v3 1/1] USB:option:add ZTE PIDs
On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
This is intended to add ZTE device PIDs on kernel.
Signed-off-by: Liu.Zhao lzsos...@163.com
---
drivers/usb/serial/option.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 876423b..e26db28 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -278,13 +278,17 @@ static void option_instat_callback(struct urb *urb);
#define ZTE_PRODUCT_MF6220x0001
#define ZTE_PRODUCT_MF6280x0015
#define ZTE_PRODUCT_MF6260x0031
-#define ZTE_PRODUCT_AC2726 0xfff1
-#define ZTE_PRODUCT_MG8800xfffd
-#define ZTE_PRODUCT_CDMA_TECH0xfffe
-#define ZTE_PRODUCT_AC8710T 0x
+#define ZTE_PRODUCT_ZM8620_X 0x0396
+#define ZTE_PRODUCT_ME3620_MBIM 0x0426
+#define ZTE_PRODUCT_ME3620_X 0x1432
+#define ZTE_PRODUCT_ME3620_L 0x1433
#define ZTE_PRODUCT_MC2718 0xffe8
#define ZTE_PRODUCT_AD3812 0xffeb
#define ZTE_PRODUCT_MC2716 0xffed
+#define ZTE_PRODUCT_AC2726 0xfff1
+#define ZTE_PRODUCT_MG8800xfffd
+#define ZTE_PRODUCT_CDMA_TECH0xfffe
+#define ZTE_PRODUCT_AC8710T 0x
Reordering the current entries is not needed, but if you do it then you
must mention it in the commit message above.
Also make sure to not change any formatting; checkpatch is now
complaining about whitespace issues (always run checkpatch before
submitting).
#define BENQ_VENDOR_ID 0x04a5
#define BENQ_PRODUCT_H10 0x4068
@@ -544,6 +548,14 @@ static const struct option_blacklist_info
zte_mc2716_z_blacklist = {
.sendsetup = BIT(1) | BIT(2) | BIT(3),
};
+static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist =
{
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
Use two structs for this: zte_me3620_blacklist and zm8620_xl_blacklist
even if they reserve the same ports.
+
+static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
+ .reserved = BIT(2) | BIT(3) | BIT(4),
+};
+
static const struct option_blacklist_info huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
};
@@ -1581,16 +1593,24 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfff9, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffb, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffc, 0xff, 0xff,
0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff,
0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH,
0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC2726,
0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710T,
0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718,
0xff, 0xff, 0xff),
- .driver_info = (kernel_ulong_t)zte_mc2718_z_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AD3812,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)zte_ad3812_z_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH,
0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)zte_mc2716_z_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718,
0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)zte_mc2718_z_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff,
0xff, 0xff) },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
+ .driver_info = (kernel_ulong_t)zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
+ .driver_info = (kernel_ulong_t)zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
+ .driver_info = (kernel_ulong_t)zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
+ .driver_info = (kernel_ulong_t)zte_me3620_mbim_blacklist },
If really want to reorder the current entries, then at least make sure
the end result is indeed sorted.
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
Johan
--
To unsubscribe from this
[PATCH] clk: ti: clk-7xx: Remove hardwired ABE clock configuration
The ABE related clocks should be configured via DT and not have it wired
inside of the kernel.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tero,
the ABE PLL configuration can, and will be done for dra7xx in DT with the
assigned-clocks/rate/parent feature so no need to have this anymore.
Regards,
Peter
drivers/clk/ti/clk-7xx.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9b5b289e6334..a911d7de3377 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -18,7 +18,6 @@
#include clock.h
-#define DRA7_DPLL_ABE_DEFFREQ 180633600
#define DRA7_DPLL_GMAC_DEFFREQ 10
#define DRA7_DPLL_USB_DEFFREQ 96000
@@ -313,27 +312,12 @@ static struct ti_dt_clk dra7xx_clks[] = {
int __init dra7xx_dt_clk_init(void)
{
int rc;
- struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
+ struct clk *dpll_ck, *hdcp_ck;
ti_dt_clocks_register(dra7xx_clks);
omap2_clk_disable_autoidle_all();
- abe_dpll_mux = clk_get_sys(NULL, abe_dpll_sys_clk_mux);
- sys_clkin2 = clk_get_sys(NULL, sys_clkin2);
- dpll_ck = clk_get_sys(NULL, dpll_abe_ck);
-
- rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
- if (!rc)
- rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
- if (rc)
- pr_err(%s: failed to configure ABE DPLL!\n, __func__);
-
- dpll_ck = clk_get_sys(NULL, dpll_abe_m2x2_ck);
- rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
- if (rc)
- pr_err(%s: failed to configure ABE DPLL m2x2!\n, __func__);
-
dpll_ck = clk_get_sys(NULL, dpll_gmac_ck);
rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
if (rc)
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3 v4] mm/vmalloc: Cache the vmalloc memory info
* George Spelvin li...@horizon.com wrote:
First, an actual, albeit minor, bug: initializing both vmap_info_gen
and vmap_info_cache_gen to 0 marks the cache as valid, which it's not.
Ha! :-) Fixed.
vmap_info_gen should be initialized to 1 to force an initial
cache update.
Yeah.
Second, I don't see why you need a 64-bit counter. Seqlocks consider
32 bits (31 bits, actually, the lsbit means update in progress) quite
a strong enough guarantee.
Just out of general paranoia - but you are right, and this would lower the
overhead on 32-bit SMP platforms a bit, plus it avoids 64-bit word tearing
artifacts on 32 bit platforms as well.
I modified it to u32.
Third, it seems as though vmap_info_cache_gen is basically a duplicate
of vmap_info_lock.sequence. It should be possible to make one variable
serve both purposes.
Correct, I alluded to that in my description:
Note that there's an even simpler variant possible I think: we could use
just
the two generation counters and barriers to remove the seqlock.
You just need a kludge to handle the case of multiple vamp_info updates
between cache updates.
There are two simple ones:
1) Avoid bumping vmap_info_gen unnecessarily. In vmap_unlock(), do
vmap_info_gen = (vmap_info_lock.sequence | 1) + 1;
2) - Make vmap_info_gen a seqcount_t
- In vmap_unlock(), do write_seqcount_barrier(vmap_info_gen)
- In get_vmalloc_info, inside the seqlock critical section, do
vmap_info_lock.seqcount.sequence = vmap_info_gen.sequence - 1;
(Using the vmap_info_gen.sequence read while validating the
cache in the first place.)
I should try to write an actual patch illustrating this.
So I think something like the patch below is even simpler than trying to kludge
generation counter semantics into seqcounts.
I used two generation counters and a spinlock. The fast path is completely
lockless and lightweight on modern SMP platforms. (where smp_rmb() is a no-op
or
very cheap.)
There's not even a seqlock retry loop, instead an invalid cache causes us to
fall
back to the old behavior - and the freshest result is guaranteed to end up in
the
cache.
The linecount got a bit larger: but half of it is comments.
Note that the generation counters are signed integers so that this comparison
can
be done:
+ if (gen-vmap_info_cache_gen 0) {
Thanks,
Ingo
==
From 1a4c168a22cc302282cbd1bf503ecfc4dc52b74f Mon Sep 17 00:00:00 2001
From: Ingo Molnar mi...@kernel.org
Date: Sat, 22 Aug 2015 12:28:01 +0200
Subject: [PATCH] mm/vmalloc: Cache the vmalloc memory info
Linus reported that for scripting-intense workloads such as the
Git build, glibc's qsort will read /proc/meminfo for every process
created (by way of get_phys_pages()), which causes the Git build
to generate a surprising amount of kernel overhead.
A fair chunk of the overhead is due to get_vmalloc_info() - which
walks a potentially long list to do its statistics.
Modify Linus's jiffies based patch to use generation counters
to cache the vmalloc info: vmap_unlock() increases the generation
counter, and the get_vmalloc_info() reads it and compares it
against a cached generation counter.
Also use a seqlock to make sure we always print a consistent
set of vmalloc statistics.
Reported-by: Linus Torvalds torva...@linux-foundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Rik van Riel r...@redhat.com
Cc: linux...@kvack.org
Signed-off-by: Ingo Molnar mi...@kernel.org
---
mm/vmalloc.c | 83 +---
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 605138083880..23df06ebb48a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -276,7 +276,21 @@ EXPORT_SYMBOL(vmalloc_to_pfn);
#define VM_LAZY_FREEING0x02
#define VM_VM_AREA 0x04
-static DEFINE_SPINLOCK(vmap_area_lock);
+static __cacheline_aligned_in_smp DEFINE_SPINLOCK(vmap_area_lock);
+
+#ifdef CONFIG_PROC_FS
+/*
+ * A seqlock and two generation counters for a simple cache of the
+ * vmalloc allocation statistics info printed in /proc/meminfo.
+ *
+ * ( The assumption of the optimization is that it's read frequently, but
+ * modified infrequently. )
+ */
+static DEFINE_SPINLOCK(vmap_info_lock);
+static int vmap_info_gen = 1;
+static int vmap_info_cache_gen;
+static struct vmalloc_info vmap_info_cache;
+#endif
static inline void vmap_lock(void)
{
@@ -285,6 +299,9 @@ static inline void vmap_lock(void)
static inline void vmap_unlock(void)
{
+#ifdef CONFIG_PROC_FS
+ WRITE_ONCE(vmap_info_gen, vmap_info_gen+1);
+#endif
spin_unlock(vmap_area_lock);
}
@@ -2699,7 +2716,7 @@ static int __init proc_vmalloc_init(void)
}
module_init(proc_vmalloc_init);
-void get_vmalloc_info(struct vmalloc_info *vmi)
+static void calc_vmalloc_info(struct vmalloc_info *vmi)
{
struct vmap_area *va;
unsigned long free_area_size;
@@ -2746,5 +2763,65 @@ void
Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp
On 2015. 8. 24., at AM 9:43, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: 2015-08-24 8:23 GMT+09:00 Rob Herring robherri...@gmail.com: On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote: Analogix dp driver is split from exynos dp driver, so we just make an copy of exynos_dp.txt, and then simplify exynos_dp.txt Beside update some exynos dtsi file with the latest change according to the devicetree binding documents. You can't just change the exynos bindings and break compatibility. Is there some agreement with exynos folks to do this? No, there is no agreement. This wasn't even sent to Exynos maintainers. Additionally the patchset did not look interesting to me because of misleading subject - Documentation instead of ARM: dts:. Yakir, please: 1. Provide backward compatibility. Mark old properties as deprecated but still support them. 2. Separate all DTS changes to a separate patch, unless bisectability would be hurt. Anyway you should prepare it in a such way that separation would be possible without breaking bisectability. 3. Use proper subject for the patch changing DTS. This is not documentation change! 4. Please use script get_maintainers to obtain list of valid maintainers and CC-them with at least cover letter and patches requiring their attention. To Yakir Yang, Please be careful when you CC people. I don't find the reason why you CC'ed the following people. Of course, they look to be one of the talented developers. However, they look to be unrelated to your patchset. Takashi Iwai Vincent Palatin Fabio Estevam Philipp Zabel Also, please add Exynos Architecture maintainers to CC list. I don't understand why you removed them from CC list. Kukjin Kim Krzysztof Kozlowski Without their Ack, you will not change the codes of ARM Exynos Architecture. Best regards, Jingoo Han Best regards, Krzysztof Signed-off-by: Yakir Yang y...@rock-chips.com --- Changes in v3: - Take Heiko suggest, add devicetree binding documents. - Take Thierry Reding suggest, remove sync pol colorimetry properies from the new analogix dp driver devicetree binding. - Update the exist exynos dtsi file with the latest DP DT properies. Changes in v2: None .../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 ++ .../devicetree/bindings/video/exynos_dp.txt| 50 ++-- arch/arm/boot/dts/exynos5250-arndale.dts | 10 ++-- arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 ++-- arch/arm/boot/dts/exynos5250-snow.dts | 12 ++-- arch/arm/boot/dts/exynos5250-spring.dts| 12 ++-- arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++-- arch/arm/boot/dts/exynos5420-smdk5420.dts | 10 ++-- arch/arm/boot/dts/exynos5800-peach-pi.dts | 12 ++-- 9 files changed, 119 insertions(+), 79 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt new file mode 100644 index 000..6127018 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt @@ -0,0 +1,70 @@ +Analogix Display Port bridge bindings + +Required properties for dp-controller: + -compatible: + platform specific such as: +* samsung,exynos5-dp +* rockchip,rk3288-dp + -reg: + physical base address of the controller and length + of memory mapped region. + -interrupts: + interrupt combiner values. + -clocks: + from common clock binding: handle to dp clock. + -clock-names: + from common clock binding: Shall be dp. + -interrupt-parent: + phandle to Interrupt combiner node. + -phys: + from general PHY binding: the phandle for the PHY device. + -phy-names: + from general PHY binding: Should be dp. + -analogix,color-space: + input video data format. + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 + -analogix,color-depth: + number of bits per colour component. + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 This seems pretty generic. Just use 6, 8, 10, or 12 for values. And drop the vendor prefix. + -analogix,link-rate: + max link rate supported by the eDP controller. + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A, + LINK_RATE_5_40GBPS = 0x14 Same here. I'd rather see something like link-rate-mbps and use the actual rate. + -analogix,lane-count: + max number of lanes supported by the eDP contoller. + LANE_COUNT1 = 1, LANE_COUNT2 = 2,
Re: [PATCH v3 2/2] drivers: rtc: add xilinx zynqmp rtc driver
On 19/08/2015 at 15:23:22 +0530, Suneel Garapati wrote : adds support for RTC controller found on Xilinx Zynq Ultrascale+ MPSoC platform. Signed-off-by: Suneel Garapati suneel.garap...@xilinx.com --- Changes v3 - fix checkpatch errors - check time in secs arg against max sec val - order header files - use ptr_err_or_zero macro - use time64 variants Changes v2 - change alm to alarm --- drivers/rtc/Kconfig | 7 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-zynqmp.c | 279 +++ 3 files changed, 287 insertions(+) create mode 100644 drivers/rtc/rtc-zynqmp.c Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
* Mike Galbraith umgwanakikb...@gmail.com wrote: On Mon, 2015-08-24 at 08:44 +0200, Ingo Molnar wrote: the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a full mask to it (housekeeping_mask - a variable mask to begin with) and recover the housekeeping CPU via: + return cpumask_any_and(housekeeping_mask, cpu_online_mask); There can be, and had better be if box is big, multiple housekeepers. Yes - but that does not seem to be possible via the code right now AFAICS, so at minimum it's incomplete. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3 v5] mm/vmalloc: Cache the vmalloc memory info
* Ingo Molnar mi...@kernel.org wrote:
One more detail: I just realized that with the read barriers, the READ_ONCE()
accesses are not needed anymore - the barriers and the control dependencies
are
enough.
This will further simplify the code.
I.e. something like the updated patch below. (We still need the WRITE_ONCE()
for
vmap_info_gen update.)
Thanks,
Ingo
From 46a0507e0a395a7bc2fe4b46a4766e7457ac0140 Mon Sep 17 00:00:00 2001
From: Ingo Molnar mi...@kernel.org
Date: Sat, 22 Aug 2015 12:28:01 +0200
Subject: [PATCH] mm/vmalloc: Cache the vmalloc memory info
Linus reported that for scripting-intense workloads such as the
Git build, glibc's qsort will read /proc/meminfo for every process
created (by way of get_phys_pages()), which causes the Git build
to generate a surprising amount of kernel overhead.
A fair chunk of the overhead is due to get_vmalloc_info() - which
walks a potentially long list to do its statistics.
Modify Linus's jiffies based patch to use generation counters
to cache the vmalloc info: vmap_unlock() increases the generation
counter, and the get_vmalloc_info() reads it and compares it
against a cached generation counter.
Also use a seqlock to make sure we always print a consistent
set of vmalloc statistics.
Reported-by: Linus Torvalds torva...@linux-foundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Rik van Riel r...@redhat.com
Cc: linux...@kvack.org
Signed-off-by: Ingo Molnar mi...@kernel.org
---
mm/vmalloc.c | 82 +---
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 605138083880..2f8d9660e007 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -276,7 +276,21 @@ EXPORT_SYMBOL(vmalloc_to_pfn);
#define VM_LAZY_FREEING0x02
#define VM_VM_AREA 0x04
-static DEFINE_SPINLOCK(vmap_area_lock);
+static __cacheline_aligned_in_smp DEFINE_SPINLOCK(vmap_area_lock);
+
+#ifdef CONFIG_PROC_FS
+/*
+ * A seqlock and two generation counters for a simple cache of the
+ * vmalloc allocation statistics info printed in /proc/meminfo.
+ *
+ * ( The assumption of the optimization is that it's read frequently, but
+ * modified infrequently. )
+ */
+static DEFINE_SPINLOCK(vmap_info_lock);
+static int vmap_info_gen = 1;
+static int vmap_info_cache_gen;
+static struct vmalloc_info vmap_info_cache;
+#endif
static inline void vmap_lock(void)
{
@@ -285,6 +299,9 @@ static inline void vmap_lock(void)
static inline void vmap_unlock(void)
{
+#ifdef CONFIG_PROC_FS
+ WRITE_ONCE(vmap_info_gen, vmap_info_gen+1);
+#endif
spin_unlock(vmap_area_lock);
}
@@ -2699,7 +2716,7 @@ static int __init proc_vmalloc_init(void)
}
module_init(proc_vmalloc_init);
-void get_vmalloc_info(struct vmalloc_info *vmi)
+static void calc_vmalloc_info(struct vmalloc_info *vmi)
{
struct vmap_area *va;
unsigned long free_area_size;
@@ -2746,5 +2763,64 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
out:
rcu_read_unlock();
}
-#endif
+/*
+ * Return a consistent snapshot of the current vmalloc allocation
+ * statistics, for /proc/meminfo:
+ */
+void get_vmalloc_info(struct vmalloc_info *vmi)
+{
+ int gen = vmap_info_gen;
+
+ /*
+* If the generation counter of the cache matches that of
+* the vmalloc generation counter then return the cache:
+*/
+ if (vmap_info_cache_gen == gen) {
+ int gen_after;
+
+ /*
+* The two read barriers make sure that we read
+* 'gen', 'vmap_info_cache' and 'gen_after' in
+* precisely that order:
+*/
+ smp_rmb();
+ *vmi = vmap_info_cache;
+
+ smp_rmb();
+ gen_after = vmap_info_gen;
+
+ /* The cache is still valid: */
+ if (gen == gen_after)
+ return;
+
+ /* Ok, the cache got invalidated just now, regenerate it */
+ gen = gen_after;
+ }
+
+ /* Make sure 'gen' is read before the vmalloc info */
+ smp_rmb();
+
+ calc_vmalloc_info(vmi);
+
+ /*
+* All updates to vmap_info_cache_gen go through this spinlock,
+* so when the cache got invalidated, we'll only mark it valid
+* again if we first fully write the new vmap_info_cache.
+*
+* This ensures that partial results won't be used.
+*/
+ spin_lock(vmap_info_lock);
+ if (gen-vmap_info_cache_gen 0) {
+ vmap_info_cache = *vmi;
+ /*
+* Make sure the new cached data is visible before
+* the generation counter update:
+*/
+ smp_wmb();
+ vmap_info_cache_gen = gen;
+ }
+ spin_unlock(vmap_info_lock);
+}
+
+#endif /* CONFIG_PROC_FS */
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH v2 1/5] clocksource: mediatek: do not enable GPT_CLK_EVT when setup
On 08/21/2015 04:39 PM, Yingjoe Chen wrote: [ ... ] - Does the spurious interrupt occurs *every* time ? at each boot ? Yes. If you applied this series to enable mtk timer without this fix on mt8173 or mt8135 you can reproduce it. It occurs for every boot. It crash before uart driver is ready, so you'll have to use earlycon to see the crash log. Can you give me the earlycon params ? Thanks. -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
On Mon, 2015-08-24 at 09:41 +0200, Ingo Molnar wrote: * Mike Galbraith umgwanakikb...@gmail.com wrote: On Mon, 2015-08-24 at 08:44 +0200, Ingo Molnar wrote: the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a full mask to it (housekeeping_mask - a variable mask to begin with) and recover the housekeeping CPU via: + return cpumask_any_and(housekeeping_mask, cpu_online_mask); There can be, and had better be if box is big, multiple housekeepers. Yes - but that does not seem to be possible via the code right now AFAICS, so at minimum it's incomplete. In master housekeepers are set up in tick_nohz_init(). Everybody who's not a nohz_full CPU is a housekeeper. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ubifs: Allow O_DIRECT
On Mon, Aug 24, 2015 at 10:13:25AM +0300, Artem Bityutskiy wrote: 1. we are the only FS erroring out on O_DIRECT 2. other file-systems not supporting direct IO just fake it There are lots of file systems not supporting O_DIRECT, but ubifs might be the most common one. Given that O_DIRECT implementations aren't hard, so what's holding back a real implementation? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
* Mike Galbraith umgwanakikb...@gmail.com wrote:
On Mon, 2015-08-24 at 09:41 +0200, Ingo Molnar wrote:
* Mike Galbraith umgwanakikb...@gmail.com wrote:
On Mon, 2015-08-24 at 08:44 +0200, Ingo Molnar wrote:
the 'housekeeping CPU' is essentially the boot CPU. Yet we dedicate a
full mask to
it (housekeeping_mask - a variable mask to begin with) and recover the
housekeeping CPU via:
+ return cpumask_any_and(housekeeping_mask, cpu_online_mask);
There can be, and had better be if box is big, multiple housekeepers.
Yes - but that does not seem to be possible via the code right now AFAICS,
so
at minimum it's incomplete.
In master housekeepers are set up in tick_nohz_init(). Everybody who's not a
nohz_full CPU is a housekeeper.
Ah, indeed, I missed the nohz_full= boot option:
static int __init tick_nohz_full_setup(char *str)
{
alloc_bootmem_cpumask_var(tick_nohz_full_mask);
if (cpulist_parse(str, tick_nohz_full_mask) 0) {
Ok, first question is resolved - but the second one, behavior on boot CPU
unplug
still holds.
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/7] ARM: dts: add SROM device node for exynos5
Add SROM controller device node for exynos5.
CC: Rob Herring robh...@kernel.org
CC: Mark Rutland mark.rutl...@arm.com
CC: Ian Campbell ijc+devicet...@hellion.org.uk
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/boot/dts/exynos5.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 110dbd4..b5d3437 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -30,6 +30,11 @@
reg = 0x1000 0x100;
};
+ sromc@1225 {
+ compatible = samsung,exynos-srom;
+ reg = 0x1225 0x10;
+ };
+
combiner: interrupt-controller@1044 {
compatible = samsung,exynos4210-combiner;
#interrupt-cells = 2;
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/7] Documentation: dt-bindings: add exynos-srom binding information
This patch adds exynos-srom binding information for SROM Controller
driver on Exynos SoCs.
CC: Rob Herring robh...@kernel.org
CC: Mark Rutland mark.rutl...@arm.com
CC: Ian Campbell ijc+devicet...@hellion.org.uk
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
.../devicetree/bindings/arm/samsung/exynos-srom.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
new file mode 100644
index 000..33886d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -0,0 +1,12 @@
+SAMSUNG Exynos SoCs SROM Controller driver.
+
+Required properties:
+- compatible : Should contain samsung,exynos-srom.
+
+- reg: offset and length of the register set
+
+Example:
+ sromc@1257 {
+ compatible = samsung,exynos-srom;
+ reg = 0x1257 0x10;
+ };
--
2.4.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] drivers: rtc: add xilinx zynqmp rtc driver
On 24/08/2015 at 09:48:42 +0200, Michal Simek wrote : On 08/24/2015 09:43 AM, Alexandre Belloni wrote: On 19/08/2015 at 15:23:22 +0530, Suneel Garapati wrote : adds support for RTC controller found on Xilinx Zynq Ultrascale+ MPSoC platform. Signed-off-by: Suneel Garapati suneel.garap...@xilinx.com --- Changes v3 - fix checkpatch errors - check time in secs arg against max sec val - order header files - use ptr_err_or_zero macro - use time64 variants Changes v2 - change alm to alarm --- drivers/rtc/Kconfig | 7 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-zynqmp.c | 279 +++ 3 files changed, 287 insertions(+) create mode 100644 drivers/rtc/rtc-zynqmp.c Applied, thanks. Actually, I got the following message: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: suneel.garap...@xilinx.com Unknown User I'm not fond of carrying patches with uncontactable authors. Is that a permanent error? -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ubifs: Allow O_DIRECT
On Mon, Aug 24, 2015 at 03:17:10PM +0800, Dongsheng Yang wrote: Richard, you mention this was suggested by Dave, could you please pint to the discussion, if possible? http://lists.infradead.org/pipermail/linux-mtd/2015-August/060702.html That's in a discussion I want to introduce ubifs into xfstests. FYI, xfstests is a test suite, _not_ an application. Adding O_DIRECT just for xfstests is utterly dumb and suggeting that is even dumber. xfstests should check for supported features, and skip tests that use it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ubifs: Allow O_DIRECT
On 08/24/2015 04:03 PM, Christoph Hellwig wrote: On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote: Back when we were writing UBIFS, we did not need direct IO, so we did not implement it. But yes, probably someone who cares could just try implementing this feature. So I think the answer here is to implement a real version insted of adding hacks to pretend it is supported. Actually, I had a plan for it. But it's for 4.4 or 4.5 in my plan. Yang . -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
