Re: [PATCH 00/11] ASoC: OMAP: Convert to use dmaengine
On 09/13/2012 11:11 AM, Mark Brown wrote: > On Wed, Sep 12, 2012 at 02:46:56PM +0300, Peter Ujfalusi wrote: >> Hello, >> >> This series will switch the OMAP audio to use dmaengine. >> The final patch which does the switch was based on Russell King's earlier >> patch. > > I'm fine with this from the ASoC side but it sounds like you're going to > respin anyway. Are the earlier bits of the series safe to apply without > the last bit, it seems like that's the only bit that really needs a > respin so we may as well go ahead and apply the earlier bits now? Yes, I'm preparing the second series (adding the pause/resume support). Patch 2-10 is to prepare the OMAP audio drivers for the dmaengine conversion they can be applied earlier IMHO. I can in turn can send only dmaengine related patches in v2 (patch 1 and 10 from this series and additional ones). Anyways I need some time to figure out how to add back the support for SNDRV_PCM_INFO_NO_PERIOD_WAKEUP. Either way is good for me. -- Péter -- 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 9/9] drivers/isdn/gigaset/common.c: Remove useless kfree
On Thu, Sep 13, 2012 at 09:31:45AM +0100, David Laight wrote: > > Remove useless kfree() and clean up code related to the removal. > ... > > diff --git a/drivers/isdn/gigaset/common.c b/drivers/isdn/gigaset/common.c > > index aa41485..30a6b17 100644 > > --- a/drivers/isdn/gigaset/common.c > > +++ b/drivers/isdn/gigaset/common.c > > @@ -1123,7 +1123,6 @@ struct gigaset_driver *gigaset_initdriver(unsigned > > minor, unsigned minors, > > return drv; > > > > error: > > - kfree(drv->cs); > > kfree(drv); > > return NULL; > > } > > > > Seems to me that (assuming kfree(NULL) is ok) the kfree() > is best left in - just in case some other error path is > added after drv->cs is assigned. > Better safe than a memory leak. No. Delete vestigial code. There are all kinds of no-ops we could add to the unwind bits of code if we wanted to so why is "drv->cs" better than anything else. First of all, no one is going to change the ISDN code to add an allocation, but if they did then they have to make sure they don't leak memory. That's how it always works. They can't just assume that there is going to be a forgotten kfree() hanging off to the side which is going to take care of it. regards, dan carpenter -- 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 09/12] thp: introduce khugepaged_prealloc_page and khugepaged_alloc_page
On 09/13/2012 02:27 PM, Hugh Dickins wrote: > On Wed, 12 Sep 2012, Xiao Guangrong wrote: >> On 09/12/2012 10:03 AM, Hugh Dickins wrote: >> >>> What brought me to look at it was hitting "BUG at mm/huge_memory.c:1842!" >>> running tmpfs kbuild swapping load (with memcg's memory.limit_in_bytes >>> forcing out to swap), while I happened to have CONFIG_NUMA=y. >>> >>> That's the VM_BUG_ON(*hpage) on entry to khugepaged_alloc_page(). >> >>> >>> So maybe 9/12 is just obscuring what was already a BUG, either earlier >>> in your series or elsewhere in mmotm (I've never seen it on 3.6-rc or >>> earlier releases, nor without CONFIG_NUMA). I've not spent any time >>> looking for it, maybe it's obvious - can you spot and fix it? >> >> Hugh, >> >> I think i have already found the reason, > > Great, thank you. > >> if i am correct, the bug was existing before my patch. > > Before your patchset? Are you sure of that? No. :) I have told Andrew that the fix patch need not back port in 0/3. Sorry again for my mistake. -- 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 9/9] drivers/isdn/gigaset/common.c: Remove useless kfree
> Seems to me that (assuming kfree(NULL) is ok) the kfree() > is best left in - just in case some other error path is > added after drv->cs is assigned. > Better safe than a memory leak. I'm not sure if I got your point. Now the label "error:" is only reached if drv->cs is NULL. There is not other way to move to error: unless drv->cs is NULL. Why wouldn't be safe to remove the kfree(drv->cs) when drv->cs is NULL? -- Peter -- 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] sched: unify the check on atomic sleeping in __might_sleep() and schedule_bug()
On 09/03/2012 10:16 AM, Michael Wang wrote: > On 08/22/2012 10:40 AM, Michael Wang wrote: >> From: Michael Wang >> >> Fengguang Wu has reported the bug: >> >> [0.043953] BUG: scheduling while atomic: swapper/0/1/0x1002 >> [0.044017] no locks held by swapper/0/1. >> [0.044692] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc1-00420-gb7aebb9 >> #34 >> [0.045861] Call Trace: >> [0.048071] [] __schedule_bug+0x5e/0x70 >> [0.048890] [] __schedule+0x91/0xb10 >> [0.049660] [] ? vsnprintf+0x33a/0x450 >> [0.050444] [] ? lg_local_lock+0x6/0x70 >> [0.051256] [] ? wait_for_xmitr+0x31/0x90 >> [0.052019] [] ? do_raw_spin_unlock+0xa5/0xf0 >> [0.052903] [] ? _raw_spin_unlock+0x22/0x30 >> [0.053759] [] ? up+0x1b/0x70 >> [0.054421] [] __cond_resched+0x1b/0x30 >> [0.055228] [] _cond_resched+0x45/0x50 >> [0.056020] [] mutex_lock_nested+0x28/0x370 >> [0.056884] [] ? console_unlock+0x3a2/0x4e0 >> [0.057741] [] __irq_alloc_descs+0x39/0x1c0 >> [0.058589] [] io_apic_setup_irq_pin+0x2c/0x310 >> [0.060042] [] setup_IO_APIC+0x101/0x744 >> [0.060878] [] ? clear_IO_APIC+0x31/0x50 >> [0.061695] [] native_smp_prepare_cpus+0x538/0x680 >> [0.062644] [] ? do_one_initcall+0x12c/0x12c >> [0.063517] [] ? do_one_initcall+0x12c/0x12c >> [0.064016] [] kernel_init+0x4b/0x17f >> [0.064790] [] ? do_one_initcall+0x12c/0x12c >> [0.065660] [] kernel_thread_helper+0x6/0x10 >> >> It was caused by that: >> >> native_smp_prepare_cpus() >> preempt_disable() //preempt_count++ >> mutex_lock()//in __irq_alloc_descs >> __might_sleep() //system is booting, avoid check >> might_resched() >> __schedule() >> preempt_disable() //preempt_count++ >> schedule_bug() //preempt_count > 1, report bug >> >> The __might_sleep() avoid check on atomic sleeping until the system booted >> while the schedule_bug() doesn't, it's the reason for the bug. >> >> This patch will add one additional check in schedule_bug() to avoid check >> until the system booted, so the check on atomic sleeping will be unified. > > Could I get some comments on this patch? Oh, I just realised I'm using the wrong address... So could I get some comments on the patch? Regards, Michael Wang > > Regards, > Michael Wang >> >> Signed-off-by: Michael Wang >> Tested-by: Fengguang Wu >> --- >> kernel/sched/core.c |3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 4376c9f..3396c33 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -3321,7 +3321,8 @@ static inline void schedule_debug(struct task_struct >> *prev) >> * schedule() atomically, we ignore that path for now. >> * Otherwise, whine if we are scheduling when we should not be. >> */ >> -if (unlikely(in_atomic_preempt_off() && !prev->exit_state)) >> +if (unlikely(in_atomic_preempt_off() && !prev->exit_state >> +&& system_state == SYSTEM_RUNNING)) >> __schedule_bug(prev); >> rcu_sleep_check(); >> >> > -- 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: issues with unknown/new alias [retraction]
On 13/09/12 09:57, Christoph Jung wrote: Am 13.09.2012 10:49, schrieb Alan Jenkins: On 13/09/12 08:25, Christoph Jung wrote: Hello, I am from the company "Code Mercenaries GmbH" from Germany. We have some USB HID devices wich work with Linux. Since kernel version 2.6 our default products will be included in the kernel. Devicedetails VendorID: 0x07C0 ProductIDs: 0x1500, 0x1501, 0x1511, 0x1512, 0x1503 Devicename: iowarrior Now we have some new custom product IDs but this two new devices get no node in dev/usb/ , but I can find the with "lsusb". If I run "modinfo iowarrior" there will be 5 alias (with the default pIDs) . The two new pIDs are: 0x158A, 0x158B I have not much experiance with linux (I work with Ubuntu 12.04). What have be done to get the device nodes to work with them? Have I add some rules? Or have I edit the iowarrior.ko? Argh, sorry, I misread your email and went off on one. You will indeed need to "edit iowarrior.ko". I.e. change the C source code to include the new pIDs, recompile, test, get patches merged into the mainline kernel etc :). It's also possible to test new devices with an old driver, i.e. before you modify it. Possible instructions: http://www.ha19.no/usb/ Alan Ah ok but where will I find the sourcecode for iowarrior.ko ? I have no idea about compiling, patching in linux Christoph The kernel is all one big tree. The file you're looking for is drivers/usb/misc/iowarrior.c. (Preview at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/usb/misc/iowarrior.c). The change you're talking about should be fairly straightforward - just look for the existing ids. Step 1 for me has always been to compile a whole kernel. Unfortunately that's a bit of learning curve. I'm not sure which resources to recommend. 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: i2c:clk: preparation for switch to common clock framework
On Thu, Aug 30, 2012 at 06:10:36PM -, m-kariche...@ti.com wrote: > As a first step towards migrating davinci platforms to use common clock > framework, replace all instances of clk_enable() with clk_prepare_enable() > and clk_disable() with clk_disable_unprepare(). Until the platform is > switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just > adds a might_sleep() call and would work without any issues. > > This will make it easy later to switch to common clk based implementation > of clk driver from DaVinci specific driver. > > Signed-off-by: Murali Karicheri Subject had "i2c:clk" where "i2c: davinci" would be more precise. Fixed that and pushed to -next. Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: xt_nat_init: BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
Fengguang Wu wrote: > Hi Patrick, > > This happens in today's linux-next tree and is pretty reproducible. > [1.834544] nf_conntrack version 0.5.0 (1786 buckets, 7144 max) > [1.835406] ctnetlink v0.93: registering with nfnetlink. > [1.836202] BUG: unable to handle kernel NULL pointer dereference at > 00e0 > [1.837539] IP: [] mutex_lock_interruptible+0x23/0x70 Should be fixed by commit 00545bec9412d130c77f72a08d6c8b6ad21d4a1e Author: Pablo Neira Ayuso Subject: netfilter: fix crash during boot if NAT has been compiled built-in But seems its not yet in net-next. Pablo? -- 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]URL is unavailable
On Wed, Sep 12, 2012 at 09:13:50PM -0400, Konstantin Ryabitsev wrote: > On 12/09/12 12:03 PM, Borislav Petkov wrote: > > Dear KORG admins, what are the chances of userweb.kernel.org coming back > > online? > > Hello: > > There is no ETA on that service being available. It may not ever come > back, at least not in the way it was before. > > That being said, I'm perfectly willing to set up a few redirects in > place if broken URLs are causing problems. I just cannot use any of the > existing backups of userweb data, as it is under a strict "do not use, > ever" quarantine. > > If someone can provide me with trusted backups of that data, I will > provide hosting and redirects to unbreak the URLs. My memory is hazy on this, but after the move, what's the policy on enabling users.kernel.org or userweb.kernel org or some other user web serving thing? I vaguely remember that we don't want to do this anymore but I'm not sure. In any case, if we do, it would probably be better to have a whole different machine for such stuff and let users upload their stuff again without touching the old backups at all... Hmm. -- 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: xt_nat_init: BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
On Thu, 2012-09-13 at 17:16 +0800, Fengguang Wu wrote: > Hi Patrick, > > This happens in today's linux-next tree and is pretty reproducible. > Bisection has been started. > > [1.834544] nf_conntrack version 0.5.0 (1786 buckets, 7144 max) > [1.835406] ctnetlink v0.93: registering with nfnetlink. > [1.836202] BUG: unable to handle kernel NULL pointer dereference at > 00e0 > [1.837539] IP: [] mutex_lock_interruptible+0x23/0x70 > [1.838493] PGD 0 > [1.838983] Oops: 0002 [#1] PREEMPT SMP > [1.839786] CPU 0 > [1.840050] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc5-07686-gdbf978b > #58 Bochs Bochs > [1.840172] RIP: 0010:[] [] > mutex_lock_interruptible+0x23/0x70 > [1.840172] RSP: 0018:88000d845e40 EFLAGS: 00010202 > [1.840172] RAX: 0246 RBX: 00e0 RCX: > 88000d848000 > [1.840172] RDX: RSI: 0175 RDI: > 81e6bc88 > [1.840172] RBP: 88000d845e50 R08: 821bd170 R09: > > [1.840172] R10: R11: dead00200200 R12: > > [1.840172] R13: 0004 R14: 821c1ce0 R15: > > [1.840172] FS: () GS:88000de0() > knlGS: > [1.840172] CS: 0010 DS: ES: CR0: 8005003b > [1.840172] CR2: 00e0 CR3: 0200b000 CR4: > 06f0 > [1.840172] DR0: DR1: DR2: > > [1.840172] DR3: DR6: 0ff0 DR7: > 0400 > [1.840172] Process swapper/0 (pid: 1, threadinfo 88000d844000, task > 88000d848000) > [1.840172] Stack: > [1.840172] 00e0 821c1ce0 88000d845e80 > 8187c204 > [1.840172] 820f7ea0 > 821c1ce0 > [1.840172] 88000d845ec0 8187c334 88000d845eb0 > > [1.840172] Call Trace: > [1.840172] [] xt_register_target+0x34/0x70 > [1.840172] [] xt_register_targets+0x34/0x70 > [1.840172] [] ? nf_nat_init+0x12c/0x12c > [1.840172] [] xt_nat_init+0x15/0x17 > [1.840172] [] do_one_initcall+0x7a/0x134 > [1.840172] [] kernel_init+0x103/0x187 > [1.864014] [] ? do_early_param+0x8d/0x8d > [1.864014] [] kernel_thread_helper+0x4/0x10 > [1.864014] [] ? do_one_initcall+0x134/0x134 > [1.864014] [] ? gs_change+0x13/0x13 > [1.864014] Code: 8b 65 f8 c9 c3 0f 1f 00 55 31 d2 be 75 01 00 00 48 89 e5 > 41 54 41 bc ff ff ff ff 53 48 89 fb 48 c7 c7 88 bc e6 81 e8 dd 73 6e ff > 44 0f c1 23 41 83 ec 01 31 d2 48 c7 c7 c8 b7 13 82 41 c1 ec > [1.864014] RIP [] mutex_lock_interruptible+0x23/0x70 > [1.864014] RSP > [1.864014] CR2: 00e0 > > Thanks, > Fengguang Wasnt it already solved ? http://1984.lsi.us.es/git/nf-next/commit/?id=00545bec9412d130c77f72a08d6c8b6ad21d4a1 Just have to wait that netfilter fixes are pushed upstream Thanks -- 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/1] Input: ab8500-ponkey: Make the distinction between DT and non-DT boots
On Mon, Aug 6, 2012 at 2:32 PM, Lee Jones wrote: > If we're booting with Device Tree enabled, we want the IRQ numbers to > be taken and translated from the Device Tree binary. If not, they > should be taken from the resource allocation defined in the AB8500 MFD > core driver. > > Tested-by: Linus Walleij > Signed-off-by: Lee Jones Not having this patch in v3.6-rcN gives the following boot noise (and the key does not work): [ cut here ] WARNING: at /home/elinwal/linux-stericsson/kernel/irq/irqdomain.c:137 irq_domain_legacy_revmap+0x20/0x48() Modules linked in: [] (unwind_backtrace+0x0/0xf8) from [] (warn_slowpath_common+0x4c/0x64) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x1c/0x24) [] (warn_slowpath_null+0x1c/0x24) from [] (irq_domain_legacy_revmap+0x20/0x48) [] (irq_domain_legacy_revmap+0x20/0x48) from [] (ab8500_ponkey_probe+0xd0/0x1f8) [] (ab8500_ponkey_probe+0xd0/0x1f8) from [] (platform_drv_probe+0x14/0x18) [] (platform_drv_probe+0x14/0x18) from [] (driver_probe_device+0x78/0x208) [] (driver_probe_device+0x78/0x208) from [] (__driver_attach+0x8c/0x90) [] (__driver_attach+0x8c/0x90) from [] (bus_for_each_dev+0x50/0x7c) [] (bus_for_each_dev+0x50/0x7c) from [] (bus_add_driver+0x170/0x23c) [] (bus_add_driver+0x170/0x23c) from [] (driver_register+0x78/0x144) [] (driver_register+0x78/0x144) from [] (do_one_initcall+0x34/0x174) [] (do_one_initcall+0x34/0x174) from [] (kernel_init+0xfc/0x1bc) [] (kernel_init+0xfc/0x1bc) from [] (kernel_thread_exit+0x0/0x8) ---[ end trace d77aa0db848f0e28 ]--- ab8500-core ab8500-core.0: Failed to request dbf IRQ#0: -22 ab8500-poweron-key: probe of ab8500-poweron-key.0 failed with error -22 So how do we proceed to not release v3.6 with this regression? Shall all of the MFD IRQdomain stuff be pulled into the -rc series? (Linux-next seems to be working, so the real fix is in there) Yours, Linus Walleij -- 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] lockdep: Check if nested lock is actually held
It is considered good form to lock the lock you claim to be nested in.
Signed-off-by: Maarten Lankhorst
---
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index ea9ee45..7175447 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2998,6 +2998,43 @@ EXPORT_SYMBOL_GPL(lockdep_init_map);
struct lock_class_key __lockdep_no_validate__;
+static int
+print_lock_nested_lock_not_held(struct task_struct *curr,
+ struct held_lock *lock,
+ struct lockdep_map *nest,
+ unsigned long ip)
+{
+ if (!debug_locks_off())
+ return 0;
+ if (debug_locks_silent)
+ return 0;
+
+ printk("\n");
+ printk("==\n");
+ printk("[ BUG: Nested lock was not taken ]\n");
+ print_kernel_ident();
+ printk("--\n");
+
+ printk("%s/%d is trying to lock:\n", curr->comm, task_pid_nr(curr));
+ print_lock(lock);
+
+ printk("\nbut this task is not holding:\n");
+ printk("%s\n", nest->name);
+
+ printk("\nstack backtrace:\n");
+ dump_stack();
+
+ printk("\nother info that might help us debug this:\n");
+ lockdep_print_held_locks(curr);
+
+ printk("\nstack backtrace:\n");
+ dump_stack();
+
+ return 0;
+}
+
+static int __lock_is_held(struct lockdep_map *lock);
+
/*
* This gets called for every mutex_lock*()/spin_lock*() operation.
* We maintain the dependency maps and validate the locking attempt:
@@ -3139,6 +3176,10 @@ static int __lock_acquire(struct lockdep_map *lock,
unsigned int subclass,
}
chain_key = iterate_chain_key(chain_key, id);
+ if (nest_lock && !__lock_is_held(nest_lock))
+ return print_lock_nested_lock_not_held(curr, hlock,
+ nest_lock, ip);
+
if (!validate_chain(curr, lock, hlock, chain_head, chain_key))
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: xt_nat_init: BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
On Thu, Sep 13, 2012 at 11:30:24AM +0200, Florian Westphal wrote: > Fengguang Wu wrote: > > Hi Patrick, > > > > This happens in today's linux-next tree and is pretty reproducible. > > [1.834544] nf_conntrack version 0.5.0 (1786 buckets, 7144 max) > > [1.835406] ctnetlink v0.93: registering with nfnetlink. > > [1.836202] BUG: unable to handle kernel NULL pointer dereference at > > 00e0 > > [1.837539] IP: [] mutex_lock_interruptible+0x23/0x70 > > Should be fixed by > commit 00545bec9412d130c77f72a08d6c8b6ad21d4a1e > Author: Pablo Neira Ayuso > Subject: netfilter: fix crash during boot if NAT has been compiled built-in > > But seems its not yet in net-next. Pablo? I'll request the pull asap. -- 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: AMD Bulldozer FX-8150 Powers off during kernel build
On Thu, Sep 13, 2012 at 02:30:27AM +0100, Sid Boyce wrote: > I have a huge heatsink and large CPU fan plus lots of cooling fans > in the case and nothing gets hot. > If I build e.g 3.6-rc5 with 8 or 6 cores, part way through it > suddenly powers off. Ok, can you catch the whole dmesg when you boot the machine _after_ the sudden poweroff? You can send it to me and Andreas (on CC) privately if you prefer. Important: make sure the kernel has CONFIG_X86_MCE and CONFIG_EDAC_DECODE_MCE built-in. Please make sure to use a recent kernel, i.e. 3.4, 3.5 is fine. Thanks. (Leaving in the rest for reference) > I have checked hwmon/k10temp.c to see if I could see where these > values were defined. > > k10temp.h is 0 bytes. > -rw-r--r-- 1 root root 0 Sep 9 01:59 > /usr/src/linux-3.6.0-rc5/include/config/sensors/k10temp.h > > Currently I build with "make -j 1" and temperature and power values > are around those below. > # sensors > k10temp-pci-00c3 > Adapter: PCI adapter > temp1:+60.4°C (high = +70.0°C) >(crit = +90.0°C, hyst = +87.0°C) > > fam15h_power-pci-00c4 > Adapter: PCI adapter > power1: 127.49 W (crit = 124.77 W) > > # cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 21 > model : 1 > model name : AMD FX(tm)-8150 Eight-Core Processor > stepping: 2 > microcode : 0x6000626 > cpu MHz : 3600.000 > cache size : 2048 KB > > from .config:- > # grep HWMON .config > CONFIG_IXGBE_HWMON=y > CONFIG_HWMON=y > CONFIG_HWMON_VID=m > # CONFIG_HWMON_DEBUG_CHIP is not set > CONFIG_THERMAL_HWMON=y > > # grep POWERSAVE .config > # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set > CONFIG_CPU_FREQ_GOV_POWERSAVE=m > # CONFIG_PCIEASPM_POWERSAVE is not set > CONFIG_DEVFREQ_GOV_POWERSAVE=y > > On another 6-core box I can build kernels with "make -j 6" without problems. > # cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 21 > model : 1 > model name : AMD FX(tm)-6100 Six-Core Processor > stepping: 2 > microcode : 0x6000623 > cpu MHz : 3300.000 > cache size : 2048 KB > > With a kernel build going on six core box, temperature and power > hover around the values below. > sabre:~ # sensors > k10temp-pci-00c3 > Adapter: PCI adapter > temp1:+50.2°C (high = +70.0°C) >(crit = +90.0°C, hyst = +87.0°C) > > fam15h_power-pci-00c4 > Adapter: PCI adapter > power1: 94.40 W (crit = 95.01 W) > > 73 ... Sid. > > -- > Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot > Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support > Senior Staff Specialist, Cricket Coach > Microsoft Windows Free Zone - Linux used for all Computing Tasks > > -- > 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/
[PATCH 5/5] Staging: ipack/devices/ipoctal: simplify ipoctal_write_tty()
Remove count_wr and the assigment of nb_bytes = 0 in that function as is
useless. Now it returns the count of the characters actually sent.
There is other nb_bytes = 0 deleted that has a duplicate a few lines before.
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/devices/ipoctal.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 5f4545a..150fc75 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -33,7 +33,6 @@ static const struct tty_operations ipoctal_fops;
struct ipoctal_channel {
struct ipoctal_statsstats;
unsigned intnb_bytes;
- unsigned intcount_wr;
wait_queue_head_t queue;
spinlock_t lock;
unsigned intpointer_read;
@@ -189,7 +188,6 @@ static void ipoctal_irq_tx(struct ipoctal_channel *channel)
value = channel->tty_port.xmit_buf[*pointer_write];
iowrite8(value, >regs->w.thr);
channel->stats.tx++;
- channel->count_wr++;
(*pointer_write)++;
*pointer_write = *pointer_write % PAGE_SIZE;
channel->nb_bytes--;
@@ -444,7 +442,6 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
spin_lock_init(>lock);
channel->pointer_read = 0;
channel->pointer_write = 0;
- channel->nb_bytes = 0;
tty_dev = tty_register_device(tty, i, NULL);
if (IS_ERR(tty_dev)) {
dev_err(>dev->dev, "Failed to register tty
device.\n");
@@ -499,11 +496,9 @@ static int ipoctal_write_tty(struct tty_struct *tty,
const unsigned char *buf, int count)
{
struct ipoctal_channel *channel = tty->driver_data;
+ unsigned int char_copied;
- channel->nb_bytes = 0;
- channel->count_wr = 0;
-
- ipoctal_copy_write_buffer(channel, buf, count);
+ char_copied = ipoctal_copy_write_buffer(channel, buf, count);
/* As the IP-OCTAL 485 only supports half duplex, do it manually */
if (channel->board_id == IPACK1_DEVICE_ID_SBS_OCTAL_485) {
@@ -520,7 +515,7 @@ static int ipoctal_write_tty(struct tty_struct *tty,
iowrite8(CR_DISABLE_TX, >regs->w.cr);
*channel->board_write = 0;
- return channel->count_wr;
+ return char_copied;
}
static int ipoctal_write_room(struct tty_struct *tty)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] Staging: ipack/devices/ipoctal: acknowledge BREAK condition.
Clear the BREAK flag from the ISR register.
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/devices/ipoctal.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 0fd0e01..5f4545a 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -158,6 +158,7 @@ static void ipoctal_irq_rx(struct ipoctal_channel *channel,
flag = TTY_FRAME;
}
if (sr & SR_RECEIVED_BREAK) {
+ iowrite8(CR_CMD_RESET_BREAK_CHANGE,
>regs->w.cr);
channel->stats.rcv_break++;
flag = TTY_BREAK;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] staging: ipack: remove irq field in struct ipack_device.
From: Jens Taprogge
The field irq currently is identical to the slot number. It does not seem to
have any real use. The number is written to hardware in ipoctal but it seems
the value that is written does not matter.
Signed-off-by: Jens Taprogge
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/bridges/tpci200.c |9 ++---
drivers/staging/ipack/devices/ipoctal.c |8
drivers/staging/ipack/ipack.c |3 +--
drivers/staging/ipack/ipack.h |8 ++--
4 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/ipack/bridges/tpci200.c
b/drivers/staging/ipack/bridges/tpci200.c
index 43f2f38..bb8aa70 100644
--- a/drivers/staging/ipack/bridges/tpci200.c
+++ b/drivers/staging/ipack/bridges/tpci200.c
@@ -190,7 +190,7 @@ static int tpci200_free_irq(struct ipack_device *dev)
return 0;
}
-static int tpci200_request_irq(struct ipack_device *dev, int vector,
+static int tpci200_request_irq(struct ipack_device *dev,
irqreturn_t (*handler)(void *), void *arg)
{
int res = 0;
@@ -227,7 +227,6 @@ static int tpci200_request_irq(struct ipack_device *dev,
int vector,
* Read the User Manual of your IndustryPack device to know
* where to write the vector in memory.
*/
- slot_irq->vector = vector;
slot_irq->handler = handler;
slot_irq->arg = arg;
slot_irq->holder = dev;
@@ -715,12 +714,8 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
tpci200->number = tpci200->info->ipack_bus->bus_nr;
dev_set_drvdata(>dev, tpci200);
- /*
-* Give the same IRQ number as the slot number.
-* The TPCI200 has assigned his own two IRQ by PCI bus driver
-*/
for (i = 0; i < TPCI200_NB_SLOT; i++)
- ipack_device_register(tpci200->info->ipack_bus, i, i);
+ ipack_device_register(tpci200->info->ipack_bus, i);
return 0;
out_err_bus_register:
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 30d8d42..0fd0e01 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -288,7 +288,7 @@ static const struct tty_port_operations
ipoctal_tty_port_ops = {
};
static int ipoctal_inst_slot(struct ipoctal *ipoctal, unsigned int bus_nr,
-unsigned int slot, unsigned int vector)
+unsigned int slot)
{
int res = 0;
int i;
@@ -387,9 +387,9 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
* Depending of the carrier these addresses are accesible or not.
* More info in the datasheet.
*/
- ipoctal->dev->bus->ops->request_irq(ipoctal->dev, vector,
+ ipoctal->dev->bus->ops->request_irq(ipoctal->dev,
ipoctal_irq_handler, ipoctal);
- iowrite8(vector, ipoctal->dev->mem_space.address + 1);
+ iowrite8(1, ipoctal->dev->mem_space.address + 1);
/* Register the TTY device */
@@ -722,7 +722,7 @@ static int ipoctal_probe(struct ipack_device *dev)
return -ENOMEM;
ipoctal->dev = dev;
- res = ipoctal_inst_slot(ipoctal, dev->bus_nr, dev->slot, dev->irq);
+ res = ipoctal_inst_slot(ipoctal, dev->bus_nr, dev->slot);
if (res)
goto out_uninst;
diff --git a/drivers/staging/ipack/ipack.c b/drivers/staging/ipack/ipack.c
index c83f015..d1e0651 100644
--- a/drivers/staging/ipack/ipack.c
+++ b/drivers/staging/ipack/ipack.c
@@ -427,7 +427,7 @@ out:
}
struct ipack_device *ipack_device_register(struct ipack_bus_device *bus,
- int slot, int irqv)
+ int slot)
{
int ret;
struct ipack_device *dev;
@@ -441,7 +441,6 @@ struct ipack_device *ipack_device_register(struct
ipack_bus_device *bus,
dev->dev.parent = bus->parent;
dev->slot = slot;
dev->bus_nr = bus->bus_nr;
- dev->irq = irqv;
dev->bus = bus;
dev_set_name(>dev,
"ipack-dev.%u.%u", dev->bus_nr, dev->slot);
diff --git a/drivers/staging/ipack/ipack.h b/drivers/staging/ipack/ipack.h
index f8405df..d8e3bb6 100644
--- a/drivers/staging/ipack/ipack.h
+++ b/drivers/staging/ipack/ipack.h
@@ -54,7 +54,6 @@ struct ipack_addr_space {
*
* @bus_nr: IP bus number where the device is plugged
* @slot: Slot where the device is plugged in the carrier board
- * @irq: IRQ vector
* @bus: ipack_bus_device where the device is plugged to.
* @id_space: Virtual address to ID space.
* @io_space: Virtual address to IO space.
@@ -68,7 +67,6 @@ struct ipack_addr_space {
struct ipack_device {
unsigned int bus_nr;
unsigned int slot;
- unsigned int irq;
struct ipack_bus_device *bus;
struct
[PATCH 2/5] Staging: ipack: move the responsibility to clear interrupts to the IPack devices.
From: Jens Taprogge
Now the IPack device acknowledges its own IRQ.
Signed-off-by: Jens Taprogge
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/bridges/tpci200.c |4
drivers/staging/ipack/devices/ipoctal.c | 19 +--
drivers/staging/ipack/devices/scc2698.h |3 +++
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ipack/bridges/tpci200.c
b/drivers/staging/ipack/bridges/tpci200.c
index 3462783..43f2f38 100644
--- a/drivers/staging/ipack/bridges/tpci200.c
+++ b/drivers/staging/ipack/bridges/tpci200.c
@@ -126,10 +126,6 @@ static irqreturn_t tpci200_slot_irq(struct slot_irq
*slot_irq)
return -ENODEV;
ret = slot_irq->handler(slot_irq->arg);
- /* Clear the IPack device interrupt */
- readw(slot_irq->holder->io_space.address + 0xC0);
- readw(slot_irq->holder->io_space.address + 0xC2);
-
return ret;
}
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 0292364..30d8d42 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -252,6 +252,10 @@ static irqreturn_t ipoctal_irq_handler(void *arg)
for (i = 0; i < NR_CHANNELS; i++)
ipoctal_irq_channel(>channel[i]);
+ /* Clear the IPack device interrupt */
+ readw(ipoctal->dev->int_space.address + ACK_INT_REQ0);
+ readw(ipoctal->dev->int_space.address + ACK_INT_REQ1);
+
return IRQ_HANDLED;
}
@@ -264,7 +268,6 @@ static int ipoctal_check_model(struct ipack_device *dev,
unsigned char *id)
manufacturerID = ioread8(dev->id_space.address +
IPACK_IDPROM_OFFSET_MANUFACTURER_ID);
if (manufacturerID != IPACK1_VENDOR_ID_SBS)
return -ENODEV;
-
board_id = ioread8(dev->id_space.address + IPACK_IDPROM_OFFSET_MODEL);
switch (board_id) {
case IPACK1_DEVICE_ID_SBS_OCTAL_232:
@@ -322,13 +325,22 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
goto out_unregister_id_space;
}
+ res = ipoctal->dev->bus->ops->map_space(ipoctal->dev, 0,
+ IPACK_INT_SPACE);
+ if (res) {
+ dev_err(>dev->dev,
+ "Unable to map slot [%d:%d] INT space!\n",
+ bus_nr, slot);
+ goto out_unregister_io_space;
+ }
+
res = ipoctal->dev->bus->ops->map_space(ipoctal->dev,
0x8000, IPACK_MEM_SPACE);
if (res) {
dev_err(>dev->dev,
"Unable to map slot [%d:%d] MEM space!\n",
bus_nr, slot);
- goto out_unregister_io_space;
+ goto out_unregister_int_space;
}
/* Save the virtual address to access the registers easily */
@@ -450,6 +462,8 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
out_unregister_slot_unmap:
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_ID_SPACE);
+out_unregister_int_space:
+ ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_INT_SPACE);
out_unregister_io_space:
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_IO_SPACE);
out_unregister_id_space:
@@ -735,6 +749,7 @@ static void __ipoctal_remove(struct ipoctal *ipoctal)
tty_unregister_driver(ipoctal->tty_drv);
put_tty_driver(ipoctal->tty_drv);
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_MEM_SPACE);
+ ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_INT_SPACE);
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_IO_SPACE);
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_ID_SPACE);
kfree(ipoctal);
diff --git a/drivers/staging/ipack/devices/scc2698.h
b/drivers/staging/ipack/devices/scc2698.h
index 223838a..96e8d8c 100644
--- a/drivers/staging/ipack/devices/scc2698.h
+++ b/drivers/staging/ipack/devices/scc2698.h
@@ -221,4 +221,7 @@ union scc2698_block {
#define ISR_DELTA_BREAK_B (0x1 << 6)
#define ISR_INPUT_PORT_CHANGE (0x1 << 7)
+#define ACK_INT_REQ0 0
+#define ACK_INT_REQ1 2
+
#endif /* SCC2698_H_ */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Staging: ipack: Add IPACK_INT_SPACE memory space.
From: Jens Taprogge
This will allow us to correctly access the IPack INT space.
Signed-off-by: Jens Taprogge
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/bridges/tpci200.c | 29 +
drivers/staging/ipack/bridges/tpci200.h |2 ++
drivers/staging/ipack/ipack.h |2 ++
3 files changed, 33 insertions(+)
diff --git a/drivers/staging/ipack/bridges/tpci200.c
b/drivers/staging/ipack/bridges/tpci200.c
index 21b2b75..3462783 100644
--- a/drivers/staging/ipack/bridges/tpci200.c
+++ b/drivers/staging/ipack/bridges/tpci200.c
@@ -95,6 +95,8 @@ static void tpci200_unregister(struct tpci200_board *tpci200)
tpci200->slots[i].io_phys.size = 0;
tpci200->slots[i].id_phys.address = NULL;
tpci200->slots[i].id_phys.size = 0;
+ tpci200->slots[i].int_phys.address = NULL;
+ tpci200->slots[i].int_phys.size = 0;
tpci200->slots[i].mem_phys.address = NULL;
tpci200->slots[i].mem_phys.size = 0;
}
@@ -331,6 +333,11 @@ static int tpci200_register(struct tpci200_board *tpci200)
TPCI200_ID_SPACE_OFF + TPCI200_ID_SPACE_GAP*i;
tpci200->slots[i].id_phys.size = TPCI200_ID_SPACE_SIZE;
+ tpci200->slots[i].int_phys.address =
+ (void __iomem *)ioidint_base +
+ TPCI200_INT_SPACE_OFF + TPCI200_INT_SPACE_GAP * i;
+ tpci200->slots[i].int_phys.size = TPCI200_INT_SPACE_SIZE;
+
tpci200->slots[i].mem_phys.address =
(void __iomem *)mem_base + TPCI200_MEM8_GAP*i;
tpci200->slots[i].mem_phys.size = TPCI200_MEM8_SIZE;
@@ -391,6 +398,15 @@ static int tpci200_slot_unmap_space(struct ipack_device
*dev, int space)
}
virt_addr_space = >id_space;
break;
+ case IPACK_INT_SPACE:
+ if (dev->int_space.address == NULL) {
+ dev_info(>dev,
+"Slot [%d:%d] INT space not mapped !\n",
+dev->bus_nr, dev->slot);
+ goto out_unlock;
+ }
+ virt_addr_space = >int_space;
+ break;
case IPACK_MEM_SPACE:
if (dev->mem_space.address == NULL) {
dev_info(>dev,
@@ -460,6 +476,19 @@ static int tpci200_slot_map_space(struct ipack_device *dev,
phys_address = tpci200->slots[dev->slot].id_phys.address;
size_to_map = tpci200->slots[dev->slot].id_phys.size;
break;
+ case IPACK_INT_SPACE:
+ if (dev->int_space.address != NULL) {
+ dev_err(>dev,
+ "Slot [%d:%d] INT space already mapped !\n",
+ tpci200->number, dev->slot);
+ res = -EINVAL;
+ goto out_unlock;
+ }
+ virt_addr_space = >int_space;
+
+ phys_address = tpci200->slots[dev->slot].int_phys.address;
+ size_to_map = tpci200->slots[dev->slot].int_phys.size;
+ break;
case IPACK_MEM_SPACE:
if (dev->mem_space.address != NULL) {
dev_err(>dev,
diff --git a/drivers/staging/ipack/bridges/tpci200.h
b/drivers/staging/ipack/bridges/tpci200.h
index e1f60f3..235d1fe 100644
--- a/drivers/staging/ipack/bridges/tpci200.h
+++ b/drivers/staging/ipack/bridges/tpci200.h
@@ -132,6 +132,7 @@ struct slot_irq {
* @irqSlot IRQ infos
* @io_physIO physical base address register of the slot
* @id_physID physical base address register of the slot
+ * @int_phys INT physical base address register of the slot
* @mem_phys MEM physical base address register of the slot
*
*/
@@ -139,6 +140,7 @@ struct tpci200_slot {
struct slot_irq *irq;
struct ipack_addr_space io_phys;
struct ipack_addr_space id_phys;
+ struct ipack_addr_space int_phys;
struct ipack_addr_space mem_phys;
};
diff --git a/drivers/staging/ipack/ipack.h b/drivers/staging/ipack/ipack.h
index 9c3079d..f8405df 100644
--- a/drivers/staging/ipack/ipack.h
+++ b/drivers/staging/ipack/ipack.h
@@ -35,6 +35,7 @@ enum ipack_space {
IPACK_IO_SPACE= 0,
IPACK_ID_SPACE= 1,
IPACK_MEM_SPACE = 2,
+ IPACK_INT_SPACE,
};
/**
@@ -71,6 +72,7 @@ struct ipack_device {
struct ipack_bus_device *bus;
struct ipack_addr_space id_space;
struct ipack_addr_space io_space;
+ struct ipack_addr_space int_space;
struct ipack_addr_space mem_space;
struct device dev;
u8 *id;
--
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
Re: [PATCH] perf record: Add missing perf_hpp__init for pipe-mode
On 13.09.12 13:14:30, Namhyung Kim wrote:
> From: Namhyung Kim
>
> The perf_hpp__init() function was only called from setup_browser() so
> that the pipe-mode missed the initialization thus didn't respond to
> related options. Fix it.
>
> Reported-by: Robert Richter
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/builtin-report.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
This patch fixes it.
Thanks,
-Robert
>
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index 97b2e6300f4c..279155a47d1c 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -689,8 +689,10 @@ int cmd_report(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> if (strcmp(report.input_name, "-") != 0)
> setup_browser(true);
> - else
> + else {
> use_browser = 0;
> + perf_hpp__init(false, false);
> + }
>
> /*
>* Only in the newt browser we are doing integrated annotation,
> --
> 1.7.11.4
>
>
--
Advanced Micro Devices, Inc.
Operating System Research Center
--
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 9/9] drivers/isdn/gigaset/common.c: Remove useless kfree
Am 12.09.2012 17:06, schrieb Peter Senna Tschudin: > From: Peter Senna Tschudin > > Remove useless kfree() and clean up code related to the removal. > > The semantic patch that finds this problem is as follows: [...] > > Signed-off-by: Peter Senna Tschudin Acked-by: Tilman Schmidt > --- > drivers/isdn/gigaset/common.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/isdn/gigaset/common.c b/drivers/isdn/gigaset/common.c > index aa41485..30a6b17 100644 > --- a/drivers/isdn/gigaset/common.c > +++ b/drivers/isdn/gigaset/common.c > @@ -1123,7 +1123,6 @@ struct gigaset_driver *gigaset_initdriver(unsigned > minor, unsigned minors, > return drv; > > error: > - kfree(drv->cs); > kfree(drv); > return NULL; > } This is indeed vestigial code, left in when another error path that needed it was removed. Though innocuous, it's better to remove it. Thanks, Tilman -- Tilman SchmidtE-Mail: til...@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH v2] USB: PHY: Re-organize Tegra USB PHY driver
Hi,
On Thu, Sep 13, 2012 at 12:32 PM, Venu Byravarasu
wrote:
> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> In order to support USB PHY drivers on these SoCs, existing
> PHY driver is split into SoC agnostic common USB PHY driver
> and Tegra20-specific USB phy driver. This will facilitate
> easy addition and deletion of phy drivers for Tegra SoCs.
>
> Signed-off-by: Venu Byravarasu
> ---
> delta from v1:
>
> 1. Added two new phy_open functions, which will be called based
> on the phy type being used.
> 2. Moved function pointer initialization to these two functions.
> 3. Renamed usb_phy_ops to tegra_usb_phy_ops.
> 4. Moved tegra_freq_table from header to tegra_usb_phy.c
>
> drivers/usb/host/ehci-tegra.c | 24 +-
> drivers/usb/phy/Makefile |1 +
> .../usb/phy/{tegra_usb_phy.c => tegra2_usb_phy.c} | 421 +++--
> drivers/usb/phy/tegra2_usb_phy.h | 140
> drivers/usb/phy/tegra_usb_phy.c| 688
> +---
> include/linux/usb/tegra_usb_phy.h | 34 +-
> 6 files changed, 296 insertions(+), 1012 deletions(-)
> copy drivers/usb/phy/{tegra_usb_phy.c => tegra2_usb_phy.c} (53%)
> create mode 100644 drivers/usb/phy/tegra2_usb_phy.h
>
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> index 6223d17..15af372 100644
> --- a/drivers/usb/host/ehci-tegra.c
> +++ b/drivers/usb/host/ehci-tegra.c
> @@ -618,6 +618,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
> int err = 0;
> int irq;
> int instance = pdev->id;
> + struct device_node *np = pdev->dev.of_node;
> + struct phy_params params;
> + int phy_type;
>
> pdata = pdev->dev.platform_data;
> if (!pdata) {
> @@ -701,14 +704,27 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> break;
> default:
> err = -ENODEV;
> - dev_err(>dev, "unknown usb instance\n");
> + dev_err(>dev, "unknown usb inst:%d\n",
> instance);
> goto fail_io;
> }
> }
It's better you have the below code under *if (np)*, since both device
node and pdata co-exist for you.
>
> + phy_type = of_property_match_string(np, "phy_type", "utmi");
> + if (phy_type >= 0)
> + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> + else {
> + phy_type = of_property_match_string(np, "phy_type", "ulpi");
> + if (phy_type >= 0)
> + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> + else
> + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> + }
> +
> + params.mode = TEGRA_USB_PHY_MODE_HOST;
> + params.config = pdata->phy_config;
doesn't this above line result in abort when you are doing a dt boot?
> +
> tegra->phy = tegra_usb_phy_open(>dev, instance, hcd->regs,
> - pdata->phy_config,
> - TEGRA_USB_PHY_MODE_HOST);
> + );
> if (IS_ERR(tegra->phy)) {
> dev_err(>dev, "Failed to open USB phy\n");
> err = -ENXIO;
> @@ -744,7 +760,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (err) {
> - dev_err(>dev, "Failed to add USB HCD\n");
> + dev_err(>dev, "usb_add_hcd failed with err 0x%x\n",
> err);
> goto fail;
> }
>
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index b069f29..21872e1 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
> obj-$(CONFIG_USB_ISP1301) += isp1301.o
> obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
> +obj-$(CONFIG_USB_EHCI_TEGRA) += tegra2_usb_phy.o
> diff --git a/drivers/usb/phy/tegra_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
> similarity index 53%
> copy from drivers/usb/phy/tegra_usb_phy.c
> copy to drivers/usb/phy/tegra2_usb_phy.c
> index 987116f..4896a4d 100644
> --- a/drivers/usb/phy/tegra_usb_phy.c
> +++ b/drivers/usb/phy/tegra2_usb_phy.c
> @@ -1,9 +1,11 @@
> /*
> * Copyright (C) 2010 Google, Inc.
> + * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
> *
> * Author:
> * Erik Gilling
> * Benoit Goby
> + * Venu Byravarasu
> *
> * This software is licensed under the terms of the GNU General Public
> * License version 2, as published by the Free Software Foundation, and
> @@ -31,187 +33,18 @@
> #include
> #include
>
> -#define ULPI_VIEWPORT 0x170
> -
> -#define USB_PORTSC10x184
> -#define USB_PORTSC1_PTS(x) (((x) & 0x3) << 30)
> -#define
[RFC] tty: Add get- ioctls to fetch tty status
For checkpoint/restore we need to know if tty has
exclusive or packet mode set, as well as if pty
is currently locked. Just to be able to restore
this characteristics.
For this sake the following ioctl codes are introduced
- TIOGPKT to get packet mode state
- TIOGPTLCK to get Pty locked state
- TIOGEXCL to get Exclusive mode state
Signed-off-by: Cyrill Gorcunov
---
Guys, what do you think?
drivers/tty/pty.c| 12
drivers/tty/tty_io.c |7 +++
drivers/tty/tty_ioctl.c | 16
fs/compat_ioctl.c|3 +++
include/asm-generic/ioctls.h |3 +++
5 files changed, 41 insertions(+)
Index: linux-2.6.git/drivers/tty/pty.c
===
--- linux-2.6.git.orig/drivers/tty/pty.c
+++ linux-2.6.git/drivers/tty/pty.c
@@ -173,6 +173,14 @@ static int pty_set_lock(struct tty_struc
return 0;
}
+static int pty_get_lock(struct tty_struct *tty, int __user *arg)
+{
+ int locked = test_bit(TTY_PTY_LOCK, >flags);
+ if (put_user(locked, arg))
+ return -EFAULT;
+ return 0;
+}
+
/* Send a signal to the slave */
static int pty_signal(struct tty_struct *tty, int sig)
{
@@ -342,6 +350,8 @@ static int pty_bsd_ioctl(struct tty_stru
switch (cmd) {
case TIOCSPTLCK: /* Set PT Lock (disallow slave open) */
return pty_set_lock(tty, (int __user *) arg);
+ case TIOGPTLCK:
+ return pty_get_lock(tty, (int __user *) arg);
case TIOCSIG:/* Send signal to other side of pty */
return pty_signal(tty, (int) arg);
}
@@ -449,6 +459,8 @@ static int pty_unix98_ioctl(struct tty_s
switch (cmd) {
case TIOCSPTLCK: /* Set PT Lock (disallow slave open) */
return pty_set_lock(tty, (int __user *)arg);
+ case TIOGPTLCK:
+ return pty_get_lock(tty, (int __user *) arg);
case TIOCGPTN: /* Get PT Number */
return put_user(tty->index, (unsigned int __user *)arg);
case TIOCSIG:/* Send signal to other side of pty */
Index: linux-2.6.git/drivers/tty/tty_io.c
===
--- linux-2.6.git.orig/drivers/tty/tty_io.c
+++ linux-2.6.git/drivers/tty/tty_io.c
@@ -2675,6 +2675,13 @@ long tty_ioctl(struct file *file, unsign
case TIOCNXCL:
clear_bit(TTY_EXCLUSIVE, >flags);
return 0;
+ case TIOGEXCL:
+ {
+ int excl = test_bit(TTY_EXCLUSIVE, >flags);
+ if (put_user(excl, (int __user *)p))
+ return -EFAULT;
+ return 0;
+ }
case TIOCNOTTY:
if (current->signal->tty != tty)
return -ENOTTY;
Index: linux-2.6.git/drivers/tty/tty_ioctl.c
===
--- linux-2.6.git.orig/drivers/tty/tty_ioctl.c
+++ linux-2.6.git/drivers/tty/tty_ioctl.c
@@ -1173,6 +1173,22 @@ int n_tty_ioctl_helper(struct tty_struct
spin_unlock_irqrestore(>ctrl_lock, flags);
return 0;
}
+ case TIOGPKT:
+ {
+ int pktmode;
+
+ if (tty->driver->type != TTY_DRIVER_TYPE_PTY ||
+ tty->driver->subtype != PTY_TYPE_MASTER)
+ return -ENOTTY;
+
+ spin_lock_irqsave(>ctrl_lock, flags);
+ pktmode = tty->packet;
+ spin_unlock_irqrestore(>ctrl_lock, flags);
+
+ if (put_user(pktmode, (int __user *) arg))
+ return -EFAULT;
+ return 0;
+ }
default:
/* Try the mode commands */
return tty_mode_ioctl(tty, file, cmd, arg);
Index: linux-2.6.git/fs/compat_ioctl.c
===
--- linux-2.6.git.orig/fs/compat_ioctl.c
+++ linux-2.6.git/fs/compat_ioctl.c
@@ -842,6 +842,9 @@ COMPATIBLE_IOCTL(TIOCGDEV)
COMPATIBLE_IOCTL(TIOCCBRK)
COMPATIBLE_IOCTL(TIOCGSID)
COMPATIBLE_IOCTL(TIOCGICOUNT)
+COMPATIBLE_IOCTL(TIOGPKT)
+COMPATIBLE_IOCTL(TIOGPTLCK)
+COMPATIBLE_IOCTL(TIOGEXCL)
/* Little t */
COMPATIBLE_IOCTL(TIOCGETD)
COMPATIBLE_IOCTL(TIOCSETD)
Index: linux-2.6.git/include/asm-generic/ioctls.h
===
--- linux-2.6.git.orig/include/asm-generic/ioctls.h
+++ linux-2.6.git/include/asm-generic/ioctls.h
@@ -74,6 +74,9 @@
#define TCSETXW0x5435
#define TIOCSIG_IOW('T', 0x36, int) /* pty: generate signal */
#define TIOCVHANGUP0x5437
+#define TIOGPKT_IOR('T', 0x38, int) /* Get packet mode state */
+#define TIOGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */
+#define TIOGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */
#define FIONCLEX 0x5450
#define FIOCLEX0x5451
--
To
Re: qemu-kvm loops after kernel udpate
On 09/12/2012 09:11 PM, Jiri Slaby wrote: > On 09/12/2012 10:18 AM, Avi Kivity wrote: >> On 09/12/2012 11:13 AM, Jiri Slaby wrote: >>> Please provide the output of vmxcap (http://goo.gl/c5lUO), >>> >>> Unrestricted guest no >> >> The big real mode fixes. >> >> >>> and a snapshot of kvm_stat while the guest is hung. >>> >>> kvm statistics >>> >>> exits 6778198 615942 >>> host_state_reload 1988 187 >>> irq_exits 1523 138 >>> mmu_cache_miss 4 0 >>> fpu_reload 1 0 >> >> Please run this as root so we get the tracepoint based output; and press >> 'x' when it's running so we get more detailed output. > > kvm statistics > > kvm_exit 13798699 330708 > kvm_entry 13799110 330708 > kvm_page_fault13793650 330604 > kvm_exit(EXCEPTION_NMI)6188458 330604 > kvm_exit(EXTERNAL_INTERRUPT) 2169 105 > kvm_exit(TPR_BELOW_THRESHOLD) 82 0 > kvm_exit(IO_INSTRUCTION) 6 0 Strange, it's unable to fault in the very first page. Please provide a trace as per http://www.linux-kvm.org/page/Tracing (but append -e kvmmmu to the command line). -- error compiling committee.c: too many arguments to function -- 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] lockdep: Check if nested lock is actually held
On Thu, 2012-09-13 at 11:39 +0200, Maarten Lankhorst wrote:
> It is considered good form to lock the lock you claim to be nested in.
Uhm yeah.. cute. You actually found a site where this triggered?
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> index ea9ee45..7175447 100644
> --- a/kernel/lockdep.c
> +++ b/kernel/lockdep.c
> @@ -2998,6 +2998,43 @@ EXPORT_SYMBOL_GPL(lockdep_init_map);
>
> struct lock_class_key __lockdep_no_validate__;
>
> +static int
> +print_lock_nested_lock_not_held(struct task_struct *curr,
> + struct held_lock *lock,
> + struct lockdep_map *nest,
> + unsigned long ip)
> +{
> + if (!debug_locks_off())
> + return 0;
> + if (debug_locks_silent)
> + return 0;
> +
> + printk("\n");
> + printk("==\n");
> + printk("[ BUG: Nested lock was not taken ]\n");
> + print_kernel_ident();
> + printk("--\n");
> +
> + printk("%s/%d is trying to lock:\n", curr->comm, task_pid_nr(curr));
> + print_lock(lock);
> +
> + printk("\nbut this task is not holding:\n");
> + printk("%s\n", nest->name);
> +
> + printk("\nstack backtrace:\n");
> + dump_stack();
> +
> + printk("\nother info that might help us debug this:\n");
> + lockdep_print_held_locks(curr);
> +
> + printk("\nstack backtrace:\n");
> + dump_stack();
> +
> + return 0;
> +}
> +
> +static int __lock_is_held(struct lockdep_map *lock);
> +
> /*
> * This gets called for every mutex_lock*()/spin_lock*() operation.
> * We maintain the dependency maps and validate the locking attempt:
> @@ -3139,6 +3176,10 @@ static int __lock_acquire(struct lockdep_map *lock,
> unsigned int subclass,
> }
> chain_key = iterate_chain_key(chain_key, id);
>
> + if (nest_lock && !__lock_is_held(nest_lock))
> + return print_lock_nested_lock_not_held(curr, hlock,
> +nest_lock, ip);
At this time we've already set hlock->nest_lock, so I've shortened the
argument list here a little.
> if (!validate_chain(curr, lock, hlock, chain_head, chain_key))
> return 0;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the final tree (akpm tree related)
On Thu, Sep 13, 2012 at 06:01:21PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> mm/internal.h: In function 'swap_cache_hit':
> mm/internal.h:377:3: error: implicit declaration of function
> 'atomic_dec_if_positive' [-Werror=implicit-function-declaration]
>
> Caused by commit "swap: add a simple detector for inappropriate swapin
> readahead" from the akmp tree. atomic_dec_if_positive() appears to only
> exist on avr32, microblaze, mips, powerpc and x86 ...
>
> I have reverted that commit (and the following trivial fix commit) for
> today.
The x86 implementation of atomic_dec_if_positive is quite generic, how about
add this one?
Signed-off-by: Shaohua Li
---
arch/microblaze/include/asm/atomic.h |3 ++-
arch/powerpc/include/asm/atomic.h|3 ++-
arch/x86/include/asm/atomic.h| 24
include/linux/atomic.h | 25 +
4 files changed, 29 insertions(+), 26 deletions(-)
Index: linux/arch/microblaze/include/asm/atomic.h
===
--- linux.orig/arch/microblaze/include/asm/atomic.h 2012-09-13
17:56:54.206807900 +0800
+++ linux/arch/microblaze/include/asm/atomic.h 2012-09-13 17:57:18.202506238
+0800
@@ -9,7 +9,7 @@
* Atomically test *v and decrement if it is greater than 0.
* The function returns the old value of *v minus 1.
*/
-static inline int atomic_dec_if_positive(atomic_t *v)
+static inline int __atomic_dec_if_positive(atomic_t *v)
{
unsigned long flags;
int res;
@@ -22,5 +22,6 @@ static inline int atomic_dec_if_positive
return res;
}
+#define atomic_dec_if_positive __atomic_dec_if_positive
#endif /* _ASM_MICROBLAZE_ATOMIC_H */
Index: linux/arch/powerpc/include/asm/atomic.h
===
--- linux.orig/arch/powerpc/include/asm/atomic.h2012-09-13
17:56:54.210807849 +0800
+++ linux/arch/powerpc/include/asm/atomic.h 2012-09-13 17:57:18.202506238
+0800
@@ -247,7 +247,7 @@ static __inline__ int atomic_inc_not_zer
* The function returns the old value of *v minus 1, even if
* the atomic variable, v, was not decremented.
*/
-static __inline__ int atomic_dec_if_positive(atomic_t *v)
+static __inline__ int __atomic_dec_if_positive(atomic_t *v)
{
int t;
@@ -268,6 +268,7 @@ static __inline__ int atomic_dec_if_posi
return t;
}
+#define atomic_dec_if_positive __atomic_dec_if_positive
#define smp_mb__before_atomic_dec() smp_mb()
#define smp_mb__after_atomic_dec() smp_mb()
Index: linux/arch/x86/include/asm/atomic.h
===
--- linux.orig/arch/x86/include/asm/atomic.h2012-09-13 17:56:54.210807849
+0800
+++ linux/arch/x86/include/asm/atomic.h 2012-09-13 17:57:18.202506238 +0800
@@ -240,30 +240,6 @@ static inline int __atomic_add_unless(at
return c;
}
-
-/*
- * atomic_dec_if_positive - decrement by 1 if old value positive
- * @v: pointer of type atomic_t
- *
- * The function returns the old value of *v minus 1, even if
- * the atomic variable, v, was not decremented.
- */
-static inline int atomic_dec_if_positive(atomic_t *v)
-{
- int c, old, dec;
- c = atomic_read(v);
- for (;;) {
- dec = c - 1;
- if (unlikely(dec < 0))
- break;
- old = atomic_cmpxchg((v), c, dec);
- if (likely(old == c))
- break;
- c = old;
- }
- return dec;
-}
-
/**
* atomic_inc_short - increment of a short integer
* @v: pointer to type int
Index: linux/include/linux/atomic.h
===
--- linux.orig/include/linux/atomic.h 2012-09-13 17:56:54.210807849 +0800
+++ linux/include/linux/atomic.h2012-09-13 17:57:18.202506238 +0800
@@ -86,6 +86,31 @@ static inline int atomic_dec_unless_posi
}
#endif
+/*
+ * atomic_dec_if_positive - decrement by 1 if old value positive
+ * @v: pointer of type atomic_t
+ *
+ * The function returns the old value of *v minus 1, even if
+ * the atomic variable, v, was not decremented.
+ */
+#ifndef atomic_dec_if_positive
+static inline int atomic_dec_if_positive(atomic_t *v)
+{
+ int c, old, dec;
+ c = atomic_read(v);
+ for (;;) {
+ dec = c - 1;
+ if (unlikely(dec < 0))
+ break;
+ old = atomic_cmpxchg((v), c, dec);
+ if (likely(old == c))
+ break;
+ c = old;
+ }
+ return dec;
+}
+#endif
+
#ifndef CONFIG_ARCH_HAS_ATOMIC_OR
static inline void atomic_or(int i, atomic_t *v)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH 3/5] staging: ipack: remove irq field in struct ipack_device.
On Thu, Sep 13, 2012 at 11:46:26AM +0200, Samuel Iglesias Gonsalvez wrote: > From: Jens Taprogge > > The field irq currently is identical to the slot number. It does not seem to > have any real use. The number is written to hardware in ipoctal but it seems > the value that is written does not matter. > > Signed-off-by: Jens Taprogge > Signed-off-by: Samuel Iglesias Gonsalvez > --- > - iowrite8(vector, ipoctal->dev->mem_space.address + 1); > + iowrite8(1, ipoctal->dev->mem_space.address + 1); It might be nice to put a /* dummy write */ comment here. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] Staging: ipack/devices/ipoctal: acknowledge BREAK condition.
On Thu, Sep 13, 2012 at 11:46:27AM +0200, Samuel Iglesias Gonsalvez wrote: > Clear the BREAK flag from the ISR register. > > Signed-off-by: Samuel Iglesias Gonsalvez What are the user visible effects of this bugfix? regards, dan carpenter -- 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] USB: PHY: Re-organize Tegra USB PHY driver
Thanks Kishon, for your comments.
Plz see my answers inline.
> -Original Message-
> From: ABRAHAM, KISHON VIJAY [mailto:kis...@ti.com]
> Sent: Thursday, September 13, 2012 3:25 PM
> To: Venu Byravarasu
> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org;
> ba...@ti.com; Stephen Warren; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; linux-te...@vger.kernel.org
> Subject: Re: [PATCH v2] USB: PHY: Re-organize Tegra USB PHY driver
>
> Hi,
>
> On Thu, Sep 13, 2012 at 12:32 PM, Venu Byravarasu
> wrote:
> > NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> > In order to support USB PHY drivers on these SoCs, existing
> > PHY driver is split into SoC agnostic common USB PHY driver
> > and Tegra20-specific USB phy driver. This will facilitate
> > easy addition and deletion of phy drivers for Tegra SoCs.
> >
> > Signed-off-by: Venu Byravarasu
> > ---
> > delta from v1:
> >
> > 1. Added two new phy_open functions, which will be called based
> > on the phy type being used.
> > 2. Moved function pointer initialization to these two functions.
> > 3. Renamed usb_phy_ops to tegra_usb_phy_ops.
> > 4. Moved tegra_freq_table from header to tegra_usb_phy.c
> >
> > drivers/usb/host/ehci-tegra.c | 24 +-
> > drivers/usb/phy/Makefile |1 +
> > .../usb/phy/{tegra_usb_phy.c => tegra2_usb_phy.c} | 421 +++--
> > drivers/usb/phy/tegra2_usb_phy.h | 140
> > drivers/usb/phy/tegra_usb_phy.c| 688
> > +---
> > include/linux/usb/tegra_usb_phy.h | 34 +-
> > 6 files changed, 296 insertions(+), 1012 deletions(-)
> > copy drivers/usb/phy/{tegra_usb_phy.c => tegra2_usb_phy.c} (53%)
> > create mode 100644 drivers/usb/phy/tegra2_usb_phy.h
> >
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> > index 6223d17..15af372 100644
> > --- a/drivers/usb/host/ehci-tegra.c
> > +++ b/drivers/usb/host/ehci-tegra.c
> > @@ -618,6 +618,9 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > int err = 0;
> > int irq;
> > int instance = pdev->id;
> > + struct device_node *np = pdev->dev.of_node;
> > + struct phy_params params;
> > + int phy_type;
> >
> > pdata = pdev->dev.platform_data;
> > if (!pdata) {
> > @@ -701,14 +704,27 @@ static int tegra_ehci_probe(struct
> platform_device *pdev)
> > break;
> > default:
> > err = -ENODEV;
> > - dev_err(>dev, "unknown usb instance\n");
> > + dev_err(>dev, "unknown usb inst:%d\n",
> > instance);
> > goto fail_io;
> > }
> > }
>
> It's better you have the below code under *if (np)*, since both device
> node and pdata co-exist for you.
Sure, will add it in upcoming patches of code-clean up.
> >
> > + phy_type = of_property_match_string(np, "phy_type", "utmi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> > + else {
> > + phy_type = of_property_match_string(np, "phy_type", "ulpi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> > + else
> > + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> > + }
> > +
> > + params.mode = TEGRA_USB_PHY_MODE_HOST;
> > + params.config = pdata->phy_config;
>
> doesn't this above line result in abort when you are doing a dt boot?
I did not see any abort during my testing on Ventana.
> > +
> > tegra->phy = tegra_usb_phy_open(>dev, instance, hcd->regs,
> > - pdata->phy_config,
> > - TEGRA_USB_PHY_MODE_HOST);
> > + );
> > if (IS_ERR(tegra->phy)) {
> > dev_err(>dev, "Failed to open USB phy\n");
> > err = -ENXIO;
> > @@ -744,7 +760,7 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> >
> > err = usb_add_hcd(hcd, irq, IRQF_SHARED);
> > if (err) {
> > - dev_err(>dev, "Failed to add USB HCD\n");
> > + dev_err(>dev, "usb_add_hcd failed with err 0x%x\n",
> > err);
> > goto fail;
> > }
> >
> > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> > index b069f29..21872e1 100644
> > --- a/drivers/usb/phy/Makefile
> > +++ b/drivers/usb/phy/Makefile
> > @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
> > obj-$(CONFIG_USB_ISP1301) += isp1301.o
> > obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
> > obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
> > +obj-$(CONFIG_USB_EHCI_TEGRA) += tegra2_usb_phy.o
> > diff --git a/drivers/usb/phy/tegra_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
> > similarity index
Re: [PATCH] sched: unify the check on atomic sleeping in __might_sleep() and schedule_bug()
On Wed, 2012-08-22 at 10:40 +0800, Michael Wang wrote: > From: Michael Wang > > Fengguang Wu has reported the bug: > > [0.043953] BUG: scheduling while atomic: swapper/0/1/0x1002 > [0.044017] no locks held by swapper/0/1. > [0.044692] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc1-00420-gb7aebb9 > #34 > [0.045861] Call Trace: > [0.048071] [] __schedule_bug+0x5e/0x70 > [0.048890] [] __schedule+0x91/0xb10 > [0.049660] [] ? vsnprintf+0x33a/0x450 > [0.050444] [] ? lg_local_lock+0x6/0x70 > [0.051256] [] ? wait_for_xmitr+0x31/0x90 > [0.052019] [] ? do_raw_spin_unlock+0xa5/0xf0 > [0.052903] [] ? _raw_spin_unlock+0x22/0x30 > [0.053759] [] ? up+0x1b/0x70 > [0.054421] [] __cond_resched+0x1b/0x30 > [0.055228] [] _cond_resched+0x45/0x50 > [0.056020] [] mutex_lock_nested+0x28/0x370 > [0.056884] [] ? console_unlock+0x3a2/0x4e0 > [0.057741] [] __irq_alloc_descs+0x39/0x1c0 > [0.058589] [] io_apic_setup_irq_pin+0x2c/0x310 > [0.060042] [] setup_IO_APIC+0x101/0x744 > [0.060878] [] ? clear_IO_APIC+0x31/0x50 > [0.061695] [] native_smp_prepare_cpus+0x538/0x680 > [0.062644] [] ? do_one_initcall+0x12c/0x12c > [0.063517] [] ? do_one_initcall+0x12c/0x12c > [0.064016] [] kernel_init+0x4b/0x17f > [0.064790] [] ? do_one_initcall+0x12c/0x12c > [0.065660] [] kernel_thread_helper+0x6/0x10 > > It was caused by that: > > native_smp_prepare_cpus() > preempt_disable() //preempt_count++ > mutex_lock()//in __irq_alloc_descs > __might_sleep() //system is booting, avoid check > might_resched() > __schedule() > preempt_disable() //preempt_count++ > schedule_bug() //preempt_count > 1, report bug > > The __might_sleep() avoid check on atomic sleeping until the system booted > while the schedule_bug() doesn't, it's the reason for the bug. > > This patch will add one additional check in schedule_bug() to avoid check > until the system booted, so the check on atomic sleeping will be unified. > > Signed-off-by: Michael Wang > Tested-by: Fengguang Wu > --- > kernel/sched/core.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 4376c9f..3396c33 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3321,7 +3321,8 @@ static inline void schedule_debug(struct task_struct > *prev) >* schedule() atomically, we ignore that path for now. >* Otherwise, whine if we are scheduling when we should not be. >*/ > - if (unlikely(in_atomic_preempt_off() && !prev->exit_state)) > + if (unlikely(in_atomic_preempt_off() && !prev->exit_state > + && system_state == SYSTEM_RUNNING)) > __schedule_bug(prev); > rcu_sleep_check(); > No this is very very wrong.. we avoid the might_sleep bug on ! SYSTEM_RUNNING because while we _might_ sleep, we should _never_ actually sleep under those conditions. So hitting a schedule() here is an actual bug. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] Staging: ipack/devices/ipoctal: acknowledge BREAK condition.
On Thu, 2012-09-13 at 13:02 +0300, Dan Carpenter wrote: > On Thu, Sep 13, 2012 at 11:46:27AM +0200, Samuel Iglesias Gonsalvez wrote: > > Clear the BREAK flag from the ISR register. > > > > Signed-off-by: Samuel Iglesias Gonsalvez > > What are the user visible effects of this bugfix? > It clears the BREAK flag in the device and avoid to read wrongly the same condition later. I should have described better this commit message. I will sent a second version editing this commit message. Thanks, Sam signature.asc Description: This is a digitally signed message part
Re: [PATCH] memory cgroup: update root memory cgroup when node is onlined
(2012/09/13 16:14), 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:
[ 63.413436] BUG: unable to handle kernel NULL pointer dereference at
0f60
[ 63.414161] IP: [] __mod_zone_page_state+0x9/0x60
[ 63.414161] PGD 0
[ 63.414161] Oops: [#1] SMP
[ 63.414161] Modules linked in: acpi_memhotplug binfmt_misc dm_mirror
dm_region_hash dm_log dm_mod ppdev sg microcode pcspkr virtio_console
virtio_balloon snd_intel8x0 snd_ac9
7_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore
snd_page_alloc e1000 i2c_piix4 i2c_core floppy parport_pc parport sr_mod cdrom
virtio_blk pata_acpi ata_g
eneric ata_piix libata scsi_mod
[ 63.414161] CPU 2
[ 63.414161] Pid: 1219, comm: numactl Not tainted 3.6.0-rc5+ #180 Bochs Bochs
...
[ 63.414161] Process numactl (pid: 1219, threadinfo 880039abc000, task
8800383c4ce0)
[ 63.414161] Stack:
[ 63.414161] 880039abdaf8 8117390f 880039abdaf8
8167c601
[ 63.414161] 81174162 88003a480f00 0001
8800395e
[ 63.414161] 88003dbd0e80 0282 880039abdb48
81174181
[ 63.414161] Call Trace:
[ 63.414161] [] __pagevec_lru_add_fn+0xdf/0x140
[ 63.414161] [] ? pagevec_lru_move_fn+0x92/0x100
[ 63.414161] [] pagevec_lru_move_fn+0xb1/0x100
[ 63.414161] [] ? lru_add_page_tail+0x1b0/0x1b0
[ 63.414161] [] ? exec_mmap+0x121/0x230
[ 63.414161] [] __pagevec_lru_add+0x1c/0x30
[ 63.414161] [] lru_add_drain_cpu+0xa3/0x130
[ 63.414161] [] lru_add_drain+0x2f/0x40
[ 63.414161] [] exit_mmap+0x69/0x160
[ 63.414161] [] ? lock_release_holdtime+0x35/0x1a0
[ 63.414161] [] mmput+0x77/0x100
[ 63.414161] [] exec_mmap+0x170/0x230
[ 63.414161] [] flush_old_exec+0xd2/0x140
[ 63.414161] [] load_elf_binary+0x32a/0xe70
[ 63.414161] [] ? trace_hardirqs_off+0xd/0x10
[ 63.414161] [] ? local_clock+0x6f/0x80
[ 63.414161] [] ? lock_release_holdtime+0x35/0x1a0
[ 63.414161] [] ? __lock_release+0x133/0x1a0
[ 63.414161] [] ? search_binary_handler+0x1a7/0x4a0
[ 63.414161] [] search_binary_handler+0x1b3/0x4a0
[ 63.414161] [] ? search_binary_handler+0x54/0x4a0
[ 63.414161] [] ? set_brk+0xe0/0xe0
[ 63.414161] [] do_execve_common+0x26f/0x320
[ 63.414161] [] ? kmem_cache_alloc+0x113/0x220
[ 63.414161] [] do_execve+0x3a/0x40
[ 63.414161] [] sys_execve+0x4a/0x80
[ 63.414161] [] stub_execve+0x6c/0xc0
[ 63.414161] Code: ff 03 00 00 48 c1 e7 0b 48 c1 e2 07 48 29 d7 48 03 3c c5 c0 27
d2 81 e8 a6 fe ff ff c9 c3 0f 1f 40 00 55 48 89 e5 0f 1f 44 00 00 <48> 8b 4f 60
89 f6 48 8d 44 31 40 65 44 8a 40 02 45 0f be c0 41
The reason is that we don't update
root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone
when onlining the node, and we try to access it.
Signed-off-by: Wen Congyang
Reported-by: Tang Chen
Thank you !!!
But, I think, all memcg's lruvec should be updated.
I guess you'll see panic again if you put tasks under memcg and
allocates memory on a new node.
Could you dig more ?
Thanks,
-Kame
---
include/linux/memcontrol.h |7 +++
mm/memcontrol.c| 14 ++
mm/memory_hotplug.c|2 ++
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 8d9489f..87d8b77 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -182,6 +182,9 @@ unsigned long mem_cgroup_soft_limit_reclaim(struct zone
*zone, int order,
unsigned long *total_scanned);
void mem_cgroup_count_vm_event(struct mm_struct *mm, enum vm_event_item idx);
+
+void update_root_mem_cgroup(int nid);
+
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
void mem_cgroup_split_huge_fixup(struct page *head);
#endif
@@ -374,6 +377,10 @@ static inline void mem_cgroup_replace_page_cache(struct
page *oldpage,
struct page *newpage)
{
}
+
+static inline void update_root_mem_cgroup(int nid)
+{
+}
#endif /* CONFIG_MEMCG */
#if !defined(CONFIG_MEMCG) || !defined(CONFIG_DEBUG_VM)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 795e525..c997a46 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3427,6 +3427,20 @@ void mem_cgroup_replace_page_cache(struct page *oldpage,
__mem_cgroup_commit_charge(memcg, newpage, 1, type, true);
}
+/* NODE_DATA(nid) is changed */
+void update_root_mem_cgroup(int nid)
+{
+ struct mem_cgroup_per_node *pn;
+ struct mem_cgroup_per_zone *mz;
+ int zone;
+
+ pn = root_mem_cgroup->info.nodeinfo[nid];
+ for (zone = 0; zone < MAX_NR_ZONES; zone++) {
+ mz =
[PATCH 2/3] GFS2: Fix missing allocation data for set/remove xattr
These entry points were missed in the original patch to allocate
this data structure.
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 4ce22e5..753af3d 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -1722,7 +1722,9 @@ static int gfs2_setxattr(struct dentry *dentry, const
char *name,
gfs2_holder_init(ip->i_gl, LM_ST_EXCLUSIVE, 0, );
ret = gfs2_glock_nq();
if (ret == 0) {
- ret = generic_setxattr(dentry, name, data, size, flags);
+ ret = gfs2_rs_alloc(ip);
+ if (ret == 0)
+ ret = generic_setxattr(dentry, name, data, size, flags);
gfs2_glock_dq();
}
gfs2_holder_uninit();
@@ -1757,7 +1759,9 @@ static int gfs2_removexattr(struct dentry *dentry, const
char *name)
gfs2_holder_init(ip->i_gl, LM_ST_EXCLUSIVE, 0, );
ret = gfs2_glock_nq();
if (ret == 0) {
- ret = generic_removexattr(dentry, name);
+ ret = gfs2_rs_alloc(ip);
+ if (ret == 0)
+ ret = generic_removexattr(dentry, name);
gfs2_glock_dq();
}
gfs2_holder_uninit();
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] GFS2: Take account of blockages when using reserved blocks
The claim_reserved_blks() function was not taking account of
the possibility of "blockages" while performing allocation.
This can be caused by another node allocating something in
the same extent which has been reserved locally.
This patch tests for this condition and then skips the remainder
of the reservation in this case. This is a relatively rare event,
so that it should not affect the general performance improvement
which the block reservations provide.
The claim_reserved_blks() function also appears not to be able
to deal with reservations which cross bitmap boundaries, but
that can be dealt with in a future patch since we don't generate
boundary crossing reservations currently.
Signed-off-by: Steven Whitehouse
Reported-by: David Teigland
Cc: Bob Peterson
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 4d34887..c9ed814 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1961,7 +1961,7 @@ static void gfs2_rgrp_error(struct gfs2_rgrpd *rgd)
* @dinode: 1 if this block is a dinode block, otherwise data block
* @nblocks: desired extent length
*
- * Lay claim to previously allocated block reservation blocks.
+ * Lay claim to previously reserved blocks.
* Returns: Starting block number of the blocks claimed.
* Sets *nblocks to the actual extent length allocated.
*/
@@ -1970,19 +1970,17 @@ static u64 claim_reserved_blks(struct gfs2_inode *ip,
bool dinode,
{
struct gfs2_blkreserv *rs = ip->i_res;
struct gfs2_rgrpd *rgd = rs->rs_rgd;
- struct gfs2_sbd *sdp = GFS2_SB(>i_inode);
struct gfs2_bitmap *bi;
u64 start_block = gfs2_rs_startblk(rs);
const unsigned int elen = *nblocks;
- /*BUG_ON(!gfs2_glock_is_locked_by_me(ip->i_gl));*/
- gfs2_assert_withdraw(sdp, rgd);
- /*BUG_ON(!gfs2_glock_is_locked_by_me(rgd->rd_gl));*/
bi = rs->rs_bi;
gfs2_trans_add_bh(rgd->rd_gl, bi->bi_bh, 1);
for (*nblocks = 0; *nblocks < elen && rs->rs_free; (*nblocks)++) {
- /* Make sure the bitmap hasn't changed */
+ if (gfs2_testbit(rgd, bi->bi_bh->b_data + bi->bi_offset,
+bi->bi_len, rs->rs_biblk) != GFS2_BLKST_FREE)
+ break;
gfs2_setbit(rgd, bi->bi_clone, bi, rs->rs_biblk,
dinode ? GFS2_BLKST_DINODE : GFS2_BLKST_USED);
rs->rs_biblk++;
@@ -1991,20 +1989,12 @@ static u64 claim_reserved_blks(struct gfs2_inode *ip,
bool dinode,
BUG_ON(!rgd->rd_reserved);
rgd->rd_reserved--;
dinode = false;
- trace_gfs2_rs(ip, rs, TRACE_RS_CLAIM);
}
- if (!rs->rs_free) {
- struct gfs2_rgrpd *rgd = ip->i_res->rs_rgd;
-
+ trace_gfs2_rs(ip, rs, TRACE_RS_CLAIM);
+ if (!rs->rs_free || *nblocks != elen)
gfs2_rs_deltree(rs);
- /* -nblocks because we haven't returned to do the math yet.
- I'm doing the math backwards to prevent negative numbers,
- but think of it as:
- if (unclaimed_blocks(rgd) - *nblocks >= RGRP_RSRV_MINBLKS */
- if (unclaimed_blocks(rgd) >= RGRP_RSRV_MINBLKS + *nblocks)
- rg_mblk_search(rgd, ip);
- }
+
return start_block;
}
@@ -2037,34 +2027,34 @@ int gfs2_alloc_blocks(struct gfs2_inode *ip, u64 *bn,
unsigned int *nblocks,
if (ip->i_res->rs_requested == 0)
return -ECANCELED;
- /* Check if we have a multi-block reservation, and if so, claim the
- next free block from it. */
+ /* If we have a reservation, claim blocks from it. */
if (gfs2_rs_active(ip->i_res)) {
BUG_ON(!ip->i_res->rs_free);
rgd = ip->i_res->rs_rgd;
block = claim_reserved_blks(ip, dinode, nblocks);
- } else {
- rgd = ip->i_rgd;
+ if (*nblocks)
+ goto found_blocks;
+ }
- if (!dinode && rgrp_contains_block(rgd, ip->i_goal))
- goal = ip->i_goal - rgd->rd_data0;
- else
- goal = rgd->rd_last_alloc;
-
- blk = rgblk_search(rgd, goal, GFS2_BLKST_FREE, );
-
- /* Since all blocks are reserved in advance, this shouldn't
- happen */
- if (blk == BFITNOENT) {
- printk(KERN_WARNING "BFITNOENT, nblocks=%u\n",
- *nblocks);
- printk(KERN_WARNING "FULL=%d\n",
- test_bit(GBF_FULL, >rd_bits->bi_flags));
- goto rgrp_error;
- }
+ rgd = ip->i_rgd;
- block = gfs2_alloc_extent(rgd, bi, blk, dinode, nblocks);
+ if (!dinode && rgrp_contains_block(rgd, ip->i_goal))
+ goal = ip->i_goal - rgd->rd_data0;
+ else
+ goal =
GFS2: Pre-pull patch posting (fixes)
Hi, Here are three GFS2 fixes for the current kernel tree. These are all related to the block reservation code which was added at the merge window. That code will be getting an update at the forthcoming merge window too. In the mean time though there are a few smaller issues which should be fixed. The first patch resolves an issue with write sizes of greater than 32 bits with the size hinting code. The second ensures that the allocation data structure is initialised when using xattrs and the third takes into account allocations which may have been made by other nodes which affect a reservation on the local node, Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] GFS2: Make write size hinting code common
This collects up the write size hinting code which is used by the
block reservation subsystem into a single function. At the same
time this also corrects the rounding for this calculation.
Signed-off-by: Steven Whitehouse
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index d1d791e..382000f 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -323,6 +323,29 @@ static long gfs2_ioctl(struct file *filp, unsigned int
cmd, unsigned long arg)
}
/**
+ * gfs2_size_hint - Give a hint to the size of a write request
+ * @file: The struct file
+ * @offset: The file offset of the write
+ * @size: The length of the write
+ *
+ * When we are about to do a write, this function records the total
+ * write size in order to provide a suitable hint to the lower layers
+ * about how many blocks will be required.
+ *
+ */
+
+static void gfs2_size_hint(struct file *filep, loff_t offset, size_t size)
+{
+ struct inode *inode = filep->f_dentry->d_inode;
+ struct gfs2_sbd *sdp = GFS2_SB(inode);
+ struct gfs2_inode *ip = GFS2_I(inode);
+ size_t blks = (size + sdp->sd_sb.sb_bsize - 1) >>
sdp->sd_sb.sb_bsize_shift;
+ int hint = min_t(size_t, INT_MAX, blks);
+
+ atomic_set(>i_res->rs_sizehint, hint);
+}
+
+/**
* gfs2_allocate_page_backing - Use bmap to allocate blocks
* @page: The (locked) page to allocate backing for
*
@@ -382,8 +405,7 @@ static int gfs2_page_mkwrite(struct vm_area_struct *vma,
struct vm_fault *vmf)
if (ret)
return ret;
- atomic_set(>i_res->rs_sizehint,
- PAGE_CACHE_SIZE >> sdp->sd_sb.sb_bsize_shift);
+ gfs2_size_hint(vma->vm_file, pos, PAGE_CACHE_SIZE);
gfs2_holder_init(ip->i_gl, LM_ST_EXCLUSIVE, 0, );
ret = gfs2_glock_nq();
@@ -663,7 +685,8 @@ static ssize_t gfs2_file_aio_write(struct kiocb *iocb,
const struct iovec *iov,
if (ret)
return ret;
- atomic_set(>i_res->rs_sizehint, writesize >>
sdp->sd_sb.sb_bsize_shift);
+ gfs2_size_hint(file, pos, writesize);
+
if (file->f_flags & O_APPEND) {
struct gfs2_holder gh;
@@ -789,7 +812,7 @@ static long gfs2_fallocate(struct file *file, int mode,
loff_t offset,
if (unlikely(error))
goto out_uninit;
- atomic_set(>i_res->rs_sizehint, len >> sdp->sd_sb.sb_bsize_shift);
+ gfs2_size_hint(file, offset, len);
while (len > 0) {
if (len < bytes)
--
1.7.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] lockdep: Check if nested lock is actually held
Hey,
Op 13-09-12 11:59, Peter Zijlstra schreef:
> On Thu, 2012-09-13 at 11:39 +0200, Maarten Lankhorst wrote:
>> It is considered good form to lock the lock you claim to be nested in.
> Uhm yeah.. cute. You actually found a site where this triggered?
>
Not in mainline, I was working on some lockdep annotations for my work on
moving ttm reservations to base kernel, and I wrote a whole bunch of tests
to stress interaction between reservations and locks, one of the tests I
was doing was taking a spinlock without the nested object:
static void reservation_test_fence_nest_unreserved(void)
{
struct reservation_object o;
reservation_object_init();
spin_lock_nest_lock(_lock, );
spin_unlock(_lock);
}
I would have expected it to fail, and the patch fixed it. As a nice side effect
it also complained about another hack I was doing elsewhere with reservations to
tests for deadlocks, and it forced me to fix it in a slightly less hacky way.
~Maarten
--
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
At 09/13/2012 06:06 PM, Kamezawa Hiroyuki Wrote:
> (2012/09/13 16:14), 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:
>>
>> [ 63.413436] BUG: unable to handle kernel NULL pointer dereference
>> at 0f60
>> [ 63.414161] IP: [] __mod_zone_page_state+0x9/0x60
>> [ 63.414161] PGD 0
>> [ 63.414161] Oops: [#1] SMP
>> [ 63.414161] Modules linked in: acpi_memhotplug binfmt_misc
>> dm_mirror dm_region_hash dm_log dm_mod ppdev sg microcode pcspkr
>> virtio_console virtio_balloon snd_intel8x0 snd_ac9
>> 7_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd
>> soundcore snd_page_alloc e1000 i2c_piix4 i2c_core floppy parport_pc
>> parport sr_mod cdrom virtio_blk pata_acpi ata_g
>> eneric ata_piix libata scsi_mod
>> [ 63.414161] CPU 2
>> [ 63.414161] Pid: 1219, comm: numactl Not tainted 3.6.0-rc5+ #180
>> Bochs Bochs
>> ...
>> [ 63.414161] Process numactl (pid: 1219, threadinfo
>> 880039abc000, task 8800383c4ce0)
>> [ 63.414161] Stack:
>> [ 63.414161] 880039abdaf8 8117390f 880039abdaf8
>> 8167c601
>> [ 63.414161] 81174162 88003a480f00 0001
>> 8800395e
>> [ 63.414161] 88003dbd0e80 0282 880039abdb48
>> 81174181
>> [ 63.414161] Call Trace:
>> [ 63.414161] [] __pagevec_lru_add_fn+0xdf/0x140
>> [ 63.414161] [] ? pagevec_lru_move_fn+0x92/0x100
>> [ 63.414161] [] pagevec_lru_move_fn+0xb1/0x100
>> [ 63.414161] [] ? lru_add_page_tail+0x1b0/0x1b0
>> [ 63.414161] [] ? exec_mmap+0x121/0x230
>> [ 63.414161] [] __pagevec_lru_add+0x1c/0x30
>> [ 63.414161] [] lru_add_drain_cpu+0xa3/0x130
>> [ 63.414161] [] lru_add_drain+0x2f/0x40
>> [ 63.414161] [] exit_mmap+0x69/0x160
>> [ 63.414161] [] ? lock_release_holdtime+0x35/0x1a0
>> [ 63.414161] [] mmput+0x77/0x100
>> [ 63.414161] [] exec_mmap+0x170/0x230
>> [ 63.414161] [] flush_old_exec+0xd2/0x140
>> [ 63.414161] [] load_elf_binary+0x32a/0xe70
>> [ 63.414161] [] ? trace_hardirqs_off+0xd/0x10
>> [ 63.414161] [] ? local_clock+0x6f/0x80
>> [ 63.414161] [] ? lock_release_holdtime+0x35/0x1a0
>> [ 63.414161] [] ? __lock_release+0x133/0x1a0
>> [ 63.414161] [] ? search_binary_handler+0x1a7/0x4a0
>> [ 63.414161] [] search_binary_handler+0x1b3/0x4a0
>> [ 63.414161] [] ? search_binary_handler+0x54/0x4a0
>> [ 63.414161] [] ? set_brk+0xe0/0xe0
>> [ 63.414161] [] do_execve_common+0x26f/0x320
>> [ 63.414161] [] ? kmem_cache_alloc+0x113/0x220
>> [ 63.414161] [] do_execve+0x3a/0x40
>> [ 63.414161] [] sys_execve+0x4a/0x80
>> [ 63.414161] [] stub_execve+0x6c/0xc0
>> [ 63.414161] Code: ff 03 00 00 48 c1 e7 0b 48 c1 e2 07 48 29 d7 48
>> 03 3c c5 c0 27 d2 81 e8 a6 fe ff ff c9 c3 0f 1f 40 00 55 48 89 e5 0f
>> 1f 44 00 00 <48> 8b 4f 60 89 f6 48 8d 44 31 40 65 44 8a 40 02 45 0f be
>> c0 41
>>
>> The reason is that we don't update
>> root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone
>> when onlining the node, and we try to access it.
>>
>> Signed-off-by: Wen Congyang
>> Reported-by: Tang Chen
>
> Thank you !!!
>
> But, I think, all memcg's lruvec should be updated.
> I guess you'll see panic again if you put tasks under memcg and
> allocates memory on a new node.
>
> Could you dig more ?
OK, I will do it.
Thanks
Wen Congyang
>
> Thanks,
> -Kame
>
>> ---
>> include/linux/memcontrol.h |7 +++
>> mm/memcontrol.c| 14 ++
>> mm/memory_hotplug.c|2 ++
>> 3 files changed, 23 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index 8d9489f..87d8b77 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -182,6 +182,9 @@ unsigned long mem_cgroup_soft_limit_reclaim(struct
>> zone *zone, int order,
>> unsigned long *total_scanned);
>>
>> void mem_cgroup_count_vm_event(struct mm_struct *mm, enum
>> vm_event_item idx);
>> +
>> +void update_root_mem_cgroup(int nid);
>> +
>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> void mem_cgroup_split_huge_fixup(struct page *head);
>> #endif
>> @@ -374,6 +377,10 @@ static inline void
>> mem_cgroup_replace_page_cache(struct page *oldpage,
>> struct page *newpage)
>> {
>> }
>> +
>> +static inline void update_root_mem_cgroup(int nid)
>> +{
>> +}
>> #endif /* CONFIG_MEMCG */
>>
>> #if !defined(CONFIG_MEMCG) || !defined(CONFIG_DEBUG_VM)
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 795e525..c997a46 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -3427,6 +3427,20 @@ void mem_cgroup_replace_page_cache(struct
Re: [PATCH 4/5] video:omap3isp:fix up ENOIOCTLCMD error handling
Hi Wanlong, Thanks for the patch. On Monday 27 August 2012 15:23:15 Wanlong Gao wrote: > At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be > translated as ENOTTY to user mode. > > Cc: Laurent Pinchart > Cc: Mauro Carvalho Chehab > Cc: linux-me...@vger.kernel.org > Signed-off-by: Wanlong Gao > --- > drivers/media/video/omap3isp/ispvideo.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/media/video/omap3isp/ispvideo.c > b/drivers/media/video/omap3isp/ispvideo.c index b37379d..2dd982e 100644 > --- a/drivers/media/video/omap3isp/ispvideo.c > +++ b/drivers/media/video/omap3isp/ispvideo.c > @@ -337,7 +337,7 @@ __isp_video_get_format(struct isp_video *video, struct > v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; > ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, ); > if (ret == -ENOIOCTLCMD) > - ret = -EINVAL; > + ret = -ENOTTY; I don't think this location should be changed. __isp_video_get_format() is called by isp_video_check_format() only, which in turn is called by isp_video_streamon() only. A failure to retrieve the format in __isp_video_get_format() does not really mean the VIDIOC_STREAMON is not supported. I'll apply hunks 2 to 5 and drop hunk 1 if that's fine with you. > > mutex_unlock(>mutex); > > @@ -723,7 +723,7 @@ isp_video_try_format(struct file *file, void *fh, struct > v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; > ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, ); > if (ret) > - return ret == -ENOIOCTLCMD ? -EINVAL : ret; > + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; > > isp_video_mbus_to_pix(video, , >fmt.pix); > return 0; > @@ -744,7 +744,7 @@ isp_video_cropcap(struct file *file, void *fh, struct > v4l2_cropcap *cropcap) ret = v4l2_subdev_call(subdev, video, cropcap, > cropcap); > mutex_unlock(>mutex); > > - return ret == -ENOIOCTLCMD ? -EINVAL : ret; > + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; > } > > static int > @@ -771,7 +771,7 @@ isp_video_get_crop(struct file *file, void *fh, struct > v4l2_crop *crop) format.which = V4L2_SUBDEV_FORMAT_ACTIVE; > ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, ); > if (ret < 0) > - return ret == -ENOIOCTLCMD ? -EINVAL : ret; > + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; > > crop->c.left = 0; > crop->c.top = 0; > @@ -796,7 +796,7 @@ isp_video_set_crop(struct file *file, void *fh, struct > v4l2_crop *crop) ret = v4l2_subdev_call(subdev, video, s_crop, crop); > mutex_unlock(>mutex); > > - return ret == -ENOIOCTLCMD ? -EINVAL : ret; > + return ret == -ENOIOCTLCMD ? -ENOTTY : ret; > } > > static int -- Regards, Laurent Pinchart -- 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] media: v4l2-ctrls: add control for test pattern
Hi Sakari,
On Sunday 09 September 2012 10:40:17 Sakari Ailus wrote:
> On Sat, Sep 08, 2012 at 01:11:04PM +0200, Hans Verkuil wrote:
> > On Fri September 7 2012 20:20:51 Sakari Ailus wrote:
> > > Prabhakar Lad wrote:
> > > > From: Lad, Prabhakar
> > > >
> > > > add V4L2_CID_TEST_PATTERN of type menu, which determines
> > > > the internal test pattern selected by the device.
> > > >
> > > > Signed-off-by: Lad, Prabhakar
> > > > Signed-off-by: Manjunath Hadli
> > > > Cc: Sakari Ailus
> > > > Cc: Hans Verkuil
> > > > Cc: Laurent Pinchart
> > > > Cc: Mauro Carvalho Chehab
> > > > Cc: Sylwester Nawrocki
> > > > Cc: Hans de Goede
> > > > Cc: Kyungmin Park
> > > > Cc: Rob Landley
> > > > ---
> > > > This patches has one checkpatch warning for line over
> > > > 80 characters altough it can be avoided I have kept it
> > > > for consistency.
> > > >
> > > > Changes for v2:
> > > > 1: Included display devices in the description for test pattern
> > > > as pointed by Hans.
> > > >
> > > > 2: In the menu replaced 'Test Pattern Disabled' by 'Disabled' as
> > > > pointed by Sylwester.
> > > >
> > > > 3: Removed the test patterns from menu as the are hardware specific
> > > > as pointed by Sakari.
> > > >
> > > > Documentation/DocBook/media/v4l/controls.xml | 20
> > > > drivers/media/v4l2-core/v4l2-ctrls.c |8
> > > > include/linux/videodev2.h|4
> > > > 3 files changed, 32 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/Documentation/DocBook/media/v4l/controls.xml
> > > > b/Documentation/DocBook/media/v4l/controls.xml index ad873ea..173934e
> > > > 100644
> > > > --- a/Documentation/DocBook/media/v4l/controls.xml
> > > > +++ b/Documentation/DocBook/media/v4l/controls.xml
> > > > @@ -4311,6 +4311,26 @@ interface and may change in the future.
> > > >
> > > >
> > > >
> > > > +
> > > > +> > > spanname="id">V4L2_CID_TEST_PATTERN +
> > > >
> > > > menu
> > > > +
> > > > +
> > > > +The Capture/Display/Sensors have
> > > > the
> > > > capability
> > > > + to generate internal test patterns and this are hardware
> > > > specific. This
> > > > + test patterns are used to test a device is properly working
> > > > and
> > > > can generate
> > > > + the desired waveforms that
> > > > it supports.
> > > > +
> > > > +
> > > > +
> > > > +
> > > > +
> > > > +
> > > > V4L2_TEST_PATTERN_DISABLED
> > > > + Test pattern generation is disabled
> > > > +
> > > > +
> > > > +
> > > > +
> > > >
> > > >
> > > >
> > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> > > > b/drivers/media/v4l2-core/v4l2-ctrls.c index 8f2f40b..d731422 100644
> > > > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > > > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > > > @@ -430,6 +430,10 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > > > "Advanced",
> > > > NULL,
> > > > };
> > > > + static const char * const test_pattern[] = {
> > > > + "Disabled",
> > > > + NULL,
> > > > + };
> > > >
> > > > switch (id) {
> > > > case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> > > > @@ -509,6 +513,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > > > return jpeg_chroma_subsampling;
> > > > case V4L2_CID_DPCM_PREDICTOR:
> > > > return dpcm_predictor;
> > > > + case V4L2_CID_TEST_PATTERN:
> > > > + return test_pattern;
> > >
> > > I think it's not necessary to define test_pattern (nor be prepared to
> > > return it) since the menu is going to be device specific. So the driver
> > > is responsible for all of the menu items. Such menus are created using
> > > v4l2_ctrl_new_custom() instead of v4l2_ctrl_new_std_menu().
> > >
> > > Looks good to me otherwise.
> >
> > I would suggest that we *do* make this a standard control, but the menu
> > consists of just one item: "Disabled". After creating the control you can
> > just set the ctrl->qmenu pointer to the device-specific menu. I like
> > using standard controls because they guarantee standard naming and type
> > conventions. They are also easier to use in an application.
>
> That's not quite enough. Also menu_skip_mask and max also need to be
> replaced. In a general case min as well. It's easy to do mistakes in that
> --- how about a separate function for doing that? It'd be also nice to be
> able to use the existing standardised menu item strings, but that's just an
> extra plus.
Agreed. A way to create a standard menu control with driver-supplied menu
items would be a good addition to the control framework API.
> However I think it's beyond this patch, which
Re: [PATCH v4] media: v4l2-ctrls: add control for dpcm predictor
Hi Sakari, On Friday 07 September 2012 21:46:44 Sakari Ailus wrote: > > Could you replace the above with this text (with appropriate indentation > etc.) while keeping the reference to Wikipedia? > > --8<-- > Differential pulse-code modulation (DPCM) compression can be used to > compress the samples into fewer bits than they would otherwise require. > This is done by calculating the difference between consecutive samples > and outputting the difference which in average is much smaller than the > values of the samples themselves since there is generally lots of > correlation between adjacent pixels. In decompression the original > samples are reconstructed. The process isn't lossless as the encoded > sample size in bits is less than the original. > > Formats using DPCM compression include linkend="pixfmt-srggb10dpcm8" />. > > This control is used to select the predictor used to encode the samples. If I remember correctly this control will be used on the receiver side on DaVinci, to decode pixels not encode them. How is the predictor used in that case ? Must it match the predictor used on the encoding side ? If so I expect documentation to be available somewhere. The OMAP3 ISP supports both DPCM encoding and decoding, and documents the predictors as "- The simple predictor This predictor uses only the previous same color component value as a prediction value. Therefore, only two-pixel memory is required. - The advanced predictor This predictor uses four previous pixel values, when the prediction value is evaluated. This means that also the other color component values are used, when the prediction value has been defined." It also states the the simple predictor is preferred for 10-8-10 conversion, and the advanced predictor for 10-7-10 and 10-6-10 conversion. > The main difference between the simple and the advanced predictors is > image quality, with advanced predictor supposed to produce better > quality images as a result. Simple predictor can be used e.g. for > testing purposes. > --8<-- -- Regards, Laurent Pinchart -- 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] lockdep: Check if nested lock is actually held
On Thu, 2012-09-13 at 12:10 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 13-09-12 11:59, Peter Zijlstra schreef:
> > On Thu, 2012-09-13 at 11:39 +0200, Maarten Lankhorst wrote:
> >> It is considered good form to lock the lock you claim to be nested in.
> > Uhm yeah.. cute. You actually found a site where this triggered?
> >
> Not in mainline, I was working on some lockdep annotations for my work on
> moving ttm reservations to base kernel, and I wrote a whole bunch of tests
> to stress interaction between reservations and locks, one of the tests I
> was doing was taking a spinlock without the nested object:
>
> static void reservation_test_fence_nest_unreserved(void)
> {
> struct reservation_object o;
>
> reservation_object_init();
>
> spin_lock_nest_lock(_lock, );
> spin_unlock(_lock);
> }
>
> I would have expected it to fail, and the patch fixed it. As a nice side
> effect
> it also complained about another hack I was doing elsewhere with reservations
> to
> tests for deadlocks, and it forced me to fix it in a slightly less hacky way.
Nice.. thanks for noticing!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] media: v4l2-ctrl: add a helper function to modify the menu
Hi Prabhakar,
Thanks for the patch.
On Tuesday 11 September 2012 19:53:38 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> Add a helper function to modify the menu, max and default value
> to set.
>
> Signed-off-by: Lad, Prabhakar
> Signed-off-by: Manjunath Hadli
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Sylwester Nawrocki
> Cc: Laurent Pinchart
> Cc: Mauro Carvalho Chehab
> Cc: Hans de Goede
> Cc: Kyungmin Park
> Cc: Guennadi Liakhovetski
> Cc: Rob Landley
> ---
> Changes for v3:
> 1: Fixed style/grammer issues as pointed by Hans.
>Thanks Hans for providing the description.
>
> Changes for v2:
> 1: Fixed review comments from Hans, to have return type as
>void, add WARN_ON() for fail conditions, allow this fucntion
>to modify the menu of custom controls.
>
> Documentation/video4linux/v4l2-controls.txt | 29
> drivers/media/v4l2-core/v4l2-ctrls.c| 17 +++
> include/media/v4l2-ctrls.h | 11 ++
> 3 files changed, 57 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/video4linux/v4l2-controls.txt
> b/Documentation/video4linux/v4l2-controls.txt index 43da22b..01d0a82 100644
> --- a/Documentation/video4linux/v4l2-controls.txt
> +++ b/Documentation/video4linux/v4l2-controls.txt
> @@ -367,6 +367,35 @@ it to 0 means that all menu items are supported.
> You set this mask either through the v4l2_ctrl_config struct for a custom
> control, or by calling v4l2_ctrl_new_std_menu().
>
> +There are situations where menu items may be device specific. In such cases
> the
> +framework provides a helper function to change the menu:
> +
> +void v4l2_ctrl_modify_menu(struct v4l2_ctrl *ctrl, const char * const
> *qmenu,
> + s32 max, u32 menu_skip_mask, s32 def);
Sorry if this is a stupid question, but wouldn't it be better to add a
function to create a custom menu instead of modifying it afterwards ?
> +
> +A good example is the test pattern control for capture/display/sensors
> devices
> +that have the capability to generate test patterns. These test patterns are
> +hardware specific, so the contents of the menu will vary from device to
> device.
> +
> +This helper function is used to modify the menu, max, mask and the default
> +value of the control.
> +
> +Example:
> +
> + static const char * const test_pattern[] = {
> + "Disabled",
> + "Vertical Bars",
> + "Solid Black",
> + "Solid White",
> + NULL,
> + };
> + struct v4l2_ctrl *test_pattern_ctrl =
> + v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
> + V4L2_CID_TEST_PATTERN, V4L2_TEST_PATTERN_DISABLED, 0,
> + V4L2_TEST_PATTERN_DISABLED);
> +
> + v4l2_ctrl_modify_menu(test_pattern_ctrl, test_pattern, 3, 0,
> + V4L2_TEST_PATTERN_DISABLED);
>
> Custom Controls
> ===
--
Regards,
Laurent Pinchart
--
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/
rtl8192se: ping router gives mdev of 25387.102???
Hi everyone,
(please cc)
see $subject ...
No warning, nothing in the logs, but pinging my router I get
things like:
--- 192.168.0.1 ping statistics ---
376 packets transmitted, 315 received, +33 errors, 16% packet loss, time
405164ms
rtt min/avg/max/mdev = 0.873/10077.793/95935.698/25387.102 ms, pipe 68
or
--- 192.168.0.1 ping statistics ---
1252 packets transmitted, 1225 received, 2% packet loss, time 1252976ms
rtt min/avg/max/mdev = 0.941/764.171/19929.265/2758.225 ms, pipe 20
Has anyone *ever* seen a mdev of 25387.102 ms ???
At the same time I am pinging the same router from an iphone with a
steady stream of 40ms or so, no problem whatsoever ...
$ lspci -v -s 03:00.0
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB
Wireless LAN Controller (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device e020
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f050 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
That is with git from yesterday or so.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live and Debian Developer
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
`Ford, you're turning into a penguin. Stop it.'
--- Arthur experiences the improbability drive at work.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
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] perf record: Change error message on failure
Only report
No CONFIG_PERF_EVENTS=y kernel support configured?
if the syscall fails with ENOSYS. In other cases CONFIG_PERF_EVENTS is
set and might confuse users. The default message is now:
Not all events could be opened.
Signed-off-by: Robert Richter
---
tools/perf/builtin-record.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index ae7c1c9..0290c91 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -305,19 +305,19 @@ try_again:
error("sys_perf_event_open() syscall returned with %d
(%s). /bin/dmesg may provide additional information.\n",
err, strerror(err));
+ if (err == ENOSYS)
+ pr_err("No CONFIG_PERF_EVENTS=y kernel support
configured?\n");
#if defined(__i386__) || defined(__x86_64__)
- if (attr->type == PERF_TYPE_HARDWARE &&
- err == EOPNOTSUPP) {
+ else if (attr->type == PERF_TYPE_HARDWARE &&
+err == EOPNOTSUPP)
pr_err("No hardware sampling interrupt
available."
" No APIC? If so then you can boot the
kernel"
" with the \"lapic\" boot parameter to"
" force-enable it.\n");
- rc = -err;
- goto out;
- }
#endif
+ else
+ pr_err("Not all events could be opened.\n");
- pr_err("No CONFIG_PERF_EVENTS=y kernel support
configured?\n");
rc = -err;
goto out;
}
--
1.7.8.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: [PATCH 4/5] video:omap3isp:fix up ENOIOCTLCMD error handling
On 09/13/2012 12:03 PM, Laurent Pinchart wrote: > Hi Wanlong, > > Thanks for the patch. > > On Monday 27 August 2012 15:23:15 Wanlong Gao wrote: >> At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be >> translated as ENOTTY to user mode. >> >> Cc: Laurent Pinchart >> Cc: Mauro Carvalho Chehab >> Cc: linux-me...@vger.kernel.org >> Signed-off-by: Wanlong Gao >> --- >> drivers/media/video/omap3isp/ispvideo.c | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/drivers/media/video/omap3isp/ispvideo.c >> b/drivers/media/video/omap3isp/ispvideo.c index b37379d..2dd982e 100644 >> --- a/drivers/media/video/omap3isp/ispvideo.c >> +++ b/drivers/media/video/omap3isp/ispvideo.c >> @@ -337,7 +337,7 @@ __isp_video_get_format(struct isp_video *video, struct >> v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; >> ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, ); >> if (ret == -ENOIOCTLCMD) >> -ret = -EINVAL; >> +ret = -ENOTTY; > > I don't think this location should be changed. __isp_video_get_format() is > called by isp_video_check_format() only, which in turn is called by > isp_video_streamon() only. A failure to retrieve the format in > __isp_video_get_format() does not really mean the VIDIOC_STREAMON is not > supported. > > I'll apply hunks 2 to 5 and drop hunk 1 if that's fine with you. Fine, I defer to your great knowledge in this. Thanks, Wanlong Gao -- 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] perf, intel: Don't touch MSR_IA32_DEBUGCTLMSR from NMI context
On Wed, 2012-09-12 at 18:22 +0200, Peter Zijlstra wrote:
> Oleg and Sebastian found that touching MSR_IA32_DEBUGCTLMSR from NMI
> context is problematic since the only way to change the various
> unrelated bits in there is:
>
> debugctl = get_debugctlmsr()
> /* frob flags in debugctl */
> update_debugctlmsr(debugctl);
>
> Which is entirely unsafe if we prod at the MSR from NMI context.
>
> In particular the path that is responsible is:
>
> x86_pmu_handle_irq() (NMI handler)
> x86_pmu_stop()
> x86_pmu.disable -> intel_pmu_disable_event()
> intel_pmu_lbr_disable()
> __intel_pmu_lbr_disable()
> wrmsrl(MSR_IA32_DEBUGCTLMSR,... );
>
> So remove intel_pmu_lbr_{en,dis}able() from
> intel_pmu_{en,dis}able_event() and stick them in
> intel_{get,put}_event_constraints() which are only ever called from
> regular contexts.
>
> We combine intel_pmu_needs_lbr_smpl(), which tells us if the events
> wants LBR data, with event->hw.branch_reg.alloc, which given
> intel_shared_regs_constraints() is set if our event got the shared
> resource, to give us a correctly balanced condition in
> {get,put}_event_constraints() for intel_pmu_lbr_{en,dis}able().
>
> Also change core_pmu to only use x86_get_event_constraints since it
> doesn't support any of the fancy DS (BTS,PEBS), LBR and OFFCORE features
> that make up intel_{get,put}_event_constraints.
OK, so with the added stipulation that touching the MSR from the NMI
isn't a problem as long as we ensure we leave the MSR in the same state
that we found it in, and the above is the only path found so far that
could cause this to be violated, the patch is fine?
In particular we could note that both LBR and BTS use the DEBUGCTL MSR,
but BTS doesn't throttle, so the LBR code is the only thing needing
attention as per the above description.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote: > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > > On Tue, 28 Aug 2012, Rob Herring wrote: > > > You should look at ePAPR 1.1 which defines hypervisor related bindings. > > > While it is a PPC doc, we should reuse or extend what makes sense. > > > > > > See section 7.5: > > > > > > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf > > > > Thanks for the link, I wasn't aware of ePAPR. > > > > The hypervisor node defined by ePAPR is not very different from what I > > am proposing. Should I try to be compatible with the hypervisor > > specification above (as in compatible = "epapr,hypervisor-1.1")? > > Or should I just use it as a reference for my own specification? > > > > Personally I would rather avoid full compatibility with ePAPR. > > In particular reading section 7.5, these are the required properties of > the ePAPR hypervisor node: > > - compatible = "epapr,hypervisor-1.1" > compared to what I am proposing, it is laking information about what > hypervisor we are talking about (xen, kvm, vmware, etc) and the version > of the ABI (xen-4.2). > > - hcall-instructions > potentially interesting, but given that for Xen we are quite happy with > HVC, we are not going to add any secondary hypercall mechanisms, > therefore at the moment it would just result in a BUG if the specified > hcall instruction is != HVC. Besides if somebody else wanted to > implemented the Xen hypercall interface in a different way they could > just reimplement the hypercall wrappers, that would be easier than > trying to do it with this property. Some thoughts on this: We decided that embedding machine instructions into the DT is a fairly awful idea when discussing how to describe low-level debug UARTs in the DT. I don't think it's a lot better in this case (never mind issues like ARM versus Thumb, endianness etc.) If we are going to attempt to describe the call interface, we should do it symbolically, allowing the hypervisor interface code in the kernel to choose (or, if necessary, generate) the right call wrappers. We will have this issue for descrbing power firmware interfaces for example: we already know that this functionality might require an SMC or HVC instruction to call it, depending on the platform. A hypervisor with only one call ABI could leave this to be implicit, providing there is a version number property of similar to allow future changes to be accommodated. Cheers ---Dave -- 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] sched: nohz_idle_balance
On Thu, 2012-09-13 at 10:19 +0200, Peter Zijlstra wrote: > On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote: > > On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: > > > On tickless system, one CPU runs load balance for all idle CPUs. > > > The cpu_load of this CPU is updated before starting the load balance > > > of each other idle CPUs. We should instead update the cpu_load of the > > > balance_cpu. > > > > > > Signed-off-by: Vincent Guittot > > > --- > > > kernel/sched/fair.c | 11 ++- > > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > index 1ca4fe4..9ae3a5b 100644 > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -4794,14 +4794,15 @@ static void nohz_idle_balance(int this_cpu, enum > > > cpu_idle_type idle) > > > if (need_resched()) > > > break; > > > > > > - raw_spin_lock_irq(_rq->lock); > > > - update_rq_clock(this_rq); > > > - update_idle_cpu_load(this_rq); > > > - raw_spin_unlock_irq(_rq->lock); > > > + rq = cpu_rq(balance_cpu); > > > + > > > + raw_spin_lock_irq(>lock); > > > + update_rq_clock(rq); > > > + update_idle_cpu_load(rq); > > > + raw_spin_unlock_irq(>lock); > > > > > > rebalance_domains(balance_cpu, CPU_IDLE); > > > > > > - rq = cpu_rq(balance_cpu); > > > if (time_after(this_rq->next_balance, rq->next_balance)) > > > this_rq->next_balance = rq->next_balance; > > > } > > > > Ew, banging locks and updating clocks to what good end? > > Well, updating the load statistics on the cpu you're going to balance > seems like a good end to me.. ;-) No point updating the local statistics > N times and leaving the ones you're going to balance stale for god knows > how long. Sure, the goal is fine, but I wonder about the price vs payoff. I was thinking perhaps the redundant updates should go away instead, unless stats are shown to be causing real world pain. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Wed, Sep 12, 2012 at 09:34:28PM -0500, Rob Herring wrote: > On 09/12/2012 01:14 PM, Stefano Stabellini wrote: > > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > >> On Tue, 28 Aug 2012, Rob Herring wrote: > >>> You should look at ePAPR 1.1 which defines hypervisor related bindings. > >>> While it is a PPC doc, we should reuse or extend what makes sense. > >>> > >>> See section 7.5: > >>> > >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf > >> > >> Thanks for the link, I wasn't aware of ePAPR. > >> > >> The hypervisor node defined by ePAPR is not very different from what I > >> am proposing. Should I try to be compatible with the hypervisor > >> specification above (as in compatible = "epapr,hypervisor-1.1")? > >> Or should I just use it as a reference for my own specification? > >> > >> Personally I would rather avoid full compatibility with ePAPR. > > > > In particular reading section 7.5, these are the required properties of > > the ePAPR hypervisor node: > > > > - compatible = "epapr,hypervisor-1.1" > > compared to what I am proposing, it is laking information about what > > hypervisor we are talking about (xen, kvm, vmware, etc) and the version > > of the ABI (xen-4.2). > > compatible properties are often changed. If we do deviate on the rest of > the binding, then it needs to be different. > > Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor" > doesn't even appear in the kernel. > > We also perhaps have to consider the possibility of Xen on PowerPC. Then > alignment is more important. > > > - hcall-instructions > > potentially interesting, but given that for Xen we are quite happy with > > HVC, we are not going to add any secondary hypercall mechanisms, > > therefore at the moment it would just result in a BUG if the specified > > hcall instruction is != HVC. Besides if somebody else wanted to > > implemented the Xen hypercall interface in a different way they could > > just reimplement the hypercall wrappers, that would be easier than > > trying to do it with this property. > > It's really about the parameters passed with the HVC. The ePAPR may be a > good model for defining this. Just grepping "hypervisor" under > arch/powerpc, it's pretty clear hypervisor support happened first and > the ePAPR came second. Hopefully we can avoid that for ARM. Do you think it's feasible to standardise on some interoperable ABI for kvm and Xen? This sounds pretty optimistic, but I'm not aware of all the technicalities, or what possible third-party hypervisors are out there. If we could do it, it would be good. But I have my doubts about the feasibility and the benefits. If different hypervisors are significantly imcompatible, then having a common low-level ABI doesn't help all that much. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] Staging: ipack: move the responsibility to clear interrupts to the IPack devices.
From: Jens Taprogge
Now the IPack device acknowledges its own IRQ.
Signed-off-by: Jens Taprogge
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/bridges/tpci200.c |4
drivers/staging/ipack/devices/ipoctal.c | 19 +--
drivers/staging/ipack/devices/scc2698.h |3 +++
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ipack/bridges/tpci200.c
b/drivers/staging/ipack/bridges/tpci200.c
index 3462783..43f2f38 100644
--- a/drivers/staging/ipack/bridges/tpci200.c
+++ b/drivers/staging/ipack/bridges/tpci200.c
@@ -126,10 +126,6 @@ static irqreturn_t tpci200_slot_irq(struct slot_irq
*slot_irq)
return -ENODEV;
ret = slot_irq->handler(slot_irq->arg);
- /* Clear the IPack device interrupt */
- readw(slot_irq->holder->io_space.address + 0xC0);
- readw(slot_irq->holder->io_space.address + 0xC2);
-
return ret;
}
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 0292364..30d8d42 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -252,6 +252,10 @@ static irqreturn_t ipoctal_irq_handler(void *arg)
for (i = 0; i < NR_CHANNELS; i++)
ipoctal_irq_channel(>channel[i]);
+ /* Clear the IPack device interrupt */
+ readw(ipoctal->dev->int_space.address + ACK_INT_REQ0);
+ readw(ipoctal->dev->int_space.address + ACK_INT_REQ1);
+
return IRQ_HANDLED;
}
@@ -264,7 +268,6 @@ static int ipoctal_check_model(struct ipack_device *dev,
unsigned char *id)
manufacturerID = ioread8(dev->id_space.address +
IPACK_IDPROM_OFFSET_MANUFACTURER_ID);
if (manufacturerID != IPACK1_VENDOR_ID_SBS)
return -ENODEV;
-
board_id = ioread8(dev->id_space.address + IPACK_IDPROM_OFFSET_MODEL);
switch (board_id) {
case IPACK1_DEVICE_ID_SBS_OCTAL_232:
@@ -322,13 +325,22 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
goto out_unregister_id_space;
}
+ res = ipoctal->dev->bus->ops->map_space(ipoctal->dev, 0,
+ IPACK_INT_SPACE);
+ if (res) {
+ dev_err(>dev->dev,
+ "Unable to map slot [%d:%d] INT space!\n",
+ bus_nr, slot);
+ goto out_unregister_io_space;
+ }
+
res = ipoctal->dev->bus->ops->map_space(ipoctal->dev,
0x8000, IPACK_MEM_SPACE);
if (res) {
dev_err(>dev->dev,
"Unable to map slot [%d:%d] MEM space!\n",
bus_nr, slot);
- goto out_unregister_io_space;
+ goto out_unregister_int_space;
}
/* Save the virtual address to access the registers easily */
@@ -450,6 +462,8 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
out_unregister_slot_unmap:
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_ID_SPACE);
+out_unregister_int_space:
+ ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_INT_SPACE);
out_unregister_io_space:
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_IO_SPACE);
out_unregister_id_space:
@@ -735,6 +749,7 @@ static void __ipoctal_remove(struct ipoctal *ipoctal)
tty_unregister_driver(ipoctal->tty_drv);
put_tty_driver(ipoctal->tty_drv);
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_MEM_SPACE);
+ ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_INT_SPACE);
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_IO_SPACE);
ipoctal->dev->bus->ops->unmap_space(ipoctal->dev, IPACK_ID_SPACE);
kfree(ipoctal);
diff --git a/drivers/staging/ipack/devices/scc2698.h
b/drivers/staging/ipack/devices/scc2698.h
index 223838a..96e8d8c 100644
--- a/drivers/staging/ipack/devices/scc2698.h
+++ b/drivers/staging/ipack/devices/scc2698.h
@@ -221,4 +221,7 @@ union scc2698_block {
#define ISR_DELTA_BREAK_B (0x1 << 6)
#define ISR_INPUT_PORT_CHANGE (0x1 << 7)
+#define ACK_INT_REQ0 0
+#define ACK_INT_REQ1 2
+
#endif /* SCC2698_H_ */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] Staging: ipack/devices/ipoctal: simplify ipoctal_write_tty()
Remove count_wr and the assigment of nb_bytes = 0 in that function as is
useless. Now it returns the count of the characters actually sent.
There is other nb_bytes = 0 deleted that has a duplicate a few lines before.
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/devices/ipoctal.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 164e43c..2cdbf28 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -33,7 +33,6 @@ static const struct tty_operations ipoctal_fops;
struct ipoctal_channel {
struct ipoctal_statsstats;
unsigned intnb_bytes;
- unsigned intcount_wr;
wait_queue_head_t queue;
spinlock_t lock;
unsigned intpointer_read;
@@ -189,7 +188,6 @@ static void ipoctal_irq_tx(struct ipoctal_channel *channel)
value = channel->tty_port.xmit_buf[*pointer_write];
iowrite8(value, >regs->w.thr);
channel->stats.tx++;
- channel->count_wr++;
(*pointer_write)++;
*pointer_write = *pointer_write % PAGE_SIZE;
channel->nb_bytes--;
@@ -445,7 +443,6 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
spin_lock_init(>lock);
channel->pointer_read = 0;
channel->pointer_write = 0;
- channel->nb_bytes = 0;
tty_dev = tty_register_device(tty, i, NULL);
if (IS_ERR(tty_dev)) {
dev_err(>dev->dev, "Failed to register tty
device.\n");
@@ -500,11 +497,9 @@ static int ipoctal_write_tty(struct tty_struct *tty,
const unsigned char *buf, int count)
{
struct ipoctal_channel *channel = tty->driver_data;
+ unsigned int char_copied;
- channel->nb_bytes = 0;
- channel->count_wr = 0;
-
- ipoctal_copy_write_buffer(channel, buf, count);
+ char_copied = ipoctal_copy_write_buffer(channel, buf, count);
/* As the IP-OCTAL 485 only supports half duplex, do it manually */
if (channel->board_id == IPACK1_DEVICE_ID_SBS_OCTAL_485) {
@@ -521,7 +516,7 @@ static int ipoctal_write_tty(struct tty_struct *tty,
iowrite8(CR_DISABLE_TX, >regs->w.cr);
*channel->board_write = 0;
- return channel->count_wr;
+ return char_copied;
}
static int ipoctal_write_room(struct tty_struct *tty)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] staging: ipack: remove irq field in struct ipack_device.
From: Jens Taprogge
The field irq currently is identical to the slot number. It does not seem to
have any real use. The number is written to hardware in ipoctal but it seems
the value that is written does not matter.
Signed-off-by: Jens Taprogge
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/bridges/tpci200.c |9 ++---
drivers/staging/ipack/devices/ipoctal.c |9 +
drivers/staging/ipack/ipack.c |3 +--
drivers/staging/ipack/ipack.h |8 ++--
4 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/ipack/bridges/tpci200.c
b/drivers/staging/ipack/bridges/tpci200.c
index 43f2f38..bb8aa70 100644
--- a/drivers/staging/ipack/bridges/tpci200.c
+++ b/drivers/staging/ipack/bridges/tpci200.c
@@ -190,7 +190,7 @@ static int tpci200_free_irq(struct ipack_device *dev)
return 0;
}
-static int tpci200_request_irq(struct ipack_device *dev, int vector,
+static int tpci200_request_irq(struct ipack_device *dev,
irqreturn_t (*handler)(void *), void *arg)
{
int res = 0;
@@ -227,7 +227,6 @@ static int tpci200_request_irq(struct ipack_device *dev,
int vector,
* Read the User Manual of your IndustryPack device to know
* where to write the vector in memory.
*/
- slot_irq->vector = vector;
slot_irq->handler = handler;
slot_irq->arg = arg;
slot_irq->holder = dev;
@@ -715,12 +714,8 @@ static int tpci200_pci_probe(struct pci_dev *pdev,
tpci200->number = tpci200->info->ipack_bus->bus_nr;
dev_set_drvdata(>dev, tpci200);
- /*
-* Give the same IRQ number as the slot number.
-* The TPCI200 has assigned his own two IRQ by PCI bus driver
-*/
for (i = 0; i < TPCI200_NB_SLOT; i++)
- ipack_device_register(tpci200->info->ipack_bus, i, i);
+ ipack_device_register(tpci200->info->ipack_bus, i);
return 0;
out_err_bus_register:
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 30d8d42..9fc2f7f 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -288,7 +288,7 @@ static const struct tty_port_operations
ipoctal_tty_port_ops = {
};
static int ipoctal_inst_slot(struct ipoctal *ipoctal, unsigned int bus_nr,
-unsigned int slot, unsigned int vector)
+unsigned int slot)
{
int res = 0;
int i;
@@ -387,9 +387,10 @@ static int ipoctal_inst_slot(struct ipoctal *ipoctal,
unsigned int bus_nr,
* Depending of the carrier these addresses are accesible or not.
* More info in the datasheet.
*/
- ipoctal->dev->bus->ops->request_irq(ipoctal->dev, vector,
+ ipoctal->dev->bus->ops->request_irq(ipoctal->dev,
ipoctal_irq_handler, ipoctal);
- iowrite8(vector, ipoctal->dev->mem_space.address + 1);
+ /* Dummy write */
+ iowrite8(1, ipoctal->dev->mem_space.address + 1);
/* Register the TTY device */
@@ -722,7 +723,7 @@ static int ipoctal_probe(struct ipack_device *dev)
return -ENOMEM;
ipoctal->dev = dev;
- res = ipoctal_inst_slot(ipoctal, dev->bus_nr, dev->slot, dev->irq);
+ res = ipoctal_inst_slot(ipoctal, dev->bus_nr, dev->slot);
if (res)
goto out_uninst;
diff --git a/drivers/staging/ipack/ipack.c b/drivers/staging/ipack/ipack.c
index c83f015..d1e0651 100644
--- a/drivers/staging/ipack/ipack.c
+++ b/drivers/staging/ipack/ipack.c
@@ -427,7 +427,7 @@ out:
}
struct ipack_device *ipack_device_register(struct ipack_bus_device *bus,
- int slot, int irqv)
+ int slot)
{
int ret;
struct ipack_device *dev;
@@ -441,7 +441,6 @@ struct ipack_device *ipack_device_register(struct
ipack_bus_device *bus,
dev->dev.parent = bus->parent;
dev->slot = slot;
dev->bus_nr = bus->bus_nr;
- dev->irq = irqv;
dev->bus = bus;
dev_set_name(>dev,
"ipack-dev.%u.%u", dev->bus_nr, dev->slot);
diff --git a/drivers/staging/ipack/ipack.h b/drivers/staging/ipack/ipack.h
index f8405df..d8e3bb6 100644
--- a/drivers/staging/ipack/ipack.h
+++ b/drivers/staging/ipack/ipack.h
@@ -54,7 +54,6 @@ struct ipack_addr_space {
*
* @bus_nr: IP bus number where the device is plugged
* @slot: Slot where the device is plugged in the carrier board
- * @irq: IRQ vector
* @bus: ipack_bus_device where the device is plugged to.
* @id_space: Virtual address to ID space.
* @io_space: Virtual address to IO space.
@@ -68,7 +67,6 @@ struct ipack_addr_space {
struct ipack_device {
unsigned int bus_nr;
unsigned int slot;
- unsigned int irq;
struct ipack_bus_device
[PATCH v2 4/5] Staging: ipack/devices/ipoctal: acknowledge BREAK condition.
Clear the BREAK flag from the ISR register. Doing that, we avoid to read
the same condition for the next character received.
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/devices/ipoctal.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ipack/devices/ipoctal.c
b/drivers/staging/ipack/devices/ipoctal.c
index 9fc2f7f..164e43c 100644
--- a/drivers/staging/ipack/devices/ipoctal.c
+++ b/drivers/staging/ipack/devices/ipoctal.c
@@ -158,6 +158,7 @@ static void ipoctal_irq_rx(struct ipoctal_channel *channel,
flag = TTY_FRAME;
}
if (sr & SR_RECEIVED_BREAK) {
+ iowrite8(CR_CMD_RESET_BREAK_CHANGE,
>regs->w.cr);
channel->stats.rcv_break++;
flag = TTY_BREAK;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] Staging: ipack: Add IPACK_INT_SPACE memory space.
From: Jens Taprogge
This will allow us to correctly access the IPack INT space.
Signed-off-by: Jens Taprogge
Signed-off-by: Samuel Iglesias Gonsalvez
---
drivers/staging/ipack/bridges/tpci200.c | 29 +
drivers/staging/ipack/bridges/tpci200.h |2 ++
drivers/staging/ipack/ipack.h |2 ++
3 files changed, 33 insertions(+)
diff --git a/drivers/staging/ipack/bridges/tpci200.c
b/drivers/staging/ipack/bridges/tpci200.c
index 21b2b75..3462783 100644
--- a/drivers/staging/ipack/bridges/tpci200.c
+++ b/drivers/staging/ipack/bridges/tpci200.c
@@ -95,6 +95,8 @@ static void tpci200_unregister(struct tpci200_board *tpci200)
tpci200->slots[i].io_phys.size = 0;
tpci200->slots[i].id_phys.address = NULL;
tpci200->slots[i].id_phys.size = 0;
+ tpci200->slots[i].int_phys.address = NULL;
+ tpci200->slots[i].int_phys.size = 0;
tpci200->slots[i].mem_phys.address = NULL;
tpci200->slots[i].mem_phys.size = 0;
}
@@ -331,6 +333,11 @@ static int tpci200_register(struct tpci200_board *tpci200)
TPCI200_ID_SPACE_OFF + TPCI200_ID_SPACE_GAP*i;
tpci200->slots[i].id_phys.size = TPCI200_ID_SPACE_SIZE;
+ tpci200->slots[i].int_phys.address =
+ (void __iomem *)ioidint_base +
+ TPCI200_INT_SPACE_OFF + TPCI200_INT_SPACE_GAP * i;
+ tpci200->slots[i].int_phys.size = TPCI200_INT_SPACE_SIZE;
+
tpci200->slots[i].mem_phys.address =
(void __iomem *)mem_base + TPCI200_MEM8_GAP*i;
tpci200->slots[i].mem_phys.size = TPCI200_MEM8_SIZE;
@@ -391,6 +398,15 @@ static int tpci200_slot_unmap_space(struct ipack_device
*dev, int space)
}
virt_addr_space = >id_space;
break;
+ case IPACK_INT_SPACE:
+ if (dev->int_space.address == NULL) {
+ dev_info(>dev,
+"Slot [%d:%d] INT space not mapped !\n",
+dev->bus_nr, dev->slot);
+ goto out_unlock;
+ }
+ virt_addr_space = >int_space;
+ break;
case IPACK_MEM_SPACE:
if (dev->mem_space.address == NULL) {
dev_info(>dev,
@@ -460,6 +476,19 @@ static int tpci200_slot_map_space(struct ipack_device *dev,
phys_address = tpci200->slots[dev->slot].id_phys.address;
size_to_map = tpci200->slots[dev->slot].id_phys.size;
break;
+ case IPACK_INT_SPACE:
+ if (dev->int_space.address != NULL) {
+ dev_err(>dev,
+ "Slot [%d:%d] INT space already mapped !\n",
+ tpci200->number, dev->slot);
+ res = -EINVAL;
+ goto out_unlock;
+ }
+ virt_addr_space = >int_space;
+
+ phys_address = tpci200->slots[dev->slot].int_phys.address;
+ size_to_map = tpci200->slots[dev->slot].int_phys.size;
+ break;
case IPACK_MEM_SPACE:
if (dev->mem_space.address != NULL) {
dev_err(>dev,
diff --git a/drivers/staging/ipack/bridges/tpci200.h
b/drivers/staging/ipack/bridges/tpci200.h
index e1f60f3..235d1fe 100644
--- a/drivers/staging/ipack/bridges/tpci200.h
+++ b/drivers/staging/ipack/bridges/tpci200.h
@@ -132,6 +132,7 @@ struct slot_irq {
* @irqSlot IRQ infos
* @io_physIO physical base address register of the slot
* @id_physID physical base address register of the slot
+ * @int_phys INT physical base address register of the slot
* @mem_phys MEM physical base address register of the slot
*
*/
@@ -139,6 +140,7 @@ struct tpci200_slot {
struct slot_irq *irq;
struct ipack_addr_space io_phys;
struct ipack_addr_space id_phys;
+ struct ipack_addr_space int_phys;
struct ipack_addr_space mem_phys;
};
diff --git a/drivers/staging/ipack/ipack.h b/drivers/staging/ipack/ipack.h
index 9c3079d..f8405df 100644
--- a/drivers/staging/ipack/ipack.h
+++ b/drivers/staging/ipack/ipack.h
@@ -35,6 +35,7 @@ enum ipack_space {
IPACK_IO_SPACE= 0,
IPACK_ID_SPACE= 1,
IPACK_MEM_SPACE = 2,
+ IPACK_INT_SPACE,
};
/**
@@ -71,6 +72,7 @@ struct ipack_device {
struct ipack_bus_device *bus;
struct ipack_addr_space id_space;
struct ipack_addr_space io_space;
+ struct ipack_addr_space int_space;
struct ipack_addr_space mem_space;
struct device dev;
u8 *id;
--
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
Re: [PATCH 3/5] staging: ipack: remove irq field in struct ipack_device.
On Thu, 2012-09-13 at 13:01 +0300, Dan Carpenter wrote: > On Thu, Sep 13, 2012 at 11:46:26AM +0200, Samuel Iglesias Gonsalvez wrote: > > From: Jens Taprogge > > > > The field irq currently is identical to the slot number. It does not seem > > to > > have any real use. The number is written to hardware in ipoctal but it > > seems > > the value that is written does not matter. > > > > Signed-off-by: Jens Taprogge > > Signed-off-by: Samuel Iglesias Gonsalvez > > --- > > - iowrite8(vector, ipoctal->dev->mem_space.address + 1); > > + iowrite8(1, ipoctal->dev->mem_space.address + 1); > > It might be nice to put a /* dummy write */ comment here. > Added! Thanks for the suggestion, Sam signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] ARM: SoC: convert MSM SMP to SoC descriptor
On Wednesday 12 September 2012, David Brown wrote: > > From: Marc Zyngier > > Convert MSM SMP platforms to use the SoC descriptor to provide > their SMP and CPU hotplug operations. > > Cc: David Brown > Signed-off-by: Marc Zyngier > Signed-off-by: Arnd Bergmann > --- > This is an adaptation of this change on top of the msm-for-3.7 tree I > recently sent out a pull request for. The only real change is to > resolve the conflicts with the simplified board files. Not sure what I'm supposed to do with this patch, it doesn't apply unless I rebase all of the SMP patches on top of your msm-for-3.7 branch, which would be rather odd. I'll make sure the branches merge fine and then apply your patch 2/2 on top of the merge, ok? 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/
Re: [PATCH v9 10/13] ARM: SoC: convert imx6q to SoC descriptor
On Thursday 13 September 2012, Shawn Guo wrote: > > > > DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad (Device Tree)") > > + .smp= smp_ops(imx6q_soc_desc), > > s/imx6q_soc_desc/imx_smp_ops Yes, just noticed this myself when testing the series together with other patches. > Otherwise, > > Acked-by: Shawn Guo Thanks, 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/
Re: [PATCH v3 26/31] arm64: Miscellaneous library functions
On Wednesday 12 September 2012, Catalin Marinas wrote: > From 64ec78a2fce931e0148db90747c69688f248a531 Mon Sep 17 00:00:00 2001 > From: Catalin Marinas > Date: Wed, 12 Sep 2012 22:00:53 +0100 > Subject: [PATCH 1/2] Implement generic ffs/fls using __builtin_* functions > > This patch implements ffs, __ffs, fls, __fls using __builtin_* gcc > functions. These header files can be used by other architectures that > rely on the gcc builtins. > > Signed-off-by: Catalin Marinas > Cc: Arnd Bergmann Very good. Acked-by: Arnd Bergmann -- 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/4] i2c: introduce i2c-cbus driver
On Mon, Sep 03, 2012 at 11:23:22PM +0300, Aaro Koskinen wrote: > Add i2c driver to enable access to devices behind CBUS on Nokia Internet > Tablets. > > The patch also adds CBUS I2C configuration for N8x0 which is one of the > users of this driver. > > Cc: linux-...@vger.kernel.org > Acked-by: Felipe Balbi > Acked-by: Tony Lindgren > Signed-off-by: Aaro Koskinen My main question is: what is CBUS? It doesn't look like an I2C/SMBUS host controller, but some bit-banging protocol? As such, it shouldn't go to i2c/busses/. And the protocol doesn't look much like I2C, neither. There is no ACK/NACK/START/STOP, so I wonder if it should be in i2c after all... Jean, maybe you want to have a glimpse on this as well? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/1] Input: joydev - fix axes values sent in initial js_event
2012/9/13, Dmitry Torokhov : > On Wed, Sep 05, 2012 at 10:09:57PM +0200, Vojtěch Boček wrote: > > This makes sense. Just to confirm - have you tried the patch and > verified it works for you? > > Thanks. > > -- > Dmitry > Yes, I did. Only one thing is incorrect(?). When I plug the joystick in, then open my test program, everything is okay, startup event has correct values. Then, I unplug the joystick and plug it in again quickly, after that, startup event has wrong values, but another normal axis event with correct values is fired immediately after. I suppose it does not matter, because in the end, values are correct. Felt worth mentioning, though. -- 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: xt_nat_init: BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
> Wasnt it already solved ? > > http://1984.lsi.us.es/git/nf-next/commit/?id=00545bec9412d130c77f72a08d6c8b6ad21d4a1 > > Just have to wait that netfilter fixes are pushed upstream OK, sorry. I didn't subscribe many mailing lists and rely on the search results in google and LKML to avoid duplicate reports.. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/5] Support for TSC/ADC MFD driver
This patch set adds a MFD core driver which registers
touchscreen and ADC as its client drivers.
The existing touchscreen has been modified to work as
a MFD client driver and a new ADC driver has been added
in the IIO subsystem.
There are 8 analog input lines, which can be used as:
1. 8 general purpose ADC channels
2. 4 wire TS, with 4 general purpose ADC channels
3. 5 wire TS, with 3 general purpose ADC channels
This patch set has been tested on AM335x EVM.
These set of patches are based on top of Touchscreen patch
set submitted.
Subject: [PATCH 0/4] input: TSC: ti_tscadc: TI Touchscreen driver updates [1]
[1] http://www.spinics.net/lists/linux-input/msg22107.html
Changes in v2:
Dropped one patch send in the last version after
receiving internal comments. I have merged the changes
into existing patches.
Also added a new patch to support suspend/resume feature.
Fixed review comments by Matthias Kaehlcke.
Changes in v3:
Addressed review comments by Jonathan Cameron.
Improved ADC driver with more readable labels,
spaces and comments.
Patil, Rachna (5):
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
MFD: ti_tscadc: add suspend/resume functionality
drivers/iio/adc/Kconfig|7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/ti_adc.c | 255
drivers/input/touchscreen/Kconfig |4 +-
drivers/input/touchscreen/Makefile |2 +-
.../input/touchscreen/{ti_tscadc.c => ti_tsc.c}| 310 ++--
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |1 +
drivers/mfd/ti_tscadc.c| 251
include/linux/input/{ti_tscadc.h => ti_tsc.h} |4 +-
include/linux/mfd/ti_tscadc.h | 151 ++
include/linux/platform_data/ti_adc.h | 14 +
12 files changed, 781 insertions(+), 228 deletions(-)
create mode 100644 drivers/iio/adc/ti_adc.c
rename drivers/input/touchscreen/{ti_tscadc.c => ti_tsc.c} (55%)
create mode 100644 drivers/mfd/ti_tscadc.c
rename include/linux/input/{ti_tscadc.h => ti_tsc.h} (90%)
create mode 100644 include/linux/mfd/ti_tscadc.h
create mode 100644 include/linux/platform_data/ti_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 v3 3/5] 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
---
Changes in v2:
No changes
Changes in v3:
No changes
drivers/input/touchscreen/ti_tsc.c | 277 +++-
drivers/mfd/ti_tscadc.c| 11 ++
include/linux/mfd/ti_tscadc.h | 10 ++-
3 files changed, 74 insertions(+), 224 deletions(-)
diff --git a/drivers/input/touchscreen/ti_tsc.c
b/drivers/input/touchscreen/ti_tsc.c
index 8e94c00..ca8ce73 100644
--- a/drivers/input/touchscreen/ti_tsc.c
+++ b/drivers/input/touchscreen/ti_tsc.c
@@ -26,123 +26,31 @@
#include
#include
#include
-
-#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
#define ADCFSM_STEPID 0x10
#define SEQ_SETTLE 275
-#define ADC_CLK300
#define MAX_12BIT ((1 << 12) - 1)
struct tscadc {
struct input_dev*input;
- struct clk *tsc_ick;
- void __iomem*tsc_base;
unsigned intirq;
unsigned intwires;
unsigned intx_plate_resistance;
boolpen_down;
int steps_to_configure;
+ struct ti_tscadc_dev*mfd_tscadc;
};
static unsigned int tscadc_readl(struct tscadc *ts, unsigned int reg)
{
- return readl(ts->tsc_base + reg);
+ return readl(ts->mfd_tscadc->tscadc_base + reg);
}
static void tscadc_writel(struct tscadc *tsc, unsigned
[PATCH v3 5/5] MFD: ti_tscadc: add suspend/resume functionality
This patch adds support for suspend/resume of
TSC/ADC MFDevice.
Signed-off-by: Patil, Rachna
---
Changes in v2:
Added this patch newly in this patch series.
Changes in v3:
No changes.
drivers/iio/adc/ti_adc.c | 32
drivers/input/touchscreen/ti_tsc.c | 33 +
drivers/mfd/ti_tscadc.c| 33 -
include/linux/mfd/ti_tscadc.h |3 +++
4 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/drivers/iio/adc/ti_adc.c b/drivers/iio/adc/ti_adc.c
index 56f8af2..69f19f0 100644
--- a/drivers/iio/adc/ti_adc.c
+++ b/drivers/iio/adc/ti_adc.c
@@ -207,6 +207,36 @@ static int __devexit tiadc_remove(struct platform_device
*pdev)
return 0;
}
+static int adc_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct ti_tscadc_dev *tscadc_dev = pdev->dev.platform_data;
+ struct adc_device *adc_dev = tscadc_dev->adc;
+ unsigned int idle;
+
+ if (!device_may_wakeup(tscadc_dev->dev)) {
+ idle = adc_readl(adc_dev, REG_CTRL);
+ idle &= ~(CNTRLREG_TSCSSENB);
+ adc_writel(adc_dev, REG_CTRL, (idle |
+ CNTRLREG_POWERDOWN));
+ }
+ return 0;
+}
+
+static int adc_resume(struct platform_device *pdev)
+{
+ struct ti_tscadc_dev *tscadc_dev = pdev->dev.platform_data;
+ struct adc_device *adc_dev = tscadc_dev->adc;
+ unsigned int restore;
+
+ /* Make sure ADC is powered up */
+ restore = adc_readl(adc_dev, REG_CTRL);
+ restore &= ~(CNTRLREG_POWERDOWN);
+ adc_writel(adc_dev, REG_CTRL, restore);
+
+ adc_step_config(adc_dev);
+ return 0;
+}
+
static struct platform_driver tiadc_driver = {
.driver = {
.name = "tiadc",
@@ -214,6 +244,8 @@ static struct platform_driver tiadc_driver = {
},
.probe = tiadc_probe,
.remove = __devexit_p(tiadc_remove),
+ .suspend = adc_suspend,
+ .resume = adc_resume,
};
module_platform_driver(tiadc_driver);
diff --git a/drivers/input/touchscreen/ti_tsc.c
b/drivers/input/touchscreen/ti_tsc.c
index ca8ce73..f103e5f 100644
--- a/drivers/input/touchscreen/ti_tsc.c
+++ b/drivers/input/touchscreen/ti_tsc.c
@@ -338,6 +338,37 @@ static int __devexit tscadc_remove(struct platform_device
*pdev)
return 0;
}
+static int tsc_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct ti_tscadc_dev*tscadc_dev = pdev->dev.platform_data;
+ struct tscadc *ts_dev = tscadc_dev->tsc;
+ unsigned int idle;
+
+ if (device_may_wakeup(tscadc_dev->dev)) {
+ idle = tscadc_readl(ts_dev, REG_IRQENABLE);
+ tscadc_writel(ts_dev, REG_IRQENABLE,
+ (idle | IRQENB_HW_PEN));
+ tscadc_writel(ts_dev, REG_IRQWAKEUP, IRQWKUP_ENB);
+ }
+ return 0;
+}
+
+static int tsc_resume(struct platform_device *pdev)
+{
+ struct ti_tscadc_dev*tscadc_dev = pdev->dev.platform_data;
+ struct tscadc *ts_dev = tscadc_dev->tsc;
+
+ if (device_may_wakeup(tscadc_dev->dev)) {
+ tscadc_writel(ts_dev, REG_IRQWAKEUP,
+ 0x00);
+ tscadc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
+ }
+ tscadc_step_config(ts_dev);
+ tscadc_writel(ts_dev, REG_FIFO0THR,
+ ts_dev->steps_to_configure);
+ return 0;
+}
+
static struct platform_driver ti_tsc_driver = {
.probe = tscadc_probe,
.remove = __devexit_p(tscadc_remove),
@@ -345,6 +376,8 @@ static struct platform_driver ti_tsc_driver = {
.name = "tsc",
.owner = THIS_MODULE,
},
+ .suspend = tsc_suspend,
+ .resume = tsc_resume,
};
module_platform_driver(ti_tsc_driver);
diff --git a/drivers/mfd/ti_tscadc.c b/drivers/mfd/ti_tscadc.c
index 9dbd6d0..2c84aed 100644
--- a/drivers/mfd/ti_tscadc.c
+++ b/drivers/mfd/ti_tscadc.c
@@ -170,6 +170,7 @@ static int __devinit ti_tscadc_probe(struct
platform_device *pdev)
if (err < 0)
goto err_disable_clk;
+ device_init_wakeup(>dev, true);
platform_set_drvdata(pdev, tscadc);
return 0;
@@ -203,6 +204,35 @@ static int __devexit ti_tscadc_remove(struct
platform_device *pdev)
return 0;
}
+static int tscadc_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct ti_tscadc_dev*tscadc_dev = platform_get_drvdata(pdev);
+
+ tscadc_writel(tscadc_dev, REG_SE, 0x00);
+ pm_runtime_put_sync(>dev);
+ return 0;
+}
+
+static int tscadc_resume(struct platform_device *pdev)
+{
+ struct ti_tscadc_dev*tscadc_dev = platform_get_drvdata(pdev);
+ unsigned int restore, ctrl;
+
+ pm_runtime_get_sync(>dev);
+
+ /* context restore */
+ ctrl
[PATCH v3 4/5] 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
---
Changes in v2:
Addressed review comments from Matthias Kaehlcke
Changes in v3:
Addressed review comments from Jonathan Cameron.
Added comments, new line appropriately.
drivers/iio/adc/Kconfig |7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/ti_adc.c | 223 ++
drivers/mfd/ti_tscadc.c | 18 +++-
include/linux/mfd/ti_tscadc.h|9 ++-
include/linux/platform_data/ti_adc.h | 14 ++
6 files changed, 270 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/adc/ti_adc.c
create mode 100644 include/linux/platform_data/ti_adc.h
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 8a78b4f..ad32df8 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -22,4 +22,11 @@ config AT91_ADC
help
Say yes here to build support for Atmel AT91 ADC.
+config TI_ADC
+ tristate "TI's ADC driver"
+ depends on ARCH_OMAP2PLUS
+ 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 52eec25..a930cee 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_AD7266) += ad7266.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
+obj-$(CONFIG_TI_ADC) += ti_adc.o
diff --git a/drivers/iio/adc/ti_adc.c b/drivers/iio/adc/ti_adc.c
new file mode 100644
index 000..56f8af2
--- /dev/null
+++ b/drivers/iio/adc/ti_adc.c
@@ -0,0 +1,223 @@
+/*
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct adc_device {
+ struct ti_tscadc_dev *mfd_tscadc;
+ struct iio_dev *idev;
+ int channels;
+};
+
+static unsigned int adc_readl(struct adc_device *adc, unsigned int reg)
+{
+ return readl(adc->mfd_tscadc->tscadc_base + reg);
+}
+
+static void adc_writel(struct adc_device *adc, unsigned int reg,
+ unsigned int val)
+{
+ writel(val, adc->mfd_tscadc->tscadc_base + reg);
+}
+
+static void adc_step_config(struct adc_device *adc_dev)
+{
+ unsigned intstepconfig;
+ 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++) {
+ adc_writel(adc_dev, REG_STEPCONFIG(i),
+ stepconfig | STEPCONFIG_INP(channels));
+ adc_writel(adc_dev, REG_STEPDELAY(i),
+ STEPCONFIG_OPENDLY);
+ channels++;
+ }
+ adc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+}
+
+static int tiadc_channel_init(struct iio_dev *idev, int channels)
+{
+ struct iio_chan_spec *chan_array;
+ int i;
+
+ idev->num_channels = channels;
+ chan_array = kcalloc(idev->num_channels, sizeof(struct iio_chan_spec),
+ GFP_KERNEL);
+
+ if (chan_array == NULL)
+ return -ENOMEM;
+
+ for (i = 0; i < (idev->num_channels); i++) {
+ struct iio_chan_spec *chan = chan_array + i;
+ chan->type = IIO_VOLTAGE;
+ chan->indexed = 1;
+ chan->channel = i;
+ chan->info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT;
+ }
+
+ idev->channels = chan_array;
+
+ return idev->num_channels;
+}
+
+static void tiadc_channels_remove(struct iio_dev *idev)
+{
+ kfree(idev->channels);
+}
+
+static int tiadc_read_raw(struct iio_dev *idev,
+ struct iio_chan_spec
[PATCH v3 1/5] 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
---
Changes in v2:
Missed changing the name of touchscreen header file
in the previous version.
Adding the same.
Changes in v3:
no changes.
drivers/input/touchscreen/Kconfig |4 ++--
drivers/input/touchscreen/Makefile |2 +-
.../input/touchscreen/{ti_tscadc.c => ti_tsc.c}|2 +-
include/linux/input/{ti_tscadc.h => ti_tsc.h} |4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
rename drivers/input/touchscreen/{ti_tscadc.c => ti_tsc.c} (99%)
rename include/linux/input/{ti_tscadc.h => ti_tsc.h} (90%)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 1ba232c..68ac802 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_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_tsc.
config TOUCHSCREEN_ATMEL_TSADCC
tristate "Atmel Touchscreen Interface"
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 178eb12..d579427 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_TSC) += ti_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_tsc.c
similarity index 99%
rename from drivers/input/touchscreen/ti_tscadc.c
rename to drivers/input/touchscreen/ti_tsc.c
index ec0a442..8e94c00 100644
--- a/drivers/input/touchscreen/ti_tscadc.c
+++ b/drivers/input/touchscreen/ti_tsc.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
#include
#define REG_RAWIRQSTATUS 0x024
diff --git a/include/linux/input/ti_tscadc.h b/include/linux/input/ti_tsc.h
similarity index 90%
rename from include/linux/input/ti_tscadc.h
rename to include/linux/input/ti_tsc.h
index ad442a3..5da27d6 100644
--- a/include/linux/input/ti_tscadc.h
+++ b/include/linux/input/ti_tsc.h
@@ -1,5 +1,5 @@
-#ifndef __LINUX_TI_TSCADC_H
-#define __LINUX_TI_TSCADC_H
+#ifndef __LINUX_TI_TSC_H
+#define __LINUX_TI_TSC_H
/**
* struct tsc_data Touchscreen wire configuration
--
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 v3 2/5] 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
---
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
drivers/mfd/Kconfig |9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/ti_tscadc.c | 193 +
include/linux/mfd/ti_tscadc.h | 133
4 files changed, 336 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/ti_tscadc.c
create mode 100644 include/linux/mfd/ti_tscadc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d1facef..81eb815 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -94,6 +94,15 @@ config MFD_TI_SSP
To compile this driver as a module, choose M here: the
module will be called ti-ssp.
+config MFD_TI_TSCADC
+ tristate "TI ADC / Touch Screen chip support"
+ depends on ARCH_OMAP2PLUS
+ 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_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 79dd22d..1537f74 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_TSCADC)+= ti_tscadc.o
obj-$(CONFIG_MFD_STA2X11) += sta2x11-mfd.o
obj-$(CONFIG_MFD_STMPE)+= stmpe.o
diff --git a/drivers/mfd/ti_tscadc.c b/drivers/mfd/ti_tscadc.c
new file mode 100644
index 000..ac4bf7b
--- /dev/null
+++ b/drivers/mfd/ti_tscadc.c
@@ -0,0 +1,193 @@
+/*
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int reg)
+{
+ return readl(tsadc->tscadc_base + reg);
+}
+
+static void tscadc_writel(struct ti_tscadc_dev *tsadc, unsigned int reg,
+ unsigned int val)
+{
+ writel(val, tsadc->tscadc_base + reg);
+}
+
+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(>dev, "Could not find platform data\n");
+ return -EINVAL;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(>dev, "no memory resource defined.\n");
+ return -EINVAL;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(>dev, "no irq ID is specified.\n");
+ return -EINVAL;
+ }
+
+ /* Allocate memory for device */
+ tscadc = kzalloc(sizeof(struct ti_tscadc_dev), GFP_KERNEL);
+ if (!tscadc) {
+ dev_err(>dev, "failed to allocate memory.\n");
+ return -ENOMEM;
+ }
+ tscadc->dev = >dev;
+ tscadc->irq = irq;
+
+ res = request_mem_region(res->start, resource_size(res), pdev->name);
+ if (!res) {
+ dev_err(>dev, "failed to reserve registers.\n");
+ err = -EBUSY;
+ goto err_free_mem;
+ }
+
+ tscadc->tscadc_base = ioremap(res->start, resource_size(res));
+ if (!tscadc->tscadc_base) {
+
Re: [PATCH v3 21/31] arm64: 32-bit (compat) applications support
On Thursday 13 September 2012, Catalin Marinas wrote:
> Here they are. For converting the other architectures, I'll post
> separate patches as I don't want to add an extra dependency to the
> arm64 series.
Ok, thanks!
> diff --git a/kernel/compat.c b/kernel/compat.c
> index c28a306..5f07388 100644
> --- a/kernel/compat.c
> +++ b/kernel/compat.c
> @@ -1215,6 +1215,50 @@ compat_sys_sysinfo(struct compat_sysinfo __user *info)
> return 0;
> }
>
> +#ifdef __ARCH_WANT_COMPAT_SYS_SENDFILE
> +asmlinkage int compat_sys_sendfile(int out_fd, int in_fd,
> + compat_off_t __user *offset, s32 count)
> +{
> + mm_segment_t old_fs = get_fs();
> + int ret;
> + off_t of;
> +
> + if (offset && get_user(of, offset))
> + return -EFAULT;
> +
> + set_fs(KERNEL_DS);
> + ret = sys_sendfile(out_fd, in_fd,
> + offset ? (off_t __user *) : NULL, count);
> + set_fs(old_fs);
> +
> + if (offset && put_user(of, offset))
> + return -EFAULT;
> + return ret;
> +}
> +#endif /* __ARCH_WANT_COMPAT_SYS_SENDFILE */
Looking at this code in detail now, I think it's better to move the functions to
fs/read_write.c and get rid of the get_fs/set_fs hack, like
asmlinkage int compat_sys_sendfile(int out_fd, int in_fd,
compat_off_t __user *offset, s32 count)
{
loff_t pos;
compat_off_t off;
ssize_t ret;
if (offset) {
if (unlikely(get_user(off, offset)))
return -EFAULT;
pos = off;
ret = do_sendfile(out_fd, in_fd, , count, MAX_NON_LFS);
if (unlikely(put_user(pos, offset)))
return -EFAULT;
return ret;
}
return do_sendfile(out_fd, in_fd, NULL, count, 0);
}
This implementation is smaller and more efficient than the common one.
Same for compat_sys_sendfile64, although I don't think there is ever
a case where loff_t is defined differently from compat_loff_t, so
you can probably just use the native sys_sendfile64 for the compat
case.
>
> +#ifdef __ARCH_WANT_COMPAT_SYS_SCHED_RR_GET_INTERVAL
> +asmlinkage int compat_sys_sched_rr_get_interval(compat_pid_t pid,
> + struct compat_timespec __user
> *interval)
> +{
> + struct timespec t;
> + int ret;
> + mm_segment_t old_fs = get_fs();
> +
> + set_fs(KERNEL_DS);
> + ret = sys_sched_rr_get_interval(pid, (struct timespec __user *));
> + set_fs(old_fs);
> + if (put_compat_timespec(, interval))
> + return -EFAULT;
> + return ret;
> +}
> +#endif /* __ARCH_WANT_COMPAT_SYS_SCHED_RR_GET_INTERVAL */
> +
This one looks reasonable. It would be nice to kill the get_fs/set_fs but here
it would just make the native code slower or duplicate a lot of it.
Acked-by: Arnd Bergmann
--
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 00/13] Per sub-architecture SMP operations
On 12/09/12 15:58, Arnd Bergmann wrote: > As I promised at the ARM mini summit, I've updated Marc's series > for smp operations according to my complaints. Unfortunately, > I could not find version 7 of the patches when I started this, > so I based my work on version 6 and had to redo the same > changes. I'm quite happy with that series. I don't have much to add (my SoB is already all over the place), so if all platform maintainers are willing to give their acks, let's merge the damned thing! :-) M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Thu, 13 Sep 2012, Dave Martin wrote: > On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote: > > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > > - hcall-instructions > > potentially interesting, but given that for Xen we are quite happy with > > HVC, we are not going to add any secondary hypercall mechanisms, > > therefore at the moment it would just result in a BUG if the specified > > hcall instruction is != HVC. Besides if somebody else wanted to > > implemented the Xen hypercall interface in a different way they could > > just reimplement the hypercall wrappers, that would be easier than > > trying to do it with this property. > > Some thoughts on this: > > We decided that embedding machine instructions into the DT is a fairly > awful idea when discussing how to describe low-level debug UARTs in the > DT. I don't think it's a lot better in this case (never mind issues > like ARM versus Thumb, endianness etc.) > > If we are going to attempt to describe the call interface, we should > do it symbolically, allowing the hypervisor interface code in the kernel > to choose (or, if necessary, generate) the right call wrappers. > > We will have this issue for descrbing power firmware interfaces for > example: we already know that this functionality might require an SMC > or HVC instruction to call it, depending on the platform. > > A hypervisor with only one call ABI could leave this to be implicit, > providing there is a version number property of similar to allow future > changes to be accommodated. I completely agree with Dave. I have no problems adding a symbolic property to say "we are using hvc with parameters on registers". I just want to avoid having actual machine instructions (and potentially dealing with executing them) into the DT. Maybe we could have a "calling-convention" property that can be "xen" or something else. When a new hypervisor vendor comes along it can change the value of "calling-convention" to "foo". -- 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 11/13] ARM: SoC: convert spear13xx to SoC descriptor
On Wed, Sep 12, 2012 at 8:28 PM, Arnd Bergmann wrote: > Convert the spear13xx platform to use the SoC descriptor to provide > its SMP and CPU hotplug operations. > > Cc: Viresh Kumar > Cc: Shiraz Hashim > Cc: spear-de...@list.st.com > Signed-off-by: Marc Zyngier > Signed-off-by: Arnd Bergmann Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Thu, 13 Sep 2012, Dave Martin wrote: > Do you think it's feasible to standardise on some interoperable ABI for > kvm and Xen? This sounds pretty optimistic, but I'm not aware of all > the technicalities, or what possible third-party hypervisors are out > there. > > If we could do it, it would be good. But I have my doubts about the > feasibility and the benefits. If different hypervisors are significantly > imcompatible, then having a common low-level ABI doesn't help all that > much. It is not really possible because each hypervisor offers a different set of hypercalls and has a different calling convention, so there is very little we can do to unify them. For example many of the current Xen hypercalls are to deal with the grant table and event channels, that are Xen specific concepts completely missing in KVM. -- 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/5] fat: allocate persistent inode numbers
On Thu, Sep 13, 2012 at 05:33:02PM +0900, OGAWA Hirofumi wrote:
> Namjae Jeon writes:
>
> >> I see. So, client can't solve the ESTALE if inode cache was evicted,
> >> right? (without application changes)
> >
> > There can be situation where we may get not only ESTALE but EIO also.
> >
> > For example,
> > ---
> > fd = open(“foo.txt”);
> > while (1) {
> >sleep(1);
> >write(fd..);
> > }
> >
> >
> > Here “write” may fail when inode number of “foo.txt” is changed at
> > server due to cache eviction under memory pressure.
> > When we tried a similar test, we found that “write” is retuning “EIO”
> > instead of “ESTALE”
> >
> > -
> > #> ./write_test_dbg bbb 1000 0
> > FILE : bbb, SIZE : 1048576000 , FSYNC : OFF , RECORD_SIZE = 4096
> > 106264 -rwxr-xr-x 1 root 0 0 Jan 1 00:14 bbb
> > write failed after 60080128 bytes:, errno = 5: Input/output error
> > -
> >
> > As we get EIO instead of ESTALE, it may be difficult to decide when
> > "restart from LOOKUP” in such situation.
> > Also, as per Bruce opinion, we can not avoid ESTALE from inode number
> > change in rebooted server case.
> > In reboot case, it is worst as it may attempt to write in a different
> > file if NFS handle at NFS client match with inode number of some other
> > file at NFS server.
>
> I see.
>
> >> Grepping around... Documentation/sysctl/vm.txt mentions a
> >> vfs_cache_pressure parameter.
> >> Yeah. And dirty hack will be possible to adjust sb->s_shrink.batch.
> > I am worrying if it could lead to OOM condition on embedded
> > system(short memory(DRAM) and support 3TB HDD disk of big size.)
> >
> > Please let me know if any issues or queries.
>
> So, now I think stable inode number may be useful if there are users of
> it. And I guess those functionality is no collisions with -mm. And I
> suppose we can add two modes for "nfs" option (e.g. nfs=1 and nfs=2).
>
> If nfs=1, works like current -mm without no limited operations.
Apologies, I haven't been following the conversation carefully: remind
me what "works like current -mm" means?
--b.
> If nfs=2, try to make stable FH and limit some operations
>
> (option name doesn't matter here.)
>
> Does this work fine?
> --
> OGAWA Hirofumi
--
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] edac/85xx: fix error handle of mpc85xx_mc_err_probe
Error handle in case of DDR ECC off is wrong, sysfs entries have not been
created, so edac_mc_free which frees a mci instance should not be called.
Also, free mci's memory in this case.
Signed-off-by: Shaohui Xie
---
drivers/edac/edac_core.h|1 +
drivers/edac/edac_mc.c | 53 --
drivers/edac/mpc85xx_edac.c | 14 +++
3 files changed, 45 insertions(+), 23 deletions(-)
diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h
index 23bb99f..108c4e2 100644
--- a/drivers/edac/edac_core.h
+++ b/drivers/edac/edac_core.h
@@ -448,6 +448,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
unsigned sz_pvt);
extern int edac_mc_add_mc(struct mem_ctl_info *mci);
extern void edac_mc_free(struct mem_ctl_info *mci);
+extern void edac_mc_free_mem(struct mem_ctl_info *mci);
extern struct mem_ctl_info *edac_mc_find(int idx);
extern struct mem_ctl_info *find_mci_by_dev(struct device *dev);
extern struct mem_ctl_info *edac_mc_del_mc(struct device *dev);
diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index 616d90b..a2488b2 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -199,6 +199,40 @@ void *edac_align_ptr(void **p, unsigned size, int n_elems)
return (void *)(((unsigned long)ptr) + align - r);
}
+/*
+ * edac_mc_free_mem
+ * 'Free' a previously allocated 'mci' memory
+ * @mci: pointer to a struct mem_ctl_info structure
+ */
+void edac_mc_free_mem(struct mem_ctl_info *mci)
+{
+ int i = 0, tot_dimms, chn, tot_channels;
+ struct csrow_info *csr;
+
+ tot_dimms = mci->tot_dimms;
+ tot_channels = mci->num_cschannel;
+
+ if (mci->dimms) {
+ for (i = 0; i < tot_dimms; i++)
+ kfree(mci->dimms[i]);
+ kfree(mci->dimms);
+ }
+ if (mci->csrows) {
+ for (chn = 0; chn < tot_channels; chn++) {
+ csr = mci->csrows[chn];
+ if (csr) {
+ for (chn = 0; chn < tot_channels; chn++)
+ kfree(csr->channels[chn]);
+ kfree(csr);
+ }
+ kfree(mci->csrows[i]);
+ }
+ kfree(mci->csrows);
+ }
+ kfree(mci);
+}
+EXPORT_SYMBOL_GPL(edac_mc_free_mem);
+
/**
* edac_mc_alloc: Allocate and partially fill a struct mem_ctl_info structure
* @mc_num:Memory controller number
@@ -413,24 +447,7 @@ struct mem_ctl_info *edac_mc_alloc(unsigned mc_num,
return mci;
error:
- if (mci->dimms) {
- for (i = 0; i < tot_dimms; i++)
- kfree(mci->dimms[i]);
- kfree(mci->dimms);
- }
- if (mci->csrows) {
- for (chn = 0; chn < tot_channels; chn++) {
- csr = mci->csrows[chn];
- if (csr) {
- for (chn = 0; chn < tot_channels; chn++)
- kfree(csr->channels[chn]);
- kfree(csr);
- }
- kfree(mci->csrows[i]);
- }
- kfree(mci->csrows);
- }
- kfree(mci);
+ edac_mc_free_mem(mci);
return NULL;
}
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index a1e791e..402b3f5 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1012,7 +1012,7 @@ static int __devinit mpc85xx_mc_err_probe(struct
platform_device *op)
if (res) {
printk(KERN_ERR "%s: Unable to get resource for MC err regs\n",
__func__);
- goto err;
+ goto err1;
}
if (!devm_request_mem_region(>dev, r.start, resource_size(),
@@ -1020,14 +1020,14 @@ static int __devinit mpc85xx_mc_err_probe(struct
platform_device *op)
printk(KERN_ERR "%s: Error while requesting mem region\n",
__func__);
res = -EBUSY;
- goto err;
+ goto err1;
}
pdata->mc_vbase = devm_ioremap(>dev, r.start, resource_size());
if (!pdata->mc_vbase) {
printk(KERN_ERR "%s: Unable to setup MC err regs\n", __func__);
res = -ENOMEM;
- goto err;
+ goto err1;
}
sdram_ctl = in_be32(pdata->mc_vbase + MPC85XX_MC_DDR_SDRAM_CFG);
@@ -1035,7 +1035,7 @@ static int __devinit mpc85xx_mc_err_probe(struct
platform_device *op)
/* no ECC */
printk(KERN_WARNING "%s: No ECC DIMMs discovered\n", __func__);
res = -ENODEV;
- goto err;
+ goto err1;
}
edac_dbg(3, "init mci\n");
@@ -1065,7 +1065,7 @@ static int __devinit mpc85xx_mc_err_probe(struct
platform_device
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On Thu, 13 Sep 2012, Rob Herring wrote: > On 09/12/2012 01:14 PM, Stefano Stabellini wrote: > > On Wed, 12 Sep 2012, Stefano Stabellini wrote: > >> On Tue, 28 Aug 2012, Rob Herring wrote: > >>> You should look at ePAPR 1.1 which defines hypervisor related bindings. > >>> While it is a PPC doc, we should reuse or extend what makes sense. > >>> > >>> See section 7.5: > >>> > >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf > >> > >> Thanks for the link, I wasn't aware of ePAPR. > >> > >> The hypervisor node defined by ePAPR is not very different from what I > >> am proposing. Should I try to be compatible with the hypervisor > >> specification above (as in compatible = "epapr,hypervisor-1.1")? > >> Or should I just use it as a reference for my own specification? > >> > >> Personally I would rather avoid full compatibility with ePAPR. > > > > In particular reading section 7.5, these are the required properties of > > the ePAPR hypervisor node: > > > > - compatible = "epapr,hypervisor-1.1" > > compared to what I am proposing, it is laking information about what > > hypervisor we are talking about (xen, kvm, vmware, etc) and the version > > of the ABI (xen-4.2). > > compatible properties are often changed. If we do deviate on the rest of > the binding, then it needs to be different. > > Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor" > doesn't even appear in the kernel. > > We also perhaps have to consider the possibility of Xen on PowerPC. Then > alignment is more important. OK. In that case I think that we can just use "xen,xen-4.2". > > - hcall-instructions > > potentially interesting, but given that for Xen we are quite happy with > > HVC, we are not going to add any secondary hypercall mechanisms, > > therefore at the moment it would just result in a BUG if the specified > > hcall instruction is != HVC. Besides if somebody else wanted to > > implemented the Xen hypercall interface in a different way they could > > just reimplement the hypercall wrappers, that would be easier than > > trying to do it with this property. > > It's really about the parameters passed with the HVC. The ePAPR may be a > good model for defining this. Just grepping "hypervisor" under > arch/powerpc, it's pretty clear hypervisor support happened first and > the ePAPR came second. Hopefully we can avoid that for ARM. Right. As I wrote in the other email, we could have a new property to select the calling convention (and therefore the hypercall wrappers) to be used with the hypervisor. > > - guest-id > > we usually make a point in trying not to tell the guest its own domid > > because if the VM gets migrated to a different host it acquires a new > > domid, therefore it should not rely on it. > > > > - guest-name > > we could pass the guest name here, but I don't see how it could be > > of any use. > > > > I have no issue with these being optional. OK, good. > > On the other hand, thinking more about what Xen needs in the device > > tree, I think we could improve the current spec by clarifying the > > meaning of the memory region and interrupt properties we currently > > require. I thought about moving them to two separate children node with > > an explicit name: > > > > --- > > > > * Xen hypervisor device tree bindings > > > > I really think we need to define ARM hypervisor device tree bindings > first, then Xen specific bindings as an addition to that. I worry that > the KVM folks aren't paying attention and then want something different > later on. The problem is that there isn't much in common between Xen and KVM at least from the DT point of view. I am not sure what would go into this common hypervisor node. The three key pieces of information that we are currently passing in the DT (xen-4.2, a memory region, a PPI) are Xen specific. If one day KVM (or another hypervisor vendor) decides to support the Xen interface, can't they just have the Xen specific binding with a slightly different compatible node? For example: compatible = "linux,kvm", "xen,xen-4.2" wouldn't that mean "I am KVM but I can support the Xen interface"? > > Xen ARM virtual platforms shall have the following properties and > > children nodes: > > > > - compatible property: > > compatible = "xen,xen", "xen,xen-"; > > "xen,xen" should be last as it is less specific. Ah OK, thanks. > > where is the version of the Xen ABI of the platform. > > > > - grant_table child with the following properties: > > - name: > > name = "grant_table"; > > What's a grant table? A Xen specific mechanism to share pages between guests. > > - reg: specifies the base physical address and size of a region in > > memory where the grant table should be mapped to, using an > > HYPERVISOR_memory_op hypercall. > > > > - events child with the following properties: > > - name: > > name = "events"; > > - interrupts: the interrupt used by Xen to inject
kmemcg benchmarks
Hello everybody. I've just finished a round of benchmarks for kmemcg code. All the results can be found at: http://glommer.net/kmemcg-benchmarks-13092012/ The benchmarks were run in a 2-socket, 24-cpu machine. I haven't run all possible configurations I have envisioned, because I wanted this posted early rather than later. I've also had un-official runs in my 4-cpu i7 laptop and in a 6-way single socket AMD box. They would need to be re-run to be publishable, since they are quite raw and ad-hoc (like, I was not running perf stat always in the same way, doing some things manually, etc) But they overall point to consistent results. You can find a guide to that data in the README file in that dir, and the actual data in the results* dir. The chosen allocator for this is the SLAB. A summary and discussion of the data follows: fork intensive workload, elapsed time: === base-NotCompiled : 16.76 +- 0.87% [ + 0.00 % ] kmemcg-stack-Unset: 16.28 +- 1.10% [ - 2.86 % ] kmemcg-stack-Set : 16.96 +- 0.65% [ + 1.19 % ] kmemcg-slab-Unset : 16.71 +- 1.16% [ + 0.28 % ] kmemcg-slab-Set : 17.11 +- 0.48% [ + 2.08 % ] fork + user mem, elapsed time: === base-NotCompiled : 4.88 +- 0.35% [ + 0.00 % ] kmemcg-stack-Unset: 4.87 +- 0.36% [ - 0.34 % ] kmemcg-stack-Set : 4.85 +- 0.37% [ - 0.76 % ] kmemcg-slab-Unset : 4.84 +- 0.39% [ - 0.79 % ] kmemcg-slab-Set : 4.84 +- 0.35% [ - 0.78 % ] So in general, I don't see a big difference, with almost all measurements falling inside the 2-sigma range. >From the fork intensive workload, two things pop out: first, kmem patches applied, but kmem not used, actually performs slightly better than no patches at all. I don't know why this is, and it might even be a glitch. But it consistently happened in my laptop and in the 6-way AMD machine. Also, we can see that in that workload, which is slab intensive, kmemcg-slab-Set performs slightly worse. Being worse is inline with expectations, but I don't consider the hit to be too big. Please let me know of any additional work you would like to see done here. -- 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/
[GIT PULL] sound fixes for 3.6-rc6
Linus,
The following changes since commit 2e4a263ca80a203ac6109f5932722a716c265395:
ALSA: snd-usb: fix cross-interface streaming devices (2012-08-31 21:04:53
+0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
for you to fetch changes up to 3737e2be505d872bf2b3c1cd4151b2d2b413d7b5:
ALSA: ice1724: Use linear scale for AK4396 volume control. (2012-09-12
16:17:41 +0200)
Sound fixes for 3.6-rc6
Just a few small / trivial regression fixes at this time.
Catalin Iacob (1):
ALSA: hda_intel: add position_fix quirk for Asus K53E
Dan Carpenter (1):
ALSA: compress_core: fix open flags test in snd_compr_open()
Matteo Frigo (1):
ALSA: ice1724: Use linear scale for AK4396 volume control.
Takashi Iwai (3):
ALSA: hda - Fix missing Master volume for STAC9200/925x
ALSA: usb-audio: Fix bogus error messages for delay accounting
ALSA: hda - Fix Oops at codec reset/reconfig
sound/core/compress_offload.c| 8 +++-
sound/pci/hda/hda_codec.c| 2 +-
sound/pci/hda/hda_intel.c| 1 +
sound/pci/hda/patch_sigmatel.c | 2 +-
sound/pci/ice1712/prodigy_hifi.c | 3 ++-
sound/usb/pcm.c | 6 ++
6 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index ec2118d..eb60cb8 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -80,14 +80,12 @@ static int snd_compr_open(struct inode *inode, struct file
*f)
int maj = imajor(inode);
int ret;
- if (f->f_flags & O_WRONLY)
+ if ((f->f_flags & O_ACCMODE) == O_WRONLY)
dirn = SND_COMPRESS_PLAYBACK;
- else if (f->f_flags & O_RDONLY)
+ else if ((f->f_flags & O_ACCMODE) == O_RDONLY)
dirn = SND_COMPRESS_CAPTURE;
- else {
- pr_err("invalid direction\n");
+ else
return -EINVAL;
- }
if (maj == snd_major)
compr = snd_lookup_minor_data(iminor(inode),
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index f25c24c..1c65cc5 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2353,6 +2353,7 @@ int snd_hda_codec_reset(struct hda_codec *codec)
}
if (codec->patch_ops.free)
codec->patch_ops.free(codec);
+ memset(>patch_ops, 0, sizeof(codec->patch_ops));
snd_hda_jack_tbl_clear(codec);
codec->proc_widget_hook = NULL;
codec->spec = NULL;
@@ -2368,7 +2369,6 @@ int snd_hda_codec_reset(struct hda_codec *codec)
codec->num_pcms = 0;
codec->pcm_info = NULL;
codec->preset = NULL;
- memset(>patch_ops, 0, sizeof(codec->patch_ops));
codec->slave_dig_outs = NULL;
codec->spdif_status_reset = 0;
module_put(codec->owner);
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 60882c6..228cdf9 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2701,6 +2701,7 @@ static struct snd_pci_quirk position_fix_list[]
__devinitdata = {
SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x1043, 0x1b43, "ASUS K53E", POS_FIX_POSBUF),
SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
SND_PCI_QUIRK(0x10de, 0xcb89, "Macbook Pro 7,1", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1297, 0x3166, "Shuttle", POS_FIX_LPIB),
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 6f806d3..3d4722f 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -1075,7 +1075,7 @@ static struct snd_kcontrol_new stac_smux_mixer = {
static const char * const slave_pfxs[] = {
"Front", "Surround", "Center", "LFE", "Side",
- "Headphone", "Speaker", "IEC958",
+ "Headphone", "Speaker", "IEC958", "PCM",
NULL
};
diff --git a/sound/pci/ice1712/prodigy_hifi.c b/sound/pci/ice1712/prodigy_hifi.c
index 764cc93..075d5aa 100644
--- a/sound/pci/ice1712/prodigy_hifi.c
+++ b/sound/pci/ice1712/prodigy_hifi.c
@@ -297,6 +297,7 @@ static int ak4396_dac_vol_put(struct snd_kcontrol
*kcontrol, struct snd_ctl_elem
}
static const DECLARE_TLV_DB_SCALE(db_scale_wm_dac, -12700, 100, 1);
+static const DECLARE_TLV_DB_LINEAR(ak4396_db_scale, TLV_DB_GAIN_MUTE, 0);
static struct snd_kcontrol_new prodigy_hd2_controls[] __devinitdata = {
{
@@ -307,7 +308,7 @@ static struct snd_kcontrol_new prodigy_hd2_controls[]
__devinitdata = {
.info = ak4396_dac_vol_info,
.get = ak4396_dac_vol_get,
.put = ak4396_dac_vol_put,
- .tlv = { .p = db_scale_wm_dac },
+ .tlv = {
Re: [PATCH v3] media: v4l2-ctrl: add a helper function to modify the menu
Hi Laurent,
Thanks for the review.
On Thursday 13 September 2012 06:45 AM, Laurent Pinchart wrote:
> Hi Prabhakar,
>
> Thanks for the patch.
>
> On Tuesday 11 September 2012 19:53:38 Prabhakar Lad wrote:
>> From: Lad, Prabhakar
>>
>> Add a helper function to modify the menu, max and default value
>> to set.
>>
>> Signed-off-by: Lad, Prabhakar
>> Signed-off-by: Manjunath Hadli
>> Cc: Hans Verkuil
>> Cc: Sakari Ailus
>> Cc: Sylwester Nawrocki
>> Cc: Laurent Pinchart
>> Cc: Mauro Carvalho Chehab
>> Cc: Hans de Goede
>> Cc: Kyungmin Park
>> Cc: Guennadi Liakhovetski
>> Cc: Rob Landley
>> ---
>> Changes for v3:
>> 1: Fixed style/grammer issues as pointed by Hans.
>>Thanks Hans for providing the description.
>>
>> Changes for v2:
>> 1: Fixed review comments from Hans, to have return type as
>>void, add WARN_ON() for fail conditions, allow this fucntion
>>to modify the menu of custom controls.
>>
>> Documentation/video4linux/v4l2-controls.txt | 29
>> drivers/media/v4l2-core/v4l2-ctrls.c| 17 +++
>> include/media/v4l2-ctrls.h | 11 ++
>> 3 files changed, 57 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/video4linux/v4l2-controls.txt
>> b/Documentation/video4linux/v4l2-controls.txt index 43da22b..01d0a82 100644
>> --- a/Documentation/video4linux/v4l2-controls.txt
>> +++ b/Documentation/video4linux/v4l2-controls.txt
>> @@ -367,6 +367,35 @@ it to 0 means that all menu items are supported.
>> You set this mask either through the v4l2_ctrl_config struct for a custom
>> control, or by calling v4l2_ctrl_new_std_menu().
>>
>> +There are situations where menu items may be device specific. In such cases
>> the
>> +framework provides a helper function to change the menu:
>> +
>> +void v4l2_ctrl_modify_menu(struct v4l2_ctrl *ctrl, const char * const
>> *qmenu,
>> +s32 max, u32 menu_skip_mask, s32 def);
>
> Sorry if this is a stupid question, but wouldn't it be better to add a
> function to create a custom menu instead of modifying it afterwards ?
>
Create a custom menu? eventually everything boils down to modifying the
menu itself.
Regards,
--Prabhakar Lad
>> +
>> +A good example is the test pattern control for capture/display/sensors
>> devices
>> +that have the capability to generate test patterns. These test patterns are
>> +hardware specific, so the contents of the menu will vary from device to
>> device.
>> +
>> +This helper function is used to modify the menu, max, mask and the default
>> +value of the control.
>> +
>> +Example:
>> +
>> +static const char * const test_pattern[] = {
>> +"Disabled",
>> +"Vertical Bars",
>> +"Solid Black",
>> +"Solid White",
>> +NULL,
>> +};
>> +struct v4l2_ctrl *test_pattern_ctrl =
>> +v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
>> +V4L2_CID_TEST_PATTERN, V4L2_TEST_PATTERN_DISABLED, 0,
>> +V4L2_TEST_PATTERN_DISABLED);
>> +
>> +v4l2_ctrl_modify_menu(test_pattern_ctrl, test_pattern, 3, 0,
>> +V4L2_TEST_PATTERN_DISABLED);
>>
>> Custom Controls
>> ===
>
--
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] tty: Add get- ioctls to fetch tty status
On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote: > For checkpoint/restore we need to know if tty has > exclusive or packet mode set, as well as if pty > is currently locked. Just to be able to restore > this characteristics. > > For this sake the following ioctl codes are introduced > > - TIOGPKT to get packet mode state > - TIOGPTLCK to get Pty locked state > - TIOGEXCL to get Exclusive mode state Hi! I have only a comment regarding the naming. Why not to follow TIOC*? thanks, -- 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: [RFC][PATCH] perf, intel: Don't touch MSR_IA32_DEBUGCTLMSR from NMI context
On Thu, Sep 13, 2012 at 12:23 PM, Peter Zijlstra wrote:
> On Wed, 2012-09-12 at 18:22 +0200, Peter Zijlstra wrote:
>> Oleg and Sebastian found that touching MSR_IA32_DEBUGCTLMSR from NMI
>> context is problematic since the only way to change the various
>> unrelated bits in there is:
>>
>> debugctl = get_debugctlmsr()
>> /* frob flags in debugctl */
>> update_debugctlmsr(debugctl);
>>
>> Which is entirely unsafe if we prod at the MSR from NMI context.
>>
>> In particular the path that is responsible is:
>>
>> x86_pmu_handle_irq() (NMI handler)
>> x86_pmu_stop()
>> x86_pmu.disable -> intel_pmu_disable_event()
>> intel_pmu_lbr_disable()
>> __intel_pmu_lbr_disable()
>> wrmsrl(MSR_IA32_DEBUGCTLMSR,... );
>>
>> So remove intel_pmu_lbr_{en,dis}able() from
>> intel_pmu_{en,dis}able_event() and stick them in
>> intel_{get,put}_event_constraints() which are only ever called from
>> regular contexts.
>>
>> We combine intel_pmu_needs_lbr_smpl(), which tells us if the events
>> wants LBR data, with event->hw.branch_reg.alloc, which given
>> intel_shared_regs_constraints() is set if our event got the shared
>> resource, to give us a correctly balanced condition in
>> {get,put}_event_constraints() for intel_pmu_lbr_{en,dis}able().
>>
>> Also change core_pmu to only use x86_get_event_constraints since it
>> doesn't support any of the fancy DS (BTS,PEBS), LBR and OFFCORE features
>> that make up intel_{get,put}_event_constraints.
>
> OK, so with the added stipulation that touching the MSR from the NMI
> isn't a problem as long as we ensure we leave the MSR in the same state
> that we found it in, and the above is the only path found so far that
> could cause this to be violated, the patch is fine?
>
Should be, though it is pretty ugly to stash all of this in the
put/get constraints.
I will run some tests.
I wonder what this does when you come in to get/put with a fake cpuc. You don't
want to perturb the local lbr which may be in use.
> In particular we could note that both LBR and BTS use the DEBUGCTL MSR,
> but BTS doesn't throttle, so the LBR code is the only thing needing
> attention as per the above description.
>
>
--
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: [GIT PULL] sound fixes for 3.6-rc6
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote: > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus *PLEASE* don't do this. You point to a branch, but then the pull request clearly implies there is a tag with extra information in it. And indeed, the actual thing I should pull is not at all "for-linus", it seems to be your "tags/sound-3.6" tag. I don't know if this is the old "git pull-request" breakage where it stupidly "corrects" the remote branch when it verifies the branch name, or whether it's some other scripting problem. I think current git versions should not mess up the tag information, if that's the cause, but please verify. Linus -- 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] tty: Add get- ioctls to fetch tty status
On Thu, Sep 13, 2012 at 01:46:53PM +0200, Jiri Slaby wrote: > On 09/13/2012 11:56 AM, Cyrill Gorcunov wrote: > > For checkpoint/restore we need to know if tty has > > exclusive or packet mode set, as well as if pty > > is currently locked. Just to be able to restore > > this characteristics. > > > > For this sake the following ioctl codes are introduced > > > > - TIOGPKT to get packet mode state > > - TIOGPTLCK to get Pty locked state > > - TIOGEXCL to get Exclusive mode state > > Hi! I have only a comment regarding the naming. Why not to follow TIOC*? Hi Jiri, yeah, seems to be a good idea. I'll update if there will be no objection about idea in general. Thanks! Cyrill -- 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] Improving directed yield scalability for PLE handler
* Andrew Theurer [2012-09-11 13:27:41]:
> On Tue, 2012-09-11 at 11:38 +0530, Raghavendra K T wrote:
> > On 09/11/2012 01:42 AM, Andrew Theurer wrote:
> > > On Mon, 2012-09-10 at 19:12 +0200, Peter Zijlstra wrote:
> > >> On Mon, 2012-09-10 at 22:26 +0530, Srikar Dronamraju wrote:
> > +static bool __yield_to_candidate(struct task_struct *curr, struct
> > task_struct *p)
> > +{
> > + if (!curr->sched_class->yield_to_task)
> > + return false;
> > +
> > + if (curr->sched_class != p->sched_class)
> > + return false;
> > >>>
> > >>>
> > >>> Peter,
> > >>>
> > >>> Should we also add a check if the runq has a skip buddy (as pointed out
> > >>> by Raghu) and return if the skip buddy is already set.
> > >>
> > >> Oh right, I missed that suggestion.. the performance improvement went
> > >> from 81% to 139% using this, right?
> > >>
> > >> It might make more sense to keep that separate, outside of this
> > >> function, since its not a strict prerequisite.
> > >>
> >
> > + if (task_running(p_rq, p) || p->state)
> > + return false;
> > +
> > + return true;
> > +}
> > >>
> > >>
> > @@ -4323,6 +4340,10 @@ bool __sched yield_to(struct task_struct *p,
> > >>> bool preempt)
> > rq = this_rq();
> >
> > again:
> > + /* optimistic test to avoid taking locks */
> > + if (!__yield_to_candidate(curr, p))
> > + goto out_irq;
> > +
> > >>
> > >> So add something like:
> > >>
> > >> /* Optimistic, if we 'raced' with another yield_to(), don't bother */
> > >> if (p_rq->cfs_rq->skip)
> > >> goto out_irq;
> > >>>
> > >>>
> > p_rq = task_rq(p);
> > double_rq_lock(rq, p_rq);
> > >>>
> > >>>
> > >> But I do have a question on this optimization though,.. Why do we check
> > >> p_rq->cfs_rq->skip and not rq->cfs_rq->skip ?
> > >>
> > >> That is, I'd like to see this thing explained a little better.
> > >>
> > >> Does it go something like: p_rq is the runqueue of the task we'd like to
> > >> yield to, rq is our own, they might be the same. If we have a ->skip,
> > >> there's nothing we can do about it, OTOH p_rq having a ->skip and
> > >> failing the yield_to() simply means us picking the next VCPU thread,
> > >> which might be running on an entirely different cpu (rq) and could
> > >> succeed?
> > >
> > > Here's two new versions, both include a __yield_to_candidate(): "v3"
> > > uses the check for p_rq->curr in guest mode, and "v4" uses the cfs_rq
> > > skip check. Raghu, I am not sure if this is exactly what you want
> > > implemented in v4.
> > >
> >
> > Andrew, Yes that is what I had. I think there was a mis-understanding.
> > My intention was to if there is a directed_yield happened in runqueue
> > (say rqA), do not bother to directed yield to that. But unfortunately as
> > PeterZ pointed that would have resulted in setting next buddy of a
> > different run queue than rqA.
> > So we can drop this "skip" idea. Pondering more over what to do? can we
> > use next buddy itself ... thinking..
>
> As I mentioned earlier today, I did not have your changes from kvm.git
> tree when I tested my changes. Here are your changes and my changes
> compared:
>
> throughput in MB/sec
>
> kvm_vcpu_on_spin changes: 4636 +/- 15.74%
> yield_to changes:4515 +/- 12.73%
>
> I would be inclined to stick with your changes which are kept in kvm
> code. I did try both combined, and did not get good results:
>
> both changes:4074 +/- 19.12%
>
> So, having both is probably not a good idea. However, I feel like
> there's more work to be done. With no over-commit (10 VMs), total
> throughput is 23427 +/- 2.76%. A 2x over-commit will no doubt have some
> overhead, but a reduction to ~4500 is still terrible. By contrast,
> 8-way VMs with 2x over-commit have a total throughput roughly 10% less
> than 8-way VMs with no overcommit (20 vs 10 8-way VMs on 80 cpu-thread
> host). We still have what appears to be scalability problems, but now
> it's not so much in runqueue locks for yield_to(), but now
> get_pid_task():
>
Hi Andrew,
IMHO, reducing the double runqueue lock overhead is a good idea,
and may be we see the benefits when we increase the overcommit further.
The explaination for not seeing good benefit on top of PLE handler
optimization patch is because we filter the yield_to candidates,
and hence resulting in less contention for double runqueue lock.
and extra code overhead during genuine yield_to might have resulted in
some degradation in the case you tested.
However, did you use cfs.next also?. I hope it helps, when we combine.
Here is the result that is showing positive benefit.
I experimented on a 32 core (no HT) PLE machine with 32 vcpu guest(s).
+---+---+---++---+
kernbench time in sec, lower is better
Re: [PATCH 1/2] mfd/janz-cmodio: fix MODULBus number sysfs entry
On 09/12/2012 12:58 AM, Ira W. Snyder wrote: > From: "Ira W. Snyder" > > Revision 1.0 of the Janz CMOD-IO Carrier Board does not contain zeroes > in the top 4 bits of the modulbus_num (int_enable) register. Mask off > the unused bits so that the correct value is displayed in sysfs. > > Cc: Samuel Ortiz > Signed-off-by: Ira W. Snyder Who will take care of this patch? Marc > --- > drivers/mfd/janz-cmodio.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/mfd/janz-cmodio.c b/drivers/mfd/janz-cmodio.c > index 2ea9998..32d0efd 100644 > --- a/drivers/mfd/janz-cmodio.c > +++ b/drivers/mfd/janz-cmodio.c > @@ -216,7 +216,7 @@ static int __devinit cmodio_pci_probe(struct pci_dev *dev, > } > > /* Read the hex switch on the carrier board */ > - priv->hex = ioread8(>ctrl->int_enable); > + priv->hex = ioread8(>ctrl->int_enable) & 0x0f; > > /* Add the MODULbus number (hex switch value) to the device's sysfs */ > ret = sysfs_create_group(>dev.kobj, _sysfs_attr_group); > -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH] ASoC: codecs: Add DA9055 codec driver
On Wed, 2012-09-12 at 10:57 +0800, Mark Brown wrote: > > > + aif_ctrl |= (DA9055_AIF_OE | DA9055_AIF_EN); > > DAPM. Here the trouble in making it DAPM based is that there is no separate control for AIF input and output. It is confirmed that AIF_EN is the master control bit, which enables both output as well as input. The AIF _OE bit is redundant. If we use the same control bit(i.e AIF_EN) for both DAPM_AIF_IN and DAPM_AIF_OUT, there will be obvious side effects. Is there any other way to take care of this? Or should we leave it outside DAPM? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] can: janz-ican3: fix support for older hardware revisions
On 09/12/2012 12:58 AM, Ira W. Snyder wrote:
> From: "Ira W. Snyder"
>
> The Revision 1.0 Janz CMOD-IO Carrier Board does not have support for
> the reset registers. To support older hardware, the code is changed to
> use the hardware reset register on the Janz VMOD-ICAN3 hardware itself.
>
> Signed-off-by: Ira W. Snyder
Applied to linux-can.
Tnx,
Marc
> ---
> drivers/net/can/janz-ican3.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
> index 98ee438..7edadee 100644
> --- a/drivers/net/can/janz-ican3.c
> +++ b/drivers/net/can/janz-ican3.c
> @@ -1391,7 +1391,6 @@ static irqreturn_t ican3_irq(int irq, void *dev_id)
> */
> static int ican3_reset_module(struct ican3_dev *mod)
> {
> - u8 val = 1 << mod->num;
> unsigned long start;
> u8 runold, runnew;
>
> @@ -1405,8 +1404,7 @@ static int ican3_reset_module(struct ican3_dev *mod)
> runold = ioread8(mod->dpm + TARGET_RUNNING);
>
> /* reset the module */
> - iowrite8(val, >ctrl->reset_assert);
> - iowrite8(val, >ctrl->reset_deassert);
> + iowrite8(0x00, >dpmctrl->hwreset);
>
> /* wait until the module has finished resetting and is running */
> start = jiffies;
>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [GIT PULL] sound fixes for 3.6-rc6
At Thu, 13 Sep 2012 19:51:14 +0800, Linus Torvalds wrote: > > On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote: > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus > > *PLEASE* don't do this. > > You point to a branch, but then the pull request clearly implies there > is a tag with extra information in it. > > And indeed, the actual thing I should pull is not at all "for-linus", > it seems to be your "tags/sound-3.6" tag. > > I don't know if this is the old "git pull-request" breakage where it > stupidly "corrects" the remote branch when it verifies the branch > name, or whether it's some other scripting problem. I think current > git versions should not mess up the tag information, if that's the > cause, but please verify. Oops, yes, it's indeed intended to be tags/sound-3.6. So please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.6 FWIW, it was an output from git-pull-request, which fell back to the equivalent branch. Usually I check it manually but I forgot it at this time just before going to a meeting. This was with git 1.7.11.5. I'll check whether this still happens with 1.7.12. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] media: v4l2-ctrl: add a helper function to modify the menu
On Thu 13 September 2012 13:43:36 Prabhakar Lad wrote:
> Hi Laurent,
>
> Thanks for the review.
>
> On Thursday 13 September 2012 06:45 AM, Laurent Pinchart wrote:
> > Hi Prabhakar,
> >
> > Thanks for the patch.
> >
> > On Tuesday 11 September 2012 19:53:38 Prabhakar Lad wrote:
> >> From: Lad, Prabhakar
> >>
> >> Add a helper function to modify the menu, max and default value
> >> to set.
> >>
> >> Signed-off-by: Lad, Prabhakar
> >> Signed-off-by: Manjunath Hadli
> >> Cc: Hans Verkuil
> >> Cc: Sakari Ailus
> >> Cc: Sylwester Nawrocki
> >> Cc: Laurent Pinchart
> >> Cc: Mauro Carvalho Chehab
> >> Cc: Hans de Goede
> >> Cc: Kyungmin Park
> >> Cc: Guennadi Liakhovetski
> >> Cc: Rob Landley
> >> ---
> >> Changes for v3:
> >> 1: Fixed style/grammer issues as pointed by Hans.
> >>Thanks Hans for providing the description.
> >>
> >> Changes for v2:
> >> 1: Fixed review comments from Hans, to have return type as
> >>void, add WARN_ON() for fail conditions, allow this fucntion
> >>to modify the menu of custom controls.
> >>
> >> Documentation/video4linux/v4l2-controls.txt | 29
> >>
> >> drivers/media/v4l2-core/v4l2-ctrls.c| 17 +++
> >> include/media/v4l2-ctrls.h | 11 ++
> >> 3 files changed, 57 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/Documentation/video4linux/v4l2-controls.txt
> >> b/Documentation/video4linux/v4l2-controls.txt index 43da22b..01d0a82 100644
> >> --- a/Documentation/video4linux/v4l2-controls.txt
> >> +++ b/Documentation/video4linux/v4l2-controls.txt
> >> @@ -367,6 +367,35 @@ it to 0 means that all menu items are supported.
> >> You set this mask either through the v4l2_ctrl_config struct for a custom
> >> control, or by calling v4l2_ctrl_new_std_menu().
> >>
> >> +There are situations where menu items may be device specific. In such
> >> cases
> >> the
> >> +framework provides a helper function to change the menu:
> >> +
> >> +void v4l2_ctrl_modify_menu(struct v4l2_ctrl *ctrl, const char * const
> >> *qmenu,
> >> + s32 max, u32 menu_skip_mask, s32 def);
> >
> > Sorry if this is a stupid question, but wouldn't it be better to add a
> > function to create a custom menu instead of modifying it afterwards ?
> >
> Create a custom menu? eventually everything boils down to modifying the
> menu itself.
Laurent, the reason we went for modifying a standard control is that that
ensures that the control name and type is all standardized. The only thing
that can be changed later is the menu contents.
Regards,
Hans
>
> Regards,
> --Prabhakar Lad
>
> >> +
> >> +A good example is the test pattern control for capture/display/sensors
> >> devices
> >> +that have the capability to generate test patterns. These test patterns
> >> are
> >> +hardware specific, so the contents of the menu will vary from device to
> >> device.
> >> +
> >> +This helper function is used to modify the menu, max, mask and the default
> >> +value of the control.
> >> +
> >> +Example:
> >> +
> >> + static const char * const test_pattern[] = {
> >> + "Disabled",
> >> + "Vertical Bars",
> >> + "Solid Black",
> >> + "Solid White",
> >> + NULL,
> >> + };
> >> + struct v4l2_ctrl *test_pattern_ctrl =
> >> + v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
> >> + V4L2_CID_TEST_PATTERN, V4L2_TEST_PATTERN_DISABLED, 0,
> >> + V4L2_TEST_PATTERN_DISABLED);
> >> +
> >> + v4l2_ctrl_modify_menu(test_pattern_ctrl, test_pattern, 3, 0,
> >> + V4L2_TEST_PATTERN_DISABLED);
> >>
> >> Custom Controls
> >> ===
> >
>
>
--
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: [alsa-devel] [PATCH] ASoC: codecs: Add DA9055 codec driver
On Thu, Sep 13, 2012 at 05:38:36PM +0530, Ashish Chavan wrote: > On Wed, 2012-09-12 at 10:57 +0800, Mark Brown wrote: > > > + aif_ctrl |= (DA9055_AIF_OE | DA9055_AIF_EN); > > DAPM. > Here the trouble in making it DAPM based is that there is no separate > control for AIF input and output. It is confirmed that AIF_EN is the > master control bit, which enables both output as well as input. The AIF > _OE bit is redundant. If we use the same control bit(i.e AIF_EN) for > both DAPM_AIF_IN and DAPM_AIF_OUT, there will be obvious side effects. > Is there any other way to take care of this? Or should we leave it > outside DAPM? Use a supply widget. -- 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 0/5] ARM: topology: set the capacity of each cores for big.LITTLE
On Thu, 2012-09-13 at 11:17 +0200, Vincent Guittot wrote: > On 10 July 2012 15:42, Peter Zijlstra wrote: > > On Tue, 2012-07-10 at 14:35 +0200, Vincent Guittot wrote: > >> > >> May be the last one which enable ARCH_POWER should also go into tip ? > >> > > OK, I can take it. > > Hi Peter, > > I can't find the patch that enable ARCH_POWER in the tip tree. Have > you take it in your tree ? Uhmmm how about I say I have now? Sorry about that. -- 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] SUNRPC: check current nsproxy before set of node name on client creation
10.09.2012 19:41, Myklebust, Trond пишет: On Mon, 2012-09-10 at 19:37 +0400, Stanislav Kinsbursky wrote: Hi, Trond. So, if I understand you right, we can create rpc client (or increase usage counter) on NSMPROC_MON call and destroy (or decrease usage counter) on NSMPROC_UNMON call. Will this solution works? The rpc client(s) will need to be per-net-namespace, which complicates matters a little bit, but yes, creation at NSMPROC_MON, and destruction at NSMPROC_UNMON should work. Hi, Trond. With reference-counted NSM client I got this: BUG: unable to handle kernel NULL pointer dereference at 0008 IP: [] encode_mon_id+0x2e/0x64 [lockd] PGD 0 Oops: [#1] SMP DEBUG_PAGEALLOC Modules linked in: nfsv3 nfs_acl nfs lockd veth sunrpc bridge stp llc i2c_piix4 i2c_core virtio_blk virtio_net floppy virtio_pci virtio_ring virtio CPU 1 Pid: 1174, comm: bash Not tainted 3.5.0-kitchensink+ #44 Bochs Bochs RIP: 0010:[] [] encode_mon_id+0x2e/0x64 [lockd] RSP: 0018:88001d0f1a08 EFLAGS: 00010246 RAX: RBX: 88001d0f1c38 RCX: RDX: 88001c85803f RSI: 88001d23b204 RDI: 88001d0f1a48 RBP: 88001d0f1a18 R08: 88001c858040 R09: 0003 R10: 88001a5aba10 R11: 88001d0f1ac8 R12: 88001d0f1a48 R13: 88001a8a3138 R14: a008d580 R15: a00c0db5 FS: 7f0d60eea700() GS:88001f70() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0008 CR3: 1db3d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process bash (pid: 1174, threadinfo 88001d0f, task 88001d1f4160) Stack: 88001d0f1a48 88001c858030 88001d0f1a28 a00c0dc9 88001d0f1ab8 a00731a0 88001a5aba10 88001d0f1c38 88001c858040 88001a8a3140 88001c858854 88001a8a3140 Call Trace: [] nsm_xdr_enc_unmon+0x14/0x16 [lockd] [] rpcauth_wrap_req+0xa1/0xb2 [sunrpc] [] ? xprt_prepare_transmit+0x83/0x93 [sunrpc] [] call_transmit+0x1e4/0x263 [sunrpc] [] __rpc_execute+0xe7/0x313 [sunrpc] [] ? call_transmit_status+0xb8/0xb8 [sunrpc] [] ? wake_up_bit+0x25/0x2a [] rpc_execute+0x9d/0xa5 [sunrpc] [] rpc_run_task+0x7e/0x86 [sunrpc] [] rpc_call_sync+0x44/0x65 [sunrpc] [] nsm_mon_unmon+0x81/0xad [lockd] [] nsm_unmonitor+0x82/0x13a [lockd] [] nlm_destroy_host_locked+0x93/0xc9 [lockd] [] nlmclnt_release_host+0xb3/0xc3 [lockd] [] nlmclnt_done+0x1a/0x26 [lockd] [] nfs_destroy_server+0x24/0x26 [nfs] [] nfs_free_server+0xad/0x134 [nfs] [] nfs_kill_super+0x22/0x26 [nfs] [] deactivate_locked_super+0x26/0x57 [] deactivate_super+0x45/0x4c [] mntput_no_expire+0x110/0x119 [] mntput+0x2a/0x2c [] release_mounts+0x72/0x84 [] put_mnt_ns+0x6f/0x7e [] free_nsproxy+0x1f/0x87 [] switch_task_namespaces+0x5c/0x65 [] exit_task_namespaces+0x10/0x12 [] do_exit+0x69b/0x84f [] do_group_exit+0x83/0xae [] sys_exit_group+0x17/0x1b [] system_call_fastpath+0x16/0x1b Code: e5 41 54 53 66 66 66 66 90 48 89 f3 49 89 fc 48 8b 76 18 e8 93 ff ff ff 4c 89 e7 65 48 8b 04 25 c0 b9 00 00 48 8b 80 00 05 00 00 <48> 8b 70 08 48 83 c6 45 e8 73 ff ff ff 4c 89 e7 be 0c 00 00 00 RIP [] encode_mon_id+0x2e/0x64 [lockd] There are more places, where NFS and Lockd code dereference utsname(). In XDR layer, for instance. So, probably, we have to tie NFS to utsns as well as to netns. Add one more ns to xprt? What do you think? -- 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: [RFC][PATCH] perf, intel: Don't touch MSR_IA32_DEBUGCTLMSR from NMI context
On Thu, 2012-09-13 at 13:49 +0200, Stephane Eranian wrote: > Should be, though it is pretty ugly to stash all of this in the > put/get constraints. Agreed, I almost added two extra functions for it but when I went to look at where to call them I ended up next to get/put constraints. > I will run some tests. > > I wonder what this does when you come in to get/put with a fake cpuc. You > don't > want to perturb the local lbr which may be in use. Fake cpu will never set ->alloc and thus intel_pmu_has_lbr() should fail and we don't do anything. -- 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] Improving directed yield scalability for PLE handler
On 09/11/2012 09:27 PM, Andrew Theurer wrote: > > So, having both is probably not a good idea. However, I feel like > there's more work to be done. With no over-commit (10 VMs), total > throughput is 23427 +/- 2.76%. A 2x over-commit will no doubt have some > overhead, but a reduction to ~4500 is still terrible. By contrast, > 8-way VMs with 2x over-commit have a total throughput roughly 10% less > than 8-way VMs with no overcommit (20 vs 10 8-way VMs on 80 cpu-thread > host). We still have what appears to be scalability problems, but now > it's not so much in runqueue locks for yield_to(), but now > get_pid_task(): > > perf on host: > > 32.10% 320131 qemu-system-x86 [kernel.kallsyms] [k] get_pid_task > 11.60% 115686 qemu-system-x86 [kernel.kallsyms] [k] _raw_spin_lock > 10.28% 102522 qemu-system-x86 [kernel.kallsyms] [k] yield_to > 9.17% 91507 qemu-system-x86 [kvm] [k] kvm_vcpu_on_spin > 7.74% 77257 qemu-system-x86 [kvm] [k] kvm_vcpu_yield_to > 3.56% 35476 qemu-system-x86 [kernel.kallsyms] [k] __srcu_read_lock > 3.00% 29951 qemu-system-x86 [kvm] [k] __vcpu_run > 2.93% 29268 qemu-system-x86 [kvm_intel] [k] vmx_vcpu_run > 2.88% 28783 qemu-system-x86 [kvm] [k] vcpu_enter_guest > 2.59% 25827 qemu-system-x86 [kernel.kallsyms] [k] __schedule > 1.40% 13976 qemu-system-x86 [kernel.kallsyms] [k] _raw_spin_lock_irq > 1.28% 12823 qemu-system-x86 [kernel.kallsyms] [k] resched_task > 1.14% 11376 qemu-system-x86 [kvm_intel] [k] vmcs_writel > 0.85% 8502 qemu-system-x86 [kernel.kallsyms] [k] pick_next_task_fair > 0.53% 5315 qemu-system-x86 [kernel.kallsyms] [k] native_write_msr_safe > 0.46% 4553 qemu-system-x86 [kernel.kallsyms] [k] native_load_tr_desc > > get_pid_task() uses some rcu fucntions, wondering how scalable this > is I tend to think of rcu as -not- having issues like this... is > there a rcu stat/tracing tool which would help identify potential > problems? It's not, it's the atomics + cache line bouncing. We're basically guaranteed to bounce here. Here we're finally paying for the ioctl() based interface. A syscall based interface would have a 1:1 correspondence between vcpus and tasks, so these games would be unnecessary. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] IIO : ADC: tiadc: Add support of TI's ADC driver
On 13/09/12 11:40, Patil, Rachna wrote:
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
There's a little fuzz in applying this due to other drivers that have
gone in recently.
Actually this is going to be 'interesting' to merge. Dmitry, Samuel
thoughts on who takes this one and how? Maybe this is a case for a
'special' branch pulled into more than one tree?
One minor thing inline. I have an aversion to dynamic allocation of
things that are then constant.
Also the module name is simply ti_adc. Does seem a little 'vague'
given the range of ADC's TI makes :) Perhaps keep the reference
to the tsc in there? Personally I'd have preferred the whole thing
being named after a particular part number (any one it support would
do) to avoid a clash in future with a new touch screen adc from TI.
Bit late for that though I guess ;)
Jonathan
---
Changes in v2:
Addressed review comments from Matthias Kaehlcke
Changes in v3:
Addressed review comments from Jonathan Cameron.
Added comments, new line appropriately.
drivers/iio/adc/Kconfig |7 +
drivers/iio/adc/Makefile |1 +
drivers/iio/adc/ti_adc.c | 223 ++
drivers/mfd/ti_tscadc.c | 18 +++-
include/linux/mfd/ti_tscadc.h|9 ++-
include/linux/platform_data/ti_adc.h | 14 ++
6 files changed, 270 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/adc/ti_adc.c
create mode 100644 include/linux/platform_data/ti_adc.h
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 8a78b4f..ad32df8 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -22,4 +22,11 @@ config AT91_ADC
help
Say yes here to build support for Atmel AT91 ADC.
+config TI_ADC
+ tristate "TI's ADC driver"
+ depends on ARCH_OMAP2PLUS
+ 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 52eec25..a930cee 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_AD7266) += ad7266.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
+obj-$(CONFIG_TI_ADC) += ti_adc.o
diff --git a/drivers/iio/adc/ti_adc.c b/drivers/iio/adc/ti_adc.c
new file mode 100644
index 000..56f8af2
--- /dev/null
+++ b/drivers/iio/adc/ti_adc.c
@@ -0,0 +1,223 @@
+/*
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct adc_device {
+ struct ti_tscadc_dev *mfd_tscadc;
+ struct iio_dev *idev;
+ int channels;
+};
+
+static unsigned int adc_readl(struct adc_device *adc, unsigned int reg)
+{
+ return readl(adc->mfd_tscadc->tscadc_base + reg);
+}
+
+static void adc_writel(struct adc_device *adc, unsigned int reg,
+ unsigned int val)
+{
+ writel(val, adc->mfd_tscadc->tscadc_base + reg);
+}
+
+static void adc_step_config(struct adc_device *adc_dev)
+{
+ unsigned intstepconfig;
+ 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++) {
+ adc_writel(adc_dev, REG_STEPCONFIG(i),
+ stepconfig | STEPCONFIG_INP(channels));
+ adc_writel(adc_dev, REG_STEPDELAY(i),
+ STEPCONFIG_OPENDLY);
+ channels++;
+ }
+ adc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+}
+
+static int tiadc_channel_init(struct iio_dev *idev, int channels)
+{
+ struct iio_chan_spec *chan_array;
+
Re: [PATCH REPOST RFC cgroup/for-3.7] cgroup: mark subsystems with broken hierarchy support and whine if cgroups are nested for them
On Wed 12-09-12 10:11:20, Tejun Heo wrote: > Hello, > > On Wed, Sep 12, 2012 at 05:49:07PM +0200, Michal Hocko wrote: > > > While I respect your goal of not warning about any configuration > > > with max_level = 1, I believe the only sane configuration as soon > > > as we get any 2nd-level child is use_hierarchy = 1 for everybody. > > > > > > Everything aside from it should be warned. > > > > Defintely. And that what the above guarantess, doesn't it? > > I'm getting a bit worried that I might not be fully understanding what > your concern is. Can you please elaborate what your worries are and > the transition plan that you have in your mind regarding > .use_hierarchy? I would like to see use_hierarchy go away. The only concern I have is to warn only if somebody is doing something wrong (aka flat hierarchies). Or better put it this way. Do not warn in cases which do not change if use_hierarchy is gone or default changes to 1. An example: root (use_hierarchy=0) | \ | A (use_hierarchy=0) | B (use_hierarachy=1) |\ C D is a perfectly sane configuration and I do not see any reason to fill logs with some scary warnings when A is created. There will be no semantical change in this setup When use_hierchy is gone. So the only thing I am proposing here is to warn only if something should be fixed in the configuration in order to be prepared for fully hierarchical (and that is a second level of children from root with use_hierachy==0). Does it make more sense now? -- 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: [PATCH] genalloc: make possible to use a custom allocation algorithm
>From b78b2fea3899c5170b780f5ff138490ac6cf4cb7 Mon Sep 17 00:00:00 2001
From: Benjamin Gaignard
Date: Thu, 13 Sep 2012 11:29:03 +0200
Subject: [PATCH] genalloc: make possible to use a custom allocation algorithm
This patch allow to use another algorithm than the default first-fit one.
For example a custom algorithm could be used to manage alignment requirements.
As I can't predict all the possible requirements/needs for all allocation
uses cases, I add a "free" field 'void *data' to pass any needed information
to the allocation function. For example 'data' could be used to handle
a structure
where you store the alignment, the expected memory bank, the requester
device, or any information that could influence the allocation algorithm.
An usage example may look like this:
struct my_pool_constraints {
int align;
int bank;
...
};
unsigned long my_custom_algo(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data)
{
struct my_pool_constraints *constraints = data;
...
deal with allocation contraints
...
return the index in bitmap where perform the allocation
}
void create_my_pool()
{
struct my_pool_constraints c;
struct gen_pool *pool = gen_pool_create(...);
gen_pool_add(pool, ...);
gen_pool_set_algo(pool, my_custom_algo, );
}
Add of best-fit algorithm function:
most of the time best-fit is slower then first-fit but memory fragmentation
is lower. The random buffer allocation/free tests don't show any arithmetic
relation between the allocation time and fragmentation but the
best-fit algorithm
is sometime able to perform the allocation when the first-fit can't.
This new algorithm help to remove static allocations on ESRAM, a small but
fast on-chip RAM of few KB, used for high-performance uses cases like DMA
linked lists, graphic accelerators, encoders/decoders. On the Ux500
(in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
static allocations becomes unmaintainable:
cd arch/arm/mach-ux500 && grep -r ESRAM .
./include/mach/db8500-regs.h:/* Base address and bank offsets for ESRAM */
./include/mach/db8500-regs.h:#define U8500_ESRAM_BASE 0x4000
./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK_SIZE 0x0002
./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK0 U8500_ESRAM_BASE
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK1 (U8500_ESRAM_BASE + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK2 (U8500_ESRAM_BANK1 + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK3 (U8500_ESRAM_BANK2 + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define
U8500_ESRAM_BANK4 (U8500_ESRAM_BANK3 + U8500_ESRAM_BANK_SIZE)
./include/mach/db8500-regs.h:#define U8500_ESRAM_DMA_LCPA_OFFSET 0x1
./include/mach/db8500-regs.h:#define U8500_DMA_LCPA_BASE
(U8500_ESRAM_BANK0 + U8500_ESRAM_DMA_LCPA_OFFSET)
./include/mach/db8500-regs.h:#define U8500_DMA_LCLA_BASE U8500_ESRAM_BANK4
I want to use genalloc to do dynamic allocations but I need to be able to
fine tune the allocation algorithm. I my case best-fit algorithm give
better results than first-fit, but it will not be true for every use case.
Signed-off-by: Benjamin Gaignard
---
include/linux/genalloc.h | 27 ++
lib/genalloc.c | 88 +++---
2 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 5e98eeb..dd7c569 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -29,6 +29,20 @@
#ifndef __GENALLOC_H__
#define __GENALLOC_H__
+/**
+ * Allocation callback function type definition
+ * @map: Pointer to bitmap
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @data: optional additional data used by @genpool_algo_t
+ */
+typedef unsigned long (*genpool_algo_t)(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ void *data);
+
/*
* General purpose special memory pool descriptor.
*/
@@ -36,6 +50,9 @@ struct gen_pool {
spinlock_t lock;
struct list_head chunks;/* list of chunks in this pool */
int min_alloc_order;/* minimum allocation order */
+
+ genpool_algo_t algo;/* allocation function */
+ void *data;
};
/*
@@ -78,4 +95,14 @@ extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
extern size_t gen_pool_avail(struct gen_pool *);
extern size_t gen_pool_size(struct gen_pool *);
+
+extern void gen_pool_set_algo(struct gen_pool *pool, genpool_algo_t algo,
+ void *data);
+
+extern unsigned
Re: [PATCH REPOST RFC cgroup/for-3.7] cgroup: mark subsystems with broken hierarchy support and whine if cgroups are nested for them
On Mon, Sep 10, 2012 at 03:33:55PM -0700, Tejun Heo wrote: > (forgot cc'ing containers / cgroups mailing lists and used the old > address for Li. Reposting. Sorry for the noise.) > > Currently, cgroup hierarchy support is a mess. cpu related subsystems > behave correctly - configuration, accounting and control on a parent > properly cover its children. blkio and freezer completely ignore > hierarchy and treat all cgroups as if they're directly under the root > cgroup. Others show yet different behaviors. > > These differing interpretations of cgroup hierarchy make using cgroup > confusing and it impossible to co-mount controllers into the same > hierarchy and obtain sane behavior. > > Eventually, we want full hierarchy support from all subsystems and > probably a unified hierarchy. Users using separate hierarchies > expecting completely different behaviors depending on the mounted > subsystem is deterimental to making any progress on this front. > > This patch adds cgroup_subsys.broken_hierarchy and sets it to %true > for controllers which are lacking in hierarchy support. The goal of > this patch is two-fold. > > * Move users away from using hierarchy on currently non-hierarchical > subsystems, so that implementing proper hierarchy support on those > doesn't surprise them. > > * Keep track of which controllers are broken how and nudge the > subsystems to implement proper hierarchy support. > > For now, start with a single warning message. We can whine louder > later on. If you want application developers / users to understand this, then you really need to update the Documentation/cgroups/cgroups.txt file to provide suitable recommendations on use of hierarchies. As it stands today it arguably encourages apps to make use of arbitrary hierarchies. While some of the other docs (blkio-controller.txt) do describe the limitations of their implementation, they don't ever go as far as recommending against usage of hierarchies, which is what you seem to be saying. Just printing warning messages in the logs with no docs to explain the issues which cause the warnings is not friendly to users, and IMHO will just lead people to ignore the warnings. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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/5] fat: allocate persistent inode numbers
"J. Bruce Fields" writes: >> >> Grepping around... Documentation/sysctl/vm.txt mentions a >> >> vfs_cache_pressure parameter. >> >> Yeah. And dirty hack will be possible to adjust sb->s_shrink.batch. >> > I am worrying if it could lead to OOM condition on embedded >> > system(short memory(DRAM) and support 3TB HDD disk of big size.) >> > >> > Please let me know if any issues or queries. >> >> So, now I think stable inode number may be useful if there are users of >> it. And I guess those functionality is no collisions with -mm. And I >> suppose we can add two modes for "nfs" option (e.g. nfs=1 and nfs=2). >> >> If nfs=1, works like current -mm without no limited operations. > > Apologies, I haven't been following the conversation carefully: remind > me what "works like current -mm" means? Current -mm means the best-effort work only if inode cache is not evicted. I.e. if there is no inode cache anymore on server, server would return ESTALE. So I guess the behavior would not be stable relatively. Thanks. >> If nfs=2, try to make stable FH and limit some operations >> >> (option name doesn't matter here.) >> >> Does this work fine? -- OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] perf: use hrtimer for event multiplexing
On Wed, 2012-09-12 at 17:37 +0200, Stephane Eranian wrote: > Note however that the rotation_list is still used in perf_event_task_tick() > to iterate over the ctx which needs unthrottling. We would have to switch > that loop over to a for-each-pmu() which would necessary incur more > iterations as it would include all the SW PMUs. Oh urgh, right. I think that was one of the reasons I bailed on the hrtimer thing, the frequency and throttle stuff. ctx->nr_freq and needs_unthr could help, but yeah. -- 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/
