[PATCH] pinctrl: tegra: correct bank for pingroup and drv pingroup
Signed-off-by: Pritesh Raithatha
---
drivers/pinctrl/pinctrl-tegra30.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-tegra30.c
b/drivers/pinctrl/pinctrl-tegra30.c
index 0386fdf..7894f14 100644
--- a/drivers/pinctrl/pinctrl-tegra30.c
+++ b/drivers/pinctrl/pinctrl-tegra30.c
@@ -3345,10 +3345,10 @@ static const struct tegra_function tegra30_functions[]
= {
FUNCTION(vi_alt3),
};
-#define MUXCTL_REG_A 0x3000
-#define PINGROUP_REG_A 0x868
+#define DRV_PINGROUP_REG_A 0x868 /* bank 0 */
+#define PINGROUP_REG_A 0x3000 /* bank 1 */
-#define PINGROUP_REG_Y(r) ((r) - MUXCTL_REG_A)
+#define PINGROUP_REG_Y(r) ((r) - PINGROUP_REG_A)
#define PINGROUP_REG_N(r) -1
#define PINGROUP(pg_name, f0, f1, f2, f3, f_safe, r, od, ior) \
@@ -3364,25 +3364,25 @@ static const struct tegra_function tegra30_functions[]
= {
}, \
.func_safe = TEGRA_MUX_ ## f_safe, \
.mux_reg = PINGROUP_REG_Y(r), \
- .mux_bank = 0, \
+ .mux_bank = 1, \
.mux_bit = 0, \
.pupd_reg = PINGROUP_REG_Y(r), \
- .pupd_bank = 0, \
+ .pupd_bank = 1, \
.pupd_bit = 2, \
.tri_reg = PINGROUP_REG_Y(r), \
- .tri_bank = 0, \
+ .tri_bank = 1, \
.tri_bit = 4, \
.einput_reg = PINGROUP_REG_Y(r),\
- .einput_bank = 0, \
+ .einput_bank = 1, \
.einput_bit = 5,\
.odrain_reg = PINGROUP_REG_##od(r), \
- .odrain_bank = 0, \
+ .odrain_bank = 1, \
.odrain_bit = 6,\
.lock_reg = PINGROUP_REG_Y(r), \
- .lock_bank = 0, \
+ .lock_bank = 1, \
.lock_bit = 7, \
.ioreset_reg = PINGROUP_REG_##ior(r), \
- .ioreset_bank = 0, \
+ .ioreset_bank = 1, \
.ioreset_bit = 8, \
.drv_reg = -1, \
}
@@ -3401,8 +3401,8 @@ static const struct tegra_function tegra30_functions[] = {
.odrain_reg = -1, \
.lock_reg = -1, \
.ioreset_reg = -1, \
- .drv_reg = ((r) - PINGROUP_REG_A), \
- .drv_bank = 1, \
+ .drv_reg = ((r) - DRV_PINGROUP_REG_A), \
+ .drv_bank = 0, \
.hsm_bit = hsm_b, \
.schmitt_bit = schmitt_b, \
.lpmd_bit = lpmd_b, \
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/2] Reset PCIe devices to address DMA problem on kdump with iommu
These patches reset PCIe devices at boot time to address DMA problem on
kdump with iommu. When "reset_devices" is specified, a hot reset is
triggered on each PCIe root port and downstream port to reset its
downstream endpoint.
Background:
A kdump problem about DMA has been discussed for a long time. That is,
when a kernel is switched to the kdump kernel DMA derived from first
kernel affects second kernel. Recently this problem surfaces when iommu
is used for PCI passthrough on KVM guest. In the case of the machine I
use, when intel_iommu=on is specified, DMAR error is detected in kdump
kernel and PCI SERR is also detected. Finally kdump fails because some
devices does not work correctly.
The root cause is that ongoing DMA from first kernel causes DMAR fault
because page table of DMAR is initialized while kdump kernel is booting
up. Therefore to address this problem DMA needs to be stopped before
DMAR is initialized at kdump kernel boot time. By these patches, PCIe
devices are reset by hot reset and its DMA is stopped when reset_devices
is specified. One problem of this solution is that the monitor blacks
out when VGA controller is reset. So this patch does not reset the port
whose child endpoint is VGA device.
What I tried:
- Clearing bus master bit and INTx disable bit at boot time
This did not solve this problem. I still got DMAR error on devices.
- Resetting devices in fixup_final(v1 patch)
DMAR error disappeared, but sometimes PCI SERR was detected. This
is well explained here.
https://lkml.org/lkml/2012/9/9/245
This PCI SERR seems to be related to interrupt remapping.
- Clearing bus master in setup_arch() and resetting devices in
fixup_final
Neither DMAR error nor PCI SERR occurred. But on certain machine
kdump kernel hung up when resetting devices. It seems to be a
problem specific to the platform.
- Resetting devices in setup_arch() (v2 and later patch)
This solution solves all problems I found so far.
v5:
Do bus reset after all devices are scanned and its config registers are
saved. This fixes a bug that config register is accessed without delay
after reset.
v4:
Reduce waiting time after resetting devices. A previous patch does reset
like this:
for (each device) {
save config registers
reset
wait for 500 ms
restore config registers
}
If there are N devices to be reset, it takes N*500 ms. On the other
hand, the v4 patch does:
for (each device) {
save config registers
reset
}
wait 500 ms
for (each device) {
restore config registers
}
Though it needs more memory space to save config registers, the waiting
time is always 500ms.
https://lkml.org/lkml/2012/10/15/49
v3:
Move alloc_bootmem and free_bootmem to early_reset_pcie_devices so that
they are called only once.
https://lkml.org/lkml/2012/10/10/57
v2:
Reset devices in setup_arch() because reset need to be done before
interrupt remapping is initialized.
https://lkml.org/lkml/2012/10/2/54
v1:
Add fixup_final quirk to reset PCIe devices
https://lkml.org/lkml/2012/8/3/160
Thanks,
Takao Indoh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 2/2] x86, pci: Enable PCI INTx when MSI is disabled
This patch enables INTx if MSI is disabled in pcibios_enable_device().
In normal case interrupt disable bit in command register is 0b on boot
time, but in case of kdump, this bit may be 1b. It causes problems of
some drivers. At leaset I confirmed mptsas driver does not work in such
a case. This patch fix this problem.
Signed-off-by: Takao Indoh
---
arch/x86/pci/common.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 720e973..2bb7ecc 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -615,8 +615,10 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
if ((err = pci_enable_resources(dev, mask)) < 0)
return err;
- if (!pci_dev_msi_enabled(dev))
+ if (!pci_dev_msi_enabled(dev)) {
+ pci_intx(dev, true);
return pcibios_enable_irq(dev);
+ }
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/2] x86, pci: Reset PCIe devices at boot time
This patch resets PCIe devices at boot time by hot reset when
"reset_devices" is specified.
Signed-off-by: Takao Indoh
---
arch/x86/include/asm/pci-direct.h |1
arch/x86/kernel/setup.c |3
arch/x86/pci/early.c | 353
include/linux/pci.h |2
init/main.c |4
5 files changed, 361 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pci-direct.h
b/arch/x86/include/asm/pci-direct.h
index b1e7a45..de30db2 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -18,4 +18,5 @@ extern int early_pci_allowed(void);
extern unsigned int pci_early_dump_regs;
extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
extern void early_dump_pci_devices(void);
+extern void early_reset_pcie_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index a2bb18e..73d3425 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -987,6 +987,9 @@ void __init setup_arch(char **cmdline_p)
generic_apic_probe();
early_quirks();
+#ifdef CONFIG_PCI
+ early_reset_pcie_devices();
+#endif
/*
* Read APIC and some other early information from ACPI tables.
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index d1067d5..df7f4fc 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -1,5 +1,6 @@
#include
#include
+#include
#include
#include
#include
@@ -109,3 +110,355 @@ void early_dump_pci_devices(void)
}
}
}
+
+#define PCI_EXP_SAVE_REGS 7
+#define pcie_cap_has_devctl(type, flags) 1
+#define pcie_cap_has_lnkctl(type, flags) \
+ ((flags & PCI_EXP_FLAGS_VERS) > 1 ||\
+(type == PCI_EXP_TYPE_ROOT_PORT || \
+ type == PCI_EXP_TYPE_ENDPOINT || \
+ type == PCI_EXP_TYPE_LEG_END))
+#define pcie_cap_has_sltctl(type, flags) \
+ ((flags & PCI_EXP_FLAGS_VERS) > 1 ||\
+((type == PCI_EXP_TYPE_ROOT_PORT) || \
+ (type == PCI_EXP_TYPE_DOWNSTREAM && \
+ (flags & PCI_EXP_FLAGS_SLOT
+#define pcie_cap_has_rtctl(type, flags)\
+ ((flags & PCI_EXP_FLAGS_VERS) > 1 ||\
+(type == PCI_EXP_TYPE_ROOT_PORT || \
+ type == PCI_EXP_TYPE_RC_EC))
+
+struct save_config {
+ u32 pci[16];
+ u16 pcie[PCI_EXP_SAVE_REGS];
+};
+
+struct pcie_dev {
+ int cap; /* position of PCI Express capability */
+ int flags; /* PCI_EXP_FLAGS */
+ struct save_config save; /* saved configration register */
+};
+
+struct pcie_port {
+ struct list_head dev;
+ u8 bus;
+ u8 slot;
+ u8 func;
+ u8 secondary;
+ struct pcie_dev child[PCI_MAX_FUNCTIONS];
+};
+
+static LIST_HEAD(device_list);
+static void __init pci_udelay(int loops)
+{
+ while (loops--) {
+ /* Approximately 1 us */
+ native_io_delay();
+ }
+}
+
+/* Derived from drivers/pci/pci.c */
+#define PCI_FIND_CAP_TTL 48
+static int __init __pci_find_next_cap_ttl(u8 bus, u8 slot, u8 func,
+ u8 pos, int cap, int *ttl)
+{
+ u8 id;
+
+ while ((*ttl)--) {
+ pos = read_pci_config_byte(bus, slot, func, pos);
+ if (pos < 0x40)
+ break;
+ pos &= ~3;
+ id = read_pci_config_byte(bus, slot, func,
+ pos + PCI_CAP_LIST_ID);
+ if (id == 0xff)
+ break;
+ if (id == cap)
+ return pos;
+ pos += PCI_CAP_LIST_NEXT;
+ }
+ return 0;
+}
+
+static int __init __pci_find_next_cap(u8 bus, u8 slot, u8 func, u8 pos, int
cap)
+{
+ int ttl = PCI_FIND_CAP_TTL;
+
+ return __pci_find_next_cap_ttl(bus, slot, func, pos, cap, &ttl);
+}
+
+static int __init __pci_bus_find_cap_start(u8 bus, u8 slot, u8 func,
+ u8 hdr_type)
+{
+ u16 status;
+
+ status = read_pci_config_16(bus, slot, func, PCI_STATUS);
+ if (!(status & PCI_STATUS_CAP_LIST))
+ return 0;
+
+ switch (hdr_type) {
+ case PCI_HEADER_TYPE_NORMAL:
+ case PCI_HEADER_TYPE_BRIDGE:
+ return PCI_CAPABILITY_LIST;
+ case PCI_HEADER_TYPE_CARDBUS:
+ return PCI_CB_CAPABILITY_LIST;
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+
+static int __init early_pci_find_capability(u8 bus, u8 slot, u8 func, int cap)
+{
+ int pos;
+ u8 type = read_pci_config_byte(bus, slot, func, PCI_HEADER_TYPE);
+
+ pos = __pci_bus_find_cap_start(bus, slot, func, type & 0x7f);
+ if (pos)
+ pos = __pci_find_next_
Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e)
On 09/14/2012 01:57 PM, Xiao Guangrong wrote: > On 09/12/2012 04:15 PM, Avi Kivity wrote: >> On 09/12/2012 07:40 AM, Fengguang Wu wrote: >>> Hi, >>> >>> 3 of my test boxes running v3.5 kernel become unaccessible and I find >>> two of them kept emitting this dmesg: >>> >>> vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit >>> reason is 0x31 >>> >>> The other one has froze and the above lines are the last dmesg. >>> Any ideas? >> >> First, that printk should be rate-limited. >> >> Second, we should add EXIT_REASON_EPT_MISCONFIG (0x31) to >> >> if ((vectoring_info & VECTORING_INFO_VALID_MASK) && >> (exit_reason != EXIT_REASON_EXCEPTION_NMI && >> exit_reason != EXIT_REASON_EPT_VIOLATION && >> exit_reason != EXIT_REASON_TASK_SWITCH)) >> printk(KERN_WARNING "%s: unexpected, valid vectoring info " >> "(0x%x) and exit reason is 0x%x\n", >> __func__, vectoring_info, exit_reason); >> >> since it's easily caused by the guest. > > Yes, i will do these. > >> >> Third, it's really unexpected. It seems the guest was attempting to deliver >> a page fault exception (0x0e) but encountered an mmio page during delivery >> (in the IDT, TSS, stack, or page tables). Is this reproducible? If so it's >> easy to patch kvm to halt in that case and allow examining the guest via >> qemu. >> > > Have no idea yet why the box was frozen under this case, will try to write a > test case, > hope it can help me to find the reason out. > Still did not know why linux kernel triggered it. I have posted a patchset to report an internal error for this case, hoping Fengguang can reproduce it after the patchset and Qemu's dump can help us to find the reason out. I will keep working on it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cpufreq: Improve debug prints
On Wed, 2012-10-17 at 11:47 +0530, Viresh Kumar wrote: > On 17 October 2012 11:34, Joe Perches wrote: > > I believe you are quoting KBUILD_MODNAME > > Yes. :( > Far better output with this. Thanks. Oh good, but please use a space between KBUILD_MODNAME and the quoted ": ". #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt look at: $ git grep -E -h "pr_fmt.*KBUILD_MODNAME" *|sort|uniq -c|sort -rn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] qla3xxx: Ensure req_q_phy_addr writes to the register
Make sure req_q_phy_addr write to the register. Signed-off-by: Joe Jin Cc: Ron Mercer Cc: Jitendra Kalsaria --- drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c index df09b1c..78b4cba 100644 --- a/drivers/net/ethernet/qlogic/qla3xxx.c +++ b/drivers/net/ethernet/qlogic/qla3xxx.c @@ -2525,6 +2525,12 @@ static int ql_alloc_net_req_rsp_queues(struct ql3_adapter *qdev) qdev->req_q_size = (u32) (NUM_REQ_Q_ENTRIES * sizeof(struct ob_mac_iocb_req)); + /* +* The barrier is required to ensure that req_q_phy_addr writes to +* the memory. +*/ + wmb(); + qdev->req_q_virt_addr = pci_alloc_consistent(qdev->pdev, (size_t) qdev->req_q_size, -- 1.7.11.7
Re: [PATCH 1/2] cpufreq: Improve debug prints
On 17 October 2012 11:56, Joe Perches wrote: > Oh good, but please use a space between KBUILD_MODNAME > and the quoted ": ". Anything technical behind it or just for code formatting? As output is same in both cases :) 8<--8<--- From: Viresh Kumar Date: Wed, 17 Oct 2012 10:38:31 +0530 Subject: [PATCH] cpufreq: Improve debug prints With debug options on, it is difficult to locate cpufreq core's debug prints. Fix this by prefixing debug prints with KBUILD_MODNAME. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 2 ++ drivers/cpufreq/cpufreq_performance.c | 2 ++ drivers/cpufreq/cpufreq_powersave.c | 2 ++ drivers/cpufreq/cpufreq_userspace.c | 2 ++ drivers/cpufreq/freq_table.c | 2 ++ 5 files changed, 10 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index db6e337..85df538 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -15,6 +15,8 @@ * */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include diff --git a/drivers/cpufreq/cpufreq_performance.c b/drivers/cpufreq/cpufreq_performance.c index f13a8a9..ceee068 100644 --- a/drivers/cpufreq/cpufreq_performance.c +++ b/drivers/cpufreq/cpufreq_performance.c @@ -10,6 +10,8 @@ * */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include diff --git a/drivers/cpufreq/cpufreq_powersave.c b/drivers/cpufreq/cpufreq_powersave.c index 4c2eb51..2d948a1 100644 --- a/drivers/cpufreq/cpufreq_powersave.c +++ b/drivers/cpufreq/cpufreq_powersave.c @@ -10,6 +10,8 @@ * */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include diff --git a/drivers/cpufreq/cpufreq_userspace.c b/drivers/cpufreq/cpufreq_userspace.c index bedac1a..c8c3d29 100644 --- a/drivers/cpufreq/cpufreq_userspace.c +++ b/drivers/cpufreq/cpufreq_userspace.c @@ -11,6 +11,8 @@ * */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c index 90431cb..49cda25 100644 --- a/drivers/cpufreq/freq_table.c +++ b/drivers/cpufreq/freq_table.c @@ -9,6 +9,8 @@ * */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3 09/13] vfs: add one wq to update map info periodically
On Tue, Oct 16, 2012 at 8:27 AM, Dave Chinner wrote:
> On Wed, Oct 10, 2012 at 06:07:31PM +0800, zwu.ker...@gmail.com wrote:
>> From: Zhi Yong Wu
>>
>> Add a per-superblock workqueue and a work_struct
>> to run periodic work to update map info on each superblock.
>>
>> Signed-off-by: Zhi Yong Wu
>> ---
>> fs/hot_tracking.c| 94
>> ++
>> fs/hot_tracking.h|3 +
>> include/linux/hot_tracking.h |2 +
>> 3 files changed, 99 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/hot_tracking.c b/fs/hot_tracking.c
>> index a8dc599..f333c47 100644
>> --- a/fs/hot_tracking.c
>> +++ b/fs/hot_tracking.c
>> @@ -15,6 +15,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -623,6 +625,88 @@ static void hot_map_array_exit(struct hot_info *root)
>> }
>>
>> /*
>> + * Update temperatures for each hot inode item and
>> + * hot range item for aging purposes
>> + */
>> +static void hot_temperature_update_work(struct work_struct *work)
>> +{
>> + struct hot_update_work *hot_work =
>> + container_of(work, struct hot_update_work, work);
>> + struct hot_info *root = hot_work->hot_info;
>> + struct hot_inode_item *hi_nodes[8];
>> + unsigned long delay = HZ * HEAT_UPDATE_DELAY;
>> + u64 ino = 0;
>> + int i, n;
>> +
>> + do {
>> + while (1) {
>> + spin_lock(&root->lock);
>> + n = radix_tree_gang_lookup(&root->hot_inode_tree,
>> +(void **)hi_nodes, ino,
>> +ARRAY_SIZE(hi_nodes));
>> + if (!n) {
>> + spin_unlock(&root->lock);
>> + break;
>> + }
>> +
>> + ino = hi_nodes[n - 1]->i_ino + 1;
>> + for (i = 0; i < n; i++) {
>> + kref_get(&hi_nodes[i]->hot_inode.refs);
>> + hot_map_array_update(
>> + &hi_nodes[i]->hot_inode.hot_freq_data,
>> root);
>> + hot_range_update(hi_nodes[i], root);
>> + hot_inode_item_put(hi_nodes[i]);
>> + }
>> + spin_unlock(&root->lock);
>
> This is a lot of work to do under a spin lock. Perhaps you should
> get a reference on all the nodes, then drop the root->lock and then
> update all the nodes in a separate loop.
OK, done
>
>> + }
>> +
>> + if (unlikely(freezing(current))) {
>> + __refrigerator(true);
>> + } else {
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + if (!kthread_should_stop()) {
>> + schedule_timeout(delay);
>> + }
>> + __set_current_state(TASK_RUNNING);
>> + }
>> + } while (!kthread_should_stop());
>
> I don't think you understand workqueues fully. A work queue worker
> function is not something that executes endlessly. It is a
> "one-shot" function that does the work once, not an endless loop
> that has to delay it's execution for periodic work.
ah, i have done this based on your following suggestions, thanks.
>
> If you need periodic work, then you should use a struct delayed_work
> and queue the next work iteration to be run a later time. See, for
> example, xfs_syncd_worker() and xfs_syncd_queue_sync() and how that
> reschedules itself for periodic work. It also means you don't have
> to handle kthread freezing, as the WQ infrastructure takes care of
> that for you.
ditto.
>
> This is why unmount is hanging for me - this work never completes,
> so flush_workqueue() will never return.
got it, thanks.
>
>> +}
>> +
>> +static int hot_wq_init(struct hot_info *root)
>> +{
>> + struct hot_update_work *hot_work;
>> + int ret = 0;
>> +
>> + root->update_wq = alloc_workqueue(
>> + "hot_temperature_update", WQ_MEM_RECLAIM | WQ_UNBOUND, 1);
>> + if (!root->update_wq) {
>> + printk(KERN_ERR "%s: failed to create "
>> + "temperature update workqueue\n",
>> + __func__);
>> + return 1;
>> + }
>> +
>> + hot_work = kmalloc(sizeof(*hot_work), GFP_NOFS);
>> + if (hot_work) {
>> + hot_work->hot_info = root;
>> + INIT_WORK(&hot_work->work, hot_temperature_update_work);
>> + queue_work(root->update_wq, &hot_work->work);
>> + } else {
>> + printk(KERN_ERR "%s: failed to create update work\n",
>> + __func__);
>> + ret = 1;
>> + }
>
> I don't understand why you need a separate "hot_work" structure.
> just embed a struct delayed_work in the struct hot_info and use
> container_of() to get the struct hot
RE: [PATCH] extcon : callback function to read cable property
Myunjoo/Chanwoo Ping... Could you please review this patch? -jtc > > > Subject: Re: [PATCH] extcon : callback function to read cable > > > property > > > > > > I think the reason why we have extcon is in first place is to only > > > notify the clients of cable connection and disconnection and it is > > > up to the client to decide what else to do with the cable such as > > > finding which state it is in and other details. > > > So I feel this should not be handled in the extcon. > > > > > > However it is up to the maintainer to decide. > > > > Once the consumer gets the notification, it needs to take some action. > > One of the action is to read the cable properties. This can be done by > > proprietary calls which is known both to the consumer and the provider. > > My intention is to avoid this proprietary calls. Since both the > > provider and consumer are communicating with the extcon subsystem , I > > feel having a callback function of this kind would help to avoid the > > use of proprietary calls. Also I agree that extcon notifier chains are > > used to notify the cable state (attach/detach). But if a cable has > > more than two states (like the charger cable) how do we support it without > having a callback function like this? > > Let the maintainer take the final decision. > Well this use case will keep on growing if we start factor in this kind of > changes and that is why I am opposed to adding any other state. > Maintainer? > > > > >
Re: [PATCH] CAN: sja1000: Add support for Connect Tech Inc's Canpro/104-Plus Opto CAN board
On 10/16/2012 11:03 PM, Muhammad Ghias wrote: > Patch adds support for CANpro/104-Plus Opto CAN board. Board uses PLX9030 > bridge and two NXP SJA1000 CAN controllers. Patch is generated and tested > with kernel 3.6.1. > > If you have any questions or any feedback please let me know. > > Thanks, The above two lines should go ... > Signed-off-by: Muhammad Ghias > --- ... here (out of the commit message). Apart from that the patch looks good. You can add my Acked-by: Wolfgang Grandegger Thanks for your contribution. Wolfgang. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon : register for cable interest by cable name
There are some scnearios where a driver/framework needs to register
interest for a particular cable without specifying the extcon device
name. One such scenario is charger notifications. The platform will
have charger cabel which will be bound to any extcon device. It's
not mandatory for the charger driver to know which extcon device
it should use. This patch enables the support for registering
interest for a cable just by cable name wihtout specifying the
extcon device name
Signed-off-by: Jenny TC
---
v1:
Initial submit
V2:
Removed the new API and modified the extcon_register_interest
API to accomodate the new requirement
drivers/extcon/extcon-class.c | 43 +++--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 946a318..738919e 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -466,22 +466,45 @@ int extcon_register_interest(struct
extcon_specific_cable_nb *obj,
const char *extcon_name, const char *cable_name,
struct notifier_block *nb)
{
- if (!obj || !extcon_name || !cable_name || !nb)
+
+ if (!obj || !cable_name || !nb)
return -EINVAL;
- obj->edev = extcon_get_extcon_dev(extcon_name);
- if (!obj->edev)
- return -ENODEV;
+ if (extcon_name) {
+
+ obj->edev = extcon_get_extcon_dev(extcon_name);
+ if (!obj->edev)
+ return -ENODEV;
+
+ obj->cable_index = extcon_find_cable_index(obj->edev,
cable_name);
+ if (obj->cable_index < 0)
+ return -ENODEV;
- obj->cable_index = extcon_find_cable_index(obj->edev, cable_name);
- if (obj->cable_index < 0)
- return -ENODEV;
+ obj->user_nb = nb;
- obj->user_nb = nb;
+ obj->internal_nb.notifier_call = _call_per_cable;
- obj->internal_nb.notifier_call = _call_per_cable;
+ return raw_notifier_chain_register(&obj->edev->nh,
&obj->internal_nb);
+ } else {
+ struct class_dev_iter iter;
+ struct extcon_dev *extd;
+ struct device *dev;
+ if (!extcon_class)
+ return -ENODEV;
+ class_dev_iter_init(&iter, extcon_class, NULL, NULL);
+ while ((dev = class_dev_iter_next(&iter))) {
+ extd = (struct extcon_dev *)dev_get_drvdata(dev);
+
+ if (extcon_find_cable_index(extd, cable_name) < 0)
+ continue;
+
+ class_dev_iter_exit(&iter);
+ return extcon_register_interest(obj, extd->name,
+ cable_name, nb);
+ }
- return raw_notifier_chain_register(&obj->edev->nh, &obj->internal_nb);
+ return -ENODEV;
+ }
}
/**
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cpufreq: Improve debug prints
On Wed, 2012-10-17 at 12:03 +0530, Viresh Kumar wrote: > On 17 October 2012 11:56, Joe Perches wrote: > > Oh good, but please use a space between KBUILD_MODNAME > > and the quoted ": ". > > Anything technical behind it or just for code formatting? Just code formatting though it makes it easier to remove all these unnecessary defines when it becomes the default prefix some year soon. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 06/14] memcg: kmem controller infrastructure
(2012/10/16 19:16), Glauber Costa wrote: > This patch introduces infrastructure for tracking kernel memory pages to > a given memcg. This will happen whenever the caller includes the flag > __GFP_KMEMCG flag, and the task belong to a memcg other than the root. > > In memcontrol.h those functions are wrapped in inline acessors. The > idea is to later on, patch those with static branches, so we don't incur > any overhead when no mem cgroups with limited kmem are being used. > > Users of this functionality shall interact with the memcg core code > through the following functions: > > memcg_kmem_newpage_charge: will return true if the group can handle the > allocation. At this point, struct page is not > yet allocated. > > memcg_kmem_commit_charge: will either revert the charge, if struct page >allocation failed, or embed memcg information >into page_cgroup. > > memcg_kmem_uncharge_page: called at free time, will revert the charge. > > [ v2: improved comments and standardized function names ] > [ v3: handle no longer opaque, functions not exported, >even more comments ] > [ v4: reworked Used bit handling and surroundings for more clarity ] > [ v5: simplified code for kmemcg compiled out and core functions in >memcontrol.c, moved kmem code to the middle to avoid forward decls ] > > Signed-off-by: Glauber Costa > Acked-by: Michal Hocko > CC: Christoph Lameter > CC: Pekka Enberg > CC: Kamezawa Hiroyuki > CC: Johannes Weiner > CC: Tejun Heo Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device
*mem_device)
{
int result;
struct acpi_memory_info *info, *n;
+ list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
>>>
>>> Which lock protect this loop?
>>
>> There is no any lock to protect it now...
>
> When iterate an item removal list, you should use lock for protecting from
> memory corruption.
>
>
>
>
+static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+{
+ int result;
/*
* Ask the VM to offline this memory range.
* Note: Assume that this function returns zero on success
*/
>>>
>>> Write function comment instead of this silly comment.
>>>
- list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
- if (info->enabled) {
- result = remove_memory(info->start_addr,
info->length);
- if (result)
- return result;
- }
- kfree(info);
- }
+ result = acpi_memory_remove_memory(mem_device);
+ if (result)
+ return result;
/* Power-off and eject the device */
result = acpi_memory_powerdown_device(mem_device);
>>>
>>> This patch move acpi_memory_powerdown_device() from
>>> ACPI_NOTIFY_EJECT_REQUEST
>>> to release callback, but don't explain why.
>>
>> Hmm, it doesn't move the code. It just reuse the code in
>> acpi_memory_powerdown_device().
>
> Even if reuse or not reuse, you changed the behavior. If any changes
> has no good rational, you cannot get an ack.
I don't understand this? IIRC, the behavior isn't changed.
Thanks
Wen Congyang
>
>
>
>
@@ -473,12 +486,23 @@ static int acpi_memory_device_add(struct
static int acpi_memory_device_remove(struct acpi_device *device, int type)
{
struct acpi_memory_device *mem_device = NULL;
-
+ int result;
if (!device || !acpi_driver_data(device))
return -EINVAL;
mem_device = acpi_driver_data(device);
+
+ if (type == ACPI_BUS_REMOVAL_EJECT) {
+ /*
+* offline and remove memory only when the memory device is
+* ejected.
+*/
>>>
>>> This comment explain nothing. A comment should describe _why_ should we do.
>>> e.g. Why REMOVAL_NORMAL and REMOVEL_EJECT should be ignored. Why
>>> we need remove memory here instead of ACPI_NOTIFY_EJECT_REQUEST.
>>
>> Hmm, we have 2 ways to remove a memory:
>> 1. SCI
>> 2. echo 1 >/sys/bus/acpi/devices/PNP0C80:XX/eject
>>
>> In the 2nd case, there is no ACPI_NOTIFY_EJECT_REQUEST. We should offline
>> the memory and remove it from kernel in the release callback. We will
>> poweroff
>> the memory device in acpi_bus_hot_remove_device(), so we must offline
>> and remove it if the type is ACPI_BUS_REMOVAL_EJECT.
>>
>> I guess we should not poweroff the memory device when we fail to offline it.
>> But device_release_driver() doesn't returns any error...
>
> 1) I think /sys/bus/acpi/devices/PNP0C80:XX/eject should emulate acpi
> eject. Can't
> you make a pseudo acpi eject event and detach device by acpi regular path?
>
> 2) Your explanation didn't explain why we should ignore REMOVAL_NORMAL
> and REMOVEL_EJECT. As far as reviewers can't track your intention, we
> can't maintain
> the code and can't ack them.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e)
On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote: > On 09/14/2012 01:57 PM, Xiao Guangrong wrote: > > On 09/12/2012 04:15 PM, Avi Kivity wrote: > >> On 09/12/2012 07:40 AM, Fengguang Wu wrote: > >>> Hi, > >>> > >>> 3 of my test boxes running v3.5 kernel become unaccessible and I find > >>> two of them kept emitting this dmesg: > >>> > >>> vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit > >>> reason is 0x31 > >>> > >>> The other one has froze and the above lines are the last dmesg. > >>> Any ideas? > >> > >> First, that printk should be rate-limited. > >> > >> Second, we should add EXIT_REASON_EPT_MISCONFIG (0x31) to > >> > >>if ((vectoring_info & VECTORING_INFO_VALID_MASK) && > >>(exit_reason != EXIT_REASON_EXCEPTION_NMI && > >>exit_reason != EXIT_REASON_EPT_VIOLATION && > >>exit_reason != EXIT_REASON_TASK_SWITCH)) > >>printk(KERN_WARNING "%s: unexpected, valid vectoring info " > >> "(0x%x) and exit reason is 0x%x\n", > >> __func__, vectoring_info, exit_reason); > >> > >> since it's easily caused by the guest. > > > > Yes, i will do these. > > > >> > >> Third, it's really unexpected. It seems the guest was attempting to > >> deliver a page fault exception (0x0e) but encountered an mmio page during > >> delivery (in the IDT, TSS, stack, or page tables). Is this reproducible? > >> If so it's easy to patch kvm to halt in that case and allow examining the > >> guest via qemu. > >> > > > > Have no idea yet why the box was frozen under this case, will try to write > > a test case, > > hope it can help me to find the reason out. > > > > Still did not know why linux kernel triggered it. I have posted > a patchset to report an internal error for this case, hoping > Fengguang can reproduce it after the patchset and Qemu's dump > can help us to find the reason out. > > I will keep working on it. Thanks! Shall I run some patched kernel, or just 3.6.0? Another problem I sometimes run into is, dmesg no longer works in the test boxes that run lots of KVMs. It aborts with an error message: dmesg: klogctl failed: Bad address 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: ata4.00: failed to get Identify Device Data, Emask 0x1
On 10/17/2012 12:50 PM, Robert Hancock wrote: > On 10/16/2012 07:38 PM, Aaron Lu wrote: >> On 10/16/2012 11:18 PM, Borislav Petkov wrote: >>> On Tue, Oct 16, 2012 at 03:58:24PM +0100, Alan Cox wrote: Can you check whether 3.6 works on them. I know 3.6 is horribly broken on several brands of AHCI controller (Jmicron for example). Dunno where Jeff is on fixing the regressions ? >>> >>> If by "works" you mean I don't see the message there, then yes, it does. >>> Logs say the message started appearing on Oct 4th after me building >>> Linus master after the merge window started. >>> >>> Ok, let me test 3.6.2 just in case .. yes, no error message >>> there. >> >> This is brought by commit: 65fe1f0f66a57380229a4ced844188103135f37b, >> ahci: implement aggressive SATA device sleep support. >> >> Shane, got time to take a look? This debug message made people >> uncomfortable :-) > > I don't have whatever version of ATA command set defines this command, > but surely there's some identify bit which lists whether this log page > is supported. Right now checking for it is only conditional on NCQ support. Agree. If NCQ does not imply support of this log page, we should definitely refine the check condition used here. I suppose Shane will take care of this, but if he doesn't, I'll do that at a later time. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 0/5] snd-ice1712: Add Philips PSC724 Ultimate Edge
At Sun, 14 Oct 2012 21:09:18 +0200, Ondrej Zary wrote: > > Hello, > this patch series adds full support for Philips PSC724 Ultimate Edge sound > card to snd-ice1712 driver. Unlike other snd-ice1712 subdrivers, the codec > code is splitted into separate files, reusable by other ice1712 subdrivers. > > Working: all analog outputs (front, rear, center+lfe, headphone) and inputs > (front mic, rear mic, line, cd, aux), mixer, headphone jack detection, > suspend/resume > > Untested: SPDIF Applied patches 1-4 now, but skipped 5. See the reply to the post for details. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 12/14] execute the whole memcg freeing in free_worker
(2012/10/16 19:16), Glauber Costa wrote: > A lot of the initialization we do in mem_cgroup_create() is done with > softirqs enabled. This include grabbing a css id, which holds > &ss->id_lock->rlock, and the per-zone trees, which holds > rtpz->lock->rlock. All of those signal to the lockdep mechanism that > those locks can be used in SOFTIRQ-ON-W context. This means that the > freeing of memcg structure must happen in a compatible context, > otherwise we'll get a deadlock, like the one bellow, caught by lockdep: > >[] free_accounted_pages+0x47/0x4c >[] free_task+0x31/0x5c >[] __put_task_struct+0xc2/0xdb >[] put_task_struct+0x1e/0x22 >[] delayed_put_task_struct+0x7a/0x98 >[] __rcu_process_callbacks+0x269/0x3df >[] rcu_process_callbacks+0x31/0x5b >[] __do_softirq+0x122/0x277 > > This usage pattern could not be triggered before kmem came into play. > With the introduction of kmem stack handling, it is possible that we > call the last mem_cgroup_put() from the task destructor, which is run in > an rcu callback. Such callbacks are run with softirqs disabled, leading > to the offensive usage pattern. > > In general, we have little, if any, means to guarantee in which context > the last memcg_put will happen. The best we can do is test it and try to > make sure no invalid context releases are happening. But as we add more > code to memcg, the possible interactions grow in number and expose more > ways to get context conflicts. One thing to keep in mind, is that part > of the freeing process is already deferred to a worker, such as vfree(), > that can only be called from process context. > > For the moment, the only two functions we really need moved away are: > >* free_css_id(), and >* mem_cgroup_remove_from_trees(). > > But because the later accesses per-zone info, > free_mem_cgroup_per_zone_info() needs to be moved as well. With that, we > are left with the per_cpu stats only. Better move it all. > > Signed-off-by: Glauber Costa > Tested-by: Greg Thelen > Acked-by: Michal Hocko > CC: KAMEZAWA Hiroyuki > CC: Johannes Weiner > CC: Tejun Heo Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 5/5] snd-ice1712: Fix resume on ice1724
At Sun, 14 Oct 2012 21:09:23 +0200,
Ondrej Zary wrote:
>
> set_pro_rate() is called from hw_params() but not from prepare(), breaking
> running PCM on suspend/resume.
> Call it from prepare() if PCM was suspended to fix the problem.
>
> Signed-off-by: Ondrej Zary
This should be fixed in the resume callback. Could you check the
patch below instead?
thanks,
Takashi
---
diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c
index 161c8f6..5cc3fa5 100644
--- a/sound/pci/ice1712/ice1724.c
+++ b/sound/pci/ice1712/ice1724.c
@@ -2867,7 +2867,12 @@ static int snd_vt1724_resume(struct device *dev)
ice->set_spdif_clock(ice, 0);
} else {
/* internal on-card clock */
- snd_vt1724_set_pro_rate(ice, ice->pro_rate_default, 1);
+ int rate;
+ if (ice->cur_rate)
+ rate = ice->cur_rate;
+ else
+ rate = ice->pro_rate_default;
+ snd_vt1724_set_pro_rate(ice, rate, 1);
}
update_spdif_bits(ice, ice->pm_saved_spdif_ctrl);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] oom, memcg: handle sysctl oom_kill_allocating_task while memcg oom happening
On Tue 16-10-12 14:32:05, Sha Zhengju wrote: [...] > Thanks for reminding! Yes, I cooked it on memcg-devel git repo but > a out-of-date > since-3.2 branch... But I notice the latest branch is since-3.5(not > seeing 3.6/3.7), does > it okay to working on this branch? The tree has moved to http://git.kernel.org/?p=linux/kernel/git/mhocko/mm.git;a=summary. Please use that tree. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] mm: teach mm by current context info to not do I/O during memory allocation
On Tue, Oct 16, 2012 at 1:49 PM, Minchan Kim wrote: > > Fair enough but it wouldn't be a good idea that add new unlikely branch > in allocator's fast path. Please move the check into slow path which could > be in __alloc_pages_slowpath. Thanks for your comment. I have considered to add the branch into gfp_to_alloc_flags() before, but didn't do it because I see that get_page_from_freelist() may use the GFP_IO or GFP_FS flag at least in zone_reclaim() path. So could you make sure it is safe to move the branch into __alloc_pages_slowpath()? If so, I will add the check into gfp_to_alloc_flags(). Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix memory leak in binder--version2
On Mon, Oct 15, 2012 at 05:39:22PM -0700, Arve Hjønnevåg wrote: > On Mon, Oct 15, 2012 at 4:58 PM, Greg KH wrote: > > On Mon, Oct 15, 2012 at 04:55:21PM -0700, Arve Hjønnevåg wrote: > >> On Mon, Oct 15, 2012 at 3:52 PM, Greg KH > >> wrote: > >> > On Mon, Oct 15, 2012 at 07:20:01AM +, Tu, Xiaobing wrote: > >> >> After enabling kmemleak and run monkey, following memleak is reported: > >> >> unreferenced object 0xeed27f80 (size 64): > >> >> comm "Binder_8", pid 641, jiffies 4294946341 (age 2275.810s) > >> >> hex dump (first 32 bytes): > >> >> 4f dd 00 00 84 7f d2 ee 84 7f d2 ee 01 00 00 00 O... > >> >> 00 00 00 00 00 00 00 00 00 aa 4c d7 00 00 00 00 ..L. > >> >> backtrace: > >> >> [] kmemleak_alloc+0x3c/0xa0 > >> >> [] kmem_cache_alloc_trace+0x9e/0x180 > >> >> [] binder_thread_write+0xcf5/0x23a0 > >> >> [] binder_ioctl+0x1f1/0x530 > >> >> [] do_vfs_ioctl+0x86/0x5e0 > >> >> [] sys_ioctl+0x32/0x60 > >> >> [] syscall_call+0x7/0xb > >> >> [] 0x > >> >> > >> >> The work item in async_todo list is not freed when binder released. > >> >> Also the async transaction should also be freed in binder_release_work. > >> >> > >> >> Signed-off-by: Leon Ma > >> >> Signed-off-by: Di Zhang > >> >> --- > >> >> drivers/staging/android/binder.c |6 ++ > >> >> 1 files changed, 6 insertions(+), 0 deletions(-) > >> > > >> > Nice fix, but next time can you at least use scripts/get_maintainer.pl > >> > to figure out who to send this to? I'll queue it up soon, but it took > >> > akpm to point me at this for me to notice it. > >> > >> This patch was just pointer out to me as well. I have a similar fix > >> queued up at https://android-review.googlesource.com/#/c/43801/ that > >> is still being tested. It fixes this leak and a theoretical leak of > >> death notification objects. > > > > Ok, should I hold off applying this patch and wait for your patch > > instead? > > > > I just sent two patches, but they are not fully tested yet. Ok, care to test them and after that, resend them with the changes I noted in the changelog section of the patch? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Staging: android: binder: Fix memory leak on thread/process exit
On Mon, Oct 15, 2012 at 05:32:41PM -0700, Arve Hjønnevåg wrote: > If a thread or process exited while a reply, one-way transaction or > death notification was pending, the struct holding the pending work > was leaked. > > Change-Id: I2eaafaba1c0ecda3ec0872d449dc16d0721c21e7 What is this field? Please don't include this in kernel patches, it forces me to edit the patch by hand :( Also, this should go to older kernels, right? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] iio: adc: add viperboard adc driver
On Monday 15 October 2012 at 16:26:36, Lars-Peter Clausen wrote:
> Added linux-...@vger.kernel.org to Cc.
>
> On 10/12/2012 04:34 PM, Lars Poeschel wrote:
> > From: Lars Poeschel
> >
> > This adds the mfd cell to use the adc part of the Nano River Technologies
> > viperboard.
> >
> > Signed-off-by: Lars Poeschel
>
> Looks good in general, just some minor code style issues.
>
> > ---
> >
> > drivers/iio/adc/Kconfig |7 ++
> > drivers/iio/adc/Makefile |1 +
> > drivers/iio/adc/viperboard_adc.c | 185
> > ++ drivers/mfd/viperboard.c
> > |3 +
> > 4 files changed, 196 insertions(+)
> > create mode 100644 drivers/iio/adc/viperboard_adc.c
>
> [...]
>
> > diff --git a/drivers/iio/adc/viperboard_adc.c
> > b/drivers/iio/adc/viperboard_adc.c new file mode 100644
> > index 000..8ae6634
> > --- /dev/null
> > +++ b/drivers/iio/adc/viperboard_adc.c
> > @@ -0,0 +1,185 @@
> > +/*
> > + * Nano River Technologies viperboard iio ADC driver
> > + *
> > + * (C) 2012 by Lemonage GmbH
> > + * Author: Lars Poeschel
> > + * All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify it + * under the terms of the GNU General Public License as
> > published by the + * Free Software Foundation; either version 2 of
> > the License, or (at your + * option) any later version.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#define VPRBRD_ADC_CMD_GET 0x00
> > +
> > +struct __packed vprbrd_adc_msg {
> > + u8 cmd;
> > + u8 chan;
> > + u8 val;
> > +};
>
> put the __packed between } and ;
GCC allows both alternatives, but you are right: Most kernel code is doing it
between } and ; so I will change this.
> > +
> > +struct vprbrd_adc {
> > + struct vprbrd *vb;
> > +};
> > +
> > +#define VPRBRD_ADC_CHANNEL(_index) { \
> > + .type = IIO_VOLTAGE,\
> > + .indexed = 1, \
> > + .channel = _index, \
> > + .info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT,\
>
> It would be good if you could also report the channel scale.
I saw that there is the possibility to supply a channel scale, which is way
cool. :-) The doc of the viperboard says nothing about the scale of the ADC.
At the moment I do not have the right measuring equipment here to measure a
scale myself. I would do another tiny patch if I have the oppotunity to
measure somewhere.
> > + .scan_index = _index, \
> > + .scan_type.sign = 'u', \
> > + .scan_type.realbits = 8,\
> > + .scan_type.storagebits = 8, \
>
> Usually this is written as
> .scan_type = {
> .sign = 'u',
>
> },
>
> > +}
> > +
> > +static struct iio_chan_spec vprbrd_adc_iio_channels[] = {
>
> const
>
> > + VPRBRD_ADC_CHANNEL(0),
> > + VPRBRD_ADC_CHANNEL(1),
> > + VPRBRD_ADC_CHANNEL(2),
> > + VPRBRD_ADC_CHANNEL(3),
> > +};
> > +
> > +static int vprbrd_iio_read_raw(struct iio_dev *iio_dev,
> > + struct iio_chan_spec const *chan,
> > + int *val,
> > + int *val2,
> > + long mask)
>
> 'mask' used to be a mask and that's why it is still called 'mask' in older
> drivers. For new drivers we should use 'info'.
>
> > +{
> > + int ret, error = 0;
> > + struct vprbrd_adc *adc = iio_priv(iio_dev);
> > + struct vprbrd *vb = adc->vb;
> > + struct vprbrd_adc_msg *admsg = (struct vprbrd_adc_msg *)vb->buf;
> > +
> > + if (mask == IIO_CHAN_INFO_RAW) {
> > +
>
> Use switch instead of if. Otherwise you'd end up with if(mask == ...) else
> if(mask == ...) else if (mask == ...) if you add support for more channel
> attributes.
>
> > + mutex_lock(&vb->lock);
> > +
> > + admsg->cmd = VPRBRD_ADC_CMD_GET;
> > + admsg->chan = chan->scan_index;
> > + admsg->val = 0x00;
> > +
> > + ret = usb_control_msg(vb->usb_dev,
> > + usb_sndctrlpipe(vb->usb_dev, 0), 0xec, 0x40,
> > + 0x, 0x, admsg,
> > + sizeof(struct vprbrd_adc_msg), 100);
> > + if (ret != sizeof(struct vprbrd_adc_msg)) {
> > + dev_err(&iio_dev->dev, "usb send error on adc read\n");
> > + error = -EREMOTEIO;
> > + }
>
> Does it make sense to send out the second msg if the first one failed?
This is a good question. I can not fully answer it, because I did not build
the hardware. I thought it is better to try send the second message, because
there is some chance it reaches the device. I would opt for trying it.
> > +
> > +
Re: [PATCH 2/2] Staging: android: binder: Allow using highmem for binder buffers
On Mon, Oct 15, 2012 at 05:32:42PM -0700, Arve Hjønnevåg wrote: > Change-Id: I19be5fd89c194abcb8b041e2dd6c4d71ae7b1cc2 Again with the change-id field :( And please provide some information here, _why_ do we want to allow highmem for binder buffers? What does this solve? Is it a bug or just a feature enhancement? Depending on what it is depends on what release it should go into. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: csr: fix coding style
Hi,
On 10/15/2012 10:55 AM, SeongJae Park wrote:
Fix coding style of csr_framework_ext_types.h
Signed-off-by: SeongJae Park
---
drivers/staging/csr/csr_framework_ext_types.h | 33 +++--
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/csr/csr_framework_ext_types.h
b/drivers/staging/csr/csr_framework_ext_types.h
index 57194ee..7e9cf8e 100644
--- a/drivers/staging/csr/csr_framework_ext_types.h
+++ b/drivers/staging/csr/csr_framework_ext_types.h
@@ -2,11 +2,11 @@
...
@@ -24,17 +24,15 @@ extern "C" {
#ifdef __KERNEL__
-struct CsrThread
-{
-struct task_struct *thread_task;
-charname[16];
+struct CsrThreadi {
I think this extra i letter at the end of CsrThreadi string is typo. Did
you try to compile the driver with your changes?
Best regards,
Lauri Hintsala
+ struct task_struct *thread_task;
+ charname[16];
...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] mfd: add viperboard driver
On Monday 15 October 2012 at 19:09:53, Peter Meerwald wrote:
> minor nitpicking below
>
> > From: Lars Poeschel
> >
> > Add mfd driver for Nano River Technologies viperboard.
> >
> > Signed-off-by: Lars Poeschel
> > ---
> >
> > drivers/mfd/Kconfig| 14
> > drivers/mfd/Makefile |1 +
> > drivers/mfd/viperboard.c | 149
> > include/linux/mfd/viperboard.h
> > | 99 ++ 4 files changed, 263 insertions(+)
> > create mode 100644 drivers/mfd/viperboard.c
> > create mode 100644 include/linux/mfd/viperboard.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index b1a1462..98d9fa3 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -1003,6 +1003,20 @@ config MFD_PALMAS
> >
> > If you say yes here you get support for the Palmas
> > series of PMIC chips from Texas Instruments.
> >
> > +config MFD_VIPERBOARD
> > +tristate "Support for Nano River Technologies Viperboard"
>
> probably wrong indentation (space vs. tab)?
>
> > + select MFD_CORE
> > + depends on USB && IIO
> > +default n
> > +help
> > + Say yes here if you want support for Nano River Technologies
> > + Viperboard.
> > + There are mfd cell drivers available for i2c master, adc and
> > + both gpios found on the board. The spi part does not yet
> > + have a driver.
> > + You need to select the mfd cell drivers seperatly.
>
> separately
>
> > + The drivers do not support all features the board exposes.
> > +
> >
> > endmenu
> > endif
> >
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 79dd22d..6ab6b64 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -128,6 +128,7 @@ obj-$(CONFIG_MFD_TPS65090) += tps65090.o
> >
> > obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
> > obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
> > obj-$(CONFIG_MFD_PALMAS) += palmas.o
> >
> > +obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
> >
> > obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
> > obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
> > obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
> >
> > diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
> > new file mode 100644
> > index 000..8095ea2
> > --- /dev/null
> > +++ b/drivers/mfd/viperboard.c
> > @@ -0,0 +1,149 @@
> > +/*
> > + * Nano River Technologies viperboard driver
> > + *
> > + * This is the core driver for the viperboard. There are cell drivers
> > + * available for I2C, ADC and both GPIOs. SPI is not yet supported
>
> full stop (.) missing
>
> > + * The drivers do not support all features the board exposes. See user
> > + * manual of the viperboard.
> > + *
> > + * (C) 2012 by Lemonage GmbH
> > + * Author: Lars Poeschel
> > + * All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify it + * under the terms of the GNU General Public License as
> > published by the + * Free Software Foundation; either version 2 of the
> > License, or (at your + * option) any later version.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +
> > +static const struct usb_device_id vprbrd_table[] = {
> > + { USB_DEVICE(0x2058, 0x1005) }, /* Nano River Technologies */
> > + { } /* Terminating entry */
> > +};
> > +
> > +MODULE_DEVICE_TABLE(usb, vprbrd_table);
> > +
> > +static void vprbrd_dev_release(struct device *dev)
> > +{
> > + return;
>
> return not needed
>
> > +}
> > +
> > +static void vprbrd_free(struct vprbrd *dev)
> > +{
> > + usb_put_dev(dev->usb_dev);
> > + kfree(dev);
> > +}
Thanks for your review. I will change this and after waiting some time for
additional comments, I will do a version 3 of the whole patchset.
Regards,
Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] avr32: fix build error in atstk1006_defconfig
fixed the following compile error when use avr32 atstk1006_defconfig:
drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location':
drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function
'writel_relaxed'
which was introduced by commit 1c7b874d33b463 ("mtd: at91: atmel_nand: add
Programmable Multibit ECC controller support").
The PMECC for nand flash code uses writel_relaxed(). But in avr32, there is no
macro "writel_relaxed" defined. This patch add writex_relaxed macro definitions.
Signed-off-by: Josh Wu
---
arch/avr32/include/asm/io.h |4
1 file changed, 4 insertions(+)
diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index cf60d0a..fc6483f 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -165,6 +165,10 @@ BUILDIO_IOPORT(l, u32)
#define readw_be __raw_readw
#define readl_be __raw_readl
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
+
#define writeb_be __raw_writeb
#define writew_be __raw_writew
#define writel_be __raw_writel
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memory cgroup: update root memory cgroup when node is onlined
(2012/09/14 10:36), Hugh Dickins wrote:
On Thu, 13 Sep 2012, Johannes Weiner wrote:
On Thu, Sep 13, 2012 at 03:14:28PM +0800, Wen Congyang wrote:
root_mem_cgroup->info.nodeinfo is initialized when the system boots.
But NODE_DATA(nid) is null if the node is not onlined, so
root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone contains
an invalid pointer. If we use numactl to bind a program to the node
after onlining the node and its memory, it will cause the kernel
panicked:
Is there any chance we could get rid of the zone backpointer in lruvec
again instead?
It could be done, but it would make me sad :(
Adding new nodes is a rare event and so updating every
single memcg in the system might be just borderline crazy.
Not horribly crazy, but rather ugly, yes.
But can't
we just go back to passing the zone along with the lruvec down
vmscan.c paths? I agree it's ugly to pass both, given their
relationship. But I don't think the backpointer is any cleaner but in
addition less robust.
It's like how we use vma->mm: we could change everywhere to pass mm with
vma, but it looks cleaner and cuts down on long arglists to have mm in vma.
From past experience, one of the things I worried about was adding extra
args to the reclaim stack.
That being said, the crashing code in particular makes me wonder:
static __always_inline void add_page_to_lru_list(struct page *page,
struct lruvec *lruvec, enum lru_list lru)
{
int nr_pages = hpage_nr_pages(page);
mem_cgroup_update_lru_size(lruvec, lru, nr_pages);
list_add(&page->lru, &lruvec->lists[lru]);
__mod_zone_page_state(lruvec_zone(lruvec), NR_LRU_BASE + lru, nr_pages);
}
Why did we ever pass zone in here and then felt the need to replace it
with lruvec->zone in fa9add6 "mm/memcg: apply add/del_page to lruvec"?
A page does not roam between zones, its zone is a static property that
can be retrieved with page_zone().
Just as in vmscan.c, we have the lruvec to hand, and that's what we
mainly want to operate upon, but there is also some need for zone.
(Both Konstantin and I were looking towards the day when we move the
lru_lock into the lruvec, removing more dependence on "zone". Pretty
much the only reason that hasn't happened yet, is that we have not found
time to make a performance case convincingly - but that's another topic.)
Yes, page_zone(page) is a static property of the page, but it's not
necessarily cheap to evaluate: depends on how complex the memory model
and the spare page flags space, doesn't it? We both preferred to
derive zone from lruvec where convenient.
How do you feel about this patch, and does it work for you guys?
You'd be right if you guessed that I started out without the
mem_cgroup_zone_lruvec part of it, but oops in get_scan_count
told me that's needed too.
Description to be filled in later: would it be needed for -stable,
or is onlining already broken in other ways that you're now fixing up?
Reported-by: Tang Chen
Signed-off-by: Hugh Dickins
Acked-by: KAMEZAWA Hiroyuki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ACPI: move acpi_no_s4_hw_signature() declaration into #ifdef CONFIG_HIBERNATION
On Tue, Oct 16, 2012 at 02:24:53PM +0800, Fengguang Wu wrote: > On Tue, Oct 16, 2012 at 01:24:12PM +0800, Yuanhan Liu wrote: > > acpi_no_s4_hw_signature is defined in #ifdef CONFIG_HIBERNATION block, > > but the current code put the declaration in #ifdef CONFIG_PM_SLEEP block. > > > > I happened to meet this issue when I turned off PM_SLEEP config manually: > > arch/x86/kernel/acpi/sleep.c:100:4: error: implicit declaration of function > > ‘acpi_no_s4_hw_signature’ [-Werror=implicit-function-declaration] > > This should be more clear: > > Fix build error on !CONFIG_PM_SLEEP: Actually, there are more erros besides the followling one on !CONFIG_PM_SLEEP. This patch just fix one obvious one: the logical is wrong. Thanks, Yuanhan Liu > > arch/x86/kernel/acpi/sleep.c:100:4: error: implicit declaration of function > ‘acpi_no_s4_hw_signature’ > > The root cause is, acpi_no_s4_hw_signature() is defined in > #ifdef CONFIG_HIBERNATION block, but the current code put the > declaration in #ifdef CONFIG_PM_SLEEP block. > > Thanks, > Fengguang > > > v2: take better title and add build error message suggested by Fengguang > > > > Signed-off-by: Yuanhan Liu > > Reviewed-by: Fengguang Wu > > --- > > include/linux/acpi.h |5 - > > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > > index 90be989..a468429 100644 > > --- a/include/linux/acpi.h > > +++ b/include/linux/acpi.h > > @@ -257,8 +257,11 @@ int acpi_check_region(resource_size_t start, > > resource_size_t n, > > > > int acpi_resources_are_enforced(void); > > > > -#ifdef CONFIG_PM_SLEEP > > +#ifdef CONFIG_HIBERNATION > > void __init acpi_no_s4_hw_signature(void); > > +#endif > > + > > +#ifdef CONFIG_PM_SLEEP > > void __init acpi_old_suspend_ordering(void); > > void __init acpi_nvs_nosave(void); > > #endif /* CONFIG_PM_SLEEP */ > > -- > > 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Q] Default SLAB allocator
On Tue, 2012-10-16 at 10:28 +0900, JoonSoo Kim wrote:
> Hello, Eric.
>
> 2012/10/14 Eric Dumazet :
> > SLUB was really bad in the common workload you describe (allocations
> > done by one cpu, freeing done by other cpus), because all kfree() hit
> > the slow path and cpus contend in __slab_free() in the loop guarded by
> > cmpxchg_double_slab(). SLAB has a cache for this, while SLUB directly
> > hit the main "struct page" to add the freed object to freelist.
>
> Could you elaborate more on how 'netperf RR' makes kernel "allocations
> done by one cpu, freeling done by other cpus", please?
> I don't have enough background network subsystem, so I'm just curious.
>
Common network load is to have one cpu A handling device interrupts
doing the memory allocations to hold incoming frames,
and queueing skbs to various sockets.
These sockets are read by other cpus (if the cpu A is fully used to
service softirqs under high load), so the kfree() are done by other
cpus.
Each incoming frame uses one sk_buff, allocated from skbuff_head_cache
kmemcache (256 bytes on x86_64)
# ls -l /sys/kernel/slab/skbuff_head_cache
lrwxrwxrwx 1 root root 0 oct. 16
08:50 /sys/kernel/slab/skbuff_head_cache -> :t-256
# cat /sys/kernel/slab/skbuff_head_cache/objs_per_slab
32
On a configuration with 24 cpus and one cpu servicing network, we may
have 23 cpus doing the frees roughly at the same time, all competing in
__slab_free() on the same page. This increases if we increase slub page
order (as recommended by SLUB hackers)
To reproduce this kind of workload without a real NIC, we probably need
some test module, using one thread doing allocations, and other threads
doing the free.
> > I played some months ago adding a percpu associative cache to SLUB, then
> > just moved on other strategy.
> >
> > (Idea for this per cpu cache was to build a temporary free list of
> > objects to batch accesses to struct page)
>
> Is this implemented and submitted?
> If it is, could you tell me the link for the patches?
It was implemented in february and not submitted at that time.
The following rebase has probably some issues with slab debug, but seems
to work.
include/linux/slub_def.h | 22 ++
mm/slub.c| 127 +++--
2 files changed, 131 insertions(+), 18 deletions(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index df448ad..9e5b91c 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -41,8 +41,30 @@ enum stat_item {
CPU_PARTIAL_FREE, /* Refill cpu partial on free */
CPU_PARTIAL_NODE, /* Refill cpu partial from node partial */
CPU_PARTIAL_DRAIN, /* Drain cpu partial to node partial */
+ FREE_CACHED,/* free delayed in secondary freelist,
cumulative counter */
+ FREE_CACHED_ITEMS, /* items in victim cache */
NR_SLUB_STAT_ITEMS };
+/**
+ * struct slub_cache_desc - victim cache descriptor
+ * @page: slab page
+ * @objects_head: head of freed objects list
+ * @objects_tail: tail of freed objects list
+ * @count: number of objects in list
+ *
+ * freed objects in slow path are managed into an associative cache,
+ * to reduce contention on @page->freelist
+ */
+struct slub_cache_desc {
+ struct page *page;
+ void**objects_head;
+ void**objects_tail;
+ int count;
+};
+
+#define NR_SLUB_PCPU_CACHE_SHIFT 6
+#define NR_SLUB_PCPU_CACHE (1 << NR_SLUB_PCPU_CACHE_SHIFT)
+
struct kmem_cache_cpu {
void **freelist;/* Pointer to next available object */
unsigned long tid; /* Globally unique transaction id */
diff --git a/mm/slub.c b/mm/slub.c
index a0d6984..30a6d72 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
@@ -221,6 +222,14 @@ static inline void stat(const struct kmem_cache *s, enum
stat_item si)
#endif
}
+static inline void stat_add(const struct kmem_cache *s, enum stat_item si,
+ int cnt)
+{
+#ifdef CONFIG_SLUB_STATS
+ __this_cpu_add(s->cpu_slab->stat[si], cnt);
+#endif
+}
+
/
* Core slab cache functions
***/
@@ -1993,6 +2002,8 @@ static inline void flush_slab(struct kmem_cache *s,
struct kmem_cache_cpu *c)
c->freelist = NULL;
}
+static void victim_cache_flush(struct kmem_cache *s, int cpu);
+
/*
* Flush cpu slab.
*
@@ -2006,6 +2017,7 @@ static inline void __flush_cpu_slab(struct kmem_cache *s,
int cpu)
if (c->page)
flush_slab(s, c);
+ victim_cache_flush(s, cpu);
unfreeze_partials(s);
}
}
@@ -2446,38 +2458,34 @@ EXPORT_SYMBOL(kmem_cache_alloc_node_trace);
#endif
/*
- * Slow patch handling. This may still be called frequentl
[PATCH] backlight: da903x_bl: use dev_get_drvdata() instead of platform_get_drvdata()
dev_get_drvdata() can be used instead of platform_get_drvdata()
to make the code smaller.
Signed-off-by: Jingoo Han
Cc: Richard Purdie
Cc: Mike Rapoport
---
drivers/video/backlight/da903x_bl.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/da903x_bl.c
b/drivers/video/backlight/da903x_bl.c
index 573c7ec..6891754 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -164,15 +164,14 @@ static int da903x_backlight_remove(struct platform_device
*pdev)
#ifdef CONFIG_PM
static int da903x_backlight_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct backlight_device *bl = platform_get_drvdata(pdev);
+ struct backlight_device *bl = dev_get_drvdata(dev);
+
return da903x_backlight_set(bl, 0);
}
static int da903x_backlight_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct backlight_device *bl = platform_get_drvdata(pdev);
+ struct backlight_device *bl = dev_get_drvdata(dev);
backlight_update_status(bl);
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/17] backlight: 88pm860x_bl: fix checkpatch warning
This patch fixes the checkpatch warning as below: WARNING: quoted string split across lines Signed-off-by: Jingoo Han Cc: Richard Purdie --- drivers/video/backlight/88pm860x_bl.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/88pm860x_bl.c b/drivers/video/backlight/88pm860x_bl.c index b7ec34c..6e509d9 100644 --- a/drivers/video/backlight/88pm860x_bl.c +++ b/drivers/video/backlight/88pm860x_bl.c @@ -117,8 +117,8 @@ static int pm860x_backlight_set(struct backlight_device *bl, int brightness) data->current_brightness = value; return 0; out: - dev_dbg(chip->dev, "set brightness %d failure with return " - "value:%d\n", value, ret); + dev_dbg(chip->dev, "set brightness %d failure with return value: %d\n", + value, ret); return ret; } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/17] backlight: atmel-pwm-bl: fix checkpatch warning
This patch fixes the checkpatch warning as below: WARNING: quoted string split across lines Signed-off-by: Jingoo Han Cc: Richard Purdie --- drivers/video/backlight/atmel-pwm-bl.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c index df1cbb7..de5e5e7 100644 --- a/drivers/video/backlight/atmel-pwm-bl.c +++ b/drivers/video/backlight/atmel-pwm-bl.c @@ -106,10 +106,9 @@ static int atmel_pwm_bl_init_pwm(struct atmel_pwm_bl *pwmbl) pwm_channel_writel(&pwmbl->pwmc, PWM_CPRD, pwmbl->pdata->pwm_compare_max); - dev_info(&pwmbl->pdev->dev, "Atmel PWM backlight driver " - "(%lu Hz)\n", pwmbl->pwmc.mck / - pwmbl->pdata->pwm_compare_max / - (1 << prescale)); + dev_info(&pwmbl->pdev->dev, "Atmel PWM backlight driver (%lu Hz)\n", + pwmbl->pwmc.mck / pwmbl->pdata->pwm_compare_max / + (1 << prescale)); return pwm_channel_enable(&pwmbl->pwmc); } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] proc: check vma->vm_file before dereferencing
16.10.2012 01:40, Andrew Morton пишет: On Mon, 15 Oct 2012 19:30:03 +0400 Stanislav Kinsbursky wrote: It can be equal to NULL. Please write better changelogs, so people do not have to ask questions such as: - Under what conditions does this bug trigger? - In which kernel version(s)? - Is it a post-3.6 regression? Sure. Sorry. Thanks. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/17] backlight: corgi_lcd: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: please, no space before tabs
WARNING: quoted string split across lines
ERROR: space required before the open parenthesis '('
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/corgi_lcd.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/corgi_lcd.c
b/drivers/video/backlight/corgi_lcd.c
index c781768..7171815 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -6,8 +6,8 @@
* Based on Sharp's 2.4 Backlight Driver
*
* Copyright (c) 2008 Marvell International Ltd.
- * Converted to SPI device based LCD/Backlight device driver
- * by Eric Miao
+ * Converted to SPI device based LCD/Backlight device driver
+ * by Eric Miao
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -192,7 +192,7 @@ static void lcdtg_set_phadadj(struct corgi_lcd *lcd, int
mode)
{
int adj;
- switch(mode) {
+ switch (mode) {
case CORGI_LCD_MODE_VGA:
/* Setting for VGA */
adj = sharpsl_param.phadadj;
@@ -495,8 +495,9 @@ static int setup_gpio_backlight(struct corgi_lcd *lcd,
err = devm_gpio_request(&spi->dev, pdata->gpio_backlight_on,
"BL_ON");
if (err) {
- dev_err(&spi->dev, "failed to request GPIO%d for "
- "backlight_on\n", pdata->gpio_backlight_on);
+ dev_err(&spi->dev,
+ "failed to request GPIO%d for backlight_on\n",
+ pdata->gpio_backlight_on);
return err;
}
@@ -508,8 +509,9 @@ static int setup_gpio_backlight(struct corgi_lcd *lcd,
err = devm_gpio_request(&spi->dev, pdata->gpio_backlight_cont,
"BL_CONT");
if (err) {
- dev_err(&spi->dev, "failed to request GPIO%d for "
- "backlight_cont\n", pdata->gpio_backlight_cont);
+ dev_err(&spi->dev,
+ "failed to request GPIO%d for backlight_cont\n",
+ pdata->gpio_backlight_cont);
return err;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/17] backlight: da903x_bl: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
WARNING: quoted string split across lines
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/da903x_bl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/da903x_bl.c
b/drivers/video/backlight/da903x_bl.c
index 573c7ec..f02e95c 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -2,10 +2,10 @@
* Backlight driver for Dialog Semiconductor DA9030/DA9034
*
* Copyright (C) 2008 Compulab, Ltd.
- * Mike Rapoport
+ * Mike Rapoport
*
* Copyright (C) 2006-2008 Marvell International Ltd.
- * Eric Miao
+ * Eric Miao
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -199,7 +199,7 @@ static struct platform_driver da903x_backlight_driver = {
module_platform_driver(da903x_backlight_driver);
MODULE_DESCRIPTION("Backlight Driver for Dialog Semiconductor DA9030/DA9034");
-MODULE_AUTHOR("Eric Miao "
- "Mike Rapoport ");
+MODULE_AUTHOR("Eric Miao ");
+MODULE_AUTHOR("Mike Rapoport ");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:da903x-backlight");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/17] backlight: generic_bl: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: space prohibited between function name and open parenthesis '('
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/generic_bl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/generic_bl.c
b/drivers/video/backlight/generic_bl.c
index 8c660fc..0ae155b 100644
--- a/drivers/video/backlight/generic_bl.c
+++ b/drivers/video/backlight/generic_bl.c
@@ -97,8 +97,8 @@ static int genericbl_probe(struct platform_device *pdev)
props.max_brightness = machinfo->max_intensity;
bd = backlight_device_register(name, &pdev->dev, NULL, &genericbl_ops,
&props);
- if (IS_ERR (bd))
- return PTR_ERR (bd);
+ if (IS_ERR(bd))
+ return PTR_ERR(bd);
platform_set_drvdata(pdev, bd);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/17] backlight: hp680_bl: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: please, no space before tabs
WARNING: please, no spaces at the start of a line
ERROR: do not initialise statics to 0 or NULL
ERROR: code indent should use tabs where possible
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/hp680_bl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/hp680_bl.c
b/drivers/video/backlight/hp680_bl.c
index 38aa002..191fbed 100644
--- a/drivers/video/backlight/hp680_bl.c
+++ b/drivers/video/backlight/hp680_bl.c
@@ -26,7 +26,7 @@
#define HP680_DEFAULT_INTENSITY 10
static int hp680bl_suspended;
-static int current_intensity = 0;
+static int current_intensity;
static DEFINE_SPINLOCK(bl_lock);
static void hp680bl_send_intensity(struct backlight_device *bd)
@@ -168,7 +168,7 @@ static int __init hp680bl_init(void)
static void __exit hp680bl_exit(void)
{
platform_device_unregister(hp680bl_device);
- platform_driver_unregister(&hp680bl_driver);
+ platform_driver_unregister(&hp680bl_driver);
}
module_init(hp680bl_init);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/17] backlight: ili9320: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: please, no space before tabs
WARNING: please, no spaces at the start of a line
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
WARNING: braces {} are not necessary for single statement blocks
ERROR: code indent should use tabs where possible
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/ili9320.c | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/ili9320.c
b/drivers/video/backlight/ili9320.c
index 9327cd1..a66cfd1 100644
--- a/drivers/video/backlight/ili9320.c
+++ b/drivers/video/backlight/ili9320.c
@@ -45,7 +45,7 @@ static inline int ili9320_write_spi(struct ili9320 *ili,
/* second message is the data to transfer */
data[0] = spi->id | ILI9320_SPI_DATA | ILI9320_SPI_WRITE;
- data[1] = value >> 8;
+ data[1] = value >> 8;
data[2] = value;
return spi_sync(spi->dev, &spi->message);
@@ -56,7 +56,6 @@ int ili9320_write(struct ili9320 *ili, unsigned int reg,
unsigned int value)
dev_dbg(ili->dev, "write: reg=%02x, val=%04x\n", reg, value);
return ili->write(ili, reg, value);
}
-
EXPORT_SYMBOL_GPL(ili9320_write);
int ili9320_write_regs(struct ili9320 *ili,
@@ -74,7 +73,6 @@ int ili9320_write_regs(struct ili9320 *ili,
return 0;
}
-
EXPORT_SYMBOL_GPL(ili9320_write_regs);
static void ili9320_reset(struct ili9320 *lcd)
@@ -260,7 +258,6 @@ int __devinit ili9320_probe_spi(struct spi_device *spi,
return ret;
}
-
EXPORT_SYMBOL_GPL(ili9320_probe_spi);
int ili9320_remove(struct ili9320 *ili)
@@ -271,7 +268,6 @@ int ili9320_remove(struct ili9320 *ili)
return 0;
}
-
EXPORT_SYMBOL_GPL(ili9320_remove);
#ifdef CONFIG_PM
@@ -296,20 +292,17 @@ int ili9320_suspend(struct ili9320 *lcd, pm_message_t
state)
return 0;
}
-
EXPORT_SYMBOL_GPL(ili9320_suspend);
int ili9320_resume(struct ili9320 *lcd)
{
dev_info(lcd->dev, "resuming from power state %d\n", lcd->power);
- if (lcd->platdata->suspend == ILI9320_SUSPEND_DEEP) {
+ if (lcd->platdata->suspend == ILI9320_SUSPEND_DEEP)
ili9320_write(lcd, ILI9320_POWER1, 0x00);
- }
return ili9320_power(lcd, FB_BLANK_UNBLANK);
}
-
EXPORT_SYMBOL_GPL(ili9320_resume);
#endif
@@ -318,7 +311,6 @@ void ili9320_shutdown(struct ili9320 *lcd)
{
ili9320_power(lcd, FB_BLANK_POWERDOWN);
}
-
EXPORT_SYMBOL_GPL(ili9320_shutdown);
MODULE_AUTHOR("Ben Dooks ");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
On Tue, 16 Oct 2012, Mark Brown wrote: > On Mon, Oct 15, 2012 at 02:16:59PM +0100, Lee Jones wrote: > > Here we provide the GPIO Regulator driver with Device Tree capability, so > > that when a platform is booting with DT instead of platform data we can > > still make full use of it. > > Not looked at the patch yet but patch 2 doesn't seem to have appeared? Has it arrived yet? Arnd responded to it, so it hit the list. Since Arnd's comments I've also fired v2 up - do you see it/them? -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/17] backlight: jornada720: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: line over 80 characters
ERROR: return is not a function, parentheses are not required
Also, long comments are fixed for the preferred style.
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/jornada720_bl.c | 34 ++---
drivers/video/backlight/jornada720_lcd.c |3 +-
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/video/backlight/jornada720_bl.c
b/drivers/video/backlight/jornada720_bl.c
index 16f593b..c23801c 100644
--- a/drivers/video/backlight/jornada720_bl.c
+++ b/drivers/video/backlight/jornada720_bl.c
@@ -48,7 +48,7 @@ static int jornada_bl_get_brightness(struct backlight_device
*bd)
jornada_ssp_end();
- return (BL_MAX_BRIGHT - ret);
+ return BL_MAX_BRIGHT - ret;
}
static int jornada_bl_update_status(struct backlight_device *bd)
@@ -58,7 +58,8 @@ static int jornada_bl_update_status(struct backlight_device
*bd)
jornada_ssp_start();
/* If backlight is off then really turn it off */
- if ((bd->props.power != FB_BLANK_UNBLANK) || (bd->props.fb_blank !=
FB_BLANK_UNBLANK)) {
+ if ((bd->props.power != FB_BLANK_UNBLANK) ||
+ (bd->props.fb_blank != FB_BLANK_UNBLANK)) {
ret = jornada_ssp_byte(BRIGHTNESSOFF);
if (ret != TXDUMMY) {
pr_info("brightness off timeout\n");
@@ -77,18 +78,23 @@ static int jornada_bl_update_status(struct backlight_device
*bd)
goto out;
}
- /* at this point we expect that the mcu has accepted
- our command and is waiting for our new value
- please note that maximum brightness is 255,
- but due to physical layout it is equal to 0, so we simply
- invert the value (MAX VALUE - NEW VALUE). */
- if (jornada_ssp_byte(BL_MAX_BRIGHT - bd->props.brightness) !=
TXDUMMY) {
+ /*
+* at this point we expect that the mcu has accepted
+* our command and is waiting for our new value
+* please note that maximum brightness is 255,
+* but due to physical layout it is equal to 0, so we simply
+* invert the value (MAX VALUE - NEW VALUE).
+*/
+ if (jornada_ssp_byte(BL_MAX_BRIGHT - bd->props.brightness)
+ != TXDUMMY) {
pr_err("set brightness failed\n");
ret = -ETIMEDOUT;
}
- /* If infact we get an TXDUMMY as output we are happy and dont
- make any further comments about it */
+ /*
+* If infact we get an TXDUMMY as output we are happy and dont
+* make any further comments about it
+*/
out:
jornada_ssp_end();
@@ -121,9 +127,11 @@ static int jornada_bl_probe(struct platform_device *pdev)
bd->props.power = FB_BLANK_UNBLANK;
bd->props.brightness = BL_DEF_BRIGHT;
- /* note. make sure max brightness is set otherwise
- you will get seemingly non-related errors when
- trying to change brightness */
+ /*
+* note. make sure max brightness is set otherwise
+* you will get seemingly non-related errors when
+* trying to change brightness
+*/
jornada_bl_update_status(bd);
platform_set_drvdata(pdev, bd);
diff --git a/drivers/video/backlight/jornada720_lcd.c
b/drivers/video/backlight/jornada720_lcd.c
index 635b305..4b412cb 100644
--- a/drivers/video/backlight/jornada720_lcd.c
+++ b/drivers/video/backlight/jornada720_lcd.c
@@ -101,7 +101,8 @@ static int jornada_lcd_probe(struct platform_device *pdev)
struct lcd_device *lcd_device;
int ret;
- lcd_device = lcd_device_register(S1D_DEVICENAME, &pdev->dev, NULL,
&jornada_lcd_props);
+ lcd_device = lcd_device_register(S1D_DEVICENAME, &pdev->dev, NULL,
+ &jornada_lcd_props);
if (IS_ERR(lcd_device)) {
ret = PTR_ERR(lcd_device);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/17] backlight: l4f00242t03: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
Also, unnecessary line is removed.
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/l4f00242t03.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/l4f00242t03.c
b/drivers/video/backlight/l4f00242t03.c
index 2d90c06..472c7dc 100644
--- a/drivers/video/backlight/l4f00242t03.c
+++ b/drivers/video/backlight/l4f00242t03.c
@@ -4,7 +4,7 @@
* Copyright 2007-2009 Freescale Semiconductor, Inc. All Rights Reserved.
*
* Copyright (c) 2009 Alberto Panizzo
- * Inspired by Marek Vasut work in l4f00242t03.c
+ * Inspired by Marek Vasut work in l4f00242t03.c
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -33,7 +33,6 @@ struct l4f00242t03_priv {
struct regulator *core_reg;
};
-
static void l4f00242t03_reset(unsigned int gpio)
{
pr_debug("l4f00242t03_reset.\n");
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/17] backlight: lm3630: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: static const char * array should probably be static const char * const
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/lm3630_bl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/lm3630_bl.c
b/drivers/video/backlight/lm3630_bl.c
index dc19144..a56f6a8 100644
--- a/drivers/video/backlight/lm3630_bl.c
+++ b/drivers/video/backlight/lm3630_bl.c
@@ -37,7 +37,7 @@ enum lm3630_leds {
BLED_2
};
-static const char *bled_name[] = {
+static const char * const bled_name[] = {
[BLED_ALL] = "lm3630_bled", /*Bank1 controls all string */
[BLED_1] = "lm3630_bled1", /*Bank1 controls bled1 */
[BLED_2] = "lm3630_bled2", /*Bank1 or 2 controls bled2 */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/17] backlight: locomolcd: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: line over 80 characters
WARNING: space prohibited between function name and open parenthesis '('
ERROR: trailing statements should be on next line
Also, long comments are fixed for the preferred style and
unnecessary lines are removed.
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/locomolcd.c | 65 +++
1 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/drivers/video/backlight/locomolcd.c
b/drivers/video/backlight/locomolcd.c
index 3a6d541..4cfa87b 100644
--- a/drivers/video/backlight/locomolcd.c
+++ b/drivers/video/backlight/locomolcd.c
@@ -33,19 +33,25 @@ static unsigned long locomolcd_flags;
static void locomolcd_on(int comadj)
{
- locomo_gpio_set_dir(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHA_ON,
0);
- locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHA_ON,
1);
+ locomo_gpio_set_dir(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VSHA_ON, 0);
+ locomo_gpio_write(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VSHA_ON, 1);
mdelay(2);
- locomo_gpio_set_dir(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHD_ON,
0);
- locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHD_ON,
1);
+ locomo_gpio_set_dir(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VSHD_ON, 0);
+ locomo_gpio_write(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VSHD_ON, 1);
mdelay(2);
locomo_m62332_senddata(locomolcd_dev, comadj, 0);
mdelay(5);
- locomo_gpio_set_dir(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VEE_ON,
0);
- locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VEE_ON, 1);
+ locomo_gpio_set_dir(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VEE_ON, 0);
+ locomo_gpio_write(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VEE_ON, 1);
mdelay(10);
/* TFTCRST | CPSOUT=0 | CPSEN */
@@ -68,16 +74,19 @@ static void locomolcd_off(int comadj)
locomo_writel(0x06, locomolcd_dev->mapbase + LOCOMO_TC);
mdelay(1);
- locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHA_ON,
0);
+ locomo_gpio_write(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VSHA_ON, 0);
mdelay(110);
- locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VEE_ON, 0);
+ locomo_gpio_write(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VEE_ON, 0);
mdelay(700);
/* TFTCRST=0 | CPSOUT=0 | CPSEN = 0 */
locomo_writel(0, locomolcd_dev->mapbase + LOCOMO_TC);
locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_MOD, 0);
- locomo_gpio_write(locomolcd_dev->dev.parent, LOCOMO_GPIO_LCD_VSHD_ON,
0);
+ locomo_gpio_write(locomolcd_dev->dev.parent,
+ LOCOMO_GPIO_LCD_VSHD_ON, 0);
}
void locomolcd_power(int on)
@@ -107,7 +116,6 @@ void locomolcd_power(int on)
}
EXPORT_SYMBOL(locomolcd_power);
-
static int current_intensity;
static int locomolcd_set_intensity(struct backlight_device *bd)
@@ -122,13 +130,25 @@ static int locomolcd_set_intensity(struct
backlight_device *bd)
intensity = 0;
switch (intensity) {
- /* AC and non-AC are handled differently, but produce same results in
sharp code? */
- case 0: locomo_frontlight_set(locomolcd_dev, 0, 0, 161); break;
- case 1: locomo_frontlight_set(locomolcd_dev, 117, 0, 161); break;
- case 2: locomo_frontlight_set(locomolcd_dev, 163, 0, 148); break;
- case 3: locomo_frontlight_set(locomolcd_dev, 194, 0, 161); break;
- case 4: locomo_frontlight_set(locomolcd_dev, 194, 1, 161); break;
-
+ /*
+* AC and non-AC are handled differently,
+* but produce same results in sharp code?
+*/
+ case 0:
+ locomo_frontlight_set(locomolcd_dev, 0, 0, 161);
+ break;
+ case 1:
+ locomo_frontlight_set(locomolcd_dev, 117, 0, 161);
+ break;
+ case 2:
+ locomo_frontlight_set(locomolcd_dev, 163, 0, 148);
+ break;
+ case 3:
+ locomo_frontlight_set(locomolcd_dev, 194, 0, 161);
+ break;
+ case 4:
+ locomo_frontlight_set(locomolcd_dev, 194, 1, 161);
+ break;
default:
return -ENODEV;
}
@@ -175,9 +195,11 @@ static int locomolcd_probe(struct locomo_dev *ldev)
locomo_gpio_set_dir(ldev->dev.parent, LOCOMO_GPIO_FL_VR, 0);
- /* the poodle_lcd_power function is called for the first time
+ /*
+* the poodle_lcd_power function is called for the first time
* from fs_initcall, which is before locomo is activated.
-* We need to recall
[PATCH 12/17] backlight: omap1: fix checkpatch warning
This patch fixes the checkpatch warning as below:
ERROR: inline keyword should sit between storage class and type
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/omap1_bl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/omap1_bl.c
b/drivers/video/backlight/omap1_bl.c
index 9a046a4..af31c26 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -42,12 +42,12 @@ struct omap_backlight {
struct omap_backlight_config *pdata;
};
-static void inline omapbl_send_intensity(int intensity)
+static inline void omapbl_send_intensity(int intensity)
{
omap_writeb(intensity, OMAP_PWL_ENABLE);
}
-static void inline omapbl_send_enable(int enable)
+static inline void omapbl_send_enable(int enable)
{
omap_writeb(enable, OMAP_PWL_CLK_ENABLE);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/17] backlight: pcf50633: fix checkpatch warning
This patch fixes the checkpatch warning as below: WARNING: please, no spaces at the start of a line Also, long comments are fixed for the preferred style. Signed-off-by: Jingoo Han Cc: Richard Purdie --- drivers/video/backlight/pcf50633-backlight.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/video/backlight/pcf50633-backlight.c b/drivers/video/backlight/pcf50633-backlight.c index c092159..930fc2a 100644 --- a/drivers/video/backlight/pcf50633-backlight.c +++ b/drivers/video/backlight/pcf50633-backlight.c @@ -52,7 +52,7 @@ int pcf50633_bl_set_brightness_limit(struct pcf50633 *pcf, unsigned int limit) pcf_bl->brightness_limit = limit & 0x3f; backlight_update_status(pcf_bl->bl); -return 0; + return 0; } static int pcf50633_bl_update_status(struct backlight_device *bl) @@ -136,8 +136,10 @@ static int __devinit pcf50633_bl_probe(struct platform_device *pdev) pcf50633_reg_write(pcf_bl->pcf, PCF50633_REG_LEDDIM, pdata->ramp_time); - /* Should be different from bl_props.brightness, so we do not exit -* update_status early the first time it's called */ + /* +* Should be different from bl_props.brightness, so we do not exit +* update_status early the first time it's called +*/ pcf_bl->brightness = pcf_bl->bl->props.brightness + 1; backlight_update_status(pcf_bl->bl); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/17] backlight: platform_lcd: fix checkpatch error
This patch fixes the checkpatch error as below:
ERROR: spaces prohibited around that ':' (ctx:WxW)
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/platform_lcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/platform_lcd.c
b/drivers/video/backlight/platform_lcd.c
index ca4f5d7..74cfca4 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -27,7 +27,7 @@ struct platform_lcd {
struct plat_lcd_data*pdata;
unsigned int power;
- unsigned int suspended : 1;
+ unsigned int suspended:1;
};
static inline struct platform_lcd *to_our_lcd(struct lcd_device *lcd)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/17] backlight: tdo24m: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/tdo24m.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index 02444d0..0f6eaa4 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -2,7 +2,7 @@
* tdo24m - SPI-based drivers for Toppoly TDO24M series LCD panels
*
* Copyright (C) 2008 Marvell International Ltd.
- * Eric Miao
+ * Eric Miao
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -90,7 +90,7 @@ static uint32_t lcd_qvga_pass_through_tdo24m[] = {
};
static uint32_t lcd_vga_transfer_tdo24m[] = {
- CMD1(0xcf, 0x02), /* Blanking period control (1) */
+ CMD1(0xcf, 0x02), /* Blanking period control (1) */
CMD2(0xd0, 0x08, 0x04), /* Blanking period control (2) */
CMD1(0xd1, 0x01), /* CKV timing control on/off */
CMD2(0xd2, 0x14, 0x00), /* CKV 1,2 timing control */
@@ -132,7 +132,7 @@ static uint32_t lcd_qvga_pass_through_tdo35s[] = {
};
static uint32_t lcd_vga_transfer_tdo35s[] = {
- CMD1(0xcf, 0x02), /* Blanking period control (1) */
+ CMD1(0xcf, 0x02), /* Blanking period control (1) */
CMD2(0xd0, 0x08, 0x04), /* Blanking period control (2) */
CMD1(0xd1, 0x01), /* CKV timing control on/off */
CMD2(0xd2, 0x00, 0x1e), /* CKV 1,2 timing control */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/17] backlight: tosa: fix checkpatch error and warning
This patch fixes the checkpatch error and warning as below:
WARNING: line over 80 characters
ERROR: spaces required around that '?' (ctx:VxW)
ERROR: space required after that ',' (ctx:VxV)
Also, unnecessary lines are removed.
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/tosa_bl.c |4 ++--
drivers/video/backlight/tosa_lcd.c | 16 +---
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/video/backlight/tosa_bl.c
b/drivers/video/backlight/tosa_bl.c
index 49342e1..03c6ec2 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -90,7 +90,8 @@ static int __devinit tosa_bl_probe(struct i2c_client *client,
if (!data)
return -ENOMEM;
- data->comadj = sharpsl_param.comadj == -1 ? COMADJ_DEFAULT :
sharpsl_param.comadj;
+ data->comadj = sharpsl_param.comadj == -1 ?
+ COMADJ_DEFAULT : sharpsl_param.comadj;
ret = devm_gpio_request(&client->dev, TOSA_GPIO_BL_C20MA, "backlight");
if (ret) {
@@ -163,7 +164,6 @@ static const struct i2c_device_id tosa_bl_id[] = {
{ },
};
-
static struct i2c_driver tosa_bl_driver = {
.driver = {
.name = "tosa-bl",
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
index 33047a6..bcd97c5 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -63,7 +63,7 @@ static int tosa_tg_send(struct spi_device *spi, int adrs,
uint8_t data)
int tosa_bl_enable(struct spi_device *spi, int enable)
{
/* bl_enable GP04=1 otherwise GP04=0*/
- return tosa_tg_send(spi, TG_GPODR2, enable? 0x01 : 0x00);
+ return tosa_tg_send(spi, TG_GPODR2, enable ? 0x01 : 0x00);
}
EXPORT_SYMBOL(tosa_bl_enable);
@@ -91,15 +91,17 @@ static void tosa_lcd_tg_on(struct tosa_lcd_data *data)
tosa_tg_send(spi, TG_PNLCTL, value);
/* TG LCD pannel power up */
- tosa_tg_send(spi, TG_PINICTL,0x4);
+ tosa_tg_send(spi, TG_PINICTL, 0x4);
mdelay(50);
/* TG LCD GVSS */
- tosa_tg_send(spi, TG_PINICTL,0x0);
+ tosa_tg_send(spi, TG_PINICTL, 0x0);
if (!data->i2c) {
- /* after the pannel is powered up the first time, we can access
the i2c bus */
- /* so probe for the DAC */
+ /*
+* after the pannel is powered up the first time,
+* we can access the i2c bus so probe for the DAC
+*/
struct i2c_adapter *adap = i2c_get_adapter(0);
struct i2c_board_info info = {
.type = "tosa-bl",
@@ -115,11 +117,11 @@ static void tosa_lcd_tg_off(struct tosa_lcd_data *data)
struct spi_device *spi = data->spi;
/* TG LCD VHSA off */
- tosa_tg_send(spi, TG_PINICTL,0x4);
+ tosa_tg_send(spi, TG_PINICTL, 0x4);
mdelay(50);
/* TG LCD signal off */
- tosa_tg_send(spi, TG_PINICTL,0x6);
+ tosa_tg_send(spi, TG_PINICTL, 0x6);
mdelay(50);
/* TG Off */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/17] backlight: vgg2432a4: fix checkpatch warning
This patch fixes the checkpatch warning as below:
WARNING: please, no space before tabs
Signed-off-by: Jingoo Han
Cc: Richard Purdie
---
drivers/video/backlight/vgg2432a4.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/vgg2432a4.c
b/drivers/video/backlight/vgg2432a4.c
index b617fae..b1ead3d 100644
--- a/drivers/video/backlight/vgg2432a4.c
+++ b/drivers/video/backlight/vgg2432a4.c
@@ -217,7 +217,7 @@ static int vgg2432a4_resume(struct spi_device *spi)
}
#else
#define vgg2432a4_suspend NULL
-#define vgg2432a4_resume NULL
+#define vgg2432a4_resume NULL
#endif
static struct ili9320_client vgg2432a4_client = {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Boottime: A tool for automatic measurement of kernel/bootloader boot time
> >>root@ME:/ cat /sys/kernel/debug/boottime/bootgraph
> >>[0.185254] calling splash+0x0/0x0
> >>[2.984335] initcall splash+0x0/0x0 returned 0 after 2799 msecs.
> >>[2.984335] calling autoboot_delay+0x0/0x0
> >>[4.089513] initcall autoboot_delay+0x0/0x0 returned 0 after 1105
> >>msecs.
> >>[4.089513] calling load_kernel+0x0/0x0
> >>[4.239174] initcall load_kernel+0x0/0x0 returned 0 after 149 msecs.
> >>[4.239174] calling boot_kernel+0x0/0x0
> >>[4.276260] initcall boot_kernel+0x0/0x0 returned 0 after 37 msecs.
> >>[4.276260] calling uncompress_ll_init+0x0/0x0
> >>[4.276260] initcall uncompress_ll_init+0x0/0x0 returned 0 after 0
> >>msecs.
> >>[4.276260] Freeing init memory: 0K
> >commit 4c49a18bcfd2d041cbad7f41c6e6b39d90008382 (HEAD,
> >refs/heads/dt-snowball-pre-rc1)
> >Author: Jonas Aaberg
> >Date: Wed Sep 14 09:29:20 2011 +0200
> >
> > drivers: clocksource: dbx500-prcmu: Add boottime support
> >
> > Change-Id: I9b5e3d050131c08c08786ae84cb76619c0525049
> > Signed-off-by: Jonas Aaberg
> > Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/32055
> >
> >diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c
> >b/drivers/clocksource/clksrc-dbx500-prcmu.c
> >index c26c369..0069cd9 100644
> >--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
> >+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
> >@@ -14,6 +14,7 @@
> > */
> > #include
> > #include
> >+#include
> >
> > #include
> >
> >@@ -68,6 +69,23 @@ static u32 notrace dbx500_prcmu_sched_clock_read(void)
> >
> > #endif
> >
> >+#ifdef CONFIG_BOOTTIME
> >+static unsigned long __init boottime_get_time(void)
> >+{
> >+return div_s64(clocksource_cyc2ns(clocksource_dbx500_prcmu.read(
> >+&clocksource_dbx500_prcmu),
> >+ clocksource_dbx500_prcmu.mult,
> >+ clocksource_dbx500_prcmu.shift),
> >+ 1000);
> >+}
> >+
> >+static struct boottime_timer __initdata boottime_timer = {
> >+.init = NULL,
> >+.get_time = boottime_get_time,
> >+.finalize = NULL,
> >+};
> >+#endif
> >+
> > void __init clksrc_dbx500_prcmu_init(void __iomem *base)
> > {
> > clksrc_dbx500_timer_base = base;
> >@@ -90,4 +108,6 @@ void __init clksrc_dbx500_prcmu_init(void __iomem *base)
> > 32, RATE_32K);
> > #endif
> > clocksource_register_hz(&clocksource_dbx500_prcmu, RATE_32K);
> >+
> >+boottime_activate(&boottime_timer);
> > }
> >
>
> OK So has this been validated and tested on any other IC then a ST part?
> This boottime_activate patch seems to be only for the dbx500. If
> this is supposed to be a generic solution I would expect
> a generic patch for ARM to enable boot time activation.
No, this is essentially an STE patch. We don't have access to any other
hardware, so we'd be reliant on kindhearted soles to test on their h/w.
I guess something like Beagleboard and/or Panda would be ideal. Know
anyone? ;)
> Have you profiled how much time the boot time logging has added to
> the over all boot?
> Also the boottime commit message should explain a little more what
> it is measuring.
> i.e. This patch enables logging the boot time from point x to point
> y for the kernel only. This does not include init.
>
> What about adding the boot time from the init sequence to init complete?
I don't know the answers to these questions, but I'll endeavour to find
out and get back to you posthaste.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/3] USB: forbid memory allocation with I/O during bus reset if storage interface exits
On Tue, Oct 16, 2012 at 12:48 AM, Greg Kroah-Hartman wrote: > > No, don't limit us for no good reason, that's not acceptable at all. > Patching old kernels when new devices show up that work on those old > kernels (like USB network devices that follow the spec with no driver > change needed), is not a good idea. > > So I agree with Oliver here, this isn't acceptable. OK, I will remove the limit in -v1 and add comments on the case. thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 0/8] TI Touchscreen driver updates and Support for TSC/ADC MFD driver
This patch set is a cumulative set of [1] and [2] sent earlier. I have merged the patch set so that the MFD patches apply without any issues. Also Note that there are no code changes in either of the patch set, only rebased on top of linux-next to make sure that all the patches apply without any conflicts. This patch set has been tested on AM335x EVM. [1] "[PATCH 0/4] input: TSC: ti_tscadc: TI Touchscreen driver updates" (http://www.spinics.net/lists/linux-input/msg22107.html) [2] "[PATCH v5 0/4] Support for TSC/ADC MFD driver" (http://www.spinics.net/lists/linux-input/msg22832.html) Patil, Rachna (8): input: TSC: ti_tscadc: Correct register usage input: TSC: ti_tscadc: Add Step configuration as platform data input: TSC: ti_tscadc: set FIFO0 threshold Interrupt input: TSC: ti_tscadc: Remove definition of End Of Interrupt register input: TSC: ti_tscadc: Rename the existing touchscreen driver MFD: ti_tscadc: Add support for TI's TSC/ADC MFDevice input: TSC: ti_tsc: Convert TSC into a MFDevice IIO : ADC: tiadc: Add support of TI's ADC driver drivers/iio/adc/Kconfig |7 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/ti_am335x_adc.c | 260 ++ drivers/input/touchscreen/Kconfig |6 +- drivers/input/touchscreen/Makefile |2 +- drivers/input/touchscreen/ti_am335x_tsc.c | 398 ++ drivers/input/touchscreen/ti_tscadc.c | 486 --- drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile|1 + drivers/mfd/ti_am335x_tscadc.c | 277 +++ include/linux/input/ti_am335x_tsc.h | 23 ++ include/linux/input/ti_tscadc.h | 17 - include/linux/mfd/ti_am335x_tscadc.h| 152 + include/linux/platform_data/ti_am335x_adc.h | 14 + 14 files changed, 1148 insertions(+), 507 deletions(-) create mode 100644 drivers/iio/adc/ti_am335x_adc.c create mode 100644 drivers/input/touchscreen/ti_am335x_tsc.c delete mode 100644 drivers/input/touchscreen/ti_tscadc.c create mode 100644 drivers/mfd/ti_am335x_tscadc.c create mode 100644 include/linux/input/ti_am335x_tsc.h delete mode 100644 include/linux/input/ti_tscadc.h create mode 100644 include/linux/mfd/ti_am335x_tscadc.h create mode 100644 include/linux/platform_data/ti_am335x_adc.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 3/8] input: TSC: ti_tscadc: set FIFO0 threshold Interrupt
Code currently uses FIFO1 threshold interrupt.
since this is a MFD, Dedicating FIFO0 to touchscreen
and making way for other devices to use FIFO1 as well.
The FIFO can be shared between 2 devices but since the
interrupt used is threshold interrupt on FIFO1, we would
end up having wrong interrupts. Hence changing the same.
Signed-off-by: Patil, Rachna
---
drivers/input/touchscreen/ti_tscadc.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/ti_tscadc.c
b/drivers/input/touchscreen/ti_tscadc.c
index c1bd8e5..2cc19b0 100644
--- a/drivers/input/touchscreen/ti_tscadc.c
+++ b/drivers/input/touchscreen/ti_tscadc.c
@@ -42,6 +42,7 @@
#define REG_STEPCONFIG(n) (0x64 + ((n - 1) * 8))
#define REG_STEPDELAY(n) (0x68 + ((n - 1) * 8))
#define REG_FIFO0CNT 0xE4
+#define REG_FIFO0THR 0xE8
#define REG_FIFO1THR 0xF4
#define REG_FIFO0 0x100
#define REG_FIFO1 0x200
@@ -55,6 +56,7 @@
#define STPENB_STEPENB STEPENB(0x7FFF)
/* IRQ enable */
+#define IRQENB_FIFO0THRES BIT(2)
#define IRQENB_FIFO1THRES BIT(5)
#define IRQENB_PENUP BIT(9)
@@ -277,7 +279,7 @@ static irqreturn_t tscadc_irq(int irq, void *dev)
unsigned int fsm;
status = tscadc_readl(ts_dev, REG_IRQSTATUS);
- if (status & IRQENB_FIFO1THRES) {
+ if (status & IRQENB_FIFO0THRES) {
tscadc_read_coordinates(ts_dev, &x, &y);
z1 = tscadc_readl(ts_dev, REG_FIFO0) & 0xfff;
@@ -303,7 +305,7 @@ static irqreturn_t tscadc_irq(int irq, void *dev)
input_sync(input_dev);
}
}
- irqclr |= IRQENB_FIFO1THRES;
+ irqclr |= IRQENB_FIFO0THRES;
}
/*
@@ -446,9 +448,9 @@ static int __devinit tscadc_probe(struct platform_device
*pdev)
tscadc_writel(ts_dev, REG_CTRL, ctrl);
tscadc_idle_config(ts_dev);
- tscadc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO1THRES);
+ tscadc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
tscadc_step_config(ts_dev);
- tscadc_writel(ts_dev, REG_FIFO1THR, ts_dev->steps_to_configure);
+ tscadc_writel(ts_dev, REG_FIFO0THR, ts_dev->steps_to_configure);
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(ts_dev, REG_CTRL, ctrl);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 2/8] input: TSC: ti_tscadc: Add Step configuration as platform data
There are 16 programmable Step Configuration
registers which are used by the sequencer.
Program the Steps in order to configure a channel
input to be sampled. If the same step is applied
several times, the coordinate values read are more
accurate.
Hence we provide the user an option of how many steps
should be configured.
For ex: If this value is assigned as 4, This means that
4 steps are applied to read x co-ordinate and 4 steps to read
y co-ordinate. Furtheron the interrupt handler already
holds code to use delta filter and report the best value
out of these values to the input sub-system.
Signed-off-by: Patil, Rachna
---
drivers/input/touchscreen/ti_tscadc.c | 25 +
include/linux/input/ti_tscadc.h |6 ++
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/ti_tscadc.c
b/drivers/input/touchscreen/ti_tscadc.c
index d198cab..c1bd8e5 100644
--- a/drivers/input/touchscreen/ti_tscadc.c
+++ b/drivers/input/touchscreen/ti_tscadc.c
@@ -41,10 +41,6 @@
#define REG_CHARGEDELAY0x060
#define REG_STEPCONFIG(n) (0x64 + ((n - 1) * 8))
#define REG_STEPDELAY(n) (0x68 + ((n - 1) * 8))
-#define REG_STEPCONFIG13 0x0C4
-#define REG_STEPDELAY130x0C8
-#define REG_STEPCONFIG14 0x0CC
-#define REG_STEPDELAY140x0D0
#define REG_FIFO0CNT 0xE4
#define REG_FIFO1THR 0xF4
#define REG_FIFO0 0x100
@@ -134,6 +130,7 @@ struct tscadc {
unsigned intwires;
unsigned intx_plate_resistance;
boolpen_down;
+ int steps_to_configure;
};
static unsigned int tscadc_readl(struct tscadc *ts, unsigned int reg)
@@ -150,9 +147,10 @@ static void tscadc_writel(struct tscadc *tsc, unsigned int
reg,
static void tscadc_step_config(struct tscadc *ts_dev)
{
unsigned intconfig;
- int i;
+ int i, total_steps;
/* Configure the Step registers */
+ total_steps = 2 * ts_dev->steps_to_configure;
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | STEPCONFIG_XPP;
@@ -170,7 +168,7 @@ static void tscadc_step_config(struct tscadc *ts_dev)
break;
}
- for (i = 1; i < 7; i++) {
+ for (i = 1; i <= ts_dev->steps_to_configure; i++) {
tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -192,7 +190,7 @@ static void tscadc_step_config(struct tscadc *ts_dev)
break;
}
- for (i = 7; i < 13; i++) {
+ for (i = (ts_dev->steps_to_configure + 1); i <= total_steps; i++) {
tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -211,12 +209,14 @@ static void tscadc_step_config(struct tscadc *ts_dev)
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | STEPCONFIG_YPP |
STEPCONFIG_XNN | STEPCONFIG_INM_ADCREFM;
- tscadc_writel(ts_dev, REG_STEPCONFIG13, config);
- tscadc_writel(ts_dev, REG_STEPDELAY13, STEPCONFIG_OPENDLY);
+ tscadc_writel(ts_dev, REG_STEPCONFIG(total_steps + 1), config);
+ tscadc_writel(ts_dev, REG_STEPDELAY(total_steps + 1),
+ STEPCONFIG_OPENDLY);
config |= STEPCONFIG_INP_AN3 | STEPCONFIG_FIFO1;
- tscadc_writel(ts_dev, REG_STEPCONFIG14, config);
- tscadc_writel(ts_dev, REG_STEPDELAY14, STEPCONFIG_OPENDLY);
+ tscadc_writel(ts_dev, REG_STEPCONFIG(total_steps + 2), config);
+ tscadc_writel(ts_dev, REG_STEPDELAY(total_steps + 2),
+ STEPCONFIG_OPENDLY);
tscadc_writel(ts_dev, REG_SE, STPENB_STEPENB);
}
@@ -379,6 +379,7 @@ static int __devinit tscadc_probe(struct platform_device
*pdev)
ts_dev->irq = irq;
ts_dev->wires = pdata->wires;
ts_dev->x_plate_resistance = pdata->x_plate_resistance;
+ ts_dev->steps_to_configure = pdata->steps_to_configure;
res = request_mem_region(res->start, resource_size(res), pdev->name);
if (!res) {
@@ -447,7 +448,7 @@ static int __devinit tscadc_probe(struct platform_device
*pdev)
tscadc_idle_config(ts_dev);
tscadc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO1THRES);
tscadc_step_config(ts_dev);
- tscadc_writel(ts_dev, REG_FIFO1THR, 6);
+ tscadc_writel(ts_dev, REG_FIFO1THR, ts_dev->steps_to_configure);
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(ts_dev, REG_CTRL, ctrl);
diff --git a/include/linux/input/ti_tscadc.h b/include/linux/input/ti_tscadc.h
index b10a527..ad442a3 100644
--- a/include/linux/input/ti_tscadc.h
+++ b/include/linux/input/ti_tscadc.h
@@ -7,11 +7,17 @@
* i.e. 4/5/8 wire touchscreen support
* on the pl
[PATCH RESEND 1/8] input: TSC: ti_tscadc: Correct register usage
This patch cleans up the wrong register definitions and usage for touchscreen controller. Bit masks were not defined earlier. For ex: consider a register define as: write(xyz, ABC) ABC is expected to be written to register bits 0-11. Here we see that value written is as expected, but this write is also affecting all the remaining bits of xyz. The remaining bits hold the default value as 0 and the write also sets it to zero. Hence wrong usage were not causing user visible bugs. Due to these reasons it was difficult to follow when compared with TRM. Unused definitions are also removed. Since there is change in some naming convention because of all the above mentioned reasons, the same has been updated throughout the code. Bit declarations are grouped to increase readability. Signed-off-by: Patil, Rachna --- drivers/input/touchscreen/ti_tscadc.c | 128 + 1 files changed, 82 insertions(+), 46 deletions(-) diff --git a/drivers/input/touchscreen/ti_tscadc.c b/drivers/input/touchscreen/ti_tscadc.c index d229c74..d198cab 100644 --- a/drivers/input/touchscreen/ti_tscadc.c +++ b/drivers/input/touchscreen/ti_tscadc.c @@ -52,43 +52,79 @@ /* Register Bitfields */ #define IRQWKUP_ENBBIT(0) -#define STPENB_STEPENB 0x7FFF + +/* Step Enable */ +#define STEPENB_MASK (0x1 << 0) +#define STEPENB(val) (val << 0) +#define STPENB_STEPENB STEPENB(0x7FFF) + +/* IRQ enable */ #define IRQENB_FIFO1THRES BIT(5) #define IRQENB_PENUP BIT(9) -#define STEPCONFIG_MODE_HWSYNC 0x2 -#define STEPCONFIG_SAMPLES_AVG (1 << 4) -#define STEPCONFIG_XPP (1 << 5) -#define STEPCONFIG_XNN (1 << 6) -#define STEPCONFIG_YPP (1 << 7) -#define STEPCONFIG_YNN (1 << 8) -#define STEPCONFIG_XNP (1 << 9) -#define STEPCONFIG_YPN (1 << 10) -#define STEPCONFIG_INM (1 << 18) -#define STEPCONFIG_INP (1 << 20) -#define STEPCONFIG_INP_5 (1 << 21) -#define STEPCONFIG_FIFO1 (1 << 26) -#define STEPCONFIG_OPENDLY 0xff -#define STEPCONFIG_Z1 (3 << 19) -#define STEPIDLE_INP (1 << 22) -#define STEPCHARGE_RFP (1 << 12) -#define STEPCHARGE_INM (1 << 15) -#define STEPCHARGE_INP (1 << 19) -#define STEPCHARGE_RFM (1 << 23) -#define STEPCHARGE_DELAY 0x1 -#define CNTRLREG_TSCSSENB (1 << 0) -#define CNTRLREG_STEPID(1 << 1) -#define CNTRLREG_STEPCONFIGWRT (1 << 2) -#define CNTRLREG_4WIRE (1 << 5) -#define CNTRLREG_5WIRE (1 << 6) -#define CNTRLREG_8WIRE (3 << 5) -#define CNTRLREG_TSCENB(1 << 7) -#define ADCFSM_STEPID 0x10 +/* Step Configuration */ +#define STEPCONFIG_MODE_MASK (3 << 0) +#define STEPCONFIG_MODE(val) (val << 0) +#define STEPCONFIG_MODE_HWSYNC STEPCONFIG_MODE(2) +#define STEPCONFIG_AVG_MASK(7 << 2) +#define STEPCONFIG_AVG(val)(val << 2) +#define STEPCONFIG_AVG_16 STEPCONFIG_AVG(4) +#define STEPCONFIG_XPP BIT(5) +#define STEPCONFIG_XNN BIT(6) +#define STEPCONFIG_YPP BIT(7) +#define STEPCONFIG_YNN BIT(8) +#define STEPCONFIG_XNP BIT(9) +#define STEPCONFIG_YPN BIT(10) +#define STEPCONFIG_INM_MASK(0xF << 15) +#define STEPCONFIG_INM(val)(val << 15) +#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8) +#define STEPCONFIG_INP_MASK(0xF << 19) +#define STEPCONFIG_INP(val)(val << 19) +#define STEPCONFIG_INP_AN2 STEPCONFIG_INP(2) +#define STEPCONFIG_INP_AN3 STEPCONFIG_INP(3) +#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4) +#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8) +#define STEPCONFIG_FIFO1 BIT(26) + +/* Delay register */ +#define STEPDELAY_OPEN_MASK(0x3 << 0) +#define STEPDELAY_OPEN(val)(val << 0) +#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098) + +/* Charge Config */ +#define STEPCHARGE_RFP_MASK(7 << 12) +#define STEPCHARGE_RFP(val)(val << 12) +#define STEPCHARGE_RFP_XPULSTEPCHARGE_RFP(1) +#define STEPCHARGE_INM_MASK(0xF << 15) +#define STEPCHARGE_INM(val)(val << 15) +#define STEPCHARGE_INM_AN1 STEPCHARGE_INM(1) +#define STEPCHARGE_INP_MASK(0xF << 19) +#define STEPCHARGE_INP(val)(val << 19) +#define STEPCHARGE_INP_AN1 STEPCHARGE_INP(1) +#define STEPCHARGE_RFM_MASK(3 << 23) +#define STEPCHARGE_RFM(val)(val << 23) +#define STEPCHARGE_RFM_XNURSTEPCHARGE_RFM(1) + +/* Charge delay */ +#define CHARGEDLY_OPEN_MASK(0x3 << 0) +#define CHARGEDLY_OPEN(val)(val << 0) +#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(1) + +/* Control register */ +#define CNTRLREG_TSCSSENB BIT(0) +#define CNTRLREG_STEPIDBIT(1) +#define CNTRLREG_STEPCONFIGWRT BIT(2) +#define CNTRLREG_AFE_CTRL_MASK (3 << 5) +#define CNTRLREG_AFE_CTRL(val) (val << 5) +#define CNTRLREG_4WIRE CNTRLREG_AFE_CTRL(1) +#define CNTRLREG_5WIRE CNTRLREG_AFE_CTRL(2) +#define CNTRLREG_8WIRE CNTRLREG_AFE_C
[PATCH RESEND 8/8] IIO : ADC: tiadc: Add support of TI's ADC driver
This patch adds support for TI's ADC driver.
This is a multifunctional device.
Analog input lines are provided on which
voltage measurements can be carried out.
You can have upto 8 input lines.
Signed-off-by: Patil, Rachna
Acked-by: Jonathan Cameron
---
Changes in v2:
Addressed review comments from Matthias Kaehlcke
Changes in v3:
Addressed review comments from Jonathan Cameron.
Added comments, new line appropriately.
Changes in v4:
Removed extra comments and variables.
rename idev to indio_dev throughout the driver.
Renamed structs for better readability.
Changes in v5:
No changes
drivers/iio/adc/Kconfig |7 +
drivers/iio/adc/Makefile|1 +
drivers/iio/adc/ti_am335x_adc.c | 260 +++
drivers/mfd/ti_am335x_tscadc.c | 18 ++-
include/linux/mfd/ti_am335x_tscadc.h|9 +-
include/linux/platform_data/ti_am335x_adc.h | 14 ++
6 files changed, 307 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/adc/ti_am335x_adc.c
create mode 100644 include/linux/platform_data/ti_am335x_adc.h
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 4927581..1401ed1 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -60,4 +60,11 @@ config LP8788_ADC
help
Say yes here to build support for TI LP8788 ADC.
+config TI_AM335X_ADC
+ tristate "TI's ADC driver"
+ depends on MFD_TI_AM335X_TSCADC
+ help
+ Say yes here to build support for Texas Instruments ADC
+ driver which is also a MFD client.
+
endmenu
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 900995d..4410a90 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_AD7476) += ad7476.o
obj-$(CONFIG_AD7791) += ad7791.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
+obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
new file mode 100644
index 000..02a43c8
--- /dev/null
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -0,0 +1,260 @@
+/*
+ * TI ADC MFD driver
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct tiadc_device {
+ struct ti_tscadc_dev *mfd_tscadc;
+ int channels;
+};
+
+static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
+{
+ return readl(adc->mfd_tscadc->tscadc_base + reg);
+}
+
+static void tiadc_writel(struct tiadc_device *adc, unsigned int reg,
+ unsigned int val)
+{
+ writel(val, adc->mfd_tscadc->tscadc_base + reg);
+}
+
+static void tiadc_step_config(struct tiadc_device *adc_dev)
+{
+ unsigned int stepconfig;
+ int i, channels = 0, steps;
+
+ /*
+* There are 16 configurable steps and 8 analog input
+* lines available which are shared between Touchscreen and ADC.
+*
+* Steps backwards i.e. from 16 towards 0 are used by ADC
+* depending on number of input lines needed.
+* Channel would represent which analog input
+* needs to be given to ADC to digitalize data.
+*/
+
+ steps = TOTAL_STEPS - adc_dev->channels;
+ channels = TOTAL_CHANNELS - adc_dev->channels;
+
+ stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;
+
+ for (i = (steps + 1); i <= TOTAL_STEPS; i++) {
+ tiadc_writel(adc_dev, REG_STEPCONFIG(i),
+ stepconfig | STEPCONFIG_INP(channels));
+ tiadc_writel(adc_dev, REG_STEPDELAY(i),
+ STEPCONFIG_OPENDLY);
+ channels++;
+ }
+ tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+}
+
+static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
+{
+ struct iio_chan_spec *chan_array;
+ int i;
+
+ indio_dev->num_channels = channels;
+ chan_array = kcalloc(indio_dev->num_channels,
+ sizeof(struct iio_chan_spec), GFP_KERNEL);
+
+ if (chan_array == NULL)
+ return -ENOMEM;
+
+ for (i = 0; i < (indio_dev->num_channels); i++) {
+ struct iio_chan_spec *chan = chan_array + i;
+ chan->type = IIO_VOLTAGE;
+ chan->i
[PATCH RESEND 4/8] input: TSC: ti_tscadc: Remove definition of End Of Interrupt register
The touchscreen IP uses level sensitive interrupts rather than edge sensitive interrupts and therefore the is no need to use the EOI register to have the module re-strobe the interrupt line if there pending interrupts exist. Signed-off-by: Patil, Rachna --- drivers/input/touchscreen/ti_tscadc.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/input/touchscreen/ti_tscadc.c b/drivers/input/touchscreen/ti_tscadc.c index 2cc19b0..ec0a442 100644 --- a/drivers/input/touchscreen/ti_tscadc.c +++ b/drivers/input/touchscreen/ti_tscadc.c @@ -27,7 +27,6 @@ #include #include -#define REG_IRQEOI 0x020 #define REG_RAWIRQSTATUS 0x024 #define REG_IRQSTATUS 0x028 #define REG_IRQENABLE 0x02C @@ -330,8 +329,6 @@ static irqreturn_t tscadc_irq(int irq, void *dev) } tscadc_writel(ts_dev, REG_IRQSTATUS, irqclr); - /* check pending interrupts */ - tscadc_writel(ts_dev, REG_IRQEOI, 0x0); tscadc_writel(ts_dev, REG_SE, STPENB_STEPENB); return IRQ_HANDLED; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 5/8] input: TSC: ti_tscadc: Rename the existing touchscreen driver
Make way for addition of MFD driver.
The existing touchsreen driver is a MFD client.
For better readability we rename the file to
indicate its functionality as only touchscreen.
Signed-off-by: Patil, Rachna
---
Changes in v2:
Missed changing the name of touchscreen header file
in the previous version.
Adding the same.
Changes in v3:
no changes.
Changes in v4:
no changes.
drivers/input/touchscreen/Kconfig |4 +-
drivers/input/touchscreen/Makefile |2 +-
.../touchscreen/{ti_tscadc.c => ti_am335x_tsc.c} | 96 ++--
.../linux/input/{ti_tscadc.h => ti_am335x_tsc.h} |4 +-
4 files changed, 53 insertions(+), 53 deletions(-)
rename drivers/input/touchscreen/{ti_tscadc.c => ti_am335x_tsc.c} (83%)
rename include/linux/input/{ti_tscadc.h => ti_am335x_tsc.h} (88%)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 1ba232c..7bdb629 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -529,7 +529,7 @@ config TOUCHSCREEN_TOUCHWIN
To compile this driver as a module, choose M here: the
module will be called touchwin.
-config TOUCHSCREEN_TI_TSCADC
+config TOUCHSCREEN_TI_AM335X_TSC
tristate "TI Touchscreen Interface"
depends on ARCH_OMAP2PLUS
help
@@ -539,7 +539,7 @@ config TOUCHSCREEN_TI_TSCADC
If unsure, say N.
To compile this driver as a module, choose M here: the
- module will be called ti_tscadc.
+ module will be called ti_am335x_tsc.
config TOUCHSCREEN_ATMEL_TSADCC
tristate "Atmel Touchscreen Interface"
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 178eb12..7c4c78e 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -52,7 +52,7 @@ obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o
obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o
obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o
obj-$(CONFIG_TOUCHSCREEN_STMPE)+= stmpe-ts.o
-obj-$(CONFIG_TOUCHSCREEN_TI_TSCADC)+= ti_tscadc.o
+obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC)+= ti_am335x_tsc.o
obj-$(CONFIG_TOUCHSCREEN_TNETV107X)+= tnetv107x-ts.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
diff --git a/drivers/input/touchscreen/ti_tscadc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
similarity index 83%
rename from drivers/input/touchscreen/ti_tscadc.c
rename to drivers/input/touchscreen/ti_am335x_tsc.c
index ec0a442..462950a 100644
--- a/drivers/input/touchscreen/ti_tscadc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
#include
#define REG_RAWIRQSTATUS 0x024
@@ -123,7 +123,7 @@
#define ADC_CLK300
#define MAX_12BIT ((1 << 12) - 1)
-struct tscadc {
+struct titsc {
struct input_dev*input;
struct clk *tsc_ick;
void __iomem*tsc_base;
@@ -134,18 +134,18 @@ struct tscadc {
int steps_to_configure;
};
-static unsigned int tscadc_readl(struct tscadc *ts, unsigned int reg)
+static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
{
return readl(ts->tsc_base + reg);
}
-static void tscadc_writel(struct tscadc *tsc, unsigned int reg,
+static void titsc_writel(struct titsc *tsc, unsigned int reg,
unsigned int val)
{
writel(val, tsc->tsc_base + reg);
}
-static void tscadc_step_config(struct tscadc *ts_dev)
+static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
int i, total_steps;
@@ -170,8 +170,8 @@ static void tscadc_step_config(struct tscadc *ts_dev)
}
for (i = 1; i <= ts_dev->steps_to_configure; i++) {
- tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
- tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
config = 0;
@@ -192,8 +192,8 @@ static void tscadc_step_config(struct tscadc *ts_dev)
}
for (i = (ts_dev->steps_to_configure + 1); i <= total_steps; i++) {
- tscadc_writel(ts_dev, REG_STEPCONFIG(i), config);
- tscadc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
+ titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
+ titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
config = 0;
@@ -202,40 +202,40 @@ static void tscadc_step_config(struct tscadc *ts_dev)
STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR |
STEPCHARGE_INM_AN1 | S
[PATCH RESEND 7/8] input: TSC: ti_tsc: Convert TSC into a MFDevice
This patch converts touchscreen into a MFD client. All the register definitions, clock initialization, etc has been moved to MFD core driver. Signed-off-by: Patil, Rachna --- Changes in v2: No changes Changes in v3: No changes Changes in v4: No changes Changes in v5: No changes drivers/input/touchscreen/Kconfig |2 +- drivers/input/touchscreen/ti_am335x_tsc.c | 318 + drivers/mfd/ti_am335x_tscadc.c| 11 + include/linux/mfd/ti_am335x_tscadc.h | 10 +- 4 files changed, 118 insertions(+), 223 deletions(-) diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 7bdb629..89a0492 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -531,7 +531,7 @@ config TOUCHSCREEN_TOUCHWIN config TOUCHSCREEN_TI_AM335X_TSC tristate "TI Touchscreen Interface" - depends on ARCH_OMAP2PLUS + depends on MFD_TI_AM335X_TSCADC help Say Y here if you have 4/5/8 wire touchscreen controller to be connected to the ADC controller on your TI AM335x SoC. diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index 462950a..7a18a8a 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -27,106 +27,15 @@ #include #include -#define REG_RAWIRQSTATUS 0x024 -#define REG_IRQSTATUS 0x028 -#define REG_IRQENABLE 0x02C -#define REG_IRQWAKEUP 0x034 -#define REG_CTRL 0x040 -#define REG_ADCFSM 0x044 -#define REG_CLKDIV 0x04C -#define REG_SE 0x054 -#define REG_IDLECONFIG 0x058 -#define REG_CHARGECONFIG 0x05C -#define REG_CHARGEDELAY0x060 -#define REG_STEPCONFIG(n) (0x64 + ((n - 1) * 8)) -#define REG_STEPDELAY(n) (0x68 + ((n - 1) * 8)) -#define REG_FIFO0CNT 0xE4 -#define REG_FIFO0THR 0xE8 -#define REG_FIFO1THR 0xF4 -#define REG_FIFO0 0x100 -#define REG_FIFO1 0x200 - -/* Register Bitfields */ -#define IRQWKUP_ENBBIT(0) - -/* Step Enable */ -#define STEPENB_MASK (0x1 << 0) -#define STEPENB(val) (val << 0) -#define STPENB_STEPENB STEPENB(0x7FFF) - -/* IRQ enable */ -#define IRQENB_FIFO0THRES BIT(2) -#define IRQENB_FIFO1THRES BIT(5) -#define IRQENB_PENUP BIT(9) - -/* Step Configuration */ -#define STEPCONFIG_MODE_MASK (3 << 0) -#define STEPCONFIG_MODE(val) (val << 0) -#define STEPCONFIG_MODE_HWSYNC STEPCONFIG_MODE(2) -#define STEPCONFIG_AVG_MASK(7 << 2) -#define STEPCONFIG_AVG(val)(val << 2) -#define STEPCONFIG_AVG_16 STEPCONFIG_AVG(4) -#define STEPCONFIG_XPP BIT(5) -#define STEPCONFIG_XNN BIT(6) -#define STEPCONFIG_YPP BIT(7) -#define STEPCONFIG_YNN BIT(8) -#define STEPCONFIG_XNP BIT(9) -#define STEPCONFIG_YPN BIT(10) -#define STEPCONFIG_INM_MASK(0xF << 15) -#define STEPCONFIG_INM(val)(val << 15) -#define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8) -#define STEPCONFIG_INP_MASK(0xF << 19) -#define STEPCONFIG_INP(val)(val << 19) -#define STEPCONFIG_INP_AN2 STEPCONFIG_INP(2) -#define STEPCONFIG_INP_AN3 STEPCONFIG_INP(3) -#define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4) -#define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8) -#define STEPCONFIG_FIFO1 BIT(26) - -/* Delay register */ -#define STEPDELAY_OPEN_MASK(0x3 << 0) -#define STEPDELAY_OPEN(val)(val << 0) -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098) - -/* Charge Config */ -#define STEPCHARGE_RFP_MASK(7 << 12) -#define STEPCHARGE_RFP(val)(val << 12) -#define STEPCHARGE_RFP_XPULSTEPCHARGE_RFP(1) -#define STEPCHARGE_INM_MASK(0xF << 15) -#define STEPCHARGE_INM(val)(val << 15) -#define STEPCHARGE_INM_AN1 STEPCHARGE_INM(1) -#define STEPCHARGE_INP_MASK(0xF << 19) -#define STEPCHARGE_INP(val)(val << 19) -#define STEPCHARGE_INP_AN1 STEPCHARGE_INP(1) -#define STEPCHARGE_RFM_MASK(3 << 23) -#define STEPCHARGE_RFM(val)(val << 23) -#define STEPCHARGE_RFM_XNURSTEPCHARGE_RFM(1) - -/* Charge delay */ -#define CHARGEDLY_OPEN_MASK(0x3 << 0) -#define CHARGEDLY_OPEN(val)(val << 0) -#define CHARGEDLY_OPENDLY CHARGEDLY_OPEN(1) - -/* Control register */ -#define CNTRLREG_TSCSSENB BIT(0) -#define CNTRLREG_STEPIDBIT(1) -#define CNTRLREG_STEPCONFIGWRT BIT(2) -#define CNTRLREG_AFE_CTRL_MASK (3 << 5) -#define CNTRLREG_AFE_CTRL(val) (val << 5) -#define CNTRLREG_4WIRE CNTRLREG_AFE_CTRL(1) -#define CNTRLREG_5WIRE CNTRLREG_AFE_CTRL(2) -#define CNTRLREG_8WIRE CNTRLREG_AFE_CTRL(3) -#define CNTRLREG_TSCENBBIT(7) +#include #define ADCFSM_STEPID 0x10 #define SEQ_SETTLE 275 -#define ADC_CLK300 #
[PATCH RESEND 6/8] MFD: ti_tscadc: Add support for TI's TSC/ADC MFDevice
Add the mfd core driver which supports touchscreen
and ADC.
With this patch we are only adding infrastructure to
support the MFD clients.
Signed-off-by: Patil, Rachna
---
Changes in v2:
Merged "[PATCH 5/5] MFD: ti_tscadc: Add check on number of i/p
channels",
patch submitted in previous version into this file.
Changes in v3:
No changes
Changes in v4:
No changes
Changes in v5:
Make use of devm_xxx and regmap MMIO API's.
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile |1 +
drivers/mfd/ti_am335x_tscadc.c | 250 ++
include/linux/mfd/ti_am335x_tscadc.h | 137 +++
4 files changed, 399 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/ti_am335x_tscadc.c
create mode 100644 include/linux/mfd/ti_am335x_tscadc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index acab3ef..9bba7f7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -94,6 +94,17 @@ config MFD_TI_SSP
To compile this driver as a module, choose M here: the
module will be called ti-ssp.
+config MFD_TI_AM335X_TSCADC
+ tristate "TI ADC / Touch Screen chip support"
+ select MFD_CORE
+ select REGMAP
+ select REGMAP_MMIO
+ help
+ If you say yes here you get support for Texas Instruments series
+ of Touch Screen /ADC chips.
+ To compile this driver as a module, choose M here: the
+ module will be called ti_am335x_tscadc.
+
config HTC_EGPIO
bool "HTC EGPIO support"
depends on GENERIC_HARDIRQS && GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d8ccb63..442c17e 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_HTC_I2CPLD) += htc-i2cpld.o
obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
obj-$(CONFIG_MFD_TI_SSP) += ti-ssp.o
+obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
obj-$(CONFIG_MFD_STA2X11) += sta2x11-mfd.o
obj-$(CONFIG_MFD_STMPE)+= stmpe.o
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
new file mode 100644
index 000..14df67b
--- /dev/null
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -0,0 +1,250 @@
+/*
+ * TI Touch Screen / ADC MFD driver
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int reg)
+{
+ unsigned int val;
+
+ regmap_read(tsadc->regmap_tscadc, reg, &val);
+ return val;
+}
+
+static void tscadc_writel(struct ti_tscadc_dev *tsadc, unsigned int reg,
+ unsigned int val)
+{
+ regmap_write(tsadc->regmap_tscadc, reg, val);
+}
+
+static const struct regmap_config tscadc_regmap_config = {
+ .name = "ti_tscadc",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+};
+
+static void tscadc_idle_config(struct ti_tscadc_dev *config)
+{
+ unsigned int idleconfig;
+
+ idleconfig = STEPCONFIG_YNN | STEPCONFIG_INM_ADCREFM |
+ STEPCONFIG_INP_ADCREFM | STEPCONFIG_YPN;
+
+ tscadc_writel(config, REG_IDLECONFIG, idleconfig);
+}
+
+static int __devinit ti_tscadc_probe(struct platform_device *pdev)
+{
+ struct ti_tscadc_dev*tscadc;
+ struct resource *res;
+ struct clk *clk;
+ struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
+ int irq;
+ int err, ctrl;
+ int clk_value, clock_rate;
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "Could not find platform data\n");
+ return -EINVAL;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "no memory resource defined.\n");
+ return -EINVAL;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "no irq ID is specified.\n");
+ return -EINVAL;
+ }
+
+ /* Allocate memory for device */
+ tscadc = devm_kzalloc(&pdev->dev,
+ sizeof(struct ti_tscadc_dev), GFP_KERNEL);
+ if (!tscadc) {
+
Re: [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
On Tue, Oct 16, 2012 at 08:29:56AM +0100, Lee Jones wrote: > On Tue, 16 Oct 2012, Mark Brown wrote: > > Not looked at the patch yet but patch 2 doesn't seem to have appeared? > Has it arrived yet? > Arnd responded to it, so it hit the list. > Since Arnd's comments I've also fired v2 up - do you see it/them? Not in my inbox, I'm not looking at the list right now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] block: Add blk_rq_pos(rq) to sort rq when plushing plug-list.
2012/10/16 Jianpeng Ma : > On 2012-10-15 21:18 Shaohua Li Wrote: >>2012/10/15 Shaohua Li : >>> 2012/10/15 Jianpeng Ma : My workload is a raid5 which had 16 disks. And used our filesystem to write using direct-io mode. I used the blktrace to find those message: 8,16 0 3570 1.083923979 2519 I W 144323176 + 24 [md127_raid5] 8,16 00 1.083926214 0 m N cfq2519 insert_request 8,16 0 3571 1.083926586 2519 I W 144323072 + 104 [md127_raid5] 8,16 00 1.083926952 0 m N cfq2519 insert_request 8,16 0 3572 1.083927180 2519 U N [md127_raid5] 2 8,16 00 1.083927870 0 m N cfq2519 Not idling.st->count:1 8,16 00 1.083928320 0 m N cfq2519 dispatch_insert 8,16 00 1.083928951 0 m N cfq2519 dispatched a request 8,16 00 1.083929443 0 m N cfq2519 activate rq,drv=1 8,16 0 3573 1.083929530 2519 D W 144323176 + 24 [md127_raid5] 8,16 00 1.083933883 0 m N cfq2519 Not idling.st->count:1 8,16 00 1.083934189 0 m N cfq2519 dispatch_insert 8,16 00 1.083934654 0 m N cfq2519 dispatched a request 8,16 00 1.083935014 0 m N cfq2519 activate rq,drv=2 8,16 0 3574 1.083935101 2519 D W 144323072 + 104 [md127_raid5] 8,16 0 3575 1.084196179 0 C W 144323176 + 24 [0] 8,16 00 1.084197979 0 m N cfq2519 complete rqnoidle 0 8,16 0 3576 1.084769073 0 C W 144323072 + 104 [0] .. 8,16 1 3596 1.091394357 2519 I W 144322544 + 16 [md127_raid5] 8,16 10 1.091396181 0 m N cfq2519 insert_request 8,16 1 3597 1.091396571 2519 I W 144322520 + 24 [md127_raid5] 8,16 10 1.091396934 0 m N cfq2519 insert_request 8,16 1 3598 1.091397165 2519 I W 144322488 + 32 [md127_raid5] 8,16 10 1.091397477 0 m N cfq2519 insert_request 8,16 1 3599 1.091397708 2519 I W 144322432 + 56 [md127_raid5] 8,16 10 1.091398023 0 m N cfq2519 insert_request 8,16 1 3600 1.091398284 2519 U N [md127_raid5] 4 8,16 10 1.091398986 0 m N cfq2519 Not idling. st->count:1 8,16 10 1.091399511 0 m N cfq2519 dispatch_insert 8,16 10 1.091400217 0 m N cfq2519 dispatched a request 8,16 10 1.091400688 0 m N cfq2519 activate rq,drv=1 8,16 1 3601 1.091400766 2519 D W 144322544 + 16 [md127_raid5] 8,16 10 1.091406151 0 m N cfq2519 Not idling.st->count:1 8,16 10 1.091406460 0 m N cfq2519 dispatch_insert 8,16 10 1.091406931 0 m N cfq2519 dispatched a request 8,16 10 1.091407291 0 m N cfq2519 activate rq,drv=2 8,16 1 3602 1.091407378 2519 D W 144322520 + 24 [md127_raid5] 8,16 10 1.091414006 0 m N cfq2519 Not idling.st->count:1 8,16 10 1.091414297 0 m N cfq2519 dispatch_insert 8,16 10 1.091414702 0 m N cfq2519 dispatched a request 8,16 10 1.091415047 0 m N cfq2519 activate rq, drv=3 8,16 1 3603 1.091415125 2519 D W 144322488 + 32 [md127_raid5] 8,16 10 1.091416469 0 m N cfq2519 Not idling.st->count:1 8,16 10 1.091416754 0 m N cfq2519 dispatch_insert 8,16 10 1.091417186 0 m N cfq2519 dispatched a request 8,16 10 1.091417535 0 m N cfq2519 activate rq,drv=4 8,16 1 3604 1.091417628 2519 D W 144322432 + 56 [md127_raid5] 8,16 1 3605 1.091857225 4393 C W 144322544 + 16 [0] 8,16 10 1.091858753 0 m N cfq2519 complete rqnoidle 0 8,16 1 3606 1.092068456 4393 C W 144322520 + 24 [0] 8,16 10 1.092069851 0 m N cfq2519 complete rqnoidle 0 8,16 1 3607 1.092350440 4393 C W 144322488 + 32 [0] 8,16 10 1.092351688 0 m N cfq2519 complete rqnoidle 0 8,16 1 3608 1.093629323 0 C W 144322432 + 56 [0] 8,16 10 1.093631151 0 m N cfq2519 complete rqnoidle 0 8,16 10 1.093631574 0 m N cfq2519 will busy wait 8,16 10 1.093631829 0 m N cfq schedule dispatch Because in func "elv_attempt_insert_merge", it only to try to backmerge.So the four request can't merge in theory. I trace ten minutes and count those situation, it can count 25%.
Re: [PATCH v2] mmc: core: Add support for idle time BKOPS
Hi Maya,
I'm testing with your patch..but i need to have the more time for testing.
In now, it looks good to me. Thank you for working the idle bkops.
Best Regards,
Jaehoon Chung
> ---
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 172a768..ed040d5 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -827,6 +827,9 @@ static int mmc_blk_issue_discard_rq(struct mmc_queue *mq,
> struct request *req)
> from = blk_rq_pos(req);
> nr = blk_rq_sectors(req);
>
> + if (card->ext_csd.bkops_en)
> + card->bkops_info.sectors_changed += blk_rq_sectors(req);
using nr?
> +
> if (mmc_can_discard(card))
> arg = MMC_DISCARD_ARG;
> else if (mmc_can_trim(card))
> @@ -1268,6 +1271,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
> struct request *rqc)
> if (!rqc && !mq->mqrq_prev->req)
> return 0;
>
> + if (rqc && (card->ext_csd.bkops_en) && (rq_data_dir(rqc) == WRITE))
> + card->bkops_info.sectors_changed += blk_rq_sectors(rqc);
Fix the indent.
> +
> do {
> if (rqc) {
> /*
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index e360a97..e96f5cf 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -51,6 +51,7 @@ static int mmc_queue_thread(void *d)
> {
> struct mmc_queue *mq = d;
> struct request_queue *q = mq->queue;
> + struct mmc_card *card = mq->card;
>
> current->flags |= PF_MEMALLOC;
>
> @@ -66,6 +67,17 @@ static int mmc_queue_thread(void *d)
> spin_unlock_irq(q->queue_lock);
>
> if (req || mq->mqrq_prev->req) {
> + /*
> + * If this is the first request, BKOPs might be in
> + * progress and needs to be stopped before issuing the
> + * request
> + */
> + if (card->ext_csd.bkops_en &&
> + card->bkops_info.started_delayed_bkops) {
> + card->bkops_info.started_delayed_bkops = false;
> + mmc_stop_bkops(card);
if mmc_stop_bkops is failed..?
> + }
> +
> set_current_state(TASK_RUNNING);
> mq->issue_fn(mq, req);
> } else {
> @@ -73,6 +85,7 @@ static int mmc_queue_thread(void *d)
> set_current_state(TASK_RUNNING);
> break;
> }
> + mmc_start_delayed_bkops(card);
> up(&mq->thread_sem);
> schedule();
> down(&mq->thread_sem);
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 6612163..fd8783d 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -253,9 +253,42 @@ mmc_start_request(struct mmc_host *host, struct
> mmc_request *mrq)
> }
>
> /**
> + * mmc_start_delayed_bkops() - Start a delayed work to check for
> + * the need of non urgent BKOPS
> + *
> + * @card: MMC card to start BKOPS on
> + */
> +void mmc_start_delayed_bkops(struct mmc_card *card)
> +{
> + if (!card || !card->ext_csd.bkops_en || mmc_card_doing_bkops(card))
> + return;
> +
> + if (card->bkops_info.sectors_changed <
> + BKOPS_MIN_SECTORS_TO_QUEUE_DELAYED_WORK)
> + return;
> +
> + pr_debug("%s: %s: queueing delayed_bkops_work\n",
> + mmc_hostname(card->host), __func__);
> +
> + card->bkops_info.sectors_changed = 0;
> +
> + /*
> + * cancel_delayed_bkops_work will prevent a race condition between
> + * fetching a request by the mmcqd and the delayed work, in case
> + * it was removed from the queue work but not started yet
> + */
> + card->bkops_info.cancel_delayed_work = false;
> + card->bkops_info.started_delayed_bkops = true;
> + queue_delayed_work(system_nrt_wq, &card->bkops_info.dw,
> +msecs_to_jiffies(
> +card->bkops_info.delay_ms));
> +}
> +EXPORT_SYMBOL(mmc_start_delayed_bkops);
> +
> +/**
> * mmc_start_bkops - start BKOPS for supported cards
> * @card: MMC card to start BKOPS
> - * @form_exception: A flag to indicate if this function was
> + * @from_exception: A flag to indicate if this function was
> *called due to an exception raised by the card
> *
> * Start background operations whenever requested.
> @@ -269,25 +302,47 @@ void mmc_start_bkops(struct mmc_card *card, bool
> from_exception)
> bool use_busy_signal;
>
> BUG_ON(!card);
> -
> - if (!card->ext_csd.bkops_en || mmc_card_doing_bkops(card))
> + if (!card->ext_csd.bkops_en)
> return;
>
> + mmc_claim_host(card->host);
> +
> + if ((card->bkops_info.cancel_delayed_work) && !
Re: [RFC PATCH] posix timers: allocate timer id per task
15.10.2012 20:34, Eric Dumazet пишет: On Mon, 2012-10-15 at 20:17 +0400, Stanislav Kinsbursky wrote: This patch is required CRIU project (www.criu.org). To migrate processes with posix timers we have to make sure, that we can restore posix timer with proper id. Currently, this is not true, because timer ids are allocated globally. So, this is precursor patch and it's purpose is make posix timer id to be allocated per task. Patch replaces global idr with global hash table for posix timers and makes timer ids unique not globally, but per task. Next free timer id is type of integer and stored on signal struct (posix_timer_id). If free timer id reaches negative value on timer creation, it will be dropped to zero and -EAGAIN will be returned to user. Hash table is size of page (4KB). Key is constructed as follows: key = hash_ptr(current->signal) ^ hash_32(posix_timer_id); Signed-off-by: Stanislav Kinsbursky Hmm, it seems you removed idr, rcu friendly, and reinstated a fixed size hash table, protected by a _single_ spinlock ? Oh well. Please take a look at commit 8af088710d1e, and make sure you fix your problem and keep performance as good as before. Thanks, Eric. I'll update. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Very bad performance on Qemu/KVM
Good morning LKML, I see extremely slow virtual machines running on qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64 on Centos 6.3 with Linux 2.6.32-279.5.2.el6.x86_64 on a 64 core machine using AMD Opteron(TM) Processor 6276 (dell r815). The guests are Centos 6.3, Linux 2.6.32-220.13.1.el6.x86_64. The disk images reside on local storage, ext4 filesystem. I checked that kvm is loaded and enabled. I changed -drive to use if=virtio, -net to use model=virtio. >From the processes running it seems that cpu performance is the bottleneck. I added -cpu host to skip the emulation, but this did not fix the issue. Comparing the performance to qemu running on a xenserver, performance is at most half of it. Does anyone of you have a good pointer how to debug this further or are there any known issues with the given setup? I'm happy for every pointer I get, as there seems to be no easy to spot issue. Cheers, Nico -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 1/2] perf, cpu hotplug: Run CPU_STARTING notifiers with irqs disabled
The CPU_STARTING notifiers are supposed to be run with irqs disabled. But the
perf_cpu_notifier() macro invokes them without doing that. Fix it.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/perf_event.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 2e90235..0647805 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -803,10 +803,13 @@ static inline void perf_event_task_tick(void)
{ }
do { \
static struct notifier_block fn##_nb __cpuinitdata =\
{ .notifier_call = fn, .priority = CPU_PRI_PERF }; \
+ unsigned long flags;\
fn(&fn##_nb, (unsigned long)CPU_UP_PREPARE, \
(void *)(unsigned long)smp_processor_id()); \
+ local_irq_save(flags); \
fn(&fn##_nb, (unsigned long)CPU_STARTING, \
(void *)(unsigned long)smp_processor_id()); \
+ local_irq_restore(flags); \
fn(&fn##_nb, (unsigned long)CPU_ONLINE, \
(void *)(unsigned long)smp_processor_id()); \
register_cpu_notifier(&fn##_nb);\
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 2/2] perf, cpu hotplug: Use cached value of smp_processor_id()
The perf_cpu_notifier() macro invokes smp_processor_id() multiple
times. Optimize it by using a local variable.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/perf_event.h |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 0647805..6bfb2faa 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -803,15 +803,16 @@ static inline void perf_event_task_tick(void)
{ }
do { \
static struct notifier_block fn##_nb __cpuinitdata =\
{ .notifier_call = fn, .priority = CPU_PRI_PERF }; \
+ unsigned long cpu = smp_processor_id(); \
unsigned long flags;\
fn(&fn##_nb, (unsigned long)CPU_UP_PREPARE, \
- (void *)(unsigned long)smp_processor_id()); \
+ (void *)(unsigned long)cpu);\
local_irq_save(flags); \
fn(&fn##_nb, (unsigned long)CPU_STARTING, \
- (void *)(unsigned long)smp_processor_id()); \
+ (void *)(unsigned long)cpu);\
local_irq_restore(flags); \
fn(&fn##_nb, (unsigned long)CPU_ONLINE, \
- (void *)(unsigned long)smp_processor_id()); \
+ (void *)(unsigned long)cpu);\
register_cpu_notifier(&fn##_nb);\
} while (0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.32.xx build breaks with gcc 4.7
lo lo, I'm trying to compile 2.6.32.60 with gcc 4.7.2, and getting the following error: CC arch/x86/kernel/ptrace.o arch/x86/kernel/ptrace.c:1472:17: error: conflicting types for 'syscall_trace_enter' In file included from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/vm86.h:130:0, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/processor.h:10, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/thread_info.h:22, from include/linux/thread_info.h:56, from include/linux/preempt.h:9, from include/linux/spinlock.h:50, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/timex.h:56, from include/linux/sched.h:56, from arch/x86/kernel/ptrace.c:11: /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/ptrace.h:145:13: note: previous declaration of 'syscall_trace_enter' was here arch/x86/kernel/ptrace.c:1517:17: error: conflicting types for 'syscall_trace_leave' In file included from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/vm86.h:130:0, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/processor.h:10, from /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/thread_info.h:22, from include/linux/thread_info.h:56, from include/linux/preempt.h:9, from include/linux/spinlock.h:50, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/timex.h:56, from include/linux/sched.h:56, from arch/x86/kernel/ptrace.c:11: /usr/src/linux-2.6.32.60-gzpLinux/arch/x86/include/asm/ptrace.h:146:13: note: previous declaration of 'syscall_trace_leave' was here make[2]: *** [arch/x86/kernel/ptrace.o] Error 1 make[1]: *** [arch/x86/kernel] Error 2 make: *** [arch/x86] Error 2 My environment looks like: Linux 3.2.30, glibc 2.16, gcc 4.7.2 If I comment out the ancient line, kernel compiles fine. Willy says: | The affected entry is only used there : | arch/x86/include/asm/ptrace.h:extern void syscall_trace_leave(struct pt_regs *); | arch/x86/include/asm/thread_info.h:/* work to do in syscall_trace_leave() */ | arch/x86/kernel/entry_32.S: ENABLE_INTERRUPTS(CLBR_ANY) # could let syscall_trace_leave() call | arch/x86/kernel/entry_32.S: call syscall_trace_leave | arch/x86/kernel/entry_64.S: call syscall_trace_leave | arch/x86/kernel/ptrace.c:asmregparm void syscall_trace_leave(struct pt_regs *regs) | So if the two calls above don't need the include then maybe we can | safely remove it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] posix timers: allocate timer id per task
15.10.2012 21:04, Peter Zijlstra пишет: On Mon, 2012-10-15 at 20:17 +0400, Stanislav Kinsbursky wrote: This patch is required CRIU project (www.criu.org). To migrate processes with posix timers we have to make sure, that we can restore posix timer with proper id. Currently, this is not true, because timer ids are allocated globally. So, this is precursor patch and it's purpose is make posix timer id to be allocated per task. Patch replaces global idr with global hash table for posix timers and makes timer ids unique not globally, but per task. Next free timer id is type of integer and stored on signal struct (posix_timer_id). If free timer id reaches negative value on timer creation, it will be dropped to zero and -EAGAIN will be returned to user. Hash table is size of page (4KB). Key is constructed as follows: key = hash_ptr(current->signal) ^ hash_32(posix_timer_id); but but but.. isn't this what namespaces were invented for to solve? Why not use the regular namespace infrastructure? The reason is that CRIU have to support single processes within existent namespaces. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/14] memcg: kmem controller infrastructure
(2012/10/12 18:13), Glauber Costa wrote:
On 10/12/2012 12:57 PM, Michal Hocko wrote:
On Fri 12-10-12 12:44:57, Glauber Costa wrote:
On 10/12/2012 12:39 PM, Michal Hocko wrote:
On Fri 12-10-12 11:45:46, Glauber Costa wrote:
On 10/11/2012 04:42 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:12, Glauber Costa wrote:
[...]
+ /*
+* Conditions under which we can wait for the oom_killer.
+* __GFP_NORETRY should be masked by __mem_cgroup_try_charge,
+* but there is no harm in being explicit here
+*/
+ may_oom = (gfp & __GFP_WAIT) && !(gfp & __GFP_NORETRY);
Well we _have to_ check __GFP_NORETRY here because if we don't then we
can end up in OOM. mem_cgroup_do_charge returns CHARGE_NOMEM for
__GFP_NORETRY (without doing any reclaim) and of oom==true we decrement
oom retries counter and eventually hit OOM killer. So the comment is
misleading.
I will update. What i understood from your last message is that we don't
really need to, because try_charge will do it.
IIRC I just said it couldn't happen before because migration doesn't go
through charge and thp disable oom by default.
I had it changed to:
/*
* Conditions under which we can wait for the oom_killer.
* We have to be able to wait, but also, if we can't retry,
* we obviously shouldn't go mess with oom.
*/
may_oom = (gfp & __GFP_WAIT) && !(gfp & __GFP_NORETRY);
OK
+
+ _memcg = memcg;
+ ret = __mem_cgroup_try_charge(NULL, gfp, size >> PAGE_SHIFT,
+ &_memcg, may_oom);
+
+ if (!ret) {
+ ret = res_counter_charge(&memcg->kmem, size, &fail_res);
Now that I'm thinking about the charging ordering we should charge the
kmem first because we would like to hit kmem limit before we hit u+k
limit, don't we.
Say that you have kmem limit 10M and the total limit 50M. Current `u'
would be 40M and this charge would cause kmem to hit the `k' limit. I
think we should fail to charge kmem before we go to u+k and potentially
reclaim/oom.
Or has this been alredy discussed and I just do not remember?
This has never been discussed as far as I remember. We charged u first
since day0, and you are so far the first one to raise it...
One of the things in favor of charging 'u' first is that
mem_cgroup_try_charge is already equipped to make a lot of decisions,
like when to allow reclaim, when to bypass charges, and it would be good
if we can reuse all that.
Hmm, I think that we should prevent from those decisions if kmem charge
would fail anyway (especially now when we do not have targeted slab
reclaim).
Let's revisit this discussion when we do have targeted reclaim. For now,
I'll agree that charging kmem first would be acceptable.
This will only make a difference when K < U anyway.
Yes and it should work as advertised (aka hit the k limit first).
Just so we don't ping-pong in another submission:
I changed memcontrol.h's memcg_kmem_newpage_charge to include:
/* If the test is dying, just let it go. */
if (unlikely(test_thread_flag(TIF_MEMDIE)
|| fatal_signal_pending(current)))
return true;
I'm also attaching the proposed code in memcontrol.c
+static int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp, u64 size)
+{
+ struct res_counter *fail_res;
+ struct mem_cgroup *_memcg;
+ int ret = 0;
+ bool may_oom;
+
+ ret = res_counter_charge(&memcg->kmem, size, &fail_res);
+ if (ret)
+ return ret;
+
+ /*
+* Conditions under which we can wait for the oom_killer.
+* We have to be able to wait, but also, if we can't retry,
+* we obviously shouldn't go mess with oom.
+*/
+ may_oom = (gfp & __GFP_WAIT) && !(gfp & __GFP_NORETRY);
+
+ _memcg = memcg;
+ ret = __mem_cgroup_try_charge(NULL, gfp, size >> PAGE_SHIFT,
+ &_memcg, may_oom);
+
+ if (ret == -EINTR) {
+ /*
+* __mem_cgroup_try_charge() chosed to bypass to root due to
+* OOM kill or fatal signal. Since our only options are to
+* either fail the allocation or charge it to this cgroup, do
+* it as a temporary condition. But we can't fail. From a
+* kmem/slab perspective, the cache has already been selected,
+* by mem_cgroup_get_kmem_cache(), so it is too late to change
+* our minds. This condition will only trigger if the task
+* entered memcg_charge_kmem in a sane state, but was
+* OOM-killed. during __mem_cgroup_try_charge. Tasks that are
+* already dying when the allocation triggers should have been
+* already directed to the root cgroup.
+*/
+ res_counter_charge_nofail(&memcg->res, size, &fail_res);
+ if (d
Re: [PATCH 1/2] regulator: gpio-regulator: Allow use of GPIO controlled regulators though DT
On Tue, 16 Oct 2012, Mark Brown wrote: > On Tue, Oct 16, 2012 at 08:29:56AM +0100, Lee Jones wrote: > > On Tue, 16 Oct 2012, Mark Brown wrote: > > > > Not looked at the patch yet but patch 2 doesn't seem to have appeared? > > > Has it arrived yet? > > > Arnd responded to it, so it hit the list. > > > Since Arnd's comments I've also fired v2 up - do you see it/them? > > Not in my inbox, I'm not looking at the list right now. Strange, both emails had you in CC. I'm assuming it's just the documentation patch you're missing. Let me resend it as a single patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Documentation: Describe Device Tree bindings for GPIO Regulator driver
Here we specify all non-standard bindings which can be used when
requesting the use of an GPIO controlled regulator from Device Tree.
Cc: Mark Brown
Signed-off-by: Lee Jones
---
.../bindings/regulator/gpio-regulator.txt | 36
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/gpio-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
new file mode 100644
index 000..3703be2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -0,0 +1,36 @@
+GPIO controlled regulators
+
+Required properties:
+- compatible : Must be "regulator-gpio".
+
+Optional properties:
+- gpio-enable : GPIO to use to enable/disable the regulator.
+- gpios: GPIO group used to control voltage.
+- states : Selection of available voltages and GPIO configs.
+- startup-delay-us : Startup time in microseconds.
+- enable-active-high : Polarity of GPIO is active high (default is low).
+
+Any property defined as part of the core regulator binding defined in
+regulator.txt can also be used.
+
+Example:
+
+ mmciv: gpio-regulator {
+ compatible = "regulator-gpio";
+
+ regulator-name = "mmci-gpio-supply";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <260>;
+ regulator-boot-on;
+
+ gpio-enable = <&gpio0 23 0x4>;
+ gpios = <&gpio0 24 0x4
+&gpio0 25 0x4>;
+ states = <180 0x3
+ 220 0x2
+ 260 0x1
+ 290 0x0>;
+
+ startup-delay-us = <10>;
+ enable-active-high;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
Hi Greg, On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote: > Hi Philippe, > > On 09/10/12 19:07, Philippe De Muyter wrote: >> [CCing lkml, linux-ppc, netdev, linux-m68k] >> >> Hello kernel sources architects >> >> I have a working driver for the m54xx FEC ethernet driver that I >> would like to integrate in the kernel tree. Problems are that >> - this driver needs an associated DMA driver (provided by FreeScale) >> wich is not dma-engine enabled >> - they're are already many fec drivers in the kernel tree, and >> at least one, fec_mpc52xx.c, seems to be very similar (information >> below), to the one for the mcf54xx, except it uses a differently >> named associated DMA driver (BestComm/SmartDma/SDMA) which is also >> not dma-engine enabled, and even kept hidden in /arch/powerpc where >> it is inaccessible when compiling for m68k. The underlying DMA part >> from Freescale however seems similar to the one used in the >> m54xx. (again, see information below) >> >> So, now I am lost, what should I do ? >> >> The current state of my patches >> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] >> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, >> without adding the dma-engine compatibility layer, and adding the specific >> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale > > Do you get any responses? > I didn't see any... No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm to drivers/dma/bestcomm (except a private and useful one telling me how to set '-M' option as default for 'git format-patch'), but at least this simpler patch seems to be in a wait bucket at http://patchwork.ozlabs.org/project/linuxppc-dev/list/. Regards Philippe PS: -M as default for 'git format-patch': put [diff] renames = true in .git/config > > Regards > Greg > > > >> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: >>> Hi Philippe, >>> >>> On 05/10/12 01:03, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: > On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: >> >> My biggest concern is the amount of MCD/DMA support code. And it is >> all done quite differently to everything else in the kernel. We may >> get a bit of push back from kernel folk who look after DMA. > > Actually, there is already a similar code in > arch/powerpc/sysdev/bestcomm > (also from freescale, maybe an identical part, but I did not find any > usable doc), but the powerpc folks kept that hidden in the arch/powerpc > tree, instead of installing it in drivers/dma. The MCD DMA or DMA FEC code from freescale has a comment implying that this was first used in the MPC8220 part. And Montavista has a MPC8220 port, but I did not find it, so I do not know where they installed the MCD DMA driver. >>> >>> Ok, looks like there is a bit a variance in all this. >> >> I also began to read the mpc5200 user's guide parts about the fec and >> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) >> and they look very similar, but not identical, to their m54xx >> counterparts. >> >> It seems possible to make the fec_mpc52xx.c driver work for the m54xx >> but that needs at least: >> - moving some files or part of them from /arch/powerpc/sysdev and >>/arch/powerpc/include/asm to /drivers/dma and /include/linux, >> - renaming the fec_mpc52xx files to a more sensible name, >> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, >> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA >>in mcf_52xx.c. >> >> An additional problem is that the freescale docs for powerpcs and for >> coldfires do not use the same mnemonics for the same registers. >> >> e.g. FEC registers >> offset MPC5200 MCF5484 >> == === === >> 000 FEC_ID n/a >> 004 IEVENT EIR >> 008 IMASK EIMR >> 010 R_DES_ACTIVEn/a >> 014 X_DES_ACTIVEn/a >> 024 ECNTRL ECR >> 040 MII_DATAMDATA >> 044 MII_SPEED MSCR >> 064 MIB_CONTROL MIBC >> 084 R_CNTRL RCR >> 088 R_HASH RHR >> 0C4 X_CNTRL TCR >> 0E4 PADDR1 PALR >> 0E8 PADDR2 PAHR >> 0EC OP_PAUSEOPD >> 118 IADDR1 IAUR >> 11C IADDR1 IALR >> 120 GADDR1 GAUR >> 124 GADDR2 GALR >> 144 X_WMRK FECTFWR >> 184 RFIFO_DATA FECRFDR >> 188 RFIFO_STATUSFECRFSR >> 18C RFIFO_CONTROL FECRFCR >> 190 RFIFO_LRF_PTR FECRLRFP >> 194 RFIFO_LWF_PTR FECRLWFP >> 198 RFIFO_ALARM FECRFAR >> 19C RFIFO_RDPTR FECRFRP >> 1A0
Re: [RFC PATCH] posix timers: allocate timer id per task
15.10.2012 23:08, Thomas Gleixner пишет:
On Mon, 15 Oct 2012, Stanislav Kinsbursky wrote:
This patch is required CRIU project (www.criu.org).
To migrate processes with posix timers we have to make sure, that we can
restore posix timer with proper id.
Currently, this is not true, because timer ids are allocated globally.
So, this is precursor patch and it's purpose is make posix timer id to be
allocated per task.
You can't allocate them per task. posix timers are process wide.
This is probably a misunderstanding.
I meant process process.
What's the reason why you did not make the posix timer ids per name
space instead of going down to the per process level ?
The reason is that CRIU have to support single processes regardless to
namespaces.
Patch replaces global idr with global hash table for posix timers and
makes timer ids unique not globally, but per task. Next free timer id is type
of integer and stored on signal struct (posix_timer_id). If free timer id
reaches negative value on timer creation, it will be dropped to zero and
-EAGAIN will be returned to user.
So you want to allow 2^31 posix timers created for a single process?
I don't really want it.
I just tried to preserve existent logic. I.e. currently one process can create
2^31 posix timers (if no other processes tried to do the same).
But the amount can be decreased, of course.
+static struct k_itimer *__posix_timers_find(struct hlist_head *head, struct
signal_struct *sig, timer_t id)
+{
+ struct hlist_node *node;
+ struct k_itimer *timer;
+
+ hlist_for_each_entry(timer, node, head, t_hash) {
+ if ((timer->it_signal == sig) && (timer->it_id == id))
+ return timer;
+ }
+ return NULL;
+}
+
+static struct k_itimer *posix_timer_find(timer_t id, unsigned long *flags)
+{
+ struct k_itimer *timer;
+ struct signal_struct *sig = current->signal;
+ struct hlist_head *head = &posix_timers_hashtable[hash(sig, id)];
+
+ spin_lock_irqsave(&hash_lock, *flags);
This is not going to fly. You just reintroduced a massive scalability
problem. See commit 8af08871
Yep, Eric already pointed to it.
I'll try to fix this problem, if the idea with hash table suits in general.
Thanks.
Thanks,
tglx
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf probe: convert_name_to_addr() allocated the wrong size buffer for a function name
Hi,
2012/10/16 Masami Hiramatsu :
> (2012/10/16 10:37), Hyeoncheol Lee wrote:
>> convert_name_to_addr() allocated sizeof(char *) * MAX_PROBE_ARGS
>> bytes for a function name
>
> Yeah, that one was from my laziness...
>
>>
>> Cc: Masami Hiramatsu
>> Cc: Srikar Dronamraju
>> Signed-off-by: Hyeoncheol Lee
>> ---
>> tools/perf/util/probe-event.c |5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> index 49a256e..bb40ed4 100644
>> --- a/tools/perf/util/probe-event.c
>> +++ b/tools/perf/util/probe-event.c
>> @@ -2352,13 +2352,14 @@ static int convert_name_to_addr(struct
>> perf_probe_event *pev, const char *exec)
>> free(exec_copy);
>> }
>> free(pp->function);
>> - pp->function = zalloc(sizeof(char *) * MAX_PROBE_ARGS);
>> + pp->function = zalloc(sizeof(char) *
>> + (3 + sizeof(unsigned long long) * 2));
>
> Could you comment that this is enough long here?
>
Because a hexadecimal address that starts with "0x"
will be stored in pp->function. sizeof(unsigned long long) * 2 is
maximum length of hexadecimal number of variable "vaddr"
and 3 bytes are for "0x" and null character.
>> if (!pp->function) {
>> ret = -ENOMEM;
>> pr_warning("Failed to allocate memory by zalloc.\n");
>> goto out;
>> }
>> - e_snprintf(pp->function, MAX_PROBE_ARGS, "0x%llx", vaddr);
>> + sprintf(pp->function, "0x%llx", vaddr);
>
> And at least we should use snprintf instead of sprintf...
> (I think ret = e_snprintf(...) is better)
>
You are right, but I didn't want to write down the length of
"pp->function" again.
>> ret = 0;
>>
>> out:
>>
>
> Thank you,
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu...@hitachi.com
>
>
Thank you very much!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf probe: convert_name_to_addr() allocated the wrong size buffer for a function name
Hi,
2012/10/16 Srikar Dronamraju :
> * Masami Hiramatsu [2012-10-16 13:19:57]:
>
>> (2012/10/16 10:37), Hyeoncheol Lee wrote:
>> > convert_name_to_addr() allocated sizeof(char *) * MAX_PROBE_ARGS
>> > bytes for a function name
>>
>> Yeah, that one was from my laziness...
>>
>
> Guess not your fault, but mine.
>
>> >
>> > Cc: Masami Hiramatsu
>> > Cc: Srikar Dronamraju
>> > Signed-off-by: Hyeoncheol Lee
>> > ---
>> > tools/perf/util/probe-event.c |5 +++--
>> > 1 file changed, 3 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> > index 49a256e..bb40ed4 100644
>> > --- a/tools/perf/util/probe-event.c
>> > +++ b/tools/perf/util/probe-event.c
>> > @@ -2352,13 +2352,14 @@ static int convert_name_to_addr(struct
>> > perf_probe_event *pev, const char *exec)
>> > free(exec_copy);
>> > }
>> > free(pp->function);
>> > - pp->function = zalloc(sizeof(char *) * MAX_PROBE_ARGS);
>> > + pp->function = zalloc(sizeof(char) *
>> > + (3 + sizeof(unsigned long long) * 2));
>>
>> Could you comment that this is enough long here?
>
> Also can we move the arith into a macro?
>
I will do.
>>
>> > if (!pp->function) {
>> > ret = -ENOMEM;
>> > pr_warning("Failed to allocate memory by zalloc.\n");
>> > goto out;
>> > }
>> > - e_snprintf(pp->function, MAX_PROBE_ARGS, "0x%llx", vaddr);
>> > + sprintf(pp->function, "0x%llx", vaddr);
>>
>> And at least we should use snprintf instead of sprintf...
>> (I think ret = e_snprintf(...) is better)
>>
>
> Agree.
Yes
>
>> > ret = 0;
>> >
>> > out:
>> >
>>
>
> --
> Thanks and Regards
> Srikar
>
Thank you for your comment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c-hid: introduce HID over i2c specification implementation
On 10/15/2012 10:38 PM, Benjamin Tissoires wrote:
> Notes:
> {1}: I don't have all the informations in the beginning of the probe function
> to
> get the real size I need to allocate. So the behavior is to allocate first a
> buffer by using HID_MIN_BUFFER_SIZE and once I got the information, I can
> reallocate the buffer to the right size (in i2c_hid_start).
And there is a bug in this. See below.
> --- /dev/null
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
...
> +static int i2c_hid_alloc_buffers(struct i2c_hid *ihid)
> +{
> + /* the worst case is computed from the set_report command with a
> + * reportID > 15 and the maximum report length */
> + int args_len = sizeof(__u8) + /* optional ReportID byte */
> +sizeof(__u16) + /* data register */
> +sizeof(__u16) + /* size of the report */
> +ihid->bufsize; /* report */
> +
> + ihid->inbuf = kzalloc(ihid->bufsize, GFP_KERNEL);
> +
> + if (!ihid->inbuf)
> + return -ENOMEM;
> +
> + ihid->argsbuf = kzalloc(args_len, GFP_KERNEL);
> +
> + if (!ihid->argsbuf) {
> + kfree(ihid->inbuf);
> + return -ENOMEM;
> + }
> +
> + ihid->cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL);
> +
> + if (!ihid->cmdbuf) {
> + kfree(ihid->inbuf);
> + kfree(ihid->argsbuf);
> + return -ENOMEM;
> + }
> +
> + return 0;
If this is called from hid_start and some of the latter allocation fails
here, you free the buffers appropriately. However if another start
occurs (e.g. by loading another module for that particular device), it
will crash, as the buffers will remain unallocated because at this point
ihid->bufsize == old_bufsize. You should set ihid->bufsize back to
old_bufsize if i2c_hid_alloc_buffers fails and also set the pointers to
NULL here.
regards,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 08/14] res_counter: return amount of charges after res_counter_uncharge
(2012/10/08 19:06), Glauber Costa wrote: > It is useful to know how many charges are still left after a call to > res_counter_uncharge. While it is possible to issue a res_counter_read > after uncharge, this can be racy. > > If we need, for instance, to take some action when the counters drop > down to 0, only one of the callers should see it. This is the same > semantics as the atomic variables in the kernel. > > Since the current return value is void, we don't need to worry about > anything breaking due to this change: nobody relied on that, and only > users appearing from now on will be checking this value. > > Signed-off-by: Glauber Costa > CC: Michal Hocko > CC: Johannes Weiner > CC: Suleiman Souhlal > CC: Kamezawa Hiroyuki > --- > Documentation/cgroups/resource_counter.txt | 7 --- > include/linux/res_counter.h| 12 +++- > kernel/res_counter.c | 20 +--- > 3 files changed, 24 insertions(+), 15 deletions(-) Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 RESEND] gpio: samsung: use pr_* instead of printk
This patch uses pr_* instead of printk. Also, gpio_dbg
is replaced with pr_debug.
Signed-off-by: Ryan Mallon
Signed-off-by: Jingoo Han
Reviewed-by: Linus Walleij
---
drivers/gpio/gpio-samsung.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index a006f0d..5c5ccdf 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -42,12 +42,6 @@
#include
#include
-#ifndef DEBUG_GPIO
-#define gpio_dbg(x...) do { } while (0)
-#else
-#define gpio_dbg(x...) printk(KERN_DEBUG x)
-#endif
-
int samsung_gpio_setpull_updown(struct samsung_gpio_chip *chip,
unsigned int off, samsung_gpio_pull_t pull)
{
@@ -599,7 +593,7 @@ static int samsung_gpiolib_4bit_input(struct gpio_chip
*chip,
con &= ~(0xf << con_4bit_shift(offset));
__raw_writel(con, base + GPIOCON_OFF);
- gpio_dbg("%s: %p: CON now %08lx\n", __func__, base, con);
+ pr_debug("%s: %p: CON now %08lx\n", __func__, base, con);
return 0;
}
@@ -627,7 +621,7 @@ static int samsung_gpiolib_4bit_output(struct gpio_chip
*chip,
__raw_writel(con, base + GPIOCON_OFF);
__raw_writel(dat, base + GPIODAT_OFF);
- gpio_dbg("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
+ pr_debug("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
return 0;
}
@@ -671,7 +665,7 @@ static int samsung_gpiolib_4bit2_input(struct gpio_chip
*chip,
con &= ~(0xf << con_4bit_shift(offset));
__raw_writel(con, regcon);
- gpio_dbg("%s: %p: CON %08lx\n", __func__, base, con);
+ pr_debug("%s: %p: CON %08lx\n", __func__, base, con);
return 0;
}
@@ -706,7 +700,7 @@ static int samsung_gpiolib_4bit2_output(struct gpio_chip
*chip,
__raw_writel(con, regcon);
__raw_writel(dat, base + GPIODAT_OFF);
- gpio_dbg("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
+ pr_debug("%s: %p: CON %08lx, DAT %08lx\n", __func__, base, con, dat);
return 0;
}
@@ -926,10 +920,10 @@ static void __init samsung_gpiolib_add(struct
samsung_gpio_chip *chip)
#ifdef CONFIG_PM
if (chip->pm != NULL) {
if (!chip->pm->save || !chip->pm->resume)
- printk(KERN_ERR "gpio: %s has missing PM functions\n",
+ pr_err("gpio: %s has missing PM functions\n",
gc->label);
} else
- printk(KERN_ERR "gpio: %s has no PM function\n", gc->label);
+ pr_err("gpio: %s has no PM function\n", gc->label);
#endif
/* gpiochip_add() prints own failure message on error. */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] tty: pty - Move TIOCPKT handling into pty.c
On Fri, Sep 28, 2012 at 01:10:33AM +0400, Cyrill Gorcunov wrote: > Since this ioctl is for pty devices only move it to pty.c. > > v2: > - drop PTY_TYPE_MASTER test since it's master peer >ioctl anyway (by jslaby@) > > Suggested-by: Alan Cox > Signed-off-by: Cyrill Gorcunov > CC: "H. Peter Anvin" > CC: Greg Kroah-Hartman > CC: Pavel Emelyanov > CC: Jiri Slaby Greg, Alan, what about this series? Is there anything else I should do? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] mfd: add viperboard driver
On 10/12/2012 04:34 PM, Lars Poeschel wrote:
> [...]
> +static void vprbrd_dev_release(struct device *dev)
> +{
> + return;
A empty release callback is usually a good indicator that something is
wrong. The release callback will be called once the last reference to the
device has been called, so the memory associated with the device should not
be freed before the release callback has been called, otherwise the memory
might be accessed after it has been freed...
> +}
> +
> +static void vprbrd_free(struct vprbrd *dev)
> +{
> + usb_put_dev(dev->usb_dev);
> + kfree(dev);
..., so this kfree should be moved from here to the release callback.
Btw. I'm wondering why is the extra platform device required? Can't you not
just use the usb device as the parent device for the mfd cells?
> +}
> [...][
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: compaction: Correct the nr_strict_isolated check for CMA
Thierry reported that the "iron out" patch for isolate_freepages_block() had problems due to the strict check being too strict with "mm: compaction: Iron out isolate_freepages_block() and isolate_freepages_range() -fix1". It's possible that more pages than necessary are isolated but the check still fails and I missed that this fix was not picked up before RC1. This same problem has been identified in 3.7-RC1 by Tony Prisk and should be addressed by the following patch. Signed-off-by: Mel Gorman Tested-by: Tony Prisk --- mm/compaction.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/compaction.c b/mm/compaction.c index 2c4ce17..9eef558 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -346,7 +346,7 @@ static unsigned long isolate_freepages_block(struct compact_control *cc, * pages requested were isolated. If there were any failures, 0 is * returned and CMA will fail. */ - if (strict && nr_strict_required != total_isolated) + if (strict && nr_strict_required > total_isolated) total_isolated = 0; if (locked) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 09/14] memcg: kmem accounting lifecycle management
(2012/10/12 17:41), Michal Hocko wrote: On Fri 12-10-12 11:47:17, Glauber Costa wrote: On 10/11/2012 05:11 PM, Michal Hocko wrote: On Mon 08-10-12 14:06:15, Glauber Costa wrote: Because kmem charges can outlive the cgroup, we need to make sure that we won't free the memcg structure while charges are still in flight. For reviewing simplicity, the charge functions will issue mem_cgroup_get() at every charge, and mem_cgroup_put() at every uncharge. This can get expensive, however, and we can do better. mem_cgroup_get() only really needs to be issued once: when the first limit is set. In the same spirit, we only need to issue mem_cgroup_put() when the last charge is gone. We'll need an extra bit in kmem_accounted for that: KMEM_ACCOUNTED_DEAD. it will be set when the cgroup dies, if there are charges in the group. If there aren't, we can proceed right away. Our uncharge function will have to test that bit every time the charges drop to 0. Because that is not the likely output of res_counter_uncharge, this should not impose a big hit on us: it is certainly much better than a reference count decrease at every operation. [ v3: merged all lifecycle related patches in one ] Signed-off-by: Glauber Costa CC: Kamezawa Hiroyuki CC: Christoph Lameter CC: Pekka Enberg CC: Michal Hocko CC: Johannes Weiner CC: Suleiman Souhlal OK, I like the optimization. I have just one comment to the memcg_kmem_dead naming but other than that Acked-by: Michal Hocko [...] +static bool memcg_kmem_dead(struct mem_cgroup *memcg) The name is tricky because it doesn't tell you that it clears the flag which made me scratch my head when reading comment in kmem_cgroup_destroy memcg_kmem_finally_kill_that_bastard() ? memcg_kmem_test_and_clear_dead? I know long but at least clear that the flag is cleared. Or just open code it. I agree. Ack by me with that naming. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dw_mmc: fix multiple drv_data NULL dereferences
Commit 800d78bfccb3d38116abfda2a5b9c8afdbd5ea21 ("mmc: dw_mmc: add
support for implementation specific callbacks") merged in v3.7-rc1.
The above commit introduced multiple NULL pointer dereferences when
the default dw_mci_pltfm_probe() is used, as it sets host->drv_data to
NULL, and that's only checked against NULL in 1 out of the 7 cases where
it is dereferenced.
Signed-off-by: James Hogan
---
drivers/mmc/host/dw_mmc-pltfm.c |4 ++--
drivers/mmc/host/dw_mmc.c | 29 +
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index c960ca7..e595721 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -50,8 +50,8 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
if (!host->regs)
return -ENOMEM;
- if (host->drv_data->init) {
- ret = host->drv_data->init(host);
+ if (drv_data && drv_data->init) {
+ ret = drv_data->init(host);
if (ret)
return ret;
}
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index c2828f3..0dc6e33 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -232,6 +232,7 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
{
struct mmc_data *data;
struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci_drv_data *drv_data = slot->host->drv_data;
u32 cmdr;
cmd->error = -EINPROGRESS;
@@ -261,8 +262,8 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
cmdr |= SDMMC_CMD_DAT_WR;
}
- if (slot->host->drv_data->prepare_command)
- slot->host->drv_data->prepare_command(slot->host, &cmdr);
+ if (drv_data && drv_data->prepare_command)
+ drv_data->prepare_command(slot->host, &cmdr);
return cmdr;
}
@@ -772,6 +773,7 @@ static void dw_mci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci_drv_data *drv_data = slot->host->drv_data;
u32 regs;
/* set default 1 bit mode */
@@ -807,8 +809,8 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
slot->clock = ios->clock;
}
- if (slot->host->drv_data->set_ios)
- slot->host->drv_data->set_ios(slot->host, ios);
+ if (drv_data && drv_data->set_ios)
+ drv_data->set_ios(slot->host, ios);
switch (ios->power_mode) {
case MMC_POWER_UP:
@@ -1815,6 +1817,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
{
struct mmc_host *mmc;
struct dw_mci_slot *slot;
+ struct dw_mci_drv_data *drv_data = host->drv_data;
int ctrl_id, ret;
u8 bus_width;
@@ -1854,8 +1857,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
} else {
ctrl_id = to_platform_device(host->dev)->id;
}
- if (host->drv_data && host->drv_data->caps)
- mmc->caps |= host->drv_data->caps[ctrl_id];
+ if (drv_data && drv_data->caps)
+ mmc->caps |= drv_data->caps[ctrl_id];
if (host->pdata->caps2)
mmc->caps2 = host->pdata->caps2;
@@ -1867,10 +1870,10 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
else
bus_width = 1;
- if (host->drv_data->setup_bus) {
+ if (drv_data && drv_data->setup_bus) {
struct device_node *slot_np;
slot_np = dw_mci_of_find_slot_node(host->dev, slot->id);
- ret = host->drv_data->setup_bus(host, slot_np, bus_width);
+ ret = drv_data->setup_bus(host, slot_np, bus_width);
if (ret)
goto err_setup_bus;
}
@@ -2035,6 +2038,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci
*host)
struct dw_mci_board *pdata;
struct device *dev = host->dev;
struct device_node *np = dev->of_node;
+ struct dw_mci_drv_data *drv_data = host->drv_data;
int idx, ret;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
@@ -2062,8 +2066,8 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci
*host)
of_property_read_u32(np, "card-detect-delay", &pdata->detect_delay_ms);
- if (host->drv_data->parse_dt) {
- ret = host->drv_data->parse_dt(host);
+ if (drv_data && drv_data->parse_dt) {
+ ret = drv_data->parse_dt(host);
if (ret)
return ERR_PTR(ret);
}
@@ -2080,6 +2084,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci
*host)
int dw_mci_probe(struct dw_mci *host)
[PATCH] dmatest: terminate all ongoing transfers before submitting new one
The following error messages come if we have software LLP emulation enabled and enough threads running. modprobe dmatest iterations=40 [ 168.048601] dmatest: Started 1 threads using dma0chan0 [ 168.054546] dmatest: Started 1 threads using dma0chan1 [ 168.060441] dmatest: Started 1 threads using dma0chan2 [ 168.066333] dmatest: Started 1 threads using dma0chan3 [ 168.072250] dmatest: Started 1 threads using dma0chan4 [ 168.078144] dmatest: Started 1 threads using dma0chan5 [ 168.084057] dmatest: Started 1 threads using dma0chan6 [ 168.089948] dmatest: Started 1 threads using dma0chan7 [ 170.032962] dma0chan1-copy0: terminating after 40 tests, 0 failures (status 0) [ 170.041274] dma0chan0-copy0: terminating after 40 tests, 0 failures (status 0) [ 170.597559] dma0chan2-copy0: terminating after 40 tests, 0 failures (status 0) [ 171.085059] dma0chan7-copy0: #0: test timed out [ 171.839710] dma0chan3-copy0: terminating after 40 tests, 0 failures (status 0) [ 172.146071] dma0chan4-copy0: terminating after 40 tests, 0 failures (status 0) [ 172.220802] dma0chan7-copy0: #1: got completion callback, but status is 'in progress' [ 172.242049] dma0chan7-copy0: #2: got completion callback, but status is 'in progress' [ 172.281063] dma0chan7-copy0: #3: got completion callback, but status is 'in progress' [ 172.400866] dma0chan7-copy0: #4: got completion callback, but status is 'in progress' [ 172.471799] dma0chan7-copy0: #5: got completion callback, but status is 'in progress' [ 172.613996] dma0chan7-copy0: #6: got completion callback, but status is 'in progress' [ 172.670286] dma0chan7-copy0: #7: got completion callback, but status is 'in progress' [ 172.750763] dma0chan7-copy0: #8: got completion callback, but status is 'in progress' [ 172.777452] dma0chan5-copy0: terminating after 40 tests, 0 failures (status 0) [ 172.788740] dma0chan7-copy0: #9: got completion callback, but status is 'in progress' [ 172.845156] dma0chan7-copy0: #10: got completion callback, but status is 'in progress' [ 172.906593] dma0chan7-copy0: #11: got completion callback, but status is 'in progress' [ 173.181515] dma0chan6-copy0: terminating after 40 tests, 0 failures (status 0) [ 173.512838] dma0chan7-copy0: terminating after 40 tests, 12 failures (status 0) The patch fixes dmatest module to stop any ongoing transfer before submitting new one. Perhaps there is a better solution and driver logic needs to be fixed as well. After patch we will have modprobe dmatest iterations=50 [ 84.027375] dmatest: Started 1 threads using dma0chan0 [ 84.033282] dmatest: Started 1 threads using dma0chan1 [ 84.039182] dmatest: Started 1 threads using dma0chan2 [ 84.045089] dmatest: Started 1 threads using dma0chan3 [ 84.051003] dmatest: Started 1 threads using dma0chan4 [ 84.056916] dmatest: Started 1 threads using dma0chan5 [ 84.062828] dmatest: Started 1 threads using dma0chan6 [ 84.068714] dmatest: Started 1 threads using dma0chan7 [ 86.538284] dma0chan0-copy0: terminating after 50 tests, 0 failures (status 0) [ 86.842221] dma0chan1-copy0: terminating after 50 tests, 0 failures (status 0) [ 87.060460] dma0chan6-copy0: #0: test timed out [ 87.065614] dma0chan7-copy0: #0: test timed out [ 87.220321] dma0chan2-copy0: terminating after 50 tests, 0 failures (status 0) [ 88.595061] dma0chan3-copy0: terminating after 50 tests, 0 failures (status 0) [ 89.152170] dma0chan4-copy0: terminating after 50 tests, 0 failures (status 0) [ 89.955059] dma0chan5-copy0: terminating after 50 tests, 0 failures (status 0) [ 90.697073] dma0chan6-copy0: terminating after 50 tests, 1 failures (status 0) [ 90.893422] dma0chan7-copy0: terminating after 50 tests, 1 failures (status 0) Signed-off-by: Andy Shevchenko --- drivers/dma/dmatest.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index 24225f0..583f882 100644 --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -399,6 +399,9 @@ static int dmatest_func(void *data) continue; } + /* Stop any ongoing transfers here */ + chan->device->device_control(chan, DMA_TERMINATE_ALL, 0); + done.done = false; tx->callback = dmatest_callback; tx->callback_param = &done; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/6 v3] gpio: Add sysfs support to block GPIO API
On 22:30 Mon 15 Oct , Linus Walleij wrote: > I really request Grant to comment on this...too. > > On Mon, Oct 15, 2012 at 8:19 PM, Greg Kroah-Hartman > wrote: > > On Mon, Oct 15, 2012 at 08:07:02PM +0200, Jean-Christophe PLAGNIOL-VILLARD > > wrote: > >> On 21:11 Fri 12 Oct , Roland Stigge wrote: > >> > This patch adds sysfs support to the block GPIO API. > >> > > >> > Signed-off-by: Roland Stigge > >> > > >> > --- > >> > Documentation/ABI/testing/sysfs-gpio |6 > >> > drivers/gpio/gpiolib.c | 226 > >> > ++- > >> > include/asm-generic/gpio.h | 11 + > >> > include/linux/gpio.h | 13 ++ > >> > 4 files changed, 254 insertions(+), 2 deletions(-) > >> I really don't like this sysfs we need to add a specific device with ioctl > > > > Why? > > I don't like it either, basically because the GPIO sysfs is not > entirely sound. > > Another patch that is circulating concerns edge triggers and similar, > and it appear that some parts of the GPIO sysfs is for example > redefining and exporting IRQchip properties like trigger edge > in sysfs, while the settings of the irqchip actually used by the driver > is not reflected in the other direction. So you can *set* these things > by writing in the GPIO sysfs, but never trust what you *read* from > there. And you can set what edges an IRQ will trigger on a certain > GPIO, and the way to handle the IRQs from usespace is to poll > on a value. This is not really documented but well ... > > Part of me just want to delete that, but I can't because it's now > an ABI. > > The "devices" that the sysfs files are tied to are not real devices, > instead the code look like this: whenever a gpio is exported to > sysfs, the code calls (drivers/gpio/gpiolib.c): > > dev = device_create(&gpio_class, desc->chip->dev, MKDEV(0, 0), > desc, ioname ? ioname : "gpio%u", gpio); > > Mock device just to get a sysfs opening. And once device for > every GPIO with no hierarchical correspondence to anything > in the system. > > The thing is that struct gpio_chip is not a device at all, it's something > else. > > This inconsistency in the GPIO sysfs implementation make me > fear adding new stuff to it. The other problems need fixing first. > > The reason an ioctl() IMO is better suited to do the job is that > it can properly represent a multiple-value operation on several > GPIOs at the same time in a struct, and it can conversely inform > userspace about which GPIOs may be a block of signals that > can be fired simultaneously instead of going to string parsing > and binary values in sysfs which look like worse hacks to me. > > The last thing I'm a bit softer on though. Mainly I fear of this > sysfs ABI growing into a beast. > > It was all merged prior to Grant becoming maintainer and > me becoming co-maintainer of it, so this is legacy business. > > Sadly the main creator of this ABI is David Brownell who is > not able to respond nor maintain it from where he is now. But > we need to think hard about what we shall do with this particular > piece of legacy. Some of the stuff was added by Daniel > Glöckner so requesting advice from him. > > Daniel: are you interested in helping us fixing the GPIOlib > sysfs ABI and kernel internals? I'm a bit afraid of it. My 0.02$ too Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 12/12] x86, topology: Debug CPU00 hotplug
On 10/12/2012 09:39 PM, Fenghua Yu wrote:
> From: Fenghua Yu
> +config DEBUG_HOTPLUG_CPU0
> + def_bool n
> + prompt "Debug CPU0 hotplug"
> + depends on HOTPLUG_CPU && EXPERIMENTAL
> + ---help---
> + Enabling this option offlines CPU0 (if CPU0 can be offlined) as
> + soon as possible and boots up userspace with CPU0 offlined. User
> + can online CPU0 back after boot time.
> +
> + To debug CPU0 hotplug, you need to enable CPU0 offline/online
> + feature by either turning on CONFIG_BOOTPARAM_HOTPLUG_CPU0 during
> + compilation or giving cpu0_hotplug kernel parameter at boot.
> +
> + If unuser, say N.
s/unuser/unsure
> +#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
> +/*
> + * This function offlines a CPU as early as possible and allows userspace to
> + * boot up without the CPU. The CPU can be onlined back by user after boot.
> + *
> + * This is only called for debugging CPU offline/online feature.
> + */
> +int __ref _debug_hotplug_cpu(int cpu, int action)
> +{
> + struct device *dev = get_cpu_device(cpu);
> + int ret;
> +
> + if (!cpu_is_hotpluggable(cpu))
> + return -EINVAL;
> +
> + cpu_hotplug_driver_lock();
> +
> + switch (action) {
> + case 0:
> + ret = cpu_down(cpu);
> + if (!ret) {
> + pr_info("CPU %u is now offline\n", cpu);
> + kobject_uevent(&dev->kobj, KOBJ_OFFLINE);
> + } else
> + pr_debug("Can't offline CPU%d.\n", cpu);
> + break;
> + case 1:
> + ret = cpu_up(cpu);
> + if (!ret)
> + kobject_uevent(&dev->kobj, KOBJ_ONLINE);
> + else
> + pr_debug("Can't online CPU%d.\n", cpu);
> + break;
> + default:
> + ret = -EINVAL;
> + }
> +
> + cpu_hotplug_driver_unlock();
> +
> + return ret;
> +}
> +
> +static int __init debug_hotplug_cpu(void)
> +{
> + _debug_hotplug_cpu(0, 0);
> + return 0;
> +}
> +
> +late_initcall_sync(debug_hotplug_cpu);
> +#endif /* CONFIG_DEBUG_HOTPLUG_CPU0 */
> +
> int __ref arch_register_cpu(int num)
> {
> struct cpuinfo_x86 *c = &cpu_data(num);
> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> index adde775..120cee1 100644
> --- a/arch/x86/power/cpu.c
> +++ b/arch/x86/power/cpu.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include /* pcntxt_mask */
> +#include
>
> #ifdef CONFIG_X86_32
> static struct saved_context saved_context;
> @@ -263,6 +264,43 @@ static int bsp_pm_callback(struct notifier_block *nb,
> unsigned long action,
> case PM_HIBERNATION_PREPARE:
> ret = bsp_check();
> break;
> +#ifdef CONFIG_DEBUG_HOTPLUG_CPU0
> + case PM_RESTORE_PREPARE:
> + /*
> + * When system resumes from hibernation, online CPU0 because
> + * 1. it's required for resume and
> + * 2. the CPU was online before hibernation
> + */
> + if (!cpu_online(0))
> + _debug_hotplug_cpu(0, 1);
This won't work. CPU hotplug is disabled by cpu_hotplug_pm_callback() during
PM_HIBERNATION_PREPARE and is enabled back only during PM_POST_HIBERNATION.
So calls to cpu_up() or cpu_down() will fail in the meantime.
Regards,
Srivatsa S. Bhat
> + break;
> + case PM_POST_RESTORE:
> + /*
> + * When a resume really happens, this code won't be called.
> + *
> + * This code is called only when user space hibernation software
> + * prepares for snapshot device during boot time. So we just
> + * call _debug_hotplug_cpu() to restore to CPU0's state prior to
> + * preparing the snapshot device.
> + *
> + * This works for normal boot case in our CPU0 hotplug debug
> + * mode, i.e. CPU0 is offline and user mode hibernation
> + * software initializes during boot time.
> + *
> + * If CPU0 is online and user application accesses snapshot
> + * device after boot time, this will offline CPU0 and user may
> + * see different CPU0 state before and after accessing
> + * the snapshot device. But hopefully this is not a case when
> + * user debugging CPU0 hotplug. Even if users hit this case,
> + * they can easily online CPU0 back.
> + *
> + * To simplify this debug code, we only consider normal boot
> + * case. Otherwise we need to remember CPU0's state and restore
> + * to that state and resolve racy conditions etc.
> + */
> + _debug_hotplug_cpu(0, 0);
> + break;
> +#endif
> default:
> break;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
Re: [PATCH v4 10/14] memcg: use static branches when code not in use
(2012/10/12 16:47), Glauber Costa wrote:
On 10/11/2012 05:40 PM, Michal Hocko wrote:
On Mon 08-10-12 14:06:16, Glauber Costa wrote:
We can use static branches to patch the code in or out when not used.
Because the _ACTIVE bit on kmem_accounted is only set after the
increment is done, we guarantee that the root memcg will always be
selected for kmem charges until all call sites are patched (see
memcg_kmem_enabled). This guarantees that no mischarges are applied.
static branch decrement happens when the last reference count from the
kmem accounting in memcg dies. This will only happen when the charges
drop down to 0.
When that happen, we need to disable the static branch only on those
memcgs that enabled it. To achieve this, we would be forced to
complicate the code by keeping track of which memcgs were the ones
that actually enabled limits, and which ones got it from its parents.
It is a lot simpler just to do static_key_slow_inc() on every child
that is accounted.
[ v4: adapted this patch to the changes in kmem_accounted ]
Signed-off-by: Glauber Costa
CC: Kamezawa Hiroyuki
CC: Christoph Lameter
CC: Pekka Enberg
CC: Michal Hocko
CC: Johannes Weiner
CC: Suleiman Souhlal
Looks reasonable to me
Acked-by: Michal Hocko
Just a little nit.
[...]
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 634c7b5..724a08b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -344,11 +344,15 @@ struct mem_cgroup {
/* internal only representation about the status of kmem accounting. */
enum {
KMEM_ACCOUNTED_ACTIVE = 0, /* accounted by this cgroup itself */
+ KMEM_ACCOUNTED_ACTIVATED, /* static key enabled. */
KMEM_ACCOUNTED_DEAD, /* dead memcg, pending kmem charges */
};
-/* first bit */
-#define KMEM_ACCOUNTED_MASK 0x1
+/*
+ * first two bits. We account when limit is on, but only after
+ * call sites are patched
+ */
+#define KMEM_ACCOUNTED_MASK 0x3
The names are long but why not use KMEM_ACCOUNTED_ACTIVE*
#define KMEM_ACCOUNTED_MASK 1<
Because the names are long! =)
please use "long" macros ;) it's not bad.
Anyway,
Acked-by: KAMEZAWA Hiroyuki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] slab: Ignore internal flags in cache creation
On 10/16/2012 04:47 AM, David Rientjes wrote: > On Mon, 8 Oct 2012, David Rientjes wrote: > >>> diff --git a/mm/slab.h b/mm/slab.h >>> index 7deeb44..4c35c17 100644 >>> --- a/mm/slab.h >>> +++ b/mm/slab.h >>> @@ -45,6 +45,31 @@ static inline struct kmem_cache >>> *__kmem_cache_alias(const char *name, size_t siz >>> #endif >>> >>> >>> +/* Legal flag mask for kmem_cache_create(), for various configurations */ >>> +#define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | SLAB_PANIC >>> | \ >>> +SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS ) >>> + >>> +#if defined(CONFIG_DEBUG_SLAB) >>> +#define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER) >>> +#elif defined(CONFIG_SLUB_DEBUG) >>> +#define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \ >>> + SLAB_TRACE | SLAB_DEBUG_FREE) >>> +#else >>> +#define SLAB_DEBUG_FLAGS (0) >>> +#endif >>> + >>> +#if defined(CONFIG_SLAB) >>> +#define SLAB_CACHE_FLAGS (SLAB_MEMSPREAD | SLAB_NOLEAKTRACE | \ >> >> s/SLAB_MEMSPREAD/SLAB_MEM_SPREAD/ >> > > Did you have a v5 of this patch with the above fix? > Yes, I sent it bundled in my kmemcg-slab series. I can send it separately as well, no problem. (Or we can merge the series!!! =p ) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] tty: pty - Move TIOCPKT handling into pty.c
> Greg, Alan, what about this series? Is there anything else I should do? Other than resending it now the merge window is closed - I can't think of anything. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmatest: terminate all ongoing transfers before submitting new one
On Tue, Oct 16, 2012 at 2:15 PM, Andy Shevchenko
wrote:
> The following error messages come if we have software LLP emulation enabled
> and
> enough threads running.
>
> modprobe dmatest iterations=40
> [ 168.048601] dmatest: Started 1 threads using dma0chan0
> [ 168.054546] dmatest: Started 1 threads using dma0chan1
> [ 168.060441] dmatest: Started 1 threads using dma0chan2
> [ 168.066333] dmatest: Started 1 threads using dma0chan3
> [ 168.072250] dmatest: Started 1 threads using dma0chan4
> [ 168.078144] dmatest: Started 1 threads using dma0chan5
> [ 168.084057] dmatest: Started 1 threads using dma0chan6
> [ 168.089948] dmatest: Started 1 threads using dma0chan7
> [ 170.032962] dma0chan1-copy0: terminating after 40 tests, 0 failures
> (status 0)
> [ 170.041274] dma0chan0-copy0: terminating after 40 tests, 0 failures
> (status 0)
> [ 170.597559] dma0chan2-copy0: terminating after 40 tests, 0 failures
> (status 0)
> [ 171.085059] dma0chan7-copy0: #0: test timed out
> [ 171.839710] dma0chan3-copy0: terminating after 40 tests, 0 failures
> (status 0)
> [ 172.146071] dma0chan4-copy0: terminating after 40 tests, 0 failures
> (status 0)
> [ 172.220802] dma0chan7-copy0: #1: got completion callback, but status is
> 'in progress'
> [ 172.242049] dma0chan7-copy0: #2: got completion callback, but status is
> 'in progress'
> [ 172.281063] dma0chan7-copy0: #3: got completion callback, but status is
> 'in progress'
> [ 172.400866] dma0chan7-copy0: #4: got completion callback, but status is
> 'in progress'
> [ 172.471799] dma0chan7-copy0: #5: got completion callback, but status is
> 'in progress'
> [ 172.613996] dma0chan7-copy0: #6: got completion callback, but status is
> 'in progress'
> [ 172.670286] dma0chan7-copy0: #7: got completion callback, but status is
> 'in progress'
> [ 172.750763] dma0chan7-copy0: #8: got completion callback, but status is
> 'in progress'
> [ 172.777452] dma0chan5-copy0: terminating after 40 tests, 0 failures
> (status 0)
> [ 172.788740] dma0chan7-copy0: #9: got completion callback, but status is
> 'in progress'
> [ 172.845156] dma0chan7-copy0: #10: got completion callback, but status is
> 'in progress'
> [ 172.906593] dma0chan7-copy0: #11: got completion callback, but status is
> 'in progress'
> [ 173.181515] dma0chan6-copy0: terminating after 40 tests, 0 failures
> (status 0)
> [ 173.512838] dma0chan7-copy0: terminating after 40 tests, 12 failures
> (status 0)
>
> The patch fixes dmatest module to stop any ongoing transfer before submitting
> new one. Perhaps there is a better solution and driver logic needs to be fixed
> as well.
>
> After patch we will have
>
> modprobe dmatest iterations=50
> [ 84.027375] dmatest: Started 1 threads using dma0chan0
> [ 84.033282] dmatest: Started 1 threads using dma0chan1
> [ 84.039182] dmatest: Started 1 threads using dma0chan2
> [ 84.045089] dmatest: Started 1 threads using dma0chan3
> [ 84.051003] dmatest: Started 1 threads using dma0chan4
> [ 84.056916] dmatest: Started 1 threads using dma0chan5
> [ 84.062828] dmatest: Started 1 threads using dma0chan6
> [ 84.068714] dmatest: Started 1 threads using dma0chan7
> [ 86.538284] dma0chan0-copy0: terminating after 50 tests, 0 failures
> (status 0)
> [ 86.842221] dma0chan1-copy0: terminating after 50 tests, 0 failures
> (status 0)
> [ 87.060460] dma0chan6-copy0: #0: test timed out
> [ 87.065614] dma0chan7-copy0: #0: test timed out
> [ 87.220321] dma0chan2-copy0: terminating after 50 tests, 0 failures
> (status 0)
> [ 88.595061] dma0chan3-copy0: terminating after 50 tests, 0 failures
> (status 0)
> [ 89.152170] dma0chan4-copy0: terminating after 50 tests, 0 failures
> (status 0)
> [ 89.955059] dma0chan5-copy0: terminating after 50 tests, 0 failures
> (status 0)
> [ 90.697073] dma0chan6-copy0: terminating after 50 tests, 1 failures
> (status 0)
> [ 90.893422] dma0chan7-copy0: terminating after 50 tests, 1 failures
> (status 0)
You still have failures. :(
Can you try with a large timeout value for the module.
We must get to the root cause of these failures. There may be something more
serious which is getting hidden due to this call to terminate().
Unless there is a issue with software emulation of LLP, the only difference with
s/w emulation is the transfers become slow.
Also, the proposed solution might hide some other important errors. We may need
to terminate transfers when we found that an error is there in last transfers:
if (!done.done) {
/*
* We're leaving the timed out dma operation with
* dangling pointer to done_wait. To make this
* correct, we'll need to allocate wait_done for
* each test iteration and perform "who's gonna
* free it this time?" dancing. For now, just
* leave it dangling.
*
Re: [patch 1/3] tty: pty - Move TIOCPKT handling into pty.c
On Tue, Oct 16, 2012 at 09:58:22AM +0100, Alan Cox wrote: > > Greg, Alan, what about this series? Is there anything else I should do? > > Other than resending it now the merge window is closed - I can't think of > anything. OK, thanks, I'll resend. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
On Tue, Oct 16, 2012 at 09:04:34AM +0300, Hiroshi Doyu wrote: > In addition to those contiguous/discontiguous page allocation, is > there any way to _import_ anonymous pages allocated by a process to be > used in dma-mapping API later? > > I'm considering the following scenario, an user process allocates a > buffer by malloc() in advance, and then it asks some driver to convert > that buffer into IOMMU'able/DMA'able ones later. In this case, pages > are discouguous and even they may not be yet allocated at > malloc()/mmap(). That situation is covered. It's the streaming API you're wanting for that. dma_map_sg() - but you may need additional cache handling via flush_dcache_page() to ensure that your code is safe for all CPU cache architectures. Remember that pages allocated into userspace will be cacheable, so a cache flush is required before they can be DMA'd. Hence the streaming API. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Low-jitter kernel benchmark.
http://www.phoronix.com/scan.php?page=news_item&px=MTIwNzM While Phoronix usually miss the point of these configs, these benchmarks still show that low-jitter on the desktop, does not affect desktop performance negatively. Only if you are running Apache, on a server, you`d want a different config. And then not even X, so this is not related to "desktop". So this should weigh heavily with any sane desktop-distro maker, for his config. Ubuntu configgers have no valid argument about throughput anymore, for instance. Peace Be With You. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] uprobes tracer: Add stack/memory/retval access support
Event arguments except @SYM are supported. They are @ADDR,
$stack, $stackN, $retval, and offs(arguments).
Cc: Masami Hiramatsu
Cc: Srikar Dronamraju
Signed-off-by: Hyeoncheol Lee
---
kernel/trace/trace_kprobe.c |6 +-
kernel/trace/trace_probe.c | 162 ++-
kernel/trace/trace_probe.h |6 +-
kernel/trace/trace_uprobe.c |6 +-
4 files changed, 124 insertions(+), 56 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 1a21170..60046d3 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -683,7 +683,7 @@ static __kprobes int __get_data_size(struct trace_probe *tp,
for (i = 0; i < tp->nr_args; i++)
if (unlikely(tp->args[i].fetch_size.fn)) {
- call_fetch(&tp->args[i].fetch_size, regs, &len);
+ call_fetch(&tp->args[i].fetch_size, regs, &len, true);
ret += len;
}
@@ -708,7 +708,7 @@ static __kprobes void store_trace_args(int ent_size, struct
trace_probe *tp,
dl = (u32 *)(data + tp->args[i].offset);
*dl = make_data_rloc(maxlen, end - tp->args[i].offset);
/* Then try to fetch string or dynamic array data */
- call_fetch(&tp->args[i].fetch, regs, dl);
+ call_fetch(&tp->args[i].fetch, regs, dl, true);
/* Reduce maximum length */
end += get_rloc_len(*dl);
maxlen -= get_rloc_len(*dl);
@@ -718,7 +718,7 @@ static __kprobes void store_trace_args(int ent_size, struct
trace_probe *tp,
} else
/* Just fetching data normally */
call_fetch(&tp->args[i].fetch, regs,
- data + tp->args[i].offset);
+ data + tp->args[i].offset, true);
}
}
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index daa9980..955c3fa 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -112,7 +112,8 @@ DEFINE_FETCH_##method(u64)
/* Data fetch function templates */
#define DEFINE_FETCH_reg(type) \
static __kprobes void FETCH_FUNC_NAME(reg, type)(struct pt_regs *regs, \
- void *offset, void *dest) \
+ void *offset, void *dest, \
+ bool kprobe)\
{ \
*(type *)dest = (type)regs_get_register(regs, \
(unsigned int)((unsigned long)offset)); \
@@ -122,12 +123,49 @@ DEFINE_BASIC_FETCH_FUNCS(reg)
#define fetch_reg_string NULL
#define fetch_reg_string_size NULL
+#ifdef CONFIG_STACK_GROWSUP
+#defineWITHIN_USER_STACK(vma, addr, n) \
+ ( \
+ addr -= n, \
+ (vma)->vm_start <= (unsigned long)(addr)\
+ )
+#else
+#defineWITHIN_USER_STACK(vma, addr, n) \
+ ( \
+ addr += n, \
+ (vma)->vm_end >= (unsigned long)(addr) \
+ )
+#endif
+
+static unsigned long regs_get_user_stack_nth(struct pt_regs *regs,
+unsigned int n)
+{
+ struct vm_area_struct *vma;
+ unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+ unsigned long ret = 0;
+
+ down_read(¤t->mm->mmap_sem);
+ vma = find_vma(current->mm, (unsigned long)addr);
+ if (vma && vma->vm_start <= (unsigned long)addr) {
+ if (WITHIN_USER_STACK(vma, addr, n))
+ if (get_user(ret, addr) != 0)
+ ret = 0;
+ }
+ up_read(¤t->mm->mmap_sem);
+ return ret;
+}
+
#define DEFINE_FETCH_stack(type) \
static __kprobes void FETCH_FUNC_NAME(stack, type)(struct pt_regs *regs,\
- void *offset, void *dest) \
+ void *offset, void *dest, \
+ bool kprobe) \
{ \
- *(type *)dest = (type)regs_get_kernel_stack_nth(regs, \
+ if (kprobe) \
+ *(type *)dest = (type)regs_get_kernel_stack_nth(regs, \
(unsigned int)((unsigned long)offset)); \
+ else
Re: Strange crash on Dell R720xd
On Mon, Oct 15, 2012 at 09:42:58PM +0200, Laurent CARON wrote: > Hi, > > I'm currently replacing an old system (HP DL 380 G5) by new dell R720xd. > On those new boxes I did configure the H310 controler as plain JBOD. > > Those boxes appear to crash more often than not (from 5 mins to a couple > of hours). > I have the impression those crashes appear under heavy IO. > > The setup consists of a few md RAID arrays serving as underlying devices > for either filesystem, or drbd (plus lvm on top). > > I managed to catch a trace over netconsole: > [ cut here ] > kernel BUG at crypto/async_tx/async_tx.c:174! That's: BUG_ON(async_tx_test_ack(depend_tx) || txd_next(depend_tx) || txd_parent(tx)); but probably the b0rkage happens up the stack. And this __raid_run_ops is probably starting the whole TX so maybe we should add linux-r...@vger.kernel.org to CC. Added. > invalid opcode: [#1] SMP > Modules linked in: drbd lru_cache netconsole iptable_filter ip_tables > ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue > bonding ipv6 btrfs ioatdma lpc_ich sb_edac dca mfd_core > CPU 0 > Pid: 12580, comm: kworker/u:2 Not tainted 3.6.2-r510-r720xd #1 Dell Inc. > PowerEdge R720xd What is that "r510" thing in the kernel version? You have your patches ontop? If yes, please try reproducing this with a kernel.org kernel without anything else ontop. Also, it might be worth trying plain 3.6 to rule out a regression introduced in the stable 3.6 series. (leaving in the rest for reference) > RIP: 0010:[] [] async_tx_submit+0x29/0xab > RSP: 0018:88100940fb30 EFLAGS: 00010202 > RAX: 88100b30aeb0 RBX: 88080b5cf390 RCX: 0029 > RDX: 88100940fd00 RSI: 88080b5cf390 RDI: 880809ad0818 > RBP: 8808054a7d90 R08: 88080b5cf900 R09: 0001 > R10: 1000 R11: 0001 R12: 88100940fd00 > R13: 0002 R14: 880809ad0638 R15: 880809ad0818 > FS: () GS:88080fc0() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: ff600400 CR3: 000e4055f000 CR4: 000407f0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process kworker/u:2 (pid: 12580, threadinfo 88100940e000, task > 880804850630) > Stack: > 88100940fd00 88100940fc40 0101 8131044b > 0001 0246 0201 a0073a00 > 8808054a7d90 8808054a7690 88100940fc40 88080bf9e668 > Call Trace: > [] ? do_async_gen_syndrome+0x2f3/0x320 > [] ? ioat2_tx_submit_unlock+0xac/0xb3 [ioatdma] > [] ? ops_complete_compute+0x7b/0x7b > [] ? async_gen_syndrome+0xc8/0x1d6 > [] ? __raid_run_ops+0x9e7/0xb5a > [] ? select_task_rq_fair+0x487/0x74b > [] ? ops_complete_compute+0x7b/0x7b > [] ? __wake_up+0x35/0x46 > [] ? async_schedule+0x12/0x12 > [] ? async_run_ops+0x32/0x3e > [] ? async_run_entry_fn+0xa4/0x17e > [] ? async_schedule+0x12/0x12 > [] ? process_one_work+0x259/0x381 > [] ? worker_thread+0x2ad/0x3e3 > [] ? try_to_wake_up+0x1fc/0x20c > [] ? manage_workers+0x245/0x245 > [] ? manage_workers+0x245/0x245 > [] ? kthread+0x81/0x89 > [] ? kernel_thread_helper+0x4/0x10 > [] ? kthread_freezable_should_stop+0x4e/0x4e > [] ? gs_change+0xb/0xb > Code: 5b c3 41 54 49 89 d4 55 53 48 89 f3 48 8b 6a 08 48 8b 42 10 48 85 ed 48 > 89 46 20 48 8b 42 18 48 89 46 28 74 5c f6 45 04 02 74 72 <0f> 0b eb fe 48 8b > 02 48 8b 48 28 80 e1 40 74 24 31 f6 48 89 d7 > RIP [] async_tx_submit+0x29/0xab > RSP > ---[ end trace 64fb561d16a3b535 ]--- > Kernel panic - not syncing: Fatal exception in interrupt > Rebooting in 5 seconds.. > > Do any of you guys have a clue about it ? > > Thanks > > Laurent > > PS: The very same kernel doesn't cause any trouble on R510 hardware. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] efivarfs: efivarfs_fill_super() ensure we clean up correctly on error
Hi Andy,
If we break out of the loop on the second (and onwards) iteration,
won't we still have the other inodes and dentries remaining
allocated?
As we calling this from the mount_single() wrapper:
return mount_single(fs_type, flags, data, efivarfs_fill_super);
which does this:
struct dentry *mount_single(struct file_system_type *fs_type,
int flags, void *data,
int (*fill_super)(struct super_block *, void *, int))
{
[...]
error = fill_super(s, data, flags & MS_SILENT ? 1 : 0);
if (error) {
deactivate_locked_super(s);
return ERR_PTR(error);
}
[...]
I am expecting us to get called back via deactivate_locked_super(),
which calls sb->kill_sb() which is:
static void efivarfs_kill_sb(struct super_block *sb)
{
kill_litter_super(sb);
efivarfs_sb = NULL;
}
Which I believe will clean them up.
Awesome, thanks for that. Looks good to me.
Acked-by: Jeremy Kerr
Cheers,
Jeremy Kerr
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
