Re: [cgroup] a0f9ec1f181: -4.3% will-it-scale.per_thread_ops
Hi Tejun,
On Thu, May 15, 2014 at 12:55:17AM -0400, Tejun Heo wrote:
Hello,
On Thu, May 15, 2014 at 12:50:39PM +0800, Jet Chen wrote:
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
review-kill-tree_mutex
commit a0f9ec1f181534694cb5bf40b7b56515b8cabef9 (cgroup: use
cgroup_kn_lock_live() in other cgroup kernfs methods)
Test case : lkp-nex05/will-it-scale/writeseek
2074b6e38668e62 a0f9ec1f181534694cb5bf40b
--- -
2074b6e38668e62 is the base of comparison. So -4.3%
will-it-scale.per_thread_ops
in the below line means a0f9ec1f18 has lower will-it-scale throughput.
1027273 ~ 0% -4.3% 982732 ~ 0% TOTAL
will-it-scale.per_thread_ops
136 ~ 3% -43.1% 77 ~43% TOTAL proc-vmstat.nr_dirtied
0.51 ~ 3% +98.0% 1.01 ~ 4% TOTAL
perf-profile.cpu-cycles.shmem_write_end.generic_perform_write.__generic_file_aio_write.generic_file_aio_write.do_sync_write
1078 ~ 9% -16.3%903 ~11% TOTAL
numa-meminfo.node0.Unevictable
269 ~ 9% -16.2%225 ~11% TOTAL
numa-vmstat.node0.nr_unevictable
1.64 ~ 1% -14.3% 1.41 ~ 4% TOTAL
perf-profile.cpu-cycles.find_lock_entry.shmem_getpage_gfp.shmem_write_begin.generic_perform_write.__generic_file_aio_write
1.62 ~ 2% +14.1% 1.84 ~ 1% TOTAL
perf-profile.cpu-cycles.lseek64
The perf-profile.cpu-cycles.* lines are from perf record/report.
The last line shows that lseek64() takes 1.62% CPU cycles for
commit 2074b6e38668e62 and that percent increased by +14.1% on
a0f9ec1f181. One of the raw perf record output is
1.84% writeseek_proce libc-2.17.so [.] lseek64
|
--- lseek64
There are 5 runs and 1.62% is the average value.
I have no idea how to read the above. Which direction is plus and
which is minus? Are they counting cpu cycles? Which files is the
test seeking?
It's tmpfs files. Because the will-it-scale test case is mean to
measure scalability of syscalls. We do not use HDD/SSD etc. storage
devices when running it.
The will-it-scale/writeseek test code is
char *testcase_description = Separate file seek+write;
void testcase(unsigned long long *iterations)
{
char buf[BUFLEN];
char tmpfile[] = /tmp/willitscale.XX;
int fd = mkstemp(tmpfile);
memset(buf, 0, sizeof(buf));
assert(fd = 0);
unlink(tmpfile);
while (1) {
lseek(fd, 0, SEEK_SET);
assert(write(fd, buf, BUFLEN) == BUFLEN);
(*iterations)++;
}
}
Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / OPP: discard duplicate OPP additions
On 15 May 2014 11:16, Inderpal Singh inderpa...@samsung.com wrote: I think I did not make myself clear. Probably I was the one who got confused :) Devfreq will have its own opp table associated with its own device. It does not uses the opp table of cpus. Hence there may be need to free the table if driver (at least devfreq) getting un-registered. We may have an unregister routine routine, I am not arguing about that. But we don't need to call that for CPU's opp, that's it.. For devices it might make sense to free memory. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 09/16] kgr: mark task_safe in some kthreads
Hello, Mike. On Thu, May 15, 2014 at 07:32:29AM +0200, Mike Galbraith wrote: On Thu, 2014-05-15 at 01:09 -0400, Tejun Heo wrote: Soft/hard irq threads and anything having to do with IO mostly, which including workqueues. I had to give the user a rather fugly global prioritization option to let users more or less safely do the evil deeds they want to and WILL do whether I agree with their motivation to do so or not. I tell all users that realtime is real dangerous, but if they want to do that, it's their box, so by definition perfectly fine. Frederic is working on global settings for workqueues, so that'll resolve some of those issues at least. Yeah, wrt what runs where for unbound workqueues, but not priority. Shouldn't be too difficult to extend it to cover priorities if necessary once the infrastructure is in place. If there are good enough reasons for specific ones, sure, but I don't think we can't change any of the kthreads because someone might be diddling with it is something we can sustain in the long term. I think the opposite. Taking any control the user has is pure evil. I'm not sure good/evil is the right frame to think about it. Is pooling worker threads evil in nature then? When there may be realtime consumers, yes to some extent, because it inserts allocations he can't control directly into his world, but that's the least of his worries. The instant userspace depends upon any kernel proxy the user has no control over, he instantly has a priority inversion he can do nothing about. This is exactly what happened that prompted me to do fugly global hack. User turned pet database piggies loose as realtime tasks for his own reasons, misguided or not, they depend upon worker threads and kjournald et al who he can control, but kworker threads respawn as normal tasks which can and will end up under high priority userspace tasks. Worst case is box becomes dead, also killing pet, best case is pet collapses to the floor in a quivering heap. Neither makes Joe User particularly happy. I'm not sure how much weight I can put on the specific use case. Even with the direct control that the user thought to have previously, the use case was ripe with possibilities of breakage from any number of reasons. For example, there are driver paths which bounce to async execution on IO exceptions (doesn't have to be hard errors) and setups like the above would easily lock out exception handling and how's the setup gonna work when the filesystems have to use dynamic pool of workers as btrfs does? The identified problem in the above case is allowing the kernel to make reasonable forward progress even when RT processes don't concede CPU cycles. If that is a use case that needs to be supported, we better engineer an appropriate solution for that. Such solution doesn't necessarily have to be advanced either. Maybe all that's necessary is marking the async mechanisms involved in IO path as such (we already need to mark all workqueues involved in memory reclaim path anyway) and provide a mechanism to make all of them RT when directed. It might be simple but still would be a concious engineering decision. I think the point I'm trying to make is that it isn't possible to continue improving and maintaining the kernel with blanket restrictions on internal details. If certain things shouldn't be done, we better find out the specific reasons; otherwise, it's impossible to weight the pros and cons of different options and make a reasonable choice or to find out ways to accomodate those restrictions while still achieving the original goals. Anyways, we're getting slightly off-topic and it seems like we'll have to agree to disagree. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/crc7: Shift crc7() output left 1 bit
On Wed 2014-05-14 20:32:25, George Spelvin wrote: Pavel Machek wrote; On Sun 2014-05-11 05:16:07, George Spelvin wrote: To do it properly, I have to rename all of: crc7_syndrome_table[] crc7_byte() crc7() even though the third is the only (in-tree) user of the first two. If the first two are static, there's no problem. They're not; they're exported from the header (even though, as I mentioned, their only user is crc7()). So my patch v2 1/3 renamed all three. That's one way. Other would be to make them static so people can't use old interfaces by mistake. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 0/4] Common Mailbox Framework
Hi, Here is the next revision of Mailbox framwork. Changes since v4: o Common DT binding for Controller and Client drivers As a result, discard string based channel matching o Provide for an atomic 'peek' api, that a client could call to trigger the controller driver push data upwards. o OMAP and Highbank conversion to new api is left out, which can be converted later by the developers. Changes since v3: o Change name of symbols from ipc to mbox o Return real types instead of void * o Align structures o Change some symbol names rxcb - rx_callback txcb - tx_done o Added kernel-doc for exported API o Dropped the cl_id and use clients pointer for callbacks. o Fixed locking of channel pool o Return negative error code for unsuccessful ipc_send_message() o Module referencing during mailbox assignment to a client. o Made error code symbols specific to mailbox. Thanks Jassi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 17/20] ima: make IMA policy replaceable at runtime
On 15 May 2014 02:45, Mimi Zohar zo...@linux.vnet.ibm.com wrote:
On Wed, 2014-04-23 at 16:30 +0300, Dmitry Kasatkin wrote:
This patch provides functionality to replace the IMA policy at runtime.
By default, the IMA policy can be successfully updated only once,
but with this patch when the kernel configuration option
CONFIG_IMA_POLICY_REPLACEABLE is enabled, the IMA policy can be replaced
multiple times at runtime.
Signed-off-by: Dmitry Kasatkin d.kasat...@samsung.com
I have a couple of concerns with replacing the IMA policy.
- Currently opened files might now be in policy, that previously
weren't. Do these files need to be measured, appraised, or audited?
These files could have been modified, but the 'security.ima' xattr
hasn't been updated yet. In such cases, appraisal would fail.
Hi,
Yep. It is a bit larger problem.
But it will fail as well when using chown to change uid from user to
root, for example.
- At minimum, after replacing the policy, the iint cache entry flags
need to be reset.
Please provide the motivation for such a use case scenario.
Mimi
As I think I once mentioned, this patch should not be sent in that patchset.
We have some experimental stuff for controlling IMA at runtime.
That is not completed. There is no reason to discuss here a lot.
- Dmitry
---
security/integrity/ima/Kconfig | 8
security/integrity/ima/ima_fs.c | 2 ++
security/integrity/ima/ima_policy.c | 23 +++
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index b00044f..b60a315 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -160,3 +160,11 @@ config IMA_KERNEL_POLICY
default n
help
This option enables IMA policy loading from the kernel.
+
+config IMA_POLICY_REPLACEABLE
+ bool Allows to replace policy at runtime
+ depends on IMA_POLICY_LOADER
+ default n
+ help
+ Enabling this option allows to replace policy at runtime.
+ Only signed policy is allowed.
diff --git a/security/integrity/ima/ima_fs.c
b/security/integrity/ima/ima_fs.c
index d050a5c..b4144b4 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -304,11 +304,13 @@ static int ima_open_policy(struct inode *inode, struct
file *filp)
return -EACCES;
if (test_and_set_bit(IMA_FS_BUSY, ima_fs_flags))
return -EBUSY;
+#ifndef CONFIG_IMA_POLICY_REPLACEABLE
if (!ima_default_policy()) {
/* policy was already set*/
clear_bit(IMA_FS_BUSY, ima_fs_flags);
return -EACCES;
}
+#endif
return 0;
}
diff --git a/security/integrity/ima/ima_policy.c
b/security/integrity/ima/ima_policy.c
index c6da801..981e953 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -108,11 +108,14 @@ static struct ima_rule_entry default_appraise_rules[]
= {
static LIST_HEAD(ima_default_rules);
static LIST_HEAD(ima_policy_rules);
+static LIST_HEAD(ima_active_rules);
static struct list_head *ima_rules;
static bool path_rules;
static DEFINE_MUTEX(ima_rules_mutex);
+static void ima_do_delete_rules(struct list_head *rules);
+
static bool ima_use_tcb __initdata;
static int __init default_measure_policy_setup(char *str)
{
@@ -367,7 +370,14 @@ void ima_update_policy(void)
int result = 0;
int audit_info = 0;
- ima_rules = ima_policy_rules;
+ if (ima_default_policy()) {
+ /* set new policy head */
+ ima_rules = ima_active_rules;
+ } else {
+ /* FIXME: must be protected by lock */
+ ima_do_delete_rules(ima_rules);
+ }
+ list_replace_init(ima_policy_rules, ima_rules);
integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
NULL, op, cause, result, audit_info);
@@ -734,14 +744,14 @@ ssize_t ima_parse_add_rule(char *rule)
return len;
}
-/* ima_delete_rules called to cleanup invalid policy */
-void ima_delete_rules(void)
+/* ima_delete_rules called to cleanup invalid or old policy */
+static void ima_do_delete_rules(struct list_head *rules)
{
struct ima_rule_entry *entry, *tmp;
int i;
mutex_lock(ima_rules_mutex);
- list_for_each_entry_safe(entry, tmp, ima_policy_rules, list) {
+ list_for_each_entry_safe(entry, tmp, rules, list) {
for (i = 0; i MAX_LSM_RULES; i++)
kfree(entry-lsm[i].args_p);
@@ -751,6 +761,11 @@ void ima_delete_rules(void)
mutex_unlock(ima_rules_mutex);
}
+void ima_delete_rules(void)
+{
+ ima_do_delete_rules(ima_policy_rules);
+}
+
#ifdef CONFIG_IMA_POLICY_LOADER
ssize_t ima_read_policy(char *path)
--
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a
Re: [RFC PATCH] ARM: dts: am33xx: Re-arrange the USB dt to reflect the h/w configuration
Hi Tony,
On 5/15/2014 3:20 AM, Tony Lindgren wrote:
* George Cherian george.cher...@ti.com [140508 23:34]:
Re arrange the USB dt for AM33xx to take it a bit closer
to the hardware configuration.
The USBSS is designed as follows
USB control Module 0x44e10_0620
USBSS 0x4740_
USB00x4740_1000
USB0_PHY0x4740_1300
USB0_CORE 0x4740_1400
USB10x4740_1800
USB1_PHY0x4740_1b00
USB1_CORE 0x4740_1c00
CPPI DMA Controller 0x4740_2000
CPPI DMA Scheduler 0x4740_3000
Queue Manager 0x4740_4000
So model the DT as follows
USBSS {
usb_ctrl_mod: {
0x44e10_0620
}
usb0: {
0x4740_1000
0x4740_1400
}
usb0_phy:{
0x4740_1300
}
usb1:{
0x4740_1800
0x4740_1c00
}
usb1_phy: {
0x4740_1b00
}
cppi41dma: {
0x4740_2000
0x4740_3000
0x4740_4000
}
}
Is this just a cosmetic change or is this trying to workaround
some edma related init order issue?
Please ignore this patch. Was trying to workaround some dma and phy
related issues.
The same got fixed with following
http://www.spinics.net/lists/linux-usb/msg107244.html
Regards,
Tony
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 1/4] mailbox: rename pl320-ipc specific mailbox.h
From: Suman Anna s-a...@ti.com
The patch 30058677 ARM / highbank: add support for pl320 IPC
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.
Acked-by: Mark Langsdorf mark.langsd...@calxeda.com
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-highbank/highbank.c| 2 +-
drivers/cpufreq/highbank-cpufreq.c | 2 +-
drivers/mailbox/pl320-ipc.c | 2 +-
include/linux/{mailbox.h = pl320-ipc.h} | 0
4 files changed, 3 insertions(+), 3 deletions(-)
rename include/linux/{mailbox.h = pl320-ipc.h} (100%)
diff --git a/arch/arm/mach-highbank/highbank.c
b/arch/arm/mach-highbank/highbank.c
index c7de89b..f295cbb 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -20,7 +20,7 @@
#include linux/input.h
#include linux/io.h
#include linux/irqchip.h
-#include linux/mailbox.h
+#include linux/pl320-ipc.h
#include linux/of.h
#include linux/of_irq.h
#include linux/of_platform.h
diff --git a/drivers/cpufreq/highbank-cpufreq.c
b/drivers/cpufreq/highbank-cpufreq.c
index bf8902a..b464f29 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
#include linux/cpu.h
#include linux/err.h
#include linux/of.h
-#include linux/mailbox.h
+#include linux/pl320-ipc.h
#include linux/platform_device.h
#define HB_CPUFREQ_CHANGE_NOTE 0x8001
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index d873cba..f3755e0 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -26,7 +26,7 @@
#include linux/device.h
#include linux/amba/bus.h
-#include linux/mailbox.h
+#include linux/pl320-ipc.h
#define IPCMxSOURCE(m) ((m) * 0x40)
#define IPCMxDSET(m) (((m) * 0x40) + 0x004)
diff --git a/include/linux/mailbox.h b/include/linux/pl320-ipc.h
similarity index 100%
rename from include/linux/mailbox.h
rename to include/linux/pl320-ipc.h
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / OPP: discard duplicate OPP additions
On Thu, May 15, 2014 at 11:31 AM, Viresh Kumar viresh.ku...@linaro.org wrote: On 15 May 2014 11:16, Inderpal Singh inderpa...@samsung.com wrote: I think I did not make myself clear. Probably I was the one who got confused :) Devfreq will have its own opp table associated with its own device. It does not uses the opp table of cpus. Hence there may be need to free the table if driver (at least devfreq) getting un-registered. We may have an unregister routine routine, I am not arguing about that. But we don't need to call that for CPU's opp, that's it.. For devices it might make sense to free memory. Yes the provision should be there in the OPP framework and let the individual drivers decide whether to invoke or not. -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 2/4] mailbox: Introduce framework for mailbox
Introduce common framework for client/protocol drivers and
controller drivers of Inter-Processor-Communication (IPC).
Client driver developers should have a look at
include/linux/mailbox_client.h to understand the part of
the API exposed to client drivers.
Similarly controller driver developers should have a look
at include/linux/mailbox_controller.h
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
.../devicetree/bindings/mailbox/mailbox.txt| 30 ++
drivers/mailbox/Makefile | 4 +
drivers/mailbox/mailbox.c | 480 +
include/linux/mailbox.h| 20 +
include/linux/mailbox_client.h | 45 ++
include/linux/mailbox_controller.h | 121 ++
6 files changed, 700 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/mailbox.txt
create mode 100644 drivers/mailbox/mailbox.c
create mode 100644 include/linux/mailbox.h
create mode 100644 include/linux/mailbox_client.h
create mode 100644 include/linux/mailbox_controller.h
diff --git a/Documentation/devicetree/bindings/mailbox/mailbox.txt
b/Documentation/devicetree/bindings/mailbox/mailbox.txt
new file mode 100644
index 000..0eb2fb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mailbox.txt
@@ -0,0 +1,30 @@
+* Generic Mailbox Controller and client driver bindings
+
+Generic binding to provide a way for Mailbox controller drivers to assign
appropriate mailbox channel to client drivers.
+
+* MAILBOX Controller
+
+Required property:
+- #mbox-cells: Must be at least 1. Number of cells in a mailbox specifier.
+
+Example:
+ mailbox: mailbox {
+ ...
+ #mbox-cells = 1;
+ };
+
+
+* MAILBOX Client
+
+Required property:
+- mbox: List of phandle and mailbox channel specifier.
+
+- mbox-names: List of identifier strings for each mailbox channel required by
the client.
+
+Example:
+ pwr_cntrl: power {
+ ...
+ mbox-names = pwr-ctrl, rpc;
+ mbox = mailbox 0
+ mailbox 1;
+ };
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index e0facb3..2fa343a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -1,3 +1,7 @@
+# Generic MAILBOX API
+
+obj-$(CONFIG_MAILBOX) += mailbox.o
+
obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
obj-$(CONFIG_OMAP_MBOX)+= omap-mailbox.o
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
new file mode 100644
index 000..921fedd3
--- /dev/null
+++ b/drivers/mailbox/mailbox.c
@@ -0,0 +1,480 @@
+/*
+ * Mailbox: Common code for Mailbox controllers and users
+ *
+ * Copyright (C) 2014 Linaro Ltd.
+ * Author: Jassi Brar jassisinghb...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/interrupt.h
+#include linux/spinlock.h
+#include linux/mutex.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/module.h
+#include linux/device.h
+#include linux/mailbox_client.h
+#include linux/mailbox_controller.h
+
+#define TXDONE_BY_IRQ (1 0) /* controller has remote RTR irq */
+#define TXDONE_BY_POLL (1 1) /* controller can read status of last TX */
+#define TXDONE_BY_ACK (1 2) /* S/W ACK recevied by Client ticks the TX */
+
+static LIST_HEAD(mbox_cons);
+static DEFINE_MUTEX(con_mutex);
+
+static int _add_to_rbuf(struct mbox_chan *chan, void *mssg)
+{
+ int idx;
+ unsigned long flags;
+
+ spin_lock_irqsave(chan-lock, flags);
+
+ /* See if there is any space left */
+ if (chan-msg_count == MBOX_TX_QUEUE_LEN) {
+ spin_unlock_irqrestore(chan-lock, flags);
+ return -ENOMEM;
+ }
+
+ idx = chan-msg_free;
+ chan-msg_data[idx] = mssg;
+ chan-msg_count++;
+
+ if (idx == MBOX_TX_QUEUE_LEN - 1)
+ chan-msg_free = 0;
+ else
+ chan-msg_free++;
+
+ spin_unlock_irqrestore(chan-lock, flags);
+
+ return idx;
+}
+
+static void _msg_submit(struct mbox_chan *chan)
+{
+ unsigned count, idx;
+ unsigned long flags;
+ void *data;
+ int err;
+
+ spin_lock_irqsave(chan-lock, flags);
+
+ if (!chan-msg_count || chan-active_req) {
+ spin_unlock_irqrestore(chan-lock, flags);
+ return;
+ }
+
+ count = chan-msg_count;
+ idx = chan-msg_free;
+ if (idx = count)
+ idx -= count;
+ else
+ idx += MBOX_TX_QUEUE_LEN - count;
+
+ data = chan-msg_data[idx];
+
+ /* Try to submit a message to the MBOX controller */
+ err = chan-mbox-ops-send_data(chan, data);
+ if (!err) {
+ chan-active_req = data;
+ chan-msg_count--;
linux-next: manual merge of the clk tree with the renesas tree
Hi Mike, Today's linux-next merge of the clk tree got a conflict in Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt between commit b557deadc5cc (ARM: shmobile: r7s72100: document MSTP clock support) from the renesas tree and commit 5483bf698f42 (clk: shmobile: r8a7779: Add MSTP clock support) from the clk 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 Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt index b5fc72621bfd,30df825d72ef.. --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt @@@ -10,7 -10,7 +10,8 @@@ index in the group, from 0 to 31 Required Properties: - compatible: Must be one of the following +- renesas,r7s72100-mstp-clocks for R7S72100 (RZ) MSTP gate clocks + - renesas,r8a7779-mstp-clocks for R8A7779 (R-Car H1) MSTP gate clocks - renesas,r8a7790-mstp-clocks for R8A7790 (R-Car H2) MSTP gate clocks - renesas,r8a7791-mstp-clocks for R8A7791 (R-Car M2) MSTP gate clocks - renesas,cpg-mstp-clock for generic MSTP gate clocks signature.asc Description: PGP signature
[PATCHv5 3/4] mailbox: Fix TX completion init
From: LeyFoon Tan lftan.li...@gmail.com
For fast TX the complete could be called before being initialized as follows
mbox_send_message -- poll_txdone -- tx_tick -- complete(chan-tx_complete)
Init the completion early enough to fix the race.
Signed-off-by: LeyFoon Tan lftan.li...@gmail.com
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/mailbox/mailbox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 921fedd3..befb256 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -245,6 +245,9 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
if (!chan || !chan-cl)
return -EINVAL;
+ if (chan-cl-tx_block)
+ init_completion(chan-tx_complete);
+
t = _add_to_rbuf(chan, mssg);
if (t 0) {
pr_err(Try increasing MBOX_TX_QUEUE_LEN\n);
@@ -258,7 +261,6 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
if (chan-cl-tx_block chan-active_req) {
int ret;
- init_completion(chan-tx_complete);
ret = wait_for_completion_timeout(chan-tx_complete,
chan-cl-tx_tout);
if (ret == 0) {
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Frequency resolution in CCF vs. cpufreq
On 15 May 2014 04:00, Soren Brinkmann soren.brinkm...@xilinx.com wrote: I have one or two problems with cpufreq and the CCF, which are caused by rounding/different frequency resolutions. cpufreq works with kHz, while the CCF uses Hz. On Zynq our default frequency is 6 Hz which the CCF, due to rounding, reports as 0. And for cpufreq, which simply divides values it obtains through clk_round_rate() by 1000, 66. Since passing 66 to clk_round_rate() does not result in 0 (clk_round_rate() always rounds down!), we chose to put 67 in the OPP. This causes issue 1: cpufreq stats are broken. I know it might a big exercise, but wouldn't it be worth to make cpufreq start using frequencies in Hz ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] ARM: Don't ever downscale loops_per_jiffy in SMP systems#
On 14 May 2014 03:20, Doug Anderson diand...@chromium.org wrote: ...but then I found the true problem shows up when we transition between very low frequencies on exynos, like between 200MHz and 300MHz. While transitioning between frequencies the system temporarily bumps over to the switcher PLL running at 800MHz while waiting for the main PLL to stabilize. No CPUFREQ notification is sent for that. That means there's a period of time when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz and 300MHz. I'm welcome to any suggestions for how to address this. I have attempted to fix this in a generic way and sent an RFC patch for this. I have cc'd only few people from this list which I thought would be interested in cpufreq stuff, sorry if I missed anyone. https://lkml.org/lkml/2014/5/15/40 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 4/4] mailbox: Fix deleteing poll timer
From: LeyFoon Tan lftan.li...@gmail.com Try to delete the timer only if it was init/used. Signed-off-by: LeyFoon Tan lftan.li...@gmail.com Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- drivers/mailbox/mailbox.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index befb256..d83d12c 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -475,7 +475,8 @@ void mbox_controller_unregister(struct mbox_controller *mbox) for (i = 0; i mbox-num_chans; i++) mbox_free_channel(mbox-chans[i]); - del_timer_sync(mbox-poll); + if (mbox-txdone_poll) + del_timer_sync(mbox-poll); mutex_unlock(con_mutex); } -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [cgroup] a0f9ec1f181: -4.3% will-it-scale.per_thread_ops
Hello, Fengguang. On Thu, May 15, 2014 at 02:00:26PM +0800, Fengguang Wu wrote: 2074b6e38668e62 a0f9ec1f181534694cb5bf40b --- - 2074b6e38668e62 is the base of comparison. So -4.3% will-it-scale.per_thread_ops in the below line means a0f9ec1f18 has lower will-it-scale throughput. 1027273 ~ 0% -4.3% 982732 ~ 0% TOTAL will-it-scale.per_thread_ops 136 ~ 3% -43.1% 77 ~43% TOTAL proc-vmstat.nr_dirtied 0.51 ~ 3% +98.0% 1.01 ~ 4% TOTAL perf-profile.cpu-cycles.shmem_write_end.generic_perform_write.__generic_file_aio_write.generic_file_aio_write.do_sync_write 1078 ~ 9% -16.3%903 ~11% TOTAL numa-meminfo.node0.Unevictable 269 ~ 9% -16.2%225 ~11% TOTAL numa-vmstat.node0.nr_unevictable 1.64 ~ 1% -14.3% 1.41 ~ 4% TOTAL perf-profile.cpu-cycles.find_lock_entry.shmem_getpage_gfp.shmem_write_begin.generic_perform_write.__generic_file_aio_write 1.62 ~ 2% +14.1% 1.84 ~ 1% TOTAL perf-profile.cpu-cycles.lseek64 The perf-profile.cpu-cycles.* lines are from perf record/report. The last line shows that lseek64() takes 1.62% CPU cycles for commit 2074b6e38668e62 and that percent increased by +14.1% on a0f9ec1f181. One of the raw perf record output is 1.84% writeseek_proce libc-2.17.so [.] lseek64 | --- lseek64 There are 5 runs and 1.62% is the average value. I have no idea how to read the above. Which direction is plus and which is minus? Are they counting cpu cycles? Which files is the test seeking? It's tmpfs files. Because the will-it-scale test case is mean to measure scalability of syscalls. We do not use HDD/SSD etc. storage devices when running it. Hmmm... I'm completely stumped. The commit in question has nothing to do with tmpfs. It only affects three cgroup files - tasks, cgroup.procs and release_agent. It can't possibly have any effect on tmpfs operation. Maybe random effect through code alignment? Even that is highly unlikely. I'll look into it tomorrow but can you please try to repeat the test? It really doesn't make any sense to me. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for May 14 (tty/serial/men_z135_uart.c)
On Wed, May 14, 2014 at 09:31:10AM -0700, Randy Dunlap wrote: On 05/14/2014 01:26 AM, Stephen Rothwell wrote: Hi all, Changes since 20140513: on x86_64: CONFIG_SERIAL_CORE=m but SERIAL_MEN_Z135=y. drivers/built-in.o: In function `men_z135_remove': men_z135_uart.c:(.text+0x5bc53): undefined reference to `uart_remove_one_port' drivers/built-in.o: In function `men_z135_set_termios': men_z135_uart.c:(.text+0x5c3b5): undefined reference to `uart_get_baud_rate' men_z135_uart.c:(.text+0x5c415): undefined reference to `uart_update_timeout' drivers/built-in.o: In function `men_z135_handle_tx': men_z135_uart.c:(.text+0x5c8f4): undefined reference to `uart_write_wakeup' drivers/built-in.o: In function `men_z135_intr': men_z135_uart.c:(.text+0x5ce28): undefined reference to `uart_handle_dcd_change' men_z135_uart.c:(.text+0x5ce51): undefined reference to `uart_handle_cts_change' drivers/built-in.o: In function `men_z135_probe': men_z135_uart.c:(.text+0x5cf96): undefined reference to `uart_add_one_port' drivers/built-in.o: In function `men_z135_init': men_z135_uart.c:(.init.text+0x26e9): undefined reference to `uart_register_driver' men_z135_uart.c:(.init.text+0x2766): undefined reference to `uart_unregister_driver' drivers/built-in.o: In function `men_z135_exit': men_z135_uart.c:(.exit.text+0xe4): undefined reference to `uart_unregister_driver' make[1]: *** [vmlinux] Error 1 Hi Randy, There is a not yet merged patch from Arnd Bergmann, which can be found here: https://lkml.org/lkml/2014/4/29/529 I've just checked and it resolves the problem at my place, can you please verify it as well. Thanks, Johannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/6] phy: add a driver for the Berlin SATA PHY
Hi,
On Wednesday 14 May 2014 03:51 PM, Antoine Ténart wrote:
Hi,
On Wed, May 14, 2014 at 03:43:03PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 14 May 2014 03:18 PM, Antoine Ténart wrote:
[…]
+#define to_berlin_sata_phy_priv(desc) \
+ container_of((desc), struct phy_berlin_priv, phys[(desc)-index])
+
+struct phy_berlin_desc {
+ struct phy *phy;
+ u32 val;
+ unsignedindex;
+};
+
+struct phy_berlin_priv {
+ void __iomem*base;
+ spinlock_t lock;
+ struct phy_berlin_desc phys[BERLIN_SATA_PHY_NB];
Can't we do away with hardcoding BERLIN_SATA_PHY_NB?
We can't if we want to be able to use the container_of macro in
to_berlin_sata_phy_priv(). And we want a common structure to store the
common spinlock and base address.
to get phy_berlin_priv, you can use dev_get_drvdata(phy-dev-parent).
[…]
+ /*
+* By default the PHY node is used to request and match a PHY.
+* We describe one PHY per sub-node here. Use the right node.
+*/
+ phy-dev.of_node = child;
+
+ priv-phys[phy_id].phy = phy;
+ priv-phys[phy_id].val = desc[phy_id].val;
+ priv-phys[phy_id].index = phy_id;
+ phy_set_drvdata(phy, priv-phys[phy_id]);
+
+ /* Make sure the PHY is off */
+ phy_berlin_sata_power_off(phy);
+
+ phy_provider = devm_of_phy_provider_register(phy-dev,
+
of_phy_simple_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
was this intentional? registering multiple PHY providers?
Yes. Each sub-node describe a PHY and register as a PHY provider. This
allow to reference the PHY as sata_phy0 and not sata_phy 0. It
would be confusing to have a sub-node sata_phy0 and to use its parent
to access it.
It is still a single PHY provider, so you can't register multiple PHY
providers. So in this case sata_phy 0 is not that bad.
However phy-core.c should be patched with the following (only compile tested)
From 2517d4c0ad7f13abc2613516ef2b222a1fbcb550 Mon Sep 17 00:00:00 2001
From: Kishon Vijay Abraham I kis...@ti.com
Date: Thu, 15 May 2014 11:32:57 +0530
Subject: [PATCH] phy: phy-core: Support modelling multi-PHY PHY nodes as
subnodes of PHY PROVIDER
When a single PHY provider implementing multiple PHYs is represented in dt,
the PHYs should be modelled as sub nodes of the PHY PROVIDER node.
So the consumers using the PHY will have the phandle of the sub node rather
than the phandle of the PHY PROVIDER. Amended *of_phy_provider_lookup* in
PHY core to return the PHY PROVIDER even when the phandle of the PHY PROVIDERs
sub node is provided.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/phy-core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..124c6ec 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -83,10 +83,18 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
{
struct phy_provider *phy_provider;
+ struct device_node *child;
list_for_each_entry(phy_provider, phy_provider_list, list) {
- if (phy_provider-dev-of_node == node)
+ if (phy_provider-dev-of_node != node) {
+ for_each_child_of_node(phy_provider-dev-of_node,
+ child) {
+ if (child == node)
+ return phy_provider;
+ }
+ } else {
return phy_provider;
+ }
}
return ERR_PTR(-EPROBE_DEFER);
--
1.7.9.5
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 0/5] Add support for SW babble Control
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an
IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-George
--
-George
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 09/16] kgr: mark task_safe in some kthreads
On Thu, 2014-05-15 at 02:05 -0400, Tejun Heo wrote: I'm not sure how much weight I can put on the specific use case. Even with the direct control that the user thought to have previously, the use case was ripe with possibilities of breakage from any number of reasons. For example, there are driver paths which bounce to async execution on IO exceptions (doesn't have to be hard errors) and setups like the above would easily lock out exception handling and how's the setup gonna work when the filesystems have to use dynamic pool of workers as btrfs does? Oh yeah, this case isn't about _real_ realtime at all, it's just about unmanageable priority inversion. With hack, any/all kthreads spawning will start life at the priority the user specified, so as long as he doesn't prioritize userspace above that, he can do whatever evil deeds he sees fit, and box will function as expected. The identified problem in the above case is allowing the kernel to make reasonable forward progress even when RT processes don't concede CPU cycles. Not only, but yeah, mostly. If that is a use case that needs to be supported, we better engineer an appropriate solution for that. Such solution doesn't necessarily have to be advanced either. My solution isn't the least bit sophisticated. Dirt simple is usually best anyway, and is enough for the cases I've encountered. Maybe all that's necessary is marking the async mechanisms involved in IO path as such (we already need to mark all workqueues involved in memory reclaim path anyway) and provide a mechanism to make all of them RT when directed. It might be simple but still would be a concious engineering decision. You could do all singing/dancing PI boost thingy like RCU, but personally, I hate that, disable it. I think the point I'm trying to make is that it isn't possible to continue improving and maintaining the kernel with blanket restrictions on internal details. If certain things shouldn't be done, we better find out the specific reasons; otherwise, it's impossible to weight the pros and cons of different options and make a reasonable choice or to find out ways to accomodate those restrictions while still achieving the original goals. Anyways, we're getting slightly off-topic and it seems like we'll have to agree to disagree. Hey, we agree! :) -Mike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the clk tree with the renesas tree
Quoting Stephen Rothwell (2014-05-14 23:11:21) Hi Mike, Today's linux-next merge of the clk tree got a conflict in Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt between commit b557deadc5cc (ARM: shmobile: r7s72100: document MSTP clock support) from the renesas tree and commit 5483bf698f42 (clk: shmobile: r8a7779: Add MSTP clock support) from the clk tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). Stephen, Your fix is correct, per Geert's email in another thread[1]. Regards, Mike [1] http://www.spinics.net/lists/linux-sh/msg31748.html -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt index b5fc72621bfd,30df825d72ef.. --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt @@@ -10,7 -10,7 +10,8 @@@ index in the group, from 0 to 31 Required Properties: - compatible: Must be one of the following +- renesas,r7s72100-mstp-clocks for R7S72100 (RZ) MSTP gate clocks + - renesas,r8a7779-mstp-clocks for R8A7779 (R-Car H1) MSTP gate clocks - renesas,r8a7790-mstp-clocks for R8A7790 (R-Car H2) MSTP gate clocks - renesas,r8a7791-mstp-clocks for R8A7791 (R-Car M2) MSTP gate clocks - renesas,cpg-mstp-clock for generic MSTP gate clocks -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 1/3] slub: keep full slabs on list for per memcg caches
On Wed, May 14, 2014 at 11:16:36AM -0500, Christoph Lameter wrote:
On Tue, 13 May 2014, Vladimir Davydov wrote:
Currently full slabs are only kept on per-node lists for debugging, but
we need this feature to reparent per memcg caches, so let's enable it
for them too.
That will significantly impact the fastpaths for alloc and free.
Also a pretty significant change the logic of the fastpaths since they
were not designed to handle the full lists. In debug mode all operations
were only performed by the slow paths and only the slow paths so far
supported tracking full slabs.
That's the minimal price we have to pay for slab re-parenting, because
w/o it we won't be able to look up for all slabs of a particular per
memcg cache. The question is, can it be tolerated or I'd better try some
other way?
@@ -2587,6 +2610,9 @@ static void __slab_free(struct kmem_cache *s, struct
page *page,
} else { /* Needs to be taken off a list */
+ if (kmem_cache_has_cpu_partial(s) !prior)
+ new.frozen = 1;
+
n = get_node(s, page_to_nid(page));
Make this code conditional?
No problem, this patch is just a draft. Thanks to static keys, it won't
be difficult to eliminate any overhead if there is no kmem-active
memcgs.
Thanks.
/*
* Speculatively acquire the list_lock.
@@ -2606,6 +2632,12 @@ static void __slab_free(struct kmem_cache *s, struct
page *page,
object, new.counters,
__slab_free));
+ if (unlikely(n) new.frozen !was_frozen) {
+ remove_full(s, n, page);
+ spin_unlock_irqrestore(n-list_lock, flags);
+ n = NULL;
+ }
+
if (likely(!n)) {
Here too.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] clk/versatile: export symbols for impd1
Quoting Arnd Bergmann (2014-05-08 07:56:16)
The impd1 code on mach-integrator can be a loadable module,
so we have to export icst_clk_register, integrator_impd1_clk_init
and integrator_impd1_clk_exit.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Mike Turquette mturque...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Taken into clk-next.
Thanks!
Mike
---
drivers/clk/versatile/clk-icst.c | 1 +
drivers/clk/versatile/clk-impd1.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/clk/versatile/clk-icst.c
b/drivers/clk/versatile/clk-icst.c
index a820b0c..7f3868a 100644
--- a/drivers/clk/versatile/clk-icst.c
+++ b/drivers/clk/versatile/clk-icst.c
@@ -160,3 +160,4 @@ struct clk *icst_clk_register(struct device *dev,
return clk;
}
+EXPORT_SYMBOL_GPL(icst_clk_register);
diff --git a/drivers/clk/versatile/clk-impd1.c
b/drivers/clk/versatile/clk-impd1.c
index 31b44f0..264d8d5 100644
--- a/drivers/clk/versatile/clk-impd1.c
+++ b/drivers/clk/versatile/clk-impd1.c
@@ -133,6 +133,7 @@ void integrator_impd1_clk_init(void __iomem *base,
unsigned int id)
for (i = 0; i ARRAY_SIZE(imc-clks); i++)
clkdev_add(imc-clks[i]);
}
+EXPORT_SYMBOL_GPL(integrator_impd1_clk_init);
void integrator_impd1_clk_exit(unsigned int id)
{
@@ -155,3 +156,4 @@ void integrator_impd1_clk_exit(unsigned int id)
kfree(imc-vco2name);
kfree(imc-vco1name);
}
+EXPORT_SYMBOL_GPL(integrator_impd1_clk_exit);
--
1.8.3.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] drivers: staging: line6: Add blank lines after declarations
On Tue, May 13, 2014 at 02:02:01PM +0200, Greg KH wrote:
On Wed, May 14, 2014 at 02:56:42AM +0300, Artem Fetishev wrote:
Use the more common kernel coding style.
Signed-off-by: Artem Fetishev wwctr...@gmail.com
---
drivers/staging/line6/capture.c |4
drivers/staging/line6/midi.c |2 ++
drivers/staging/line6/playback.c |5 +
drivers/staging/line6/pod.c |5 +
drivers/staging/line6/toneport.c |2 ++
drivers/staging/line6/variax.c |2 ++
6 files changed, 20 insertions(+)
diff --git a/drivers/staging/line6/capture.c
b/drivers/staging/line6/capture.c
index 0eda51d..14ed0d7 100644
--- a/drivers/staging/line6/capture.c
+++ b/drivers/staging/line6/capture.c
@@ -97,6 +97,7 @@ void line6_unlink_audio_in_urbs(struct snd_line6_pcm
*line6pcm)
if (test_bit(i, line6pcm-active_urb_in)) {
if (!test_and_set_bit(i, line6pcm-unlink_urb_in)) {
struct urb *u = line6pcm-urb_audio_in[i];
+
usb_unlink_urb(u);
}
}
@@ -122,6 +123,7 @@ void line6_wait_clear_audio_in_urbs(struct
snd_line6_pcm *line6pcm)
if (!alive)
break;
set_current_state(TASK_UNINTERRUPTIBLE);
+
schedule_timeout(1);
} while (--timeout 0);
if (alive)
That line doesn't look like it needs to be added, why do so?
I've removed that new line in v2 of the patch. I sent it two days ago.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: ioremap: Fix static vm area boundary checking.
Static vm area boundary check:
paddr1 ---| |
| |
|---| -\--- svm-vm-addr(is page aligned)
paddr2 ---| ||
| --| --|-- svm-vm-phys_addr
| ||
paddr3 ---| ||
| ||
|---| --|-- next page boundary
| ||
paddr4 ---| || - svm-vm-size(including guard page)
| ||
| ||
max paddr_end --|---| --|-- svm-vm's phys_addr_end
| / ||
paddr5 ---| guard ||
| page ||
| / ||
--- -/--- svm-vm-addr + svm-vm_size
1 If the paddr == paddr1, then continue;
2 If the paddr == paddr2~paddr4 and paddr_end phys_addr_end,
then continue;
3 if the paddr = paddr5 then continue;
Signed-off-by: Richard Lee superlibj8...@gmail.com
---
arch/arm/mm/ioremap.c | 44 ++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index be69333..2fa41f4 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -47,16 +47,56 @@ static struct static_vm *find_static_vm_paddr(phys_addr_t
paddr,
{
struct static_vm *svm;
struct vm_struct *vm;
+ size_t offset;
+
+ /*
+* Make sure the size the mapping size is page aligned.
+*/
+ size = PAGE_ALIGN((paddr ~PAGE_SIZE) + size);
+ offset = paddr ~PAGE_SIZE;
list_for_each_entry(svm, static_vmlist, list) {
+ phys_addr_t paddr_end, phys_addr_end;
+ size_t vmoff;
+
vm = svm-vm;
if (!(vm-flags VM_ARM_STATIC_MAPPING))
continue;
if ((vm-flags VM_ARM_MTYPE_MASK) != VM_ARM_MTYPE(mtype))
continue;
- if (vm-phys_addr paddr ||
- paddr + size - 1 vm-phys_addr + vm-size - 1)
+ /* Static vm area boundary check:
+*
+* paddr1 ---| |
+* | |
+* |---| -\--- svm-vm-addr(page aligned)
+* paddr2 ---| ||
+* | --| --|-- svm-vm-phys_addr
+* | ||
+* paddr3 ---| ||
+* | ||
+* |---| --|-- next page boundary
+* | ||
+* paddr4 ---| || - svm-vm-size,
+* | || including guard page
+* | ||
+* max paddr_end --|---| --|-- svm-vm's phys_addr_end
+* | / ||
+* paddr5 ---| guard ||
+* | page ||
+* | / ||
+* --- -/-- svm-vm-addr + svm-vm_size
+*
+* 1 If paddr == paddr1, then continue;
+* 2 If paddr == paddr2~paddr4 and paddr_end phys_addr_end,
+* then continue;
+* 3 if paddr = paddr5 then continue;
+*/
+ vmoff = vm-phys_addr ~PAGE_SIZE;
+ phys_addr_end = vm-phys_addr + vm-size - PAGE_SIZE - vmoff;
+ paddr_end = paddr + size - offset;
+ if (__phys_to_pfn(vm-phys_addr) __phys_to_pfn(paddr) ||
+ paddr_end - 1 phys_addr_end - 1)
continue;
return svm;
--
1.8.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 v3 1/2] smp: Print more useful debug info upon receiving IPI on an offline CPU
On 05/13/2014 09:08 PM, Frederic Weisbecker wrote:
On Mon, May 12, 2014 at 02:06:49AM +0530, Srivatsa S. Bhat wrote:
Today the smp-call-function code just prints a warning if we get an IPI on
an offline CPU. This info is sufficient to let us know that something went
wrong, but often it is very hard to debug exactly who sent the IPI and why,
from this info alone.
In most cases, we get the warning about the IPI to an offline CPU,
immediately
after the CPU going offline comes out of the stop-machine phase and reenables
interrupts. Since all online CPUs participate in stop-machine, the
information
regarding the sender of the IPI is already lost by the time we exit the
stop-machine loop. So even if we dump the stack on each CPU at this point,
we won't find anything useful since all of them will show the stack-trace of
the stopper thread. So we need a better way to figure out who sent the IPI
and
why.
To achieve this, when we detect an IPI targeted to an offline CPU, loop
through
the call-single-data linked list and print out the payload (i.e., the name
of the function which was supposed to be executed by the target CPU). This
would give us an insight as to who might have sent the IPI and help us debug
this further.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
kernel/smp.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index 06d574e..f864921 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -185,14 +185,24 @@ void generic_smp_call_function_single_interrupt(void)
{
struct llist_node *entry;
struct call_single_data *csd, *csd_next;
+static bool warned;
+
+entry = llist_del_all(__get_cpu_var(call_single_queue));
+entry = llist_reverse_order(entry);
/*
* Shouldn't receive this interrupt on a cpu that is not yet online.
*/
-WARN_ON_ONCE(!cpu_online(smp_processor_id()));
-
-entry = llist_del_all(__get_cpu_var(call_single_queue));
-entry = llist_reverse_order(entry);
+if (unlikely(!cpu_online(smp_processor_id()) !warned)) {
+warned = true;
+WARN_ON(1);
More details may be better:
WARN_ONCE(1, IPI on offline CPU);
Sure, that sounds better.
+/*
+ * We don't have to use the _safe() variant here
+ * because we are not invoking the IPI handlers yet.
+ */
+llist_for_each_entry(csd, entry, llist)
+pr_warn(SMP IPI Payload: %pS \n, csd-func);
Payload is kind of vague. How about IPI func %pS sent on offline CPU.
Ok, and maybe s/func/function and s/on/to ?
+}
llist_for_each_entry_safe(csd, csd_next, entry, llist) {
csd-func(csd-info);
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 V6 07/11] ACPI: introduce dummy lpss scan handler
The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.
Fix this problem for lpss devices by introducing a dummy
lpss scan handler in this patch.
Plus, if lpt_clk_init() fails, we need this dummy scan handler as well.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/Makefile| 2 +-
drivers/acpi/acpi_lpss.c | 69 ++--
drivers/acpi/internal.h | 4 ---
3 files changed, 50 insertions(+), 25 deletions(-)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 171efc2..605eff7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y+= processor_core.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-$(CONFIG_X86_INTEL_LPSS) += acpi_lpss.o
+acpi-y += acpi_lpss.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-y += power.o
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 69e29f4..965428f 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -24,6 +24,8 @@
ACPI_MODULE_NAME(acpi_lpss);
+#ifdef CONFIG_X86_INTEL_LPSS
+
#define LPSS_CLK_SIZE 0x04
#define LPSS_LTR_SIZE 0x18
@@ -159,40 +161,50 @@ static struct lpss_device_desc byt_i2c_dev_desc = {
.shared_clock = i2c_clock,
};
+#define LPSS_PTR(desc) ((unsigned long)desc)
+
+#else
+
+#define LPSS_PTR(desc) 0
+
+#endif
+
static const struct acpi_device_id acpi_lpss_device_ids[] = {
/* Generic LPSS devices */
- { INTL9C60, (unsigned long)lpss_dma_desc },
+ { INTL9C60, LPSS_PTR(lpss_dma_desc) },
/* Lynxpoint LPSS devices */
- { INT33C0, (unsigned long)lpt_dev_desc },
- { INT33C1, (unsigned long)lpt_dev_desc },
- { INT33C2, (unsigned long)lpt_dev_desc },
- { INT33C3, (unsigned long)lpt_dev_desc },
- { INT33C4, (unsigned long)lpt_uart_dev_desc },
- { INT33C5, (unsigned long)lpt_uart_dev_desc },
- { INT33C6, (unsigned long)lpt_sdio_dev_desc },
+ { INT33C0, LPSS_PTR(lpt_dev_desc) },
+ { INT33C1, LPSS_PTR(lpt_dev_desc) },
+ { INT33C2, LPSS_PTR(lpt_dev_desc) },
+ { INT33C3, LPSS_PTR(lpt_dev_desc) },
+ { INT33C4, LPSS_PTR(lpt_uart_dev_desc) },
+ { INT33C5, LPSS_PTR(lpt_uart_dev_desc) },
+ { INT33C6, LPSS_PTR(lpt_sdio_dev_desc) },
{ INT33C7, },
/* BayTrail LPSS devices */
- { 80860F09, (unsigned long)byt_pwm_dev_desc },
- { 80860F0A, (unsigned long)byt_uart_dev_desc },
- { 80860F0E, (unsigned long)byt_spi_dev_desc },
- { 80860F14, (unsigned long)byt_sdio_dev_desc },
- { 80860F41, (unsigned long)byt_i2c_dev_desc },
+ { 80860F09, LPSS_PTR(byt_pwm_dev_desc) },
+ { 80860F0A, LPSS_PTR(byt_uart_dev_desc) },
+ { 80860F0E, LPSS_PTR(byt_spi_dev_desc) },
+ { 80860F14, LPSS_PTR(byt_sdio_dev_desc) },
+ { 80860F41, LPSS_PTR(byt_i2c_dev_desc) },
{ INT33B2, },
- { INT3430, (unsigned long)lpt_dev_desc },
- { INT3431, (unsigned long)lpt_dev_desc },
- { INT3432, (unsigned long)lpt_dev_desc },
- { INT3433, (unsigned long)lpt_dev_desc },
- { INT3434, (unsigned long)lpt_uart_dev_desc },
- { INT3435, (unsigned long)lpt_uart_dev_desc },
- { INT3436, (unsigned long)lpt_sdio_dev_desc },
+ { INT3430, LPSS_PTR(lpt_dev_desc) },
+ { INT3431, LPSS_PTR(lpt_dev_desc) },
+ { INT3432, LPSS_PTR(lpt_dev_desc) },
+ { INT3433, LPSS_PTR(lpt_dev_desc) },
+ { INT3434, LPSS_PTR(lpt_uart_dev_desc) },
+ { INT3435, LPSS_PTR(lpt_uart_dev_desc) },
+ { INT3436, LPSS_PTR(lpt_sdio_dev_desc) },
{ INT3437, },
{ }
};
+#ifdef CONFIG_X86_INTEL_LPSS
+
static int is_memory(struct acpi_resource *res, void *not_used)
{
struct resource r;
@@ -511,10 +523,27 @@ static struct acpi_scan_handler lpss_handler = {
.unbind = acpi_lpss_unbind,
};
+#endif /* CONFIG_X86_INTEL_LPSS */
+
+static int acpi_lpss_dummy_attach(struct acpi_device *adev,
+ const struct acpi_device_id *id)
+{
+ return 1;
+}
+
+static struct acpi_scan_handler lpss_dummy_handler = {
+ .ids = acpi_lpss_device_ids,
+ .attach = acpi_lpss_dummy_attach,
+};
+
void __init acpi_lpss_init(void)
{
+#ifdef CONFIG_X86_INTEL_LPSS
if (!lpt_clk_init()) {
bus_register_notifier(platform_bus_type, acpi_lpss_nb);
acpi_scan_add_handler(lpss_handler);
+ return;
}
[PATCH V6 01/11] ACPI: introduce .match() callback for ACPI scan handler
Currently, ACPI scan handler uses strcmp() to match device ids
and scan handler ids.
When converting PNPACPI enumeration into a scan handler, which I will do
later in this patch set, the current code becomes not flexible enough
because ACPI pnp scan handler requires wildcase and case insensitive support.
Thus a per scan handler .match() callback is introduced in this patch,
so that specified scan handler can have more flexible matching mechanism
by introduce its own .match() callback.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/scan.c | 17 +++--
include/acpi/acpi_bus.h | 1 +
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7efe546..e46e51c 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1974,14 +1974,19 @@ static bool acpi_scan_handler_matching(struct
acpi_scan_handler *handler,
const struct acpi_device_id *devid;
for (devid = handler-ids; devid-id[0]; devid++)
- if (!strcmp((char *)devid-id, idstr)) {
- if (matchid)
- *matchid = devid;
-
- return true;
- }
+ if (handler-match) {
+ if (handler-match(idstr, (char *)devid-id))
+ goto success;
+ } else
+ if (!strcmp((char *)devid-id, idstr))
+ goto success;
return false;
+
+success:
+ if (matchid)
+ *matchid = devid;
+ return true;
}
static struct acpi_scan_handler *acpi_scan_match_handler(char *idstr,
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 84a2e29..ba679af 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -131,6 +131,7 @@ static inline struct acpi_hotplug_profile
*to_acpi_hotplug_profile(
struct acpi_scan_handler {
const struct acpi_device_id *ids;
struct list_head list_node;
+ int (*match)(char *devid, char *handler_id);
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
void (*bind)(struct device *phys_dev);
--
1.8.3.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/
[PATCH V6 02/11] PNPACPI: use whilte list for pnpacpi device enumeration
ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.
Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
three capital charactors followed by four hex numbers,
3. is not in the excluded id list,
it is enumerated to PNP bus.
So actually, PNP bus is used as the default bus for enumerating _HID devices.
But, nowadays, more and more _HID devices are needed to be enumerate to
platform bus instead. And a white list is used for those devices to avoid
overlapping with PNP bus.
The problem is that this list is continuously growing.
So, a solution that uses platform bus as the default bus for _HID enumeration
is preferred.
In order to do this, this patch changes the way of enumerating PNP devices.
As the first step, we use a white list (scan handler) to create PNP devices
instead. This white list contains all the pnp_device_id strings in all the pnp
drivers, thus this change is transparent to PNP core and all the PNP drivers.
Note: I just grep all the id strings in all pnp_device_id instances and
copy them to the new white list, with a few changes to the comments
only, to follow the format of:
/* driver name, or file name if not a PNP driver */
{id-string}, /* optional comments for the id-string */
...
Note: the PNPACPI devices are created in two step,
1. mark the PNPACPI devices by the acpi pnp scan handler.
2. create the PNPACPI devices in PNPACPI code in a fs_initcall()
In this case, if PNP/PNPACPI is not set or pnpacpi=off kernel option
is used, the acpi pnp scan handler is still there, to prevent those
PNPACPI devices from being created to platform bus.
Note: For CMOS RTC devices, the acpi pnp scan handler does not work because
there is already a cmos rtc scan handler installed, thus we need to
check those devices and enumerate them to PNP bus explicitly.
Plus, the cmos rtc scan handler needs to return 1 so that it will not
be enumerated to platform bus.
TODO: Reduce this PNPACPI white list by
1. remove the ids for the devices that are never enumerated via ACPI
2. remove the ids and convert the drivers to platform bus drivers
for the devices that are not PNP devices in nature.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/Makefile| 1 +
drivers/acpi/acpi_cmos_rtc.c | 2 +-
drivers/acpi/acpi_pnp.c | 388 +++
drivers/acpi/internal.h | 1 +
drivers/acpi/scan.c | 1 +
drivers/pnp/pnpacpi/core.c | 28 +---
include/linux/acpi.h | 2 +
7 files changed, 398 insertions(+), 25 deletions(-)
create mode 100644 drivers/acpi/acpi_pnp.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..9a43893 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
acpi-$(CONFIG_X86_INTEL_LPSS) += acpi_lpss.o
acpi-y += acpi_platform.o
+acpi-y += acpi_pnp.o
acpi-y += power.o
acpi-y += event.o
acpi-y += sysfs.o
diff --git a/drivers/acpi/acpi_cmos_rtc.c b/drivers/acpi/acpi_cmos_rtc.c
index 961b45d..2da8660 100644
--- a/drivers/acpi/acpi_cmos_rtc.c
+++ b/drivers/acpi/acpi_cmos_rtc.c
@@ -68,7 +68,7 @@ static int acpi_install_cmos_rtc_space_handler(struct
acpi_device *adev,
return -ENODEV;
}
- return 0;
+ return 1;
}
static void acpi_remove_cmos_rtc_space_handler(struct acpi_device *adev)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
new file mode 100644
index 000..57d14ed
--- /dev/null
+++ b/drivers/acpi/acpi_pnp.c
@@ -0,0 +1,388 @@
+/*
+ * ACPI support for PNP bus type
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Authors: Zhang Rui rui.zh...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/module.h
+
+static const struct acpi_device_id acpi_pnp_device_ids[] = {
+ /* pata_isapnp */
+ {PNP0600},/* Generic ESDI/IDE/ATA compatible hard disk
controller */
+ /* floppy */
+ {PNP0700},
+ /* ipmi_si */
+ {IPI0001},
+ /* tpm_inf_pnp */
+ {IFX0101},/* Infineon TPMs */
+ {IFX0102},/* Infineon TPMs */
+ /*tpm_tis */
+ {PNP0C31},/* TPM */
+ {ATM1200},/* Atmel */
+ {IFX0102},/* Infineon */
+ {BCM0101},/* Broadcom */
+ {BCM0102},/* Broadcom */
+ {NSC1200},/* National */
+ {ICO0102},/* Intel */
+ /* ide */
[PATCH V6 11/11] ACPI: introduce acpi platform exclude id list
For ACPI PIC (PNP), Timer (PNP0100) and DMA controller (PNP0200)
device objects, although they have _HID control method, but they
should not be enumerated to platform bus, because there will never be
any platform drivers for them.
Thus an exclude id list is introduced in this patch to prevent
those platform device nodes from being created.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/acpi_platform.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 33376a9..db89480 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,6 +22,18 @@
ACPI_MODULE_NAME(platform);
+static const struct acpi_device_id excluded_id_list[] = {
+ {PNP, 0}, /* PIC */
+ {PNP0100, 0}, /* Timer */
+ {PNP0200, 0}, /* AT DMA Controller */
+ {, 0},
+};
+
+static bool is_exclusive_device(struct acpi_device *dev)
+{
+ return !acpi_match_device_ids(dev, excluded_id_list);
+}
+
/**
* acpi_create_platform_device - Create platform device for ACPI device node
* @adev: ACPI device node to create a platform device for.
@@ -48,6 +60,9 @@ int acpi_create_platform_device(struct acpi_device *adev,
if (adev-physical_node_count)
return 0;
+ if (is_exclusive_device(adev))
+ return 0;
+
INIT_LIST_HEAD(resource_list);
count = acpi_dev_get_resources(adev, resource_list, NULL, NULL);
if (count 0) {
--
1.8.3.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/
[PATCH V6 09/11] ACPI: introduce flag .is_master_device
For some ACPI device objects, they represent master devices,
and their children devices are enumerated by bus controller drivers
for the buses they are on.
In this case, we do not want to enumerate their children devices to
platform bus explicitly in acpi scan code.
Thus a new flag .is_master_device is introduced in this patch.
For devices with this flag set, we will not do default enumeration
for their children.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/acpi_lpss.c | 62 +---
include/acpi/acpi_bus.h | 3 ++-
2 files changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 965428f..4ab0915 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -54,6 +54,7 @@ struct lpss_shared_clock {
struct lpss_private_data;
struct lpss_device_desc {
+ bool is_master_device;
bool clk_required;
const char *clkdev_name;
bool ltr_required;
@@ -91,6 +92,7 @@ static void lpss_uart_setup(struct lpss_private_data *pdata)
}
static struct lpss_device_desc lpt_dev_desc = {
+ .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
@@ -98,6 +100,7 @@ static struct lpss_device_desc lpt_dev_desc = {
};
static struct lpss_device_desc lpt_uart_dev_desc = {
+ .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.ltr_required = true,
@@ -106,6 +109,7 @@ static struct lpss_device_desc lpt_uart_dev_desc = {
};
static struct lpss_device_desc lpt_sdio_dev_desc = {
+ .is_master_device = true,
.prv_offset = 0x1000,
.prv_size_override = 0x1018,
.ltr_required = true,
@@ -127,6 +131,7 @@ static struct lpss_shared_clock uart_clock = {
};
static struct lpss_device_desc byt_uart_dev_desc = {
+ .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.clk_gate = true,
@@ -140,6 +145,7 @@ static struct lpss_shared_clock spi_clock = {
};
static struct lpss_device_desc byt_spi_dev_desc = {
+ .is_master_device = true,
.clk_required = true,
.prv_offset = 0x400,
.clk_gate = true,
@@ -147,6 +153,7 @@ static struct lpss_device_desc byt_spi_dev_desc = {
};
static struct lpss_device_desc byt_sdio_dev_desc = {
+ .is_master_device = true,
.clk_required = true,
};
@@ -156,16 +163,24 @@ static struct lpss_shared_clock i2c_clock = {
};
static struct lpss_device_desc byt_i2c_dev_desc = {
+ .is_master_device = true,
.clk_required = true,
.prv_offset = 0x800,
.shared_clock = i2c_clock,
};
#define LPSS_PTR(desc) ((unsigned long)desc)
+#define LPSS_MASTER_PTR(desc) LPSS_PTR(desc)
#else
-#define LPSS_PTR(desc) 0
+static struct lpss_device_desc lpss_dummy_desc;
+static struct lpss_device_desc lpss_dummy_master_desc = {
+ .is_master_device = true,
+};
+
+#define LPSS_PTR(desc) (lpss_dummy_desc)
+#define LPSS_MASTER_PTR(desc) (lpss_dummy_master_desc)
#endif
@@ -174,30 +189,30 @@ static const struct acpi_device_id acpi_lpss_device_ids[]
= {
{ INTL9C60, LPSS_PTR(lpss_dma_desc) },
/* Lynxpoint LPSS devices */
- { INT33C0, LPSS_PTR(lpt_dev_desc) },
- { INT33C1, LPSS_PTR(lpt_dev_desc) },
- { INT33C2, LPSS_PTR(lpt_dev_desc) },
- { INT33C3, LPSS_PTR(lpt_dev_desc) },
- { INT33C4, LPSS_PTR(lpt_uart_dev_desc) },
- { INT33C5, LPSS_PTR(lpt_uart_dev_desc) },
- { INT33C6, LPSS_PTR(lpt_sdio_dev_desc) },
+ { INT33C0, LPSS_MASTER_PTR(lpt_dev_desc) },
+ { INT33C1, LPSS_MASTER_PTR(lpt_dev_desc) },
+ { INT33C2, LPSS_MASTER_PTR(lpt_dev_desc) },
+ { INT33C3, LPSS_MASTER_PTR(lpt_dev_desc) },
+ { INT33C4, LPSS_MASTER_PTR(lpt_uart_dev_desc) },
+ { INT33C5, LPSS_MASTER_PTR(lpt_uart_dev_desc) },
+ { INT33C6, LPSS_MASTER_PTR(lpt_sdio_dev_desc) },
{ INT33C7, },
/* BayTrail LPSS devices */
{ 80860F09, LPSS_PTR(byt_pwm_dev_desc) },
- { 80860F0A, LPSS_PTR(byt_uart_dev_desc) },
- { 80860F0E, LPSS_PTR(byt_spi_dev_desc) },
- { 80860F14, LPSS_PTR(byt_sdio_dev_desc) },
- { 80860F41, LPSS_PTR(byt_i2c_dev_desc) },
+ { 80860F0A, LPSS_MASTER_PTR(byt_uart_dev_desc) },
+ { 80860F0E, LPSS_MASTER_PTR(byt_spi_dev_desc) },
+ { 80860F14, LPSS_MASTER_PTR(byt_sdio_dev_desc) },
+ { 80860F41, LPSS_MASTER_PTR(byt_i2c_dev_desc) },
{ INT33B2, },
- { INT3430, LPSS_PTR(lpt_dev_desc) },
- { INT3431, LPSS_PTR(lpt_dev_desc) },
- { INT3432, LPSS_PTR(lpt_dev_desc) },
- { INT3433, LPSS_PTR(lpt_dev_desc) },
- { INT3434, LPSS_PTR(lpt_uart_dev_desc) },
- { INT3435, LPSS_PTR(lpt_uart_dev_desc) },
- { INT3436, LPSS_PTR(lpt_sdio_dev_desc) },
+ { INT3430, LPSS_MASTER_PTR(lpt_dev_desc) },
+ { INT3431,
[PATCH V6 04/11] ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit
The serial pnp driver supports some unknown PNP modems (PNPCXXX/PNPDXXX)
by matching magic strings in the pnp device name or the pnp device card name.
ACPI enumerated PNP device neither supports pnp card, nor supports those magic
strings in its device name, which means this mechamism never works for ACPI
enumerated PNPCXXX/PNPDXXX devices.
So it is safe to remove those two ids from the ACPI pnp scan handler id list.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/acpi_pnp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index d206616..a563a27 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -300,8 +300,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
{LTS0001},/* LG C1 EXPRESS DUAL (C1-PB11A3) touch screen
(actually a FUJ02E6 in disguise) */
{WCI0003},/* Rockwell's (PORALiNK) 33600 INT PNP */
{WEC1022},/* Winbond CIR port, should not be probed. We
should keep track of it to prevent the legacy serial driver from probing it */
- {PNPCXXX},/* Unknown PnP modems */
- {PNPDXXX},/* More unknown PnP modems */
/* scl200wdt */
{NSC0800},/* National Semiconductor PC87307/PC97307
watchdog component */
/* mpu401 */
--
1.8.3.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/
[PATCH V6 08/11] ACPI: introduce platform_id flag
Only certain kind of ACPI device objects can be enumerated to platform bus.
These ACPI device objects include
1. ACPI device objects that have _HID control method.
2. some ACPI device objects that have Linux specified HID strings.
In order to distinguish those device objects from the others, a new flag
platform_id and a new function acpi_add_platform_id() are introduced
in this patch.
Currently, only devices with _HID method have this flag set.
If you want platform devices to be created for device objects without _HID,
use acpi_add_platform_id() when adding artificial Linux-specific ID strings
to them.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/scan.c | 9 -
include/acpi/acpi_bus.h | 3 ++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c82ab73..451e7d9 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1730,6 +1730,13 @@ static void acpi_add_id(struct acpi_device_pnp *pnp,
const char *dev_id)
pnp-type.hardware_id = 1;
}
+static void acpi_add_platform_id(struct acpi_device_pnp *pnp,
+const char *dev_id)
+{
+ acpi_add_id(pnp, dev_id);
+ pnp-type.platform_id = 1;
+}
+
/*
* Old IBM workstations have a DSDT bug wherein the SMBus object
* lacks the SMBUS01 HID and the methods do not have the necessary _
@@ -1794,7 +1801,7 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct
acpi_device_pnp *pnp,
}
if (info-valid ACPI_VALID_HID)
- acpi_add_id(pnp, info-hardware_id.string);
+ acpi_add_platform_id(pnp, info-hardware_id.string);
if (info-valid ACPI_VALID_CID) {
cid_list = info-compatible_id_list;
for (i = 0; i cid_list-count; i++)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ba679af..ec92ad3 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -233,7 +233,8 @@ struct acpi_hardware_id {
struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
- u32 reserved:30;
+ u32 platform_id:1;
+ u32 reserved:29;
};
struct acpi_device_pnp {
--
1.8.3.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/
[PATCH V6 05/11] ACPI: introduce dummy container scan handler
The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.
Fix this problem for container devices by introducing a dummy
container scan handler in this patch.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/Makefile| 2 +-
drivers/acpi/container.c | 21 +
drivers/acpi/internal.h | 4
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9a43893..5611a07 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -63,7 +63,7 @@ obj-$(CONFIG_ACPI_FAN)+= fan.o
obj-$(CONFIG_ACPI_VIDEO) += video.o
obj-$(CONFIG_ACPI_PCI_SLOT)+= pci_slot.o
obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
-obj-$(CONFIG_ACPI_CONTAINER) += container.o
+obj-y += container.o
obj-$(CONFIG_ACPI_THERMAL) += thermal.o
obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
obj-$(CONFIG_ACPI_BATTERY) += battery.o
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 63119d0..9100db7 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -41,6 +41,8 @@ static const struct acpi_device_id container_device_ids[] = {
{, 0},
};
+#ifdef CONFIG_ACPI_CONTAINER
+
static int acpi_container_offline(struct container_dev *cdev)
{
struct acpi_device *adev = ACPI_COMPANION(cdev-dev);
@@ -111,3 +113,22 @@ void __init acpi_container_init(void)
{
acpi_scan_add_handler_with_hotplug(container_handler, container);
}
+
+#else
+
+static inline int container_device_attach(struct acpi_device *adev,
+ const struct acpi_device_id *not_used)
+{
+ return 1;
+}
+
+static struct acpi_scan_handler container_handler = {
+ .ids = container_device_ids,
+ .attach = container_device_attach,
+};
+
+void __init acpi_container_init(void)
+{
+ acpi_scan_add_handler(container_handler);
+}
+#endif /* CONFIG_ACPI_CONTAINER */
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 3a12866..499908e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -32,11 +32,7 @@ void acpi_processor_init(void);
void acpi_platform_init(void);
void acpi_pnp_init(void);
int acpi_sysfs_init(void);
-#ifdef CONFIG_ACPI_CONTAINER
void acpi_container_init(void);
-#else
-static inline void acpi_container_init(void) {}
-#endif
#ifdef CONFIG_ACPI_DOCK
void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
--
1.8.3.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 1/6] phy: add a driver for the Berlin SATA PHY
Hi,
On Thursday 15 May 2014 12:12 AM, Sebastian Hesselbarth wrote:
On 05/14/2014 08:12 PM, Arnd Bergmann wrote:
On Wednesday 14 May 2014 19:57:46 Sebastian Hesselbarth wrote:
On 05/14/2014 06:57 PM, Antoine Ténart wrote:
On Wed, May 14, 2014 at 06:11:24PM +0200, Arnd Bergmann wrote:
On Wednesday 14 May 2014 17:49:29 Antoine Ténart wrote:
On Wed, May 14, 2014 at 05:31:24PM +0200, Arnd Bergmann wrote:
From what I understand from the conversation, we have a single PHY
register set dealing with both SATA ports available on the SoC.
Also, from the name of the PHY bits we assume the PHY may be able
to work in different modes than just SATA. And we currently have
an AHCI-compatible SATA IP that supports up to two ports, with one
actually connected to a SATA plug on the DMP board.
Now, thinking about the PHY binding and the (possible) multi-protocol
support, it can be possible that on BG2Q there is a generic 2-lane
LVDS PHY that can be configured to support SATA or PCIe. Both are
electrically and bit-level compatible, so they could be internally
wired-up with AHCI and PCIe controller.
Sounds like a reasonable guess. We have other PHY drivers doing the
same thing already.
Well, I based that on what I know about FPGA LVDS transceivers, so
I wasn't guessing out of the blue ;)
From a DT point-of-view, we need a way to (a) link each SATA or PCIe
port to the PHY, (b) specify the PHY lane to be used, and (c) specify
the protocol to be used on that lane. If I got it right, Arnd already
mentioned to use the phy-specifier to deal with it:
e.g. phy = genphy 0 MODE_SATA or phy = genphy 1 MODE_PCIE
Right.
Let's assume we have one dual-port SATA controller and one PCIe
controller with either x1 or x2 support. The only sane DT binding,
I can think of then would be:
berlin2q.dtsi:
genphy: lvds@ea00ff {
compatible = marvell,berlin-lvds-phy;
reg = 0xea00ff 0x100;
#phy-cells = 2;
};
sata: sata@ab00ff {
compatible = ahci-platform;
reg = 0xab00ff 0x100;
sata0: sata-port@0 {
reg = 0;
phy = genphy 0 MODE_SATA;
status = disabled;
};
sata1: sata-port@1 {
reg = 1;
phy = genphy 1 MODE_SATA;
status = disabled;
};
};
pcie: pcie@ab01ff {
compatible = marvell,berlin-pcie;
reg = 0xab01ff 0x100;
pcie0: pcie-port@0 {
reg = 0;
/* set phy on a per-board basis */
/* PCIe x1 on Lane 0 : phy = genphy 0 MODE_PCIE; */
/* PCIe x2 on Lane 0 and 1 : phy = genphy 0 MODE_PCIE,
genphy 1
MODE_PCIE; */
status = disabled;
};
};
berlin2q-dmp.dts:
sata1 {
status = okay;
};
pcie0 {
phy = genphy 1 MODE_PCIE;
};
berlin2q-foo.dts:
pcie0 {
phy = genphy 0 MODE_PCIE, genphy 1 MODE_PCIE;
};
Exactly. I would also be fine with keeping the sub-nodes of the
phy device as in v3 and using #phy-cells=1 instead of #phy-cells.
The result would be pretty much the same, it just depends on how
closely connected the two logical phys are.
huh.. even with sub-nodes you'll need #phy-cells=2 if we use a single *PHY
PROVIDER*. Because with just PHYs node pointer we won't be able to get the PHY.
We'll need PHY providers node pointer.
However I'd prefer to have sub-nodes for each individual PHYs and register a
single PHY PROVIDER.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 V6 06/11] ACPI: introduce dummy memory hotplug scan handler
The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
created for them even if the scan handler is compiled out.
Fix this problem for memory hotplug devuces by introducing a dummy
memory hotplug scan handler in this patch.
Plus, the dummy memory hotplug scan handler is also needed when
kernel parameter acpi_no_memhotplug is used.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/Makefile | 2 +-
drivers/acpi/acpi_memhotplug.c | 45 ++
drivers/acpi/internal.h| 6 +-
3 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5611a07..171efc2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -65,7 +65,7 @@ obj-$(CONFIG_ACPI_PCI_SLOT) += pci_slot.o
obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
obj-y += container.o
obj-$(CONFIG_ACPI_THERMAL) += thermal.o
-obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
+obj-y += acpi_memhotplug.o
obj-$(CONFIG_ACPI_BATTERY) += battery.o
obj-$(CONFIG_ACPI_SBS) += sbshc.o
obj-$(CONFIG_ACPI_SBS) += sbs.o
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b67be85..ed2f6a7 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -44,6 +44,13 @@
ACPI_MODULE_NAME(acpi_memhotplug);
+static const struct acpi_device_id memory_device_ids[] = {
+ {ACPI_MEMORY_DEVICE_HID, 0},
+ {, 0},
+};
+
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+
/* Memory Device States */
#define MEMORY_INVALID_STATE 0
#define MEMORY_POWER_ON_STATE 1
@@ -53,11 +60,6 @@ static int acpi_memory_device_add(struct acpi_device *device,
const struct acpi_device_id *not_used);
static void acpi_memory_device_remove(struct acpi_device *device);
-static const struct acpi_device_id memory_device_ids[] = {
- {ACPI_MEMORY_DEVICE_HID, 0},
- {, 0},
-};
-
static struct acpi_scan_handler memory_device_handler = {
.ids = memory_device_ids,
.attach = acpi_memory_device_add,
@@ -362,17 +364,34 @@ static void acpi_memory_device_remove(struct acpi_device
*device)
static bool __initdata acpi_no_memhotplug;
-void __init acpi_memory_hotplug_init(void)
-{
- if (acpi_no_memhotplug)
- return;
-
- acpi_scan_add_handler_with_hotplug(memory_device_handler, memory);
-}
-
static int __init disable_acpi_memory_hotplug(char *str)
{
acpi_no_memhotplug = true;
return 1;
}
__setup(acpi_no_memhotplug, disable_acpi_memory_hotplug);
+
+#endif
+
+static int acpi_memory_dummy_add(struct acpi_device *device,
+const struct acpi_device_id *not_used)
+{
+ return 1;
+}
+
+static struct acpi_scan_handler memory_dummy_handler = {
+ .ids = memory_device_ids,
+ .attach = acpi_memory_dummy_add,
+};
+
+void __init acpi_memory_hotplug_init(void)
+{
+#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
+ if (!acpi_no_memhotplug) {
+ acpi_scan_add_handler_with_hotplug(memory_device_handler,
+ memory);
+ return;
+ }
+#endif
+ acpi_scan_add_handler(memory_dummy_handler);
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 499908e..4a9e999 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -33,6 +33,7 @@ void acpi_platform_init(void);
void acpi_pnp_init(void);
int acpi_sysfs_init(void);
void acpi_container_init(void);
+void acpi_memory_hotplug_init(void);
#ifdef CONFIG_ACPI_DOCK
void register_dock_dependent_device(struct acpi_device *adev,
acpi_handle dshandle);
@@ -44,11 +45,6 @@ static inline void register_dock_dependent_device(struct
acpi_device *adev,
static inline int dock_notify(struct acpi_device *adev, u32 event) { return
-ENODEV; }
static inline void acpi_dock_add(struct acpi_device *adev) {}
#endif
-#ifdef CONFIG_ACPI_HOTPLUG_MEMORY
-void acpi_memory_hotplug_init(void);
-#else
-static inline void acpi_memory_hotplug_init(void) {}
-#endif
#ifdef CONFIG_X86
void acpi_cmos_rtc_init(void);
#else
--
1.8.3.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/
[PATCH V6 10/11] ACPI: use platform bus as the default bus for _HID enumeration
Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. will not be enumerated by its parent.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/acpi_platform.c | 28
drivers/acpi/scan.c | 25 -
2 files changed, 24 insertions(+), 29 deletions(-)
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index dbfe49e..33376a9 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -22,24 +22,6 @@
ACPI_MODULE_NAME(platform);
-/*
- * The following ACPI IDs are known to be suitable for representing as
- * platform devices.
- */
-static const struct acpi_device_id acpi_platform_device_ids[] = {
-
- { PNP0D40 },
- { ACPI0003 },
- { VPC2004 },
- { BCM4752 },
-
- /* Intel Smart Sound Technology */
- { INT33C8 },
- { 80860F28 },
-
- { }
-};
-
/**
* acpi_create_platform_device - Create platform device for ACPI device node
* @adev: ACPI device node to create a platform device for.
@@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
kfree(resources);
return 1;
}
-
-static struct acpi_scan_handler platform_handler = {
- .ids = acpi_platform_device_ids,
- .attach = acpi_create_platform_device,
-};
-
-void __init acpi_platform_init(void)
-{
- acpi_scan_add_handler(platform_handler);
-}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 451e7d9..756977e 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2073,6 +2073,27 @@ static acpi_status acpi_bus_check_add(acpi_handle
handle, u32 lvl_not_used,
return AE_OK;
}
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+ /*
+* Do not do enumeration for device object that has been/will be
+* enumerated by its parent.
+*/
+ if (device-parent device-parent-flags.is_master_device)
+ return;
+
+ /* Do not do enumeration for device object with scan handler attached */
+ if (device-handler)
+ return;
+
+ /* Do not do enumeration for device object w/o platform_id */
+ if (!device-pnp.type.platform_id)
+ return;
+
+ acpi_create_platform_device(device, NULL);
+}
+
+
static int acpi_scan_attach_handler(struct acpi_device *device)
{
struct acpi_hardware_id *hwid;
@@ -2094,6 +2115,9 @@ static int acpi_scan_attach_handler(struct acpi_device
*device)
break;
}
}
+
+ acpi_do_default_enumeration(device);
+
return ret;
}
@@ -2253,7 +2277,6 @@ int __init acpi_scan_init(void)
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
- acpi_platform_init();
acpi_lpss_init();
acpi_cmos_rtc_init();
acpi_container_init();
--
1.8.3.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 2/2] rtmutex: Avoid pointless requeueing in the deadlock detection chain walk
A couple of suggestions:
1)
* Thomas Gleixner t...@linutronix.de wrote:
+ if (requeue) {
+ if (waiter == rt_mutex_top_waiter(lock)) {
So we have a 'top_waiter' local variable already at this point, and we
use it here:
+ /* Boost the owner */
+ rt_mutex_dequeue_pi(task, top_waiter);
+ rt_mutex_enqueue_pi(task, waiter);
+ __rt_mutex_adjust_prio(task);
+
+ } else if (top_waiter == waiter) {
To me it's a bit confusing that we have both the 'top_waiter' local
variable and also evaluate 'rt_mutex_top_waiter()' directly.
So what happens is that when we do the requeue, the top waiter might
change. I'd really suggest to signal that via naming - i.e. add
another local variable (which GCC will optimize out happily), named
descriptively:
orig_top_waiter = top_waiter;
and use that variable after that point.
+ /* Deboost the owner */
+ rt_mutex_dequeue_pi(task, waiter);
+ waiter = rt_mutex_top_waiter(lock);
+ rt_mutex_enqueue_pi(task, waiter);
+ __rt_mutex_adjust_prio(task);
+ }
}
2)
Also another small flow of control side comment, because this code is
apparently rather tricky, I'd suggest a bit more explicit structure to
show the real flow of the logic: for example in the first reading of
the above block I mistakenly read it as a usual 'if () { } else { }'
block pattern - which it really isn't.
Something like this would be slightly easier to understand 'at a
glance', IMHO:
if (requeue) {
if (waiter == top_waiter) {
/* Boost the owner */
rt_mutex_dequeue_pi(task, orig_top_waiter);
rt_mutex_enqueue_pi(task, waiter);
__rt_mutex_adjust_prio(task);
} else {
if (orig_top_waiter == waiter) {
/* Deboost the owner */
rt_mutex_dequeue_pi(task, waiter);
waiter = rt_mutex_top_waiter(lock);
rt_mutex_enqueue_pi(task, waiter);
__rt_mutex_adjust_prio(task);
} else {
/* The requeueing did not affect us, no need to
boost or deboost */
}
}
}
Assuming you agree with this structure, it's a bit more verbose, but
this might be one of the cases where verbosity helps readability.
(Note that I already propagated the 'orig_top_waiter' name into it.)
3)
Also note how the code continues:
raw_spin_unlock_irqrestore(task-pi_lock, flags);
top_waiter = rt_mutex_top_waiter(lock);
raw_spin_unlock(lock-wait_lock);
if (!detect_deadlock waiter != top_waiter)
goto out_put_task;
goto again;
So we evaluate 'top_waiter' again - maybe we could move that line to
the two branches that actually have a chance to change the top waiter,
and not change it in the 'no need to requeue' case.
So ... all in one, what I would suggest is something like the patch
below, on top of your two patches. Totally untested and such.
Thanks,
Ingo
===
Subject: locking/rtmutex: Clean up the rt_mutex_adjust_prio_chain() code flow
From: Ingo Molnar mi...@kernel.org
Date: Thu May 15 08:39:42 CEST 2014
Clean up the code flow and variable names, always precisely
maintaining the 'top_waiter' and 'orig_top_waiter' values whenever
they can change.
This probably optimizes the !requeue case a bit as well.
Signed-off-by: Ingo Molnar mi...@kernel.org
---
kernel/locking/rtmutex.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
Index: tip/kernel/locking/rtmutex.c
===
--- tip.orig/kernel/locking/rtmutex.c
+++ tip/kernel/locking/rtmutex.c
@@ -284,7 +284,7 @@ static int rt_mutex_adjust_prio_chain(st
struct rt_mutex_waiter *orig_waiter,
struct task_struct *top_task)
{
- struct rt_mutex_waiter *waiter, *top_waiter = orig_waiter;
+ struct rt_mutex_waiter *waiter, *top_waiter = orig_waiter,
*orig_top_waiter;
int detect_deadlock, ret = 0, depth = 0;
struct rt_mutex *lock;
unsigned long flags;
@@ -380,13 +380,17 @@ static int rt_mutex_adjust_prio_chain(st
goto out_unlock_pi;
}
- top_waiter = rt_mutex_top_waiter(lock);
-
if (requeue) {
+ orig_top_waiter = rt_mutex_top_waiter(lock);
+
/* Requeue the waiter */
rt_mutex_dequeue(lock, waiter);
waiter-prio = task-prio;
linux-next: build warning after merge of the net-next tree
Hi all, After merging the net-next tree, today's linux-next build (powerpc allnoconfig) produced this warning: include/net/ip.h:211:5: warning: CONFIG_SYSCTL is not defined [-Wundef] #if CONFIG_SYSCTL ^ Introduced by commit 122ff243f5f1 (ipv4: make ip_local_reserved_ports per netns). -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
[PATCH V6 03/11] ACPI: remove ids that does not comply with the ACPI PNP id rule
The acpi pnp scan handler id list just copies all the ids from all the
struct pnp_device_id instances, but some of them do not
comply with the ACPI PNP id rule (3 Alpha Charactors + 4 Hex numbers).
For those ids, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove those ids from the PNPACPI white list.
Signed-off-by: Zhang Rui rui.zh...@intel.com
---
drivers/acpi/acpi_pnp.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
index 57d14ed..d206616 100644
--- a/drivers/acpi/acpi_pnp.c
+++ b/drivers/acpi/acpi_pnp.c
@@ -33,10 +33,6 @@ static const struct acpi_device_id acpi_pnp_device_ids[] = {
/* ide */
{PNP0600},/* Generic ESDI/IDE/ATA compatible hard disk
controller */
/* ns558 */
- {@P@0001},/* ALS 100 */
- {@P@0020},/* ALS 200 */
- {@P@1001},/* ALS 100+ */
- {@P@2001},/* ALS 120 */
{ASB16fd},/* AdLib NSC16 */
{AZT3001},/* AZT1008 */
{CDC0001},/* Opl3-SAx */
--
1.8.3.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 RESEND] Documentation: clock: fixed-clock: Remove unsupported 'gpios' property
Quoting Fabio Estevam (2014-05-08 20:01:50) From: Fabio Estevam fabio.este...@freescale.com Remove the 'gpios' property from the documentation as this is something that the current fixed clock driver does not handle. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Good catch. Taken into clk-next. Regards, Mike --- Documentation/devicetree/bindings/clock/fixed-clock.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt b/Documentation/devicetree/bindings/clock/fixed-clock.txt index 48ea0ad..0641a663 100644 --- a/Documentation/devicetree/bindings/clock/fixed-clock.txt +++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt @@ -12,7 +12,6 @@ Required properties: Optional properties: - clock-accuracy : accuracy of clock in ppb (parts per billion). Should be a single cell. -- gpios : From common gpio binding; gpio connection to clock enable pin. - clock-output-names : From common clock binding. Example: -- 1.8.3.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/
[PATCH V6 00/11] ACPI: ACPI enumeration rework
Hi, all, Currently, PNP bus is used as the default bus for for enumerating ACPI devices with _HID/_CID. For a device that needs to be enumerated to platform bus, we need to add its id string to the platform scan handler white list explicitly. This becomes a problem as more and more _HID devices need to be enumerated to platform bus nowadays, thus the list is continuously growing. So, a solution that uses platform bus for _HID enumeration by default is preferred. In order to do this, this patch set First (Patch 1~4), changes the way of enumerating PNP devices. We introduce a white list to create PNP devices instead. The white list contains all the pnp_device_id strings in all the pnp drivers, thus this change is transparent to PNP core and all the PNP drivers. Second (Patch 5~11), changes the code to enumerate ACPI _HID devices to platform bus by default. Tis patch set has been tested on my desktop machine, and a TOSHIBA PORTEGE Z830 ultrabook. Clarification: Although it seems that we are introducing a much bigger white list to replace a small one, the benefit is that 1. without the patch, the acpi_platform scan handler white list is continuously growing. 2. with the patch set, the PNPACPI scan handler white list will become smaller and smaller by a) remove the ids from the PNPACPI white list, for the devices that are never enumerated via ACPI b) remove the ids from the PNPACPI whilte list and convert the drivers to platform bus drivers, for the devices that are not PNP devices in nature. which will be done later. Known Issue: PNP bus does not check the device resources when adding a new PNP device, while Platform bus does by invoking insert_resource() in platform_device_add(). This results in failure when creating platform device node for some ACPI device objects in case there is resource conflict. In my desktop, I can see that Creating PNP0C02:02 fails because its resource (IO: 0x72 ~ 0x7f) conflicts with 0070-0077 : PNP0B00:00 (CMOS RTC). Known Issue: Currently, we can't enumerate devices with _CID PNP0C01/PNP0C02 to platform bus because we need them in PNP bus in order to reserve mother board resources. thanks, rui Changes in V6: 1. Patch re-ordering to avoid bisect breakage. 2. rework the patch for fixing the redudent platform devices created for lpss slaves issue according to Rafael' comments. Changes in V5: 1. fix a problem that ACPI tries to enumerate lpss slaves to platform bus 2. rebased on 3.14 kernel Changes in V4: 1. coding style cleanups, fix checkpatch warnings/errors. Changes in V3: 1. rename enumerable_id to platform_id according to Rafael' suggestion. 2. drop two patches to handle devices with _CID PNP0C01/PNP0C02 enumeration because the code in drivers/pnp/system.c is still under discussion. 3. make cmos rtc scan handler return 1 so that the device will not be enumerated to platform bus. Changes in V2: 1.move acpi pnp scan handler from drivers/pnp/pnpacpi/core.c to drivers/acpi/acpi-pnp.c, because the scan handler needs to be always built in to prevent platform devices from being created for those ACPI devices. 2.remove the __init tag for the acpi pnp scan handler because the scan handler is still needed after system initialization, for hotplug. 3.introduce enumerable_id flag for devices that can be enumerated to platform bus. 4.introduce excluded id list for creating platform devices, because some devices have _HID but they will never be associated with a platform driver. 5.introduce dummy lpss/container/memory_hotplug scan handler to prevent platform devices from being created for those ACPI device objects. Zhang Rui (11): ACPI: introduce .match() callback for ACPI scan handler PNPACPI: use whilte list for pnpacpi device enumeration ACPI: remove ids that does not comply with the ACPI PNP id rule ACPI: remove unsupported serial PNP ids from acpi pnp scan handler id lsit ACPI: introduce dummy container scan handler ACPI: introduce dummy memory hotplug scan handler ACPI: introduce dummy lpss scan handler ACPI: introduce platform_id flag ACPI: introduce flag .is_master_device ACPI: use platform bus as the default bus for _HID enumeration ACPI: introduce acpi platform exclude id list drivers/acpi/Makefile | 7 ++-- drivers/acpi/acpi_cmos_rtc.c | 2 +- drivers/acpi/acpi_lpss.c | 93 - drivers/acpi/acpi_memhotplug.c | 45 ++-- drivers/acpi/acpi_platform.c | 39 ++--- drivers/acpi/acpi_pnp.c| 382 ++ drivers/acpi/container.c | 21 ++ drivers/acpi/internal.h
linux-next: build warning after merge of the fsl tree
Hi Scott, After merging the fsl tree, today's linux-next build (powerpc allyesconfig) produced this warning: arch/powerpc/kernel/epapr_paravirt.c:33:13: warning: 'epapr_has_idle' defined but not used [-Wunused-variable] static bool epapr_has_idle; ^ Introduced by commit f9eb581c63b2 (powerpc: fix build of epapr_paravirt on 64-bit book3s). -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH 2/8] clk: berlin: add clock binding docs for Marvell Berlin2 SoCs
On 05/15/2014 06:41 AM, Mike Turquette wrote:
Quoting Sebastian Hesselbarth (2014-05-14 16:17:52)
On 05/15/2014 12:32 AM, Mike Turquette wrote:
Quoting Sebastian Hesselbarth (2014-05-11 13:24:35)
+avpll: pll@ea0040 {
+ compatible = marvell,berlin2-avpll;
+ #clock-cells = 2;
+ reg = 0xea0050 0x100;
+ clocks = refclk;
+};
Thanks for submitting the series. It looks good. I do have some comments
about the DT bindings though. I'm encouraging new bindings (and
especially new platforms or existing platforms that are only now
converting over to CCF) to not put their per-clock data into DTS. This
has scalability problems, is unpopular with the DT crowd and sometimes
makes it hard to do things like set CLK_SET_RATE_PARENT flags for
individual clocks.
Ok, so you are proposing the have a single node for all the SoCs
internal plls and clocks. The individual SoCs will have to deal
with the differences in a single driver, right?
To be precise, I'm talking about modeling an IP block as a single node.
So if you have one clock generator IP block then you have one node. If
you have more than one clock generator block then you have more than one
node. Re-using the qcom example there are compatible strings for two
different clock generator blocks named gcc and mmcc, respectively. So
two DT nodes in the case for msm platforms that have one gcc instance
and one rcg instance.
Hmm, I'd argue that you'd identify an IP block by the price tag is
carries. You can buy a single PLL but given the vast amount of different
register sets for PLLs, it is hard to identify what still count for the
same IP.
Additionally other IP blocks may have internal clocks that can be
modeled as part of that node. OMAP's Display SubSystem (DSS) and Image
Signal Processor (ISP) blocks all have internal clocks that are modeled
through the clock framework. (There are no DT bindings for that stuff,
but the concept still applies)
Agreed. If we hit any clock mux/divider/gate in any other register set,
I wouldn't think of putting it into the core clock driver but the IP
driver instead.
If you have a strong reason to do it the way that you originally posted
then let me know.
Actually, the intermediate patch set sent before this one had a single
DT clock node. The most important draw-back of a single clock node
is that Berlin's global registers are more like a register dumpster.
Vital other registers, e.g. reset, are intermixed with clock registers.
Yeah, this is pretty common. The compatible string should reflect the IP
block as a whole, not just the clocks part of it. Lots of vendors have
PRCMs or PRCMUs or CARs or whatever.
Check out the recent series to have the reset bits and regulator support
added to the qcom binding[1]. (I'm using qcom quite a bit in my examples
but they are not the first to add reset control to their clock driver. I
think Tegra did it first...)
Yeah, I have to think about it a while. The register block we are
talking about contains - from what I remember from the ~20k lines
include - pinctrl, padctrl, reset, clocks, secondary cpu boot related
registers.
Maybe it is time to admit that these registers will never be split into
separate blocks but should be dealt with a single node.
Given the lack of public datasheets (I look everything up in some
auto-generated BSP includes), I like the current approach because it
helps to get in at least some structure to the register mess ;)
Considering the postponed of_clk_create_name() helper, that would allow
us to remove at least the names from DT again. Another option would be
a syscon node for the registers, that clk, reset, pinctrl drivers can
access. But IIRC early syscon support isn't settled, yet?
Yeah, I'm not sure of the state of syscon. And modeling this stuff in
the clock driver isn't the end of the world. There might be better
places than drivers/clk/* for sure... I sometimes joke that the name of
the IP block determines where the code lands. If it is Power, Reset
Clock Manager (several platforms use this acronym) then it can end up in
drivers/clk or drivers/reset really easily. Same for Clock and Reset IP
blocks (Tegra).
So, my current idea is:
- take this as is, stabilize berlin branches for v3.16
- review of_clk_create_name() and of_clk_get_parent_name() to allow
to remove clock-output-names properties from Berlin (and other) dtsis
- maybe switch to early syscon if it is available in v3.16
I know this would likely break DT ABI policy, but hey who else boots
mainline Linux on his Chromecast currently except me :P
I'm not a big fan of DT stable ABI, but if you plan on changing it for
3.17 why not just do it the right way the first time? And switching to
syscon is not a hard requirement. I'm OK with you putting the reset and
regulator stuff in the clock driver if that makes the most sense for
your platform (especially if registers are shared and the same locks
need to be
Re: [PATCH v4 2/2] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU
On 05/13/2014 09:27 PM, Frederic Weisbecker wrote:
On Tue, May 13, 2014 at 02:32:00PM +0530, Srivatsa S. Bhat wrote:
kernel/stop_machine.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 01fbae5..288f7fe 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -130,8 +130,10 @@ enum multi_stop_state {
MULTI_STOP_NONE,
/* Awaiting everyone to be scheduled. */
MULTI_STOP_PREPARE,
-/* Disable interrupts. */
-MULTI_STOP_DISABLE_IRQ,
+/* Disable interrupts on CPUs not in -active_cpus mask. */
+MULTI_STOP_DISABLE_IRQ_INACTIVE,
+/* Disable interrupts on CPUs in -active_cpus mask. */
+MULTI_STOP_DISABLE_IRQ_ACTIVE,
/* Run the function */
MULTI_STOP_RUN,
/* Exit */
@@ -189,12 +191,39 @@ static int multi_cpu_stop(void *data)
do {
/* Chill out and ensure we re-read multi_stop_state. */
cpu_relax();
+
+/*
+ * We use 2 separate stages to disable interrupts, namely
+ * _INACTIVE and _ACTIVE, to ensure that the inactive CPUs
+ * disable their interrupts first, followed by the active CPUs.
+ *
+ * This is done to avoid a race in the CPU offline path, which
+ * can lead to receiving IPIs on the outgoing CPU *after* it
+ * has gone offline.
+ *
+ * During CPU offline, we don't want the other CPUs to send
+ * IPIs to the active_cpu (the outgoing CPU) *after* it has
+ * disabled interrupts (because, then it will notice the IPIs
+ * only after it has gone offline). We can prevent this by
+ * making the other CPUs disable their interrupts first - that
+ * way, they will run the stop-machine code with interrupts
+ * disabled, and hence won't send IPIs after that point.
+ */
+
if (msdata-state != curstate) {
curstate = msdata-state;
switch (curstate) {
-case MULTI_STOP_DISABLE_IRQ:
-local_irq_disable();
-hard_irq_disable();
+case MULTI_STOP_DISABLE_IRQ_INACTIVE:
+if (!is_active) {
+local_irq_disable();
+hard_irq_disable();
+}
+break;
+case MULTI_STOP_DISABLE_IRQ_ACTIVE:
+if (is_active) {
+local_irq_disable();
+hard_irq_disable();
I have no idea about possible IPI latencies due to hardware. But are we sure
that a stop
machine transition state is enough to make sure we get a pending IPI?
Shouldn't we have
some sort of IPI flush in between, like polling on call_single_queue?
That might not be actually required, but the concept of flushing out
all pending work before going offline (irrespective of whether the
outgoing CPU got the corresponding IPIs in time or not) sounds like
a good idea, because we can guarantee that any late IPIs landing on
the CPU (and thus generating the warning) will be completely harmless.
We can empty the call_single_queue after disabling interrupts in
the _ACTIVE stage. That way, we can guarantee that all pending IPI
functions have been executed by the outgoing CPU (even if the
corresponding IPIs come a bit later). Also, no new IPI work can be
assigned to that CPU beyond the _INACTIVE stage.
Thanks for the suggestion, Frederic!
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/2] virtio-rng: reinstate const to struct hwrng.name
This was removed by commit 08e53fbdb85c (virtio-rng: support multiple
virtio-rng devices) in the virtio tree and can now be restored.
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
include/linux/hw_random.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index 02d9c87be54c..b4b0eef5fddf 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -31,7 +31,7 @@
* @priv: Private data, for use by the RNG driver.
*/
struct hwrng {
- char *name;
+ const char *name;
int (*init)(struct hwrng *rng);
void (*cleanup)(struct hwrng *rng);
int (*data_present)(struct hwrng *rng, int wait);
--
2.0.0.rc2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH v3 1/6] phy: add a driver for the Berlin SATA PHY
On 05/15/2014 08:45 AM, Kishon Vijay Abraham I wrote:
On Thursday 15 May 2014 12:12 AM, Sebastian Hesselbarth wrote:
On 05/14/2014 08:12 PM, Arnd Bergmann wrote:
On Wednesday 14 May 2014 19:57:46 Sebastian Hesselbarth wrote:
On 05/14/2014 06:57 PM, Antoine Ténart wrote:
On Wed, May 14, 2014 at 06:11:24PM +0200, Arnd Bergmann wrote:
On Wednesday 14 May 2014 17:49:29 Antoine Ténart wrote:
On Wed, May 14, 2014 at 05:31:24PM +0200, Arnd Bergmann wrote:
[...]
Now, thinking about the PHY binding and the (possible) multi-protocol
support, it can be possible that on BG2Q there is a generic 2-lane
LVDS PHY that can be configured to support SATA or PCIe. Both are
electrically and bit-level compatible, so they could be internally
wired-up with AHCI and PCIe controller.
Sounds like a reasonable guess. We have other PHY drivers doing the
same thing already.
[...]
From a DT point-of-view, we need a way to (a) link each SATA or PCIe
port to the PHY, (b) specify the PHY lane to be used, and (c) specify
the protocol to be used on that lane. If I got it right, Arnd already
mentioned to use the phy-specifier to deal with it:
e.g. phy = genphy 0 MODE_SATA or phy = genphy 1 MODE_PCIE
Right.
Let's assume we have one dual-port SATA controller and one PCIe
controller with either x1 or x2 support. The only sane DT binding,
I can think of then would be:
berlin2q.dtsi:
genphy: lvds@ea00ff {
compatible = marvell,berlin-lvds-phy;
reg = 0xea00ff 0x100;
#phy-cells = 2;
};
sata: sata@ab00ff {
compatible = ahci-platform;
reg = 0xab00ff 0x100;
sata0: sata-port@0 {
reg = 0;
phy = genphy 0 MODE_SATA;
status = disabled;
};
sata1: sata-port@1 {
reg = 1;
phy = genphy 1 MODE_SATA;
status = disabled;
};
};
pcie: pcie@ab01ff {
compatible = marvell,berlin-pcie;
reg = 0xab01ff 0x100;
pcie0: pcie-port@0 {
reg = 0;
/* set phy on a per-board basis */
/* PCIe x1 on Lane 0 : phy = genphy 0 MODE_PCIE; */
/* PCIe x2 on Lane 0 and 1 : phy = genphy 0 MODE_PCIE,
genphy 1
MODE_PCIE; */
status = disabled;
};
};
berlin2q-dmp.dts:
sata1 {
status = okay;
};
pcie0 {
phy = genphy 1 MODE_PCIE;
};
berlin2q-foo.dts:
pcie0 {
phy = genphy 0 MODE_PCIE, genphy 1 MODE_PCIE;
};
Exactly. I would also be fine with keeping the sub-nodes of the
phy device as in v3 and using #phy-cells=1 instead of #phy-cells.
The result would be pretty much the same, it just depends on how
closely connected the two logical phys are.
huh.. even with sub-nodes you'll need #phy-cells=2 if we use a single *PHY
PROVIDER*. Because with just PHYs node pointer we won't be able to get the
PHY.
We'll need PHY providers node pointer.
However I'd prefer to have sub-nodes for each individual PHYs and register a
single PHY PROVIDER.
Depends on what you call PHY. In the example above the PHY is what
allows you to control both lanes.
So you want sub-nodes for each individual lane given the nomenclature
of the example?
Or like it is used in the example above, a single PHY node with an index
in the phy-specifier to pick an individual lane.
IMHO, having both phy-specifier index _and_ PHY sub-node per lane
has no benefit at all. You cannot even use the PHY sub-nodes for any
setup properties, as they depend on the consumer claiming the lane.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, hugetlb: add missing TLB page invalidation for hugetlb_cow()
On 05/15/2014 08:00 PM, Anthony Iliopoulos wrote: I have dismissed this case, since I assume that there are many more cycles spent in servicing the TLB invalidation IPI, walking the pgtable plus other related overhead (e.g. sched) than in updating the pte/pmd so I am not sure how possible it would be to hit this condition. Hi Anthony, I have a question about the above statement. What will happen with multi cpu VMs ? won't the race described above can happen ? I.e one virtual CPU can will visit the host and the other will continue to encounter your race ? Thanks, Oren. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/8] OF: Introduce DT overlay support.
Hi Grant, On May 14, 2014, at 3:08 AM, Grant Likely wrote: On Fri, 4 Apr 2014 15:43:55 +0300, Pantelis Antoniou pantelis.anton...@konsulko.com wrote: Introduce DT overlay support. Using this functionality it is possible to dynamically overlay a part of the kernel's tree with another tree that's been dynamically loaded. It is also possible to remove node and properties. The creation/destruction of the devices is handled by calling in to bus specific handlers which can deal with the peculiarities of each device. Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com Hi Panto, I spent a bunch of time yesterday going over this code and I have some comments and questions. First off I must apologize. I think I completely misunderstood the approach you are taking for putting the overlay data into the tree. I had assumed that you were unflattening the overlay tree and then rearranging the new device_nodes to insert them into the existing tree, but it looks like you're leaving the overlay tree alone and merely using it's nodes as templates when allocating new nodes that will get inserted into the tree. Sorry for being confused on this. A few of my opinions have probably changed now that I understand what you're trying to do. No worries. It is a complicated subject after all. Let me reply with what we discussed on IRC, so it's recorded for posterity. As I've said before, this is a complicated bit of code that touches into the core of device tree behaviour, so I am being cautious. This patch and the previous patch add a lot of functionality that is hard to review all at once, and it conflates some concepts that I would like to be very well defined. For example, this patch adds at least 3 distinct features: - Revertable batch modifications to the live tree. - New notification infrastructure for informing other code when changes take place - Parsing a tree in the overlay format to create an of_overlay_info array. The revertable batch feature should be a patch all on its own without any of the change tracking or notification aside from what the core code is already doing. That change could be applied independently even if I still have issues with the notification or parsing code. I would even split up the first feature into two steps: batch modifications to the tree, and then adding the logging feature so a batch modification can be reverted. OK. The notification infrastructure bothers me. It duplicates the notification that the core DT code already performs. I do understand that the current notifications don't do what you need them to because you need it all deferred until the complete set of batch changes are applied. However, instead of creating a new infrastructure, the existing notifier should be reworked to be batch-change aware. If I understood correctly, you're asking of rolling in this per-bus notifier mechanism in the standard DT notifier infrastructure already in place. I can't be absolutely sure about the details right now, but seems possible. I don't know if the kernel notifier framework will be unmodified, but I hope so. The parsing function is a specific user of the other two features. It *may* be appropiate to be in a separate module, but it certainly should be in a separate patch. OK More generally I am concerned about whether or not overlays will introduce corner cases that can never be handled correctly, particularly in how multiple overlays will get handled. I want to see very clear rules on what happens when multiple overlays are applied, and then removed again. Is it possible to remove overlays out of order? If so, what are the conditions that would not be allowed? As mentioned by Guenter, a single stack of overlays is no good; we need to support an arbitrary stacking method. One way to implement it would be to add an overlay use counter which we will increase whenever a node is 'touched' by an overlay. Removal is only going to be permitted if the counters of a subtree are all less or equal to 1. The equal to 0 is to account for non-overlay node attachements. I'm also concerned about security. Turning on overlay support opens up basically full access to the hardware of the system. It definitely needs to be accessible only by root, but I think it goes farther than that. When doing changes, there should be a mechanism to restrict which nodes are allowed to be changed. It's hard for me to think of all the security implications. For starters this is obviously for root only (or in-kernel users). We can implement some kind of attribute like 'mutable' that we will use to adorn a subtree that permits overlay application. We also need to think about kexec. Kexec works by sucking the live tree out of the kernel and creating a .dtb from it to pass to the new kernel. What will the rules be when kexecing? Do all the overlays need to be removed, or does the kernel get the tree with all the
[PATCH 0/4] mfd: Intel SoC Power Management IC
Devices based on Intel SoC products such as Baytrail have a Power Management IC. In the PMIC there are subsystems for voltage regulation, A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called Crystal Cove. This series contains common code for these PMICs, and device specific support for Crystal Cove. Lejun Zhu (4): mfd: intel_soc_pmic: Core driver mfd: intel_soc_pmic: I2C interface mfd: intel_soc_pmic: Crystal Cove support mfd: intel_soc_pmic: Build files drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile | 3 + drivers/mfd/intel_soc_pmic_core.c | 543 + drivers/mfd/intel_soc_pmic_core.h | 83 ++ drivers/mfd/intel_soc_pmic_crc.c | 157 +++ drivers/mfd/intel_soc_pmic_i2c.c | 158 +++ include/linux/mfd/intel_soc_pmic.h | 29 ++ 7 files changed, 983 insertions(+) create mode 100644 drivers/mfd/intel_soc_pmic_core.c create mode 100644 drivers/mfd/intel_soc_pmic_core.h create mode 100644 drivers/mfd/intel_soc_pmic_crc.c create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c create mode 100644 include/linux/mfd/intel_soc_pmic.h -- 1.8.3.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/
[PATCH 3/4] mfd: intel_soc_pmic: Crystal Cove support
Crystal Cove is the PMIC in Baytrail-T platform. This patch provides
chip-specific support for Crystal Cove.
Signed-off-by: Yang, Bin bin.y...@intel.com
Signed-off-by: Zhu, Lejun lejun@linux.intel.com
---
drivers/mfd/intel_soc_pmic_crc.c | 157 +++
1 file changed, 157 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_crc.c
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
new file mode 100644
index 000..b16e8a9
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -0,0 +1,157 @@
+/*
+ * intel_soc_pmic_crc.c - Device access for Crystal Cove PMIC
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 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.
+ *
+ * Author: Yang, Bin bin.y...@intel.com
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/mfd/core.h
+#include linux/err.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/acpi.h
+#include linux/version.h
+#include linux/mfd/intel_soc_pmic.h
+#include intel_soc_pmic_core.h
+
+#define CRYSTAL_COVE_IRQ_NUM 7
+
+#define CHIPID 0x00
+#define CHIPVER0x01
+#define IRQLVL10x02
+#define MIRQLVL1 0x0E
+enum {
+ PWRSRC_IRQ = 0,
+ THRM_IRQ,
+ BCU_IRQ,
+ ADC_IRQ,
+ CHGR_IRQ,
+ GPIO_IRQ,
+ VHDMIOCP_IRQ
+};
+
+static struct resource gpio_resources[] = {
+ {
+ .name = GPIO,
+ .start = GPIO_IRQ,
+ .end= GPIO_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource pwrsrc_resources[] = {
+ {
+ .name = PWRSRC,
+ .start = PWRSRC_IRQ,
+ .end = PWRSRC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource adc_resources[] = {
+ {
+ .name = ADC,
+ .start = ADC_IRQ,
+ .end = ADC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct resource thermal_resources[] = {
+ {
+ .name = THERMAL,
+ .start = THRM_IRQ,
+ .end = THRM_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+static struct resource bcu_resources[] = {
+ {
+ .name = BCU,
+ .start = BCU_IRQ,
+ .end = BCU_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+static struct mfd_cell crystal_cove_dev[] = {
+ {
+ .name = crystal_cove_pwrsrc,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(pwrsrc_resources),
+ .resources = pwrsrc_resources,
+ },
+ {
+ .name = crystal_cove_adc,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(adc_resources),
+ .resources = adc_resources,
+ },
+ {
+ .name = crystal_cove_thermal,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(thermal_resources),
+ .resources = thermal_resources,
+ },
+ {
+ .name = crystal_cove_bcu,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(bcu_resources),
+ .resources = bcu_resources,
+ },
+ {
+ .name = crystal_cove_gpio,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(gpio_resources),
+ .resources = gpio_resources,
+ },
+ {NULL, },
+};
+
+#defineCRC_IRQREGMAP_VALUE(irq){ \
+ {MIRQLVL1, irq, 1, 0}, \
+ {IRQLVL1, irq, 1, 0}, \
+ INTEL_PMIC_REG_NULL,\
+ }
+
+struct intel_pmic_irqregmap crystal_cove_irqregmap[] = {
+ [PWRSRC_IRQ]= CRC_IRQREGMAP_VALUE(PWRSRC_IRQ),
+ [THRM_IRQ] = CRC_IRQREGMAP_VALUE(THRM_IRQ),
+ [BCU_IRQ] = CRC_IRQREGMAP_VALUE(BCU_IRQ),
+ [ADC_IRQ] = CRC_IRQREGMAP_VALUE(ADC_IRQ),
+ [CHGR_IRQ] = CRC_IRQREGMAP_VALUE(CHGR_IRQ),
+ [GPIO_IRQ] = CRC_IRQREGMAP_VALUE(GPIO_IRQ),
+ [VHDMIOCP_IRQ] = CRC_IRQREGMAP_VALUE(VHDMIOCP_IRQ),
+};
+
+static int crystal_cove_init(void)
+{
+ pr_debug(Crystal Cove: ID 0x%02X, VERSION 0x%02X\n,
+intel_soc_pmic_readb(CHIPID), intel_soc_pmic_readb(CHIPVER));
+ return 0;
+}
+
+struct intel_soc_pmic crystal_cove_pmic = {
+ .label = crystal cove,
+ .irq_flags = IRQF_TRIGGER_RISING |
[PATCH 1/4] mfd: intel_soc_pmic: Core driver
This patch provides the common code for the intel_soc_pmic MFD driver,
such as read/write register and set up IRQ.
Signed-off-by: Yang, Bin bin.y...@intel.com
Signed-off-by: Zhu, Lejun lejun@linux.intel.com
---
drivers/mfd/intel_soc_pmic_core.c | 543 +
drivers/mfd/intel_soc_pmic_core.h | 83 ++
include/linux/mfd/intel_soc_pmic.h | 29 ++
3 files changed, 655 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_core.c
create mode 100644 drivers/mfd/intel_soc_pmic_core.h
create mode 100644 include/linux/mfd/intel_soc_pmic.h
diff --git a/drivers/mfd/intel_soc_pmic_core.c
b/drivers/mfd/intel_soc_pmic_core.c
new file mode 100644
index 000..bd4e248
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_core.c
@@ -0,0 +1,543 @@
+/*
+ * intel_soc_pmic_core.c - Intel SoC PMIC Core Functions
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 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.
+ *
+ * Author: Yang, Bin bin.y...@intel.com
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/err.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/acpi.h
+#include linux/version.h
+#include linux/gpio.h
+#include linux/mfd/intel_soc_pmic.h
+#include intel_soc_pmic_core.h
+
+struct cell_dev_pdata {
+ struct list_headlist;
+ const char *name;
+ void*data;
+ int len;
+};
+static LIST_HEAD(pdata_list);
+
+static struct intel_soc_pmic *pmic;
+static DEFINE_MUTEX(pmic_lock);/* protecting pmic and its IO access */
+static int cache_offset = -1;
+static int cache_read_val;
+static int cache_write_val;
+static int cache_write_pending;
+static int cache_flags;
+
+struct device *intel_soc_pmic_dev(void)
+{
+ return pmic-dev;
+}
+
+/*
+ * Read from a PMIC register
+ */
+int intel_soc_pmic_readb(int reg)
+{
+ int ret;
+
+ mutex_lock(pmic_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = pmic-readb(reg);
+
+ mutex_unlock(pmic_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_readb);
+
+/*
+ * Write to a PMIC register
+ */
+int intel_soc_pmic_writeb(int reg, u8 val)
+{
+ int ret;
+
+ mutex_lock(pmic_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = pmic-writeb(reg, val);
+
+ mutex_unlock(pmic_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_writeb);
+
+/*
+ * Set 1 bit in a PMIC register
+ */
+int intel_soc_pmic_setb(int reg, u8 mask)
+{
+ int ret;
+ int val;
+
+ mutex_lock(pmic_lock);
+
+ if (!pmic) {
+ ret = -EIO;
+ } else {
+ val = pmic-readb(reg);
+ val |= mask;
+ ret = pmic-writeb(reg, val);
+ }
+
+ mutex_unlock(pmic_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_setb);
+
+/*
+ * Clear 1 bit in a PMIC register
+ */
+int intel_soc_pmic_clearb(int reg, u8 mask)
+{
+ int ret;
+ int val;
+
+ mutex_lock(pmic_lock);
+
+ if (!pmic) {
+ ret = -EIO;
+ } else {
+ val = pmic-readb(reg);
+ val = ~mask;
+ ret = pmic-writeb(reg, val);
+ }
+
+ mutex_unlock(pmic_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_clearb);
+
+/*
+ * Set and clear multiple bits of a PMIC register
+ */
+int intel_soc_pmic_update(int reg, u8 val, u8 mask)
+{
+ int ret;
+
+ mutex_lock(pmic_lock);
+
+ if (!pmic)
+ ret = -EIO;
+ else
+ ret = pmic-readb(reg);
+
+ if (ret 0)
+ goto err;
+
+ val = mask;
+ ret = ~mask;
+ ret |= val;
+ ret = pmic-writeb(reg, ret);
+
+err:
+ mutex_unlock(pmic_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(intel_soc_pmic_update);
+
+/*
+ * Set platform_data of the child devices. Needs to be called before
+ * the MFD device is added.
+ */
+int intel_soc_pmic_set_pdata(const char *name, void *data, int len)
+{
+ struct cell_dev_pdata *pdata;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err(intel_pmic: can't set pdata!\n);
+ return -ENOMEM;
+ }
+
+ pdata-name = name;
+ pdata-data = data;
+ pdata-len = len;
+
+ list_add_tail(pdata-list, pdata_list);
+
+ return 0;
+}
[PATCH 2/4] mfd: intel_soc_pmic: I2C interface
The Intel SoC PMIC devices are connected to the CPU via the I2C
interface. This patch provides support of the related I2C operations.
Signed-off-by: Yang, Bin bin.y...@intel.com
Signed-off-by: Zhu, Lejun lejun@linux.intel.com
---
drivers/mfd/intel_soc_pmic_i2c.c | 158 +++
1 file changed, 158 insertions(+)
create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c
diff --git a/drivers/mfd/intel_soc_pmic_i2c.c b/drivers/mfd/intel_soc_pmic_i2c.c
new file mode 100644
index 000..1d403f0
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_i2c.c
@@ -0,0 +1,158 @@
+/*
+ * intel_soc_pmic_i2c.c - Intel SoC PMIC MFD Driver
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 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.
+ *
+ * Author: Yang, Bin bin.y...@intel.com
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/mfd/core.h
+#include linux/err.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/acpi.h
+#include linux/version.h
+#include linux/gpio/consumer.h
+#include linux/mfd/intel_soc_pmic.h
+#include intel_soc_pmic_core.h
+
+static struct i2c_client *pmic_i2c_client;
+static struct intel_soc_pmic *pmic_i2c;
+
+static int pmic_i2c_readb(int reg)
+{
+ return i2c_smbus_read_byte_data(pmic_i2c_client, reg);
+}
+
+static int pmic_i2c_writeb(int reg, u8 val)
+{
+ return i2c_smbus_write_byte_data(pmic_i2c_client, reg, val);
+}
+
+static void pmic_shutdown(struct i2c_client *client)
+{
+ disable_irq(pmic_i2c_client-irq);
+ return;
+}
+
+static int pmic_suspend(struct device *dev)
+{
+ disable_irq(pmic_i2c_client-irq);
+ return 0;
+}
+
+static int pmic_resume(struct device *dev)
+{
+ enable_irq(pmic_i2c_client-irq);
+ return 0;
+}
+
+static const struct dev_pm_ops pmic_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pmic_suspend, pmic_resume)
+};
+
+static int pmic_i2c_lookup_gpio(struct device *dev, int acpi_index)
+{
+ struct gpio_desc *desc;
+ int gpio;
+
+ desc = gpiod_get_index(dev, KBUILD_MODNAME, acpi_index);
+ if (IS_ERR(desc))
+ return PTR_ERR(desc);
+
+ gpio = desc_to_gpio(desc);
+
+ gpiod_put(desc);
+
+ return gpio;
+}
+
+static int pmic_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ if (pmic_i2c_client != NULL || pmic_i2c != NULL)
+ return -EBUSY;
+
+ pmic_i2c= (struct intel_soc_pmic *)id-driver_data;
+ pmic_i2c_client = i2c;
+ pmic_i2c-dev = i2c-dev;
+ pmic_i2c-irq = i2c-irq;
+ pmic_i2c-pmic_int_gpio = pmic_i2c_lookup_gpio(pmic_i2c-dev, 0);
+ pmic_i2c-readb = pmic_i2c_readb;
+ pmic_i2c-writeb = pmic_i2c_writeb;
+
+ return intel_pmic_add(pmic_i2c);
+}
+
+static int pmic_i2c_remove(struct i2c_client *i2c)
+{
+ int ret = intel_pmic_remove(pmic_i2c);
+
+ pmic_i2c_client = NULL;
+ pmic_i2c = NULL;
+
+ return ret;
+}
+
+static const struct i2c_device_id pmic_i2c_id[] = {
+ { crystal_cove, (kernel_ulong_t)crystal_cove_pmic},
+ { INT33FD, (kernel_ulong_t)crystal_cove_pmic},
+ { INT33FD:00, (kernel_ulong_t)crystal_cove_pmic},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, pmic_i2c_id);
+
+static struct acpi_device_id pmic_acpi_match[] = {
+ { INT33FD, (kernel_ulong_t)crystal_cove_pmic},
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, pmic_acpi_match);
+
+static struct i2c_driver pmic_i2c_driver = {
+ .driver = {
+ .name = intel_soc_pmic_i2c,
+ .owner = THIS_MODULE,
+ .pm = pmic_pm_ops,
+ .acpi_match_table = ACPI_PTR(pmic_acpi_match),
+ },
+ .probe = pmic_i2c_probe,
+ .remove = pmic_i2c_remove,
+ .id_table = pmic_i2c_id,
+ .shutdown = pmic_shutdown,
+};
+
+static int __init pmic_i2c_init(void)
+{
+ int ret;
+
+ ret = i2c_add_driver(pmic_i2c_driver);
+ if (ret != 0)
+ pr_err(Failed to register pmic I2C driver: %d\n, ret);
+
+ return ret;
+}
+subsys_initcall(pmic_i2c_init);
+
+static void __exit pmic_i2c_exit(void)
+{
+ i2c_del_driver(pmic_i2c_driver);
+}
+module_exit(pmic_i2c_exit);
+
+MODULE_DESCRIPTION(I2C driver for Intel SoC PMIC);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Yang, Bin bin.y...@intel.com);
--
1.8.3.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
[PATCH 4/4] mfd: intel_soc_pmic: Build files
Devices based on Intel SoC products such as Baytrail have a Power Management IC. This patch adds Intel SoC PMIC support to the build files. Signed-off-by: Yang, Bin bin.y...@intel.com Signed-off-by: Zhu, Lejun lejun@linux.intel.com --- drivers/mfd/Kconfig | 10 ++ drivers/mfd/Makefile | 3 +++ 2 files changed, 13 insertions(+) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 3383412..075572f 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -241,6 +241,16 @@ config LPC_SCH LPC bridge function of the Intel SCH provides support for System Management Bus and General Purpose I/O. +config INTEL_SOC_PMIC + bool Support for Intel Atom SoC PMIC + depends on I2C=y + select MFD_CORE + help + Select this option to enable support for the PMIC device + on some Intel SoC systems. The PMIC provides ADC, GPIO, + thermal, charger and related power management functions + on these systems. + config MFD_INTEL_MSIC bool Intel MSIC depends on INTEL_SCU_IPC diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 2851275..1a18d8b 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -166,3 +166,6 @@ obj-$(CONFIG_MFD_RETU) += retu-mfd.o obj-$(CONFIG_MFD_AS3711) += as3711.o obj-$(CONFIG_MFD_AS3722) += as3722.o obj-$(CONFIG_MFD_STW481X) += stw481x.o + +intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o intel_soc_pmic_i2c.o +obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o -- 1.8.3.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 v4 2/8] OF: Introduce DT overlay support.
Hi Michael, On May 14, 2014, at 5:11 AM, Michael Stickel wrote: Hi Grant, Am 14.05.2014 12:08, schrieb Grant Likely: More generally I am concerned about whether or not overlays will introduce corner cases that can never be handled correctly, particularly in how multiple overlays will get handled. I want to see very clear rules on what happens when multiple overlays are applied, and then removed again. Is it possible to remove overlays out of order? If so, what are the conditions that would not be allowed? Yes, it is possible that an overlay depends on another. The problem is not, that an overlay is removed other overlays depend on, but that nodes of an overlay may depend on the to-be-removed overlay and the resulting devicetree can become inconsistent. I have an SPI Bus with two slaves. The second slave is used only on one of our boards. That is why we split the overlays the following way: _spi1.dts: Pinmux for SPI-Bus and activation of spi-controller. Pinmux for CS0 and definition of first slave. _spi1_cs1: Pinmux for CS1 and definition of second slave. When the overlay for the bus is removed, the overlays for the second slave does not make any sense anymore. It is even worse in a scenario we have with a test board. One of the slaves is an spi-io-controller with a few bitbanging i2c masters. In an extreme case, each component is defined in a separate overlay and only the overlay with the master is removed. I know, that this is completely sick. The devices are removed cleanly because of the device dependency. Well, shouldn't you be reverting the overlays in reverse sequence? As I see it, when proper subtree tracking is implemented this use case (of removing #0 before #1) will not be allowed. What is your ideal scenario for this use case? Michael Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/8] OF: Introduce DT overlay support.
Hi Guenter, On May 14, 2014, at 6:18 AM, Guenter Roeck wrote: On 05/14/2014 06:03 AM, Geert Uytterhoeven wrote: On Wed, May 14, 2014 at 12:08 PM, Grant Likely grant.lik...@secretlab.ca wrote: +config OF_OVERLAY + bool OF overlay support + depends on OF + select OF_DYNAMIC + select OF_DEVICE + select OF_RESOLVE + help + OpenFirmware overlay support. Allows you to modify on runtime the + live tree using overlays. Should not be a user-visable option. Drivers using it should select it Why not? It's up to the (final) user to use it, or not. or otherwise cause it to be enabled. Why should this be driver-specific? Shouldn't this just work with all drivers? It does once enabled. I think what Grant refers to is that there has to be a driver which implements the actual overlay insertion and removal (ie calls the new API functions), and that the Kconfig option for this driver should select OF_OVERLAY instead of depending on it. That makes sense. Guenter Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 3/3] slub: reparent memcg caches' slabs on memcg offline
On Wed, May 14, 2014 at 11:20:51AM -0500, Christoph Lameter wrote: On Tue, 13 May 2014, Vladimir Davydov wrote: Since the slow and the normal free's can't coexist at the same time, we must assure all conventional free's have finished before switching all further free's to the slow mode and starting reparenting. To achieve that, a percpu refcounter is used. It is taken and held during each normal free. The refcounter is killed on memcg offline, and the cache's pages migration is initiated from the refcounter's release function. If we fail to take a ref on kfree, it means all normal free's have been completed and the cache is being reparented right now, so we should free the object using the slow mode. Argh adding more code to the free path touching more cachelines in the process. Actually, there is not that much active code added, IMO. In fact, it's only percpu ref get/put for per memcg caches plus a couple of conditionals. The slow mode code is meant to be executed very rarely, so we can move it to a separate function under unlikely optimization. I admit that's far not perfect, because kfree is really a hot path, where every byte of code matters, but unfortunately I don't see how we can avoid this in case we want slab re-parenting. Again, I'd like to hear from you if there is any point in moving in this direction, or I should give up and concentrate on some other approach, because you'll never accept it. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/8] OF: Introduce DT overlay support.
Hi Pantelis,
On Thu, May 15, 2014 at 9:12 AM, Pantelis Antoniou
pantelis.anton...@konsulko.com wrote:
We also need to think about kexec. Kexec works by sucking the live tree
out of the kernel and creating a .dtb from it to pass to the new kernel.
What will the rules be when kexecing? Do all the overlays need to be
removed, or does the kernel get the tree with all the overlays applied
(in which case none of the overlays can be removed on the other side of
kexec).
We can add a sysfs attribute that configures whether overlays are reverted
before
kexec or not. I can't really tell which is the correct option, so let's allow
the
policy up to user-space.
Kexec'ing into a new kernel doesn't change the hardware, so IMHO the
in-kernel DT should not change.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] sched/fair.c: change has_capacity to has_free_capacity
On Wed, May 14, 2014 at 04:57:06PM -0400, Nicolas Pitre wrote: The capacity of a CPU/group should be some intrinsic value that doesn't change with task placement. It is like a container which capacity is stable regardless of the amount of liquid in it... unless the container itself is crushed that is, but that's another story. Therefore let's rename has_capacity to has_free_capacity in order to better convey the wanted meaning. Yeah, not really, the whole capacity thing is bollocks, but sure we can rename it for as long as it still lives ;-) pgpSDHKkHEkeJ.pgp Description: PGP signature
[PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid
This patch makes crash dump kernel use arch pfn_valid defined in arch/arm/mm/init.c instead of the one in include/linux/mmzone.h. The goal of this patch is to remove some limitation when kexec loading crash kernel while SPARSEMEM is enabled. Before this patch, if second kernel selects both CRASH_DUMP and SPARSEMEM, the second kernel will recongnize memorys at the same section with itself as valid memory, and prevents ioremap (see arm ioremap code, arm doesn't allow valid memory to be ioremapped again). Which introduces some limitations on positioning the crash kernel. For example: For a platform with SECTION_SIZE_BITS == 28 (256MiB) and crashkernel=128M@0x2800 in kernel cmdline, the second kernel is loaded at 0x2800. Kexec puts elfcorehdr at 0x2ff0, and passes 'elfcorehdr=0x2ff0 mem=130048K' to second kernel. When second kernel start, it tries to use ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the same section of the second kernel, pfn_valid will recongnize the page as valid, so ioremap will refuse to map it. Even if we put crash kernel at the boundary of two sections (such as 129MB@0x0x2800 in the above situation), 0x2000-0x2800 used by old kernel is still unable to retrived by crash kernel because they are at the same section. This patch makes crash dump kernel use strict (and slow) version of pfn_valid(), which makes crash kernel recongnize memory correctly. Signed-off-by: Wang Nan wangn...@huawei.com Cc: Geng Hui hui.g...@huawei.com Cc: Mika Westerberg ext-mika.1.westerb...@nokia.com Cc: Simon Horman ho...@verge.net.au --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index db3c541..795b1d4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1800,7 +1800,7 @@ config ARCH_SELECT_MEMORY_MODEL def_bool ARCH_SPARSEMEM_ENABLE config HAVE_ARCH_PFN_VALID - def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM + def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM || CRASH_DUMP config HIGHMEM bool High Memory Support -- 1.8.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]pwm: add xilinx pwm driver
On Wednesday 14 May 2014 13:26:13 Bart Tanghe wrote:
@@ -0,0 +1,20 @@
+Xilinx PWM controller
+
+Required properties:
+- compatible: should be xlnx,pwm-xlnx
+- add a clock source to the description
+
+Examples:
+
+ axi_timer_0: timer@4280 {
+ clock-frequency = 1;
+ clocks = clkc 15;
+ compatible = xlnx,xlnx-pwm;
+ reg = 0x4280 0x1;
+ xlnx,count-width = 0x20;
+ xlnx,gen0-assert = 0x1;
+ xlnx,gen1-assert = 0x1;
+ xlnx,one-timer-only = 0x0;
+ xlnx,trig0-assert = 0x1;
+ xlnx,trig1-assert = 0x1;
+ } ;
It seems you are missing a mandatory #pwm-cells property.
How is anybody supposed to use this?
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] microblaze: Enable SERIAL_OF_PLATFORM
SERIAL_OF_PLATFORM is required for getting 8250 to work. Reported-by: Subbaraya Sundeep Bhatta sbha...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/microblaze/configs/mmu_defconfig | 1 + arch/microblaze/configs/nommu_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/microblaze/configs/mmu_defconfig b/arch/microblaze/configs/mmu_defconfig index deaf45ab6429..e2f6543b91e7 100644 --- a/arch/microblaze/configs/mmu_defconfig +++ b/arch/microblaze/configs/mmu_defconfig @@ -49,6 +49,7 @@ CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_UARTLITE=y CONFIG_SERIAL_UARTLITE_CONSOLE=y +CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set CONFIG_XILINX_HWICAP=y CONFIG_I2C=y diff --git a/arch/microblaze/configs/nommu_defconfig b/arch/microblaze/configs/nommu_defconfig index 10b5172283d7..a29ebd4a9fcb 100644 --- a/arch/microblaze/configs/nommu_defconfig +++ b/arch/microblaze/configs/nommu_defconfig @@ -58,6 +58,7 @@ CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_UARTLITE=y CONFIG_SERIAL_UARTLITE_CONSOLE=y +CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set CONFIG_XILINX_HWICAP=y CONFIG_I2C=y -- 1.8.2.3 pgpCP5utVHeSK.pgp Description: PGP signature
Re: [PATCH 2/6] sched/fair.c: change has_capacity to has_free_capacity
On 15 May 2014 09:21, Peter Zijlstra pet...@infradead.org wrote: On Wed, May 14, 2014 at 04:57:06PM -0400, Nicolas Pitre wrote: The capacity of a CPU/group should be some intrinsic value that doesn't change with task placement. It is like a container which capacity is stable regardless of the amount of liquid in it... unless the container itself is crushed that is, but that's another story. Therefore let's rename has_capacity to has_free_capacity in order to better convey the wanted meaning. Yeah, not really, the whole capacity thing is bollocks, but sure we can rename it for as long as it still lives ;-) Hi, Yes, I'm preparing an update of my rework around cpu_power and this field will disappear Vincent -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 6/6] sched: final power vs capacity cleanup
On Wed, May 14, 2014 at 04:57:10PM -0400, Nicolas Pitre wrote: It is better not to think about compute capacity as being equivalent to CPU power. The upcoming power aware scheduler may create confusion with the notion of energy consumption if power is used too liberally. This contains the architecture visible changes. Incidentally, only ARM takes advantage of the available pow^H^H^Hcapacity scaling hooks and therefore those changes outside kernel/sched/ are confined to one ARM specific file. The default arch_scale_smt_power() hook is not overridden by anyone. Replacements are as follows: arch_scale_freq_power -- arch_scale_freq_capacity arch_scale_smt_power -- arch_scale_smt_capacity SCHED_POWER_SCALE -- SCHED_CAPA_SCALE SCHED_POWER_SHIFT -- SCHED_POWER_SHIFT The patch seems to actually make that CAPA_SHIFT The local usage of power in arch/arm/kernel/topology.c is also changed to capacity as appropriate. For some reason every time I read: 'capa' I think of some south American monster -- http://en.wikipedia.org/wiki/Chupacabra, I'm not at all sure why my brain links them. But yes, once we kill the capacity stuff we have now with some utilization bound, capacity becomes uniquely the compute capacity. pgpdAUkFIyTwx.pgp Description: PGP signature
Re: [PATCH] ARM: KVM: add irqfd and irq routing support
On 05/15/2014 07:26 AM, Anup Patel wrote: On Fri, May 9, 2014 at 6:15 PM, Eric Auger eric.au...@linaro.org wrote: This patch enables irqfd and irq routing on ARM. It turns on CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQ_ROUTING irqfd framework enables to assign physical IRQs to guests. 1) user-side uses KVM_IRQFD VM ioctl to pass KVM a kvm_irqfd struct that associates a VM, an eventfd, an IRQ number (aka. the GSI). When an actor signals the eventfd (typically a VFIO platform driver), the irqfd subsystem injects the specified IRQ into the VM (the GSI takes the semantic of a virtual IRQ for that guest). 2) the other use case is user-side does 1) and uses KVM_SET_GSI_ROUTING VM ioctl to create an association between a VM, a physical IRQ (aka GSI) and a virtual IRQ (aka irchip.pin). This creates a so-called GSI routing entry. When someone triggers the eventfd, irqfd handles it but uses the specified routing and eventually injects irqchip.pin virtual IRQ into the guest. In that context the GSI takes the semantic of a physical IRQ while the irqchip.pin takes the semantic of a virtual IRQ. in 1) routing is used by irqfd but an identity routing is created by default making the gsi = irqchip.pin. Note on ARM there is a single interrupt controller kind, the GIC. GSI routing mostly is implemented in generic irqchip.c. The tiny ARM specific part is directly implemented in the virtual interrupt controller (vgic.c) as it is done for powerpc for instance. This option was prefered compared to implementing other #ifdef in irq_comm.c (x86 and ia64). Hence irq_comm.c is not used at all. Routing currently is not used for anything else than irqfd IRQ injection. Only SPI can be injected. This means the vgic is not totally hidden behind the irqchip. There are separate discussions on PPI/SGI routing. Only level sensitive IRQs are supported (with a registered resampler). As a reminder the resampler is a second eventfd called by irqfd framework when the virtual IRQ is completed by the guest. This eventfd is supposed to be handled on user-side MSI routing is not supported yet. This work was tested with Calxeda Midway xgmac main interrupt (with and without explicit user routing) with qemu-system-arm and QEMU VFIO platform device. I have a doubt here: Why are we not using EOImode here? OR Is de-prioritization of routed IRQs taken care by different patch? As-per GICv2 spec, ARM recommends using GICC_CTRL.EOImodeNS=1 for routing physical IRQs as virtual IRQs. Xen already uses it for both arm32 and arm64. The EOImode is recommended here because we need to de-prioritize routed IRQs before forwarding them to Guest as virtual IRQs. Later, when Guests is done processing virtual IRQ it will do EOI after which we can de-activate the physical IRQ using GICC_DIR register. Hi Anup, thanks for your reply. Yes indeed we are currently studying the usage of - GICH_LR.HW==1 and maintenance IRQ disabling = enabling automatic deactivation of HW IRQ upon virtual IRQ deactivation - 2 stage IRQ completion for a next patch release. This is the natural next optimization step for assigned IRQ handling. The intent of this patch was to integrate smoothly into the irqfd/vfio driver legacy framework. Typically once we have put this further optimization in place we will not be able to trigger the resamplefd anymore (because we do not trap the EOI anymore) and also some modifications in the vfio driver might be needed (assigned IRQ masking must be removed). Best Regards Eric Regards, Anup Signed-off-by: Eric Auger eric.au...@linaro.org Conflicts: Documentation/virtual/kvm/api.txt arch/arm/kvm/Kconfig --- Documentation/virtual/kvm/api.txt | 4 +- arch/arm/include/uapi/asm/kvm.h | 8 +++ arch/arm/kvm/Kconfig | 2 + arch/arm/kvm/Makefile | 1 + arch/arm/kvm/irq.h| 25 virt/kvm/arm/vgic.c | 124 -- 6 files changed, 158 insertions(+), 6 deletions(-) create mode 100644 arch/arm/kvm/irq.h diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index a9380ba5..202d63e3 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1339,7 +1339,7 @@ KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed. 4.52 KVM_SET_GSI_ROUTING Capability: KVM_CAP_IRQ_ROUTING -Architectures: x86 ia64 s390 +Architectures: x86 ia64 s390 arm Type: vm ioctl Parameters: struct kvm_irq_routing (in) Returns: 0 on success, -1 on error @@ -2126,7 +2126,7 @@ into the hash PTE second double word). 4.75 KVM_IRQFD Capability: KVM_CAP_IRQFD -Architectures: x86 +Architectures: x86 arm Type: vm ioctl Parameters: struct kvm_irqfd (in) Returns: 0 on success, -1 on error diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h index ef0c878..89b864d
Re: [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid
Add ke...@lists.infradead.org to cc list. On 2014/5/15 15:14, Wang Nan wrote: This patch makes crash dump kernel use arch pfn_valid defined in arch/arm/mm/init.c instead of the one in include/linux/mmzone.h. The goal of this patch is to remove some limitation when kexec loading crash kernel while SPARSEMEM is enabled. Before this patch, if second kernel selects both CRASH_DUMP and SPARSEMEM, the second kernel will recongnize memorys at the same section with itself as valid memory, and prevents ioremap (see arm ioremap code, arm doesn't allow valid memory to be ioremapped again). Which introduces some limitations on positioning the crash kernel. For example: For a platform with SECTION_SIZE_BITS == 28 (256MiB) and crashkernel=128M@0x2800 in kernel cmdline, the second kernel is loaded at 0x2800. Kexec puts elfcorehdr at 0x2ff0, and passes 'elfcorehdr=0x2ff0 mem=130048K' to second kernel. When second kernel start, it tries to use ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the same section of the second kernel, pfn_valid will recongnize the page as valid, so ioremap will refuse to map it. Even if we put crash kernel at the boundary of two sections (such as 129MB@0x0x2800 in the above situation), 0x2000-0x2800 used by old kernel is still unable to retrived by crash kernel because they are at the same section. This patch makes crash dump kernel use strict (and slow) version of pfn_valid(), which makes crash kernel recongnize memory correctly. Signed-off-by: Wang Nan wangn...@huawei.com Cc: Geng Hui hui.g...@huawei.com Cc: Mika Westerberg ext-mika.1.westerb...@nokia.com Cc: Simon Horman ho...@verge.net.au --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index db3c541..795b1d4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1800,7 +1800,7 @@ config ARCH_SELECT_MEMORY_MODEL def_bool ARCH_SPARSEMEM_ENABLE config HAVE_ARCH_PFN_VALID - def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM + def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM || CRASH_DUMP config HIGHMEM bool High Memory Support -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity
On Wed, May 14, 2014 at 04:59:58PM -0400, Carlos O'Donell wrote: Nobody has looked at this code in years, likely because all parties thought they were done, but had in fact agreed to distinct expectations and assumptions about the implementation. That's just not true, we've been close to hijacking all the libpthread functionality from glibc through a kernel DSO in order to get some movement. Glibc has been known broken and unwilling to change for years and its lead to immense frustration with people. I want it fix, and I'm in a position to move resources to fix it. That's great news, and about bloody time too :-) pgpIo7t5KoHBy.pgp Description: PGP signature
Re: [RFC PATCH 2/5] clk: Introduce 'clk_round_rate_nearest()'
Hello,
it's great you pick that up.
On Wed, May 14, 2014 at 03:30:52PM -0700, Soren Brinkmann wrote:
Introduce a new API function to round a rate to the closest possible
rate the HW clock can generate.
In contrast to 'clk_round_rate()' which works similar, but always returns
a frequency = its input rate.
The code comes from Uwe and was copied from this LKML thread:
https://lkml.org/lkml/2013/3/21/115
Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
---
drivers/clk/clk.c | 26 --
include/linux/clk.h | 14 --
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dff0373f53c1..b715f5a9826c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1011,8 +1011,9 @@ unsigned long __clk_round_rate(struct clk *clk,
unsigned long rate)
* @rate: the rate which is to be rounded
*
* Takes in a rate as input and rounds it to a rate that the clk can actually
- * use which is then returned. If clk doesn't support round_rate operation
- * then the parent rate is returned.
+ * use and does not exceed the requested frequency, which is then returned.
+ * If clk doesn't support round_rate operation then the parent rate
+ * is returned.
*/
long clk_round_rate(struct clk *clk, unsigned long rate)
{
@@ -1027,6 +1028,27 @@ long clk_round_rate(struct clk *clk, unsigned long
rate)
EXPORT_SYMBOL_GPL(clk_round_rate);
/**
+ * clk_round_rate_nearest - round the given rate for a clk
+ * @clk: the clk for which we are rounding a rate
+ * @rate: the rate which is to be rounded
+ *
+ * Takes in a rate as input and rounds it to the closest rate that the clk
+ * can actually use which is then returned. If clk doesn't support
+ * round_rate operation then the parent rate is returned.
+ */
+long clk_round_rate_nearest(struct clk *clk, unsigned long rate)
+{
+ long lower_limit = clk_round_rate(clk, rate);
+ long upper_limit = clk_round_rate(clk, rate + (rate - lower_limit));
+
+ if (rate - lower_limit upper_limit - rate)
+ return lower_limit;
+ else
+ return upper_limit;
I wanted to suggest to add some comment to describe why the calculation
works here. While trying to proove it, I noticed that this
implementation is buggy.
Consider a clock that can provide the following frequencies: 38000,
38401, 38600.
clk_round_rate_nearest(clk, 38400)
lower_limit = clk_round_rate(clk, 38400) - 38000
upper_limit = clk_round_rate(clk, 38800) - 38600
return 38600
but 38401 would have been the better/correct answer. I think you cannot
implement clk_round_rate_nearest without iteration if you don't want to
add specific logic to the clock providers.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] sched/fair.c: disambiguate existing/remaining capacity usage
On 14 May 2014 22:57, Nicolas Pitre nicolas.pi...@linaro.org wrote:
We have power (which should actually become capacity) and capacity
which is a scaled down capacity factor in terms of possible tasks.
Let's use capa_factor to make room for proper usage of capacity
later.
Signed-off-by: Nicolas Pitre n...@linaro.org
---
kernel/sched/fair.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0eda4c527e..2633c42692 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5487,7 +5487,7 @@ struct sg_lb_stats {
unsigned long load_per_task;
unsigned long group_power;
unsigned int sum_nr_running; /* Nr tasks running in the group */
- unsigned int group_capacity;
+ unsigned int group_capa_factor;
As it is mainly compared to sum_nr_running, you might rename it to
group_nr_capacity instead of group_capa_factor
unsigned int idle_cpus;
unsigned int group_weight;
int group_imb; /* Is there an imbalance in the group ? */
@@ -5782,15 +5782,15 @@ static inline int sg_imbalanced(struct sched_group
*group)
}
/*
- * Compute the group capacity.
+ * Compute the group capacity factor.
*
* Avoid the issue where N*frac(smt_power) = 1 creates 'phantom' cores by
* first dividing out the smt factor and computing the actual number of cores
* and limit power unit capacity with that.
*/
-static inline int sg_capacity(struct lb_env *env, struct sched_group *group)
+static inline int sg_capa_factor(struct lb_env *env, struct sched_group
*group)
{
- unsigned int capacity, smt, cpus;
+ unsigned int capa_factor, smt, cpus;
unsigned int power, power_orig;
power = group-sgp-power;
@@ -5799,13 +5799,13 @@ static inline int sg_capacity(struct lb_env *env,
struct sched_group *group)
/* smt := ceil(cpus / power), assumes: 1 smt_power 2 */
smt = DIV_ROUND_UP(SCHED_POWER_SCALE * cpus, power_orig);
- capacity = cpus / smt; /* cores */
+ capa_factor = cpus / smt; /* cores */
- capacity = min_t(unsigned, capacity, DIV_ROUND_CLOSEST(power,
SCHED_POWER_SCALE));
- if (!capacity)
- capacity = fix_small_capacity(env-sd, group);
+ capa_factor = min_t(unsigned, capa_factor, DIV_ROUND_CLOSEST(power,
SCHED_POWER_SCALE));
+ if (!capa_factor)
+ capa_factor = fix_small_capacity(env-sd, group);
- return capacity;
+ return capa_factor;
}
/**
@@ -5855,9 +5855,9 @@ static inline void update_sg_lb_stats(struct lb_env
*env,
sgs-group_weight = group-group_weight;
sgs-group_imb = sg_imbalanced(group);
- sgs-group_capacity = sg_capacity(env, group);
+ sgs-group_capa_factor = sg_capa_factor(env, group);
- if (sgs-group_capacity sgs-sum_nr_running)
+ if (sgs-group_capa_factor sgs-sum_nr_running)
sgs-group_has_free_capacity = 1;
}
@@ -5882,7 +5882,7 @@ static bool update_sd_pick_busiest(struct lb_env *env,
if (sgs-avg_load = sds-busiest_stat.avg_load)
return false;
- if (sgs-sum_nr_running sgs-group_capacity)
+ if (sgs-sum_nr_running sgs-group_capa_factor)
return true;
if (sgs-group_imb)
@@ -5973,17 +5973,17 @@ static inline void update_sd_lb_stats(struct lb_env
*env, struct sd_lb_stats *sd
/*
* In case the child domain prefers tasks go to siblings
-* first, lower the sg capacity to one so that we'll try
+* first, lower the sg capacity factor to one so that we'll
try
* and move all the excess tasks away. We lower the capacity
* of a group only if the local group has the capacity to fit
-* these excess tasks, i.e. nr_running group_capacity. The
+* these excess tasks, i.e. nr_running group_capa_factor.
The
* extra check prevents the case where you always pull from
the
* heaviest group when it is already under-utilized (possible
* with a large weight task outweighs the tasks on the
system).
*/
if (prefer_sibling sds-local
sds-local_stat.group_has_free_capacity)
- sgs-group_capacity = min(sgs-group_capacity, 1U);
+ sgs-group_capa_factor = min(sgs-group_capa_factor,
1U);
if (update_sd_pick_busiest(env, sds, sg, sgs)) {
sds-busiest = sg;
@@ -6157,7 +6157,7 @@ static inline void calculate_imbalance(struct lb_env
*env, struct sd_lb_stats *s
* have to drop below capacity to reach cpu-load equilibrium.
*/
load_above_capacity =
-
Re: [PATCH 0/6] sched: expel confusing usage of the term power
Hi Nico, Thanks for doing this renaming. I remember that you asked me to do this while working on cpu_power but my work has not evolved as fast as expected and as it already implies some renaming other than s/power/capacity/ i have postponed it to not make review to complex. Nevertheless, i can manage the conflicts afterward and rebase my patches, depending of the review status Vincent On 14 May 2014 22:57, Nicolas Pitre nicolas.pi...@linaro.org wrote: Power is a very bad term in the scheduler context. There are so many meanings that can be attached to it. And with the upcoming power aware scheduler work confusion is sure to happen. The definition of power is typically the rate at which work is performed, energy is converted or electric energy is transferred. The notion of compute capacity is rather at odds with power to the point many comments in the code have to make it explicit that capacity is the actual intended meaning. So let's make it clear what we man by using capacity in place of power directly in the code. That will make the introduction of actual power consumption concepts much clearer later on. This is based on the latest tip tree where scheduler changes are already queued. Note: The diffstat is not completely symetric wrt added/removed lines as some comments were reflowed. arch/arm/kernel/topology.c | 54 +++ include/linux/sched.h | 8 +- kernel/sched/core.c| 89 ++- kernel/sched/fair.c| 322 --- kernel/sched/sched.h | 18 +-- 5 files changed, 246 insertions(+), 245 deletions(-) Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] phy: Add exynos-simple-phy driver
On Thu, May 15, 2014 at 10:49:37AM +0530, Rahul Sharma wrote: Hi Thierry, On 15 May 2014 03:44, Thierry Reding thierry.red...@gmail.com wrote: On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote: [...] +#define HDMI_PHY 0 +#define DAC_PHY 1 +#define ADC_PHY 2 +#define PCIE_PHY 3 +#define SATA_PHY 4 Perhaps these should be namespaced somehow to avoid potential conflicts with other PHY providers? How about XXX_SIMPLE_PHY? The indices are specific to the Exynos PHY device, so why not PHY_EXYNOS_SIMPLE_XXX (or any variation thereof)? +#define PHY_NR 5 I'm not sure that this belongs here either. It's not a value that will ever appear in a DT source file. I want it to grow along with new additions in the phy list else catastrophic. This will look unrelated in driver. But this is in no way growing automatically as it is. Whoever adds a new type of PHY will need to manually increment this define. Furthermore the driver will need to be updated to cope with this anyway. I think this is even a reason to have this only in the driver. Otherwise you could have a situation where somebody upgrades the binding (and this file along with it) but not update the driver with the necessary support. But the driver will still pick up the PHY_NR change and will accept the new PHY type as valid, even though it has no code to handle it. If you have this in the driver, however, then as long as the driver has not yet been updated it will reject requests for the new PHY type. And that's exactly what it should be doing since it doesn't know how to handle it. Thierry pgpKWA0xhO_Fl.pgp Description: PGP signature
Re: [PATCH] perf session: Fix possible null pointer dereference in session.c
On Thu, May 15, 2014 at 02:13:38AM +0900, Masanari Iida wrote:
cppcheck detected following warning.
[tools/perf/util/session.c:1628] - [tools/perf/util/session.c:1632]:
(warning) Possible null pointer dereference: session - otherwise it
is redundant to check it against null.
In order to avoide null pointer, check the pointer before use.
Signed-off-by: Masanari Iida standby2...@gmail.com
applied, thanks
jirka
---
tools/perf/util/session.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 55960f2..64a186e 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1625,13 +1625,14 @@ out_delete_map:
void perf_session__fprintf_info(struct perf_session *session, FILE *fp,
bool full)
{
- int fd = perf_data_file__fd(session-file);
struct stat st;
- int ret;
+ int fd, ret;
if (session == NULL || fp == NULL)
return;
+ fd = perf_data_file__fd(session-file);
+
ret = fstat(fd, st);
if (ret == -1)
return;
--
2.0.0.rc3.2.g998f840
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/10] clk: berlin: add core clock driver for BG2Q
On 14/05/2014 at 22:15:18 +0200, Sebastian Hesselbarth wrote :
From: Alexandre Belloni alexandre.bell...@free-electrons.com
This driver deals with the core clocks found on Marvell Berlin BG2Q. For the
shared register dividers, make use of the corresponding driver and add some
single clock muxes and gates for the rest.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
Changelog:
v1-v2:
- initial version
Cc: Mike Turquette mturque...@linaro.org
Cc: Alexandre Belloni alexandre.bell...@free-electrons.com
Cc: Jisheng Zhang jszh...@marvell.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/berlin/Makefile | 1 +
drivers/clk/berlin/bg2q.c | 269
2 files changed, 270 insertions(+)
create mode 100644 drivers/clk/berlin/bg2q.c
diff --git a/drivers/clk/berlin/Makefile b/drivers/clk/berlin/Makefile
index 2b33e1e74503..2a36ab710a07 100644
--- a/drivers/clk/berlin/Makefile
+++ b/drivers/clk/berlin/Makefile
@@ -1,3 +1,4 @@
obj-y += berlin2-avpll.o berlin2-pll.o berlin2-div.o
obj-$(CONFIG_MACH_BERLIN_BG2)+= bg2.o
obj-$(CONFIG_MACH_BERLIN_BG2CD) += bg2.o
+obj-$(CONFIG_MACH_BERLIN_BG2Q) += bg2q.o
diff --git a/drivers/clk/berlin/bg2q.c b/drivers/clk/berlin/bg2q.c
new file mode 100644
index ..df5a4ce5eb87
--- /dev/null
+++ b/drivers/clk/berlin/bg2q.c
@@ -0,0 +1,269 @@
+/*
+ * Copyright (c) 2014 Marvell Technology Group Ltd.
+ *
+ * Alexandre Belloni alexandre.bell...@free-electrons.com
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/clk.h
+#include linux/clk-provider.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/slab.h
+
+#include berlin2-div.h
+
+struct bg2_gate_data {
+ const char *name;
+ const char *parent_name;
+ u8 bit_idx;
+ unsigned long flags;
+};
+
+#define REG_CLKENABLE0x00
+#define REG_CLKSELECT0 0x04
+#define REG_CLKSELECT1 0x08
+#define REG_CLKSELECT2 0x0c
+#define REG_CLKSWITCH0 0x10
+#define REG_CLKSWITCH1 0x14
+
+#define MAX_CLKS 24
+
+static DEFINE_SPINLOCK(lock);
+static struct clk *clks[MAX_CLKS];
+static struct clk_onecell_data clk_data;
+
+static const struct berlin2_div_data bg2q_divs[] __initconst = {
+ {
+ .name = sys,
+ .flags = CLK_IGNORE_UNUSED,
+ .map = {
+ BERLIN2_DIV_GATE(REG_CLKENABLE, 0),
+ BERLIN2_PLL_SELECT(REG_CLKSELECT0, 0),
+ BERLIN2_DIV_SELECT(REG_CLKSELECT0, 3),
+ BERLIN2_PLL_SWITCH(REG_CLKSWITCH0, 3),
+ BERLIN2_DIV_SWITCH(REG_CLKSWITCH0, 4),
+ BERLIN2_DIV_D3SWITCH(REG_CLKSWITCH0, 5),
+ },
+ .div_flags = BERLIN2_DIV_HAS_GATE | BERLIN2_DIV_HAS_MUX,
+ },
+ {
+ .name = drmfigo,
+ .flags = 0,
+ .map = {
+ BERLIN2_DIV_GATE(REG_CLKENABLE, 17),
+ BERLIN2_PLL_SELECT(REG_CLKSELECT0, 6),
+ BERLIN2_DIV_SELECT(REG_CLKSELECT0, 9),
+ BERLIN2_PLL_SWITCH(REG_CLKSWITCH0, 6),
+ BERLIN2_DIV_SWITCH(REG_CLKSWITCH0, 7),
+ BERLIN2_DIV_D3SWITCH(REG_CLKSWITCH0, 8),
+ },
+ .div_flags = BERLIN2_DIV_HAS_GATE | BERLIN2_DIV_HAS_MUX,
+ },
+ {
+ .name = cfg,
+ .flags = 0,
+ .map = {
+ BERLIN2_DIV_GATE(REG_CLKENABLE, 1),
+ BERLIN2_PLL_SELECT(REG_CLKSELECT0, 12),
+ BERLIN2_DIV_SELECT(REG_CLKSELECT0, 15),
+ BERLIN2_PLL_SWITCH(REG_CLKSWITCH0, 9),
+ BERLIN2_DIV_SWITCH(REG_CLKSWITCH0, 10),
+ BERLIN2_DIV_D3SWITCH(REG_CLKSWITCH0, 11),
+ },
+ .div_flags = BERLIN2_DIV_HAS_GATE | BERLIN2_DIV_HAS_MUX,
+ },
+ {
+ .name = gfx2d,
+ .flags = 0,
+ .map = {
+ BERLIN2_DIV_GATE(REG_CLKENABLE, 4),
+
Re: [RFC PATCH 0/5] Frequency resolution in CCF vs. cpufreq
On Wed, May 14, 2014 at 03:30:50PM -0700, Soren Brinkmann wrote: Hi, I have one or two problems with cpufreq and the CCF, which are caused by rounding/different frequency resolutions. cpufreq works with kHz, while the CCF uses Hz. On Zynq our default frequency is 6 Hz which the CCF, due to rounding, reports as 0. And for Why does this happen? Isn't that a bug? What is the actual freqency? 6 Hz or 20/3 Hz? cpufreq, which simply divides values it obtains through clk_round_rate() by 1000, 66. Since passing 66 to clk_round_rate() does not result in 0 (clk_round_rate() always rounds down!), we chose to put 67 in the OPP. This What is OPP? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hello
Hello, Please can you help me reprofile fund? I am Ms Teresa Au, HSBC Hong Kong, head of corporate sustainability Asia pacific region. A sum of (USD$23,200,000.00) (Twenty three million, two Hundred Thousand dollars) Million was deposited by our Late customer who died without declaring any next of kin before his death in 2006. My suggestion to you is to stand as the next of kin to Fadel Ahmed. We shall share in the ratio of 50% for me, 50% for you. Please contact me via this e-mail: msteresa@qq.com . Thanks Regards Mrs Teresa Au. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: Tree for May 15
Hi all, Changes since 20140514: My fixes tree contains: powerpc/ppc64: Allow allmodconfig to build (finally !) The gpio tree still had its build failure for which I reverted 2 commits. The clk tree gained a conflict against the renesas tree. The akpm-current tree lost its build failure. Non-merge commits (relative to Linus' tree): 5424 5048 files changed, 183887 insertions(+), 111768 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 218 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (14186fea0cb0 Merge tag 'locks-v3.15-4' of git://git.samba.org/jlayton/linux) Merging fixes/master (0be9d8b61c0c powerpc/ppc64: Allow allmodconfig to build (finally !)) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (a798c10faf62 Linux 3.15-rc2) Merging arm-current/fixes (d93003e8e4e1 ARM: 8042/1: iwmmxt: allow to build iWMMXt on Marvell PJ4B) Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for v3.14-rc1) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging powerpc-merge/merge (8050936caf12 powerpc: irq work racing with timer interrupt can result in timer interrupt hang) Merging sparc/master (e5c460f46ae7 sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses.) Merging net/master (e84d2f8d2ae3 net: filter: s390: fix JIT address randomization) Merging ipsec/master (6d004d6cc739 vti: Use the tunnel mark for lookup in the error handlers.) CONFLICT (content): Merge conflict in net/ipv4/ip_vti.c Merging sound-current/for-linus (665ebe926e7b ALSA: sb_mixer: missing return statement) Merging pci-current/for-linus (f5d3352b2751 PCI: tegra: Use new OF interrupt mapping when possible) Merging wireless/master (faf1dc64e345 ath9k_htc: Stop ANI before doing hw_reset) Merging driver-core.current/driver-core-linus (555724a831b4 kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs) Merging tty.current/tty-linus (62a0d8d7c2b2 tty: Fix lockless tty buffer race) Merging usb.current/usb-linus (6ed07d45d09b USB: Nokia 5300 should be treated as unusual dev) Merging usb-gadget-fixes/fixes (886c7c426d46 usb: gadget: at91-udc: fix irq and iomem resource retrieval) Merging staging.current/staging-linus (3519acb3b0c2 Merge branch 'imx-drm-fixes-urgent' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into staging-linus) Merging char-misc.current/char-misc-linus (d1db0eea8524 Linux 3.15-rc3) Merging input-current/for-linus (0b5fe736fe92 Input: synaptics - add min/max quirk for the ThinkPad W540) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard stripe) Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode concurrency finding.) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (58b116bce136 drivercore: deferral race condition fix) Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting module removal.) Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before cancelling delayed works) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus) Merging drm-intel-fixes/for-linux-next-fixes (9bbfd20abe50 drm/i915:
Re: [PATCH 09/27] cris: Use common bits from generic tlb.h
On Wed, May 14, 2014 at 08:59:41PM +0200, Richard Weinberger wrote:
It is no longer needed to define them on our own.
Looks good!
Acked-by: Jesper Nilsson jesper.nils...@axis.com
Cc: Mikael Starvik star...@axis.com
Cc: Richard Weinberger rich...@nod.at
Cc: linux-cris-ker...@axis.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger rich...@nod.at
---
arch/cris/include/asm/tlb.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/cris/include/asm/tlb.h b/arch/cris/include/asm/tlb.h
index 77384ea..4cc840f 100644
--- a/arch/cris/include/asm/tlb.h
+++ b/arch/cris/include/asm/tlb.h
@@ -2,18 +2,7 @@
#define _CRIS_TLB_H
#include linux/pagemap.h
-
#include arch/tlb.h
-
-/*
- * cris doesn't need any special per-pte or
- * per-vma handling..
- */
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-#define __tlb_remove_tlb_entry(tlb, ptep, address) do { } while (0)
-
-#define tlb_flush(tlb) flush_tlb_mm((tlb)-mm)
#include asm-generic/tlb.h
#endif
--
1.8.4.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/
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] drm/panel: add support for EDT panels
On Wed, May 14, 2014 at 11:45:57PM +0200, ste...@agner.ch wrote: From: Stefan Agner ste...@agner.ch This panels are sold by Toradex for Colibri T20/T30 and Apalis T30 evaluation kits. Signed-off-by: Stefan Agner ste...@agner.ch Panel patches should go to the dri-devel mailing list as well. Also a patch was posted only yesterday for a panel that seems to be the exact same one as this, even though the name differs minimally, see: https://patchwork.kernel.org/patch/4175251/ Adding Philipp on Cc so you guys can work together whether this is indeed the same panel. The only differences seem to be in the vertical front and back porches, but I suspect that either settings will work on both Tegra and i.MX. Thierry pgp7rkdz2sOHO.pgp Description: PGP signature
Re: [PATCHv2 1/2] mm/vmalloc: Add IO mapping space reused interface support.
On Thu, May 15, 2014 at 6:56 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Wed, 14 May 2014 16:18:51 +0800 Richard Lee superlibj8...@gmail.com
wrote:
For the IO mapping, the same physical address space maybe
mapped more than one time, for example, in some SoCs:
- 0x20001000 ~ 0x20001400 -- 1KB for Dev1
- 0x20001400 ~ 0x20001800 -- 1KB for Dev2
and the page size is 4KB.
Then both Dev1 and Dev2 will do ioremap operations, and the IO
vmalloc area's virtual address will be aligned down to 4KB, and
the size will be aligned up to 4KB. That's to say, only one
4KB size's vmalloc area could contain Dev1 and Dev2 IO mapping area
at the same time.
Unclear. What happens when a caller does the two ioremaps at present?
It fails? Returns the current mapping's address? Something else?
For this case, should the later one wait ?
Maybe this patch hasn't consider about this.
For this case, we can ioremap only one time, and the later ioremap
operation will just return the exist vmalloc area.
I guess an alternative is to establish a new vmap pointing at the same
physical address. How does this approach compare to refcounting the
existing vmap?
Yes, I'm also thinking to estabish one new vmap.
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -1,6 +1,7 @@
#ifndef _LINUX_VMALLOC_H
#define _LINUX_VMALLOC_H
+#include linux/atomic.h
#include linux/spinlock.h
#include linux/init.h
#include linux/list.h
@@ -34,6 +35,7 @@ struct vm_struct {
struct page **pages;
unsigned intnr_pages;
phys_addr_t phys_addr;
+ atomic_tused;
const void *caller;
};
@@ -100,6 +102,9 @@ static inline size_t get_vm_area_size(const struct
vm_struct *area)
return area-size - PAGE_SIZE;
}
+extern struct vm_struct *find_vm_area_paddr(phys_addr_t paddr, size_t size,
+ unsigned long *offset,
+ unsigned long flags);
extern struct vm_struct *get_vm_area(unsigned long size, unsigned long
flags);
extern struct vm_struct *get_vm_area_caller(unsigned long size,
unsigned long flags, const void
*caller);
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index bf233b2..cf0093c 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1293,6 +1293,7 @@ static void setup_vmalloc_vm(struct vm_struct *vm,
struct vmap_area *va,
vm-addr = (void *)va-va_start;
vm-size = va-va_end - va-va_start;
vm-caller = caller;
+ atomic_set(vm-used, 1);
va-vm = vm;
va-flags |= VM_VM_AREA;
spin_unlock(vmap_area_lock);
@@ -1383,6 +1384,84 @@ struct vm_struct *get_vm_area_caller(unsigned long
size, unsigned long flags,
NUMA_NO_NODE, GFP_KERNEL, caller);
}
+static int vm_area_used_inc(struct vm_struct *area)
+{
+ if (!(area-flags VM_IOREMAP))
+ return -EINVAL;
afaict this can never happen?
Yes, it is for now.
+ atomic_add(1, area-used);
+
+ return atomic_read(va-vm-used);
atomic_add_return() is neater. But the return value is in fact never
used so it could return void.
yes, that' fine.
+}
+
+static int vm_area_used_dec(const void *addr)
+{
+ struct vmap_area *va;
+
+ va = find_vmap_area((unsigned long)addr);
+ if (!va || !(va-flags VM_VM_AREA))
+ return 0;
+
+ if (!(va-vm-flags VM_IOREMAP))
+ return 0;
+
+ atomic_sub(1, va-vm-used);
+
+ return atomic_read(va-vm-used);
atomic_sub_return()
yes,
+}
+
+/**
+ * find_vm_area_paddr - find a continuous kernel virtual area using the
+ * physical addreess.
+ * @paddr: base physical address
+ * @size: size of the physical area range
+ * @offset:the start offset of the vm area
+ * @flags: %VM_IOREMAP for I/O mappings
+ *
+ * Search for the kernel VM area, whoes physical address starting at
+ * @paddr, and if the exsit VM area's size is large enough, then return
+ * it with increasing the 'used' counter, or return NULL.
+ */
+struct vm_struct *find_vm_area_paddr(phys_addr_t paddr, size_t size,
+ unsigned long *offset,
+ unsigned long flags)
+{
+ struct vmap_area *va;
+ int off;
+
+ if (!(flags VM_IOREMAP))
+ return NULL;
+
+ size = PAGE_ALIGN((paddr ~PAGE_MASK) + size);
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(va, vmap_area_list, list) {
+ phys_addr_t phys_addr;
+
+ if (!va || !(va-flags VM_VM_AREA) || !va-vm)
+ continue;
+
+ if (!(va-vm-flags VM_IOREMAP))
+ continue;
+
+ phys_addr = va-vm-phys_addr;
+
+ off = (paddr PAGE_MASK) - (phys_addr PAGE_MASK);
+
[PATCH] video : remove redundant error check
From 060757f81f85babf393cc76714d49af25af7791d Mon Sep 17 00:00:00 2001
From: Daeseok Youn daeseok.y...@gmail.com
Date: Thu, 15 May 2014 16:51:35 +0900
Subject: [PATCH] video : remove redundant error check
It doesn't need to check err for printing info.
And also use pr_info instead of printk.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/video/fbdev/i810/i810_main.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810_main.c
b/drivers/video/fbdev/i810/i810_main.c
index bb674e4..15cb397 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -1910,13 +1910,12 @@ static void i810fb_find_init_mode(struct fb_info *info)
for (i = 0; i par-ddc_num + 1; i++) {
err = i810_probe_i2c_connector(info, par-edid, i);
- if (!err)
+ if (!err) {
+ pr_info(i810fb_init_pci: DDC probe successful\n);
break;
+ }
}
- if (!err)
- printk(i810fb_init_pci: DDC probe successful\n);
-
fb_edid_to_monspecs(par-edid, specs);
if (specs-modedb == NULL)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/10] clk: berlin: add driver for BG2x complex divider cells
On 14/05/2014 at 22:15:16 +0200, Sebastian Hesselbarth wrote :
+static u8 berlin2_div_get_parent(struct clk_hw *hw)
+{
+ struct berlin2_div *div = to_berlin2_div(hw);
+ struct berlin2_div_map *map = div-map;
+ u32 reg;
+ u8 index = 0;
+
+ if (div-lock)
+ spin_lock(div-lock);
+
+ /* PLL_SWITCH == 0 is index 0 */
+ reg = readl_relaxed(div-base + map-pll_switch_offs);
+ reg = BIT(map-pll_switch_shift);
+ if (reg) {
+ reg = readl_relaxed(div-base + map-pll_select_offs);
+ reg = map-pll_select_shift;
+ reg = PLL_SELECT_MASK;
+ index = 1 + reg;
After getting more insight, I think we don't need to add 1, see my
comment on the next patchs.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: imx: remove check for CONFIG_SDMA_IRAM
A check for CONFIG_SDMA_IRAM was added in v2.6.34. But the Kconfig symbol SDMA_IRAM was never added. Remove this check. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. Note that none of the MX51_MXC_DMA_CHANNEL_* macros are actually used. Why are they needed? arch/arm/mach-imx/mx51.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-imx/mx51.h b/arch/arm/mach-imx/mx51.h index af844f76261a..f2604098fd06 100644 --- a/arch/arm/mach-imx/mx51.h +++ b/arch/arm/mach-imx/mx51.h @@ -160,11 +160,7 @@ #define MX51_MXC_DMA_CHANNEL_SSI1_RX MXC_DMA_DYNAMIC_CHANNEL #define MX51_MXC_DMA_CHANNEL_SSI1_TX MXC_DMA_DYNAMIC_CHANNEL #define MX51_MXC_DMA_CHANNEL_SSI2_RX MXC_DMA_DYNAMIC_CHANNEL -#ifdef CONFIG_SDMA_IRAM -#define MX51_MXC_DMA_CHANNEL_SSI2_TX (MX51_MXC_DMA_CHANNEL_IRAM + 1) -#else /*CONFIG_SDMA_IRAM */ #define MX51_MXC_DMA_CHANNEL_SSI2_TX MXC_DMA_DYNAMIC_CHANNEL -#endif /*CONFIG_SDMA_IRAM */ #define MX51_MXC_DMA_CHANNEL_CSPI1_RX MXC_DMA_DYNAMIC_CHANNEL #define MX51_MXC_DMA_CHANNEL_CSPI1_TX MXC_DMA_DYNAMIC_CHANNEL #define MX51_MXC_DMA_CHANNEL_CSPI2_RX MXC_DMA_DYNAMIC_CHANNEL -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: Add support for Intel SoC PMIC (Crystal Cove)
Devices based on Intel SoC products such as Baytrail have a Power
Management IC. In the PMIC there are subsystems for voltage regulation,
A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
Crystal Cove.
This patch adds support for the GPIO function in Crystal Cove.
Signed-off-by: Yang, Bin bin.y...@intel.com
Signed-off-by: Zhu, Lejun lejun@linux.intel.com
---
drivers/gpio/Kconfig| 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-crystalcove.c | 323
3 files changed, 333 insertions(+)
create mode 100644 drivers/gpio/gpio-crystalcove.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index a86c49a..95bb5a0 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -440,6 +440,15 @@ config GPIO_ARIZONA
help
Support for GPIOs on Wolfson Arizona class devices.
+config GPIO_INTEL_SOC_PMIC
+ bool GPIO on Intel SoC PMIC
+ depends on INTEL_SOC_PMIC
+ help
+ Support for GPIO pins on Intel SoC PMIC, such as Crystal
+ Cove.
+ Say Y if you have a tablet with Intel SoC (e.g. Baytrail)
+ inside.
+
config GPIO_LP3943
tristate TI/National Semiconductor LP3943 GPIO expander
depends on MFD_LP3943
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6309aff..5380608 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_GPIO_F7188X) += gpio-f7188x.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
+obj-$(CONFIG_GPIO_INTEL_SOC_PMIC) += gpio-crystalcove.o
obj-$(CONFIG_GPIO_IOP) += gpio-iop.o
obj-$(CONFIG_GPIO_IT8761E) += gpio-it8761e.o
obj-$(CONFIG_GPIO_JANZ_TTL)+= gpio-janz-ttl.o
diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
new file mode 100644
index 000..974f9b8
--- /dev/null
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -0,0 +1,323 @@
+/*
+ * gpio-crystalcove.c - Intel Crystal Cove GPIO Driver
+ *
+ * Copyright (C) 2012, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 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.
+ *
+ * Author: Yang, Bin bin.y...@intel.com
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/seq_file.h
+#include linux/sched.h
+#include linux/mfd/intel_soc_pmic.h
+#include linux/gpio.h
+
+#define NUM_GPIO 16
+
+#define UPDATE_TYPE(1 0)
+#define UPDATE_MASK(1 1)
+
+#define GPIO0IRQ 0x0b
+#define GPIO1IRQ 0x0c
+#define MGPIO0IRQS00x19
+#define MGPIO1IRQS00x1a
+#define MGPIO0IRQSX0x1b
+#define MGPIO1IRQSX0x1c
+#define GPIO0P0CTLO0x2b
+#define GPIO0P0CTLI0x33
+#define GPIO1P0CTLO0x3b
+#define GPIO1P0CTLI0x43
+
+#define CTLI_INTCNT_NE (1 1)
+#define CTLI_INTCNT_PE (2 1)
+#define CTLI_INTCNT_BE (3 1)
+
+#define CTLO_DIR_OUT (1 5)
+#define CTLO_DRV_CMOS (0 4)
+#define CTLO_DRV_OD(1 4)
+#define CTLO_DRV_REN (1 3)
+#define CTLO_RVAL_2KDW (0)
+#define CTLO_RVAL_2KUP (1 1)
+#define CTLO_RVAL_50KDW(2 1)
+#define CTLO_RVAL_50KUP(3 1)
+
+#define CTLO_INPUT_DEF (CTLO_DRV_CMOS | CTLO_DRV_REN | CTLO_RVAL_2KUP)
+#define CTLO_OUTPUT_DEF(CTLO_DIR_OUT | CTLO_INPUT_DEF)
+
+struct crystalcove_gpio {
+ struct mutexbuslock; /* irq_bus_lock */
+ struct gpio_chipchip;
+ int irq;
+ int irq_base;
+ int update;
+ int trigger_type;
+ int irq_mask;
+};
+static struct crystalcove_gpio gpio_info;
+
+static void __crystalcove_irq_mask(int gpio, int mask)
+{
+ u8 mirqs0 = gpio 8 ? MGPIO0IRQS0 : MGPIO1IRQS0;
+ int offset = gpio 8 ? gpio : gpio - 8;
+
+ if (mask)
+ intel_soc_pmic_setb(mirqs0, 1 offset);
+ else
+ intel_soc_pmic_clearb(mirqs0, 1 offset);
+}
+
+static void __crystalcove_irq_type(int gpio, int type)
+{
+ u8 ctli = gpio 8 ? GPIO0P0CTLI + gpio : GPIO1P0CTLI + (gpio - 8);
+
+ type = IRQ_TYPE_EDGE_BOTH;
+ intel_soc_pmic_clearb(ctli, CTLI_INTCNT_BE);
+
+
Re: [PATCH v3 4/6] arm: add basic support for Mediatek MT6589 boards
On Wednesday 14 May 2014 14:26:12 Stephen Boyd wrote: On 05/14, Maxime Ripard wrote: On Tue, May 13, 2014 at 03:47:32PM -0700, Stephen Boyd wrote: On 05/13, Matthias Brugger wrote: + mediatek,mt6589, + NULL, +}; + +DT_MACHINE_START(MEDIATEK_DT, Mediatek Cortex-A7 (Device Tree)) + .dt_compat = mediatek_board_dt_compat, +MACHINE_END You shouldn't need this file at all if the platform is part of the multi-platform kernel. From a technical point of view, you don't. But it's interesting to keep it mostly for two things: - You get to see the platform name in /proc/cpuinfo - If you ever need to add platform quirks, it's already there We had a similar discussion two weeks ago for mach-sunxi with Olof and Arnd, and ended up keeping this minimal machine. It looks like it's only useful to make /proc/cpuinfo have the platform name because it really isn't that hard to add this file if we need to add platform quirks. The downside is we have to keep adding compatibles when we support new SoCs. We also still add Kconfig entries for each new platform, and I'd like to leave it at that for the time being. In a lot of cases we end up adding stuff to the machine descriptor later, e.g. for SMP support (hopefully no more thanks to your work though). Once we have a significant number of machines that are actually usable rather than stubs and that we are confident about never needing any additional pointers, we can revisit this discussion. At that point, we should also discuss how to avoid adding a Kconfig entry for each new platform, which e.g. involves making the clocksource drivers user selectable. That part has been surprisingly controversial in the past. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
On Tuesday 13 May 2014 13:30:30 Peter Ujfalusi wrote: From CCCFG register of eDMA3 we can get all the needed information for the driver about the IP: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE The ti,edma-regions; ti,edma-slots and dma-channels in DT are redundant since the very same information can be obtained from the HW. The mentioned properties can be removed from the binding document. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com I wonder if we should keep them listed as optional properties so you can have a dtb file that still works with older kernels which need them. What you do is an incompatible change to the binding, which we shouldn't do lightly. Any new dts files don't need this information of course, but as a general rule, I'd rather keep things like this around unless we already have to enforce an ABI break that is well documented. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] zram: remove global tb_lock with fine grain lock
Currently, we use a rwlock tb_lock to protect concurrent access to
the whole zram meta table. However, according to the actual access model,
there is only a small chance for upper user to access the same table[index],
so the current lock granularity is too big.
The idea of optimization is to change the lock granularity from whole
meta table to per table entry (table - table[index]), so that we can
protect concurrent access to the same table[index], meanwhile allow
the maximum concurrency.
With this in mind, several kinds of locks which could be used as a
per-entry lock were tested and compared:
Test environment:
x86-64 Intel Core2 Q8400, system memory 4GB, Ubuntu 12.04,
kernel v3.15.0-rc3 as base, zram with 4 max_comp_streams LZO.
iozone test:
iozone -t 4 -R -r 16K -s 200M -I +Z
(1GB zram with ext4 filesystem, take the average of 10 tests, KB/s)
Test base CASspinlockrwlock bit_spinlock
---
Initial write 1381094 1425435 1422860 1423075 1421521
Rewrite 1529479 1641199 1668762 1672855 1654910
Read 8468009 11324979 11305569 7273 10997202
Re-read 8467476 11260914 11248059 11145336 10906486
Reverse Read 6821393 8106334 8282174 8279195 8109186
Stride read 7191093 8994306 9153982 8961224 9004434
Random read 7156353 8957932 9167098 8980465 8940476
Mixed workload 4172747 5680814 5927825 5489578 5972253
Random write 1483044 1605588 1594329 1600453 1596010
Pwrite 1276644 1303108 1311612 1314228 1300960
Pread 4324337 4632869 4618386 4457870 4500166
To enhance the possibility of access the same table[index] concurrently,
set zram a small disksize(10MB) and let threads run with large loop count.
fio test:
fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers
--scramble_buffers=1 --direct=1 --loops=3000 --numjobs=4
--filename=/dev/zram0 --name=seq-write --rw=write --stonewall
--name=seq-read --rw=read --stonewall --name=seq-readwrite
--rw=rw --stonewall --name=rand-readwrite --rw=randrw --stonewall
(10MB zram raw block device, take the average of 10 tests, KB/s)
Test base CASspinlockrwlock bit_spinlock
-
seq-write 933789 999357 1003298995961 1001958
seq-read 5634130 6577930 6380861 6243912 6230006
seq-rw 1405687 1638117 1640256 1633903 1634459
rand-rw 1386119 1614664 1617211 1609267 1612471
All the optimization methods show a higher performance than the base,
however, it is hard to say which method is the most appropriate.
On the other hand, zram is mostly used on small embedded system, so we
don't want to increase any memory footprint.
This patch pick the bit_spinlock method, pack object size and page_flag
into an unsigned long table.value, so as to not increase any memory
overhead on both 32-bit and 64-bit system.
On the third hand, even though different kinds of locks have different
performances, we can ignore this difference, because:
if zram is used as zram swapfile, the swap subsystem can prevent concurrent
access to the same swapslot;
if zram is used as zram-blk for set up filesystem on it, the upper filesystem
and the page cache also prevent concurrent access of the same block mostly.
So we can ignore the different performances among locks.
Changes since v1: https://lkml.org/lkml/2014/5/5/1
- replace CAS method with bit_spinlock method
- rename zram_test_flag() to zram_test_zero()
- add some comments
- change the patch subject
Signed-off-by: Weijie Yang weijie.y...@samsung.com
---
drivers/block/zram/zram_drv.c | 84 +++--
drivers/block/zram/zram_drv.h | 22 ---
2 files changed, 63 insertions(+), 43 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9849b52..81f2b3e 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -179,23 +179,32 @@ static ssize_t comp_algorithm_store(struct device *dev,
return len;
}
-/* flag operations needs meta-tb_lock */
-static int zram_test_flag(struct zram_meta *meta, u32 index,
- enum zram_pageflags flag)
+static int zram_test_zero(struct zram_meta *meta, u32 index)
{
- return meta-table[index].flags BIT(flag);
+ return meta-table[index].value BIT(ZRAM_ZERO);
}
-static void zram_set_flag(struct zram_meta *meta, u32 index,
- enum zram_pageflags flag)
+static void zram_set_zero(struct zram_meta *meta, u32 index)
{
- meta-table[index].flags |= BIT(flag);
+ meta-table[index].value |= BIT(ZRAM_ZERO);
}
-static void zram_clear_flag(struct zram_meta *meta, u32 index,
- enum zram_pageflags flag)
+static void zram_clear_zero(struct zram_meta *meta, u32 index)
{
-
Re: [PATCH 00/34] perf and kconfig / kbuild
On Wed, May 14, 2014 at 12:02:55AM +0200, Alexis Berlemont wrote: Hello, A few months ago, I tried to make a proposal to introduce Kconfig in perf's generation procedure. (cf. https://lkml.org/lkml/2013/12/20/511) I started from David Ahern's work; I was not aware that Jiri Olsa pushed further the idea and proposed an alternative which integrated kbuild too. hi, I'll try to review this till end of the week thanks, jirka So, here is another proposal based on Jiri Olsa work (from April 2013). * Most of the NO_* and HAVE_* makefile variables were removed on behalf of Kconfig's ones (CONFIG_*); perf source code was modified accordingly; * These changes make the glue files tools/perf/config/Makefile.fix-* useless * The build test cases now relies on generated configuration files (in tools/perf/tests/configs); Hope this helps, Alexis. Alexis Berlemont (29): perf kbuild: fix recursive invocation of config/features-checks perf kbuild: store in config-detected missing variables (libdir, ...) perf kbuild: remove useless #ifdef directives perf kbuild: fix a link issue if BUILTIN_TRACE is disabled perf kbuild: add missing files and missing flags in Kbuild files perf kbuild: update kbuild files according to last changes perf kbuild: remove legacy slang-related build variables perf kbuild: remove legacy libaudit-related build variables perf kbuild: remove legacy libgtk2-related build variables perf kbuild: remove legacy libperl-related build variables perf kbuild: remove legacy timerfd-related build variable perf kbuild: remove legacy demangle-related build variables perf kbuild: remove legacy on_exit-related build variable perf kbuild: remove legacy backtrace-related build variable perf kbuild: remove legacy numa-related build variable perf kbuild: remove legacy bionic-related build variable perf kbuild: remove legacy libelf-related build variables (1st part) perf kbuild: remove legacy libelf-related build variables (2nd part) perf kbuild: remove legacy libdwarf-related build variables perf kbuild: remove legacy libunwind-related build variables perf kbuild: remove legacy libpython-related build variable perf kbuild: add generated Kconfig build-test cases perf kbuild: fix installation of traceevent plugins perf kbuild: fix tarpkg target in tests/make perf kbuild: update Kbuild files with new and removed sources perf kbuild: update build test configurations perf kbuild: relocate the configs generating script perf kbuild: minor changes perf kbuild: remove Makefile.perf Jiri Olsa (5): kbuild: Introduce KBUILD_AUTOCONF variable for auto.conf include kbuild: Introduce KCONFIG_AUTOCONFIGDEP variable for conf tool perf tools: Kbuild builtin source related fixies perf tools: Kbuild source related fixies perf tools: Add kbuild support into Makefile.kbuild scripts/Makefile.build | 3 +- scripts/kconfig/confdata.c | 11 +- scripts/kconfig/lkc.h | 1 + tools/perf/Kbuild | 47 ++ tools/perf/Kconfig | 370 tools/perf/MANIFEST| 1 + tools/perf/Makefile| 2 +- tools/perf/Makefile.kbuild | 414 + tools/perf/Makefile.perf | 930 - tools/perf/arch/Kbuild | 3 + tools/perf/arch/arm/Makefile | 4 +- tools/perf/arch/powerpc/Makefile | 2 +- tools/perf/arch/s390/Makefile | 2 +- tools/perf/arch/sh/Makefile| 2 +- tools/perf/arch/sparc/Makefile | 2 +- tools/perf/arch/x86/Kbuild | 2 + tools/perf/arch/x86/Makefile | 8 +- tools/perf/arch/x86/tests/Kbuild | 2 + tools/perf/arch/x86/util/Kbuild| 5 + tools/perf/bench/Kbuild| 12 + tools/perf/builtin-annotate.c | 8 +- tools/perf/builtin-bench.c | 5 +- tools/perf/builtin-cmds.h | 31 + tools/perf/builtin-help.c | 1 + tools/perf/builtin-inject.c| 2 +- tools/perf/builtin-kvm.c | 32 +- tools/perf/builtin-lock.c | 4 +- tools/perf/builtin-mem.c | 3 +- tools/perf/builtin-probe.c | 15 +- tools/perf/builtin-record.c| 14 +- tools/perf/builtin-report.c| 3 + tools/perf/builtin-sched.c | 2 + tools/perf/builtin-script.c| 6
Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity
On Wed, May 14, 2014 at 05:17:35PM -0400, Carlos O'Donell wrote: No, its perfectly fine to have a lock sequence abort with -EDEADLK. Userspace should release its locks and re-attempt. I agree. If I can prove that it's actually a deadlock, and that unlock/relock will work to fix it, then we can arrange for glibc to return EDEADLK. The only reason the kernel would return EDEADLK is because its walked the lock graph and determined its well, a deadlock. pgpidh7TjCYWZ.pgp Description: PGP signature
Re: futex(2) man page update help request
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote: On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote: However, unless I'm sorely mistaken, the larger problem is that glibc removed the futex() call entirely, so these man pages don't describe I don't think futex() ever was in glibc--that's by design, and completely understandable: no user-space application would want to directly use futex(). (BTW, I mispoke in my earlier mail when I said I wanted documentation suitable for writers of library functions -- I meant suitable for writers of *C library*.) I fully agree with Michael here. The futex() syscall was never exposed to userspace specifically because it was an interface we did not want to support forever with a stable ABI. The futex() syscall is an implementation detail that is shared between the kernel and the writers of core runtimes for Linux. That ship has sailed.. for one we must always support old glibc which uses the futex() syscall, and secondly there are known other programs that actually use the futex syscall. So that's really a non-argument, we're hard tied to the ABI. pgpcZdphnfUtn.pgp Description: PGP signature
Re: futex(2) man page update help request
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote: There are other syscalls like gettid() that have a: NOTE: There is no glibc wrapper for this system call; see NOTES. Yes, can we finally fix that please? It gets tedious having to endlessly copy/paste that thing around. pgp1M1syNrefX.pgp Description: PGP signature
Re: [cgroup] a0f9ec1f181: -4.3% will-it-scale.per_thread_ops
On Thu, May 15, 2014 at 02:14:22AM -0400, Tejun Heo wrote: Hello, Fengguang. On Thu, May 15, 2014 at 02:00:26PM +0800, Fengguang Wu wrote: 2074b6e38668e62 a0f9ec1f181534694cb5bf40b --- - 2074b6e38668e62 is the base of comparison. So -4.3% will-it-scale.per_thread_ops in the below line means a0f9ec1f18 has lower will-it-scale throughput. 1027273 ~ 0% -4.3% 982732 ~ 0% TOTAL will-it-scale.per_thread_ops 136 ~ 3% -43.1% 77 ~43% TOTAL proc-vmstat.nr_dirtied 0.51 ~ 3% +98.0% 1.01 ~ 4% TOTAL perf-profile.cpu-cycles.shmem_write_end.generic_perform_write.__generic_file_aio_write.generic_file_aio_write.do_sync_write 1078 ~ 9% -16.3%903 ~11% TOTAL numa-meminfo.node0.Unevictable 269 ~ 9% -16.2%225 ~11% TOTAL numa-vmstat.node0.nr_unevictable 1.64 ~ 1% -14.3% 1.41 ~ 4% TOTAL perf-profile.cpu-cycles.find_lock_entry.shmem_getpage_gfp.shmem_write_begin.generic_perform_write.__generic_file_aio_write 1.62 ~ 2% +14.1% 1.84 ~ 1% TOTAL perf-profile.cpu-cycles.lseek64 The perf-profile.cpu-cycles.* lines are from perf record/report. The last line shows that lseek64() takes 1.62% CPU cycles for commit 2074b6e38668e62 and that percent increased by +14.1% on a0f9ec1f181. One of the raw perf record output is 1.84% writeseek_proce libc-2.17.so [.] lseek64 | --- lseek64 There are 5 runs and 1.62% is the average value. I have no idea how to read the above. Which direction is plus and which is minus? Are they counting cpu cycles? Which files is the test seeking? It's tmpfs files. Because the will-it-scale test case is mean to measure scalability of syscalls. We do not use HDD/SSD etc. storage devices when running it. Hmmm... I'm completely stumped. The commit in question has nothing to do with tmpfs. It only affects three cgroup files - tasks, cgroup.procs and release_agent. It can't possibly have any effect on tmpfs operation. Maybe random effect through code alignment? Even that is highly unlikely. I'll look into it tomorrow but can you please try to repeat the test? It really doesn't make any sense to me. Yes, sorry! Even though the first bad commit a0f9ec1f1 and its parent commit 2074b6e38 has clear and stable performance changes: 5 runs of a0f9ec1f1: will-it-scale.per_thread_ops: [ 983098, 985112, 982690, 976157, 986606 ], 5 runs of 2074b6e38: will-it-scale.per_thread_ops: [ 1027667, 1029414, 1026736, 1025678, 1026871 ], Comparing the bisect-good and bisect-bad *kernels*, you'll find the performance changes are not as stable: will-it-scale.per_thread_ops 1.14e+06 ++---+ 1.12e+06 ++ *.. | | : *| 1.1e+06 ++ :: | 1.08e+06 ++ : : | | : : | 1.06e+06 ++: : | 1.04e+06 *+.*...*..*..*..*...*..*..::..*..*.. | 1.02e+06 ++ O *..* *..*.*..*...*..*..* | O O | 1e+06 O+ O O O O O| 98 ++ O OO O O O O | || 96 ++ O O | 94 ++---+ [*] bisect-good sample [O] bisect-bad sample So it might be some subtle data padding/alignment issue. Thanks, Fengguang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 06/10] usb: xhci: Add Tegra XHCI host-controller driver
On Wednesday 14 May 2014 17:33:02 Andrew Bresticker wrote:
+
+int tegra_xhci_register_mbox_notifier(struct notifier_block *nb)
+{
+ int ret;
+
+ mutex_lock(tegra_xhci_mbox_lock);
+ ret = raw_notifier_chain_register(tegra_xhci_mbox_notifiers, nb);
+ mutex_unlock(tegra_xhci_mbox_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(tegra_xhci_register_mbox_notifier);
+
+void tegra_xhci_unregister_mbox_notifier(struct notifier_block *nb)
+{
+ mutex_lock(tegra_xhci_mbox_lock);
+ raw_notifier_chain_unregister(tegra_xhci_mbox_notifiers, nb);
+ mutex_unlock(tegra_xhci_mbox_lock);
+}
+EXPORT_SYMBOL(tegra_xhci_unregister_mbox_notifier);
What driver would use these?
My feeling is that if you have a mailbox that is used by multiple
drivers, you should use a proper mailbox driver to operate them,
and have the drivers register with that API instead of a custom one.
+ /* Create child xhci-plat device */
+ memset(xhci_resources, 0, sizeof(xhci_resources));
+ res = platform_get_resource(to_platform_device(dev), IORESOURCE_IRQ, 0);
+ if (!res) {
+ dev_err(dev, Missing XHCI IRQ\n);
+ ret = -ENODEV;
+ goto out;
+ }
+ xhci_resources[0].start = res-start;
+ xhci_resources[0].end = res-end;
+ xhci_resources[0].flags = res-flags;
+ xhci_resources[0].name = res-name;
+ res = platform_get_resource(to_platform_device(dev), IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, Missing XHCI registers\n);
+ ret = -ENODEV;
+ goto out;
+ }
+ xhci_resources[1].start = res-start;
+ xhci_resources[1].end = res-end;
+ xhci_resources[1].flags = res-flags;
+ xhci_resources[1].name = res-name;
+
+ xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
+ if (!xhci) {
+ dev_err(dev, Failed to allocate XHCI host\n);
+ ret = -ENOMEM;
+ goto out;
+ }
This does not feel appropriate at all: Rather than creating a child device,
you should have a specific driver that hooks into functions exported
by the xhci core. See Documentation/driver-model/design-patterns.txt
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] phy: Add exynos-simple-phy driver
On 15 May 2014 13:12, Thierry Reding thierry.red...@gmail.com wrote: On Thu, May 15, 2014 at 10:49:37AM +0530, Rahul Sharma wrote: Hi Thierry, On 15 May 2014 03:44, Thierry Reding thierry.red...@gmail.com wrote: On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote: [...] +#define HDMI_PHY 0 +#define DAC_PHY 1 +#define ADC_PHY 2 +#define PCIE_PHY 3 +#define SATA_PHY 4 Perhaps these should be namespaced somehow to avoid potential conflicts with other PHY providers? How about XXX_SIMPLE_PHY? The indices are specific to the Exynos PHY device, so why not PHY_EXYNOS_SIMPLE_XXX (or any variation thereof)? This looks ok. I will use that. +#define PHY_NR 5 I'm not sure that this belongs here either. It's not a value that will ever appear in a DT source file. I want it to grow along with new additions in the phy list else catastrophic. This will look unrelated in driver. But this is in no way growing automatically as it is. Whoever adds a new type of PHY will need to manually increment this define. Furthermore the driver will need to be updated to cope with this anyway. Not automatically. What I meant was If keeping it at end of the list, it is not possible that somebody skip the updation of PHY_NR when adding a new phy type. If I leave a comment at the end of the list to update PHY_NR (after moving it to driver), that also serves the purpose. I think this is even a reason to have this only in the driver. Otherwise you could have a situation where somebody upgrades the binding (and this file along with it) but not update the driver with the necessary support. But the driver will still pick up the PHY_NR change and will accept the new PHY type as valid, even though it has no code to handle it. If you have this in the driver, however, then as long as the driver has not yet been updated it will reject requests for the new PHY type. And that's exactly what it should be doing since it doesn't know how to handle it. hmn...Ok. Regards, Rahul Sharma Thierry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
On 05/15/2014 11:01 AM, Arnd Bergmann wrote: On Tuesday 13 May 2014 13:30:30 Peter Ujfalusi wrote: From CCCFG register of eDMA3 we can get all the needed information for the driver about the IP: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE The ti,edma-regions; ti,edma-slots and dma-channels in DT are redundant since the very same information can be obtained from the HW. The mentioned properties can be removed from the binding document. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com I wonder if we should keep them listed as optional properties so you can have a dtb file that still works with older kernels which need them. What you do is an incompatible change to the binding, which we shouldn't do lightly. Any new dts files don't need this information of course, but as a general rule, I'd rather keep things like this around unless we already have to enforce an ABI break that is well documented. We could keep them as optional, or to be precise: ignored properties since we are not going to even look at them in the future. But I do not really see the reason to do so. With this change new kernels will boot with old DTB - if it can not be changed which I have not seen yet. Sure old kernel would not boot with this change, but why would you downgrade the kernel and update the DTB on a board? Bisecting is not a good reason since the bug you might be hunting for could be in the DTS or in the kernel code so you need to update both of them to be sure you reach the commit you are looking for. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: futex(2) man page update help request
On Wed, May 14, 2014 at 10:21:52PM -0700, Darren Hart wrote:
On 5/14/14, 17:18, H. Peter Anvin h...@zytor.com wrote:
On 05/14/2014 09:18 AM, Darren Hart wrote:
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
something users even have access to anymore. I had to revert to calling
the syscalls directly in the futextest test suite because of this:
http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git/tree/inc
lu
de/futextest.h#n67
This really comes down to the fact that we should have a libinux which
contains the basic system call wrapper machinery for Linux specific
things and nothing else.
syscall(3) is toxic and breaks randomly on some platforms.
Peter Z and I have had a good time discussing this in the past And
here it is again. :-)
Oh but we wanted _way_ more than bare syscalls in there ;-)
For a start we wanted to make the vDSO a proper DSO that gets included
in the (dynamic) link chain.
/sys/lib/libdso{32,64}.so like
That would also allow all those archs that expose raw dso function
pointers for things like cmpxchg or memory barriers to just provide
platform functions instead, far more usable.
And yes, we wanted to hijack libpthread in order to finally fix the
futex mess :-)
pgpo_DNKkeif7.pgp
Description: PGP signature
Re: [PATCH 05/27] arc: Use common bits from generic tlb.h
Hi Richard,
On Thursday 15 May 2014 12:29 AM, Richard Weinberger wrote:
It is no longer needed to define them on our own.
Cc: Vineet Gupta vgu...@synopsys.com
Cc: Richard Weinberger rich...@nod.at
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Richard Weinberger rich...@nod.at
Thx for the series.
Acked-by: Vineet Gupta vgu...@synopsys.com
---
arch/arc/include/asm/tlb.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arc/include/asm/tlb.h b/arch/arc/include/asm/tlb.h
index a9db5f6..a0fa06d 100644
--- a/arch/arc/include/asm/tlb.h
+++ b/arch/arc/include/asm/tlb.h
@@ -23,9 +23,7 @@ do {\
*
* Note, read http://lkml.org/lkml/2004/1/15/6
*/
-#ifndef CONFIG_ARC_CACHE_VIPT_ALIASING
-#define tlb_start_vma(tlb, vma)
-#else
+#ifdef CONFIG_ARC_CACHE_VIPT_ALIASING
#define tlb_start_vma(tlb, vma)
\
do { \
if (!tlb-fullmm) \
@@ -39,8 +37,6 @@ do {
\
flush_tlb_range(vma, vma-vm_start, vma-vm_end); \
} while (0)
-#define __tlb_remove_tlb_entry(tlb, ptep, address)
-
#include linux/pagemap.h
#include asm-generic/tlb.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Collecting data to demonstrate TCP ISN-based port knocking
Hello, On 14/05/14 - 21:55:36, Julian Kirsch wrote: some of you might remember the proposal of a patch which implements a variant of port-knocking that can be used to check the authenticity of arbitrary TCP connections and even can do integrity checking of TCP payload data by using a pre-shared key [0]. This patch, as well as a research paper describing its inner workings are available on gnunet.org under the name Knock [1]. As Knock uses two fields in the TCP header in order to hide information and we explicitly want to be compatible with machines sitting in typical home networks, we need to make sure that this information doesn't get corrupted by the majority of NAT boxes out there. The lack of hard data on this also was one of the objections when the patch was submitted last time. We thus created a program which tests if Knock could work in your environment. It would be greatly appreciated if some of you were able to execute the program on their machines in order to help us to get an estimation of if Knock one day could be used in a large scale. have you looked at http://www.eecs.berkeley.edu/~sylvia/cs268-2014/papers/deploytcp-imc11.pdf ? Michio started a second larger measurement campaign 2 years ago. You might ask him if he has more data now. Cheers, Christoph -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity
On Wed, May 14, 2014 at 04:59:58PM -0400, Carlos O'Donell wrote: I will make my personal opinion clear: - Internal defects should raise immediate assertions. - Real problems like resource availability, deadlocks, and other recoverable errors should result in the API returning an appropriate error code that must not diverge from the POSIX definitions for those codes (when such a definition exists). I'm not a believer in only the hot path matters, there are such things as robustness and error detection, and they matter. Awesome. In case of doubt though, I would prefer a return to an assert, just in case userspace actually does know wtf its doing ;-) Granted, that seems to be very rare, but still, its entirely annoying for those few people who do care to get dead programs. Alternatively, we could have something like you have for the allocator (which is, afaik, also considered a hot path) these env variables like MALLOC_CHECK_ to influence this edge behaviour. pgpESU9MmalQX.pgp Description: PGP signature
Re: [PATCH v2 2/3] drm/panel: add support for EDT panels
Hi Thierry, hi Philipp, Am 2014-05-15 09:51, schrieb Thierry Reding: On Wed, May 14, 2014 at 11:45:57PM +0200, ste...@agner.ch wrote: From: Stefan Agner ste...@agner.ch This panels are sold by Toradex for Colibri T20/T30 and Apalis T30 evaluation kits. Signed-off-by: Stefan Agner ste...@agner.ch Panel patches should go to the dri-devel mailing list as well. Also a patch was posted only yesterday for a panel that seems to be the exact same one as this, even though the name differs minimally, see: https://patchwork.kernel.org/patch/4175251/ Adding Philipp on Cc so you guys can work together whether this is indeed the same panel. The only differences seem to be in the vertical front and back porches, but I suspect that either settings will work on both Tegra and i.MX. Its etm0700g0dh6 vs. et070080dh6, Philipp's panel is with captive multi touch, (hence the M I guess). The panel itself really looks the same. I found this overview of EDT displays: http://www.dmbtechnics.com/scripts/passthru.php?id=7 There seem to be quite a lot variants with the same panel... Regarding timings, I just checked the documentation, Philipp's timing really matches the documented ones, I miscalculated the vertical back porch. How do we resolve that? I would suggest that I split out that patch and remove the et070080dh6 panel and send the other as a single patch to the dri-devel mailing list as well. Philipp, could you add my display type (et070080dh6) to the compatible list of your mode/panel entry? Does this sound reasonable? -- Stefan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
Hi Ingo, Do you have any comments for the latest version of the patchset. If not, kindly can you pick it up as is. With regards Maddy Kirill A. Shutemov with 8c6e50b029 commit introduced vm_ops-map_pages() for mapping easy accessible pages around fault address in hope to reduce number of minor page faults. This patch creates infrastructure to modify the FAULT_AROUND_ORDER value using mm/Kconfig. This will enable architecture maintainers to decide on suitable FAULT_AROUND_ORDER value based on performance data for that architecture. First patch also defaults FAULT_AROUND_ORDER Kconfig element to 4. Second patch list out the performance numbers for powerpc (platform pseries) and initialize the fault around order variable for pseries platform of powerpc. V4 Changes: Replaced the BUILD_BUG_ON with VM_BUG_ON. Moved fault_around_pages() and fault_around_mask() functions outside of #ifdef CONFIG_DEBUG_FS. V3 Changes: Replaced FAULT_AROUND_ORDER macro to a variable to support arch's that supports sub platforms. Made changes in commit messages. V2 Changes: Created Kconfig parameter for FAULT_AROUND_ORDER Added check in do_read_fault to handle FAULT_AROUND_ORDER value of 0 Made changes in commit messages. Madhavan Srinivasan (2): mm: move FAULT_AROUND_ORDER to arch/ powerpc/pseries: init fault_around_order for pseries arch/powerpc/platforms/pseries/pseries.h |2 ++ arch/powerpc/platforms/pseries/setup.c |5 + mm/Kconfig |8 mm/memory.c | 25 ++--- 4 files changed, 21 insertions(+), 19 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/
