Re: [Linaro-mm-sig] [RFC 0/2] DMA-mapping IOMMU - physically contiguous allocations
Hi Inki/Marek, On Tue, 16 Oct 2012 02:50:16 +0200 Inki Dae inki@samsung.com wrote: 2012/10/15 Marek Szyprowski m.szyprow...@samsung.com: Hello, Some devices, which have IOMMU, for some use cases might require to allocate a buffers for DMA which is contiguous in physical memory. Such use cases appears for example in DRM subsystem when one wants to improve performance or use secure buffer protection. I would like to ask if adding a new attribute, as proposed in this RFC is a good idea? I feel that it might be an attribute just for a single driver, but I would like to know your opinion. Should we look for other solution? In addition, currently we have worked dma-mapping-based iommu support for exynos drm driver with this patch set so this patch set has been tested with iommu enabled exynos drm driver and worked fine. actually, this feature is needed for secure mode such as TrustZone. in case of Exynos SoC, memory region for secure mode should be physically contiguous and also maybe OMAP but now dma-mapping framework doesn't guarantee physically continuous memory allocation so this patch set would make it possible. Agree that the contigous memory allocation is necessary for us too. In addition to those contiguous/discontiguous page allocation, is there any way to _import_ anonymous pages allocated by a process to be used in dma-mapping API later? I'm considering the following scenario, an user process allocates a buffer by malloc() in advance, and then it asks some driver to convert that buffer into IOMMU'able/DMA'able ones later. In this case, pages are discouguous and even they may not be yet allocated at malloc()/mmap(). -- 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: mpol_to_str revisited.
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote: I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix. It's certainly not a complete fix, but I think it's a much better result of the race, i.e. we don't panic anymore, we simply fail the read() instead. Even though 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a itself is simple. It bring to caller complex. That's not good and have no worth. Before: the kernel panics, all workloads cease. After: the file shows garbage, all workloads continue. This is better, in my opinion, but at best it's only a judgment call and has no effect on anything. I agree it would be better to respect the return value of mpol_to_str() since there are other possible error conditions other than a freed mempolicy, but let's not consider reverting 80de7c3138. It is obviously not a full solution to the problem, though, and we need to serialize with task_lock(). Dave, are you interested in coming up with a patch? -- 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] oom, memcg: handle sysctl oom_kill_allocating_task while memcg oom happening
On Tue, 16 Oct 2012, Sha Zhengju wrote: From: Sha Zhengju handai@taobao.com Sysctl oom_kill_allocating_task enables or disables killing the OOM-triggering task in out-of-memory situations, but it only works on overall system-wide oom. But it's also a useful indication in memcg so we take it into consideration while oom happening in memcg. Other sysctl such as panic_on_oom has already been memcg-ware. You're working on an old kernel, mem_cgroup_out_of_memory() has moved to mm/memcontrol.c. Please rebase on 3.7-rc1 and send an updated patch, which otherwise looks good. -- 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 5/6] MFD: twl6040: Convert to use regmap_irq
On Thu, Oct 11, 2012 at 01:55:32PM +0200, Peter Ujfalusi wrote: With regmap_irq it is possibole to remove the twl6040-irq.c file and simplify the code. Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.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: Write is not atomic?
This seems out of context. If the file was open(2)ed with O_APPEND, the file offset is first set to the end of the file before writing. The adjustment of the file offset and the write operation are performed as an atomic step. Sounds different, doesn't it? Yes, it does -- thanks for the clarification. (And thanks to Dave for the interesting tests.) Sorry for the confusion, -- Juliusz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ACPI: move acpi_no_s4_hw_signature() declaration into #ifdef CONFIG_HIBERNATION
On Tue, Oct 16, 2012 at 01:24:12PM +0800, Yuanhan Liu wrote: acpi_no_s4_hw_signature is defined in #ifdef CONFIG_HIBERNATION block, but the current code put the declaration in #ifdef CONFIG_PM_SLEEP block. I happened to meet this issue when I turned off PM_SLEEP config manually: arch/x86/kernel/acpi/sleep.c:100:4: error: implicit declaration of function ‘acpi_no_s4_hw_signature’ [-Werror=implicit-function-declaration] This should be more clear: Fix build error on !CONFIG_PM_SLEEP: arch/x86/kernel/acpi/sleep.c:100:4: error: implicit declaration of function ‘acpi_no_s4_hw_signature’ The root cause is, acpi_no_s4_hw_signature() is defined in #ifdef CONFIG_HIBERNATION block, but the current code put the declaration in #ifdef CONFIG_PM_SLEEP block. Thanks, Fengguang v2: take better title and add build error message suggested by Fengguang Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com Reviewed-by: Fengguang Wu fengguang...@intel.com --- include/linux/acpi.h |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 90be989..a468429 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -257,8 +257,11 @@ int acpi_check_region(resource_size_t start, resource_size_t n, int acpi_resources_are_enforced(void); -#ifdef CONFIG_PM_SLEEP +#ifdef CONFIG_HIBERNATION void __init acpi_no_s4_hw_signature(void); +#endif + +#ifdef CONFIG_PM_SLEEP void __init acpi_old_suspend_ordering(void); void __init acpi_nvs_nosave(void); #endif /* CONFIG_PM_SLEEP */ -- 1.7.7.6 -- 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] oom, memcg: handle sysctl oom_kill_allocating_task while memcg oom happening
From: Sha Zhengju handai@taobao.com
Sysctl oom_kill_allocating_task enables or disables killing the OOM-triggering
task in out-of-memory situations, but it only works on overall system-wide oom.
But it's also a useful indication in memcg so we take it into consideration
while oom happening in memcg. Other sysctl such as panic_on_oom has already
been memcg-ware.
Signed-off-by: Sha Zhengju handai@taobao.com
---
mm/oom_kill.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 38129e3..2a176af 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -574,6 +574,18 @@ void mem_cgroup_out_of_memory(struct mem_cgroup *memcg,
gfp_t gfp_mask)
check_panic_on_oom(CONSTRAINT_MEMCG, gfp_mask, 0, NULL);
limit = mem_cgroup_get_limit(memcg) PAGE_SHIFT;
read_lock(tasklist_lock);
+ if (sysctl_oom_kill_allocating_task
+ !oom_unkillable_task(current, memcg, NULL)
+ current-mm) {
+ /*
+* oom_kill_process() needs tasklist_lock held. If it returns
+* non-zero, current could not be killed so we must fallback to
+* the tasklist scan.
+*/
+ if (!oom_kill_process(current, gfp_mask, 0, 0, limit, memcg,
NULL,
+ Memory cgroup out of memory
(oom_kill_allocating_task)))
+ goto out;
+ }
retry:
p = select_bad_process(points, limit, memcg, NULL);
if (!p || PTR_ERR(p) == -1UL)
--
1.7.6.1
This email (including any attachments) is confidential and may be legally
privileged. If you received this email in error, please delete it immediately
and do not copy it or use it for any purpose or disclose its contents to any
other person. Thank you.
±¾µçÓÊ(°üÀ¨Èκθ½¼þ)¿ÉÄܺ¬ÓлúÃÜ×ÊÁϲ¢ÊÜ·¨Âɱ£»¤¡£ÈçÄú²»ÊÇÕýÈ·µÄÊÕ¼þÈË£¬ÇëÄúÁ¢¼´É¾³ý±¾Óʼþ¡£Çë²»Òª½«±¾µçÓʽøÐи´ÖƲ¢ÓÃ×÷ÈκÎÆäËûÓÃ;¡¢»ò͸¶±¾ÓʼþÖ®ÄÚÈÝ¡£Ð»Ð»¡£
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/06] input/rmi4: Public header and documentation
On Thu, Oct 11, 2012 at 05:32:59PM +0200, Linus Walleij wrote: On Thu, Oct 11, 2012 at 5:41 AM, Christopher Heiny che...@synaptics.com wrote: In previous patch submissions, we always used these warning functions. But in the feedback on those patches, we were asked to just make sysfs show/store NULL if the attribute is write/read only. However, during their development process, our customers want to see the warnings if the attributes are accessed incorrectly. So we made these warnings a debug option. Basically my stance is that you should not lower yourself to the level of others not getting the point of your technical solution by making unelegant compromises, what you should do is to bring them up to your level so they understand that your solution is elegant. It seems like what you really want to do is add a debug feature to sysfs which will optionally complain loudly at bad accesses; obviously it's not something that should be there all the time as running then handling an error is a perfectly legitimate thing to do. As with the /CS handling it'd mean it was handled at an appropriate level and could be reused elsewhere (it might also help make it clear to your customers why this is generally bad form). -- 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] oom, memcg: handle sysctl oom_kill_allocating_task while memcg oom happening
On 10/16/2012 02:12 PM, David Rientjes wrote: On Tue, 16 Oct 2012, Sha Zhengju wrote: From: Sha Zhengjuhandai@taobao.com Sysctl oom_kill_allocating_task enables or disables killing the OOM-triggering task in out-of-memory situations, but it only works on overall system-wide oom. But it's also a useful indication in memcg so we take it into consideration while oom happening in memcg. Other sysctl such as panic_on_oom has already been memcg-ware. You're working on an old kernel, mem_cgroup_out_of_memory() has moved to mm/memcontrol.c. Please rebase on 3.7-rc1 and send an updated patch, which otherwise looks good. Thanks for reminding! Yes, I cooked it on memcg-devel git repo but a out-of-date since-3.2 branch... But I notice the latest branch is since-3.5(not seeing 3.6/3.7), does it okay to working on this branch? Thanks, Sha -- 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: Re: [PATCH] block: Add blk_rq_pos(rq) to sort rq when plushing plug-list.
On 2012-10-15 21:18 Shaohua Li s...@kernel.org Wrote: 2012/10/15 Shaohua Li s...@fusionio.com: 2012/10/15 Jianpeng Ma majianp...@gmail.com: My workload is a raid5 which had 16 disks. And used our filesystem to write using direct-io mode. I used the blktrace to find those message: 8,16 0 3570 1.083923979 2519 I W 144323176 + 24 [md127_raid5] 8,16 00 1.083926214 0 m N cfq2519 insert_request 8,16 0 3571 1.083926586 2519 I W 144323072 + 104 [md127_raid5] 8,16 00 1.083926952 0 m N cfq2519 insert_request 8,16 0 3572 1.083927180 2519 U N [md127_raid5] 2 8,16 00 1.083927870 0 m N cfq2519 Not idling.st-count:1 8,16 00 1.083928320 0 m N cfq2519 dispatch_insert 8,16 00 1.083928951 0 m N cfq2519 dispatched a request 8,16 00 1.083929443 0 m N cfq2519 activate rq,drv=1 8,16 0 3573 1.083929530 2519 D W 144323176 + 24 [md127_raid5] 8,16 00 1.083933883 0 m N cfq2519 Not idling.st-count:1 8,16 00 1.083934189 0 m N cfq2519 dispatch_insert 8,16 00 1.083934654 0 m N cfq2519 dispatched a request 8,16 00 1.083935014 0 m N cfq2519 activate rq,drv=2 8,16 0 3574 1.083935101 2519 D W 144323072 + 104 [md127_raid5] 8,16 0 3575 1.084196179 0 C W 144323176 + 24 [0] 8,16 00 1.084197979 0 m N cfq2519 complete rqnoidle 0 8,16 0 3576 1.084769073 0 C W 144323072 + 104 [0] .. 8,16 1 3596 1.091394357 2519 I W 144322544 + 16 [md127_raid5] 8,16 10 1.091396181 0 m N cfq2519 insert_request 8,16 1 3597 1.091396571 2519 I W 144322520 + 24 [md127_raid5] 8,16 10 1.091396934 0 m N cfq2519 insert_request 8,16 1 3598 1.091397165 2519 I W 144322488 + 32 [md127_raid5] 8,16 10 1.091397477 0 m N cfq2519 insert_request 8,16 1 3599 1.091397708 2519 I W 144322432 + 56 [md127_raid5] 8,16 10 1.091398023 0 m N cfq2519 insert_request 8,16 1 3600 1.091398284 2519 U N [md127_raid5] 4 8,16 10 1.091398986 0 m N cfq2519 Not idling. st-count:1 8,16 10 1.091399511 0 m N cfq2519 dispatch_insert 8,16 10 1.091400217 0 m N cfq2519 dispatched a request 8,16 10 1.091400688 0 m N cfq2519 activate rq,drv=1 8,16 1 3601 1.091400766 2519 D W 144322544 + 16 [md127_raid5] 8,16 10 1.091406151 0 m N cfq2519 Not idling.st-count:1 8,16 10 1.091406460 0 m N cfq2519 dispatch_insert 8,16 10 1.091406931 0 m N cfq2519 dispatched a request 8,16 10 1.091407291 0 m N cfq2519 activate rq,drv=2 8,16 1 3602 1.091407378 2519 D W 144322520 + 24 [md127_raid5] 8,16 10 1.091414006 0 m N cfq2519 Not idling.st-count:1 8,16 10 1.091414297 0 m N cfq2519 dispatch_insert 8,16 10 1.091414702 0 m N cfq2519 dispatched a request 8,16 10 1.091415047 0 m N cfq2519 activate rq, drv=3 8,16 1 3603 1.091415125 2519 D W 144322488 + 32 [md127_raid5] 8,16 10 1.091416469 0 m N cfq2519 Not idling.st-count:1 8,16 10 1.091416754 0 m N cfq2519 dispatch_insert 8,16 10 1.091417186 0 m N cfq2519 dispatched a request 8,16 10 1.091417535 0 m N cfq2519 activate rq,drv=4 8,16 1 3604 1.091417628 2519 D W 144322432 + 56 [md127_raid5] 8,16 1 3605 1.091857225 4393 C W 144322544 + 16 [0] 8,16 10 1.091858753 0 m N cfq2519 complete rqnoidle 0 8,16 1 3606 1.092068456 4393 C W 144322520 + 24 [0] 8,16 10 1.092069851 0 m N cfq2519 complete rqnoidle 0 8,16 1 3607 1.092350440 4393 C W 144322488 + 32 [0] 8,16 10 1.092351688 0 m N cfq2519 complete rqnoidle 0 8,16 1 3608 1.093629323 0 C W 144322432 + 56 [0] 8,16 10 1.093631151 0 m N cfq2519 complete rqnoidle 0 8,16 10 1.093631574 0 m N cfq2519 will busy wait 8,16 10 1.093631829 0 m N cfq schedule dispatch Because in func elv_attempt_insert_merge, it only to try to backmerge.So the four request can't merge in theory. I trace ten minutes and count those situation, it can count 25%. With the patch,i tested and not found situation like above. Signed-off-by: Jianpeng Ma majianp...@gmail.com --- block/blk-core.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index a33870b..3c95c4d 100644 ---
Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
From: Yu, Fenghua fenghua...@intel.com Subject: RE: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP Date: Tue, 16 Oct 2012 05:14:46 + My motivation is to use multiple CPUs in order to quickly generate crash dump on the machine with huge amount of memory. I assume such machine tends to also have a lot of CPUs. So disabling one CPU would be no problem. Luckily you don't need to disable any CPU to archive your goal with the BSP hotplug pachest:) On a dual core/single thread machine, this means you get 100% performance boost with BSP's help. Plus crash dump kernel code is better structured by not treating BSP specially. Hello Fenghua. I've of course noticed your patch set and locally tested, but I saw NMI to BSP failed in the 2nd kernel. I'll send a log to you later. BTW, I tested with your previous v8 patch set. Did you change something during v8 to v9 relevant to this issue? In the patch 0/12 in v9, I describe what change is in v9 on the top of v8: v9: Add Intel vendor check to support the feature on Intel platforms only. Did you see the BSP wake up failure on the latest tip tree? There is a rcu regression issue which prevents BSP from waking up in 3.6.0. The issue has been fixed on 10/12. The commit is a4fbe35a. Please make sure your tip tree has this commit. Thanks for pointing out this. And I've recalled my investigation in the past now. So I want to stop retrying your patch v9 now. This NMI method is definitely not applicable to 2nd kernel without any change. Your NMI method assumes BSP thread is halting in play dead loop. But on the 2nd kernel, BSP is halting in the 1st kernel (or possibly in a fatail system error). Even if throwing NMI to BSP, it goes back to the 1st kernel soon again. I at least confirmed NMI handler is executed in this case. Also, throwing NMI changes stack in the 1st kernel, which is unpermissible from kdump's perspective. But x86_64 uses Interrupt Stack Table (IST), in which stack switching is not performed. So 2nd kernel's stack is used at least on x86_64. To sum up, to apply NMI method in the 2nd kernel, I think it necessary to modify contexts pushed on the stack so execution goes to the 2nd kernel's start_secondary() while initializing its state appropreately. Also I think it necessary to discuss whether this NMI method is reliable enough for kdump use. Thanks. HATAYAMA, Daisuke -- 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: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
Hi Philippe, On 09/10/12 19:07, Philippe De Muyter wrote: [CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Do you get any responses? I didn't see any... Regards Greg On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: Hi Philippe, On 05/10/12 01:03, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: My biggest concern is the amount of MCD/DMA support code. And it is all done quite differently to everything else in the kernel. We may get a bit of push back from kernel folk who look after DMA. Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm (also from freescale, maybe an identical part, but I did not find any usable doc), but the powerpc folks kept that hidden in the arch/powerpc tree, instead of installing it in drivers/dma. The MCD DMA or DMA FEC code from freescale has a comment implying that this was first used in the MPC8220 part. And Montavista has a MPC8220 port, but I did not find it, so I do not know where they installed the MCD DMA driver. Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIFO_STATUSFECRFSR 18C RFIFO_CONTROL FECRFCR 190 RFIFO_LRF_PTR FECRLRFP 194 RFIFO_LWF_PTR FECRLWFP 198 RFIFO_ALARM FECRFAR 19C RFIFO_RDPTR FECRFRP 1A0 RFIFO_WRPTR FECRFWP 1A4 TFIFO_DATA FECTFDR 1A8 TFIFO_STATUSFECTFSR 1AC TFIFO_CONTROL FECTFCR 1B0 TFIFO_LRF_PTR FECTLRFP 1B4 TFIFO_LWF_PTR FECTLWFP 1B8 TFIFO_ALARM FECTFAR 1BC TFIFO_RDPTR FECTFRP 1C0 TFIFO_WRPTR FECTFWP 1C4 RESET_CNTRL FECFRST 1C8 XMIT_FSMFECCTCWR Probably the best thing to do is post the patches on the linux kernel mailing list then, asking for direction on a dma driver. I have no problem with it going into the arch/m68k area. So that is always an option. For the dma engines, the similarity is also obvious. For example, find below side by side mpc52xx and m54xx definitions for the
[git pull] drm fixes
Hi Linus, fixes for i915, nouveau and radeon i915: haswell stability, modeset rework fallout, ums fix nouveau: misc fixes from code rework radeon: pll rework fixes, more 2 level PTE cleanups. core: warning fixes on 32-bit. Dave. The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to 8a00b6af4cc547725f231c8367ddc7cb56b2cf76: nouveau: fix warning on 32-bit build. (2012-10-16 16:40:53 +1000) Alex Deucher (5): drm/radeon: fix compilation with backlight disabled drm/radeon: allocate PPLLs from low to high drm/radeon: update comments to clarify VM setup (v2) drm/radeon/cayman: set VM max pfn at MC init drm/radeon: check if pcie gen 2 is already enabled (v2) Ben Skeggs (1): drm/nouveau/bios: fix typo in error message Chris Wilson (2): drm/i915: Disallow preallocation of requests drm/i915: fixup i915_gem_object_get_page inline helper Christian König (3): drm/radeon: allocate page tables on demand v4 drm/radeon: don't add the IB pool to all VMs v2 drm/radeon: separate pt alloc from lru add Daniel Vetter (5): drm/i915: paper over a pipe-enable vs pageflip race drm/i915: disable wc gtt pte mappings on gen2 drm/i915: rip out the pipe A quirk for i855gm drm/i915: fixup the plane-pipe fixup code drm/i915/dvo-ch7xxx: fix get_hw_state Dave Airlie (5): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drm: fix warning on 32-bit. Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes nouveau: fix warning on 32-bit build. Egbert Eich (1): drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy(). Jani Nikula (1): drm/i915: fix non-DP-D eDP backlight cleanup and module reload Kenneth Graunke (1): drm/i915: Set guardband clipping workaround bit in the right register. Luca Tettamanti (1): drm/radeon: use %zu for formatting size_t Marcin Slusarz (1): drm/nv50/fb: fix double free of vram mm Martin Peres (3): drm/nouveau/hwmon: fix the initialization condition drm/nouveau/pm: fix a typo related to the move to the therm subdev drm/nouveau/pm: do not stop reclocking if failing to set the fan speed Max Filippov (1): drm/nouveau: only call ttm_agp_tt_create when __OS_HAS_AGP Randy Dunlap (1): drm: radeon: fix printk format warning Rodrigo Vivi (1): drm/i915: HSW CRW stability magic Thomas Friebel (1): drm/radeon: fix spelling typos in debugging output Willy Tarreau (1): drm/i915: remove useless BUG_ON which caused a regression in 3.5. drivers/char/agp/intel-gtt.c|2 +- drivers/gpu/drm/drm_info.c |2 +- drivers/gpu/drm/i915/dvo_ch7xxx.c |6 +- drivers/gpu/drm/i915/i915_drv.h |9 +- drivers/gpu/drm/i915/i915_gem.c | 19 +- drivers/gpu/drm/i915/i915_reg.h |2 +- drivers/gpu/drm/i915/intel_display.c| 47 ++- drivers/gpu/drm/i915/intel_dp.c |3 +- drivers/gpu/drm/i915/intel_overlay.c| 72 + drivers/gpu/drm/i915/intel_pm.c |4 +- drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c |2 +- drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c |1 - drivers/gpu/drm/nouveau/core/subdev/therm/fan.c |2 +- drivers/gpu/drm/nouveau/nouveau_bo.c|2 + drivers/gpu/drm/nouveau/nouveau_pm.c|6 +- drivers/gpu/drm/radeon/atombios_crtc.c |8 +- drivers/gpu/drm/radeon/evergreen.c |7 +- drivers/gpu/drm/radeon/ni.c | 12 +- drivers/gpu/drm/radeon/r600.c |6 + drivers/gpu/drm/radeon/radeon.h | 14 +- drivers/gpu/drm/radeon/radeon_acpi.c|6 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c|2 +- drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_device.c |4 + drivers/gpu/drm/radeon/radeon_gart.c| 374 --- drivers/gpu/drm/radeon/radeon_kms.c | 22 +- drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 48 ++- drivers/gpu/drm/radeon/radeon_ring.c|2 +- drivers/gpu/drm/radeon/si.c |7 +- 29 files changed, 443 insertions(+), 249 deletions(-)
Re: [PATCH v2 2/4] gpio: add viperboard gpio driver
On Monday 15 October 2012 at 15:00:12, Linus Walleij wrote:
+#define VPRBRD_GPIOA_CLK_1 0 /* (1us = 1MHz)
*/ +#define VPRBRD_GPIOA_CLK_101 /* (10us =
100kHz) */ +#define VPRBRD_GPIOA_CLK_100 2 /* (100us
= 10kHz) */ +#define VPRBRD_GPIOA_CLK_1000 3 /* (1ms
= 1kHz) */ +#define VPRBRD_GPIOA_CLK_1 4 /*
(10ms = 100Hz) */ +#define VPRBRD_GPIOA_CLK_105
/* (100ms = 10Hz) */
So instead of #defining something noone understands and
then writing in the comment what it actually means, why
don't you just:
#define VPRBRD_GPIOA_CLK_1MHZ 0
#define VPRBRD_GPIOA_CLK_100KHZ 1
or maybe:
#define VPRBRD_GPIOA_CLK_PERIOD_1US 0
#define VPRBRD_GPIOA_CLK_PERIOD_10US1
or something else you will understand immediately when reading the
code?
Yes, you are right. I was too involved with my hardware to see this. I will
change this.
+struct __packed vprbrd_gpioa_msg {
__packed always goes *after* the struct does it not?
+ u8 cmd;
+ u8 clk;
+ u8 offset;
+ u8 t1;
+ u8 t2;
+ u8 invert;
+ u8 pwmlevel;
+ u8 outval;
+ u8 risefall;
+ u8 answer;
+ u8 __fill;
+}; - i.e. here, before the semicolon.
GCC does allow both alternatives. See description of packed attribute under:
http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type-Attributes
But since most kernel code does it right before the semicolon, I will change
that too.
+/* gpioa sampling clock module parameter */
+static unsigned char gpioa_clk = 3;
Isn't this actually
static unsigned char gpioa_clk = VPRBRD_GPIOA_CLK_1000
+module_param(gpioa_clk, byte, 0);
+MODULE_PARM_DESC(gpioa_clk, gpio a sampling clk (default is 3 for 1
kHz));
So if you're adding very magic module parameters maybe
this magic number isn't such a good idea. Oh well, there
are stranger things in the world so OK...
Also I will change this to be more descriptive.
+static int vprbrd_gpioa_get(struct gpio_chip *chip,
+ unsigned offset)
+{
+ int ret, answer, error = 0;
+ struct vprbrd_gpio *gpio =
+ container_of(chip, struct vprbrd_gpio, gpioa);
+ struct vprbrd *vb = gpio-vb;
+ struct vprbrd_gpioa_msg *gamsg = (struct vprbrd_gpioa_msg
*)vb-buf; +
+ /* if io is set to output, just return the saved value */
+ if (gpio-gpioa_out (1 offset))
+ return gpio-gpioa_val (1 offset);
That's not going to work if the hardware changes state
behind the back of the driver right? Oh well, maybe
it doesn't matter.
I thought about that and then did this cache only in case the gpio is a
output to save to usb ping-pong that is needed otherwise. I thought that
nothing can change to state of the output but the driver itself.
The rest does some clever USB marshalling that I trust
is doing what it should :-)
+ ret = usb_control_msg(vb-usb_dev, usb_sndctrlpipe(vb-usb_dev,
0), + 0xed, 0x40, 0x, 0x, gamsg,
+ sizeof(struct vprbrd_gpioa_msg), 100);
0xed? 0x40? 100?
Can you #define the magic constants, or are they already available
in some existing header file?
(The zeros are OK.)
No there are no constants in some existing file. I will introduce them.
+ if (ret != sizeof(struct vprbrd_gpioa_msg))
+ error = -EREMOTEIO;
+
+ ret = usb_control_msg(vb-usb_dev, usb_rcvctrlpipe(vb-usb_dev,
0), + 0xed, 0xc0, 0x, 0x, gamsg,
+ sizeof(struct vprbrd_gpioa_msg), 100);
Dito...
Same comment for *set, *direction_input, *direction_output,
*setdir,
(...)
+static int __devinit vprbrd_gpio_probe(struct platform_device *pdev)
+{
+ struct vprbrd *vb = dev_get_drvdata(pdev-dev.parent);
+ struct vprbrd_gpio *vb_gpio;
+ int ret;
+
+ vb_gpio = kzalloc(sizeof(*vb_gpio), GFP_KERNEL);
Can you use devm_kzalloc(pdev-dev, ...)?
Ofcourse. Thanks for the hint. I did not knew this function.
+ if (vb_gpio == NULL)
+ return -ENOMEM;
+
+ vb_gpio-vb = vb;
+ /* registering gpio a */
+ vb_gpio-gpioa.label = viperboard gpio a;
+ vb_gpio-gpioa.dev = pdev-dev;
+ vb_gpio-gpioa.owner = THIS_MODULE;
+ vb_gpio-gpioa.base = -1;
+ vb_gpio-gpioa.ngpio = 16;
+ vb_gpio-gpioa.can_sleep = 1;
+ vb_gpio-gpioa.set = vprbrd_gpioa_set;
+ vb_gpio-gpioa.get = vprbrd_gpioa_get;
+ vb_gpio-gpioa.direction_input = vprbrd_gpioa_direction_input;
+ vb_gpio-gpioa.direction_output = vprbrd_gpioa_direction_output;
+ ret = gpiochip_add(vb_gpio-gpioa);
+ if (ret 0) {
+ dev_err(vb_gpio-gpioa.dev, could not add
Re: linux-next: manual merge of the cortex tree with Linus' tree
On Tue, Oct 16, 2012 at 01:20:52PM +1100, Stephen Rothwell wrote: Hi Uwe, Today's linux-next merge of the cortex tree got a conflict in arch/arm/kernel/process.c between commit 9e14f828ee4a (arm: split ret_from_fork, simplify kernel_thread() [based on patch by rmk]) from Linus' tree and commit 2f3e7d3436cb (Cortex-M3: Add support for exception handling) from the cortex tree. I have no idea how to fix this up, so I have just dropped this tree for today. I'll look into it and rebase accordingly. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v4 2/3] devfreq: Add suspend and resume apis
On Monday 08 of October 2012 10:48:24 MyungJoo Ham wrote: On 8 October 2012 03:31, Rafael J. Wysocki r...@sisk.pl wrote: On Thursday 04 of October 2012 14:58:33 Rajagopal Venkat wrote: Add devfreq suspend/resume apis for devfreq users. This patch supports suspend and resume of devfreq load monitoring, required for devices which can idle. Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org Acked-by: MyungJoo Ham myungjoo@samsung.com Well, I wonder if this may be tied in to the runtime PM framework, so that, for example, pm_runtime_suspend() will automatically suspend devfreq on success (and the runtime resume of the device will resume devfreq)? That's a good idea. If you agree, we can handle this as separate patch on top this patchset. Sure. I guess implementing the idea may be not so obvious; thus, seperating the patchset would be appropriate. When we implement the idea, we may need to implement at the pm_runtime core. Because devfreq-dev is a child of the target dev, not a parent, runtime-pm event of the target dev does not automatically invoke a cascaded action on the devfreq-dev. I'm not exactly sure what you mean, care to explain? When a device p creates devfreq, devfreq-dev-parent = p. And, devfreq's functions need to react to the p's runtime-pm events. However, when p's runtime-pm-suspend is being invoked, devfreq-dev's runtime-pm-suspend won't be automatically invoked. Thus, we will need a mechanism that invokes devfreq-dev's runtime-pm callbacks when p's runtime-pm is invoked. (at the runtime-pm core) Or A mechanism that one can notify others (including its children) when the one's runtime-pm is invoked. (probably at the runtime-pm core, too) Without such support, it appears that the current implementation (calling runtime-pm suspend/resume equivalent devfreq functions manually at device drivers) seems to be inevitable. Anyway, if devfreq-dev is a parent of p, runtime-pm core will do the required task automatically; however, it isn't and I don't think it'd be appropriate. Maybe either 1) capability to allow a child to monitor the power state of a parent (I remember Inki Dae once suggested to add notifiers at runtime-pm, but it seems to be not merged) or 2) letting runtime-pm be aware of devfreq (doesn't feel alright with this??) is required? I'm not a big fan of notifiers, so I'd prefer to avoid using them, if possible. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. Cheers, MyungJoo
Re: Initial report on F2FS filesystem performance
Hello. Would you share the result about random read ? Thanks. 2012/10/16, Sooman Jeong 77sm...@hanyang.ac.kr: This is a brief summary of our initial filesystem performance study of f2fs against existing two filesystems in linux: EXT4, NILFS2, and f2fs. * test platform i) Desktop PC : Linux 3.6.1 (f2fs patched), Intel i5-2500 @3.3GHz quad-core, 8GB RAM, Transcend 16GB class 10 micro SD card ii) Galaxy-S3 : Linux 3.0.15 (f2fs ported), Android 4.0.4, DVFS turned off, Transcend 16GB class 10 micro SD card * experiment 1: buffered write(sequential and random, 4KByte write) === F2FS surpasses other two filesystems in both random and sequential. In desktop and Galaxy S3, f2fs exhibits 2.5 and 1.6 times better performance in random write against EXT4, respectively. EXT4 is standard Android filesystem. buffered write (1GB file) +---+-+--+ | | Desktop PC|Galaxy-S3 | | +-+---+--+---+ | |sequential (MB/s)| random (IOPS) |sequential (MB/s) | random (IOPS) | +---+-+---+--+---+ | EXT4 |7.1 | 1073 |6.7 | 1073 | +---+-+---+--+---+ | NILFS2|6.8 | 1462 |4.0 | 1272 | +---+-+---+--+---+ | F2FS | 10.6 | 2675 |6.9 | 1682 | +---+-+---+--+---+ * experiment 2: write + fsync(sequential and random) F2FS surpasses other two filesystems in both random and sequential workload. In desktop and Galaxy S3, f2fs exhibits 2 and 1.5 times better performance in write+fsync random write against EXT4, respectively. write + fsync (100MB file) +---+-+--+ | | Desktop PC|Galaxy-S3 | | +-+---+--+---+ | |sequential (KB/s)| random (IOPS) |sequential (KB/s) | random (IOPS) | +---+-+---+--+---+ | EXT4 | 511.8 | 125 | 383.4 | 119 | +---+-+---+--+---+ | NILFS2| 545.2 | 112 | 356.7 | 72 | +---+-+---+--+---+ | F2FS | 1057.9 | 240 | 772.3 | 184 | +---+-+---+--+---+ write() with fsync is to test the filesystem performance under Android SQLite operation. * experiment 3: mounting time === To measure the mount time, we used two different scenarios. First, we mounted file system after formatting without rebooting system. Second, we mounted file system after rebooting in order to ensure any data cached in memory is flushed. Overall, EXT4 shows fastest mount time, and F2FS shows second best performance; however, we observed that F2FS takes longest time to mount right after formatting. mounting time with Transcend 16GB micro-SD +---+---+---+ | | Desktop PC |Galaxy-S3 | | +-+-+-+-+ | |1st mount after | after rebooting |1st mount after | after rebooting | | |format (msec)| (msec) |format (msec)| (msec) | +---+-+-+-+-+ | EXT4 | 11 | 20 | 20 | 40 | +---+-+-+-+-+ | NILFS2|920 | 1013 | 1680 | 1630 | +---+-+-+-+-+ | F2FS | 1486 |161 | 2280 | 1570 | +---+-+-+-+-+ Sooman Jeong ESOS Lab. Hanyang University. 77sm...@hanyang.ac.kr -- 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] oom, memcg: handle sysctl oom_kill_allocating_task while memcg oom happening
On Tue 16-10-12 14:32:05, Sha Zhengju wrote: [...] Thanks for reminding! Yes, I cooked it on memcg-devel git repo but a out-of-date since-3.2 branch... But I notice the latest branch is since-3.5(not seeing 3.6/3.7), does it okay to working on this branch? The tree has moved to http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary. Please use that tree. -- Michal Hocko 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/
Re: [RFC PATCH 1/3] mm: teach mm by current context info to not do I/O during memory allocation
On Tue, Oct 16, 2012 at 1:49 PM, Minchan Kim minc...@kernel.org wrote: Fair enough but it wouldn't be a good idea that add new unlikely branch in allocator's fast path. Please move the check into slow path which could be in __alloc_pages_slowpath. Thanks for your comment. I have considered to add the branch into gfp_to_alloc_flags() before, but didn't do it because I see that get_page_from_freelist() may use the GFP_IO or GFP_FS flag at least in zone_reclaim() path. So could you make sure it is safe to move the branch into __alloc_pages_slowpath()? If so, I will add the check into gfp_to_alloc_flags(). Thanks, -- Ming Lei -- 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: Fix memory leak in binder--version2
On Mon, Oct 15, 2012 at 05:39:22PM -0700, Arve Hjønnevåg wrote: On Mon, Oct 15, 2012 at 4:58 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Oct 15, 2012 at 04:55:21PM -0700, Arve Hjønnevåg wrote: On Mon, Oct 15, 2012 at 3:52 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Oct 15, 2012 at 07:20:01AM +, Tu, Xiaobing wrote: After enabling kmemleak and run monkey, following memleak is reported: unreferenced object 0xeed27f80 (size 64): comm Binder_8, pid 641, jiffies 4294946341 (age 2275.810s) hex dump (first 32 bytes): 4f dd 00 00 84 7f d2 ee 84 7f d2 ee 01 00 00 00 O... 00 00 00 00 00 00 00 00 00 aa 4c d7 00 00 00 00 ..L. backtrace: [c184fabc] kmemleak_alloc+0x3c/0xa0 [c12f391e] kmem_cache_alloc_trace+0x9e/0x180 [c1668bb5] binder_thread_write+0xcf5/0x23a0 [c166b091] binder_ioctl+0x1f1/0x530 [c130dcf6] do_vfs_ioctl+0x86/0x5e0 [c130e282] sys_ioctl+0x32/0x60 [c1872e01] syscall_call+0x7/0xb [] 0x The work item in async_todo list is not freed when binder released. Also the async transaction should also be freed in binder_release_work. Signed-off-by: Leon Ma xindong...@intel.com Signed-off-by: Di Zhang di.zh...@intel.com --- drivers/staging/android/binder.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) Nice fix, but next time can you at least use scripts/get_maintainer.pl to figure out who to send this to? I'll queue it up soon, but it took akpm to point me at this for me to notice it. This patch was just pointer out to me as well. I have a similar fix queued up at https://android-review.googlesource.com/#/c/43801/ that is still being tested. It fixes this leak and a theoretical leak of death notification objects. Ok, should I hold off applying this patch and wait for your patch instead? I just sent two patches, but they are not fully tested yet. Ok, care to test them and after that, resend them with the changes I noted in the changelog section of the patch? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Staging: android: binder: Fix memory leak on thread/process exit
On Mon, Oct 15, 2012 at 05:32:41PM -0700, Arve Hjønnevåg wrote: If a thread or process exited while a reply, one-way transaction or death notification was pending, the struct holding the pending work was leaked. Change-Id: I2eaafaba1c0ecda3ec0872d449dc16d0721c21e7 What is this field? Please don't include this in kernel patches, it forces me to edit the patch by hand :( Also, this should go to older kernels, right? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] iio: adc: add viperboard adc driver
On Monday 15 October 2012 at 16:26:36, Lars-Peter Clausen wrote:
Added linux-...@vger.kernel.org to Cc.
On 10/12/2012 04:34 PM, Lars Poeschel wrote:
From: Lars Poeschel poesc...@lemonage.de
This adds the mfd cell to use the adc part of the Nano River Technologies
viperboard.
Signed-off-by: Lars Poeschel poesc...@lemonage.de
Looks good in general, just some minor code style issues.
---
drivers/iio/adc/Kconfig |7 ++
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/viperboard_adc.c | 185
++ drivers/mfd/viperboard.c
|3 +
4 files changed, 196 insertions(+)
create mode 100644 drivers/iio/adc/viperboard_adc.c
[...]
diff --git a/drivers/iio/adc/viperboard_adc.c
b/drivers/iio/adc/viperboard_adc.c new file mode 100644
index 000..8ae6634
--- /dev/null
+++ b/drivers/iio/adc/viperboard_adc.c
@@ -0,0 +1,185 @@
+/*
+ * Nano River Technologies viperboard iio ADC driver
+ *
+ * (C) 2012 by Lemonage GmbH
+ * Author: Lars Poeschel poesc...@lemonage.de
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
modify it + * under the terms of the GNU General Public License as
published by the + * Free Software Foundation; either version 2 of
the License, or (at your + * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/mutex.h
+#include linux/platform_device.h
+
+#include linux/usb.h
+#include linux/iio/iio.h
+
+#include linux/mfd/viperboard.h
+
+#define VPRBRD_ADC_CMD_GET 0x00
+
+struct __packed vprbrd_adc_msg {
+ u8 cmd;
+ u8 chan;
+ u8 val;
+};
put the __packed between } and ;
GCC allows both alternatives, but you are right: Most kernel code is doing it
between } and ; so I will change this.
+
+struct vprbrd_adc {
+ struct vprbrd *vb;
+};
+
+#define VPRBRD_ADC_CHANNEL(_index) { \
+ .type = IIO_VOLTAGE,\
+ .indexed = 1, \
+ .channel = _index, \
+ .info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT,\
It would be good if you could also report the channel scale.
I saw that there is the possibility to supply a channel scale, which is way
cool. :-) The doc of the viperboard says nothing about the scale of the ADC.
At the moment I do not have the right measuring equipment here to measure a
scale myself. I would do another tiny patch if I have the oppotunity to
measure somewhere.
+ .scan_index = _index, \
+ .scan_type.sign = 'u', \
+ .scan_type.realbits = 8,\
+ .scan_type.storagebits = 8, \
Usually this is written as
.scan_type = {
.sign = 'u',
},
+}
+
+static struct iio_chan_spec vprbrd_adc_iio_channels[] = {
const
+ VPRBRD_ADC_CHANNEL(0),
+ VPRBRD_ADC_CHANNEL(1),
+ VPRBRD_ADC_CHANNEL(2),
+ VPRBRD_ADC_CHANNEL(3),
+};
+
+static int vprbrd_iio_read_raw(struct iio_dev *iio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long mask)
'mask' used to be a mask and that's why it is still called 'mask' in older
drivers. For new drivers we should use 'info'.
+{
+ int ret, error = 0;
+ struct vprbrd_adc *adc = iio_priv(iio_dev);
+ struct vprbrd *vb = adc-vb;
+ struct vprbrd_adc_msg *admsg = (struct vprbrd_adc_msg *)vb-buf;
+
+ if (mask == IIO_CHAN_INFO_RAW) {
+
Use switch instead of if. Otherwise you'd end up with if(mask == ...) else
if(mask == ...) else if (mask == ...) if you add support for more channel
attributes.
+ mutex_lock(vb-lock);
+
+ admsg-cmd = VPRBRD_ADC_CMD_GET;
+ admsg-chan = chan-scan_index;
+ admsg-val = 0x00;
+
+ ret = usb_control_msg(vb-usb_dev,
+ usb_sndctrlpipe(vb-usb_dev, 0), 0xec, 0x40,
+ 0x, 0x, admsg,
+ sizeof(struct vprbrd_adc_msg), 100);
+ if (ret != sizeof(struct vprbrd_adc_msg)) {
+ dev_err(iio_dev-dev, usb send error on adc read\n);
+ error = -EREMOTEIO;
+ }
Does it make sense to send out the second msg if the first one failed?
This is a good question. I can not fully answer it, because I did not build
the hardware. I thought it is better to try send the second message, because
there is some chance it reaches the device. I would opt for trying it.
+
+ ret = usb_control_msg(vb-usb_dev,
+
Re: [PATCH 2/2] Staging: android: binder: Allow using highmem for binder buffers
On Mon, Oct 15, 2012 at 05:32:42PM -0700, Arve Hjønnevåg wrote: Change-Id: I19be5fd89c194abcb8b041e2dd6c4d71ae7b1cc2 Again with the change-id field :( And please provide some information here, _why_ do we want to allow highmem for binder buffers? What does this solve? Is it a bug or just a feature enhancement? Depending on what it is depends on what release it should go into. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: csr: fix coding style
Hi,
On 10/15/2012 10:55 AM, SeongJae Park wrote:
Fix coding style of csr_framework_ext_types.h
Signed-off-by: SeongJae Park sj38.p...@gmail.com
---
drivers/staging/csr/csr_framework_ext_types.h | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/csr/csr_framework_ext_types.h
b/drivers/staging/csr/csr_framework_ext_types.h
index 57194ee..7e9cf8e 100644
--- a/drivers/staging/csr/csr_framework_ext_types.h
+++ b/drivers/staging/csr/csr_framework_ext_types.h
@@ -2,11 +2,11 @@
...
@@ -24,17 +24,15 @@ extern C {
#ifdef __KERNEL__
-struct CsrThread
-{
-struct task_struct *thread_task;
-charname[16];
+struct CsrThreadi {
I think this extra i letter at the end of CsrThreadi string is typo. Did
you try to compile the driver with your changes?
Best regards,
Lauri Hintsala
+ struct task_struct *thread_task;
+ charname[16];
...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] mfd: add viperboard driver
On Monday 15 October 2012 at 19:09:53, Peter Meerwald wrote:
minor nitpicking below
From: Lars Poeschel poesc...@lemonage.de
Add mfd driver for Nano River Technologies viperboard.
Signed-off-by: Lars Poeschel poesc...@lemonage.de
---
drivers/mfd/Kconfig| 14
drivers/mfd/Makefile |1 +
drivers/mfd/viperboard.c | 149
include/linux/mfd/viperboard.h
| 99 ++ 4 files changed, 263 insertions(+)
create mode 100644 drivers/mfd/viperboard.c
create mode 100644 include/linux/mfd/viperboard.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..98d9fa3 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1003,6 +1003,20 @@ config MFD_PALMAS
If you say yes here you get support for the Palmas
series of PMIC chips from Texas Instruments.
+config MFD_VIPERBOARD
+tristate Support for Nano River Technologies Viperboard
probably wrong indentation (space vs. tab)?
+ select MFD_CORE
+ depends on USB IIO
+default n
+help
+ Say yes here if you want support for Nano River Technologies
+ Viperboard.
+ There are mfd cell drivers available for i2c master, adc and
+ both gpios found on the board. The spi part does not yet
+ have a driver.
+ You need to select the mfd cell drivers seperatly.
separately
+ The drivers do not support all features the board exposes.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..6ab6b64 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -128,6 +128,7 @@ obj-$(CONFIG_MFD_TPS65090) += tps65090.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
obj-$(CONFIG_MFD_PALMAS) += palmas.o
+obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
new file mode 100644
index 000..8095ea2
--- /dev/null
+++ b/drivers/mfd/viperboard.c
@@ -0,0 +1,149 @@
+/*
+ * Nano River Technologies viperboard driver
+ *
+ * This is the core driver for the viperboard. There are cell drivers
+ * available for I2C, ADC and both GPIOs. SPI is not yet supported
full stop (.) missing
+ * The drivers do not support all features the board exposes. See user
+ * manual of the viperboard.
+ *
+ * (C) 2012 by Lemonage GmbH
+ * Author: Lars Poeschel poesc...@lemonage.de
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
modify it + * under the terms of the GNU General Public License as
published by the + * Free Software Foundation; either version 2 of the
License, or (at your + * option) any later version.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/mutex.h
+
+#include linux/mfd/core.h
+#include linux/mfd/viperboard.h
+
+#include linux/usb.h
+
+
+static const struct usb_device_id vprbrd_table[] = {
+ { USB_DEVICE(0x2058, 0x1005) }, /* Nano River Technologies */
+ { } /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, vprbrd_table);
+
+static void vprbrd_dev_release(struct device *dev)
+{
+ return;
return not needed
+}
+
+static void vprbrd_free(struct vprbrd *dev)
+{
+ usb_put_dev(dev-usb_dev);
+ kfree(dev);
+}
Thanks for your review. I will change this and after waiting some time for
additional comments, I will do a version 3 of the whole patchset.
Regards,
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] avr32: fix build error in atstk1006_defconfig
fixed the following compile error when use avr32 atstk1006_defconfig: drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location': drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function 'writel_relaxed' which was introduced by commit 1c7b874d33b463 (mtd: at91: atmel_nand: add Programmable Multibit ECC controller support). The PMECC for nand flash code uses writel_relaxed(). But in avr32, there is no macro writel_relaxed defined. This patch add writex_relaxed macro definitions. Signed-off-by: Josh Wu josh...@atmel.com --- arch/avr32/include/asm/io.h |4 1 file changed, 4 insertions(+) diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h index cf60d0a..fc6483f 100644 --- a/arch/avr32/include/asm/io.h +++ b/arch/avr32/include/asm/io.h @@ -165,6 +165,10 @@ BUILDIO_IOPORT(l, u32) #define readw_be __raw_readw #define readl_be __raw_readl +#define writeb_relaxed writeb +#define writew_relaxed writew +#define writel_relaxed writel + #define writeb_be __raw_writeb #define writew_be __raw_writew #define writel_be __raw_writel -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memory cgroup: update root memory cgroup when node is onlined
(2012/09/14 10:36), Hugh Dickins wrote:
On Thu, 13 Sep 2012, Johannes Weiner wrote:
On Thu, Sep 13, 2012 at 03:14:28PM +0800, Wen Congyang wrote:
root_mem_cgroup-info.nodeinfo is initialized when the system boots.
But NODE_DATA(nid) is null if the node is not onlined, so
root_mem_cgroup-info.nodeinfo[nid]-zoneinfo[zone].lruvec.zone contains
an invalid pointer. If we use numactl to bind a program to the node
after onlining the node and its memory, it will cause the kernel
panicked:
Is there any chance we could get rid of the zone backpointer in lruvec
again instead?
It could be done, but it would make me sad :(
Adding new nodes is a rare event and so updating every
single memcg in the system might be just borderline crazy.
Not horribly crazy, but rather ugly, yes.
But can't
we just go back to passing the zone along with the lruvec down
vmscan.c paths? I agree it's ugly to pass both, given their
relationship. But I don't think the backpointer is any cleaner but in
addition less robust.
It's like how we use vma-mm: we could change everywhere to pass mm with
vma, but it looks cleaner and cuts down on long arglists to have mm in vma.
From past experience, one of the things I worried about was adding extra
args to the reclaim stack.
That being said, the crashing code in particular makes me wonder:
static __always_inline void add_page_to_lru_list(struct page *page,
struct lruvec *lruvec, enum lru_list lru)
{
int nr_pages = hpage_nr_pages(page);
mem_cgroup_update_lru_size(lruvec, lru, nr_pages);
list_add(page-lru, lruvec-lists[lru]);
__mod_zone_page_state(lruvec_zone(lruvec), NR_LRU_BASE + lru, nr_pages);
}
Why did we ever pass zone in here and then felt the need to replace it
with lruvec-zone in fa9add6 mm/memcg: apply add/del_page to lruvec?
A page does not roam between zones, its zone is a static property that
can be retrieved with page_zone().
Just as in vmscan.c, we have the lruvec to hand, and that's what we
mainly want to operate upon, but there is also some need for zone.
(Both Konstantin and I were looking towards the day when we move the
lru_lock into the lruvec, removing more dependence on zone. Pretty
much the only reason that hasn't happened yet, is that we have not found
time to make a performance case convincingly - but that's another topic.)
Yes, page_zone(page) is a static property of the page, but it's not
necessarily cheap to evaluate: depends on how complex the memory model
and the spare page flags space, doesn't it? We both preferred to
derive zone from lruvec where convenient.
How do you feel about this patch, and does it work for you guys?
You'd be right if you guessed that I started out without the
mem_cgroup_zone_lruvec part of it, but oops in get_scan_count
told me that's needed too.
Description to be filled in later: would it be needed for -stable,
or is onlining already broken in other ways that you're now fixing up?
Reported-by: Tang Chen tangc...@cn.fujitsu.com
Signed-off-by: Hugh Dickins hu...@google.com
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.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 v2] ACPI: move acpi_no_s4_hw_signature() declaration into #ifdef CONFIG_HIBERNATION
On Tue, Oct 16, 2012 at 02:24:53PM +0800, Fengguang Wu wrote: On Tue, Oct 16, 2012 at 01:24:12PM +0800, Yuanhan Liu wrote: acpi_no_s4_hw_signature is defined in #ifdef CONFIG_HIBERNATION block, but the current code put the declaration in #ifdef CONFIG_PM_SLEEP block. I happened to meet this issue when I turned off PM_SLEEP config manually: arch/x86/kernel/acpi/sleep.c:100:4: error: implicit declaration of function ‘acpi_no_s4_hw_signature’ [-Werror=implicit-function-declaration] This should be more clear: Fix build error on !CONFIG_PM_SLEEP: Actually, there are more erros besides the followling one on !CONFIG_PM_SLEEP. This patch just fix one obvious one: the logical is wrong. Thanks, Yuanhan Liu arch/x86/kernel/acpi/sleep.c:100:4: error: implicit declaration of function ‘acpi_no_s4_hw_signature’ The root cause is, acpi_no_s4_hw_signature() is defined in #ifdef CONFIG_HIBERNATION block, but the current code put the declaration in #ifdef CONFIG_PM_SLEEP block. Thanks, Fengguang v2: take better title and add build error message suggested by Fengguang Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com Reviewed-by: Fengguang Wu fengguang...@intel.com --- include/linux/acpi.h |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 90be989..a468429 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -257,8 +257,11 @@ int acpi_check_region(resource_size_t start, resource_size_t n, int acpi_resources_are_enforced(void); -#ifdef CONFIG_PM_SLEEP +#ifdef CONFIG_HIBERNATION void __init acpi_no_s4_hw_signature(void); +#endif + +#ifdef CONFIG_PM_SLEEP void __init acpi_old_suspend_ordering(void); void __init acpi_nvs_nosave(void); #endif /* CONFIG_PM_SLEEP */ -- 1.7.7.6 -- 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: [Q] Default SLAB allocator
On Tue, 2012-10-16 at 10:28 +0900, JoonSoo Kim wrote:
Hello, Eric.
2012/10/14 Eric Dumazet eric.duma...@gmail.com:
SLUB was really bad in the common workload you describe (allocations
done by one cpu, freeing done by other cpus), because all kfree() hit
the slow path and cpus contend in __slab_free() in the loop guarded by
cmpxchg_double_slab(). SLAB has a cache for this, while SLUB directly
hit the main struct page to add the freed object to freelist.
Could you elaborate more on how 'netperf RR' makes kernel allocations
done by one cpu, freeling done by other cpus, please?
I don't have enough background network subsystem, so I'm just curious.
Common network load is to have one cpu A handling device interrupts
doing the memory allocations to hold incoming frames,
and queueing skbs to various sockets.
These sockets are read by other cpus (if the cpu A is fully used to
service softirqs under high load), so the kfree() are done by other
cpus.
Each incoming frame uses one sk_buff, allocated from skbuff_head_cache
kmemcache (256 bytes on x86_64)
# ls -l /sys/kernel/slab/skbuff_head_cache
lrwxrwxrwx 1 root root 0 oct. 16
08:50 /sys/kernel/slab/skbuff_head_cache - :t-256
# cat /sys/kernel/slab/skbuff_head_cache/objs_per_slab
32
On a configuration with 24 cpus and one cpu servicing network, we may
have 23 cpus doing the frees roughly at the same time, all competing in
__slab_free() on the same page. This increases if we increase slub page
order (as recommended by SLUB hackers)
To reproduce this kind of workload without a real NIC, we probably need
some test module, using one thread doing allocations, and other threads
doing the free.
I played some months ago adding a percpu associative cache to SLUB, then
just moved on other strategy.
(Idea for this per cpu cache was to build a temporary free list of
objects to batch accesses to struct page)
Is this implemented and submitted?
If it is, could you tell me the link for the patches?
It was implemented in february and not submitted at that time.
The following rebase has probably some issues with slab debug, but seems
to work.
include/linux/slub_def.h | 22 ++
mm/slub.c| 127 +++--
2 files changed, 131 insertions(+), 18 deletions(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index df448ad..9e5b91c 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -41,8 +41,30 @@ enum stat_item {
CPU_PARTIAL_FREE, /* Refill cpu partial on free */
CPU_PARTIAL_NODE, /* Refill cpu partial from node partial */
CPU_PARTIAL_DRAIN, /* Drain cpu partial to node partial */
+ FREE_CACHED,/* free delayed in secondary freelist,
cumulative counter */
+ FREE_CACHED_ITEMS, /* items in victim cache */
NR_SLUB_STAT_ITEMS };
+/**
+ * struct slub_cache_desc - victim cache descriptor
+ * @page: slab page
+ * @objects_head: head of freed objects list
+ * @objects_tail: tail of freed objects list
+ * @count: number of objects in list
+ *
+ * freed objects in slow path are managed into an associative cache,
+ * to reduce contention on @page-freelist
+ */
+struct slub_cache_desc {
+ struct page *page;
+ void**objects_head;
+ void**objects_tail;
+ int count;
+};
+
+#define NR_SLUB_PCPU_CACHE_SHIFT 6
+#define NR_SLUB_PCPU_CACHE (1 NR_SLUB_PCPU_CACHE_SHIFT)
+
struct kmem_cache_cpu {
void **freelist;/* Pointer to next available object */
unsigned long tid; /* Globally unique transaction id */
diff --git a/mm/slub.c b/mm/slub.c
index a0d6984..30a6d72 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -31,6 +31,7 @@
#include linux/fault-inject.h
#include linux/stacktrace.h
#include linux/prefetch.h
+#include linux/hash.h
#include trace/events/kmem.h
@@ -221,6 +222,14 @@ static inline void stat(const struct kmem_cache *s, enum
stat_item si)
#endif
}
+static inline void stat_add(const struct kmem_cache *s, enum stat_item si,
+ int cnt)
+{
+#ifdef CONFIG_SLUB_STATS
+ __this_cpu_add(s-cpu_slab-stat[si], cnt);
+#endif
+}
+
/
* Core slab cache functions
***/
@@ -1993,6 +2002,8 @@ static inline void flush_slab(struct kmem_cache *s,
struct kmem_cache_cpu *c)
c-freelist = NULL;
}
+static void victim_cache_flush(struct kmem_cache *s, int cpu);
+
/*
* Flush cpu slab.
*
@@ -2006,6 +2017,7 @@ static inline void __flush_cpu_slab(struct kmem_cache *s,
int cpu)
if (c-page)
flush_slab(s, c);
+ victim_cache_flush(s, cpu);
unfreeze_partials(s);
}
}
@@ -2446,38 +2458,34 @@ EXPORT_SYMBOL(kmem_cache_alloc_node_trace);
#endif
[PATCH] backlight: da903x_bl: use dev_get_drvdata() instead of platform_get_drvdata()
dev_get_drvdata() can be used instead of platform_get_drvdata()
to make the code smaller.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Mike Rapoport m...@compulab.co.il
---
drivers/video/backlight/da903x_bl.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/da903x_bl.c
b/drivers/video/backlight/da903x_bl.c
index 573c7ec..6891754 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -164,15 +164,14 @@ static int da903x_backlight_remove(struct platform_device
*pdev)
#ifdef CONFIG_PM
static int da903x_backlight_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct backlight_device *bl = platform_get_drvdata(pdev);
+ struct backlight_device *bl = dev_get_drvdata(dev);
+
return da903x_backlight_set(bl, 0);
}
static int da903x_backlight_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct backlight_device *bl = platform_get_drvdata(pdev);
+ struct backlight_device *bl = dev_get_drvdata(dev);
backlight_update_status(bl);
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/17] backlight: 88pm860x_bl: fix checkpatch warning
This patch fixes the checkpatch warning as below: WARNING: quoted string split across lines Signed-off-by: Jingoo Han jg1@samsung.com Cc: Richard Purdie rpur...@rpsys.net --- drivers/video/backlight/88pm860x_bl.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/88pm860x_bl.c b/drivers/video/backlight/88pm860x_bl.c index b7ec34c..6e509d9 100644 --- a/drivers/video/backlight/88pm860x_bl.c +++ b/drivers/video/backlight/88pm860x_bl.c @@ -117,8 +117,8 @@ static int pm860x_backlight_set(struct backlight_device *bl, int brightness) data-current_brightness = value; return 0; out: - dev_dbg(chip-dev, set brightness %d failure with return - value:%d\n, value, ret); + dev_dbg(chip-dev, set brightness %d failure with return value: %d\n, + value, ret); return ret; } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/17] backlight: atmel-pwm-bl: fix checkpatch warning
This patch fixes the checkpatch warning as below: WARNING: quoted string split across lines Signed-off-by: Jingoo Han jg1@samsung.com Cc: Richard Purdie rpur...@rpsys.net --- drivers/video/backlight/atmel-pwm-bl.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c index df1cbb7..de5e5e7 100644 --- a/drivers/video/backlight/atmel-pwm-bl.c +++ b/drivers/video/backlight/atmel-pwm-bl.c @@ -106,10 +106,9 @@ static int atmel_pwm_bl_init_pwm(struct atmel_pwm_bl *pwmbl) pwm_channel_writel(pwmbl-pwmc, PWM_CPRD, pwmbl-pdata-pwm_compare_max); - dev_info(pwmbl-pdev-dev, Atmel PWM backlight driver - (%lu Hz)\n, pwmbl-pwmc.mck / - pwmbl-pdata-pwm_compare_max / - (1 prescale)); + dev_info(pwmbl-pdev-dev, Atmel PWM backlight driver (%lu Hz)\n, + pwmbl-pwmc.mck / pwmbl-pdata-pwm_compare_max / + (1 prescale)); return pwm_channel_enable(pwmbl-pwmc); } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] proc: check vma-vm_file before dereferencing
16.10.2012 01:40, Andrew Morton пишет: On Mon, 15 Oct 2012 19:30:03 +0400 Stanislav Kinsbursky skinsbur...@parallels.com wrote: It can be equal to NULL. Please write better changelogs, so people do not have to ask questions such as: - Under what conditions does this bug trigger? - In which kernel version(s)? - Is it a post-3.6 regression? Sure. Sorry. Thanks. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/17] backlight: corgi_lcd: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: please, no space before tabs
WARNING: quoted string split across lines
ERROR: space required before the open parenthesis '('
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/corgi_lcd.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/corgi_lcd.c
b/drivers/video/backlight/corgi_lcd.c
index c781768..7171815 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -6,8 +6,8 @@
* Based on Sharp's 2.4 Backlight Driver
*
* Copyright (c) 2008 Marvell International Ltd.
- * Converted to SPI device based LCD/Backlight device driver
- * by Eric Miao eric.m...@marvell.com
+ * Converted to SPI device based LCD/Backlight device driver
+ * by Eric Miao eric.m...@marvell.com
*
* 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
@@ -192,7 +192,7 @@ static void lcdtg_set_phadadj(struct corgi_lcd *lcd, int
mode)
{
int adj;
- switch(mode) {
+ switch (mode) {
case CORGI_LCD_MODE_VGA:
/* Setting for VGA */
adj = sharpsl_param.phadadj;
@@ -495,8 +495,9 @@ static int setup_gpio_backlight(struct corgi_lcd *lcd,
err = devm_gpio_request(spi-dev, pdata-gpio_backlight_on,
BL_ON);
if (err) {
- dev_err(spi-dev, failed to request GPIO%d for
- backlight_on\n, pdata-gpio_backlight_on);
+ dev_err(spi-dev,
+ failed to request GPIO%d for backlight_on\n,
+ pdata-gpio_backlight_on);
return err;
}
@@ -508,8 +509,9 @@ static int setup_gpio_backlight(struct corgi_lcd *lcd,
err = devm_gpio_request(spi-dev, pdata-gpio_backlight_cont,
BL_CONT);
if (err) {
- dev_err(spi-dev, failed to request GPIO%d for
- backlight_cont\n, pdata-gpio_backlight_cont);
+ dev_err(spi-dev,
+ failed to request GPIO%d for backlight_cont\n,
+ pdata-gpio_backlight_cont);
return err;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/17] backlight: da903x_bl: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
WARNING: quoted string split across lines
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/da903x_bl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/da903x_bl.c
b/drivers/video/backlight/da903x_bl.c
index 573c7ec..f02e95c 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -2,10 +2,10 @@
* Backlight driver for Dialog Semiconductor DA9030/DA9034
*
* Copyright (C) 2008 Compulab, Ltd.
- * Mike Rapoport m...@compulab.co.il
+ * Mike Rapoport m...@compulab.co.il
*
* Copyright (C) 2006-2008 Marvell International Ltd.
- * Eric Miao eric.m...@marvell.com
+ * Eric Miao eric.m...@marvell.com
*
* 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
@@ -199,7 +199,7 @@ static struct platform_driver da903x_backlight_driver = {
module_platform_driver(da903x_backlight_driver);
MODULE_DESCRIPTION(Backlight Driver for Dialog Semiconductor DA9030/DA9034);
-MODULE_AUTHOR(Eric Miao eric.m...@marvell.com
- Mike Rapoport m...@compulab.co.il);
+MODULE_AUTHOR(Eric Miao eric.m...@marvell.com);
+MODULE_AUTHOR(Mike Rapoport m...@compulab.co.il);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform:da903x-backlight);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/17] backlight: generic_bl: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: space prohibited between function name and open parenthesis '('
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/generic_bl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/generic_bl.c
b/drivers/video/backlight/generic_bl.c
index 8c660fc..0ae155b 100644
--- a/drivers/video/backlight/generic_bl.c
+++ b/drivers/video/backlight/generic_bl.c
@@ -97,8 +97,8 @@ static int genericbl_probe(struct platform_device *pdev)
props.max_brightness = machinfo-max_intensity;
bd = backlight_device_register(name, pdev-dev, NULL, genericbl_ops,
props);
- if (IS_ERR (bd))
- return PTR_ERR (bd);
+ if (IS_ERR(bd))
+ return PTR_ERR(bd);
platform_set_drvdata(pdev, bd);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/17] backlight: hp680_bl: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: please, no space before tabs
WARNING: please, no spaces at the start of a line
ERROR: do not initialise statics to 0 or NULL
ERROR: code indent should use tabs where possible
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/hp680_bl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/hp680_bl.c
b/drivers/video/backlight/hp680_bl.c
index 38aa002..191fbed 100644
--- a/drivers/video/backlight/hp680_bl.c
+++ b/drivers/video/backlight/hp680_bl.c
@@ -26,7 +26,7 @@
#define HP680_DEFAULT_INTENSITY 10
static int hp680bl_suspended;
-static int current_intensity = 0;
+static int current_intensity;
static DEFINE_SPINLOCK(bl_lock);
static void hp680bl_send_intensity(struct backlight_device *bd)
@@ -168,7 +168,7 @@ static int __init hp680bl_init(void)
static void __exit hp680bl_exit(void)
{
platform_device_unregister(hp680bl_device);
- platform_driver_unregister(hp680bl_driver);
+ platform_driver_unregister(hp680bl_driver);
}
module_init(hp680bl_init);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/17] backlight: ili9320: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: please, no space before tabs
WARNING: please, no spaces at the start of a line
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
WARNING: braces {} are not necessary for single statement blocks
ERROR: code indent should use tabs where possible
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/ili9320.c | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/ili9320.c
b/drivers/video/backlight/ili9320.c
index 9327cd1..a66cfd1 100644
--- a/drivers/video/backlight/ili9320.c
+++ b/drivers/video/backlight/ili9320.c
@@ -45,7 +45,7 @@ static inline int ili9320_write_spi(struct ili9320 *ili,
/* second message is the data to transfer */
data[0] = spi-id | ILI9320_SPI_DATA | ILI9320_SPI_WRITE;
- data[1] = value 8;
+ data[1] = value 8;
data[2] = value;
return spi_sync(spi-dev, spi-message);
@@ -56,7 +56,6 @@ int ili9320_write(struct ili9320 *ili, unsigned int reg,
unsigned int value)
dev_dbg(ili-dev, write: reg=%02x, val=%04x\n, reg, value);
return ili-write(ili, reg, value);
}
-
EXPORT_SYMBOL_GPL(ili9320_write);
int ili9320_write_regs(struct ili9320 *ili,
@@ -74,7 +73,6 @@ int ili9320_write_regs(struct ili9320 *ili,
return 0;
}
-
EXPORT_SYMBOL_GPL(ili9320_write_regs);
static void ili9320_reset(struct ili9320 *lcd)
@@ -260,7 +258,6 @@ int __devinit ili9320_probe_spi(struct spi_device *spi,
return ret;
}
-
EXPORT_SYMBOL_GPL(ili9320_probe_spi);
int ili9320_remove(struct ili9320 *ili)
@@ -271,7 +268,6 @@ int ili9320_remove(struct ili9320 *ili)
return 0;
}
-
EXPORT_SYMBOL_GPL(ili9320_remove);
#ifdef CONFIG_PM
@@ -296,20 +292,17 @@ int ili9320_suspend(struct ili9320 *lcd, pm_message_t
state)
return 0;
}
-
EXPORT_SYMBOL_GPL(ili9320_suspend);
int ili9320_resume(struct ili9320 *lcd)
{
dev_info(lcd-dev, resuming from power state %d\n, lcd-power);
- if (lcd-platdata-suspend == ILI9320_SUSPEND_DEEP) {
+ if (lcd-platdata-suspend == ILI9320_SUSPEND_DEEP)
ili9320_write(lcd, ILI9320_POWER1, 0x00);
- }
return ili9320_power(lcd, FB_BLANK_UNBLANK);
}
-
EXPORT_SYMBOL_GPL(ili9320_resume);
#endif
@@ -318,7 +311,6 @@ void ili9320_shutdown(struct ili9320 *lcd)
{
ili9320_power(lcd, FB_BLANK_POWERDOWN);
}
-
EXPORT_SYMBOL_GPL(ili9320_shutdown);
MODULE_AUTHOR(Ben Dooks ben-li...@fluff.org);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
On Tue, 16 Oct 2012, Mark Brown wrote: On Mon, Oct 15, 2012 at 02:16:59PM +0100, Lee Jones wrote: Here we provide the GPIO Regulator driver with Device Tree capability, so that when a platform is booting with DT instead of platform data we can still make full use of it. Not looked at the patch yet but patch 2 doesn't seem to have appeared? Has it arrived yet? Arnd responded to it, so it hit the list. Since Arnd's comments I've also fired v2 up - do you see it/them? -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/17] backlight: jornada720: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: line over 80 characters
ERROR: return is not a function, parentheses are not required
Also, long comments are fixed for the preferred style.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/jornada720_bl.c | 34 ++---
drivers/video/backlight/jornada720_lcd.c |3 +-
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/video/backlight/jornada720_bl.c
b/drivers/video/backlight/jornada720_bl.c
index 16f593b..c23801c 100644
--- a/drivers/video/backlight/jornada720_bl.c
+++ b/drivers/video/backlight/jornada720_bl.c
@@ -48,7 +48,7 @@ static int jornada_bl_get_brightness(struct backlight_device
*bd)
jornada_ssp_end();
- return (BL_MAX_BRIGHT - ret);
+ return BL_MAX_BRIGHT - ret;
}
static int jornada_bl_update_status(struct backlight_device *bd)
@@ -58,7 +58,8 @@ static int jornada_bl_update_status(struct backlight_device
*bd)
jornada_ssp_start();
/* If backlight is off then really turn it off */
- if ((bd-props.power != FB_BLANK_UNBLANK) || (bd-props.fb_blank !=
FB_BLANK_UNBLANK)) {
+ if ((bd-props.power != FB_BLANK_UNBLANK) ||
+ (bd-props.fb_blank != FB_BLANK_UNBLANK)) {
ret = jornada_ssp_byte(BRIGHTNESSOFF);
if (ret != TXDUMMY) {
pr_info(brightness off timeout\n);
@@ -77,18 +78,23 @@ static int jornada_bl_update_status(struct backlight_device
*bd)
goto out;
}
- /* at this point we expect that the mcu has accepted
- our command and is waiting for our new value
- please note that maximum brightness is 255,
- but due to physical layout it is equal to 0, so we simply
- invert the value (MAX VALUE - NEW VALUE). */
- if (jornada_ssp_byte(BL_MAX_BRIGHT - bd-props.brightness) !=
TXDUMMY) {
+ /*
+* at this point we expect that the mcu has accepted
+* our command and is waiting for our new value
+* please note that maximum brightness is 255,
+* but due to physical layout it is equal to 0, so we simply
+* invert the value (MAX VALUE - NEW VALUE).
+*/
+ if (jornada_ssp_byte(BL_MAX_BRIGHT - bd-props.brightness)
+ != TXDUMMY) {
pr_err(set brightness failed\n);
ret = -ETIMEDOUT;
}
- /* If infact we get an TXDUMMY as output we are happy and dont
- make any further comments about it */
+ /*
+* If infact we get an TXDUMMY as output we are happy and dont
+* make any further comments about it
+*/
out:
jornada_ssp_end();
@@ -121,9 +127,11 @@ static int jornada_bl_probe(struct platform_device *pdev)
bd-props.power = FB_BLANK_UNBLANK;
bd-props.brightness = BL_DEF_BRIGHT;
- /* note. make sure max brightness is set otherwise
- you will get seemingly non-related errors when
- trying to change brightness */
+ /*
+* note. make sure max brightness is set otherwise
+* you will get seemingly non-related errors when
+* trying to change brightness
+*/
jornada_bl_update_status(bd);
platform_set_drvdata(pdev, bd);
diff --git a/drivers/video/backlight/jornada720_lcd.c
b/drivers/video/backlight/jornada720_lcd.c
index 635b305..4b412cb 100644
--- a/drivers/video/backlight/jornada720_lcd.c
+++ b/drivers/video/backlight/jornada720_lcd.c
@@ -101,7 +101,8 @@ static int jornada_lcd_probe(struct platform_device *pdev)
struct lcd_device *lcd_device;
int ret;
- lcd_device = lcd_device_register(S1D_DEVICENAME, pdev-dev, NULL,
jornada_lcd_props);
+ lcd_device = lcd_device_register(S1D_DEVICENAME, pdev-dev, NULL,
+ jornada_lcd_props);
if (IS_ERR(lcd_device)) {
ret = PTR_ERR(lcd_device);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/17] backlight: l4f00242t03: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
Also, unnecessary line is removed.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/l4f00242t03.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/l4f00242t03.c
b/drivers/video/backlight/l4f00242t03.c
index 2d90c06..472c7dc 100644
--- a/drivers/video/backlight/l4f00242t03.c
+++ b/drivers/video/backlight/l4f00242t03.c
@@ -4,7 +4,7 @@
* Copyright 2007-2009 Freescale Semiconductor, Inc. All Rights Reserved.
*
* Copyright (c) 2009 Alberto Panizzo maramaopercheseimo...@gmail.com
- * Inspired by Marek Vasut work in l4f00242t03.c
+ * Inspired by Marek Vasut work in l4f00242t03.c
*
* 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
@@ -33,7 +33,6 @@ struct l4f00242t03_priv {
struct regulator *core_reg;
};
-
static void l4f00242t03_reset(unsigned int gpio)
{
pr_debug(l4f00242t03_reset.\n);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/17] backlight: lm3630: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: static const char * array should probably be static const char * const
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/lm3630_bl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/lm3630_bl.c
b/drivers/video/backlight/lm3630_bl.c
index dc19144..a56f6a8 100644
--- a/drivers/video/backlight/lm3630_bl.c
+++ b/drivers/video/backlight/lm3630_bl.c
@@ -37,7 +37,7 @@ enum lm3630_leds {
BLED_2
};
-static const char *bled_name[] = {
+static const char * const bled_name[] = {
[BLED_ALL] = lm3630_bled, /*Bank1 controls all string */
[BLED_1] = lm3630_bled1, /*Bank1 controls bled1 */
[BLED_2] = lm3630_bled2, /*Bank1 or 2 controls bled2 */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/17] backlight: locomolcd: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: line over 80 characters
WARNING: space prohibited between function name and open parenthesis '('
ERROR: trailing statements should be on next line
Also, long comments are fixed for the preferred style and
unnecessary lines are removed.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/locomolcd.c | 65 +++
1 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/drivers/video/backlight/locomolcd.c
b/drivers/video/backlight/locomolcd.c
index 3a6d541..4cfa87b 100644
--- a/drivers/video/backlight/locomolcd.c
+++ b/drivers/video/backlight/locomolcd.c
@@ -33,19 +33,25 @@ static unsigned long locomolcd_flags;
static void locomolcd_on(int comadj)
{
- locomo_gpio_set_dir(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VSHA_ON,
0);
- locomo_gpio_write(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VSHA_ON,
1);
+ locomo_gpio_set_dir(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VSHA_ON, 0);
+ locomo_gpio_write(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VSHA_ON, 1);
mdelay(2);
- locomo_gpio_set_dir(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VSHD_ON,
0);
- locomo_gpio_write(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VSHD_ON,
1);
+ locomo_gpio_set_dir(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VSHD_ON, 0);
+ locomo_gpio_write(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VSHD_ON, 1);
mdelay(2);
locomo_m62332_senddata(locomolcd_dev, comadj, 0);
mdelay(5);
- locomo_gpio_set_dir(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VEE_ON,
0);
- locomo_gpio_write(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VEE_ON, 1);
+ locomo_gpio_set_dir(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VEE_ON, 0);
+ locomo_gpio_write(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VEE_ON, 1);
mdelay(10);
/* TFTCRST | CPSOUT=0 | CPSEN */
@@ -68,16 +74,19 @@ static void locomolcd_off(int comadj)
locomo_writel(0x06, locomolcd_dev-mapbase + LOCOMO_TC);
mdelay(1);
- locomo_gpio_write(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VSHA_ON,
0);
+ locomo_gpio_write(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VSHA_ON, 0);
mdelay(110);
- locomo_gpio_write(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VEE_ON, 0);
+ locomo_gpio_write(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VEE_ON, 0);
mdelay(700);
/* TFTCRST=0 | CPSOUT=0 | CPSEN = 0 */
locomo_writel(0, locomolcd_dev-mapbase + LOCOMO_TC);
locomo_gpio_write(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_MOD, 0);
- locomo_gpio_write(locomolcd_dev-dev.parent, LOCOMO_GPIO_LCD_VSHD_ON,
0);
+ locomo_gpio_write(locomolcd_dev-dev.parent,
+ LOCOMO_GPIO_LCD_VSHD_ON, 0);
}
void locomolcd_power(int on)
@@ -107,7 +116,6 @@ void locomolcd_power(int on)
}
EXPORT_SYMBOL(locomolcd_power);
-
static int current_intensity;
static int locomolcd_set_intensity(struct backlight_device *bd)
@@ -122,13 +130,25 @@ static int locomolcd_set_intensity(struct
backlight_device *bd)
intensity = 0;
switch (intensity) {
- /* AC and non-AC are handled differently, but produce same results in
sharp code? */
- case 0: locomo_frontlight_set(locomolcd_dev, 0, 0, 161); break;
- case 1: locomo_frontlight_set(locomolcd_dev, 117, 0, 161); break;
- case 2: locomo_frontlight_set(locomolcd_dev, 163, 0, 148); break;
- case 3: locomo_frontlight_set(locomolcd_dev, 194, 0, 161); break;
- case 4: locomo_frontlight_set(locomolcd_dev, 194, 1, 161); break;
-
+ /*
+* AC and non-AC are handled differently,
+* but produce same results in sharp code?
+*/
+ case 0:
+ locomo_frontlight_set(locomolcd_dev, 0, 0, 161);
+ break;
+ case 1:
+ locomo_frontlight_set(locomolcd_dev, 117, 0, 161);
+ break;
+ case 2:
+ locomo_frontlight_set(locomolcd_dev, 163, 0, 148);
+ break;
+ case 3:
+ locomo_frontlight_set(locomolcd_dev, 194, 0, 161);
+ break;
+ case 4:
+ locomo_frontlight_set(locomolcd_dev, 194, 1, 161);
+ break;
default:
return -ENODEV;
}
@@ -175,9 +195,11 @@ static int locomolcd_probe(struct locomo_dev *ldev)
locomo_gpio_set_dir(ldev-dev.parent, LOCOMO_GPIO_FL_VR, 0);
- /* the poodle_lcd_power function is called for the first time
+ /*
+* the poodle_lcd_power function is called for the first time
* from fs_initcall, which is before locomo is activated.
-* We
[PATCH 12/17] backlight: omap1: fix checkpatch warning
This patch fixes the checkpatch warning as below:
ERROR: inline keyword should sit between storage class and type
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/omap1_bl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/omap1_bl.c
b/drivers/video/backlight/omap1_bl.c
index 9a046a4..af31c26 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -42,12 +42,12 @@ struct omap_backlight {
struct omap_backlight_config *pdata;
};
-static void inline omapbl_send_intensity(int intensity)
+static inline void omapbl_send_intensity(int intensity)
{
omap_writeb(intensity, OMAP_PWL_ENABLE);
}
-static void inline omapbl_send_enable(int enable)
+static inline void omapbl_send_enable(int enable)
{
omap_writeb(enable, OMAP_PWL_CLK_ENABLE);
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/17] backlight: pcf50633: fix checkpatch warning
This patch fixes the checkpatch warning as below: WARNING: please, no spaces at the start of a line Also, long comments are fixed for the preferred style. Signed-off-by: Jingoo Han jg1@samsung.com Cc: Richard Purdie rpur...@rpsys.net --- drivers/video/backlight/pcf50633-backlight.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/video/backlight/pcf50633-backlight.c b/drivers/video/backlight/pcf50633-backlight.c index c092159..930fc2a 100644 --- a/drivers/video/backlight/pcf50633-backlight.c +++ b/drivers/video/backlight/pcf50633-backlight.c @@ -52,7 +52,7 @@ int pcf50633_bl_set_brightness_limit(struct pcf50633 *pcf, unsigned int limit) pcf_bl-brightness_limit = limit 0x3f; backlight_update_status(pcf_bl-bl); -return 0; + return 0; } static int pcf50633_bl_update_status(struct backlight_device *bl) @@ -136,8 +136,10 @@ static int __devinit pcf50633_bl_probe(struct platform_device *pdev) pcf50633_reg_write(pcf_bl-pcf, PCF50633_REG_LEDDIM, pdata-ramp_time); - /* Should be different from bl_props.brightness, so we do not exit -* update_status early the first time it's called */ + /* +* Should be different from bl_props.brightness, so we do not exit +* update_status early the first time it's called +*/ pcf_bl-brightness = pcf_bl-bl-props.brightness + 1; backlight_update_status(pcf_bl-bl); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/17] backlight: platform_lcd: fix checkpatch error
This patch fixes the checkpatch error as below:
ERROR: spaces prohibited around that ':' (ctx:WxW)
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/platform_lcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/platform_lcd.c
b/drivers/video/backlight/platform_lcd.c
index ca4f5d7..74cfca4 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -27,7 +27,7 @@ struct platform_lcd {
struct plat_lcd_data*pdata;
unsigned int power;
- unsigned int suspended : 1;
+ unsigned int suspended:1;
};
static inline struct platform_lcd *to_our_lcd(struct lcd_device *lcd)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/17] backlight: tdo24m: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/tdo24m.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index 02444d0..0f6eaa4 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -2,7 +2,7 @@
* tdo24m - SPI-based drivers for Toppoly TDO24M series LCD panels
*
* Copyright (C) 2008 Marvell International Ltd.
- * Eric Miao eric.m...@marvell.com
+ * Eric Miao eric.m...@marvell.com
*
* 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
@@ -90,7 +90,7 @@ static uint32_t lcd_qvga_pass_through_tdo24m[] = {
};
static uint32_t lcd_vga_transfer_tdo24m[] = {
- CMD1(0xcf, 0x02), /* Blanking period control (1) */
+ CMD1(0xcf, 0x02), /* Blanking period control (1) */
CMD2(0xd0, 0x08, 0x04), /* Blanking period control (2) */
CMD1(0xd1, 0x01), /* CKV timing control on/off */
CMD2(0xd2, 0x14, 0x00), /* CKV 1,2 timing control */
@@ -132,7 +132,7 @@ static uint32_t lcd_qvga_pass_through_tdo35s[] = {
};
static uint32_t lcd_vga_transfer_tdo35s[] = {
- CMD1(0xcf, 0x02), /* Blanking period control (1) */
+ CMD1(0xcf, 0x02), /* Blanking period control (1) */
CMD2(0xd0, 0x08, 0x04), /* Blanking period control (2) */
CMD1(0xd1, 0x01), /* CKV timing control on/off */
CMD2(0xd2, 0x00, 0x1e), /* CKV 1,2 timing control */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/17] backlight: tosa: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: line over 80 characters
ERROR: spaces required around that '?' (ctx:VxW)
ERROR: space required after that ',' (ctx:VxV)
Also, unnecessary lines are removed.
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/tosa_bl.c |4 ++--
drivers/video/backlight/tosa_lcd.c | 16 +---
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/video/backlight/tosa_bl.c
b/drivers/video/backlight/tosa_bl.c
index 49342e1..03c6ec2 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -90,7 +90,8 @@ static int __devinit tosa_bl_probe(struct i2c_client *client,
if (!data)
return -ENOMEM;
- data-comadj = sharpsl_param.comadj == -1 ? COMADJ_DEFAULT :
sharpsl_param.comadj;
+ data-comadj = sharpsl_param.comadj == -1 ?
+ COMADJ_DEFAULT : sharpsl_param.comadj;
ret = devm_gpio_request(client-dev, TOSA_GPIO_BL_C20MA, backlight);
if (ret) {
@@ -163,7 +164,6 @@ static const struct i2c_device_id tosa_bl_id[] = {
{ },
};
-
static struct i2c_driver tosa_bl_driver = {
.driver = {
.name = tosa-bl,
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index 33047a6..bcd97c5 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -63,7 +63,7 @@ static int tosa_tg_send(struct spi_device *spi, int adrs,
uint8_t data)
int tosa_bl_enable(struct spi_device *spi, int enable)
{
/* bl_enable GP04=1 otherwise GP04=0*/
- return tosa_tg_send(spi, TG_GPODR2, enable? 0x01 : 0x00);
+ return tosa_tg_send(spi, TG_GPODR2, enable ? 0x01 : 0x00);
}
EXPORT_SYMBOL(tosa_bl_enable);
@@ -91,15 +91,17 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
tosa_tg_send(spi, TG_PNLCTL, value);
/* TG LCD pannel power up */
- tosa_tg_send(spi, TG_PINICTL,0x4);
+ tosa_tg_send(spi, TG_PINICTL, 0x4);
mdelay(50);
/* TG LCD GVSS */
- tosa_tg_send(spi, TG_PINICTL,0x0);
+ tosa_tg_send(spi, TG_PINICTL, 0x0);
if (!data-i2c) {
- /* after the pannel is powered up the first time, we can access
the i2c bus */
- /* so probe for the DAC */
+ /*
+* after the pannel is powered up the first time,
+* we can access the i2c bus so probe for the DAC
+*/
struct i2c_adapter *adap = i2c_get_adapter(0);
struct i2c_board_info info = {
.type = tosa-bl,
@@ -115,11 +117,11 @@ static void tosa_lcd_tg_off(struct tosa_lcd_data *data)
struct spi_device *spi = data-spi;
/* TG LCD VHSA off */
- tosa_tg_send(spi, TG_PINICTL,0x4);
+ tosa_tg_send(spi, TG_PINICTL, 0x4);
mdelay(50);
/* TG LCD signal off */
- tosa_tg_send(spi, TG_PINICTL,0x6);
+ tosa_tg_send(spi, TG_PINICTL, 0x6);
mdelay(50);
/* TG Off */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/17] backlight: vgg2432a4: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
Signed-off-by: Jingoo Han jg1@samsung.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/video/backlight/vgg2432a4.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/vgg2432a4.c
b/drivers/video/backlight/vgg2432a4.c
index b617fae..b1ead3d 100644
--- a/drivers/video/backlight/vgg2432a4.c
+++ b/drivers/video/backlight/vgg2432a4.c
@@ -217,7 +217,7 @@ static int vgg2432a4_resume(struct spi_device *spi)
}
#else
#define vgg2432a4_suspend NULL
-#define vgg2432a4_resume NULL
+#define vgg2432a4_resume NULL
#endif
static struct ili9320_client vgg2432a4_client = {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Boottime: A tool for automatic measurement of kernel/bootloader boot time
root@ME:/ cat /sys/kernel/debug/boottime/bootgraph
[0.185254] calling splash+0x0/0x0
[2.984335] initcall splash+0x0/0x0 returned 0 after 2799 msecs.
[2.984335] calling autoboot_delay+0x0/0x0
[4.089513] initcall autoboot_delay+0x0/0x0 returned 0 after 1105
msecs.
[4.089513] calling load_kernel+0x0/0x0
[4.239174] initcall load_kernel+0x0/0x0 returned 0 after 149 msecs.
[4.239174] calling boot_kernel+0x0/0x0
[4.276260] initcall boot_kernel+0x0/0x0 returned 0 after 37 msecs.
[4.276260] calling uncompress_ll_init+0x0/0x0
[4.276260] initcall uncompress_ll_init+0x0/0x0 returned 0 after 0
msecs.
[4.276260] Freeing init memory: 0K
commit 4c49a18bcfd2d041cbad7f41c6e6b39d90008382 (HEAD,
refs/heads/dt-snowball-pre-rc1)
Author: Jonas Aabergjonas.ab...@stericsson.com
Date: Wed Sep 14 09:29:20 2011 +0200
drivers: clocksource: dbx500-prcmu: Add boottime support
Change-Id: I9b5e3d050131c08c08786ae84cb76619c0525049
Signed-off-by: Jonas Aabergjonas.ab...@stericsson.com
Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/32055
diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c
b/drivers/clocksource/clksrc-dbx500-prcmu.c
index c26c369..0069cd9 100644
--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
@@ -14,6 +14,7 @@
*/
#includelinux/clockchips.h
#includelinux/clksrc-dbx500-prcmu.h
+#includelinux/boottime.h
#includeasm/sched_clock.h
@@ -68,6 +69,23 @@ static u32 notrace dbx500_prcmu_sched_clock_read(void)
#endif
+#ifdef CONFIG_BOOTTIME
+static unsigned long __init boottime_get_time(void)
+{
+return div_s64(clocksource_cyc2ns(clocksource_dbx500_prcmu.read(
+clocksource_dbx500_prcmu),
+ clocksource_dbx500_prcmu.mult,
+ clocksource_dbx500_prcmu.shift),
+ 1000);
+}
+
+static struct boottime_timer __initdata boottime_timer = {
+.init = NULL,
+.get_time = boottime_get_time,
+.finalize = NULL,
+};
+#endif
+
void __init clksrc_dbx500_prcmu_init(void __iomem *base)
{
clksrc_dbx500_timer_base = base;
@@ -90,4 +108,6 @@ void __init clksrc_dbx500_prcmu_init(void __iomem *base)
32, RATE_32K);
#endif
clocksource_register_hz(clocksource_dbx500_prcmu, RATE_32K);
+
+boottime_activate(boottime_timer);
}
OK So has this been validated and tested on any other IC then a ST part?
This boottime_activate patch seems to be only for the dbx500. If
this is supposed to be a generic solution I would expect
a generic patch for ARM to enable boot time activation.
No, this is essentially an STE patch. We don't have access to any other
hardware, so we'd be reliant on kindhearted soles to test on their h/w.
I guess something like Beagleboard and/or Panda would be ideal. Know
anyone? ;)
Have you profiled how much time the boot time logging has added to
the over all boot?
Also the boottime commit message should explain a little more what
it is measuring.
i.e. This patch enables logging the boot time from point x to point
y for the kernel only. This does not include init.
What about adding the boot time from the init sequence to init complete?
I don't know the answers to these questions, but I'll endeavour to find
out and get back to you posthaste.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/3] USB: forbid memory allocation with I/O during bus reset if storage interface exits
On Tue, Oct 16, 2012 at 12:48 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: No, don't limit us for no good reason, that's not acceptable at all. Patching old kernels when new devices show up that work on those old kernels (like USB network devices that follow the spec with no driver change needed), is not a good idea. So I agree with Oliver here, this isn't acceptable. OK, I will remove the limit in -v1 and add comments on the case. thanks, -- Ming Lei -- 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 RESEND 0/8] TI Touchscreen driver updates and Support for TSC/ADC MFD driver
This patch set is a cumulative set of [1] and [2] sent earlier. I have merged the patch set so that the MFD patches apply without any issues. Also Note that there are no code changes in either of the patch set, only rebased on top of linux-next to make sure that all the patches apply without any conflicts. This patch set has been tested on AM335x EVM. [1] [PATCH 0/4] input: TSC: ti_tscadc: TI Touchscreen driver updates (http://www.spinics.net/lists/linux-input/msg22107.html) [2] [PATCH v5 0/4] Support for TSC/ADC MFD driver (http://www.spinics.net/lists/linux-input/msg22832.html) Patil, Rachna (8): input: TSC: ti_tscadc: Correct register usage input: TSC: ti_tscadc: Add Step configuration as platform data input: TSC: ti_tscadc: set FIFO0 threshold Interrupt input: TSC: ti_tscadc: Remove definition of End Of Interrupt register input: TSC: ti_tscadc: Rename the existing touchscreen driver MFD: ti_tscadc: Add support for TI's TSC/ADC MFDevice input: TSC: ti_tsc: Convert TSC into a MFDevice IIO : ADC: tiadc: Add support of TI's ADC driver drivers/iio/adc/Kconfig |7 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/ti_am335x_adc.c | 260 ++ drivers/input/touchscreen/Kconfig |6 +- drivers/input/touchscreen/Makefile |2 +- drivers/input/touchscreen/ti_am335x_tsc.c | 398 ++ drivers/input/touchscreen/ti_tscadc.c | 486 --- drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile|1 + drivers/mfd/ti_am335x_tscadc.c | 277 +++ include/linux/input/ti_am335x_tsc.h | 23 ++ include/linux/input/ti_tscadc.h | 17 - include/linux/mfd/ti_am335x_tscadc.h| 152 + include/linux/platform_data/ti_am335x_adc.h | 14 + 14 files changed, 1148 insertions(+), 507 deletions(-) create mode 100644 drivers/iio/adc/ti_am335x_adc.c create mode 100644 drivers/input/touchscreen/ti_am335x_tsc.c delete mode 100644 drivers/input/touchscreen/ti_tscadc.c create mode 100644 drivers/mfd/ti_am335x_tscadc.c create mode 100644 include/linux/input/ti_am335x_tsc.h delete mode 100644 include/linux/input/ti_tscadc.h create mode 100644 include/linux/mfd/ti_am335x_tscadc.h create mode 100644 include/linux/platform_data/ti_am335x_adc.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 3/8] input: TSC: ti_tscadc: set FIFO0 threshold Interrupt
Code currently uses FIFO1 threshold interrupt.
since this is a MFD, Dedicating FIFO0 to touchscreen
and making way for other devices to use FIFO1 as well.
The FIFO can be shared between 2 devices but since the
interrupt used is threshold interrupt on FIFO1, we would
end up having wrong interrupts. Hence changing the same.
Signed-off-by: Patil, Rachna rac...@ti.com
---
drivers/input/touchscreen/ti_tscadc.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/ti_tscadc.c
b/drivers/input/touchscreen/ti_tscadc.c
index c1bd8e5..2cc19b0 100644
--- a/drivers/input/touchscreen/ti_tscadc.c
+++ b/drivers/input/touchscreen/ti_tscadc.c
@@ -42,6 +42,7 @@
#define REG_STEPCONFIG(n) (0x64 + ((n - 1) * 8))
#define REG_STEPDELAY(n) (0x68 + ((n - 1) * 8))
#define REG_FIFO0CNT 0xE4
+#define REG_FIFO0THR 0xE8
#define REG_FIFO1THR 0xF4
#define REG_FIFO0 0x100
#define REG_FIFO1 0x200
@@ -55,6 +56,7 @@
#define STPENB_STEPENB STEPENB(0x7FFF)
/* IRQ enable */
+#define IRQENB_FIFO0THRES BIT(2)
#define IRQENB_FIFO1THRES BIT(5)
#define IRQENB_PENUP BIT(9)
@@ -277,7 +279,7 @@ static irqreturn_t tscadc_irq(int irq, void *dev)
unsigned int fsm;
status = tscadc_readl(ts_dev, REG_IRQSTATUS);
- if (status IRQENB_FIFO1THRES) {
+ if (status IRQENB_FIFO0THRES) {
tscadc_read_coordinates(ts_dev, x, y);
z1 = tscadc_readl(ts_dev, REG_FIFO0) 0xfff;
@@ -303,7 +305,7 @@ static irqreturn_t tscadc_irq(int irq, void *dev)
input_sync(input_dev);
}
}
- irqclr |= IRQENB_FIFO1THRES;
+ irqclr |= IRQENB_FIFO0THRES;
}
/*
@@ -446,9 +448,9 @@ static int __devinit tscadc_probe(struct platform_device
*pdev)
tscadc_writel(ts_dev, REG_CTRL, ctrl);
tscadc_idle_config(ts_dev);
- tscadc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO1THRES);
+ tscadc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
tscadc_step_config(ts_dev);
- tscadc_writel(ts_dev, REG_FIFO1THR, ts_dev-steps_to_configure);
+ tscadc_writel(ts_dev, REG_FIFO0THR, ts_dev-steps_to_configure);
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(ts_dev, REG_CTRL, ctrl);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 2/8] input: TSC: ti_tscadc: Add Step configuration as platform data
There are 16 programmable Step Configuration
registers which are used by the sequencer.
Program the Steps in order to configure a channel
input to be sampled. If the same step is applied
several times, the coordinate values read are more
accurate.
Hence we provide the user an option of how many steps
should be configured.
For ex: If this value is assigned as 4, This means that
4 steps are applied to read x co-ordinate and 4 steps to read
y co-ordinate. Furtheron the interrupt handler already
holds code to use delta filter and report the best value
out of these values to the input sub-system.
Signed-off-by: Patil, Rachna rac...@ti.com
---
drivers/input/touchscreen/ti_tscadc.c | 25 +
include/linux/input/ti_tscadc.h |6 ++
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/ti_tscadc.c
b/drivers/input/touchscreen/ti_tscadc.c
index d198cab..c1bd8e5 100644
--- a/drivers/input/touchscreen/ti_tscadc.c
+++ b/drivers/input/touchscreen/ti_tscadc.c
@@ -41,10 +41,6 @@
#define REG_CHARGEDELAY0x060
#define REG_STEPCONFIG(n) (0x64 + ((n - 1) * 8))
#define REG_STEPDELAY(n) (0x68 + ((n - 1) * 8))
-#define REG_STEPCONFIG13 0x0C4
-#define REG_STEPDELAY130x0C8
-#define REG_STEPCONFIG14 0x0CC
-#define REG_STEPDELAY140x0D0
#define REG_FIFO0CNT 0xE4
#define REG_FIFO1THR 0xF4
#define REG_FIFO0 0x100
@@ -134,6 +130,7 @@ struct tscadc {
unsigned intwires;
unsigned intx_plate_resistance;
boolpen_down;
+ int steps_to_configure;
};
static unsigned int tscadc_readl(struct tscadc *ts, unsigned int reg)
@@ -150,9 +147,10 @@ static void tscadc_writel(struct tscadc *tsc, unsigned int
reg,
static void tscadc_step_config(struct tscadc *ts_dev)
{
unsigned intconfig;
- int i;
+ int i, total_steps;
/* Configure the Step registers */
+ total_steps = 2 * ts_dev-steps_to_configure;
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | STEPCONFIG_XPP;
@@ -170,7 +168,7 @@ static void tscadc_step_config(struct tscadc *ts_dev)
break;
}
- for (i = 1; i 7; i++) {
+ for (i = 1; i = ts_dev-steps_to_configure; i++) {
tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -192,7 +190,7 @@ static void tscadc_step_config(struct tscadc *ts_dev)
break;
}
- for (i = 7; i 13; i++) {
+ for (i = (ts_dev-steps_to_configure + 1); i = total_steps; i++) {
tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -211,12 +209,14 @@ static void tscadc_step_config(struct tscadc *ts_dev)
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | STEPCONFIG_YPP |
STEPCONFIG_XNN | STEPCONFIG_INM_ADCREFM;
- tscadc_writel(ts_dev, REG_STEPCONFIG13, config);
- tscadc_writel(ts_dev, REG_STEPDELAY13, STEPCONFIG_OPENDLY);
+ tscadc_writel(ts_dev, REG_STEPCONFIG(total_steps + 1), config);
+ tscadc_writel(ts_dev, REG_STEPDELAY(total_steps + 1),
+ STEPCONFIG_OPENDLY);
config |= STEPCONFIG_INP_AN3 | STEPCONFIG_FIFO1;
- tscadc_writel(ts_dev, REG_STEPCONFIG14, config);
- tscadc_writel(ts_dev, REG_STEPDELAY14, STEPCONFIG_OPENDLY);
+ tscadc_writel(ts_dev, REG_STEPCONFIG(total_steps + 2), config);
+ tscadc_writel(ts_dev, REG_STEPDELAY(total_steps + 2),
+ STEPCONFIG_OPENDLY);
tscadc_writel(ts_dev, REG_SE, STPENB_STEPENB);
}
@@ -379,6 +379,7 @@ static int __devinit tscadc_probe(struct platform_device
*pdev)
ts_dev-irq = irq;
ts_dev-wires = pdata-wires;
ts_dev-x_plate_resistance = pdata-x_plate_resistance;
+ ts_dev-steps_to_configure = pdata-steps_to_configure;
res = request_mem_region(res-start, resource_size(res), pdev-name);
if (!res) {
@@ -447,7 +448,7 @@ static int __devinit tscadc_probe(struct platform_device
*pdev)
tscadc_idle_config(ts_dev);
tscadc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO1THRES);
tscadc_step_config(ts_dev);
- tscadc_writel(ts_dev, REG_FIFO1THR, 6);
+ tscadc_writel(ts_dev, REG_FIFO1THR, ts_dev-steps_to_configure);
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(ts_dev, REG_CTRL, ctrl);
diff --git a/include/linux/input/ti_tscadc.h b/include/linux/input/ti_tscadc.h
index b10a527..ad442a3 100644
--- a/include/linux/input/ti_tscadc.h
+++ b/include/linux/input/ti_tscadc.h
@@ -7,11 +7,17 @@
* i.e. 4/5/8 wire touchscreen support
* on the
[PATCH RESEND 1/8] input: TSC: ti_tscadc: Correct register usage
This patch cleans up the wrong register definitions and usage for touchscreen controller. Bit masks were not defined earlier. For ex: consider a register define as: write(xyz, ABC) ABC is expected to be written to register bits 0-11. Here we see that value written is as expected, but this write is also affecting all the remaining bits of xyz. The remaining bits hold the default value as 0 and the write also sets it to zero. Hence wrong usage were not causing user visible bugs. Due to these reasons it was difficult to follow when compared with TRM. Unused definitions are also removed. Since there is change in some naming convention because of all the above mentioned reasons, the same has been updated throughout the code. Bit declarations are grouped to increase readability. Signed-off-by: Patil, Rachna rac...@ti.com --- drivers/input/touchscreen/ti_tscadc.c | 128 + 1 files changed, 82 insertions(+), 46 deletions(-) diff --git a/drivers/input/touchscreen/ti_tscadc.c b/drivers/input/touchscreen/ti_tscadc.c index d229c74..d198cab 100644 --- a/drivers/input/touchscreen/ti_tscadc.c +++ b/drivers/input/touchscreen/ti_tscadc.c @@ -52,43 +52,79 @@ /* Register Bitfields */ #define IRQWKUP_ENBBIT(0) -#define STPENB_STEPENB 0x7FFF + +/* Step Enable */ +#define STEPENB_MASK (0x1 0) +#define STEPENB(val) (val 0) +#define STPENB_STEPENB STEPENB(0x7FFF) + +/* IRQ enable */ #define IRQENB_FIFO1THRES BIT(5) #define IRQENB_PENUP BIT(9) -#define STEPCONFIG_MODE_HWSYNC 0x2 -#define STEPCONFIG_SAMPLES_AVG (1 4) -#define STEPCONFIG_XPP (1 5) -#define STEPCONFIG_XNN (1 6) -#define STEPCONFIG_YPP (1 7) -#define STEPCONFIG_YNN (1 8) -#define STEPCONFIG_XNP (1 9) -#define STEPCONFIG_YPN (1 10) -#define STEPCONFIG_INM (1 18) -#define STEPCONFIG_INP (1 20) -#define STEPCONFIG_INP_5 (1 21) -#define STEPCONFIG_FIFO1 (1 26) -#define STEPCONFIG_OPENDLY 0xff -#define STEPCONFIG_Z1 (3 19) -#define STEPIDLE_INP (1 22) -#define STEPCHARGE_RFP (1 12) -#define STEPCHARGE_INM (1 15) -#define STEPCHARGE_INP (1 19) -#define STEPCHARGE_RFM (1 23) -#define STEPCHARGE_DELAY 0x1 -#define CNTRLREG_TSCSSENB (1 0) -#define CNTRLREG_STEPID(1 1) -#define CNTRLREG_STEPCONFIGWRT (1 2) -#define CNTRLREG_4WIRE (1 5) -#define CNTRLREG_5WIRE (1 6) -#define CNTRLREG_8WIRE (3 5) -#define CNTRLREG_TSCENB(1 7) -#define ADCFSM_STEPID 0x10 +/* Step Configuration */ +#define STEPCONFIG_MODE_MASK (3 0) +#define STEPCONFIG_MODE(val) (val 0) +#define STEPCONFIG_MODE_HWSYNC STEPCONFIG_MODE(2) +#define STEPCONFIG_AVG_MASK(7 2) +#define STEPCONFIG_AVG(val)(val 2) +#define STEPCONFIG_AVG_16 STEPCONFIG_AVG(4) +#define STEPCONFIG_XPP BIT(5) +#define STEPCONFIG_XNN BIT(6) +#define STEPCONFIG_YPP BIT(7) +#define STEPCONFIG_YNN BIT(8) +#define STEPCONFIG_XNP BIT(9) +#define STEPCONFIG_YPN BIT(10) +#define STEPCONFIG_INM_MASK(0xF 15) +#define STEPCONFIG_INM(val)(val 15) +#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8) +#define STEPCONFIG_INP_MASK(0xF 19) +#define STEPCONFIG_INP(val)(val 19) +#define STEPCONFIG_INP_AN2 STEPCONFIG_INP(2) +#define STEPCONFIG_INP_AN3 STEPCONFIG_INP(3) +#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4) +#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8) +#define STEPCONFIG_FIFO1 BIT(26) + +/* Delay register */ +#define STEPDELAY_OPEN_MASK(0x3 0) +#define STEPDELAY_OPEN(val)(val 0) +#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098) + +/* Charge Config */ +#define STEPCHARGE_RFP_MASK(7 12) +#define STEPCHARGE_RFP(val)(val 12) +#define STEPCHARGE_RFP_XPULSTEPCHARGE_RFP(1) +#define STEPCHARGE_INM_MASK(0xF 15) +#define STEPCHARGE_INM(val)(val 15) +#define STEPCHARGE_INM_AN1 STEPCHARGE_INM(1) +#define STEPCHARGE_INP_MASK(0xF 19) +#define STEPCHARGE_INP(val)(val 19) +#define STEPCHARGE_INP_AN1 STEPCHARGE_INP(1) +#define STEPCHARGE_RFM_MASK(3 23) +#define STEPCHARGE_RFM(val)(val 23) +#define STEPCHARGE_RFM_XNURSTEPCHARGE_RFM(1) + +/* Charge delay */ +#define CHARGEDLY_OPEN_MASK(0x3 0) +#define CHARGEDLY_OPEN(val)(val 0) +#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(1) + +/* Control register */ +#define CNTRLREG_TSCSSENB BIT(0) +#define CNTRLREG_STEPIDBIT(1) +#define CNTRLREG_STEPCONFIGWRT BIT(2) +#define CNTRLREG_AFE_CTRL_MASK (3 5) +#define CNTRLREG_AFE_CTRL(val) (val 5) +#define CNTRLREG_4WIRE CNTRLREG_AFE_CTRL(1) +#define CNTRLREG_5WIRE CNTRLREG_AFE_CTRL(2) +#define CNTRLREG_8WIRE CNTRLREG_AFE_CTRL(3) +#define CNTRLREG_TSCENBBIT(7) + +#define ADCFSM_STEPID
[PATCH RESEND 8/8] IIO : ADC: tiadc: Add support of TI's ADC driver
This patch adds support for TI's ADC driver.
This is a multifunctional device.
Analog input lines are provided on which
voltage measurements can be carried out.
You can have upto 8 input lines.
Signed-off-by: Patil, Rachna rac...@ti.com
Acked-by: Jonathan Cameron ji...@kernel.org
---
Changes in v2:
Addressed review comments from Matthias Kaehlcke
Changes in v3:
Addressed review comments from Jonathan Cameron.
Added comments, new line appropriately.
Changes in v4:
Removed extra comments and variables.
rename idev to indio_dev throughout the driver.
Renamed structs for better readability.
Changes in v5:
No changes
drivers/iio/adc/Kconfig |7 +
drivers/iio/adc/Makefile|1 +
drivers/iio/adc/ti_am335x_adc.c | 260 +++
drivers/mfd/ti_am335x_tscadc.c | 18 ++-
include/linux/mfd/ti_am335x_tscadc.h|9 +-
include/linux/platform_data/ti_am335x_adc.h | 14 ++
6 files changed, 307 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/adc/ti_am335x_adc.c
create mode 100644 include/linux/platform_data/ti_am335x_adc.h
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 4927581..1401ed1 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -60,4 +60,11 @@ config LP8788_ADC
help
Say yes here to build support for TI LP8788 ADC.
+config TI_AM335X_ADC
+ tristate TI's ADC driver
+ depends on MFD_TI_AM335X_TSCADC
+ help
+ Say yes here to build support for Texas Instruments ADC
+ driver which is also a MFD client.
+
endmenu
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 900995d..4410a90 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_AD7476) += ad7476.o
obj-$(CONFIG_AD7791) += ad7791.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
+obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
new file mode 100644
index 000..02a43c8
--- /dev/null
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -0,0 +1,260 @@
+/*
+ * TI ADC MFD driver
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/err.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/iio/iio.h
+
+#include linux/mfd/ti_am335x_tscadc.h
+#include linux/platform_data/ti_am335x_adc.h
+
+struct tiadc_device {
+ struct ti_tscadc_dev *mfd_tscadc;
+ int channels;
+};
+
+static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
+{
+ return readl(adc-mfd_tscadc-tscadc_base + reg);
+}
+
+static void tiadc_writel(struct tiadc_device *adc, unsigned int reg,
+ unsigned int val)
+{
+ writel(val, adc-mfd_tscadc-tscadc_base + reg);
+}
+
+static void tiadc_step_config(struct tiadc_device *adc_dev)
+{
+ unsigned int stepconfig;
+ int i, channels = 0, steps;
+
+ /*
+* There are 16 configurable steps and 8 analog input
+* lines available which are shared between Touchscreen and ADC.
+*
+* Steps backwards i.e. from 16 towards 0 are used by ADC
+* depending on number of input lines needed.
+* Channel would represent which analog input
+* needs to be given to ADC to digitalize data.
+*/
+
+ steps = TOTAL_STEPS - adc_dev-channels;
+ channels = TOTAL_CHANNELS - adc_dev-channels;
+
+ stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;
+
+ for (i = (steps + 1); i = TOTAL_STEPS; i++) {
+ tiadc_writel(adc_dev, REG_STEPCONFIG(i),
+ stepconfig | STEPCONFIG_INP(channels));
+ tiadc_writel(adc_dev, REG_STEPDELAY(i),
+ STEPCONFIG_OPENDLY);
+ channels++;
+ }
+ tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+}
+
+static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
+{
+ struct iio_chan_spec *chan_array;
+ int i;
+
+ indio_dev-num_channels = channels;
+ chan_array = kcalloc(indio_dev-num_channels,
+ sizeof(struct iio_chan_spec), GFP_KERNEL);
+
+ if (chan_array == NULL)
+
[PATCH RESEND 4/8] input: TSC: ti_tscadc: Remove definition of End Of Interrupt register
The touchscreen IP uses level sensitive interrupts rather than edge sensitive interrupts and therefore the is no need to use the EOI register to have the module re-strobe the interrupt line if there pending interrupts exist. Signed-off-by: Patil, Rachna rac...@ti.com --- drivers/input/touchscreen/ti_tscadc.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/input/touchscreen/ti_tscadc.c b/drivers/input/touchscreen/ti_tscadc.c index 2cc19b0..ec0a442 100644 --- a/drivers/input/touchscreen/ti_tscadc.c +++ b/drivers/input/touchscreen/ti_tscadc.c @@ -27,7 +27,6 @@ #include linux/input/ti_tscadc.h #include linux/delay.h -#define REG_IRQEOI 0x020 #define REG_RAWIRQSTATUS 0x024 #define REG_IRQSTATUS 0x028 #define REG_IRQENABLE 0x02C @@ -330,8 +329,6 @@ static irqreturn_t tscadc_irq(int irq, void *dev) } tscadc_writel(ts_dev, REG_IRQSTATUS, irqclr); - /* check pending interrupts */ - tscadc_writel(ts_dev, REG_IRQEOI, 0x0); tscadc_writel(ts_dev, REG_SE, STPENB_STEPENB); return IRQ_HANDLED; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 5/8] input: TSC: ti_tscadc: Rename the existing touchscreen driver
Make way for addition of MFD driver.
The existing touchsreen driver is a MFD client.
For better readability we rename the file to
indicate its functionality as only touchscreen.
Signed-off-by: Patil, Rachna rac...@ti.com
---
Changes in v2:
Missed changing the name of touchscreen header file
in the previous version.
Adding the same.
Changes in v3:
no changes.
Changes in v4:
no changes.
drivers/input/touchscreen/Kconfig |4 +-
drivers/input/touchscreen/Makefile |2 +-
.../touchscreen/{ti_tscadc.c = ti_am335x_tsc.c} | 96 ++--
.../linux/input/{ti_tscadc.h = ti_am335x_tsc.h} |4 +-
4 files changed, 53 insertions(+), 53 deletions(-)
rename drivers/input/touchscreen/{ti_tscadc.c = ti_am335x_tsc.c} (83%)
rename include/linux/input/{ti_tscadc.h = ti_am335x_tsc.h} (88%)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 1ba232c..7bdb629 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -529,7 +529,7 @@ config TOUCHSCREEN_TOUCHWIN
To compile this driver as a module, choose M here: the
module will be called touchwin.
-config TOUCHSCREEN_TI_TSCADC
+config TOUCHSCREEN_TI_AM335X_TSC
tristate TI Touchscreen Interface
depends on ARCH_OMAP2PLUS
help
@@ -539,7 +539,7 @@ config TOUCHSCREEN_TI_TSCADC
If unsure, say N.
To compile this driver as a module, choose M here: the
- module will be called ti_tscadc.
+ module will be called ti_am335x_tsc.
config TOUCHSCREEN_ATMEL_TSADCC
tristate Atmel Touchscreen Interface
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 178eb12..7c4c78e 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -52,7 +52,7 @@ obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o
obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o
obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o
obj-$(CONFIG_TOUCHSCREEN_STMPE)+= stmpe-ts.o
-obj-$(CONFIG_TOUCHSCREEN_TI_TSCADC)+= ti_tscadc.o
+obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC)+= ti_am335x_tsc.o
obj-$(CONFIG_TOUCHSCREEN_TNETV107X)+= tnetv107x-ts.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
diff --git a/drivers/input/touchscreen/ti_tscadc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
similarity index 83%
rename from drivers/input/touchscreen/ti_tscadc.c
rename to drivers/input/touchscreen/ti_am335x_tsc.c
index ec0a442..462950a 100644
--- a/drivers/input/touchscreen/ti_tscadc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -24,7 +24,7 @@
#include linux/clk.h
#include linux/platform_device.h
#include linux/io.h
-#include linux/input/ti_tscadc.h
+#include linux/input/ti_am335x_tsc.h
#include linux/delay.h
#define REG_RAWIRQSTATUS 0x024
@@ -123,7 +123,7 @@
#define ADC_CLK300
#define MAX_12BIT ((1 12) - 1)
-struct tscadc {
+struct titsc {
struct input_dev*input;
struct clk *tsc_ick;
void __iomem*tsc_base;
@@ -134,18 +134,18 @@ struct tscadc {
int steps_to_configure;
};
-static unsigned int tscadc_readl(struct tscadc *ts, unsigned int reg)
+static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
{
return readl(ts-tsc_base + reg);
}
-static void tscadc_writel(struct tscadc *tsc, unsigned int reg,
+static void titsc_writel(struct titsc *tsc, unsigned int reg,
unsigned int val)
{
writel(val, tsc-tsc_base + reg);
}
-static void tscadc_step_config(struct tscadc *ts_dev)
+static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
int i, total_steps;
@@ -170,8 +170,8 @@ static void tscadc_step_config(struct tscadc *ts_dev)
}
for (i = 1; i = ts_dev-steps_to_configure; i++) {
- tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
- tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
config = 0;
@@ -192,8 +192,8 @@ static void tscadc_step_config(struct tscadc *ts_dev)
}
for (i = (ts_dev-steps_to_configure + 1); i = total_steps; i++) {
- tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
- tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
config = 0;
@@ -202,40 +202,40 @@ static void tscadc_step_config(struct tscadc *ts_dev)
[PATCH RESEND 7/8] input: TSC: ti_tsc: Convert TSC into a MFDevice
This patch converts touchscreen into a MFD client. All the register definitions, clock initialization, etc has been moved to MFD core driver. Signed-off-by: Patil, Rachna rac...@ti.com --- Changes in v2: No changes Changes in v3: No changes Changes in v4: No changes Changes in v5: No changes drivers/input/touchscreen/Kconfig |2 +- drivers/input/touchscreen/ti_am335x_tsc.c | 318 + drivers/mfd/ti_am335x_tscadc.c| 11 + include/linux/mfd/ti_am335x_tscadc.h | 10 +- 4 files changed, 118 insertions(+), 223 deletions(-) diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 7bdb629..89a0492 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -531,7 +531,7 @@ config TOUCHSCREEN_TOUCHWIN config TOUCHSCREEN_TI_AM335X_TSC tristate TI Touchscreen Interface - depends on ARCH_OMAP2PLUS + depends on MFD_TI_AM335X_TSCADC help Say Y here if you have 4/5/8 wire touchscreen controller to be connected to the ADC controller on your TI AM335x SoC. diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index 462950a..7a18a8a 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -27,106 +27,15 @@ #include linux/input/ti_am335x_tsc.h #include linux/delay.h -#define REG_RAWIRQSTATUS 0x024 -#define REG_IRQSTATUS 0x028 -#define REG_IRQENABLE 0x02C -#define REG_IRQWAKEUP 0x034 -#define REG_CTRL 0x040 -#define REG_ADCFSM 0x044 -#define REG_CLKDIV 0x04C -#define REG_SE 0x054 -#define REG_IDLECONFIG 0x058 -#define REG_CHARGECONFIG 0x05C -#define REG_CHARGEDELAY0x060 -#define REG_STEPCONFIG(n) (0x64 + ((n - 1) * 8)) -#define REG_STEPDELAY(n) (0x68 + ((n - 1) * 8)) -#define REG_FIFO0CNT 0xE4 -#define REG_FIFO0THR 0xE8 -#define REG_FIFO1THR 0xF4 -#define REG_FIFO0 0x100 -#define REG_FIFO1 0x200 - -/* Register Bitfields */ -#define IRQWKUP_ENBBIT(0) - -/* Step Enable */ -#define STEPENB_MASK (0x1 0) -#define STEPENB(val) (val 0) -#define STPENB_STEPENB STEPENB(0x7FFF) - -/* IRQ enable */ -#define IRQENB_FIFO0THRES BIT(2) -#define IRQENB_FIFO1THRES BIT(5) -#define IRQENB_PENUP BIT(9) - -/* Step Configuration */ -#define STEPCONFIG_MODE_MASK (3 0) -#define STEPCONFIG_MODE(val) (val 0) -#define STEPCONFIG_MODE_HWSYNC STEPCONFIG_MODE(2) -#define STEPCONFIG_AVG_MASK(7 2) -#define STEPCONFIG_AVG(val)(val 2) -#define STEPCONFIG_AVG_16 STEPCONFIG_AVG(4) -#define STEPCONFIG_XPP BIT(5) -#define STEPCONFIG_XNN BIT(6) -#define STEPCONFIG_YPP BIT(7) -#define STEPCONFIG_YNN BIT(8) -#define STEPCONFIG_XNP BIT(9) -#define STEPCONFIG_YPN BIT(10) -#define STEPCONFIG_INM_MASK(0xF 15) -#define STEPCONFIG_INM(val)(val 15) -#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8) -#define STEPCONFIG_INP_MASK(0xF 19) -#define STEPCONFIG_INP(val)(val 19) -#define STEPCONFIG_INP_AN2 STEPCONFIG_INP(2) -#define STEPCONFIG_INP_AN3 STEPCONFIG_INP(3) -#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4) -#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8) -#define STEPCONFIG_FIFO1 BIT(26) - -/* Delay register */ -#define STEPDELAY_OPEN_MASK(0x3 0) -#define STEPDELAY_OPEN(val)(val 0) -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098) - -/* Charge Config */ -#define STEPCHARGE_RFP_MASK(7 12) -#define STEPCHARGE_RFP(val)(val 12) -#define STEPCHARGE_RFP_XPULSTEPCHARGE_RFP(1) -#define STEPCHARGE_INM_MASK(0xF 15) -#define STEPCHARGE_INM(val)(val 15) -#define STEPCHARGE_INM_AN1 STEPCHARGE_INM(1) -#define STEPCHARGE_INP_MASK(0xF 19) -#define STEPCHARGE_INP(val)(val 19) -#define STEPCHARGE_INP_AN1 STEPCHARGE_INP(1) -#define STEPCHARGE_RFM_MASK(3 23) -#define STEPCHARGE_RFM(val)(val 23) -#define STEPCHARGE_RFM_XNURSTEPCHARGE_RFM(1) - -/* Charge delay */ -#define CHARGEDLY_OPEN_MASK(0x3 0) -#define CHARGEDLY_OPEN(val)(val 0) -#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(1) - -/* Control register */ -#define CNTRLREG_TSCSSENB BIT(0) -#define CNTRLREG_STEPIDBIT(1) -#define CNTRLREG_STEPCONFIGWRT BIT(2) -#define CNTRLREG_AFE_CTRL_MASK (3 5) -#define CNTRLREG_AFE_CTRL(val) (val 5) -#define CNTRLREG_4WIRE CNTRLREG_AFE_CTRL(1) -#define CNTRLREG_5WIRE CNTRLREG_AFE_CTRL(2) -#define CNTRLREG_8WIRE CNTRLREG_AFE_CTRL(3) -#define CNTRLREG_TSCENBBIT(7) +#include linux/mfd/ti_am335x_tscadc.h #define ADCFSM_STEPID 0x10 #define SEQ_SETTLE 275 -#define ADC_CLK
[PATCH RESEND 6/8] MFD: ti_tscadc: Add support for TI's TSC/ADC MFDevice
Add the mfd core driver which supports touchscreen
and ADC.
With this patch we are only adding infrastructure to
support the MFD clients.
Signed-off-by: Patil, Rachna rac...@ti.com
---
Changes in v2:
Merged [PATCH 5/5] MFD: ti_tscadc: Add check on number of i/p
channels,
patch submitted in previous version into this file.
Changes in v3:
No changes
Changes in v4:
No changes
Changes in v5:
Make use of devm_xxx and regmap MMIO API's.
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile |1 +
drivers/mfd/ti_am335x_tscadc.c | 250 ++
include/linux/mfd/ti_am335x_tscadc.h | 137 +++
4 files changed, 399 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/ti_am335x_tscadc.c
create mode 100644 include/linux/mfd/ti_am335x_tscadc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index acab3ef..9bba7f7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -94,6 +94,17 @@ config MFD_TI_SSP
To compile this driver as a module, choose M here: the
module will be called ti-ssp.
+config MFD_TI_AM335X_TSCADC
+ tristate TI ADC / Touch Screen chip support
+ select MFD_CORE
+ select REGMAP
+ select REGMAP_MMIO
+ help
+ If you say yes here you get support for Texas Instruments series
+ of Touch Screen /ADC chips.
+ To compile this driver as a module, choose M here: the
+ module will be called ti_am335x_tscadc.
+
config HTC_EGPIO
bool HTC EGPIO support
depends on GENERIC_HARDIRQS GPIOLIB ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d8ccb63..442c17e 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o
obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
obj-$(CONFIG_MFD_TI_SSP) += ti-ssp.o
+obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
obj-$(CONFIG_MFD_STA2X11) += sta2x11-mfd.o
obj-$(CONFIG_MFD_STMPE)+= stmpe.o
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
new file mode 100644
index 000..14df67b
--- /dev/null
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -0,0 +1,250 @@
+/*
+ * TI Touch Screen / ADC MFD driver
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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/init.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/regmap.h
+#include linux/mfd/core.h
+#include linux/pm_runtime.h
+
+#include linux/mfd/ti_am335x_tscadc.h
+
+static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int reg)
+{
+ unsigned int val;
+
+ regmap_read(tsadc-regmap_tscadc, reg, val);
+ return val;
+}
+
+static void tscadc_writel(struct ti_tscadc_dev *tsadc, unsigned int reg,
+ unsigned int val)
+{
+ regmap_write(tsadc-regmap_tscadc, reg, val);
+}
+
+static const struct regmap_config tscadc_regmap_config = {
+ .name = ti_tscadc,
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+};
+
+static void tscadc_idle_config(struct ti_tscadc_dev *config)
+{
+ unsigned int idleconfig;
+
+ idleconfig = STEPCONFIG_YNN | STEPCONFIG_INM_ADCREFM |
+ STEPCONFIG_INP_ADCREFM | STEPCONFIG_YPN;
+
+ tscadc_writel(config, REG_IDLECONFIG, idleconfig);
+}
+
+static int __devinit ti_tscadc_probe(struct platform_device *pdev)
+{
+ struct ti_tscadc_dev*tscadc;
+ struct resource *res;
+ struct clk *clk;
+ struct mfd_tscadc_board *pdata = pdev-dev.platform_data;
+ int irq;
+ int err, ctrl;
+ int clk_value, clock_rate;
+
+ if (!pdata) {
+ dev_err(pdev-dev, Could not find platform data\n);
+ return -EINVAL;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(pdev-dev, no memory resource defined.\n);
+ return -EINVAL;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(pdev-dev, no irq ID is specified.\n);
+ return -EINVAL;
+ }
+
+ /* Allocate memory for device */
+ tscadc
Re: [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
On Tue, Oct 16, 2012 at 08:29:56AM +0100, Lee Jones wrote: On Tue, 16 Oct 2012, Mark Brown wrote: Not looked at the patch yet but patch 2 doesn't seem to have appeared? Has it arrived yet? Arnd responded to it, so it hit the list. Since Arnd's comments I've also fired v2 up - do you see it/them? Not in my inbox, I'm not looking at the list right now. -- 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: Re: [PATCH] block: Add blk_rq_pos(rq) to sort rq when plushing plug-list.
2012/10/16 Jianpeng Ma majianp...@gmail.com: On 2012-10-15 21:18 Shaohua Li s...@kernel.org Wrote: 2012/10/15 Shaohua Li s...@fusionio.com: 2012/10/15 Jianpeng Ma majianp...@gmail.com: My workload is a raid5 which had 16 disks. And used our filesystem to write using direct-io mode. I used the blktrace to find those message: 8,16 0 3570 1.083923979 2519 I W 144323176 + 24 [md127_raid5] 8,16 00 1.083926214 0 m N cfq2519 insert_request 8,16 0 3571 1.083926586 2519 I W 144323072 + 104 [md127_raid5] 8,16 00 1.083926952 0 m N cfq2519 insert_request 8,16 0 3572 1.083927180 2519 U N [md127_raid5] 2 8,16 00 1.083927870 0 m N cfq2519 Not idling.st-count:1 8,16 00 1.083928320 0 m N cfq2519 dispatch_insert 8,16 00 1.083928951 0 m N cfq2519 dispatched a request 8,16 00 1.083929443 0 m N cfq2519 activate rq,drv=1 8,16 0 3573 1.083929530 2519 D W 144323176 + 24 [md127_raid5] 8,16 00 1.083933883 0 m N cfq2519 Not idling.st-count:1 8,16 00 1.083934189 0 m N cfq2519 dispatch_insert 8,16 00 1.083934654 0 m N cfq2519 dispatched a request 8,16 00 1.083935014 0 m N cfq2519 activate rq,drv=2 8,16 0 3574 1.083935101 2519 D W 144323072 + 104 [md127_raid5] 8,16 0 3575 1.084196179 0 C W 144323176 + 24 [0] 8,16 00 1.084197979 0 m N cfq2519 complete rqnoidle 0 8,16 0 3576 1.084769073 0 C W 144323072 + 104 [0] .. 8,16 1 3596 1.091394357 2519 I W 144322544 + 16 [md127_raid5] 8,16 10 1.091396181 0 m N cfq2519 insert_request 8,16 1 3597 1.091396571 2519 I W 144322520 + 24 [md127_raid5] 8,16 10 1.091396934 0 m N cfq2519 insert_request 8,16 1 3598 1.091397165 2519 I W 144322488 + 32 [md127_raid5] 8,16 10 1.091397477 0 m N cfq2519 insert_request 8,16 1 3599 1.091397708 2519 I W 144322432 + 56 [md127_raid5] 8,16 10 1.091398023 0 m N cfq2519 insert_request 8,16 1 3600 1.091398284 2519 U N [md127_raid5] 4 8,16 10 1.091398986 0 m N cfq2519 Not idling. st-count:1 8,16 10 1.091399511 0 m N cfq2519 dispatch_insert 8,16 10 1.091400217 0 m N cfq2519 dispatched a request 8,16 10 1.091400688 0 m N cfq2519 activate rq,drv=1 8,16 1 3601 1.091400766 2519 D W 144322544 + 16 [md127_raid5] 8,16 10 1.091406151 0 m N cfq2519 Not idling.st-count:1 8,16 10 1.091406460 0 m N cfq2519 dispatch_insert 8,16 10 1.091406931 0 m N cfq2519 dispatched a request 8,16 10 1.091407291 0 m N cfq2519 activate rq,drv=2 8,16 1 3602 1.091407378 2519 D W 144322520 + 24 [md127_raid5] 8,16 10 1.091414006 0 m N cfq2519 Not idling.st-count:1 8,16 10 1.091414297 0 m N cfq2519 dispatch_insert 8,16 10 1.091414702 0 m N cfq2519 dispatched a request 8,16 10 1.091415047 0 m N cfq2519 activate rq, drv=3 8,16 1 3603 1.091415125 2519 D W 144322488 + 32 [md127_raid5] 8,16 10 1.091416469 0 m N cfq2519 Not idling.st-count:1 8,16 10 1.091416754 0 m N cfq2519 dispatch_insert 8,16 10 1.091417186 0 m N cfq2519 dispatched a request 8,16 10 1.091417535 0 m N cfq2519 activate rq,drv=4 8,16 1 3604 1.091417628 2519 D W 144322432 + 56 [md127_raid5] 8,16 1 3605 1.091857225 4393 C W 144322544 + 16 [0] 8,16 10 1.091858753 0 m N cfq2519 complete rqnoidle 0 8,16 1 3606 1.092068456 4393 C W 144322520 + 24 [0] 8,16 10 1.092069851 0 m N cfq2519 complete rqnoidle 0 8,16 1 3607 1.092350440 4393 C W 144322488 + 32 [0] 8,16 10 1.092351688 0 m N cfq2519 complete rqnoidle 0 8,16 1 3608 1.093629323 0 C W 144322432 + 56 [0] 8,16 10 1.093631151 0 m N cfq2519 complete rqnoidle 0 8,16 10 1.093631574 0 m N cfq2519 will busy wait 8,16 10 1.093631829 0 m N cfq schedule dispatch Because in func elv_attempt_insert_merge, it only to try to backmerge.So the four request can't merge in theory. I trace ten minutes and count those situation, it can count 25%. With the patch,i tested and not found situation like above. Signed-off-by: Jianpeng Ma majianp...@gmail.com --- block/blk-core.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c
Re: [PATCH v2] mmc: core: Add support for idle time BKOPS
Hi Maya,
I'm testing with your patch..but i need to have the more time for testing.
In now, it looks good to me. Thank you for working the idle bkops.
Best Regards,
Jaehoon Chung
---
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 172a768..ed040d5 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -827,6 +827,9 @@ static int mmc_blk_issue_discard_rq(struct mmc_queue *mq,
struct request *req)
from = blk_rq_pos(req);
nr = blk_rq_sectors(req);
+ if (card-ext_csd.bkops_en)
+ card-bkops_info.sectors_changed += blk_rq_sectors(req);
using nr?
+
if (mmc_can_discard(card))
arg = MMC_DISCARD_ARG;
else if (mmc_can_trim(card))
@@ -1268,6 +1271,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *rqc)
if (!rqc !mq-mqrq_prev-req)
return 0;
+ if (rqc (card-ext_csd.bkops_en) (rq_data_dir(rqc) == WRITE))
+ card-bkops_info.sectors_changed += blk_rq_sectors(rqc);
Fix the indent.
+
do {
if (rqc) {
/*
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index e360a97..e96f5cf 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -51,6 +51,7 @@ static int mmc_queue_thread(void *d)
{
struct mmc_queue *mq = d;
struct request_queue *q = mq-queue;
+ struct mmc_card *card = mq-card;
current-flags |= PF_MEMALLOC;
@@ -66,6 +67,17 @@ static int mmc_queue_thread(void *d)
spin_unlock_irq(q-queue_lock);
if (req || mq-mqrq_prev-req) {
+ /*
+ * If this is the first request, BKOPs might be in
+ * progress and needs to be stopped before issuing the
+ * request
+ */
+ if (card-ext_csd.bkops_en
+ card-bkops_info.started_delayed_bkops) {
+ card-bkops_info.started_delayed_bkops = false;
+ mmc_stop_bkops(card);
if mmc_stop_bkops is failed..?
+ }
+
set_current_state(TASK_RUNNING);
mq-issue_fn(mq, req);
} else {
@@ -73,6 +85,7 @@ static int mmc_queue_thread(void *d)
set_current_state(TASK_RUNNING);
break;
}
+ mmc_start_delayed_bkops(card);
up(mq-thread_sem);
schedule();
down(mq-thread_sem);
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 6612163..fd8783d 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -253,9 +253,42 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
}
/**
+ * mmc_start_delayed_bkops() - Start a delayed work to check for
+ * the need of non urgent BKOPS
+ *
+ * @card: MMC card to start BKOPS on
+ */
+void mmc_start_delayed_bkops(struct mmc_card *card)
+{
+ if (!card || !card-ext_csd.bkops_en || mmc_card_doing_bkops(card))
+ return;
+
+ if (card-bkops_info.sectors_changed
+ BKOPS_MIN_SECTORS_TO_QUEUE_DELAYED_WORK)
+ return;
+
+ pr_debug(%s: %s: queueing delayed_bkops_work\n,
+ mmc_hostname(card-host), __func__);
+
+ card-bkops_info.sectors_changed = 0;
+
+ /*
+ * cancel_delayed_bkops_work will prevent a race condition between
+ * fetching a request by the mmcqd and the delayed work, in case
+ * it was removed from the queue work but not started yet
+ */
+ card-bkops_info.cancel_delayed_work = false;
+ card-bkops_info.started_delayed_bkops = true;
+ queue_delayed_work(system_nrt_wq, card-bkops_info.dw,
+msecs_to_jiffies(
+card-bkops_info.delay_ms));
+}
+EXPORT_SYMBOL(mmc_start_delayed_bkops);
+
+/**
* mmc_start_bkops - start BKOPS for supported cards
* @card: MMC card to start BKOPS
- * @form_exception: A flag to indicate if this function was
+ * @from_exception: A flag to indicate if this function was
*called due to an exception raised by the card
*
* Start background operations whenever requested.
@@ -269,25 +302,47 @@ void mmc_start_bkops(struct mmc_card *card, bool
from_exception)
bool use_busy_signal;
BUG_ON(!card);
-
- if (!card-ext_csd.bkops_en || mmc_card_doing_bkops(card))
+ if (!card-ext_csd.bkops_en)
return;
+ mmc_claim_host(card-host);
+
+ if ((card-bkops_info.cancel_delayed_work) !from_exception) {
+ pr_debug(%s: %s: cancel_delayed_work was set, exit\n,
+ mmc_hostname(card-host), __func__);
+
Re: [RFC PATCH] posix timers: allocate timer id per task
15.10.2012 20:34, Eric Dumazet пишет: On Mon, 2012-10-15 at 20:17 +0400, Stanislav Kinsbursky wrote: This patch is required CRIU project (www.criu.org). To migrate processes with posix timers we have to make sure, that we can restore posix timer with proper id. Currently, this is not true, because timer ids are allocated globally. So, this is precursor patch and it's purpose is make posix timer id to be allocated per task. Patch replaces global idr with global hash table for posix timers and makes timer ids unique not globally, but per task. Next free timer id is type of integer and stored on signal struct (posix_timer_id). If free timer id reaches negative value on timer creation, it will be dropped to zero and -EAGAIN will be returned to user. Hash table is size of page (4KB). Key is constructed as follows: key = hash_ptr(current-signal) ^ hash_32(posix_timer_id); Signed-off-by: Stanislav Kinsbursky skinsbur...@parallels.com Hmm, it seems you removed idr, rcu friendly, and reinstated a fixed size hash table, protected by a _single_ spinlock ? Oh well. Please take a look at commit 8af088710d1e, and make sure you fix your problem and keep performance as good as before. Thanks, Eric. I'll update. -- Best regards, Stanislav Kinsbursky -- 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/
Very bad performance on Qemu/KVM
Good morning LKML, I see extremely slow virtual machines running on qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64 on Centos 6.3 with Linux 2.6.32-279.5.2.el6.x86_64 on a 64 core machine using AMD Opteron(TM) Processor 6276 (dell r815). The guests are Centos 6.3, Linux 2.6.32-220.13.1.el6.x86_64. The disk images reside on local storage, ext4 filesystem. I checked that kvm is loaded and enabled. I changed -drive to use if=virtio, -net to use model=virtio. From the processes running it seems that cpu performance is the bottleneck. I added -cpu host to skip the emulation, but this did not fix the issue. Comparing the performance to qemu running on a xenserver, performance is at most half of it. Does anyone of you have a good pointer how to debug this further or are there any known issues with the given setup? I'm happy for every pointer I get, as there seems to be no easy to spot issue. Cheers, Nico -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 -- 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/
[RESEND PATCH 1/2] perf, cpu hotplug: Run CPU_STARTING notifiers with irqs disabled
The CPU_STARTING notifiers are supposed to be run with irqs disabled. But the
perf_cpu_notifier() macro invokes them without doing that. Fix it.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/perf_event.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 2e90235..0647805 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -803,10 +803,13 @@ static inline void perf_event_task_tick(void)
{ }
do { \
static struct notifier_block fn##_nb __cpuinitdata =\
{ .notifier_call = fn, .priority = CPU_PRI_PERF }; \
+ unsigned long flags;\
fn(fn##_nb, (unsigned long)CPU_UP_PREPARE, \
(void *)(unsigned long)smp_processor_id()); \
+ local_irq_save(flags); \
fn(fn##_nb, (unsigned long)CPU_STARTING, \
(void *)(unsigned long)smp_processor_id()); \
+ local_irq_restore(flags); \
fn(fn##_nb, (unsigned long)CPU_ONLINE, \
(void *)(unsigned long)smp_processor_id()); \
register_cpu_notifier(fn##_nb);\
--
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/
[RESEND PATCH 2/2] perf, cpu hotplug: Use cached value of smp_processor_id()
The perf_cpu_notifier() macro invokes smp_processor_id() multiple
times. Optimize it by using a local variable.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
include/linux/perf_event.h |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 0647805..6bfb2faa 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -803,15 +803,16 @@ static inline void perf_event_task_tick(void)
{ }
do { \
static struct notifier_block fn##_nb __cpuinitdata =\
{ .notifier_call = fn, .priority = CPU_PRI_PERF }; \
+ unsigned long cpu = smp_processor_id(); \
unsigned long flags;\
fn(fn##_nb, (unsigned long)CPU_UP_PREPARE, \
- (void *)(unsigned long)smp_processor_id()); \
+ (void *)(unsigned long)cpu);\
local_irq_save(flags); \
fn(fn##_nb, (unsigned long)CPU_STARTING, \
- (void *)(unsigned long)smp_processor_id()); \
+ (void *)(unsigned long)cpu);\
local_irq_restore(flags); \
fn(fn##_nb, (unsigned long)CPU_ONLINE, \
- (void *)(unsigned long)smp_processor_id()); \
+ (void *)(unsigned long)cpu);\
register_cpu_notifier(fn##_nb);\
} while (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/
Linux 2.6.32.xx build breaks with gcc 4.7
lo lo, I'm trying to compile 2.6.32.60 with gcc 4.7.2, and getting the following error: CC arch/x86/kernel/ptrace.o arch/x86/kernel/ptrace.c:1472:17: error: conflicting types for 'syscall_trace_enter' In file included from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/vm86.h:130:0, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/processor.h:10, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/thread_info.h:22, from include/linux/thread_info.h:56, from include/linux/preempt.h:9, from include/linux/spinlock.h:50, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/timex.h:56, from include/linux/sched.h:56, from arch/x86/kernel/ptrace.c:11: /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/ptrace.h:145:13: note: previous declaration of 'syscall_trace_enter' was here arch/x86/kernel/ptrace.c:1517:17: error: conflicting types for 'syscall_trace_leave' In file included from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/vm86.h:130:0, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/processor.h:10, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/thread_info.h:22, from include/linux/thread_info.h:56, from include/linux/preempt.h:9, from include/linux/spinlock.h:50, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/timex.h:56, from include/linux/sched.h:56, from arch/x86/kernel/ptrace.c:11: /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/ptrace.h:146:13: note: previous declaration of 'syscall_trace_leave' was here make[2]: *** [arch/x86/kernel/ptrace.o] Error 1 make[1]: *** [arch/x86/kernel] Error 2 make: *** [arch/x86] Error 2 My environment looks like: Linux 3.2.30, glibc 2.16, gcc 4.7.2 If I comment out the ancient line, kernel compiles fine. Willy says: | The affected entry is only used there : | arch/x86/include/asm/ptrace.h:extern void syscall_trace_leave(struct pt_regs *); | arch/x86/include/asm/thread_info.h:/* work to do in syscall_trace_leave() */ | arch/x86/kernel/entry_32.S: ENABLE_INTERRUPTS(CLBR_ANY) # could let syscall_trace_leave() call | arch/x86/kernel/entry_32.S: call syscall_trace_leave | arch/x86/kernel/entry_64.S: call syscall_trace_leave | arch/x86/kernel/ptrace.c:asmregparm void syscall_trace_leave(struct pt_regs *regs) | So if the two calls above don't need the include then maybe we can | safely remove 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: [RFC PATCH] posix timers: allocate timer id per task
15.10.2012 21:04, Peter Zijlstra пишет: On Mon, 2012-10-15 at 20:17 +0400, Stanislav Kinsbursky wrote: This patch is required CRIU project (www.criu.org). To migrate processes with posix timers we have to make sure, that we can restore posix timer with proper id. Currently, this is not true, because timer ids are allocated globally. So, this is precursor patch and it's purpose is make posix timer id to be allocated per task. Patch replaces global idr with global hash table for posix timers and makes timer ids unique not globally, but per task. Next free timer id is type of integer and stored on signal struct (posix_timer_id). If free timer id reaches negative value on timer creation, it will be dropped to zero and -EAGAIN will be returned to user. Hash table is size of page (4KB). Key is constructed as follows: key = hash_ptr(current-signal) ^ hash_32(posix_timer_id); but but but.. isn't this what namespaces were invented for to solve? Why not use the regular namespace infrastructure? The reason is that CRIU have to support single processes within existent namespaces. -- Best regards, Stanislav Kinsbursky -- 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 06/14] memcg: kmem controller infrastructure
(2012/10/12 18:13), Glauber Costa wrote:
On 10/12/2012 12:57 PM, Michal Hocko wrote:
On Fri 12-10-12 12:44:57, Glauber Costa wrote:
On 10/12/2012 12:39 PM, Michal Hocko wrote:
On Fri 12-10-12 11:45:46, Glauber Costa wrote:
On 10/11/2012 04:42 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:12, Glauber Costa wrote:
[...]
+ /*
+* Conditions under which we can wait for the oom_killer.
+* __GFP_NORETRY should be masked by __mem_cgroup_try_charge,
+* but there is no harm in being explicit here
+*/
+ may_oom = (gfp __GFP_WAIT) !(gfp __GFP_NORETRY);
Well we _have to_ check __GFP_NORETRY here because if we don't then we
can end up in OOM. mem_cgroup_do_charge returns CHARGE_NOMEM for
__GFP_NORETRY (without doing any reclaim) and of oom==true we decrement
oom retries counter and eventually hit OOM killer. So the comment is
misleading.
I will update. What i understood from your last message is that we don't
really need to, because try_charge will do it.
IIRC I just said it couldn't happen before because migration doesn't go
through charge and thp disable oom by default.
I had it changed to:
/*
* Conditions under which we can wait for the oom_killer.
* We have to be able to wait, but also, if we can't retry,
* we obviously shouldn't go mess with oom.
*/
may_oom = (gfp __GFP_WAIT) !(gfp __GFP_NORETRY);
OK
+
+ _memcg = memcg;
+ ret = __mem_cgroup_try_charge(NULL, gfp, size PAGE_SHIFT,
+ _memcg, may_oom);
+
+ if (!ret) {
+ ret = res_counter_charge(memcg-kmem, size, fail_res);
Now that I'm thinking about the charging ordering we should charge the
kmem first because we would like to hit kmem limit before we hit u+k
limit, don't we.
Say that you have kmem limit 10M and the total limit 50M. Current `u'
would be 40M and this charge would cause kmem to hit the `k' limit. I
think we should fail to charge kmem before we go to u+k and potentially
reclaim/oom.
Or has this been alredy discussed and I just do not remember?
This has never been discussed as far as I remember. We charged u first
since day0, and you are so far the first one to raise it...
One of the things in favor of charging 'u' first is that
mem_cgroup_try_charge is already equipped to make a lot of decisions,
like when to allow reclaim, when to bypass charges, and it would be good
if we can reuse all that.
Hmm, I think that we should prevent from those decisions if kmem charge
would fail anyway (especially now when we do not have targeted slab
reclaim).
Let's revisit this discussion when we do have targeted reclaim. For now,
I'll agree that charging kmem first would be acceptable.
This will only make a difference when K U anyway.
Yes and it should work as advertised (aka hit the k limit first).
Just so we don't ping-pong in another submission:
I changed memcontrol.h's memcg_kmem_newpage_charge to include:
/* If the test is dying, just let it go. */
if (unlikely(test_thread_flag(TIF_MEMDIE)
|| fatal_signal_pending(current)))
return true;
I'm also attaching the proposed code in memcontrol.c
+static int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, u64 size)
+{
+ struct res_counter *fail_res;
+ struct mem_cgroup *_memcg;
+ int ret = 0;
+ bool may_oom;
+
+ ret = res_counter_charge(memcg-kmem, size, fail_res);
+ if (ret)
+ return ret;
+
+ /*
+* Conditions under which we can wait for the oom_killer.
+* We have to be able to wait, but also, if we can't retry,
+* we obviously shouldn't go mess with oom.
+*/
+ may_oom = (gfp __GFP_WAIT) !(gfp __GFP_NORETRY);
+
+ _memcg = memcg;
+ ret = __mem_cgroup_try_charge(NULL, gfp, size PAGE_SHIFT,
+ _memcg, may_oom);
+
+ if (ret == -EINTR) {
+ /*
+* __mem_cgroup_try_charge() chosed to bypass to root due to
+* OOM kill or fatal signal. Since our only options are to
+* either fail the allocation or charge it to this cgroup, do
+* it as a temporary condition. But we can't fail. From a
+* kmem/slab perspective, the cache has already been selected,
+* by mem_cgroup_get_kmem_cache(), so it is too late to change
+* our minds. This condition will only trigger if the task
+* entered memcg_charge_kmem in a sane state, but was
+* OOM-killed. during __mem_cgroup_try_charge. Tasks that are
+* already dying when the allocation triggers should have been
+* already directed to the root cgroup.
+*/
+ res_counter_charge_nofail(memcg-res, size, fail_res);
+ if (do_swap_account)
+
Re: [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
On Tue, 16 Oct 2012, Mark Brown wrote: On Tue, Oct 16, 2012 at 08:29:56AM +0100, Lee Jones wrote: On Tue, 16 Oct 2012, Mark Brown wrote: Not looked at the patch yet but patch 2 doesn't seem to have appeared? Has it arrived yet? Arnd responded to it, so it hit the list. Since Arnd's comments I've also fired v2 up - do you see it/them? Not in my inbox, I'm not looking at the list right now. Strange, both emails had you in CC. I'm assuming it's just the documentation patch you're missing. Let me resend it as a single patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Documentation: Describe Device Tree bindings for GPIO Regulator driver
Here we specify all non-standard bindings which can be used when
requesting the use of an GPIO controlled regulator from Device Tree.
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
.../bindings/regulator/gpio-regulator.txt | 36
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/gpio-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
new file mode 100644
index 000..3703be2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -0,0 +1,36 @@
+GPIO controlled regulators
+
+Required properties:
+- compatible : Must be regulator-gpio.
+
+Optional properties:
+- gpio-enable : GPIO to use to enable/disable the regulator.
+- gpios: GPIO group used to control voltage.
+- states : Selection of available voltages and GPIO configs.
+- startup-delay-us : Startup time in microseconds.
+- enable-active-high : Polarity of GPIO is active high (default is low).
+
+Any property defined as part of the core regulator binding defined in
+regulator.txt can also be used.
+
+Example:
+
+ mmciv: gpio-regulator {
+ compatible = regulator-gpio;
+
+ regulator-name = mmci-gpio-supply;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 260;
+ regulator-boot-on;
+
+ gpio-enable = gpio0 23 0x4;
+ gpios = gpio0 24 0x4
+gpio0 25 0x4;
+ states = 180 0x3
+ 220 0x2
+ 260 0x1
+ 290 0x0;
+
+ startup-delay-us = 10;
+ enable-active-high;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
Hi Greg, On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote: Hi Philippe, On 09/10/12 19:07, Philippe De Muyter wrote: [CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Do you get any responses? I didn't see any... No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm to drivers/dma/bestcomm (except a private and useful one telling me how to set '-M' option as default for 'git format-patch'), but at least this simpler patch seems to be in a wait bucket at http://patchwork.ozlabs.org/project/linuxppc-dev/list/. Regards Philippe PS: -M as default for 'git format-patch': put [diff] renames = true in .git/config Regards Greg On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: Hi Philippe, On 05/10/12 01:03, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: My biggest concern is the amount of MCD/DMA support code. And it is all done quite differently to everything else in the kernel. We may get a bit of push back from kernel folk who look after DMA. Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm (also from freescale, maybe an identical part, but I did not find any usable doc), but the powerpc folks kept that hidden in the arch/powerpc tree, instead of installing it in drivers/dma. The MCD DMA or DMA FEC code from freescale has a comment implying that this was first used in the MPC8220 part. And Montavista has a MPC8220 port, but I did not find it, so I do not know where they installed the MCD DMA driver. Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIFO_STATUSFECRFSR 18C RFIFO_CONTROL FECRFCR 190 RFIFO_LRF_PTR FECRLRFP 194 RFIFO_LWF_PTR FECRLWFP 198 RFIFO_ALARM FECRFAR 19C RFIFO_RDPTR FECRFRP 1A0 RFIFO_WRPTR FECRFWP 1A4 TFIFO_DATA FECTFDR 1A8 TFIFO_STATUSFECTFSR 1AC TFIFO_CONTROL FECTFCR 1B0 TFIFO_LRF_PTR FECTLRFP 1B4 TFIFO_LWF_PTR FECTLWFP 1B8 TFIFO_ALARM FECTFAR
Re: [RFC PATCH] posix timers: allocate timer id per task
15.10.2012 23:08, Thomas Gleixner пишет:
On Mon, 15 Oct 2012, Stanislav Kinsbursky wrote:
This patch is required CRIU project (www.criu.org).
To migrate processes with posix timers we have to make sure, that we can
restore posix timer with proper id.
Currently, this is not true, because timer ids are allocated globally.
So, this is precursor patch and it's purpose is make posix timer id to be
allocated per task.
You can't allocate them per task. posix timers are process wide.
This is probably a misunderstanding.
I meant process process.
What's the reason why you did not make the posix timer ids per name
space instead of going down to the per process level ?
The reason is that CRIU have to support single processes regardless to
namespaces.
Patch replaces global idr with global hash table for posix timers and
makes timer ids unique not globally, but per task. Next free timer id is type
of integer and stored on signal struct (posix_timer_id). If free timer id
reaches negative value on timer creation, it will be dropped to zero and
-EAGAIN will be returned to user.
So you want to allow 2^31 posix timers created for a single process?
I don't really want it.
I just tried to preserve existent logic. I.e. currently one process can create
2^31 posix timers (if no other processes tried to do the same).
But the amount can be decreased, of course.
+static struct k_itimer *__posix_timers_find(struct hlist_head *head, struct
signal_struct *sig, timer_t id)
+{
+ struct hlist_node *node;
+ struct k_itimer *timer;
+
+ hlist_for_each_entry(timer, node, head, t_hash) {
+ if ((timer-it_signal == sig) (timer-it_id == id))
+ return timer;
+ }
+ return NULL;
+}
+
+static struct k_itimer *posix_timer_find(timer_t id, unsigned long *flags)
+{
+ struct k_itimer *timer;
+ struct signal_struct *sig = current-signal;
+ struct hlist_head *head = posix_timers_hashtable[hash(sig, id)];
+
+ spin_lock_irqsave(hash_lock, *flags);
This is not going to fly. You just reintroduced a massive scalability
problem. See commit 8af08871
Yep, Eric already pointed to it.
I'll try to fix this problem, if the idea with hash table suits in general.
Thanks.
Thanks,
tglx
--
Best regards,
Stanislav Kinsbursky
--
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] perf probe: convert_name_to_addr() allocated the wrong size buffer for a function name
Hi,
2012/10/16 Masami Hiramatsu masami.hiramatsu...@hitachi.com:
(2012/10/16 10:37), Hyeoncheol Lee wrote:
convert_name_to_addr() allocated sizeof(char *) * MAX_PROBE_ARGS
bytes for a function name
Yeah, that one was from my laziness...
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Hyeoncheol Lee hyc@gmail.com
---
tools/perf/util/probe-event.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 49a256e..bb40ed4 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2352,13 +2352,14 @@ static int convert_name_to_addr(struct
perf_probe_event *pev, const char *exec)
free(exec_copy);
}
free(pp-function);
- pp-function = zalloc(sizeof(char *) * MAX_PROBE_ARGS);
+ pp-function = zalloc(sizeof(char) *
+ (3 + sizeof(unsigned long long) * 2));
Could you comment that this is enough long here?
Because a hexadecimal address that starts with 0x
will be stored in pp-function. sizeof(unsigned long long) * 2 is
maximum length of hexadecimal number of variable vaddr
and 3 bytes are for 0x and null character.
if (!pp-function) {
ret = -ENOMEM;
pr_warning(Failed to allocate memory by zalloc.\n);
goto out;
}
- e_snprintf(pp-function, MAX_PROBE_ARGS, 0x%llx, vaddr);
+ sprintf(pp-function, 0x%llx, vaddr);
And at least we should use snprintf instead of sprintf...
(I think ret = e_snprintf(...) is better)
You are right, but I didn't want to write down the length of
pp-function again.
ret = 0;
out:
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
Thank you very much!
--
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] perf probe: convert_name_to_addr() allocated the wrong size buffer for a function name
Hi,
2012/10/16 Srikar Dronamraju sri...@linux.vnet.ibm.com:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com [2012-10-16 13:19:57]:
(2012/10/16 10:37), Hyeoncheol Lee wrote:
convert_name_to_addr() allocated sizeof(char *) * MAX_PROBE_ARGS
bytes for a function name
Yeah, that one was from my laziness...
Guess not your fault, but mine.
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Hyeoncheol Lee hyc@gmail.com
---
tools/perf/util/probe-event.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 49a256e..bb40ed4 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2352,13 +2352,14 @@ static int convert_name_to_addr(struct
perf_probe_event *pev, const char *exec)
free(exec_copy);
}
free(pp-function);
- pp-function = zalloc(sizeof(char *) * MAX_PROBE_ARGS);
+ pp-function = zalloc(sizeof(char) *
+ (3 + sizeof(unsigned long long) * 2));
Could you comment that this is enough long here?
Also can we move the arith into a macro?
I will do.
if (!pp-function) {
ret = -ENOMEM;
pr_warning(Failed to allocate memory by zalloc.\n);
goto out;
}
- e_snprintf(pp-function, MAX_PROBE_ARGS, 0x%llx, vaddr);
+ sprintf(pp-function, 0x%llx, vaddr);
And at least we should use snprintf instead of sprintf...
(I think ret = e_snprintf(...) is better)
Agree.
Yes
ret = 0;
out:
--
Thanks and Regards
Srikar
Thank you for your comment.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c-hid: introduce HID over i2c specification implementation
On 10/15/2012 10:38 PM, Benjamin Tissoires wrote:
Notes:
{1}: I don't have all the informations in the beginning of the probe function
to
get the real size I need to allocate. So the behavior is to allocate first a
buffer by using HID_MIN_BUFFER_SIZE and once I got the information, I can
reallocate the buffer to the right size (in i2c_hid_start).
And there is a bug in this. See below.
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid.c
...
+static int i2c_hid_alloc_buffers(struct i2c_hid *ihid)
+{
+ /* the worst case is computed from the set_report command with a
+ * reportID 15 and the maximum report length */
+ int args_len = sizeof(__u8) + /* optional ReportID byte */
+sizeof(__u16) + /* data register */
+sizeof(__u16) + /* size of the report */
+ihid-bufsize; /* report */
+
+ ihid-inbuf = kzalloc(ihid-bufsize, GFP_KERNEL);
+
+ if (!ihid-inbuf)
+ return -ENOMEM;
+
+ ihid-argsbuf = kzalloc(args_len, GFP_KERNEL);
+
+ if (!ihid-argsbuf) {
+ kfree(ihid-inbuf);
+ return -ENOMEM;
+ }
+
+ ihid-cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL);
+
+ if (!ihid-cmdbuf) {
+ kfree(ihid-inbuf);
+ kfree(ihid-argsbuf);
+ return -ENOMEM;
+ }
+
+ return 0;
If this is called from hid_start and some of the latter allocation fails
here, you free the buffers appropriately. However if another start
occurs (e.g. by loading another module for that particular device), it
will crash, as the buffers will remain unallocated because at this point
ihid-bufsize == old_bufsize. You should set ihid-bufsize back to
old_bufsize if i2c_hid_alloc_buffers fails and also set the pointers to
NULL here.
regards,
--
js
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/
Re: [PATCH v4 08/14] res_counter: return amount of charges after res_counter_uncharge
(2012/10/08 19:06), Glauber Costa wrote: It is useful to know how many charges are still left after a call to res_counter_uncharge. While it is possible to issue a res_counter_read after uncharge, this can be racy. If we need, for instance, to take some action when the counters drop down to 0, only one of the callers should see it. This is the same semantics as the atomic variables in the kernel. Since the current return value is void, we don't need to worry about anything breaking due to this change: nobody relied on that, and only users appearing from now on will be checking this value. Signed-off-by: Glauber Costa glom...@parallels.com CC: Michal Hocko mho...@suse.cz CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com --- Documentation/cgroups/resource_counter.txt | 7 --- include/linux/res_counter.h| 12 +++- kernel/res_counter.c | 20 +--- 3 files changed, 24 insertions(+), 15 deletions(-) Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.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/
[PATCH V2 RESEND] gpio: samsung: use pr_* instead of printk
This patch uses pr_* instead of printk. Also, gpio_dbg
is replaced with pr_debug.
Signed-off-by: Ryan Mallon rmal...@gmail.com
Signed-off-by: Jingoo Han jg1@samsung.com
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/gpio/gpio-samsung.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index a006f0d..5c5ccdf 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -42,12 +42,6 @@
#include plat/gpio-fns.h
#include plat/pm.h
-#ifndef DEBUG_GPIO
-#define gpio_dbg(x...) do { } while (0)
-#else
-#define gpio_dbg(x...) printk(KERN_DEBUG x)
-#endif
-
int samsung_gpio_setpull_updown(struct samsung_gpio_chip *chip,
unsigned int off, samsung_gpio_pull_t pull)
{
@@ -599,7 +593,7 @@ static int samsung_gpiolib_4bit_input(struct gpio_chip
*chip,
con = ~(0xf con_4bit_shift(offset));
__raw_writel(con, base + GPIOCON_OFF);
- gpio_dbg(%s: %p: CON now %08lx\n, __func__, base, con);
+ pr_debug(%s: %p: CON now %08lx\n, __func__, base, con);
return 0;
}
@@ -627,7 +621,7 @@ static int samsung_gpiolib_4bit_output(struct gpio_chip
*chip,
__raw_writel(con, base + GPIOCON_OFF);
__raw_writel(dat, base + GPIODAT_OFF);
- gpio_dbg(%s: %p: CON %08lx, DAT %08lx\n, __func__, base, con, dat);
+ pr_debug(%s: %p: CON %08lx, DAT %08lx\n, __func__, base, con, dat);
return 0;
}
@@ -671,7 +665,7 @@ static int samsung_gpiolib_4bit2_input(struct gpio_chip
*chip,
con = ~(0xf con_4bit_shift(offset));
__raw_writel(con, regcon);
- gpio_dbg(%s: %p: CON %08lx\n, __func__, base, con);
+ pr_debug(%s: %p: CON %08lx\n, __func__, base, con);
return 0;
}
@@ -706,7 +700,7 @@ static int samsung_gpiolib_4bit2_output(struct gpio_chip
*chip,
__raw_writel(con, regcon);
__raw_writel(dat, base + GPIODAT_OFF);
- gpio_dbg(%s: %p: CON %08lx, DAT %08lx\n, __func__, base, con, dat);
+ pr_debug(%s: %p: CON %08lx, DAT %08lx\n, __func__, base, con, dat);
return 0;
}
@@ -926,10 +920,10 @@ static void __init samsung_gpiolib_add(struct
samsung_gpio_chip *chip)
#ifdef CONFIG_PM
if (chip-pm != NULL) {
if (!chip-pm-save || !chip-pm-resume)
- printk(KERN_ERR gpio: %s has missing PM functions\n,
+ pr_err(gpio: %s has missing PM functions\n,
gc-label);
} else
- printk(KERN_ERR gpio: %s has no PM function\n, gc-label);
+ pr_err(gpio: %s has no PM function\n, gc-label);
#endif
/* gpiochip_add() prints own failure message on error. */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] tty: pty - Move TIOCPKT handling into pty.c
On Fri, Sep 28, 2012 at 01:10:33AM +0400, Cyrill Gorcunov wrote: Since this ioctl is for pty devices only move it to pty.c. v2: - drop PTY_TYPE_MASTER test since it's master peer ioctl anyway (by jslaby@) Suggested-by: Alan Cox a...@lxorguk.ukuu.org.uk Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org CC: H. Peter Anvin h...@zytor.com CC: Greg Kroah-Hartman gre...@linuxfoundation.org CC: Pavel Emelyanov xe...@parallels.com CC: Jiri Slaby jsl...@suse.cz Greg, Alan, what about this series? Is there anything else I should do? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] mfd: add viperboard driver
On 10/12/2012 04:34 PM, Lars Poeschel wrote:
[...]
+static void vprbrd_dev_release(struct device *dev)
+{
+ return;
A empty release callback is usually a good indicator that something is
wrong. The release callback will be called once the last reference to the
device has been called, so the memory associated with the device should not
be freed before the release callback has been called, otherwise the memory
might be accessed after it has been freed...
+}
+
+static void vprbrd_free(struct vprbrd *dev)
+{
+ usb_put_dev(dev-usb_dev);
+ kfree(dev);
..., so this kfree should be moved from here to the release callback.
Btw. I'm wondering why is the extra platform device required? Can't you not
just use the usb device as the parent device for the mfd cells?
+}
[...][
--
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: compaction: Correct the nr_strict_isolated check for CMA
Thierry reported that the iron out patch for isolate_freepages_block() had problems due to the strict check being too strict with mm: compaction: Iron out isolate_freepages_block() and isolate_freepages_range() -fix1. It's possible that more pages than necessary are isolated but the check still fails and I missed that this fix was not picked up before RC1. This same problem has been identified in 3.7-RC1 by Tony Prisk and should be addressed by the following patch. Signed-off-by: Mel Gorman mgor...@suse.de Tested-by: Tony Prisk li...@prisktech.co.nz --- mm/compaction.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/compaction.c b/mm/compaction.c index 2c4ce17..9eef558 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -346,7 +346,7 @@ static unsigned long isolate_freepages_block(struct compact_control *cc, * pages requested were isolated. If there were any failures, 0 is * returned and CMA will fail. */ - if (strict nr_strict_required != total_isolated) + if (strict nr_strict_required total_isolated) total_isolated = 0; if (locked) -- 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 09/14] memcg: kmem accounting lifecycle management
(2012/10/12 17:41), Michal Hocko wrote: On Fri 12-10-12 11:47:17, Glauber Costa wrote: On 10/11/2012 05:11 PM, Michal Hocko wrote: On Mon 08-10-12 14:06:15, Glauber Costa wrote: Because kmem charges can outlive the cgroup, we need to make sure that we won't free the memcg structure while charges are still in flight. For reviewing simplicity, the charge functions will issue mem_cgroup_get() at every charge, and mem_cgroup_put() at every uncharge. This can get expensive, however, and we can do better. mem_cgroup_get() only really needs to be issued once: when the first limit is set. In the same spirit, we only need to issue mem_cgroup_put() when the last charge is gone. We'll need an extra bit in kmem_accounted for that: KMEM_ACCOUNTED_DEAD. it will be set when the cgroup dies, if there are charges in the group. If there aren't, we can proceed right away. Our uncharge function will have to test that bit every time the charges drop to 0. Because that is not the likely output of res_counter_uncharge, this should not impose a big hit on us: it is certainly much better than a reference count decrease at every operation. [ v3: merged all lifecycle related patches in one ] Signed-off-by: Glauber Costa glom...@parallels.com CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com CC: Christoph Lameter c...@linux.com CC: Pekka Enberg penb...@cs.helsinki.fi CC: Michal Hocko mho...@suse.cz CC: Johannes Weiner han...@cmpxchg.org CC: Suleiman Souhlal sulei...@google.com OK, I like the optimization. I have just one comment to the memcg_kmem_dead naming but other than that Acked-by: Michal Hocko mho...@suse.cz [...] +static bool memcg_kmem_dead(struct mem_cgroup *memcg) The name is tricky because it doesn't tell you that it clears the flag which made me scratch my head when reading comment in kmem_cgroup_destroy memcg_kmem_finally_kill_that_bastard() ? memcg_kmem_test_and_clear_dead? I know long but at least clear that the flag is cleared. Or just open code it. I agree. Ack by me with that naming. Thanks, -Kame -- 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] dw_mmc: fix multiple drv_data NULL dereferences
Commit 800d78bfccb3d38116abfda2a5b9c8afdbd5ea21 (mmc: dw_mmc: add
support for implementation specific callbacks) merged in v3.7-rc1.
The above commit introduced multiple NULL pointer dereferences when
the default dw_mci_pltfm_probe() is used, as it sets host-drv_data to
NULL, and that's only checked against NULL in 1 out of the 7 cases where
it is dereferenced.
Signed-off-by: James Hogan james.ho...@imgtec.com
---
drivers/mmc/host/dw_mmc-pltfm.c |4 ++--
drivers/mmc/host/dw_mmc.c | 29 +
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c960ca7..e595721 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -50,8 +50,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
if (!host-regs)
return -ENOMEM;
- if (host-drv_data-init) {
- ret = host-drv_data-init(host);
+ if (drv_data drv_data-init) {
+ ret = drv_data-init(host);
if (ret)
return ret;
}
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index c2828f3..0dc6e33 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -232,6 +232,7 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
{
struct mmc_data *data;
struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 cmdr;
cmd-error = -EINPROGRESS;
@@ -261,8 +262,8 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
cmdr |= SDMMC_CMD_DAT_WR;
}
- if (slot-host-drv_data-prepare_command)
- slot-host-drv_data-prepare_command(slot-host, cmdr);
+ if (drv_data drv_data-prepare_command)
+ drv_data-prepare_command(slot-host, cmdr);
return cmdr;
}
@@ -772,6 +773,7 @@ static void dw_mci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 regs;
/* set default 1 bit mode */
@@ -807,8 +809,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
slot-clock = ios-clock;
}
- if (slot-host-drv_data-set_ios)
- slot-host-drv_data-set_ios(slot-host, ios);
+ if (drv_data drv_data-set_ios)
+ drv_data-set_ios(slot-host, ios);
switch (ios-power_mode) {
case MMC_POWER_UP:
@@ -1815,6 +1817,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
{
struct mmc_host *mmc;
struct dw_mci_slot *slot;
+ struct dw_mci_drv_data *drv_data = host-drv_data;
int ctrl_id, ret;
u8 bus_width;
@@ -1854,8 +1857,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
} else {
ctrl_id = to_platform_device(host-dev)-id;
}
- if (host-drv_data host-drv_data-caps)
- mmc-caps |= host-drv_data-caps[ctrl_id];
+ if (drv_data drv_data-caps)
+ mmc-caps |= drv_data-caps[ctrl_id];
if (host-pdata-caps2)
mmc-caps2 = host-pdata-caps2;
@@ -1867,10 +1870,10 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
else
bus_width = 1;
- if (host-drv_data-setup_bus) {
+ if (drv_data drv_data-setup_bus) {
struct device_node *slot_np;
slot_np = dw_mci_of_find_slot_node(host-dev, slot-id);
- ret = host-drv_data-setup_bus(host, slot_np, bus_width);
+ ret = drv_data-setup_bus(host, slot_np, bus_width);
if (ret)
goto err_setup_bus;
}
@@ -2035,6 +2038,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci
*host)
struct dw_mci_board *pdata;
struct device *dev = host-dev;
struct device_node *np = dev-of_node;
+ struct dw_mci_drv_data *drv_data = host-drv_data;
int idx, ret;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
@@ -2062,8 +2066,8 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci
*host)
of_property_read_u32(np, card-detect-delay, pdata-detect_delay_ms);
- if (host-drv_data-parse_dt) {
- ret = host-drv_data-parse_dt(host);
+ if (drv_data drv_data-parse_dt) {
+ ret = drv_data-parse_dt(host);
if (ret)
return ERR_PTR(ret);
}
@@ -2080,6 +2084,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci
*host)
int dw_mci_probe(struct dw_mci *host)
{
+ struct dw_mci_drv_data *drv_data = host-drv_data;
[PATCH] dmatest: terminate all ongoing transfers before submitting new one
The following error messages come if we have software LLP emulation enabled and enough threads running. modprobe dmatest iterations=40 [ 168.048601] dmatest: Started 1 threads using dma0chan0 [ 168.054546] dmatest: Started 1 threads using dma0chan1 [ 168.060441] dmatest: Started 1 threads using dma0chan2 [ 168.066333] dmatest: Started 1 threads using dma0chan3 [ 168.072250] dmatest: Started 1 threads using dma0chan4 [ 168.078144] dmatest: Started 1 threads using dma0chan5 [ 168.084057] dmatest: Started 1 threads using dma0chan6 [ 168.089948] dmatest: Started 1 threads using dma0chan7 [ 170.032962] dma0chan1-copy0: terminating after 40 tests, 0 failures (status 0) [ 170.041274] dma0chan0-copy0: terminating after 40 tests, 0 failures (status 0) [ 170.597559] dma0chan2-copy0: terminating after 40 tests, 0 failures (status 0) [ 171.085059] dma0chan7-copy0: #0: test timed out [ 171.839710] dma0chan3-copy0: terminating after 40 tests, 0 failures (status 0) [ 172.146071] dma0chan4-copy0: terminating after 40 tests, 0 failures (status 0) [ 172.220802] dma0chan7-copy0: #1: got completion callback, but status is 'in progress' [ 172.242049] dma0chan7-copy0: #2: got completion callback, but status is 'in progress' [ 172.281063] dma0chan7-copy0: #3: got completion callback, but status is 'in progress' [ 172.400866] dma0chan7-copy0: #4: got completion callback, but status is 'in progress' [ 172.471799] dma0chan7-copy0: #5: got completion callback, but status is 'in progress' [ 172.613996] dma0chan7-copy0: #6: got completion callback, but status is 'in progress' [ 172.670286] dma0chan7-copy0: #7: got completion callback, but status is 'in progress' [ 172.750763] dma0chan7-copy0: #8: got completion callback, but status is 'in progress' [ 172.777452] dma0chan5-copy0: terminating after 40 tests, 0 failures (status 0) [ 172.788740] dma0chan7-copy0: #9: got completion callback, but status is 'in progress' [ 172.845156] dma0chan7-copy0: #10: got completion callback, but status is 'in progress' [ 172.906593] dma0chan7-copy0: #11: got completion callback, but status is 'in progress' [ 173.181515] dma0chan6-copy0: terminating after 40 tests, 0 failures (status 0) [ 173.512838] dma0chan7-copy0: terminating after 40 tests, 12 failures (status 0) The patch fixes dmatest module to stop any ongoing transfer before submitting new one. Perhaps there is a better solution and driver logic needs to be fixed as well. After patch we will have modprobe dmatest iterations=50 [ 84.027375] dmatest: Started 1 threads using dma0chan0 [ 84.033282] dmatest: Started 1 threads using dma0chan1 [ 84.039182] dmatest: Started 1 threads using dma0chan2 [ 84.045089] dmatest: Started 1 threads using dma0chan3 [ 84.051003] dmatest: Started 1 threads using dma0chan4 [ 84.056916] dmatest: Started 1 threads using dma0chan5 [ 84.062828] dmatest: Started 1 threads using dma0chan6 [ 84.068714] dmatest: Started 1 threads using dma0chan7 [ 86.538284] dma0chan0-copy0: terminating after 50 tests, 0 failures (status 0) [ 86.842221] dma0chan1-copy0: terminating after 50 tests, 0 failures (status 0) [ 87.060460] dma0chan6-copy0: #0: test timed out [ 87.065614] dma0chan7-copy0: #0: test timed out [ 87.220321] dma0chan2-copy0: terminating after 50 tests, 0 failures (status 0) [ 88.595061] dma0chan3-copy0: terminating after 50 tests, 0 failures (status 0) [ 89.152170] dma0chan4-copy0: terminating after 50 tests, 0 failures (status 0) [ 89.955059] dma0chan5-copy0: terminating after 50 tests, 0 failures (status 0) [ 90.697073] dma0chan6-copy0: terminating after 50 tests, 1 failures (status 0) [ 90.893422] dma0chan7-copy0: terminating after 50 tests, 1 failures (status 0) Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- drivers/dma/dmatest.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index 24225f0..583f882 100644 --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -399,6 +399,9 @@ static int dmatest_func(void *data) continue; } + /* Stop any ongoing transfers here */ + chan-device-device_control(chan, DMA_TERMINATE_ALL, 0); + done.done = false; tx-callback = dmatest_callback; tx-callback_param = done; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/6 v3] gpio: Add sysfs support to block GPIO API
On 22:30 Mon 15 Oct , Linus Walleij wrote: I really request Grant to comment on this...too. On Mon, Oct 15, 2012 at 8:19 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Oct 15, 2012 at 08:07:02PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 21:11 Fri 12 Oct , Roland Stigge wrote: This patch adds sysfs support to the block GPIO API. Signed-off-by: Roland Stigge sti...@antcom.de --- Documentation/ABI/testing/sysfs-gpio |6 drivers/gpio/gpiolib.c | 226 ++- include/asm-generic/gpio.h | 11 + include/linux/gpio.h | 13 ++ 4 files changed, 254 insertions(+), 2 deletions(-) I really don't like this sysfs we need to add a specific device with ioctl Why? I don't like it either, basically because the GPIO sysfs is not entirely sound. Another patch that is circulating concerns edge triggers and similar, and it appear that some parts of the GPIO sysfs is for example redefining and exporting IRQchip properties like trigger edge in sysfs, while the settings of the irqchip actually used by the driver is not reflected in the other direction. So you can *set* these things by writing in the GPIO sysfs, but never trust what you *read* from there. And you can set what edges an IRQ will trigger on a certain GPIO, and the way to handle the IRQs from usespace is to poll on a value. This is not really documented but well ... Part of me just want to delete that, but I can't because it's now an ABI. The devices that the sysfs files are tied to are not real devices, instead the code look like this: whenever a gpio is exported to sysfs, the code calls (drivers/gpio/gpiolib.c): dev = device_create(gpio_class, desc-chip-dev, MKDEV(0, 0), desc, ioname ? ioname : gpio%u, gpio); Mock device just to get a sysfs opening. And once device for every GPIO with no hierarchical correspondence to anything in the system. The thing is that struct gpio_chip is not a device at all, it's something else. This inconsistency in the GPIO sysfs implementation make me fear adding new stuff to it. The other problems need fixing first. The reason an ioctl() IMO is better suited to do the job is that it can properly represent a multiple-value operation on several GPIOs at the same time in a struct, and it can conversely inform userspace about which GPIOs may be a block of signals that can be fired simultaneously instead of going to string parsing and binary values in sysfs which look like worse hacks to me. The last thing I'm a bit softer on though. Mainly I fear of this sysfs ABI growing into a beast. It was all merged prior to Grant becoming maintainer and me becoming co-maintainer of it, so this is legacy business. Sadly the main creator of this ABI is David Brownell who is not able to respond nor maintain it from where he is now. But we need to think hard about what we shall do with this particular piece of legacy. Some of the stuff was added by Daniel Glöckner so requesting advice from him. Daniel: are you interested in helping us fixing the GPIOlib sysfs ABI and kernel internals? I'm a bit afraid of it. My 0.02$ too Best Regards, J. -- 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 v9 12/12] x86, topology: Debug CPU00 hotplug
On 10/12/2012 09:39 PM, Fenghua Yu wrote:
From: Fenghua Yu fenghua...@intel.com
+config DEBUG_HOTPLUG_CPU0
+ def_bool n
+ prompt Debug CPU0 hotplug
+ depends on HOTPLUG_CPU EXPERIMENTAL
+ ---help---
+ Enabling this option offlines CPU0 (if CPU0 can be offlined) as
+ soon as possible and boots up userspace with CPU0 offlined. User
+ can online CPU0 back after boot time.
+
+ To debug CPU0 hotplug, you need to enable CPU0 offline/online
+ feature by either turning on CONFIG_BOOTPARAM_HOTPLUG_CPU0 during
+ compilation or giving cpu0_hotplug kernel parameter at boot.
+
+ If unuser, say N.
s/unuser/unsure
+#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
+/*
+ * This function offlines a CPU as early as possible and allows userspace to
+ * boot up without the CPU. The CPU can be onlined back by user after boot.
+ *
+ * This is only called for debugging CPU offline/online feature.
+ */
+int __ref _debug_hotplug_cpu(int cpu, int action)
+{
+ struct device *dev = get_cpu_device(cpu);
+ int ret;
+
+ if (!cpu_is_hotpluggable(cpu))
+ return -EINVAL;
+
+ cpu_hotplug_driver_lock();
+
+ switch (action) {
+ case 0:
+ ret = cpu_down(cpu);
+ if (!ret) {
+ pr_info(CPU %u is now offline\n, cpu);
+ kobject_uevent(dev-kobj, KOBJ_OFFLINE);
+ } else
+ pr_debug(Can't offline CPU%d.\n, cpu);
+ break;
+ case 1:
+ ret = cpu_up(cpu);
+ if (!ret)
+ kobject_uevent(dev-kobj, KOBJ_ONLINE);
+ else
+ pr_debug(Can't online CPU%d.\n, cpu);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ cpu_hotplug_driver_unlock();
+
+ return ret;
+}
+
+static int __init debug_hotplug_cpu(void)
+{
+ _debug_hotplug_cpu(0, 0);
+ return 0;
+}
+
+late_initcall_sync(debug_hotplug_cpu);
+#endif /* CONFIG_DEBUG_HOTPLUG_CPU0 */
+
int __ref arch_register_cpu(int num)
{
struct cpuinfo_x86 *c = cpu_data(num);
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index adde775..120cee1 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -21,6 +21,7 @@
#include asm/suspend.h
#include asm/debugreg.h
#include asm/fpu-internal.h /* pcntxt_mask */
+#include asm/cpu.h
#ifdef CONFIG_X86_32
static struct saved_context saved_context;
@@ -263,6 +264,43 @@ static int bsp_pm_callback(struct notifier_block *nb,
unsigned long action,
case PM_HIBERNATION_PREPARE:
ret = bsp_check();
break;
+#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
+ case PM_RESTORE_PREPARE:
+ /*
+ * When system resumes from hibernation, online CPU0 because
+ * 1. it's required for resume and
+ * 2. the CPU was online before hibernation
+ */
+ if (!cpu_online(0))
+ _debug_hotplug_cpu(0, 1);
This won't work. CPU hotplug is disabled by cpu_hotplug_pm_callback() during
PM_HIBERNATION_PREPARE and is enabled back only during PM_POST_HIBERNATION.
So calls to cpu_up() or cpu_down() will fail in the meantime.
Regards,
Srivatsa S. Bhat
+ break;
+ case PM_POST_RESTORE:
+ /*
+ * When a resume really happens, this code won't be called.
+ *
+ * This code is called only when user space hibernation software
+ * prepares for snapshot device during boot time. So we just
+ * call _debug_hotplug_cpu() to restore to CPU0's state prior to
+ * preparing the snapshot device.
+ *
+ * This works for normal boot case in our CPU0 hotplug debug
+ * mode, i.e. CPU0 is offline and user mode hibernation
+ * software initializes during boot time.
+ *
+ * If CPU0 is online and user application accesses snapshot
+ * device after boot time, this will offline CPU0 and user may
+ * see different CPU0 state before and after accessing
+ * the snapshot device. But hopefully this is not a case when
+ * user debugging CPU0 hotplug. Even if users hit this case,
+ * they can easily online CPU0 back.
+ *
+ * To simplify this debug code, we only consider normal boot
+ * case. Otherwise we need to remember CPU0's state and restore
+ * to that state and resolve racy conditions etc.
+ */
+ _debug_hotplug_cpu(0, 0);
+ break;
+#endif
default:
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
Re: [PATCH v4 10/14] memcg: use static branches when code not in use
(2012/10/12 16:47), Glauber Costa wrote:
On 10/11/2012 05:40 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:16, Glauber Costa wrote:
We can use static branches to patch the code in or out when not used.
Because the _ACTIVE bit on kmem_accounted is only set after the
increment is done, we guarantee that the root memcg will always be
selected for kmem charges until all call sites are patched (see
memcg_kmem_enabled). This guarantees that no mischarges are applied.
static branch decrement happens when the last reference count from the
kmem accounting in memcg dies. This will only happen when the charges
drop down to 0.
When that happen, we need to disable the static branch only on those
memcgs that enabled it. To achieve this, we would be forced to
complicate the code by keeping track of which memcgs were the ones
that actually enabled limits, and which ones got it from its parents.
It is a lot simpler just to do static_key_slow_inc() on every child
that is accounted.
[ v4: adapted this patch to the changes in kmem_accounted ]
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: Michal Hocko mho...@suse.cz
CC: Johannes Weiner han...@cmpxchg.org
CC: Suleiman Souhlal sulei...@google.com
Looks reasonable to me
Acked-by: Michal Hocko mho...@suse.cz
Just a little nit.
[...]
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 634c7b5..724a08b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -344,11 +344,15 @@ struct mem_cgroup {
/* internal only representation about the status of kmem accounting. */
enum {
KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */
+ KMEM_ACCOUNTED_ACTIVATED, /* static key enabled. */
KMEM_ACCOUNTED_DEAD, /* dead memcg, pending kmem charges */
};
-/* first bit */
-#define KMEM_ACCOUNTED_MASK 0x1
+/*
+ * first two bits. We account when limit is on, but only after
+ * call sites are patched
+ */
+#define KMEM_ACCOUNTED_MASK 0x3
The names are long but why not use KMEM_ACCOUNTED_ACTIVE*
#define KMEM_ACCOUNTED_MASK 1KMEM_ACCOUNTED_ACTIVE |
1KMEM_ACCOUNTED_ACTIVATED
Because the names are long! =)
please use long macros ;) it's not bad.
Anyway,
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.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 v4] slab: Ignore internal flags in cache creation
On 10/16/2012 04:47 AM, David Rientjes wrote: On Mon, 8 Oct 2012, David Rientjes wrote: diff --git a/mm/slab.h b/mm/slab.h index 7deeb44..4c35c17 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -45,6 +45,31 @@ static inline struct kmem_cache *__kmem_cache_alias(const char *name, size_t siz #endif +/* Legal flag mask for kmem_cache_create(), for various configurations */ +#define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | SLAB_PANIC | \ +SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS ) + +#if defined(CONFIG_DEBUG_SLAB) +#define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER) +#elif defined(CONFIG_SLUB_DEBUG) +#define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \ + SLAB_TRACE | SLAB_DEBUG_FREE) +#else +#define SLAB_DEBUG_FLAGS (0) +#endif + +#if defined(CONFIG_SLAB) +#define SLAB_CACHE_FLAGS (SLAB_MEMSPREAD | SLAB_NOLEAKTRACE | \ s/SLAB_MEMSPREAD/SLAB_MEM_SPREAD/ Did you have a v5 of this patch with the above fix? Yes, I sent it bundled in my kmemcg-slab series. I can send it separately as well, no problem. (Or we can merge the series!!! =p ) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] tty: pty - Move TIOCPKT handling into pty.c
Greg, Alan, what about this series? Is there anything else I should do? Other than resending it now the merge window is closed - I can't think of anything. Alan -- 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] dmatest: terminate all ongoing transfers before submitting new one
On Tue, Oct 16, 2012 at 2:15 PM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
The following error messages come if we have software LLP emulation enabled
and
enough threads running.
modprobe dmatest iterations=40
[ 168.048601] dmatest: Started 1 threads using dma0chan0
[ 168.054546] dmatest: Started 1 threads using dma0chan1
[ 168.060441] dmatest: Started 1 threads using dma0chan2
[ 168.066333] dmatest: Started 1 threads using dma0chan3
[ 168.072250] dmatest: Started 1 threads using dma0chan4
[ 168.078144] dmatest: Started 1 threads using dma0chan5
[ 168.084057] dmatest: Started 1 threads using dma0chan6
[ 168.089948] dmatest: Started 1 threads using dma0chan7
[ 170.032962] dma0chan1-copy0: terminating after 40 tests, 0 failures
(status 0)
[ 170.041274] dma0chan0-copy0: terminating after 40 tests, 0 failures
(status 0)
[ 170.597559] dma0chan2-copy0: terminating after 40 tests, 0 failures
(status 0)
[ 171.085059] dma0chan7-copy0: #0: test timed out
[ 171.839710] dma0chan3-copy0: terminating after 40 tests, 0 failures
(status 0)
[ 172.146071] dma0chan4-copy0: terminating after 40 tests, 0 failures
(status 0)
[ 172.220802] dma0chan7-copy0: #1: got completion callback, but status is
'in progress'
[ 172.242049] dma0chan7-copy0: #2: got completion callback, but status is
'in progress'
[ 172.281063] dma0chan7-copy0: #3: got completion callback, but status is
'in progress'
[ 172.400866] dma0chan7-copy0: #4: got completion callback, but status is
'in progress'
[ 172.471799] dma0chan7-copy0: #5: got completion callback, but status is
'in progress'
[ 172.613996] dma0chan7-copy0: #6: got completion callback, but status is
'in progress'
[ 172.670286] dma0chan7-copy0: #7: got completion callback, but status is
'in progress'
[ 172.750763] dma0chan7-copy0: #8: got completion callback, but status is
'in progress'
[ 172.777452] dma0chan5-copy0: terminating after 40 tests, 0 failures
(status 0)
[ 172.788740] dma0chan7-copy0: #9: got completion callback, but status is
'in progress'
[ 172.845156] dma0chan7-copy0: #10: got completion callback, but status is
'in progress'
[ 172.906593] dma0chan7-copy0: #11: got completion callback, but status is
'in progress'
[ 173.181515] dma0chan6-copy0: terminating after 40 tests, 0 failures
(status 0)
[ 173.512838] dma0chan7-copy0: terminating after 40 tests, 12 failures
(status 0)
The patch fixes dmatest module to stop any ongoing transfer before submitting
new one. Perhaps there is a better solution and driver logic needs to be fixed
as well.
After patch we will have
modprobe dmatest iterations=50
[ 84.027375] dmatest: Started 1 threads using dma0chan0
[ 84.033282] dmatest: Started 1 threads using dma0chan1
[ 84.039182] dmatest: Started 1 threads using dma0chan2
[ 84.045089] dmatest: Started 1 threads using dma0chan3
[ 84.051003] dmatest: Started 1 threads using dma0chan4
[ 84.056916] dmatest: Started 1 threads using dma0chan5
[ 84.062828] dmatest: Started 1 threads using dma0chan6
[ 84.068714] dmatest: Started 1 threads using dma0chan7
[ 86.538284] dma0chan0-copy0: terminating after 50 tests, 0 failures
(status 0)
[ 86.842221] dma0chan1-copy0: terminating after 50 tests, 0 failures
(status 0)
[ 87.060460] dma0chan6-copy0: #0: test timed out
[ 87.065614] dma0chan7-copy0: #0: test timed out
[ 87.220321] dma0chan2-copy0: terminating after 50 tests, 0 failures
(status 0)
[ 88.595061] dma0chan3-copy0: terminating after 50 tests, 0 failures
(status 0)
[ 89.152170] dma0chan4-copy0: terminating after 50 tests, 0 failures
(status 0)
[ 89.955059] dma0chan5-copy0: terminating after 50 tests, 0 failures
(status 0)
[ 90.697073] dma0chan6-copy0: terminating after 50 tests, 1 failures
(status 0)
[ 90.893422] dma0chan7-copy0: terminating after 50 tests, 1 failures
(status 0)
You still have failures. :(
Can you try with a large timeout value for the module.
We must get to the root cause of these failures. There may be something more
serious which is getting hidden due to this call to terminate().
Unless there is a issue with software emulation of LLP, the only difference with
s/w emulation is the transfers become slow.
Also, the proposed solution might hide some other important errors. We may need
to terminate transfers when we found that an error is there in last transfers:
if (!done.done) {
/*
* We're leaving the timed out dma operation with
* dangling pointer to done_wait. To make this
* correct, we'll need to allocate wait_done for
* each test iteration and perform who's gonna
* free it this time? dancing. For now, just
* leave it dangling.
*/
pr_warning(%s: #%u: test
Re: [patch 1/3] tty: pty - Move TIOCPKT handling into pty.c
On Tue, Oct 16, 2012 at 09:58:22AM +0100, Alan Cox wrote: Greg, Alan, what about this series? Is there anything else I should do? Other than resending it now the merge window is closed - I can't think of anything. OK, thanks, I'll resend. -- 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: [Linaro-mm-sig] [RFC 0/2] DMA-mapping IOMMU - physically contiguous allocations
On Tue, Oct 16, 2012 at 09:04:34AM +0300, Hiroshi Doyu wrote: In addition to those contiguous/discontiguous page allocation, is there any way to _import_ anonymous pages allocated by a process to be used in dma-mapping API later? I'm considering the following scenario, an user process allocates a buffer by malloc() in advance, and then it asks some driver to convert that buffer into IOMMU'able/DMA'able ones later. In this case, pages are discouguous and even they may not be yet allocated at malloc()/mmap(). That situation is covered. It's the streaming API you're wanting for that. dma_map_sg() - but you may need additional cache handling via flush_dcache_page() to ensure that your code is safe for all CPU cache architectures. Remember that pages allocated into userspace will be cacheable, so a cache flush is required before they can be DMA'd. Hence the streaming API. -- 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/
Low-jitter kernel benchmark.
http://www.phoronix.com/scan.php?page=news_itempx=MTIwNzM While Phoronix usually miss the point of these configs, these benchmarks still show that low-jitter on the desktop, does not affect desktop performance negatively. Only if you are running Apache, on a server, you`d want a different config. And then not even X, so this is not related to desktop. So this should weigh heavily with any sane desktop-distro maker, for his config. Ubuntu configgers have no valid argument about throughput anymore, for instance. Peace Be With You. -- 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] uprobes tracer: Add stack/memory/retval access support
Event arguments except @SYM are supported. They are @ADDR,
$stack, $stackN, $retval, and offs(arguments).
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Hyeoncheol Lee hyc@gmail.com
---
kernel/trace/trace_kprobe.c |6 +-
kernel/trace/trace_probe.c | 162 ++-
kernel/trace/trace_probe.h |6 +-
kernel/trace/trace_uprobe.c |6 +-
4 files changed, 124 insertions(+), 56 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 1a21170..60046d3 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -683,7 +683,7 @@ static __kprobes int __get_data_size(struct trace_probe *tp,
for (i = 0; i tp-nr_args; i++)
if (unlikely(tp-args[i].fetch_size.fn)) {
- call_fetch(tp-args[i].fetch_size, regs, len);
+ call_fetch(tp-args[i].fetch_size, regs, len, true);
ret += len;
}
@@ -708,7 +708,7 @@ static __kprobes void store_trace_args(int ent_size, struct
trace_probe *tp,
dl = (u32 *)(data + tp-args[i].offset);
*dl = make_data_rloc(maxlen, end - tp-args[i].offset);
/* Then try to fetch string or dynamic array data */
- call_fetch(tp-args[i].fetch, regs, dl);
+ call_fetch(tp-args[i].fetch, regs, dl, true);
/* Reduce maximum length */
end += get_rloc_len(*dl);
maxlen -= get_rloc_len(*dl);
@@ -718,7 +718,7 @@ static __kprobes void store_trace_args(int ent_size, struct
trace_probe *tp,
} else
/* Just fetching data normally */
call_fetch(tp-args[i].fetch, regs,
- data + tp-args[i].offset);
+ data + tp-args[i].offset, true);
}
}
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index daa9980..955c3fa 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -112,7 +112,8 @@ DEFINE_FETCH_##method(u64)
/* Data fetch function templates */
#define DEFINE_FETCH_reg(type) \
static __kprobes void FETCH_FUNC_NAME(reg, type)(struct pt_regs *regs, \
- void *offset, void *dest) \
+ void *offset, void *dest, \
+ bool kprobe)\
{ \
*(type *)dest = (type)regs_get_register(regs, \
(unsigned int)((unsigned long)offset)); \
@@ -122,12 +123,49 @@ DEFINE_BASIC_FETCH_FUNCS(reg)
#define fetch_reg_string NULL
#define fetch_reg_string_size NULL
+#ifdef CONFIG_STACK_GROWSUP
+#defineWITHIN_USER_STACK(vma, addr, n) \
+ ( \
+ addr -= n, \
+ (vma)-vm_start = (unsigned long)(addr)\
+ )
+#else
+#defineWITHIN_USER_STACK(vma, addr, n) \
+ ( \
+ addr += n, \
+ (vma)-vm_end = (unsigned long)(addr) \
+ )
+#endif
+
+static unsigned long regs_get_user_stack_nth(struct pt_regs *regs,
+unsigned int n)
+{
+ struct vm_area_struct *vma;
+ unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+ unsigned long ret = 0;
+
+ down_read(current-mm-mmap_sem);
+ vma = find_vma(current-mm, (unsigned long)addr);
+ if (vma vma-vm_start = (unsigned long)addr) {
+ if (WITHIN_USER_STACK(vma, addr, n))
+ if (get_user(ret, addr) != 0)
+ ret = 0;
+ }
+ up_read(current-mm-mmap_sem);
+ return ret;
+}
+
#define DEFINE_FETCH_stack(type) \
static __kprobes void FETCH_FUNC_NAME(stack, type)(struct pt_regs *regs,\
- void *offset, void *dest) \
+ void *offset, void *dest, \
+ bool kprobe) \
{ \
- *(type *)dest = (type)regs_get_kernel_stack_nth(regs, \
+ if (kprobe) \
+ *(type *)dest = (type)regs_get_kernel_stack_nth(regs, \
Re: Strange crash on Dell R720xd
On Mon, Oct 15, 2012 at 09:42:58PM +0200, Laurent CARON wrote: Hi, I'm currently replacing an old system (HP DL 380 G5) by new dell R720xd. On those new boxes I did configure the H310 controler as plain JBOD. Those boxes appear to crash more often than not (from 5 mins to a couple of hours). I have the impression those crashes appear under heavy IO. The setup consists of a few md RAID arrays serving as underlying devices for either filesystem, or drbd (plus lvm on top). I managed to catch a trace over netconsole: [ cut here ] kernel BUG at crypto/async_tx/async_tx.c:174! That's: BUG_ON(async_tx_test_ack(depend_tx) || txd_next(depend_tx) || txd_parent(tx)); but probably the b0rkage happens up the stack. And this __raid_run_ops is probably starting the whole TX so maybe we should add linux-r...@vger.kernel.org to CC. Added. invalid opcode: [#1] SMP Modules linked in: drbd lru_cache netconsole iptable_filter ip_tables ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue bonding ipv6 btrfs ioatdma lpc_ich sb_edac dca mfd_core CPU 0 Pid: 12580, comm: kworker/u:2 Not tainted 3.6.2-r510-r720xd #1 Dell Inc. PowerEdge R720xd What is that r510 thing in the kernel version? You have your patches ontop? If yes, please try reproducing this with a kernel.org kernel without anything else ontop. Also, it might be worth trying plain 3.6 to rule out a regression introduced in the stable 3.6 series. (leaving in the rest for reference) RIP: 0010:[8130f9ab] [8130f9ab] async_tx_submit+0x29/0xab RSP: 0018:88100940fb30 EFLAGS: 00010202 RAX: 88100b30aeb0 RBX: 88080b5cf390 RCX: 0029 RDX: 88100940fd00 RSI: 88080b5cf390 RDI: 880809ad0818 RBP: 8808054a7d90 R08: 88080b5cf900 R09: 0001 R10: 1000 R11: 0001 R12: 88100940fd00 R13: 0002 R14: 880809ad0638 R15: 880809ad0818 FS: () GS:88080fc0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: ff600400 CR3: 000e4055f000 CR4: 000407f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process kworker/u:2 (pid: 12580, threadinfo 88100940e000, task 880804850630) Stack: 88100940fd00 88100940fc40 0101 8131044b 0001 0246 0201 a0073a00 8808054a7d90 8808054a7690 88100940fc40 88080bf9e668 Call Trace: [8131044b] ? do_async_gen_syndrome+0x2f3/0x320 [a0073a00] ? ioat2_tx_submit_unlock+0xac/0xb3 [ioatdma] [815e6820] ? ops_complete_compute+0x7b/0x7b [81310540] ? async_gen_syndrome+0xc8/0x1d6 [815e8b9a] ? __raid_run_ops+0x9e7/0xb5a [810848f0] ? select_task_rq_fair+0x487/0x74b [815e6820] ? ops_complete_compute+0x7b/0x7b [8107e40b] ? __wake_up+0x35/0x46 [8107ca2a] ? async_schedule+0x12/0x12 [815e8d3f] ? async_run_ops+0x32/0x3e [8107cace] ? async_run_entry_fn+0xa4/0x17e [8107ca2a] ? async_schedule+0x12/0x12 [81071cf8] ? process_one_work+0x259/0x381 [81072312] ? worker_thread+0x2ad/0x3e3 [81082e50] ? try_to_wake_up+0x1fc/0x20c [81072065] ? manage_workers+0x245/0x245 [81072065] ? manage_workers+0x245/0x245 [8107746a] ? kthread+0x81/0x89 [81791034] ? kernel_thread_helper+0x4/0x10 [810773e9] ? kthread_freezable_should_stop+0x4e/0x4e [81791030] ? gs_change+0xb/0xb Code: 5b c3 41 54 49 89 d4 55 53 48 89 f3 48 8b 6a 08 48 8b 42 10 48 85 ed 48 89 46 20 48 8b 42 18 48 89 46 28 74 5c f6 45 04 02 74 72 0f 0b eb fe 48 8b 02 48 8b 48 28 80 e1 40 74 24 31 f6 48 89 d7 RIP [8130f9ab] async_tx_submit+0x29/0xab RSP 88100940fb30 ---[ end trace 64fb561d16a3b535 ]--- Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 5 seconds.. Do any of you guys have a clue about it ? Thanks Laurent PS: The very same kernel doesn't cause any trouble on R510 hardware. -- 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/ -- Regards/Gruss, Boris. -- 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 5/5] efivarfs: efivarfs_fill_super() ensure we clean up correctly on error
Hi Andy,
If we break out of the loop on the second (and onwards) iteration,
won't we still have the other inodes and dentries remaining
allocated?
As we calling this from the mount_single() wrapper:
return mount_single(fs_type, flags, data, efivarfs_fill_super);
which does this:
struct dentry *mount_single(struct file_system_type *fs_type,
int flags, void *data,
int (*fill_super)(struct super_block *, void *, int))
{
[...]
error = fill_super(s, data, flags MS_SILENT ? 1 : 0);
if (error) {
deactivate_locked_super(s);
return ERR_PTR(error);
}
[...]
I am expecting us to get called back via deactivate_locked_super(),
which calls sb-kill_sb() which is:
static void efivarfs_kill_sb(struct super_block *sb)
{
kill_litter_super(sb);
efivarfs_sb = NULL;
}
Which I believe will clean them up.
Awesome, thanks for that. Looks good to me.
Acked-by: Jeremy Kerr jeremy.k...@canonical.com
Cheers,
Jeremy Kerr
--
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
Re: [PATCH] avr32: fix build error in atstk1006_defconfig
Around Tue 16 Oct 2012 15:19:27 +0800 or thereabout, Josh Wu wrote: fixed the following compile error when use avr32 atstk1006_defconfig: drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location': drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function 'writel_relaxed' which was introduced by commit 1c7b874d33b463 (mtd: at91: atmel_nand: add Programmable Multibit ECC controller support). The PMECC for nand flash code uses writel_relaxed(). But in avr32, there is no macro writel_relaxed defined. This patch add writex_relaxed macro definitions. Signed-off-by: Josh Wu josh...@atmel.com --- arch/avr32/include/asm/io.h |4 1 file changed, 4 insertions(+) diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h index cf60d0a..fc6483f 100644 --- a/arch/avr32/include/asm/io.h +++ b/arch/avr32/include/asm/io.h @@ -165,6 +165,10 @@ BUILDIO_IOPORT(l, u32) #define readw_be __raw_readw #define readl_be __raw_readl +#define writeb_relaxed writeb +#define writew_relaxed writew +#define writel_relaxed writel + I'm wondering if they should be something similar to SH arch: #define writeb_relaxed(v,c) ((void)__raw_writeb((__force u8)ioswabb(v),c)) What is the intention behind the macro? Which restriction is relaxed? #define writeb_be__raw_writeb #define writew_be__raw_writew #define writel_be__raw_writel -- mvh Hans-Christian Egtvedt -- 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] loop: Limit the number of requests in the bio list
Currently there is not limitation of number of requests in the loop bio
list. This can lead into some nasty situations when the caller spawns
tons of bio requests taking huge amount of memory. This is even more
obvious with discard where blkdev_issue_discard() will submit all bios
for the range and wait for them to finish afterwards. On really big loop
devices and slow backing file system this can lead to OOM situation as
reported by Dave Chinner.
With this patch we will wait in loop_make_request() if the number of
bios in the loop bio list would exceed 'nr_requests' number of requests.
We'll wake up the process as we process the bios form the list. Some
threshold hysteresis is in place to avoid high frequency oscillation.
Signed-off-by: Lukas Czerner lczer...@redhat.com
Reported-by: Dave Chinner dchin...@redhat.com
---
v2: add threshold hysteresis
drivers/block/loop.c | 16
include/linux/loop.h |3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index e9d594f..0589976 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -463,6 +463,7 @@ out:
*/
static void loop_add_bio(struct loop_device *lo, struct bio *bio)
{
+ lo-lo_bio_count++;
bio_list_add(lo-lo_bio_list, bio);
}
@@ -471,6 +472,7 @@ static void loop_add_bio(struct loop_device *lo, struct bio
*bio)
*/
static struct bio *loop_get_bio(struct loop_device *lo)
{
+ lo-lo_bio_count--;
return bio_list_pop(lo-lo_bio_list);
}
@@ -489,6 +491,14 @@ static void loop_make_request(struct request_queue *q,
struct bio *old_bio)
goto out;
if (unlikely(rw == WRITE (lo-lo_flags LO_FLAGS_READ_ONLY)))
goto out;
+ if (lo-lo_bio_count = lo-lo_queue-nr_requests) {
+ unsigned int nr;
+ spin_unlock_irq(lo-lo_lock);
+ nr = lo-lo_queue-nr_requests - (lo-lo_queue-nr_requests/8);
+ wait_event_interruptible(lo-lo_req_wait,
+lo-lo_bio_count nr);
+ spin_lock_irq(lo-lo_lock);
+ }
loop_add_bio(lo, old_bio);
wake_up(lo-lo_event);
spin_unlock_irq(lo-lo_lock);
@@ -532,6 +542,7 @@ static inline void loop_handle_bio(struct loop_device *lo,
struct bio *bio)
static int loop_thread(void *data)
{
struct loop_device *lo = data;
+ unsigned int nr;
struct bio *bio;
set_user_nice(current, -20);
@@ -546,6 +557,9 @@ static int loop_thread(void *data)
continue;
spin_lock_irq(lo-lo_lock);
bio = loop_get_bio(lo);
+ nr = lo-lo_queue-nr_requests - (lo-lo_queue-nr_requests/8);
+ if (lo-lo_bio_count nr)
+ wake_up(lo-lo_req_wait);
spin_unlock_irq(lo-lo_lock);
BUG_ON(!bio);
@@ -873,6 +887,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode,
lo-transfer = transfer_none;
lo-ioctl = NULL;
lo-lo_sizelimit = 0;
+ lo-lo_bio_count = 0;
lo-old_gfp_mask = mapping_gfp_mask(mapping);
mapping_set_gfp_mask(mapping, lo-old_gfp_mask ~(__GFP_IO|__GFP_FS));
@@ -1660,6 +1675,7 @@ static int loop_add(struct loop_device **l, int i)
lo-lo_number = i;
lo-lo_thread = NULL;
init_waitqueue_head(lo-lo_event);
+ init_waitqueue_head(lo-lo_req_wait);
spin_lock_init(lo-lo_lock);
disk-major = LOOP_MAJOR;
disk-first_minor = i part_shift;
diff --git a/include/linux/loop.h b/include/linux/loop.h
index 9635116..4ba4789 100644
--- a/include/linux/loop.h
+++ b/include/linux/loop.h
@@ -57,10 +57,13 @@ struct loop_device {
spinlock_t lo_lock;
struct bio_list lo_bio_list;
+ unsigned intlo_bio_count;
int lo_state;
struct mutexlo_ctl_mutex;
struct task_struct *lo_thread;
wait_queue_head_t lo_event;
+ /* wait queue for incoming requests */
+ wait_queue_head_t lo_req_wait;
struct request_queue*lo_queue;
struct gendisk *lo_disk;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/5] irq_work: Move irq_work_raise() declaration/default definition to arch headers
On Tuesday 16 October 2012, Mark Brown wrote: On Tue, Oct 16, 2012 at 12:18:05AM +0200, Frederic Weisbecker wrote: I came up with stuff for it, though it needed prettyfying. This seems to do the trick: (It's the diff result of ln -s asm-generic include/asm) Unfortunately, this is not enough, it breaks make headers_install, which now needs to decide whether to install a header that is present in the architecture directory, or to copy one from the asm-generic directory otherwise. On the plus side, the symlink breaks checking into CVS and cross-building from operating systems that don't support posix file systems, so we might want to do this anyway. ;-) That'd work, but I assume there is some reason why we've got this system of explicitly adding each file. It's not like cpp can test for the presence of include files. If we can't figure out why we're not doing this I'd propose we start. We discussed renaming asm-generic to asm before, but some people objected to the use of #include_next. There is a smaller problem with opening the asm/*.h namespace to header files that are not relevant for architctures, so I'd prefer to have a well-defined list of headers that are implicitly shared, but it's not a technical argument. Arnd -- 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/
