Re: [PATCH] power: max77693: fix platform_no_drv_owner.cocci warnings
On śro, 2015-01-21 at 12:11 +0800, kbuild test robot wrote:
> drivers/power/max77693_charger.c:747:3-8: No need to set .owner here. The
> core will do it.
>
> Remove .owner field if calls are used which set it automatically
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
>
> CC: Krzysztof Kozlowski
> Signed-off-by: Fengguang Wu
> ---
>
> max77693_charger.c |1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski
>
> --- a/drivers/power/max77693_charger.c
> +++ b/drivers/power/max77693_charger.c
> @@ -744,7 +744,6 @@ MODULE_DEVICE_TABLE(platform, max77693_c
>
> static struct platform_driver max77693_charger_driver = {
> .driver = {
> - .owner = THIS_MODULE,
> .name = "max77693-charger",
> },
> .probe = max77693_charger_probe,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 2/2] ARM: dts: exynos3250-monk: Add regulator-haptic node for haptics
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim
Reviewed-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-monk.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 24822aa..7102d88 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -109,6 +109,13 @@
};
};
};
+
+ haptics {
+ compatible = "regulator-haptic";
+ haptic-supply = <_reg>;
+ min-microvolt = <110>;
+ max-microvolt = <270>;
+ };
};
{
--
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/
[RESEND PATCH] xen/blkfront: increase the default value of xen_blkif_max_segments
The default max-segments of indirect requests was 32, so IO operations with bigger block size(>32*4k) would be split and make performance drop. Nowadays backend device usually support 512k max_sectors_kb on desktop, and usually larger on server machines connected with high-end storage system. The default max size(128k) is not appropriate anymore, this patch increases it to 128(128*4k=512k). Signed-off-by: Bob Liu --- drivers/block/xen-blkfront.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2236c6f..1bf2429 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -94,9 +94,9 @@ static const struct block_device_operations xlvbd_block_fops; * by the backend driver. */ -static unsigned int xen_blkif_max_segments = 32; +static unsigned int xen_blkif_max_segments = 128; module_param_named(max, xen_blkif_max_segments, int, S_IRUGO); -MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 32)"); +MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests (default is 128)"); #define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 5/6] epoll: Add implementation for epoll_mod_wait
On Tue, Jan 20, 2015 at 05:57:57PM +0800, Fam Zheng wrote:
> This syscall is a sequence of
>
> 1) a number of epoll_ctl calls
> 2) a epoll_pwait, with timeout enhancement.
>
> The epoll_ctl operations are embeded so that application doesn't have to use
> separate syscalls to insert/delete/update the fds before poll. It is more
> efficient if the set of fds varies from one poll to another, which is the
> common pattern for certain applications. For example, depending on the input
> buffer status, a data reading program may decide to temporarily not polling an
> fd.
>
> Because the enablement of batching in this interface, even that regular
> epoll_ctl call sequence, which manipulates several fds, can be optimized to
> one
> single epoll_ctl_wait (while specifying spec=NULL to skip the poll part).
>
> The only complexity is returning the result of each operation. For each
> epoll_mod_cmd in cmds, the field "error" is an output field that will be
> stored
> the return code *iff* the command is executed (0 for success and -errno of the
> equivalent epoll_ctl call), and will be left unchanged if the command is not
> executed because some earlier error, for example due to failure of
> copy_from_user to copy the array.
>
> Applications can utilize this fact to do error handling: they could initialize
> all the epoll_mod_wait.error to a positive value, which is by definition not a
> possible output value from epoll_mod_wait. Then when the syscall returned,
> they
> know whether or not the command is executed by comparing each error with the
> init value, if they're different, they have the result of the command.
> More roughly, they can put any non-zero and not distinguish "not run" from
> failure.
>
> Also, timeout parameter is enhanced: timespec is used, compared to the old ms
> scalar. This provides higher precision. The parameter field in struct
> epoll_wait_spec, "clockid", also makes it possible for users to use a
> different
> clock than the default when it makes more sense.
>
> Signed-off-by: Fam Zheng
> ---
> fs/eventpoll.c | 60
>
> include/linux/syscalls.h | 5
> 2 files changed, 65 insertions(+)
>
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index e7a116d..2cc22c9 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -2067,6 +2067,66 @@ SYSCALL_DEFINE6(epoll_pwait, int, epfd, struct
> epoll_event __user *, events,
> sigmask ? : NULL);
> }
>
> +SYSCALL_DEFINE5(epoll_mod_wait, int, epfd, int, flags,
> + int, ncmds, struct epoll_mod_cmd __user *, cmds,
> + struct epoll_wait_spec __user *, spec)
> +{
> + struct epoll_mod_cmd *kcmds = NULL;
> + int i, ret = 0;
> + int cmd_size = sizeof(struct epoll_mod_cmd) * ncmds;
> +
> + if (flags)
> + return -EINVAL;
> + if (ncmds) {
> + if (!cmds)
> + return -EINVAL;
> + kcmds = kmalloc(cmd_size, GFP_KERNEL);
> + if (!kcmds)
> + return -ENOMEM;
> + if (copy_from_user(kcmds, cmds, cmd_size)) {
> + ret = -EFAULT;
> + goto out;
> + }
> + }
> + for (i = 0; i < ncmds; i++) {
> + struct epoll_event ev = (struct epoll_event) {
> + .events = kcmds[i].events,
> + .data = kcmds[i].data,
> + };
> + if (kcmds[i].flags) {
> + kcmds[i].error = ret = -EINVAL;
> + goto out;
> + }
> + kcmds[i].error = ret = ep_ctl_do(epfd, kcmds[i].op,
> kcmds[i].fd, ev);
> + if (ret)
> + goto out;
> + }
> + if (spec) {
> + sigset_t ksigmask;
> + struct epoll_wait_spec kspec;
> + ktime_t timeout;
> +
> + if(copy_from_user(, spec, sizeof(struct epoll_wait_spec)))
> + return -EFAULT;
This should probably be goto out, or you'll leak kcmds.
> + if (kspec.sigmask) {
> + if (kspec.sigsetsize != sizeof(sigset_t))
> + return -EINVAL;
Same here...
> + if (copy_from_user(, kspec.sigmask,
> sizeof(ksigmask)))
> + return -EFAULT;
and here.
> + }
> + timeout = timespec_to_ktime(kspec.timeout);
> + ret = epoll_pwait_do(epfd, kspec.events, kspec.maxevents,
> + kspec.clockid, timeout,
> + kspec.sigmask ? : NULL);
> + }
> +
> +out:
> + if (ncmds && copy_to_user(cmds, kcmds, cmd_size))
> + return -EFAULT;
This will also leak kcmds, it should be ret = -EFAULT. This case, however, seems
to lead to a weird corner case: if cmds is read-only, we'll end up executing
every command but fail to copy out the return values, so when
[PATCH RESEND 0/2] Add regulator-haptic device tree
This patch series adds regulator-haptic device tree in rinato and monk boards. The regulator-haptic has haptic motor and it is controlled by voltage of regulator via force feedback framework. regualtor-haptic driver merged at linux-next ref : https://lkml.org/lkml/2014/12/17/477 Jaewon Kim (2): ARM: dts: exynos3250-rinato: Add regulator-haptic node for haptics ARM: dts: exynos3250-monk: Add regulator-haptic node for haptics arch/arm/boot/dts/exynos3250-monk.dts |7 +++ arch/arm/boot/dts/exynos3250-rinato.dts |7 +++ 2 files changed, 14 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 1/2] ARM: dts: exynos3250-rinato: Add regulator-haptic node for haptics
This patch adds regulator-haptic device node controlled by regulator.
Signed-off-by: Jaewon Kim
Reviewed-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-rinato.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 80aa8b4..0e3d499 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -100,6 +100,13 @@
};
};
};
+
+ haptics {
+ compatible = "regulator-haptic";
+ haptic-supply = <_reg>;
+ min-microvolt = <110>;
+ max-microvolt = <270>;
+ };
};
{
--
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 V3 2/2] devicetree: Add bindings for DA9063
On 20 January 2015 17:04 Lee Jones wrote:
> On Tue, 20 Jan 2015, Lee Jones wrote:
> > On Tue, 20 Jan 2015, Steve Twiss wrote:
> > > From: Steve Twiss
> > >
> > > Add device tree bindings for DA9063 regulators; Real-Time Clock
> > > and Watchdog.
[...]
> This is why in-patch changelogs are helpful. ;)
Will do in-patch changelogs in future.
> Applied now, thanks.
Thanks!
Regards,
Steve
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [LKP] [rcu] 00f5159aeb6: +55.3% will-it-scale.time.involuntary_context_switches
On Wed, Jan 21, 2015 at 03:32:44PM +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> stall.2015.01.06a
> commit 00f5159aeb68f08ce29597be86be87d6db0c1ba1 ("rcu: Run grace-period
> kthreads at real-time priority")
Glad this helps!
However, the version that I am pushing during the upcoming merge window
requires a boot parameter rcutree.kthread_prio= set to a value in the
range 1..99 to have effect. The reason is that we need to focus any
risks from this change on the people needing it.
Thanx, Paul
> testbox/testcase/testparams: lkp-a03/will-it-scale/performance-lock1
>
> e3663b1024d1f946 00f5159aeb68f08ce29597be86
> --
> %stddev %change %stddev
> \ |\
> 11321 ± 5% +55.3% 17582 ± 14%
> will-it-scale.time.involuntary_context_switches
> 28999 ± 44%+109.3% 60700 ± 25% sched_debug.cpu#1.ttwu_count
> 58384 ± 44%+103.6% 118851 ± 24% sched_debug.cpu#1.nr_switches
> 26144 ± 48% +90.3% 49762 ± 26% sched_debug.cpu#1.sched_goidle
>827 ± 34% -57.3%353 ± 21% cpuidle.C2-ATM.usage
> 58976 ± 43%+103.0% 119712 ± 24% sched_debug.cpu#1.sched_count
>503 ± 29% -56.5%219 ± 27% cpuidle.C4-ATM.usage
> 11321 ± 5% +55.3% 17582 ± 14%
> time.involuntary_context_switches
>156 ± 14% -29.6%110 ± 19% cpuidle.POLL.usage
> 50583 ± 2% -21.7% 39630 ± 4% cpuidle.C6-ATM.usage
> 51597156 ± 2% +23.7% 63848564 ± 3% cpuidle.C1E-ATM.time
> 39349 ± 2% -12.0% 34622 ± 2% softirqs.SCHED
> 758790 ± 8% -15.3% 642336 ± 12% sched_debug.cpu#2.sched_count
> 378981 ± 8% -15.6% 319776 ± 12% sched_debug.cpu#2.ttwu_count
> 374440 ± 8% -15.5% 316513 ± 12% sched_debug.cpu#2.ttwu_local
> 5307 ± 0% -1.0% 5255 ± 0% vmstat.system.in
>
> testbox/testcase/testparams: wsm/will-it-scale/performance-open2
>
> e3663b1024d1f946 00f5159aeb68f08ce29597be86
> --
> 22128 ± 3%+120.2% 48719 ± 8%
> will-it-scale.time.involuntary_context_switches
> 5577 ± 45% +1492.2% 88802 ± 33% sched_debug.cpu#6.sched_count
> 5457 ± 46% +1526.2% 88751 ± 33% sched_debug.cpu#6.nr_switches
> 0.45 ± 43% -73.3% 0.12 ± 15% turbostat.%c3
> 10 ± 24% -55.8% 4 ± 40%
> sched_debug.cpu#9.nr_uninterruptible
>147 ± 11% -58.5% 61 ± 32% sched_debug.cpu#11.load
>147 ± 11% -58.5% 61 ± 32% sched_debug.cfs_rq[11]:/.load
> 10821106 ± 39% -59.8%4347430 ± 20% cpuidle.C3-NHM.time
>356 ± 41% +76.6%629 ± 3%
> sched_debug.cfs_rq[6]:/.blocked_load_avg
> 22128 ± 3%+120.2% 48719 ± 8%
> time.involuntary_context_switches
>145 ± 36% -35.9% 93 ± 30% sched_debug.cpu#5.load
>469 ± 29% +55.9%732 ± 4%
> sched_debug.cfs_rq[6]:/.tg_load_contrib
>145 ± 36% -34.0% 95 ± 29% sched_debug.cfs_rq[5]:/.load
> 99 ± 8% -27.8% 72 ± 24% sched_debug.cpu#9.load
> 99 ± 8% -27.8% 72 ± 24% sched_debug.cfs_rq[9]:/.load
> 219871 ± 6% -33.3% 146545 ± 19% sched_debug.cpu#3.ttwu_local
> 224610 ± 6% -31.3% 154342 ± 18% sched_debug.cpu#3.sched_goidle
> 451877 ± 6% -31.1% 311378 ± 18% sched_debug.cpu#3.sched_count
> 451737 ± 6% -31.1% 311279 ± 18% sched_debug.cpu#3.nr_switches
> 225208 ± 6% -31.3% 154688 ± 18% sched_debug.cpu#3.ttwu_count
> 4122 ± 7% -23.6% 3148 ± 17% cpuidle.C3-NHM.usage
> 84 ± 11% -27.4% 61 ± 5% sched_debug.cpu#7.cpu_load[0]
> 154565 ± 2% -29.6% 108768 ± 9% cpuidle.C6-NHM.usage
> 124949 ± 25% +41.4% 176670 ± 15% sched_debug.cpu#2.sched_goidle
> 74177 ± 2% -23.6% 56653 ± 4%
> sched_debug.cpu#3.nr_load_updates
> 79 ± 6% -23.1% 60 ± 5% sched_debug.cpu#7.cpu_load[1]
> 50107 ± 6% -20.9% 39621 ± 7%
> sched_debug.cfs_rq[3]:/.exec_clock
> 76 ± 4% -20.6% 60 ± 6% sched_debug.cpu#7.cpu_load[2]
> 385983 ± 9% -20.4% 307347 ± 12%
> sched_debug.cfs_rq[3]:/.min_vruntime
> 74 ± 2% -18.5% 60 ± 6% sched_debug.cpu#7.cpu_load[3]
> 1.50 ± 6% -10.0% 1.35 ± 9%
> perf-profile.cpu-cycles.selinux_file_free_security.security_file_free.__fput.fput.task_work_run
> 46086 ± 1% -25.7% 34260 ± 5% softirqs.SCHED
> 72 ± 1% -15.9% 60 ± 7% sched_debug.cpu#7.cpu_load[4]
> 74 ± 13% -17.7% 61 ± 2%
>
Re: [PATCH RFC 5/6] epoll: Add implementation for epoll_mod_wait
Hello Fam Zheng,
On 01/21/2015 05:59 AM, Fam Zheng wrote:
> On Tue, 01/20 13:50, Michael Kerrisk (man-pages) wrote:
>> Hello Fam Zheng,
>>
>> On 01/20/2015 10:57 AM, Fam Zheng wrote:
>>> This syscall is a sequence of
>>>
>>> 1) a number of epoll_ctl calls
>>> 2) a epoll_pwait, with timeout enhancement.
>>>
>>> The epoll_ctl operations are embeded so that application doesn't have to use
>>> separate syscalls to insert/delete/update the fds before poll. It is more
>>> efficient if the set of fds varies from one poll to another, which is the
>>> common pattern for certain applications.
>>
>> Which applications? Could we have some specific examples? This is a
>> complex API, and it needs good justification.
>
> OK, I'll explain more in v2.
Okay.
[...]
>>> The only complexity is returning the result of each operation. For each
>>> epoll_mod_cmd in cmds, the field "error" is an output field that will be
>>> stored
>>> the return code *iff* the command is executed (0 for success and -errno of
>>> the
>>> equivalent epoll_ctl call), and will be left unchanged if the command is not
>>> executed because some earlier error, for example due to failure of
>>> copy_from_user to copy the array.
>>>
>>> Applications can utilize this fact to do error handling: they could
>>> initialize
>>> all the epoll_mod_wait.error to a positive value, which is by definition
>>> not a
>>> possible output value from epoll_mod_wait. Then when the syscall returned,
>>> they
>>> know whether or not the command is executed by comparing each error with the
>>> init value, if they're different, they have the result of the command.
>>> More roughly, they can put any non-zero and not distinguish "not run" from
>>> failure.
>>
>> The "cmds' are not executed in a specified order plus the need to
>> initialize the 'errors' fields to a positive value feels a bit ugly.
>> And indeed the whole "command list was only partially run" case
>> is not pretty. Am I correct to understand that if an error is found
>> during execution of one of the "epoll_ctl" commands in 'cmds' then
>> the system call will return -1 with errno set, indicating an error,
>> even though the epoll interest list may have changed because some
>> of the earlier 'cmds' executed successfully? This all seems a bit of
>> a headache for user space.
>
> This is the trade-off for batching. The best we can do is probably make this
> transactional: none or all of the commands succeeds. It will require a much
> more complex implementation, though.
Transactional would be more comfortable for user-space, and while I
can see that it would be complex to implement, perhaps the greater
point might be that the implementation is CPU expensive.
> But even with that, the error reporting on
> which command failed is a complication.
My suggestions below could make the error reporting much simpler...
>> I have a couple of questions:
>>
>> Q1. I can see that batching "epoll_ctl" commands might be useful,
>> since it results in fewer systems calls. But, does it really
>> need to be bound together with the "epoll_pwait" functionality?
>> (Perhaps this point was covered in previous discussions, but
>> neither the message accompanying this patch nor the 0/6 man page
>> provide a compelling rationale for the need to bind these two
>> operations together.)
>>
>> Yes, I realize you might save a system call, but it makes for a
>> cumbersome API that has the above headache, and also forces the
>> need for double pointer indirection in the 'spec' argument (i.e.,
>> spec is a pointer to an array of structures where each element
>> in turn includes an 'events' pointer that points to another array).
>>
>> Why not a simpler API with two syscalls such as:
>>
>> epoll_ctl_batch(int epfd, int flags,
>> int ncmds, struct epoll_mod_cmd *cmds);
>>
>> epoll_pwait1(int epfd, struct epoll_event *events, int maxevents,
>> struct timespec *timeout, int clock_id,
>> const sigset_t *sigmask, size_t sigsetsize);
>
> The problem is that there is no room for flags field in epoll_pwait1, which is
> asked for, in previous discussion thread [1].
Ahh yes, I certainly should not have forgotten that. But that's easily solved.
Do as for pselect6():
strcut sigargs {
const sigset_t *ss;
size_t ss_len; /* Size (in bytes) of object pointed
to by 'ss' */
}
epoll_pwait1(int epfd, struct epoll_event *events, int maxevents,
struct timespec *timeout, int clock_id, int flags,
int timeout,
const struct sigargs *sargs);
> I don't see epoll_mod_wait as a *significantly more* complicated interface
> compared to epoll_ctl_batch and epoll_pwait1 above.
My biggest problem with epoll_ctl_wait() is the complexity of error
handling. epoll_ctl_batch and epoll_pwait1 would simplify that, as I
note below.
Aside from that, I do think that epoll_ctl_wait() passes a certain
threshold of complexity that
[RESEND Patch V2 3/4] xen: use generated hypervisor symbols in arch/x86/xen/trace.c
Instead of manually list all hypervisor calls in arch/x86/xen/trace.c
use the auto generated list.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/xen/trace.c | 50 --
1 file changed, 4 insertions(+), 46 deletions(-)
diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 8296cdf..a702ec2 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -1,54 +1,12 @@
#include
#include
+#include
-#define N(x) [__HYPERVISOR_##x] = "("#x")"
+#define HYPERCALL(x) [__HYPERVISOR_##x] = "("#x")",
static const char *xen_hypercall_names[] = {
- N(set_trap_table),
- N(mmu_update),
- N(set_gdt),
- N(stack_switch),
- N(set_callbacks),
- N(fpu_taskswitch),
- N(sched_op_compat),
- N(dom0_op),
- N(set_debugreg),
- N(get_debugreg),
- N(update_descriptor),
- N(memory_op),
- N(multicall),
- N(update_va_mapping),
- N(set_timer_op),
- N(event_channel_op_compat),
- N(xen_version),
- N(console_io),
- N(physdev_op_compat),
- N(grant_table_op),
- N(vm_assist),
- N(update_va_mapping_otherdomain),
- N(iret),
- N(vcpu_op),
- N(set_segment_base),
- N(mmuext_op),
- N(xsm_op),
- N(nmi_op),
- N(sched_op),
- N(callback_op),
- N(xenoprof_op),
- N(event_channel_op),
- N(physdev_op),
- N(hvm_op),
-
-/* Architecture-specific hypercall definitions. */
- N(arch_0),
- N(arch_1),
- N(arch_2),
- N(arch_3),
- N(arch_4),
- N(arch_5),
- N(arch_6),
- N(arch_7),
+#include
};
-#undef N
+#undef HYPERCALL
static const char *xen_hypercall_name(unsigned op)
{
--
2.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/
[RESEND Patch V2 4/4] xen: use generated hypercall symbols in arch/x86/xen/xen-head.S
Instead of manually list each hypercall in arch/x86/xen/xen-head.S use the auto generated symbol list. This also corrects the wrong address of xen_hypercall_mca which was located 32 bytes higher than it should. Symbol addresses have been verified to match the correct ones via objdump output. Based-on-patch-by: Jan Beulich Signed-off-by: Juergen Gross Reviewed-by: David Vrabel --- arch/x86/xen/xen-head.S | 63 - 1 file changed, 10 insertions(+), 53 deletions(-) diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S index 674b2225..8afdfcc 100644 --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -12,6 +12,8 @@ #include #include +#include +#include #include #ifdef CONFIG_XEN_PVH @@ -85,59 +87,14 @@ ENTRY(xen_pvh_early_cpu_init) .pushsection .text .balign PAGE_SIZE ENTRY(hypercall_page) -#define NEXT_HYPERCALL(x) \ - ENTRY(xen_hypercall_##x) \ - .skip 32 - -NEXT_HYPERCALL(set_trap_table) -NEXT_HYPERCALL(mmu_update) -NEXT_HYPERCALL(set_gdt) -NEXT_HYPERCALL(stack_switch) -NEXT_HYPERCALL(set_callbacks) -NEXT_HYPERCALL(fpu_taskswitch) -NEXT_HYPERCALL(sched_op_compat) -NEXT_HYPERCALL(platform_op) -NEXT_HYPERCALL(set_debugreg) -NEXT_HYPERCALL(get_debugreg) -NEXT_HYPERCALL(update_descriptor) -NEXT_HYPERCALL(ni) -NEXT_HYPERCALL(memory_op) -NEXT_HYPERCALL(multicall) -NEXT_HYPERCALL(update_va_mapping) -NEXT_HYPERCALL(set_timer_op) -NEXT_HYPERCALL(event_channel_op_compat) -NEXT_HYPERCALL(xen_version) -NEXT_HYPERCALL(console_io) -NEXT_HYPERCALL(physdev_op_compat) -NEXT_HYPERCALL(grant_table_op) -NEXT_HYPERCALL(vm_assist) -NEXT_HYPERCALL(update_va_mapping_otherdomain) -NEXT_HYPERCALL(iret) -NEXT_HYPERCALL(vcpu_op) -NEXT_HYPERCALL(set_segment_base) -NEXT_HYPERCALL(mmuext_op) -NEXT_HYPERCALL(xsm_op) -NEXT_HYPERCALL(nmi_op) -NEXT_HYPERCALL(sched_op) -NEXT_HYPERCALL(callback_op) -NEXT_HYPERCALL(xenoprof_op) -NEXT_HYPERCALL(event_channel_op) -NEXT_HYPERCALL(physdev_op) -NEXT_HYPERCALL(hvm_op) -NEXT_HYPERCALL(sysctl) -NEXT_HYPERCALL(domctl) -NEXT_HYPERCALL(kexec_op) -NEXT_HYPERCALL(tmem_op) /* 38 */ -ENTRY(xen_hypercall_rsvr) - .skip 320 -NEXT_HYPERCALL(mca) /* 48 */ -NEXT_HYPERCALL(arch_1) -NEXT_HYPERCALL(arch_2) -NEXT_HYPERCALL(arch_3) -NEXT_HYPERCALL(arch_4) -NEXT_HYPERCALL(arch_5) -NEXT_HYPERCALL(arch_6) - .balign PAGE_SIZE + .skip PAGE_SIZE + +#define HYPERCALL(n) \ + .equ xen_hypercall_##n, hypercall_page + __HYPERVISOR_##n * 32; \ + .type xen_hypercall_##n, @function; .size xen_hypercall_##n, 32 +#include +#undef HYPERCALL + .popsection ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS, .asciz "linux") -- 2.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/
[RESEND Patch V2 2/4] xen: synchronize include/xen/interface/xen.h with xen
The header include/xen/interface/xen.h doesn't contain all definitions
from Xen's version of that header. Update it accordingly.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/xen/trace.c| 2 +-
include/xen/interface/xen.h | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
index 520022d..8296cdf 100644
--- a/arch/x86/xen/trace.c
+++ b/arch/x86/xen/trace.c
@@ -29,7 +29,7 @@ static const char *xen_hypercall_names[] = {
N(vcpu_op),
N(set_segment_base),
N(mmuext_op),
- N(acm_op),
+ N(xsm_op),
N(nmi_op),
N(sched_op),
N(callback_op),
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index f68719f..a483789 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -67,7 +67,7 @@
#define __HYPERVISOR_vcpu_op 24
#define __HYPERVISOR_set_segment_base 25 /* x86/64 only */
#define __HYPERVISOR_mmuext_op26
-#define __HYPERVISOR_acm_op 27
+#define __HYPERVISOR_xsm_op 27
#define __HYPERVISOR_nmi_op 28
#define __HYPERVISOR_sched_op 29
#define __HYPERVISOR_callback_op 30
@@ -75,7 +75,11 @@
#define __HYPERVISOR_event_channel_op 32
#define __HYPERVISOR_physdev_op 33
#define __HYPERVISOR_hvm_op 34
+#define __HYPERVISOR_sysctl 35
+#define __HYPERVISOR_domctl 36
+#define __HYPERVISOR_kexec_op 37
#define __HYPERVISOR_tmem_op 38
+#define __HYPERVISOR_xc_reserved_op 39 /* reserved for XenClient */
/* Architecture-specific hypercall definitions. */
#define __HYPERVISOR_arch_0 48
--
2.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/
[RESEND Patch V2 0/4] xen: auto-generate symbols for xen hypercalls
The Xen hypercalls are defined in include/xen/interface/xen.h. There are some places where for each hypercall a table element is created. Instead of manually add each hypercall element to these tables use an auto generated header built during the make process of the kernel. Changes in V2: - add "autogenerated" comment to generated header file as suggested by David Vrabel (patch 1) - some minor adjustments to patch 4 as suggested by David Vrabel Juergen Gross (4): xen: build infrastructure for generating hypercall depending symbols xen: synchronize include/xen/interface/xen.h with xen xen: use generated hypervisor symbols in arch/x86/xen/trace.c xen: use generated hypercall symbols in arch/x86/xen/xen-head.S arch/x86/syscalls/Makefile | 9 +++ arch/x86/xen/trace.c| 50 +++ arch/x86/xen/xen-head.S | 63 +++-- include/xen/interface/xen.h | 6 - scripts/xen-hypercalls.sh | 12 + 5 files changed, 40 insertions(+), 100 deletions(-) create mode 100644 scripts/xen-hypercalls.sh -- 2.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/
[RESEND Patch V2 1/4] xen: build infrastructure for generating hypercall depending symbols
Today there are several places in the kernel which build tables
containing one entry for each possible Xen hypercall. Create an
infrastructure to be able to generate these tables at build time.
Based-on-patch-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/syscalls/Makefile | 9 +
scripts/xen-hypercalls.sh | 12
2 files changed, 21 insertions(+)
create mode 100644 scripts/xen-hypercalls.sh
diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile
index 3323c27..a55abb9 100644
--- a/arch/x86/syscalls/Makefile
+++ b/arch/x86/syscalls/Makefile
@@ -19,6 +19,9 @@ quiet_cmd_syshdr = SYSHDR $@
quiet_cmd_systbl = SYSTBL $@
cmd_systbl = $(CONFIG_SHELL) '$(systbl)' $< $@
+quiet_cmd_hypercalls = HYPERCALLS $@
+ cmd_hypercalls = $(CONFIG_SHELL) '$<' $@ $(filter-out $<,$^)
+
syshdr_abi_unistd_32 := i386
$(uapi)/unistd_32.h: $(syscall32) $(syshdr)
$(call if_changed,syshdr)
@@ -47,10 +50,16 @@ $(out)/syscalls_32.h: $(syscall32) $(systbl)
$(out)/syscalls_64.h: $(syscall64) $(systbl)
$(call if_changed,systbl)
+$(out)/xen-hypercalls.h: $(srctree)/scripts/xen-hypercalls.sh
+ $(call if_changed,hypercalls)
+
+$(out)/xen-hypercalls.h: $(srctree)/include/xen/interface/xen*.h
+
uapisyshdr-y += unistd_32.h unistd_64.h unistd_x32.h
syshdr-y += syscalls_32.h
syshdr-$(CONFIG_X86_64)+= unistd_32_ia32.h unistd_64_x32.h
syshdr-$(CONFIG_X86_64)+= syscalls_64.h
+syshdr-$(CONFIG_XEN) += xen-hypercalls.h
targets+= $(uapisyshdr-y) $(syshdr-y)
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 000..676d922
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+ eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+ END { print "/* auto-generated by scripts/xen-hypercall.sh */"
+ for (i in v) if (!(v[i] in v))
+ print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
--
2.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: [PATCH v3 2/3] mfd: lubbock_io: add lubbock_io board
Russell King - ARM Linux writes: > What I'd suggest (and always have done) is: > > dev_err(>dev, "couldn't request main irq%d: %d\n", > irq, ret); I like it, it's even more compact, I'll use it for next patch version. > but I guess printing the IRQ number no longer makes sense with todays > dynamic mapping of logical IRQ numbers, as it is no longer meaningful. Yes ... we're not yet there with pxa gpio interrupts, maybe it will come eventually one day. For Lee: > > > platform_get_irq()? > > No. I need the flags. > Where are they used? A couple of lines below, using local "irqflags" variable : ret = devm_request_irq(>dev, cot->irq, lubbock_irq_handler, irqflags, dev_name(>dev), cot); Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/filemap_xip.c between commit de1414a654e6 ("fs: export inode_to_bdi
and use it in favor of mapping->backing_dev_info") from the block tree
and commit cd5ca6e1eb43 ("dax,ext2: replace XIP read and write with DAX
I/O") from the akpm tree.
I fixed it up (the latter removed the code modified by the former) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp3cfXzUalgf.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 1/6] mfd: rtsx: add func to split u32 into register
On Tue, 20 Jan 2015, Ulf Hansson wrote:
> On 20 January 2015 at 15:47, Lee Jones wrote:
> > On Tue, 23 Dec 2014, micky_ch...@realsil.com.cn wrote:
> >
> >> From: Micky Ching
> >>
> >> Add helper function to write u32 to registers, if we want to put u32
> >> value to 4 continuous register, this can help us reduce tedious work.
> >>
> >> Signed-off-by: Micky Ching
> >> Acked-by: Lee Jones
> >> ---
> >> include/linux/mfd/rtsx_pci.h | 9 +
> >> 1 file changed, 9 insertions(+)
> >
> > Applied, thanks.
>
> This one has already been queued by you, for 3.19, and it's in Linus tree. :-)
>
> For your reference, I have queued the mmc patches which depends on
> $subject patch for 3.20.
I discovered this myself when I attempted to apply it. :)
Thanks for the heads-up though.
> >> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
> >> index 74346d5..9234449 100644
> >> --- a/include/linux/mfd/rtsx_pci.h
> >> +++ b/include/linux/mfd/rtsx_pci.h
> >> @@ -558,6 +558,7 @@
> >> #define SD_SAMPLE_POINT_CTL 0xFDA7
> >> #define SD_PUSH_POINT_CTL0xFDA8
> >> #define SD_CMD0 0xFDA9
> >> +#define SD_CMD_START 0x40
> >> #define SD_CMD1 0xFDAA
> >> #define SD_CMD2 0xFDAB
> >> #define SD_CMD3 0xFDAC
> >> @@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct
> >> rtsx_pcr *pcr)
> >> return (u8 *)(pcr->host_cmds_ptr);
> >> }
> >>
> >> +static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
> >> val)
> >> +{
> >> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val >> 24);
> >> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val >> 16);
> >> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val >> 8);
> >> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
> >> +}
> >> +
> >> #endif
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sound fixes for 3.19-rc6
Linus, please pull sound fixes for v3.19-rc6 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.19-rc6 The topmost commit is 6455931186bff407493135e74c5f32efd30860e2 sound fixes for 3.19-rc6 This batch contains two fixes for FireWire lib module and a quirk for yet another Logitech WebCam. The former is the fixes for MIDI handling I forgot to pick up during the merge window. All the fixed code is pretty local and shouldn't give any regressions. Clemens Ladisch (2): ALSA: firewire-lib: remove rx_blocks_for_midi quirk ALSA: firewire-lib: limit the MIDI data rate Jason Lee Cragg (1): ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210 --- sound/firewire/amdtp.c | 71 + sound/firewire/amdtp.h | 5 +- sound/firewire/bebob/bebob_stream.c | 7 --- sound/firewire/fireworks/fireworks_stream.c | 5 -- sound/usb/mixer.c | 1 + 5 files changed, 65 insertions(+), 24 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/
[PATCH] selftests/exec: Check if the syscall exists and bail if not
On systems which don't implement sys_execveat(), this test produces a
lot of output.
Add a check at the beginning to see if the syscall is present, and if
not just note one error and return.
Signed-off-by: Michael Ellerman
---
tools/testing/selftests/exec/execveat.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/exec/execveat.c
b/tools/testing/selftests/exec/execveat.c
index e238c9559caf..b87e4a843bea 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
@@ -234,6 +234,14 @@ static int run_tests(void)
int fd_cloexec = open_or_die("execveat", O_RDONLY|O_CLOEXEC);
int fd_script_cloexec = open_or_die("script", O_RDONLY|O_CLOEXEC);
+ /* Check if we have execveat at all, and bail early if not */
+ errno = 0;
+ execveat_(-1, NULL, NULL, NULL, 0);
+ if (errno == -ENOSYS) {
+ printf("[FAIL] ENOSYS calling execveat - no kernel support?\n");
+ return 1;
+ }
+
/* Change file position to confirm it doesn't affect anything */
lseek(fd, 10, SEEK_SET);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: rtsx_usb: Fix runtime PM deadlock
On Wed, 21 Jan 2015, Roger Tseng wrote:
> On Tue, 2015-01-20 at 16:07 +, Lee Jones wrote:
> > On Tue, 20 Jan 2015, Roger Tseng wrote:
> >
> > > On Mon, 2015-01-19 at 09:45 +, Lee Jones wrote:
> > > > On Thu, 15 Jan 2015, Roger Tseng wrote:
> > > >
> > > > > sd_set_power_mode() in derived module
> > > > > drivers/mmc/host/rtsx_usb_sdmmc.c
> > > > > acquires dev_mutex and then calls pm_runtime_get_sync() to make sure
> > > > > the
> > > > > device is awake while initializing a newly inserted card. Once it is
> > > > > called during suspending state and explicitly before
> > > > > rtsx_usb_suspend()
> > > > > acquires the same dev_mutex, both routine deadlock and further hang
> > > > > the
> > > > > driver because pm_runtime_get_sync() waits the pending PM operations.
> > > > >
> > > > > Fix this by using an empty suspend method. mmc_core always turns the
> > > > > LED off after a request is done and thus it is ok to remove the only
> > > > > rtsx_usb_turn_off_led() here.
> > > > >
> > > > > Cc: # v3.16+
> > > > > Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver")
> > > > > Signed-off-by: Roger Tseng
> > > > > ---
> > > > > drivers/mfd/rtsx_usb.c | 9 -
> > > > > 1 file changed, 9 deletions(-)
> > > >
> > > > Applied, thanks.
> > > >
> > > I'm sorry but build bot from Intel just reported me that I forgot to
> > > delete an unused variable "ucr" between two commits. My bad.
> > >
> > > Do I have a chance to send v2?
> >
> > You're lucky I'm in a good mood. ;)
> >
> > I fixed it already.
> >
> That's great, thanks! And thus patch 2/2 also needs to be changed
> accordingly.
>
> By the way, the build bot reported again about an undefined variable
> build error in 2/2(I'm sorry for this again). I put the overall updated
> content of 2/2 here for you if you're going to fix it, or I can also
> re-send it individually.
Please re-send this patch and prefix it with [OVERWRITE].
In future make sure you test your submission thoroughly prior to
sending, as my time is very limited and with all due respect I could
make better use of it than this.
> diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> index 210d1f85679e..ede50244f265 100644
> --- a/drivers/mfd/rtsx_usb.c
> +++ b/drivers/mfd/rtsx_usb.c
> @@ -681,9 +681,27 @@ static void rtsx_usb_disconnect(struct
> usb_interface *intf)
> #ifdef CONFIG_PM
> static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t
> message)
> {
> + struct rtsx_ucr *ucr =
> + (struct rtsx_ucr *)usb_get_intfdata(intf);
> + u16 val = 0;
> +
> dev_dbg(>dev, "%s called with pm message 0x%04x\n",
> __func__, message.event);
>
> + if (PMSG_IS_AUTO(message)) {
> + if (mutex_trylock(>dev_mutex)) {
> + rtsx_usb_get_card_status(ucr, );
> + mutex_unlock(>dev_mutex);
> +
> + /* Defer the autosuspend if card exists */
> + if (val & (SD_CD | MS_CD))
> + return -EAGAIN;
> + } else {
> + /* There is an ongoing operation*/
> + return -EAGAIN;
> + }
> + }
> +
> return 0;
> }
>
>
>
> > > > > diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> > > > > index dbdd0faeb6ce..076694126e5d 100644
> > > > > --- a/drivers/mfd/rtsx_usb.c
> > > > > +++ b/drivers/mfd/rtsx_usb.c
> > > > > @@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface
> > > > > *intf, pm_message_t message)
> > > > > dev_dbg(>dev, "%s called with pm message 0x%04x\n",
> > > > > __func__, message.event);
> > > > >
> > > > > - /*
> > > > > - * Call to make sure LED is off during suspend to save more
> > > > > power.
> > > > > - * It is NOT a permanent state and could be turned on anytime
> > > > > later.
> > > > > - * Thus no need to call turn_on when resunming.
> > > > > - */
> > > > > - mutex_lock(>dev_mutex);
> > > > > - rtsx_usb_turn_off_led(ucr);
> > > > > - mutex_unlock(>dev_mutex);
> > > > > -
> > > > > return 0;
> > > > > }
> > > > >
> > > >
> > >
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[LKP] [rcu] 00f5159aeb6: +55.3% will-it-scale.time.involuntary_context_switches
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
stall.2015.01.06a
commit 00f5159aeb68f08ce29597be86be87d6db0c1ba1 ("rcu: Run grace-period
kthreads at real-time priority")
testbox/testcase/testparams: lkp-a03/will-it-scale/performance-lock1
e3663b1024d1f946 00f5159aeb68f08ce29597be86
--
%stddev %change %stddev
\ |\
11321 ± 5% +55.3% 17582 ± 14%
will-it-scale.time.involuntary_context_switches
28999 ± 44%+109.3% 60700 ± 25% sched_debug.cpu#1.ttwu_count
58384 ± 44%+103.6% 118851 ± 24% sched_debug.cpu#1.nr_switches
26144 ± 48% +90.3% 49762 ± 26% sched_debug.cpu#1.sched_goidle
827 ± 34% -57.3%353 ± 21% cpuidle.C2-ATM.usage
58976 ± 43%+103.0% 119712 ± 24% sched_debug.cpu#1.sched_count
503 ± 29% -56.5%219 ± 27% cpuidle.C4-ATM.usage
11321 ± 5% +55.3% 17582 ± 14% time.involuntary_context_switches
156 ± 14% -29.6%110 ± 19% cpuidle.POLL.usage
50583 ± 2% -21.7% 39630 ± 4% cpuidle.C6-ATM.usage
51597156 ± 2% +23.7% 63848564 ± 3% cpuidle.C1E-ATM.time
39349 ± 2% -12.0% 34622 ± 2% softirqs.SCHED
758790 ± 8% -15.3% 642336 ± 12% sched_debug.cpu#2.sched_count
378981 ± 8% -15.6% 319776 ± 12% sched_debug.cpu#2.ttwu_count
374440 ± 8% -15.5% 316513 ± 12% sched_debug.cpu#2.ttwu_local
5307 ± 0% -1.0% 5255 ± 0% vmstat.system.in
testbox/testcase/testparams: wsm/will-it-scale/performance-open2
e3663b1024d1f946 00f5159aeb68f08ce29597be86
--
22128 ± 3%+120.2% 48719 ± 8%
will-it-scale.time.involuntary_context_switches
5577 ± 45% +1492.2% 88802 ± 33% sched_debug.cpu#6.sched_count
5457 ± 46% +1526.2% 88751 ± 33% sched_debug.cpu#6.nr_switches
0.45 ± 43% -73.3% 0.12 ± 15% turbostat.%c3
10 ± 24% -55.8% 4 ± 40%
sched_debug.cpu#9.nr_uninterruptible
147 ± 11% -58.5% 61 ± 32% sched_debug.cpu#11.load
147 ± 11% -58.5% 61 ± 32% sched_debug.cfs_rq[11]:/.load
10821106 ± 39% -59.8%4347430 ± 20% cpuidle.C3-NHM.time
356 ± 41% +76.6%629 ± 3%
sched_debug.cfs_rq[6]:/.blocked_load_avg
22128 ± 3%+120.2% 48719 ± 8% time.involuntary_context_switches
145 ± 36% -35.9% 93 ± 30% sched_debug.cpu#5.load
469 ± 29% +55.9%732 ± 4%
sched_debug.cfs_rq[6]:/.tg_load_contrib
145 ± 36% -34.0% 95 ± 29% sched_debug.cfs_rq[5]:/.load
99 ± 8% -27.8% 72 ± 24% sched_debug.cpu#9.load
99 ± 8% -27.8% 72 ± 24% sched_debug.cfs_rq[9]:/.load
219871 ± 6% -33.3% 146545 ± 19% sched_debug.cpu#3.ttwu_local
224610 ± 6% -31.3% 154342 ± 18% sched_debug.cpu#3.sched_goidle
451877 ± 6% -31.1% 311378 ± 18% sched_debug.cpu#3.sched_count
451737 ± 6% -31.1% 311279 ± 18% sched_debug.cpu#3.nr_switches
225208 ± 6% -31.3% 154688 ± 18% sched_debug.cpu#3.ttwu_count
4122 ± 7% -23.6% 3148 ± 17% cpuidle.C3-NHM.usage
84 ± 11% -27.4% 61 ± 5% sched_debug.cpu#7.cpu_load[0]
154565 ± 2% -29.6% 108768 ± 9% cpuidle.C6-NHM.usage
124949 ± 25% +41.4% 176670 ± 15% sched_debug.cpu#2.sched_goidle
74177 ± 2% -23.6% 56653 ± 4% sched_debug.cpu#3.nr_load_updates
79 ± 6% -23.1% 60 ± 5% sched_debug.cpu#7.cpu_load[1]
50107 ± 6% -20.9% 39621 ± 7% sched_debug.cfs_rq[3]:/.exec_clock
76 ± 4% -20.6% 60 ± 6% sched_debug.cpu#7.cpu_load[2]
385983 ± 9% -20.4% 307347 ± 12%
sched_debug.cfs_rq[3]:/.min_vruntime
74 ± 2% -18.5% 60 ± 6% sched_debug.cpu#7.cpu_load[3]
1.50 ± 6% -10.0% 1.35 ± 9%
perf-profile.cpu-cycles.selinux_file_free_security.security_file_free.__fput.fput.task_work_run
46086 ± 1% -25.7% 34260 ± 5% softirqs.SCHED
72 ± 1% -15.9% 60 ± 7% sched_debug.cpu#7.cpu_load[4]
74 ± 13% -17.7% 61 ± 2%
sched_debug.cfs_rq[7]:/.runnable_load_avg
65 ± 2% +16.9% 76 ± 4% sched_debug.cpu#1.cpu_load[3]
1.94 ± 5% -9.9% 1.74 ± 6%
perf-profile.cpu-cycles.security_file_free.__fput.fput.task_work_run.do_notify_resume
58851 ± 1% +20.5% 70942 ± 9% sched_debug.cfs_rq[1]:/.exec_clock
69880 ± 1% -16.9% 58047 ± 11% sched_debug.cpu#7.nr_load_updates
60 ± 5% +9.5% 66 ± 3% sched_debug.cpu#9.cpu_load[4]
12064 ± 7% +12.4% 13561 ± 5% slabinfo.kmalloc-64.num_objs
[LKP] [fs] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 5dc5218840e1268de639150a851978bb19c341df ("fs: create proper filename
objects using getname_kernel()")
[ 16.813397] 010f 65536 ram15 (driver?)
[ 16.815041] fc00 268435456 vda driver: virtio_blk
[ 16.816777] fc10 268435456 vdb driver: virtio_blk
[ 16.818544] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)
[ 16.819520] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.19.0-rc5-next-20150120-g5d0eebb #799
[ 16.819520] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[ 16.819520] 8800076a 880006f47db8 81b7a16b
810cf061
[ 16.819520] 81fd6ce5 880006f47e38 81b749fd
822459b0
[ 16.819520] 8810 880006f47e48 880006f47de8
003500626476
[ 16.819520] Call Trace:
[ 16.819520] [] dump_stack+0x4c/0x65
[ 16.819520] [] ? console_unlock+0x398/0x3c7
[ 16.819520] [] panic+0xc9/0x1f7
[ 16.819520] [] mount_block_root+0x201/0x218
[ 16.819520] [] mount_root+0x13f/0x14a
[ 16.819520] [] ? initrd_load+0x2d7/0x2e6
[ 16.819520] [] prepare_namespace+0x16d/0x1a6
[ 16.819520] [] kernel_init_freeable+0x268/0x278
[ 16.819520] [] ? rest_init+0xca/0xca
[ 16.819520] [] kernel_init+0xe/0xda
[ 16.819520] [] ret_from_fork+0x7c/0xb0
[ 16.819520] [] ? rest_init+0xca/0xca
[ 16.819520] Kernel Offset: 0x0 from 0x8100 (relocation range:
0x8000-0x9fff)
Elapsed time: 20
Thanks,
Huang, Ying
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.16.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACC
Re: [PATCH 1/2] printk: Add dummy routine for when CONFIG_PRINTK=n
On Tue, 2015-01-20 at 18:51 -0500, Pranith Kumar wrote: > There are missing dummy routines for log_buf_addr_get() and log_buf_len_get() > for when CONFIG_PRINTK is not set causing build failures. > > This patch adds these dummy routines at the appropriate location. > > Signed-off-by: Pranith Kumar > CC: Michael Ellerman Are folks on CC happy if we take this via the powerpc tree? Apologies for not getting it right the first time. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/page-writeback.c: In function 'account_page_cleared':
mm/page-writeback.c:2122:23: error: 'struct address_space' has no member named
'backing_dev_info'
dec_bdi_stat(mapping->backing_dev_info,
^
Caused by commit d475bc581640 ("page_writeback: cleanup mess around
cancel_dirty_page()") (hmm, that commit has no Signed-off-by from
Andrew?) interacting with commit b83ae6d42143 ("fs: remove
mapping->backing_dev_info") from the block tree.
I have applied the following fix patch:
From: Stephen Rothwell
Date: Wed, 21 Jan 2015 18:23:41 +1100
Subject: [PATCH] fs: remove mapping->backing_dev_info fix
Signed-off-by: Stephen Rothwell
---
mm/page-writeback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index a8397a6923be..ab922616e522 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2119,7 +2119,7 @@ void account_page_cleared(struct page *page, struct
address_space *mapping)
{
if (mapping_cap_account_dirty(mapping)) {
dec_zone_page_state(page, NR_FILE_DIRTY);
- dec_bdi_stat(mapping->backing_dev_info,
+ dec_bdi_stat(inode_to_bdi(mapping->host),
BDI_RECLAIMABLE);
task_io_account_cancelled_write(PAGE_CACHE_SIZE);
}
--
2.1.4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp1VaNjylXJe.pgp
Description: OpenPGP digital signature
Re: RCU CPU stall console spews leads to soft lockup disabled is reasonable ?
On 2015/1/21 15:02, Paul E. McKenney wrote:
> On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
>> On 2015/1/21 11:13, Zhang Zhen wrote:
>>> On 2015/1/21 10:26, Zhang Zhen wrote:
On 2015/1/20 23:25, Don Zickus wrote:
>
> [ . . . ]
>
>>> Sorry, i made a mistake, the log above is based on v3.10.63.
>>> I have tested the latest upstream kernel (based on ec6f34e5b552),
>>> but my test case can't triggered RCU stall warning.
>>>
>>
>> I used git bisect to find the bad commit, but found a irrelevant
>> commit(db5d711e2db776 zram: avoid null access when fail to alloc meta).
>> Before this commit, my test case can easily trigger RCU stall warning,
>> but after this commit, my test case can't trigger RCU stall warning.
>
> I have lost track of exactly what kernel you are using. If you are
> using a recent kernel (v3.18 or thereabouts), one thing to try is to
> apply my stack of RCU CPU stall-warning changes that are on their way
> in, please see v3.19-rc1..630181c4a915 in -rcu, which is at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>
> These handle the problems that Dave Jones and a few others located this
> past December. Could you please give them a spin?
>
Ok, i will try.
Thanks!
> Thanx, Paul
>
>> I'm totally confused.
>>
>> My test case:
>>
>> //
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> struct foo {
>> int a;
>> char b;
>> long c;
>> };
>>
>> struct foo gbl_foo = {1, 'a', 2};
>> struct foo *pgbl_foo = _foo;
>>
>> static int my_kthread(void *data)
>> {
>> DEFINE_SPINLOCK(foo_mutex);
>> struct foo *new_fp;
>> struct foo *old_fp;
>>
>> new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
>> spin_lock(_mutex);
>> old_fp = pgbl_foo;
>> *new_fp = *old_fp;
>> new_fp->a = 2;
>> rcu_assign_pointer(pgbl_foo, new_fp);
>> spin_unlock(_mutex);
>> synchronize_rcu();
>> kfree(old_fp);
>>
>> return 0;
>> }
>>
>> static int hello_start(void)
>> {
>> struct task_struct *my_task = NULL;
>> DEFINE_SPINLOCK(hello_lock);
>>
>> my_task = kthread_run(my_kthread, NULL, "my_thread%d", 1);
>>
>> spin_lock_init(_lock);
>> spin_lock(_lock);
>> spin_lock(_lock);
>> return 0;
>> }
>>
>> static int __init test_init(void)
>> {
>> hello_start();
>>
>> printk(KERN_INFO "Module init\n");
>> return 0;
>> }
>>
>> static void __exit test_exit(void)
>> {
>> printk(KERN_INFO "Module exit!\n");
>> }
>>
>> module_init(test_init)
>> module_exit(test_exit)
>> MODULE_LICENSE("GPL");
>> //
>
> Cheers,
> Don
>
> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> index 70bf118..833c015 100644
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@ -209,7 +209,7 @@ void touch_nmi_watchdog(void)
>* going off.
>*/
> raw_cpu_write(watchdog_nmi_touch, true);
> - touch_softlockup_watchdog();
> + //touch_softlockup_watchdog();
> }
> EXPORT_SYMBOL(touch_nmi_watchdog);
>
>
> .
>
>>>
>>
>>
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with the block tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in
mm/filemap.c and mm/truncate.c between commit de1414a654e6 ("fs: export
inode_to_bdi and use it in favor of mapping->backing_dev_info") from
the tree and commit d475bc581640 ("page_writeback: cleanup mess around
cancel_dirty_page()") from the akpm-current tree.
I fixed it up (the latter removed the code modified by the former) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpVVzCBoQ8K_.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
mm/swap.c between commit 97b713ba3eba ("fs: kill BDI_CAP_SWAP_BACKED")
from the block tree and commit f69ec11fad9f ("rmap: drop support of
non-linear mappings") from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/swap.c
index 4e0109a2f37b,5b3087228b99..
--- a/mm/swap.c
+++ b/mm/swap.c
@@@ -1138,10 -1138,10 +1138,8 @@@ void __init swap_setup(void
#ifdef CONFIG_SWAP
int i;
- for (i = 0; i < MAX_SWAPFILES; i++) {
- if (bdi_init(swapper_spaces[0].backing_dev_info))
- panic("Failed to init swap bdi");
+ for (i = 0; i < MAX_SWAPFILES; i++)
spin_lock_init(_spaces[i].tree_lock);
- INIT_LIST_HEAD(_spaces[i].i_mmap_nonlinear);
- }
#endif
/* Use a smaller cluster for small-memory machines */
pgpS7jOUPVpVB.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH 0/5] Second attempt at contained helper execution
On Fri, 2015-01-16 at 10:25 -0500, J. Bruce Fields wrote: > On Fri, Jan 16, 2015 at 09:01:13AM +0800, Ian Kent wrote: > > On Thu, 2015-01-15 at 11:27 -0500, J. Bruce Fields wrote: > > > On Thu, Jan 15, 2015 at 08:26:12AM +0800, Ian Kent wrote: > > > > On Wed, 2015-01-14 at 17:10 -0500, J. Bruce Fields wrote: > > > > > > On Wed, Jan 14, 2015 at 05:32:22PM +0800, Ian Kent wrote: > > > > > > > There are other difficulties to tackle as well, such as how to > > > > > > > decide > > > > > > > if contained helper execution is needed. For example, if a mount > > > > > > > has > > > > > > > been propagated to a container or bound into the container tree > > > > > > > (such > > > > > > > as with the --volume option of "docker run") the root init > > > > > > > namespace > > > > > > > may need to be used and not the container namespace. > > > > > > > > > > I think you have to go through each of the existing upcall examples > > > > > and > > > > > decide what's needed for each. > > > > > > > > > > At least for the nfsv4 idmapper I would've thought the namespace the > > > > > mount was done in would be the right choice, hence my previous > > > > > question. > > > > > > > > Probably but you don't necessarily know what namespace the mount was > > > > done in. It may have been propagated from another namespace or (although > > > > I don't think it works yet) bound from another container using the > > > > volumes-from docker option. > > > > > > Name-id mappings should be associated with the superblock, I guess--so > > > don't you store a pointer to the right thing there? > > > > Quite possibly but my original point was, without an acceptable > > mechanism to execute the helper we can't know what might need to be done > > to use it. > > At least for me it would be easier to review if it came with at least > one example user. Haven't seen any negative responses but perhaps people are still away over Xmas. In the mean time it's probably a good idea to add some use cases to the series in case the approach is OK. I'll have a look at the nfsd code and see if I can spot the places. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: RCU CPU stall console spews leads to soft lockup disabled is reasonable ?
On Wed, Jan 21, 2015 at 02:54:05PM +0800, Zhang Zhen wrote:
> On 2015/1/21 11:13, Zhang Zhen wrote:
> > On 2015/1/21 10:26, Zhang Zhen wrote:
> >> On 2015/1/20 23:25, Don Zickus wrote:
[ . . . ]
> > Sorry, i made a mistake, the log above is based on v3.10.63.
> > I have tested the latest upstream kernel (based on ec6f34e5b552),
> > but my test case can't triggered RCU stall warning.
> >
>
> I used git bisect to find the bad commit, but found a irrelevant
> commit(db5d711e2db776 zram: avoid null access when fail to alloc meta).
> Before this commit, my test case can easily trigger RCU stall warning,
> but after this commit, my test case can't trigger RCU stall warning.
I have lost track of exactly what kernel you are using. If you are
using a recent kernel (v3.18 or thereabouts), one thing to try is to
apply my stack of RCU CPU stall-warning changes that are on their way
in, please see v3.19-rc1..630181c4a915 in -rcu, which is at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
These handle the problems that Dave Jones and a few others located this
past December. Could you please give them a spin?
Thanx, Paul
> I'm totally confused.
>
> My test case:
>
> //
> #include
> #include
> #include
> #include
> #include
>
> struct foo {
> int a;
> char b;
> long c;
> };
>
> struct foo gbl_foo = {1, 'a', 2};
> struct foo *pgbl_foo = _foo;
>
> static int my_kthread(void *data)
> {
> DEFINE_SPINLOCK(foo_mutex);
> struct foo *new_fp;
> struct foo *old_fp;
>
> new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
> spin_lock(_mutex);
> old_fp = pgbl_foo;
> *new_fp = *old_fp;
> new_fp->a = 2;
> rcu_assign_pointer(pgbl_foo, new_fp);
> spin_unlock(_mutex);
> synchronize_rcu();
> kfree(old_fp);
>
> return 0;
> }
>
> static int hello_start(void)
> {
> struct task_struct *my_task = NULL;
> DEFINE_SPINLOCK(hello_lock);
>
> my_task = kthread_run(my_kthread, NULL, "my_thread%d", 1);
>
> spin_lock_init(_lock);
> spin_lock(_lock);
> spin_lock(_lock);
> return 0;
> }
>
> static int __init test_init(void)
> {
> hello_start();
>
> printk(KERN_INFO "Module init\n");
> return 0;
> }
>
> static void __exit test_exit(void)
> {
> printk(KERN_INFO "Module exit!\n");
> }
>
> module_init(test_init)
> module_exit(test_exit)
> MODULE_LICENSE("GPL");
> //
> >>>
> >>> Cheers,
> >>> Don
> >>>
> >>> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
> >>> index 70bf118..833c015 100644
> >>> --- a/kernel/watchdog.c
> >>> +++ b/kernel/watchdog.c
> >>> @@ -209,7 +209,7 @@ void touch_nmi_watchdog(void)
> >>>* going off.
> >>>*/
> >>> raw_cpu_write(watchdog_nmi_touch, true);
> >>> - touch_softlockup_watchdog();
> >>> + //touch_softlockup_watchdog();
> >>> }
> >>> EXPORT_SYMBOL(touch_nmi_watchdog);
> >>>
> >>>
> >>> .
> >>>
> >>
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: rtsx_usb: Fix runtime PM deadlock
On Tue, 2015-01-20 at 16:07 +, Lee Jones wrote:
> On Tue, 20 Jan 2015, Roger Tseng wrote:
>
> > On Mon, 2015-01-19 at 09:45 +, Lee Jones wrote:
> > > On Thu, 15 Jan 2015, Roger Tseng wrote:
> > >
> > > > sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
> > > > acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
> > > > device is awake while initializing a newly inserted card. Once it is
> > > > called during suspending state and explicitly before rtsx_usb_suspend()
> > > > acquires the same dev_mutex, both routine deadlock and further hang the
> > > > driver because pm_runtime_get_sync() waits the pending PM operations.
> > > >
> > > > Fix this by using an empty suspend method. mmc_core always turns the
> > > > LED off after a request is done and thus it is ok to remove the only
> > > > rtsx_usb_turn_off_led() here.
> > > >
> > > > Cc: # v3.16+
> > > > Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver")
> > > > Signed-off-by: Roger Tseng
> > > > ---
> > > > drivers/mfd/rtsx_usb.c | 9 -
> > > > 1 file changed, 9 deletions(-)
> > >
> > > Applied, thanks.
> > >
> > I'm sorry but build bot from Intel just reported me that I forgot to
> > delete an unused variable "ucr" between two commits. My bad.
> >
> > Do I have a chance to send v2?
>
> You're lucky I'm in a good mood. ;)
>
> I fixed it already.
>
That's great, thanks! And thus patch 2/2 also needs to be changed
accordingly.
By the way, the build bot reported again about an undefined variable
build error in 2/2(I'm sorry for this again). I put the overall updated
content of 2/2 here for you if you're going to fix it, or I can also
re-send it individually.
diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index 210d1f85679e..ede50244f265 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -681,9 +681,27 @@ static void rtsx_usb_disconnect(struct
usb_interface *intf)
#ifdef CONFIG_PM
static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t
message)
{
+ struct rtsx_ucr *ucr =
+ (struct rtsx_ucr *)usb_get_intfdata(intf);
+ u16 val = 0;
+
dev_dbg(>dev, "%s called with pm message 0x%04x\n",
__func__, message.event);
+ if (PMSG_IS_AUTO(message)) {
+ if (mutex_trylock(>dev_mutex)) {
+ rtsx_usb_get_card_status(ucr, );
+ mutex_unlock(>dev_mutex);
+
+ /* Defer the autosuspend if card exists */
+ if (val & (SD_CD | MS_CD))
+ return -EAGAIN;
+ } else {
+ /* There is an ongoing operation*/
+ return -EAGAIN;
+ }
+ }
+
return 0;
}
> > > > diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> > > > index dbdd0faeb6ce..076694126e5d 100644
> > > > --- a/drivers/mfd/rtsx_usb.c
> > > > +++ b/drivers/mfd/rtsx_usb.c
> > > > @@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface
> > > > *intf, pm_message_t message)
> > > > dev_dbg(>dev, "%s called with pm message 0x%04x\n",
> > > > __func__, message.event);
> > > >
> > > > - /*
> > > > -* Call to make sure LED is off during suspend to save more
> > > > power.
> > > > -* It is NOT a permanent state and could be turned on anytime
> > > > later.
> > > > -* Thus no need to call turn_on when resunming.
> > > > -*/
> > > > - mutex_lock(>dev_mutex);
> > > > - rtsx_usb_turn_off_led(ucr);
> > > > - mutex_unlock(>dev_mutex);
> > > > -
> > > > return 0;
> > > > }
> > > >
> > >
> >
>
--
Best regards,
Roger Tseng
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 10/12] clk: samsung: exynos5433: Add missing clocks for CMU_FSYS domain
Hi Sylwester,
I'm so sorry. I miss adding the version to patch[10-12].
- [PATCH 10/12] clk: samsung: exynos5433: Add missing clocks for CMU_FSYS domain
- [PATCH 11/12] clk: samsung: exynos5433: Add clocks for CMU_G3D domain
- [PATCH 12/12] clk: samsung: exynos5433: Add clocks for CMU_GSCL domain
Best Regards,
Chanwoo Choi
On 01/21/2015 03:51 PM, Chanwoo Choi wrote:
> This patch adds the mux/divider/gate clocks for CMU_FSYS domain which
> contains the clocks of USB/UFS/SDMMC/TSI/PDMA IPs.
>
> Cc: Sylwester Nawrocki
> Cc: Tomasz Figa
> Signed-off-by: Chanwoo Choi
> Acked-by: Inki Dae
> ---
> drivers/clk/samsung/clk-exynos5433.c | 302
> +
> include/dt-bindings/clock/exynos5433.h | 96 ++-
> 2 files changed, 395 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5433.c
> b/drivers/clk/samsung/clk-exynos5433.c
> index e79edd7..fa39e6c 100644
> --- a/drivers/clk/samsung/clk-exynos5433.c
> +++ b/drivers/clk/samsung/clk-exynos5433.c
> @@ -462,6 +462,16 @@ static struct samsung_div_clock top_div_clks[]
> __initdata = {
> DIV(CLK_DIV_SCLK_MMC2_A, "div_sclk_mmc2_a", "mout_sclk_mmc2_b",
> DIV_TOP_FSYS1, 0, 4),
>
> + /* DIV_TOP_FSYS2 */
> + DIV(CLK_DIV_SCLK_PCIE_100, "div_sclk_pcie_100", "mout_sclk_pcie_100",
> + DIV_TOP_FSYS2, 12, 3),
> + DIV(CLK_DIV_SCLK_USBHOST30, "div_sclk_usbhost30",
> + "mout_sclk_usbhost30", DIV_TOP_FSYS2, 8, 4),
> + DIV(CLK_DIV_SCLK_UFSUNIPRO, "div_sclk_ufsunipro",
> + "mout_sclk_ufsunipro", DIV_TOP_FSYS2, 4, 4),
> + DIV(CLK_DIV_SCLK_USBDRD30, "div_sclk_usbdrd30", "mout_sclk_usbdrd30",
> + DIV_TOP_FSYS2, 0, 4),
> +
> /* DIV_TOP_PERIC0 */
> DIV(CLK_DIV_SCLK_SPI1_B, "div_sclk_spi1_b", "div_sclk_spi1_a",
> DIV_TOP_PERIC0, 16, 8),
> @@ -543,12 +553,23 @@ static struct samsung_gate_clock top_gate_clks[]
> __initdata = {
> CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
>
> /* ENABLE_SCLK_TOP_FSYS */
> + GATE(CLK_SCLK_PCIE_100_FSYS, "sclk_pcie_100_fsys", "div_sclk_pcie_100",
> + ENABLE_SCLK_TOP_FSYS, 7, 0, 0),
> GATE(CLK_SCLK_MMC2_FSYS, "sclk_mmc2_fsys", "div_sclk_mmc2_b",
> ENABLE_SCLK_TOP_FSYS, 6, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_SCLK_MMC1_FSYS, "sclk_mmc1_fsys", "div_sclk_mmc1_b",
> ENABLE_SCLK_TOP_FSYS, 5, CLK_SET_RATE_PARENT, 0),
> GATE(CLK_SCLK_MMC0_FSYS, "sclk_mmc0_fsys", "div_sclk_mmc0_b",
> ENABLE_SCLK_TOP_FSYS, 4, CLK_SET_RATE_PARENT, 0),
> + GATE(CLK_SCLK_UFSUNIPRO_FSYS, "sclk_ufsunipro_fsys",
> + "div_sclk_ufsunipro", ENABLE_SCLK_TOP_FSYS,
> + 3, CLK_SET_RATE_PARENT, 0),
> + GATE(CLK_SCLK_USBHOST30_FSYS, "sclk_usbhost30_fsys",
> + "div_sclk_usbhost30", ENABLE_SCLK_TOP_FSYS,
> + 1, CLK_SET_RATE_PARENT, 0),
> + GATE(CLK_SCLK_USBDRD30_FSYS, "sclk_usbdrd30_fsys",
> + "div_sclk_usbdrd30", ENABLE_SCLK_TOP_FSYS,
> + 0, CLK_SET_RATE_PARENT, 0),
>
> /* ENABLE_SCLK_TOP_PERIC */
> GATE(CLK_SCLK_SPI4_PERIC, "sclk_spi4_peric", "div_sclk_spi4_b",
> @@ -1832,10 +1853,45 @@ CLK_OF_DECLARE(exynos5433_cmu_peris,
> "samsung,exynos5433-cmu-peris",
> #define ENABLE_IP_FSYS1 0x0b04
>
> /* list of all parent clock list */
> +PNAME(mout_sclk_ufs_mphy_user_p) = { "fin_pll", "sclk_ufs_mphy", };
> PNAME(mout_aclk_fsys_200_user_p) = { "fin_pll", "div_aclk_fsys_200", };
> +PNAME(mout_sclk_pcie_100_user_p) = { "fin_pll", "sclk_pcie_100_fsys",};
> +PNAME(mout_sclk_ufsunipro_user_p)= { "fin_pll", "sclk_ufsunipro_fsys",};
> PNAME(mout_sclk_mmc2_user_p) = { "fin_pll", "sclk_mmc2_fsys", };
> PNAME(mout_sclk_mmc1_user_p) = { "fin_pll", "sclk_mmc1_fsys", };
> PNAME(mout_sclk_mmc0_user_p) = { "fin_pll", "sclk_mmc0_fsys", };
> +PNAME(mout_sclk_usbhost30_user_p)= { "fin_pll", "sclk_usbhost30_fsys",};
> +PNAME(mout_sclk_usbdrd30_user_p) = { "fin_pll", "sclk_usbdrd30_fsys", };
> +
> +PNAME(mout_phyclk_usbhost30_uhost30_pipe_pclk_user_p)
> + = { "fin_pll", "phyclk_usbhost30_uhost30_pipe_pclk_phy", };
> +PNAME(mout_phyclk_usbhost30_uhost30_phyclock_user_p)
> + = { "fin_pll", "phyclk_usbhost30_uhost30_phyclock_phy", };
> +PNAME(mout_phyclk_usbhost20_phy_hsic1_p)
> + = { "fin_pll", "phyclk_usbhost20_phy_hsic1_phy", };
> +PNAME(mout_phyclk_usbhost20_phy_clk48mohci_user_p)
> + = { "fin_pll", "phyclk_usbhost20_phy_clk48mohci_phy", };
> +PNAME(mout_phyclk_usbhost20_phy_phyclock_user_p)
> + = { "fin_pll", "phyclk_usbhost20_phy_phyclock_phy", };
> +PNAME(mout_phyclk_usbhost20_phy_freeclk_user_p)
> + = { "fin_pll", "phyclk_usbhost20_phy_freeclk_phy", };
>
Re: RCU CPU stall console spews leads to soft lockup disabled is reasonable ?
On 2015/1/21 11:13, Zhang Zhen wrote:
> On 2015/1/21 10:26, Zhang Zhen wrote:
>> On 2015/1/20 23:25, Don Zickus wrote:
>>> On Tue, Jan 20, 2015 at 11:09:19AM +0800, Zhang Zhen wrote:
> Of course back then, touch_nmi_watchdog touched all cpus. So a problem
> like this was masked. I believe this upstream commit 62572e29bc53, solved
> the problem.
Thanks for your suggestion.
Commit 62572e29bc53 changed the semantics of touch_nmi_watchdog and make it
only touch local cpu not every one.
But watchdog_nmi_touch = true only guarantee no hard lockup check on this
cpu.
Commit 62572e29bc53 didn't changed the semantics of
touch_softlockup_watchdog.
>>>
>>> Ah, yes. I reviewed the commit to quickly yesterday. I thought
>>> touch_softlockup_watchdog was called on every cpu and that commit changed
>>> it to the local cpu. But that was incorrect.
>>>
>
> You can apply that commit and see if you if you get both RCU stall
> messages _and_ softlockup messages. I believe that is what you were
> expecting, correct?
>
Correct, i expect i can get both RCU stall messages _and_ softlockup
messages.
I applied that commit, and i only got RCU stall messages.
>>>
>>> Hmm, I believe the act of printing to the console calls touch_nmi_watchdog
>>> which calls touch_softlockup_watchdog. I think that is the problem there.
>>>
>> Yeah, you are right.
>>
>>> This may not cause other problems but what happens if you comment out the
>>> 'touch_softlockup_watchdog' from the touch_nmi_watchdog function like
>>> below (based on latest upstream cb59670870)?
>>>
>>> The idea is that console printing for that cpu won't reset the softlockup
>>> detector. Again other bad things might happen and this patch may not be a
>>> good final solution, but it can help give me a clue about what is going
>>> on.
>>
>> I commented out the 'touch_softlockup_watchdog' from the touch_nmi_watchdog
>> function
>> (based on latest upstream ec6f34e5b552).
>> This triggered RCU stall and softlockup, but softlockup just printk only
>> once.
>> As you mentioned "other bad things" lead to softlockup just printk only once.
>> What's the bad thing ?
>>
>> / #
>> / # echo 60 > /proc/sys/kernel/watchdog_thresh
>> / # busybox insmod softlockup_test.ko &
>> / # [ 39.044058] INFO: rcu_preempt detected stalls on CPUs/tasks: {}
>> (detected by 0, t=21002 jiffies, g=78, c=77, q=4)
>> [ 39.044058] INFO: Stall ended before state dump start
>> [ 102.049045] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=84007 jiffies, g=78, c=77, q=4)
>> [ 102.049045] INFO: Stall ended before state dump start
>> [ 160.482123] BUG: soft lockup - CPU#0 stuck for 134s! [busybox:54]
>> [ 165.054075] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=147012 jiffies, g=78, c=77, q=4)
>> [ 165.054075] INFO: Stall ended before state dump start
>> [ 228.059045] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=210017 jiffies, g=78, c=77, q=4)
>> [ 228.059045] INFO: Stall ended before state dump start
>> [ 291.064099] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=273022 jiffies, g=78, c=77, q=4)
>> [ 291.064099] INFO: Stall ended before state dump start
>> [ 354.069074] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=336027 jiffies, g=78, c=77, q=4)
>> [ 354.069099] INFO: Stall ended before state dump start
>> [ 417.074045] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=399032 jiffies, g=78, c=77, q=4)
>> [ 417.074045] INFO: Stall ended before state dump start
>> [ 480.079099] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=462037 jiffies, g=78, c=77, q=4)
>> [ 480.079099] INFO: Stall ended before state dump start
>> [ 543.084099] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=525042 jiffies, g=78, c=77, q=4)
>> [ 543.084099] INFO: Stall ended before state dump start
>> [ 606.089101] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=588047 jiffies, g=78, c=77, q=4)
>> [ 606.089101] INFO: Stall ended before state dump start
>> [ 669.094099] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=651052 jiffies, g=78, c=77, q=4)
>> [ 669.094099] INFO: Stall ended before state dump start
>> [ 732.099045] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=714057 jiffies, g=78, c=77, q=4)
>> [ 732.099045] INFO: Stall ended before state dump start
>> [ 795.104074] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=777062 jiffies, g=78, c=77, q=4)
>> [ 795.104098] INFO: Stall ended before state dump start
>> [ 858.109046] INFO: rcu_preempt detected stalls on CPUs/tasks: {} (detected
>> by 0, t=840067 jiffies, g=78, c=77, q=4)
>> [ 858.109046] INFO: Stall ended before state dump start
[PATCH 10/12] clk: samsung: exynos5433: Add missing clocks for CMU_FSYS domain
This patch adds the mux/divider/gate clocks for CMU_FSYS domain which
contains the clocks of USB/UFS/SDMMC/TSI/PDMA IPs.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
drivers/clk/samsung/clk-exynos5433.c | 302 +
include/dt-bindings/clock/exynos5433.h | 96 ++-
2 files changed, 395 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index e79edd7..fa39e6c 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -462,6 +462,16 @@ static struct samsung_div_clock top_div_clks[] __initdata
= {
DIV(CLK_DIV_SCLK_MMC2_A, "div_sclk_mmc2_a", "mout_sclk_mmc2_b",
DIV_TOP_FSYS1, 0, 4),
+ /* DIV_TOP_FSYS2 */
+ DIV(CLK_DIV_SCLK_PCIE_100, "div_sclk_pcie_100", "mout_sclk_pcie_100",
+ DIV_TOP_FSYS2, 12, 3),
+ DIV(CLK_DIV_SCLK_USBHOST30, "div_sclk_usbhost30",
+ "mout_sclk_usbhost30", DIV_TOP_FSYS2, 8, 4),
+ DIV(CLK_DIV_SCLK_UFSUNIPRO, "div_sclk_ufsunipro",
+ "mout_sclk_ufsunipro", DIV_TOP_FSYS2, 4, 4),
+ DIV(CLK_DIV_SCLK_USBDRD30, "div_sclk_usbdrd30", "mout_sclk_usbdrd30",
+ DIV_TOP_FSYS2, 0, 4),
+
/* DIV_TOP_PERIC0 */
DIV(CLK_DIV_SCLK_SPI1_B, "div_sclk_spi1_b", "div_sclk_spi1_a",
DIV_TOP_PERIC0, 16, 8),
@@ -543,12 +553,23 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
/* ENABLE_SCLK_TOP_FSYS */
+ GATE(CLK_SCLK_PCIE_100_FSYS, "sclk_pcie_100_fsys", "div_sclk_pcie_100",
+ ENABLE_SCLK_TOP_FSYS, 7, 0, 0),
GATE(CLK_SCLK_MMC2_FSYS, "sclk_mmc2_fsys", "div_sclk_mmc2_b",
ENABLE_SCLK_TOP_FSYS, 6, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_MMC1_FSYS, "sclk_mmc1_fsys", "div_sclk_mmc1_b",
ENABLE_SCLK_TOP_FSYS, 5, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_MMC0_FSYS, "sclk_mmc0_fsys", "div_sclk_mmc0_b",
ENABLE_SCLK_TOP_FSYS, 4, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UFSUNIPRO_FSYS, "sclk_ufsunipro_fsys",
+ "div_sclk_ufsunipro", ENABLE_SCLK_TOP_FSYS,
+ 3, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_USBHOST30_FSYS, "sclk_usbhost30_fsys",
+ "div_sclk_usbhost30", ENABLE_SCLK_TOP_FSYS,
+ 1, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_USBDRD30_FSYS, "sclk_usbdrd30_fsys",
+ "div_sclk_usbdrd30", ENABLE_SCLK_TOP_FSYS,
+ 0, CLK_SET_RATE_PARENT, 0),
/* ENABLE_SCLK_TOP_PERIC */
GATE(CLK_SCLK_SPI4_PERIC, "sclk_spi4_peric", "div_sclk_spi4_b",
@@ -1832,10 +1853,45 @@ CLK_OF_DECLARE(exynos5433_cmu_peris,
"samsung,exynos5433-cmu-peris",
#define ENABLE_IP_FSYS10x0b04
/* list of all parent clock list */
+PNAME(mout_sclk_ufs_mphy_user_p) = { "fin_pll", "sclk_ufs_mphy", };
PNAME(mout_aclk_fsys_200_user_p) = { "fin_pll", "div_aclk_fsys_200", };
+PNAME(mout_sclk_pcie_100_user_p) = { "fin_pll", "sclk_pcie_100_fsys",};
+PNAME(mout_sclk_ufsunipro_user_p) = { "fin_pll", "sclk_ufsunipro_fsys",};
PNAME(mout_sclk_mmc2_user_p) = { "fin_pll", "sclk_mmc2_fsys", };
PNAME(mout_sclk_mmc1_user_p) = { "fin_pll", "sclk_mmc1_fsys", };
PNAME(mout_sclk_mmc0_user_p) = { "fin_pll", "sclk_mmc0_fsys", };
+PNAME(mout_sclk_usbhost30_user_p) = { "fin_pll", "sclk_usbhost30_fsys",};
+PNAME(mout_sclk_usbdrd30_user_p) = { "fin_pll", "sclk_usbdrd30_fsys", };
+
+PNAME(mout_phyclk_usbhost30_uhost30_pipe_pclk_user_p)
+ = { "fin_pll", "phyclk_usbhost30_uhost30_pipe_pclk_phy", };
+PNAME(mout_phyclk_usbhost30_uhost30_phyclock_user_p)
+ = { "fin_pll", "phyclk_usbhost30_uhost30_phyclock_phy", };
+PNAME(mout_phyclk_usbhost20_phy_hsic1_p)
+ = { "fin_pll", "phyclk_usbhost20_phy_hsic1_phy", };
+PNAME(mout_phyclk_usbhost20_phy_clk48mohci_user_p)
+ = { "fin_pll", "phyclk_usbhost20_phy_clk48mohci_phy", };
+PNAME(mout_phyclk_usbhost20_phy_phyclock_user_p)
+ = { "fin_pll", "phyclk_usbhost20_phy_phyclock_phy", };
+PNAME(mout_phyclk_usbhost20_phy_freeclk_user_p)
+ = { "fin_pll", "phyclk_usbhost20_phy_freeclk_phy", };
+PNAME(mout_phyclk_usbdrd30_udrd30_pipe_pclk_p)
+ = { "fin_pll", "phyclk_usbdrd30_udrd30_pipe_pclk_phy", };
+PNAME(mout_phyclk_usbdrd30_udrd30_phyclock_user_p)
+ = { "fin_pll", "phyclk_usbdrd30_udrd30_phyclock_phy", };
+PNAME(mout_phyclk_ufs_rx1_symbol_user_p)
+ = { "fin_pll", "phyclk_ufs_rx1_symbol_phy", };
+PNAME(mout_phyclk_ufs_rx0_symbol_user_p)
+ = { "fin_pll", "phyclk_ufs_rx0_symbol_phy", };
[PATCH 12/12] clk: samsung: exynos5433: Add clocks for CMU_GSCL domain
This patch adds the divider/gate of CMU_GSCL domain which contains gscaler
clocks.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 ++
drivers/clk/samsung/clk-exynos5433.c | 146 +
include/dt-bindings/clock/exynos5433.h | 37 +-
3 files changed, 190 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 589ed93..bf72817 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -30,6 +30,8 @@ Required Properties:
which generates global data buses clock and global peripheral buses clock.
- "samsung,exynos5433-cmu-g3d" - clock controller compatible for CMU_G3D
which generates clocks for 3D Graphics Engine IP.
+ - "samsung,exynos5433-cmu-gscl" - clock controller compatible for CMU_GSCL
+which generates clocks for GSCALER IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -123,6 +125,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_gscl: clock-controller@0x13cf {
+ compatible = "samsung,exynos5433-cmu-gscl";
+ reg = <0x13cf 0x0b10>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 27dda68..1d8d67a 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -545,6 +545,12 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_ACLK_FSYS_200, "aclk_fsys_200", "div_aclk_fsys_200",
ENABLE_ACLK_TOP, 18,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_GSCL_111, "aclk_gscl_111", "div_aclk_gscl_111",
+ ENABLE_ACLK_TOP, 15,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_GSCL_333, "aclk_gscl_333", "div_aclk_gscl_333",
+ ENABLE_ACLK_TOP, 14,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_G2D_266, "aclk_g2d_266", "div_aclk_g2d_266",
ENABLE_ACLK_TOP, 2,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -3247,3 +3253,143 @@ static void __init exynos5433_cmu_g3d_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_g3d, "samsung,exynos5433-cmu-g3d",
exynos5433_cmu_g3d_init);
+
+/*
+ * Register offset definitions for CMU_GSCL
+ */
+#define MUX_SEL_GSCL 0x0200
+#define MUX_ENABLE_GSCL0x0300
+#define MUX_STAT_GSCL 0x0400
+#define ENABLE_ACLK_GSCL 0x0800
+#define ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL0 0x0804
+#define ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL1 0x0808
+#define ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL2 0x080c
+#define ENABLE_PCLK_GSCL 0x0900
+#define ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL0 0x0904
+#define ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL1 0x0908
+#define ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL2 0x090c
+#define ENABLE_IP_GSCL00x0b00
+#define ENABLE_IP_GSCL10x0b04
+#define ENABLE_IP_GSCL_SECURE_SMMU_GSCL0 0x0b08
+#define ENABLE_IP_GSCL_SECURE_SMMU_GSCL1 0x0b0c
+#define ENABLE_IP_GSCL_SECURE_SMMU_GSCL2 0x0b10
+
+static unsigned long gscl_clk_regs[] __initdata = {
+ MUX_SEL_GSCL,
+ MUX_ENABLE_GSCL,
+ MUX_STAT_GSCL,
+ ENABLE_ACLK_GSCL,
+ ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL0,
+ ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL1,
+ ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL2,
+ ENABLE_PCLK_GSCL,
+ ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL0,
+ ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL1,
+ ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL2,
+ ENABLE_IP_GSCL0,
+ ENABLE_IP_GSCL1,
+ ENABLE_IP_GSCL_SECURE_SMMU_GSCL0,
+ ENABLE_IP_GSCL_SECURE_SMMU_GSCL1,
+ ENABLE_IP_GSCL_SECURE_SMMU_GSCL2,
+};
+
+/* list of all parent clock list */
+PNAME(aclk_gscl_111_user_p)= { "fin_pll", "aclk_gscl_111", };
+PNAME(aclk_gscl_333_user_p)= { "fin_pll", "aclk_gscl_333", };
+
+static struct samsung_mux_clock gscl_mux_clks[] __initdata = {
+ /* MUX_SEL_GSCL */
+ MUX(CLK_MOUT_ACLK_GSCL_111_USER, "mout_aclk_gscl_111_user",
+ aclk_gscl_111_user_p, MUX_SEL_GSCL, 4, 1),
+ MUX(CLK_MOUT_ACLK_GSCL_333_USER, "mout_aclk_gscl_333_user",
+ aclk_gscl_333_user_p, MUX_SEL_GSCL, 0, 1),
+};
+
Re: [RFC][PATCH RESEND] mm: vmalloc: remove ioremap align constraint
On Sun, 04 Jan 2015 17:38:06 +0100
Arnd Bergmann wrote:
> On Saturday 03 January 2015 18:59:46 Sergey Dyasly wrote:
> > Hi Arnd,
> >
> > First, some background information. We originally encountered high
> > fragmentation
> > issue in vmalloc area:
> >
> > 1. Total size of vmalloc area was 400 MB.
> > 2. 200 MB of vmalloc area was consumed by ioremaps of various sizes.
> > 3. Largest contiguous chunk of vmalloc area was 12 MB.
> > 4. ioremap of 10 MB failed due to 8 MB alignment requirement.
>
> Interesting, can you describe how you end up with that many ioremap mappings?
> 200MB seems like a lot. Do you perhaps get a lot of duplicate entries for the
> same hardware registers, or maybe a leak?
>
> Can you send the output of /proc/vmallocinfo?
>
> > It was decided to further increase the size of vmalloc area to resolve the
> > above
> > issue. And I don't like that solution because it decreases the amount of
> > lowmem.
>
> If all the mappings are in fact required, have you considered using
> CONFIG_VMSPLIT_2G split to avoid the use of highmem?
>
> > Now let's see how ioremap uses supersections. Judging from current
> > implementation
> > of __arm_ioremap_pfn_caller:
> >
> > #if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
> > if (pfn >= 0x10 && !((paddr | size | addr) &
> > ~SUPERSECTION_MASK)) {
> > remap_area_supersections();
> > } else if (!((paddr | size | addr) & ~PMD_MASK)) {
> > remap_area_sections();
> > } else
> > #endif
> > err = ioremap_page_range();
> >
> > supersections and sections mappings are used only in !SMP && !LPAE case.
> > Otherwise, mapping is created using the usual 4K pages (and we are using
> > SMP).
> > The suggested patch removes alignment requirements for ioremap but it means
> > that
> > sections will not be used in !SMP case. So another solution is required.
> >
> > __get_vm_area_node has align parameter, maybe it can be used to specify the
> > required alignment of ioremap operation? Because I find current generic fls
> > algorithm to be very restrictive in cases when it's not necessary to use
> > such
> > a big alignment.
>
> I think using next-power-of-two alignment generally helps limit the effects of
> fragmentation the same way that the buddy allocator works.
>
> Since the section and supersection maps are only used with non-SMP non-LPAE
> (why is that the case btw?),
vmap/vunmap mechanism works that way. ARM is using 2 levels of page tables:
PGD and PTE; and that provides the needed level of indirection. Every mm
contains a copy of init_mm's pgd mappings for kernel and they point to the same
set of PTEs. vmap/vunmap manipulates only with *pgd->pte and the change becomes
visible to every mm. This is impossible to do for sections because they use
PGD entries directly.
> it would however make sense to use the default
> (7 + PAGE_SHIFT) instead of the ARM-specific 24 here if one of them is set,
> I don't see any downsides to that.
This makes sense. I'll prepare a patch for that.
>
> Arnd
--
Sergey Dyasly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] clk: samsung: exynos5433: Add clocks for CMU_G3D domain
This patch adds the mux/divider/gate clocks for CMU_G3D domain which contains
the clocks for GPU(3D Graphics Engine).
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Pankaj Dubey
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 ++
drivers/clk/samsung/clk-exynos5433.c | 127 +
include/dt-bindings/clock/exynos5433.h | 25
3 files changed, 160 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 03ae40a..589ed93 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -28,6 +28,8 @@ Required Properties:
- "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
and "samsung,exynos5433-cmu-bus2" - clock controller compatible for CMU_BUS
which generates global data buses clock and global peripheral buses clock.
+ - "samsung,exynos5433-cmu-g3d" - clock controller compatible for CMU_G3D
+which generates clocks for 3D Graphics Engine IP.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -115,6 +117,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_g3d: clock-controller@0x14aa {
+ compatible = "samsung,exynos5433-cmu-g3d";
+ reg = <0x14aa 0x1000>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index fa39e6c..27dda68 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -3120,3 +3120,130 @@ CLK_OF_DECLARE(exynos5433_cmu_bus##id,
\
exynos5433_cmu_bus_init(0);
exynos5433_cmu_bus_init(1);
exynos5433_cmu_bus_init(2);
+
+/*
+ * Register offset definitions for CMU_G3D
+ */
+#define G3D_PLL_LOCK 0x
+#define G3D_PLL_CON0 0x0100
+#define G3D_PLL_CON1 0x0104
+#define G3D_PLL_FREQ_DET 0x010c
+#define MUX_SEL_G3D0x0200
+#define MUX_ENABLE_G3D 0x0300
+#define MUX_STAT_G3D 0x0400
+#define DIV_G3D0x0600
+#define DIV_G3D_PLL_FREQ_DET 0x0604
+#define DIV_STAT_G3D 0x0700
+#define DIV_STAT_G3D_PLL_FREQ_DET 0x0704
+#define ENABLE_ACLK_G3D0x0800
+#define ENABLE_PCLK_G3D0x0900
+#define ENABLE_SCLK_G3D0x0a00
+#define ENABLE_IP_G3D0 0x0b00
+#define ENABLE_IP_G3D1 0x0b04
+#define CLKOUT_CMU_G3D 0x0c00
+#define CLKOUT_CMU_G3D_DIV_STAT0x0c04
+#define CLK_STOPCTRL 0x1000
+
+static unsigned long g3d_clk_regs[] __initdata = {
+ G3D_PLL_LOCK,
+ G3D_PLL_CON0,
+ G3D_PLL_CON1,
+ G3D_PLL_FREQ_DET,
+ MUX_SEL_G3D,
+ MUX_ENABLE_G3D,
+ MUX_STAT_G3D,
+ DIV_G3D,
+ DIV_G3D_PLL_FREQ_DET,
+ DIV_STAT_G3D,
+ DIV_STAT_G3D_PLL_FREQ_DET,
+ ENABLE_ACLK_G3D,
+ ENABLE_PCLK_G3D,
+ ENABLE_SCLK_G3D,
+ ENABLE_IP_G3D0,
+ ENABLE_IP_G3D1,
+ CLKOUT_CMU_G3D,
+ CLKOUT_CMU_G3D_DIV_STAT,
+ CLK_STOPCTRL,
+};
+
+/* list of all parent clock list */
+PNAME(mout_aclk_g3d_400_p) = { "mout_g3d_pll", "aclk_g3d_400", };
+PNAME(mout_g3d_pll_p) = { "fin_pll", "fout_g3d_pll", };
+
+static struct samsung_pll_clock g3d_pll_clks[] __initdata = {
+ PLL(pll_35xx, CLK_FOUT_G3D_PLL, "fout_g3d_pll", "fin_pll",
+ G3D_PLL_LOCK, G3D_PLL_CON0, exynos5443_pll_rates),
+};
+
+static struct samsung_mux_clock g3d_mux_clks[] __initdata = {
+ /* MUX_SEL_G3D */
+ MUX(CLK_MOUT_ACLK_G3D_400, "mout_aclk_g3d_400", mout_aclk_g3d_400_p,
+ MUX_SEL_G3D, 8, 1),
+ MUX(CLK_MOUT_G3D_PLL, "mout_g3d_pll", mout_g3d_pll_p,
+ MUX_SEL_G3D, 0, 1),
+};
+
+static struct samsung_div_clock g3d_div_clks[] __initdata = {
+ /* DIV_G3D */
+ DIV(CLK_DIV_SCLK_HPM_G3D, "div_sclk_hpm_g3d", "mout_g3d_pll", DIV_G3D,
+ 8, 2),
+ DIV(CLK_DIV_PCLK_G3D, "div_pclk_g3d", "div_aclk_g3d", DIV_G3D,
+ 4, 3),
+ DIV(CLK_DIV_ACLK_G3D, "div_aclk_g3d", "mout_aclk_g3d_400", DIV_G3D,
+ 0, 3),
+};
+
+static struct samsung_gate_clock g3d_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_G3D */
+ GATE(CLK_ACLK_BTS_G3D1, "aclk_bts_g3d1", "div_aclk_g3d",
+ ENABLE_ACLK_G3D, 7, 0, 0),
+ GATE(CLK_ACLK_BTS_G3D0, "aclk_bts_g3d0",
Re: [PATCH V2 06/12] selftests, powerpc: Add test for system wide DSCR default
On Tue, 2015-01-20 at 16:40 -0500, Dave Jones wrote: > On Wed, Jan 14, 2015 at 10:44:31AM +1100, Michael Ellerman wrote: > > > > Also, I would like to see the test results reports using > > > kselftest.h - it can be separate patch in the interest of > > > getting tests in. > > > > Sorry but kselftest.h doesn't do anything useful for us. > > > > We have existing test reporting that uses the subunit protocol. > > > > I'm happy to convert that to TAP, or some other well defined output > format, but > > not to something ad-hoc like kselftest.h currently provides. > > Something TAP-alike would also help reduce some of the spew from > tests that are going to fail. Possibly :) > eg, running execveat tests on a kernel that doesn't implement that > syscall currently spews around 20 lines of [FAIL]. Adding something > to the beginning of the test to set plan() accordingly if it detects > -ENOSYS could make that output a little cleaner. Yeah I'm a bit dubious about plan, it often ends up being a pain to calculate correctly and so it's either missing or wrong. The execveat test probably just needs an initial test that looks for ENOSYS and bails entirely. I'll write a patch. > That other projects (like jenkins, bug trackers etc) could consume > the output of the test runs would be a nice bonus. I only recently > started looking at kselftests and was surprised at the amount > of variance we have in the way of printing 'Ok' '[OK]' 'ok...' etc. Variance in output is annoying, but putting up too many barriers to entry for new tests is even less desirable IMHO. Our preference should always be for more tests in the tree, and we can clean up the output/reporting later. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blackfin: mach-common: ints-priority: Remove unused function
On Tue, Jan 20, 2015 at 9:07 PM, Jiri Kosina wrote:
> On Sat, 3 Jan 2015, Rickard Strandqvist wrote:
>
>> Remove the function bfin_sec_resume() that is not used anywhere.
>>
>> This was partially found by using a static code analysis program called
>> cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist
>
> This doesn't seem to be present in linux-next as of today, so I am picking
> it up.
It seems it's still in today's linux-next?
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/blackfin/mach-common/ints-priority.c#n432
>
>> ---
>> arch/blackfin/mach-common/ints-priority.c |8
>> 1 file changed, 8 deletions(-)
>>
>> diff --git a/arch/blackfin/mach-common/ints-priority.c
>> b/arch/blackfin/mach-common/ints-priority.c
>> index dd2af74..7236bdf 100644
>> --- a/arch/blackfin/mach-common/ints-priority.c
>> +++ b/arch/blackfin/mach-common/ints-priority.c
>> @@ -429,14 +429,6 @@ static void init_software_driven_irq(void)
>> bfin_sec_enable_ssi(37);
>> }
>>
>> -void bfin_sec_resume(void)
>> -{
>> - bfin_write_SEC_SCI(0, SEC_CCTL, SEC_CCTL_RESET);
>> - udelay(100);
>> - bfin_write_SEC_GCTL(SEC_GCTL_EN);
>> - bfin_write_SEC_SCI(0, SEC_CCTL, SEC_CCTL_EN | SEC_CCTL_NMI_EN);
>> -}
>> -
>> void handle_sec_sfi_fault(uint32_t gstat)
>> {
>>
>> --
>> 1.7.10.4
>>
>
> --
> Jiri Kosina
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 04/16] virtio/console: verify device has config space
On Wed, Jan 21, 2015 at 11:44:52AM +0530, Amit Shah wrote: > On (Tue) 20 Jan 2015 [13:09:55], Michael S. Tsirkin wrote: > > On Tue, Jan 20, 2015 at 04:10:40PM +0530, Amit Shah wrote: > > > On (Wed) 14 Jan 2015 [19:27:35], Michael S. Tsirkin wrote: > > > > Some devices might not implement config space access > > > > (e.g. remoteproc used not to - before 3.9). > > > > virtio/console needs config space access so make it > > > > fail gracefully if not there. > > > > > > Do we know any such devices? Wondering what prompted this patch. If > > > it's just theoretical, I'd rather let it be like this, and pull this > > > in when there's a device that doesn't have config space. > > > > Yes, with virtio 1.0 config space can be in a separate BAR now. If > > that's not enabled by BIOS (e.g. out of space), we won't have config > > space. > > I'm still not sure whether we should pull in this patch before > actually seeing a failure. > > You do have a dev_err which tells why the probe failed, so it's an > acceptable compromise I suppose. > > > > Also, just the console functionality (i.e. F_MULTIPORT is unset) is > > > available w/o config space access. > > > > Supporting this by gracefully disabling F_MULTIPORT > > would require getting this info from driver before > > features are finalized. > > Alternatively, check F_MULTIPORT and only fail if set? > > Let me know, I'll cook up a patch. > > Yes, failing only if F_MULTIPORT is set is a better option (if we have > to fail). OK, that's easy I think - will send a patch on top. > > > In fact, getting this patch in > > > would mean remoteproc wouldn't even run in its pre-config days... > > > > It seems to have get callback unconditionally now - or did I miss > > something? > > What I meant was remoteproc doesn't depend on the config space, only > uses the console functionality. If remoteproc devices didn't expose a > config space, this patch would cause it to lose its console > functionality for no apparent reason. > > > Amit Better than crashing on jump to NULL? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blackfin: mach-common: ints-priority: Remove unused function
Hi Rickard,
On Sun, Jan 4, 2015 at 1:01 AM, Rickard Strandqvist
wrote:
> Remove the function bfin_sec_resume() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> arch/blackfin/mach-common/ints-priority.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/arch/blackfin/mach-common/ints-priority.c
> b/arch/blackfin/mach-common/ints-priority.c
> index dd2af74..7236bdf 100644
> --- a/arch/blackfin/mach-common/ints-priority.c
> +++ b/arch/blackfin/mach-common/ints-priority.c
> @@ -429,14 +429,6 @@ static void init_software_driven_irq(void)
> bfin_sec_enable_ssi(37);
> }
>
> -void bfin_sec_resume(void)
> -{
> - bfin_write_SEC_SCI(0, SEC_CCTL, SEC_CCTL_RESET);
> - udelay(100);
> - bfin_write_SEC_GCTL(SEC_GCTL_EN);
> - bfin_write_SEC_SCI(0, SEC_CCTL, SEC_CCTL_EN | SEC_CCTL_NMI_EN);
> -}
> -
> void handle_sec_sfi_fault(uint32_t gstat)
> {
>
> --
> 1.7.10.4
>
Yes, this bfin_sec_resume() should be dropped.
-steven
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] pinctrl: exynos: Add support for Exynos5433
This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi-
functional input/output port pins and 135 memory port pins. There are 41 general
port groups and 2 memory port groups.
Cc: Tomasz Figa
Cc: Thomas Abraham
Cc: Linus Walleij
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
Changes from v2:
- Rebase it on v3.19-rc5
Changes from v1:
- Fix the wrong number of Exynos5433 (four -> ten)
- Divide pinctrl patch from following patch[1]
[1] https://lkml.org/lkml/2014/12/2/134
drivers/pinctrl/samsung/pinctrl-exynos.c | 153 ++
drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
3 files changed, 156 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index becb379..4976441 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1240,6 +1240,159 @@ const struct samsung_pin_ctrl exynos5420_pin_ctrl[]
__initconst = {
},
};
+/* pin banks of exynos5433 pin-controller - ALIVE */
+static const struct samsung_pin_bank_data exynos5433_pin_banks0[] = {
+ EXYNOS_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
+ EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
+ EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
+ EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
+};
+
+/* pin banks of exynos5433 pin-controller - AUD */
+static const struct samsung_pin_bank_data exynos5433_pin_banks1[] = {
+ EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
+};
+
+/* pin banks of exynos5433 pin-controller - CPIF */
+static const struct samsung_pin_bank_data exynos5433_pin_banks2[] = {
+ EXYNOS_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - eSE */
+static const struct samsung_pin_bank_data exynos5433_pin_banks3[] = {
+ EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - FINGER */
+static const struct samsung_pin_bank_data exynos5433_pin_banks4[] = {
+ EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - FSYS */
+static const struct samsung_pin_bank_data exynos5433_pin_banks5[] = {
+ EXYNOS_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
+ EXYNOS_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
+ EXYNOS_PIN_BANK_EINTG(5, 0x040, "gpr0", 0x08),
+ EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr1", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpr2", 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpr3", 0x14),
+};
+
+/* pin banks of exynos5433 pin-controller - IMEM */
+static const struct samsung_pin_bank_data exynos5433_pin_banks6[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpf0", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - NFC */
+static const struct samsung_pin_bank_data exynos5433_pin_banks7[] = {
+ EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj0", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - PERIC */
+static const struct samsung_pin_bank_data exynos5433_pin_banks8[] = {
+ EXYNOS_PIN_BANK_EINTG(6, 0x000, "gpv7", 0x00),
+ EXYNOS_PIN_BANK_EINTG(5, 0x020, "gpb0", 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpc0", 0x08),
+ EXYNOS_PIN_BANK_EINTG(2, 0x060, "gpc1", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x080, "gpc2", 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpc3", 0x14),
+ EXYNOS_PIN_BANK_EINTG(2, 0x0c0, "gpg0", 0x18),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0e0, "gpd0", 0x1c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x100, "gpd1", 0x20),
+ EXYNOS_PIN_BANK_EINTG(8, 0x120, "gpd2", 0x24),
+ EXYNOS_PIN_BANK_EINTG(5, 0x140, "gpd4", 0x28),
+ EXYNOS_PIN_BANK_EINTG(2, 0x160, "gpd8", 0x2c),
+ EXYNOS_PIN_BANK_EINTG(7, 0x180, "gpd6", 0x30),
+ EXYNOS_PIN_BANK_EINTG(3, 0x1a0, "gpd7", 0x34),
+ EXYNOS_PIN_BANK_EINTG(5, 0x1c0, "gpg1", 0x38),
+ EXYNOS_PIN_BANK_EINTG(2, 0x1e0, "gpg2", 0x3c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x200, "gpg3", 0x40),
+};
+
+/* pin banks of exynos5433 pin-controller - TOUCH */
+static const struct samsung_pin_bank_data exynos5433_pin_banks9[] = {
+ EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj1", 0x00),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
+ * ten gpio/pin-mux/pinconfig controllers.
+ */
+const struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
+ {
+ /* pin-controller instance 0 data */
+ .pin_banks = exynos5433_pin_banks0,
+ .nr_banks = ARRAY_SIZE(exynos5433_pin_banks0),
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .suspend= exynos_pinctrl_suspend,
+ .resume = exynos_pinctrl_resume,
+ }, {
+ /* pin-controller instance 1 data */
+ .pin_banks = exynos5433_pin_banks1,
+ .nr_banks =
Re: PowerMac G5 Quad Issue reporting
On 20.01.2015 20:52, luigi burdo wrote: > Hello all LinuxPPc Developer, > need to report a issue that im facing from kernel 3.16 and up. > > The fans of powermac g5 quad start boosting like a turbo jet after the > system is > been loaded and up. > Usually this become after about 30-60 seconds when the system is loaded. You need to load the i2c_powermac kernel module. > Need to report to Michel D. from amd.com . The RadeonHD 6570 now is > working on PowerMac G5 too > look like the Xorg bigendian issue related Evergreen / Northern is > been fixed ;-) Xorg itself has always been working, only OpenGL can be problematic. Have you verified r600_dri.so is used for that? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] clocksource: Conexant CX92755 timers support
This short series adds support for the Conexant CX92755 SoC timers. This SoC is part of the Conexant Digicolor series of SoCs. v3: * Split into a separate clocksource series v2: http://article.gmane.org/gmane.linux.kernel/1861850 http://article.gmane.org/gmane.linux.kernel/1861853 * Change the timer dt binding, so that the 'reg' property points to the first "Agent Communication" register. This should improve the chance of reusing this binding for other SoCs in this series. * Add the CONTROL() and COUNT() macros to the timer driver to make the code clearer. * Move arch/arm Kconfig changes from the clocksource driver patch to the base arch support patch to reduce dependency between them v1: http://article.gmane.org/gmane.linux.kernel/1855028 http://article.gmane.org/gmane.linux.kernel/1855025 Baruch Siach (2): clocksource: devicetree: document Conexant Digicolor timer binding clocksource: driver for Conexant Digicolor SoC timer .../devicetree/bindings/timer/digicolor-timer.txt | 18 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-digicolor.c | 164 + 3 files changed, 183 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/digicolor-timer.txt create mode 100644 drivers/clocksource/timer-digicolor.c -- 2.1.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: [RFC Patch 17/19] resources: Move struct resource_list_entry from ACPI into resource core
On 2015/1/21 9:10, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:33:04 AM Jiang Liu wrote:
>> diff --git a/kernel/resource.c b/kernel/resource.c
>> index 0bcebffc4e77..414183809383 100644
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -1529,6 +1529,54 @@ int iomem_is_exclusive(u64 addr)
>> return err;
>> }
>>
>> +struct resource_list_entry *resource_list_alloc(struct resource *res,
>> +size_t extra_size)
>
> What about create_resource_list_entry()? Less confusing surely.
Sure, I will rename it as resource_list_create_entry().
>
>> +{
>> +struct resource_list_entry *entry;
>> +
>> +entry = kzalloc(sizeof(*entry) + extra_size, GFP_KERNEL);
>> +if (entry) {
>> +INIT_LIST_HEAD(>node);
>> +entry->res = res ? res : >__res;
>> +}
>> +
>> +return entry;
>> +}
>> +EXPORT_SYMBOL(resource_list_alloc);
>> +
>> +void resource_list_free(struct resource_list_entry *entry)
>> +{
>> +kfree(entry);
>> +}
>> +EXPORT_SYMBOL(resource_list_free);
>
> Well, I'm not sure I like this. The name suggests that it would free the
> entire list and what's wrong with using kfree() directly on "entry" anyway?
I just want to make interface symmetric. We may also support some type
of callback when freeing resources in future.
>
>> +
>> +void resource_list_insert(struct list_head *head,
>> + struct resource_list_entry *entry, bool tail)
>
> I would call this resource_list_add() if anything.
>
> Also it may be better to have two helpers, one for "add" and one for
> "add_tail"
> (and perhaps define them as static inline?).
We can't use inline functions here because that needs pulling list.h
into ioport.h, then causing building issues to header inclusion order.
>
> And why change the ordering between "head" and "entry". That's alomost
> guaranteed to confuse people.
My fault, will change in next version.
>
>> +{
>> +if (tail)
>> +list_add_tail(>node, head);
>> +else
>> +list_add(>node, head);
>> +}
>> +EXPORT_SYMBOL(resource_list_insert);
>> +
>> +void resource_list_delete(struct resource_list_entry *entry)
>> +{
>> +list_del(>node);
>> +}
>> +EXPORT_SYMBOL(resource_list_delete);
>
> Couldn't this be a static inline)?
Inline will cause header file inclusion order issue:(
>
> Or maybe we can combine the "list_del" with "kfree" in one function?
There are callers which need separating list_del from kfree,
so exported two interfaces here. Will add another helper interface
resource_list_destroy_entry().
Regards!
Gerry
>
>> +
>> +void resource_list_free_list(struct list_head *head)
>> +{
>> +struct resource_list_entry *entry, *tmp;
>> +
>> +list_for_each_entry_safe(entry, tmp, head, node) {
>> +list_del(>node);
>> +resource_list_free(entry);
>> +}
>> +}
>> +EXPORT_SYMBOL(resource_list_free_list);
>> +
>> static int __init strict_iomem(char *str)
>> {
>> if (strstr(str, "relaxed"))
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] clocksource: driver for Conexant Digicolor SoC timer
Add clocksource driver to the Conexant CX92755 SoC, part of the Digicolor SoCs
series. Hardware provides 8 timers, A to H. Timer A is dedicated to a future
watchdog driver so we don't use it here. Use timer B for sched_clock, and timer
C for clock_event.
Signed-off-by: Baruch Siach
---
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-digicolor.c | 164 ++
2 files changed, 165 insertions(+)
create mode 100644 drivers/clocksource/timer-digicolor.c
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 94d90b24b56b..a993c108be67 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_SH_TIMER_TMU)+= sh_tmu.o
obj-$(CONFIG_EM_TIMER_STI) += em_sti.o
obj-$(CONFIG_CLKBLD_I8253) += i8253.o
obj-$(CONFIG_CLKSRC_MMIO) += mmio.o
+obj-$(CONFIG_ARCH_DIGICOLOR) += timer-digicolor.o
obj-$(CONFIG_DW_APB_TIMER) += dw_apb_timer.o
obj-$(CONFIG_DW_APB_TIMER_OF) += dw_apb_timer_of.o
obj-$(CONFIG_CLKSRC_NOMADIK_MTU) += nomadik-mtu.o
diff --git a/drivers/clocksource/timer-digicolor.c
b/drivers/clocksource/timer-digicolor.c
new file mode 100644
index ..014c50675980
--- /dev/null
+++ b/drivers/clocksource/timer-digicolor.c
@@ -0,0 +1,164 @@
+/*
+ * Conexant Digicolor timer driver
+ *
+ * Author: Baruch Siach
+ *
+ * Copyright (C) 2014 Paradox Innovation Ltd.
+ *
+ * Based on:
+ * Allwinner SoCs hstimer driver
+ *
+ * Copyright (C) 2013 Maxime Ripard
+ *
+ * Maxime Ripard
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/*
+ * Conexant Digicolor SoCs have 8 configurable timers, named from "Timer A" to
+ * "Timer H". Timer A is the only one with watchdog support, so it is dedicated
+ * to the watchdog driver. This driver uses Timer B for sched_clock(), and
+ * Timer C for clockevents.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ TIMER_A,
+ TIMER_B,
+ TIMER_C,
+ TIMER_D,
+ TIMER_E,
+ TIMER_F,
+ TIMER_G,
+ TIMER_H,
+};
+
+#define CONTROL(t) ((t)*8)
+#define COUNT(t) ((t)*8 + 4)
+
+static void __iomem *timer_base;
+static u32 ticks_per_jiffy;
+
+static void digicolor_clkevt_mode(enum clock_event_mode mode,
+ struct clock_event_device *clk)
+{
+ switch (mode) {
+ case CLOCK_EVT_MODE_PERIODIC:
+ writeb(0, timer_base + CONTROL(TIMER_C));
+ writel(ticks_per_jiffy, timer_base + COUNT(TIMER_C));
+ writeb(0x21, timer_base + CONTROL(TIMER_C));
+ break;
+ case CLOCK_EVT_MODE_ONESHOT:
+ writeb(0, timer_base + CONTROL(TIMER_C));
+ writeb(0x11, timer_base + CONTROL(TIMER_C));
+ break;
+ case CLOCK_EVT_MODE_UNUSED:
+ case CLOCK_EVT_MODE_SHUTDOWN:
+ default:
+ writeb(0, timer_base + CONTROL(TIMER_C));
+ break;
+ }
+}
+
+static int digicolor_clkevt_next_event(unsigned long evt,
+ struct clock_event_device *unused)
+{
+ writeb(0, timer_base + CONTROL(TIMER_C));
+ writel(evt, timer_base + COUNT(TIMER_C));
+ writeb(0x11, timer_base + CONTROL(TIMER_C));
+
+ return 0;
+}
+
+static struct clock_event_device digicolor_clockevent = {
+ .name = "digicolor_tick",
+ .rating = 340,
+ .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+ .set_mode = digicolor_clkevt_mode,
+ .set_next_event = digicolor_clkevt_next_event,
+};
+
+
+static irqreturn_t digicolor_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *evt = (struct clock_event_device *)dev_id;
+
+ evt->event_handler(evt);
+
+ return IRQ_HANDLED;
+}
+
+static struct irqaction digicolor_timer_irq = {
+ .name = "digicolor_timerC",
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
+ .handler = digicolor_timer_interrupt,
+ .dev_id = _clockevent,
+};
+
+static u64 digicolor_timer_sched_read(void)
+{
+ return ~readl(timer_base + COUNT(TIMER_B));
+}
+
+static void __init digicolor_timer_init(struct device_node *node)
+{
+ unsigned long rate;
+ struct clk *clk;
+ int ret, irq;
+
+ timer_base = of_iomap(node, 0);
+ if (!timer_base) {
+ pr_err("Can't map registers");
+ return;
+ }
+
+ irq = irq_of_parse_and_map(node, TIMER_C);
+ if (irq <= 0) {
+ pr_err("Can't parse IRQ");
+ return;
+ }
+
+ clk = of_clk_get(node, 0);
+ if (IS_ERR(clk)) {
+ pr_err("Can't get timer clock");
+ return;
+ }
+
[PATCH v3 1/2] clocksource: devicetree: document Conexant Digicolor timer binding
Signed-off-by: Baruch Siach
---
.../devicetree/bindings/timer/digicolor-timer.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/digicolor-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/digicolor-timer.txt
b/Documentation/devicetree/bindings/timer/digicolor-timer.txt
new file mode 100644
index ..d1b659bbc29f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/digicolor-timer.txt
@@ -0,0 +1,18 @@
+Conexant Digicolor SoCs Timer Controller
+
+Required properties:
+
+- compatible : should be "cnxt,cx92755-timer"
+- reg : Specifies base physical address and size of the "Agent Communication"
+ timer registers
+- interrupts : Contains 8 interrupts, one for each timer
+- clocks: phandle to the main clock
+
+Example:
+
+ timer@ffc0 {
+ compatible = "cnxt,cx92755-timer";
+ reg = <0xffc0 0x40>;
+ interrupts = <19>, <31>, <34>, <35>, <52>, <53>, <54>, <55>;
+ clocks = <_clk>;
+ };
--
2.1.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: stable 3.14 backport request for ARC
On Monday 19 January 2015 07:03 PM, Greg KH wrote: On Tue, Dec 23, 2014 at 08:08:51AM +, Vineet Gupta wrote: > 2014-04-18 64ee9f32c33c ARC: Delete stale barrier.h I don't see how this is an issue for 3.14, it says it fixes a 3.15 build issue only, so I didn't apply it. Why did you ask for it? Technically it was indeed detected in 3.15 but the offending commit was merged in 3.14 (93ea02bb8435 arch: Clean up asm/barrier.h implementations using asm-generic/barrier.h) I'm ok if you think it doesn't qualify ! FWIW, as an addendum to my prev email I'd also requested for the following backport. Perhaps you will do that when u eventually get to that email from ur backlog. Otherwise, the details are below. 2014-06-24 ba25915fb2cd ARC: Fix build breakage for !CONFIG_ARC_DW2_UNWIND Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range
On Wed, Jan 21, 2015 at 11:43:13AM +0530, Shiraz Hashim wrote:
> walk_page_range silently skips vma having VM_PFNMAP set,
> which leads to undesirable behaviour at client end (who
> called walk_page_range). For example for pagemap_read,
> when no callbacks are called against VM_PFNMAP vma,
> pagemap_read may prepare pagemap data for next virtual
> address range at wrong index.
>
> Signed-off-by: Shiraz Hashim
Thank you!
Acked-by: Naoya Horiguchi
> ---
> The fix is revised, based upon the suggestion here at
> http://www.spinics.net/lists/linux-mm/msg83058.html
>
> mm/pagewalk.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
> index ad83195..b264bda 100644
> --- a/mm/pagewalk.c
> +++ b/mm/pagewalk.c
> @@ -199,7 +199,10 @@ int walk_page_range(unsigned long addr, unsigned long
> end,
>*/
> if ((vma->vm_start <= addr) &&
> (vma->vm_flags & VM_PFNMAP)) {
> - next = vma->vm_end;
> + if (walk->pte_hole)
> + err = walk->pte_hole(addr, next, walk);
> + if (err)
> + break;
> pgd = pgd_offset(walk->mm, next);
> continue;
> }
> --
> Shiraz Hashim
>
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of the Code Aurora Forum, hosted by The Linux Foundation
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 21 January 2015 at 11:42, Chanwoo Choi wrote: > OK, I understand. > I'll try to update exynos memory bus according to your comment. Great. @Rob: So there is nothing special required for devfreq drivers in new OPP bindings, right ? :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] I2C: mediatek: Add driver for MediaTek I2C controller
Hi Uwe,
Thanks for your review,
On Wed, 2015-01-21 at 11:13 +0800, Eddie Huang wrote:
<...>
> > > + ret = -EINVAL;
> > > + goto err_exit;
> > > + }
> > > +
> > > + if (msgs->buf == NULL) {
> > > + dev_dbg(i2c->dev, " data buffer is NULL.\n");
> > > + ret = -EINVAL;
> > > + goto err_exit;
> > > + }
> > > +
> > > + i2c->addr = msgs->addr;
> > > + i2c->msg_len = msgs->len;
> > > + i2c->msg_buf = msgs->buf;
> > > +
> > > + if (msgs->flags & I2C_M_RD)
> > > + i2c->op = I2C_MASTER_RD;
> > > + else
> > > + i2c->op = I2C_MASTER_WR;
> > > +
> > > + /* combined two messages into one transaction */
> > > + if (num > 1) {
> > > + i2c->msg_aux_len = (msgs + 1)->len;
> > > + i2c->op = I2C_MASTER_WRRD;
> > > + }
> > This means "write then read", right? You should check here that the
> > first message is really a write and the 2nd a read then.
> > Can this happen at all with the quirks defined below (.max_num_msgs =
> > 1)?
> Yes, mean write then read. Indeed, add check is better.
> If msg number is 1, means normal write or read, not "write then read".
The quirks will increase the message count and check 'write then read'
for us. We don't have to add check here.
<...>
> > > +static int mtk_i2c_remove(struct platform_device *pdev)
> > > +{
> > > + struct mtk_i2c *i2c = platform_get_drvdata(pdev);
> > > +
> > > + i2c_del_adapter(>adap);
> > > + free_i2c_dma_bufs(i2c);
> > > + platform_set_drvdata(pdev, NULL);
> > > +
> > Here you need to make sure that no irq is running when i2c_del_adapter
> > is called.
> OK, add check here
I thought after i2c_del_adapter() is complete, all i2c_transfer for this
adapter is completed. If this is true, then i2c clock is already off and
we won't have any on-going transfer/pending irq.
Joe.C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 03/12] clk: samsung: exynos5433: Add clocks for CMU_PERIC domain
This patch adds missing divider/gate clocks of CMU_PERIC domain
which includes I2S/PCM/SPDIF/PWM/SLIMBUS IPs. The SPI/I2S may use
external input clock which has 'ioclk_*' prefix.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
[ideal.song: Change clk flags of to pclk_gpio_* clk, pclk_gpio_* should be
always on.]
Signed-off-by: Inha Song
Acked-by: Inki Dae
---
drivers/clk/samsung/clk-exynos5433.c | 83 +-
include/dt-bindings/clock/exynos5433.h | 34 +-
2 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 077fa61..cfc9d69 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -251,6 +251,14 @@ static struct samsung_fixed_rate_clock top_fixed_clks[]
__initdata = {
FRATE(0, "ioclk_audiocdclk0", NULL, CLK_IS_ROOT, 1),
/* Xi2s1SDI input clock for SPDIF */
FRATE(0, "ioclk_spdif_extclk", NULL, CLK_IS_ROOT, 1),
+ /* XspiCLK[4:0] input clock for SPI */
+ FRATE(0, "ioclk_spi4_clk_in", NULL, CLK_IS_ROOT, 5000),
+ FRATE(0, "ioclk_spi3_clk_in", NULL, CLK_IS_ROOT, 5000),
+ FRATE(0, "ioclk_spi2_clk_in", NULL, CLK_IS_ROOT, 5000),
+ FRATE(0, "ioclk_spi1_clk_in", NULL, CLK_IS_ROOT, 5000),
+ FRATE(0, "ioclk_spi0_clk_in", NULL, CLK_IS_ROOT, 5000),
+ /* Xi2s1SCLK input clock for I2S1_BCLK */
+ FRATE(0, "ioclk_i2s1_bclk_in", NULL, CLK_IS_ROOT, 12288000),
};
static struct samsung_mux_clock top_mux_clks[] __initdata = {
@@ -756,6 +764,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif,
"samsung,exynos5433-cmu-mif",
* Register offset definitions for CMU_PERIC
*/
#define DIV_PERIC 0x0600
+#define DIV_STAT_PERIC 0x0700
#define ENABLE_ACLK_PERIC 0x0800
#define ENABLE_PCLK_PERIC0 0x0900
#define ENABLE_PCLK_PERIC1 0x0904
@@ -766,6 +775,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif,
"samsung,exynos5433-cmu-mif",
static unsigned long peric_clk_regs[] __initdata = {
DIV_PERIC,
+ DIV_STAT_PERIC,
ENABLE_ACLK_PERIC,
ENABLE_PCLK_PERIC0,
ENABLE_PCLK_PERIC1,
@@ -775,14 +785,57 @@ static unsigned long peric_clk_regs[] __initdata = {
ENABLE_IP_PERIC2,
};
+static struct samsung_div_clock peric_div_clks[] __initdata = {
+ /* DIV_PERIC */
+ DIV(CLK_DIV_SCLK_SCI, "div_sclk_sci", "fin_pll", DIV_PERIC, 4, 4),
+ DIV(CLK_DIV_SCLK_SC_IN, "div_sclk_sc_in", "fin_pll", DIV_PERIC, 0, 4),
+};
+
static struct samsung_gate_clock peric_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_PERIC */
+ GATE(CLK_ACLK_AHB2APB_PERIC2P, "aclk_ahb2apb_peric2p", "aclk_peric_66",
+ ENABLE_ACLK_PERIC, 3, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_AHB2APB_PERIC1P, "aclk_ahb2apb_peric1p", "aclk_peric_66",
+ ENABLE_ACLK_PERIC, 2, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_AHB2APB_PERIC0P, "aclk_ahb2apb_peric0p", "aclk_peric_66",
+ ENABLE_ACLK_PERIC, 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_PERICNP_66, "aclk_pericnp_66", "aclk_peric_66",
+ ENABLE_ACLK_PERIC, 0, CLK_IGNORE_UNUSED, 0),
+
/* ENABLE_PCLK_PERIC0 */
+ GATE(CLK_PCLK_SCI, "pclk_sci", "aclk_peric_66", ENABLE_PCLK_PERIC0,
+ 31, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_PCLK_GPIO_FINGER, "pclk_gpio_finger", "aclk_peric_66",
+ ENABLE_PCLK_PERIC0, 30, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_GPIO_ESE, "pclk_gpio_ese", "aclk_peric_66",
+ ENABLE_PCLK_PERIC0, 29, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_PWM, "pclk_pwm", "aclk_peric_66", ENABLE_PCLK_PERIC0,
+ 28, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_PCLK_SPDIF, "pclk_spdif", "aclk_peric_66", ENABLE_PCLK_PERIC0,
+ 26, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_PCLK_PCM1, "pclk_pcm1", "aclk_peric_66", ENABLE_PCLK_PERIC0,
+ 25, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_PCLK_I2S1, "pclk_i2s", "aclk_peric_66", ENABLE_PCLK_PERIC0,
+ 24, CLK_SET_RATE_PARENT, 0),
GATE(CLK_PCLK_SPI2, "pclk_spi2", "aclk_peric_66", ENABLE_PCLK_PERIC0,
23, CLK_SET_RATE_PARENT, 0),
GATE(CLK_PCLK_SPI1, "pclk_spi1", "aclk_peric_66", ENABLE_PCLK_PERIC0,
22, CLK_SET_RATE_PARENT, 0),
GATE(CLK_PCLK_SPI0, "pclk_spi0", "aclk_peric_66", ENABLE_PCLK_PERIC0,
21, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_PCLK_ADCIF, "pclk_adcif", "aclk_peric_66", ENABLE_PCLK_PERIC0,
+ 20, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_PCLK_GPIO_TOUCH, "pclk_gpio_touch", "aclk_peric_66",
+ ENABLE_PCLK_PERIC0, 19, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_PCLK_GPIO_NFC,
Re: [PATCH] ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
On Tue, 2015-01-20 at 21:10 -0800, Paul E. McKenney wrote: > On Wed, Jan 21, 2015 at 04:40:39AM +0100, Mike Galbraith wrote: > > I've been curious about this for ages, so now is a great time to bite > > the bullet and ask TheMan. A context switch is not far away, why do we > > need that quiescent state badly enough to tell what looks like a little > > white lie to get it immediately? > > > > (I commented it out in an -rt kernel I was testing yesterday, beat it > > enthusiastically for a while, and box didn't _seem_ to notice that it > > was missing anything) > > Yeah, you do have to have a fairly violent network-based DoS attack > to see the difference. Robert Olsson was the first to make this happen > back in the day. Ah, my little NIC doesn't have enough poop to do that. Thanks. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/12] clk: samsung: exynos5433: Add clocks for CMU_G2D domain
This patch adds ths mux/divider/gate clocks of CMU_G2D domain which includes
G2D/MDMA IPs. The CMU_G2D must need the clocks related to G2D by providing
CMU_TOP domain. So, this patch add several clocks for G2D from CMU_TOP domain.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Pankaj Dubey
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 ++
drivers/clk/samsung/clk-exynos5433.c | 146 +
include/dt-bindings/clock/exynos5433.h | 42 +-
3 files changed, 195 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 72cd0ba..27dd77b 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -19,6 +19,8 @@ Required Properties:
which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs.
- "samsung,exynos5433-cmu-fsys" - clock controller compatible for CMU_FSYS
which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
+ - "samsung,exynos5433-cmu-g2d" - clock controller compatible for CMU_G2D
+which generates clocks for G2D/MDMA IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -70,6 +72,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_g2d: clock-controller@0x1246 {
+ compatible = "samsung,exynos5433-cmu-g2d";
+ reg = <0x1246 0x0b08>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 88e8651..9754c3d 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -398,6 +398,20 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
};
static struct samsung_div_clock top_div_clks[] __initdata = {
+ /* DIV_TOP1 */
+ DIV(CLK_DIV_ACLK_GSCL_111, "div_aclk_gscl_111", "mout_aclk_gscl_333",
+ DIV_TOP1, 28, 3),
+ DIV(CLK_DIV_ACLK_GSCL_333, "div_aclk_gscl_333", "mout_aclk_gscl_333",
+ DIV_TOP1, 24, 3),
+ DIV(CLK_DIV_ACLK_HEVC_400, "div_aclk_hevc_400", "mout_aclk_hevc_400",
+ DIV_TOP1, 20, 3),
+ DIV(CLK_DIV_ACLK_MFC_400, "div_aclk_mfc_400", "mout_aclk_mfc_400_c",
+ DIV_TOP1, 12, 3),
+ DIV(CLK_DIV_ACLK_G2D_266, "div_aclk_g2d_266", "mout_bus_pll_user",
+ DIV_TOP1, 8, 3),
+ DIV(CLK_DIV_ACLK_G2D_400, "div_aclk_g2d_400", "mout_aclk_g2d_400_b",
+ DIV_TOP1, 0, 3),
+
/* DIV_TOP2 */
DIV(CLK_DIV_ACLK_FSYS_200, "div_aclk_fsys_200", "mout_bus_pll_user",
DIV_TOP2, 0, 3),
@@ -490,6 +504,12 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_ACLK_FSYS_200, "aclk_fsys_200", "div_aclk_fsys_200",
ENABLE_ACLK_TOP, 18,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_G2D_266, "aclk_g2d_266", "div_aclk_g2d_266",
+ ENABLE_ACLK_TOP, 2,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_G2D_400, "aclk_g2d_400", "div_aclk_g2d_400",
+ ENABLE_ACLK_TOP, 0,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
/* ENABLE_SCLK_TOP_FSYS */
GATE(CLK_SCLK_MMC2_FSYS, "sclk_mmc2_fsys", "div_sclk_mmc2_b",
@@ -1277,3 +1297,129 @@ static void __init exynos5433_cmu_fsys_init(struct
device_node *np)
CLK_OF_DECLARE(exynos5433_cmu_fsys, "samsung,exynos5433-cmu-fsys",
exynos5433_cmu_fsys_init);
+
+/*
+ * Register offset definitions for CMU_G2D
+ */
+#define MUX_SEL_G2D0 0x0200
+#define MUX_SEL_ENABLE_G2D00x0300
+#define MUX_SEL_STAT_G2D0 0x0400
+#define DIV_G2D0x0600
+#define DIV_STAT_G2D 0x0700
+#define DIV_ENABLE_ACLK_G2D0x0800
+#define DIV_ENABLE_ACLK_G2D_SECURE_SMMU_G2D0x0804
+#define DIV_ENABLE_PCLK_G2D0x0900
+#define DIV_ENABLE_PCLK_G2D_SECURE_SMMU_G2D0x0904
+#define DIV_ENABLE_IP_G2D0 0x0b00
+#define DIV_ENABLE_IP_G2D1 0x0b04
+#define DIV_ENABLE_IP_G2D_SECURE_SMMU_G2D 0x0b08
+
+static unsigned long g2d_clk_regs[] __initdata = {
+ MUX_SEL_G2D0,
+ MUX_SEL_ENABLE_G2D0,
+ MUX_SEL_STAT_G2D0,
+ DIV_G2D,
+ DIV_STAT_G2D,
+ DIV_ENABLE_ACLK_G2D,
+ DIV_ENABLE_ACLK_G2D_SECURE_SMMU_G2D,
+ DIV_ENABLE_PCLK_G2D,
+
[PATCH v3 01/12] clk: samsung: exynos5433: Add clocks using common clock framework
This patch adds the support for CMU (Clock Management Units) of Exynos5433
which is 64bit SoC and has Octa-cores. This patch supports necessary clocks
(PLL/MMC/UART/MCT/I2C/SPI) for kernel boot and includes binding documentation
for Exynos5433 clock controller.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 106 +++
drivers/clk/samsung/Makefile | 1 +
drivers/clk/samsung/clk-exynos5433.c | 963 +
include/dt-bindings/clock/exynos5433.h | 199 +
4 files changed, 1269 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5433-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5433.c
create mode 100644 include/dt-bindings/clock/exynos5433.h
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
new file mode 100644
index 000..72cd0ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -0,0 +1,106 @@
+* Samsung Exynos5433 CMU (Clock Management Units)
+
+The Exynos5433 clock controller generates and supplies clock to various
+controllers within the Exynos5433 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+ - "samsung,exynos5433-cmu-top" - clock controller compatible for CMU_TOP
+which generates clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
+domains and bus clocks.
+ - "samsung,exynos5433-cmu-cpif" - clock controller compatible for CMU_CPIF
+which generates clocks for LLI (Low Latency Interface) IP.
+ - "samsung,exynos5433-cmu-mif" - clock controller compatible for CMU_MIF
+which generates clocks for DRAM Memory Controller domain.
+ - "samsung,exynos5433-cmu-peric" - clock controller compatible for CMU_PERIC
+which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs.
+ - "samsung,exynos5433-cmu-peris" - clock controller compatible for CMU_PERIS
+which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs.
+ - "samsung,exynos5433-cmu-fsys" - clock controller compatible for CMU_FSYS
+which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5433.h header and can be used in device
+tree sources.
+
+Example 1: Examples of clock controller nodes are listed below.
+
+ cmu_top: clock-controller@0x1003 {
+ compatible = "samsung,exynos5433-cmu-top";
+ reg = <0x1003 0x0c04>;
+ #clock-cells = <1>;
+ };
+
+ cmu_cpif: clock-controller@0x10fc {
+ compatible = "samsung,exynos5433-cmu-cpif";
+ reg = <0x10fc 0x0c04>;
+ #clock-cells = <1>;
+ };
+
+ cmu_mif: clock-controller@0x105b {
+ compatible = "samsung,exynos5433-cmu-mif";
+ reg = <0x105b 0x100c>;
+ #clock-cells = <1>;
+ };
+
+ cmu_peric: clock-controller@0x14c8 {
+ compatible = "samsung,exynos5433-cmu-peric";
+ reg = <0x14c8 0x0b08>;
+ #clock-cells = <1>;
+ };
+
+ cmu_peris: clock-controller@0x1004 {
+ compatible = "samsung,exynos5433-cmu-peris";
+ reg = <0x1004 0x0b20>;
+ #clock-cells = <1>;
+ };
+
+ cmu_fsys: clock-controller@0x156e {
+ compatible = "samsung,exynos5433-cmu-fsys";
+ reg = <0x156e 0x0b04>;
+ #clock-cells = <1>;
+ };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+ controller.
+
+ serial_0: serial@14C1 {
+ compatible = "samsung,exynos5433-uart";
+ reg = <0x14C1 0x100>;
+ interrupts = <0 421 0>;
+ clocks = <_peric CLK_PCLK_UART0>,
+<_peric CLK_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus>;
+ status = "disabled";
+ };
+
+Example 3: SPI controller node that consumes the clock generated by the clock
+ controller.
+
+ spi_0: spi@14d2 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d2 0x100>;
+ interrupts = <0 432 0>;
+ dmas = < 9>, < 8>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <_peric CLK_PCLK_SPI0>,
+
[PATCH v3 09/12] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
This patch adds the mux/divider/gate clocks for CMU_BUS{0|1|2} domains
which contain global data buses clocked at up the 400MHz. These blocks
transfer data between DRAM and various sub-blocks. These clock domains
also contain global peripheral buses clocked at 67/111/200/222/266/333/400
MHz and used for register accesses.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Cc: Arnd Bergmann
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Pankaj Dubey
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 21 +++
drivers/clk/samsung/clk-exynos5433.c | 187 +
include/dt-bindings/clock/exynos5433.h | 27 ++-
3 files changed, 234 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 9a6ae75..03ae40a 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -25,6 +25,9 @@ Required Properties:
which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.
- "samsung,exynos5433-cmu-aud" - clock controller compatible for CMU_AUD
which generates clocks for Cortex-A5/BUS/AUDIO clocks.
+ - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
+and "samsung,exynos5433-cmu-bus2" - clock controller compatible for CMU_BUS
+which generates global data buses clock and global peripheral buses clock.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -94,6 +97,24 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_bus0: clock-controller@0x1360 {
+ compatible = "samsung,exynos5433-cmu-bus0";
+ reg = <0x1360 0x0b04>;
+ #clock-cells = <1>;
+ };
+
+ cmu_bus1: clock-controller@0x1480 {
+ compatible = "samsung,exynos5433-cmu-bus1";
+ reg = <0x1480 0x0b04>;
+ #clock-cells = <1>;
+ };
+
+ cmu_bus2: clock-controller@0x1340 {
+ compatible = "samsung,exynos5433-cmu-bus2";
+ reg = <0x1340 0x0b04>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index a33ef2e..e79edd7 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -438,6 +438,14 @@ static struct samsung_div_clock top_div_clks[] __initdata
= {
DIV(CLK_DIV_ACLK_PERIS_66_A, "div_aclk_peris_66_a",
"mout_bus_pll_user", DIV_TOP3, 0, 3),
+ /* DIV_TOP4 */
+ DIV(CLK_DIV_ACLK_G3D_400, "div_aclk_g3d_400", "mout_bus_pll_user",
+ DIV_TOP4, 8, 3),
+ DIV(CLK_DIV_ACLK_BUS0_400, "div_aclk_bus0_400", "mout_aclk_bus0_400",
+ DIV_TOP4, 4, 3),
+ DIV(CLK_DIV_ACLK_BUS1_400, "div_aclk_bus1_400", "mout_bus_pll_user",
+ DIV_TOP4, 0, 3),
+
/* DIV_TOP_FSYS0 */
DIV(CLK_DIV_SCLK_MMC1_B, "div_sclk_mmc1_b", "div_sclk_mmc1_a",
DIV_TOP_FSYS0, 16, 8),
@@ -501,6 +509,23 @@ static struct samsung_div_clock top_div_clks[] __initdata
= {
static struct samsung_gate_clock top_gate_clks[] __initdata = {
/* ENABLE_ACLK_TOP */
+ GATE(CLK_ACLK_G3D_400, "aclk_g3d_400", "div_aclk_g3d_400",
+ ENABLE_ACLK_TOP, 30, 0, 0),
+ GATE(CLK_ACLK_IMEM_SSX_266, "aclk_imem_ssx_266",
+ "div_aclk_imem_sssx_266", ENABLE_ACLK_TOP,
+ 29, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_BUS0_400, "aclk_bus0_400", "div_aclk_bus0_400",
+ ENABLE_ACLK_TOP, 26,
+ CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_ACLK_BUS1_400, "aclk_bus1_400", "div_aclk_bus1_400",
+ ENABLE_ACLK_TOP, 25,
+ CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_ACLK_IMEM_200, "aclk_imem_200", "div_aclk_imem_266",
+ ENABLE_ACLK_TOP, 24,
+ CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_ACLK_IMEM_266, "aclk_imem_266", "div_aclk_imem_200",
+ ENABLE_ACLK_TOP, 23,
+ CLK_IGNORE_UNUSED | CLK_SET_RATE_PARENT, 0),
GATE(CLK_ACLK_PERIC_66, "aclk_peric_66", "div_aclk_peric_66_b",
ENABLE_ACLK_TOP, 22,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -2631,3 +2656,165 @@ static void __init exynos5433_cmu_aud_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_aud, "samsung,exynos5433-cmu-aud",
exynos5433_cmu_aud_init);
+
+
+/*
+ * Register offset
Re: [alsa-devel] [PATCH 0/3] Add master mode, tmd and right-j mode support
On Tue, Jan 20, 2015 at 11:15:54PM -0200, Fabio Estevam wrote: > Not related to your series, but do you have a patch for imx6sx-sdb.dts > that adds sai support? > > In the FSL version they use 'fsl,sdma-event-remap' property to specify > the SAI sdma channels, but this is not present in mainline? How are > you dealing with it? I think he must have those patches applied to his own local branch as I do :) I was quite hesitating to send them because the SDMA one doesn't look flawless, plus I don't know SDMA owner's plan for upstream. Nicolin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 08/12] clk: samsung: exynos5433: Add clocks for CMU_AUD domain
This patch adds the mux/divider/gate clocks for CMU_AUD domain which
includes the clocks of Cortex-A5/Bus/Audio clocks.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 7 +
drivers/clk/samsung/clk-exynos5433.c | 172 +
include/dt-bindings/clock/exynos5433.h | 53 +++
3 files changed, 232 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 8d3dad4..9a6ae75 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -23,6 +23,8 @@ Required Properties:
which generates clocks for G2D/MDMA IPs.
- "samsung,exynos5433-cmu-disp" - clock controller compatible for CMU_DISP
which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.
+ - "samsung,exynos5433-cmu-aud" - clock controller compatible for CMU_AUD
+which generates clocks for Cortex-A5/BUS/AUDIO clocks.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -86,6 +88,11 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_aud: clock-controller@0x114c {
+ compatible = "samsung,exynos5433-cmu-aud";
+ reg = <0x114c 0x0b04>;
+ #clock-cells = <1>;
+ };
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 3a3e64b..a33ef2e 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -2459,3 +2459,175 @@ static void __init exynos5433_cmu_disp_init(struct
device_node *np)
CLK_OF_DECLARE(exynos5433_cmu_disp, "samsung,exynos5433-cmu-disp",
exynos5433_cmu_disp_init);
+
+/*
+ * Register offset definitions for CMU_AUD
+ */
+#define MUX_SEL_AUD0 0x0200
+#define MUX_SEL_AUD1 0x0204
+#define MUX_ENABLE_AUD00x0300
+#define MUX_ENABLE_AUD10x0304
+#define MUX_STAT_AUD0 0x0400
+#define DIV_AUD0 0x0600
+#define DIV_AUD1 0x0604
+#define DIV_STAT_AUD0 0x0700
+#define DIV_STAT_AUD1 0x0704
+#define ENABLE_ACLK_AUD0x0800
+#define ENABLE_PCLK_AUD0x0900
+#define ENABLE_SCLK_AUD0 0x0a00
+#define ENABLE_SCLK_AUD1 0x0a04
+#define ENABLE_IP_AUD0 0x0b00
+#define ENABLE_IP_AUD1 0x0b04
+
+static unsigned long aud_clk_regs[] __initdata = {
+ MUX_SEL_AUD0,
+ MUX_SEL_AUD1,
+ MUX_ENABLE_AUD0,
+ MUX_ENABLE_AUD1,
+ MUX_STAT_AUD0,
+ DIV_AUD0,
+ DIV_AUD1,
+ DIV_STAT_AUD0,
+ DIV_STAT_AUD1,
+ ENABLE_ACLK_AUD,
+ ENABLE_PCLK_AUD,
+ ENABLE_SCLK_AUD0,
+ ENABLE_SCLK_AUD1,
+ ENABLE_IP_AUD0,
+ ENABLE_IP_AUD1,
+};
+
+/* list of all parent clock list */
+PNAME(mout_aud_pll_user_aud_p) = { "fin_pll", "fout_aud_pll", };
+PNAME(mout_sclk_aud_pcm_p) = { "mout_aud_pll_user", "ioclk_audiocdclk0",};
+
+static struct samsung_fixed_rate_clock aud_fixed_clks[] __initdata = {
+ FRATE(0, "ioclk_jtag_tclk", NULL, CLK_IS_ROOT, 3300),
+ FRATE(0, "ioclk_slimbus_clk", NULL, CLK_IS_ROOT, 2500),
+ FRATE(0, "ioclk_i2s_bclk", NULL, CLK_IS_ROOT, 5000),
+};
+
+static struct samsung_mux_clock aud_mux_clks[] __initdata = {
+ /* MUX_SEL_AUD0 */
+ MUX(CLK_MOUT_AUD_PLL_USER, "mout_aud_pll_user",
+ mout_aud_pll_user_aud_p, MUX_SEL_AUD0, 0, 1),
+
+ /* MUX_SEL_AUD1 */
+ MUX(CLK_MOUT_SCLK_AUD_PCM, "mout_sclk_aud_pcm", mout_sclk_aud_pcm_p,
+ MUX_SEL_AUD1, 8, 1),
+ MUX(CLK_MOUT_SCLK_AUD_I2S, "mout_sclk_aud_i2s", mout_sclk_aud_pcm_p,
+ MUX_SEL_AUD1, 0, 1),
+};
+
+static struct samsung_div_clock aud_div_clks[] __initdata = {
+ /* DIV_AUD0 */
+ DIV(CLK_DIV_ATCLK_AUD, "div_atclk_aud", "div_aud_ca5", DIV_AUD0,
+ 12, 4),
+ DIV(CLK_DIV_PCLK_DBG_AUD, "div_pclk_dbg_aud", "div_aud_ca5", DIV_AUD0,
+ 8, 4),
+ DIV(CLK_DIV_ACLK_AUD, "div_aclk_aud", "div_aud_ca5", DIV_AUD0,
+ 4, 4),
+ DIV(CLK_DIV_AUD_CA5, "div_aud_ca5", "mout_aud_pll_user", DIV_AUD0,
+ 0, 4),
+
+ /* DIV_AUD1 */
+ DIV(CLK_DIV_SCLK_AUD_SLIMBUS, "div_sclk_aud_slimbus",
+ "mout_aud_pll_user", DIV_AUD1, 16, 5),
+ DIV(CLK_DIV_SCLK_AUD_UART, "div_sclk_aud_uart", "mout_aud_pll_user",
+ DIV_AUD1, 12,
[PATCH v3 07/12] clk: samsung: exynos5433: Add clocks for CMU_DISP domain
This patch adds the the mux/divider/gate clocks for CMU_DISP domain which
includes the clocks of Display IPs (DECON/HDMI/DSIM/MIXER). The CMU_DISP clocks
is used to need the source clock of CMU_MIF domain so, the CMU_MIF's clocks
related to CMU_DISP should be always on state.
Also, CMU_DISP must need the source clock of 'sclk_hdmi_spdif_disp'
from CMU_TOP domain. This patch adds the clocks of CMU_TOP related to HDMI.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 9 +
drivers/clk/samsung/clk-exynos5433.c | 437 +
include/dt-bindings/clock/exynos5433.h | 114 +-
3 files changed, 559 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 27dd77b..8d3dad4 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -21,6 +21,8 @@ Required Properties:
which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
- "samsung,exynos5433-cmu-g2d" - clock controller compatible for CMU_G2D
which generates clocks for G2D/MDMA IPs.
+ - "samsung,exynos5433-cmu-disp" - clock controller compatible for CMU_DISP
+which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -78,6 +80,13 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_disp: clock-controller@0x13b9 {
+ compatible = "samsung,exynos5433-cmu-disp";
+ reg = <0x13b9 0x0c04>;
+ #clock-cells = <1>;
+ };
+
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 7e33c68..3a3e64b 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -245,6 +245,8 @@ PNAME(mout_sclk_audio1_p) = { "ioclk_audiocdclk1",
"fin_pll",
PNAME(mout_sclk_audio0_p) = { "ioclk_audiocdclk0", "fin_pll",
"mout_aud_pll_user_t",};
+PNAME(mout_sclk_hdmi_spdif_p) = { "sclk_audio1", "ioclk_spdif_extclk", };
+
static struct samsung_fixed_factor_clock top_fixed_factor_clks[] __initdata = {
FFACTOR(0, "oscclk_efuse_common", "fin_pll", 1, 1, 0),
};
@@ -395,6 +397,10 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
MUX_SEL_TOP_PERIC1, 4, 2),
MUX(CLK_MOUT_SCLK_AUDIO0, "mout_sclk_audio0", mout_sclk_audio0_p,
MUX_SEL_TOP_PERIC1, 0, 2),
+
+ /* MUX_SEL_TOP_DISP */
+ MUX(CLK_MOUT_SCLK_HDMI_SPDIF, "mout_sclk_hdmi_spdif",
+ mout_sclk_hdmi_spdif_p, MUX_SEL_TOP_DISP, 0, 1),
};
static struct samsung_div_clock top_div_clks[] __initdata = {
@@ -1360,6 +1366,11 @@ static struct samsung_gate_clock mif_gate_clks[]
__initdata = {
ENABLE_SCLK_MIF, 1, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_BUS_PLL_ATLAS, "sclk_bus_pll_atlas", "sclk_bus_pll",
ENABLE_SCLK_MIF, 0, CLK_IGNORE_UNUSED, 0),
+
+ /* ENABLE_SCLK_TOP_DISP */
+ GATE(CLK_SCLK_HDMI_SPDIF_DISP, "sclk_hdmi_spdif_disp",
+ "mout_sclk_hdmi_spdif", ENABLE_SCLK_TOP_DISP, 0,
+ CLK_IGNORE_UNUSED, 0),
};
static struct samsung_cmu_info mif_cmu_info __initdata = {
@@ -2022,3 +2033,429 @@ static void __init exynos5433_cmu_g2d_init(struct
device_node *np)
CLK_OF_DECLARE(exynos5433_cmu_g2d, "samsung,exynos5433-cmu-g2d",
exynos5433_cmu_g2d_init);
+
+/*
+ * Register offset definitions for CMU_DISP
+ */
+#define DISP_PLL_LOCK 0x
+#define DISP_PLL_CON0 0x0100
+#define DISP_PLL_CON1 0x0104
+#define DISP_PLL_FREQ_DET 0x0108
+#define MUX_SEL_DISP0 0x0200
+#define MUX_SEL_DISP1 0x0204
+#define MUX_SEL_DISP2 0x0208
+#define MUX_SEL_DISP3 0x020c
+#define MUX_SEL_DISP4 0x0210
+#define MUX_ENABLE_DISP0 0x0300
+#define MUX_ENABLE_DISP1 0x0304
+#define MUX_ENABLE_DISP2 0x0308
+#define MUX_ENABLE_DISP3 0x030c
+#define MUX_ENABLE_DISP4 0x0310
+#define MUX_STAT_DISP0 0x0400
+#define MUX_STAT_DISP1 0x0404
+#define MUX_STAT_DISP2 0x0408
+#define MUX_STAT_DISP3 0x040c
+#define MUX_STAT_DISP4 0x0410
+#define MUX_IGNORE_DISP2 0x0508
+#define DIV_DISP 0x0600
+#define DIV_DISP_PLL_FREQ_DET 0x0604
[PATCH v3 04/12] clk: samsung: exynos5433: Add clocks for CMU_PERIS domain
This patch adds missing gate clocks of CMU_PERIS domain
which includes TMU/TZPC/SECKEY/CHIPID/TOPRTC/EFUSE IPs.
The special clocks of CMU_PERIS use fin_pll source clock directly.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Pankaj Dubey
---
drivers/clk/samsung/clk-exynos5433.c | 151 -
include/dt-bindings/clock/exynos5433.h | 33 ++-
2 files changed, 181 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index cfc9d69..88e8651 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -245,6 +245,10 @@ PNAME(mout_sclk_audio1_p) = { "ioclk_audiocdclk1",
"fin_pll",
PNAME(mout_sclk_audio0_p) = { "ioclk_audiocdclk0", "fin_pll",
"mout_aud_pll_user_t",};
+static struct samsung_fixed_factor_clock top_fixed_factor_clks[] __initdata = {
+ FFACTOR(0, "oscclk_efuse_common", "fin_pll", 1, 1, 0),
+};
+
static struct samsung_fixed_rate_clock top_fixed_clks[] __initdata = {
/* Xi2s{0|1}CDCLK input clock for I2S/PCM */
FRATE(0, "ioclk_audiocdclk1", NULL, CLK_IS_ROOT, 1),
@@ -614,6 +618,8 @@ static struct samsung_cmu_info top_cmu_info __initdata = {
.nr_gate_clks = ARRAY_SIZE(top_gate_clks),
.fixed_clks = top_fixed_clks,
.nr_fixed_clks = ARRAY_SIZE(top_fixed_clks),
+ .fixed_factor_clks = top_fixed_factor_clks,
+ .nr_fixed_factor_clks = ARRAY_SIZE(top_fixed_factor_clks),
.nr_clk_ids = TOP_NR_CLK,
.clk_regs = top_clk_regs,
.nr_clk_regs= ARRAY_SIZE(top_clk_regs),
@@ -954,15 +960,69 @@ CLK_OF_DECLARE(exynos5433_cmu_peric,
"samsung,exynos5433-cmu-peric",
/*
* Register offset definitions for CMU_PERIS
*/
-#define ENABLE_ACLK_PERIS 0x0800
-#define ENABLE_PCLK_PERIS 0x0900
+#define ENABLE_ACLK_PERIS 0x0800
+#define ENABLE_PCLK_PERIS 0x0900
+#define ENABLE_PCLK_PERIS_SECURE_TZPC 0x0904
+#define ENABLE_PCLK_PERIS_SECURE_SECKEY_APBIF 0x0908
+#define ENABLE_PCLK_PERIS_SECURE_CHIPID_APBIF 0x090c
+#define ENABLE_PCLK_PERIS_SECURE_TOPRTC0x0910
+#define ENABLE_PCLK_PERIS_SECURE_CUSTOM_EFUSE_APBIF0x0914
+#define ENABLE_PCLK_PERIS_SECURE_ANTIRBK_CNT_APBIF 0x0918
+#define ENABLE_PCLK_PERIS_SECURE_OTP_CON_APBIF 0x091c
+#define ENABLE_SCLK_PERIS 0x0a00
+#define ENABLE_SCLK_PERIS_SECURE_SECKEY0x0a04
+#define ENABLE_SCLK_PERIS_SECURE_CHIPID0x0a08
+#define ENABLE_SCLK_PERIS_SECURE_TOPRTC0x0a0c
+#define ENABLE_SCLK_PERIS_SECURE_CUSTOM_EFUSE 0x0a10
+#define ENABLE_SCLK_PERIS_SECURE_ANTIRBK_CNT 0x0a14
+#define ENABLE_SCLK_PERIS_SECURE_OTP_CON 0x0a18
+#define ENABLE_IP_PERIS0 0x0b00
+#define ENABLE_IP_PERIS1 0x0b04
+#define ENABLE_IP_PERIS_SECURE_TZPC0x0b08
+#define ENABLE_IP_PERIS_SECURE_SECKEY 0x0b0c
+#define ENABLE_IP_PERIS_SECURE_CHIPID 0x0b10
+#define ENABLE_IP_PERIS_SECURE_TOPRTC 0x0b14
+#define ENABLE_IP_PERIS_SECURE_CUSTOM_EFUSE0x0b18
+#define ENABLE_IP_PERIS_SECURE_ANTIBRK_CNT 0x0b1c
+#define ENABLE_IP_PERIS_SECURE_OTP_CON 0x0b20
static unsigned long peris_clk_regs[] __initdata = {
ENABLE_ACLK_PERIS,
ENABLE_PCLK_PERIS,
+ ENABLE_PCLK_PERIS_SECURE_TZPC,
+ ENABLE_PCLK_PERIS_SECURE_SECKEY_APBIF,
+ ENABLE_PCLK_PERIS_SECURE_CHIPID_APBIF,
+ ENABLE_PCLK_PERIS_SECURE_TOPRTC,
+ ENABLE_PCLK_PERIS_SECURE_CUSTOM_EFUSE_APBIF,
+ ENABLE_PCLK_PERIS_SECURE_ANTIRBK_CNT_APBIF,
+ ENABLE_PCLK_PERIS_SECURE_OTP_CON_APBIF,
+ ENABLE_SCLK_PERIS,
+ ENABLE_SCLK_PERIS_SECURE_SECKEY,
+ ENABLE_SCLK_PERIS_SECURE_CHIPID,
+ ENABLE_SCLK_PERIS_SECURE_TOPRTC,
+ ENABLE_SCLK_PERIS_SECURE_CUSTOM_EFUSE,
+ ENABLE_SCLK_PERIS_SECURE_ANTIRBK_CNT,
+ ENABLE_SCLK_PERIS_SECURE_OTP_CON,
+ ENABLE_IP_PERIS0,
+ ENABLE_IP_PERIS1,
+ ENABLE_IP_PERIS_SECURE_TZPC,
+ ENABLE_IP_PERIS_SECURE_SECKEY,
+ ENABLE_IP_PERIS_SECURE_CHIPID,
+ ENABLE_IP_PERIS_SECURE_TOPRTC,
+ ENABLE_IP_PERIS_SECURE_CUSTOM_EFUSE,
+ ENABLE_IP_PERIS_SECURE_ANTIBRK_CNT,
+ ENABLE_IP_PERIS_SECURE_OTP_CON,
};
static struct samsung_gate_clock peris_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_PERIS */
+ GATE(CLK_ACLK_AHB2APB_PERIS1P, "aclk_ahb2apb_peris1p", "aclk_peris_66",
+ ENABLE_ACLK_PERIS, 2, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_AHB2APB_PERIS0P,
[PATCH v3 02/12] clk: samsung: exynos5433: Add MUX clocks of CMU_TOP domain
This patch adds the MUX (multiplexer) clocks for CMU_TOP domain of Exynos5433.
CMU_TOP domain provides source clocks to other CMU domains.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
Reviewed-by: Pankaj Dubey
---
drivers/clk/samsung/clk-exynos5433.c | 90 ++
include/dt-bindings/clock/exynos5433.h | 31 +++-
2 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 59a87bc..077fa61 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -208,6 +208,7 @@ PNAME(mout_mphy_pll_user_p) = { "fin_pll", "sclk_mphy_pll",
};
PNAME(mout_mfc_pll_user_p) = { "fin_pll", "sclk_mfc_pll", };
PNAME(mout_bus_pll_user_p) = { "fin_pll", "sclk_bus_pll", };
PNAME(mout_bus_pll_user_t_p) = { "fin_pll", "mout_bus_pll_user", };
+PNAME(mout_mphy_pll_user_t_p) = { "fin_pll", "mout_mphy_pll_user", };
PNAME(mout_bus_mfc_pll_user_p) = { "mout_bus_pll_user", "mout_mfc_pll_user",};
PNAME(mout_mfc_bus_pll_user_p) = { "mout_mfc_pll_user", "mout_bus_pll_user",};
@@ -215,6 +216,12 @@ PNAME(mout_aclk_cam1_552_b_p) = {
"mout_aclk_cam1_552_a",
"mout_mfc_pll_user", };
PNAME(mout_aclk_cam1_552_a_p) = { "mout_isp_pll", "mout_bus_pll_user", };
+PNAME(mout_aclk_mfc_400_c_p) = { "mout_aclk_mfc_400_b",
+ "mout_mphy_pll_user", };
+PNAME(mout_aclk_mfc_400_b_p) = { "mout_aclk_mfc_400_a",
+ "mout_bus_pll_user", };
+PNAME(mout_aclk_mfc_400_a_p) = { "mout_mfc_pll_user", "mout_isp_pll", };
+
PNAME(mout_bus_mphy_pll_user_p)= { "mout_bus_pll_user",
"mout_mphy_pll_user", };
PNAME(mout_aclk_mscl_b_p) = { "mout_aclk_mscl_400_a",
@@ -231,6 +238,21 @@ PNAME(mout_sclk_mmc0_d_p) = { "mout_sclk_mmc0_c",
"mout_isp_pll", };
PNAME(mout_sclk_mmc0_c_p) = { "mout_sclk_mmc0_b", "mout_mphy_pll_user",};
PNAME(mout_sclk_mmc0_b_p) = { "mout_sclk_mmc0_a", "mout_mfc_pll_user", };
+PNAME(mout_sclk_spdif_p) = { "sclk_audio0", "sclk_audio1",
+ "fin_pll", "ioclk_spdif_extclk", };
+PNAME(mout_sclk_audio1_p) = { "ioclk_audiocdclk1", "fin_pll",
+ "mout_aud_pll_user_t",};
+PNAME(mout_sclk_audio0_p) = { "ioclk_audiocdclk0", "fin_pll",
+ "mout_aud_pll_user_t",};
+
+static struct samsung_fixed_rate_clock top_fixed_clks[] __initdata = {
+ /* Xi2s{0|1}CDCLK input clock for I2S/PCM */
+ FRATE(0, "ioclk_audiocdclk1", NULL, CLK_IS_ROOT, 1),
+ FRATE(0, "ioclk_audiocdclk0", NULL, CLK_IS_ROOT, 1),
+ /* Xi2s1SDI input clock for SPDIF */
+ FRATE(0, "ioclk_spdif_extclk", NULL, CLK_IS_ROOT, 1),
+};
+
static struct samsung_mux_clock top_mux_clks[] __initdata = {
/* MUX_SEL_TOP0 */
MUX(CLK_MOUT_AUD_PLL, "mout_aud_pll", mout_aud_pll_p, MUX_SEL_TOP0,
@@ -276,6 +298,14 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
MUX(CLK_MOUT_ACLK_G2D_400_A, "mout_aclk_g2d_400_a",
mout_bus_mfc_pll_user_p, MUX_SEL_TOP3, 0, 1),
+ /* MUX_SEL_TOP4 */
+ MUX(CLK_MOUT_ACLK_MFC_400_C, "mout_aclk_mfc_400_c",
+ mout_aclk_mfc_400_c_p, MUX_SEL_TOP4, 8, 1),
+ MUX(CLK_MOUT_ACLK_MFC_400_B, "mout_aclk_mfc_400_b",
+ mout_aclk_mfc_400_b_p, MUX_SEL_TOP4, 4, 1),
+ MUX(CLK_MOUT_ACLK_MFC_400_A, "mout_aclk_mfc_400_a",
+ mout_aclk_mfc_400_a_p, MUX_SEL_TOP4, 0, 1),
+
/* MUX_SEL_TOP_MSCL */
MUX(CLK_MOUT_SCLK_JPEG_C, "mout_sclk_jpeg_c", mout_sclk_jpeg_c_p,
MUX_SEL_TOP_MSCL, 8, 1),
@@ -284,6 +314,20 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
MUX(CLK_MOUT_SCLK_JPEG_A, "mout_sclk_jpeg_a", mout_bus_pll_user_t_p,
MUX_SEL_TOP_MSCL, 0, 1),
+ /* MUX_SEL_TOP_CAM1 */
+ MUX(CLK_MOUT_SCLK_ISP_SENSOR2, "mout_sclk_isp_sensor2",
+ mout_bus_pll_user_t_p, MUX_SEL_TOP_CAM1, 24, 1),
+ MUX(CLK_MOUT_SCLK_ISP_SENSOR1, "mout_sclk_isp_sensor1",
+ mout_bus_pll_user_t_p, MUX_SEL_TOP_CAM1, 20, 1),
+ MUX(CLK_MOUT_SCLK_ISP_SENSOR0, "mout_sclk_isp_sensor0",
+ mout_bus_pll_user_t_p, MUX_SEL_TOP_CAM1, 16, 1),
+ MUX(CLK_MOUT_SCLK_ISP_UART, "mout_sclk_isp_uart",
+ mout_bus_pll_user_t_p, MUX_SEL_TOP_CAM1, 8, 1),
+ MUX(CLK_MOUT_SCLK_ISP_SPI1, "mout_sclk_isp_spi1",
+ mout_bus_pll_user_t_p, MUX_SEL_TOP_CAM1, 4, 1),
+ MUX(CLK_MOUT_SCLK_ISP_SPI0, "mout_sclk_isp_spi0",
+ mout_bus_pll_user_t_p, MUX_SEL_TOP_CAM1, 0, 1),
+
/* MUX_SEL_TOP_FSYS0 */
[PATCH v3 06/12] clk: samsung: exynos5433: Add clocks for CMU_MIF domain
This patch adds the mux/divider/gate clocks of CMU_MIF domain which includes
the clocks for DMC(DRAM memory controller) and CCI(Cache Coherent Interconnect).
The CMU_MIF domain provides the source clocks for CMU_DISP/CMU_BUS2.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
drivers/clk/samsung/clk-exynos5433.c | 599 +
include/dt-bindings/clock/exynos5433.h | 190 ++-
2 files changed, 788 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 9754c3d..7e33c68 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -740,6 +740,66 @@ CLK_OF_DECLARE(exynos5433_cmu_cpif,
"samsung,exynos5433-cmu-cpif",
#define MFC_PLL_CON0 0x0130
#define MFC_PLL_CON1 0x0134
#define MFC_PLL_FREQ_DET 0x013c
+#define MUX_SEL_MIF0 0x0200
+#define MUX_SEL_MIF1 0x0204
+#define MUX_SEL_MIF2 0x0208
+#define MUX_SEL_MIF3 0x020c
+#define MUX_SEL_MIF4 0x0210
+#define MUX_SEL_MIF5 0x0214
+#define MUX_SEL_MIF6 0x0218
+#define MUX_SEL_MIF7 0x021c
+#define MUX_ENABLE_MIF00x0300
+#define MUX_ENABLE_MIF10x0304
+#define MUX_ENABLE_MIF20x0308
+#define MUX_ENABLE_MIF30x030c
+#define MUX_ENABLE_MIF40x0310
+#define MUX_ENABLE_MIF50x0314
+#define MUX_ENABLE_MIF60x0318
+#define MUX_ENABLE_MIF70x031c
+#define MUX_STAT_MIF0 0x0400
+#define MUX_STAT_MIF1 0x0404
+#define MUX_STAT_MIF2 0x0408
+#define MUX_STAT_MIF3 0x040c
+#define MUX_STAT_MIF4 0x0410
+#define MUX_STAT_MIF5 0x0414
+#define MUX_STAT_MIF6 0x0418
+#define MUX_STAT_MIF7 0x041c
+#define DIV_MIF1 0x0604
+#define DIV_MIF2 0x0608
+#define DIV_MIF3 0x060c
+#define DIV_MIF4 0x0610
+#define DIV_MIF5 0x0614
+#define DIV_MIF_PLL_FREQ_DET 0x0618
+#define DIV_STAT_MIF1 0x0704
+#define DIV_STAT_MIF2 0x0708
+#define DIV_STAT_MIF3 0x070c
+#define DIV_STAT_MIF4 0x0710
+#define DIV_STAT_MIF5 0x0714
+#define DIV_STAT_MIF_PLL_FREQ_DET 0x0718
+#define ENABLE_ACLK_MIF0 0x0800
+#define ENABLE_ACLK_MIF1 0x0804
+#define ENABLE_ACLK_MIF2 0x0808
+#define ENABLE_ACLK_MIF3 0x080c
+#define ENABLE_PCLK_MIF0x0900
+#define ENABLE_PCLK_MIF_SECURE_DREX0_TZ0x0904
+#define ENABLE_PCLK_MIF_SECURE_DREX1_TZ0x0908
+#define ENABLE_PCLK_MIF_SECURE_MONOTONIC_CNT 0x090c
+#define ENABLE_PCLK_MIF_SECURE_RTC 0x0910
+#define ENABLE_SCLK_MIF0x0a00
+#define ENABLE_IP_MIF0 0x0b00
+#define ENABLE_IP_MIF1 0x0b04
+#define ENABLE_IP_MIF2 0x0b08
+#define ENABLE_IP_MIF3 0x0b0c
+#define ENABLE_IP_MIF_SECURE_DREX0_TZ 0x0b10
+#define ENABLE_IP_MIF_SECURE_DREX1_TZ 0x0b14
+#define ENABLE_IP_MIF_SECURE_MONOTONIC_CNT 0x0b18
+#define ENABLE_IP_MIF_SECURE_RTC 0x0b1c
+#define CLKOUT_CMU_MIF 0x0c00
+#define CLKOUT_CMU_MIF_DIV_STAT0x0c04
+#define DREX_FREQ_CTRL00x1000
+#define DREX_FREQ_CTRL10x1004
+#define PAUSE 0x1008
+#define DDRPHY_LOCK_CTRL 0x100c
static unsigned long mif_clk_regs[] __initdata = {
MEM0_PLL_LOCK,
@@ -758,6 +818,66 @@ static unsigned long mif_clk_regs[] __initdata = {
MFC_PLL_CON0,
MFC_PLL_CON1,
MFC_PLL_FREQ_DET,
+ MUX_SEL_MIF0,
+ MUX_SEL_MIF1,
+ MUX_SEL_MIF2,
+ MUX_SEL_MIF3,
+ MUX_SEL_MIF4,
+ MUX_SEL_MIF5,
+ MUX_SEL_MIF6,
+ MUX_SEL_MIF7,
+ MUX_ENABLE_MIF0,
+ MUX_ENABLE_MIF1,
+ MUX_ENABLE_MIF2,
+ MUX_ENABLE_MIF3,
+ MUX_ENABLE_MIF4,
+ MUX_ENABLE_MIF5,
+ MUX_ENABLE_MIF6,
+ MUX_ENABLE_MIF7,
+ MUX_STAT_MIF0,
+ MUX_STAT_MIF1,
+ MUX_STAT_MIF2,
+ MUX_STAT_MIF3,
+ MUX_STAT_MIF4,
+ MUX_STAT_MIF5,
+ MUX_STAT_MIF6,
+ MUX_STAT_MIF7,
+ DIV_MIF1,
+ DIV_MIF2,
+ DIV_MIF3,
+ DIV_MIF4,
+ DIV_MIF5,
+ DIV_MIF_PLL_FREQ_DET,
+ DIV_STAT_MIF1,
+ DIV_STAT_MIF2,
+ DIV_STAT_MIF3,
+ DIV_STAT_MIF4,
+ DIV_STAT_MIF5,
+ DIV_STAT_MIF_PLL_FREQ_DET,
+ ENABLE_ACLK_MIF0,
+
[PATCH v3 00/12] clk: samsung: Add the support for exynos5433 clocks
This patchset adds the support for Exynos5433 CMU (Clock Management Unit)
by using common clock framework. This patchset is divided from patch[1]
and then sent it.
[1] https://lkml.org/lkml/2014/12/2/134
Changelog:
Changes from v2:
- Fix the parent clock of sclk_bus_pll/sclk_mfc_pll clock on CMU_MIF domain
- Fix wrong clock name of 'phyclk_usbdrd30_udrd30_{pipe_pclk|phyclock}_phy'
clock
- Add the clock id for CMU_FSYS fixed clock
- Fix wrong bit width of CLK_DIV_SCLK_SCI clock on CMU_PERIC domain
- Remove duplicat parent clocks on CMU_DISP/CMU_AUD domains
- Fix typo on patch descriptions
- Fix wrong fixed rate on CMU_AUD domain (ioclk_{jtag_|slimbus_|i2s_b}clk)
- Add CLK_IGNORE_UNUSED flag to 'aclk_dmac/sclk_aud_i2s' clock for audio
subsystem
- Fix the parent clock of mout_aclk_fsys_200_user clock from aclk_fsys_200 to
div_aclk_fsys_200
Changes from v1:
- Fix wrong register and code clean by using space instead of tab [Pankaj]
- Add CLK_IGNORE_UNUSED flag to pclk_sysreg_* clock for accessing system
control register
- Remove duplicate definition on the patch for CMU_BUS{0|1|2} domain
Chanwoo Choi (12):
clk: samsung: exynos5433: Add clocks using common clock framework
clk: samsung: exynos5433: Add MUX clocks of CMU_TOP domain
clk: samsung: exynos5433: Add clocks for CMU_PERIC domain
clk: samsung: exynos5433: Add clocks for CMU_PERIS domain
clk: samsung: exynos5433: Add clocks for CMU_G2D domain
clk: samsung: exynos5433: Add clocks for CMU_MIF domain
clk: samsung: exynos5433: Add clocks for CMU_DISP domain
clk: samsung: exynos5433: Add clocks for CMU_AUD domain
clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
clk: samsung: exynos5433: Add missing clocks for CMU_FSYS domain
clk: samsung: exynos5433: Add clocks for CMU_G3D domain
clk: samsung: exynos5433: Add clocks for CMU_GSCL domain
.../devicetree/bindings/clock/exynos5433-clock.txt | 167 +
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos5433.c | 3395
include/dt-bindings/clock/exynos5433.h | 857 +
4 files changed, 4420 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5433-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5433.c
create mode 100644 include/dt-bindings/clock/exynos5433.h
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 03/10] zsmalloc: implement reverse mapping
This patch supports reverse mapping which gets handle from object.
For keeping handle per object, it allocates ZS_HANDLE_SIZE greater
than size user requested and stores handle in the extra space.
IOW, *(address mapped by zs_map_object - ZS_HANDLE_SIZE) == handle.
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9436ee8..2df2f1b 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -142,7 +142,8 @@
/* ZS_MIN_ALLOC_SIZE must be multiple of ZS_ALIGN */
#define ZS_MIN_ALLOC_SIZE \
MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
-#define ZS_MAX_ALLOC_SIZE PAGE_SIZE
+/* each chunk includes extra space to keep handle */
+#define ZS_MAX_ALLOC_SIZE (PAGE_SIZE + ZS_HANDLE_SIZE)
/*
* On systems with 4K page size, this gives 255 size classes! There is a
@@ -235,8 +236,17 @@ struct size_class {
* This must be power of 2 and less than or equal to ZS_ALIGN
*/
struct link_free {
- /* Handle of next free chunk (encodes ) */
- void *next;
+ union {
+ /*
+* Position of next free chunk (encodes )
+* It's valid for non-allocated object
+*/
+ void *next;
+ /*
+* Handle of allocated object.
+*/
+ unsigned long handle;
+ };
};
struct zs_pool {
@@ -896,12 +906,16 @@ static void __zs_unmap_object(struct mapping_area *area,
{
int sizes[2];
void *addr;
- char *buf = area->vm_buf;
+ char *buf;
/* no write fastpath */
if (area->vm_mm == ZS_MM_RO)
goto out;
+ buf = area->vm_buf + ZS_HANDLE_SIZE;
+ size -= ZS_HANDLE_SIZE;
+ off += ZS_HANDLE_SIZE;
+
sizes[0] = PAGE_SIZE - off;
sizes[1] = size - sizes[0];
@@ -1196,6 +1210,7 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
handle,
struct size_class *class;
struct mapping_area *area;
struct page *pages[2];
+ void *ret;
BUG_ON(!handle);
@@ -1217,7 +1232,8 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
handle,
if (off + class->size <= PAGE_SIZE) {
/* this object is contained entirely within a page */
area->vm_addr = kmap_atomic(page);
- return area->vm_addr + off;
+ ret = area->vm_addr + off;
+ goto out;
}
/* this object spans two pages */
@@ -1225,7 +1241,9 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
handle,
pages[1] = get_next_page(page);
BUG_ON(!pages[1]);
- return __zs_map_object(area, pages, off, class->size);
+ ret = __zs_map_object(area, pages, off, class->size);
+out:
+ return ret + ZS_HANDLE_SIZE;
}
EXPORT_SYMBOL_GPL(zs_map_object);
@@ -1282,13 +1300,15 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t
size)
struct page *first_page, *m_page;
unsigned long m_objidx, m_offset;
- if (unlikely(!size || size > ZS_MAX_ALLOC_SIZE))
+ if (unlikely(!size || (size + ZS_HANDLE_SIZE) > ZS_MAX_ALLOC_SIZE))
return 0;
handle = alloc_handle(pool);
if (!handle)
return 0;
+ /* extra space in chunk to keep the handle */
+ size += ZS_HANDLE_SIZE;
class = pool->size_class[get_size_class_index(size)];
spin_lock(>lock);
@@ -1318,7 +1338,9 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t size)
vaddr = kmap_atomic(m_page);
link = (struct link_free *)vaddr + m_offset / sizeof(*link);
first_page->freelist = link->next;
- memset(link, POISON_INUSE, sizeof(*link));
+
+ /* record handle in the header of allocated chunk */
+ link->handle = handle;
kunmap_atomic(vaddr);
first_page->inuse++;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 04/10] zsmalloc: factor out obj_[malloc|free]
In later patch, migration needs a part of function in zs_[malloc|free].
So, this patch factor out them.
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 99 ---
1 file changed, 61 insertions(+), 38 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 2df2f1b..e52b1b6 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -525,11 +525,10 @@ static void remove_zspage(struct page *page, struct
size_class *class,
* page from the freelist of the old fullness group to that of the new
* fullness group.
*/
-static enum fullness_group fix_fullness_group(struct zs_pool *pool,
+static enum fullness_group fix_fullness_group(struct size_class *class,
struct page *page)
{
int class_idx;
- struct size_class *class;
enum fullness_group currfg, newfg;
BUG_ON(!is_first_page(page));
@@ -539,7 +538,6 @@ static enum fullness_group fix_fullness_group(struct
zs_pool *pool,
if (newfg == currfg)
goto out;
- class = pool->size_class[class_idx];
remove_zspage(page, class, currfg);
insert_zspage(page, class, newfg);
set_zspage_mapping(page, class_idx, newfg);
@@ -1281,6 +1279,33 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long
handle)
}
EXPORT_SYMBOL_GPL(zs_unmap_object);
+static unsigned long obj_malloc(struct page *first_page,
+ struct size_class *class, unsigned long handle)
+{
+ unsigned long obj;
+ struct link_free *link;
+
+ struct page *m_page;
+ unsigned long m_objidx, m_offset;
+ void *vaddr;
+
+ obj = (unsigned long)first_page->freelist;
+ obj_to_location(obj, _page, _objidx);
+ m_offset = obj_idx_to_offset(m_page, m_objidx, class->size);
+
+ vaddr = kmap_atomic(m_page);
+ link = (struct link_free *)vaddr + m_offset / sizeof(*link);
+ first_page->freelist = link->next;
+ /* record handle in the header of allocated chunk */
+ link->handle = handle;
+ kunmap_atomic(vaddr);
+ first_page->inuse++;
+ zs_stat_inc(class, OBJ_USED, 1);
+
+ return obj;
+}
+
+
/**
* zs_malloc - Allocate block of given size from pool.
* @pool: pool to allocate from
@@ -1293,12 +1318,8 @@ EXPORT_SYMBOL_GPL(zs_unmap_object);
unsigned long zs_malloc(struct zs_pool *pool, size_t size)
{
unsigned long handle, obj;
- struct link_free *link;
struct size_class *class;
- void *vaddr;
-
- struct page *first_page, *m_page;
- unsigned long m_objidx, m_offset;
+ struct page *first_page;
if (unlikely(!size || (size + ZS_HANDLE_SIZE) > ZS_MAX_ALLOC_SIZE))
return 0;
@@ -1331,22 +1352,9 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t
size)
class->size, class->pages_per_zspage));
}
- obj = (unsigned long)first_page->freelist;
- obj_to_location(obj, _page, _objidx);
- m_offset = obj_idx_to_offset(m_page, m_objidx, class->size);
-
- vaddr = kmap_atomic(m_page);
- link = (struct link_free *)vaddr + m_offset / sizeof(*link);
- first_page->freelist = link->next;
-
- /* record handle in the header of allocated chunk */
- link->handle = handle;
- kunmap_atomic(vaddr);
-
- first_page->inuse++;
- zs_stat_inc(class, OBJ_USED, 1);
+ obj = obj_malloc(first_page, class, handle);
/* Now move the zspage to another fullness group, if required */
- fix_fullness_group(pool, first_page);
+ fix_fullness_group(class, first_page);
record_obj(handle, obj);
spin_unlock(>lock);
@@ -1354,46 +1362,61 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t
size)
}
EXPORT_SYMBOL_GPL(zs_malloc);
-void zs_free(struct zs_pool *pool, unsigned long handle)
+static void obj_free(struct zs_pool *pool, struct size_class *class,
+ unsigned long obj)
{
struct link_free *link;
struct page *first_page, *f_page;
- unsigned long obj, f_objidx, f_offset;
+ unsigned long f_objidx, f_offset;
void *vaddr;
-
int class_idx;
- struct size_class *class;
enum fullness_group fullness;
- if (unlikely(!handle))
- return;
+ BUG_ON(!obj);
- obj = handle_to_obj(handle);
- free_handle(pool, handle);
obj_to_location(obj, _page, _objidx);
first_page = get_first_page(f_page);
get_zspage_mapping(first_page, _idx, );
- class = pool->size_class[class_idx];
f_offset = obj_idx_to_offset(f_page, f_objidx, class->size);
- spin_lock(>lock);
+ vaddr = kmap_atomic(f_page);
/* Insert this object in containing zspage's freelist */
- vaddr = kmap_atomic(f_page);
link = (struct link_free *)(vaddr + f_offset);
link->next = first_page->freelist;
Re: [PATCH 0/6] randomize kernel physical address and virtual address separately
On Tue, Jan 20, 2015 at 7:37 PM, Baoquan He wrote: > Currently kaslr only randomize physical address of kernel loading, then add > the delta > to virtual address of kernel text mapping. Because kernel virtual address can > only be > from __START_KERNEL_map to > LOAD_PHYSICAL_ADDR+CONFIG_RANDOMIZE_BASE_MAX_OFFSET, namely > [0x8000, 0xc000], so physical address can only be > randomized > in region [LOAD_PHYSICAL_ADDR, CONFIG_RANDOMIZE_BASE_MAX_OFFSET], namely > [16M, 1G]. > > So hpa and Vivek suggested the randomization should be done separately for > both physical > and virtual address. In this patchset I tried it. And after randomization, > relocation > handling only depends on virtual address changing, means I only check whether > virtual > address is randomized to other position, if yes relocation need be handled, > if no just > skip the relocation handling though physical address is randomized to > different place. > Now physical address can be randomized from 16M to 4G, virtual address offset > can be > from 16M to 1G. This looks really great! Thanks for working on it! I'll wait to see what you find out about the #PF handler, and then I can start doing some testing too. -Kees > > Leftover problem: > hpa want to see the physical randomization can cover the whole physical > memory. I > checked code and found it's hard to do. Because in > arch/x86/boot/compressed/head_64.S > an identity mapping of 4G is built and then kaslr and decompressing are done. > The #PF > handler solution which he suggested is only available after jump into > decompressed > kernel, namely in arch/x86/kernel/head_64.S. I didn't think of a way to do > the whole > memory covering for physical address randomization, any suggestion or idea? > > Baoquan He (6): > remove a unused function parameter > a bug that relocation can not be handled when kernel is loaded above > 2G > Introduce a function to randomize the kernel text mapping address > adapt choose_kernel_location to add the kernel virtual address > randomzation > change the relocations behavior for kaslr on x86_64 > extend the upper limit of kernel physical address randomization to 4G > > arch/x86/boot/compressed/aslr.c | 69 > - > arch/x86/boot/compressed/misc.c | 34 +--- > arch/x86/boot/compressed/misc.h | 20 ++-- > 3 files changed, 82 insertions(+), 41 deletions(-) > > -- > 1.9.3 > -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 02/10] zsmalloc: decouple handle and object
Currently, zram's handle encodes object's location directly so
it makes hard to support migration/compaction.
This patch decouples handle and object via adding indirect layer.
For it, it allocates handle dynamically and returns it to user.
The handle is the address allocated by slab allocation so it's
unique and the memory allocated keeps object's position so that
we can get object's position from derefercing handle.
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 90 ---
1 file changed, 68 insertions(+), 22 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 0dec1fa..9436ee8 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -110,6 +110,8 @@
#define ZS_MAX_ZSPAGE_ORDER 2
#define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
+#define ZS_HANDLE_SIZE (sizeof(unsigned long))
+
/*
* Object location (, ) is encoded as
* as single (unsigned long) handle value.
@@ -241,6 +243,7 @@ struct zs_pool {
char *name;
struct size_class **size_class;
+ struct kmem_cache *handle_cachep;
gfp_t flags;/* allocation flags used when growing pool */
atomic_long_t pages_allocated;
@@ -269,6 +272,34 @@ struct mapping_area {
enum zs_mapmode vm_mm; /* mapping mode */
};
+static int create_handle_cache(struct zs_pool *pool)
+{
+ pool->handle_cachep = kmem_cache_create("zs_handle", ZS_HANDLE_SIZE,
+ 0, 0, NULL);
+ return pool->handle_cachep ? 0 : 1;
+}
+
+static void destroy_handle_cache(struct zs_pool *pool)
+{
+ kmem_cache_destroy(pool->handle_cachep);
+}
+
+static unsigned long alloc_handle(struct zs_pool *pool)
+{
+ return (unsigned long)kmem_cache_alloc(pool->handle_cachep,
+ pool->flags & ~__GFP_HIGHMEM);
+}
+
+static void free_handle(struct zs_pool *pool, unsigned long handle)
+{
+ kmem_cache_free(pool->handle_cachep, (void *)handle);
+}
+
+static void record_obj(unsigned long handle, unsigned long obj)
+{
+ *(unsigned long *)handle = obj;
+}
+
/* zpool driver */
#ifdef CONFIG_ZPOOL
@@ -595,13 +626,18 @@ static void *obj_location_to_handle(struct page *page,
unsigned long obj_idx)
* decoded obj_idx back to its original value since it was adjusted in
* obj_location_to_handle().
*/
-static void obj_handle_to_location(unsigned long handle, struct page **page,
+static void obj_to_location(unsigned long handle, struct page **page,
unsigned long *obj_idx)
{
*page = pfn_to_page(handle >> OBJ_INDEX_BITS);
*obj_idx = (handle & OBJ_INDEX_MASK) - 1;
}
+static unsigned long handle_to_obj(unsigned long handle)
+{
+ return *(unsigned long *)handle;
+}
+
static unsigned long obj_idx_to_offset(struct page *page,
unsigned long obj_idx, int class_size)
{
@@ -1153,7 +1189,7 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
handle,
enum zs_mapmode mm)
{
struct page *page;
- unsigned long obj_idx, off;
+ unsigned long obj, obj_idx, off;
unsigned int class_idx;
enum fullness_group fg;
@@ -1170,7 +1206,8 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
handle,
*/
BUG_ON(in_interrupt());
- obj_handle_to_location(handle, , _idx);
+ obj = handle_to_obj(handle);
+ obj_to_location(obj, , _idx);
get_zspage_mapping(get_first_page(page), _idx, );
class = pool->size_class[class_idx];
off = obj_idx_to_offset(page, obj_idx, class->size);
@@ -1195,7 +1232,7 @@ EXPORT_SYMBOL_GPL(zs_map_object);
void zs_unmap_object(struct zs_pool *pool, unsigned long handle)
{
struct page *page;
- unsigned long obj_idx, off;
+ unsigned long obj, obj_idx, off;
unsigned int class_idx;
enum fullness_group fg;
@@ -1204,7 +1241,8 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long
handle)
BUG_ON(!handle);
- obj_handle_to_location(handle, , _idx);
+ obj = handle_to_obj(handle);
+ obj_to_location(obj, , _idx);
get_zspage_mapping(get_first_page(page), _idx, );
class = pool->size_class[class_idx];
off = obj_idx_to_offset(page, obj_idx, class->size);
@@ -1236,7 +1274,7 @@ EXPORT_SYMBOL_GPL(zs_unmap_object);
*/
unsigned long zs_malloc(struct zs_pool *pool, size_t size)
{
- unsigned long obj;
+ unsigned long handle, obj;
struct link_free *link;
struct size_class *class;
void *vaddr;
@@ -1247,6 +1285,10 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t
size)
if (unlikely(!size || size > ZS_MAX_ALLOC_SIZE))
return 0;
+ handle = alloc_handle(pool);
+ if (!handle)
+ return 0;
+
class = pool->size_class[get_size_class_index(size)];
spin_lock(>lock);
@@ -1255,8 +1297,10 @@ unsigned long zs_malloc(struct
[PATCH v1 05/10] zsmalloc: add status bit
For migration, we need to identify which object in zspage is
allocated so that we could migrate allocated(ie, used) object.
We could know it by iterating of freed objects in a zspage
but it's inefficient. Instead, this patch adds a tag(ie,
OBJ_ALLOCATED_TAG) in the head of each object(ie, handle) so
we could check the object is allocated or not efficiently
during migration. Mixing the tag into handle kept in the memory
is okay because handle is allocated by slab so least two bit
is free to use it.
Another status bit this patch is adding is HANDLE_PIN_TAG.
During migration, it cannot move the object user are using
by zs_map_object due to data coherency between old object and
new object. Migration will check it to skip the object in
later patch.
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 64 ---
1 file changed, 48 insertions(+), 16 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index e52b1b6..99555da 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -135,7 +135,24 @@
#endif
#endif
#define _PFN_BITS (MAX_PHYSMEM_BITS - PAGE_SHIFT)
-#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS)
+
+/*
+ * Memory for allocating handle keeps object position by
+ * encoding and the encoded value has a room
+ * in the least bit(ie, look at obj_to_location).
+ * We use the bit to indicate the object is accessed by client
+ * via zs_map_object so the migraion can skip the object.
+ */
+#define HANDLE_PIN_TAG 1
+
+/*
+ * Head in allocated object should have OBJ_ALLOCATED_TAG.
+ * It's okay to keep the handle valid because handle is 4byte-aligned
+ * address so we have room for two bit.
+ */
+#define OBJ_ALLOCATED_TAG 1
+#define OBJ_TAG_BITS 1
+#define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
#define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
#define MAX(a, b) ((a) >= (b) ? (a) : (b))
@@ -610,35 +627,35 @@ static struct page *get_next_page(struct page *page)
/*
* Encode as a single handle value.
- * On hardware platforms with physical memory starting at 0x0 the pfn
- * could be 0 so we ensure that the handle will never be 0 by adjusting the
- * encoded obj_idx value before encoding.
+ * We use the least bit of handle for tagging.
*/
-static void *obj_location_to_handle(struct page *page, unsigned long obj_idx)
+static void *location_to_obj(struct page *page, unsigned long obj_idx)
{
- unsigned long handle;
+ unsigned long obj;
if (!page) {
BUG_ON(obj_idx);
return NULL;
}
- handle = page_to_pfn(page) << OBJ_INDEX_BITS;
- handle |= ((obj_idx + 1) & OBJ_INDEX_MASK);
+ obj = page_to_pfn(page) << OBJ_INDEX_BITS;
+ obj |= ((obj_idx) & OBJ_INDEX_MASK);
+ obj <<= OBJ_TAG_BITS;
- return (void *)handle;
+ return (void *)obj;
}
/*
* Decode pair from the given object handle. We adjust the
* decoded obj_idx back to its original value since it was adjusted in
- * obj_location_to_handle().
+ * location_to_obj().
*/
-static void obj_to_location(unsigned long handle, struct page **page,
+static void obj_to_location(unsigned long obj, struct page **page,
unsigned long *obj_idx)
{
- *page = pfn_to_page(handle >> OBJ_INDEX_BITS);
- *obj_idx = (handle & OBJ_INDEX_MASK) - 1;
+ obj >>= OBJ_TAG_BITS;
+ *page = pfn_to_page(obj >> OBJ_INDEX_BITS);
+ *obj_idx = (obj & OBJ_INDEX_MASK);
}
static unsigned long handle_to_obj(unsigned long handle)
@@ -657,6 +674,16 @@ static unsigned long obj_idx_to_offset(struct page *page,
return off + obj_idx * class_size;
}
+static void pin_tag(unsigned long handle)
+{
+ record_obj(handle, *(unsigned long *)handle | HANDLE_PIN_TAG);
+}
+
+static void unpin_tag(unsigned long handle)
+{
+ record_obj(handle, *(unsigned long *)handle & ~HANDLE_PIN_TAG);
+}
+
static void reset_page(struct page *page)
{
clear_bit(PG_private, >flags);
@@ -718,7 +745,7 @@ static void init_zspage(struct page *first_page, struct
size_class *class)
link = (struct link_free *)vaddr + off / sizeof(*link);
while ((off += class->size) < PAGE_SIZE) {
- link->next = obj_location_to_handle(page, i++);
+ link->next = location_to_obj(page, i++);
link += class->size / sizeof(*link);
}
@@ -728,7 +755,7 @@ static void init_zspage(struct page *first_page, struct
size_class *class)
* page (if present)
*/
next_page = get_next_page(page);
- link->next = obj_location_to_handle(next_page, 0);
+ link->next = location_to_obj(next_page, 0);
kunmap_atomic(vaddr);
page = next_page;
off %= PAGE_SIZE;
@@ -782,7 +809,7 @@ static struct page *alloc_zspage(struct size_class *class,
gfp_t
[PATCH v1 06/10] zsmalloc: support compaction
This patch provides core functions for migration of zsmalloc.
Migraion policy is simple as follows.
It searches source zspages from ZS_ALMOST_EMPTY and destination
zspages from ZS_ALMOST_FULL and try to move objects in source
zspage into destination zspages. If it is lack of destination
pages in ZS_ALMOST_FULL, it falls back to ZS_ALMOST_EMPTY.
If all objects in source zspage moved out, the zspage could be
freed.
Migrate uses rcu freeing to free source zspage in migration
since migration could race with object accessing via
zs_map_object so that we can access size_class from handle
safely with rcu_read_[un]lock but it needs to recheck
handle's validity.
Signed-off-by: Minchan Kim
---
include/linux/zsmalloc.h | 1 +
mm/zsmalloc.c| 324 ++-
2 files changed, 321 insertions(+), 4 deletions(-)
diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h
index 3283c6a..1338190 100644
--- a/include/linux/zsmalloc.h
+++ b/include/linux/zsmalloc.h
@@ -47,5 +47,6 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
handle,
void zs_unmap_object(struct zs_pool *pool, unsigned long handle);
unsigned long zs_get_total_pages(struct zs_pool *pool);
+unsigned long zs_compact(struct zs_pool *pool);
#endif
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 99555da..99bf5bd 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -663,6 +663,11 @@ static unsigned long handle_to_obj(unsigned long handle)
return *(unsigned long *)handle;
}
+unsigned long obj_to_head(void *obj)
+{
+ return *(unsigned long *)obj;
+}
+
static unsigned long obj_idx_to_offset(struct page *page,
unsigned long obj_idx, int class_size)
{
@@ -1044,6 +1049,13 @@ static bool can_merge(struct size_class *prev, int size,
int pages_per_zspage)
return true;
}
+static bool zspage_full(struct page *page)
+{
+ BUG_ON(!is_first_page(page));
+
+ return page->inuse == page->objects;
+}
+
#ifdef CONFIG_ZSMALLOC_STAT
static inline void zs_stat_inc(struct size_class *class,
@@ -1246,12 +1258,27 @@ void *zs_map_object(struct zs_pool *pool, unsigned long
handle,
*/
BUG_ON(in_interrupt());
- pin_tag(handle);
-
+retry:
+ /*
+* Migrating object will not be destroyed so we can get a first_page
+* safely but need to verify handle again.
+*/
+ rcu_read_lock();
obj = handle_to_obj(handle);
obj_to_location(obj, , _idx);
get_zspage_mapping(get_first_page(page), _idx, );
class = pool->size_class[class_idx];
+ spin_lock(>lock);
+ if (obj != handle_to_obj(handle)) {
+ /* the object was moved by migration. Then fetch new object */
+ spin_unlock(>lock);
+ rcu_read_unlock();
+ goto retry;
+ }
+ rcu_read_unlock();
+ /* From now on, migration cannot move the object */
+ pin_tag(handle);
+ spin_unlock(>lock);
off = obj_idx_to_offset(page, obj_idx, class->size);
area = _cpu_var(zs_map_area);
@@ -1305,7 +1332,9 @@ void zs_unmap_object(struct zs_pool *pool, unsigned long
handle)
__zs_unmap_object(area, pages, off, class->size);
}
put_cpu_var(zs_map_area);
+ spin_lock(>lock);
unpin_tag(handle);
+ spin_unlock(>lock);
}
EXPORT_SYMBOL_GPL(zs_unmap_object);
@@ -1434,9 +1463,9 @@ void zs_free(struct zs_pool *pool, unsigned long handle)
if (unlikely(!handle))
return;
-
+retry:
+ rcu_read_lock();
obj = handle_to_obj(handle);
- free_handle(pool, handle);
obj_to_location(obj, _page, _objidx);
first_page = get_first_page(f_page);
@@ -1444,6 +1473,15 @@ void zs_free(struct zs_pool *pool, unsigned long handle)
class = pool->size_class[class_idx];
spin_lock(>lock);
+ /* Retry if migrate moves object */
+ if (obj != handle_to_obj(handle)) {
+ spin_unlock(>lock);
+ rcu_read_unlock();
+ goto retry;
+ }
+ rcu_read_unlock();
+
+ free_handle(pool, handle);
obj_free(pool, class, obj);
fullness = fix_fullness_group(class, first_page);
if (fullness == ZS_EMPTY)
@@ -1459,6 +1497,284 @@ void zs_free(struct zs_pool *pool, unsigned long handle)
}
EXPORT_SYMBOL_GPL(zs_free);
+static void zs_object_copy(unsigned long src, unsigned long dst,
+ struct size_class *class)
+{
+ struct page *s_page, *d_page;
+ unsigned long s_objidx, d_objidx;
+ unsigned long s_off, d_off;
+ void *s_addr, *d_addr;
+ int s_size, d_size, size;
+ int written = 0;
+
+ s_size = d_size = class->size;
+
+ obj_to_location(src, _page, _objidx);
+ obj_to_location(dst, _page, _objidx);
+
+ s_off = obj_idx_to_offset(s_page, s_objidx, class->size);
+ d_off =
[PATCH v1 07/10] zsmalloc: adjust ZS_ALMOST_FULL
Curretly, zsmalloc regards a zspage as ZS_ALMOST_EMPTY if the zspage has under 1/4 used objects(ie, fullness_threshold_frac). It could make result in loose packing since zsmalloc migrates only ZS_ALMOST_EMPTY zspage out. This patch changes the rule so that zsmalloc makes zspage which has above 3/4 used object ZS_ALMOST_FULL so it could make tight packing. Signed-off-by: Minchan Kim --- mm/zsmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 99bf5bd..8217e8e 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -477,7 +477,7 @@ static enum fullness_group get_fullness_group(struct page *page) fg = ZS_EMPTY; else if (inuse == max_objects) fg = ZS_FULL; - else if (inuse <= max_objects / fullness_threshold_frac) + else if (inuse <= 3 * max_objects / fullness_threshold_frac) fg = ZS_ALMOST_EMPTY; else fg = ZS_ALMOST_FULL; -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[LKP] [x86_64,entry] 71428f63e68: -35.9% will-it-scale.time.user_time +8.2% will-it-scale.per_process_ops
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/entry-devel
commit 71428f63e681e1b4aa1a781e3ef7c27f027d1103 ("x86_64,entry: Use sysret to
return to userspace when possible")
testbox/testcase/testparams: wsm/will-it-scale/performance-unlink2
c9a418c3dc3993cb 71428f63e681e1b4aa1a781e3e
--
%stddev %change %stddev
\ |\
35.37 ± 0% -39.9% 21.24 ± 0% will-it-scale.time.user_time
206954 ± 0% +2.1% 211373 ± 0% will-it-scale.per_process_ops
992 ± 0% +1.3% 1005 ± 0% will-it-scale.time.system_time
35.37 ± 0% -39.9% 21.24 ± 0% time.user_time
8.51 ± 1% -18.5% 6.93 ± 1% perf-profile.cpu-cycles.close
157780 ± 1% +10.5% 174306 ± 2% slabinfo.kmalloc-256.active_objs
157803 ± 1% +10.5% 174330 ± 2% slabinfo.kmalloc-256.num_objs
4930 ± 1% +10.5% 5447 ± 2% slabinfo.kmalloc-256.active_slabs
4930 ± 1% +10.5% 5447 ± 2% slabinfo.kmalloc-256.num_slabs
157357 ± 1% +10.5% 173860 ± 2%
slabinfo.shmem_inode_cache.active_objs
157370 ± 1% +10.5% 173871 ± 2%
slabinfo.shmem_inode_cache.num_objs
6556 ± 1% +10.5% 7244 ± 2%
slabinfo.shmem_inode_cache.active_slabs
6556 ± 1% +10.5% 7244 ± 2%
slabinfo.shmem_inode_cache.num_slabs
44396 ± 2% +9.9% 48785 ± 2% proc-vmstat.nr_slab_unreclaimable
testbox/testcase/testparams: wsm/will-it-scale/performance-signal1
c9a418c3dc3993cb 71428f63e681e1b4aa1a781e3e
--
%stddev %change %stddev
\ |\
35.20 ± 2% -35.9% 22.56 ± 1% will-it-scale.time.user_time
365460 ± 1% +7.3% 391965 ± 2% will-it-scale.per_thread_ops
971513 ± 0% +8.2%1050889 ± 0% will-it-scale.per_process_ops
0.59 ± 1% -5.0% 0.56 ± 0% will-it-scale.scalability
1028 ± 0% +1.2% 1040 ± 0% will-it-scale.time.system_time
640 ± 33% -49.5%323 ± 20%
sched_debug.cfs_rq[7]:/.blocked_load_avg
127248 ± 37% +85.3% 235849 ± 22% sched_debug.cpu#1.ttwu_local
129447 ± 36% +84.0% 238199 ± 21% sched_debug.cpu#1.ttwu_count
129567 ± 36% +83.6% 237839 ± 22% sched_debug.cpu#1.sched_goidle
259984 ± 36% +83.4% 476883 ± 21% sched_debug.cpu#1.nr_switches
260083 ± 36% +83.4% 476997 ± 21% sched_debug.cpu#1.sched_count
725 ± 28% -44.9%400 ± 17%
sched_debug.cfs_rq[7]:/.tg_load_contrib
35.20 ± 2% -35.9% 22.56 ± 1% time.user_time
112 ± 30% -33.6% 74 ± 14% sched_debug.cfs_rq[1]:/.load
102 ± 19% -26.9% 74 ± 14% sched_debug.cpu#1.load
62 ± 4% +33.9% 84 ± 7%
sched_debug.cfs_rq[4]:/.runnable_load_avg
109 ± 3% -19.5% 87 ± 9% sched_debug.cpu#6.cpu_load[3]
52 ± 9% +19.6% 62 ± 11% sched_debug.cpu#10.cpu_load[2]
64 ± 8% +23.9% 80 ± 6% sched_debug.cpu#4.cpu_load[0]
61 ± 12% +35.2% 82 ± 23% sched_debug.cfs_rq[10]:/.load
103 ± 3% -17.1% 85 ± 6% sched_debug.cpu#6.cpu_load[2]
0.83 ± 3% +16.9% 0.97 ± 8%
perf-profile.cpu-cycles._raw_spin_lock_irq.get_signal.do_signal.do_notify_resume.int_signal
0.89 ± 3% +21.3% 1.08 ± 2%
perf-profile.cpu-cycles.setup_sigcontext.do_signal.do_notify_resume.int_signal.raise
114 ± 4% -19.0% 92 ± 11% sched_debug.cpu#6.cpu_load[4]
1861 ± 6% -16.2% 1560 ± 8% cpuidle.C3-NHM.usage
410 ± 6% -16.3%343 ± 9% cpuidle.C1-NHM.usage
3.18 ± 2% +13.8% 3.62 ± 3%
perf-profile.cpu-cycles.init_fpu.__restore_xstate_sig.restore_sigcontext.sys_rt_sigreturn.stub_rt_sigreturn
7.29 ± 1% +15.6% 8.43 ± 4%
perf-profile.cpu-cycles.__sigqueue_free.part.12.__dequeue_signal.dequeue_signal.get_signal.do_signal
0.92 ± 3% +11.7% 1.03 ± 4%
perf-profile.cpu-cycles.system_call.handler
3469 ± 2% -18.2% 2838 ± 15% sched_debug.cpu#1.curr->pid
2.37 ± 1% +13.1% 2.67 ± 4%
perf-profile.cpu-cycles.free_uid.__sigqueue_free.__dequeue_signal.dequeue_signal.get_signal
13.43 ± 2% +13.4% 15.23 ± 3%
perf-profile.cpu-cycles.get_signal.do_signal.do_notify_resume.int_signal.raise
12.93 ± 3% +12.8% 14.58 ± 4%
perf-profile.cpu-cycles.__send_signal.send_signal.do_send_sig_info.do_send_specific.do_tkill
2.67 ± 1% +12.7% 3.01 ± 4%
perf-profile.cpu-cycles.memset.init_fpu.__restore_xstate_sig.restore_sigcontext.sys_rt_sigreturn
10.12 ± 2% +11.9% 11.33 ± 3%
Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree
* Andy Lutomirski wrote: > On Tue, Jan 20, 2015 at 9:55 PM, Ingo Molnar wrote: > > > > * Andy Lutomirski wrote: > > > >> On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar wrote: > >> > > >> > * Andy Lutomirski wrote: > >> > > >> >> Hi Ingo and Thomas- > >> >> > >> >> There's a trivial conflict in the pull request I sent last week. > >> > > >> > This is your x86 entry code rework pull request, right? The -tip > >> > tree now has the RCU commit it depends on, so could you please > >> > rebase it on top of tip:core/rcu so I can pull it? I'll resolve > >> > any remaining conflicts with the rest of -tip. > >> > > >> > >> Sure, I can do that in the morning. The pull request merges cleanly > >> with tip:core/rcu, though, so is the rebase needed? > > > > Yes, because your changes rely on the RCU change (semantically), > > so if anyone bisects into your commits it might result in a > > subtly broken kernel, right? > > Almost. The parent of my original pull request is the RCU > change that my entry changes semantically depend on, so > bisection should be fine. Okay, that's good - so now I can pull your bits, because the RCU commit is final, no need to rebase. (Because you already based your bits on the RCU change that later on ended up in -tip.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 08/10] zram: support compaction
Now that zsmalloc supports compaction, zram can use it.
For the first step, this patch exports compact knob via sysfs
so user can do compaction via "echo 1 > /sys/block/zram0/compact".
Signed-off-by: Minchan Kim
---
Documentation/ABI/testing/sysfs-block-zram | 8
drivers/block/zram/zram_drv.c | 25 +
drivers/block/zram/zram_drv.h | 1 +
3 files changed, 34 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block-zram
b/Documentation/ABI/testing/sysfs-block-zram
index a6148ea..91ad707 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -141,3 +141,11 @@ Description:
amount of memory ZRAM can use to store the compressed data. The
limit could be changed in run time and "0" means disable the
limit. No limit is the initial state. Unit: bytes
+
+What: /sys/block/zram/compact
+Date: August 2015
+Contact: Minchan Kim
+Description:
+ The compact file is write-only and trigger compaction for
+ allocator zrm uses. The allocator moves some objects so that
+ it could free fragment space.
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 7e03d86..7ac8dae 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -246,6 +246,27 @@ static ssize_t comp_algorithm_store(struct device *dev,
return len;
}
+static ssize_t compact_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ unsigned long nr_migrated;
+ struct zram *zram = dev_to_zram(dev);
+ struct zram_meta *meta;
+
+ down_read(>init_lock);
+ if (!init_done(zram)) {
+ up_read(>init_lock);
+ return -EINVAL;
+ }
+
+ meta = zram->meta;
+ nr_migrated = zs_compact(meta->mem_pool);
+ atomic64_add(nr_migrated, >stats.num_migrated);
+ up_read(>init_lock);
+
+ return len;
+}
+
/* flag operations needs meta->tb_lock */
static int zram_test_flag(struct zram_meta *meta, u32 index,
enum zram_pageflags flag)
@@ -994,6 +1015,7 @@ static const struct block_device_operations zram_devops = {
.owner = THIS_MODULE
};
+static DEVICE_ATTR_WO(compact);
static DEVICE_ATTR_RW(disksize);
static DEVICE_ATTR_RO(initstate);
static DEVICE_ATTR_WO(reset);
@@ -1012,6 +1034,7 @@ ZRAM_ATTR_RO(invalid_io);
ZRAM_ATTR_RO(notify_free);
ZRAM_ATTR_RO(zero_pages);
ZRAM_ATTR_RO(compr_data_size);
+ZRAM_ATTR_RO(num_migrated);
static struct attribute *zram_disk_attrs[] = {
_attr_disksize.attr,
@@ -1021,6 +1044,8 @@ static struct attribute *zram_disk_attrs[] = {
_attr_num_writes.attr,
_attr_failed_reads.attr,
_attr_failed_writes.attr,
+ _attr_num_migrated.attr,
+ _attr_compact.attr,
_attr_invalid_io.attr,
_attr_notify_free.attr,
_attr_zero_pages.attr,
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index b05a816..5e7a565 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -84,6 +84,7 @@ struct zram_stats {
atomic64_t compr_data_size; /* compressed size of pages stored */
atomic64_t num_reads; /* failed + successful */
atomic64_t num_writes; /* --do-- */
+ atomic64_t num_migrated;/* no. of migrated object */
atomic64_t failed_reads;/* can happen when memory is too low */
atomic64_t failed_writes; /* can happen when memory is too low */
atomic64_t invalid_io; /* non-page-aligned I/O requests */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 01/10] zram: avoid calling of zram_meta_free under init_lock
We don't need to call zram_meta_free under init_lock.
What we need to prevent race is setting NULL into zram->meta
(ie, init_done). This patch does it.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9250b3f..7e03d86 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -719,6 +719,8 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
}
meta = zram->meta;
+ zram->meta = NULL;
+
/* Free all pages that are still in this zram device */
for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
unsigned long handle = meta->table[index].handle;
@@ -731,8 +733,6 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
zcomp_destroy(zram->comp);
zram->max_comp_streams = 1;
- zram_meta_free(zram->meta);
- zram->meta = NULL;
/* Reset stats */
memset(>stats, 0, sizeof(zram->stats));
@@ -741,6 +741,7 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
set_capacity(zram->disk, 0);
up_write(>init_lock);
+ zram_meta_free(meta);
/*
* Revalidate disk out of the init_lock to avoid lockdep splat.
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] cpuset: fix crash when adding CPUs to an empty set
While creating a set of shielded CPUs, we passed cpuset_cpumask_can_shrink() an empty cpumask (cur), and dl_bw_of(cpumask_any(cur)) made boom with it. [ 514.513841] CPU: 0 PID: 6942 Comm: shield.sh Not tainted 3.19.0-master #19 [ 514.513841] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007 [ 514.513841] task: 880224552450 ti: 8800caab8000 task.ti: 8800caab8000 [ 514.513841] RIP: 0010:[] [] cpuset_cpumask_can_shrink+0x56/0xb0 [ 514.513841] RSP: 0018:8800caabbda8 EFLAGS: 00010202 [ 514.513841] RAX: RBX: 880037ae2ab8 RCX: [ 514.513841] RDX: 00012900 RSI: RDI: 000c [ 514.513841] RBP: 8800caabbdc8 R08: 880037ae2ab8 R09: 0034 [ 514.513841] R10: 0077e6fd3d1a R11: 88022e9b301c R12: 880223c98ab8 [ 514.513841] R13: 880037ae2a00 R14: 0004 R15: 8802254b3c60 [ 514.513841] FS: 7fdbab533700() GS:88022fc0() knlGS: [ 514.513841] CS: 0010 DS: ES: CR0: 80050033 [ 514.513841] CR2: 78ab8000 CR3: bef11000 CR4: 07f0 [ 514.513841] Stack: [ 514.513841] 880223c98ab8 81a46c20 880223c98a00 880037ae2a00 [ 514.513841] 8800caabbdf8 810cb82a 8800caabbdf8 880037ae2a00 [ 514.513841] 8800ca9e5240 8800caabbe48 810cc877 [ 514.513841] Call Trace: [ 514.513841] [] validate_change+0x18a/0x200 [ 514.513841] [] cpuset_write_resmask+0x3b7/0x720 [ 514.513841] [] cgroup_file_write+0x38/0x100 [ 514.513841] [] kernfs_fop_write+0x12a/0x180 [ 514.513841] [] vfs_write+0xb3/0x1d0 [ 514.513841] [] SyS_write+0x46/0xb0 [ 514.513841] [] system_call_fastpath+0x16/0x1b Signed-off-by: Mike Galbraith --- kernel/cpuset.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/cpuset.c +++ b/kernel/cpuset.c @@ -511,7 +511,7 @@ static int validate_change(struct cpuset * tasks. */ ret = -EBUSY; - if (is_cpu_exclusive(cur) && + if (is_cpu_exclusive(cur) && !cpumask_empty(cur->cpus_allowed) && !cpuset_cpumask_can_shrink(cur->cpus_allowed, trial->cpus_allowed)) goto out; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 10/10] zsmalloc: record handle in page->private for huge object
We stores handle on header of each allocated object so it
increases the size of each object by sizeof(unsigned long).
If zram stores 4096 bytes to zsmalloc(ie, bad compression),
zsmalloc needs 4104B-class to store the data with handle.
However, 4104B-class has 1-pages_per_zspage so wasted size by
internal fragment is 8192 - 4104, which is terrible.
So this patch records the handle in page->private on such
huge object(ie, pages_per_zspage == 1 && maxobj_per_zspage == 1)
instead of header of each object so we could use 4096B-class,
not 4104B-class.
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 54 ++
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 48b702e..c9f9230 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -57,6 +57,8 @@
*
* page->private (union with page->first_page): refers to the
* component page after the first page
+ * If the page is first_page for huge object, it stores handle.
+ * Look at size_class->huge.
* page->freelist: points to the first free object in zspage.
* Free objects are linked together using in-place
* metadata.
@@ -160,7 +162,7 @@
#define ZS_MIN_ALLOC_SIZE \
MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
/* each chunk includes extra space to keep handle */
-#define ZS_MAX_ALLOC_SIZE (PAGE_SIZE + ZS_HANDLE_SIZE)
+#define ZS_MAX_ALLOC_SIZE PAGE_SIZE
/*
* On systems with 4K page size, this gives 255 size classes! There is a
@@ -238,6 +240,8 @@ struct size_class {
/* Number of PAGE_SIZE sized pages to combine to form a 'zspage' */
int pages_per_zspage;
+ /* huge object: pages_per_zspage == 1 && maxobj_per_zspage == 1 */
+ bool huge;
#ifdef CONFIG_ZSMALLOC_STAT
struct zs_size_stat stats;
@@ -299,6 +303,7 @@ struct mapping_area {
#endif
char *vm_addr; /* address of kmap_atomic()'ed pages */
enum zs_mapmode vm_mm; /* mapping mode */
+ bool huge;
};
static int create_handle_cache(struct zs_pool *pool)
@@ -461,7 +466,7 @@ static int get_size_class_index(int size)
idx = DIV_ROUND_UP(size - ZS_MIN_ALLOC_SIZE,
ZS_SIZE_CLASS_DELTA);
- return idx;
+ return min(zs_size_classes - 1, idx);
}
#ifdef CONFIG_ZSMALLOC_STAT
@@ -847,9 +852,14 @@ static unsigned long handle_to_obj(unsigned long handle)
return *(unsigned long *)handle;
}
-unsigned long obj_to_head(void *obj)
+static unsigned long obj_to_head(struct size_class *class, struct page *page,
+ void *obj)
{
- return *(unsigned long *)obj;
+ if (class->huge) {
+ VM_BUG_ON(!is_first_page(page));
+ return *(unsigned long *)page_private(page);
+ } else
+ return *(unsigned long *)obj;
}
static unsigned long obj_idx_to_offset(struct page *page,
@@ -1126,9 +1136,12 @@ static void __zs_unmap_object(struct mapping_area *area,
if (area->vm_mm == ZS_MM_RO)
goto out;
- buf = area->vm_buf + ZS_HANDLE_SIZE;
- size -= ZS_HANDLE_SIZE;
- off += ZS_HANDLE_SIZE;
+ buf = area->vm_buf;
+ if (!area->huge) {
+ buf = buf + ZS_HANDLE_SIZE;
+ size -= ZS_HANDLE_SIZE;
+ off += ZS_HANDLE_SIZE;
+ }
sizes[0] = PAGE_SIZE - off;
sizes[1] = size - sizes[0];
@@ -1316,7 +1329,10 @@ retry:
ret = __zs_map_object(area, pages, off, class->size);
out:
- return ret + ZS_HANDLE_SIZE;
+ if (!class->huge)
+ ret += ZS_HANDLE_SIZE;
+
+ return ret;
}
EXPORT_SYMBOL_GPL(zs_map_object);
@@ -1375,8 +1391,12 @@ static unsigned long obj_malloc(struct page *first_page,
vaddr = kmap_atomic(m_page);
link = (struct link_free *)vaddr + m_offset / sizeof(*link);
first_page->freelist = link->next;
- /* record handle in the header of allocated chunk */
- link->handle = handle;
+ if (!class->huge)
+ /* record handle in the header of allocated chunk */
+ link->handle = handle;
+ else
+ /* record handle in first_page->private */
+ set_page_private(first_page, handle);
kunmap_atomic(vaddr);
first_page->inuse++;
zs_stat_inc(class, OBJ_USED, 1);
@@ -1400,7 +1420,7 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t size)
struct size_class *class;
struct page *first_page;
- if (unlikely(!size || (size + ZS_HANDLE_SIZE) > ZS_MAX_ALLOC_SIZE))
+ if (unlikely(!size || size > ZS_MAX_ALLOC_SIZE))
return 0;
handle = alloc_handle(pool);
@@ -1410,6 +1430,11 @@ unsigned long zs_malloc(struct zs_pool *pool, size_t
size)
/* extra space in chunk to keep the handle */
size += ZS_HANDLE_SIZE;
Re: [PATCH v3 04/16] virtio/console: verify device has config space
On (Tue) 20 Jan 2015 [13:09:55], Michael S. Tsirkin wrote: > On Tue, Jan 20, 2015 at 04:10:40PM +0530, Amit Shah wrote: > > On (Wed) 14 Jan 2015 [19:27:35], Michael S. Tsirkin wrote: > > > Some devices might not implement config space access > > > (e.g. remoteproc used not to - before 3.9). > > > virtio/console needs config space access so make it > > > fail gracefully if not there. > > > > Do we know any such devices? Wondering what prompted this patch. If > > it's just theoretical, I'd rather let it be like this, and pull this > > in when there's a device that doesn't have config space. > > Yes, with virtio 1.0 config space can be in a separate BAR now. If > that's not enabled by BIOS (e.g. out of space), we won't have config > space. I'm still not sure whether we should pull in this patch before actually seeing a failure. You do have a dev_err which tells why the probe failed, so it's an acceptable compromise I suppose. > > Also, just the console functionality (i.e. F_MULTIPORT is unset) is > > available w/o config space access. > > Supporting this by gracefully disabling F_MULTIPORT > would require getting this info from driver before > features are finalized. > Alternatively, check F_MULTIPORT and only fail if set? > Let me know, I'll cook up a patch. Yes, failing only if F_MULTIPORT is set is a better option (if we have to fail). > > In fact, getting this patch in > > would mean remoteproc wouldn't even run in its pre-config days... > > It seems to have get callback unconditionally now - or did I miss > something? What I meant was remoteproc doesn't depend on the config space, only uses the console functionality. If remoteproc devices didn't expose a config space, this patch would cause it to lose its console functionality for no apparent reason. Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 09/10] zsmalloc: add fullness into stat
During investigating compaction, fullness information of each class
and pages_per_zspage are helpful for investigating how compaction
works well on each size class.
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 349 +++---
1 file changed, 184 insertions(+), 165 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 8217e8e..48b702e 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -192,6 +192,8 @@ enum fullness_group {
enum zs_stat_type {
OBJ_ALLOCATED,
OBJ_USED,
+ CLASS_ALMOST_FULL,
+ CLASS_ALMOST_EMPTY,
NR_ZS_STAT_TYPE,
};
@@ -404,6 +406,11 @@ static struct zpool_driver zs_zpool_driver = {
MODULE_ALIAS("zpool-zsmalloc");
#endif /* CONFIG_ZPOOL */
+static unsigned int get_maxobj_per_zspage(int size, int pages_per_zspage)
+{
+ return pages_per_zspage * PAGE_SIZE / size;
+}
+
/* per-cpu VM mapping areas for zspage accesses that cross page boundaries */
static DEFINE_PER_CPU(struct mapping_area, zs_map_area);
@@ -457,6 +464,179 @@ static int get_size_class_index(int size)
return idx;
}
+#ifdef CONFIG_ZSMALLOC_STAT
+
+static inline void zs_stat_inc(struct size_class *class,
+ enum zs_stat_type type, unsigned long cnt)
+{
+ class->stats.objs[type] += cnt;
+}
+
+static inline void zs_stat_dec(struct size_class *class,
+ enum zs_stat_type type, unsigned long cnt)
+{
+ class->stats.objs[type] -= cnt;
+}
+
+static inline unsigned long zs_stat_get(struct size_class *class,
+ enum zs_stat_type type)
+{
+ return class->stats.objs[type];
+}
+
+static int __init zs_stat_init(void)
+{
+ if (!debugfs_initialized())
+ return -ENODEV;
+
+ zs_stat_root = debugfs_create_dir("zsmalloc", NULL);
+ if (!zs_stat_root)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static void __exit zs_stat_exit(void)
+{
+ debugfs_remove_recursive(zs_stat_root);
+}
+
+static int zs_stats_size_show(struct seq_file *s, void *v)
+{
+ int i;
+ struct zs_pool *pool = s->private;
+ struct size_class *class;
+ int objs_per_zspage;
+ unsigned long class_almost_full, class_almost_empty;
+ unsigned long obj_allocated, obj_used, pages_used;
+ unsigned long total_class_almost_full = 0, total_class_almost_empty = 0;
+ unsigned long total_objs = 0, total_used_objs = 0, total_pages = 0;
+
+ seq_printf(s, " %5s %5s %11s %12s %13s %10s %10s %16s\n",
+ "class", "size", "almost_full", "almost_empty",
+ "obj_allocated", "obj_used", "pages_used",
+ "pages_per_zspage");
+
+ for (i = 0; i < zs_size_classes; i++) {
+ class = pool->size_class[i];
+
+ if (class->index != i)
+ continue;
+
+ spin_lock(>lock);
+ class_almost_full = zs_stat_get(class, CLASS_ALMOST_FULL);
+ class_almost_empty = zs_stat_get(class, CLASS_ALMOST_EMPTY);
+ obj_allocated = zs_stat_get(class, OBJ_ALLOCATED);
+ obj_used = zs_stat_get(class, OBJ_USED);
+ spin_unlock(>lock);
+
+ objs_per_zspage = get_maxobj_per_zspage(class->size,
+ class->pages_per_zspage);
+ pages_used = obj_allocated / objs_per_zspage *
+ class->pages_per_zspage;
+
+ seq_printf(s, " %5u %5u %11lu %12lu %13lu %10lu %10lu %16d\n",
+ i, class->size, class_almost_full, class_almost_empty,
+ obj_allocated, obj_used, pages_used,
+ class->pages_per_zspage);
+
+ total_class_almost_full += class_almost_full;
+ total_class_almost_empty += class_almost_empty;
+ total_objs += obj_allocated;
+ total_used_objs += obj_used;
+ total_pages += pages_used;
+ }
+
+ seq_puts(s, "\n");
+ seq_printf(s, " %5s %5s %11lu %12lu %13lu %10lu %10lu\n",
+ "Total", "", total_class_almost_full,
+ total_class_almost_empty, total_objs,
+ total_used_objs, total_pages);
+
+ return 0;
+}
+
+static int zs_stats_size_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, zs_stats_size_show, inode->i_private);
+}
+
+static const struct file_operations zs_stat_size_ops = {
+ .open = zs_stats_size_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int zs_pool_stat_create(char *name, struct zs_pool *pool)
+{
+ struct dentry *entry;
+
+ if (!zs_stat_root)
+ return -ENODEV;
+
+ entry = debugfs_create_dir(name, zs_stat_root);
+ if (!entry) {
+
Re: [PATCHv3 00/36] perf tools: New build framework
* David Ahern wrote: > On 1/20/15 9:38 AM, Jiri Olsa wrote: > >The patchset is also available in: > > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > > perf/build > > Do I have to guess which branch? > > $ git branch -a | grep jirka | grep build > remotes/jirka/perf/build > remotes/jirka/perf/build_1 > remotes/jirka/perf/build_3 > remotes/jirka/perf/build_4 > remotes/jirka/perf/build_6 > remotes/jirka/perf/buildid_3 > remotes/jirka/perf/buildid_4 > remotes/jirka/perf/core_buildid_cache_clean > remotes/jirka/perf/kbuild1 > remotes/jirka/perf/kbuild2 > remotes/jirka/perf/kbuild3 > remotes/jirka/perf/kbuild4 > remotes/jirka/perf/kbuild7 > remotes/jirka/perf/kbuild9 I used 'perf/build' as announced, and it gave the same diffstat as the announcement. I guess the rest are WIP branches? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 00/10] zsmalloc compaction support
Recently, there was issue about zsmalloc fragmentation and I got a report from Juneho that new fork failed although there are plenty of free pages in the system. His investigation revealed zram is one of the culprit to make heavy fragmentation so there was no more contiguous 16K page for pgd to fork in the ARM. This patchset implement *basic* zsmalloc compaction support and zram utilizes it so admin can do "echo 1 > /sys/block/zram0/compact" In my experiment(high compress ratio data with heavy swap in/out on zram 8G swap), data is as follows, Before = zram allocated object : 60212066 bytes zram total used: 140103680 bytes ratio: 42.98 percent MemFree: 840192 kB Compaction After = frag ratio after compaction zram allocated object : 60212066 bytes zram total used: 76185600 bytes ratio: 79.03 percent MemFree: 901932 kB This patchset adds more logics in zsmalloc but when I tested heavy swapin/out program, the regression is marginal because most of overheads were caused by compress/decompress and other MM reclaim stuff. Minchan Kim (10): zram: avoid calling of zram_meta_free under init_lock zsmalloc: decouple handle and object zsmalloc: implement reverse mapping zsmalloc: factor out obj_[malloc|free] zsmalloc: add status bit zsmalloc: support compaction zsmalloc: adjust ZS_ALMOST_FULL zram: support compaction zsmalloc: add fullness into stat zsmalloc: record handle in page->private for huge object Documentation/ABI/testing/sysfs-block-zram |8 + drivers/block/zram/zram_drv.c | 30 +- drivers/block/zram/zram_drv.h |1 + include/linux/zsmalloc.h |1 + mm/zsmalloc.c | 1008 +--- 5 files changed, 786 insertions(+), 262 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range
walk_page_range silently skips vma having VM_PFNMAP set,
which leads to undesirable behaviour at client end (who
called walk_page_range). For example for pagemap_read,
when no callbacks are called against VM_PFNMAP vma,
pagemap_read may prepare pagemap data for next virtual
address range at wrong index.
Signed-off-by: Shiraz Hashim
---
The fix is revised, based upon the suggestion here at
http://www.spinics.net/lists/linux-mm/msg83058.html
mm/pagewalk.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index ad83195..b264bda 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -199,7 +199,10 @@ int walk_page_range(unsigned long addr, unsigned long end,
*/
if ((vma->vm_start <= addr) &&
(vma->vm_flags & VM_PFNMAP)) {
- next = vma->vm_end;
+ if (walk->pte_hole)
+ err = walk->pte_hole(addr, next, walk);
+ if (err)
+ break;
pgd = pgd_offset(walk->mm, next);
continue;
}
--
Shiraz Hashim
QUALCOMM INDIA, on behalf of 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/
Re: [PATCHv3 00/36] perf tools: New build framework
* Jiri Olsa wrote: > hi, > I'm following up on latest post from Alexis: > http://marc.info/?l=linux-kernel=141427580405357=2 > > v3 changes: > - disabling only builtin rules, keeping builtin variables in place > because some projects we depends on using them (traceevent) [David] > - fixed empy source list issue that happened on arm [Will, Mark] > - updated to the current Arnaldo's perf/core branch > - added automated tests into: tools/build/tests/ > - tested on arm64,ppc64,s390,x86_64,i386 > > v2 changes: > - build Makefiles librarized and moved to 'tools/build' [Ingo] > - several minor fixies [Namhyung] > - tested on other archs now - x86_64, i386, powerpc > - moved tools/lib/* under new build framework to show > that it's possible ;-) > included traceevent/lockdep maintainers to get the feedback > - omitted last 2 patches > > The patchset is also available in: > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/build > > All tests/make tests passed. Very nice! I gave it a quick test and saw no problems, behavior, speed and functionality of the build appears to be identical to the old system. > Also now we have the full dependency check ((gcc -Wp,-MD,... > stuff) and build command line is stored/checked automatically > by the build system. Btw., another thing that might be nice to extract into tools/build/ [or tools/config/] is the build/OS features detection framework - it goes hand in hand with the build system. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
On 01/21/2015 01:37 PM, Viresh Kumar wrote:
> On 21 January 2015 at 09:50, Chanwoo Choi wrote:
>> If the clock will be stayed on highest voltage, will reduce
>> the considerable benefit of power-consumption.
>
> But this is exactly what you must be doing right now as well..
> I think I didn't make it clear enough with an example. Let me
> try..
>
> This is how I feel it should look like:
>
>memory_bus_int: memory_bus@1 {
>// Regulator is shared for all below
>blocks {
>peri_block: memory_bus_block1 {
> operating-points = <
> 10 85
> 5 85>;
>};
>
>display_block: memory_bus_block2 {
> operating-points = <
> 20 95
> 16 95
> 10 925000
> 8 85
> 5 85>;
>};
>
>isp_block: memory_bus_block3 {
> operating-points = <
> 20 95
> 10 925000
> 8 85
> 5 85>;
>};
>
>gps_block: memory_bus_block4 {
> operating-points = <
> 30 95
> 20 95
> 133000 925000
> 10 85
> 5 85>;
>};
>
>
> Now suppose these are the requirements from all the blocks
> at any point of time:
> - block1: 10 85
> - block2: 10 925000
> - block3: 8 85
> - block4: 133000 925000
>
> Now, all of them can control freq separately and we don't need to
> worry for that. But regulator is shared between them. We can check
> what's the highest voltage requested at this point of time and can
> switch to that.
>
> i.e. 925000 in this case. And that's not the highest possible one.
> And you will reach to similar conclusion with your current code as
> well I believe.
>
OK, I understand.
I'll try to update exynos memory bus according to your comment.
Thanks
Chanwoo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Shorten efi regions output
On 1/5/15, 10:00 AM, Laszlo Ersek wrote: On 01/05/15 15:03, Matt Fleming wrote: On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote: On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote: I have same feeling with you, it is too long for most of people. Since the printk code are for EFI_DEBUG, they are around the #ifdef so I would like to see a kernel param like efi_debug=on, so only efi_debug is specified then these verbose messages are printed. Without the param kernel can print some basic infomation about the memory ranges. In arm64 code there's already a uefi_debug param it can be moved to general code so that there will be a goable switch. Hmm, makes sense to me. Maybe we should really hide those behind a debug switch, the question is whether asking the user to boot with "efi_debug=on" in order to see the regions is ok. And I think it is ok because we do that when debugging other stuff so I don't see anything different here. And then when they're disabled by default, we don't really need to shorten them as they're pure debug output then. Matt? I'm fine with disabling the EFI memory output regions by default. Printing the regions is still useful for debugging, but like you mention, we frequently ask users to enable other debug options when tracking down issues. Laszlo, would you be OK with that? Sure. Pardon my intrusion into this thread (just going over the past month's LKML for things I missed). I'd like to see some map output by default in the kernel. We have on a number of occasions found just this output useful in debugging boot issues on ARM servers and I suspect that will remain the case over the coming months. Sure, you can always tell someone to reboot, but then you have to rely on them doing it. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel][PATCH 1/3] SoC: fsl_sai: add sai master mode support
On Tue, Jan 20, 2015 at 08:21:18PM +0800, Zidan Wang wrote:
> +static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq)
> + if ((tx && sai->synchronous[TX]) || (!tx && !sai->synchronous[RX])) {
> + regmap_update_bits(sai->regmap, FSL_SAI_RCR2,
> + FSL_SAI_CR2_MSEL_MASK, FSL_SAI_CR2_MSEL(sai->mclk_id));
> + regmap_update_bits(sai->regmap, FSL_SAI_RCR2,
> + FSL_SAI_CR2_DIV_MASK, savediv - 1);
Hmm...the case should be a bit more complicated here IMO.
"tx && sai->synchronous[TX]" means the playback in synchronous
mode (TX following RX). What if the recording has been already
activated with an MSEL setting at this point? Then the playback
stream, as a secondary stream, will overwrite MSEL of the first
stream -- Record. Same would happen to the DIV configuration.
> @@ -297,6 +368,24 @@ static int fsl_sai_hw_params(struct snd_pcm_substream
> *substream,
> unsigned int channels = params_channels(params);
> u32 word_width = snd_pcm_format_width(params_format(params));
> u32 val_cr4 = 0, val_cr5 = 0;
> + int ret;
> +
> + if (!sai->is_slave_mode) {
> + ret = fsl_sai_set_bclk(cpu_dai, tx,
> + 2 * word_width * params_rate(params));
> + if (ret)
> + return ret;
> +
> + /* Do not enable the clock if it is already enabled */
It actually doesn't matter to enable the clock again since it
purely increaes its count. But we do need a protection for MSEL
overwritten issue resulted from the fsl_sai_set_bclk() call.
> @@ -133,10 +135,13 @@ struct fsl_sai {
> struct clk *mclk_clk[FSL_SAI_MCLK_MAX];
>
> bool is_lsb_first;
> + bool is_slave_mode;
> bool is_dsp_mode;
> bool sai_on_imx;
> bool synchronous[2];
>
> + unsigned int mclk_id;
> + unsigned int mclk_streams;
Besides, I doubt that only one property of mclk_id can content
Asynchronous Mode -- TX and RX can fetch their clocks from
different MCLK sources.
Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: perf: behavior of poll() changed in 3.18
On Tue, 20 Jan 2015, Jiri Olsa wrote:
> I made this change to get notification that monitored
> process exited. We use it in 'perf record' to find out
> that we have nothing more to monitor and quit.
>
> The logic is to return POLLHUP (via poll syscall) when
> the monitored process exits for the event.
>
> Could you please share your test code?
My code does something like this to count the number of overflows
happening in a child:
/* fds contains one fd, which is a harware event */
/* attached to a child */
while(1) {
result=poll(fds,1,100);
if (result==0) {
waitpid(child,,WNOHANG);
if (WIFEXITED(status)) break;
if (WIFSIGNALED(status)) {
printf("Signalled %d!\n",WTERMSIG(status));
break;
}
}
if (fds[0].revents) count.in++;
if (fds[0].revents) count.hup++;
if (fds[0].revents) break;
}
With the change you made this code hangs forever because poll no longer
returns "0" when the child exits, but instead returns "1" with
POLLHUP set.
I admit my code isn't the best out there, but it worked reliably up
until 3.18 when the change was made.
Part of why my code doesn't just exit on POLLHUP is because you can
get that result for reasons other than a process exit (for example,
if you are using ioctl(PERF_EVENT_IOC_REFRESH)
Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree
* Andy Lutomirski wrote: > On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar wrote: > > > > * Andy Lutomirski wrote: > > > >> Hi Ingo and Thomas- > >> > >> There's a trivial conflict in the pull request I sent last week. > > > > This is your x86 entry code rework pull request, right? The -tip > > tree now has the RCU commit it depends on, so could you please > > rebase it on top of tip:core/rcu so I can pull it? I'll resolve > > any remaining conflicts with the rest of -tip. > > > > Sure, I can do that in the morning. The pull request merges cleanly > with tip:core/rcu, though, so is the rebase needed? Yes, because your changes rely on the RCU change (semantically), so if anyone bisects into your commits it might result in a subtly broken kernel, right? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree
On Tue, Jan 20, 2015 at 9:55 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar wrote: >> > >> > * Andy Lutomirski wrote: >> > >> >> Hi Ingo and Thomas- >> >> >> >> There's a trivial conflict in the pull request I sent last week. >> > >> > This is your x86 entry code rework pull request, right? The -tip >> > tree now has the RCU commit it depends on, so could you please >> > rebase it on top of tip:core/rcu so I can pull it? I'll resolve >> > any remaining conflicts with the rest of -tip. >> > >> >> Sure, I can do that in the morning. The pull request merges cleanly >> with tip:core/rcu, though, so is the rebase needed? > > Yes, because your changes rely on the RCU change (semantically), > so if anyone bisects into your commits it might result in a > subtly broken kernel, right? > Almost. The parent of my original pull request is the RCU change that my entry changes semantically depend on, so bisection should be fine. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: dts: exynos5422-odroidxu3: add sound nodes
Add MAX98090 audio codec, I2S interface and the sound nodes to support
audio on Odroid-XU3 board.
Signed-off-by: Inha Song
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index 7874da2..79493d1 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -310,6 +310,40 @@
rtc@101E {
status = "okay";
};
+
+ sound: sound {
+ compatible = "samsung,odroidu3-audio";
+ samsung,model = "Odroid-XU3";
+ samsung,i2s-controller = <>;
+ samsung,audio-codec = <>;
+ assigned-clocks = <_audss EXYNOS_MOUT_AUDSS>,
+ <_audss EXYNOS_MOUT_I2S>;
+ assigned-clock-parents = < CLK_FIN_PLL>,
+ <_audss EXYNOS_MOUT_AUDSS>;
+ samsung,audio-routing =
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "Headphone Jack", "MICBIAS",
+ "IN1", "Headphone Jack",
+ "Speakers", "SPKL",
+ "Speakers", "SPKR";
+ };
+};
+
+_5 {
+ status = "okay";
+ max98090: max98090@10 {
+ compatible = "maxim,max98090";
+ reg = <0x10>;
+ interrupt-parent = <>;
+ interrupts = <2 0>;
+ clocks = <_audss EXYNOS_DOUT_AUD_BUS>;
+ clock-names = "mclk";
+ };
+};
+
+ {
+ status = "okay";
};
{
--
2.0.0.390.gcb682f8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: dsa: set parent of hwmon device
2015-01-20 19:50 GMT-08:00 Guenter Roeck : > On 01/20/2015 04:13 PM, Vivien Didelot wrote: >> >> Set the dsa device as the parent of the hwmon device, in order to link >> the hwmon subsystem under the corresponding /sys/devices/platform/dsa.X/ >> sysfs directory. >> >> Signed-off-by: Vivien Didelot >> --- >> net/dsa/dsa.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c >> index 3731714..363102a 100644 >> --- a/net/dsa/dsa.c >> +++ b/net/dsa/dsa.c >> @@ -347,7 +347,7 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int >> index, >> hname[j] = '\0'; >> scnprintf(ds->hwmon_name, sizeof(ds->hwmon_name), >> "%s_dsa%d", >> hname, index); >> - ds->hwmon_dev = hwmon_device_register_with_groups(NULL, >> + ds->hwmon_dev = hwmon_device_register_with_groups(parent, >> ds->hwmon_name, ds, >> dsa_hwmon_groups); >> if (IS_ERR(ds->hwmon_dev)) >> ds->hwmon_dev = NULL; >> > > Looking into my old e-mail, turns out we did not add the parent device > because > it affected the output of the "sensors" command, and we wanted the device > to be handled as 'virtual device' (which implies no parent). That was an > explicit > part of the patch set (v2 of 'net: dsa: Add support for reporting switch > chip > temperatures'), compared to v1, which did set the parent device. > > I would suggest to keep the code as is. Maybe follow-up with a comment adding that above the call to hwmon_device_register_with_groups()? I suspect the intent is clear if you are deep into hwmon devices, but not necessarily for the reader ;) > > Thanks, > Guenter > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/6] epoll: Introduce new syscall "epoll_mod_wait"
On 01/20/2015 11:40 PM, Andy Lutomirski wrote: > On Tue, Jan 20, 2015 at 1:57 AM, Fam Zheng wrote: >> This adds a new system call, epoll_mod_wait. It's described as below: [...] >>There is no guartantee that all the commands are executed in order. >> Only >>if all the commands are successfully executed (all the error fields >> are >>set to 0), events are polled. > > If this doesn't happen, what error is returned? If I read the code correctly: the error of the first epoll_ctl op that fails. [...] >> RETURN VALUE >> >>When any error occurs, epoll_mod_wait() returns -1 and errno is set >>appropriately. All the "error" fields in cmds are unchanged before >> they >>are executed, and if any cmds are executed, the "error" fields are set >>to a return code accordingly. See also epoll_ctl for more details of >> the >>return code. > > Does this mean that callers should initialize the error fields to an > impossible value first so they can tell which commands were executed? Yes. (Ugly!) [...] >> ERRORS >> >>These errors apply on either the return value of epoll_mod_wait or >> error >>status for each command, respectively. > > Please clarify which errors are returned overall and which are per-command. Yes, I think this would be valuable as well. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree
On Tue, Jan 20, 2015 at 9:48 PM, Andy Lutomirski wrote: > On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar wrote: >> >> * Andy Lutomirski wrote: >> >>> Hi Ingo and Thomas- >>> >>> There's a trivial conflict in the pull request I sent last week. >> >> This is your x86 entry code rework pull request, right? The -tip >> tree now has the RCU commit it depends on, so could you please >> rebase it on top of tip:core/rcu so I can pull it? I'll resolve >> any remaining conflicts with the rest of -tip. >> > > Sure, I can do that in the morning. The pull request merges cleanly > with tip:core/rcu, though, so is the rebase needed? The rebase was trivial. If you prefer it: The following changes since commit f49028292c13b958fdf4f36c8cc8119d0dde187b: Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu (2015-01-21 06:12:21 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git tags/pr-20150120-x86-entry for you to fetch changes up to 0e5c6d1b97b194aa5cbb79ea3a73236a9de8811c: x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user (2015-01-20 21:49:15 -0800) [This is identical to pr-20150114-x86-entry, except rebased to tip:core/rcu] This is my accumulated x86 entry work, part 1, for 3.20. The meat of this is an IST rework. When an IST exception interrupts user space, we will handle it on the per-thread kernel stack instead of on the IST stack. This sounds messy, but it actually simplifies the IST entry/exit code, because it eliminates some ugly games we used to play in order to handle rescheduling, signal delivery, etc on the way out of an IST exception. The IST rework introduces proper context tracking to IST exception handlers. I haven't seen any bug reports, but the old code could have incorrectly treated an IST exception handler as an RCU extended quiescent state. The memory failure change (included in this pull request with Borislav and Tony's permission) eliminates a bunch of code that is no longer needed now that user memory failure handlers are called in process context. Finally, this includes a few on Denys' uncontroversial and Obviously Correct (tm) cleanups. The IST and memory failure changes have been in -next for a while. LKML references: IST rework: http://lkml.kernel.org/r/cover.1416604491.git.l...@amacapital.net Memory failure change: http://lkml.kernel.org/r/54ab2ffa301102c...@agluck-desk.sc.intel.com Denys' cleanups: http://lkml.kernel.org/r/1420927210-19738-1-git-send-email-dvlas...@redhat.com Andy Lutomirski (4): x86, entry: Switch stacks on a paranoid entry from userspace x86, traps: Track entry into and exit from IST context x86: Clean up current_stack_pointer x86, traps: Add ist_begin_non_atomic and ist_end_non_atomic Denys Vlasenko (3): x86: entry_64.S: delete unused code x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user Tony Luck (1): x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks Documentation/x86/entry_64.txt | 18 ++- Documentation/x86/x86_64/kernel-stacks | 8 +- arch/x86/ia32/ia32entry.S | 4 +- arch/x86/include/asm/calling.h | 1 - arch/x86/include/asm/mce.h | 1 - arch/x86/include/asm/thread_info.h | 15 ++- arch/x86/include/asm/traps.h | 6 + arch/x86/kernel/cpu/mcheck/mce.c | 114 +- arch/x86/kernel/cpu/mcheck/p5.c| 6 + arch/x86/kernel/cpu/mcheck/winchip.c | 5 + arch/x86/kernel/entry_64.S | 208 ++--- arch/x86/kernel/irq_32.c | 13 +-- arch/x86/kernel/signal.c | 6 - arch/x86/kernel/traps.c| 108 + 14 files changed, 252 insertions(+), 261 deletions(-) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree
On Tue, Jan 20, 2015 at 9:34 PM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> Hi Ingo and Thomas- >> >> There's a trivial conflict in the pull request I sent last week. > > This is your x86 entry code rework pull request, right? The -tip > tree now has the RCU commit it depends on, so could you please > rebase it on top of tip:core/rcu so I can pull it? I'll resolve > any remaining conflicts with the rest of -tip. > Sure, I can do that in the morning. The pull request merges cleanly with tip:core/rcu, though, so is the rebase needed? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the char-misc tree with the block tree
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in
drivers/char/mem.c between commit b4caecd48005 ("fs: introduce
f_op->mmap_capabilities for nommu mmap support") from the block tree
and commit 73f0718e74e2 ("drivers: char: mem: Make /dev/mem an optional
device") from the char-misc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/char/mem.c
index 9a6b63783a94,080273287c48..
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@@ -732,25 -717,17 +728,23 @@@ static const struct file_operations __m
.write = write_mem,
.mmap = mmap_mem,
.open = open_mem,
+#ifndef CONFIG_MMU
.get_unmapped_area = get_unmapped_area_mem,
+ .mmap_capabilities = memory_mmap_capabilities,
+#endif
};
- #ifdef CONFIG_DEVKMEM
- static const struct file_operations kmem_fops = {
+ static const struct file_operations __maybe_unused kmem_fops = {
.llseek = memory_lseek,
.read = read_kmem,
.write = write_kmem,
.mmap = mmap_kmem,
.open = open_kmem,
+#ifndef CONFIG_MMU
.get_unmapped_area = get_unmapped_area_mem,
+ .mmap_capabilities = memory_mmap_capabilities,
+#endif
};
- #endif
static const struct file_operations null_fops = {
.llseek = null_lseek,
@@@ -793,22 -775,24 +785,24 @@@ static const struct memdev
const char *name;
umode_t mode;
const struct file_operations *fops;
- struct backing_dev_info *dev_info;
+ fmode_t fmode;
} devlist[] = {
+ #ifdef CONFIG_DEVMEM
- [1] = { "mem", 0, _fops, _mappable_cdev_bdi },
+ [1] = { "mem", 0, _fops, FMODE_UNSIGNED_OFFSET },
+ #endif
#ifdef CONFIG_DEVKMEM
- [2] = { "kmem", 0, _fops, _mappable_cdev_bdi },
+ [2] = { "kmem", 0, _fops, FMODE_UNSIGNED_OFFSET },
#endif
- [3] = { "null", 0666, _fops, NULL },
+ [3] = { "null", 0666, _fops, 0 },
#ifdef CONFIG_DEVPORT
- [4] = { "port", 0, _fops, NULL },
+ [4] = { "port", 0, _fops, 0 },
#endif
- [5] = { "zero", 0666, _fops, _bdi },
- [7] = { "full", 0666, _fops, NULL },
- [8] = { "random", 0666, _fops, NULL },
- [9] = { "urandom", 0666, _fops, NULL },
+ [5] = { "zero", 0666, _fops, 0 },
+ [7] = { "full", 0666, _fops, 0 },
+ [8] = { "random", 0666, _fops, 0 },
+ [9] = { "urandom", 0666, _fops, 0 },
#ifdef CONFIG_PRINTK
- [11] = { "kmsg", 0644, _fops, NULL },
+ [11] = { "kmsg", 0644, _fops, 0 },
#endif
};
pgpupDfWFo5f6.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 0/5] Add Mediatek SoC Pinctrl/GPIO/EINT driver for MT8135.
On Wed, 2015-01-21 at 13:28 +0800, Hongzhou Yang wrote: > This is v5 of add Mediatek SoC Pinctrl/GPIO/EINT driver for MT8135. > It is based on Joe.C' basic device tree support. > See > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296093.html Hi, A little correction. I just talked to Hongzhou, this series is based on 3.19-rc1 instead of my old patch. Sorry for the confusion. Joe.C -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch 15/19] ACPI: Add field offset to struct resource_list_entry
On 2015/1/21 8:53, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:33:02 AM Jiang Liu wrote:
>> Add field offset to struct resource_list_entry to host address space
>> translation offset so it could be used to represent bridge resources.
>>
>> Signed-off-by: Jiang Liu
>> ---
>> drivers/acpi/resource.c | 13 -
>> include/linux/acpi.h|1 +
>> 2 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 16d334a1ee25..54204ac94f8e 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -462,7 +462,8 @@ struct res_proc_context {
>> };
>>
>> static acpi_status acpi_dev_new_resource_entry(struct resource *r,
>> - struct res_proc_context *c)
>> + struct res_proc_context *c,
>> + resource_size_t offset)
>> {
>> struct resource_list_entry *rentry;
>>
>> @@ -472,6 +473,7 @@ static acpi_status acpi_dev_new_resource_entry(struct
>> resource *r,
>> return AE_NO_MEMORY;
>> }
>> rentry->res = *r;
>> +rentry->offset = offset;
>> list_add_tail(>node, c->list);
>> c->count++;
>> return AE_OK;
>> @@ -480,6 +482,7 @@ static acpi_status acpi_dev_new_resource_entry(struct
>> resource *r,
>> static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
>> void *context)
>> {
>> +resource_size_t offset = 0;
>> struct res_proc_context *c = context;
>> struct resource r;
>> int i;
>> @@ -500,14 +503,14 @@ static acpi_status acpi_dev_process_resource(struct
>> acpi_resource *ares,
>>
>> if (acpi_dev_resource_memory(ares, )
>> || acpi_dev_resource_io(ares, )
>> -|| acpi_dev_resource_address_space(ares, , NULL)
>> -|| acpi_dev_resource_ext_address_space(ares, , NULL))
>> -return acpi_dev_new_resource_entry(, c);
>> +|| acpi_dev_resource_address_space(ares, , )
>> +|| acpi_dev_resource_ext_address_space(ares, , ))
>> +return acpi_dev_new_resource_entry(, c, offset);
>>
>> for (i = 0; acpi_dev_resource_interrupt(ares, i, ); i++) {
>> acpi_status status;
>>
>> -status = acpi_dev_new_resource_entry(, c);
>> +status = acpi_dev_new_resource_entry(, c, 0);
>> if (ACPI_FAILURE(status))
>> return status;
>> }
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index bde8119f5897..fea78e772450 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -300,6 +300,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource
>> *ares, int index,
>> struct resource_list_entry {
>> struct list_head node;
>> struct resource res;
>> +resource_size_t offset;
>
> Well, so instead of adding the offset thing here and there, wouldn't it be
> cleaner to introduce something like
>
> struct ext_resource {
> sturct resource res;
> resource_size_t offset;
> };
>
> and use struct ext_resource instead of struct resource where an offset is
> needed?
>
> Just a thought ...
Hi Rafael,
Following patches will achieve this by sharing struct
resource_list_entry.
Regards!
Gerry
>
>> };
>>
>> void acpi_dev_free_resource_list(struct list_head *list);
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch 14/19] ACPI: Translate resource into master side address for bridge window resources
On 2015/1/21 8:50, Rafael J. Wysocki wrote:
> On Thursday, January 08, 2015 10:33:01 AM Jiang Liu wrote:
>> Add translation_offset into the result address for bridge window
>> resources to form the master side address.
>>
>> Currently acpi_dev_resource_{ext_}address_space() are only used for
>> devices instead of bridges, so it won't break current users. Later
>> it will be used to support PCI host bridge drivers.
>>
>> Signed-off-by: Jiang Liu
>> ---
>> drivers/acpi/resource.c | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index d3aa56674bd4..16d334a1ee25 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -203,6 +203,20 @@ static bool acpi_decode_space(struct resource *res,
>> resource_size_t *offset,
>> res->start = addr->minimum;
>> res->end = addr->maximum;
>>
>> +/*
>> + * For bridges that translate addresses across the bridge,
>> + * translation_offset is the offset that must be added to the
>> + * address on the secondary side to obtain the address on the
>> + * primary side. Non-bridge devices must list 0 for all Address
>> + * Translation offset bits.
>> + */
>> +if (base->producer_consumer == ACPI_PRODUCER) {
>
> OK, so the assumption is that this check is never true in the current code,
> right?
Yes.
>
>> +res->start += addr->translation_offset;
>> +res->end += addr->translation_offset;
>> +} else if (addr->translation_offset) {
>
> And won't this break anything even if so?
I'm trying to follow the spec, how about giving a warning here
instead of failure?
Regards!
Gerry
>
>> +return false;
>> +}
>> +
>> switch(base->resource_type) {
>> case ACPI_MEMORY_RANGE:
>> acpi_dev_memresource_flags(res, len, wp);
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Fwd: linux-next: manual merge of the luto-misc tree with the tip tree
* Andy Lutomirski wrote: > Hi Ingo and Thomas- > > There's a trivial conflict in the pull request I sent last week. This is your x86 entry code rework pull request, right? The -tip tree now has the RCU commit it depends on, so could you please rebase it on top of tip:core/rcu so I can pull it? I'll resolve any remaining conflicts with the rest of -tip. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Selinux/hooks.c: Fix a NULL pointer dereference caused by semop()
On 01/21/2015 04:53 AM, Ethan Zhao wrote:
On Tue, Jan 20, 2015 at 10:10 PM, Stephen Smalley wrote:
On 01/20/2015 04:18 AM, Ethan Zhao wrote:
sys_semget()
->newary()
->security_sem_alloc()
->sem_alloc_security()
selinux_sem_alloc_security()
->ipc_alloc_security() {
->rc = avc_has_perm()
if (rc) {
ipc_free_security(>sem_perm);
return rc;
We free the security structure here to avoid a memory leak on a
failed/denied semaphore set creation. In this situation, we return an
error to the caller (ultimately to newary), it does an
ipc_rcu_putref(sma, ipc_rcu_free), and it returns an error to the
caller. Thus, it never calls ipc_addid() and the semaphore set is not
created. So how then can you call semtimedop() on it?
Seems it wouldn't happen after commit e8577d1f0329d4842e8302e289fb2c22156abef4 ?
That was my first guess when I read the bug report - but it can't be the
fix, because security_sem_alloc() is before the ipc_addid(), with or
without the patch.
thread A:
thread B:
semtimedop()
-> sem_obtain_object_check()
semctl(IPC_RMID)
-> freeary()
-> ipc_rcu_putref()
-> call_rcu()
-> somehow a grace period
-> sem_rcu_free()
-> security_sem_free()
Perhaps: modify ipc_free_security() to hexdump perm and a few more bytes
if the pointer is NULL?
--
Manfred
Thanks,
Ethan
So ipc_perms->security was NULL, then semtimedop() was called as
following:
sys_semtimedop() / semop()
->selinux_sem_semop()
->ipc_has_perm()
->avc_has_perm(sid, isec->sid, isec->sclass, perms, );
^- NULL pointer dereference happens
The test kernel was running on VMware.
This patch use to fix this serious security issue could be triggered by user
space.
This patch was tested with v3.19-rc5.
Signed-off-by: Ethan Zhao
---
security/selinux/hooks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6da7532..bbe76f5 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5129,6 +5129,8 @@ static int ipc_has_perm(struct kern_ipc_perm *ipc_perms,
u32 sid = current_sid();
isec = ipc_perms->security;
+ if (!isec)
+ return -EACCES;
ad.type = LSM_AUDIT_DATA_IPC;
ad.u.ipc_id = ipc_perms->key;
That is not the correct fix; it just hides a bug. If we reach
ipc_has_perm() with a NULL isec, it is a bug in the ipc 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cfq-iosched: fix incorrect filing of rt async cfqq
Hi,
Thank you for the patch, Jeff!
(2015/01/13 5:21), Jeff Moyer wrote:
> Hi,
>
> If you can manage to submit an async write as the first async I/O from
> the context of a process with realtime scheduling priority, then a
> cfq_queue is allocated, but filed into the wrong async_cfqq bucket. It
> ends up in the best effort array, but actually has realtime I/O
> scheduling priority set in cfqq->ioprio.
Actually, this bug causes a severe I/O starvation in the following scenario
(we've experienced):
1. RT demon issues an O_SYNC write to an ext2 filesystem early in the
boot sequence (this is an example which causes the first async write
to a device in an RT process context)
2. Do heavy buffered writes to the device (these writes will be
treated as RT class)
3. Issue a sync I/O to the device, and it will take over tens seconds
to be prevented by many RT class I/Os
I confirmed Jeff's patch solves the above problem.
Tested-by: Hidehiro Kawai
>
> The reason is that cfq_get_queue assumes the default scheduling class and
> priority when there is no information present (i.e. when the async cfqq
> is created):
>
> static struct cfq_queue *
> cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
> struct bio *bio, gfp_t gfp_mask)
> {
> const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
> const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
>
> cic->ioprio starts out as 0, which is "invalid". So, class of 0
> (IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:
>
> async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
>
> static struct cfq_queue **
> cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
> {
> switch (ioprio_class) {
> case IOPRIO_CLASS_RT:
> return >async_cfqq[0][ioprio];
> case IOPRIO_CLASS_NONE:
> ioprio = IOPRIO_NORM;
> /* fall through */
> case IOPRIO_CLASS_BE:
> return >async_cfqq[1][ioprio];
> case IOPRIO_CLASS_IDLE:
> return >async_idle_cfqq;
> default:
> BUG();
> }
> }
>
> Here, instead of returning a class mapped from the process' scheduling
> priority, we get back the bucket associated with IOPRIO_CLASS_BE.
>
> Now, there is no queue allocated there yet, so we create it:
>
> cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
>
> That function ends up doing this:
>
> cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
> cfq_init_prio_data(cfqq, cic);
>
> cfq_init_cfqq marks the priority as having changed. Then, cfq_init_prio
> data does this:
>
> ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
> switch (ioprio_class) {
> default:
> printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
> case IOPRIO_CLASS_NONE:
> /*
>* no prio set, inherit CPU scheduling settings
>*/
> cfqq->ioprio = task_nice_ioprio(tsk);
> cfqq->ioprio_class = task_nice_ioclass(tsk);
> break;
>
> So we basically have two code paths that treat IOPRIO_CLASS_NONE
> differently, which results in an RT async cfqq filed into a best effort
> bucket.
>
> Attached is a patch which fixes the problem. I'm not sure how to make
> it cleaner. Suggestions would be welcome.
>
> Signed-off-by: Jeff Moyer
>
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index 6f2751d..b9abdca 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -3656,12 +3656,17 @@ static struct cfq_queue *
> cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
> struct bio *bio, gfp_t gfp_mask)
> {
> - const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
> - const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
> + int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
> + int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
> struct cfq_queue **async_cfqq = NULL;
> struct cfq_queue *cfqq = NULL;
>
> if (!is_sync) {
> + if (!ioprio_valid(cic->ioprio)) {
> + struct task_struct *tsk = current;
> + ioprio = task_nice_ioprio(tsk);
> + ioprio_class = task_nice_ioclass(tsk);
> + }
> async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
> cfqq = *async_cfqq;
> }
>
>
--
Hidehiro Kawai
Hitachi, Yokohama Research Laboratory
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] extcon: gpio-usb: Introduce gpio usb extcon driver
Hi Roger,
On 01/20/2015 02:52 AM, Roger Quadros wrote:
> This driver observes the USB ID pin connected over a GPIO and
> updates the USB cable extcon states accordingly.
>
> The existing GPIO extcon driver is not suitable for this purpose
> as it needs to be taught to understand USB cable states and it
> can't handle more than one cable per instance.
>
> For the USB case we need to handle 2 cable states.
> 1) USB (attach/detach)
> 2) USB-Host (attach/detach)
>
> This driver can be easily updated in the future to handle VBUS
> events in case it happens to be available on GPIO for any platform.
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/extcon/extcon-usb.txt | 20 ++
> drivers/extcon/Kconfig | 7 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-gpio-usb.c | 225
> +
> 4 files changed, 253 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb.txt
> create mode 100644 drivers/extcon/extcon-gpio-usb.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb.txt
> b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
> new file mode 100644
> index 000..171c5a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
Need to rename from extcon-usb.txt to extcon-gpio-usb.txt.
> @@ -0,0 +1,20 @@
> +USB Extcon device
> +
> +This is a virtual device used to generate USB cable states from the USB ID
> pin
> +connected to a GPIO pin.
> +
> +Required properties:
> +- compatible: Should be "linux,extcon-usb"
I think you better use "linux,extcon-gpio-usb"
because the point of this driver use the gpio for usb cable.
> +- id-gpio: gpio for USB ID pin. See gpio binding.
> +
> +Example:
> + extcon_usb1 {
> + compatible = "linux,extcon-usb";
ditto.
> + id-gpio = < 1 GPIO_ACTIVE_HIGH>;
> + }
> +
> + usb@1 {
> + ...
> + extcon = <_usb1>;
> + ...
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de..8106a83 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -35,6 +35,13 @@ config EXTCON_GPIO
> Say Y here to enable GPIO based extcon support. Note that GPIO
> extcon supports single state per extcon instance.
>
> +config EXTCON_GPIO_USB
> + tristate "USB GPIO extcon support"
> + depends on GPIOLIB
> + help
> + Say Y here to enable GPIO based USB cable detection extcon support.
> + Used typically if GPIO is used for USB ID pin detection.
> +
> config EXTCON_MAX14577
> tristate "MAX14577/77836 EXTCON Support"
> depends on MFD_MAX14577
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42..bae594b 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
> +obj-$(CONFIG_EXTCON_GPIO_USB)+= extcon-gpio-usb.o
Need to re-order it alphabetically.
> diff --git a/drivers/extcon/extcon-gpio-usb.c
> b/drivers/extcon/extcon-gpio-usb.c
> new file mode 100644
> index 000..aeb2298
> --- /dev/null
> +++ b/drivers/extcon/extcon-gpio-usb.c
> @@ -0,0 +1,225 @@
> +/**
> + * drivers/extcon/extcon_gpio_usb.c - USB GPIO extcon driver
> + *
> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
> + *
Remove un-necessary blank line.
> + * Author: Roger Quadros
> + *
> + * 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.
> + *
> + * 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
Is it necessary? I think it is your mistake?
> +#include
Don't need it because 'of_gpio.h' includes already 'gpio.h'.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
> +
> +struct usb_extcon_info {
> + struct device *dev;
> + struct extcon_dev *edev;
> +
> + struct gpio_desc *id_gpiod;
> + int id_irq;
> +
> + unsigned long debounce_jiffies;
> + struct delayed_work wq_detcable;
> +};
> +
> +/* List of detectable cables */
> +enum {
> + EXTCON_CABLE_USB = 0,
> + EXTCON_CABLE_USB_HOST,
> +
> + EXTCON_CABLE_END,
> +};
> +
> +static const char *usb_extcon_cable[] = {
> + [EXTCON_CABLE_USB] = "USB",
> + [EXTCON_CABLE_USB_HOST] =
