Re: sched: spinlock recursion in migrate_swap_stop

[Peter Zijlstra]

On Wed, May 21, 2014 at 10:34:44PM -0400, Sasha Levin wrote:
> On 05/21/2014 12:49 PM, Peter Zijlstra wrote:
> > On Wed, May 21, 2014 at 03:19:48PM +0200, Peter Zijlstra wrote:
> >> > On Wed, May 21, 2014 at 09:08:26AM -0400, Sasha Levin wrote:
> >>> > > +++ b/kernel/sched/core.c
> >>> > > @@ -1154,6 +1156,7 @@ int migrate_swap(struct task_struct *cur, 
> >>> > > struct task_struct *p)
> >>> > > goto out;
> >>> > > 
> >>> > > trace_sched_swap_numa(cur, arg.src_cpu, p, arg.dst_cpu);
> >>> > > +   BUG_ON(cur == p);
> >>> > > ret = stop_two_cpus(arg.dst_cpu, arg.src_cpu, 
> >>> > > migrate_swap_stop, &arg);
> >>> > > 
> >>> > >  out:
> >>> > > 
> >>> > > 
> >>> > > Which seems to get hit. This sounds like a race with task moving to
> >>> > > other cpu maybe?
> >> > 
> >> > Oi, good call that, lemme go stare.
> > I think something simple like this should be sufficient to avoid the
> > problem of selecting oneself as a flip target.
> 
> Why would that happen in the first place?

We do all that with preemption enabled, because its big and expensive,
so its entirely possible that current (env->p) got moved around while we
were doing it, at which point we'll look at it as a possible dst, while
its already our src.




pgp8ct_lmcajt.pgp
Description: PGP signature

Re: ye olde task_ctx_sched_out trace.

[Adrian Hunter]

On 05/21/2014 06:32 PM, Peter Zijlstra wrote:
> On Wed, May 21, 2014 at 05:30:13PM +0200, Peter Zijlstra wrote:
>> A little something like so I suppose.
>>
>> ---
> 
>> +void perf_event_exec(void)
>> +{
>> +struct perf_event_context *ctx;
>> +int ctxn;
>> +
>> +rcu_read_lock();
>> +for_each_task_context_nr(ctxn) {
>> +ctx = task->perf_event_ctxp[ctxn];
> 
> s/task/current/
> 
>> +if (!ctx)
>> +continue;
>> +
>> +perf_event_enable_on_exec(ctx);
>> +}
>> +rcu_read_unlock();
>> +}
> 
> 
> It would help if I pasted the one that actually compiles I suppose..
> 
> ---
>  fs/exec.c  |  1 +
>  include/linux/perf_event.h |  1 +
>  kernel/events/core.c   | 28 
>  3 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index 476f3ebf437e..8d51d7ce3dcf 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -,6 +,7 @@ void setup_new_exec(struct linux_binprm * bprm)
>   set_dumpable(current->mm, suid_dumpable);
>  
>   set_task_comm(current, kbasename(bprm->filename));
> + perf_event_exec();

Shouldn't that be the other way around i.e.

+   perf_event_exec();
set_task_comm(current, kbasename(bprm->filename));

Also what about flagging the comm event that corresponds to an exec e.g.

diff --git a/fs/exec.c b/fs/exec.c
index 476f3eb..28d69a1 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1046,13 +1046,13 @@ EXPORT_SYMBOL_GPL(get_task_comm);
  * so that a new one can be started
  */
 
-void set_task_comm(struct task_struct *tsk, const char *buf)
+void __set_task_comm(struct task_struct *tsk, const char *buf, bool exec)
 {
task_lock(tsk);
trace_task_rename(tsk, buf);
strlcpy(tsk->comm, buf, sizeof(tsk->comm));
task_unlock(tsk);
-   perf_event_comm(tsk);
+   perf_event_comm(tsk, exec);
 }
 
 int flush_old_exec(struct linux_binprm * bprm)
@@ -1110,7 +1110,7 @@ void setup_new_exec(struct linux_binprm * bprm)
else
set_dumpable(current->mm, suid_dumpable);
 
-   set_task_comm(current, kbasename(bprm->filename));
+   __set_task_comm(current, kbasename(bprm->filename), true);
 
/* Set the new mm task size. We have to do that late because it may
 * depend on TIF_32BIT which is only updated in flush_thread() on
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index af6dcf1..26614312 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -694,7 +694,7 @@ extern struct perf_guest_info_callbacks *perf_guest_cbs;
 extern int perf_register_guest_info_callbacks(struct perf_guest_info_callbacks 
*callbacks);
 extern int perf_unregister_guest_info_callbacks(struct 
perf_guest_info_callbacks *callbacks);
 
-extern void perf_event_comm(struct task_struct *tsk);
+extern void perf_event_comm(struct task_struct *tsk, bool exec);
 extern void perf_event_fork(struct task_struct *tsk);
 
 /* Callchains */
@@ -801,7 +801,7 @@ static inline int perf_unregister_guest_info_callbacks
 (struct perf_guest_info_callbacks *callbacks)  { 
return 0; }
 
 static inline void perf_event_mmap(struct vm_area_struct *vma) { }
-static inline void perf_event_comm(struct task_struct *tsk){ }
+static inline void perf_event_comm(struct task_struct *tsk, bool exec) { }
 static inline void perf_event_fork(struct task_struct *tsk){ }
 static inline void perf_event_init(void)   { }
 static inline int  perf_swevent_get_recursion_context(void){ 
return -1; }
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..cadcf38 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2376,7 +2376,11 @@ extern long do_fork(unsigned long, unsigned long, 
unsigned long, int __user *, i
 struct task_struct *fork_idle(int);
 extern pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
-extern void set_task_comm(struct task_struct *tsk, const char *from);
+extern void __set_task_comm(struct task_struct *tsk, const char *from, bool 
exec);
+static inline void set_task_comm(struct task_struct *tsk, const char *from)
+{
+   __set_task_comm(tsk, from, false);
+}
 extern char *get_task_comm(char *to, struct task_struct *tsk);
 
 #ifdef CONFIG_SMP
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index e3fc8f0..8ae875a 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -501,7 +501,12 @@ struct perf_event_mmap_page {
 #define PERF_RECORD_MISC_GUEST_KERNEL  (4 << 0)
 #define PERF_RECORD_MISC_GUEST_USER(5 << 0)
 
+/*
+ * PERF_RECORD_MISC_MMAP_DATA and PERF_RECORD_MISC_COMM_EXEC are used on
+ * different events so can reuse the same bit position.
+ */
 #define PERF_RECORD_MISC_MMAP_DATA (1 << 13)
+#define PERF_RECORD_MISC_COMM_EXEC   

From Brian, Libya

[Brian Shields]

I apologize for using this medium to reach out to you however, I am compelled 
by the urgency of my situation to contact you. I am a US Army Officer currently 
on mission in Libya. 
I  would need your assistance to invest the sum of US$ 2.5M for me in your 
region. If you can offer me some guidelines and serve as my proxy investor in 
investing the funds, I will surely compensate you adequately. Kindly provide me 
with your direct phone number in your response to my private email so that we 
can discuss more in details. My private email is: shields...@gmail.com
Best regards
Brian Shields.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the pci tree

[Sebastian Ott]

Hello,

On Thu, 22 May 2014, Stephen Rothwell wrote:
> Hi Bjorn,
> 
> After merging the pci tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> drivers/pci/pci-sysfs.c: In function 'devspec_show':
> drivers/pci/pci-sysfs.c:426:22: error: dereferencing pointer to incomplete 
> type
> drivers/pci/pci-sysfs.c:428:30: error: dereferencing pointer to incomplete 
> type
> drivers/pci/pci-sysfs.c:429:1: warning: control reaches end of non-void 
> function [-Wreturn-type]
> 
> Caused by commit da647bb30834 ("PCI: Move Open Firmware devspec
> attribute to PCI common code").  Presumably a forgotten include.
> 
> I have used the pci tree from next-20140521 for today.

Oops, sry for that one - this should fix it:

pci: fix compile failure on arm

Fix this compile error introduced by "PCI: Move Open Firmware
devspec attribute to PCI common code":

drivers/pci/pci-sysfs.c: In function 'devspec_show':
drivers/pci/pci-sysfs.c:426:22: error: dereferencing pointer to incomplete type
drivers/pci/pci-sysfs.c:428:30: error: dereferencing pointer to incomplete type
drivers/pci/pci-sysfs.c:429:1: warning: control reaches end of non-void 
function [-Wreturn-type]

Reported-by: Stephen Rothwell 
Signed-off-by: Sebastian Ott 
---
 drivers/pci/pci-sysfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 4e0acef..d6e61ae 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 static int sysfs_initialized;  /* = 0 */
-- 
1.8.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: filemap: Avoid unnecessary barries and waitqueue lookups in unlock_page fastpath v5

[Peter Zijlstra]

On Wed, May 21, 2014 at 02:50:00PM -0700, Andrew Morton wrote:
> On Wed, 21 May 2014 23:33:54 +0200 Peter Zijlstra  
> wrote:

> Alternative solution is not to merge the patch ;)

There is always that.. :-)

> > Yeah, so we only clear that bit when at 'unlock' we find there are no
> > more pending waiters, so if the last unlock still had a waiter, we'll
> > leave the bit set.
> 
> Confused.  If the last unlock had a waiter, that waiter will get woken
> up so there are no waiters any more, so the last unlock clears the flag.
> 
> um, how do we determine that there are no more waiters?  By looking at
> the waitqueue.  But that waitqueue is hashed, so it may contain waiters
> for other pages so we're screwed?  But we could just go and wake up the
> other-page waiters anyway and still clear PG_waiters?
> 
> um2, we're using exclusive waitqueues so we can't (or don't) wake all
> waiters, so we're screwed again?

Ah, so leave it set. Then when we do an uncontended wakeup, that is a
wakeup where there are _no_ waiters left, we'll iterate the entire
hashed queue, looking for a matching page.

We'll find none, and only then clear the bit.


> (This process is proving to be a hard way of writing Mel's changelog btw).

Agreed :/

> If I'm still on track here, what happens if we switch to wake-all so we
> can avoid the dangling flag?  I doubt if there are many collisions on
> that hash table?

Wake-all will be ugly and loose a herd of waiters, all racing to
acquire, all but one of whoem will loose the race. It also looses the
fairness, its currently a FIFO queue. Wake-all will allow starvation.

> If there *are* a lot of collisions, I bet it's because a great pile of
> threads are all waiting on the same page.  If they're trying to lock
> that page then wake-all is bad.  But if they're just waiting for IO
> completion (probable) then it's OK.

Yeah, I'm not entirely sure on the rationale for adding PG_waiters to
writeback completion, and yes PG_writeback is a wake-all.


pgp0z0FmMKIdX.pgp
Description: PGP signature

Re: [PATCH] cpufreq: s5pv210: remove unused call of pr_err()

[Paul Bolle]

Sachin,

On Thu, 2014-05-22 at 08:52 +0530, Sachin Kamat wrote:
> The config symbol itself is not defined and hence could be removed.
> However I feel, the
> error message could be retained after trimming down the arguments a bit.

My reasoning is, of course, that never used code can simply be dropped.

But you want to print an error here. That's fine with me. I prefer if
you'd submit a patch that does that, as I have no idea whatsoever why an
error is needed here nor what that error should say.

I do hope you don't mind me prodding you if that takes too long, and
this pointless check of CONFIG_PM_VERBOSE is still here after, say,
another development cycle.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/4] mfd: intel_soc_pmic: Crystal Cove support

[Zhu, Lejun]

Crystal Cove is the PMIC in Baytrail-T platform. This patch provides
chip-specific support for Crystal Cove.

v2:
- Add regmap_config for Crystal Cove.

Signed-off-by: Yang, Bin 
Signed-off-by: Zhu, Lejun 
---
 drivers/mfd/intel_soc_pmic_crc.c | 165 +++
 1 file changed, 165 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_crc.c

diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
new file mode 100644
index 000..6ab4cbf
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -0,0 +1,165 @@
+/*
+ * intel_soc_pmic_crc.c - Device access for Crystal Cove PMIC
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Author: Yang, Bin 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "intel_soc_pmic_core.h"
+
+#define CRYSTAL_COVE_IRQ_NUM   7
+#define CRYSTAL_COVE_MAX_REGISTER  0xBD
+
+#define CHIPID 0x00
+#define CHIPVER0x01
+#define IRQLVL10x02
+#define MIRQLVL1   0x0E
+enum {
+   PWRSRC_IRQ = 0,
+   THRM_IRQ,
+   BCU_IRQ,
+   ADC_IRQ,
+   CHGR_IRQ,
+   GPIO_IRQ,
+   VHDMIOCP_IRQ
+};
+
+static struct resource gpio_resources[] = {
+   {
+   .name   = "GPIO",
+   .start  = GPIO_IRQ,
+   .end= GPIO_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct resource pwrsrc_resources[] = {
+   {
+   .name  = "PWRSRC",
+   .start = PWRSRC_IRQ,
+   .end   = PWRSRC_IRQ,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static struct resource adc_resources[] = {
+   {
+   .name  = "ADC",
+   .start = ADC_IRQ,
+   .end   = ADC_IRQ,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static struct resource thermal_resources[] = {
+   {
+   .name  = "THERMAL",
+   .start = THRM_IRQ,
+   .end   = THRM_IRQ,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+static struct resource bcu_resources[] = {
+   {
+   .name  = "BCU",
+   .start = BCU_IRQ,
+   .end   = BCU_IRQ,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+static struct mfd_cell crystal_cove_dev[] = {
+   {
+   .name = "crystal_cove_pwrsrc",
+   .id = 0,
+   .num_resources = ARRAY_SIZE(pwrsrc_resources),
+   .resources = pwrsrc_resources,
+   },
+   {
+   .name = "crystal_cove_adc",
+   .id = 0,
+   .num_resources = ARRAY_SIZE(adc_resources),
+   .resources = adc_resources,
+   },
+   {
+   .name = "crystal_cove_thermal",
+   .id = 0,
+   .num_resources = ARRAY_SIZE(thermal_resources),
+   .resources = thermal_resources,
+   },
+   {
+   .name = "crystal_cove_bcu",
+   .id = 0,
+   .num_resources = ARRAY_SIZE(bcu_resources),
+   .resources = bcu_resources,
+   },
+   {
+   .name = "crystal_cove_gpio",
+   .id = 0,
+   .num_resources = ARRAY_SIZE(gpio_resources),
+   .resources = gpio_resources,
+   },
+   {NULL, },
+};
+
+#defineCRC_IRQREGMAP_VALUE(irq){   \
+   {MIRQLVL1, irq, 1, 0},  \
+   {IRQLVL1,  irq, 1, 0},  \
+   INTEL_PMIC_REG_NULL,\
+   }
+
+static struct intel_pmic_irqregmap crystal_cove_irqregmap[] = {
+   [PWRSRC_IRQ]= CRC_IRQREGMAP_VALUE(PWRSRC_IRQ),
+   [THRM_IRQ]  = CRC_IRQREGMAP_VALUE(THRM_IRQ),
+   [BCU_IRQ]   = CRC_IRQREGMAP_VALUE(BCU_IRQ),
+   [ADC_IRQ]   = CRC_IRQREGMAP_VALUE(ADC_IRQ),
+   [CHGR_IRQ]  = CRC_IRQREGMAP_VALUE(CHGR_IRQ),
+   [GPIO_IRQ]  = CRC_IRQREGMAP_VALUE(GPIO_IRQ),
+   [VHDMIOCP_IRQ]  = CRC_IRQREGMAP_VALUE(VHDMIOCP_IRQ),
+};
+
+static struct regmap_config crystal_cove_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = CRYSTAL_COVE_MAX_REGISTER,
+   .cache_type = REGCACHE_NONE,
+};
+
+static int crystal_cove_init(void)
+{
+   pr_debug("Crystal Cove: ID 0x%02X, VERSION 0x%02X\n",
+intel_soc_pmic_readb(CHIPID), intel_soc_pmic_readb(CHIPVER));
+   return 0;
+}
+
+struct intel_so

[PATCH v2 2/4] mfd: intel_soc_pmic: I2C interface

[Zhu, Lejun]

The Intel SoC PMIC devices are connected to the CPU via the I2C
interface. This patch provides support of the related I2C operations.

v2:
- Use regmap instead of creating our own I2C read/write callbacks.

Signed-off-by: Yang, Bin 
Signed-off-by: Zhu, Lejun 
---
 drivers/mfd/intel_soc_pmic_i2c.c | 148 +++
 1 file changed, 148 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c

diff --git a/drivers/mfd/intel_soc_pmic_i2c.c b/drivers/mfd/intel_soc_pmic_i2c.c
new file mode 100644
index 000..b6b8ee1
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_i2c.c
@@ -0,0 +1,148 @@
+/*
+ * intel_soc_pmic_i2c.c - Intel SoC PMIC MFD Driver
+ *
+ * Copyright (C) 2013, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Author: Yang, Bin 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "intel_soc_pmic_core.h"
+
+static struct i2c_client *pmic_i2c_client;
+static struct intel_soc_pmic *pmic_i2c;
+
+static void pmic_shutdown(struct i2c_client *client)
+{
+   disable_irq(pmic_i2c_client->irq);
+   return;
+}
+
+static int pmic_suspend(struct device *dev)
+{
+   disable_irq(pmic_i2c_client->irq);
+   return 0;
+}
+
+static int pmic_resume(struct device *dev)
+{
+   enable_irq(pmic_i2c_client->irq);
+   return 0;
+}
+
+static const struct dev_pm_ops pmic_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(pmic_suspend, pmic_resume)
+};
+
+static int pmic_i2c_lookup_gpio(struct device *dev, int acpi_index)
+{
+   struct gpio_desc *desc;
+   int gpio;
+
+   desc = gpiod_get_index(dev, KBUILD_MODNAME, acpi_index);
+   if (IS_ERR(desc))
+   return PTR_ERR(desc);
+
+   gpio = desc_to_gpio(desc);
+
+   gpiod_put(desc);
+
+   return gpio;
+}
+
+static int pmic_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+   if (pmic_i2c_client != NULL || pmic_i2c != NULL)
+   return -EBUSY;
+
+   pmic_i2c= (struct intel_soc_pmic *)id->driver_data;
+   pmic_i2c_client = i2c;
+   pmic_i2c->dev   = &i2c->dev;
+   pmic_i2c->irq   = i2c->irq;
+   pmic_i2c->pmic_int_gpio = pmic_i2c_lookup_gpio(pmic_i2c->dev, 0);
+   pmic_i2c->regmap = devm_regmap_init_i2c(i2c, pmic_i2c->regmap_cfg);
+
+   return intel_pmic_add(pmic_i2c);
+}
+
+static int pmic_i2c_remove(struct i2c_client *i2c)
+{
+   int ret = intel_pmic_remove(pmic_i2c);
+
+   pmic_i2c_client = NULL;
+   pmic_i2c = NULL;
+
+   return ret;
+}
+
+static const struct i2c_device_id pmic_i2c_id[] = {
+   { "crystal_cove", (kernel_ulong_t)&crystal_cove_pmic},
+   { "INT33FD", (kernel_ulong_t)&crystal_cove_pmic},
+   { "INT33FD:00", (kernel_ulong_t)&crystal_cove_pmic},
+   { }
+};
+MODULE_DEVICE_TABLE(i2c, pmic_i2c_id);
+
+static struct acpi_device_id pmic_acpi_match[] = {
+   { "INT33FD", (kernel_ulong_t)&crystal_cove_pmic},
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, pmic_acpi_match);
+
+static struct i2c_driver pmic_i2c_driver = {
+   .driver = {
+   .name = "intel_soc_pmic_i2c",
+   .owner = THIS_MODULE,
+   .pm = &pmic_pm_ops,
+   .acpi_match_table = ACPI_PTR(pmic_acpi_match),
+   },
+   .probe = pmic_i2c_probe,
+   .remove = pmic_i2c_remove,
+   .id_table = pmic_i2c_id,
+   .shutdown = pmic_shutdown,
+};
+
+static int __init pmic_i2c_init(void)
+{
+   int ret;
+
+   ret = i2c_add_driver(&pmic_i2c_driver);
+   if (ret != 0)
+   pr_err("Failed to register pmic I2C driver: %d\n", ret);
+
+   return ret;
+}
+subsys_initcall(pmic_i2c_init);
+
+static void __exit pmic_i2c_exit(void)
+{
+   i2c_del_driver(&pmic_i2c_driver);
+}
+module_exit(pmic_i2c_exit);
+
+MODULE_DESCRIPTION("I2C driver for Intel SoC PMIC");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Yang, Bin ");
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] mfd: intel_soc_pmic: Build files

[Zhu, Lejun]

Devices based on Intel SoC products such as Baytrail have a Power
Management IC. This patch adds Intel SoC PMIC support to the build files.

v2:
- Add select REGMAP_I2C.

Signed-off-by: Yang, Bin 
Signed-off-by: Zhu, Lejun 
---
 drivers/mfd/Kconfig  | 11 +++
 drivers/mfd/Makefile |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3383412..2c9de8e0 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -241,6 +241,17 @@ config LPC_SCH
  LPC bridge function of the Intel SCH provides support for
  System Management Bus and General Purpose I/O.
 
+config INTEL_SOC_PMIC
+   bool "Support for Intel Atom SoC PMIC"
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ Select this option to enable support for the PMIC device
+ on some Intel SoC systems. The PMIC provides ADC, GPIO,
+ thermal, charger and related power management functions
+ on these systems.
+
 config MFD_INTEL_MSIC
bool "Intel MSIC"
depends on INTEL_SCU_IPC
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 2851275..1a18d8b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -166,3 +166,6 @@ obj-$(CONFIG_MFD_RETU)  += retu-mfd.o
 obj-$(CONFIG_MFD_AS3711)   += as3711.o
 obj-$(CONFIG_MFD_AS3722)   += as3722.o
 obj-$(CONFIG_MFD_STW481X)  += stw481x.o
+
+intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o 
intel_soc_pmic_i2c.o
+obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] mfd: Intel SoC Power Management IC

[Zhu, Lejun]

Devices based on Intel SoC products such as Baytrail have a Power
Management IC. In the PMIC there are subsystems for voltage regulation,
A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
Crystal Cove.

This series contains common code for these PMICs, and device specific
support for Crystal Cove.

v2:
- Use regmap instead of creating our own I2C read/write callbacks.
- Add one missing EXPORT_SYMBOL.
- Remove some duplicate code and put them into pmic_regmap_load_from_hw.

Zhu, Lejun (4):
  mfd: intel_soc_pmic: Core driver
  mfd: intel_soc_pmic: I2C interface
  mfd: intel_soc_pmic: Crystal Cove support
  mfd: intel_soc_pmic: Build files

 drivers/mfd/Kconfig|  11 +
 drivers/mfd/Makefile   |   3 +
 drivers/mfd/intel_soc_pmic_core.c  | 521 +
 drivers/mfd/intel_soc_pmic_core.h  |  83 ++
 drivers/mfd/intel_soc_pmic_crc.c   | 165 
 drivers/mfd/intel_soc_pmic_i2c.c   | 148 +++
 include/linux/mfd/intel_soc_pmic.h |  29 +++
 7 files changed, 960 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_core.c
 create mode 100644 drivers/mfd/intel_soc_pmic_core.h
 create mode 100644 drivers/mfd/intel_soc_pmic_crc.c
 create mode 100644 drivers/mfd/intel_soc_pmic_i2c.c
 create mode 100644 include/linux/mfd/intel_soc_pmic.h

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

USB 3.0 - Synopsis DWC Host-AHB - on Linux Kernel 3.10.28

[krishnamurthy holla]

Hello,

I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian)

I see that XHCI fails during xhci_device_alloc() because of
wait_for_completion_interruptible_timeout () when I connect a device.

So, I thought of initializing host controller as BE as my host is BE.
But this time, it failed much earlier, i.e in xhci_handle_event()
itself for the check le32_to_cpu(event->event_cmd.flags) & TRB_CYCLE)
!=  xhci->event_ring->cycle_state)

I would like to know if any of you used Synopsis DWC Host-AHB and got
successful device detection. Also, Please let me know if XHCI needs
special configuration on Big Endian system.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 3/3] timerfd: Implement write method

[Michael Kerrisk]

[Thomas, thanks for pinging me on this.]

Hi Cyril

Please CC linux-api on changes that affect kernel-user-space ABI/API.

On Thu, May 22, 2014 at 12:35 AM, Cyrill Gorcunov  wrote:
> On Thu, May 22, 2014 at 07:12:30AM +0900, Thomas Gleixner wrote:
>>
>> There is a world outside of checkpoint/restore, really.
>
> Yes, I simply don't know who else might use this write()
> functionality for other purpose, I mean i don't see a
> point to use it for anything else.

Nevertheless, when making API changes like this, we should be thinking
as generally as possible, rather than looking from the perspective of
a single use case.

>> So what's the semantics of that write function? We really want to have
>> that agreed on and documented in the man page.
>
> The idea was to provide a way to setup @ticks into (nonzero) value
> which we get from show_fdinfo output. Then when we restore it
> we setup the timer and set @ticks to the value it had at dump
> moment.
>
>> Right now the write will just update the ticks and nothing else. So
>> what if there is a waiter already? What if there is a timer armed?
>>
>> Can you please describe how checkpoint/restore is going to use all of
>> this. How is the timer restored and how/when is the reader which was
>> waiting in read/poll at the time of suspend reattached to it.
>
> Thomas, I see what you mean. Need to think (I must admit I forgot about
> polling of timerfds :( I were to restore timerfds like this
>
>  - fetch data from fdinfo
>  - use timer_create/settime to arm it
>  - write @ticks then
>
> but i didn't try restore polling waiters, my bad. Letme rework this
> trying addressing your comments.

Great. Please CC me and linux-api@ on the next round.

Cheers,

Michael

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 5/6] usb: musb: dsps: Add the sw_babble_control()

[George Cherian]

Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.

Babble control register logic is implemented in the latest
revision of AM335x.

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_dsps.c | 50 
 drivers/usb/musb/musb_regs.h |  7 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..868caf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
 }
 
+static int sw_babble_control(struct musb *musb)
+{
+   int timeout = 10;
+   u8 babble_ctl, session_restart = 0;
+
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   dev_dbg(musb->controller, "babble: MUSB_BABBLE_CTL value %x\n",
+   babble_ctl);
+   /*
+* check line monitor flag to check whether babble is
+* due to noise
+*/
+   dev_dbg(musb->controller, "STUCK_J is %s\n",
+   babble_ctl & MUSB_BABBLE_STUCK_J ? "set" : "reset");
+
+   if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+   /*
+* babble is due to noise, then set transmit idle (d7 bit)
+* to resume normal operation
+*/
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+   dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+   /* wait till line monitor flag cleared */
+   dev_dbg(musb->controller, "Set TXIDLE, wait J to clear\n");
+   do {
+   babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   udelay(1);
+   } while ((babble_ctl & MUSB_BABBLE_STUCK_J) && timeout--);
+
+   /* check whether stuck_at_j bit cleared */
+   if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+   /*
+* real babble condition is occured
+* restart the controller to start the
+* session again
+*/
+   dev_dbg(musb->controller, "J not cleared, misc (%x)\n",
+   babble_ctl);
+   session_restart = 1;
+   }
+
+   } else {
+   session_restart = 1;
+   }
+
+   return session_restart;
+}
+
 static int dsps_musb_reset(struct musb *musb)
 {
struct device *dev = musb->controller;
diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h
index 03f2655..b9bcda5 100644
--- a/drivers/usb/musb/musb_regs.h
+++ b/drivers/usb/musb/musb_regs.h
@@ -72,6 +72,12 @@
 #define MUSB_DEVCTL_HR 0x02
 #define MUSB_DEVCTL_SESSION0x01
 
+/* BABBLE_CTL */
+#define MUSB_BABBLE_FORCE_TXIDLE   0x80
+#define MUSB_BABBLE_SW_SESSION_CTRL0x40
+#define MUSB_BABBLE_STUCK_J0x20
+#define MUSB_BABBLE_RCV_DISABLE0x04
+
 /* MUSB ULPI VBUSCONTROL */
 #define MUSB_ULPI_USE_EXTVBUS  0x01
 #define MUSB_ULPI_USE_EXTVBUSIND 0x02
@@ -246,6 +252,7 @@
  */
 
 #define MUSB_DEVCTL0x60/* 8 bit */
+#define MUSB_BABBLE_CTL0x61/* 8 bit */
 
 /* These are always controlled through the INDEX register */
 #define MUSB_TXFIFOSZ  0x62/* 8-bit (see masks) */
-- 
1.8.3.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 2/6] usb: musb: core: Convert babble recover work to delayed work

[George Cherian]

During babble condition both first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.

To acheive this schedule a delayed work for babble rrecovery.

While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_core.c | 15 ---
 drivers/usb/musb/musb_core.h |  2 +-
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index eff3c5c..8920b80 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -850,7 +850,8 @@ b_host:
 
/* handle babble condition */
if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
-   schedule_work(&musb->recover_work);
+   schedule_delayed_work(&musb->recover_work,
+ msecs_to_jiffies(100));
 
 #if 0
 /* REVISIT ... this would be for multiplexing periodic endpoints, or
@@ -1753,16 +1754,16 @@ static void musb_irq_work(struct work_struct *data)
 /* Recover from babble interrupt conditions */
 static void musb_recover_work(struct work_struct *data)
 {
-   struct musb *musb = container_of(data, struct musb, recover_work);
+   struct musb *musb = container_of(data, struct musb, recover_work.work);
int status;
 
musb_platform_reset(musb);
 
usb_phy_vbus_off(musb->xceiv);
-   udelay(100);
+   usleep_range(100, 200);
 
usb_phy_vbus_on(musb->xceiv);
-   udelay(100);
+   usleep_range(100, 200);
 
/*
 * When a babble condition occurs, the musb controller removes the
@@ -1945,7 +1946,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 
/* Init IRQ workqueue before request_irq */
INIT_WORK(&musb->irq_work, musb_irq_work);
-   INIT_WORK(&musb->recover_work, musb_recover_work);
+   INIT_DELAYED_WORK(&musb->recover_work, musb_recover_work);
INIT_DELAYED_WORK(&musb->deassert_reset_work, musb_deassert_reset);
INIT_DELAYED_WORK(&musb->finish_resume_work, musb_host_finish_resume);
 
@@ -2041,7 +2042,7 @@ fail4:
 
 fail3:
cancel_work_sync(&musb->irq_work);
-   cancel_work_sync(&musb->recover_work);
+   cancel_delayed_work_sync(&musb->recover_work);
cancel_delayed_work_sync(&musb->finish_resume_work);
cancel_delayed_work_sync(&musb->deassert_reset_work);
if (musb->dma_controller)
@@ -2107,7 +2108,7 @@ static int musb_remove(struct platform_device *pdev)
dma_controller_destroy(musb->dma_controller);
 
cancel_work_sync(&musb->irq_work);
-   cancel_work_sync(&musb->recover_work);
+   cancel_delayed_work_sync(&musb->recover_work);
cancel_delayed_work_sync(&musb->finish_resume_work);
cancel_delayed_work_sync(&musb->deassert_reset_work);
musb_free(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index d155a15..9241025 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -297,7 +297,7 @@ struct musb {
 
irqreturn_t (*isr)(int, void *);
struct work_struct  irq_work;
-   struct work_struct  recover_work;
+   struct delayed_work recover_work;
struct delayed_work deassert_reset_work;
struct delayed_work finish_resume_work;
u16 hwvers;
-- 
1.8.3.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 3/6] usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset()

[George Cherian]

For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_dsps.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 51beb13..74c4193 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -543,7 +543,11 @@ static void dsps_musb_reset(struct musb *musb)
const struct dsps_musb_wrapper *wrp = glue->wrp;
 
dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
-   udelay(100);
+   usleep_range(100, 200);
+   usb_phy_shutdown(musb->xceiv);
+   usleep_range(100, 200);
+   usb_phy_init(musb->xceiv);
+
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
1.8.3.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 1/6] usb: musb: core: Handle Babble condition only in HOST mode

[George Cherian]

BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.

Handle babble condition iff MUSB is in HOST mode.

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61da471..eff3c5c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -849,7 +849,7 @@ b_host:
}
 
/* handle babble condition */
-   if (int_usb & MUSB_INTR_BABBLE)
+   if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
schedule_work(&musb->recover_work);
 
 #if 0
-- 
1.8.3.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 4/6] usb: musb: core: Convert the musb_platform_reset to have a return value.

[George Cherian]

Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the  musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetting the IP block. In preperation to add that support
its better to have a rest_done return for  musb_platform_reset().

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_core.c | 10 ++
 drivers/usb/musb/musb_core.h | 10 ++
 drivers/usb/musb/musb_dsps.c |  3 ++-
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 8920b80..7c6836cc 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1755,9 +1755,11 @@ static void musb_irq_work(struct work_struct *data)
 static void musb_recover_work(struct work_struct *data)
 {
struct musb *musb = container_of(data, struct musb, recover_work.work);
-   int status;
+   int status, ret;
 
-   musb_platform_reset(musb);
+   ret  = musb_platform_reset(musb);
+   if (ret)
+   return;
 
usb_phy_vbus_off(musb->xceiv);
usleep_range(100, 200);
@@ -1766,8 +1768,8 @@ static void musb_recover_work(struct work_struct *data)
usleep_range(100, 200);
 
/*
-* When a babble condition occurs, the musb controller removes the
-* session bit and the endpoint config is lost.
+* When a babble condition occurs, the musb controller
+* removes the session bit and the endpoint config is lost.
 */
if (musb->dyn_fifo)
status = ep_config_from_table(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 9241025..414e57a 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,7 +192,7 @@ struct musb_platform_ops {
 
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
-   void(*reset)(struct musb *musb);
+   int (*reset)(struct musb *musb);
 
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -555,10 +555,12 @@ static inline void musb_platform_try_idle(struct musb 
*musb,
musb->ops->try_idle(musb, timeout);
 }
 
-static inline void musb_platform_reset(struct musb *musb)
+static inline int  musb_platform_reset(struct musb *musb)
 {
-   if (musb->ops->reset)
-   musb->ops->reset(musb);
+   if (!musb->ops->reset)
+   return -EINVAL;
+
+   return musb->ops->reset(musb);
 }
 
 static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..f6f3087 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
 }
 
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
 {
struct device *dev = musb->controller;
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
usleep_range(100, 200);
usb_phy_init(musb->xceiv);
 
+   return 0;
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
1.8.3.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 6/6] usb: musb: dsps: Enable sw babble control for newer silicon

[George Cherian]

Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.

Signed-off-by: George Cherian 
---
 drivers/usb/musb/musb_dsps.c | 38 --
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 868caf8..2ced061 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -136,6 +136,7 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+   bool sw_babble_enabled;
 
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
val &= ~(1 << wrp->otg_disable);
dsps_writel(musb->ctrl_base, wrp->phy_utmi, val);
 
+   /*
+*  Check whether the dsps version has babble control enabled.
+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+   val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+   if (val == MUSB_BABBLE_RCV_DISABLE) {
+   glue->sw_babble_enabled = true;
+   val |= MUSB_BABBLE_SW_SESSION_CTRL;
+   dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+   }
+
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
return ret;
@@ -591,14 +605,26 @@ static int dsps_musb_reset(struct musb *musb)
struct device *dev = musb->controller;
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
+   int session_restart = 0;
 
-   dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
-   usleep_range(100, 200);
-   usb_phy_shutdown(musb->xceiv);
-   usleep_range(100, 200);
-   usb_phy_init(musb->xceiv);
+   if (glue->sw_babble_enabled)
+   session_restart = sw_babble_control(musb);
+   /*
+* In case of new silicon version babble condition can be recovered
+* without resetting the MUSB. But for older silicon versions, MUSB
+* reset is needed
+*/
+   if (session_restart || !glue->sw_babble_enabled) {
+   dev_info(musb->controller, "Restarting MUSB to recover from 
Babble\n");
+   dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
+   usleep_range(100, 200);
+   usb_phy_shutdown(musb->xceiv);
+   usleep_range(100, 200);
+   usb_phy_init(musb->xceiv);
+   session_restart = 1;
+   }
 
-   return 0;
+   return !session_restart;
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
1.8.3.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/6] Add support for SW babble Control

[George Cherian]

Series add support for SW babble control logic found in 
new silicon versions of AM335x. Runtime differentiation of
silicon version is done by checking the BABBLE_CTL register.
For newer silicon the register default value read is 0x4 and
for older versions its 0x0.

Patch 1 -> Handle Babble only if MUSB is in HOST mode
Patch 2 -> Convert recover work to delayed work.
Patch 3 -> usb_phy_vbus_(off/_on) are NOPs for am335x PHY
   so use usb_phy(_shutdown/_init) in musb_platform_reset()
Patch 4 -> Add return value for musb_platform_reset() in prepration
   to support SW babble_ctrl
Patch 5 -> Add the sw_babble_control()
Patch 6 -> Enable sw babble control for newer silicon

v4 -> v5 : Added a debug print before resetting MUSB.
   changed a musb_readb to dsps_readb introduced in Patch#5 of v4.

v3 -> v4 : Fixes an issue in gagdet mode - BUS RESET should not
   be handled as a BABBLE. Added a check for the same.(Patch #1)
   Enable sw babble control properly (Patch #6)

v2 -> v3 : Modify musb_platform_reset() to return zero on success.

George Cherian (6):
  usb: musb: core: Handle Babble condition only in HOST mode
  usb: musb: core: Convert babble recover work to delayed work
  usb: musb: dsps: Call usb_phy(_shutdown/_init) during
musb_platform_reset()
  usb: musb: core: Convert the musb_platform_reset to have a return
value.
  usb: musb: dsps: Add the sw_babble_control()
  usb: musb: dsps: Enable sw babble control for newer silicon

 drivers/usb/musb/musb_core.c | 27 --
 drivers/usb/musb/musb_core.h | 12 +++---
 drivers/usb/musb/musb_dsps.c | 87 ++--
 drivers/usb/musb/musb_regs.h |  7 
 4 files changed, 113 insertions(+), 20 deletions(-)

-- 
1.8.3.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] dmaengine: qcom_bam_dma: Add descriptor flag APIs

[Vinod Koul]

On Thu, May 15, 2014 at 12:32:06PM -0500, Andy Gross wrote:
> On Fri, May 02, 2014 at 01:08:27PM -0500, Andy Gross wrote:
> > On Fri, May 02, 2014 at 09:58:41PM +0530, Vinod Koul wrote:
> > > On Thu, Apr 17, 2014 at 05:04:02PM -0500, Andy Gross wrote:
> > > > This patch adds APIs that allow for BAM hardware flags to be set per
> > > > descriptor.  Each one of the new flags informs the attached peripheral 
> > > > of a
> > > > special behavior that is required.
> > > > 
> > > > The EOT flag requests that the peripheral assert an end of transaction 
> > > > interrupt
> > > > when that descriptor is complete.  It also results in special signaling 
> > > > protocol
> > > > that is used between the attached peripheral and the core using the DMA
> > > > controller.
> > > DMA_PREP_INTERRUPT ??
> > 
> > I have 3 different IRQs that can be asserted based on the bit I set in the
> > hardware descriptor.  The normal IRQ is the INT bit.  However, in some 
> > cases the
> > peripheral protocol requires the use of the EOT or EOB interrupt instead.  
> > The
> > DMA_PREP_INTERRUPT would only work if I had only 2 choices.
> 
> Thinking about this more, I could use the DMA_PREP_INTERRUPT to cover the EOT
> flag.  However, I might get in a bind later if I need to support the EOB (end 
> of
> block) interrupt.
Sorry for delay in this.

I think it would make sense to use DMA_PREP_INTERRUPT for EOB interrupt. The EOT
should always be enabled for the cases where it is applicable instead of nomral
irq.

That should genrically ocvery your cases, or did we miss anything here
> 
> > 
> > > 
> > > > 
> > > > The NWD flag requests that the peripheral wait until the data has been 
> > > > fully
> > > > processed before signaling an interrupt.
> > > interrupt for transaction complete or DMA request?
> > 
> > This is a special signaling mechanism that holds off the DMA interrupt 
> > until the
> > peripheral actually acks that the data has been processed completely.  This 
> > is
> > required in many cases by the peripheral.  One example is the SPI 
> > controller.
> > At the end of a transaction you are supposed to set the NWD so that the chip
> > select is de-asserted.
> 
> I'm not sure what flag I could map this to... maybe DMA_CTRL_ACK?  or maybe 
> the
> DMA_PREP_FENCE?  I don't generally like overloading the flags and slightly
> twisting their intent.  Could we add a flag to denote device ACK?
Nope lets not override these...

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: dma-mapping: add checking cma area initialized

[Marek Szyprowski]

Hello,

On 2014-05-22 06:38, Gioh Kim wrote:

If CMA is turned on and CMA size is set to zero, kernel should
behave as if CMA was not enabled at compile time.
Every dma allocation should check existence of cma area
before requesting memory.

Signed-off-by: Gioh Kim 
Signed-off-by: Joonsoo Kim 
Acked-by: Michal Nazarewicz 


Thanks for this patch! The initial version was really ugly, but
this one really does what should be there from the begging.

I've applied this patch with redundant empty line add removed.


---
  arch/arm/mm/dma-mapping.c |7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 18e98df..9173a13 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -390,12 +390,13 @@ static int __init atomic_pool_init(void)
if (!pages)
goto no_pages;
  
-	if (IS_ENABLED(CONFIG_DMA_CMA))

+   if (dev_get_cma_area(NULL))
ptr = __alloc_from_contiguous(NULL, pool->size, prot, &page,
  atomic_pool_init);
else
ptr = __alloc_remap_buffer(NULL, pool->size, gfp, prot, &page,
   atomic_pool_init);
+
if (ptr) {
int i;
  
@@ -701,7 +702,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,

addr = __alloc_simple_buffer(dev, size, gfp, &page);
else if (!(gfp & __GFP_WAIT))
addr = __alloc_from_pool(size, &page);
-   else if (!IS_ENABLED(CONFIG_DMA_CMA))
+   else if (!dev_get_cma_area(dev))
addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, 
caller);
else
addr = __alloc_from_contiguous(dev, size, prot, &page, caller);
@@ -790,7 +791,7 @@ static void __arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
__dma_free_buffer(page, size);
} else if (__free_from_pool(cpu_addr, size)) {
return;
-   } else if (!IS_ENABLED(CONFIG_DMA_CMA)) {
+   } else if (!dev_get_cma_area(dev)) {
__dma_free_remap(cpu_addr, size);
__dma_free_buffer(page, size);
} else {


Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [net] WARNING: CPU: 1 PID: 1 at net/batman-adv/hard-interface.c:92 batadv_is_on_batman_iface()

[Cong Wang]

On Wed, May 21, 2014 at 9:42 PM, Jet Chen  wrote:
> Hi Steffen,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
> commit 78ff4be45a4c51d8fb21ad92e4fabb467c6c3eeb
> Author: Steffen Klassert 
> AuthorDate: Mon May 19 11:36:56 2014 +0200
> Commit: David S. Miller 
> CommitDate: Wed May 21 02:08:32 2014 -0400
>
> ip_tunnel: Initialize the fallback device properly
> We need to initialize the fallback device to have a correct mtu
> set on this device. Otherwise the mtu is set to null and the device
> is unusable.
> Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
> Cc: Pravin B Shelar 
> Signed-off-by: Steffen Klassert 
> Signed-off-by: David S. Miller 
>
> ++++
> |
> | d8d33c3b8a | 78ff4be45a |
> ++++
> | boot_successes
> | 60 | 0  |
> | boot_failures
> | 0  | 20 |
> |
> WARNING:CPU:PID:at_net/batman-adv/hard-interface.c:batadv_is_on_batman_iface()
> | 0  | 20 |
> | backtrace:register_netdevice_notifier
> | 0  | 20 |
> | backtrace:batadv_init
> | 0  | 20 |
> | backtrace:kernel_init_freeable
> | 0  | 20 |
> ++++
>

batman needs to fix:

diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index b851cc5..fbda6b5 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -83,7 +83,7 @@ static bool batadv_is_on_batman_iface(const struct
net_device *net_dev)
return true;

/* no more parents..stop recursion */
-   if (net_dev->iflink == net_dev->ifindex)
+   if (net_dev->iflink == 0 || net_dev->iflink == net_dev->ifindex)
return false;

/* recurse over the parent device */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/base/dma-contiguous.c: erratum of dev_get_cma_area

[Marek Szyprowski]

Hello,

On 2014-05-22 06:31, Gioh Kim wrote:

fix erratum get_dev_cma_area into dev_get_cma_area

Signed-off-by: Gioh Kim 
---
  drivers/base/dma-contiguous.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index b056661..6343f25 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -291,7 +291,7 @@ err:
   *
   * This function allocates memory buffer for specified device. It uses
   * device specific contiguous memory area if available or the default
- * global one. Requires architecture specific get_dev_cma_area() helper
+ * global one. Requires architecture specific dev_get_cma_area() helper
   * function.
   */
  struct page *dma_alloc_from_contiguous(struct device *dev, int count,


Thanks for this small fix. I've applied it to my tree.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_drv.h between commit f93e94efebbe ("drm/i915:
Fix dynamic allocation of physical handles") from the drm-intel-fixes
tree and commit 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user
pages into video memory (userptr) ioctl") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_drv.h
index d6dc54aa123a,d2da390b6b9f..
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -1609,9 -1712,21 +1697,21 @@@ struct drm_i915_gem_object 
struct drm_file *pin_filp;
  
/** for phy allocated objects */
 -  struct drm_i915_gem_phys_object *phys_obj;
 +  drm_dma_handle_t *phys_handle;
- };
  
+   union {
+   struct i915_gem_userptr {
+   uintptr_t ptr;
+   unsigned read_only :1;
+   unsigned workers :4;
+ #define I915_GEM_USERPTR_MAX_WORKERS 15
+ 
+   struct mm_struct *mm;
+   struct i915_mmu_object *mn;
+   struct work_struct *work;
+   } userptr;
+   };
+ };
  #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
  
  /**


signature.asc
Description: PGP signature

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_gem_execbuffer.c between commit 4eda4e461109
("drm/i915: Prevent negative relocation deltas from wrapping") from the
drm-intel-fixes tree and commit a8ebba75b358 ("drm/i915: Use the coarse
ping-pong mechanism based on drm fd to dispatch the BSD command on BDW
GT3") from the drm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6651195edcad,47fe8ecef135..
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@@ -1018,25 -1007,37 +1026,56 @@@ i915_reset_gen7_sol_offsets(struct drm_
return 0;
  }
  
 +static struct drm_i915_gem_object *
 +eb_get_batch(struct eb_vmas *eb)
 +{
 +  struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), 
exec_list);
 +
 +  /*
 +   * SNA is doing fancy tricks with compressing batch buffers, which leads
 +   * to negative relocation deltas. Usually that works out ok since the
 +   * relocate address is still positive, except when the batch is placed
 +   * very low in the GTT. Ensure this doesn't happen.
 +   *
 +   * Note that actual hangs have only been observed on gen7, but for
 +   * paranoia do it everywhere.
 +   */
 +  vma->exec_entry->flags |= __EXEC_OBJECT_NEEDS_BIAS;
 +
 +  return vma->obj;
 +}
 +
+ /**
+  * Find one BSD ring to dispatch the corresponding BSD command.
+  * The Ring ID is returned.
+  */
+ static int gen8_dispatch_bsd_ring(struct drm_device *dev,
+ struct drm_file *file)
+ {
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_file_private *file_priv = file->driver_priv;
+ 
+   /* Check whether the file_priv is using one ring */
+   if (file_priv->bsd_ring)
+   return file_priv->bsd_ring->id;
+   else {
+   /* If no, use the ping-pong mechanism to select one ring */
+   int ring_id;
+ 
+   mutex_lock(&dev->struct_mutex);
+   if (dev_priv->ring_index == 0) {
+   ring_id = VCS;
+   dev_priv->ring_index = 1;
+   } else {
+   ring_id = VCS2;
+   dev_priv->ring_index = 0;
+   }
+   file_priv->bsd_ring = &dev_priv->ring[ring_id];
+   mutex_unlock(&dev->struct_mutex);
+   return ring_id;
+   }
+ }
+ 
  static int
  i915_gem_do_execbuffer(struct drm_device *dev, void *data,
   struct drm_file *file,


signature.asc
Description: PGP signature

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit f93e94efebbe ("drm/i915:
Fix dynamic allocation of physical handles") from the drm-intel-fixes
tree and commit c8725f3dc091 ("drm/i915: Do not call retire_requests
from wait_for_rendering") from the drm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem.c
index 3326770c9ed2,e1fa919017e2..
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -43,7 -43,14 +43,9 @@@ static void i915_gem_object_flush_cpu_w
  static __must_check int
  i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
   bool readonly);
+ static void
+ i915_gem_object_retire(struct drm_i915_gem_object *obj);
  
 -static int i915_gem_phys_pwrite(struct drm_device *dev,
 -  struct drm_i915_gem_object *obj,
 -  struct drm_i915_gem_pwrite *args,
 -  struct drm_file *file);
 -
  static void i915_gem_write_fence(struct drm_device *dev, int reg,
 struct drm_i915_gem_object *obj);
  static void i915_gem_object_update_fence(struct drm_i915_gem_object *obj,


signature.asc
Description: PGP signature

[PATCH V3 8/8] cpufreq: exynos5440: don't initialize opp table

[Viresh Kumar]

CPU OPP tables are already initialized by CPU core and we don't need to
reinitialize them from exynos5440's driver.

Cc: Amit Daniel Kachhap 
Cc: Kukjin Kim 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/exynos5440-cpufreq.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/cpufreq/exynos5440-cpufreq.c 
b/drivers/cpufreq/exynos5440-cpufreq.c
index f33f25b..72a4206 100644
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -360,12 +360,6 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
goto err_put_node;
}
 
-   ret = of_init_opp_table(dvfs_info->dev);
-   if (ret) {
-   dev_err(dvfs_info->dev, "failed to init OPP table: %d\n", ret);
-   goto err_put_node;
-   }
-
ret = dev_pm_opp_init_cpufreq_table(dvfs_info->dev,
&dvfs_info->freq_table);
if (ret) {
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 6/8] cpufreq: imx6q: don't initialize opp table

[Viresh Kumar]

CPU OPP tables are already initialized by CPU core and we don't need to
reinitialize them from imx6q specific code.

Acked-by: Shawn Guo 
Signed-off-by: Viresh Kumar 
---
 arch/arm/mach-imx/mach-imx6q.c  | 36 
 drivers/cpufreq/imx6q-cpufreq.c | 20 +---
 2 files changed, 9 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index e60456d..03819e7 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -290,12 +290,18 @@ static void __init imx6q_init_machine(void)
 #define OCOTP_CFG3_SPEED_996MHZ0x2
 #define OCOTP_CFG3_SPEED_852MHZ0x1
 
-static void __init imx6q_opp_check_speed_grading(struct device *cpu_dev)
+static void __init imx6q_opp_check_speed_grading(void)
 {
+   struct device *cpu_dev = get_cpu_device(0);
struct device_node *np;
void __iomem *base;
u32 val;
 
+   if (!cpu_dev) {
+   pr_warn("failed to get cpu0 device\n");
+   return;
+   }
+
np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-ocotp");
if (!np) {
pr_warn("failed to find ocotp node\n");
@@ -336,32 +342,6 @@ put_node:
of_node_put(np);
 }
 
-static void __init imx6q_opp_init(void)
-{
-   struct device_node *np;
-   struct device *cpu_dev = get_cpu_device(0);
-
-   if (!cpu_dev) {
-   pr_warn("failed to get cpu0 device\n");
-   return;
-   }
-   np = of_node_get(cpu_dev->of_node);
-   if (!np) {
-   pr_warn("failed to find cpu0 node\n");
-   return;
-   }
-
-   if (of_init_opp_table(cpu_dev)) {
-   pr_warn("failed to init OPP table\n");
-   goto put_node;
-   }
-
-   imx6q_opp_check_speed_grading(cpu_dev);
-
-put_node:
-   of_node_put(np);
-}
-
 static struct platform_device imx6q_cpufreq_pdev = {
.name = "imx6q-cpufreq",
 };
@@ -376,7 +356,7 @@ static void __init imx6q_init_late(void)
imx6q_cpuidle_init();
 
if (IS_ENABLED(CONFIG_ARM_IMX6Q_CPUFREQ)) {
-   imx6q_opp_init();
+   imx6q_opp_check_speed_grading();
platform_device_register(&imx6q_cpufreq_pdev);
}
 }
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index af366c2..b72e94f 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -190,26 +190,8 @@ static int imx6q_cpufreq_probe(struct platform_device 
*pdev)
goto put_reg;
}
 
-   /*
-* We expect an OPP table supplied by platform.
-* Just, incase the platform did not supply the OPP
-* table, it will try to get it.
-*/
num = dev_pm_opp_get_opp_count(cpu_dev);
-   if (num < 0) {
-   ret = of_init_opp_table(cpu_dev);
-   if (ret < 0) {
-   dev_err(cpu_dev, "failed to init OPP table: %d\n", ret);
-   goto put_reg;
-   }
-
-   num = dev_pm_opp_get_opp_count(cpu_dev);
-   if (num < 0) {
-   ret = num;
-   dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
-   goto put_reg;
-   }
-   }
+   WARN_ON(num < 0);
 
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
if (ret) {
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 7/8] cpufreq: cpufreq-cpu0: don't initialize opp table

[Viresh Kumar]

CPU OPP tables are already initialized by CPU core and we don't need to
reinitialize them from cpufreq-cpu0 driver.

Acked-by: Shawn Guo 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq-cpu0.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 1bf6bba..4301c7c 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -152,12 +152,6 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
goto out_put_node;
}
 
-   ret = of_init_opp_table(cpu_dev);
-   if (ret) {
-   pr_err("failed to init OPP table: %d\n", ret);
-   goto out_put_node;
-   }
-
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
if (ret) {
pr_err("failed to init cpufreq table: %d\n", ret);
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 4/8] driver/core: cpu: initialize opp table

[Viresh Kumar]

Drivers expecting CPU's OPPs from device tree initialize OPP table themselves by
calling of_init_opp_table() and there is nothing driver specific in that. They
all do it in the same redundant way.

It would be better if we can get rid of redundancy by initializing CPU OPPs from
CPU core code for all CPUs (that have a "operating-points" property defined in
their node).

This patch adds another routine in cpu.c: of_init_cpu_opp_table() and calls it
right after CPU device is registered in register_cpu(). A dummy implementation
is also provided to make it lightweight for platforms that don't need it.

Cc: Greg Kroah-Hartman 
Cc: Amit Daniel Kachhap 
Cc: Kukjin Kim 
Cc: Shawn Guo 
Signed-off-by: Viresh Kumar 
---
 drivers/base/cpu.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 006b1bc..818cfe8 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "base.h"
 
@@ -322,6 +323,25 @@ static int cpu_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 }
 #endif
 
+#if defined(CONFIG_PM_OPP) && defined(CONFIG_OF)
+static inline void of_init_cpu_opp_table(struct cpu *cpu)
+{
+   int error;
+
+   /* Initialize CPU's OPP table */
+   error = of_init_opp_table(&cpu->dev);
+   if (!error)
+   dev_dbg(&cpu->dev, "%s: created OPP table for cpu: %d\n",
+   __func__, cpu->dev.id);
+   /* Print error only if there is an issue with OPP table */
+   else if (error != -ENOSYS && error != -ENODEV)
+   dev_err(&cpu->dev, "%s: failed to init OPP table for cpu%d, 
err: %d\n",
+   __func__, cpu->dev.id, error);
+}
+#else
+static inline void of_init_cpu_opp_table(struct cpu *cpu) {}
+#endif
+
 /*
  * register_cpu - Setup a sysfs device for a CPU.
  * @cpu - cpu->hotpluggable field set to 1 will generate a control file in
@@ -349,10 +369,12 @@ int register_cpu(struct cpu *cpu, int num)
if (cpu->hotpluggable)
cpu->dev.groups = hotplugable_cpu_attr_groups;
error = device_register(&cpu->dev);
-   if (!error)
-   per_cpu(cpu_sys_devices, num) = &cpu->dev;
-   if (!error)
-   register_cpu_under_node(num, cpu_to_node(num));
+   if (error)
+   return error;
+
+   per_cpu(cpu_sys_devices, num) = &cpu->dev;
+   register_cpu_under_node(num, cpu_to_node(num));
+   of_init_cpu_opp_table(cpu);
 
return error;
 }
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 5/8] cpufreq: arm_big_little: don't initialize opp table

[Viresh Kumar]

CPU OPP tables are already initialized by CPU core and we don't need to
reinitialize them from arm_big_little_dt driver.

As the arm_big_little_dt driver doesn't have a .init_opp_table() callback
anymore, make this callback optional.

Cc: Sudeep Holla 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/arm_big_little.c| 12 +++-
 drivers/cpufreq/arm_big_little_dt.c | 18 --
 2 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 1f4d4e3..561261e 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -325,11 +325,13 @@ static int _get_cluster_clk_and_freq_table(struct device 
*cpu_dev)
if (freq_table[cluster])
return 0;
 
-   ret = arm_bL_ops->init_opp_table(cpu_dev);
-   if (ret) {
-   dev_err(cpu_dev, "%s: init_opp_table failed, cpu: %d, err: 
%d\n",
+   if (arm_bL_ops->init_opp_table) {
+   ret = arm_bL_ops->init_opp_table(cpu_dev);
+   if (ret) {
+   dev_err(cpu_dev, "%s: init_opp_table failed, cpu: %d, 
err: %d\n",
__func__, cpu_dev->id, ret);
-   goto out;
+   goto out;
+   }
}
 
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table[cluster]);
@@ -542,7 +544,7 @@ int bL_cpufreq_register(struct cpufreq_arm_bL_ops *ops)
return -EBUSY;
}
 
-   if (!ops || !strlen(ops->name) || !ops->init_opp_table) {
+   if (!ops || !strlen(ops->name)) {
pr_err("%s: Invalid arm_bL_ops, exiting\n", __func__);
return -ENODEV;
}
diff --git a/drivers/cpufreq/arm_big_little_dt.c 
b/drivers/cpufreq/arm_big_little_dt.c
index 8d9d591..502182d 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -43,23 +43,6 @@ static struct device_node *get_cpu_node_with_valid_op(int 
cpu)
return np;
 }
 
-static int dt_init_opp_table(struct device *cpu_dev)
-{
-   struct device_node *np;
-   int ret;
-
-   np = of_node_get(cpu_dev->of_node);
-   if (!np) {
-   pr_err("failed to find cpu%d node\n", cpu_dev->id);
-   return -ENOENT;
-   }
-
-   ret = of_init_opp_table(cpu_dev);
-   of_node_put(np);
-
-   return ret;
-}
-
 static int dt_get_transition_latency(struct device *cpu_dev)
 {
struct device_node *np;
@@ -81,7 +64,6 @@ static int dt_get_transition_latency(struct device *cpu_dev)
 static struct cpufreq_arm_bL_ops dt_bL_ops = {
.name   = "dt-bl",
.get_transition_latency = dt_get_transition_latency,
-   .init_opp_table = dt_init_opp_table,
 };
 
 static int generic_bL_probe(struct platform_device *pdev)
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 3/8] opp: call of_node_{get|put}() from of_init_opp_table()

[Viresh Kumar]

All callers of of_init_opp_table() are required to take reference of
dev->of_node, by initiating calls to of_node_{get|put}(), before and after
calling of_init_opp_table().

Its better to call these from within of_init_opp_table(), no fun adding
redundant code to every caller.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index faae9cf..2b615b9 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -622,6 +622,9 @@ int of_init_opp_table(struct device *dev)
const __be32 *val;
int nr;
 
+   if (!of_node_get(dev->of_node))
+   return -ENODEV;
+
prop = of_find_property(dev->of_node, "operating-points", NULL);
if (!prop)
return -ENODEV;
@@ -649,6 +652,7 @@ int of_init_opp_table(struct device *dev)
nr -= 2;
}
 
+   of_node_put(dev->of_node);
return 0;
 }
 EXPORT_SYMBOL_GPL(of_init_opp_table);
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 2/8] opp: of_init_opp_table(): return -ENOSYS when feature isn't implemented

[Viresh Kumar]

When none of CONFIG_PM_OPP or CONFIG_OF is enabled we use the dummy
implementation of of_init_opp_table() routine, which returns -EINVAL currently.
-EINVAL can confuse the callers a bit as it can have other meanings for the
actual implementation of this routine.

It is more appropriate to return -ENOSYS instead to avoid confusion at caller.

Suggested-and-reviewed-by: Sudeep Holla 
Signed-off-by: Viresh Kumar 
---
 include/linux/pm_opp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 0330217..6668150 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -112,7 +112,7 @@ int of_init_opp_table(struct device *dev);
 #else
 static inline int of_init_opp_table(struct device *dev)
 {
-   return -EINVAL;
+   return -ENOSYS;
 }
 #endif
 
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 0/8] CPUFreq: Initialize CPU's OPP tables from CPU core

[Viresh Kumar]

This is third attempt to initialize CPU's OPPs from CPU core code. First two are
here: https://lkml.org/lkml/2014/5/19/57 and https://lkml.org/lkml/2014/5/21/199

Drivers expecting CPU's OPPs from device tree initialize OPP table themselves by
calling of_init_opp_table() and there is nothing driver specific in that. They
all do it in the same redundant way.

It would be better if we can get rid of redundancy by initializing CPU OPPs from
CPU core code for all CPUs (that have a "operating-points" property defined in
their node).

This patchset is all about that.

The idea was initially discussed here: https://lkml.org/lkml/2014/5/17/123

V2->V3:
- s/dev_info/dev_dbg
- Fixed changelogs

V1->V2:
- Addition of two new patches: 1/2 & 2/2
- Created separate routine of_init_cpu_opp_table() which wouldn't add any
  overhead for the platforms which don't have OPP or OF enabled.
- Added a print for success case as well
- Added Acks from Shawn
- Got rid of extra indentation level by returning early from register_cpu().

Cc: Greg Kroah-Hartman 
Cc: Amit Daniel Kachhap 
Cc: Kukjin Kim 
Cc: Shawn Guo 

Viresh Kumar (8):
  cpufreq: cpufreq-cpu0: remove dependency on thermal
  opp: of_init_opp_table(): return -ENOSYS when feature isn't
implemented
  opp: call of_node_{get|put}() from of_init_opp_table()
  driver/core: cpu: initialize opp table
  cpufreq: arm_big_little: don't initialize opp table
  cpufreq: imx6q: don't initialize opp table
  cpufreq: cpufreq-cpu0: don't initialize opp table
  cpufreq: exynos5440: don't initialize opp table

 arch/arm/mach-imx/mach-imx6q.c   | 36 
 drivers/base/cpu.c   | 30 ++
 drivers/base/power/opp.c |  4 
 drivers/cpufreq/Kconfig  |  2 +-
 drivers/cpufreq/arm_big_little.c | 12 +++-
 drivers/cpufreq/arm_big_little_dt.c  | 18 --
 drivers/cpufreq/cpufreq-cpu0.c   |  6 --
 drivers/cpufreq/exynos5440-cpufreq.c |  6 --
 drivers/cpufreq/imx6q-cpufreq.c  | 20 +---
 include/linux/pm_opp.h   |  2 +-
 10 files changed, 48 insertions(+), 88 deletions(-)

-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 1/8] cpufreq: cpufreq-cpu0: remove dependency on thermal

[Viresh Kumar]

cpufreq-cpu0 uses thermal framework to register a cooling device, but doesn't
depend on it as there are dummy calls provided by thermal layer when
CONFIG_THERMAL=n. So, we don't really need to mention thermal as a dependency
for cpufreq-cpu0 in Kconfig.

Remove it.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 1fbe11f..4310997 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -185,7 +185,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
 
 config GENERIC_CPUFREQ_CPU0
tristate "Generic CPU0 cpufreq driver"
-   depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
+   depends on HAVE_CLK && REGULATOR && OF
select PM_OPP
help
  This adds a generic cpufreq driver for CPU0 frequency management.
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i8k: increase fan limit to 3

[Guenter Roeck]

On 05/21/2014 08:45 PM, Flavio Leitner wrote:

On Wed, May 21, 2014 at 08:32:24PM -0700, Guenter Roeck wrote:

On 05/21/2014 07:19 PM, Flavio Leitner wrote:

From: Flavio Leitner 

It is possible to increase left fan speed on a
DELL Precision 490n system up to 3.

 valuefan rpm
   1  35460
   2  64740
   3  78510


Guess the speed factor 30 doesn't apply here.


Those are actual rpms, not just a multiplied rpm. What I mean
is that you can hear the fan spinning up or down and the
temperature going up or down accordingly.


I don't think there are any fans running at 78k rpm. The real speed
is 78,510 / 30 or 2,617 rpm. You should set the fan_mult module
parameter to 1 for your system.


But even setting it to 3 is not enough to spin at maximum
speed. Anyway, now I can load the system without the FBDIMM
going above 75oC.


Did you try to set higher values ?

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: non-atomically mark page accessed during page cache allocation where possible -fix

[Prabhakar Lad]

On Wed, May 21, 2014 at 1:04 AM, Andrew Morton
 wrote:
> On Tue, 20 May 2014 16:49:00 +0100 Mel Gorman  wrote:
>
>> Prabhakar Lad reported the following problem
>>
>>   I see following issue on DA850 evm,
>>   git bisect points me to
>>   commit id: 975c3a671f11279441006a29a19f55ccc15fb320
>>   ( mm: non-atomically mark page accessed during page cache allocation
>>   where possible)
>>
>>   Unable to handle kernel paging request at virtual address 30e03501
>>   pgd = c68cc000
>>   [30e03501] *pgd=
>>   Internal error: Oops: 1 [#1] PREEMPT ARM
>>   Modules linked in:
>>   CPU: 0 PID: 1015 Comm: network.sh Not tainted 3.15.0-rc5-00323-g975c3a6 #9
>>   task: c70c4e00 ti: c73d task.ti: c73d
>>   PC is at init_page_accessed+0xc/0x24
>>   LR is at shmem_write_begin+0x54/0x60
>>   pc : []lr : []psr: 2013
>>   sp : c73d1d90  ip : c73d1da0  fp : c73d1d9c
>>   r10: c73d1dec  r9 :   r8 : 
>>   r7 : c73d1e6c  r6 : c694d7bc  r5 : ffe4  r4 : c73d1dec
>>   r3 : c73d  r2 : 0001  r1 :   r0 : 30e03501
>>   Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
>>   Control: 0005317f  Table: c68cc000  DAC: 0015
>>   Process network.sh (pid: 1015, stack limit = 0xc73d01c0)
>>
>> pagep is set but not pointing to anywhere valid as it's an uninitialised
>> stack variable. This patch is a fix to
>> mm-non-atomically-mark-page-accessed-during-page-cache-allocation-where-possible.patch
>>
>> ...
>>
>> --- a/mm/filemap.c
>> +++ b/mm/filemap.c
>> @@ -2459,7 +2459,7 @@ ssize_t generic_perform_write(struct file *file,
>>   flags |= AOP_FLAG_UNINTERRUPTIBLE;
>>
>>   do {
>> - struct page *page;
>> + struct page *page = NULL;
>>   unsigned long offset;   /* Offset into pagecache page */
>>   unsigned long bytes;/* Bytes to write to page */
>>   size_t copied;  /* Bytes copied from user */
>
> Well not really.  generic_perform_write() only touches *page if
> ->write_begin() returned "success", which is reasonable behavior.
>
> I'd say you mucked up shmem_write_begin() - it runs
> init_page_accessed() even if shmem_getpage() returned an error.  It
> shouldn't be doing that.
>
> This?
>
> From: Andrew Morton 
> Subject: mm/shmem.c: don't run init_page_accessed() against an uninitialised 
> pointer
>
> If shmem_getpage() returned an error then it didn't necessarily initialise
> *pagep.  So shmem_write_begin() shouldn't be playing with *pagep in this
> situation.
>
> Fixes an oops when "mm: non-atomically mark page accessed during page
> cache allocation where possible" (quite reasonably) left *pagep
> uninitialized.
>
> Reported-by: Prabhakar Lad 
> Cc: Johannes Weiner 
> Cc: Vlastimil Babka 
> Cc: Jan Kara 
> Cc: Michal Hocko 
> Cc: Hugh Dickins 
> Cc: Peter Zijlstra 
> Cc: Dave Hansen 
> Cc: Mel Gorman 
> Signed-off-by: Andrew Morton 
> ---
>
>  mm/shmem.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN 
> mm/shmem.c~mm-non-atomically-mark-page-accessed-during-page-cache-allocation-where-possiblefix-2
>  mm/shmem.c
> --- 
> a/mm/shmem.c~mm-non-atomically-mark-page-accessed-during-page-cache-allocation-where-possiblefix-2
> +++ a/mm/shmem.c
> @@ -1376,7 +1376,7 @@ shmem_write_begin(struct file *file, str
> struct inode *inode = mapping->host;
> pgoff_t index = pos >> PAGE_CACHE_SHIFT;
> ret = shmem_getpage(inode, index, pagep, SGP_WRITE, NULL);
> -   if (*pagep)
> +   if (ret == 0 && *pagep)
> init_page_accessed(*pagep);
> return ret;
>  }

Reported-and-Tested-by: Lad, Prabhakar 

Regards,
--Prabhakar Lad

> _
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: sched: spinlock recursion in migrate_swap_stop

[Srikar Dronamraju]

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 927fa33..b5e11c7 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1154,6 +1156,7 @@ int migrate_swap(struct task_struct *cur, struct 
> task_struct *p)
> goto out;
>
> trace_sched_swap_numa(cur, arg.src_cpu, p, arg.dst_cpu);
> +   BUG_ON(cur == p);

I am not sure how this check can ever be successful because at the start
of this function migrate_swap() we have

  if (arg.src_cpu == arg.dst_cpu)
  goto out;


if cur is actually p; then should the above condition should always be
successul right?

Or am I missing something?

> ret = stop_two_cpus(arg.dst_cpu, arg.src_cpu, migrate_swap_stop, 
> &arg);
>
>  out:
>
>
> Which seems to get hit. This sounds like a race with task moving to
> other cpu maybe?
>

--
Thanks and Regards
Srikar Dronamraju

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: /prom/pid/clear_refs: avoid split_huge_page()

[Cyrill Gorcunov]

On Thu, May 22, 2014 at 04:11:10AM +0300, Kirill A. Shutemov wrote:
> Andrew Morton wrote:
> > On Wed, 21 May 2014 22:04:22 +0300 "Kirill A. Shutemov" 
> >  wrote:
> > 
> > > Currently we split all THP pages on any clear_refs request. It's not
> > > necessary. We can handle this on PMD level.
> > > 
> > > One side effect is that soft dirty will potentially see more dirty
> > > memory, since we will mark whole THP page dirty at once.
> > 
> > This clashes pretty badly with
> > http://ozlabs.org/~akpm/mmots/broken-out/clear_refs-redefine-callback-functions-for-page-table-walker.patch
> 
> Hm.. For some reason CRIU memory-snapshotting test cases fail on current
> linux-next. I didn't debug why. Mainline works. Folks?

Thanks for noticing, Kirill! I don't test linux-test regulary will try and
report the results.

Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the l2-mtd tree

[Stephen Rothwell]

Hi Artem,

After merging the l2-mtd tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/mtd/lpddr/lpddr2_nvm.c: In function 'ow_enable':
drivers/mtd/lpddr/lpddr2_nvm.c:149:2: error: implicit declaration of function 
'writel_relaxed' [-Werror=implicit-function-declaration]
  writel_relaxed(build_mr_cfgmask(pcm_data->bus_width) | 0x18,
  ^

Caused by commit 96ba9dd65788 ("mtd: lpddr: add driver for LPDDR2-NVM
PCM memories").

I have used the l2-mtd tree from next-20140521 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [patch 3/3] timerfd: Implement write method

[Cyrill Gorcunov]

On Thu, May 22, 2014 at 08:30:04AM +0900, Thomas Gleixner wrote:
> > 
> > > So what's the semantics of that write function? We really want to have
> > > that agreed on and documented in the man page.
> > 
> > The idea was to provide a way to setup @ticks into (nonzero) value
> > which we get from show_fdinfo output. Then when we restore it
> > we setup the timer and set @ticks to the value it had at dump
> > moment.
> 
> That's not describing the semantics. It's describing what you use it
> for.

That's I've been intending to use it for and as result the semantic
was to write unconditionally. But because I missed polling in first
place now I think such semantic is wrong and write() should be
a complete counterpart of read() method and wake up waiters.

> > > Right now the write will just update the ticks and nothing else. So
> > > what if there is a waiter already? What if there is a timer armed?
> > > 
> > > Can you please describe how checkpoint/restore is going to use all of
> > > this. How is the timer restored and how/when is the reader which was
> > > waiting in read/poll at the time of suspend reattached to it.
> > 
> > Thomas, I see what you mean. Need to think (I must admit I forgot about
> > polling of timerfds :( I were to restore timerfds like this
> > 
> >  - fetch data from fdinfo
> >  - use timer_create/settime to arm it
> >  - write @ticks then
> 
> That's clear to me.
> 
> So again you have to answer the questions:
> 
>Do we just allow the write unconditionally?
>Do we care about waking readers/pollers?
>  
> Whatever the answer is, it needs to be documented coherently in the
> changelog, in the code and in the man page.

"Yes" to both questions I think. Thomas I'll return with a new patchset,
testcase and man update.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets

[Michael Ellerman]

On Tue, 2014-05-13 at 18:21 +0100, Pedro Alves wrote:
> I wonder whether people are getting Roland's address from?
> 
> It's frequent that ptrace related patches end up CCed to
> rol...@redhat.com, but, he's not been at Red Hat for a few years
> now.  Roland, do you still want to be CCed on ptrace-related
> issues?  If so, there's probably a script somewhere in the
> kernel that needs updating.  If not, well, it'd be good
> if it were updated anyway.  :-)

In MAINTAINERS I see:

PTRACE SUPPORT
M:  Roland McGrath 
M:  Oleg Nesterov 
S:  Maintained


cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] clk: samsung: Add driver to control CLKOUT line on Exynos SoCs

[Tushar Behera]

On 05/20/2014 10:13 PM, Tomasz Figa wrote:
> This patch introduces a driver that handles configuration of CLKOUT pin
> of Exynos SoCs that can be used to output certain clocks from inside of
> the SoC to a dedicated output pin.
> 
> Signed-off-by: Tomasz Figa 
> ---
>  .../devicetree/bindings/arm/samsung/pmu.txt|  30 
>  drivers/clk/samsung/Makefile   |   1 +
>  drivers/clk/samsung/clk-exynos-clkout.c| 153 
> +
>  3 files changed, 184 insertions(+)
>  create mode 100644 drivers/clk/samsung/clk-exynos-clkout.c
> 

[ ... ]

> + clkout->clk_table[0] = clk_register_composite(NULL, "clkout",
> + parent_names, parent_count, &clkout->mux.hw,
> + &clk_mux_ops, NULL, NULL, &clkout->gate.hw,
> + &clk_gate_ops, CLK_SET_RATE_PARENT
> + | CLK_SET_RATE_NO_REPARENT);

Would you please remove CLK_SET_RATE_NO_REPARENT flag from here? Let me
know if you have reservations against this.

With RFC patches, I am able to do a clk_set_rate() on this clock to
get a 24MHz output to the codec clock. With this flag set, I again have
to rely on the default value set to this register in bootloader.

-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets

[Anshuman Khandual]

On 05/20/2014 04:03 PM, Pedro Alves wrote:
> On 05/20/2014 09:14 AM, Anshuman Khandual wrote:
>> On 05/19/2014 08:13 PM, Pedro Alves wrote:
>>> On 05/19/2014 12:46 PM, Anshuman Khandual wrote:
>>>
>> I couldn't actually find any arch that currently returns -ENODEV in
>> the "active" hook.  I see that binfmt_elf.c doesn't handle
>> regset->active() returning < 0.  Guess that may be why.  Looks like
>> something that could be cleaned up, to me.
>>
 Also it does not consider the return value of regset->active(t->task, 
 regset)
 (whose objective is to figure out whether we need to request regset->n 
 number
 of elements or less than that) in the subsequent call to regset->get 
 function.
>>>
>>> Indeed.
>>>
>>> TBC, do you plan on fixing this?  Otherwise ...
>>
>> Sure, thinking something like this as mentioned below. But still not sure 
>> how to use
>> the return type of -ENODEV from the function regset->active(). Right now if 
>> any
>> regset does have the active hook and it returns anything but positive value, 
>> it will
>> be ignored and the control moves to the next regset in view. This prevents 
>> the thread
>> core note type being written to the core dump.
> 
> Looks to me that that's exactly what should happen for -ENODEV too.  The 
> regset
> should be ignored.  If regset->active() returns -ENODEV, then the machine
> doesn't have the registers at all, so what makes sense to me is to not write 
> the
> corresponding core note in the dump.  IOW, on such a machine, the kernel
> generates a core exactly like if the support for these registers that don't
> make sense for this machine wasn't compiled in at all.  And generates a core
> exactly like an older kernel that didn't know about that regset
> (which is fine for that same machine) yet.
> 

All of this happen right now even without specifically checking for the return 
type
of -ENODEV and just checking for a positive value. I guess thats the reason 
they had
omitted -ENODEV in the first place. 

 
>>
>> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
>> index aa3cb62..80672fb 100644
>> --- a/fs/binfmt_elf.c
>> +++ b/fs/binfmt_elf.c
>> @@ -1553,7 +1553,15 @@ static int fill_thread_core_info(struct 
>> elf_thread_core_info *t,
>> if (regset->core_note_type && regset->get &&
>> (!regset->active || regset->active(t->task, regset))) {
>> int ret;
> 
> So, here, this ?
> 
> (!regset->active || regset->active(t->task, regset) > 0)) 
> {
> 
> 
>> -   size_t size = regset->n * regset->size;
>> +   size_t size;
>> +
>> +   /* Request only the active elements in the regset */
>> +   if (!regset->active)
>> +   size = regset->n * regset->size;
>> +   else
>> +   size = regset->active(t->task, regset)
>> +   * 
>> regset->size;
>> +
> 
> 
> I wonder if it wouldn't be cleaner to add a function like:
> 
> int
> regset_active (tast *task, regseg *regset)
> {
>if (!regset->active)
> return regset->n * regset->size;
>else
> return regset->active(task, regset);
> }
> 
> And then use it like
> 
>if (regset->core_note_type && regset->get) {
>int size = regset_active (t->task, regset);
> 
>if (size > 0) {
>   ...
>}
> 

Yeah this makes sense.

> Though at this point, we don't actually make use of
> the distinction between -ENODEV vs 0.  Guess that's what
> we should be thinking about.  Seems like there some details that
> need to be sorted out, and some verification that consumers aren't
> broken by outputting smaller notes -- e.g., ia64 makes me
> wonder that.

I agree.

> 
> Maybe we should leave this for another day, and have tm_spr_active
> return 0 instead of -ENODEV when the machine doesn't have the hardware,
> or not install that hook at all.  Seems like the effect will be the same,
> as the note isn't output if ->get fails.

Agree. Active hooks which return 0 in case of -ENODEV sounds good to me and 
shall
incorporate this in the next version.

> 
>> void *data = kmalloc(size, GFP_KERNEL);
>> if (unlikely(!data))
>> return 0;
>>
>>>
 Now coming to the installation of the .active hooks part for all the new 
 regsets, it
 should be pretty straight forward as well. Though its optional and used 
 for elf_core_dump
 purpose only, its worth adding them here. Example of an active function 
 should be something
 like this. The function is inexpensive as required.

 +static int tm_spr_active(struct task_struct *target,
 +   const struct user_regset *regset)
 +{
 

[PATCH V6] PM/OPP: discard duplicate OPPs

[Viresh Kumar]

From: Chander Kashyap 

We don't have any protection against addition of duplicate OPPs currently and in
case some code tries to add them, it will end up corrupting OPP tables.

We need to handle some duplication cases separately as returning error might not
be the right thing always. The new list of return values for dev_pm_opp_add()
are:

0:  On success OR
Duplicate OPPs (both freq and volt are same) and opp->available
-EEXIST:Freq are same and volt are different OR
Duplicate OPPs (both freq and volt are same) and !opp->available
-ENOMEM:Memory allocation failure

Acked-by: Nishanth Menon 
Signed-off-by: Chander Kashyap 
Signed-off-by: Inderpal Singh 
Signed-off-by: Viresh Kumar 
---
I took some rest before sending V6, just to make sure I don't send another
version in hurry with any obvious mistake.

V5->V6:
- Remove parenthesis around initialization of 'ret'.
- s/Returns/Return
- Fix checkpatch.pl --strict warning: 'Alignment should match open parenthesis'
- Tried improving changelog..

 drivers/base/power/opp.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index faae9cf..89ced95 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -393,6 +393,13 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
  * to keep the integrity of the internal data structures. Callers should ensure
  * that this function is *NOT* called under RCU protection or in contexts where
  * mutex cannot be locked.
+ *
+ * Return:
+ * 0:  On success OR
+ * Duplicate OPPs (both freq and volt are same) and opp->available
+ * -EEXIST:Freq are same and volt are different OR
+ * Duplicate OPPs (both freq and volt are same) and !opp->available
+ * -ENOMEM:Memory allocation failure
  */
 int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long 
u_volt)
 {
@@ -442,15 +449,31 @@ int dev_pm_opp_add(struct device *dev, unsigned long 
freq, unsigned long u_volt)
new_opp->u_volt = u_volt;
new_opp->available = true;
 
-   /* Insert new OPP in order of increasing frequency */
+   /*
+* Insert new OPP in order of increasing frequency
+* and discard if already present
+*/
head = &dev_opp->opp_list;
list_for_each_entry_rcu(opp, &dev_opp->opp_list, node) {
-   if (new_opp->rate < opp->rate)
+   if (new_opp->rate <= opp->rate)
break;
else
head = &opp->node;
}
 
+   /* Duplicate OPPs ? */
+   if (new_opp->rate == opp->rate) {
+   int ret = opp->available && new_opp->u_volt == opp->u_volt ?
+   0 : -EEXIST;
+
+   dev_warn(dev, "%s: duplicate OPPs detected. Existing: freq: 
%lu, volt: %lu, enabled: %d. New: freq: %lu, volt: %lu, enabled: %d\n",
+__func__, opp->rate, opp->u_volt, opp->available,
+new_opp->rate, new_opp->u_volt, new_opp->available);
+   mutex_unlock(&dev_opp_list_lock);
+   kfree(new_opp);
+   return ret;
+   }
+
list_add_rcu(&new_opp->node, head);
mutex_unlock(&dev_opp_list_lock);
 
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [x86, vdso] cfda7bb9ecb: +14.7% will-it-scale.per_thread_ops

[H. Peter Anvin]

On 05/21/2014 06:54 PM, Fengguang Wu wrote:
>>>
>>> test case: nhm4/will-it-scale/sched_yield
>>>
>>> 3d7ee969bffcc98  cfda7bb9ecbf9d96264bb5bad
>>> ---  -
>>> 5497021 ~ 0% +14.7%6303424 ~ 0%  TOTAL
>>> will-it-scale.per_thread_ops
>>>0.54 ~ 0%  +5.6%   0.57 ~ 0%  TOTAL will-it-scale.scalability
>>> 6209483 ~ 0%  +1.6%6305917 ~ 0%  TOTAL
>>> will-it-scale.per_process_ops
>>>2455 ~ 5% +16.9%   2870 ~ 5%  TOTAL cpuidle.C1-NHM.usage
>>>8829 ~ 7% +15.2%  10169 ~10%  TOTAL
>>> slabinfo.kmalloc-64.active_objs
>>>   24.13 ~12% +48.9%  35.93 ~14%  TOTAL time.user_time
>>> 393 ~ 0%  -3.0%382 ~ 1%  TOTAL time.system_time
>>>
>>
>> Is this a speedup or a slowdown?
> 
> It's a speedup. The will-it-scale/sched_yield test case's throughput
> increased by +14.7% (multi-thread case) and +1.6% (multi-process case).
> 
> However the CPU %user time increased more, by +48.9%.
> 

That would be consistent with spending less time in the kernel, no?

But I agree... that is completely bizarre.  That checkin should have
absolutely zero effect on performance.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] gpio: Add support for Intel SoC PMIC (Crystal Cove)

[Zhu, Lejun]

Devices based on Intel SoC products such as Baytrail have a Power
Management IC. In the PMIC there are subsystems for voltage regulation,
A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
Crystal Cove.

This patch adds support for the GPIO function in Crystal Cove.

v2:
- Use IRQ chip helper to provide irqdomain.
- Implement .remove and can now build as a module.
- Various fix for unreadable or ugly code pieces.
v3:
- More fix in irq_handler and probe.

Signed-off-by: Yang, Bin 
Signed-off-by: Zhu, Lejun 
---
 drivers/gpio/Kconfig|  13 ++
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-crystalcove.c | 347 
 3 files changed, 361 insertions(+)
 create mode 100644 drivers/gpio/gpio-crystalcove.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index a86c49a..fed08d9d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -440,6 +440,19 @@ config GPIO_ARIZONA
help
  Support for GPIOs on Wolfson Arizona class devices.
 
+config GPIO_CRYSTAL_COVE
+   tristate "GPIO support for Crystal Cove PMIC"
+   depends on INTEL_SOC_PMIC
+   select GPIOLIB_IRQCHIP
+   help
+ Support for GPIO pins on Crystal Cove PMIC.
+
+ Say Yes if you have a Intel SoC based tablet with Crystal Cove PMIC
+ inside.
+
+ This driver can also be built as a module. If so, the module will be
+ called gpio-crystalcove.
+
 config GPIO_LP3943
tristate "TI/National Semiconductor LP3943 GPIO expander"
depends on MFD_LP3943
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 6309aff..e6cd935 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_GPIO_BCM_KONA)   += gpio-bcm-kona.o
 obj-$(CONFIG_GPIO_BT8XX)   += gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
 obj-$(CONFIG_GPIO_CS5535)  += gpio-cs5535.o
+obj-$(CONFIG_GPIO_CRYSTAL_COVE)+= gpio-crystalcove.o
 obj-$(CONFIG_GPIO_DA9052)  += gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)  += gpio-da9055.o
 obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
new file mode 100644
index 000..ea6ae1d
--- /dev/null
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -0,0 +1,347 @@
+/*
+ * gpio-crystalcove.c - Intel Crystal Cove GPIO Driver
+ *
+ * Copyright (C) 2012, 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Author: Yang, Bin 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUM_GPIO   16
+
+#define UPDATE_TYPEBIT(0)
+#define UPDATE_MASKBIT(1)
+
+#define GPIO0IRQ   0x0b
+#define GPIO1IRQ   0x0c
+#define MGPIO0IRQS00x19
+#define MGPIO1IRQS00x1a
+#define MGPIO0IRQSX0x1b
+#define MGPIO1IRQSX0x1c
+#define GPIO0P0CTLO0x2b
+#define GPIO0P0CTLI0x33
+#define GPIO1P0CTLO0x3b
+#define GPIO1P0CTLI0x43
+
+#define CTLI_INTCNT_NE (1 << 1)
+#define CTLI_INTCNT_PE (2 << 1)
+#define CTLI_INTCNT_BE (3 << 1)
+
+#define CTLO_DIR_OUT   (1 << 5)
+
+#define CTLO_DRV_CMOS  (0 << 4)
+#define CTLO_DRV_OD(1 << 4)
+
+#define CTLO_DRV_REN   (1 << 3)
+
+#define CTLO_RVAL_2KDW (0)
+#define CTLO_RVAL_2KUP (1 << 1)
+#define CTLO_RVAL_50KDW(2 << 1)
+#define CTLO_RVAL_50KUP(3 << 1)
+
+#define CTLO_INPUT_DEF (CTLO_DRV_CMOS | CTLO_DRV_REN | CTLO_RVAL_2KUP)
+#define CTLO_OUTPUT_DEF(CTLO_DIR_OUT | CTLO_INPUT_DEF)
+
+#define GPIO_TO_CTL(gpio, dir) \
+   ((gpio < 8 ? GPIO0P0CTL ## dir : GPIO1P0CTL ## dir) + (gpio % 8))
+
+/**
+ * struct crystalcove_gpio - Crystal Cove GPIO controller
+ * @buslock: for bus lock/sync and unlock.
+ * @chip: the abstract gpio_chip structure.
+ * @update: pending IRQ setting update, to be written to the chip upon unlock.
+ * @trigger_type: the trigger type of the IRQ.
+ * @set_irq_mask: true if the IRQ mask needs to be set, false to clear.
+ */
+struct crystalcove_gpio {
+   struct mutexbuslock; /* irq_bus_lock */
+   struct gpio_chipchip;
+   int update;
+   int trigger_type;
+   boolset_irq_mask;
+};
+
+static void crystalcove_update_irq_mask(in

Re: [PATCH 1/4] clocksource: em_sti: remove unnecessary OOM messages

[Jingoo Han]

On Monday, May 19, 2014 7:48 PM, Daniel Lezcano wrote:
> On 04/29/2014 10:26 AM, Jingoo Han wrote:
> > The site-specific OOM messages are unnecessary, because they
> > duplicate the MM subsystem generic OOM message.
> 
> Are you sure the MM subsys display a message when an allocation fails ?
> 
> There are multiple reasons an allocation can fail.

(+cc Viresh Kumar, Laurent Pinchart, Dan Carpenter, Joe Perches,
   Thierry Reding, Andrew Morton)

There was a discussion about this in other threads. [1]
Please refer to the following link. Thank you.

[1] http://patchwork.ozlabs.org/patch/324158/

Best regards,
Jingoo Han

> 
> > Signed-off-by: Jingoo Han 
> > ---
> >   drivers/clocksource/em_sti.c |4 +---
> >   1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
> > index 9d17083..d0a7bd6 100644
> > --- a/drivers/clocksource/em_sti.c
> > +++ b/drivers/clocksource/em_sti.c
> > @@ -318,10 +318,8 @@ static int em_sti_probe(struct platform_device *pdev)
> > int irq;
> >
> > p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
> > -   if (p == NULL) {
> > -   dev_err(&pdev->dev, "failed to allocate driver data\n");
> > +   if (p == NULL)
> > return -ENOMEM;
> > -   }
> >
> > p->pdev = pdev;
> > platform_set_drvdata(pdev, 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/

[PATCH] arm: dma-mapping: add checking cma area initialized

[Gioh Kim]

If CMA is turned on and CMA size is set to zero, kernel should
behave as if CMA was not enabled at compile time.
Every dma allocation should check existence of cma area
before requesting memory.

Signed-off-by: Gioh Kim 
Signed-off-by: Joonsoo Kim 
Acked-by: Michal Nazarewicz 
---
 arch/arm/mm/dma-mapping.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 18e98df..9173a13 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -390,12 +390,13 @@ static int __init atomic_pool_init(void)
if (!pages)
goto no_pages;
 
-   if (IS_ENABLED(CONFIG_DMA_CMA))
+   if (dev_get_cma_area(NULL))
ptr = __alloc_from_contiguous(NULL, pool->size, prot, &page,
  atomic_pool_init);
else
ptr = __alloc_remap_buffer(NULL, pool->size, gfp, prot, &page,
   atomic_pool_init);
+
if (ptr) {
int i;
 
@@ -701,7 +702,7 @@ static void *__dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
addr = __alloc_simple_buffer(dev, size, gfp, &page);
else if (!(gfp & __GFP_WAIT))
addr = __alloc_from_pool(size, &page);
-   else if (!IS_ENABLED(CONFIG_DMA_CMA))
+   else if (!dev_get_cma_area(dev))
addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, 
caller);
else
addr = __alloc_from_contiguous(dev, size, prot, &page, caller);
@@ -790,7 +791,7 @@ static void __arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
__dma_free_buffer(page, size);
} else if (__free_from_pool(cpu_addr, size)) {
return;
-   } else if (!IS_ENABLED(CONFIG_DMA_CMA)) {
+   } else if (!dev_get_cma_area(dev)) {
__dma_free_remap(cpu_addr, size);
__dma_free_buffer(page, size);
} else {
-- 
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/

[OMAP-Serial] omap ttyO2 problem

[Varka Bhadram]

hi,

I am using the kernel 3.12 from beagleboard. I loaded the overlay to enable
the ttyO2 on BBB.

echo BB-UART1 > /sys/devices/bone_capemgr.*/slots

It created the ttyO2 device node in /dev.

in dmesg :
[   76.077679] bone-capemgr bone_capemgr.6: part_number 'BB-UART1', version
'N/A'
[   76.077761] bone-capemgr bone_capemgr.6: slot #7: generic override
[   76.077789] bone-capemgr bone_capemgr.6: bone: Using override eeprom data
at slot 7
[   76.077818] bone-capemgr bone_capemgr.6: slot #7: 'Override Board
Name,00A0,Override Manuf,BB-UART1'
[   76.078444] bone-capemgr bone_capemgr.6: slot #7: Requesting part
number/version based 'BB-UART1-00A0.dtbo
[   76.078479] bone-capemgr bone_capemgr.6: slot #7: Requesting firmware
'BB-UART1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[   76.086769] bone-capemgr bone_capemgr.6: slot #7: dtbo
'BB-UART1-00A0.dtbo' loaded; converting to live tree
[   76.087041] bone-capemgr bone_capemgr.6: slot #7: #2 overlays
[   76.116716] of_get_named_gpio_flags: can't parse gpios property of node
'/ocp/serial@48024000[0]'
[   76.140196] *omap_uart 48024000.serial:
serial_omap_get_context_loss_count failed : -22*
[   76.140323] omap_uart 48024000.serial: serial_omap_type+2
[   76.140347] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90,
base_baud = 300) is a OMAP UART2
[   76.140368] omap_uart 48024000.serial: serial_omap_pm+2
[   76.140394] omap_uart 48024000.serial: serial_omap_set_mctrl+2
[   76.140415] omap_uart 48024000.serial: serial_omap_pm+2
[   76.143291] bone-capemgr bone_capemgr.6: slot #7: Applied #2 overlays.


How can i test the this UART working ?

I write a simple code to open("/dev/ttyO2",O_RDWR), and writes "hello", But
i am not getting the data on TX pin (P9.24) of BBB.

Am i missing any thing ?


Thanks in advance...

Reagrds,
Varka Bhadram. 



--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/OMAP-Serial-omap-ttyO2-problem-tp865529.html
Sent from the Linux Kernel mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] ARM: dts: exynos: Update PMU node with CLKOUT related data

[Tushar Behera]

On 05/20/2014 10:13 PM, Tomasz Figa wrote:

[...]

> diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
> b/arch/arm/boot/dts/exynos4210.dtsi
> index ee3001f..b7956cc 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -31,6 +31,15 @@
>   pinctrl2 = &pinctrl_2;
>   };
>  
> + pmu_system_controller: system-controller@1002 {

#clock-cells = <1>;

> + clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
> + "clkout4", "clkout8", "clkout9";
> + clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
> + <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
> + <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
> + <&clock CLK_XUSBXTI>;
> + };
> +
>   sysram@0202 {
>   compatible = "mmio-sram";
>   reg = <0x0202 0x2>;
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 264a28f..d9651fa 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -139,6 +139,12 @@
>  
>   pmu_system_controller: system-controller@1002 {
>   compatible = "samsung,exynos4212-pmu", "syscon";

#clock-cells = <1>;

> + clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
> + "clkout4", "clkout5", "clkout8", "clkout9";
> + clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
> + <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
> + <&clock CLK_OUT_CPU>, <&clock CLK_OUT_ISP>,
> + <&clock CLK_XXTI>, <&clock CLK_XUSBXTI>;
>   };
>  
>   g2d@1080 {
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 68a3e6f..cb939ef 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -191,6 +191,9 @@
>   pmu_system_controller: system-controller@1004 {
>   compatible = "samsung,exynos5250-pmu", "syscon";
>   reg = <0x1004 0x5000>;
> + #clock-cells = <0>;

#clock-cells = <1>;

> + clock-names = "clkout16";
> + clocks = <&clock CLK_FIN_PLL>;
>   };
>  
>   watchdog@101D {
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 8e7e35c..23d0ebb 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -723,6 +723,9 @@
>   pmu_system_controller: system-controller@1004 {
>   compatible = "samsung,exynos5420-pmu", "syscon";
>   reg = <0x1004 0x5000>;
> + #clock-cells = <0>;

#clock-cells = <1>;

> + clock-names = "clkout16";
> + clocks = <&clock CLK_FIN_PLL>;
>   };
>  
>   tmu_cpu0: tmu@1006 {
> 


-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] I found an errataum at drivers/base/dma-contiguous.c:294

[Gioh Kim]

Thanks your advice.
I'll send a patch soon.


2014-05-22 오전 11:54, David Rientjes 쓴 글:

On Thu, 22 May 2014, Gioh Kim wrote:


This is not a big deal but I think get_dev_cma_area is errataum of 
dev_get_cma_area.



Looks good, but you may want to read Documentation/SubmittingPatches when
proposing patches.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/base/dma-contiguous.c: erratum of dev_get_cma_area

[Gioh Kim]

fix erratum get_dev_cma_area into dev_get_cma_area

Signed-off-by: Gioh Kim 
---
 drivers/base/dma-contiguous.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index b056661..6343f25 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -291,7 +291,7 @@ err:
  *
  * This function allocates memory buffer for specified device. It uses
  * device specific contiguous memory area if available or the default
- * global one. Requires architecture specific get_dev_cma_area() helper
+ * global one. Requires architecture specific dev_get_cma_area() helper
  * function.
  */
 struct page *dma_alloc_from_contiguous(struct device *dev, int count,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] arm: dma-mapping: fallback allocation for cma failure

[Gioh Kim]

I'll resend the patch using git-send-email with your name.
I also hope some ARM-guys took a look at it.


2014-05-22 오후 12:22, Michal Nazarewicz 쓴 글:

On Thu, May 22 2014, Gioh Kim  wrote:

I appreciate your comments.
The previous patch was ugly. But now it's beautiful! Just 3 lines!

I'm not familiar with kernel patch process.
Can I have your name at Signed-off-by: line?
What tag do I have to write your name in?


My Signed-off-by line does not apply in this case.
Documentation/SubmittingPatches describes what Signed-off-by means.

I've added Acked-by below.  You may want to resend this patch using
“git-send-email”.


- 8< 
--
  From 135c986cfaa5a7291519308b3d47e58bf9f5af25 Mon Sep 17 00:00:00 2001
From: Gioh Kim 
Date: Tue, 20 May 2014 14:16:20 +0900
Subject: [PATCH] arm: dma-mapping: add checking cma area initialized

If CMA is turned on and CMA size is set to zero, kernel should
behave as if CMA was not enabled at compile time.
Every dma allocation should check existence of cma area
before requesting memory.

Signed-off-by: Gioh Kim 
Signed-off-by: Joonsoo Kim 


Acked-by: Michal Nazarewicz 

But like before, if someone with more ARM knowledge could take a look at
it, it would be awesome.


---
   arch/arm/mm/dma-mapping.c |7 ---
   1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 18e98df..9173a13 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -390,12 +390,13 @@ static int __init atomic_pool_init(void)
  if (!pages)
  goto no_pages;

-   if (IS_ENABLED(CONFIG_DMA_CMA))
+   if (dev_get_cma_area(NULL))
  ptr = __alloc_from_contiguous(NULL, pool->size, prot, &page,
atomic_pool_init);
  else
  ptr = __alloc_remap_buffer(NULL, pool->size, gfp, prot, &page,
 atomic_pool_init);
+
  if (ptr) {
  int i;

@@ -701,7 +702,7 @@ static void *__dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
  addr = __alloc_simple_buffer(dev, size, gfp, &page);
  else if (!(gfp & __GFP_WAIT))
  addr = __alloc_from_pool(size, &page);
-   else if (!IS_ENABLED(CONFIG_DMA_CMA))
+   else if (!dev_get_cma_area(dev))
  addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, 
caller);
  else
  addr = __alloc_from_contiguous(dev, size, prot, &page, 
caller);
@@ -790,7 +791,7 @@ static void __arm_dma_free(struct device *dev, size_t size, 
void *cpu_addr,
  __dma_free_buffer(page, size);
  } else if (__free_from_pool(cpu_addr, size)) {
  return;
-   } else if (!IS_ENABLED(CONFIG_DMA_CMA)) {
+   } else if (!dev_get_cma_area(dev)) {
  __dma_free_remap(cpu_addr, size);
  __dma_free_buffer(page, size);
  } else {
--
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: Fwd: [V6 00/11] perf: New conditional branch filter

[Michael Ellerman]

On Wed, 2014-05-21 at 14:01 +0200, Peter Zijlstra wrote:
> On Wed, May 21, 2014 at 04:09:55PM +0530, Anshuman Khandual wrote:
> > On 05/21/2014 02:53 PM, Peter Zijlstra wrote:
> > > On Wed, May 21, 2014 at 02:41:58PM +0530, Anshuman Khandual wrote:
> > >> Hello Peter/Ingo,
> > >>
> > >> Would you please consider reviewing the first four patches in this patch 
> > >> series
> > >> which changes the generic perf kernel and perf tools code. Andi Kleen 
> > >> and Stephane
> > >> Eranian have already reviewed these changes. The rest of the patch 
> > >> series is related
> > >> to powerpc and being reviewed by Michael Ellerman/Ben.
> > >>
> > > 
> > > If they land in my inbox I might have a look.
> > > 
> > 
> > Sent.
> 
> Thanks, they look fine to me, although 1/x can use a lightly longer
> changelog, making it explicit its a filter for conditional branches.
> 
> How do people want this routed? Should I take all patches through tip,
> or do I ask Ingo to create a special perf/cond branch which includes the
> first 4 patches which can be merged into whatever ppc branch and the
> rest then go on top in the ppc tree?

Hi Peter,

Can you take just the first 4 in your tree please. I asked Anshuman to just
send those 4 but he & I seem to have miscommunicated on that.

We only depend on patch 1 in order for the powerpc parts to build, so I think
we'll just merge that into the powerpc tree and it should merge fine when it
hits next.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] clk: samsung: Add driver to control CLKOUT line on Exynos SoCs

[Tushar Behera]

On 05/20/2014 10:13 PM, Tomasz Figa wrote:
> This patch introduces a driver that handles configuration of CLKOUT pin
> of Exynos SoCs that can be used to output certain clocks from inside of
> the SoC to a dedicated output pin.
> 
> Signed-off-by: Tomasz Figa 
> ---
>  .../devicetree/bindings/arm/samsung/pmu.txt|  30 
>  drivers/clk/samsung/Makefile   |   1 +
>  drivers/clk/samsung/clk-exynos-clkout.c| 153 
> +
>  3 files changed, 184 insertions(+)
>  create mode 100644 drivers/clk/samsung/clk-exynos-clkout.c
> 
> diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
> b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> index b562634..5ed94a9 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
> @@ -11,8 +11,38 @@ Properties:
>  
>   - reg : offset and length of the register set.
>  
> + - #clock-cells : must be <1>, since PMU requires once cell as clock 
> specifier.

s/once/one

> + The single specifier cell is used as index to list of clocks
> + provided by PMU, which is currently:
> + 0 : SoC clock output (CLKOUT pin)

Will it make more sense if we add a macro for this clock number that
would be referred in the device tree files?

> +Example of clock consumer :
> +
> +usb3503: usb3503@08 {
> + /* ... */
> + clock-names = "refclk";
> + clocks = <&pmu_system_controller 0>;
> + /* ... */
>  };

-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: s5pv210: remove unused call of pr_err()

[Sachin Kamat]

On 22 May 2014 09:44, Viresh Kumar  wrote:
> On 22 May 2014 08:52, Sachin Kamat  wrote:
>> On 22 May 2014 01:23, Paul Bolle  wrote:
>>> A call of pr_err() was added in v3.1. It was guarded by a check for
>>> CONFIG_PM_VERBOSE. The Kconfig symbol PM_VERBOSE was removed in v3.0. So
>>> this call of pr_err() has never been used. Remove it.
>>>
>>> Signed-off-by: Paul Bolle 
>>> ---
>>> Untested.
>>>
>>>  drivers/cpufreq/s5pv210-cpufreq.c | 4 
>>>  1 file changed, 4 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
>>> b/drivers/cpufreq/s5pv210-cpufreq.c
>>> index ab2c1a40d437..0873729135df 100644
>>> --- a/drivers/cpufreq/s5pv210-cpufreq.c
>>> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
>>> @@ -175,10 +175,6 @@ static int s5pv210_target(struct cpufreq_policy 
>>> *policy, unsigned int index)
>>> mutex_lock(&set_freq_lock);
>>>
>>> if (no_cpufreq_access) {
>>> -#ifdef CONFIG_PM_VERBOSE
>>> -   pr_err("%s:%d denied access to %s as it is disabled"
>>> -   "temporarily\n", __FILE__, __LINE__, 
>>> __func__);
>>> -#endif
>>
>> The config symbol itself is not defined and hence could be removed.
>
> What do you meant by this? He already got rid of CONFIG_PM_VERBOSE..

Yes, my ack for that change :)


-- 
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: s5pv210: remove unused call of pr_err()

[Viresh Kumar]

On 22 May 2014 08:52, Sachin Kamat  wrote:
> On 22 May 2014 01:23, Paul Bolle  wrote:
>> A call of pr_err() was added in v3.1. It was guarded by a check for
>> CONFIG_PM_VERBOSE. The Kconfig symbol PM_VERBOSE was removed in v3.0. So
>> this call of pr_err() has never been used. Remove it.
>>
>> Signed-off-by: Paul Bolle 
>> ---
>> Untested.
>>
>>  drivers/cpufreq/s5pv210-cpufreq.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
>> b/drivers/cpufreq/s5pv210-cpufreq.c
>> index ab2c1a40d437..0873729135df 100644
>> --- a/drivers/cpufreq/s5pv210-cpufreq.c
>> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
>> @@ -175,10 +175,6 @@ static int s5pv210_target(struct cpufreq_policy 
>> *policy, unsigned int index)
>> mutex_lock(&set_freq_lock);
>>
>> if (no_cpufreq_access) {
>> -#ifdef CONFIG_PM_VERBOSE
>> -   pr_err("%s:%d denied access to %s as it is disabled"
>> -   "temporarily\n", __FILE__, __LINE__, 
>> __func__);
>> -#endif
>
> The config symbol itself is not defined and hence could be removed.

What do you meant by this? He already got rid of CONFIG_PM_VERBOSE..

> However I feel, the
> error message could be retained after trimming down the arguments a bit.

I agree..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Resend] driver/core: cpu: initialize opp table

[Viresh Kumar]

On 22 May 2014 05:27, Rafael J. Wysocki  wrote:
> In a header file included by cpu.c.  Something like
>
> #if defined(CONFIG_OF) && defined(CONFIG_PM_OPP)
> 
> #else
> static inline 
> #endif

Thanks, Sudeep already helped me in understanding that :) ..
Already implemented that in cpu.c only ..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 3/7] driver/core: cpu: initialize opp table

[Viresh Kumar]

On 21 May 2014 22:56, Sudeep Holla  wrote:
> Sorry I missed this earlier, main idea of this wrapper is not to have any
> config dependency and hide error handling details for non-DT platforms.
> Since
> of_init_opp_table has dummy implementation, you really don't need this dummy
> implementation again here.

x-( (That's my angry face ..)

I still added it so that the next few conditional statements (error checking)
also go away for non-DT platforms.. So, lets keep for now. We may have
more additions into it in future..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf tools : adds support for native scripting

[Adrien BAK]

As it is perf-script allows one to use perl or python scripts to parse 
perf events.
The following proposal aimed to introduce support of .so files as scripts.
This support allows for better performance when parsing perf's data 
files and a complete access to the raw data.

This support is implemented analogously to the one in place for 
perl/python script.
More precisely, when passing a .so file as a script argument, the 
following symbols
are loaded :
- start_script
- stop_script
- process_event
These symbols will be called instead of the corresponding :
- default_start_script
- default_stop_script
- process_event

There currently is a limitation regarding the generate_script function 
which cannot be generalized to native scripts. Is it better to leave
 things as they are (die gracefully when the user asks for 
native_generate_script) or to do one of the following :
- print a usage message specifying the symbols a .so script should 
expose
- create a .c file complying with said interface

Regarding style compliance, the following issues remains :
- 3 'fprintf' lines slightly over 80 chars in trace-event-native.
Is it better to introduce a line break than to have a 83-chars 
long line?
- in trace-event-scripting.c a struct is declared as extern. Here, 
I followed what was already done for perl/python scripting.


Signed-off-by: Adrien BAK 

---

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 895edd3..1342a2e 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -543,6 +543,10 @@ ifndef NO_LIBPYTHON
   LIB_OBJS += $(OUTPUT)scripts/python/Perf-Trace-Util/Context.o
 endif
 
+ifndef NO_NATIVE_SCRIPTING
+  LIB_OBJS += $(OUTPUT)util/scripting-engines/trace-event-native.o
+endif
+
 ifeq ($(NO_PERF_REGS),0)
   ifeq ($(ARCH),x86)
 LIB_H += arch/x86/include/perf_regs.h
@@ -715,6 +719,9 @@ $(OUTPUT)util/scripting-engines/trace-event-python.o: 
util/scripting-engines/tra
 $(OUTPUT)scripts/python/Perf-Trace-Util/Context.o: 
scripts/python/Perf-Trace-Util/Context.c $(OUTPUT)PERF-CFLAGS
$(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) $(PYTHON_EMBED_CCOPTS) 
-Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter 
-Wno-nested-externs $<
 
+$(OUTPUT)util/scripting-engines/trace-event-native.o: 
util/scripting-engines/trace-event-native.c $(OUTPUT)PERF-CFLAGS
+   $(QUIET_CC)$(CC) -o $@ -c $(CFLAGS) -Wno-redundant-decls 
-Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs $<
+
 $(OUTPUT)perf-%: %.o $(PERFLIBS)
$(QUIET_LINK)$(CC) $(CFLAGS) -o $@ $(LDFLAGS) $(filter %.o,$^) $(LIBS)
 
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 9e9c91f..7241e30 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -522,6 +522,7 @@ static void setup_scripting(void)
 {
setup_perl_scripting();
setup_python_scripting();
+   setup_native_scripting();
 
scripting_ops = &default_scripting_ops;
 }
diff --git a/tools/perf/util/scripting-engines/trace-event-native.c 
b/tools/perf/util/scripting-engines/trace-event-native.c
new file mode 100644
index 000..4349bf1
--- /dev/null
+++ b/tools/perf/util/scripting-engines/trace-event-native.c
@@ -0,0 +1,125 @@
+#include 
+#include 
+
+#include "../../perf.h"
+#include "../evsel.h"
+#include "../util.h"
+#include "../event.h"
+#include "../thread.h"
+#include "../trace-event.h"
+
+static void *handle;
+
+enum syms {
+START_SCRIPT = 0,
+STOP_SCRIPT,
+PROCESS_EVENT,
+GENERATE_SCRIPT,
+};
+
+const char *sym_names[4] = {"start_script",
+   "stop_script",
+   "process_event",
+   "generate_script"};
+
+int  (*so_start_script)(const char*, int, const char**);
+int  (*so_stop_script)(void);
+void (*so_process_event)(union perf_event *, struct perf_sample *,
+struct perf_evsel *, struct thread *,
+struct addr_location *);
+
+static void native_process_event(union perf_event *event __maybe_unused,
+struct perf_sample *sample,
+struct perf_evsel *evsel,
+struct thread *thread,
+struct addr_location *al)
+{
+   (so_process_event)(event, sample, evsel, thread, al);
+}
+
+static int native_start_script(const char *script, int argc, const char **argv)
+{
+   int err = 0;
+
+   char *local_error;
+
+   handle = dlopen(script, RTLD_NOW);
+
+   if (!handle) {
+   fprintf(stderr, "an error occurred while loading the .so 
file\n");
+   fprintf(stderr, "%s\n", dlerror());
+   return -1;
+   }
+
+   *(void **)(&so_start_script) = dlsym(handle, sym_names[START_SCRIPT]);
+
+   local_error = dlerror();
+   if (local_error) {
+   fprintf(stderr

[ANNOUNCE]: SCST 2.2 pre-release freeze

[Vladislav Bolkhovitin]

Hi All,

I'm glad to announce SCST 3.0 pre-release code freeze in the SCST SVN branch 
3.0.x

You can get it by command:

$ svn co https://scst.svn.sourceforge.net/svnroot/scst/branches/3.0.x

It is going to be released after few weeks of testing, if nothing bad found.

SCST is alternative SCSI target stack for Linux. SCST allows creation of 
sophisticated storage devices, which provide advanced functionality, like 
replication, thin provisioning, deduplication, high availability, automatic 
backup, etc. Majority of recently developed SAN appliances, especially higher 
end ones, are SCST based. It might well be that your favorite storage appliance 
running SCST in the firmware.

More info about SCST and its modules you can find on: 
http://scst.sourceforge.net

Thanks to all who made it happen!

Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the pci tree

[Stephen Rothwell]

Hi Bjorn,

After merging the pci tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/pci/pci-sysfs.c: In function 'devspec_show':
drivers/pci/pci-sysfs.c:426:22: error: dereferencing pointer to incomplete type
drivers/pci/pci-sysfs.c:428:30: error: dereferencing pointer to incomplete type
drivers/pci/pci-sysfs.c:429:1: warning: control reaches end of non-void 
function [-Wreturn-type]

Caused by commit da647bb30834 ("PCI: Move Open Firmware devspec
attribute to PCI common code").  Presumably a forgotten include.

I have used the pci tree from next-20140521 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH V5] PM/OPP: discard duplicate OPPs

[Viresh Kumar]

On 22 May 2014 05:18, Rafael J. Wysocki  wrote:
> The case in which we want to return 0.  Never mind, it's OK.

Ahh yes, It was wrong earlier and fixed during this patch only :)

> The parens are still not necessary, though.

Already got rid of them and so didn't bother replying :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/6] usb: dwc3: dwc3-omap: Add dwc3_omap_extcon_register function

[George Cherian]

Move the extcon related code to its own function.
Improve code readability, decrease the dwc3_probe() size.

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 65 ++--
 1 file changed, 39 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 56ec6eb..7594535 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -421,6 +421,42 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
dwc3_omap_write_utmi_status(omap, reg);
 }
 
+static int dwc3_omap_extcon_register(struct dwc3_omap *omap)
+{
+   u32 ret;
+   struct device_node  *node = omap->dev->of_node;
+   struct extcon_dev   *edev;
+
+   if (of_property_read_bool(node, "extcon")) {
+   edev = extcon_get_edev_by_phandle(omap->dev, 0);
+   if (IS_ERR(edev)) {
+   dev_vdbg(omap->dev, "couldn't get extcon device\n");
+   return -EPROBE_DEFER;
+   }
+
+   omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
+   ret = extcon_register_interest(&omap->extcon_vbus_dev,
+  edev->name, "USB",
+  &omap->vbus_nb);
+   if (ret < 0)
+   dev_vdbg(omap->dev, "failed to register notifier for 
USB\n");
+
+   omap->id_nb.notifier_call = dwc3_omap_id_notifier;
+   ret = extcon_register_interest(&omap->extcon_id_dev,
+  edev->name, "USB-HOST",
+  &omap->id_nb);
+   if (ret < 0)
+   dev_vdbg(omap->dev, "failed to register notifier for 
USB-HOST\n");
+
+   if (extcon_get_cable_state(edev, "USB") == true)
+   dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
+   if (extcon_get_cable_state(edev, "USB-HOST") == true)
+   dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
+   }
+
+   return 0;
+}
+
 static int dwc3_omap_probe(struct platform_device *pdev)
 {
struct device_node  *node = pdev->dev.of_node;
@@ -428,7 +464,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
struct dwc3_omap*omap;
struct resource *res;
struct device   *dev = &pdev->dev;
-   struct extcon_dev   *edev;
struct regulator*vbus_reg = NULL;
 
int ret;
@@ -500,31 +535,9 @@ static int dwc3_omap_probe(struct platform_device *pdev)
 
dwc3_omap_enable_irqs(omap);
 
-   if (of_property_read_bool(node, "extcon")) {
-   edev = extcon_get_edev_by_phandle(dev, 0);
-   if (IS_ERR(edev)) {
-   dev_vdbg(dev, "couldn't get extcon device\n");
-   ret = -EPROBE_DEFER;
-   goto err2;
-   }
-
-   omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
-   ret = extcon_register_interest(&omap->extcon_vbus_dev,
-   edev->name, "USB", &omap->vbus_nb);
-   if (ret < 0)
-   dev_vdbg(dev, "failed to register notifier for USB\n");
-   omap->id_nb.notifier_call = dwc3_omap_id_notifier;
-   ret = extcon_register_interest(&omap->extcon_id_dev, edev->name,
-"USB-HOST", &omap->id_nb);
-   if (ret < 0)
-   dev_vdbg(dev,
-   "failed to register notifier for USB-HOST\n");
-
-   if (extcon_get_cable_state(edev, "USB") == true)
-   dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
-   if (extcon_get_cable_state(edev, "USB-HOST") == true)
-   dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
-   }
+   ret = dwc3_omap_extcon_register(omap);
+   if (ret < 0)
+   goto err2;
 
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
-- 
1.8.3.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 v3 3/6] usb: dwc3: dwc3-omap: Add dwc3_omap_set_utmi_mode() function

[George Cherian]

Move find and set the utmi mode to its own seperate function.
Improve code readability, decrease the dwc3_probe() size.

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 44 +---
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 09918ac..56ec6eb 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -397,6 +397,30 @@ static void dwc3_omap_map_offset(struct dwc3_omap *omap)
}
 }
 
+static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
+{
+   u32 reg;
+   struct device_node  *node = omap->dev->of_node;
+   int utmi_mode = 0;
+
+   reg = dwc3_omap_read_utmi_status(omap);
+
+   of_property_read_u32(node, "utmi-mode", &utmi_mode);
+
+   switch (utmi_mode) {
+   case DWC3_OMAP_UTMI_MODE_SW:
+   reg |= USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
+   break;
+   case DWC3_OMAP_UTMI_MODE_HW:
+   reg &= ~USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
+   break;
+   default:
+   dev_dbg(omap->dev, "UNKNOWN utmi mode %d\n", utmi_mode);
+   }
+
+   dwc3_omap_write_utmi_status(omap, reg);
+}
+
 static int dwc3_omap_probe(struct platform_device *pdev)
 {
struct device_node  *node = pdev->dev.of_node;
@@ -410,8 +434,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
int ret;
int irq;
 
-   int utmi_mode = 0;
-
u32 reg;
 
void __iomem*base;
@@ -462,23 +484,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
}
 
dwc3_omap_map_offset(omap);
-
-   reg = dwc3_omap_read_utmi_status(omap);
-
-   of_property_read_u32(node, "utmi-mode", &utmi_mode);
-
-   switch (utmi_mode) {
-   case DWC3_OMAP_UTMI_MODE_SW:
-   reg |= USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
-   break;
-   case DWC3_OMAP_UTMI_MODE_HW:
-   reg &= ~USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
-   break;
-   default:
-   dev_dbg(dev, "UNKNOWN utmi mode %d\n", utmi_mode);
-   }
-
-   dwc3_omap_write_utmi_status(omap, reg);
+   dwc3_omap_set_utmi_mode(omap);
 
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
-- 
1.8.3.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 v3 1/6] usb: dwc3: dwc3-omap: Remove x_major calculation from revision register

[George Cherian]

Remove the x_major calculation logic from the wrapper revision register
to differentiate between OMAP5 and AM437x. This was done to find the
register offsets of wrapper register. Now that We do it using dt
compatible, remove the whole logic.

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 36 
 1 file changed, 4 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 4af4c35..999bdc8 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -77,10 +77,6 @@
 #define USBOTGSS_DEV_EBC_EN0x0110
 #define USBOTGSS_DEBUG_OFFSET  0x0600
 
-/* REVISION REGISTER */
-#define USBOTGSS_REVISION_XMAJOR(reg)  ((reg >> 8) & 0x7)
-#define USBOTGSS_REVISION_XMAJOR1  1
-#define USBOTGSS_REVISION_XMAJOR2  2
 /* SYSCONFIG REGISTER */
 #define USBOTGSS_SYSCONFIG_DMADISABLE  (1 << 16)
 
@@ -129,7 +125,6 @@ struct dwc3_omap {
u32 irq_eoi_offset;
u32 debug_offset;
u32 irq0_offset;
-   u32 revision;
 
u32 dma_status:1;
 
@@ -397,7 +392,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
int irq;
 
int utmi_mode = 0;
-   int x_major;
 
u32 reg;
 
@@ -448,32 +442,10 @@ static int dwc3_omap_probe(struct platform_device *pdev)
goto err0;
}
 
-   reg = dwc3_omap_readl(omap->base, USBOTGSS_REVISION);
-   omap->revision = reg;
-   x_major = USBOTGSS_REVISION_XMAJOR(reg);
-
-   /* Differentiate between OMAP5 and AM437x */
-   switch (x_major) {
-   case USBOTGSS_REVISION_XMAJOR1:
-   case USBOTGSS_REVISION_XMAJOR2:
-   omap->irq_eoi_offset = 0;
-   omap->irq0_offset = 0;
-   omap->irqmisc_offset = 0;
-   omap->utmi_otg_offset = 0;
-   omap->debug_offset = 0;
-   break;
-   default:
-   /* Default to the latest revision */
-   omap->irq_eoi_offset = USBOTGSS_EOI_OFFSET;
-   omap->irq0_offset = USBOTGSS_IRQ0_OFFSET;
-   omap->irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
-   omap->utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
-   omap->debug_offset = USBOTGSS_DEBUG_OFFSET;
-   break;
-   }
-
-   /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
-* changes in wrapper registers, Using dt compatible for aegis
+   /* Differentiate between OMAP5 and AM437x.
+* For OMAP5(ES2.0) and AM437x wrapper revision is same, even
+* though there are changes in wrapper register offsets.
+* Using dt compatible to differentiate  AM437x.
 */
 
if (of_device_is_compatible(node, "ti,am437x-dwc3")) {
-- 
1.8.3.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 v3 5/6] usb: dwc3: dwc3-omap: Fix the crash on module removal

[George Cherian]

Following crash is seen on dwc3_omap removal
Unable to handle kernel NULL pointer dereference at virtual address 0018
pgd = ec098000
[0018] *pgd=ad1f9831, *pte=, *ppte=
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in: usb_f_ss_lb g_zero usb_f_acm u_serial usb_f_ecm u_ether 
libcomposite configfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hwdep 
snd_soc_omap snd_pcm_dmaengine snd_soc_core snd_compress snd_pcm snd_tim]
CPU: 0 PID: 1296 Comm: rmmod Tainted: GW 
3.15.0-rc4-02716-g95c4e18-dirty #10
task: ed05a080 ti: ec368000 task.ti: ec368000
PC is at release_resource+0x14/0x7c
LR is at release_resource+0x10/0x7c
pc : []lr : []psr: 6013
sp : ec369ec0  ip : 6013  fp : 00021008
r10:   r9 : ec368000  r8 : c000e7a4
r7 : 0081  r6 : bf0062c0  r5 : ed7cd000  r4 : ed7d85c0
r3 :   r2 :   r1 : 0011  r0 : c086d08c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: ac098059  DAC: 0015
Process rmmod (pid: 1296, stack limit = 0xec368248)
Stack: (0xec369ec0 to 0xec36a000)
9ec0:  0001 ed7cd000 c034de94 ed7cd010 ed7cd000  c034e194
9ee0:  bf0062cc ed7cd010 c03490b0 ed154cc0 ed4c2570 ed2b8410 ed156810
ed156810 bf006d24 c034db9c c034db84 c034c518
9f20: bf006d24 ed156810 bf006d24 c034cd2c bf006d24 bf006d68 0800 c034c340
9f40:  c00a9e5c 0020  bf006d68 0800 ec369f4c 33637764
9f60: 616d6f5f 0070 0001 ec368000 ed05a080 c000e670 0001 c0084010
9f80: 00021088 0800 00021088 0081 8010 e6f4 00021088 0800
9fa0: 00021088 c000e5e0 00021088 0800 000210b8 0800 e04f6d00 e04f6d00
9fc0: 00021088 0800 00021088 0081 0001  be91de08 00021008
9fe0: 4d768880 be91dbb4 b6fc5984 4d76888c 8010 000210b8  
[] (release_resource) from [] 
(platform_device_del+0x6c/0x9c)
[] (platform_device_del) from [] 
(platform_device_unregister+0xc/0x18)
[] (platform_device_unregister) from [] 
(dwc3_omap_remove_core+0xc/0x14 [dwc3_omap])
[] (dwc3_omap_remove_core [dwc3_omap]) from [] 
(device_for_each_child+0x34/0x74)
[] (device_for_each_child) from [] 
(dwc3_omap_remove+0x6c/0x78 [dwc3_omap])
[] (dwc3_omap_remove [dwc3_omap]) from [] 
(platform_drv_remove+0x18/0x1c)
[] (platform_drv_remove) from [] 
(__device_release_driver+0x70/0xc8)
[] (__device_release_driver) from [] 
(driver_detach+0xb4/0xb8)
[] (driver_detach) from [] (bus_remove_driver+0x4c/0x90)
[] (bus_remove_driver) from [] 
(SyS_delete_module+0x10c/0x198)
[] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x48)
Code: e1a04000 e59f0068 eb14505e e5943010 (e5932018)
---[ end trace 7e2a8746ff4fc811 ]---
Segmentation fault

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 7594535..b729cdb 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -317,7 +317,7 @@ static int dwc3_omap_remove_core(struct device *dev, void 
*c)
 {
struct platform_device *pdev = to_platform_device(dev);
 
-   platform_device_unregister(pdev);
+   of_device_unregister(pdev);
 
return 0;
 }
-- 
1.8.3.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 v3 6/6] usb: dwc3: dwc3-omap: Disable/Enable only wrapper interrupts in prepare/complete

[George Cherian]

The dwc3 wrapper driver should not be fiddling with the core interrupts.
Disabling the core interrupts in prepare stops xhci from proper operation.
So remove disable/enable of core interrupts from prepare/complete.

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b729cdb..116f71c 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -597,7 +597,7 @@ static int dwc3_omap_prepare(struct device *dev)
 {
struct dwc3_omap*omap = dev_get_drvdata(dev);
 
-   dwc3_omap_disable_irqs(omap);
+   dwc3_omap_write_irqmisc_set(omap, 0x00);
 
return 0;
 }
@@ -605,8 +605,19 @@ static int dwc3_omap_prepare(struct device *dev)
 static void dwc3_omap_complete(struct device *dev)
 {
struct dwc3_omap*omap = dev_get_drvdata(dev);
+   u32 reg;
 
-   dwc3_omap_enable_irqs(omap);
+   reg = (USBOTGSS_IRQMISC_OEVT |
+   USBOTGSS_IRQMISC_DRVVBUS_RISE |
+   USBOTGSS_IRQMISC_CHRGVBUS_RISE |
+   USBOTGSS_IRQMISC_DISCHRGVBUS_RISE |
+   USBOTGSS_IRQMISC_IDPULLUP_RISE |
+   USBOTGSS_IRQMISC_DRVVBUS_FALL |
+   USBOTGSS_IRQMISC_CHRGVBUS_FALL |
+   USBOTGSS_IRQMISC_DISCHRGVBUS_FALL |
+   USBOTGSS_IRQMISC_IDPULLUP_FALL);
+
+   dwc3_omap_write_irqmisc_set(omap, reg);
 }
 
 static int dwc3_omap_suspend(struct device *dev)
-- 
1.8.3.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 v3 0/6] Cleanup and fixes for dwc3-omap

[George Cherian]

The series does some refactoring on dwc3_probe()

Patch 1 - Now that we use driver compatible for revision check, remove the 
unnecessary logic.
Patch 2-4 - reduce the size of dwc3_probe()
Patch 5 - Fix the crash on dwc3_omap removal
Patch 6 - Addresses the issue of  xhci hang while resuming from system sleep.

George Cherian (6):
  usb: dwc3: dwc3-omap: Remove x_major calculation from revision
register
  usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset() function
  usb: dwc3: dwc3-omap: Add dwc3_omap_set_utmi_mode() function
  usb: dwc3: dwc3-omap: Add dwc3_omap_extcon_register function
  usb: dwc3: dwc3-omap: Fix the crash on module removal
  usb: dwc3: dwc3-omap: Disable/Enable only wrapper interrupts in
prepare/complete

 drivers/usb/dwc3/dwc3-omap.c | 187 +++
 1 file changed, 98 insertions(+), 89 deletions(-)

-- 
1.8.3.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 v3 2/6] usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset() function

[George Cherian]

Move map offset to its own seperate function.
Improve code readability, decrease the dwc3_probe() size.

Signed-off-by: George Cherian 
---
 drivers/usb/dwc3/dwc3-omap.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 999bdc8..09918ac 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -378,6 +378,25 @@ static int dwc3_omap_vbus_notifier(struct notifier_block 
*nb,
return NOTIFY_DONE;
 }
 
+static void dwc3_omap_map_offset(struct dwc3_omap *omap)
+{
+   struct device_node  *node = omap->dev->of_node;
+
+   /* Differentiate between OMAP5 and AM437x.
+* For OMAP5(ES2.0) and AM437x wrapper revision is same  even
+* though there are changes in wrapper register offsets.
+* Using dt compatible to differentiate  AM437x.
+*/
+
+   if (of_device_is_compatible(node, "ti,am437x-dwc3")) {
+   omap->irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+   omap->irq0_offset = USBOTGSS_IRQ0_OFFSET;
+   omap->irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+   omap->utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+   omap->debug_offset = USBOTGSS_DEBUG_OFFSET;
+   }
+}
+
 static int dwc3_omap_probe(struct platform_device *pdev)
 {
struct device_node  *node = pdev->dev.of_node;
@@ -442,19 +461,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
goto err0;
}
 
-   /* Differentiate between OMAP5 and AM437x.
-* For OMAP5(ES2.0) and AM437x wrapper revision is same, even
-* though there are changes in wrapper register offsets.
-* Using dt compatible to differentiate  AM437x.
-*/
-
-   if (of_device_is_compatible(node, "ti,am437x-dwc3")) {
-   omap->irq_eoi_offset = USBOTGSS_EOI_OFFSET;
-   omap->irq0_offset = USBOTGSS_IRQ0_OFFSET;
-   omap->irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
-   omap->utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
-   omap->debug_offset = USBOTGSS_DEBUG_OFFSET;
-   }
+   dwc3_omap_map_offset(omap);
 
reg = dwc3_omap_read_utmi_status(omap);
 
-- 
1.8.3.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 v3 2/4] Regulators: Add TPS65917 Bindings

[Keerthy]

Add TPS65917 Bindings.

Signed-off-by: Keerthy 
---
 .../bindings/regulator/tps65917-pmic.txt   |   67 
 1 file changed, 67 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65917-pmic.txt

diff --git a/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt 
b/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
new file mode 100644
index 000..96d1fb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
@@ -0,0 +1,67 @@
+* tps65917 regulator IP block devicetree bindings
+
+Required properties:
+- compatible : Should be
+  ti,tps65917-pmic
+
+- interrupt-parent : The parent interrupt controller which is tps65917.
+- interrupts : The interrupt number and the type which can be looked up here:
+  arch/arm/boot/dts/include/dt-bindings/interrupt-controller/irq.h
+- interrupts-name: The names of the individual interrupts.
+
+Optional nodes:
+- regulators : Must contain a sub-node per regulator from the list below.
+  Each sub-node should contain the constraints and initialization
+  information for that regulator. See regulator.txt for a
+  description of standard properties for these sub-nodes.
+  Additional custom properties  are listed below.
+
+  Optional sub-node properties:
+  ti,warm-reset - maintain voltage during warm reset(boolean)
+  ti,roof-floor - This takes as optional argument on platform 
supporting
+  the rail from desired external control. If there is no argument 
then
+  it will be assume that it is controlled by NSLEEP pin.
+  The valid value for external pins are:
+   ENABLE1 then 1,
+   ENABLE2 then 2 or
+   NSLEEP then 3.
+  ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
+  2 - eco, 3 - forced pwm
+  ti,smps-range - OTP has the wrong range set for the hardware so 
override
+  0 - low range, 1 - high range.
+
+- ti,system-power-controller: Telling whether or not this pmic is controlling
+ the system power.
+
+Example:
+
+#include 
+
+pmic {
+   compatible = "ti,tps65917-pmic";
+   interrupt-parent = <&tps65917>;
+   interrupts = <14 IRQ_TYPE_NONE>;
+   interrupts-name = "short-irq";
+
+   ti,system-power-controller;
+
+   regulators {
+   smps1_reg : smps1 {
+   regulator-name = "smps1";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   regulator-boot-on;
+   ti,warm-reset;
+   ti,roof-floor = <1>; /* ENABLE1 control */
+   ti,mode-sleep = <0>;
+   ti,smps-range = <1>;
+   };
+
+   ldo1_reg: ldo1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   };
+   };
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/4] regulator: tps65917: Add Regulator driver for TPS65917 PMIC

[Keerthy]

This patch adds support for TPS65917 PMIC regulators.

The regulators set consists of 5 SMPSs and 5 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.

Signed-off-by: Keerthy 
---

v3 Changes:

 removed NULL ops structure
 Corrected documentation style
 
v2 Changes:

  Used the standard functions in helpers.c
  Added a NULL entry in of_tps65917_match_tbl table.
  Used linear ranges instead of open coded function.
 
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/tps65917-regulator.c |  809 
 3 files changed, 822 insertions(+)
 create mode 100644 drivers/regulator/tps65917-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 903eb37..6455a6e 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -581,6 +581,18 @@ config REGULATOR_TPS65912
help
This driver supports TPS65912 voltage regulator chip.
 
+config REGULATOR_TPS65917
+   tristate "TI TPS65917 PMIC Regulators"
+   depends on MFD_TPS65917
+   help
+ If you wish to control the regulators on the TPS65917 series of
+ chips say Y here. This will enable support for all the software
+ controllable SMPS/LDO regulators.
+
+ The regulators available on TPS65917 series chips vary depending
+ on the muxing. This is handled automatically in the driver by
+ reading the mux info from OTP.
+
 config REGULATOR_TPS80031
tristate "TI TPS80031/TPS80032 power regualtor driver"
depends on MFD_TPS80031
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 12ef277..115ee53 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65917) += tps65917-regulator.o
 obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
 obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
 obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
diff --git a/drivers/regulator/tps65917-regulator.c 
b/drivers/regulator/tps65917-regulator.c
new file mode 100644
index 000..877cf05
--- /dev/null
+++ b/drivers/regulator/tps65917-regulator.c
@@ -0,0 +1,809 @@
+/*
+ * Driver for Regulator part of TPS65917 PMIC
+ *
+ * Copyright (C) 2013 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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct regs_info {
+   char*name;
+   char*sname;
+   u8  vsel_addr;
+   u8  ctrl_addr;
+   int sleep_id;
+};
+
+static const struct regulator_linear_range smps_low_ranges[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x1, 0x6, 0),
+   REGULATOR_LINEAR_RANGE(51, 0x7, 0x79, 1),
+   REGULATOR_LINEAR_RANGE(165, 0x7A, 0x7f, 0),
+};
+
+static const struct regulator_linear_range smps_high_ranges[] = {
+   REGULATOR_LINEAR_RANGE(100, 0x1, 0x6, 0),
+   REGULATOR_LINEAR_RANGE(102, 0x7, 0x79, 2),
+   REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
+};
+
+static const struct regs_info tps65917_regs_info[] = {
+   {
+   .name   = "SMPS1",
+   .sname  = "smps1-in",
+   .vsel_addr  = TPS65917_SMPS1_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS1_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+   },
+   {
+   .name   = "SMPS2",
+   .sname  = "smps2-in",
+   .vsel_addr  = TPS65917_SMPS2_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS2_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+   },
+   {
+   .name   = "SMPS3",
+   .sname  = "smps3-in",
+   .vsel_addr  = TPS65917_SMPS3_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS3_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+   },
+   {
+   .name   = "SMPS4",
+   .sname  = "smps4-in",
+   .vsel_addr  = TPS65917_SMPS4_VOLTAGE,
+   

[PATCH v3 0/4] tps65917: Drivers for TPS65917 PMIC

[Keerthy]

The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

 - Regulators.
 - GPADC.
 - Over Temperature warning and Shut down.

This patch series adds support for TPS65917 mfd device. At this time only
the regulator functionality is made available.

The closest drivers are PALMAS series drivers.
The register set is changed. Bit-field defenitions are changed.
Hence based on the PALMAS drivers and created a new set of drivers
with code changes as required.

The patches are boot tested on DRA72-EVM.

Keerthy (4):
  MFD: DT bindings for the TPS65917 family MFD
  Regulators: Add TPS65917 Bindings
  mfd: tps65917: Add driver for the TPS65917 PMIC
  regulator: tps65917: Add Regulator driver for TPS65917 PMIC

 Documentation/devicetree/bindings/mfd/tps65917.txt |   35 +
 .../bindings/regulator/tps65917-pmic.txt   |   67 +
 drivers/mfd/Kconfig|   12 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/tps65917.c |  594 
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/tps65917-regulator.c |  809 +++
 include/linux/mfd/tps65917.h   | 1485 
 9 files changed, 3016 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65917.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
 create mode 100644 drivers/mfd/tps65917.c
 create mode 100644 drivers/regulator/tps65917-regulator.c
 create mode 100644 include/linux/mfd/tps65917.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/4] MFD: DT bindings for the TPS65917 family MFD

[Keerthy]

Add the various binding files for the TPS65917 family of chips. There is a
top level MFD binding then a seperate binding for regulators IP blocks on chips.

Signed-off-by: Keerthy 
---
 Documentation/devicetree/bindings/mfd/tps65917.txt |   35 
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65917.txt

diff --git a/Documentation/devicetree/bindings/mfd/tps65917.txt 
b/Documentation/devicetree/bindings/mfd/tps65917.txt
new file mode 100644
index 000..287a713
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65917.txt
@@ -0,0 +1,35 @@
+* TPS65917 device tree bindings
+
+The TI TPS65917 family of PMICs.
+
+Required properties:
+- compatible : Should be from the list
+  ti,tps65917
+- interrupt-controller : TPS65917 has its own internal IRQs
+- #interrupt-cells : should be set to 2 for IRQ number and flags
+  The first cell is the IRQ number.
+  The second cell is the flags, encoded as the trigger masks from
+  Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+
+Optional properties:
+  ti,mux-padX : set the pad register X (1-2) to the correct muxing for the
+   hardware, if not set will use muxing in OTP.
+
+Example:
+
+tps65917 {
+   compatible = "ti,tps65917";
+   reg = <0x58>
+   interrupt-parent = <&intc>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pmic {
+   compatible = "ti,tps65917-pmic";
+   
+   };
+}
-- 
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: Fwd: [V6 00/11] perf: New conditional branch filter

[Anshuman Khandual]

On 05/21/2014 05:31 PM, Peter Zijlstra wrote:
> On Wed, May 21, 2014 at 04:09:55PM +0530, Anshuman Khandual wrote:
>> On 05/21/2014 02:53 PM, Peter Zijlstra wrote:
>>> On Wed, May 21, 2014 at 02:41:58PM +0530, Anshuman Khandual wrote:
 Hello Peter/Ingo,

 Would you please consider reviewing the first four patches in this patch 
 series
 which changes the generic perf kernel and perf tools code. Andi Kleen and 
 Stephane
 Eranian have already reviewed these changes. The rest of the patch series 
 is related
 to powerpc and being reviewed by Michael Ellerman/Ben.

>>>
>>> If they land in my inbox I might have a look.
>>>
>>
>> Sent.
> 
> Thanks, they look fine to me, although 1/x can use a lightly longer
> changelog, making it explicit its a filter for conditional branches.
> 
> How do people want this routed? Should I take all patches through tip,
> or do I ask Ingo to create a special perf/cond branch which includes the
> first 4 patches which can be merged into whatever ppc branch and the
> rest then go on top in the ppc tree?
> 

Peter,

Thanks for considering the patchset.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] phy: exynos5-usbdrd: Make local functions static

[Jingoo Han]

Make local functions static, because these are used only in this
file.

Signed-off-by: Jingoo Han 
---
 drivers/phy/phy-exynos5-usbdrd.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 76d862b..205159d 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -506,7 +506,7 @@ static struct phy_ops exynos5_usbdrd_phy_ops = {
.owner  = THIS_MODULE,
 };
 
-const struct exynos5_usbdrd_phy_config phy_cfg_exynos5[] = {
+static const struct exynos5_usbdrd_phy_config phy_cfg_exynos5[] = {
{
.id = EXYNOS5_DRDPHY_UTMI,
.phy_isol   = exynos5_usbdrd_phy_isol,
@@ -521,13 +521,13 @@ const struct exynos5_usbdrd_phy_config phy_cfg_exynos5[] 
= {
},
 };
 
-const struct exynos5_usbdrd_phy_drvdata exynos5420_usbdrd_phy = {
+static const struct exynos5_usbdrd_phy_drvdata exynos5420_usbdrd_phy = {
.phy_cfg= phy_cfg_exynos5,
.pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
.pmu_offset_usbdrd1_phy = EXYNOS5420_USBDRD1_PHY_CONTROL,
 };
 
-const struct exynos5_usbdrd_phy_drvdata exynos5250_usbdrd_phy = {
+static const struct exynos5_usbdrd_phy_drvdata exynos5250_usbdrd_phy = {
.phy_cfg= phy_cfg_exynos5,
.pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
 };
-- 
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: [ANNOUNCE] Git v2.0.0-rc4

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras  writes:
> 
> > Junio C Hamano wrote:
> >
> >>  * The remote-helper interface to fast-import/fast-export via the
> >>transport-helper has been tightened to avoid leaving the import
> >>marks file from a failed/crashed run, as such a file that is out-of-
> >>sync with reality confuses a later invocation of itself.
> >
> > Really? Where are the patches for that?
> >
> > I think it's fair to say the way the remote-helpers and transport-helper
> > has been handled for v2.0 has been a total disaster.
> 
> Thanks for noticing.  The last-minute change of plans in the morning
> on the -rc release day did not help.  Will remove.

But this changed before that.

> Anything else I missed?

Not as far as I can see.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V6 01/11] perf: Add PERF_SAMPLE_BRANCH_COND

[Anshuman Khandual]

On 05/21/2014 05:00 PM, Peter Zijlstra wrote:
> On Wed, May 21, 2014 at 03:29:46PM +0530, Anshuman Khandual wrote:
>> This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
>> will extend the existing perf ABI. Various architectures can provide
>> this functionality with either with HW filtering support (if present)
>> or with SW filtering of captured branch instructions.
> 
> The Changelog fails to mention what _this_ functionality is.
> 

Peter,

Hope this new change log below makes more sense.

---
commit af75191bb7ad36cba7d75c2741c93dfbdaf09da3
Author: Anshuman Khandual 
Date:   Mon Jul 22 12:22:27 2013 +0530

perf: Add new conditional branch filter PERF_SAMPLE_BRANCH_COND

This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
will extend the existing perf ABI. This will filter branches which are
conditional. Various architectures can provide this functionality either
with HW filtering support (if present) or with SW filtering of captured
branch instructions.

Signed-off-by: Anshuman Khandual 
Reviewed-by: Stephane Eranian 
Reviewed-by: Andi Kleen 

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 853bc1c..696f69b4 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -163,8 +163,9 @@ enum perf_branch_sample_type {
PERF_SAMPLE_BRANCH_ABORT_TX = 1U << 7, /* transaction aborts */
PERF_SAMPLE_BRANCH_IN_TX= 1U << 8, /* in transaction */
PERF_SAMPLE_BRANCH_NO_TX= 1U << 9, /* not in transaction */
+   PERF_SAMPLE_BRANCH_COND = 1U << 10, /* conditional branches */
 
-   PERF_SAMPLE_BRANCH_MAX  = 1U << 10, /* non-ABI */
+   PERF_SAMPLE_BRANCH_MAX  = 1U << 11, /* non-ABI */
 };
 
 #define PERF_SAMPLE_BRANCH_PLM_ALL \

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: add params in disable_setting for different usage

[FanWu]

On 05/22/2014 11:10 AM, f...@marvell.com wrote:

From: Fan Wu 

What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
   calling pinctrl_select_state
2.Remove the HW disable operation in in pinmux_disable_setting function.

The reason why to do this is that:
1.To avoid duplicated enable_setting operation without disabling operation
   which will let Pin's desc->mux_usecount keep being added.
2.The HW pin disable operation is not useful for most of the vendors' platform.
   And this avoid the HW glitch after using the item 1# modification.

In the following case, the issue can be reproduced:
1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
"default" state
2)The Pin setting configuration in DTS node may be like the following one:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&a_grp_setting &c_grp_setting>;
pinctrl-1 = <&b_grp_setting &c_grp_setting>;
}
The "c_grp_setting" config node is totaly same, maybe like following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
MFP_DEFAULT;
}
3)When switching the Pin state in the following official Pinctrl sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();

Test Result:
1)The switch is completed as expectation, that is: component's
Pins configuration are changed according to the description in the
"wanted_state" group setting
2)The "desc->mux_usecount" of corresponding Pins in "c_group" is added without 
being
decreased, because the "desc" is for each physical pin while the "setting" is
for each setting node in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead of enabling
"c_grp_setting" in pinctrl-1, the desc->mux_usecount will be kept added without
any chance to be decreased.

According to the comments in the original code, only the setting, in old state
but not in new state, will be "disable"(calling pinmux_disable_setting), which
is correct logic but not intact. We still need consider case that the setting
is in both old state and new state.
We can do this in the following two ways:
1) Avoid "enable"(calling pinmux_enable_setting) the Same Pins setting 
repeatedly.
2) "Disable"(calling pinmux_disable_setting) the "Same Pins setting", actually
two setting instance, ahead of enabling them.

Analysis:
1.The solution 2# is better because it can avoid too much iteration.
2.If we disable all of the setting in the old state and one/ones of the 
setting(s) is/are
existed in the new state, the Pin's mux function change may happen when
some SoC vendors defined the "pinctrl-single,function-off" in their DTS file.
old_setting=>disabled_setting=>new_setting.
3.In the pinmux framework, when Pin state is switched, the setting in the old 
state should be
marked as "disabled".

Conclusion:
1.To Remove the HW disabling operation to above the glitch mentioned above.
2.Handle the issue mentioned above by disabling all of the setting in old
state and then enable the new setting in new state.

Signed-off-by: Fan Wu 
---
  drivers/pinctrl/core.c   |   18 +++---
  drivers/pinctrl/pinmux.c |4 
  2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe609..c97491a 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -993,25 +993,13 @@ int pinctrl_select_state(struct pinctrl *p, struct 
pinctrl_state *state)
 * may not be identical to the set of groups with a mux setting
 * in the new state. While this might be unusual, it's entirely
 * possible for the "user"-supplied mapping table to be written
-* that way. For each group that was configured in the old state
-* but not in the new state, this code puts that group into a
-* safe/disabled state.
+* that way. This code is used for each group that was
+* configured in the old state but not in the new state
 */
list_for_each_entry(setting, &p->state->settings, node) {
-   bool found = false;
if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
continue;
-   list_for_each_entry(setting2, &state->settings, node) {
-   if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
-   continue;
-   if (setting2->data.mux.group ==
-   setting->data.mux.group) {
-   found = true;
-   break;
-   }
-   }
-   if (!found)
-   pinmux_disable_setting(setting);
+ 

Re: [PATCH] i8k: increase fan limit to 3

[Flavio Leitner]

On Wed, May 21, 2014 at 08:32:24PM -0700, Guenter Roeck wrote:
> On 05/21/2014 07:19 PM, Flavio Leitner wrote:
> >From: Flavio Leitner 
> >
> >It is possible to increase left fan speed on a
> >DELL Precision 490n system up to 3.
> >
> > valuefan rpm
> >   1  35460
> >   2  64740
> >   3  78510
> >
> Guess the speed factor 30 doesn't apply here.

Those are actual rpms, not just a multiplied rpm. What I mean
is that you can hear the fan spinning up or down and the
temperature going up or down accordingly.

But even setting it to 3 is not enough to spin at maximum
speed. Anyway, now I can load the system without the FBDIMM
going above 75oC.

[...]
> I'll have to test this on older systems to make sure it doesn't cause 
> problems there.

Sure, let me know your findings. In meanwhile, I am using the patch here.
Thanks,
fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] of: Make of_find_node_by_path() handle /aliases

[Grant Likely]

On Tue, 20 May 2014 19:46:19 -0700, Frank Rowand  wrote:
> On 5/20/2014 7:41 PM, Frank Rowand wrote:
> < snip >
> > I will reply to this email with an additional patch that restores the
> > original behavior.
> < snip >
> From: Frank Rowand 
> 
> If __of_find_node_by_path() returns parent when the remaining portion of the
> path is "/" then the behavior of of_find_node_by_path() has changed.
> 
> Previously, adding an extraneous "/" on the end of a path would result
> in of_find_node_by_path() not finding a match.
> 
> Signed-off-by: Frank Rowand 
> ---
>  drivers/of/base.c |   13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> Index: b/drivers/of/base.c
> ===
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -778,7 +778,7 @@ static struct device_node *__of_find_nod
>   int len = strchrnul(path, '/') - path;
>  
>   if (!len)
> - return parent;
> + return NULL;
>  
>   for_each_child_of_node(parent, child) {
>   const char *name = strrchr(child->full_name, '/');
> @@ -813,6 +813,17 @@ struct device_node *of_find_node_by_path
>   struct property *pp;
>   unsigned long flags;
>  
> + if (strcmp(path, "/") == 0) {
> + raw_spin_lock_irqsave(&devtree_lock, flags);
> + for (; np; np = np->allnext) {
> + if (np->full_name && (of_node_cmp(np->full_name, path) 
> == 0)
> + && of_node_get(np))
> + break;
> + }
> + raw_spin_unlock_irqrestore(&devtree_lock, flags);
> + return np;
> + }
> +

Special case for the root node? Could use a comment, and of_allnodes
will already point to the root node so this could simply be:

if (strcmp(path, "/") == 0)
return of_node_get(np);

Here's a complete patch:

commit adc96db6c39ef7b895e75d30dbc69781f6443f1d
Author: Grant Likely 
Date:   Thu May 22 11:55:31 2014 +0900

fix trailing '/' case

diff --git a/drivers/of/base.c b/drivers/of/base.c
index c05a143b6a70..45ac44c8dfea 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -790,7 +790,7 @@ static struct device_node *__of_find_node_by_path(struct 
device_node *parent,
int len = strchrnul(path, '/') - path;
 
if (!len)
-   return parent;
+   return NULL;
 
__for_each_child_of_node(parent, child) {
const char *name = strrchr(child->full_name, '/');
@@ -820,10 +820,13 @@ static struct device_node *__of_find_node_by_path(struct 
device_node *parent,
  */
 struct device_node *of_find_node_by_path(const char *path)
 {
-   struct device_node *np = of_allnodes;
+   struct device_node *np = NULL;
struct property *pp;
unsigned long flags;
 
+   if (strcmp(path, "/") == 0)
+   return of_node_get(of_allnodes);
+
/* The path could begin with an alias */
if (*path != '/') {
char *p = strchrnul(path, '/');
@@ -833,7 +836,6 @@ struct device_node *of_find_node_by_path(const char *path)
if (!of_aliases)
return NULL;
 
-   np = NULL;
for_each_property_of_node(of_aliases, pp) {
if (strlen(pp->name) == len && !strncmp(pp->name, path, 
len)) {
np = of_find_node_by_path(pp->value);
@@ -847,6 +849,8 @@ struct device_node *of_find_node_by_path(const char *path)
 
/* Step down the tree matching path components */
raw_spin_lock_irqsave(&devtree_lock, flags);
+   if (!np)
+   np = of_node_get(of_allnodes);
while (np && *path == '/') {
path++; /* Increment past '/' delimiter */
np = __of_find_node_by_path(np, path);
diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index 10900b18fc06..aeb0b5c8b21d 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -42,9 +42,7 @@ static void __init of_selftest_find_node_by_name(void)
 
/* Test if trailing '/' works */
np = of_find_node_by_path("/testcase-data/");
-   selftest(np && !strcmp("/testcase-data", np->full_name),
-   "find /testcase-data/ failed\n");
-   of_node_put(np);
+   selftest(!np, "trailing '/' on /testcase-data/ should fail\n");
 
np = of_find_node_by_path("/testcase-data/phandle-tests/consumer-a");
selftest(np && !strcmp("/testcase-data/phandle-tests/consumer-a", 
np->full_name),
@@ -58,9 +56,7 @@ static void __init of_selftest_find_node_by_name(void)
 
/* Test if trailing '/' works on aliases */
np = of_find_node_by_path("testcase-alias/");
-   selftest(np && !strcmp("/testcase-data", np->full_name),
-   "find testcase-alias/ failed\n");
-   of_node_put(np);
+   selftest(!np, "trailing '/' on testcase-alias/ should fail\n");
 
np = of_find

Re: [PATCH] i8k: increase fan limit to 3

[Guenter Roeck]

On 05/21/2014 07:19 PM, Flavio Leitner wrote:

From: Flavio Leitner 

It is possible to increase left fan speed on a
DELL Precision 490n system up to 3.

 valuefan rpm
   1  35460
   2  64740
   3  78510


Guess the speed factor 30 doesn't apply here.


Signed-off-by: Flavio Leitner 
---
  drivers/char/i8k.c   | 4 ++--
  include/uapi/linux/i8k.h | 3 ++-
  2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index d915707..99180f0 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -519,7 +519,7 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
status = i8k_get_fan_status(index);
if (status < 0)
return -EIO;
-   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 255));
+   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 384));
  }

  static ssize_t i8k_hwmon_set_pwm(struct device *dev,
@@ -533,7 +533,7 @@ static ssize_t i8k_hwmon_set_pwm(struct device *dev,
err = kstrtoul(buf, 10, &val);
if (err)
return err;
-   val = clamp_val(DIV_ROUND_CLOSEST(val, 128), 0, 2);
+   val = clamp_val(DIV_ROUND_CLOSEST(val, 128), 0, 3);

mutex_lock(&i8k_mutex);
err = i8k_set_fan(index, val);
diff --git a/include/uapi/linux/i8k.h b/include/uapi/linux/i8k.h
index 1c45ba5..133d02f 100644
--- a/include/uapi/linux/i8k.h
+++ b/include/uapi/linux/i8k.h
@@ -34,7 +34,8 @@
  #define I8K_FAN_OFF   0
  #define I8K_FAN_LOW   1
  #define I8K_FAN_HIGH  2
-#define I8K_FAN_MAXI8K_FAN_HIGH
+#define I8K_FAN_TURBO  3
+#define I8K_FAN_MAXI8K_FAN_TURBO

  #define I8K_VOL_UP1
  #define I8K_VOL_DOWN  2



I'll have to test this on older systems to make sure it doesn't cause problems 
there.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] drivers/scsi/tmscsim.c: replace shift loop by ilog2

[Guenter Roeck]

On 05/21/2014 06:03 PM, Joe Perches wrote:

On Wed, 2014-05-21 at 17:28 -0700, Guenter Roeck wrote:

On Tue, May 20, 2014 at 10:06:42AM -0700, Joe Perches wrote:

On Tue, 2014-05-20 at 18:48 +0200, Fabian Frederick wrote:

Cc: Kurt Garloff 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
---
  drivers/scsi/tmscsim.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c

[]

@@ -1611,7 +1611,7 @@ dc390_Reselect( struct dc390_acb* pACB )
printk (KERN_ERR "DC390: Reselection must select host adapter: 
%02x!\n", lun);
  else
lun ^= 1 << pACB->pScsiHost->this_id; /* Mask AdapterID */
-id = 0; while (lun >>= 1) id++;
+id = ilog2(lun);
  /* Get LUN */
  lun = DC390_read8 (ScsiFifo);
  if (!(lun & IDENTIFY_BASE)) printk (KERN_ERR "DC390: Resel: Expect identify 
message!\n");


Hey Fabian.

You've submitted several of these now.

Have you gone through all of these to make sure
that the ilog2() uses are always using a
non-zero ?


Maybe I am missing something. Why not just use fls() ?


fls strains Andrew Morton's brain.

https://lkml.org/lkml/2014/5/19/771



:-).

On the other side fls(1) == 1 while ilog2(1) == 0. So some test is necessary 
anyway.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 0/6] rtmutex: Repair deadlock detector and cleanup

[Thomas Gleixner]

The first patch in the series makes the deadlock detector work again.

The second is removing the rtmutex tester as with the current
implementation of the lock chain walk plus the demise of the lock
steal mechanism and the BKL extra logic, we can now build a tester in
userspace via the futex syscall.

The other patches clarify and optimize the deadlock detection logic
and the lock chain walk mechanism.

Thanks,

Thomas



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 4/6] rtmutex: Confine deadlock logic to futex

[Thomas Gleixner]

The builtin tester is gone,, so the deadlock logic is now only
required for futexes.

Remove the extra arguments for the public functions and also for the
futex specific ones which get always called with deadlock detection
enabled.

Signed-off-by: Thomas Gleixner 
---
 include/linux/rtmutex.h |6 +---
 kernel/futex.c  |9 ++
 kernel/locking/rtmutex.c|   54 +---
 kernel/locking/rtmutex_common.h |7 ++---
 4 files changed, 37 insertions(+), 39 deletions(-)

Index: tip/include/linux/rtmutex.h
===
--- tip.orig/include/linux/rtmutex.h
+++ tip/include/linux/rtmutex.h
@@ -90,11 +90,9 @@ extern void __rt_mutex_init(struct rt_mu
 extern void rt_mutex_destroy(struct rt_mutex *lock);
 
 extern void rt_mutex_lock(struct rt_mutex *lock);
-extern int rt_mutex_lock_interruptible(struct rt_mutex *lock,
-   int detect_deadlock);
+extern int rt_mutex_lock_interruptible(struct rt_mutex *lock);
 extern int rt_mutex_timed_lock(struct rt_mutex *lock,
-   struct hrtimer_sleeper *timeout,
-   int detect_deadlock);
+  struct hrtimer_sleeper *timeout);
 
 extern int rt_mutex_trylock(struct rt_mutex *lock);
 
Index: tip/kernel/futex.c
===
--- tip.orig/kernel/futex.c
+++ tip/kernel/futex.c
@@ -1619,8 +1619,7 @@ retry_private:
this->pi_state = pi_state;
ret = rt_mutex_start_proxy_lock(&pi_state->pi_mutex,
this->rt_waiter,
-   this->task,
-   
RT_MUTEX_FULL_CHAINWALK);
+   this->task);
if (ret == 1) {
/* We got the lock. */
requeue_pi_wake_futex(this, &key2, hb2);
@@ -2240,8 +2239,7 @@ retry_private:
 * Block on the PI mutex:
 */
if (!trylock) {
-   ret = rt_mutex_timed_lock(&q.pi_state->pi_mutex, to,
- RT_MUTEX_FULL_CHAINWALK);
+   ret = __rt_mutex_timed_lock(&q.pi_state->pi_mutex, to);
} else {
ret = rt_mutex_trylock(&q.pi_state->pi_mutex);
/* Fixup the trylock return value: */
@@ -2564,8 +2562,7 @@ static int futex_wait_requeue_pi(u32 __u
 */
WARN_ON(!q.pi_state);
pi_mutex = &q.pi_state->pi_mutex;
-   ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter,
-RT_MUTEX_FULL_CHAINWALK);
+   ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter);
debug_rt_mutex_free_waiter(&rt_waiter);
 
spin_lock(q.lock_ptr);
Index: tip/kernel/locking/rtmutex.c
===
--- tip.orig/kernel/locking/rtmutex.c
+++ tip/kernel/locking/rtmutex.c
@@ -957,47 +957,53 @@ EXPORT_SYMBOL_GPL(rt_mutex_lock);
 /**
  * rt_mutex_lock_interruptible - lock a rt_mutex interruptible
  *
- * @lock:  the rt_mutex to be locked
- * @detect_deadlock:   deadlock detection on/off
+ * @lock:  the rt_mutex to be locked
  *
  * Returns:
- *  0  on success
- * -EINTR  when interrupted by a signal
- * -EDEADLKwhen the lock would deadlock (when deadlock detection is on)
+ *  0  on success
+ * -EINTR  when interrupted by a signal
  */
-int __sched rt_mutex_lock_interruptible(struct rt_mutex *lock,
-int detect_deadlock)
+int __sched rt_mutex_lock_interruptible(struct rt_mutex *lock)
 {
might_sleep();
 
return rt_mutex_fastlock(lock, TASK_INTERRUPTIBLE,
-detect_deadlock, rt_mutex_slowlock);
+RT_MUTEX_MIN_CHAINWALK, rt_mutex_slowlock);
 }
 EXPORT_SYMBOL_GPL(rt_mutex_lock_interruptible);
 
+/*
+ * Futex variant to allow full deadlock detection.
+ */
+int __rt_mutex_timed_lock(struct rt_mutex *lock,
+ struct hrtimer_sleeper *timeout)
+{
+   might_sleep();
+
+   return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout,
+  RT_MUTEX_FULL_CHAINWALK,
+  rt_mutex_slowlock);
+}
+
 /**
  * rt_mutex_timed_lock - lock a rt_mutex interruptible
  * the timeout structure is provided
  * by the caller
  *
- * @lock:  the rt_mutex to be locked
+ * @lock:  the rt_mutex to be locked
  * @timeout:   timeout structure or NULL (

[patch 3/6] rtmutex: Cleanup deadlock detector debug logic

[Thomas Gleixner]

The conditions under which deadlock detection is conducted are unclear
and undocumented.

Add constants instead of using 0/1 and provide a selection function
which hides the additional debug dependency from the calling code.

Add comments where needed.

Signed-off-by: Thomas Gleixner 
---
 kernel/futex.c  |   13 -
 kernel/locking/rtmutex.c|   37 ++---
 kernel/locking/rtmutex.h|7 ++-
 kernel/locking/rtmutex_common.h |   15 +++
 4 files changed, 59 insertions(+), 13 deletions(-)

Index: tip/kernel/futex.c
===
--- tip.orig/kernel/futex.c
+++ tip/kernel/futex.c
@@ -1619,7 +1619,8 @@ retry_private:
this->pi_state = pi_state;
ret = rt_mutex_start_proxy_lock(&pi_state->pi_mutex,
this->rt_waiter,
-   this->task, 1);
+   this->task,
+   
RT_MUTEX_FULL_CHAINWALK);
if (ret == 1) {
/* We got the lock. */
requeue_pi_wake_futex(this, &key2, hb2);
@@ -2238,9 +2239,10 @@ retry_private:
/*
 * Block on the PI mutex:
 */
-   if (!trylock)
-   ret = rt_mutex_timed_lock(&q.pi_state->pi_mutex, to, 1);
-   else {
+   if (!trylock) {
+   ret = rt_mutex_timed_lock(&q.pi_state->pi_mutex, to,
+ RT_MUTEX_FULL_CHAINWALK);
+   } else {
ret = rt_mutex_trylock(&q.pi_state->pi_mutex);
/* Fixup the trylock return value: */
ret = ret ? 0 : -EWOULDBLOCK;
@@ -2562,7 +2564,8 @@ static int futex_wait_requeue_pi(u32 __u
 */
WARN_ON(!q.pi_state);
pi_mutex = &q.pi_state->pi_mutex;
-   ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter, 1);
+   ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter,
+RT_MUTEX_FULL_CHAINWALK);
debug_rt_mutex_free_waiter(&rt_waiter);
 
spin_lock(q.lock_ptr);
Index: tip/kernel/locking/rtmutex.c
===
--- tip.orig/kernel/locking/rtmutex.c
+++ tip/kernel/locking/rtmutex.c
@@ -256,6 +256,25 @@ static void rt_mutex_adjust_prio(struct
 }
 
 /*
+ * Deadlock detection is conditional:
+ *
+ * If CONFIG_DEBUG_RT_MUTEXES=n, deadlock detection is only conducted
+ * if the detect argument is != 0.
+ *
+ * If CONFIG_DEBUG_RT_MUTEXES=y, deadlock detection is always
+ * conducted independent of the detect argument.
+ *
+ * If the waiter argument is NULL this indicates the deboost path and
+ * deadlock detection is disabled independent of the detect argument
+ * and the config settings.
+ */
+static int
+rt_mutex_cond_detect_deadlock(struct rt_mutex_waiter *waiter, int detect)
+{
+   return debug_rt_mutex_detect_deadlock(waiter, detect);
+}
+
+/*
  * Max number of times we'll walk the boosting chain:
  */
 int max_lock_depth = 1024;
@@ -289,8 +308,8 @@ static int rt_mutex_adjust_prio_chain(st
int detect_deadlock, ret = 0, depth = 0;
unsigned long flags;
 
-   detect_deadlock = debug_rt_mutex_detect_deadlock(orig_waiter,
-deadlock_detect);
+   detect_deadlock = rt_mutex_cond_detect_deadlock(orig_waiter,
+   deadlock_detect);
 
/*
 * The (de)boosting is a step by step approach with a lot of
@@ -569,9 +588,10 @@ static int task_blocks_on_rt_mutex(struc
if (owner->pi_blocked_on)
chain_walk = 1;
raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
-   }
-   else if (debug_rt_mutex_detect_deadlock(waiter, detect_deadlock))
+
+   } else if (rt_mutex_cond_detect_deadlock(waiter, detect_deadlock)) {
chain_walk = 1;
+   }
 
if (!chain_walk)
return 0;
@@ -674,7 +694,8 @@ static void remove_waiter(struct rt_mute
 
raw_spin_unlock(&lock->wait_lock);
 
-   rt_mutex_adjust_prio_chain(owner, 0, lock, NULL, current);
+   rt_mutex_adjust_prio_chain(owner, RT_MUTEX_MIN_CHAINWALK, lock,
+  NULL, current);
 
raw_spin_lock(&lock->wait_lock);
 }
@@ -702,7 +723,8 @@ void rt_mutex_adjust_pi(struct task_stru
 
/* gets dropped in rt_mutex_adjust_prio_chain()! */
get_task_struct(task);
-   rt_mutex_adjust_prio_chain(task, 0, NULL, NULL, task);
+   rt_mutex_adjust_prio_chain(task, RT_MUTEX_MIN_CHAINWALK, NULL, NULL,
+  task);
 

[patch 2/6] rtmutex: Remove builtin tester

[Thomas Gleixner]

The tester has been broken for quite some time. It's possible to fix
it, but the main reason for having it in the kernel was the lock steal
mechanism in the rtmutex code. That's gone, so we can implement a
stateful correctness tester just via the futex syscall.

Signed-off-by: Thomas Gleixner 
---
 kernel/locking/Makefile   |1 
 kernel/locking/rtmutex-tester.c   |  420 --
 kernel/locking/rtmutex.c  |2 
 kernel/locking/rtmutex_common.h   |   22 
 lib/Kconfig.debug |6 
 scripts/rt-tester/check-all.sh|   22 
 scripts/rt-tester/rt-tester.py|  220 -
 scripts/rt-tester/t2-l1-2rt-sameprio.tst  |   94 
 scripts/rt-tester/t2-l1-pi.tst|   77 ---
 scripts/rt-tester/t2-l1-signal.tst|   72 ---
 scripts/rt-tester/t2-l2-2rt-deadlock.tst  |   84 ---
 scripts/rt-tester/t3-l1-pi-1rt.tst|   87 ---
 scripts/rt-tester/t3-l1-pi-2rt.tst|   88 ---
 scripts/rt-tester/t3-l1-pi-3rt.tst|   87 ---
 scripts/rt-tester/t3-l1-pi-signal.tst |   93 ---
 scripts/rt-tester/t3-l1-pi-steal.tst  |   91 ---
 scripts/rt-tester/t3-l2-pi.tst|   87 ---
 scripts/rt-tester/t4-l2-pi-deboost.tst|  118 -
 scripts/rt-tester/t5-l4-pi-boost-deboost-setsched.tst |  178 ---
 scripts/rt-tester/t5-l4-pi-boost-deboost.tst  |  138 -
 20 files changed, 1 insertion(+), 1986 deletions(-)

Index: tip/kernel/locking/Makefile
===
--- tip.orig/kernel/locking/Makefile
+++ tip/kernel/locking/Makefile
@@ -18,7 +18,6 @@ obj-$(CONFIG_SMP) += lglock.o
 obj-$(CONFIG_PROVE_LOCKING) += spinlock.o
 obj-$(CONFIG_RT_MUTEXES) += rtmutex.o
 obj-$(CONFIG_DEBUG_RT_MUTEXES) += rtmutex-debug.o
-obj-$(CONFIG_RT_MUTEX_TESTER) += rtmutex-tester.o
 obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o
 obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock_debug.o
 obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
Index: tip/kernel/locking/rtmutex-tester.c
===
--- tip.orig/kernel/locking/rtmutex-tester.c
+++ /dev/null
@@ -1,420 +0,0 @@
-/*
- * RT-Mutex-tester: scriptable tester for rt mutexes
- *
- * started by Thomas Gleixner:
- *
- *  Copyright (C) 2006, Timesys Corp., Thomas Gleixner 
- *
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "rtmutex.h"
-
-#define MAX_RT_TEST_THREADS8
-#define MAX_RT_TEST_MUTEXES8
-
-static spinlock_t rttest_lock;
-static atomic_t rttest_event;
-
-struct test_thread_data {
-   int opcode;
-   int opdata;
-   int mutexes[MAX_RT_TEST_MUTEXES];
-   int event;
-   struct device   dev;
-};
-
-static struct test_thread_data thread_data[MAX_RT_TEST_THREADS];
-static struct task_struct *threads[MAX_RT_TEST_THREADS];
-static struct rt_mutex mutexes[MAX_RT_TEST_MUTEXES];
-
-enum test_opcodes {
-   RTTEST_NOP = 0,
-   RTTEST_SCHEDOT, /* 1 Sched other, data = nice */
-   RTTEST_SCHEDRT, /* 2 Sched fifo, data = prio */
-   RTTEST_LOCK,/* 3 Lock uninterruptible, data = lockindex */
-   RTTEST_LOCKNOWAIT,  /* 4 Lock uninterruptible no wait in wakeup, 
data = lockindex */
-   RTTEST_LOCKINT, /* 5 Lock interruptible, data = lockindex */
-   RTTEST_LOCKINTNOWAIT,   /* 6 Lock interruptible no wait in wakeup, data 
= lockindex */
-   RTTEST_LOCKCONT,/* 7 Continue locking after the wakeup delay */
-   RTTEST_UNLOCK,  /* 8 Unlock, data = lockindex */
-   /* 9, 10 - reserved for BKL commemoration */
-   RTTEST_SIGNAL = 11, /* 11 Signal other test thread, data = thread 
id */
-   RTTEST_RESETEVENT = 98, /* 98 Reset event counter */
-   RTTEST_RESET = 99,  /* 99 Reset all pending operations */
-};
-
-static int handle_op(struct test_thread_data *td, int lockwakeup)
-{
-   int i, id, ret = -EINVAL;
-
-   switch(td->opcode) {
-
-   case RTTEST_NOP:
-   return 0;
-
-   case RTTEST_LOCKCONT:
-   td->mutexes[td->opdata] = 1;
-   td->event = atomic_add_return(1, &rttest_event);
-   return 0;
-
-   case RTTEST_RESET:
-   for (i = 0; i < MAX_RT_TEST_MUTEXES; i++) {
-   if (td->mutexes[i] == 4) {
-   rt_mutex_unlock(&mutexes[i]);
-   td->mutexes[i] = 0;
-   }
-   }
-   return 0;
-
-   case RTTEST_RESETEVENT:
-   atomic_set(&rttest_event, 0);
-   

[patch 5/6] rtmutex: Clarify the lock chain walk

[Thomas Gleixner]

Add a separate local variable for the boost/deboost logic to make the
code more readable. Add comments where appropriate.

Signed-off-by: Thomas Gleixner 
---
 kernel/locking/rtmutex.c |   50 +++
 1 file changed, 42 insertions(+), 8 deletions(-)

Index: tip/kernel/locking/rtmutex.c
===
--- tip.orig/kernel/locking/rtmutex.c
+++ tip/kernel/locking/rtmutex.c
@@ -302,9 +302,10 @@ static int rt_mutex_adjust_prio_chain(st
  struct rt_mutex_waiter *orig_waiter,
  struct task_struct *top_task)
 {
-   struct rt_mutex *lock;
struct rt_mutex_waiter *waiter, *top_waiter = orig_waiter;
+   struct rt_mutex_waiter *prerequeue_top_waiter;
int detect_deadlock, ret = 0, depth = 0;
+   struct rt_mutex *lock;
unsigned long flags;
 
detect_deadlock = rt_mutex_cond_detect_deadlock(orig_waiter,
@@ -379,6 +380,11 @@ static int rt_mutex_adjust_prio_chain(st
}
 
lock = waiter->lock;
+   /*
+* We need to trylock here as we are holding task->pi_lock,
+* which is the reverse lock order versus the other rtmutex
+* operations.
+*/
if (!raw_spin_trylock(&lock->wait_lock)) {
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
cpu_relax();
@@ -398,7 +404,11 @@ static int rt_mutex_adjust_prio_chain(st
goto out_unlock_pi;
}
 
-   top_waiter = rt_mutex_top_waiter(lock);
+   /*
+* Store the top waiter before doing any requeue operation. We
+* need it for the boost/deboost decision below.
+*/
+   prerequeue_top_waiter = rt_mutex_top_waiter(lock);
 
/* Requeue the waiter */
rt_mutex_dequeue(lock, waiter);
@@ -407,13 +417,18 @@ static int rt_mutex_adjust_prio_chain(st
 
/* Release the task */
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
+
+   /*
+* We must abort the chain walk if there is no lock owner even
+* in the dead lock detection case, as we have nothing to
+* follow here.
+*/
if (!rt_mutex_owner(lock)) {
/*
 * If the requeue above changed the top waiter, then we need
 * to wake the new top waiter up to try to get the lock.
 */
-
-   if (top_waiter != rt_mutex_top_waiter(lock))
+   if (prerequeue_top_waiter != rt_mutex_top_waiter(lock))
wake_up_process(rt_mutex_top_waiter(lock)->task);
raw_spin_unlock(&lock->wait_lock);
goto out_put_task;
@@ -426,17 +441,31 @@ static int rt_mutex_adjust_prio_chain(st
raw_spin_lock_irqsave(&task->pi_lock, flags);
 
if (waiter == rt_mutex_top_waiter(lock)) {
-   /* Boost the owner */
-   rt_mutex_dequeue_pi(task, top_waiter);
+   /*
+* The waiter became the top waiter on the
+* lock. Remove the previous top waiter from the tasks
+* pi waiters list and add waiter to it.
+*/
+   rt_mutex_dequeue_pi(task, prerequeue_top_waiter);
rt_mutex_enqueue_pi(task, waiter);
__rt_mutex_adjust_prio(task);
 
-   } else if (top_waiter == waiter) {
-   /* Deboost the owner */
+   } else if (prerequeue_top_waiter == waiter) {
+   /*
+* The waiter was the top waiter on the lock. Remove
+* waiter from the tasks pi waiters list and add the
+* new top waiter to it.
+*/
rt_mutex_dequeue_pi(task, waiter);
waiter = rt_mutex_top_waiter(lock);
rt_mutex_enqueue_pi(task, waiter);
__rt_mutex_adjust_prio(task);
+
+   } else {
+   /*
+* Nothing changed. No need to do any priority
+* adjustment.
+*/
}
 
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
@@ -444,6 +473,11 @@ static int rt_mutex_adjust_prio_chain(st
top_waiter = rt_mutex_top_waiter(lock);
raw_spin_unlock(&lock->wait_lock);
 
+   /*
+* If the current waiter is not the top waiter on the lock,
+* then we can stop the chain walk here if we are not in full
+* deadlock detection mode.
+*/
if (!detect_deadlock && waiter != top_waiter)
goto out_put_task;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] rtmutex: Avoid pointless requeueing in the deadlock detection chain walk

[Thomas Gleixner]

In case the dead lock detector is enabled we follow the lock chain to
the end in rt_mutex_adjust_prio_chain, even if we could stop earlier
due to the priority/waiter constellation.

But once we are not longer the top priority waiter in a certain step
or the task holding the lock has already the same priority then there
is no point in dequeing and enqueing along the lock chain as there is
no change at all.

So stop the queueing at this point.

Signed-off-by: Thomas Gleixner 
---
 kernel/locking/rtmutex.c |   87 +--
 1 file changed, 54 insertions(+), 33 deletions(-)

Index: tip/kernel/locking/rtmutex.c
===
--- tip.orig/kernel/locking/rtmutex.c
+++ tip/kernel/locking/rtmutex.c
@@ -307,6 +307,7 @@ static int rt_mutex_adjust_prio_chain(st
int detect_deadlock, ret = 0, depth = 0;
struct rt_mutex *lock;
unsigned long flags;
+   bool requeue = true;
 
detect_deadlock = rt_mutex_cond_detect_deadlock(orig_waiter,
deadlock_detect);
@@ -366,8 +367,11 @@ static int rt_mutex_adjust_prio_chain(st
if (!task_has_pi_waiters(task))
goto out_unlock_pi;
 
-   if (!detect_deadlock && top_waiter != task_top_pi_waiter(task))
-   goto out_unlock_pi;
+   if (top_waiter != task_top_pi_waiter(task)) {
+   if (!detect_deadlock)
+   goto out_unlock_pi;
+   requeue = false;
+   }
}
 
/*
@@ -377,6 +381,7 @@ static int rt_mutex_adjust_prio_chain(st
if (waiter->prio == task->prio) {
if (!detect_deadlock)
goto out_unlock_pi;
+   requeue = false;
}
 
lock = waiter->lock;
@@ -410,10 +415,16 @@ static int rt_mutex_adjust_prio_chain(st
 */
prerequeue_top_waiter = rt_mutex_top_waiter(lock);
 
-   /* Requeue the waiter */
-   rt_mutex_dequeue(lock, waiter);
-   waiter->prio = task->prio;
-   rt_mutex_enqueue(lock, waiter);
+   /*
+* Requeue the waiter, if we are in the boost/deboost
+* operation and not just following the lock chain for
+* deadlock detection.
+*/
+   if (requeue) {
+   rt_mutex_dequeue(lock, waiter);
+   waiter->prio = task->prio;
+   rt_mutex_enqueue(lock, waiter);
+   }
 
/* Release the task */
raw_spin_unlock_irqrestore(&task->pi_lock, flags);
@@ -428,7 +439,8 @@ static int rt_mutex_adjust_prio_chain(st
 * If the requeue above changed the top waiter, then we need
 * to wake the new top waiter up to try to get the lock.
 */
-   if (prerequeue_top_waiter != rt_mutex_top_waiter(lock))
+   if (requeue &&
+   prerequeue_top_waiter != rt_mutex_top_waiter(lock))
wake_up_process(rt_mutex_top_waiter(lock)->task);
raw_spin_unlock(&lock->wait_lock);
goto out_put_task;
@@ -440,32 +452,41 @@ static int rt_mutex_adjust_prio_chain(st
get_task_struct(task);
raw_spin_lock_irqsave(&task->pi_lock, flags);
 
-   if (waiter == rt_mutex_top_waiter(lock)) {
-   /*
-* The waiter became the top waiter on the
-* lock. Remove the previous top waiter from the tasks
-* pi waiters list and add waiter to it.
-*/
-   rt_mutex_dequeue_pi(task, prerequeue_top_waiter);
-   rt_mutex_enqueue_pi(task, waiter);
-   __rt_mutex_adjust_prio(task);
-
-   } else if (prerequeue_top_waiter == waiter) {
-   /*
-* The waiter was the top waiter on the lock. Remove
-* waiter from the tasks pi waiters list and add the
-* new top waiter to it.
-*/
-   rt_mutex_dequeue_pi(task, waiter);
-   waiter = rt_mutex_top_waiter(lock);
-   rt_mutex_enqueue_pi(task, waiter);
-   __rt_mutex_adjust_prio(task);
-
-   } else {
-   /*
-* Nothing changed. No need to do any priority
-* adjustment.
-*/
+   /*
+* In case we are just following the lock chain for deadlock
+* detection we can avoid the whole requeue and priority
+* adjustment business.
+*/
+   if (requeue) {
+   if (waiter == rt_mutex_top_waiter(lock)) {
+   /*
+* The waiter became the top waiter on the
+* lock. Remove the previous top waiter from
+* the tasks pi waiters list and add waiter to
+* it.
+*/
+ 

[patch 1/6] rtmutex: Fix deadlock detector for real

[Thomas Gleixner]

The current deadlock detection logic does not work reliably due to the
following early exit path:

/*
 * Drop out, when the task has no waiters. Note,
 * top_waiter can be NULL, when we are in the deboosting
 * mode!
 */
if (top_waiter && (!task_has_pi_waiters(task) ||
   top_waiter != task_top_pi_waiter(task)))
goto out_unlock_pi;

So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.

So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.

Simple fix: Continue the chain walk, when deadlock detection is
enabled.

Signed-off-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
---
 kernel/locking/rtmutex.c |   27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

Index: tip/kernel/locking/rtmutex.c
===
--- tip.orig/kernel/locking/rtmutex.c
+++ tip/kernel/locking/rtmutex.c
@@ -343,16 +343,22 @@ static int rt_mutex_adjust_prio_chain(st
 * top_waiter can be NULL, when we are in the deboosting
 * mode!
 */
-   if (top_waiter && (!task_has_pi_waiters(task) ||
-  top_waiter != task_top_pi_waiter(task)))
-   goto out_unlock_pi;
+   if (top_waiter) {
+   if (!task_has_pi_waiters(task))
+   goto out_unlock_pi;
+
+   if (!detect_deadlock && top_waiter != task_top_pi_waiter(task))
+   goto out_unlock_pi;
+   }
 
/*
 * When deadlock detection is off then we check, if further
 * priority adjustment is necessary.
 */
-   if (!detect_deadlock && waiter->prio == task->prio)
-   goto out_unlock_pi;
+   if (waiter->prio == task->prio) {
+   if (!detect_deadlock)
+   goto out_unlock_pi;
+   }
 
lock = waiter->lock;
if (!raw_spin_trylock(&lock->wait_lock)) {
@@ -361,7 +367,12 @@ static int rt_mutex_adjust_prio_chain(st
goto retry;
}
 
-   /* Deadlock detection */
+   /*
+* Deadlock detection. If the lock is the same as the original
+* lock which caused us to walk the lock chain or if the
+* current lock is owned by the task which initiated the chain
+* walk, we detected a deadlock.
+*/
if (lock == orig_lock || rt_mutex_owner(lock) == top_task) {
debug_rt_mutex_deadlock(deadlock_detect, orig_waiter, lock);
raw_spin_unlock(&lock->wait_lock);
@@ -527,6 +538,10 @@ static int task_blocks_on_rt_mutex(struc
unsigned long flags;
int chain_walk = 0, res;
 
+   /* Early deadlock detection */
+   if (detect_deadlock && owner == task)
+   return -EDEADLK;
+
raw_spin_lock_irqsave(&task->pi_lock, flags);
__rt_mutex_adjust_prio(task);
waiter->task = task;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm: dma-mapping: fallback allocation for cma failure

[Michal Nazarewicz]

On Thu, May 22 2014, Gioh Kim  wrote:
> I appreciate your comments.
> The previous patch was ugly. But now it's beautiful! Just 3 lines!
>
> I'm not familiar with kernel patch process.
> Can I have your name at Signed-off-by: line?
> What tag do I have to write your name in?

My Signed-off-by line does not apply in this case.
Documentation/SubmittingPatches describes what Signed-off-by means.

I've added Acked-by below.  You may want to resend this patch using
“git-send-email”.

> - 8< 
> --
>  From 135c986cfaa5a7291519308b3d47e58bf9f5af25 Mon Sep 17 00:00:00 2001
> From: Gioh Kim 
> Date: Tue, 20 May 2014 14:16:20 +0900
> Subject: [PATCH] arm: dma-mapping: add checking cma area initialized
>
> If CMA is turned on and CMA size is set to zero, kernel should
> behave as if CMA was not enabled at compile time.
> Every dma allocation should check existence of cma area
> before requesting memory.
>
> Signed-off-by: Gioh Kim 
> Signed-off-by: Joonsoo Kim 

Acked-by: Michal Nazarewicz 

But like before, if someone with more ARM knowledge could take a look at
it, it would be awesome.

> ---
>   arch/arm/mm/dma-mapping.c |7 ---
>   1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 18e98df..9173a13 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -390,12 +390,13 @@ static int __init atomic_pool_init(void)
>  if (!pages)
>  goto no_pages;
>
> -   if (IS_ENABLED(CONFIG_DMA_CMA))
> +   if (dev_get_cma_area(NULL))
>  ptr = __alloc_from_contiguous(NULL, pool->size, prot, &page,
>atomic_pool_init);
>  else
>  ptr = __alloc_remap_buffer(NULL, pool->size, gfp, prot, 
> &page,
> atomic_pool_init);
> +
>  if (ptr) {
>  int i;
>
> @@ -701,7 +702,7 @@ static void *__dma_alloc(struct device *dev, size_t size, 
> dma_addr_t *handle,
>  addr = __alloc_simple_buffer(dev, size, gfp, &page);
>  else if (!(gfp & __GFP_WAIT))
>  addr = __alloc_from_pool(size, &page);
> -   else if (!IS_ENABLED(CONFIG_DMA_CMA))
> +   else if (!dev_get_cma_area(dev))
>  addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, 
> caller);
>  else
>  addr = __alloc_from_contiguous(dev, size, prot, &page, 
> caller);
> @@ -790,7 +791,7 @@ static void __arm_dma_free(struct device *dev, size_t 
> size, void *cpu_addr,
>  __dma_free_buffer(page, size);
>  } else if (__free_from_pool(cpu_addr, size)) {
>  return;
> -   } else if (!IS_ENABLED(CONFIG_DMA_CMA)) {
> +   } else if (!dev_get_cma_area(dev)) {
>  __dma_free_remap(cpu_addr, size);
>  __dma_free_buffer(page, size);
>  } else {
> --
> 1.7.9.5

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: s5pv210: remove unused call of pr_err()

[Sachin Kamat]

On 22 May 2014 01:23, Paul Bolle  wrote:
> A call of pr_err() was added in v3.1. It was guarded by a check for
> CONFIG_PM_VERBOSE. The Kconfig symbol PM_VERBOSE was removed in v3.0. So
> this call of pr_err() has never been used. Remove it.
>
> Signed-off-by: Paul Bolle 
> ---
> Untested.
>
>  drivers/cpufreq/s5pv210-cpufreq.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c 
> b/drivers/cpufreq/s5pv210-cpufreq.c
> index ab2c1a40d437..0873729135df 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -175,10 +175,6 @@ static int s5pv210_target(struct cpufreq_policy *policy, 
> unsigned int index)
> mutex_lock(&set_freq_lock);
>
> if (no_cpufreq_access) {
> -#ifdef CONFIG_PM_VERBOSE
> -   pr_err("%s:%d denied access to %s as it is disabled"
> -   "temporarily\n", __FILE__, __LINE__, 
> __func__);
> -#endif

The config symbol itself is not defined and hence could be removed.
However I feel, the
error message could be retained after trimming down the arguments a bit.

-- 
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

compaction is still too expensive for thp (was: [PATCH v2] mm, compaction: properly signal and act upon lock and need_sched() contention)

[David Rientjes]

On Fri, 16 May 2014, Vlastimil Babka wrote:

> Compaction uses compact_checklock_irqsave() function to periodically check for
> lock contention and need_resched() to either abort async compaction, or to
> free the lock, schedule and retake the lock. When aborting, cc->contended is
> set to signal the contended state to the caller. Two problems have been
> identified in this mechanism.
> 
> First, compaction also calls directly cond_resched() in both scanners when no
> lock is yet taken. This call either does not abort async compaction, or set
> cc->contended appropriately. This patch introduces a new 
> compact_should_abort()
> function to achieve both. In isolate_freepages(), the check frequency is
> reduced to once by SWAP_CLUSTER_MAX pageblocks to match what the migration
> scanner does in the preliminary page checks. In case a pageblock is found
> suitable for calling isolate_freepages_block(), the checks within there are
> done on higher frequency.
> 
> Second, isolate_freepages() does not check if isolate_freepages_block()
> aborted due to contention, and advances to the next pageblock. This violates
> the principle of aborting on contention, and might result in pageblocks not
> being scanned completely, since the scanning cursor is advanced. This patch
> makes isolate_freepages_block() check the cc->contended flag and abort.
> 
> In case isolate_freepages() has already isolated some pages before aborting
> due to contention, page migration will proceed, which is OK since we do not
> want to waste the work that has been done, and page migration has own checks
> for contention. However, we do not want another isolation attempt by either
> of the scanners, so cc->contended flag check is added also to
> compaction_alloc() and compact_finished() to make sure compaction is aborted
> right after the migration.
> 

We have a pretty significant problem with async compaction related to thp 
faults and it's not limited to this patch but was intended to be addressed 
in my series as well.  Since this is the latest patch to be proposed for 
aborting async compaction when it's too expensive, it's probably a good 
idea to discuss it here.

With -mm, it turns out that while egregious thp fault latencies were 
reduced, faulting 64MB of memory backed by thp on a fragmented 128GB 
machine can result in latencies of 1-3s for the entire 64MB.  Collecting 
compaction stats from older kernels that give more insight into 
regressions, one such incident is as follows.

Baseline:
compact_blocks_moved 8181986
compact_pages_moved 6549560
compact_pagemigrate_failed 1612070
compact_stall 101959
compact_fail 100895
compact_success 1064

5s later:
compact_blocks_moved 8182447
compact_pages_moved 6550286
compact_pagemigrate_failed 1612092
compact_stall 102023
compact_fail 100959
compact_success 1064

This represents faulting two 64MB ranges of anonymous memory.  As you can 
see, it results in falling back to 4KB pages because all 64 faults of 
hugepages ends up triggering compaction and failing to allocate.  Over the 
64 async compactions, we scan on average 7.2 pageblocks per call, 
successfully migrate 11.3 pages per call, and fail migrating 0.34 pages 
per call.

If each async compaction scans 7.2 pageblocks per call, it would have to 
be called 9103 times to scan all memory on this 128GB machine.  We're 
simply not scanning enough memory as a result of ISOLATE_ABORT due to 
need_resched().

So the net result is that -mm is much better than Linus's tree, where such 
faulting of 64MB ranges could stall 8-9s, but we're still very expensive.  
We may need to consider scanning more memory on a single call to async 
compaction even when need_resched() and if we are unsuccessful in 
allocating a hugepage to defer async compaction in subsequent calls up to 
1 << COMPACT_MAX_DEFER_SHIFT.  Today, we defer on sync compaction but that 
is now never done for thp faults since it is reliant solely on async 
compaction.

I have a few improvements in mind, but thought it would be better to 
get feedback on it first because it's a substantial rewrite of the 
pageblock migration:

 - For all async compaction, avoid migrating memory unless enough 
   contiguous memory is migrated to allow a cc->order allocation.  This
   would remove the COMPACT_CLUSTER_MAX restriction on pageblock
   compaction and keep pages on the cc->migratepages list between
   calls to isolate_migratepages_range().

   When an unmigratable page is encountered or memory hole is found,
   put all pages on cc->migratepages back on the lru lists unless
   cc->nr_migratepages >= (1 << cc->order).  Otherwise, migrate when
   enough contiguous memory has been isolated.

 - Remove the need_resched() checks entirely from compaction and
   consider only doing a set amount of scanning for each call, such
   as 1GB per call.

   If there is contention on zone->lru_lock, then we can still abort
   to avoid excessive stalls, but need_resched() is a poor heuristic
   to determine when asyn

[git pull] drm radeon and nouveau fixes

[Dave Airlie]

Hi Linus,

Fixes for the other big two, the radeon VCE one is large but it fixes some 
userspace triggerable issues, otherwise its blackscreens and oopses,

nouveau fixes a bleeding laptop panel issue when displayport is used 
sometimes,

Dave.

The following changes since commit 4b660a7f5c8099d88d1a43d8ae138965112592c7:

  Linux 3.15-rc6 (2014-05-22 06:42:02 +0900)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 77c01bef72a5ce5cb24adae6066ed81a52004d30:

  Merge branch 'drm-fixes-3.15' of 
git://people.freedesktop.org/~deathsimple/linux into drm-fixes (2014-05-22 
09:15:57 +1000)



Alex Deucher (4):
  drm/radeon: fix DCE83 check for mullins
  drm/radeon: handle non-VGA class pci devices with ATRM
  drm/radeon: fix register typo on si
  drm/radeon/pm: don't allow debugfs/sysfs access when PX card is off (v2)

Ben Skeggs (1):
  drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setup

Christian König (4):
  drm/radeon: also try GART for CPU accessed buffers
  drm/radeon: fix page directory update size estimation
  drm/radeon: fix buffer placement under memory pressure v2
  drm/radeon: fix typo in finding PLL params

Dave Airlie (2):
  Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge branch 'drm-fixes-3.15' of 
git://people.freedesktop.org/~deathsimple/linux into drm-fixes

Jérôme Glisse (1):
  drm/radeon: avoid segfault on device open when accel is not working.

Leo Liu (1):
  drm/radeon: check VCE relocation buffer range v3

Martin Peres (1):
  drm/nvd9/therm: handle another kind of PWM fan

 drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c  |   2 +-
 drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c |   1 +
 drivers/gpu/drm/radeon/radeon.h  |   6 +-
 drivers/gpu/drm/radeon/radeon_bios.c |  14 +++
 drivers/gpu/drm/radeon/radeon_display.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_kms.c  |  55 +-
 drivers/gpu/drm/radeon/radeon_object.c   |  40 ---
 drivers/gpu/drm/radeon/radeon_pm.c   |  42 +++-
 drivers/gpu/drm/radeon/radeon_vce.c  | 130 +--
 drivers/gpu/drm/radeon/radeon_vm.c   |   2 +-
 drivers/gpu/drm/radeon/sid.h |   4 +-
 11 files changed, 218 insertions(+), 80 deletions(-)

[PATCH v2] pinctrl: add params in disable_setting for different usage

[fwu]

From: Fan Wu 

What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
  calling pinctrl_select_state
2.Remove the HW disable operation in in pinmux_disable_setting function.

The reason why to do this is that:
1.To avoid duplicated enable_setting operation without disabling operation
  which will let Pin's desc->mux_usecount keep being added.
2.The HW pin disable operation is not useful for most of the vendors' platform.
  And this avoid the HW glitch after using the item 1# modification.

In the following case, the issue can be reproduced:
1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
"default" state
2)The Pin setting configuration in DTS node may be like the following one:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&a_grp_setting &c_grp_setting>;
pinctrl-1 = <&b_grp_setting &c_grp_setting>;
}
The "c_grp_setting" config node is totaly same, maybe like following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
MFP_DEFAULT;
}
3)When switching the Pin state in the following official Pinctrl sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();

Test Result:
1)The switch is completed as expectation, that is: component's
Pins configuration are changed according to the description in the
"wanted_state" group setting
2)The "desc->mux_usecount" of corresponding Pins in "c_group" is added without 
being
decreased, because the "desc" is for each physical pin while the "setting" is
for each setting node in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead of enabling
"c_grp_setting" in pinctrl-1, the desc->mux_usecount will be kept added without
any chance to be decreased.

According to the comments in the original code, only the setting, in old state
but not in new state, will be "disable"(calling pinmux_disable_setting), which
is correct logic but not intact. We still need consider case that the setting
is in both old state and new state.
We can do this in the following two ways:
1) Avoid "enable"(calling pinmux_enable_setting) the Same Pins setting 
repeatedly.
2) "Disable"(calling pinmux_disable_setting) the "Same Pins setting", actually
two setting instance, ahead of enabling them.

Analysis:
1.The solution 2# is better because it can avoid too much iteration.
2.If we disable all of the setting in the old state and one/ones of the 
setting(s) is/are
existed in the new state, the Pin's mux function change may happen when
some SoC vendors defined the "pinctrl-single,function-off" in their DTS file.
old_setting=>disabled_setting=>new_setting.
3.In the pinmux framework, when Pin state is switched, the setting in the old 
state should be
marked as "disabled".

Conclusion:
1.To Remove the HW disabling operation to above the glitch mentioned above.
2.Handle the issue mentioned above by disabling all of the setting in old
state and then enable the new setting in new state.

Signed-off-by: Fan Wu 
---
 drivers/pinctrl/core.c   |   18 +++---
 drivers/pinctrl/pinmux.c |4 
 2 files changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe609..c97491a 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -993,25 +993,13 @@ int pinctrl_select_state(struct pinctrl *p, struct 
pinctrl_state *state)
 * may not be identical to the set of groups with a mux setting
 * in the new state. While this might be unusual, it's entirely
 * possible for the "user"-supplied mapping table to be written
-* that way. For each group that was configured in the old state
-* but not in the new state, this code puts that group into a
-* safe/disabled state.
+* that way. This code is used for each group that was
+* configured in the old state but not in the new state
 */
list_for_each_entry(setting, &p->state->settings, node) {
-   bool found = false;
if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
continue;
-   list_for_each_entry(setting2, &state->settings, node) {
-   if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
-   continue;
-   if (setting2->data.mux.group ==
-   setting->data.mux.group) {
-   found = true;
-   break;
-   }
-   }
-   if (!found)
-   pinmux_disable_setting(setting);
+   pinmux_disable_setting(setting);
 

RE: /proc/stat vs. failed order-4 allocation

[Elliott, Robert (Server Storage)]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Wednesday, May 21, 2014 9:32 AM
> To: Heiko Carstens
> Cc: Andrew Morton; KAMEZAWA Hiroyuki; Andrea Righi; Eric Dumazet; linux-
> ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; Hendrik Brueckner;
> Thorsten Diehl
> Subject: Re: /proc/stat vs. failed order-4 allocation
> 
> On Wed, May 21, 2014 at 02:25:21PM +0200, Heiko Carstens wrote:
> > Hi all,
> >
> > I'm just wondering why /proc/stat is a single_open() seq_file and not a
> > regular seq_file with an iterator (say 48 online cpus for each iteration
> > or something similar).
> 
> Probably because no one sent a patch for it. I'm pretty sure it used the
> even more horrible old proc ops before and was converted in batch with
> various other files.

https://lkml.org/lkml/2012/1/20/153 worried about performance and led to 
the current code; the reply in https://lkml.org/lkml/2012/1/23/41 
discussed using seq_file, but that idea was rejected at the time.

Be careful about losing consistency of the information for the CPUs.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/13] ARM/DT: edma: IP configuration from hardware and cleanups

[Vinod Koul]

On Tue, May 20, 2014 at 04:26:09PM +0530, Sekhar Nori wrote:
> On Monday 19 May 2014 10:23 PM, Peter Ujfalusi wrote:
> > On 05/19/2014 04:06 PM, Sekhar Nori wrote:
> >> On Friday 16 May 2014 05:47 PM, Peter Ujfalusi wrote:
> >>> Hi,
> >>>
> >>> Changes since v2:
> >>> - Comments from Sekhar and Arnd has been addressed best as I could.
> >>> - Use the CCCFG information in all cases instead of pdata provided 
> >>> information
> >>> - To achieve this I needed to do a bit more cleanup in this series
> >>> - In the documentation patch, retrain the old properties for reference
> >>> - Cleanups in the old davinci board files and removing edma_soc_info 
> >>> members
> >>>
> >>> Changes sicne v1:
> >>> - added missing patch to remove the memset from edma_of_parse_dt()
> >>>
> >>> We are requesting redundant information via DT for the driver since the 
> >>> very same
> >>> data is available in the HW: by reading and decoding the content of CCCFG
> >>> register we can get:
> >>> Number of channels: NUM_DMACH
> >>> Number of regions: NUM_REGN
> >>> Number of slots (PaRAM sets): NUM_PAENTRY
> >>> Number of TC/EQ: NUM_EVQUE
> >>>
> >>> So these does not need to be provided by the DT binding.
> >>>
> >>> The driver will no longer look for these properties from DT and they can 
> >>> be
> >>> removed from the binding documentation and from the dtsi files as well.
> >>> The change will not introduce regression when new kernel is booted using 
> >>> older
> >>> DTB (since we just ignore the mentioned properties).
> >>
> >> Applied all patches and pushed to branch v3.16/edma of:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
> >>
> >> Since the patches did not apply cleanly, please verify. I tested on
> >> DA850 EVM using MMC/SD as EDMA user.
> > 
> > The patches in this series looks OK in your branch.
> > However I can not find the following commits in there, which I have in 
> > linux-next:
> > c689a7b79c28 Merge remote-tracking branch 'slave-dma/next'
> > cdae05a0f0f7 dmaengine: edma: Make reading the position of active channels 
> > work
> > cf7eb979116c ARM: common: edma: Fix xbar mapping
> > 232b223d8281 dmaengine: edma: Set DMA_CYCLIC capability flag
> > 7cf2af90cd51 arm: common: edma: Save the number of event queues/TCs
> > 
> > They might come via different route...
> 
> Vinod,
> 
> Do you have an immutable branch based on which I can send this patch
> series to ARM-SoC? Some of the patches in the series depend on code that
> went through your tree.
yup, pls pull my topic/edma for these change. This branch will not be rebased.

> Or if you are comfortable taking this series through your tree, thats
> okay by me too. We are still waiting for acks from DT maintainers on the
> binding change patches.
Since these patchs are for ARM, I think they are best suited thru arm tree. If
you run into issues with that I cna merge this but with right ACKs...

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] I found an errataum at drivers/base/dma-contiguous.c:294

[David Rientjes]

On Thu, 22 May 2014, Gioh Kim wrote:

> This is not a big deal but I think get_dev_cma_area is errataum of 
> dev_get_cma_area.
> 

Looks good, but you may want to read Documentation/SubmittingPatches when 
proposing patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] mm/compaction: avoid rescanning pageblocks in isolate_freepages

[David Rientjes]

On Mon, 19 May 2014, Vlastimil Babka wrote:

> Fix a (spurious) build warning:
> 
> mm/compaction.c:860:15: warning: ‘next_free_pfn’ may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
> 
> Seems like the compiler cannot prove that exiting the for loop without 
> updating
> next_free_pfn there will mean that the check for crossing the scanners will
> trigger. So let's not confuse people who try to see why this warning occurs.
> 
> Instead of initializing next_free_pfn to zero with an explaining comment, just
> drop the damned variable altogether and work with cc->free_pfn directly as
> Nayoa originally suggested.
> 

s/Nayoa/Naoya/

> Suggested-by: Naoya Horiguchi 
> Signed-off-by: Vlastimil Babka 

Acked-by: David Rientjes