[PATCH] arch: arm64: kernel: add '#ifdef CONFIG_COMPAT' for aarch32_break_handler()
If 'COMPAT' not defined, aarch32_break_handler() cannot pass compiling,
so need add '#ifdef' for it just like the header file has done.
The related make:
make ARCH=arm64 randconfig
make ARCH=arm64 menuconfig
make ARCH=arm64 V=1 EXTRA_CFLAGS=-W
The related error:
arch/arm64/kernel/debug-monitors.c:249:5: error: redefinition of
‘aarch32_break_handler’
In file included from arch/arm64/kernel/debug-monitors.c:29:0:
/root/linux-next/arch/arm64/include/asm/debug-monitors.h:89:12: note:
previous definition of ‘aarch32_break_handler’ was here
Signed-off-by: Chen Gang
---
arch/arm64/kernel/debug-monitors.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index 08018e3..ceedcd7 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -246,6 +246,7 @@ static int brk_handler(unsigned long addr, unsigned int esr,
return 0;
}
+#ifdef CONFIG_COMPAT
int aarch32_break_handler(struct pt_regs *regs)
{
siginfo_t info;
@@ -285,6 +286,7 @@ int aarch32_break_handler(struct pt_regs *regs)
force_sig_info(SIGTRAP, , current);
return 0;
}
+#endif
static int __init debug_traps_init(void)
{
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch: sparc: kernel: check the memory length before use strcpy().
For the related next strcpy(), the destination length is less than 512,
but the source maximize length may be 'OPROMMAXPARAM' (4096) which is
more than 512.
One work flow may:
openprom_sunos_ioctl() -> if (cmd == OPROMSETOPT)
getstrings() -> will alloc buffer with size 'OPROMMAXPARAM'.
opromsetopt() -> devide the buffer into 'var' and 'value'
of_set_property() -> pass
prom_setprop() -> pass
ldom_set_var()
And do not mind the additional 4 alignment buffer increasing, since
'sizeof(pkt) - sizeof(pkt.header)' is 4 alignment at least.
Signed-off-by: Chen Gang
---
arch/sparc/kernel/ds.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/sparc/kernel/ds.c b/arch/sparc/kernel/ds.c
index 5ef48da..11d460f 100644
--- a/arch/sparc/kernel/ds.c
+++ b/arch/sparc/kernel/ds.c
@@ -783,6 +783,16 @@ void ldom_set_var(const char *var, const char *value)
char *base, *p;
int msg_len, loops;
+ if (strlen(var) + strlen(value) + 2 >
+ sizeof(pkt) - sizeof(pkt.header)) {
+ printk(KERN_ERR PFX
+ "contents length: %zu, which more than max:
%lu,"
+ "so could not set (%s) variable to (%s).\n",
+ strlen(var) + strlen(value) + 2,
+ sizeof(pkt) - sizeof(pkt.header), var, value);
+ return;
+ }
+
memset(, 0, sizeof(pkt));
pkt.header.data.tag.type = DS_DATA;
pkt.header.data.handle = cp->handle;
--
1.7.11.7
--
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 04/11] tracing: fix disabling of soft disable
On Fri, 2013-06-21 at 16:14 -0500, Tom Zanussi wrote: > On Fri, 2013-06-21 at 16:39 -0400, Steven Rostedt wrote: > > On Fri, 2013-06-21 at 20:12 +0900, Masami Hiramatsu wrote: > > > (2013/06/21 3:31), Tom Zanussi wrote: > > > > The comment on the soft disable 'disable' case of > > > > __ftrace_event_enable_disable() states that the soft disable bit > > > > should be cleared in that case, but currently only the soft mode bit > > > > is actually cleared. > > > > > > > > This essentially leaves the standard non-soft-enable enable/disable > > > > paths as the only way to clear the soft disable flag, but the soft > > > > disable bit should also be cleared when removing a trigger with '!'. > > > > > > Indeed, the soft-disabled flag may remain after the event itself > > > disabled. However that soft-disabled flag will be cleared when > > > the event is re-enabled. it seems no bad side-effect. > > > > > > Thus I doubt this patch is separately required. I guess this is > > > required for adding new trigger flag, isn't it? :) > > > > Tom, I'm guessing Masami is correct here. It's needed for the trigger > > work to work, correct? > > > > Well, the trigger should really work without this - this is basically > just a cleanup I added because it bothered me that I couldn't completely > revert the enable state back to the original state that existed before I > added the trigger (by reverting the trigger using '!'). It also just > seemed obviously correct from looking at the code as well (though I > agree, it's hard to keep the state machine of that function in your head > in order to prove it correct, and the straggling soft-disable state > hasn't bothered anyone until now, so maybe it's not worth it..) > Looking into this a bit more, I think the reason it hasn't bothered anyone until now is that it's been hidden by the existing event_enable_read() implementation, which doesn't show any soft disable state when the event is actually disabled, only when it's enabled. So the case where SOFT_DISABLED is still set but the event is actually disabled gets hidden by the catch-all "0" case. My new version of event_enable_read() does show the soft disabled state when the event is actually disabled, which is why I noticed it wasn't getting turned off, and led to the current patch. Ironically, the reason I refactored the function in the first place was to add the '+' flag for triggers - redundant, yes, but useful for debugging, not quite in the way I planned though. ;-) (It might be that leaving the current function in place and remaining oblivious would be ok, too, since it doesn't seem to really cause much of a problem in any case...) Tom > In any case, if the SOFT_DISABLED bit is erroneously set but there are > no triggers, it shouldn't be a problem, since the trigger calls would > just return immediately, so not having this patch wouldn't break > anything... > > Tom > > > > Either way, I probably could add it as a clean up patch regardless. I'll > > just have to test the hell out of it some more, as the accounting for > > soft-disable vs real disable was a PITA. > > > > > > -- 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/
Re: RFC: named anonymous vmas
On Fri, Jun 21, 2013 at 10:12 PM, Kyungmin Park wrote: > On Sat, Jun 22, 2013 at 8:42 AM, Colin Cross wrote: >> One of the features of ashmem (drivers/staging/android/ashmem.c) that >> hasn't gotten much discussion about moving out of staging is named >> anonymous memory. >> >> In Android, ashmem is used for three different features, and most >> users of it only care about one feature at a time. One is volatile >> ranges, which John Stultz has been implementing. The second is >> anonymous shareable memory without having a world-writable tmpfs that >> untrusted apps could fill with files. The third and most heavily used >> feature within the Android codebase is named anonymous memory, where a >> region of anonymous memory can have a name associated with it that >> will show up in /proc/pid/maps. The Dalvik VM likes to use this > > Good to know it. I didn't know ashmem provides these features. > we are also discussing these requirement internally. and study how to > show who request these anon memory and which callback is used for it. > >> feature extensively, even for memory that will never be shared and >> could easily be allocated using an anonymous mmap, and even malloc has >> used it in the past. It provides an easy way to collate memory used >> for different purposes across multiple processes, which Android uses >> for its "dumpsys meminfo" and "librank" tools to determine how much >> memory is used for java heaps, JIT caches, native mallocs, etc. > Same requirement for app developers. they want to know what's the > meaning these anon memory is allocated and how to find out these anon > memory is allocated at their codes. >> >> I'd like to add this feature for anonymous mmap memory. I propose >> adding an madvise2(unsigned long start, size_t len_in, int behavior, >> void *ptr, size_t size) syscall and a new MADV_NAME behavior, which >> treats ptr as a string of length size. The string would be copied >> somewhere reusable in the kernel, or reused if it already exists, and >> the kernel address of the string would get stashed in a new field in >> struct vm_area_struct. Adjacent vmas would only get merged if the >> name pointer matched, and naming part of a mapping would split the >> mapping. show_map_vma would print the name only if none of the other >> existing names rules match. > Do you want to create new syscall? can it use current madvise and only > allow this feature at linux only? > As you know it's just hint and it doesn't break existing memory behaviors. The existing madvise syscall only takes a single int to modify the vma, which is not enough to pass a pointer to a string. -- 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: named anonymous vmas
On Sat, Jun 22, 2013 at 8:42 AM, Colin Cross wrote: > One of the features of ashmem (drivers/staging/android/ashmem.c) that > hasn't gotten much discussion about moving out of staging is named > anonymous memory. > > In Android, ashmem is used for three different features, and most > users of it only care about one feature at a time. One is volatile > ranges, which John Stultz has been implementing. The second is > anonymous shareable memory without having a world-writable tmpfs that > untrusted apps could fill with files. The third and most heavily used > feature within the Android codebase is named anonymous memory, where a > region of anonymous memory can have a name associated with it that > will show up in /proc/pid/maps. The Dalvik VM likes to use this Good to know it. I didn't know ashmem provides these features. we are also discussing these requirement internally. and study how to show who request these anon memory and which callback is used for it. > feature extensively, even for memory that will never be shared and > could easily be allocated using an anonymous mmap, and even malloc has > used it in the past. It provides an easy way to collate memory used > for different purposes across multiple processes, which Android uses > for its "dumpsys meminfo" and "librank" tools to determine how much > memory is used for java heaps, JIT caches, native mallocs, etc. Same requirement for app developers. they want to know what's the meaning these anon memory is allocated and how to find out these anon memory is allocated at their codes. > > I'd like to add this feature for anonymous mmap memory. I propose > adding an madvise2(unsigned long start, size_t len_in, int behavior, > void *ptr, size_t size) syscall and a new MADV_NAME behavior, which > treats ptr as a string of length size. The string would be copied > somewhere reusable in the kernel, or reused if it already exists, and > the kernel address of the string would get stashed in a new field in > struct vm_area_struct. Adjacent vmas would only get merged if the > name pointer matched, and naming part of a mapping would split the > mapping. show_map_vma would print the name only if none of the other > existing names rules match. Do you want to create new syscall? can it use current madvise and only allow this feature at linux only? As you know it's just hint and it doesn't break existing memory behaviors. > > Any comments as I start implementing it? Is there any reason to allow > naming a file-backed mapping and showing it alongside the file name in > /proc/pid/maps? > Thank you, Kyungmin Park -- 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 03/11] tracing: add soft disable for syscall events
On Sat, Jun 22, 2013 at 4:22 AM, Steven Rostedt wrote:
> On Fri, 2013-06-21 at 14:53 +0800, zhangwei(Jovi) wrote:
>> On 2013/6/21 2:31, Tom Zanussi wrote:
>> > Add support for SOFT_DISABLE to syscall events.
>> >
>> > The original SOFT_DISABLE patches didn't add support for soft disable
>> > of syscall events; this adds it and paves the way for future patches
>> > allowing triggers to be added to syscall events, since triggers are
>> > built on top of SOFT_DISABLE.
>> >
>> > Because the trigger and SOFT_DISABLE bits are attached to the
>> > ftrace_event_file associated with the event, pointers to the
>> > ftrace_event_files associated with the event are added to the syscall
>> > metadata entry for the event.
>> >
>> > Signed-off-by: Tom Zanussi
>> > ---
>> > include/linux/syscalls.h | 2 ++
>> > include/trace/syscall.h | 5 +
>> > kernel/trace/trace_syscalls.c | 28
>> > 3 files changed, 31 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
>> > index 4147d70..b4c2afa 100644
>> > --- a/include/linux/syscalls.h
>> > +++ b/include/linux/syscalls.h
>> > @@ -158,6 +158,8 @@ extern struct trace_event_functions
>> > exit_syscall_print_funcs;
>> > .args = nb ? args_##sname : NULL, \
>> > .enter_event= _enter_##sname, \
>> > .exit_event = _exit_##sname, \
>> > + .enter_file = NULL, /* Filled in at boot */ \
>> > + .exit_file = NULL, /* Filled in at boot */ \
>> > .enter_fields =
>> > LIST_HEAD_INIT(__syscall_meta_##sname.enter_fields), \
>> > }; \
>> > static struct syscall_metadata __used \
>> > diff --git a/include/trace/syscall.h b/include/trace/syscall.h
>> > index fed853f..ba24d3a 100644
>> > --- a/include/trace/syscall.h
>> > +++ b/include/trace/syscall.h
>> > @@ -19,6 +19,8 @@
>> > * @enter_fields: list of fields for syscall_enter trace event
>> > * @enter_event: associated syscall_enter trace event
>> > * @exit_event: associated syscall_exit trace event
>> > + * @enter_file: associated syscall_enter ftrace event file
>> > + * @exit_file: associated syscall_exit ftrace event file
>> > */
>> > struct syscall_metadata {
>> > const char *name;
>> > @@ -30,6 +32,9 @@ struct syscall_metadata {
>> >
>> > struct ftrace_event_call *enter_event;
>> > struct ftrace_event_call *exit_event;
>> > +
>> > + struct ftrace_event_file *enter_file;
>> > + struct ftrace_event_file *exit_file;
>> > };
>>
>> I doubt this could work correctly.
>> struct ftrace_event_file is allocated dynamically, there could
>> have many ftrace_event_file in there, associated with different trace_array,
>> it means there may have many ftrace_event_file linked with same
>> syscall_metadata.
>>
>> The enter_file/exit_file pointer of syscall_metadata will be override if
>> another
>> ftrace_event_file registered in some other trace_array.
>>
>> Perhaps we could use simple list_head in here, which link with all
>> registered ftrace_event_file.
>>
>> Oleg use "struct event_file_link" for trace_kprobe, the structure could be
>> reuse in here.
>>
>>
>> struct event_file_link {
>> struct ftrace_event_file*file;
>> struct list_headlist;
>> };
>>
>> struct syscall_metadata {
>> const char *name;
>> int syscall_nr;
>> int nb_args;
>> const char **types;
>> const char **args;
>> struct list_head enter_fields;
>>
>> struct ftrace_event_call *enter_event;
>> struct ftrace_event_call *exit_event;
>>
>> struct list_headenter_files;
>> struct list_headexit_files;
>> };
>>
>
>
> I would really like to make these smaller. They are made for every
> system call, and I consider tracing to always be added overhead. I hate
> it when we waste more memory for tracing as very few people use it
> (compared to those that use Linux).
>
> Is it possible to allocate this only when its first used?
>
> -- Steve
I think the answer is yes.
Compare with link ftrace_event_file with static syscall_metadata, another option
is put into structure trace_array, just like enabled_enter_syscalls and
enabled_exit_syscalls BITMAP already in there
(need change to dynamic allocated NR_syscalls array, just keep a
pointer in trace_array).
Then in this way, there don't have any extra size overhead for static
syscall_metadata,
but need to allocate a array with NR_syscalls elements when first use
syscall tracing.
which option do you prefer? steven.
.jovi
--
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] PowerPC: kernel: need return the related error code when failure occurs
Hello Maintainers:
Please help check this patch whether is OK, when you have time.
Thanks.
On 05/21/2013 05:20 PM, Chen Gang wrote:
>
> When error occurs, need return the related error code to let upper
> caller know about it.
>
> ppc_md.nvram_size() can return the error code (e.g. core99_nvram_size()
> in 'arch/powerpc/platforms/powermac/nvram.c').
>
> Also set ret value when only need it, so can save structions for normal
> cases.
>
> The original related patch: "f9ce299 [PATCH] powerpc: fix large nvram
> access".
>
>
> Signed-off-by: Chen Gang
> ---
> arch/powerpc/kernel/nvram_64.c | 20 ++--
> 1 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
> index 48fbc2b..8213ee1 100644
> --- a/arch/powerpc/kernel/nvram_64.c
> +++ b/arch/powerpc/kernel/nvram_64.c
> @@ -84,22 +84,30 @@ static ssize_t dev_nvram_read(struct file *file, char
> __user *buf,
> char *tmp = NULL;
> ssize_t size;
>
> - ret = -ENODEV;
> - if (!ppc_md.nvram_size)
> + if (!ppc_md.nvram_size) {
> + ret = -ENODEV;
> goto out;
> + }
>
> - ret = 0;
> size = ppc_md.nvram_size();
> - if (*ppos >= size || size < 0)
> + if (size < 0) {
> + ret = size;
> + goto out;
> + }
> +
> + if (*ppos >= size) {
> + ret = 0;
> goto out;
> + }
>
> count = min_t(size_t, count, size - *ppos);
> count = min(count, PAGE_SIZE);
>
> - ret = -ENOMEM;
> tmp = kmalloc(count, GFP_KERNEL);
> - if (!tmp)
> + if (!tmp) {
> + ret = -ENOMEM;
> goto out;
> + }
>
> ret = ppc_md.nvram_read(tmp, count, ppos);
> if (ret <= 0)
>
Thanks
--
Chen Gang
Asianux Corporation
--
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] vfio: Limit group opens
On Sat, 2013-06-22 at 13:16 +1000, Alexey Kardashevskiy wrote: > On 06/22/2013 12:57 PM, Alex Williamson wrote: > > On Sat, 2013-06-22 at 12:44 +1000, Alexey Kardashevskiy wrote: > >> On 06/22/2013 11:26 AM, Alex Williamson wrote: > >>> On Sat, 2013-06-22 at 11:16 +1000, Alexey Kardashevskiy wrote: > Cool, thanks! > > So we will need only this (to be called from KVM), and that will be it, > right? > >>> > >>> For what? This is not the external lock you're looking for. As I've > >>> mentioned, the file can only hold the group, but that doesn't give you > >>> any guarantee that the group is protected by the IOMMU. Thanks, > >> > >> > >> I am confused, sorry :) With this patch, a group fd cannot be reopened if > >> already opened, and this is the only way for user space to take control > >> over a group. If it is not an external lock, then what is it? And all I > >> have to do now is to verify that the group fd passed to KVM is correct and > >> I am happy. Who and how can break anything (group? KVM?) now? > > > > By that logic all a user needs to do is open() a group and they they're > > free to pass the fd to KVM, right? But the IOMMU protection isn't > > enabled until the user calls SET_CONTAINER and SET_IOMMU, so you'd be > > giving KVM access to the IOMMU that the user hasn't enabled. The group > > may still have devices attached to host drivers. Likewise, a user need > > only call UNSET_CONTAINER to teardown the IOMMU protection. At that > > point a device could be re-bound to host drivers, thus making it unsafe > > for KVM to be directly poking the IOMMU. > > > > This patch is just a bug fix for inconsistent behavior. Thanks, > > Oh. Thanks for the detailed explanation, I was missing this one. > > Yeah. Looks like we need some other brand new lock now... Something like a > notifier from VFIO to KVM to inform KVM that it can or cannot use the group > now (on VFIO_IOMMU_ENABLE/VFIO_IOMMU_DISABLE or some new ioctls) so KVM > would not touch the group in not allowed. > > typedef int notifier_fn(bool enable); > int vfio_group_iommu_id_from_file(struct file *filep, notifier_fn fn); > > ? I don't think we need either a new lock or a notifier. If we do as Ben suggested and allow KVM to keep the group active then the requirements are pretty much identical to having an open vfio device file descriptor. This is why I suggested container_users. I think the code I proposed will work, it just needs a few more conditions tested when the external user is added to make sure the group is iommu protected. Thanks, Alex -- 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 v12 00/11] DMA Engine support for AM33XX
On Fri, Jun 21, 2013 at 7:07 PM, Joel A Fernandes wrote: > Hi Sekhar, > > On Fri, Jun 21, 2013 at 5:27 AM, Sekhar Nori wrote: >> Joel, >> >> On 6/21/2013 2:36 AM, Joel A Fernandes wrote: >>> From: Joel A Fernandes >>> >>> This series is remaining of Matt Porter's EDMA patches for AM33XX EDMA >>> support >>> with changes for few pending review comments on v11 series. >> >> I have posted a branch with fixes for patches accepted by me in this >> series (also posted inline as replies to specific patches). >> >> https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.11/soc-2 >> >> Can you please give it a good test - especially on AM335x? I will send a >> pull request after you confirm. If you find bugs please send incremental >> patches so I can merge into the original patch. > > [Joel] > This breaks on AM33XX due to dangling pointer, I sent a follow up > patch addressing it. > > However, with this branch I still get.. > mmc: unable to obtain RX DMA engine channel 25 [Joel] Fixed. I posted a v2 patch. With this, on v3.11/soc-2 branch - AM33xx MMC is working (root fs mount). Tested-by: Joel A Fernandes Thanks, Joel -- 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] ARM: common: edma: Fix dangling pointer dereference
Fixup for linux-davinci/soc-v2 branch. Please ignore v1 and use this.
Returning a pointer to a variable in the setup_from_dt function is
causing dangling pointer dereferences. This causes boot to fail
on AM33XX.
Add ninfo to the caller's stack and just return the kzalloc'ed ptr
from the calling function.
v2: Fixed last issue in davinci branch:
ninfo 2D array is used for DT platforms.
info is shared between DT and non-DT cases. So point info to ninfo.
With this MMC is working (rootfs mount) on AM33XX.
Signed-off-by: Sekhar Nori
Signed-off-by: Joel A Fernandes
---
arch/arm/common/edma.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2b591b1..3567ba1 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1514,10 +1514,9 @@ static struct of_dma_filter_info edma_filter_info = {
.filter_fn = edma_filter_fn,
};
-static struct edma_soc_info **edma_setup_info_from_dt(struct device *dev,
+static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
struct device_node *node)
{
- static struct edma_soc_info **info;
struct edma_soc_info *ninfo;
int ret;
@@ -1539,9 +1538,7 @@ static struct edma_soc_info
**edma_setup_info_from_dt(struct device *dev,
of_dma_controller_register(dev->of_node, of_dma_simple_xlate,
_filter_info);
- info =
-
- return info;
+ return ninfo;
}
#else
static struct edma_soc_info **edma_setup_info_from_dt(struct device *dev,
@@ -1554,6 +1551,7 @@ static struct edma_soc_info
**edma_setup_info_from_dt(struct device *dev,
static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev->dev.platform_data;
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL};
s8 (*queue_priority_mapping)[2];
s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
@@ -1572,7 +1570,9 @@ static int edma_probe(struct platform_device *pdev)
int ret;
if (node) {
- info = edma_setup_info_from_dt(dev, node);
+ /* For now, for DT we populate only first ninfo element */
+ ninfo[0] = edma_setup_info_from_dt(dev, node);
+ info = ninfo;
if (IS_ERR(info)) {
dev_err(dev, "failed to get DT data\n");
return PTR_ERR(info);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] target fixes for v3.10-rc7
Hello Linus, Here are the current target-pending fixes queued for v3.10-rc7 code. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master Included is the recent tcm_qla2xxx residual underrun length fix from Roland, along with Joern's iscsi-target patch for session_lock breakage within iscsit_stop_time2retain_timer() code. Both are CC'ed to stable. The remaining two are specific to recent iscsi-target + iser conversion changes. One drops some left-over debug noise, and Andy's patch fixes configfs attribute handling during an explicit network portal feature bit disable when iser-target is unsupported. Thank you, --nab Andy Grover (1): target/iscsi: Fix op=disable + error handling cases in np_store_iser Jörn Engel (1): target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer() Nicholas Bellinger (1): iscsi-target: Remove left over v3.10-rc debug printks Roland Dreier (1): tcm_qla2xxx: Fix residual for underrun commands that fail drivers/scsi/qla2xxx/tcm_qla2xxx.c |6 - drivers/target/iscsi/iscsi_target_configfs.c | 27 + drivers/target/iscsi/iscsi_target_erl0.c |4 +- drivers/target/iscsi/iscsi_target_login.c|3 -- drivers/target/iscsi/iscsi_target_nego.c |3 -- 5 files changed, 21 insertions(+), 22 deletions(-) -- 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] vfio: Limit group opens
On 06/22/2013 12:57 PM, Alex Williamson wrote:
> On Sat, 2013-06-22 at 12:44 +1000, Alexey Kardashevskiy wrote:
>> On 06/22/2013 11:26 AM, Alex Williamson wrote:
>>> On Sat, 2013-06-22 at 11:16 +1000, Alexey Kardashevskiy wrote:
Cool, thanks!
So we will need only this (to be called from KVM), and that will be it,
right?
>>>
>>> For what? This is not the external lock you're looking for. As I've
>>> mentioned, the file can only hold the group, but that doesn't give you
>>> any guarantee that the group is protected by the IOMMU. Thanks,
>>
>>
>> I am confused, sorry :) With this patch, a group fd cannot be reopened if
>> already opened, and this is the only way for user space to take control
>> over a group. If it is not an external lock, then what is it? And all I
>> have to do now is to verify that the group fd passed to KVM is correct and
>> I am happy. Who and how can break anything (group? KVM?) now?
>
> By that logic all a user needs to do is open() a group and they they're
> free to pass the fd to KVM, right? But the IOMMU protection isn't
> enabled until the user calls SET_CONTAINER and SET_IOMMU, so you'd be
> giving KVM access to the IOMMU that the user hasn't enabled. The group
> may still have devices attached to host drivers. Likewise, a user need
> only call UNSET_CONTAINER to teardown the IOMMU protection. At that
> point a device could be re-bound to host drivers, thus making it unsafe
> for KVM to be directly poking the IOMMU.
>
> This patch is just a bug fix for inconsistent behavior. Thanks,
Oh. Thanks for the detailed explanation, I was missing this one.
Yeah. Looks like we need some other brand new lock now... Something like a
notifier from VFIO to KVM to inform KVM that it can or cannot use the group
now (on VFIO_IOMMU_ENABLE/VFIO_IOMMU_DISABLE or some new ioctls) so KVM
would not touch the group in not allowed.
typedef int notifier_fn(bool enable);
int vfio_group_iommu_id_from_file(struct file *filep, notifier_fn fn);
?
>
> Alex
>
int vfio_group_iommu_id_from_file(struct file *filep)
...
On 06/22/2013 07:12 AM, Alex Williamson wrote:
> vfio_group_fops_open attempts to limit concurrent sessions by
> disallowing opens once group->container is set. This really doesn't
> do what we want and allow for inconsistent behavior, for instance a
> group can be opened twice, then a container set giving the user two
> file descriptors to the group. But then it won't allow more to be
> opened. There's not much reason to have the group opened multiple
> times since most access is through devices or the container, so
> complete what the original code intended and only allow a single
> instance.
>
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/vfio.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 6d78736..d30f44d 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -76,6 +76,7 @@ struct vfio_group {
> struct notifier_block nb;
> struct list_headvfio_next;
> struct list_headcontainer_next;
> + atomic_topened;
> };
>
> struct vfio_device {
> @@ -206,6 +207,7 @@ static struct vfio_group *vfio_create_group(struct
> iommu_group *iommu_group)
> INIT_LIST_HEAD(>device_list);
> mutex_init(>device_lock);
> atomic_set(>container_users, 0);
> + atomic_set(>opened, 0);
> group->iommu_group = iommu_group;
>
> group->nb.notifier_call = vfio_iommu_group_notifier;
> @@ -1236,12 +1238,22 @@ static long vfio_group_fops_compat_ioctl(struct
> file *filep,
> static int vfio_group_fops_open(struct inode *inode, struct file *filep)
> {
> struct vfio_group *group;
> + int opened;
>
> group = vfio_group_get_from_minor(iminor(inode));
> if (!group)
> return -ENODEV;
>
> + /* Do we need multiple instances of the group open? Seems not. */
> + opened = atomic_cmpxchg(>opened, 0, 1);
> + if (opened) {
> + vfio_group_put(group);
> + return -EBUSY;
> + }
> +
> + /* Is something still in use from a previous open? */
> if (group->container) {
> + atomic_dec(>opened);
> vfio_group_put(group);
> return -EBUSY;
> }
> @@ -1259,6 +1271,8 @@ static int vfio_group_fops_release(struct inode
> *inode, struct file *filep)
>
> vfio_group_try_dissolve_container(group);
>
> + atomic_dec(>opened);
> +
> vfio_group_put(group);
>
> return 0;
>
>>>
>>>
>>>
>>
>>
>
>
>
--
Alexey
--
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 v5 0/7] PCI: Change assign unassigned resources per root bus bassis
On Fri, May 31, 2013 at 11:03 PM, Yinghai Lu wrote: > BenH reported that there is some assign unassigned resource problem > in powerpc. > > It turns out after > | commit 0c5be0cb0edfe3b5c4b62eac68aa2aa15ec681af > | Date: Thu Feb 23 19:23:29 2012 -0800 > | > |PCI: Retry on IORESOURCE_IO type allocations > > even the root bus does not have io port range, it will keep retrying > to realloc with mmio. > > After checking the code, found that we bound io port and mmio fail > path together. > First patch fix the problem, that will not make mmio fall back to must-only > when only have io port fail with must+optional. > > During we found the fix for that problem, found that we can separate assign > unassigned resources to per root bus. > that will make the code simple, also could reuse it for hotadd path. > > These patches are targeted to 3.11 > > -v4: split first patch into 4 patches per Bjorn. > -v5: drop two patches that will pass root bus resource mask after we found > simple and less intrusive way to fix the problem. > > PCI: Don't let mmio fallback to must-only, if ioport fails with must+optional > PCI: Don't use temp bus for pci_bus_release_bridge_resources > PCI: Use pci_walk_bus to detect unassigned resources > PCI: Introduce enable_local to prepare per root bus handling > PCI: Split pci_assign_unassigned_resources to per root bus > PCI: Enable pci bridge when it is needed > PCI: Retry assign unassigned resources for hotadd root bus Hi, Bjorn, Can you put this patchset in pci/next for 3.11? Found another pciehp will need this one two. the pcie bridge does not have io port range and it cause mmio get clear and retry. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vfio: Limit group opens
On Sat, 2013-06-22 at 12:44 +1000, Alexey Kardashevskiy wrote:
> On 06/22/2013 11:26 AM, Alex Williamson wrote:
> > On Sat, 2013-06-22 at 11:16 +1000, Alexey Kardashevskiy wrote:
> >> Cool, thanks!
> >>
> >> So we will need only this (to be called from KVM), and that will be it,
> >> right?
> >
> > For what? This is not the external lock you're looking for. As I've
> > mentioned, the file can only hold the group, but that doesn't give you
> > any guarantee that the group is protected by the IOMMU. Thanks,
>
>
> I am confused, sorry :) With this patch, a group fd cannot be reopened if
> already opened, and this is the only way for user space to take control
> over a group. If it is not an external lock, then what is it? And all I
> have to do now is to verify that the group fd passed to KVM is correct and
> I am happy. Who and how can break anything (group? KVM?) now?
By that logic all a user needs to do is open() a group and they they're
free to pass the fd to KVM, right? But the IOMMU protection isn't
enabled until the user calls SET_CONTAINER and SET_IOMMU, so you'd be
giving KVM access to the IOMMU that the user hasn't enabled. The group
may still have devices attached to host drivers. Likewise, a user need
only call UNSET_CONTAINER to teardown the IOMMU protection. At that
point a device could be re-bound to host drivers, thus making it unsafe
for KVM to be directly poking the IOMMU.
This patch is just a bug fix for inconsistent behavior. Thanks,
Alex
> >> int vfio_group_iommu_id_from_file(struct file *filep)
> >> ...
> >>
> >>
> >>
> >> On 06/22/2013 07:12 AM, Alex Williamson wrote:
> >>> vfio_group_fops_open attempts to limit concurrent sessions by
> >>> disallowing opens once group->container is set. This really doesn't
> >>> do what we want and allow for inconsistent behavior, for instance a
> >>> group can be opened twice, then a container set giving the user two
> >>> file descriptors to the group. But then it won't allow more to be
> >>> opened. There's not much reason to have the group opened multiple
> >>> times since most access is through devices or the container, so
> >>> complete what the original code intended and only allow a single
> >>> instance.
> >>>
> >>> Signed-off-by: Alex Williamson
> >>> ---
> >>> drivers/vfio/vfio.c | 14 ++
> >>> 1 file changed, 14 insertions(+)
> >>>
> >>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> >>> index 6d78736..d30f44d 100644
> >>> --- a/drivers/vfio/vfio.c
> >>> +++ b/drivers/vfio/vfio.c
> >>> @@ -76,6 +76,7 @@ struct vfio_group {
> >>> struct notifier_block nb;
> >>> struct list_headvfio_next;
> >>> struct list_headcontainer_next;
> >>> + atomic_topened;
> >>> };
> >>>
> >>> struct vfio_device {
> >>> @@ -206,6 +207,7 @@ static struct vfio_group *vfio_create_group(struct
> >>> iommu_group *iommu_group)
> >>> INIT_LIST_HEAD(>device_list);
> >>> mutex_init(>device_lock);
> >>> atomic_set(>container_users, 0);
> >>> + atomic_set(>opened, 0);
> >>> group->iommu_group = iommu_group;
> >>>
> >>> group->nb.notifier_call = vfio_iommu_group_notifier;
> >>> @@ -1236,12 +1238,22 @@ static long vfio_group_fops_compat_ioctl(struct
> >>> file *filep,
> >>> static int vfio_group_fops_open(struct inode *inode, struct file *filep)
> >>> {
> >>> struct vfio_group *group;
> >>> + int opened;
> >>>
> >>> group = vfio_group_get_from_minor(iminor(inode));
> >>> if (!group)
> >>> return -ENODEV;
> >>>
> >>> + /* Do we need multiple instances of the group open? Seems not. */
> >>> + opened = atomic_cmpxchg(>opened, 0, 1);
> >>> + if (opened) {
> >>> + vfio_group_put(group);
> >>> + return -EBUSY;
> >>> + }
> >>> +
> >>> + /* Is something still in use from a previous open? */
> >>> if (group->container) {
> >>> + atomic_dec(>opened);
> >>> vfio_group_put(group);
> >>> return -EBUSY;
> >>> }
> >>> @@ -1259,6 +1271,8 @@ static int vfio_group_fops_release(struct inode
> >>> *inode, struct file *filep)
> >>>
> >>> vfio_group_try_dissolve_container(group);
> >>>
> >>> + atomic_dec(>opened);
> >>> +
> >>> vfio_group_put(group);
> >>>
> >>> 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: [PATCH v12 05/11] edma: config: Enable config options for EDMA
>> > config TI_EDMA
>> > tristate "TI EDMA support"
>> > default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
>> > select DMA_ENGINE
>> > select DMA_VIRTUAL_CHANNELS
>>
>>
>> MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
>> 'm' option will require some initramfs to load the module when needing
>> to MMC boot, I suggest lets leave it as y.
>>
>
> Ah, right: you still export a filter function from the edma driver
> and use it in slave drivers:
>
> drivers/mmc/host/davinci_mmc.c:
> dma_request_slave_channel_compat(mask, edma_filter_fn,
> drivers/mmc/host/davinci_mmc.c:
> dma_request_slave_channel_compat(mask, edma_filter_fn,
> drivers/spi/spi-davinci.c: dspi->dma_rx = dma_request_channel(mask,
> edma_filter_fn,
> drivers/spi/spi-davinci.c: dspi->dma_tx = dma_request_channel(mask,
> edma_filter_fn,
>
> As long as this is the case, you have to be careful with the dependencies
> to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or
> edma_filter_fn gets defined to NULL when you are building for a DT-only
> platform.
Yes sure, right now they are defined as follows in include/linux/edma.h:
#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
bool edma_filter_fn(struct dma_chan *, void *);
#else
static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
{
return false;
}
#endif
This also has the side effect of causing DMA requests to fail if
TI_EDMA is not built, causing frustration for a lot of people some of
whom don't want to deal with DMA so I think it is OK to build the
driver in by default as it is (and will be) used by a lot of
OMAP2PLUS.
Thanks,
Joel
--
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: [BUGFIX v2 0/4] fix bug 56531, 59501 and 59581
On 06/22/2013 08:13 AM, Rafael J. Wysocki wrote: > On Saturday, June 22, 2013 12:54:21 AM Jiang Liu wrote: >> On 06/21/2013 03:06 AM, Rafael J. Wysocki wrote: >>> On Wednesday, June 19, 2013 11:18:41 AM Alexander E. Patrakov wrote: 2013/6/19 Rafael J. Wysocki : > OK, let's try to untangle this a bit. > > If you applyt patches [1/4] and [4/4] from the $subject series only, what > does remain unfixed? [not tested, can do so in 12 hours if needed] I think there will be problems on undocking and/or on the second docking, as described in comments #6 - #8 of https://bugzilla.kernel.org/show_bug.cgi?id=59501 >>> >>> OK, I think I have something that might work. It may not solve all >>> problems, >>> but maybe it helps a bit. Unfortunately, I can't really test it, so please >>> do >>> if you can. >>> >>> Please apply [1/4] and [4/4] and the one below and see what happens. >>> >>> Thanks, >>> Rafael >>> >>> >>> --- >>> Rationale: >>> acpiphp_glue.c:disable_device() trims the underlying ACPI device objects >>> after removing the companion PCI devices, so the dock station code >>> doesn't need to trim them separately for the dependent devices handled >>> by acpiphp. >>> >>> Moreover, acpiphp_glue.c is the only user of >>> [un]register_hotplug_dock_device(), so *all* devices on the >>> ds->hotplug_devices list are handled by acpiphp and ops is set for all >>> of them. >> Hi Rafael, >> There's an ongoing patch to fix a disk bay hotplug regression, which >> may add a second caller of register_hotplug_device(). Please refer to >> bug 59871, and the proposed patch is at: >> https://bugzilla.kernel.org/attachment.cgi?id=105581 Hi Rafael, You can find the proposed patch for ATA Bay hotplug at https://bugzilla.kernel.org/attachment.cgi?id=105581 Regards! Gerry >> >> The proposed patch for bug 59871 may not be safe with above changes >> because the ACPI ATA hotplug handler may not remove ACPI devices as >> acpiphp driver does. > > Well, since there's not ATA hotplug handler in 3.10-rc6, as far as I can say, > I suppose that you're talking about a new patch scheduled for 3.11. If so,u > can you please give me a pointer to that patch, possibly the tree it is > queued on etc.? [...] > > Thanks, > Rafael > > -- 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] vfio: Limit group opens
On 06/22/2013 11:26 AM, Alex Williamson wrote:
> On Sat, 2013-06-22 at 11:16 +1000, Alexey Kardashevskiy wrote:
>> Cool, thanks!
>>
>> So we will need only this (to be called from KVM), and that will be it,
>> right?
>
> For what? This is not the external lock you're looking for. As I've
> mentioned, the file can only hold the group, but that doesn't give you
> any guarantee that the group is protected by the IOMMU. Thanks,
I am confused, sorry :) With this patch, a group fd cannot be reopened if
already opened, and this is the only way for user space to take control
over a group. If it is not an external lock, then what is it? And all I
have to do now is to verify that the group fd passed to KVM is correct and
I am happy. Who and how can break anything (group? KVM?) now?
>
> Alex
>
>> int vfio_group_iommu_id_from_file(struct file *filep)
>> ...
>>
>>
>>
>> On 06/22/2013 07:12 AM, Alex Williamson wrote:
>>> vfio_group_fops_open attempts to limit concurrent sessions by
>>> disallowing opens once group->container is set. This really doesn't
>>> do what we want and allow for inconsistent behavior, for instance a
>>> group can be opened twice, then a container set giving the user two
>>> file descriptors to the group. But then it won't allow more to be
>>> opened. There's not much reason to have the group opened multiple
>>> times since most access is through devices or the container, so
>>> complete what the original code intended and only allow a single
>>> instance.
>>>
>>> Signed-off-by: Alex Williamson
>>> ---
>>> drivers/vfio/vfio.c | 14 ++
>>> 1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>>> index 6d78736..d30f44d 100644
>>> --- a/drivers/vfio/vfio.c
>>> +++ b/drivers/vfio/vfio.c
>>> @@ -76,6 +76,7 @@ struct vfio_group {
>>> struct notifier_block nb;
>>> struct list_headvfio_next;
>>> struct list_headcontainer_next;
>>> + atomic_topened;
>>> };
>>>
>>> struct vfio_device {
>>> @@ -206,6 +207,7 @@ static struct vfio_group *vfio_create_group(struct
>>> iommu_group *iommu_group)
>>> INIT_LIST_HEAD(>device_list);
>>> mutex_init(>device_lock);
>>> atomic_set(>container_users, 0);
>>> + atomic_set(>opened, 0);
>>> group->iommu_group = iommu_group;
>>>
>>> group->nb.notifier_call = vfio_iommu_group_notifier;
>>> @@ -1236,12 +1238,22 @@ static long vfio_group_fops_compat_ioctl(struct
>>> file *filep,
>>> static int vfio_group_fops_open(struct inode *inode, struct file *filep)
>>> {
>>> struct vfio_group *group;
>>> + int opened;
>>>
>>> group = vfio_group_get_from_minor(iminor(inode));
>>> if (!group)
>>> return -ENODEV;
>>>
>>> + /* Do we need multiple instances of the group open? Seems not. */
>>> + opened = atomic_cmpxchg(>opened, 0, 1);
>>> + if (opened) {
>>> + vfio_group_put(group);
>>> + return -EBUSY;
>>> + }
>>> +
>>> + /* Is something still in use from a previous open? */
>>> if (group->container) {
>>> + atomic_dec(>opened);
>>> vfio_group_put(group);
>>> return -EBUSY;
>>> }
>>> @@ -1259,6 +1271,8 @@ static int vfio_group_fops_release(struct inode
>>> *inode, struct file *filep)
>>>
>>> vfio_group_try_dissolve_container(group);
>>>
>>> + atomic_dec(>opened);
>>> +
>>> vfio_group_put(group);
>>>
>>> return 0;
>>>
>>
>>
>
>
>
--
Alexey
--
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: [PATCHv v3] power: Include additional information in pm_print_times
On Sat, 2013-06-22 at 02:24 +0200, Rafael J. Wysocki wrote: > Namely, there are tools that use these messages to create suspend/resume time > charts and they will stop working after the proposed changes. dmesg output isn't guaranteed to be stable. -- 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/
[PATCHv2 2/2] defconfig: msm_defconfig: Enable CONFIG_ARCH_MSM8974
This patch enables MSM8974 build support. Signed-off-by: Rohit Vaswani --- arch/arm/configs/msm_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig index 690b5f9..0ed32e5 100644 --- a/arch/arm/configs/msm_defconfig +++ b/arch/arm/configs/msm_defconfig @@ -20,6 +20,7 @@ CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_MSM=y CONFIG_ARCH_MSM8X60=y CONFIG_ARCH_MSM8960=y +CONFIG_ARCH_MSM8974=y CONFIG_SMP=y CONFIG_PREEMPT=y CONFIG_AEABI=y -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/
[PATCHv2 1/2] ARM: msm: Add support for MSM8974
This patch adds basic board support for MSM8974 which
belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.
Signed-off-by: Rohit Vaswani
---
arch/arm/boot/dts/Makefile|3 ++-
arch/arm/boot/dts/msm8974.dts | 24
arch/arm/mach-msm/Kconfig | 21 ++---
arch/arm/mach-msm/Makefile|1 +
arch/arm/mach-msm/board-dt-8974.c | 23 +++
5 files changed, 68 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/msm8974.dts
create mode 100644 arch/arm/mach-msm/board-dt-8974.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9f7121..7728cfe 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -90,7 +90,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
kirkwood-openblocks_a6.dtb
dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
- msm8960-cdp.dtb
+ msm8960-cdp.dtb \
+ msm8974.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-mirabox.dtb \
armada-370-rd.dtb \
diff --git a/arch/arm/boot/dts/msm8974.dts b/arch/arm/boot/dts/msm8974.dts
new file mode 100644
index 000..8ed71ef
--- /dev/null
+++ b/arch/arm/boot/dts/msm8974.dts
@@ -0,0 +1,24 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Qualcomm MSM8974";
+ compatible = "qcom,msm8974";
+ interrupt-parent = <>;
+
+ intc: interrupt-controller@f900 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = < 0xf900 0x1000 >,
+ < 0xf9002000 0x1000 >;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 2 0xf08>,
+<1 3 0xf08>;
+ clock-frequency = <1920>;
+ };
+};
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 614e41e..343675b 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -1,12 +1,12 @@
if ARCH_MSM
comment "Qualcomm MSM SoC Type"
- depends on (ARCH_MSM8X60 || ARCH_MSM8960)
+ depends on ARCH_MSM_DT
choice
prompt "Qualcomm MSM SoC Type"
default ARCH_MSM7X00A
- depends on !(ARCH_MSM8X60 || ARCH_MSM8960)
+ depends on !ARCH_MSM_DT
config ARCH_MSM7X00A
bool "MSM7x00A / MSM7x01A"
@@ -60,6 +60,19 @@ config ARCH_MSM8960
select MSM_SCM if SMP
select USE_OF
+config ARCH_MSM8974
+ bool "MSM8974"
+ select ARM_GIC
+ select CPU_V7
+ select HAVE_ARM_ARCH_TIMER
+ select HAVE_SMP
+ select MSM_SCM if SMP
+ select USE_OF
+
+config ARCH_MSM_DT
+ def_bool y
+ depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
+
config MSM_HAS_DEBUG_UART_HS
bool
@@ -68,6 +81,7 @@ config MSM_SOC_REV_A
config ARCH_MSM_ARM11
bool
+
config ARCH_MSM_SCORPION
bool
@@ -75,6 +89,7 @@ config MSM_VIC
bool
menu "Qualcomm MSM Board Type"
+ depends on !ARCH_MSM_DT
config MACH_HALIBUT
depends on ARCH_MSM
@@ -121,7 +136,7 @@ config MSM_SMD
bool
config MSM_GPIOMUX
- depends on !(ARCH_MSM8X60 || ARCH_MSM8960)
+ depends on !ARCH_MSM_DT
bool "MSM V1 TLMM GPIOMUX architecture"
help
Support for MSM V1 TLMM GPIOMUX architecture.
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index d257ff4..80e3b15 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -29,5 +29,6 @@ obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o
devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-dt-8660.o
obj-$(CONFIG_ARCH_MSM8960) += board-dt-8960.o
+obj-$(CONFIG_ARCH_MSM8974) += board-dt-8974.o
obj-$(CONFIG_MSM_GPIOMUX) += gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o
diff --git a/arch/arm/mach-msm/board-dt-8974.c
b/arch/arm/mach-msm/board-dt-8974.c
new file mode 100644
index 000..d7f84f2
--- /dev/null
+++ b/arch/arm/mach-msm/board-dt-8974.c
@@ -0,0 +1,23 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+static const char * const msm8974_dt_match[] __initconst = {
+ "qcom,msm8974",
+ NULL
+};
+
+DT_MACHINE_START(MSM8974_DT, "Qualcomm MSM (Flattened Device
[PATCH 1/1] staging/speakup/kobjects.c: Code improvement.
Well, there is no need to use strcmp since we can make a test of similar
semantic by using the var_id field of param.
I moved the test into the VAR_NUM:VAR_TIME case since VAR_STRING will never be
"voice".
spk_xlate isn't used anymore (in line 608), then there is no difference between
using cp and buf in VAR_STRING case.
Besides, buf is a const char and those changes remove one uneeded line.
I created the function spk_reset_default_value because it clarifies the code
and allows code reusing.
Signed-off-by: Raphael S. Carvalho
---
drivers/staging/speakup/kobjects.c | 73 +++
1 files changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/speakup/kobjects.c
b/drivers/staging/speakup/kobjects.c
index 943b6c1..4660ce3 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -585,6 +585,25 @@ ssize_t spk_var_show(struct kobject *kobj, struct
kobj_attribute *attr,
}
EXPORT_SYMBOL_GPL(spk_var_show);
+/*
+ * Used to reset either default_pitch or default_vol.
+ */
+static inline void spk_reset_default_value(char *header_name,
+ int *synth_default_value, int idx)
+{
+ struct st_var_header *param;
+
+ if (synth && synth_default_value) {
+ param = spk_var_header_by_name(header_name);
+ if (param) {
+ spk_set_num_var(synth_default_value[idx],
+ param, E_NEW_DEFAULT);
+ spk_set_num_var(0, param, E_DEFAULT);
+ pr_info("%s reset to default value\n", param->name);
+ }
+ }
+}
+
/*
* This function is called when a user echos a value to one of the
* variable parameters.
@@ -624,56 +643,44 @@ ssize_t spk_var_store(struct kobject *kobj, struct
kobj_attribute *attr,
if (ret == -ERANGE) {
var_data = param->data;
pr_warn("value for %s out of range, expect %d to %d\n",
- attr->attr.name,
+ param->name,
var_data->u.n.low, var_data->u.n.high);
}
+
+ /*
+ * If voice was just changed, we might need to reset our default
+ * pitch and volume.
+ */
+ if (param->var_id == VOICE) {
+ spk_reset_default_value("pitch", synth->default_pitch,
+ value);
+ spk_reset_default_value("vol", synth->default_vol,
+ value);
+ }
break;
case VAR_STRING:
- len = strlen(buf);
- if ((len >= 1) && (buf[len - 1] == '\n'))
+ len = strlen(cp);
+ if ((len >= 1) && (cp[len - 1] == '\n'))
--len;
- if ((len >= 2) && (buf[0] == '"') && (buf[len - 1] == '"')) {
- ++buf;
+ if ((len >= 2) && (cp[0] == '"') && (cp[len - 1] == '"')) {
+ ++cp;
len -= 2;
}
- cp = (char *) buf;
cp[len] = '\0';
- ret = spk_set_string_var(buf, param, len);
+ ret = spk_set_string_var(cp, param, len);
if (ret == -E2BIG)
pr_warn("value too long for %s\n",
- attr->attr.name);
+ param->name);
break;
default:
pr_warn("%s unknown type %d\n",
param->name, (int)param->var_type);
- break;
- }
- /*
-* If voice was just changed, we might need to reset our default
-* pitch and volume.
-*/
- if (strcmp(attr->attr.name, "voice") == 0) {
- if (synth && synth->default_pitch) {
- param = spk_var_header_by_name("pitch");
- if (param) {
- spk_set_num_var(synth->default_pitch[value],
- param, E_NEW_DEFAULT);
- spk_set_num_var(0, param, E_DEFAULT);
- }
- }
- if (synth && synth->default_vol) {
- param = spk_var_header_by_name("vol");
- if (param) {
- spk_set_num_var(synth->default_vol[value],
- param, E_NEW_DEFAULT);
- spk_set_num_var(0, param, E_DEFAULT);
- }
- }
- }
+ break;
+ }
spk_unlock(flags);
if (ret == -ERESTART)
- pr_info("%s reset to default value\n", attr->attr.name);
+ pr_info("%s reset to
Re: frequent softlockups with 3.10rc6.
On Fri, Jun 21, 2013 at 09:59:49PM +0200, Oleg Nesterov wrote:
> I am puzzled. And I do not really understand
>
> hardirqs last enabled at (2380318): []
> restore_args+0x0/0x30
> hardirqs last disabled at (2380319): []
> apic_timer_interrupt+0x6a/0x80
> softirqs last enabled at (196990): []
> __do_softirq+0x194/0x440 [19886.471395]
> softirqs last disabled at (197479): []
> irq_exit+0xcd/0xe0
>
> below. how can they differ that much...
>
> Dave, any chance you can reproduce the hang with the debugging patch at
> the end? Just in case, the warnings themself do not mean a problem, just
> to have a bit more info.
[ 7485.261299] WARNING: at include/linux/nsproxy.h:63
get_proc_task_net+0x1c8/0x1d0()
[ 7485.262021] Modules linked in: 8021q garp stp tun fuse rfcomm bnep hidp
snd_seq_dummy nfnetlink scsi_transport_iscsi can_bcm ipt_ULOG can_raw rds
af_802154 nfc can rose caif_socket caif llc2 af_rxrpc phonet ipx p8023 p8022
pppoe pppox ppp_generic netrom slhc ax25 x25 af_key appletalk atm psnap llc
irda crc_ccitt bluetooth rfkill coretemp hwmon kvm_intel snd_hda_codec_realtek
kvm snd_hda_codec_hdmi crc32c_intel ghash_clmulni_intel microcode snd_hda_intel
snd_hda_codec snd_hwdep snd_seq snd_seq_device pcspkr snd_pcm snd_page_alloc
e1000e snd_timer ptp snd pps_core soundcore xfs libcrc32c
[ 7485.265434] CPU: 2 PID: 5623 Comm: trinity-child3 Not tainted 3.10.0-rc6+
#28
[ 7485.267158] 81a1529c 8801c8eafd30 816e432d
8801c8eafd68
[ 7485.268045] 8104a0c1 880225e9bd18
8801bc6e4de0
[ 7485.268932] 00dd 8801c8eafd78
8104a19a
[ 7485.270463] Call Trace:
[ 7485.271338] [] dump_stack+0x19/0x1b
[ 7485.272207] [] warn_slowpath_common+0x61/0x80
[ 7485.273092] [] warn_slowpath_null+0x1a/0x20
[ 7485.273942] [] get_proc_task_net+0x1c8/0x1d0
[ 7485.274793] [] ? get_proc_task_net+0x5/0x1d0
[ 7485.275659] [] proc_tgid_net_lookup+0x1d/0x80
[ 7485.276531] [] lookup_real+0x1d/0x50
[ 7485.277646] [] __lookup_hash+0x33/0x40
[ 7485.278477] [] kern_path_create+0xb3/0x190
[ 7485.279345] [] ? getname_flags+0xb5/0x190
[ 7485.280292] [] user_path_create+0x41/0x60
[ 7485.281233] [] SyS_symlinkat+0x4b/0xd0
[ 7485.282072] [] tracesys+0xdd/0xe2
[ 7485.282973] ---[ end trace 2204b7c65d6c5519 ]---
> +pr_info("YESTHISHAPPENS new=%p\n", new);
This didn't trigger. (yet?)
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: [PATCH] vfio: Limit group opens
On Sat, 2013-06-22 at 11:16 +1000, Alexey Kardashevskiy wrote:
> Cool, thanks!
>
> So we will need only this (to be called from KVM), and that will be it, right?
For what? This is not the external lock you're looking for. As I've
mentioned, the file can only hold the group, but that doesn't give you
any guarantee that the group is protected by the IOMMU. Thanks,
Alex
> int vfio_group_iommu_id_from_file(struct file *filep)
> ...
>
>
>
> On 06/22/2013 07:12 AM, Alex Williamson wrote:
> > vfio_group_fops_open attempts to limit concurrent sessions by
> > disallowing opens once group->container is set. This really doesn't
> > do what we want and allow for inconsistent behavior, for instance a
> > group can be opened twice, then a container set giving the user two
> > file descriptors to the group. But then it won't allow more to be
> > opened. There's not much reason to have the group opened multiple
> > times since most access is through devices or the container, so
> > complete what the original code intended and only allow a single
> > instance.
> >
> > Signed-off-by: Alex Williamson
> > ---
> > drivers/vfio/vfio.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index 6d78736..d30f44d 100644
> > --- a/drivers/vfio/vfio.c
> > +++ b/drivers/vfio/vfio.c
> > @@ -76,6 +76,7 @@ struct vfio_group {
> > struct notifier_block nb;
> > struct list_headvfio_next;
> > struct list_headcontainer_next;
> > + atomic_topened;
> > };
> >
> > struct vfio_device {
> > @@ -206,6 +207,7 @@ static struct vfio_group *vfio_create_group(struct
> > iommu_group *iommu_group)
> > INIT_LIST_HEAD(>device_list);
> > mutex_init(>device_lock);
> > atomic_set(>container_users, 0);
> > + atomic_set(>opened, 0);
> > group->iommu_group = iommu_group;
> >
> > group->nb.notifier_call = vfio_iommu_group_notifier;
> > @@ -1236,12 +1238,22 @@ static long vfio_group_fops_compat_ioctl(struct
> > file *filep,
> > static int vfio_group_fops_open(struct inode *inode, struct file *filep)
> > {
> > struct vfio_group *group;
> > + int opened;
> >
> > group = vfio_group_get_from_minor(iminor(inode));
> > if (!group)
> > return -ENODEV;
> >
> > + /* Do we need multiple instances of the group open? Seems not. */
> > + opened = atomic_cmpxchg(>opened, 0, 1);
> > + if (opened) {
> > + vfio_group_put(group);
> > + return -EBUSY;
> > + }
> > +
> > + /* Is something still in use from a previous open? */
> > if (group->container) {
> > + atomic_dec(>opened);
> > vfio_group_put(group);
> > return -EBUSY;
> > }
> > @@ -1259,6 +1271,8 @@ static int vfio_group_fops_release(struct inode
> > *inode, struct file *filep)
> >
> > vfio_group_try_dissolve_container(group);
> >
> > + atomic_dec(>opened);
> > +
> > vfio_group_put(group);
> >
> > 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: [PATCH] vfio: Limit group opens
Cool, thanks!
So we will need only this (to be called from KVM), and that will be it, right?
int vfio_group_iommu_id_from_file(struct file *filep)
...
On 06/22/2013 07:12 AM, Alex Williamson wrote:
> vfio_group_fops_open attempts to limit concurrent sessions by
> disallowing opens once group->container is set. This really doesn't
> do what we want and allow for inconsistent behavior, for instance a
> group can be opened twice, then a container set giving the user two
> file descriptors to the group. But then it won't allow more to be
> opened. There's not much reason to have the group opened multiple
> times since most access is through devices or the container, so
> complete what the original code intended and only allow a single
> instance.
>
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/vfio.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 6d78736..d30f44d 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -76,6 +76,7 @@ struct vfio_group {
> struct notifier_block nb;
> struct list_headvfio_next;
> struct list_headcontainer_next;
> + atomic_topened;
> };
>
> struct vfio_device {
> @@ -206,6 +207,7 @@ static struct vfio_group *vfio_create_group(struct
> iommu_group *iommu_group)
> INIT_LIST_HEAD(>device_list);
> mutex_init(>device_lock);
> atomic_set(>container_users, 0);
> + atomic_set(>opened, 0);
> group->iommu_group = iommu_group;
>
> group->nb.notifier_call = vfio_iommu_group_notifier;
> @@ -1236,12 +1238,22 @@ static long vfio_group_fops_compat_ioctl(struct file
> *filep,
> static int vfio_group_fops_open(struct inode *inode, struct file *filep)
> {
> struct vfio_group *group;
> + int opened;
>
> group = vfio_group_get_from_minor(iminor(inode));
> if (!group)
> return -ENODEV;
>
> + /* Do we need multiple instances of the group open? Seems not. */
> + opened = atomic_cmpxchg(>opened, 0, 1);
> + if (opened) {
> + vfio_group_put(group);
> + return -EBUSY;
> + }
> +
> + /* Is something still in use from a previous open? */
> if (group->container) {
> + atomic_dec(>opened);
> vfio_group_put(group);
> return -EBUSY;
> }
> @@ -1259,6 +1271,8 @@ static int vfio_group_fops_release(struct inode *inode,
> struct file *filep)
>
> vfio_group_try_dissolve_container(group);
>
> + atomic_dec(>opened);
> +
> vfio_group_put(group);
>
> return 0;
>
--
Alexey
--
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/
How to get AP tx bitrate from STA side?
Hello there! I have an AP xmitting data to STA. What I am trying to do is somehow get the bitrate AP uses for xmission from STA side, which is just like what "iw dev wlan0 link" does. But I need a kernel function so that I can grab this bitrate in driver and therefore do some other stuff. Your suggestions are highly welcome! Thanks in advance! -- View this message in context: http://linux-kernel.2935.n7.nabble.com/How-to-get-AP-tx-bitrate-from-STA-side-tp672347.html Sent from the Linux Kernel mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv v3] power: Include additional information in pm_print_times
On 06/21/2013 06:15 PM, Rafael J. Wysocki wrote: > On Monday, June 17, 2013 01:36:35 PM Shuah Khan wrote: >> Change __device_suspend() path to include driver name and the ops that >> get run for a device. This additional information helps associate the >> driver and the type of pm_ops the device uses in the suspend path very >> quickly, which will aid in debugging problems in suspend and resume paths. >> Changed both start and end debug messages to include pm_ops information >> and use dev_info() instead of pr_info(). Changed the end message to include >> parent device information and have the same format as the start message. >> >> dmesg output before the change: >> >> [ 164.390032] calling 1-1+ @ 69, parent: usb1 >> [ 164.390035] call 1-1+ returned 0 after 0 usecs >> >> [ 164.390352] calling 00:0a+ @ 2457, parent: pnp0 >> [ 164.390357] call 00:0a+ returned 0 after 3 usecs >> >> [ 164.390361] calling 00:09+ @ 2457, parent: pnp0 >> [ 164.496458] call 00:09+ returned 0 after 103500 usecs >> >> [ 164.496494] calling 00:05+ @ 2457, parent: pnp0 >> [ 164.496511] call 00:05+ returned 0 after 14 usecs >> >> dmesg output after the change: >> >> [ 545.985394] usb 1-1: Start: type pm ops @ 68, parent: usb1 >> [ 545.987650] usb 1-1: End : type pm ops @ 68, parent: usb1 time(2184 >> usecs) err(0) >> >> [ 545.982544] system 00:0a: Start: legacy bus pm ops @ 2391, parent: pnp0 >> [ 545.982554] system 00:0a: End : legacy bus pm ops @ 2391, parent: pnp0 >> time(4 usecs) err(0) >> >> [ 545.982569] tpm_tis 00:09: Start: legacy bus pm ops @ 2391, parent: pnp0 >> [ 546.087017] tpm_tis 00:09: End : legacy bus pm ops @ 2391, parent: pnp0 >> time(101936 usecs) err(0) >> >> [ 546.087069] rtc_cmos 00:05: Start: legacy bus pm ops @ 2391, parent: pnp0 >> [ 546.087084] rtc_cmos 00:05: End : legacy bus pm ops @ 2391, parent: pnp0 >> time(11 usecs) err(0) >> > > I was about to apply your patch, but then I noticed something that might cause > problems to happen. > > Namely, there are tools that use these messages to create suspend/resume time > charts and they will stop working after the proposed changes. > > Please keep the existing formatting the way it is and only append the > additional > information at the end of each line. > > Thanks, > Rafael > Hi Rafael, Yes changing the format would cause problems for scripts that rely on the exact format. Would you like to pick the v2 version of the patch that appends the additional information at the end, instead of changing the format? Here is the link. If you would like me to resend it, I can do that. https://lkml.org/lkml/2013/6/14/448 -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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 0/2] rwsem: performance enhancements for systems with many cores
On Fri, 2013-06-21 at 17:25 -0700, Michel Lespinasse wrote: > On Fri, Jun 21, 2013 at 5:00 PM, Davidlohr Bueso > wrote: > > On Fri, 2013-06-21 at 16:51 -0700, Tim Chen wrote: > >> In this patchset, we introduce two optimizations to read write semaphore. > >> The first one reduces cache bouncing of the sem->count field > >> by doing a pre-read of the sem->count and avoid cmpxchg if possible. > >> The second patch introduces similar optimistic spining logic in > >> the mutex code for the writer lock acquisition of rw-sem. > >> > >> Combining the two patches, in testing by Davidlohr Bueso on aim7 workloads > >> on 8 socket 80 cores system, he saw improvements of > >> alltests (+14.5%), custom (+17%), disk (+11%), high_systime > >> (+5%), shared (+15%) and short (+4%), most of them after around 500 > >> users when i_mmap was implemented as rwsem. > >> > >> Feedbacks on the effectiveness of these tweaks on other workloads > >> will be appreciated. > > > > Tim, I was really hoping to send all this in one big bundle. I was doing > > some further testing (enabling hyperthreading and some Oracle runs), > > fortunately everything looks ok and we are getting actual improvements > > on large boxes. > > > > That said, how about I send you my i_mmap rwsem patchset for a v2 of > > this patchset? > > I'm a bit confused about the state of these patchsets - it looks like > I'm only copied into half of the conversations. Should I wait for a v2 > here, or should I hunt down for Alex's version of things, or... ? Except for some internal patch logistics, you haven't been left out on any conversations :) My original plan was to send out, in one patchset: - rwsem optimizations from Alex (patch 1/2 here, which should be actually 4 patches) + - rwsem optimistic spinning (patch 2/2 here) + - i_mmap_mutex to rwsem conversion (5 more patches) Now, I realize that the i_mmap stuff might not be welcomed in a rwsem-specific optimizations patchset like this one, but I think it's relevant to include everything in a single bundle as it really shows the performance boosts and it's what I have been using and measuring the original negative rwsem performance when compared to a mutex. If folks don't agree, I can always send it as a separate patchset. Thanks, Davidlohr the rwsem spin on owner functionality (2/2) + 4 from Alex )which is really patch 1/2 here + I haven't sent out any -- 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] power/reset: Make the vexpress driver optional on arm and arm64
On Mon, Jun 10, 2013 at 04:12:01PM +0100, Pawel Moll wrote: > The driver can be used on either arm or arm64 platforms, but > the latter doesn't have any platform-specific configuration > options, so it must be possible to manually enable the driver. > > Signed-off-by: Pawel Moll > Acked-by: Catalin Marinas > --- Applied. Thanks a lot, Pawel! > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig > index 349e9ae..ee039dc 100644 > --- a/drivers/power/reset/Kconfig > +++ b/drivers/power/reset/Kconfig > @@ -32,7 +32,8 @@ config POWER_RESET_RESTART > user presses a key. u-boot then boots into Linux. > > config POWER_RESET_VEXPRESS > - bool > + bool "ARM Versatile Express power-off and reset driver" > + depends on ARM || ARM64 > depends on POWER_RESET > help > Power off and reset support for the ARM Ltd. Versatile > -- > 1.8.1.2 -- 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: introduce i2c helper i2c_find_client_by_name()
On 6/19/2013 3:13 AM, Wolfram Sang wrote: Even you prefer to extend v4l2, you still need this helper. The idea is just to move the unregister/register from a specific ISP driver to v4l2. I think you misunderstood my pionts somehow. Let me clarfiy a little bit: Current solution: 1. Platform codes(on top of DT/ACPI5/SFI) don't call i2c_register_board_info(), instead, prepare a table(kind of platform data) that has all camera i2c device information. 2. ISP driver registers devices listed in the table to i2c core - this makes sure v4l2 takes over these devices. The problem with this solution is that when a camera device runs on both ACPI5 and SFI, the platform codes will get a bit complicated and it's difficult to ensure one binary kernel runs on both platforms(ACPI5 and SFI). (To extend v4l2 with this solution doen't resolve my problem) Solution I'm suggesting: 1. Let the platform codes call i2c_register_board_info() anyway. 2. Since ISP driver knows which camera devices it supports, so it simply unregisters those devices (get the client by the introduced helper), then register it within v4l2. This solution ensure one binary kernel can run on both platforms. (To extend v4l2 with this solution could not be feasible, the device table is ISP driver specific, not v4l2 specific) I also wonder about the need to unregister. I have to admit I don't know much about I2C handling in v4l2. But if it requires unregistering from i2c core and registering to v4l2 core, then it sounds to me like we could check if there is a more fundamential cleanup needed? Deferring for now, looks like an issue worth looking at, yet there are other things in the queue first. Platform codes are supposed to call i2c_register_board_info() or i2c_new_device() to register devices, we don't want to change this. Not sure v4l2 can still take over the devices without unregistering/registering. Need look deeply into the v4l2 code... -- 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: randconfig build errors with next-20130620, in several drivers/media
Hi, On Thursday 20 June 2013 11:52:44 Jim Davis wrote: > Building with the attached random configuration file generates errors in > both > > drivers/media/v4l2-core > drivers/media/usb/uvc > > LD init/built-in.o > /home/jim/linux-next/linux/drivers/media/v4l2-core/videobuf2-core.c:2577: > undefi ned reference to `video_devdata' [snip] > /home/jim/linux-next/linux/drivers/media/v4l2-core/videobuf2-core.c:2591: > undefi ned reference to `v4l2_fh_release' [snip] > /home/jim/linux-next/linux/drivers/media/v4l2-core/videobuf2-core.c:1980: > undefi ned reference to `v4l2_event_pending' [snip] > drivers/built-in.o: In function `uvc_delete': > /home/jim/linux-next/linux/drivers/media/usb/uvc/uvc_driver.c:1606: > undefined re ference to `usb_put_intf' [snip] The issue seem to be caused by USB_VIDEO_CLASS=y and VIDEO_V4L2=m && USB=m. I'm not sure what made that combination possible, but I haven't been able to reproduce it locally on next-20130620. Running make with the attached config turns USB_VIDEO_CLASS=y into USB_VIDEO_CLASS=m. -- 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 0/2] rwsem: performance enhancements for systems with many cores
On Fri, Jun 21, 2013 at 5:00 PM, Davidlohr Bueso wrote: > On Fri, 2013-06-21 at 16:51 -0700, Tim Chen wrote: >> In this patchset, we introduce two optimizations to read write semaphore. >> The first one reduces cache bouncing of the sem->count field >> by doing a pre-read of the sem->count and avoid cmpxchg if possible. >> The second patch introduces similar optimistic spining logic in >> the mutex code for the writer lock acquisition of rw-sem. >> >> Combining the two patches, in testing by Davidlohr Bueso on aim7 workloads >> on 8 socket 80 cores system, he saw improvements of >> alltests (+14.5%), custom (+17%), disk (+11%), high_systime >> (+5%), shared (+15%) and short (+4%), most of them after around 500 >> users when i_mmap was implemented as rwsem. >> >> Feedbacks on the effectiveness of these tweaks on other workloads >> will be appreciated. > > Tim, I was really hoping to send all this in one big bundle. I was doing > some further testing (enabling hyperthreading and some Oracle runs), > fortunately everything looks ok and we are getting actual improvements > on large boxes. > > That said, how about I send you my i_mmap rwsem patchset for a v2 of > this patchset? I'm a bit confused about the state of these patchsets - it looks like I'm only copied into half of the conversations. Should I wait for a v2 here, or should I hunt down for Alex's version of things, or... ? -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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 0/2] Delay initializing of large sections of memory
On Fri, Jun 21, 2013 at 2:30 PM, Mike Travis wrote: > > > On 6/21/2013 11:50 AM, Greg KH wrote: >> On Fri, Jun 21, 2013 at 11:44:22AM -0700, Yinghai Lu wrote: >>> On Fri, Jun 21, 2013 at 10:03 AM, H. Peter Anvin wrote: On 06/21/2013 09:51 AM, Greg KH wrote: I suspect the cutoff for this should be a lot lower than 8 TB even, more like 128 GB or so. The only concern is to not set the cutoff so low that we can end up running out of memory or with suboptimal NUMA placement just because of this. >>> >>> I would suggest another way: >>> only boot the system with boot node (include cpu, ram and pci root buses). >>> then after boot, could add other nodes. >> >> What exactly do you mean by "after boot"? Often, the boot process of >> userspace needs those additional cpus and ram in order to initialize >> everything (like the pci devices) properly. > > Exactly. That's why I left both low and high memory on each node. looks like you assume every node have same ram, and before booting you you need to know memory layout to append the boot command line. We have patchset that moving srat table parse early. git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-mm https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-mm on top that, we could make your patch pass more simple command like 1/2^n of every node, and only need to pass n instead. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH staging-next] zram: remove zram_sysfs file (v2)
Move zram sysfs code to zram drv and remove zram_sysfs.c
file. This gives ability to make static a number of previously
exported zram functions, used from zram sysfs, e.g. internal zram
zram_meta_alloc/free(). We also can drop zram_drv wrapper
functions, used from zram sysfs:
e.g. zram_reset_device()/__zram_reset_device() pair.
v2: as suggested by Greg K-H, move MODULE description to the
bottom of the file.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/Makefile | 2 +-
drivers/staging/zram/zram_drv.c | 516 ++
drivers/staging/zram/zram_drv.h | 10 -
drivers/staging/zram/zram_sysfs.c | 209 ---
4 files changed, 350 insertions(+), 387 deletions(-)
diff --git a/drivers/staging/zram/Makefile b/drivers/staging/zram/Makefile
index 7f4a301..cb0f9ce 100644
--- a/drivers/staging/zram/Makefile
+++ b/drivers/staging/zram/Makefile
@@ -1,3 +1,3 @@
-zram-y := zram_drv.o zram_sysfs.o
+zram-y := zram_drv.o
obj-$(CONFIG_ZRAM) += zram.o
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index ec2b2b5..7538774 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -42,6 +42,104 @@ static struct zram *zram_devices;
/* Module params (documentation at end) */
static unsigned int num_devices = 1;
+static inline struct zram *dev_to_zram(struct device *dev)
+{
+ return (struct zram *)dev_to_disk(dev)->private_data;
+}
+
+static ssize_t disksize_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%llu\n", zram->disksize);
+}
+
+static ssize_t initstate_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%u\n", zram->init_done);
+}
+
+static ssize_t num_reads_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%llu\n",
+ (u64)atomic64_read(>stats.num_reads));
+}
+
+static ssize_t num_writes_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%llu\n",
+ (u64)atomic64_read(>stats.num_writes));
+}
+
+static ssize_t invalid_io_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%llu\n",
+ (u64)atomic64_read(>stats.invalid_io));
+}
+
+static ssize_t notify_free_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%llu\n",
+ (u64)atomic64_read(>stats.notify_free));
+}
+
+static ssize_t zero_pages_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%u\n", zram->stats.pages_zero);
+}
+
+static ssize_t orig_data_size_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%llu\n",
+ (u64)(zram->stats.pages_stored) << PAGE_SHIFT);
+}
+
+static ssize_t compr_data_size_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct zram *zram = dev_to_zram(dev);
+
+ return sprintf(buf, "%llu\n",
+ (u64)atomic64_read(>stats.compr_size));
+}
+
+static ssize_t mem_used_total_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ u64 val = 0;
+ struct zram *zram = dev_to_zram(dev);
+ struct zram_meta *meta = zram->meta;
+
+ down_read(>init_lock);
+ if (zram->init_done)
+ val = zs_get_total_size_bytes(meta->mem_pool);
+ up_read(>init_lock);
+
+ return sprintf(buf, "%llu\n", val);
+}
+
static int zram_test_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
{
@@ -60,6 +158,97 @@ static void zram_clear_flag(struct zram_meta *meta, u32
index,
meta->table[index].flags &= ~BIT(flag);
}
+static inline int is_partial_io(struct bio_vec *bvec)
+{
+ return bvec->bv_len != PAGE_SIZE;
+}
+
+/*
+ * Check if request is within bounds and aligned on zram logical blocks.
+ */
+static inline int valid_io_request(struct zram *zram, struct bio *bio)
+{
+ u64 start, end, bound;
+
+ /* unaligned request */
+ if (unlikely(bio->bi_sector & (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1)))
+ return 0;
+ if (unlikely(bio->bi_size & (ZRAM_LOGICAL_BLOCK_SIZE - 1)))
+ return 0;
+
+
Re: [PATCH 1/2] rwsem: check the lock before cpmxchg in down_write_trylock and rwsem_do_wake
On Sat, 2013-06-22 at 08:10 +0800, Alex Shi wrote: > On 06/22/2013 07:51 AM, Tim Chen wrote: > > Doing cmpxchg will cause cache bouncing when checking > > sem->count. This could cause scalability issue > > in a large machine (e.g. a 80 cores box). > > > > A pre-read of sem->count can mitigate this. > > > > Signed-off-by: Alex Shi > > Signed-off-by: Tim Chen > > Hi Tim, > there is a technical error in this patch. > the "From: " line should be 'Alex Shi', since he made the most input of > this patch. > > And I still think split this patch to 4 smaller will make it more simple > to review, that I had sent you and Davidlohr. Yep, and you had updated the changelog for 1/4: rwsem: check the lock before cpmxchg in down_write_trylock to: "cmpxchg will cause cache bouncing when do the value checking, that cause scalability issue in a large machine (like a 80 cores box). A lock status pre-read can relief this." > > could you like to re-send with my 4 patch version? :) For those 4 patches: Acked-by: Davidlohr Bueso -- 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: [PATCHv v3] power: Include additional information in pm_print_times
On Monday, June 17, 2013 01:36:35 PM Shuah Khan wrote:
> Change __device_suspend() path to include driver name and the ops that
> get run for a device. This additional information helps associate the
> driver and the type of pm_ops the device uses in the suspend path very
> quickly, which will aid in debugging problems in suspend and resume paths.
> Changed both start and end debug messages to include pm_ops information
> and use dev_info() instead of pr_info(). Changed the end message to include
> parent device information and have the same format as the start message.
>
> dmesg output before the change:
>
> [ 164.390032] calling 1-1+ @ 69, parent: usb1
> [ 164.390035] call 1-1+ returned 0 after 0 usecs
>
> [ 164.390352] calling 00:0a+ @ 2457, parent: pnp0
> [ 164.390357] call 00:0a+ returned 0 after 3 usecs
>
> [ 164.390361] calling 00:09+ @ 2457, parent: pnp0
> [ 164.496458] call 00:09+ returned 0 after 103500 usecs
>
> [ 164.496494] calling 00:05+ @ 2457, parent: pnp0
> [ 164.496511] call 00:05+ returned 0 after 14 usecs
>
> dmesg output after the change:
>
> [ 545.985394] usb 1-1: Start: type pm ops @ 68, parent: usb1
> [ 545.987650] usb 1-1: End : type pm ops @ 68, parent: usb1 time(2184
> usecs) err(0)
>
> [ 545.982544] system 00:0a: Start: legacy bus pm ops @ 2391, parent: pnp0
> [ 545.982554] system 00:0a: End : legacy bus pm ops @ 2391, parent: pnp0
> time(4 usecs) err(0)
>
> [ 545.982569] tpm_tis 00:09: Start: legacy bus pm ops @ 2391, parent: pnp0
> [ 546.087017] tpm_tis 00:09: End : legacy bus pm ops @ 2391, parent: pnp0
> time(101936 usecs) err(0)
>
> [ 546.087069] rtc_cmos 00:05: Start: legacy bus pm ops @ 2391, parent: pnp0
> [ 546.087084] rtc_cmos 00:05: End : legacy bus pm ops @ 2391, parent: pnp0
> time(11 usecs) err(0)
>
I was about to apply your patch, but then I noticed something that might cause
problems to happen.
Namely, there are tools that use these messages to create suspend/resume time
charts and they will stop working after the proposed changes.
Please keep the existing formatting the way it is and only append the additional
information at the end of each line.
Thanks,
Rafael
> Signed-off-by: Shuah Khan
> ---
>
> v2: Change to use dev_info() instead of pr_info()
> v3: Change to add parent info to debug_report and make start and end messages
> look similar have a tighter association.
>
> drivers/base/power/main.c | 49
> +++--
> 1 file changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 5a9b656..c2132b8 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -157,13 +157,14 @@ void device_pm_move_last(struct device *dev)
> list_move_tail(>power.entry, _list);
> }
>
> -static ktime_t initcall_debug_start(struct device *dev)
> +static ktime_t initcall_debug_start(struct device *dev, char *info)
> {
> ktime_t calltime = ktime_set(0, 0);
>
> if (pm_print_times_enabled) {
> - pr_info("calling %s+ @ %i, parent: %s\n",
> - dev_name(dev), task_pid_nr(current),
> + /* string in info has an extra space at the end */
> + dev_info(dev, "Start: %s@ %i, parent: %s\n",
> + info, task_pid_nr(current),
> dev->parent ? dev_name(dev->parent) : "none");
> calltime = ktime_get();
> }
> @@ -172,15 +173,19 @@ static ktime_t initcall_debug_start(struct device *dev)
> }
>
> static void initcall_debug_report(struct device *dev, ktime_t calltime,
> - int error)
> + int error, char *info)
> {
> ktime_t delta, rettime;
>
> if (pm_print_times_enabled) {
> rettime = ktime_get();
> delta = ktime_sub(rettime, calltime);
> - pr_info("call %s+ returned %d after %Ld usecs\n", dev_name(dev),
> - error, (unsigned long long)ktime_to_ns(delta) >> 10);
> + /* string in info has an extra space at the end */
> + dev_info(dev,
> + "End : %s@ %i, parent: %s time(%llu usecs) err(%d)\n",
> + info, task_pid_nr(current),
> + dev->parent ? dev_name(dev->parent) : "none",
> + (unsigned long long)ktime_to_ns(delta) >> 10, error);
> }
> }
>
> @@ -373,13 +378,13 @@ static int dpm_run_callback(pm_callback_t cb, struct
> device *dev,
> if (!cb)
> return 0;
>
> - calltime = initcall_debug_start(dev);
> + calltime = initcall_debug_start(dev, info);
>
> pm_dev_dbg(dev, state, info);
> error = cb(dev);
> suspend_report_result(cb, error);
>
> - initcall_debug_report(dev, calltime, error);
> + initcall_debug_report(dev, calltime, error, info);
>
> return error;
> }
> @@ -1027,17 +1032,19 @@
Re: [PATCH 1/2] rwsem: check the lock before cpmxchg in down_write_trylock and rwsem_do_wake
On 06/22/2013 07:51 AM, Tim Chen wrote:
> Doing cmpxchg will cause cache bouncing when checking
> sem->count. This could cause scalability issue
> in a large machine (e.g. a 80 cores box).
>
> A pre-read of sem->count can mitigate this.
>
> Signed-off-by: Alex Shi
> Signed-off-by: Tim Chen
Hi Tim,
there is a technical error in this patch.
the "From: " line should be 'Alex Shi', since he made the most input of
this patch.
And I still think split this patch to 4 smaller will make it more simple
to review, that I had sent you and Davidlohr.
could you like to re-send with my 4 patch version? :)
> ---
> include/asm-generic/rwsem.h |8
> lib/rwsem.c | 21 +
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/include/asm-generic/rwsem.h b/include/asm-generic/rwsem.h
> index bb1e2cd..052d973 100644
> --- a/include/asm-generic/rwsem.h
> +++ b/include/asm-generic/rwsem.h
> @@ -70,11 +70,11 @@ static inline void __down_write(struct rw_semaphore *sem)
>
> static inline int __down_write_trylock(struct rw_semaphore *sem)
> {
> - long tmp;
> + if (unlikely(>count != RWSEM_UNLOCKED_VALUE))
> + return 0;
>
> - tmp = cmpxchg(>count, RWSEM_UNLOCKED_VALUE,
> - RWSEM_ACTIVE_WRITE_BIAS);
> - return tmp == RWSEM_UNLOCKED_VALUE;
> + return cmpxchg(>count, RWSEM_UNLOCKED_VALUE,
> + RWSEM_ACTIVE_WRITE_BIAS) == RWSEM_UNLOCKED_VALUE;
> }
>
> /*
> diff --git a/lib/rwsem.c b/lib/rwsem.c
> index 19c5fa9..2072af5 100644
> --- a/lib/rwsem.c
> +++ b/lib/rwsem.c
> @@ -75,7 +75,7 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
> rwsem_wake_type wake_type)
>* will block as they will notice the queued writer.
>*/
> wake_up_process(waiter->task);
> - goto out;
> + return sem;
> }
>
> /* Writers might steal the lock before we grant it to the next reader.
> @@ -85,15 +85,21 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
> rwsem_wake_type wake_type)
> adjustment = 0;
> if (wake_type != RWSEM_WAKE_READ_OWNED) {
> adjustment = RWSEM_ACTIVE_READ_BIAS;
> - try_reader_grant:
> - oldcount = rwsem_atomic_update(adjustment, sem) - adjustment;
> - if (unlikely(oldcount < RWSEM_WAITING_BIAS)) {
> - /* A writer stole the lock. Undo our reader grant. */
> + while (1) {
> + /* A writer stole the lock. */
> + if (sem->count < RWSEM_WAITING_BIAS)
> + return sem;
> +
> + oldcount = rwsem_atomic_update(adjustment, sem)
> + - adjustment;
> + if (likely(oldcount >= RWSEM_WAITING_BIAS))
> + break;
> +
> + /* A writer stole the lock. Undo our reader grant. */
> if (rwsem_atomic_update(-adjustment, sem) &
> RWSEM_ACTIVE_MASK)
> - goto out;
> + return sem;
> /* Last active locker left. Retry waking readers. */
> - goto try_reader_grant;
> }
> }
>
> @@ -136,7 +142,6 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
> rwsem_wake_type wake_type)
> sem->wait_list.next = next;
> next->prev = >wait_list;
>
> - out:
> return sem;
> }
>
>
--
Thanks
Alex
--
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 v12 00/11] DMA Engine support for AM33XX
Hi Sekhar, On Fri, Jun 21, 2013 at 5:27 AM, Sekhar Nori wrote: > Joel, > > On 6/21/2013 2:36 AM, Joel A Fernandes wrote: >> From: Joel A Fernandes >> >> This series is remaining of Matt Porter's EDMA patches for AM33XX EDMA >> support >> with changes for few pending review comments on v11 series. > > I have posted a branch with fixes for patches accepted by me in this > series (also posted inline as replies to specific patches). > > https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.11/soc-2 > > Can you please give it a good test - especially on AM335x? I will send a > pull request after you confirm. If you find bugs please send incremental > patches so I can merge into the original patch. This breaks on AM33XX due to dangling pointer, I sent a follow up patch addressing it. However, with this branch I still get.. mmc: unable to obtain RX DMA engine channel 25 Is there anything obvious you might have changed that is causing this? Thanks, Joel -- 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: [BUGFIX v2 0/4] fix bug 56531, 59501 and 59581
On Saturday, June 22, 2013 12:54:21 AM Jiang Liu wrote:
> On 06/21/2013 03:06 AM, Rafael J. Wysocki wrote:
> > On Wednesday, June 19, 2013 11:18:41 AM Alexander E. Patrakov wrote:
> >> 2013/6/19 Rafael J. Wysocki :
> >>> OK, let's try to untangle this a bit.
> >>>
> >>> If you applyt patches [1/4] and [4/4] from the $subject series only, what
> >>> does remain unfixed?
> >>
> >> [not tested, can do so in 12 hours if needed]
> >>
> >> I think there will be problems on undocking and/or on the second
> >> docking, as described in comments #6 - #8 of
> >> https://bugzilla.kernel.org/show_bug.cgi?id=59501
> >
> > OK, I think I have something that might work. It may not solve all
> > problems,
> > but maybe it helps a bit. Unfortunately, I can't really test it, so please
> > do
> > if you can.
> >
> > Please apply [1/4] and [4/4] and the one below and see what happens.
> >
> > Thanks,
> > Rafael
> >
> >
> > ---
> > Rationale:
> > acpiphp_glue.c:disable_device() trims the underlying ACPI device objects
> > after removing the companion PCI devices, so the dock station code
> > doesn't need to trim them separately for the dependent devices handled
> > by acpiphp.
> >
> > Moreover, acpiphp_glue.c is the only user of
> > [un]register_hotplug_dock_device(), so *all* devices on the
> > ds->hotplug_devices list are handled by acpiphp and ops is set for all
> > of them.
> Hi Rafael,
> There's an ongoing patch to fix a disk bay hotplug regression, which
> may add a second caller of register_hotplug_device(). Please refer to
> bug 59871, and the proposed patch is at:
> https://bugzilla.kernel.org/attachment.cgi?id=105581
>
> >
> > This means that (1) the ds->hotplug_devices list is not necessary (we
> > can always walk ds->dependent_devices instead and look for those that
> > have dd->ops set) and (2) we don't need to call
> > dock_remove_acpi_device(dd->handle) on eject for any of those devices,
> > because dd->ops->handler() is going to take care of the ACPI device
> > objects trimming for them anyway.
> >
> > Taking the above into account make the following changes:
> > (1) Drop hotplug_devices from struct dock_station.
> > (2) Drop dock_{add|del}_hotplug_device()
> > (3) Make [un]register_hotplug_dock_device() [un]set 'ops' and
> > 'context' for the given device under ds->hp_lock.
> > (4) Add hot_remove_dock_devices() that walks ds->dependent_devices and
> > either calls dd->ops->handler(), if present, or trims the underlying
> > ACPI device object, otherwise.
> > (5) Replace hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST) calls
> > with hot_remove_dock_devices(ds).
> > (6) Rename hotplug_dock_devices() to hot_add_dock_devices() and make
> > it only handle bus check and device check requests. Make it walk
> > ds->dependent_devices instead of ds->hotplug devices.
> > (7) Make dock_event() walk ds->dependent_devices (instead of
> > ds->hotplug devices) under ds->hp_lock.
> > ---
> > drivers/acpi/dock.c | 111
> >
> > 1 file changed, 53 insertions(+), 58 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/dock.c
> > ===
> > --- linux-pm.orig/drivers/acpi/dock.c
> > +++ linux-pm/drivers/acpi/dock.c
> > @@ -66,7 +66,6 @@ struct dock_station {
> > spinlock_t dd_lock;
> > struct mutex hp_lock;
> > struct list_head dependent_devices;
> > - struct list_head hotplug_devices;
> >
> > struct list_head sibling;
> > struct platform_device *dock_device;
> > @@ -121,38 +120,6 @@ add_dock_dependent_device(struct dock_st
> > }
> >
> > /**
> > - * dock_add_hotplug_device - associate a hotplug handler with the dock
> > station
> > - * @ds: The dock station
> > - * @dd: The dependent device struct
> > - *
> > - * Add the dependent device to the dock's hotplug device list
> > - */
> > -static void
> > -dock_add_hotplug_device(struct dock_station *ds,
> > - struct dock_dependent_device *dd)
> > -{
> > - mutex_lock(>hp_lock);
> > - list_add_tail(>hotplug_list, >hotplug_devices);
> > - mutex_unlock(>hp_lock);
> > -}
> > -
> > -/**
> > - * dock_del_hotplug_device - remove a hotplug handler from the dock station
> > - * @ds: The dock station
> > - * @dd: the dependent device struct
> > - *
> > - * Delete the dependent device from the dock's hotplug device list
> > - */
> > -static void
> > -dock_del_hotplug_device(struct dock_station *ds,
> > - struct dock_dependent_device *dd)
> > -{
> > - mutex_lock(>hp_lock);
> > - list_del(>hotplug_list);
> > - mutex_unlock(>hp_lock);
> > -}
> > -
> > -/**
> > * find_dock_dependent_device - get a device dependent on this dock
> > * @ds: the dock station
> > * @handle: the acpi_handle of the device we want
> > @@ -342,40 +309,60 @@ static void
[PATCH] ARM: common: edma: Fix dangling pointer dereference
Returning a pointer to a variable in the setup_from_dt function is
causing dangling pointer dereferences. This causes boot to fail
on AM33XX.
Add ninfo to the caller's stack and just return the kzalloc'ed ptr
from the calling function.
Seen on linux-davinci/soc-v2 branch.
Cc: Sekhar Nori
Signed-off-by: Joel A Fernandes
---
arch/arm/common/edma.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2b591b1..f913e82 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1514,10 +1514,9 @@ static struct of_dma_filter_info edma_filter_info = {
.filter_fn = edma_filter_fn,
};
-static struct edma_soc_info **edma_setup_info_from_dt(struct device *dev,
+static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
struct device_node *node)
{
- static struct edma_soc_info **info;
struct edma_soc_info *ninfo;
int ret;
@@ -1539,9 +1538,7 @@ static struct edma_soc_info
**edma_setup_info_from_dt(struct device *dev,
of_dma_controller_register(dev->of_node, of_dma_simple_xlate,
_filter_info);
- info =
-
- return info;
+ return ninfo;
}
#else
static struct edma_soc_info **edma_setup_info_from_dt(struct device *dev,
@@ -1554,6 +1551,7 @@ static struct edma_soc_info
**edma_setup_info_from_dt(struct device *dev,
static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev->dev.platform_data;
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL};
s8 (*queue_priority_mapping)[2];
s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
@@ -1572,7 +1570,7 @@ static int edma_probe(struct platform_device *pdev)
int ret;
if (node) {
- info = edma_setup_info_from_dt(dev, node);
+ ninfo[0] = edma_setup_info_from_dt(dev, node);
if (IS_ERR(info)) {
dev_err(dev, "failed to get DT data\n");
return PTR_ERR(info);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] rwsem: do optimistic spinning for writer lock acquisition
On Fri, 2013-06-21 at 16:51 -0700, Tim Chen wrote:
> Introduce in this patch optimistic spinning for writer lock
> acquisition in read write semaphore. The logic is
> similar to the optimistic spinning in mutex but without
> the MCS lock queueing of the spinner. This provides a
> better chance for a writer to acquire the lock before
> being we block it and put it to sleep.
>
> Disabling of pre-emption during optimistic spinning
> was suggested by Davidlohr Bueso. It
> improved performance of aim7 for his test suite.
>
> Combined with the patch to avoid unnecesary cmpxchg,
> in testing by Davidlohr Bueso on aim7 workloads
> on 8 socket 80 cores system, he saw improvements of
> alltests (+14.5%), custom (+17%), disk (+11%), high_systime
> (+5%), shared (+15%) and short (+4%), most of them after around 500
> users when he implemented i_mmap as rwsem.
>
> Signed-off-by: Tim Chen
Signed-off-by: Davidlohr Bueso
> ---
> Makefile |2 +-
> include/linux/rwsem.h |3 +
> init/Kconfig |9 +++
> kernel/rwsem.c| 29 +-
> lib/rwsem.c | 148
> +
> 5 files changed, 178 insertions(+), 13 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 49aa84b..7d1ef64 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +1,7 @@
> VERSION = 3
> PATCHLEVEL = 10
> SUBLEVEL = 0
> -EXTRAVERSION = -rc4
> +EXTRAVERSION = -rc4-optspin4
> NAME = Unicycling Gorilla
>
> # *DOCUMENTATION*
> diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
> index 0616ffe..0c5933b 100644
> --- a/include/linux/rwsem.h
> +++ b/include/linux/rwsem.h
> @@ -29,6 +29,9 @@ struct rw_semaphore {
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lockdep_map dep_map;
> #endif
> +#ifdef CONFIG_RWSEM_SPIN_ON_WRITE_OWNER
> + struct task_struct *owner;
> +#endif
> };
>
> extern struct rw_semaphore *rwsem_down_read_failed(struct rw_semaphore *sem);
> diff --git a/init/Kconfig b/init/Kconfig
> index 9d3a788..1c582d1 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1595,6 +1595,15 @@ config TRACEPOINTS
>
> source "arch/Kconfig"
>
> +config RWSEM_SPIN_ON_WRITE_OWNER
> + bool "Optimistic spin write acquisition for writer owned rw-sem"
> + default n
> + depends on SMP
> + help
> + Allows a writer to perform optimistic spinning if another writer own
> + the read write semaphore. This gives a greater chance for writer to
> + acquire a semaphore before blocking it and putting it to sleep.
> +
> endmenu # General setup
>
> config HAVE_GENERIC_DMA_COHERENT
> diff --git a/kernel/rwsem.c b/kernel/rwsem.c
> index cfff143..a32990a 100644
> --- a/kernel/rwsem.c
> +++ b/kernel/rwsem.c
> @@ -12,6 +12,26 @@
>
> #include
>
> +#ifdef CONFIG_RWSEM_SPIN_ON_WRITE_OWNER
> +static inline void rwsem_set_owner(struct rw_semaphore *sem)
> +{
> + sem->owner = current;
> +}
> +
> +static inline void rwsem_clear_owner(struct rw_semaphore *sem)
> +{
> + sem->owner = NULL;
> +}
> +#else
> +static inline void rwsem_set_owner(struct rw_semaphore *sem)
> +{
> +}
> +
> +static inline void rwsem_clear_owner(struct rw_semaphore *sem)
> +{
> +}
> +#endif
> +
> /*
> * lock for reading
> */
> @@ -48,6 +68,7 @@ void __sched down_write(struct rw_semaphore *sem)
> rwsem_acquire(>dep_map, 0, 0, _RET_IP_);
>
> LOCK_CONTENDED(sem, __down_write_trylock, __down_write);
> + rwsem_set_owner(sem);
> }
>
> EXPORT_SYMBOL(down_write);
> @@ -59,8 +80,10 @@ int down_write_trylock(struct rw_semaphore *sem)
> {
> int ret = __down_write_trylock(sem);
>
> - if (ret == 1)
> + if (ret == 1) {
> rwsem_acquire(>dep_map, 0, 1, _RET_IP_);
> + rwsem_set_owner(sem);
> + }
> return ret;
> }
>
> @@ -86,6 +109,7 @@ void up_write(struct rw_semaphore *sem)
> rwsem_release(>dep_map, 1, _RET_IP_);
>
> __up_write(sem);
> + rwsem_clear_owner(sem);
> }
>
> EXPORT_SYMBOL(up_write);
> @@ -100,6 +124,7 @@ void downgrade_write(struct rw_semaphore *sem)
>* dependency.
>*/
> __downgrade_write(sem);
> + rwsem_clear_owner(sem);
> }
>
> EXPORT_SYMBOL(downgrade_write);
> @@ -122,6 +147,7 @@ void _down_write_nest_lock(struct rw_semaphore *sem,
> struct lockdep_map *nest)
> rwsem_acquire_nest(>dep_map, 0, 0, nest, _RET_IP_);
>
> LOCK_CONTENDED(sem, __down_write_trylock, __down_write);
> + rwsem_set_owner(sem);
> }
>
> EXPORT_SYMBOL(_down_write_nest_lock);
> @@ -141,6 +167,7 @@ void down_write_nested(struct rw_semaphore *sem, int
> subclass)
> rwsem_acquire(>dep_map, subclass, 0, _RET_IP_);
>
> LOCK_CONTENDED(sem, __down_write_trylock, __down_write);
> + rwsem_set_owner(sem);
> }
>
> EXPORT_SYMBOL(down_write_nested);
> diff --git a/lib/rwsem.c b/lib/rwsem.c
> index 2072af5..8e331c5 100644
> --- a/lib/rwsem.c
> +++ b/lib/rwsem.c
> @@ -8,6 +8,7 @@
> */
>
Re: [PATCH 0/2] rwsem: performance enhancements for systems with many cores
On Fri, 2013-06-21 at 16:51 -0700, Tim Chen wrote: > In this patchset, we introduce two optimizations to read write semaphore. > The first one reduces cache bouncing of the sem->count field > by doing a pre-read of the sem->count and avoid cmpxchg if possible. > The second patch introduces similar optimistic spining logic in > the mutex code for the writer lock acquisition of rw-sem. > > Combining the two patches, in testing by Davidlohr Bueso on aim7 workloads > on 8 socket 80 cores system, he saw improvements of > alltests (+14.5%), custom (+17%), disk (+11%), high_systime > (+5%), shared (+15%) and short (+4%), most of them after around 500 > users when i_mmap was implemented as rwsem. > > Feedbacks on the effectiveness of these tweaks on other workloads > will be appreciated. Tim, I was really hoping to send all this in one big bundle. I was doing some further testing (enabling hyperthreading and some Oracle runs), fortunately everything looks ok and we are getting actual improvements on large boxes. That said, how about I send you my i_mmap rwsem patchset for a v2 of this patchset? Thanks, Davidlohr > > > Alex Shi (1): > rwsem: check the lock before cpmxchg in down_write_trylock and > rwsem_do_wake > > Tim Chen (1): > rwsem: do optimistic spinning for writer lock acquisition > > Makefile|2 +- > include/asm-generic/rwsem.h |8 +- > include/linux/rwsem.h |3 + > init/Kconfig|9 +++ > kernel/rwsem.c | 29 +++- > lib/rwsem.c | 169 > ++- > 6 files changed, 195 insertions(+), 25 deletions(-) > -- 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 0/2] *** SUBJECT HERE ***
On Sat, Jun 22, 2013 at 01:08:12AM +0200, Anders Hammarquist wrote:
> In a message of Wed, 19 Jun 2013 15:53:15 -0700, Greg KH writes:
> >I think you forgot a Subject :)
>
> Indeed. I blame it on my first fight with git format-patch ;-)
>
> >On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote:
> >> This patch set adds the product id to the driver, and makes the
> >> product type more explicit. Arguably, the ABBOTT_PRODUCT_ID
> >> define could be removed, but I left it on the off chance that
> >> someone other that the TI 3410 driver uses it.
> >
> >No, it doesn't, please fix up that last patch and resend it.
>
> Right, and in removing it I actually found that it was used in
> two places in the driver. I lost my second fight with format-patch
> so I'll just enclose the fixed patch below.
>
> /Anders
>
> ---8<---
> ti_usb_3410_5052:
> * Remove unspecific ABBOTT_PRODUCT_ID
> * Fix size of statically sized arrays
>
> Signed-off-by: Anders Hammarquist
Please resend this in a format that I can apply it in (i.e. one that
does not require me to edit it by hand...)
Also, please cc: the linux-...@vger.kernel.org mailing list for usb
patches.
> diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
> b/drivers/usb/serial/ti_usb_3410_5052.c
> index e581c25..26c1161 100644
> --- a/drivers/usb/serial/ti_usb_3410_5052.c
> +++ b/drivers/usb/serial/ti_usb_3410_5052.c
> @@ -158,7 +158,7 @@ static unsigned int product_5052_count;
> /* the array dimension is the number of default entries plus */
> /* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
> /* null entry */
> -static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
> +static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
That's a mess, why have it be a static array at all? Just include an
empty one at the end.
> { USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
> { USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
> { USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
> @@ -172,8 +172,8 @@ static struct usb_device_id
> ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
> { USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
> { USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
> { USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
> - { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
> - { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
> + { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
> + { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
> { USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
> };
>
> @@ -184,7 +184,7 @@ static struct usb_device_id
> ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
> { USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
> };
>
> -static struct usb_device_id
> ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
> +static struct usb_device_id
> ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
Same here. Although that might take another patch, to handle it all
correctly, separate from this "change the device id names" patch.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] rwsem: performance enhancements for systems with many cores
In this patchset, we introduce two optimizations to read write semaphore. The first one reduces cache bouncing of the sem->count field by doing a pre-read of the sem->count and avoid cmpxchg if possible. The second patch introduces similar optimistic spining logic in the mutex code for the writer lock acquisition of rw-sem. Combining the two patches, in testing by Davidlohr Bueso on aim7 workloads on 8 socket 80 cores system, he saw improvements of alltests (+14.5%), custom (+17%), disk (+11%), high_systime (+5%), shared (+15%) and short (+4%), most of them after around 500 users when i_mmap was implemented as rwsem. Feedbacks on the effectiveness of these tweaks on other workloads will be appreciated. Alex Shi (1): rwsem: check the lock before cpmxchg in down_write_trylock and rwsem_do_wake Tim Chen (1): rwsem: do optimistic spinning for writer lock acquisition Makefile|2 +- include/asm-generic/rwsem.h |8 +- include/linux/rwsem.h |3 + init/Kconfig|9 +++ kernel/rwsem.c | 29 +++- lib/rwsem.c | 169 ++- 6 files changed, 195 insertions(+), 25 deletions(-) -- 1.7.4.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 2/2] rwsem: do optimistic spinning for writer lock acquisition
Introduce in this patch optimistic spinning for writer lock
acquisition in read write semaphore. The logic is
similar to the optimistic spinning in mutex but without
the MCS lock queueing of the spinner. This provides a
better chance for a writer to acquire the lock before
being we block it and put it to sleep.
Disabling of pre-emption during optimistic spinning
was suggested by Davidlohr Bueso. It
improved performance of aim7 for his test suite.
Combined with the patch to avoid unnecesary cmpxchg,
in testing by Davidlohr Bueso on aim7 workloads
on 8 socket 80 cores system, he saw improvements of
alltests (+14.5%), custom (+17%), disk (+11%), high_systime
(+5%), shared (+15%) and short (+4%), most of them after around 500
users when he implemented i_mmap as rwsem.
Signed-off-by: Tim Chen
---
Makefile |2 +-
include/linux/rwsem.h |3 +
init/Kconfig |9 +++
kernel/rwsem.c| 29 +-
lib/rwsem.c | 148 +
5 files changed, 178 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index 49aa84b..7d1ef64 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 10
SUBLEVEL = 0
-EXTRAVERSION = -rc4
+EXTRAVERSION = -rc4-optspin4
NAME = Unicycling Gorilla
# *DOCUMENTATION*
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 0616ffe..0c5933b 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -29,6 +29,9 @@ struct rw_semaphore {
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
+#ifdef CONFIG_RWSEM_SPIN_ON_WRITE_OWNER
+ struct task_struct *owner;
+#endif
};
extern struct rw_semaphore *rwsem_down_read_failed(struct rw_semaphore *sem);
diff --git a/init/Kconfig b/init/Kconfig
index 9d3a788..1c582d1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1595,6 +1595,15 @@ config TRACEPOINTS
source "arch/Kconfig"
+config RWSEM_SPIN_ON_WRITE_OWNER
+ bool "Optimistic spin write acquisition for writer owned rw-sem"
+ default n
+ depends on SMP
+ help
+ Allows a writer to perform optimistic spinning if another writer own
+ the read write semaphore. This gives a greater chance for writer to
+ acquire a semaphore before blocking it and putting it to sleep.
+
endmenu# General setup
config HAVE_GENERIC_DMA_COHERENT
diff --git a/kernel/rwsem.c b/kernel/rwsem.c
index cfff143..a32990a 100644
--- a/kernel/rwsem.c
+++ b/kernel/rwsem.c
@@ -12,6 +12,26 @@
#include
+#ifdef CONFIG_RWSEM_SPIN_ON_WRITE_OWNER
+static inline void rwsem_set_owner(struct rw_semaphore *sem)
+{
+ sem->owner = current;
+}
+
+static inline void rwsem_clear_owner(struct rw_semaphore *sem)
+{
+ sem->owner = NULL;
+}
+#else
+static inline void rwsem_set_owner(struct rw_semaphore *sem)
+{
+}
+
+static inline void rwsem_clear_owner(struct rw_semaphore *sem)
+{
+}
+#endif
+
/*
* lock for reading
*/
@@ -48,6 +68,7 @@ void __sched down_write(struct rw_semaphore *sem)
rwsem_acquire(>dep_map, 0, 0, _RET_IP_);
LOCK_CONTENDED(sem, __down_write_trylock, __down_write);
+ rwsem_set_owner(sem);
}
EXPORT_SYMBOL(down_write);
@@ -59,8 +80,10 @@ int down_write_trylock(struct rw_semaphore *sem)
{
int ret = __down_write_trylock(sem);
- if (ret == 1)
+ if (ret == 1) {
rwsem_acquire(>dep_map, 0, 1, _RET_IP_);
+ rwsem_set_owner(sem);
+ }
return ret;
}
@@ -86,6 +109,7 @@ void up_write(struct rw_semaphore *sem)
rwsem_release(>dep_map, 1, _RET_IP_);
__up_write(sem);
+ rwsem_clear_owner(sem);
}
EXPORT_SYMBOL(up_write);
@@ -100,6 +124,7 @@ void downgrade_write(struct rw_semaphore *sem)
* dependency.
*/
__downgrade_write(sem);
+ rwsem_clear_owner(sem);
}
EXPORT_SYMBOL(downgrade_write);
@@ -122,6 +147,7 @@ void _down_write_nest_lock(struct rw_semaphore *sem, struct
lockdep_map *nest)
rwsem_acquire_nest(>dep_map, 0, 0, nest, _RET_IP_);
LOCK_CONTENDED(sem, __down_write_trylock, __down_write);
+ rwsem_set_owner(sem);
}
EXPORT_SYMBOL(_down_write_nest_lock);
@@ -141,6 +167,7 @@ void down_write_nested(struct rw_semaphore *sem, int
subclass)
rwsem_acquire(>dep_map, subclass, 0, _RET_IP_);
LOCK_CONTENDED(sem, __down_write_trylock, __down_write);
+ rwsem_set_owner(sem);
}
EXPORT_SYMBOL(down_write_nested);
diff --git a/lib/rwsem.c b/lib/rwsem.c
index 2072af5..8e331c5 100644
--- a/lib/rwsem.c
+++ b/lib/rwsem.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
@@ -27,6 +28,9 @@ void __init_rwsem(struct rw_semaphore *sem, const char *name,
sem->count = RWSEM_UNLOCKED_VALUE;
raw_spin_lock_init(>wait_lock);
INIT_LIST_HEAD(>wait_list);
+#ifdef CONFIG_RWSEM_SPIN_ON_WRITE_OWNER
+ sem->owner = NULL;
+#endif
}
[PATCH 1/2] rwsem: check the lock before cpmxchg in down_write_trylock and rwsem_do_wake
Doing cmpxchg will cause cache bouncing when checking
sem->count. This could cause scalability issue
in a large machine (e.g. a 80 cores box).
A pre-read of sem->count can mitigate this.
Signed-off-by: Alex Shi
Signed-off-by: Tim Chen
---
include/asm-generic/rwsem.h |8
lib/rwsem.c | 21 +
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/include/asm-generic/rwsem.h b/include/asm-generic/rwsem.h
index bb1e2cd..052d973 100644
--- a/include/asm-generic/rwsem.h
+++ b/include/asm-generic/rwsem.h
@@ -70,11 +70,11 @@ static inline void __down_write(struct rw_semaphore *sem)
static inline int __down_write_trylock(struct rw_semaphore *sem)
{
- long tmp;
+ if (unlikely(>count != RWSEM_UNLOCKED_VALUE))
+ return 0;
- tmp = cmpxchg(>count, RWSEM_UNLOCKED_VALUE,
- RWSEM_ACTIVE_WRITE_BIAS);
- return tmp == RWSEM_UNLOCKED_VALUE;
+ return cmpxchg(>count, RWSEM_UNLOCKED_VALUE,
+ RWSEM_ACTIVE_WRITE_BIAS) == RWSEM_UNLOCKED_VALUE;
}
/*
diff --git a/lib/rwsem.c b/lib/rwsem.c
index 19c5fa9..2072af5 100644
--- a/lib/rwsem.c
+++ b/lib/rwsem.c
@@ -75,7 +75,7 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
rwsem_wake_type wake_type)
* will block as they will notice the queued writer.
*/
wake_up_process(waiter->task);
- goto out;
+ return sem;
}
/* Writers might steal the lock before we grant it to the next reader.
@@ -85,15 +85,21 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
rwsem_wake_type wake_type)
adjustment = 0;
if (wake_type != RWSEM_WAKE_READ_OWNED) {
adjustment = RWSEM_ACTIVE_READ_BIAS;
- try_reader_grant:
- oldcount = rwsem_atomic_update(adjustment, sem) - adjustment;
- if (unlikely(oldcount < RWSEM_WAITING_BIAS)) {
- /* A writer stole the lock. Undo our reader grant. */
+ while (1) {
+ /* A writer stole the lock. */
+ if (sem->count < RWSEM_WAITING_BIAS)
+ return sem;
+
+ oldcount = rwsem_atomic_update(adjustment, sem)
+ - adjustment;
+ if (likely(oldcount >= RWSEM_WAITING_BIAS))
+ break;
+
+/* A writer stole the lock. Undo our reader grant. */
if (rwsem_atomic_update(-adjustment, sem) &
RWSEM_ACTIVE_MASK)
- goto out;
+ return sem;
/* Last active locker left. Retry waking readers. */
- goto try_reader_grant;
}
}
@@ -136,7 +142,6 @@ __rwsem_do_wake(struct rw_semaphore *sem, enum
rwsem_wake_type wake_type)
sem->wait_list.next = next;
next->prev = >wait_list;
- out:
return sem;
}
--
1.7.4.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 staging-next] zram: remove zram_sysfs file
On (06/21/13 15:10), Greg Kroah-Hartman wrote:
> > Move zram sysfs code to zram drv and remove zram_sysfs file.
> > This gives ability to make static a number of previously exported
> > zram functions, used from zram sysfs, e.g. internal zram
> > zram_meta_alloc/free(). We also can drop several zram_drv wrapper
> > functions, used from zram sysfs:
> > e.g. zram_reset_device()/__zram_reset_device() pair.
> >
> > Signed-off-by: Sergey Senozhatsky
> >
> > ---
> > drivers/staging/zram/Makefile | 2 +-
> > drivers/staging/zram/zram_drv.c | 524
> > +-
> > drivers/staging/zram/zram_drv.h | 10 -
> > drivers/staging/zram/zram_sysfs.c | 209 ---
> > 4 files changed, 354 insertions(+), 391 deletions(-)
> >
> > diff --git a/drivers/staging/zram/Makefile b/drivers/staging/zram/Makefile
> > index 7f4a301..cb0f9ce 100644
> > --- a/drivers/staging/zram/Makefile
> > +++ b/drivers/staging/zram/Makefile
> > @@ -1,3 +1,3 @@
> > -zram-y := zram_drv.o zram_sysfs.o
> > +zram-y := zram_drv.o
> >
> > obj-$(CONFIG_ZRAM) += zram.o
> > diff --git a/drivers/staging/zram/zram_drv.c
> > b/drivers/staging/zram/zram_drv.c
> > index ec2b2b5..f32fcca 100644
> > --- a/drivers/staging/zram/zram_drv.c
> > +++ b/drivers/staging/zram/zram_drv.c
> > @@ -42,6 +42,111 @@ static struct zram *zram_devices;
> > /* Module params (documentation at end) */
> > static unsigned int num_devices = 1;
> >
> > +module_param(num_devices, uint, 0);
> > +MODULE_PARM_DESC(num_devices, "Number of zram devices");
> > +
> > +MODULE_LICENSE("Dual BSD/GPL");
> > +MODULE_AUTHOR("Nitin Gupta ");
> > +MODULE_DESCRIPTION("Compressed RAM Block Device");
>
> This is usually best put at the bottom of the file, not at the top.
>
> Why did you move it?
>
Hello Greg,
That's a good question, thanks. I was pretty sure that such information
is usually put at the top of the file. At least what I saw (to name a
few)
arch/ia64/kernel/salinfo.c
drivers/ata/ata_piix.c
drivers/ata/ata_generic.c
drivers/ata/libata-core.c
[..]
MODULE_LICENSE and MODULE_AUTHOR are at the top. Of course I can move
it back to original place, will resend soon.
-ss
> thanks,
>
> greg k-h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] drivers/misc: rf/ad9361: AD9361 device driver for Radio phy
On 6/20/2013 4:05 PM, pankaj chauhan wrote: On 6/19/2013 6:27 PM, Lars-Peter Clausen wrote: On 06/17/2013 10:09 AM, akhil.go...@freescale.com wrote: From: Akhil Goyal AD9361 is a radio phy(RFIC) for radio networks. This phy can support LTE-FDD/LTE-TDD and WCDMA networks. The RFIC can convert the analog radio signals from air to digital IQ samples. AD9361 is controlled via an SPI bus and all the register read/ write can be performed via SPI transactions. Driver provides various operations for configuring and controlling the AD PHY. These can be controlled from the user space via the rfdev framework. Driver also binds itself to one of AIC lane using RF framework. The combination of AIC lane and PHY connected to it works as one RF device. Signed-off-by: Shaveta Leekha Signed-off-by: Pankaj Chauhan Signed-off-by: Bhaskar Upadhaya Signed-off-by: Akhil Goyal Hi, This is interesting. We at Analog Devices are currently also working on a driver for this part. We are using the Linux Industrial IO (IIO) framework though, since the AD9361 is more or less a multifunction device implementing different functions already covered by the IIO framework, like ADCs, DACs, clock chips and so on. Yes i agree AD9361 is more of a multifunction device and it can fit in IIO framework. This patch (ad9361: AD9361 device driver for Radio phy) implements: 1. Programming of AD9361 : Most of initialization is done by parsing Low level script generated by ADI tool, and sending the SPIwrite/read/wait calibration commands to the driver. This is more of a raw write interface to device. 2. Adding utility function APIs for higher layers: We have LTE/WCDMA stacks running in user space. They have requirement of monitoring RSSI, changing Attenuation, reading/changing Rx gain, disable/enable of tx/rx antennas, changing LO frequency etc. This patch exposes APIs which can be accessed through RF device layer user space interface (explained later in the email). 3. Control of Radio card (which has AD9361): We have radio card which contains AD9361 and there are different set of PA/LNAs (Power amplifier/Low Noise Amplifier). Each set caters a set of frequency bands. This patch also exports functions to enable/disable a Tx/Rx path (PA/LNAs) which are external to AD9361. May be we can spit this driver in two parts : 1. AD9361 driver: which covers #1 and #2 as mentioned as above. And this can be merged with the driver you have in IIO framework. 2. Radio card driver: which covers #3 and uses AD9361 driver's exported APIs to program AD9361 OR may be we can program AD9361 from user space using IIO interface. pls let me know what do you think is best approach. Lars pls suggest whether this split will work for both of us. You seem to have made the kernel layer as thin as possible and provide a IOCTL which allows userspace to directly modify the registers of the hardware. So this sentence from the documentation "user space interface is independent of component (vendor specific) drivers" is not exactly true. If you write a userspace application it will still only work with one specific RF-frontend. There is only a common interface on how to talk to the frontend. Your documentation on this is also a bit sparse, e.g. there is no explanation of the individual IOCTLs. Yes modifying registers from user space is part of the patch set and register read/write interface is aimed only for two purposes: 1. Debugging : taking register dumps etc. 2. Initializing AD9361 using Low level script generated by ADI GUI tool. I'll try to explain what we meant by 'independent of vendor specific drivers' and the framework itself. Following is the overview of hardware on which are running these drivers: 1. Antenna controller : This is part of SOC. The controller has multiple IQ data lanes. On the application core of SOC we run Linux. LTE/WCDMA stacks run in user space, and they interact with antenna controller and RFPHY. 2. Radio card: This contains one or more RF PHYS (AD9361). Each AD9361 is connected to Antenna controller IQ lane over JESD207 bus. With this patch set we aim to abstract combination of a IQ data lane and RF PHY as a 'radio device'. So this patch set is divided in three parts: 1. RF device layer : - Exposes IOCTLS to user space for device configuration. - Exposes registration APIs so that antenna controllers and PHYs so that they can register their control operations. antenna controller and RF PHYs don't interact with user space directly. - Maintains state of overall RF device. For example IQ data transfer starts only when both the controller and PHY are configured and ready. 2. Antenna controller driver: This configures the Antenna controller hardware. It registers its control functions as a ops structure (containing function pointers) with RF device layer. 3. RF PHY driver: This is AD9361 driver (in this patch set). This also registers with it ops
[PATCH v2] dmatest: masking tests for channel capabilities
The current dmatest module tests all the hardware capabilities (MEMCPY, XOR
and PQ) supported by a particular DMA channel and these tests are performed
concurrently by default. This patch allows the user to enable or disable the
test performed for any particular capability. The mask bits for enabling the
tests are set using the debugfs.
Signed-off-by: Jubin Mehta
---
Documentation/dmatest.txt | 33
drivers/dma/dmatest.c | 92 +++--
2 files changed, 122 insertions(+), 3 deletions(-)
diff --git a/Documentation/dmatest.txt b/Documentation/dmatest.txt
index 279ac0a..d092646 100644
--- a/Documentation/dmatest.txt
+++ b/Documentation/dmatest.txt
@@ -79,3 +79,36 @@ Comparison between buffers is stored to the dedicated
structure.
Note that the verify result is now accessible only via file 'results' in the
debugfs.
+
+ Part 5 - Masking tests for channel capabilities
+
+By default, the dmatest module concurrently tests all the hardware capabilities
+(MEMCPY, XOR and PQ) supported by a particular DMA channel. In order to disable
+any capability/capabilities from being tested, the user needs to modify the
+file 'cap_mask' in debugfs.
+
+Method to enable the capabilities:
+
+PATH = /sys/kernel/debug/dmatest/cap_mask
+echo copy,xor,pq > $PATH # Enables all the capability tests (DEFAULT)
+echo xor > $PATH # Enables XOR capability test
+
+Note: No whitespaces between the capabilities.
+ Only COMMA (,) to be used for separation.
+
+Example to perform only MEMCPY and PQ mode tests:
+
+ % modprobe dmatest
+ % echo dma0chan0 > /sys/kernel/debug/dmatest/channel
+ % echo copy,pq > /sys/kernel/debug/dmatest/cap_mask
+ % echo 1 > /sys/kernel/debug/dmatest/iterations
+ % echo 1 > /sys/kernel/debug/dmatest/run
+
+ Output:
+ % cat /sys/kernel/debug/dmatest/results
+
+ dma0chan0-copy0: #1: No errors with src_off=0xXX dst_off=0xXX len=0xXX
+ dma0chan0-pq0: #1: No errors with src_off=0xXX dst_off=0xXX len=0xXX
+
+Note: The result is available only for the enabled capabilities of
+ particular channel.
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index d8ce4ec..c152755 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
static unsigned int test_buf_size = 16384;
module_param(test_buf_size, uint, S_IRUGO);
@@ -66,6 +67,11 @@ module_param(timeout, uint, S_IRUGO);
MODULE_PARM_DESC(timeout, "Transfer Timeout in msec (default: 3000), "
"Pass -1 for infinite timeout");
+static char test_cap_mask[20] = "copy,xor,pq";
+module_param_string(cap_mask, test_cap_mask, sizeof(test_cap_mask), S_IRUGO);
+MODULE_PARM_DESC(cap_mask, "Mask bits for different capability test "
+"(default: copy,xor,pq)");
+
/* Maximum amount of mismatched bytes in buffer to print */
#define MAX_ERROR_COUNT32
@@ -164,6 +170,7 @@ struct dmatest_chan {
* @xor_sources: number of xor source buffers
* @pq_sources:number of p+q source buffers
* @timeout: transfer timeout in msec, -1 for infinite timeout
+ * @cap_mask: mask for different hardware capabilities tests
*/
struct dmatest_params {
unsigned intbuf_size;
@@ -175,6 +182,7 @@ struct dmatest_params {
unsigned intxor_sources;
unsigned intpq_sources;
int timeout;
+ charcap_mask[128];
};
/**
@@ -883,11 +891,44 @@ static int dmatest_add_threads(struct dmatest_info *info,
return i;
}
+static int dmatest_cap_check(struct dmatest_info *info,
+ dma_cap_mask_t *test_cap_mask)
+{
+ struct dmatest_params *params;
+ char*cap;
+ unsigned char c;
+ int i;
+
+ params = >params;
+ cap = (params->cap_mask);
+
+ for (i = 0; i < 3; i++) {
+ if (!strncmp(cap, "copy", 4)) {
+ dma_cap_set(DMA_MEMCPY, *test_cap_mask);
+ cap += 4;
+ } else if (!strncmp(cap, "xor", 3)) {
+ dma_cap_set(DMA_XOR, *test_cap_mask);
+ cap += 3;
+ } else if (!strncmp(cap, "pq", 2)) {
+ dma_cap_set(DMA_PQ, *test_cap_mask);
+ cap += 2;
+ } else {
+ return -1;
+ }
+ c = *cap++;
+ if (c != ',')
+ break;
+ }
+ return 0;
+}
+
static int dmatest_add_channel(struct dmatest_info *info,
struct dma_chan *chan)
{
struct dmatest_chan *dtc;
struct dma_device *dma_dev = chan->device;
+ struct dmatest_params *params;
+ dma_cap_mask_t test_cap_mask;
unsigned intthread_count = 0;
int cnt;
@@
RFC: named anonymous vmas
One of the features of ashmem (drivers/staging/android/ashmem.c) that hasn't gotten much discussion about moving out of staging is named anonymous memory. In Android, ashmem is used for three different features, and most users of it only care about one feature at a time. One is volatile ranges, which John Stultz has been implementing. The second is anonymous shareable memory without having a world-writable tmpfs that untrusted apps could fill with files. The third and most heavily used feature within the Android codebase is named anonymous memory, where a region of anonymous memory can have a name associated with it that will show up in /proc/pid/maps. The Dalvik VM likes to use this feature extensively, even for memory that will never be shared and could easily be allocated using an anonymous mmap, and even malloc has used it in the past. It provides an easy way to collate memory used for different purposes across multiple processes, which Android uses for its "dumpsys meminfo" and "librank" tools to determine how much memory is used for java heaps, JIT caches, native mallocs, etc. I'd like to add this feature for anonymous mmap memory. I propose adding an madvise2(unsigned long start, size_t len_in, int behavior, void *ptr, size_t size) syscall and a new MADV_NAME behavior, which treats ptr as a string of length size. The string would be copied somewhere reusable in the kernel, or reused if it already exists, and the kernel address of the string would get stashed in a new field in struct vm_area_struct. Adjacent vmas would only get merged if the name pointer matched, and naming part of a mapping would split the mapping. show_map_vma would print the name only if none of the other existing names rules match. Any comments as I start implementing it? Is there any reason to allow naming a file-backed mapping and showing it alongside the file name in /proc/pid/maps? -- 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] pinctrl: establish pull-up/pull-down terminology
Am Samstag, 22. Juni 2013, 01:30:18 schrieb Laurent Pinchart: > Hi Stephen, > > On Friday 21 June 2013 13:06:47 Stephen Warren wrote: > > On 06/20/2013 06:38 AM, James Hogan wrote: > > > On 19/06/13 23:03, Stephen Warren wrote: > > >> On 06/16/2013 04:45 AM, Linus Walleij wrote: > > >>> From: Linus Walleij > > >>> > > >>> It is counter-intuitive to have "0" mean disable in a boolean > > >>> manner for electronic properties of pins such as pull-up and > > >>> pull-down. Therefore, define that a pull-up/pull-down argument > > >>> of 0 to such a generic option means that the pin is > > >>> short-circuited to VDD or GROUND. Pull disablement shall be > > >>> done using PIN_CONFIG_BIAS_DISABLE. > > >>> > > >>> Cc: Heiko St�bner > > >>> Cc: James Hogan > > >>> Cc: Laurent Pinchart > > >>> Signed-off-by: Linus Walleij > > >>> --- > > >>> > > >>> include/linux/pinctrl/pinconf-generic.h | 13 +++-- > > >>> 1 file changed, 7 insertions(+), 6 deletions(-) > > >>> > > >>> diff --git a/include/linux/pinctrl/pinconf-generic.h > > >>> b/include/linux/pinctrl/pinconf-generic.h index d414a77..67780f5 > > >>> 100644 --- a/include/linux/pinctrl/pinconf-generic.h > > >>> +++ b/include/linux/pinctrl/pinconf-generic.h > > >>> @@ -36,14 +36,15 @@ > > >>> > > >>> * tristate. The argument is ignored. > > >>> * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with > > >>> high > > >>> * impedance to VDD). If the argument is != 0 pull-up is enabled, > > >>> > > >>> - * if it is 0, pull-up is disabled. > > >>> + * if it is 0, pull-up it total, i.e. the pin is connected to VDD. > > >>> > > >>> * @PIN_CONFIG_BIAS_PULL_DOWN: the pin will be pulled down (usually > > >>> with high * impedance to GROUND). If the argument is != 0 pull-down > > >>> is enabled,>>> > > >>> > > >>> - * if it is 0, pull-down is disabled. > > >>> + * if it is 0, pull-down is total, i.e. the pin is connected to > > >>> GROUND. > > >>> > > >>> * @PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: the pin will be pulled up or > > >>> down based * on embedded knowledge of the controller, like current > > >>> mux function.>>> > > >>> > > >>> - * If the argument is != 0 pull up/down is enabled, if it is 0, > > >>> - * the pull is disabled. > > >>> + * If the argument is != 0 pull up/down is enabled, if it is 0, the > > >>> + * configuration is ignored. The proper way to disable it is to use > > >>> + * @PIN_CONFIG_BIAS_DISABLE. > > >> > > >> Why treat PULL_UP/PULL_DOWN differently from PULL_PIN_DEFAULT? > > >> PULL_PIN_DEFAULT is logically simply a macro that selects PULL_UP/DOWN > > >> based on what's "normal" for the pin's expected usage, so surely the > > >> value associated with that option should behave identically? > > > > > > I'm not familiar with hardware that does this so I could be way wrong > > > here, but presumably if there's a default up/down, there's probably a > > > default resistance too. Does it really make sense to say > > > "pull up or down depending on whatever the pin is intended for... but > > > whichever it is must be XXX Ohm"? > > > If you know the resistance you want, you surely already know whether > > > you want it pull up or down with that resistence. > > > > IIRC the idea of the PULL_PIN_DEFAULT was to avoid having to specify > > UP/DOWN for each pin/group, but could just say "default", which would > > then reduce the number of pinctrl mapping table entries or pinctrl DT > > property entries. > > I may be mistaken, but I've understood the PULL_PIN_DEFAULT option as a way > to select the default bias configuration when the default value is > hardware- controlled, not as a pure software option. Yep that was the original intent ... to handle hardware that hides the complete logic from the software and you only get to turn it on or off, while the direction and other params are determined internally for example by the pin function. > > > I don't think this would have any interaction with setting the > > resistance; it's entirely plausible that you'd want the same explicit, > > or same default, resistance, for all pins, irrespective of pull-up vs. > > down. -- 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] pinctrl: establish pull-up/pull-down terminology
Hi Stephen, On Friday 21 June 2013 13:06:47 Stephen Warren wrote: > On 06/20/2013 06:38 AM, James Hogan wrote: > > On 19/06/13 23:03, Stephen Warren wrote: > >> On 06/16/2013 04:45 AM, Linus Walleij wrote: > >>> From: Linus Walleij > >>> > >>> It is counter-intuitive to have "0" mean disable in a boolean > >>> manner for electronic properties of pins such as pull-up and > >>> pull-down. Therefore, define that a pull-up/pull-down argument > >>> of 0 to such a generic option means that the pin is > >>> short-circuited to VDD or GROUND. Pull disablement shall be > >>> done using PIN_CONFIG_BIAS_DISABLE. > >>> > >>> Cc: Heiko St�bner > >>> Cc: James Hogan > >>> Cc: Laurent Pinchart > >>> Signed-off-by: Linus Walleij > >>> --- > >>> > >>> include/linux/pinctrl/pinconf-generic.h | 13 +++-- > >>> 1 file changed, 7 insertions(+), 6 deletions(-) > >>> > >>> diff --git a/include/linux/pinctrl/pinconf-generic.h > >>> b/include/linux/pinctrl/pinconf-generic.h index d414a77..67780f5 100644 > >>> --- a/include/linux/pinctrl/pinconf-generic.h > >>> +++ b/include/linux/pinctrl/pinconf-generic.h > >>> @@ -36,14 +36,15 @@ > >>> > >>> * tristate. The argument is ignored. > >>> * @PIN_CONFIG_BIAS_PULL_UP: the pin will be pulled up (usually with > >>> high > >>> * impedance to VDD). If the argument is != 0 pull-up is enabled, > >>> > >>> - * if it is 0, pull-up is disabled. > >>> + * if it is 0, pull-up it total, i.e. the pin is connected to VDD. > >>> > >>> * @PIN_CONFIG_BIAS_PULL_DOWN: the pin will be pulled down (usually > >>> with high * impedance to GROUND). If the argument is != 0 pull-down > >>> is enabled,>>> > >>> - * if it is 0, pull-down is disabled. > >>> + * if it is 0, pull-down is total, i.e. the pin is connected to > >>> GROUND. > >>> > >>> * @PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: the pin will be pulled up or down > >>> based * on embedded knowledge of the controller, like current mux > >>> function.>>> > >>> - * If the argument is != 0 pull up/down is enabled, if it is 0, > >>> - * the pull is disabled. > >>> + * If the argument is != 0 pull up/down is enabled, if it is 0, the > >>> + * configuration is ignored. The proper way to disable it is to use > >>> + * @PIN_CONFIG_BIAS_DISABLE. > >> > >> Why treat PULL_UP/PULL_DOWN differently from PULL_PIN_DEFAULT? > >> PULL_PIN_DEFAULT is logically simply a macro that selects PULL_UP/DOWN > >> based on what's "normal" for the pin's expected usage, so surely the > >> value associated with that option should behave identically? > > > > I'm not familiar with hardware that does this so I could be way wrong > > here, but presumably if there's a default up/down, there's probably a > > default resistance too. Does it really make sense to say > > "pull up or down depending on whatever the pin is intended for... but > > whichever it is must be XXX Ohm"? > > If you know the resistance you want, you surely already know whether you > > want it pull up or down with that resistence. > > IIRC the idea of the PULL_PIN_DEFAULT was to avoid having to specify > UP/DOWN for each pin/group, but could just say "default", which would > then reduce the number of pinctrl mapping table entries or pinctrl DT > property entries. I may be mistaken, but I've understood the PULL_PIN_DEFAULT option as a way to select the default bias configuration when the default value is hardware- controlled, not as a pure software option. > I don't think this would have any interaction with setting the resistance; > it's entirely plausible that you'd want the same explicit, or same default, > resistance, for all pins, irrespective of pull-up vs. down. -- 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: linux-next: Tree for Jun 21 (netdev: openvswitch)
On Fri, Jun 21, 2013 at 8:22 AM, Randy Dunlap wrote: > On 06/21/13 01:17, Stephen Rothwell wrote: >> Hi all, >> >> Happy solstice! >> >> Changes since 20130620: >> > > when CONFIG_INET is not enabled: > > CC net/openvswitch/flow.o > In file included from net/openvswitch/flow.c:43:0: > include/net/ip_tunnels.h: In function 'tunnel_ip_select_ident': > include/net/ip_tunnels.h:155:3: error: implicit declaration of function > '__ip_select_ident' [-Werror=implicit-function-declaration] Thanks, I just sent out a couple of patches to fix config issues with the recent tunneling series. -- 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: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]
On Sat, Jun 22, 2013 at 12:54 AM, Sedat Dilek wrote: > On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso > wrote: >> On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote: >>> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell >>> wrote: >>> > Hi all, >>> > >>> > Happy solstice! >>> > >>> > Changes since 20130620: >>> > >>> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree) >>> > >>> > The net-next tree gained a conflict against the net tree. >>> > >>> > The leds tree still had its build failure, so I used the version from >>> > next-20130607. >>> > >>> > The arm-soc tree gained conflicts against the tip, net-next, mfd and >>> > mailbox trees. >>> > >>> > The staging tree still had its build failure for which I disabled some >>> > code. >>> > >>> > The akpm tree lost a few patches that turned up elsewhere and gained >>> > conflicts against the ftrace and arm-soc trees. >>> > >>> > >>> > >>> >>> [ CC IPC folks ] >>> >>> Building via 'make deb-pkg' with fakeroot fails here like this: >>> >>> make: *** [deb-pkg] Terminated >>> /usr/bin/fakeroot: line 181: 2386 Terminated >>> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" >>> "$@" >>> semop(1): encountered an error: Identifier removed >>> semop(2): encountered an error: Invalid argument >>> semop(1): encountered an error: Identifier removed >>> semop(1): encountered an error: Identifier removed >>> semop(1): encountered an error: Invalid argument >>> semop(1): encountered an error: Invalid argument >>> semop(1): encountered an error: Invalid argument >>> >> >> Hmmm those really shouldn't be related to the message queue changes. Are >> you sure you got the right bisect? >> >> Manfred has a few ipc/sem.c patches in linux-next, starting at commit >> c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does >> reverting any of those instead of "ipc,msg: shorten critical region in >> msgrcv" help at all? Also, anything reported in dmesg? >> > > First, I reverted all IPC patches from akpm-tree within -next. > Then, I isolated the culprit by git-bisecting. > As I checked my logs I did not see anything helpful. > >>> The issue is present since next-20130606! >>> >>> LAST KNOWN GOOD: next-20130605 >>> FIRST KNOWN BAD: next-20130606 >>> >>> KNOWN GOOD: next-20130604 >>> KNOWN BAD: next-20130607 || next-20130619 || next-20130620 || next-20130621 >>> >>> git-bisect says CULPRIT commit is... >>> >>> "ipc,msg: shorten critical region in msgrcv" >> >> This I get. I went through the code again and it looks correct and >> functionally equivalent to the old msgrcv. >> > > Hmm, I guess a rcu_read_unlock() is missing? > > [ next-20130605 ] > ... > /* Lockless receive, part 3: > * Acquire the queue spinlock. > */ > ipc_lock_by_ptr(>q_perm); > rcu_read_unlock(); > ... > [ next-20130621 ] > ... > /* Lockless receive, part 3: > * Acquire the queue spinlock. > */ > ipc_lock_object(>q_perm); > ... > > Whereas ipc_lock_by_ptr() is equivalent to: > rcu_read_lock(); > ipc_lock_object(); > >>> >>> NOTE: msg_lock_(check_) routines have to be restored (one more revert >>> needed)! >> >> This I don't get. Restoring msg_lock_[check] is already equivalent to >> reverting "ipc,msg: shorten critical region in msgrcv" and several other >> of the msq patches. What other patch needs reverted? >> > > No, you have to revert both patches as the other removed > msg_lock_[check] afterwards. > >> Anyway, I'll see if I can reproduce the issue, maybe I'm missing >> something. >> > > Yupp, I try with adding rcu_read_unlock()... and report. > > - Sedat - > >> Thanks, >> Davidlohr >> >>> >>> Reverting both (below) commits makes fakeroot build via 'make dep-pkg" >>> again. >>> >>> I have tested the revert-patches with next-20130606 and next-20130621 >>>
Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]
On Sat, Jun 22, 2013 at 1:11 AM, Davidlohr Bueso wrote: > On Sat, 2013-06-22 at 00:54 +0200, Sedat Dilek wrote: >> On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso >> wrote: >> > On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote: >> >> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell >> >> wrote: >> >> > Hi all, >> >> > >> >> > Happy solstice! >> >> > >> >> > Changes since 20130620: >> >> > >> >> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree) >> >> > >> >> > The net-next tree gained a conflict against the net tree. >> >> > >> >> > The leds tree still had its build failure, so I used the version from >> >> > next-20130607. >> >> > >> >> > The arm-soc tree gained conflicts against the tip, net-next, mfd and >> >> > mailbox trees. >> >> > >> >> > The staging tree still had its build failure for which I disabled some >> >> > code. >> >> > >> >> > The akpm tree lost a few patches that turned up elsewhere and gained >> >> > conflicts against the ftrace and arm-soc trees. >> >> > >> >> > >> >> > >> >> >> >> [ CC IPC folks ] >> >> >> >> Building via 'make deb-pkg' with fakeroot fails here like this: >> >> >> >> make: *** [deb-pkg] Terminated >> >> /usr/bin/fakeroot: line 181: 2386 Terminated >> >> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" >> >> "$@" >> >> semop(1): encountered an error: Identifier removed >> >> semop(2): encountered an error: Invalid argument >> >> semop(1): encountered an error: Identifier removed >> >> semop(1): encountered an error: Identifier removed >> >> semop(1): encountered an error: Invalid argument >> >> semop(1): encountered an error: Invalid argument >> >> semop(1): encountered an error: Invalid argument >> >> >> > >> > Hmmm those really shouldn't be related to the message queue changes. Are >> > you sure you got the right bisect? >> > >> > Manfred has a few ipc/sem.c patches in linux-next, starting at commit >> > c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does >> > reverting any of those instead of "ipc,msg: shorten critical region in >> > msgrcv" help at all? Also, anything reported in dmesg? >> > >> >> First, I reverted all IPC patches from akpm-tree within -next. >> Then, I isolated the culprit by git-bisecting. >> As I checked my logs I did not see anything helpful. >> >> >> The issue is present since next-20130606! >> >> >> >> LAST KNOWN GOOD: next-20130605 >> >> FIRST KNOWN BAD: next-20130606 >> >> >> >> KNOWN GOOD: next-20130604 >> >> KNOWN BAD: next-20130607 || next-20130619 || next-20130620 || >> >> next-20130621 >> >> >> >> git-bisect says CULPRIT commit is... >> >> >> >> "ipc,msg: shorten critical region in msgrcv" >> > >> > This I get. I went through the code again and it looks correct and >> > functionally equivalent to the old msgrcv. >> > >> >> Hmm, I guess a rcu_read_unlock() is missing? >> >> [ next-20130605 ] >> ... >> /* Lockless receive, part 3: >>* Acquire the queue spinlock. >>*/ >> ipc_lock_by_ptr(>q_perm); >> rcu_read_unlock(); >> ... >> [ next-20130621 ] >> ... >> /* Lockless receive, part 3: >>* Acquire the queue spinlock. >>*/ >> ipc_lock_object(>q_perm); >> ... >> >> Whereas ipc_lock_by_ptr() is equivalent to: >> rcu_read_lock(); >> ipc_lock_object(); > > Yeah, I noticed that, but it's not an error. In the older code we have > > rcu_read_lock (Lockless receive, part 1) > [...] > /* Lockless receive, part 3: > * Acquire the queue spinlock. > */ > ipc_lock_by_ptr(>q_perm); > rcu_read_unlock(); > > > Which translates to: > rcu_read_lock (Lockless receive, part 1) > [...] > /* Lockless receive, part 3: > * Acquire the queue spinlo
Re: [PATCHv3/RESEND 4/4] clocksource: arch_timer: Add support for memory mapped timers
On Fri, 21 Jun 2013, Stephen Boyd wrote:
> On 06/21/13 14:18, Thomas Gleixner wrote:
> > Something in my little brain yells: function pointer
> >
> > You can't be serious about hacking nested if/else/switch constructs
> > into a hot path.
> >
> > Why not making your cpu data:
> >
> > struct arch_timer {
> >struct clock_event_device evt;
> >
> >void (*write_ctrl)(val, timer);
> >void (*write_tval)(val, timer);
> >
> > }
> >
> > and get rid of all that conditionals?
>
> It sounds like that's undesirable according to the comment above
> arch_timer_reg_write(). It seems that all this code was written under
> the assumption that the compiler is good enough to optimize all the code
> paths and only generate the code that is necessary. So far this seems to
> be working and the hotpath is optimized for each type of access.
That might be true for kernels which are optimized for a specific
target, but this will fall flat for any multi-platform kernel.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]
On Sat, 2013-06-22 at 00:54 +0200, Sedat Dilek wrote: > On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso > wrote: > > On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote: > >> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell > >> wrote: > >> > Hi all, > >> > > >> > Happy solstice! > >> > > >> > Changes since 20130620: > >> > > >> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree) > >> > > >> > The net-next tree gained a conflict against the net tree. > >> > > >> > The leds tree still had its build failure, so I used the version from > >> > next-20130607. > >> > > >> > The arm-soc tree gained conflicts against the tip, net-next, mfd and > >> > mailbox trees. > >> > > >> > The staging tree still had its build failure for which I disabled some > >> > code. > >> > > >> > The akpm tree lost a few patches that turned up elsewhere and gained > >> > conflicts against the ftrace and arm-soc trees. > >> > > >> > > >> > > >> > >> [ CC IPC folks ] > >> > >> Building via 'make deb-pkg' with fakeroot fails here like this: > >> > >> make: *** [deb-pkg] Terminated > >> /usr/bin/fakeroot: line 181: 2386 Terminated > >> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" > >> "$@" > >> semop(1): encountered an error: Identifier removed > >> semop(2): encountered an error: Invalid argument > >> semop(1): encountered an error: Identifier removed > >> semop(1): encountered an error: Identifier removed > >> semop(1): encountered an error: Invalid argument > >> semop(1): encountered an error: Invalid argument > >> semop(1): encountered an error: Invalid argument > >> > > > > Hmmm those really shouldn't be related to the message queue changes. Are > > you sure you got the right bisect? > > > > Manfred has a few ipc/sem.c patches in linux-next, starting at commit > > c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does > > reverting any of those instead of "ipc,msg: shorten critical region in > > msgrcv" help at all? Also, anything reported in dmesg? > > > > First, I reverted all IPC patches from akpm-tree within -next. > Then, I isolated the culprit by git-bisecting. > As I checked my logs I did not see anything helpful. > > >> The issue is present since next-20130606! > >> > >> LAST KNOWN GOOD: next-20130605 > >> FIRST KNOWN BAD: next-20130606 > >> > >> KNOWN GOOD: next-20130604 > >> KNOWN BAD: next-20130607 || next-20130619 || next-20130620 || > >> next-20130621 > >> > >> git-bisect says CULPRIT commit is... > >> > >> "ipc,msg: shorten critical region in msgrcv" > > > > This I get. I went through the code again and it looks correct and > > functionally equivalent to the old msgrcv. > > > > Hmm, I guess a rcu_read_unlock() is missing? > > [ next-20130605 ] > ... > /* Lockless receive, part 3: >* Acquire the queue spinlock. >*/ > ipc_lock_by_ptr(>q_perm); > rcu_read_unlock(); > ... > [ next-20130621 ] > ... > /* Lockless receive, part 3: >* Acquire the queue spinlock. >*/ > ipc_lock_object(>q_perm); > ... > > Whereas ipc_lock_by_ptr() is equivalent to: > rcu_read_lock(); > ipc_lock_object(); Yeah, I noticed that, but it's not an error. In the older code we have rcu_read_lock (Lockless receive, part 1) [...] /* Lockless receive, part 3: * Acquire the queue spinlock. */ ipc_lock_by_ptr(>q_perm); rcu_read_unlock(); Which translates to: rcu_read_lock (Lockless receive, part 1) [...] /* Lockless receive, part 3: * Acquire the queue spinlock. */ rcu_read_lock(); ipc_lock_object(); rcu_read_unlock(); And thus, after that last rcu_read_unlock we are left with rcu_read_lock() ipc_lock_object(); If you notice, that's exactly what is done in the new code, only much more readable: We do rcu_read_lock in the part 1, then in part 3, we acquire the spinlock via ipc_lock_object(>q_perm) > >> > >> NOTE: msg_lock_(check_) routines have to be restored (one more revert > >> needed)! > > > > This I don't get. Restoring msg_loc
Re: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Wed, 19 Jun 2013 15:53:15 -0700, Greg KH writes:
>I think you forgot a Subject :)
Indeed. I blame it on my first fight with git format-patch ;-)
>On Wed, Jun 19, 2013 at 02:05:07AM +0200, Anders Hammarquist wrote:
>> This patch set adds the product id to the driver, and makes the
>> product type more explicit. Arguably, the ABBOTT_PRODUCT_ID
>> define could be removed, but I left it on the off chance that
>> someone other that the TI 3410 driver uses it.
>
>No, it doesn't, please fix up that last patch and resend it.
Right, and in removing it I actually found that it was used in
two places in the driver. I lost my second fight with format-patch
so I'll just enclose the fixed patch below.
/Anders
---8<---
ti_usb_3410_5052:
* Remove unspecific ABBOTT_PRODUCT_ID
* Fix size of statically sized arrays
Signed-off-by: Anders Hammarquist
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index e581c25..26c1161 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -158,7 +158,7 @@ static unsigned int product_5052_count;
/* the array dimension is the number of default entries plus */
/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
/* null entry */
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -172,8 +172,8 @@ static struct usb_device_id
ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
};
@@ -184,7 +184,7 @@ static struct usb_device_id
ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
};
-static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id
ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -202,7 +202,8 @@ static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1]
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
{ }
};
diff --git a/drivers/usb/serial/ti_usb_3410_5052.h
b/drivers/usb/serial/ti_usb_3410_5052.h
index 4a2423e..d3ff470 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.h
+++ b/drivers/usb/serial/ti_usb_3410_5052.h
@@ -52,9 +52,8 @@
/* Abbott Diabetics vendor and product ids */
#define ABBOTT_VENDOR_ID 0x1a61
-#define ABBOTT_STEREO_PLUG_ID 0x3410
-#define ABBOTT_PRODUCT_ID ABBOTT_STEREO_PLUG_ID
-#define ABBOTT_STRIP_PORT_ID 0x3420
+#define ABBOTT_STEREO_PLUG_PRODUCT_ID 0x3410
+#define ABBOTT_STRIP_PORT_PRODUCT_ID 0x3420
/* Commands */
#define TI_GET_VERSION 0x01
--
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/4] time: add a notifier chain for when the system time is stepped
On Fri, 21 Jun 2013, David Vrabel wrote: > On 21/06/13 08:57, Thomas Gleixner wrote: > > On Thu, 20 Jun 2013, David Vrabel wrote: > > > >> From: David Vrabel > >> > >> The high resolution timer code gets notified of step changes to the > >> system time with clock_was_set() or clock_was_set_delayed() calls. If > >> other parts of the kernel require similar notification there is no > >> clear place to hook into. > > > > You fail to explain why any other part of the kernel requires a > > notification. > > This is needed by patch 3 in this series. > > "The Xen wallclock is a software only clock within the Xen hypervisor > that is used by: a) PV guests as the equivalent of a hardware RTC; and > b) the hypervisor as the clock source for the emulated RTC provided to > HVM guests. > > Currently the Xen wallclock is only updated every 11 minutes if NTP is > synchronized to its clock source. If a guest is started before NTP is > synchronized it may see an incorrect wallclock time. What you are saying is, that you are fixing Xens failure to implement a proper RTC emulation by hacking a notifier into the core code. You can't be serious about that. According to your changelog: Currently the Xen wallclock is only updated every 11 minutes if NTP is synchronized to its clocksource. How is that related to clock_was_set() ? clock_was_set*() is invoked from: do_settimeofday() timekeeping_inject_offset() timekeeping_set_tai_offset() timekeeping_inject_sleeptime() update_wall_time() do_adjtimex() The only function which calls clock_was_set() and can affect RTC is do_adjtimex(). Though you claim that the natural place to add a notifier is clock_was_set(). So you went the other way round this time. In the hrtimers case you tried to fix shortcomings of the core code in some random Xen code. With this patch you try to fix Xen nonsense in the core code. Can you please provide a proper explanation of the problem you are trying to solve? This means that you should explain the semantics of the desired XEN RTC emulation and not the desired workarounds to fix the shortcommings current implementation. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3/RESEND 4/4] clocksource: arch_timer: Add support for memory mapped timers
On 06/21/13 14:18, Thomas Gleixner wrote:
> On Fri, 21 Jun 2013, Stephen Boyd wrote:
>> /*
>> * Architected system timer support.
>> @@ -46,13 +73,69 @@ static bool arch_timer_use_virtual = true;
>> static inline void arch_timer_reg_write(int access, int reg, u32 val,
>> struct clock_event_device *clk)
>> {
>> -arch_timer_reg_write_cp15(access, reg, val);
>> +if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
>> +struct arch_timer *timer = to_arch_timer(clk);
>> +switch (reg) {
>> +case ARCH_TIMER_REG_CTRL:
>> +writel_relaxed(val, timer->base + CNTP_CTL);
>> +break;
>> +case ARCH_TIMER_REG_TVAL:
>> +writel_relaxed(val, timer->base + CNTP_TVAL);
>> +break;
>> +default:
>> +BUILD_BUG();
> So you are relying on the compiler cleverness to identify a caller
> which calls that inline with a not supported reg value.
>
> How does that work, when the compiler decides not to inline that?
>
> enum without a default case emits at least a reliable warning.
Right now arm and arm64 don't allow inline to be anything besides
always_inline so the compiler is forced to inline. But point taken, I'll
remove the BUILD_BUG and make the register argument into an enum (which
it isn't right now).
>
>> +}
>> +} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
>> +struct arch_timer *timer = to_arch_timer(clk);
>> +switch (reg) {
>> +case ARCH_TIMER_REG_CTRL:
>> +writel_relaxed(val, timer->base + CNTV_CTL);
>> +break;
>> +case ARCH_TIMER_REG_TVAL:
>> +writel_relaxed(val, timer->base + CNTV_TVAL);
>> +break;
>> +default:
>> +BUILD_BUG();
>> +}
>> +} else {
>> +arch_timer_reg_write_cp15(access, reg, val);
>> +}
>> }
> Something in my little brain yells: function pointer
>
> You can't be serious about hacking nested if/else/switch constructs
> into a hot path.
>
> Why not making your cpu data:
>
> struct arch_timer {
>struct clock_event_device evt;
>
>void (*write_ctrl)(val, timer);
>void (*write_tval)(val, timer);
>
> }
>
> and get rid of all that conditionals?
It sounds like that's undesirable according to the comment above
arch_timer_reg_write(). It seems that all this code was written under
the assumption that the compiler is good enough to optimize all the code
paths and only generate the code that is necessary. So far this seems to
be working and the hotpath is optimized for each type of access.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: msm: Add support for MSM8974
On 06/21, Rohit Vaswani wrote:
> diff --git a/arch/arm/boot/dts/msm8974.dts b/arch/arm/boot/dts/msm8974.dts
> new file mode 100644
> index 000..d9c10d4
> --- /dev/null
> +++ b/arch/arm/boot/dts/msm8974.dts
> @@ -0,0 +1,23 @@
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "Qualcomm MSM8974";
> + compatible = "qcom,msm8974";
> + interrupt-parent = <>;
> +
> + intc: interrupt-controller@f900 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = < 0xf900 0x1000 >,
> + < 0xf9002000 0x1000 >;
> + };
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <1 2 0 1 3 0>;
> + clock-frequency = <1920>;
> + };
Please specify all the interrupts similar to how the binding
says to.
<1 2 0>,
<1 3 0>,
<1 4 0>,
<1 5 0>;
Also, add irq flags?
> +};
> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> index 614e41e..580e89b 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
> @@ -46,7 +46,6 @@ config ARCH_MSM8X60
> bool "MSM8X60"
> select ARM_GIC
> select CPU_V7
> - select GPIO_MSM_V2
> select HAVE_SMP
> select MSM_SCM if SMP
> select USE_OF
Looks unrelated. Can you drop this?
> @@ -60,14 +59,37 @@ config ARCH_MSM8960
> select MSM_SCM if SMP
> select USE_OF
>
> +config ARCH_MSM8974
> + bool "MSM8974"
> + select ARCH_MSM_KRAITMP
> + select ARM_GIC
> + select CPU_V7
> + select HAVE_ARM_ARCH_TIMER
> + select USE_OF
> + select MSM_SCM if SMP
Please sort these selects alphabetically.
> +
> +config ARCH_MSM_DT
> + def_bool y
> + depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
> +
> config MSM_HAS_DEBUG_UART_HS
> bool
>
> config MSM_SOC_REV_A
> bool
>
> +config ARCH_MSM_KRAIT
> + bool
> + select ARM_L1_CACHE_SHIFT_6
This is the default for CPU_V7 and so is unnnecessary.
> +
> +config ARCH_MSM_KRAITMP
> + select ARCH_MSM_KRAIT
> + select HAVE_SMP
> + bool
And this is not doing much besides enabling SMP. So I would just
drop this for now or merge it with the 8974 kconfig.
> diff --git a/arch/arm/mach-msm/board-dt-8974.c
> b/arch/arm/mach-msm/board-dt-8974.c
> +#include
> +#include
These two aren't needed?
> +#include
> +
> +static const char * const msm8974_dt_match[] __initconst = {
> + "qcom,msm8974",
> + NULL
> +};
> +
> +DT_MACHINE_START(MSM8974_DT, "Qualcomm MSM (Flattened Device Tree)")
> + .dt_compat = msm8974_dt_match,
> +MACHINE_END
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: [ 29/48] mm: migration: add migrate_entry_wait_huge()
At Fri, 21 Jun 2013 14:47:27 +0200, Michal Hocko wrote: > > On Thu 20-06-13 18:52:43, Satoru Takeuchi wrote: > > Hi Naoya, > > > > At Tue, 18 Jun 2013 09:17:55 -0700, > > Greg Kroah-Hartman wrote: > > > > > > From: Greg Kroah-Hartman > > > > > > 3.9-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Naoya Horiguchi > > > > > > commit 30dad30922ccc733cfdbfe232090cf674dc374dc upstream. > > > > > > When we have a page fault for the address which is backed by a hugepage > > > under migration, the kernel can't wait correctly and do busy looping on > > > hugepage fault until the migration finishes. As a result, users who try > > > to kick hugepage migration (via soft offlining, for example) occasionally > > > experience long delay or soft lockup. > > > > > > This is because pte_offset_map_lock() can't get a correct migration entry > > > or a correct page table lock for hugepage. This patch introduces > > > migration_entry_wait_huge() to solve this. > > > > I suspect that this code doesn't work correctly on i686 box with > > CONFIG_HIGHPTE. > > If we call hugetlb_fault() -> migration_entry_wait_huge() -> > > __migration_entry_wait(), > > this function tries to kunmap pte, in this case pte is not-kmapped pmd, via > > pte_unmap_unlock(). > > If CONFIG_DEBUG_HIGHMEM is also enabled, it results in BUG_ON() at > > __kunmap_atomic(). > > > > Correct me if I'm wrong. > > I haven't checked the code closer but the patch doesn't change anything > regarding pte_unmap_unlock. The only thing that it touches is the > _locking_. So whether there ever was a problem with kmap or not this > patch doesn't change it. > > That being said, the patch is OK for the stable tree. OK, I see. This is a different problem from this patch. If I'll find a real problem with kmap, I'll report it as the different problem. Thanks, Satoru -- 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: hanging, and possible exploit/ddos from LAN for RTL and other cards (watchdog netdev)
opensou...@tigusoft.pl : > On Sunday 16 June 2013 18:39:21 Francois Romieu wrote: > > Thank you for feedback. We provide XID, IRQ and additional info below. Executive summary: 1. affected Realtek nics are 8168evl (XID 0c900800) and an old PCI (XID 1800) 2. failing marvell nic resorts to a proprietary fglrx tainted kernel on a computer with several graphic cards (2) is nothing I am thrilled to spend time on, especially in a clusterfucked openbsd-tor-bitcoin-grsecurity-backport-from-hell technical context. b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 must be applied if tx checksumming is enabled on your 8168evl (see 'ethtool -k eth0'). b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 is still pending inclusion in -stable so it can only be found in current -git. [...] > * We plan to connect -eth-tcpdump-eth- boxes between some computers and LAN > * We plan to swap electrical devices: switches, even cables to exclude this No overclocking nor outdated gigabyte EP45xyz motherboard bioses ? [...] > --- possible solutions > #1 the patch rtl8169-fix1a-3.2.46.patch below (NO. not working) As expected: 8168evl is RTL_GIGA_MAC_VER_34. > #2 kernel cmdline "pcie_aspm=off" (not tested enough) > #3 kernel cmdline "clocksource=acpi_pm" (not tested enough) > > Since rearranging the network as in below, the hang of > trident-mainboard-based computer no longer hangs entire network > easily, so we wait for the freezing of computers to reoccur. 8168 may go into a mac pause frame frenzy if it fails. [...] > - when 2nd card was plugged in (usb0) it instantly was unhanging the computer > same as replugging eth0 cable would, and seemed to immunize it from hanging Ok. [...] > r8169 :02:00.0: eth4: unable to load firmware patch > rtl_nic/rtl8168e-3.fw (-2) You can give it a try. -- Ueimor -- 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: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]
On Sat, Jun 22, 2013 at 12:07 AM, Davidlohr Bueso wrote: > On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote: >> On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell >> wrote: >> > Hi all, >> > >> > Happy solstice! >> > >> > Changes since 20130620: >> > >> > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree) >> > >> > The net-next tree gained a conflict against the net tree. >> > >> > The leds tree still had its build failure, so I used the version from >> > next-20130607. >> > >> > The arm-soc tree gained conflicts against the tip, net-next, mfd and >> > mailbox trees. >> > >> > The staging tree still had its build failure for which I disabled some >> > code. >> > >> > The akpm tree lost a few patches that turned up elsewhere and gained >> > conflicts against the ftrace and arm-soc trees. >> > >> > >> > >> >> [ CC IPC folks ] >> >> Building via 'make deb-pkg' with fakeroot fails here like this: >> >> make: *** [deb-pkg] Terminated >> /usr/bin/fakeroot: line 181: 2386 Terminated >> FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" >> "$@" >> semop(1): encountered an error: Identifier removed >> semop(2): encountered an error: Invalid argument >> semop(1): encountered an error: Identifier removed >> semop(1): encountered an error: Identifier removed >> semop(1): encountered an error: Invalid argument >> semop(1): encountered an error: Invalid argument >> semop(1): encountered an error: Invalid argument >> > > Hmmm those really shouldn't be related to the message queue changes. Are > you sure you got the right bisect? > > Manfred has a few ipc/sem.c patches in linux-next, starting at commit > c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does > reverting any of those instead of "ipc,msg: shorten critical region in > msgrcv" help at all? Also, anything reported in dmesg? > First, I reverted all IPC patches from akpm-tree within -next. Then, I isolated the culprit by git-bisecting. As I checked my logs I did not see anything helpful. >> The issue is present since next-20130606! >> >> LAST KNOWN GOOD: next-20130605 >> FIRST KNOWN BAD: next-20130606 >> >> KNOWN GOOD: next-20130604 >> KNOWN BAD: next-20130607 || next-20130619 || next-20130620 || next-20130621 >> >> git-bisect says CULPRIT commit is... >> >> "ipc,msg: shorten critical region in msgrcv" > > This I get. I went through the code again and it looks correct and > functionally equivalent to the old msgrcv. > Hmm, I guess a rcu_read_unlock() is missing? [ next-20130605 ] ... /* Lockless receive, part 3: * Acquire the queue spinlock. */ ipc_lock_by_ptr(>q_perm); rcu_read_unlock(); ... [ next-20130621 ] ... /* Lockless receive, part 3: * Acquire the queue spinlock. */ ipc_lock_object(>q_perm); ... Whereas ipc_lock_by_ptr() is equivalent to: rcu_read_lock(); ipc_lock_object(); >> >> NOTE: msg_lock_(check_) routines have to be restored (one more revert >> needed)! > > This I don't get. Restoring msg_lock_[check] is already equivalent to > reverting "ipc,msg: shorten critical region in msgrcv" and several other > of the msq patches. What other patch needs reverted? > No, you have to revert both patches as the other removed msg_lock_[check] afterwards. > Anyway, I'll see if I can reproduce the issue, maybe I'm missing > something. > Yupp, I try with adding rcu_read_unlock()... and report. - Sedat - > Thanks, > Davidlohr > >> >> Reverting both (below) commits makes fakeroot build via 'make dep-pkg" again. >> >> I have tested the revert-patches with next-20130606 and next-20130621 >> (see file-attachments). >> >> My build-script is attached! >> >> Can someone of the IPC folks look at that? >> Thanks! >> >> - Sedat - >> >> >> P.S.: Commit-IDs listed below. >> >> [ next-20130606 ] >> >> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606 >> >> "ipc: remove unused functions" >> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79 >> >> "ipc,msg: shorten critic
[PATCH] drm: always provide debugfs function prototypes
It is generally considered bad style to enclose function prototypes in header files in #ifdef. This case illustrates why that is: The tegra host1x driver calls into the debugfs functions if CONFIG_DEBUG_FS is enabled, but that code is otherwise already discarded by the compiler, so leaving the prototype in place actually makes everything work. drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_init': drivers/gpu/host1x/drm/dc.c:1004:2: error: implicit declaration of function 'drm_debugfs_create_files' [-Werror=implicit-function-declaration] drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_exit': drivers/gpu/host1x/drm/dc.c:1026:2: error: implicit declaration of function 'drm_debugfs_remove_files' [-Werror=implicit-function-declaration] Signed-off-by: Arnd Bergmann Cc: Ben Gamari Cc: Dave Airlie diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 63d17ee..8bc105e 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1551,7 +1551,7 @@ extern int drm_proc_init(struct drm_minor *minor, struct proc_dir_entry *root); extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry *root); /* Debugfs support */ -#if defined(CONFIG_DEBUG_FS) + extern int drm_debugfs_init(struct drm_minor *minor, int minor_id, struct dentry *root); extern int drm_debugfs_create_files(struct drm_info_list *files, int count, @@ -1559,7 +1559,6 @@ extern int drm_debugfs_create_files(struct drm_info_list *files, int count, extern int drm_debugfs_remove_files(struct drm_info_list *files, int count, struct drm_minor *minor); extern int drm_debugfs_cleanup(struct drm_minor *minor); -#endif /* Info file support */ extern int drm_name_info(struct seq_file *m, void *data); -- 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: [ 29/48] mm: migration: add migrate_entry_wait_huge()
At Thu, 20 Jun 2013 10:02:13 -0700, Greg Kroah-Hartman wrote: > > On Thu, Jun 20, 2013 at 06:52:43PM +0900, Satoru Takeuchi wrote: > > Hi Naoya, > > > > At Tue, 18 Jun 2013 09:17:55 -0700, > > Greg Kroah-Hartman wrote: > > > > > > From: Greg Kroah-Hartman > > > > > > 3.9-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Naoya Horiguchi > > > > > > commit 30dad30922ccc733cfdbfe232090cf674dc374dc upstream. > > > > > > When we have a page fault for the address which is backed by a hugepage > > > under migration, the kernel can't wait correctly and do busy looping on > > > hugepage fault until the migration finishes. As a result, users who try > > > to kick hugepage migration (via soft offlining, for example) occasionally > > > experience long delay or soft lockup. > > > > > > This is because pte_offset_map_lock() can't get a correct migration entry > > > or a correct page table lock for hugepage. This patch introduces > > > migration_entry_wait_huge() to solve this. > > > > I suspect that this code doesn't work correctly on i686 box with > > CONFIG_HIGHPTE. > > If we call hugetlb_fault() -> migration_entry_wait_huge() -> > > __migration_entry_wait(), > > this function tries to kunmap pte, in this case pte is not-kmapped pmd, via > > pte_unmap_unlock(). > > If CONFIG_DEBUG_HIGHMEM is also enabled, it results in BUG_ON() at > > __kunmap_atomic(). > > Have you tried this? Not yet. I'm now preparing the kernel to reproduce this problem. > > Also, the same issue is still in 3.10-rc6, right? Yes. Thanks, Satoru -- 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: [PATCHv2 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
On Thu, Jun 20, 2013 at 3:57 PM, Alexandre Belloni wrote: > From: Maxime Ripard > > The ADCs connected to this bus have been experiencing some timeout > issues when using the iMX28 i2c controller. Switching back to bitbanging > solves this. Could you please investigate this timeout issue? The I2C timeouts I was having on mx28 when trying to access sgtl5000 codec, was due to the lack of codec clock. After I provided the codec clock I am able to use I2C without issues and just sent a patch for it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: line6: avoid __sync_fetch_and_{and,or}
On 06/21/13 12:55, Arnd Bergmann wrote:
> __sync_fetch_and_and and __sync_fetch_and_or are functions that are provided
> by gcc and depending on the target architecture may be implemented in libgcc,
> which is not always available in the kernel. This leads to a build failure
> on ARMv5:
and on x86_64.
Acked-by: Randy Dunlap
Thanks.
>
> drivers/built-in.o: In function `line6_pcm_release':
> :(.text+0x3bfe80): undefined reference to `__sync_fetch_and_and_4'
> drivers/built-in.o: In function `line6_pcm_acquire':
> :(.text+0x3bff30): undefined reference to `__sync_fetch_and_or_4'
>
> To work around this, we can use the kernel-provided cmpxchg macro.
>
> Build-tested only.
>
> Signed-off-by: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Markus Grabner
>
> diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
> index 02f77d7..4795f12 100644
> --- a/drivers/staging/line6/pcm.c
> +++ b/drivers/staging/line6/pcm.c
> @@ -107,11 +107,15 @@ static bool test_flags(unsigned long flags0, unsigned
> long flags1,
>
> int line6_pcm_acquire(struct snd_line6_pcm *line6pcm, int channels)
> {
> - unsigned long flags_old =
> - __sync_fetch_and_or(>flags, channels);
> - unsigned long flags_new = flags_old | channels;
> - unsigned long flags_final = flags_old;
> - int err = 0;
> + unsigned long flags_old, flags_new, flags_final;
> + int err;
> +
> + do {
> + flags_old = ACCESS_ONCE(line6pcm->flags);
> + flags_new = flags_old | channels;
> + } while (cmpxchg(>flags, flags_old, flags_new) != flags_old);
> +
> + flags_final = flags_old;
>
> line6pcm->prev_fbuf = NULL;
>
> @@ -197,9 +201,12 @@ pcm_acquire_error:
>
> int line6_pcm_release(struct snd_line6_pcm *line6pcm, int channels)
> {
> - unsigned long flags_old =
> - __sync_fetch_and_and(>flags, ~channels);
> - unsigned long flags_new = flags_old & ~channels;
> + unsigned long flags_old, flags_new;
> +
> + do {
> + flags_old = ACCESS_ONCE(line6pcm->flags);
> + flags_new = flags_old & ~channels;
> + } while (cmpxchg(>flags, flags_old, flags_new) != flags_old);
>
> if (test_flags(flags_new, flags_old, LINE6_BITS_CAPTURE_STREAM))
> line6_unlink_audio_in_urbs(line6pcm);
> --
--
~Randy
--
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 v12 05/11] edma: config: Enable config options for EDMA
On Friday 21 June 2013, Joel A Fernandes wrote: > Hi Arnd, > > On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann wrote: > > On Friday 21 June 2013, Joel A Fernandes wrote: > >> I think we are talking about different things, I agree the 'select > >> DMADEVICES' can be dropped but lets please keep the default y option > >> (not adding new select statements, just saying that if someone select > >> DMADEVICES in menuconfig and if they're ARCH_OMAP=1 , then default to > >> EDMA). This will simply allow people to have a default. Thanks. > > > > Yes, that's ok. > > Ok, thanks. I will follow up with a patch in my next submissions that builds > it. > > Perhaps a: > default y if 'ARCH_OMAP2PLUS' > > and leave the existing as it is... > default n if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2' > > would make most sense to me. Basically EDMA is seen on current and all > new OMAP2PLUS. Ok > > config TI_EDMA > > tristate "TI EDMA support" > > default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2 > > select DMA_ENGINE > > select DMA_VIRTUAL_CHANNELS > > > MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The > 'm' option will require some initramfs to load the module when needing > to MMC boot, I suggest lets leave it as y. > Ah, right: you still export a filter function from the edma driver and use it in slave drivers: drivers/mmc/host/davinci_mmc.c: dma_request_slave_channel_compat(mask, edma_filter_fn, drivers/mmc/host/davinci_mmc.c: dma_request_slave_channel_compat(mask, edma_filter_fn, drivers/spi/spi-davinci.c: dspi->dma_rx = dma_request_channel(mask, edma_filter_fn, drivers/spi/spi-davinci.c: dspi->dma_tx = dma_request_channel(mask, edma_filter_fn, As long as this is the case, you have to be careful with the dependencies to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or edma_filter_fn gets defined to NULL when you are building for a DT-only platform. 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 staging-next] zram: remove zram_sysfs file
On Fri, Jun 21, 2013 at 06:29:14PM +0300, Sergey Senozhatsky wrote:
> Move zram sysfs code to zram drv and remove zram_sysfs file.
> This gives ability to make static a number of previously exported
> zram functions, used from zram sysfs, e.g. internal zram
> zram_meta_alloc/free(). We also can drop several zram_drv wrapper
> functions, used from zram sysfs:
> e.g. zram_reset_device()/__zram_reset_device() pair.
>
> Signed-off-by: Sergey Senozhatsky
>
> ---
> drivers/staging/zram/Makefile | 2 +-
> drivers/staging/zram/zram_drv.c | 524
> +-
> drivers/staging/zram/zram_drv.h | 10 -
> drivers/staging/zram/zram_sysfs.c | 209 ---
> 4 files changed, 354 insertions(+), 391 deletions(-)
>
> diff --git a/drivers/staging/zram/Makefile b/drivers/staging/zram/Makefile
> index 7f4a301..cb0f9ce 100644
> --- a/drivers/staging/zram/Makefile
> +++ b/drivers/staging/zram/Makefile
> @@ -1,3 +1,3 @@
> -zram-y := zram_drv.o zram_sysfs.o
> +zram-y := zram_drv.o
>
> obj-$(CONFIG_ZRAM) += zram.o
> diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
> index ec2b2b5..f32fcca 100644
> --- a/drivers/staging/zram/zram_drv.c
> +++ b/drivers/staging/zram/zram_drv.c
> @@ -42,6 +42,111 @@ static struct zram *zram_devices;
> /* Module params (documentation at end) */
> static unsigned int num_devices = 1;
>
> +module_param(num_devices, uint, 0);
> +MODULE_PARM_DESC(num_devices, "Number of zram devices");
> +
> +MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_AUTHOR("Nitin Gupta ");
> +MODULE_DESCRIPTION("Compressed RAM Block Device");
This is usually best put at the bottom of the file, not at the top.
Why did you move it?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jun 21 [ BROKEN ipc/ipc-msg ]
On Fri, 2013-06-21 at 21:34 +0200, Sedat Dilek wrote: > On Fri, Jun 21, 2013 at 10:17 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Happy solstice! > > > > Changes since 20130620: > > > > Dropped tree: mailbox (really bad merge conflicts with the arm-soc tree) > > > > The net-next tree gained a conflict against the net tree. > > > > The leds tree still had its build failure, so I used the version from > > next-20130607. > > > > The arm-soc tree gained conflicts against the tip, net-next, mfd and > > mailbox trees. > > > > The staging tree still had its build failure for which I disabled some > > code. > > > > The akpm tree lost a few patches that turned up elsewhere and gained > > conflicts against the ftrace and arm-soc trees. > > > > > > > > [ CC IPC folks ] > > Building via 'make deb-pkg' with fakeroot fails here like this: > > make: *** [deb-pkg] Terminated > /usr/bin/fakeroot: line 181: 2386 Terminated > FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" > "$@" > semop(1): encountered an error: Identifier removed > semop(2): encountered an error: Invalid argument > semop(1): encountered an error: Identifier removed > semop(1): encountered an error: Identifier removed > semop(1): encountered an error: Invalid argument > semop(1): encountered an error: Invalid argument > semop(1): encountered an error: Invalid argument > Hmmm those really shouldn't be related to the message queue changes. Are you sure you got the right bisect? Manfred has a few ipc/sem.c patches in linux-next, starting at commit c50df1b4 (ipc/sem.c: cacheline align the semaphore structures), does reverting any of those instead of "ipc,msg: shorten critical region in msgrcv" help at all? Also, anything reported in dmesg? > The issue is present since next-20130606! > > LAST KNOWN GOOD: next-20130605 > FIRST KNOWN BAD: next-20130606 > > KNOWN GOOD: next-20130604 > KNOWN BAD: next-20130607 || next-20130619 || next-20130620 || next-20130621 > > git-bisect says CULPRIT commit is... > > "ipc,msg: shorten critical region in msgrcv" This I get. I went through the code again and it looks correct and functionally equivalent to the old msgrcv. > > NOTE: msg_lock_(check_) routines have to be restored (one more revert needed)! This I don't get. Restoring msg_lock_[check] is already equivalent to reverting "ipc,msg: shorten critical region in msgrcv" and several other of the msq patches. What other patch needs reverted? Anyway, I'll see if I can reproduce the issue, maybe I'm missing something. Thanks, Davidlohr > > Reverting both (below) commits makes fakeroot build via 'make dep-pkg" again. > > I have tested the revert-patches with next-20130606 and next-20130621 > (see file-attachments). > > My build-script is attached! > > Can someone of the IPC folks look at that? > Thanks! > > - Sedat - > > > P.S.: Commit-IDs listed below. > > [ next-20130606 ] > > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130606 > > "ipc: remove unused functions" > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8793fdfb0d0a6ed5916767e29a15d3eb56e04e79 > > "ipc,msg: shorten critical region in msgrcv" > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=c0ff93322847a54f74a5450032c4df64c17fdaed > > [ next-20130621 ] > > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=next-20130621 > > "ipc: remove unused functions" > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=941ce57c81dcceadf55265616ee1e8bef18b0ad3 > > "ipc,msg: shorten critical region in msgrcv" > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=62190df4081ee8504e3611d45edb40450cb408ac -- 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: clocksource with changing frequency?
Thanks for your answers. Sören -- 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][GIT PULL] trace,x86: Move creation of irq tracepoints from apic.c to irq.c
On 06/21/2013 02:28 PM, Steven Rostedt wrote: > On Fri, 2013-06-21 at 14:13 -0700, H. Peter Anvin wrote: >> On 06/21/2013 02:09 PM, Steven Rostedt wrote: >>> Call Trace: >>> [] do_fork+0xa8/0x260 >>> [] ? trace_preempt_on+0x2a/0x2f >>> [] ? trace_hardirqs_on_thunk+0x3a/0x3f >> >> This bit of the call chain seems a little odd, no? > > Doesn't the "?" mean its just in the stack but not part of the call > frame that was used. CONFIG_FRAME_POINTER is set in the config. > > With lockdep and preempt tracing enabled, why would this seem strange? > I didn't think trace_hardirqs_on_thunk called trace_preempt_on but maybe I misread the code. -hpa -- 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 v12 05/11] edma: config: Enable config options for EDMA
Hi Arnd, On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann wrote: > On Friday 21 June 2013, Joel A Fernandes wrote: >> I think we are talking about different things, I agree the 'select >> DMADEVICES' can be dropped but lets please keep the default y option >> (not adding new select statements, just saying that if someone select >> DMADEVICES in menuconfig and if they're ARCH_OMAP=1 , then default to >> EDMA). This will simply allow people to have a default. Thanks. > > Yes, that's ok. Ok, thanks. I will follow up with a patch in my next submissions that builds it. Perhaps a: default y if 'ARCH_OMAP2PLUS' and leave the existing as it is... default n if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2' would make most sense to me. Basically EDMA is seen on current and all new OMAP2PLUS. > > config TI_EDMA > tristate "TI EDMA support" > default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2 > select DMA_ENGINE > select DMA_VIRTUAL_CHANNELS MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The 'm' option will require some initramfs to load the module when needing to MMC boot, I suggest lets leave it as y. Thanks, Joel -- 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] pinctrl: msm: Add support for MSM TLMM pinmux
Add a new device tree enabled pinctrl driver for Qualcomm MSM SoC's. This driver provides an extensible framework to interface all MSM's that use a TLMM pinmux, with the pinctrl subsytem. This driver is split into two parts: the pinctrl interface and the TLMM version specific implementation. The pinctrl interface parses the device tree and registers with the pinctrl subsytem. The TLMM version specific implementation supports pin configuration/register programming for the different pin types present on a given TLMM pinmux version. Add support only for TLMM version 3 pinmux right now, as well as, only two of the different pin types present on the TLMM v3 pinmux. Pintype 1: General purpose pins. Pintype 2: SDC pins. Signed-off-by: Hanumant Singh --- .../devicetree/bindings/pinctrl/msm-pinctrl.txt| 187 + drivers/pinctrl/Kconfig| 10 + drivers/pinctrl/Makefile | 2 + drivers/pinctrl/pinctrl-msm-tlmm-v3.c | 345 + drivers/pinctrl/pinctrl-msm.c | 774 + drivers/pinctrl/pinctrl-msm.h | 112 +++ 6 files changed, 1430 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-msm-tlmm-v3.c create mode 100644 drivers/pinctrl/pinctrl-msm.c create mode 100644 drivers/pinctrl/pinctrl-msm.h diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt new file mode 100644 index 000..c76777b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt @@ -0,0 +1,187 @@ +MSM TLMM pinmux controller + +Qualcomm MSM integrates a GPIO and Pin mux/config hardware, (TOP Level Mode +Multiplexper in short TLMM). It controls the input/output settings on the +available pads/pins and also provides ability to multiplex and configure the +output of various on-chip controllers onto these pads. The pins are also of +different types, encapsulating different functions and having differing register +semantics. + +Required Properties: +- compatible: should be one of the following. + - "qcom,msm-tlmm-v3": for MSM with TLMM version 3. + +- reg: Base address of the pin controller hardware module and length of + the address space it occupies. + +- Pin types as child nodes: Pin types supported by a particular controller + instance are represented as child nodes of the controller node. Each + pin type node must contain following properties: + +Required Properties + - qcom,pin-type: identifies the pin type. + - qcom,pin-cells: number of cells in the pin type specifier. + - qcom,num-pins: number of pins of given type present on the MSM. + +- Pin groups as child nodes: The pin mux (selecting pin function + mode) and pin config (pull up/down, driver strength, direction) settings are + represented as child nodes of the pin-controller node. There is no limit on + the count of these child nodes. + + Required Properties +-qcom,pins: phandle specifying pin type and a pin number. + + Optional Properties +-qcom,pin-func: function setting for the pin group. + + The child node should contain a list of pin(s) on which a particular pin + function selection or pin configuration (or both) have to applied. This + list of pins is specified using the property name "qcom,pins". There + should be atleast one pin specfied for this property and there is no upper + limit on the count of pins that can be specified. The pins are specified + using the pintype phandle and the pin number within that pintype. + + The pin function selection that should be applied on the pins listed in the + child node is specified using the "qcom,pin-func" property. The value + of this property that should be applied to each of the pins listed in the + "qcom,pins" property, should be picked from the hardware manual of the SoC. + This property is optional in the child node if no specific function + selection is desired for the pins listed in the child node or if the pin is + to be used for bit bang. The value of this property is used as-is to program + the pin-controller + + The pin group node must additionally have a pin configuration node as its own + child node. There can be more then one such configuration node for a pin group + node. There can be one or more configurations within the configuration + node. These configurations are applied to all pins mentoned above using the + "qcom,pins" property. These configurations are specific to the pintype of the + pins. The following pin configuration properties are supported by general + purpose pins. + + - qcom,gp-pull: Pull up/down configuration. + - qcom,gp-drv: Drive strength configuration. + - qcom,gp-dir: Pull up/down configuration in power down mode. + + The following pin configurations are properties are supported by SDC pins + - qcom,sdc1-clk-pull: Pull up/down configuration
[PATCH] Minor patch for drivers/misc/mei/pci-me.c: Delete stray dev_err() calls.
The pci-me.c code contains 2 dev_err() calls which are apparently left over from debugging; they do not represent actual error conditions. They do produce messages in a "quiet" kernel, and add ERROR entries to the logger. Signed-off-by: "charles anthony" Linux 3.10-rc6 --- linux-3.10-rc6/drivers/misc/mei/pci-me.c.orig 2013-06-21 14:30:33.916202629 -0700 +++ linux-3.10-rc6/drivers/misc/mei/pci-me.c2013-06-21 14:30:59.023519010 -0700 @@ -248,7 +248,6 @@ static void mei_me_remove(struct pci_dev hw = to_me_hw(dev); - dev_err(>dev, "stop\n"); mei_stop(dev); mei_pdev = NULL; @@ -281,8 +280,6 @@ static int mei_me_pci_suspend(struct dev if (!dev) return -ENODEV; - dev_err(>dev, "suspend\n"); - mei_stop(dev); mei_disable_interrupts(dev); -- 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 0/2] Delay initializing of large sections of memory
On 6/21/2013 1:08 PM, H. Peter Anvin wrote: > Is this init code? 32K of unconditional runtime addition isn't completely > trivial. The delay functions that move memory to the absent list are __init but the read back of the list and memory insertion are not. BTW, this option is only available with the memory hotplug option which depends on the sparse memory option. So any usage of these distro configs will normally be on enterprise class machines. > > Nathan Zimmer wrote: > >> On 06/21/2013 12:28 PM, H. Peter Anvin wrote: >>> On 06/21/2013 10:18 AM, Nathan Zimmer wrote: > Since you made it a compile time option, it would be good to know >> how > much code it adds, but otherwise I agree with Greg here... this >> really > shouldn't need to be an option. It *especially* shouldn't need to >> be a > hand-set runtime option (which looks quite complex, to boot.) The patchset as a whole is just over 400 lines so it doesn't add >> alot. If I were to pull the .config option it would probably remove 30 >> lines. >>> I'm more concerned about bytes of code. >> Oh, The difference is just under 32k. >> 371843425 Jun 21 14:08 vmlinux.o /* DELAY_MEM_INIT is not set */ >> 371875600 Jun 21 14:36 vmlinux.o /* DELAY_MEM_INIT=y */ >> >>> The command line option is too complex but some of the data I >> haven't found a way to get at runtime yet. >>> I think that is probably key. >>> > I suspect the cutoff for this should be a lot lower than 8 TB even, >> more > like 128 GB or so. The only concern is to not set the cutoff so >> low > that we can end up running out of memory or with suboptimal NUMA > placement just because of this. Even at lower amounts of ram there is an positive impact.I it knocks time off boot even at as small as a 1TB of ram. >>> I am not surprised. >>> >>> -hpa >>> > -- 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: power-efficient scheduling design
On 6/21/2013 2:23 PM, Catalin Marinas wrote: oops sorry I misread your mail (lack of early coffee I suppose) I can see your point of having a thing for "did we ask for all the performance we could ask for" prior to doing a load balance (although, for power efficiency, if you have two tasks that could run in parallel, it's usually better to run them in parallel... so likely we should balance anyway) Not necessarily, especially if parallel running implies powering up a full cluster just for one CPU (it depends on the hardware but for example a cluster may not be able to go in deeper sleep states unless all the CPUs in that cluster are idle). I guess it depends on the system the very first cpu needs to power on * the core itself * the "cluster" that you mention * the memory controller * the memory (out of self refresh) while the second cpu needs * the core itself * maybe a second cluster normally on Intel systems, the memory power delta is quite significant which then means the efficiency of the second core is huge compared to running things in sequence. -- 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/
[RFC PATCH V2 5/8] ARM: dts: OMAP4: add voltage processor nodes
OMAP443x, OMAP446x SoC use same offsets for voltage processor,
however their voltage characteristics differ a little.
Introduce the voltage processor nodes for the same.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4.dtsi| 43 +++
arch/arm/boot/dts/omap443x.dtsi | 15 ++
arch/arm/boot/dts/omap4460.dtsi | 15 ++
3 files changed, 73 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a153e8d..3c75b23 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -689,5 +689,48 @@
compatible = "ti,omap4-vc-channel-core";
};
};
+
+ vp_mpu: vp@0x4A307B58 {
+ compatible = "ti,omap4-vp";
+
+ reg = <0x4A307b58 0x18>, <0x4A306014 0x4>;
+ reg-names = "base-address", "int-address";
+ ti,tranxdone-status-mask=<0x20>;
+
+ clocks = <_in>;
+
+ ti,vc-channel = <_mpu>;
+ ti,min-step-micro-volts = <1>;
+ ti,max-step-micro-volts = <5>;
+ };
+
+ vp_iva: vp@0x4A307B70 {
+ compatible = "ti,omap4-vp";
+
+ reg = <0x4A307B70 0x18>, <0x4A306010 0x4>;
+ reg-names = "base-address", "int-address";
+ ti,tranxdone-status-mask=<0x2000>;
+
+ clocks = <_in>;
+
+ ti,vc-channel = <_iva>;
+ ti,min-step-micro-volts = <1>;
+ ti,max-step-micro-volts = <5>;
+ };
+
+ vp_core: vp@0x4A307B40 {
+ compatible = "ti,omap4-vp";
+
+ reg = <0x4A307b40 0x18>, <0x4A306010 0x4>;
+ reg-names = "base-address", "int-address";
+ ti,tranxdone-status-mask=<0x20>;
+
+ clocks = <_in>;
+
+ regulator_name = "vdd_core";
+ ti,vc-channel = <_core>;
+ ti,min-step-micro-volts = <1>;
+ ti,max-step-micro-volts = <5>;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 2b0deb5..e759937 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -46,3 +46,18 @@
ti,retention-micro-volts = <75>;
ti,off-micro-volts = <0>;
};
+
+_mpu {
+ ti,min-micro-volts = <75>;
+ ti,max-micro-volts = <1388000>;
+};
+
+_iva {
+ ti,min-micro-volts = <75>;
+ ti,max-micro-volts = <1291000>;
+};
+
+_core {
+ ti,min-micro-volts = <75>;
+ ti,max-micro-volts = <1127000>;
+};
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 16210a1..8320865 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -55,3 +55,18 @@
ti,retention-micro-volts = <75>;
ti,off-micro-volts = <0>;
};
+
+_mpu {
+ ti,min-micro-volts = <75>;
+ ti,max-micro-volts = <138>;
+};
+
+_iva {
+ ti,min-micro-volts = <75>;
+ ti,max-micro-volts = <1375000>;
+};
+
+_core {
+ ti,min-micro-volts = <75>;
+ ti,max-micro-volts = <125>;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH V2 6/8] ARM: dts: TWL6030/OMAP4: Add OMAP voltage path linkage
OMAP4430 and 4460 platforms use TWL6030 to power voltage rails.
However, on 4460, we use twl6030 only for iva and core voltage rails.
Introduce an twl6030_omap4.dtsi to be able to reuse the base definition
for all OMAP4 platforms and the delta change only for panda-es platform
which is based on 4460.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4-panda-common.dtsi |1 +
arch/arm/boot/dts/omap4-panda-es.dts | 13 +++
arch/arm/boot/dts/omap4-sdp.dts |1 +
arch/arm/boot/dts/omap4-var-som.dts |1 +
arch/arm/boot/dts/twl6030_omap4.dtsi | 35 +
5 files changed, 51 insertions(+)
create mode 100644 arch/arm/boot/dts/twl6030_omap4.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..2b15c2b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -199,6 +199,7 @@
};
#include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
{
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 56c4354..49017c5 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -62,3 +62,16 @@
gpios = < 8 GPIO_ACTIVE_HIGH>;
};
};
+
+_twl6030_vcore1 {
+ ti,vp = <_core>;
+};
+
+_twl6030_vcore2 {
+ ti,vp = <_iva>;
+};
+
+_twl6030_vcore3 {
+ /* We use TPS62361 on this platform instead */
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..2f81b4d5 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -337,6 +337,7 @@
};
#include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
{
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/omap4-var-som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
index b41269e..6f0b763 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -40,6 +40,7 @@
};
#include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
{
clock-frequency = <40>;
diff --git a/arch/arm/boot/dts/twl6030_omap4.dtsi
b/arch/arm/boot/dts/twl6030_omap4.dtsi
new file mode 100644
index 000..7724039
--- /dev/null
+++ b/arch/arm/boot/dts/twl6030_omap4.dtsi
@@ -0,0 +1,35 @@
+/*
+ * TWL6030 entries specific for OMAP
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+ {
+ omap_twl6030_vcore1: vcore1 {
+ compatible = "ti,omap-twl6030-vcore1";
+ ti,boot-voltage-micro-volts = <120>;
+ ti,vp = <_mpu>;
+ };
+
+ omap_twl6030_vcore2: vcore2 {
+ compatible = "ti,omap-twl6030-vcore2";
+ ti,boot-voltage-micro-volts = <120>;
+ ti,vp = <_iva>;
+ };
+
+ omap_twl6030_vcore3: vcore3 {
+ compatible = "ti,omap-twl6030-vcore3";
+ ti,boot-voltage-micro-volts = <120>;
+ ti,vp = <_core>;
+ };
+};
+
+ {
+ ti,i2c-high-speed;
+ ti,i2c-pad-load = <3>;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/2] Delay initializing of large sections of memory
On 6/21/2013 11:50 AM, Greg KH wrote: > On Fri, Jun 21, 2013 at 11:44:22AM -0700, Yinghai Lu wrote: >> On Fri, Jun 21, 2013 at 10:03 AM, H. Peter Anvin wrote: >>> On 06/21/2013 09:51 AM, Greg KH wrote: >>> >>> I suspect the cutoff for this should be a lot lower than 8 TB even, more >>> like 128 GB or so. The only concern is to not set the cutoff so low >>> that we can end up running out of memory or with suboptimal NUMA >>> placement just because of this. >> >> I would suggest another way: >> only boot the system with boot node (include cpu, ram and pci root buses). >> then after boot, could add other nodes. > > What exactly do you mean by "after boot"? Often, the boot process of > userspace needs those additional cpus and ram in order to initialize > everything (like the pci devices) properly. Exactly. That's why I left both low and high memory on each node. > > thanks, > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH V2 7/8] ARM: dts: omap4-panda-es: add TPS62361 supply for vdd_mpu
Unlike other OMAP4 platforms including the the "vanilla" PandaBoard,
PandaBoard-ES uses TPS62361 to supply vdd_mpu.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4-panda-es.dts | 18 ++
arch/arm/boot/dts/tps62361_omap.dtsi | 18 ++
2 files changed, 36 insertions(+)
create mode 100644 arch/arm/boot/dts/tps62361_omap.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 49017c5..325816c 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -75,3 +75,21 @@
/* We use TPS62361 on this platform instead */
status = "disabled";
};
+
+#include "tps62361_omap.dtsi"
+
+_pmx_wkup {
+ tps62361_wkgpio_pins: pinmux_tps62361_wkpins {
+ pinctrl-single,pins = <
+ 0x1a (PIN_OUTPUT | MUX_MODE3 | OFF_EN | OFFOUT_VAL) /*
gpio_wk7 */
+ >;
+ };
+};
+
+_tps62361 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+ gpios = < 7 GPIO_ACTIVE_HIGH>;
+};
diff --git a/arch/arm/boot/dts/tps62361_omap.dtsi
b/arch/arm/boot/dts/tps62361_omap.dtsi
new file mode 100644
index 000..ee261ec
--- /dev/null
+++ b/arch/arm/boot/dts/tps62361_omap.dtsi
@@ -0,0 +1,18 @@
+/*
+ * TPS62361 entries specific for OMAP
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+ omap_tps62361: tps62361 {
+ compatible = "ti,omap-tps62361";
+ ti,boot-voltage-micro-volts = <1203000>;
+ ti,vp = <_mpu>;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI custom hardware block to better facilitate and standardize integration of Power Management ICs which communicate over I2C. In fact, many custom PMICs were designed to be usable over this interface. On the other hand, generic PMICs which are compatible to the I2C protocol supported by Voltage controller may also be used. In general, the following categories of PMICs exist: a) PMICs which are completely controlled by voltage controller/voltage processor pair - this implies even configuration needs to be done over the same interface. Example: TPS62361 used on PandaBoard-ES and many OMAP4460 based platforms. Few Maxim and Fairchild PMICs used on certain products would fall in this category. - Note: in this case, there may not even exist/needed to support an "traditional Linux regulator driver" b) PMICs which provide two views over two I2C interfaces - however, voltage can only be set only on one of them. Example: TWL4030/5030: allows us to use Voltage controller once we set up a bit over regular I2C - This is used in OMAP3. TWO6030/TWL6032 - configuration *has* to be performed over regular i2c (example smps_offset) and voltage control *has* to be performed by using voltage controller/processor. - Note: in this case, there may exist "traditional Linux regulator driver" however, it may not support in any form SMPS modelling for that part of the device which is exposed to voltage controller/processor. c) PMICs which allow voltage and configurations over either i2c interfaces - TWL6035/TWL6037/Palmas family of TI processor - Note: in this case, there may exist "traditional Linux regulator driver" and, it may support in some form SMPS modelling for that part of the device which is exposed to voltage controller/processor. d) custom PMICs which are setup so that no configuration is needed to be performed and they operate with preset register offsets and minimal conferability using voltage controller/processor. - Note: in this case, there may not even exist/needed to support an "traditional Linux regulator driver" However, no matter the type of PMIC used, the OMAP view of a PMIC is generic when used over voltage controller/processor. We attempt to model this generic view of the regulator represented by OMAP SoC. Alternative to this approach would be to "hack" into the get voltage/set voltage interfaces of regulator drivers which represent the rest of the PMIC controlled over regular I2C interface and re-route the requests to voltage controller/processor. But, by doing that, we needlessly create additional code which may be abstracted out into device tree node information. Since the regulator node representing PMIC, voltage controller, processors are probed at varied points in time, probe deferral is used to sequence in the right order. It is expected by the driver to register omap_pmic_register_controller_ops providing mandatory operations at the earliest possible opportunity. Despite the current SoCs implementing the solution based on voltage controller and voltage processor (which are part of the OMAP SoC modules which enable Adaptive Voltage Scaling class support), the interfaces are generic enough to handle future equivalent modules. [grygorii.stras...@ti.com, ta...@ti.com: co-developer] Signed-off-by: Grygorii Strashko Signed-off-by: Taras Kondratiuk Signed-off-by: Nishanth Menon --- .../bindings/regulator/omap-pmic-regulator.txt | 41 ++ drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/omap-pmic-regulator.c| 638 include/linux/regulator/omap-pmic-regulator.h | 162 + 5 files changed, 854 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt create mode 100644 drivers/regulator/omap-pmic-regulator.c create mode 100644 include/linux/regulator/omap-pmic-regulator.h diff --git a/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt new file mode 100644 index 000..6991e58 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt @@ -0,0 +1,41 @@ +Generic Power Management IC(PMIC) Regulator for Texas Instruments OMAP SoCs + +Required Properties: +- compatible: Should be one of: + - "ti,omap-twl4030-vdd1" - TWL4030/5030/TPS65950 VDD1 + - "ti,omap-twl4030-vdd2" - TWL4030/5030/TPS65950 VDD2 + - "ti,omap-twl6030-vcore1" - TWL6030 VCORE1 + - "ti,omap-twl6030-vcore2" - TWL6030 VCORE2 + - "ti,omap-twl6030-vcore3" - TWL6030 VCORE3 + - "ti,omap-tps62361" - TPS62361 VSEL1 + - "ti,omap-twl6032-smps1" - TWL6032 SMPS1 + - "ti,omap-twl6032-smps2" - TWL6032 SMPS2 + - "ti,omap-twl6032-smps5" - TWL6032 SMPS5 + - "ti,omap-twl6035-smps1" - TWL6035/6037 in SMPS1, 12, 123 configuration + - "ti,omap-twl6035-smps4" - TWL6035/6037 in SMPS4,
[RFC PATCH V2 0/8] regulator/OMAP: support VC/VP support in dts
Hi, Texas Instrument's OMAP Processor have a dedicated hardware module which is customised to operate with Power Management IC(PMIC) over an dedicated I2C. The communication involves a few SoC internal modules as follows: PMIC - The power management chip on the dedicated I2C (sometimes called I2C_SR) Voltage controller - consists of an hardware i2c controller and interface customized for PMICs. VC consists of multiple VC Channels, each channel representing a variable voltage rail supply to the SoC. Voltage Processor(VP) - controls the voltage requests to VC channel SmartReflex(Adaptive Voltage control) - (SR/AVS)- specialized hardware block which can dynamically control device voltage without software intervention. This module communicates with VP. In the simplest view, a simple voltage set operation is as follows: Vp->VC Channel -> VC -> PMIC Note, there may be dedicated PMIC per variable voltage rail OR PMICs which provide control for multiple SMPS supplying variable rails etc. In addition, there is an Adaptive Voltage Control (AVS) technique called SmartReflex which can operate (in a configuration called continous monitoring hardware loop or class 3 mode of operation), in which the SmartReflex block communicates with Voltage Processor. We have an OMAP specific implementation in arch/arm/mach-omap2 which does not tree VC/VP or PMIC as Linux devices, but as data which is configured as needed. In this series, we introduce replacement approach which has support for only Device Tree as OMAP is transitioning completely away from non-DT approach. As an overview, the following approach is taken. PMIC is now the regulator driver - generic omap-pmic-regulator (patch #1) Voltage controller and voltage controller channel is handled by driver/power/avs/omap_vc.c Voltage processor is handled by driver/power/avs/omap_vp.c Benefit of using drivers/power/avs is also to set the foundation to convert SmartReflex AVS into device tree based solution. (next stage). S/w dependency is as follows: Voltage controller <- Voltage Processor Voltage Processor registers with OMAP_PMIC it's controller operations OMAP_PMIC uses the controller operations to call vp which in turn calls VC to setup the communication chain. This allows us to maintain this as a module if needed as well (something our existing implementation was not capable of doing). The series is also available here: https://github.com/nmenon/linux-2.6-playground/commits/devel/vc-vp-regulator-rfc git://github.com/nmenon/linux-2.6-playground.git branch: devel/vc-vp-regulator-setv-v1-rfc-2 This depends on a few patches for cpufreq/clock node I added in, merged with 3.10-rc6 master + the following for-next branches benoit/for_3.11/dts mturquette/clk-next broonie/for-next rafael/linux-next Available as branch: devel/vc-vp-base Note: 1. AVS device tree conversion will have to depend on this due to dependency on VP 2. Clock node strategy used here is based on implementation I had posted here: http://marc.info/?t=13680400841=1=2 3. I chose OMAP4460 based PandaBoard ES platform as my development platform and patch #4 in this series is an attempt to showcase how it will look like. Rationale: weird PMIC configuration was used in PandaBoard ES. Ability to handle that platform makes introduction to other platforms/SoCs trivial. 4. Once this approach is agreed upon, I can do the dts changes for all SoCs OMAP3-5 and will post a formal series. Related defects: https://bugzilla.kernel.org/show_bug.cgi?id=58541 https://bugzilla.kernel.org/show_bug.cgi?id=58611 Related discussion: v1 of RFC: http://marc.info/?t=13692468965=1=2 related discussion: http://marc.info/?t=13716695495=1=2 Nishanth Menon (8): regulator: Introduce OMAP regulator to control PMIC over VC/VP PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes PM / AVS: Introduce support for OMAP Voltage Processor(VP) with device tree nodes ARM: dts: OMAP4: add voltage controller nodes ARM: dts: OMAP4: add voltage processor nodes ARM: dts: TWL6030/OMAP4: Add OMAP voltage path linkage ARM: dts: omap4-panda-es: add TPS62361 supply for vdd_mpu ARM: dts: OMAP4-panda-es: use tps regulator as cpu0 supply .../devicetree/bindings/power/omap-vc.txt | 99 ++ .../devicetree/bindings/power/omap-vp.txt | 39 + .../bindings/regulator/omap-pmic-regulator.txt | 41 + arch/arm/boot/dts/omap4-panda-common.dtsi |1 + arch/arm/boot/dts/omap4-panda-es.dts | 35 + arch/arm/boot/dts/omap4-sdp.dts|1 + arch/arm/boot/dts/omap4-var-som.dts|1 + arch/arm/boot/dts/omap4.dtsi | 73 +- arch/arm/boot/dts/omap443x.dtsi| 32 +- arch/arm/boot/dts/omap4460.dtsi| 33 +- arch/arm/boot/dts/tps62361_omap.dtsi | 18 + arch/arm/boot/dts/twl6030_omap4.dtsi | 35 +
[RFC PATCH V2 3/8] PM / AVS: Introduce support for OMAP Voltage Processor(VP) with device tree nodes
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI
custom hardware block to better facilitate and standardize integration
of Power Management ICs which communicate over I2C called Voltage
Processor(VP).
This is an specialized hardware block meant to support PMIC chips only
over Voltage Controller(VC) interface. This provides an interface for
SmartReflex AVS module to send adjustment steps which is converted into
voltage values and send onwards by VP to VC. VP is also used to set the
voltage of the PMIC by commanding using "forceupdate".
We have an existing implementation in mach-omap2 which has been
re factored and moved out as a separate driver. This new driver is DT
only and the separation was meant to get a maintainable driver which
does not have to deal with legacy platform_data dependencies. The legacy
driver is retained to support non-DT boot and functionality will be
migrated to the DT-only version as we enable features.
Currently, this implementation considers only the basic steps needed for
voltage scaling and exposing voltage processor which hooks on to Voltage
Controller driver and OMAP PMIC driver to provide an regulator interface
over OMAP PMIC driver.
We may need to do additional timing configurations to enable Low power
mode voltage transitions and to hook the Adaptive Voltage
Scaling(AVS) implementation for OMAP which also uses the same voltage
controller to talk to PMICs. This needs to be addressed in a later
series.
This driver is meant to interface with OMAP PMIC driver when the
controller driver registers it's operations with OMAP PMIC driver and
associates with an voltage controller channel. This enables the full
communication path between the OMAP PMIC regulator to the external PMIC
hardware over OMAP Voltage Processor and OMAP Voltage Controller.
[grygorii.stras...@ti.com, ta...@ti.com: co-developer]
Signed-off-by: Grygorii Strashko
Signed-off-by: Taras Kondratiuk
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/power/omap-vp.txt | 39 +
drivers/power/avs/Makefile |2 +-
drivers/power/avs/omap_vp.c| 892
3 files changed, 932 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/power/omap-vp.txt
create mode 100644 drivers/power/avs/omap_vp.c
diff --git a/Documentation/devicetree/bindings/power/omap-vp.txt
b/Documentation/devicetree/bindings/power/omap-vp.txt
new file mode 100644
index 000..b690e35
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/omap-vp.txt
@@ -0,0 +1,39 @@
+Voltage Controller driver for Texas Instruments OMAP SoCs
+
+Voltage Controller Properties:
+The following are the properties of the voltage controller node
+Required Properties:
+- compatible: Should be one of:
+ - "ti,omap3-vp" - for OMAP3 family of devices
+ - "ti,omap4-vp" - for OMAP4 family of devices
+ - "ti,omap5-vp" - for OMAP5 family of devices
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ - "base-address" - contains base address of VP module
+ - "int-address" - contains base address of interrupt register for VP
module
+- clocks: should point to the clock node used by VC module, usually sysclk
+- ti,min-micro-volts - SoC supported min operational voltage in micro-volts
+- ti,max-micro-volts - SoC supported max operational voltage in micro-volts
+- ti,min-step-micro-volts - SoC supported min operational voltage steps in
micro-volts
+- ti,max-step-micro-volts - SoC supported max operational voltage steps in
micro-volts
+- ti,tranxdone-status-mask: Mask to the int-register to write-to-clear mask
+ indicating VP has completed operation in sending command to Voltage
Controller.
+- ti,vc-channel - phandle to the Voltage Controller Channel device used by
this Voltage
+ Processor.
+Example:
+vp_mpu: vp@0x4a307b58 {
+ compatible = "ti,omap4-vp";
+
+ reg = <0x4a307b58 0x18>, <0x4A306014 0x4>;
+ reg-names = "base-address", "int-address";
+ ti,tranxdone-status-mask=<0x20>;
+
+ clocks = <_in>;
+
+ ti,vc-channel = <_mpu>;
+ ti,min-step-micro-volts = <1>;
+ ti,max-step-micro-volts = <5>;
+ ti,min-micro-volts = <75>;
+ ti,max-micro-volts = <141>;
+};
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
index 95d5f59..535cab5 100644
--- a/drivers/power/avs/Makefile
+++ b/drivers/power/avs/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_POWER_AVS_OMAP)+= smartreflex.o
ifneq ($(CONFIG_POWER_TI_HARDWARE_VOLTAGE_CONTROL),)
# OMAP Common
-omap-volt-common = omap_vc.o
+omap-volt-common = omap_vc.o omap_vp.o
# OMAP SoC specific
ifneq ($(CONFIG_ARCH_OMAP3),)
diff --git a/drivers/power/avs/omap_vp.c b/drivers/power/avs/omap_vp.c
new file
Re: [PATCH v5 0/5] clk: implement remuxing during set_rate
On 21 June 2013 18:04, Mike Turquette wrote: > Quoting James Hogan (2013-06-13 09:05:57) >> This patchset adds support for automatic selection of the best parent >> for a clock mux, i.e. the one which can provide the closest clock rate >> to that requested. It can be disabled by a new CLK_SET_RATE_NO_REPARENT >> flag (which is set for all uses of clk_register_mux(). >> >> This works by way of adding a new op, determine_rate, similar to >> round_rate but with an extra parameter to allow the clock driver to >> optionally select a different parent clock. This is used in >> clk_calc_new_rates to decide whether to initiate a set_parent operation. > > Hi James, > > I'm going to hold off on this one for 3.11. I'll revisit it after the > next merge window. Okay, no worries. Thanks James -- 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 0/2] Delay initializing of large sections of memory
On 6/21/2013 12:00 PM, Yinghai Lu wrote: > On Fri, Jun 21, 2013 at 11:44 AM, Greg Kroah-Hartman > wrote: >> On Fri, Jun 21, 2013 at 11:36:21AM -0700, Yinghai Lu wrote: >>> On Fri, Jun 21, 2013 at 9:25 AM, Nathan Zimmer wrote: This rfc patch set delays initializing large sections of memory until we have started cpus. This has the effect of reducing startup times on large memory systems. On 16TB it can take over an hour to boot and most of that time is spent initializing memory. >>> >>> One hour on system with 16T ram? BIOS or OS? >>> >>> I use wall clock to check bootime on one system with 3T and 16 pcie cards, >>> Linus only takes about 3m and 30 seconds from bootloader. >>> >>> wonder if you boot delay is with so many cpu get onlined in serialized mode. >>> >>> so can you try boot your system with "maxcpus=128" to get the boot time with >>> wall clock ? >> >> Why use the "wall clock" when we have the wonderful bootchart tools and >> scripts that do this all for you, and can tell you exactly what part of >> the kernel is taking what time, to help with fixing issues like this? > > bootchart is not completed. > > printk timestamp come after mem get initialized. > > [0.004000] tsc: Fast TSC calibration using PIT > > before that stamp are all 0. > > Yinghai > On UV the system console function has an option to include timestamps, both sequential in HH:MM:SS and deltas to 100ms. So we get both the BIOS and system times before printk time is active. We also have a custom "script" command that adds timing info. -- 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][GIT PULL] trace,x86: Move creation of irq tracepoints from apic.c to irq.c
On Fri, 2013-06-21 at 14:13 -0700, H. Peter Anvin wrote: > On 06/21/2013 02:09 PM, Steven Rostedt wrote: > > Call Trace: > > [] do_fork+0xa8/0x260 > > [] ? trace_preempt_on+0x2a/0x2f > > [] ? trace_hardirqs_on_thunk+0x3a/0x3f > > This bit of the call chain seems a little odd, no? Doesn't the "?" mean its just in the stack but not part of the call frame that was used. CONFIG_FRAME_POINTER is set in the config. With lockdep and preempt tracing enabled, why would this seem strange? -- 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/
[RFC PATCH V2 2/8] PM / AVS: Introduce support for OMAP Voltage Controller(VC) with device tree nodes
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI custom hardware block to better facilitate and standardize integration of Power Management ICs which communicate over I2C called Voltage Controller(VC). This is an specialized hardware block meant to support PMIC chips and is customized to that requirement. Even though it functions as an I2C controller, it is a write-only interface whose configurations are custom to PMICs. We have an existing implementation in mach-omap2 which has been re factored and moved out as a separate driver. This new driver is DT only and the separation was meant to get a maintainable driver which does not have to deal with legacy platform_data dependencies. The legacy driver is retained to support non-DT boot and functionality will be migrated to the DT-only version as we enable features. Currently, this implementation considers only the basic steps needed for voltage scaling and exposing voltage controller as a device whose child devices are voltage controller channel devices. We may need to do additional timing configurations to enable Low power mode voltage transitions, but this will be completed in a following series. We may need a few tweaks to hook the Adaptive Voltage Scaling(AVS) implementation for OMAP which also uses the same voltage controller to talk to PMICs. This driver is meant to interface with voltage processor when the voltage processor attempts devm_omap_vc_channel_get for the VC channel corresponding to the voltage processor. [grygorii.stras...@ti.com, ta...@ti.com: co-developer] Signed-off-by: Grygorii Strashko Signed-off-by: Taras Kondratiuk Signed-off-by: Nishanth Menon --- .../devicetree/bindings/power/omap-vc.txt | 99 ++ drivers/power/avs/Kconfig | 15 + drivers/power/avs/Makefile | 20 + drivers/power/avs/omap_vc.c| 1513 drivers/power/avs/omap_vc.h| 67 + 5 files changed, 1714 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/omap-vc.txt create mode 100644 drivers/power/avs/omap_vc.c create mode 100644 drivers/power/avs/omap_vc.h diff --git a/Documentation/devicetree/bindings/power/omap-vc.txt b/Documentation/devicetree/bindings/power/omap-vc.txt new file mode 100644 index 000..f97737c --- /dev/null +++ b/Documentation/devicetree/bindings/power/omap-vc.txt @@ -0,0 +1,99 @@ +Voltage Controller driver for Texas Instruments OMAP SoCs + +Voltage Controller Properties: +The following are the properties of the voltage controller node +Required Properties: +- compatible: Should be one of: + - "ti,omap3-vc" - for OMAP3 family of devices + - "ti,omap4-vc" - for OMAP4 family of devices + - "ti,omap5-vc" - for OMAP5 family of devices +- reg: Address and length of the register set for the device. It contains + the information of registers in the same order as described by reg-names +- reg-names: Should contain the reg names + - "base-address" - contains base address of VC module +- clocks: should point to the clock node used by VC module, usually sysclk +- ti,i2c-clk-scl-low: is mandatory if ti,i2c-pad-load is not used. contains + hex to represent timing for slow I2C phase low clock time. +- ti,i2c-clk-scl-high: is mandatory if ti,i2c-pad-load is not used. contains + hex to represent timing for slow I2C phase high clock time. +- ti,i2c-clk-hsscl-low: is mandatory if ti,i2c-pad-load is not used and + ti,i2c-high-speed is used, contains hex to represent timing for high speed I2C + phase low clock time. +- ti,i2c-clk-hsscl-high: is mandatory if ti,i2c-pad-load is not used and + ti,i2c-high-speed is used, contains hex to represent timing for high speed I2C + phase high clock time. +- Must contain VC channel nodes which belong to the Voltage controller. + +Optional Properties: +- ti,i2c-high-speed: bool to indicate if VC should operate in high speed I2C + mode. +- ti,i2c-pad-load: if ti,i2c-high-speed, then this is optional to auto load + pre-calculated I2C clock timing configuration. This is denoted in pico-farads. +- ti,i2c-pcb-length: if ti,i2c-pad-load, then this is optional to select the + pre-calculated I2C clock timing configuration. default of '63' is used. + This is denoted in millimeters. +- pinctrl: Most OMAP SoCs do not allow pinctrl option to select VC's I2C path. + it is usually hardcoded by default. Define "default" pinctrl-0 as needed. + +Voltage Controller Channel Properties: +The following are the properties of the voltage controller channel nodes +Required Properties: +- compatible: Should be one of: + - ti,omap3-vc-channel-0 - Channel 0 on OMAP3 family of devices + - ti,omap3-vc-channel-1 - Channel 1 on OMAP3 family of devices + - ti,omap4-vc-channel-mpu - Channel MPU on OMAP4 family of devices + - ti,omap4-vc-channel-iva - Channel IVA on OMAP4 family of devices + - ti,omap4-vc-channel-core - Channel CORE on OMAP4 family of
[RFC PATCH V2 8/8] ARM: dts: OMAP4-panda-es: use tps regulator as cpu0 supply
TPS62361 is used for cpufreq regulation. As part of this change
use labels that can be used to reference cpu0 to setup it's supply.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4-panda-es.dts |4
arch/arm/boot/dts/omap4.dtsi |4 ++--
arch/arm/boot/dts/omap443x.dtsi |2 +-
arch/arm/boot/dts/omap4460.dtsi |2 +-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 325816c..d2ce518 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -93,3 +93,7 @@
>;
gpios = < 7 GPIO_ACTIVE_HIGH>;
};
+
+ {
+ cpu0-supply = <_tps62361>;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3c75b23..127b974 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -24,13 +24,13 @@
};
cpus {
- cpu@0 {
+ cpu0: cpu@0 {
compatible = "arm,cortex-a9";
next-level-cache = <>;
clocks = <_mpu>;
clock-names = "cpu";
};
- cpu@1 {
+ cpu1: cpu@1 {
compatible = "arm,cortex-a9";
next-level-cache = <>;
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index e759937..91a5f70 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
- cpu@0 {
+ cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points = <
/* kHzuV */
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 8320865..9827e35 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
- cpu@0 {
+ cpu0: cpu@0 {
operating-points = <
/* kHzuV */
35 1025000
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][GIT PULL] trace,x86: Move creation of irq tracepoints from apic.c to irq.c
On Fri, 2013-06-21 at 17:09 -0400, Steven Rostedt wrote: > On Fri, 2013-06-21 at 13:31 -0400, Steven Rostedt wrote: > > > My testing also triggered another bug, but I'm not sure it's related to > > these patches or something that already existed. I'm currently > > investigating it now. > > > I haven't been able to reproduce it. Correction, I am able to reproduce it. The trick is I need to kick off the test as soon as I get a login prompt, as the gui is still coming up (this time the crash happened on pulseaudio). The test suite runs the test when it detects the login. I was trying to reproduce it manually, which was well after login was set up. I'll try to make sure I can reproduce it consistently, or at least in a short number of tries. And then remove all the patches and see if I can still trigger it. -- 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/
[RFC PATCH V2 4/8] ARM: dts: OMAP4: add voltage controller nodes
OMAP443x, OMAP446x SoC use same offsets for voltage controller,
however their voltage characteristics differ a little.
Introduce the voltage controller nodes for the same.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4.dtsi| 26 ++
arch/arm/boot/dts/omap443x.dtsi | 15 +++
arch/arm/boot/dts/omap4460.dtsi | 16
3 files changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3b44546..a153e8d 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -104,6 +104,11 @@
ti,hwmods = "counter_32k";
};
+ sysclk_in: sys_clkin {
+ #clock-cells = <0>;
+ compatible = "ti,omap-clock";
+ };
+
dpll_mpu: dpll_mpu {
#clock-cells = <0>;
compatible = "ti,omap-clock";
@@ -663,5 +668,26 @@
ram-bits = <12>;
ti,has-mailbox;
};
+
+ vc: vc@0x4A307B88 {
+ compatible = "ti,omap4-vc";
+ clocks = <_in>;
+ reg = <0x4A307B88 0x40>;
+ reg-names = "base-address";
+
+ ti,i2c-high-speed; /* belongs to board file */
+ vc_mpu: vc_mpu {
+ compatible = "ti,omap4-vc-channel-mpu";
+ ti,master-channel;
+ };
+
+ vc_iva: vc_iva {
+ compatible = "ti,omap4-vc-channel-iva";
+ };
+
+ vc_core: vc_core {
+ compatible = "ti,omap4-vc-channel-core";
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..2b0deb5 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -31,3 +31,18 @@
compatible = "ti,omap4430-bandgap";
};
};
+
+_mpu {
+ ti,retention-micro-volts = <75>;
+ ti,off-micro-volts = <0>;
+};
+
+_iva {
+ ti,retention-micro-volts = <75>;
+ ti,off-micro-volts = <0>;
+};
+
+_core {
+ ti,retention-micro-volts = <75>;
+ ti,off-micro-volts = <0>;
+};
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..16210a1 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -39,3 +39,19 @@
gpios = < 22 0>; /* tshut */
};
};
+
+_mpu {
+ ti,retention-micro-volts = <75>;
+ /* Erratum i738: Reliability impact work around */
+ ti,off-micro-volts = <75>;
+};
+
+_iva {
+ ti,retention-micro-volts = <75>;
+ ti,off-micro-volts = <0>;
+};
+
+_core {
+ ti,retention-micro-volts = <75>;
+ ti,off-micro-volts = <0>;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] hrtimers: provide a hrtimers_late_resume() call
On Fri, 21 Jun 2013, David Vrabel wrote:
> On 21/06/13 15:32, Thomas Gleixner wrote:
> However, since hrtimers require the use of a one-shot ticker and when
> one-shot timers are resumed they are armed to fire immediately (see
> tick_resume_oneshot()) this interrupt is sufficient to kick the require
> softirq.
>
> So, as proposed before:
>
> hrtimers_resume()
> {
>/* This CPU's tick is armed to fire immediately by
> tick_oneshot_resume(). Just need raise a softirq to program
> the timers on all CPUs. */
>cpu_base->clock_was_set = 1;
>__raise_softirq_irqoff(HRTIMER_SOFTIRQ);
> }
>
> Do you agree or disagree?
Fair enough. I did not think about that. With the comment in place it
is clear. It might be a bit more elaborate for the casual reader.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: power-efficient scheduling design
On 21 June 2013 16:38, Arjan van de Ven wrote: > On 6/21/2013 1:50 AM, Morten Rasmussen wrote: >> A hint when a task is moved to a new cpu is too late if the migration >> shouldn't have happened at all. If the scheduler knows that the cpu is >> able to switch to a higher p-state it can decide to wait for the p-state >> change instead of migrating the task and waking up another cpu. > > oops sorry I misread your mail (lack of early coffee I suppose) > > I can see your point of having a thing for "did we ask for all the performance > we could ask for" prior to doing a load balance (although, for power > efficiency, > if you have two tasks that could run in parallel, it's usually better to > run them in parallel... so likely we should balance anyway) Not necessarily, especially if parallel running implies powering up a full cluster just for one CPU (it depends on the hardware but for example a cluster may not be able to go in deeper sleep states unless all the CPUs in that cluster are idle). -- Catalin -- 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 0/2] Delay initializing of large sections of memory
On 6/21/2013 11:36 AM, Yinghai Lu wrote: > On Fri, Jun 21, 2013 at 9:25 AM, Nathan Zimmer wrote: >> This rfc patch set delays initializing large sections of memory until we have >> started cpus. This has the effect of reducing startup times on large memory >> systems. On 16TB it can take over an hour to boot and most of that time >> is spent initializing memory. > > One hour on system with 16T ram? BIOS or OS? The BIOS is about 20 minutes *before* the 1+ hour. (When we started this UV project way back when, 8TB took over 4 hours before we threw in the towel.) > > I use wall clock to check bootime on one system with 3T and 16 pcie cards, > Linus only takes about 3m and 30 seconds from bootloader. I can send some stats on where various delays are but most of it was in memory initialization. On average UV nodes carry 128 or 256G per node, so 12 nodes would take about 3 or 4 minutes, perhaps more. > > wonder if you boot delay is with so many cpu get onlined in serialized mode. Nope. If that was the case, delaying memory but initializing all the cpus would not affect the time. > > so can you try boot your system with "maxcpus=128" to get the boot time with > wall clock ? We could try if you really think it will provide any useful info. Not sure exactly how having memory on nodes with no active cpus will react. > > Thanks > > Yinghai > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3/RESEND 4/4] clocksource: arch_timer: Add support for memory mapped timers
On Fri, 21 Jun 2013, Stephen Boyd wrote:
> /*
> * Architected system timer support.
> @@ -46,13 +73,69 @@ static bool arch_timer_use_virtual = true;
> static inline void arch_timer_reg_write(int access, int reg, u32 val,
> struct clock_event_device *clk)
> {
> - arch_timer_reg_write_cp15(access, reg, val);
> + if (access == ARCH_TIMER_MEM_PHYS_ACCESS) {
> + struct arch_timer *timer = to_arch_timer(clk);
> + switch (reg) {
> + case ARCH_TIMER_REG_CTRL:
> + writel_relaxed(val, timer->base + CNTP_CTL);
> + break;
> + case ARCH_TIMER_REG_TVAL:
> + writel_relaxed(val, timer->base + CNTP_TVAL);
> + break;
> + default:
> + BUILD_BUG();
So you are relying on the compiler cleverness to identify a caller
which calls that inline with a not supported reg value.
How does that work, when the compiler decides not to inline that?
enum without a default case emits at least a reliable warning.
> + }
> + } else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
> + struct arch_timer *timer = to_arch_timer(clk);
> + switch (reg) {
> + case ARCH_TIMER_REG_CTRL:
> + writel_relaxed(val, timer->base + CNTV_CTL);
> + break;
> + case ARCH_TIMER_REG_TVAL:
> + writel_relaxed(val, timer->base + CNTV_TVAL);
> + break;
> + default:
> + BUILD_BUG();
> + }
> + } else {
> + arch_timer_reg_write_cp15(access, reg, val);
> + }
> }
Something in my little brain yells: function pointer
You can't be serious about hacking nested if/else/switch constructs
into a hot path.
Why not making your cpu data:
struct arch_timer {
struct clock_event_device evt;
void (*write_ctrl)(val, timer);
void (*write_tval)(val, timer);
}
and get rid of all that conditionals?
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Make non-linear GPIO ranges accesible from gpiolib
On 06/20/2013 05:57 AM, Christian Ruppert wrote:
> Hello Stephen,
>
> On Wed, Jun 19, 2013 at 12:27:56PM -0600, Stephen Warren wrote:
>> On 06/19/2013 12:10 PM, Stephen Warren wrote:
>>> On 06/14/2013 03:12 AM, Christian Ruppert wrote:
On Thu, Jun 13, 2013 at 03:38:09PM -0600, Stephen Warren wrote:
> On 06/13/2013 06:55 AM, Christian Ruppert wrote:
>> [...]
> The potential advantage of this patch is that the pinctrl-side of the
> mapping can be a group name rather than pin IDs, which might reduce the
> size of the mapping list if you have an extremely sparse or non-linear
> mapping /and/ parts of that mapping just happen to align with the pin
> groups in the pin controller HW, since each entry in the gpio-ranges
> property can be sparse/non-linear, rather than being a small linear
> chunk of the mapping.
Pin controller authors have the freedom to define pin groups just for
the purpose of "predefining" the pinctrl side of GPIO ranges.
>>>
>>> Hmm. I suppose that's true. I'm not sure how enthusiastic I am about
>>> doing this though... The reason I'm unsure is because it starts using
>>> pin groups from something other than groups of pins in HW that are all
>>> affected by the same mux or config bits in a register, and starts using
>>> pin groups for something else; GPIO<->pinmux pins mapping. Perhaps it's
>>> OK though, considering the other abuses of pin groups that are already
>>> present, such as using pin groups to represent default/common uses of
>>> groups of pins that don't actually exist in HW.
>
> The reason for these "abuses" might just be that every company (or maybe
> even hardware team) has a different understanding of how pin muxing
> should be implemented in hardware. There are probably as many different
> pin muxing architectures out there as companies (maybe even more).
> Finding a "one size fits all"-approach to this is extremely difficult
> and driver authors adapt the kernel infrastructure as well as they can
> to the hardware they have. As an example, see below for a fundamental
> cultural difference between your hardware/integration team and ours.
The issues I'm talking about are more SW issues; people have created
"pin groups" that represent both a set of pins/groups *and* the function
the is muxed onto them (and perhaps pin config settings too), rather
than having the driver create "pin groups" that actually represent just
groups of pins, and then using the DT pinctrl bindings as intended to
select which mux/config settings to use for that group.
>> I've realized what I don't like about this.
>>
>> Pin groups are supposed to be something that represents some property of
>> the pinctrl HW itself. So, if you have register "X" bits 3-0 that define
>> the mux function for pins 8, 9, 10, and 11, then there really is a pin
>> group that exists in HW, and that pin group will still exist with that
>> same definition no matter what SoC you put the pinctrl HW into. If this
>> changes, it's not the same pinctrl HW module.
>
> Let me see if I get this right (Let's take the example in the section
> "What is pinmuxing" of Documentation/pinctrl.txt in Linux-3.10-rc6 which
> is similar to TB10x):
> If I understand you correctly, you define two pin groups in this
> example:
> gpr1 = {A5, A6, A7, A8, B5};
> grp2 = {A1, B1, C1, D1, E1, F1, G1, G2, G3, G4, H1};
>
> grp1 has three configurations: allgpio, i2c and spi
> grp2 has five configurations: allgpio, mmc2, mmc2_spi, mmc4, mmc4_spi, mmc8
No, I don't think so at all.
When I pushed for the concept of groups, I intended it to mean precisely
one single thing. The points below describe this.
1) A pin is a single pin/ball/pad on the package.
2) Some register fields affect just a single pin. For example, there may
be a register field that affects pin A8's mux setting only.
3) Some register fields affect multiple pins at once. For example,
perhaps one register field affects both pin A8's an pin A7's mux setting
at once.
4) Depending on HW design, all register fields might be of type
described at (2) above, or all of the type described at (3) above, or a
mixture of both. Tegra is a mixture.
5) I expect the concept of a pin group to solely represent the various
groups of pins affected by each register field; in (2) above one pin per
group, in (3) above many pins per group.
Thus, to my mind, a pin group is purely a HW concept, and dictated
purely by HW design.
> Let's assume that unused pins are automatically configured as GPIOs in
> each configuration. The pin controller thus requires a second list of
> pins (for each of the modes), defining for which pins in each group it
> can grant gpio_requests in a given mode. Furthermore, the mmc node will
> have to "know" if mode "mmc2" or "mmc2_spi" must be selected for a given
> setup, making the thing somewhat unorthogonal.
The Linux pinctrl subsystem specifically doesn't provide mutual
exclusion between "mux function" and GPIO usage within a pin
Re: [PATCH 04/11] tracing: fix disabling of soft disable
On Fri, 2013-06-21 at 16:39 -0400, Steven Rostedt wrote: > On Fri, 2013-06-21 at 20:12 +0900, Masami Hiramatsu wrote: > > (2013/06/21 3:31), Tom Zanussi wrote: > > > The comment on the soft disable 'disable' case of > > > __ftrace_event_enable_disable() states that the soft disable bit > > > should be cleared in that case, but currently only the soft mode bit > > > is actually cleared. > > > > > > This essentially leaves the standard non-soft-enable enable/disable > > > paths as the only way to clear the soft disable flag, but the soft > > > disable bit should also be cleared when removing a trigger with '!'. > > > > Indeed, the soft-disabled flag may remain after the event itself > > disabled. However that soft-disabled flag will be cleared when > > the event is re-enabled. it seems no bad side-effect. > > > > Thus I doubt this patch is separately required. I guess this is > > required for adding new trigger flag, isn't it? :) > > Tom, I'm guessing Masami is correct here. It's needed for the trigger > work to work, correct? > Well, the trigger should really work without this - this is basically just a cleanup I added because it bothered me that I couldn't completely revert the enable state back to the original state that existed before I added the trigger (by reverting the trigger using '!'). It also just seemed obviously correct from looking at the code as well (though I agree, it's hard to keep the state machine of that function in your head in order to prove it correct, and the straggling soft-disable state hasn't bothered anyone until now, so maybe it's not worth it..) In any case, if the SOFT_DISABLED bit is erroneously set but there are no triggers, it shouldn't be a problem, since the trigger calls would just return immediately, so not having this patch wouldn't break anything... Tom > Either way, I probably could add it as a clean up patch regardless. I'll > just have to test the hell out of it some more, as the accounting for > soft-disable vs real disable was a PITA. > > -- 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/
Re: [PATCH][GIT PULL] trace,x86: Move creation of irq tracepoints from apic.c to irq.c
On 06/21/2013 02:09 PM, Steven Rostedt wrote: > Call Trace: > [] do_fork+0xa8/0x260 > [] ? trace_preempt_on+0x2a/0x2f > [] ? trace_hardirqs_on_thunk+0x3a/0x3f This bit of the call chain seems a little odd, no? -hpa -- 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] vfio: Limit group opens
vfio_group_fops_open attempts to limit concurrent sessions by
disallowing opens once group->container is set. This really doesn't
do what we want and allow for inconsistent behavior, for instance a
group can be opened twice, then a container set giving the user two
file descriptors to the group. But then it won't allow more to be
opened. There's not much reason to have the group opened multiple
times since most access is through devices or the container, so
complete what the original code intended and only allow a single
instance.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 6d78736..d30f44d 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -76,6 +76,7 @@ struct vfio_group {
struct notifier_block nb;
struct list_headvfio_next;
struct list_headcontainer_next;
+ atomic_topened;
};
struct vfio_device {
@@ -206,6 +207,7 @@ static struct vfio_group *vfio_create_group(struct
iommu_group *iommu_group)
INIT_LIST_HEAD(>device_list);
mutex_init(>device_lock);
atomic_set(>container_users, 0);
+ atomic_set(>opened, 0);
group->iommu_group = iommu_group;
group->nb.notifier_call = vfio_iommu_group_notifier;
@@ -1236,12 +1238,22 @@ static long vfio_group_fops_compat_ioctl(struct file
*filep,
static int vfio_group_fops_open(struct inode *inode, struct file *filep)
{
struct vfio_group *group;
+ int opened;
group = vfio_group_get_from_minor(iminor(inode));
if (!group)
return -ENODEV;
+ /* Do we need multiple instances of the group open? Seems not. */
+ opened = atomic_cmpxchg(>opened, 0, 1);
+ if (opened) {
+ vfio_group_put(group);
+ return -EBUSY;
+ }
+
+ /* Is something still in use from a previous open? */
if (group->container) {
+ atomic_dec(>opened);
vfio_group_put(group);
return -EBUSY;
}
@@ -1259,6 +1271,8 @@ static int vfio_group_fops_release(struct inode *inode,
struct file *filep)
vfio_group_try_dissolve_container(group);
+ atomic_dec(>opened);
+
vfio_group_put(group);
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/
[PATCH] vfio/type1: Fix missed frees and zero sized removes
With hugepage support we can only properly aligned and sized ranges.
We only guarantee that we can unmap the same ranges mapped and not
arbitrary sub-ranges. This means we might not free anything or might
free more than requested. The vfio unmap interface started storing
the unmapped size to return to userspace to handle this. This patch
fixes a few places where we don't properly handle those cases, moves
a memory allocation to a place where failure is an option and checks
our loops to make sure we don't get into an infinite loop trying to
remove an overlap.
Signed-off-by: Alex Williamson
---
drivers/vfio/vfio_iommu_type1.c | 77 +--
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 8a2be4e..98231d1 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -370,6 +370,9 @@ static int vfio_remove_dma_overlap(struct vfio_iommu
*iommu, dma_addr_t start,
struct vfio_dma *split;
int ret;
+ if (!*size)
+ return 0;
+
/*
* Existing dma region is completely covered, unmap all. This is
* the likely case since userspace tends to map and unmap buffers
@@ -411,7 +414,9 @@ static int vfio_remove_dma_overlap(struct vfio_iommu
*iommu, dma_addr_t start,
dma->vaddr += overlap;
dma->size -= overlap;
vfio_insert_dma(iommu, dma);
- }
+ } else
+ kfree(dma);
+
*size = overlap;
return 0;
}
@@ -425,48 +430,41 @@ static int vfio_remove_dma_overlap(struct vfio_iommu
*iommu, dma_addr_t start,
if (ret)
return ret;
- /*
-* We may have unmapped the entire vfio_dma if the user is
-* trying to unmap a sub-region of what was originally
-* mapped. If anything left, we can resize in place since
-* iova is unchanged.
-*/
- if (overlap < dma->size)
- dma->size -= overlap;
- else
- vfio_remove_dma(iommu, dma);
-
+ dma->size -= overlap;
*size = overlap;
return 0;
}
/* Split existing */
+ split = kzalloc(sizeof(*split), GFP_KERNEL);
+ if (!split)
+ return -ENOMEM;
+
offset = start - dma->iova;
ret = vfio_unmap_unpin(iommu, dma, start, size);
if (ret)
return ret;
- WARN_ON(!*size);
+ if (!*size) {
+ kfree(split);
+ return -EINVAL;
+ }
+
tmp = dma->size;
- /*
-* Resize the lower vfio_dma in place, insert new for remaining
-* upper segment.
-*/
+ /* Resize the lower vfio_dma in place, before the below insert */
dma->size = offset;
- if (offset + *size < tmp) {
- split = kzalloc(sizeof(*split), GFP_KERNEL);
- if (!split)
- return -ENOMEM;
-
+ /* Insert new for remainder, assuming it didn't all get unmapped */
+ if (likely(offset + *size < tmp)) {
split->size = tmp - offset - *size;
split->iova = dma->iova + offset + *size;
split->vaddr = dma->vaddr + offset + *size;
split->prot = dma->prot;
vfio_insert_dma(iommu, split);
- }
+ } else
+ kfree(split);
return 0;
}
@@ -483,7 +481,7 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
if (unmap->iova & mask)
return -EINVAL;
- if (unmap->size & mask)
+ if (!unmap->size || unmap->size & mask)
return -EINVAL;
WARN_ON(mask & PAGE_MASK);
@@ -493,7 +491,7 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
while ((dma = vfio_find_dma(iommu, unmap->iova, unmap->size))) {
size = unmap->size;
ret = vfio_remove_dma_overlap(iommu, unmap->iova, , dma);
- if (ret)
+ if (ret || !size)
break;
unmapped += size;
}
@@ -635,7 +633,6 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
if (tmp && tmp->prot == prot &&
tmp->vaddr + tmp->size == vaddr) {
tmp->size += size;
-
iova = tmp->iova;
size = tmp->size;
vaddr = tmp->vaddr;
@@ -643,19 +640,28 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
}
}
- /* Check if we abut a region above - nothing above ~0 + 1 */
+ /*
+*
