[PATCH v3 5/7] pinctrl: sunxi: define A31 R_PIO pin functions
The A31 SoC provides both PL and PM pio bank through the R_PIO block.
These pins all support gpio function and can bbe assigned to system
peripherals (like TWI, P2WI, JTAG, ...)
Add new compatible string to the DT bindings doc.
Signed-off-by: Boris BREZILLON
Acked-by: Maxime Ripard
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
drivers/pinctrl/pinctrl-sunxi-pins.h | 74 ++
drivers/pinctrl/pinctrl-sunxi.c| 1 +
3 files changed, 76 insertions(+)
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index f5da7e3..d8d0656 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -11,6 +11,7 @@ Required properties:
"allwinner,sun5i-a10s-pinctrl"
"allwinner,sun5i-a13-pinctrl"
"allwinner,sun6i-a31-pinctrl"
+ "allwinner,sun6i-a31-r-pinctrl"
"allwinner,sun7i-a20-pinctrl"
- reg: Should contain the register physical address and length for the
pin controller.
diff --git a/drivers/pinctrl/pinctrl-sunxi-pins.h
b/drivers/pinctrl/pinctrl-sunxi-pins.h
index 3d60669..51100ca 100644
--- a/drivers/pinctrl/pinctrl-sunxi-pins.h
+++ b/drivers/pinctrl/pinctrl-sunxi-pins.h
@@ -2820,6 +2820,74 @@ static const struct sunxi_desc_pin sun6i_a31_pins[] = {
SUNXI_FUNCTION(0x2, "nand1")),/* CE3 */
};
+static const struct sunxi_desc_pin sun6i_a31_r_pins[] = {
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL0,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_twi"), /* SCK */
+ SUNXI_FUNCTION(0x3, "s_p2wi")), /* SCK */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL1,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_twi"), /* SDA */
+ SUNXI_FUNCTION(0x3, "s_p2wi")), /* SDA */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL2,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart")), /* TX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart")), /* RX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL4,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_ir")), /* RX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL5,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* MS */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL6,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* CK */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL7,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* DO */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL8,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* DI */
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM0,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM1,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM2,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "1wire")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM4,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM5,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM6,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM7,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "rtc")), /* CLKO */
+};
+
static const struct sunxi_desc_pin sun7i_a20_pins[] = {
SUNXI_PIN(SUNXI_PINCTRL_PIN_PA0,
SUNXI_FUNCTION(0x0,
Re: [PATCH 1/4 v2] perf: Allow ability to map cpus to nodes easily
On Thu, Apr 10, 2014 at 03:24:58PM +0200, Jiri Olsa wrote:
> On Thu, Apr 10, 2014 at 09:15:15AM -0400, Don Zickus wrote:
> > On Thu, Apr 10, 2014 at 11:31:46AM +0200, Jiri Olsa wrote:
> > > On Mon, Apr 07, 2014 at 02:55:21PM -0400, Don Zickus wrote:
> > >
> > > SNIP
> > >
> > > > +static int init_cpunode_map(void)
> > > > +{
> > > > + int i;
> > > > +
> > > > + set_max_cpu_num();
> > > > + set_max_node_num();
> > > > +
> > > > + cpunode_map = calloc(max_cpu_num, sizeof(int));
> > > > + if (!cpunode_map) {
> > > > + pr_err("%s: calloc failed\n", __func__);
> > > > + goto out;
> > > shuld probably be ^^^:
> > >
> > > return -1;
> > >
> > > > + }
> > > > +
> > > > + for (i = 0; i < max_cpu_num; i++)
> > > > + cpunode_map[i] = -1;
> > > > +
> > > > + return 0;
> > > > +out:
> > > > + return -1;
> > >
> > > and remove 'out' label code
> >
> > Sorry, probably leftover code that after snipping and changing didn't get
> > noticed. Thanks.
> >
> > >
> > > other than that, it seems ok.. I'll queue it
> >
> > I assume you are making the changes locally or should I resubmit?
>
> yes, I'll do that localy
Thanks!
Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] pinctrl: sunxi: disable clk when failing to probe pin controller
Disable the clk when failing to probe the pin controller device.
Signed-off-by: Boris BREZILLON
---
drivers/pinctrl/pinctrl-sunxi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index 2d9ca1c..73d11e2 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -891,7 +891,7 @@ static int sunxi_pinctrl_probe(struct platform_device *pdev)
pctl->irq = irq_of_parse_and_map(node, 0);
if (!pctl->irq) {
ret = -EINVAL;
- goto gpiochip_error;
+ goto clk_error;
}
pctl->domain = irq_domain_add_linear(node, SUNXI_IRQ_NUMBER,
@@ -899,7 +899,7 @@ static int sunxi_pinctrl_probe(struct platform_device *pdev)
if (!pctl->domain) {
dev_err(>dev, "Couldn't register IRQ domain\n");
ret = -ENOMEM;
- goto gpiochip_error;
+ goto clk_error;
}
for (i = 0; i < SUNXI_IRQ_NUMBER; i++) {
@@ -917,6 +917,8 @@ static int sunxi_pinctrl_probe(struct platform_device *pdev)
return 0;
+clk_error:
+ clk_disable_unprepare(clk);
gpiochip_error:
if (gpiochip_remove(pctl->chip))
dev_err(>dev, "failed to remove gpio chip\n");
--
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 v3 1/7] pinctrl: sunxi: check clk_prepare_enable return value
Check the clk_prepare_enable return value to avoid false positive probe.
Signed-off-by: Boris BREZILLON
---
drivers/pinctrl/pinctrl-sunxi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index f9fabe9..2d9ca1c 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -884,7 +884,9 @@ static int sunxi_pinctrl_probe(struct platform_device *pdev)
goto gpiochip_error;
}
- clk_prepare_enable(clk);
+ ret = clk_prepare_enable(clk);
+ if (ret)
+ goto gpiochip_error;
pctl->irq = irq_of_parse_and_map(node, 0);
if (!pctl->irq) {
--
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 v3 7/7] ARM: sunxi: update the default ARCH_NR_GPIO for sunxi arch
The A31 SoC has PL and PM banks and thus increase the default ARCH_NR_GPIO. Signed-off-by: Boris BREZILLON Acked-by: Maxime Ripard --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5db05f6a..ee096bf 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1644,9 +1644,9 @@ config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX + default 416 if ARCH_SUNXI default 392 if ARCH_U8500 default 352 if ARCH_VT8500 - default 288 if ARCH_SUNXI default 264 if MACH_H4700 default 0 help -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: atmel: set pwm_chip can_sleep flag
On 09/04/2014 20:26, Alexandre Belloni : > atmel_pwm_config() calls clk_get_rate() which might sleep, so we need to set > pwm_chip can_sleep flag. > > Signed-off-by: Alexandre Belloni Acked-by: Nicolas Ferre > --- > drivers/pwm/pwm-atmel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > index 0e589594b1cb..180e34e46617 100644 > --- a/drivers/pwm/pwm-atmel.c > +++ b/drivers/pwm/pwm-atmel.c > @@ -369,6 +369,7 @@ static int atmel_pwm_probe(struct platform_device *pdev) > > atmel_pwm->chip.base = -1; > atmel_pwm->chip.npwm = 4; > + atmel_pwm->chip.can_sleep = true; > atmel_pwm->config = data->config; > > ret = pwmchip_add(_pwm->chip); > -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7 4/6] pci: Introduce a domain number for pci_host_bridge.
On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann wrote:
> On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
>> On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau wrote:
>> > On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas wrote:
>> >> >> struct pci_host_bridge {
>> >> >> int domain;
>> >> >> int node;
>> >> >> struct device *dev;
>> >> >> struct pci_ops *ops;
>> >> >> struct list_head resources;
>> >> >> void *sysdata;
>> >> >> struct pci_bus *bus; /* filled in by core, not by arch */
>> >> >> ... /* other existing contents managed by core */
>> >> >> };
>> >> >>
>> >> >> struct pci_bus *pci_scan_host_bridge(struct pci_host_bridge *bridge);
>> >> >
>> >> > I'm really reluctant to give the arches more rope to hang themselves.
>> >>
>> >> If you mean the sysdata pointer is rope to hang themselves, I think it
>> >> would be great it we didn't need sysdata at all. But I think it would
>> >> be a huge amount of work to get rid of it completely, and keeping it
>> >> would let us work at that incrementally.
>> >
>> > Agree. But then your suggestion was to wrap sysdata inside another
>> > structure,
>> > which to me constitutes additional rope.
>>
>> I'll ponder this more, but I don't see your point here yet. The arch
>> already supplies a sysdata pointer to pci_scan_root_bus(), and we
>> stash it in every struct pci_bus already. My idea was just to pass it
>> in differently, as a structure member rather than a separate argument.
>> (And I'm not completely attached to my proposal; it was only to
>> illustrate my concern about the explosion of interfaces if we have to
>> add *_domain(), *_node(), etc.)
>
> As a minor variation of your suggestion, how about passing in a pointer
> to struct pci_host_bridge, and embed that within its own private
> structure? I think this is closer to how a lot of other subsystems
> do the abstraction.
I'm not sure I'm following you; you mean the arch-specific sysdata
structure would contain a pointer to struct pci_host_bridge?
I have to admit that I'm not up on how other subsystems handle this
sort of abstraction. Do you have any pointers to good examples that I
can study?
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] watchdog: add Intel MID watchdog driver support
On 04/09/2014 10:48 AM, David Cohen wrote: On Tue, Apr 08, 2014 at 04:56:36PM -0700, Randy Dunlap wrote: On 04/08/2014 01:59 PM, David Cohen wrote: Add initial Intel MID watchdog driver support. This driver is an initial implementation of generic Intel MID watchdog driver. Currently it supports Intel Merrifield platform. Signed-off-by: Eric Ernst Signed-off-by: David Cohen --- drivers/watchdog/Kconfig | 12 +++ drivers/watchdog/Makefile| 1 + drivers/watchdog/intel-mid_wdt.c | 209 +++ 3 files changed, 222 insertions(+) create mode 100644 drivers/watchdog/intel-mid_wdt.c diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 79d25894343a..4da09b8b2f11 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -643,6 +643,18 @@ config INTEL_SCU_WATCHDOG To compile this driver as a module, choose M here. +config INTEL_MID_WATCHDOG + bool "Intel MID SCU Watchdog Mobile Platforms" + depends on X86_INTEL_MID && WATCHDOG_CORE + ---help--- + Watchdog timer driver built into the Intel SCU for Intel MID + Platforms. + + This driver currently supports only the watchdog evolution + implementation in SCU, available for Merrifield generation. + + To compile this driver as a module, choose M here. Does choosing M work when INTEL_MID_WATCHDOG is a bool? and why is INTEL_MID_WATCHDOG a bool? The error here is the left over line from the template I used. There should be no mention about choosing M. It's bool because the watchdog is started by default on fw. We need this driver probed during boot to pet/kick/ping asap. IMHO It makes not much sense to compile it as module. Is that true for your firmware, but for all users of the supported set of devices ? The reason for having modules is to be able to load the driver only when needed, while using the same distribution for multiple platforms. So either you are forcing the driver to be loaded on every hardware which has it enabled, or you are limiting the scope of a distribution to one specific CPU. Neither seems desirable. If _you_ want to build the driver into the kernel, you always can. But you have to have a better reason than that to enforce it on everyone else. 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: [BUG] kernel BUG at /.../block/cfq-iosched.c:3145!
On 2014-04-10 00:45, Benjamin Herrenschmidt wrote: On Wed, 2014-04-09 at 21:52 -0600, Jens Axboe wrote: On 2014-04-09 21:35, Benjamin Herrenschmidt wrote: On Wed, 2014-04-09 at 20:25 -0600, Jens Axboe wrote: On 2014-04-09 19:36, Benjamin Herrenschmidt wrote: On Wed, 2014-04-09 at 19:31 -0600, Jens Axboe wrote: OK, I think we're seeing different symptoms of the same bug. Stay tuned, will have something for you to test shortly, I hope. Ah thanks. I'll defer the bisection then (it's painful on that machine for various reasons) Can you try with these two patches applied? Booted to login prompt once ... and twice. Much better ! :-) Excellent! I was hoping it was the same bug :-) I'll amend the commit and add your tested-by. A colleague was complaining of yet another oddball block related crash today on another machine when doing rsync's with upstream (this machine booted fine but crashed later on, but then it has less CPUs... maybe that's relevant) and these patches fixed it too. I'm sure it could manifest itself in a lot of weird ways. I'll send it upstream this morning, so hopefully should be fixed in mainline shortly. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 2/6] uprobes/x86: Emulate unconditional rip-relative jmp's
On 04/10, Denys Vlasenko wrote:
>
> On 04/09/2014 09:44 PM, Oleg Nesterov wrote:
> > uprobes/x86: Emulate unconditional rip-relative jmp's
>
> I propose "Emulate unconditional relative jmp's"
Thanks, will do. And I also agree with your reply to 0/6, will update
the code/subjects.
>
> > + union {
> > #ifdef CONFIG_X86_64
> > - unsigned long rip_rela_target_address;
> > + unsigned long rip_rela_target_address;
> > #endif
> > + struct {
> > + s32 disp;
>
> In x86-speak, jumps and calls have "offsets", not "displacements"
OK. s/disp/offs/.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: hang in migrate_swap
10.04.2014, 11:00, "Michael wang" :
> On 04/10/2014 11:31 AM, Sasha Levin wrote:
> [snip]
>
>> I'd like to re-open this issue. It seems that something broke and I'm
>> now seeing the same issues that have gone away 2 months with this patch
>> again.
>
> A new mechanism has been designed to move the priority checking inside
> idle_balance(), including Kirill who is the designer ;-)
Not sure, it's connected with my patch. But looks like, we forgot
exactly stop class. Maybe this will help?
[PATCH] sched: Checking for stop task appearance when balancing happens
Just do it, like we do for other higher priority classes...
Signed-off-by: Kirill Tkhai
---
kernel/sched/deadline.c | 11 ++-
kernel/sched/fair.c | 3 ++-
kernel/sched/rt.c | 7 ---
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 27ef409..b080957 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1021,8 +1021,17 @@ struct task_struct *pick_next_task_dl(struct rq *rq,
struct task_struct *prev)
dl_rq = >dl;
- if (need_pull_dl_task(rq, prev))
+ if (need_pull_dl_task(rq, prev)) {
pull_dl_task(rq);
+ /*
+* pull_rt_task() can drop (and re-acquire) rq->lock; this
+* means a stop task can slip in, in which case we need to
+* re-start task selection.
+*/
+ if (rq->stop && rq->stop->on_rq)
+ return RETRY_TASK;
+ }
+
/*
* When prev is DL, we may throttle it in put_prev_task().
* So, we update time before we check for dl_nr_running.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e9bd0b..c50275b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6727,7 +6727,8 @@ static int idle_balance(struct rq *this_rq)
out:
/* Is there a task of a high priority class? */
if (this_rq->nr_running != this_rq->cfs.h_nr_running &&
- (this_rq->dl.dl_nr_running ||
+ ((this_rq->stop && this_rq->stop->on_rq) ||
+this_rq->dl.dl_nr_running ||
(this_rq->rt.rt_nr_running && !rt_rq_throttled(_rq->rt
pulled_task = -1;
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index d8cdf16..bd2267a 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1362,10 +1362,11 @@ pick_next_task_rt(struct rq *rq, struct task_struct
*prev)
pull_rt_task(rq);
/*
* pull_rt_task() can drop (and re-acquire) rq->lock; this
-* means a dl task can slip in, in which case we need to
-* re-start task selection.
+* means a dl or stop task can slip in, in which case we need
+* to re-start task selection.
*/
- if (unlikely(rq->dl.dl_nr_running))
+ if (unlikely((rq->stop && rq->stop->on_rq) ||
+rq->dl.dl_nr_running))
return RETRY_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: mm: kernel BUG at mm/huge_memory.c:1829!
On Thu, Apr 10, 2014 at 01:25:27PM +0300, Kirill A. Shutemov wrote:
> On Tue, Apr 08, 2014 at 10:37:05AM -0400, Sasha Levin wrote:
> > Hi all,
> >
> > While fuzzing with trinity inside a KVM tools guest running the latest -next
> > kernel, I've stumbled on the following:
> >
> > [ 1275.253114] kernel BUG at mm/huge_memory.c:1829!
> > [ 1275.253642] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > [ 1275.254775] Dumping ftrace buffer:
> > [ 1275.255631](ftrace buffer empty)
> > [ 1275.256440] Modules linked in:
> > [ 1275.257347] CPU: 20 PID: 22807 Comm: trinity-c299 Not tainted
> > 3.14.0-next-20140407-sasha-00023-gd35b0d6 #382
> > [ 1275.258686] task: 8803e7873000 ti: 8803e7896000 task.ti:
> > 8803e7896000
> > [ 1275.259416] RIP: __split_huge_page (mm/huge_memory.c:1829 (discriminator
> > 1))
> > [ 1275.260527] RSP: 0018:8803e7897bb8 EFLAGS: 00010297
> > [ 1275.261323] RAX: 012c RBX: 8803e789d600 RCX:
> > 0006
> > [ 1275.261323] RDX: 5b80 RSI: 8803e7873d00 RDI:
> > 0282
> > [ 1275.261323] RBP: 8803e7897c68 R08: R09:
> >
> > [ 1275.261323] R10: 0001 R11: 30303320746e756f R12:
> >
> > [ 1275.261323] R13: 00a0 R14: 8803ede73000 R15:
> > ea001003
> > [ 1275.261323] FS: 7f899d23f700() GS:88043700()
> > knlGS:
> > [ 1275.261323] CS: 0010 DS: ES: CR0: 8005003b
> > [ 1275.261323] CR2: 024cf048 CR3: 0003e787f000 CR4:
> > 06a0
> > [ 1275.261323] DR0: 00696000 DR1: 00696000 DR2:
> >
> > [ 1275.261323] DR3: DR6: 0ff0 DR7:
> > 0600
> > [ 1275.261323] Stack:
> > [ 1275.261323] 8803e7897bd8 880024dab898 8803e7897bd8
> > ac1bea0e
> > [ 1275.261323] 8803e7897c28 0282 0014b06cc072
> >
> > [ 1275.261323] 012be7897c28 0a00 880024dab8d0
> > 880024dab898
> > [ 1275.261323] Call Trace:
> > [ 1275.261323] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98
> > kernel/locking/lockdep.c:254)
> > [ 1275.261323] ? down_write (kernel/locking/rwsem.c:51 (discriminator 2))
> > [ 1275.261323] ? split_huge_page_to_list (mm/huge_memory.c:1874)
> > [ 1275.261323] split_huge_page_to_list (include/linux/vmstat.h:37
> > mm/huge_memory.c:1879)
> > [ 1275.261323] __split_huge_page_pmd (mm/huge_memory.c:2811)
> > [ 1275.261323] ? mutex_unlock (kernel/locking/mutex.c:220)
> > [ 1275.261323] ? __mutex_unlock_slowpath
> > (arch/x86/include/asm/paravirt.h:809 kernel/locking/mutex.c:713
> > kernel/locking/mutex.c:722)
> > [ 1275.261323] ? get_parent_ip (kernel/sched/core.c:2471)
> > [ 1275.261323] ? preempt_count_sub (kernel/sched/core.c:2526)
> > [ 1275.261323] follow_page_mask (mm/memory.c:1518 (discriminator 1))
> > [ 1275.261323] SYSC_move_pages (mm/migrate.c:1227 mm/migrate.c:1353
> > mm/migrate.c:1508)
> > [ 1275.261323] ? SYSC_move_pages (include/linux/rcupdate.h:800
> > mm/migrate.c:1472)
> > [ 1275.261323] ? sched_clock_local (kernel/sched/clock.c:213)
> > [ 1275.261323] SyS_move_pages (mm/migrate.c:1456)
> > [ 1275.261323] tracesys (arch/x86/kernel/entry_64.S:749)
> > [ 1275.261323] Code: c0 01 39 45 94 74 18 41 8b 57 18 48 c7 c7 90 5e 6d b0
> > 31 c0 8b 75 94 83 c2 01 e8 3d 6a 23 03 41 8b 47 18 83 c0 01 39 45 94 74 02
> > <0f> 0b 49 8b 07 48 89 c2 48 c1 e8 34 83 e0 03 48 c1 ea 36 4c 8d
> > [ 1275.261323] RIP __split_huge_page (mm/huge_memory.c:1829 (discriminator
> > 1))
> > [ 1275.261323] RSP
> >
> > Looking at the code, there was supposed to be a printk printing both
> > mapcounts if they're different. However, there was no matching entry
> > in the log for that.
>
> We had the bug triggered a year ago[1] and I tried to ask whether it can
> caused by chaining the same_anon_vma list with interval tree[2].
>
> It's not obvious for me how new implementation of anon rmap with interval
> tree guarantee behaviour of anon_vma_interval_tree_foreach() vs.
> anon_vma_interval_tree_insert() which __split_huge_page() expects.
>
> Michel, could you clarify that?
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=923817
> [2] http://article.gmane.org/gmane.linux.kernel.mm/96518
Okay, below is my attempt to fix the bug. I'm not entirely sure it's
correct. Andrea, could you take a look?
I used this program to reproduce the issue:
#include
#include
#include
#include
#include
#define SIZE (2*1024*1024)
int main()
{
char * x;
for (;;) {
x = mmap(NULL, SIZE+SIZE-4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
if (x == MAP_FAILED)
perror("error"), exit(1);
x[SIZE] = 0;
if (!fork()) {
_exit(0);
}
[PATCH] cpuidle: governor: menu: move repeated correction factor check to init
In menu_select function we check for correction factor every time.
If it is zero we are initializing to unity. Hence move it to init function
and initialise by unity, hence avoid repeated comparisons.
Signed-off-by: Chander Kashyap
---
drivers/cpuidle/governors/menu.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index cf7f2f0..048f6d9 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -315,13 +315,6 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
multiplier = performance_multiplier();
/*
-* if the correction factor is 0 (eg first time init or cpu hotplug
-* etc), we actually want to start out with a unity factor.
-*/
- if (data->correction_factor[data->bucket] == 0)
- data->correction_factor[data->bucket] = RESOLUTION * DECAY;
-
- /*
* Force the result of multiplication to be 64 bits even if both
* operands are 32 bits.
* Make sure to round up for half microseconds.
@@ -453,9 +446,17 @@ static int menu_enable_device(struct cpuidle_driver *drv,
struct cpuidle_device *dev)
{
struct menu_device *data = _cpu(menu_devices, dev->cpu);
+ int i;
memset(data, 0, sizeof(struct menu_device));
+ /*
+* if the correction factor is 0 (eg first time init or cpu hotplug
+* etc), we actually want to start out with a unity factor.
+*/
+ for(i = 0; i < BUCKETS; i++)
+ data->correction_factor[i] = RESOLUTION * DECAY;
+
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Darlehen Angebot
Wir bieten privaten und gewerblichen Darlehen ohne Sicherheiten (nur Identifikation) bei 3% Zinssatz, ab € 10.000 bis € 90.000.000 in 1 Jahr bis 20 Jahren Laufzeit überall in der Welt.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch: fix wildcard DT compatible string checking
From: Rob Herring
We attempt to search for compatible strings which use a variable
token in the documented name such as or . While this
was attempted to be handled, it's utterly broken.
The desired forms of matching are:
vendor,-*
vendor,name-*
For , lower case characters and numbers are permitted. For
, only numeric values are allowed.
With this change, the number of missing compatible strings reported in
arch/arm/boot/dts is reduced from 1071 to 960.
Reported-by: Alexandre Belloni
Signed-off-by: Rob Herring
Cc: Florian Vaussard
Cc: Joe Perches
Cc: Andy Whitcroft
Cc: Andrew Morton
---
v2:
- drop debugging print
scripts/checkpatch.pl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 34eb216..62d005e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2093,8 +2093,10 @@ sub process {
foreach my $compat (@compats) {
my $compat2 = $compat;
- $compat2 =~ s/\,[a-z]*\-/\,<\.\*>\-/;
- `grep -Erq "$compat|$compat2" $dt_path`;
+ $compat2 =~ s/\,[a-zA-Z0-9]*\-/\,<\.\*>\-/;
+ my $compat3 = $compat;
+ $compat3 =~ s/\,([a-z]*)[0-9]*\-/\,$1<\.\*>\-/;
+ `grep -Erq "$compat|$compat2|$compat3"
$dt_path`;
if ( $? >> 8 ) {
WARN("UNDOCUMENTED_DT_STRING",
"DT compatible string \"$compat\"
appears un-documented -- check $dt_path\n" . $herecurr);
--
1.9.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: [RFC PATCH 4/6] uprobes/x86: Emulate rip-relative call's
On 04/09/2014 05:43 PM, Oleg Nesterov wrote: > On 04/08, Jim Keniston wrote: >> >> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote: >>> 0xe8. Anything else? >> >> No, I think e8 is the only call instruction uprobes will see. > > Good. There is this monstrosity, "16-bit override for branches" in 64-mode: 66 e8 nn nn callw Nobody sane uses it because it truncates instruction pointer. Or rather, *I think* it should truncate it (i.e. zero-extend to full width), but conceivably some CPUs can be buggy wrt that: they can decide to modify only lower 16 bits of IP, or even they can decided to use signed but apply it to full-width RIP. AMD manuals are not clear on what exactly should happen. I am sure no one sane uses this form of branch instructions in 32-bit and 64-bit code. I don't think we should be trying to support it "correctly" (we can just let program crash with SIGILL or something), we only need to make sure we don't overlook its existence and thus are not tricked into touching or modifying unrelated data. Imagine that 66 e8 nn nnbytes are exactly at the end of a page, and we wrongly assume that offset is 32-bit, not 16-bit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 4/6] uprobes/x86: Emulate rip-relative call's
On 04/10, Masami Hiramatsu wrote: > > (2014/04/10 21:53), Denys Vlasenko wrote: > > On 04/09/2014 09:44 PM, Oleg Nesterov wrote: > >> +static void ttt_clear_displacement(struct arch_uprobe *auprobe, struct > >> insn *insn) > > > > Branch instruction's offset isn't called "displacement" > > on x86. > > > > How about ttt_clear_branch_offset? > > I like his idea. Me too. Thanks Denys! Except ttt_clear_branch_offset() won't look nice after s/ttt/branch/ ;) I'll rename it to branch_clear_offset(). > "displacement" on x86 is so confused especially > with using x86 insn decoder. Yes. The naming just mirros my initial misunderstanding of lib/insn.c. Thanks, Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Oops in acpi_gpiochip_add on MacBookPro with Linux v3.14-12042-g69cd9eba3886
On Thu, Apr 10, 2014 at 8:52 AM, Josh Boyer wrote: > On Thu, Apr 10, 2014 at 8:40 AM, Mika Westerberg > wrote: >> On Thu, Apr 10, 2014 at 08:22:12AM -0400, Josh Boyer wrote: >>> On Thu, Apr 10, 2014 at 2:50 AM, Rafał Miłecki wrote: >>> > 2014-04-09 23:09 GMT+02:00 Josh Boyer : >>> >> With Linux v3.14-12042-g69cd9eba3886 I get an oops from the bcma >>> >> module on the MacBookPro 10,2 I have here. This works fine with Linux >>> >> v3.14-7333-g59ecc26004e7. There have been no changes between those >>> >> two versions to bcma itself, but the GPIO merge did go in that window. >>> >> I can attempt to do a bisect tomorrow, but looking over some of the >>> >> GPIO commits it seems pretty relevant to the ACPI GPIO changes. I'm >>> >> hoping someone here has an idea on what the issue might be and has >>> >> some possible things for me to test for fixes. >>> > >>> > Bug report: https://lkml.org/lkml/2014/3/24/262 >>> > Patch: https://lkml.org/lkml/2014/3/24/293 >>> > Tested by Sabrina: https://lkml.org/lkml/2014/3/24/304 >>> > (all links are for the same thread). >>> > >>> > Now you simply have to find above patch in some git tree :) Not sure >>> > if it's already in Linus's one. >>> >>> Ah, wonderful. I now wish I would have found those in my searching >>> before doing the bisect. Oh well. For what it's worth, my bisect >>> landed on the same commit. >>> >>> The fix isn't in Linus' tree or linux-next. I'm guessing Mika is >>> either still on vacation, or hasn't sent out the formal fix yet. >> >> No, not on vacation anymore (unfortunately). I did send the formal patch >> already: >> >> https://lkml.org/lkml/2014/3/31/135 >> >> but it isn't merged to Linus' GPIO tree yet. > > Ah, ok great. I'll test that today. Thanks. Yep, that works for my bcma issue as well. Thanks! Tested-by: Josh Boyer josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/2] tracing: syscall_regfunc() should not skip kernel threads
On 04/10, Steven Rostedt wrote: > > On Wed, 9 Apr 2014 19:06:16 +0200 > Oleg Nesterov wrote: > > > syscall_regfunc() ignores the kernel thread because "it has > > no effect", see cc3b13c1 "Don't trace kernel thread syscalls". > > > > However, this means that a user-space task spawned by > > call_usermodehelper() won't report the system calls if > > kernel_execve() is called when sys_tracepoint_refcount != 0. > > What about doing the set there? That is, we could add a check in the > call_userspacehelper() just before it does the do_execve, that if > sys_tracepoint_refcount is set, we set the TIF flag. But for what? And if we do this, call_usermodehelper() needs write_lock_irq(tasklist) to serialize with syscall_*regfunc(). Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] tracing: syscall_*regfunc() can race with copy_process()
On 04/10, Steven Rostedt wrote:
>
> On Wed, 9 Apr 2014 19:05:42 +0200
> Oleg Nesterov wrote:
>
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -1472,7 +1472,9 @@ static struct task_struct *copy_process(unsigned long
> > clone_flags,
> >
> > total_forks++;
> > spin_unlock(>sighand->siglock);
> > + syscall_tracepoint_update(p);
> > write_unlock_irq(_lock);
> > +
>
> So this looks to be a fix that probably should go to stable?
Not sure, this is up to you.
> > @@ -732,33 +732,31 @@ static int sys_tracepoint_refcount;
> >
> > void syscall_regfunc(void)
> > {
> > - unsigned long flags;
> > struct task_struct *g, *t;
> >
> > if (!sys_tracepoint_refcount) {
> > - read_lock_irqsave(_lock, flags);
> > + read_lock(_lock);
> > do_each_thread(g, t) {
> > /* Skip kernel threads. */
> > - if (t->mm)
> > + if (!(t->flags & PF_KTHREAD))
> > set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
> > } while_each_thread(g, t);
> > - read_unlock_irqrestore(_lock, flags);
> > + read_unlock(_lock);
> > }
> > sys_tracepoint_refcount++;
> > }
> >
> > void syscall_unregfunc(void)
> > {
> > - unsigned long flags;
> > struct task_struct *g, *t;
> >
> > sys_tracepoint_refcount--;
> > if (!sys_tracepoint_refcount) {
> > - read_lock_irqsave(_lock, flags);
> > + read_lock(_lock);
> > do_each_thread(g, t) {
> > clear_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
> > } while_each_thread(g, t);
> > - read_unlock_irqrestore(_lock, flags);
> > + read_unlock(_lock);
>
> These changes should be in a separate patch, as they can wait till 3.16.
OK, I'll split this change.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] tracing: syscall_*regfunc() can race with copy_process()
On 04/10, Steven Rostedt wrote: > > On Wed, 9 Apr 2014 19:05:42 +0200 > Oleg Nesterov wrote: > > > syscall_regfunc() and syscall_unregfunc() should set/clear > > TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race > > with copy_process() and miss the new child which was not added to > > init_task.tasks list yet. > > > > Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT > > under tasklist. > > > > While at it, > > > > - remove _irqsafe from syscall_regfunc/syscall_unregfunc, > > read_lock(tasklist) doesn't need to disable irqs. > > > > - change syscall_unregfunc() to check PF_KTHREAD to skip > > the kernel threads, ->mm != NULL is the common mistake. > > > > Note: probably this check should be simply removed, needs > > another patch. > > > > Signed-off-by: Oleg Nesterov > > BTW, how important is this fix? Something we should aim for the current > merge window? stable? Or can it wait till 3.16? I think this all can wait till 3.16. The problem is really minor. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [for-next][PATCH 14/14] tracing: Get trace_array ref counts when accessing trace files
On Tue, 8 Apr 2014 13:32:31 -0400 Steven Rostedt wrote: > On Tue, 08 Apr 2014 13:11:32 -0400 > Sasha Levin wrote: > > > >> > > >> Although when I mount everything for the fuzzer I do it with > > >> '-onoexec,nosuid' > > >> and the fuzzer is banned from testing mount(), so I'm not sure how it > > >> would > > >> do that thing on it's own. > > > > > > What does the -onoexec do? Not change the exec flag of files? > > > > It lets you set it as executable, but it won't let you actually exec it. > > > > > Also, I wonder if this has something to do with the syscall being a > > > compat sys_exec and not a native one. Is userspace on your vm 32bit? Or > > > does the fuzzer just try the different compat calls? > > > > Right, everything is 64bit but the fuzzer tries 32bit calls as well. > > When this bug is triggered, is there a way to let the fuzzer tell us > what exactly the last syscall it sent was? That is, the syscall number > plus all its arguments? Just letting you know. I'm holding off looking too deep into this as it seems to require very strange behavior to trigger (like perhaps execing a tracing file). This only happens when running as root, right? If not, then there's a bigger bug involved. If you can get me more information on this bug, like what I suggested above, then I'll take another look. Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] blk-throttle: simplify logic by token bucket algorithm
On Thu, Apr 10, 2014 at 06:07:05PM +0800, Hong zhi guo wrote:
> Hi, Tejun, Vivek and Jens,
>
> I did tests and you affirmed the idea, and Vivek said he'll review the
> last version of the patch. But it seems he left blkio area more than
> half year. What next should I do to make progress ?
Hong,
I would say post the patches again with your testing information. I will
review these.
Thanks
Vivek
>
> BRs
> Zhiguo
>
> On Sun, Oct 20, 2013 at 8:11 PM, Hong Zhiguo wrote:
> > Token bucket algorithm(http://en.wikipedia.org/wiki/Token_bucket)
> > is very simple and widely used for rate limiting and shaping.
> > It's well suitable for blk-throttle. And it naturally works for
> > hierarchical cgroups. So I took it to replace the original time
> > _slicing_|_trimming_|_extending_ logic.
> >
> > The advantage is simplicity, reliability and less fluctuation.
> >
> > About 300 lines of code for time-slicing is replaced with 60 lines
> > of code for token bucket in blk-throttle.c.
> >
> > I've tested this patch by fio with rw=randread, rw=randrw. It
> > behaves almost the same with original time-slicing implementation,
> > and with less fluctuation. It's also tested on hierarchical setup.
> >
> > Signed-off-by: Hong Zhiguo
> > Tested-by: Hong Zhiguo
> > ---
> > block/blk-throttle.c | 285
> > +--
> > 1 file changed, 50 insertions(+), 235 deletions(-)
> >
> > diff --git a/block/blk-throttle.c b/block/blk-throttle.c
> > index 8331aba..45d4d91 100644
> > --- a/block/blk-throttle.c
> > +++ b/block/blk-throttle.c
> > @@ -2,6 +2,8 @@
> > * Interface for controlling IO bandwidth on a request queue
> > *
> > * Copyright (C) 2010 Vivek Goyal
> > + *
> > + * Simplify the logic with token bucket, Hong Zhiguo
> >
> > */
> >
> > #include
> > @@ -18,9 +20,6 @@ static int throtl_grp_quantum = 8;
> > /* Total max dispatch from all groups in one round */
> > static int throtl_quantum = 32;
> >
> > -/* Throttling is performed over 100ms slice and after that slice is
> > renewed */
> > -static unsigned long throtl_slice = HZ/10; /* 100 ms */
> > -
> > static struct blkcg_policy blkcg_policy_throtl;
> >
> > /* A workqueue to queue throttle related work */
> > @@ -91,6 +90,11 @@ struct tg_stats_cpu {
> > struct blkg_rwstat serviced;
> > };
> >
> > +/* Depth of iops token bucket */
> > +#define THROTL_BURST_IO 8
> > +/* Depth of bps token bucket */
> > +#define THROTL_BURST_BYTES (4096 * 8)
> > +
> > struct throtl_grp {
> > /* must be the first member */
> > struct blkg_policy_data pd;
> > @@ -133,14 +137,13 @@ struct throtl_grp {
> > /* IOPS limits */
> > unsigned int iops[2];
> >
> > - /* Number of bytes disptached in current slice */
> > - uint64_t bytes_disp[2];
> > - /* Number of bio's dispatched in current slice */
> > - unsigned int io_disp[2];
> > + /* Token for throttling by bps */
> > + uint64_t bytes_token[2];
> > + /* Token for throttling by iops */
> > + unsigned int io_token[2];
> >
> > - /* When did we start a new slice */
> > - unsigned long slice_start[2];
> > - unsigned long slice_end[2];
> > + /* Time check-point */
> > + unsigned long t_c[2];
> >
> > /* Per cpu stats pointer */
> > struct tg_stats_cpu __percpu *stats_cpu;
> > @@ -680,171 +683,39 @@ static bool throtl_schedule_next_dispatch(struct
> > throtl_service_queue *sq,
> > return false;
> > }
> >
> > -static inline void throtl_start_new_slice_with_credit(struct throtl_grp
> > *tg,
> > - bool rw, unsigned long start)
> > -{
> > - tg->bytes_disp[rw] = 0;
> > - tg->io_disp[rw] = 0;
> > -
> > - /*
> > -* Previous slice has expired. We must have trimmed it after last
> > -* bio dispatch. That means since start of last slice, we never used
> > -* that bandwidth. Do try to make use of that bandwidth while giving
> > -* credit.
> > -*/
> > - if (time_after_eq(start, tg->slice_start[rw]))
> > - tg->slice_start[rw] = start;
> > -
> > - tg->slice_end[rw] = jiffies + throtl_slice;
> > - throtl_log(>service_queue,
> > - "[%c] new slice with credit start=%lu end=%lu
> > jiffies=%lu",
> > - rw == READ ? 'R' : 'W', tg->slice_start[rw],
> > - tg->slice_end[rw], jiffies);
> > -}
> > -
> > -static inline void throtl_start_new_slice(struct throtl_grp *tg, bool rw)
> > -{
> > - tg->bytes_disp[rw] = 0;
> > - tg->io_disp[rw] = 0;
> > - tg->slice_start[rw] = jiffies;
> > - tg->slice_end[rw] = jiffies + throtl_slice;
> > - throtl_log(>service_queue,
> > - "[%c] new slice start=%lu end=%lu jiffies=%lu",
> > - rw == READ ? 'R' : 'W', tg->slice_start[rw],
> > - tg->slice_end[rw], jiffies);
> > -}
> > -
> > -static inline
Re: [RFC PATCH] Suppress a device hot remove related lockdep warning
Hello,
On Thu, Apr 10, 2014 at 05:18:34PM +0800, Li Zhong wrote:
> I noticed following lockdep warning when trying acpi hot-remove cpus:
>
> [84154.204080] ==
> [84154.204080] [ INFO: possible circular locking dependency detected ]
> [84154.204080] 3.14.0-next-20140408+ #24 Tainted: GW
> [84154.204080] ---
> [84154.204080] bash/777 is trying to acquire lock:
> [84154.204080] (cpu_add_remove_lock){+.+.+.}, at: []
> cpu_maps_update_begin+0x17/0x20
> [84154.213203]
> [84154.213203] but task is already holding lock:
> [84154.213203] (s_active#79){.+}, at: []
> kernfs_fop_write+0xe4/0x190
> [84154.213203]
> [84154.213203] which lock already depends on the new lock.
> [84154.213203]
> [84154.213203]
> [84154.213203] the existing dependency chain (in reverse order) is:
> [84154.213203]
...
> [84154.213203] Possible unsafe locking scenario:
> [84154.213203]
> [84154.213203]CPU0CPU1
> [84154.213203]
> [84154.213203] lock(s_active#79);
> [84154.213203]lock(cpu_hotplug.lock#2);
> [84154.213203]lock(s_active#79);
> [84154.213203] lock(cpu_add_remove_lock);
> [84154.213203]
> [84154.213203] *** DEADLOCK ***
> .
>
> The deadlock itself seems already fixed in commit 5e33bc41.
>
> This patch uses DEVICE_ATTR_IGNORE_LOCKDEP for "online" attr to suppress
> this lockdep warning. But I'm a little afraid it might also hide
> (future) potential real dead lock scenarios?
I suppose this is happening because offlining a cpu involves removing
some sysfs files? If the file isn't trying to remove itself, it
should be okay but I think it could be better to use
kernfs_break_active_protection() from online callback so that the
operation is actually outside the dependency chain rather than just
suppressing lockdep.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 2/2] tracing: syscall_regfunc() should not skip kernel threads
On Wed, 9 Apr 2014 19:06:16 +0200
Oleg Nesterov wrote:
> syscall_regfunc() ignores the kernel thread because "it has
> no effect", see cc3b13c1 "Don't trace kernel thread syscalls".
>
> However, this means that a user-space task spawned by
> call_usermodehelper() won't report the system calls if
> kernel_execve() is called when sys_tracepoint_refcount != 0.
What about doing the set there? That is, we could add a check in the
call_userspacehelper() just before it does the do_execve, that if
sys_tracepoint_refcount is set, we set the TIF flag.
-- Steve
>
> Remove this check. Hopefully the unnecessary report from
> ret_from_fork path mentioned by cc3b13c1 is fine. In fact
> "this is the only case" is not true. Say, kernel_execve()
> itself does "int 80" on X86_32. Hopefully fine too.
>
> Signed-off-by: Oleg Nesterov
> ---
> kernel/tracepoint.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> index a16754b..4e1e4ca 100644
> --- a/kernel/tracepoint.c
> +++ b/kernel/tracepoint.c
> @@ -737,9 +737,7 @@ void syscall_regfunc(void)
> if (!sys_tracepoint_refcount) {
> read_lock(_lock);
> do_each_thread(g, t) {
> - /* Skip kernel threads. */
> - if (!(t->flags & PF_KTHREAD))
> - set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
> + set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
> } while_each_thread(g, t);
> read_unlock(_lock);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.
Signed-off-by: Vivek Gautam
Cc: Jingoo Han
Cc: Alan Stern
---
Based on 'usb-next' branch of Greg's usb tree.
Tested with local dt patches, similar to ehci dt changes posted by Kamil[1].
Tested on Exynos5250 smdk.
[1] [PATCH v6 4/8] dts: Add usb2phy to Exynos 5250
https://lkml.org/lkml/2014/1/29/302
.../devicetree/bindings/usb/exynos-usb.txt | 14
drivers/usb/host/ohci-exynos.c | 79 ++--
2 files changed, 85 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..ef0bc09 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,6 +38,10 @@ Required properties:
- interrupts: interrupt number to the cpu.
- clocks: from common clock binding: handle to usb clock.
- clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+One phy per port. Each port should have its reg entry with a consecutive
+number. Also it should contain phys and phy-names entries specifying the
+phy used by the port.
Example:
usb@1212 {
@@ -47,6 +51,16 @@ Example:
clocks = < 285>;
clock-names = "usbhost";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ phys = < 1>;
+ phy-names = "host";
+ status = "disabled";
+ };
+
};
DWC3
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..52eb821 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,6 +38,7 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct phy *phy_g;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -57,12 +59,26 @@ static void exynos_ohci_phy_disable(struct platform_device
*pdev)
usb_phy_shutdown(exynos_ohci->phy);
}
+static int exynos_ohci_phyg_on(struct phy *phy, bool on)
+{
+ int ret = 0;
+
+ if (phy) {
+ if (on)
+ ret = phy_power_on(phy);
+ else
+ ret = phy_power_off(phy);
+ }
+
+ return ret;
+}
+
static int exynos_ohci_probe(struct platform_device *pdev)
{
struct exynos_ohci_hcd *exynos_ohci;
struct usb_hcd *hcd;
struct resource *res;
- struct usb_phy *phy;
+ struct device_node *child;
int irq;
int err;
@@ -88,16 +104,49 @@ static int exynos_ohci_probe(struct platform_device *pdev)
"samsung,exynos5440-ohci"))
goto skip_phy;
- phy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(phy)) {
- usb_put_hcd(hcd);
- dev_warn(>dev, "no platform data or transceiver
defined\n");
- return -EPROBE_DEFER;
+ exynos_ohci->phy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(exynos_ohci->phy)) {
+ err = PTR_ERR(exynos_ohci->phy);
+ if (err == -ENXIO || err == -ENODEV) {
+ exynos_ohci->phy = NULL;
+ } else if (err == -EPROBE_DEFER) {
+ usb_put_hcd(hcd);
+ return err;
+ } else {
+ dev_err(>dev, "no usb2 phy configured\n");
+ usb_put_hcd(hcd);
+ return err;
+ }
} else {
- exynos_ohci->phy = phy;
- exynos_ohci->otg = phy->otg;
+ exynos_ohci->otg = exynos_ohci->phy->otg;
}
+ /* Getting generic phy:
+* We are keeping both types of phys as a part of transiting OHCI
+* to generic phy framework, so that in absence of supporting dts
+* changes the functionality doesn't break.
+* Once we move the ohci dt nodes to use new generic phys,
+* we can remove support for older PHY in this driver.
+*/
+ child = of_get_next_child(pdev->dev.of_node, NULL);
+ exynos_ohci->phy_g = devm_of_phy_get(>dev, child, 0);
+ of_node_put(child);
+ if (IS_ERR(exynos_ohci->phy_g)) {
+ err = PTR_ERR(exynos_ohci->phy_g);
+ if (err == -ENOSYS || err
Re: [PATCH 1/4 v2] perf: Allow ability to map cpus to nodes easily
On Thu, Apr 10, 2014 at 09:15:15AM -0400, Don Zickus wrote:
> On Thu, Apr 10, 2014 at 11:31:46AM +0200, Jiri Olsa wrote:
> > On Mon, Apr 07, 2014 at 02:55:21PM -0400, Don Zickus wrote:
> >
> > SNIP
> >
> > > +static int init_cpunode_map(void)
> > > +{
> > > + int i;
> > > +
> > > + set_max_cpu_num();
> > > + set_max_node_num();
> > > +
> > > + cpunode_map = calloc(max_cpu_num, sizeof(int));
> > > + if (!cpunode_map) {
> > > + pr_err("%s: calloc failed\n", __func__);
> > > + goto out;
> > shuld probably be ^^^:
> >
> > return -1;
> >
> > > + }
> > > +
> > > + for (i = 0; i < max_cpu_num; i++)
> > > + cpunode_map[i] = -1;
> > > +
> > > + return 0;
> > > +out:
> > > + return -1;
> >
> > and remove 'out' label code
>
> Sorry, probably leftover code that after snipping and changing didn't get
> noticed. Thanks.
>
> >
> > other than that, it seems ok.. I'll queue it
>
> I assume you are making the changes locally or should I resubmit?
yes, I'll do that localy
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/13] extcon: extcon-class: improve extcon client API
This patch improves extcon client API to get rid of ugly functions operating
on name strings. It gives independency from naming convention in extcon
provider drivers. Names given at provider registration are now used only
for sysfs, debugs, and to support platforms using legacy devicetree bindings.
>From now individual cables are specified in devicetree, so client API has
changed from extcon_dev oriented to extcon_cable oriented. Added also some
minor modifications to simplify interest registration.
The extcon_specific_cable_nb structure has been changed to extcon_cable_nb.
Now this is the only struct which has to be supplied by client. Pointer to
user_nb has been changed to extcon_notifier_fn_t to simplify interest
registation process.
Each single cable is represented by struct extcon_cable. Pointer to
extcon_cable is returned from functions:
of_extcon_get_cable() - returning cable of given index
of_extcon_get_cable_by_name() - returing cable by name defined in devicetree
extcon_get_cable_by_name() - similar to of_extcon_get_cable_by_name(),
but it takes struct device instead of struct device_node
Function extcon_register_interest() has been changed. Registration is now
not based on cable name string, but on pointer to struct extcon_cable.
Also extcon_get_cable_state() function has been changed. Now it takes
pointer to struct extcon_cable.
This patch modifies all client drivers to make it using new extcon API.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c | 201 +--
drivers/power/charger-manager.c | 36 +++---
drivers/usb/dwc3/dwc3-omap.c| 68 ++-
drivers/usb/phy/phy-omap-otg.c | 72 ++-
include/linux/extcon.h | 92 --
include/linux/platform_data/usb-omap1.h |2 -
include/linux/power/charger-manager.h |6 +-
7 files changed, 288 insertions(+), 189 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 1075ce8..708b352 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -324,15 +324,14 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
/**
* extcon_get_cable_state() - Get the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name.
- *
- * Note that this is slower than extcon_get_cable_state_.
+ * @cable: the cable.
*/
-int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name)
+int extcon_get_cable_state(struct extcon_cable *cable)
{
- return extcon_get_cable_state_(edev, extcon_find_cable_index
- (edev, cable_name));
+ if (!cable)
+ return -ENODEV;
+
+ return !!(cable->edev->state & (1 << cable->cable_index));
}
EXPORT_SYMBOL_GPL(extcon_get_cable_state);
@@ -376,24 +375,130 @@ out:
return edev;
}
+/**
+ * of_extcon_get_cable() - Get specified extcon cable instance from devicetree
+ * @np:The node of extcon device
+ */
+struct extcon_cable *of_extcon_get_cable(struct device_node *np, int index)
+{
+ struct of_phandle_args extcon_spec;
+ struct extcon_dev *edev;
+ struct extcon_cable *cable;
+ int ret;
+
+ if (index < 0)
+ return ERR_PTR(-EINVAL);
+
+ ret = of_parse_phandle_with_args(np, "extcon-cables", "#extcon-cells",
+ index, _spec);
+ if (ret)
+ return ERR_PTR(ret);
+
+ edev = of_extcon_get_extcon_dev(extcon_spec.np);
+ if (!edev) {
+ pr_devel("unable to get extcon device");
+ return ERR_PTR(-ENODEV);
+ }
+
+ cable = >cables[extcon_spec.args[0]];
+
+ of_node_put(extcon_spec.np);
+ return cable;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_cable);
+
+struct extcon_cable *of_extcon_get_cable_legacy(struct device_node *np,
+ const char *name)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ int i;
+
+ node = of_parse_phandle(np, "extcon", 0);
+ if (!node)
+ return ERR_PTR(-EINVAL);
+ edev = of_extcon_get_extcon_dev(node);
+ if (!edev)
+ return ERR_PTR(-ENODEV);
+
+ if (!edev->supported_cable)
+ return ERR_PTR(-EINVAL);
+
+ for (i = 0; edev->supported_cable[i]; ++i) {
+ if (!strncmp(edev->supported_cable[i], name, CABLE_NAME_MAX))
+ return >cables[i];
+ }
+ return ERR_PTR(-ENODEV);
+}
+
+/*
+ * of_extcon_get_cable_by_name() - Get extcon cable from devicetree by name
+ * @np - devicetree node of client device
+ * @name - name of the cable specified in devicetree
+ *
+ * return the instance of extcon cable
+ */
+struct extcon_cable *of_extcon_get_cable_by_name(struct device_node *np,
+const char
[PATCH 12/13] extcon: extcon-max8997: check if pdata exists
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-max8997.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index c071588..d7d12e9 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -726,7 +726,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
goto err_irq;
}
- if (pdata->muic_pdata) {
+ if (pdata && pdata->muic_pdata) {
struct max8997_muic_platform_data *muic_pdata
= pdata->muic_pdata;
--
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 13/13] extcon: extcon-max77693: check if pdata exists
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-max77693.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 2cd8892..fa8534e 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1210,7 +1210,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
/* Initialize MUIC register by using platform data or default data */
- if (pdata->muic_data) {
+ if (pdata && pdata->muic_data) {
init_data = pdata->muic_data->init_data;
num_init_data = pdata->muic_data->num_init_data;
} 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/
[PATCH 11/13] extcon: extcon-adc-jack: add devicetree support
This patch modifies extcon-adc-jack driver to use initialization data from
devicetree, when platform data is not available. It allows to define cable list
with ADC value ranges for each of them in devicetree bindings.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-adc-jack.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index d65915e..293871b1 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -92,12 +93,78 @@ static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
return IRQ_HANDLED;
}
+static struct adc_jack_pdata *get_pdata_from_dt(struct device *dev)
+{
+ int ret, cnt, i;
+ struct device_node *cables_np, *child;
+ struct adc_jack_pdata *pdata =
+ devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+
+ ret = of_property_read_string_index(dev->of_node,
+ "adc-name", 0, >name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_string_index(dev->of_node,
+ "adc-consumer-channel", 0, >consumer_channel);
+ if (ret)
+ return NULL;
+
+ cables_np = of_find_node_by_name(dev->of_node, "cables");
+ if (!cables_np)
+ return NULL;
+
+ cnt = of_get_child_count(cables_np);
+ if (cnt <= 0)
+ return NULL;
+
+ pdata->cable_names = devm_kcalloc(dev, cnt+1,
+ sizeof(*pdata->cable_names), GFP_KERNEL);
+ if (!pdata->cable_names)
+ return NULL;
+
+ pdata->adc_conditions = devm_kcalloc(dev, cnt+1,
+ sizeof(*pdata->adc_conditions), GFP_KERNEL);
+ if (!pdata->adc_conditions)
+ return NULL;
+
+ i = 0;
+ for_each_child_of_node(cables_np, child) {
+ ret = of_property_read_string_index(child,
+ "cable-name", 0, >cable_names[i]);
+ if (ret)
+ return NULL;
+
+ pdata->adc_conditions[i].state = (1adc_conditions[i].max_adc, 0);
+ if (ret)
+ return NULL;
+
+ i++;
+ }
+
+ return pdata;
+}
+
static int adc_jack_probe(struct platform_device *pdev)
{
struct adc_jack_data *data;
struct adc_jack_pdata *pdata = dev_get_platdata(>dev);
int i, err = 0;
+ if (!pdata) {
+ pdata = get_pdata_from_dt(>dev);
+ if (!pdata)
+ return -EINVAL;
+ }
+
data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -188,11 +255,18 @@ static int adc_jack_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id of_adc_jack_match_tbl[] = {
+ { .compatible = "extcon-adc-jack", },
+ { /* end */ },
+};
+
+
static struct platform_driver adc_jack_driver = {
.probe = adc_jack_probe,
.remove = adc_jack_remove,
.driver = {
.name = "adc-jack",
+ .of_match_table = of_adc_jack_match_tbl,
.owner = THIS_MODULE,
},
};
--
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 09/13] extcon: extcon-class: move example to Documentation
This patch removes cable array example form extcon code, to avoid
littering driver namespace. Now it's located in extcon documentation.
Signed-off-by: Robert Baldyga
---
Documentation/extcon/extcon.txt | 108 +++
drivers/extcon/extcon-class.c | 32
include/linux/extcon.h | 42 ---
3 files changed, 108 insertions(+), 74 deletions(-)
create mode 100644 Documentation/extcon/extcon.txt
diff --git a/Documentation/extcon/extcon.txt b/Documentation/extcon/extcon.txt
new file mode 100644
index 000..6713f5f
--- /dev/null
+++ b/Documentation/extcon/extcon.txt
@@ -0,0 +1,108 @@
+Extcon - external connector
+===
+
+Extcon is generic framework used for notifying client drivers
+about specific cable connections and disconnections.
+
+Provider API
+
+
+Providers API consists of very few functions:
+
+extcon_dev_register() - register new extcon provider
+extcon_dev_unregister() - unregister extcon provider
+
+extcon_get_cable_state_() - get specific cable state
+extcon_set_cable_state_() - set specific cable state
+
+extcon_update_state() - update entire extcon state
+extcon_set_state() - set entire extcon state
+
+There are few fields in struct extcon_dev to be filled before passing it
+to extcon_dev_register() functions:
+
+name - name of extcon controller
+node - devicetree node of parent device
+supported_cable - array of strings with cable names ended with NULL pointer
+
+Example of cable array definition example can be found below:
+
+ enum extcon_cable_name {
+ EXTCON_USB = 0,
+ EXTCON_USB_HOST,
+ EXTCON_TA,
+ EXTCON_FAST_CHARGER,
+ EXTCON_SLOW_CHARGER,
+ EXTCON_CHARGE_DOWNSTREAM,
+ EXTCON_HDMI,
+ EXTCON_MHL,
+ EXTCON_DVI,
+ EXTCON_VGA,
+ EXTCON_DOCK,
+ EXTCON_LINE_IN,
+ EXTCON_LINE_OUT,
+ EXTCON_MIC_IN,
+ EXTCON_HEADPHONE_OUT,
+ EXTCON_SPDIF_IN,
+ EXTCON_SPDIF_OUT,
+ EXTCON_VIDEO_IN,
+ EXTCON_VIDEO_OUT,
+ EXTCON_MECHANICAL,
+ };
+
+ const char *extcon_cable_name[] = {
+ [EXTCON_USB]= "USB",
+ [EXTCON_USB_HOST] = "USB-Host",
+ [EXTCON_TA] = "TA",
+ [EXTCON_FAST_CHARGER] = "Fast-charger",
+ [EXTCON_SLOW_CHARGER] = "Slow-charger",
+ [EXTCON_CHARGE_DOWNSTREAM] = "Charge-downstream",
+ [EXTCON_HDMI] = "HDMI",
+ [EXTCON_MHL]= "MHL",
+ [EXTCON_DVI]= "DVI",
+ [EXTCON_VGA]= "VGA",
+ [EXTCON_DOCK] = "Dock",
+ [EXTCON_LINE_IN]= "Line-in",
+ [EXTCON_LINE_OUT] = "Line-out",
+ [EXTCON_MIC_IN] = "Microphone",
+ [EXTCON_HEADPHONE_OUT] = "Headphone",
+ [EXTCON_SPDIF_IN] = "SPDIF-in",
+ [EXTCON_SPDIF_OUT] = "SPDIF-out",
+ [EXTCON_VIDEO_IN] = "Video-in",
+ [EXTCON_VIDEO_OUT] = "Video-out",
+ [EXTCON_MECHANICAL] = "Mechanical",
+ };
+
+Cable name strings are used for debug messages and sysfs.
+
+After extcon device registration you can use functions modifying extcon state.
+If any extcon clients will register their interests in some cables, they will
+recieve notifications about cable state changes.
+
+Client API
+==
+
+Extcon client API is also pretty simple. It consists of funtions:
+
+of_extcon_get_cable() - returns extcon_cable at selected index
+of_extcon_get_cable_by_name() - returns extcon_cable associated with
+ selected name
+extcon_get_cable_by_name() - the same as above, but takes struct device
+instead of struct device_node
+
+extcon_register_interest() - register interest in selected cable
+extcon_unregister_interest() - unregister cable interest
+
+extcon_get_cable_state() - get state of given cable
+
+The extcon_register_interest() function takes three parameters,
+struct extcon_cable, struct extcon_cable_nb and extcon_notifier_fn_t
+which is pointer to callback function called when cable state changes.
+
+There are also two functions:
+
+extcon_register_notifier() - register notifier for entire extcon state
+extcon_unregister_notifier() - unregister such notifier
+
+But they should be used only for debug, and use of them in client drivers
+is not recommended.
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index ce76c08..2ea9a84 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -33,38 +33,6 @@
#include
#include
-/*
- * extcon_cable_name suggests the
[PATCH 10/13] extcon: extcon-gpio: add devicetree support
This patch modifies extcon-gpio driver to use initialization data from
devicetree if platform data is not available. It allows to set controller
and cable names, and another parameters from devicetree bindings.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-gpio.c | 63 ++--
include/linux/extcon/extcon-gpio.h |2 +-
2 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index fc90b7a..2a3cfd7 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -53,7 +55,7 @@ static void gpio_extcon_work(struct work_struct *work)
state = gpio_get_value(data->gpio);
if (data->gpio_active_low)
state = !state;
- extcon_set_state(>edev, state);
+ extcon_set_cable_state_(>edev, 0, state);
}
static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
@@ -70,7 +72,7 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
struct gpio_extcon_data *extcon_data =
container_of(edev, struct gpio_extcon_data, edev);
const char *state;
- if (extcon_get_state(edev))
+ if (extcon_get_cable_state_(edev, 0))
state = extcon_data->state_on;
else
state = extcon_data->state_off;
@@ -80,17 +82,50 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
return -EINVAL;
}
+static struct gpio_extcon_platform_data *get_pdata_from_dt(struct device *dev)
+{
+ int ret;
+ struct gpio_extcon_platform_data *pdata =
+ devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+
+ ret = of_property_read_string_index(dev->of_node,
+ "gpio-controller-name", 0, >name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_string_index(dev->of_node,
+ "gpio-cable-name", 0, >cable_name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_u32_array(dev->of_node,
+ "gpio-debounce", >debounce, 0);
+ if (ret)
+ pdata->debounce = 0;
+
+ pdata->gpio = of_get_gpio(dev->of_node, 0);
+ if (pdata->gpio < 0)
+ return NULL;
+
+ pdata->gpio_active_low = of_property_read_bool(dev->of_node,
+ "gpio-active-low");
+
+ pdata->check_on_resume = of_property_read_bool(dev->of_node,
+ "check-on-resume");
+ return pdata;
+}
+
static int gpio_extcon_probe(struct platform_device *pdev)
{
struct gpio_extcon_platform_data *pdata = dev_get_platdata(>dev);
struct gpio_extcon_data *extcon_data;
+ const char *gpio_extcon_cable[2];
int ret;
- if (!pdata)
- return -EBUSY;
- if (!pdata->irq_flags) {
- dev_err(>dev, "IRQ flag is not specified.\n");
- return -EINVAL;
+ if (!pdata) {
+ pdata = get_pdata_from_dt(>dev);
+ if (!pdata)
+ return -EINVAL;
}
extcon_data = devm_kzalloc(>dev, sizeof(struct gpio_extcon_data),
@@ -98,10 +133,14 @@ static int gpio_extcon_probe(struct platform_device *pdev)
if (!extcon_data)
return -ENOMEM;
+ gpio_extcon_cable[0] = pdata->cable_name;
+ gpio_extcon_cable[1] = NULL;
+
extcon_data->edev.name = pdata->name;
extcon_data->edev.dev.parent = >dev;
extcon_data->edev.node = pdev->dev.of_node;
extcon_data->gpio = pdata->gpio;
+ extcon_data->edev.supported_cable = gpio_extcon_cable;
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
@@ -135,8 +174,8 @@ static int gpio_extcon_probe(struct platform_device *pdev)
}
ret = request_any_context_irq(extcon_data->irq, gpio_irq_handler,
- pdata->irq_flags, pdev->name,
- extcon_data);
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+ pdev->name, extcon_data);
if (ret < 0)
goto err;
@@ -177,6 +216,11 @@ static int gpio_extcon_resume(struct device *dev)
}
#endif
+static struct of_device_id of_gpio_match_tbl[] = {
+ { .compatible = "extcon-gpio", },
+ { /* end */ },
+};
+
static SIMPLE_DEV_PM_OPS(gpio_extcon_pm_ops, NULL, gpio_extcon_resume);
static struct platform_driver gpio_extcon_driver = {
@@ -184,6 +228,7 @@ static struct platform_driver gpio_extcon_driver = {
.remove = gpio_extcon_remove,
.driver = {
.name =
[PATCH 08/13] extcon: extcon-class: simplify extcon_updata_state() function
This patch simplifies extcon_updata_state() function. There is greatly
simplified kobject_uevent preparation. Also meaning of variable passed
to raw_notifier_call_chain() (and in effect to _call_per_cable()) has
changed. Now positions on ones in variable 'val' in _call_per_cable()
indicates numbers of cables which changed their status. It allowed
to simplify also _call_per_cable() function.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c | 81 -
include/linux/extcon.h|1 -
2 files changed, 31 insertions(+), 51 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 2659805..ce76c08 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -206,59 +206,48 @@ int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state)
{
char name_buf[120];
char state_buf[120];
- char *prop_buf;
+ char *tmp;
char *envp[3];
int env_offset = 0;
int length;
unsigned long flags;
+ u32 change;
spin_lock_irqsave(>lock, flags);
- if (edev->state != ((edev->state & ~mask) | (state & mask))) {
- u32 old_state = edev->state;
-
- if (check_mutually_exclusive(edev, (edev->state & ~mask) |
- (state & mask))) {
+ change = (edev->state & mask) ^ (state & mask);
+ if (change) {
+ if (check_mutually_exclusive(edev, edev->state ^ change)) {
spin_unlock_irqrestore(>lock, flags);
return -EPERM;
}
- edev->state &= ~mask;
- edev->state |= state & mask;
-
- raw_notifier_call_chain(>nh, old_state, edev);
- /* This could be in interrupt handler */
- prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
- if (prop_buf) {
- length = name_show(>dev, NULL, prop_buf);
- if (length > 0) {
- if (prop_buf[length - 1] == '\n')
- prop_buf[length - 1] = 0;
- snprintf(name_buf, sizeof(name_buf),
- "NAME=%s", prop_buf);
- envp[env_offset++] = name_buf;
- }
- length = state_show(>dev, NULL, prop_buf);
- if (length > 0) {
- if (prop_buf[length - 1] == '\n')
- prop_buf[length - 1] = 0;
- snprintf(state_buf, sizeof(state_buf),
- "STATE=%s", prop_buf);
- envp[env_offset++] = state_buf;
- }
- envp[env_offset] = NULL;
- /* Unlock early before uevent */
- spin_unlock_irqrestore(>lock, flags);
+ edev->state ^= change;
- kobject_uevent_env(>dev.kobj, KOBJ_CHANGE, envp);
- free_page((unsigned long)prop_buf);
- } else {
- /* Unlock early before uevent */
- spin_unlock_irqrestore(>lock, flags);
+ raw_notifier_call_chain(>nh, change, edev);
+
+ tmp = name_buf + sprintf(name_buf, "NAME=");
+ length = name_show(>dev, NULL, tmp);
+ if (length > 0) {
+ if (tmp[length - 1] == '\n')
+ tmp[length - 1] = 0;
+ envp[env_offset++] = name_buf;
+ }
- dev_err(>dev, "out of memory in
extcon_set_state\n");
- kobject_uevent(>dev.kobj, KOBJ_CHANGE);
+ tmp = state_buf + sprintf(state_buf, "STATE=");
+ length = state_show(>dev, NULL, tmp);
+ if (length > 0) {
+ if (tmp[length - 1] == '\n')
+ tmp[length - 1] = 0;
+ envp[env_offset++] = state_buf;
}
+
+ envp[env_offset] = NULL;
+
+ /* Unlock early before uevent */
+ spin_unlock_irqrestore(>lock, flags);
+
+ kobject_uevent_env(>dev.kobj, KOBJ_CHANGE, envp);
} else {
/* No changes */
spin_unlock_irqrestore(>lock, flags);
@@ -464,18 +453,10 @@ static int _call_per_cable(struct notifier_block *nb,
unsigned long val,
{
struct extcon_cable_nb *obj = container_of(nb,
struct extcon_cable_nb, internal_nb);
- struct extcon_dev *edev = ptr;
-
- if ((val & (1 << obj->cable->cable_index)) !=
- (edev->state & (1 << obj->cable->cable_index))) {
- bool cable_state =
[PATCH 07/13] extcon: extcon-class: improve get_cable_state_()/set_cable_state_() functions
Added check if pointer to edev is not NULL, and updated documentation of index
parameter. Function extcon_find_cable_index() has been deleted and cannot be
used to retrieve cable number.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 2be0ac9..2659805 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -285,10 +285,12 @@ EXPORT_SYMBOL_GPL(extcon_set_state);
/**
* extcon_get_cable_state_() - Get the status of a specific cable.
* @edev: the extcon device that has the cable.
- * @index: cable index that can be retrieved by extcon_find_cable_index().
+ * @index: cable index in extcon device.
*/
int extcon_get_cable_state_(struct extcon_dev *edev, int index)
{
+ if (!edev)
+ return -ENODEV;
if (index < 0 || (edev->max_supported && edev->max_supported <= index))
return -EINVAL;
@@ -312,8 +314,7 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state);
/**
* extcon_set_cable_state_() - Set the status of a specific cable.
* @edev: the extcon device that has the cable.
- * @index: cable index that can be retrieved by
- * extcon_find_cable_index().
+ * @index: cable index in extcon device.
* @cable_state: the new cable status. The default semantics is
* true: attached / false: detached.
*/
@@ -322,6 +323,8 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
{
u32 state;
+ if (!edev)
+ return -ENODEV;
if (index < 0 || (edev->max_supported && edev->max_supported <= index))
return -EINVAL;
--
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: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP
On Wed, 2014-04-09 at 16:10 -0700, H. Peter Anvin wrote: > On 04/09/2014 04:01 PM, Fengguang Wu wrote: > > CC the KVM people: it looks like a KVM problem that can be triggered by > > > > qemu-system-x86_64 -cpu Haswell,+smep,+smap > > I'm really confused. First of all, is this a KVM problem or is it a > Qemu JIT problem? > > Either seems really wonky. It is questionable at best whether or not > Qemu in JIT mode should set the hypervisor bit IMO. However, even so, > you *better* not call VMCALL *just* because the hypervisor bit is set. > > The reason for it is that you have absolutely no idea what VMCALL is > going to do on any one hypervisor... different hypervisors even use > completely different conventions for VMCALL, and some might not accept > VMCALL at all and might just terminate your guest with extreme prejudice. > > So what is actually going on here? > > -hpa > I'm confused by the intended behavior of KVM.. Is the intention of the -cpu switch to fully emulate a particular CPU? If that's the case, the Intel documentation says bit 31 should always be 0, so the value returned by the cpuid instruction isn't correct. If the intention is to present a VM with a specific CPU architecture, the CPU ought to behave as described in Intel's virtualization documentation and just vmexit instead of faulting with invalid op, IMHO. I've already said the check in the code was insufficient, and I'm trying to fix that part now. :)
[PATCH 03/13] extcon: extcon-class: remove extcon_set_cable_state() function
This patch removes extcon_set_cable_state() and replace all calls of
this function witch extcon_set_cable_state_(), which is faster version.
This is first step of changing extcon API to faster and safer.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c| 17
drivers/extcon/extcon-max14577.c | 24 ++--
drivers/extcon/extcon-max77693.c | 79 +++---
drivers/extcon/extcon-max8997.c | 32 +--
drivers/extcon/extcon-palmas.c | 27 +
include/linux/extcon.h |8
6 files changed, 99 insertions(+), 88 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index a45c5e9..1b98c4e 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -358,23 +358,6 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
- * extcon_set_cable_state() - Set the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name.
- * @cable_state: the new cable status. The default semantics is
- * true: attached / false: detached.
- *
- * Note that this is slower than extcon_set_cable_state_.
- */
-int extcon_set_cable_state(struct extcon_dev *edev,
- const char *cable_name, bool cable_state)
-{
- return extcon_set_cable_state_(edev, extcon_find_cable_index
- (edev, cable_name), cable_state);
-}
-EXPORT_SYMBOL_GPL(extcon_set_cable_state);
-
-/**
* extcon_get_extcon_dev() - Get the extcon device instance from the name
* @extcon_name: The extcon name provided with extcon_dev_register()
*/
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 3846941..7a947d3 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -333,7 +333,7 @@ static int max14577_muic_get_cable_type(struct
max14577_muic_info *info,
static int max14577_muic_jig_handler(struct max14577_muic_info *info,
int cable_type, bool attached)
{
- char cable_name[32];
+ int cable;
int ret = 0;
u8 path = CTRL1_SW_OPEN;
@@ -344,17 +344,17 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
switch (cable_type) {
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_OFF:/* ADC_JIG_USB_OFF */
/* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-OFF");
+ cable = EXTCON_CABLE_JIG_USB_OFF;
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_ON: /* ADC_JIG_USB_ON */
/* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-ON");
+ cable = EXTCON_CABLE_JIG_USB_ON;
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_UART_OFF: /* ADC_JIG_UART_OFF */
/* PATH:AP_UART */
- strcpy(cable_name, "JIG-UART-OFF");
+ cable = EXTCON_CABLE_JIG_UART_OFF;
path = CTRL1_SW_UART;
break;
default:
@@ -367,7 +367,7 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, cable_name, attached);
+ extcon_set_cable_state_(info->edev, cable, attached);
return 0;
}
@@ -464,20 +464,22 @@ static int max14577_muic_chg_handler(struct
max14577_muic_info *info)
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, "USB", attached);
+ extcon_set_cable_state_(info->edev, EXTCON_CABLE_USB, attached);
break;
case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
- extcon_set_cable_state(info->edev, "TA", attached);
+ extcon_set_cable_state_(info->edev, EXTCON_CABLE_TA, attached);
break;
case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
- extcon_set_cable_state(info->edev,
- "Charge-downstream", attached);
+ extcon_set_cable_state_(info->edev,
+ EXTCON_CABLE_CHARGE_DOWNSTREAM, attached);
break;
case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
- extcon_set_cable_state(info->edev, "Slow-charger", attached);
+ extcon_set_cable_state_(info->edev,
+ EXTCON_CABLE_SLOW_CHARGER, attached);
break;
case MAX14577_CHARGER_TYPE_SPECIAL_1A:
- extcon_set_cable_state(info->edev, "Fast-charger", attached);
+ extcon_set_cable_state_(info->edev,
+ EXTCON_CABLE_FAST_CHARGER, attached);
break;
case
[PATCH 06/13] extcon: extcon-class: remove unused functions
This patch removes two functions, extcon_find_cable_index() and
extcon_get_edev_by_phandle(). They are not longer needed, since
extcon client API has changed to be oriented on extcon_cable instead
of extcon_dev.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c | 67 -
include/linux/extcon.h| 18 ---
2 files changed, 85 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 708b352..2be0ac9 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -283,32 +283,6 @@ int extcon_set_state(struct extcon_dev *edev, u32 state)
EXPORT_SYMBOL_GPL(extcon_set_state);
/**
- * extcon_find_cable_index() - Get the cable index based on the cable name.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name to be searched.
- *
- * Note that accessing a cable state based on cable_index is faster than
- * cable_name because using cable_name induces a loop with strncmp().
- * Thus, when get/set_cable_state is repeatedly used, using cable_index
- * is recommended.
- */
-int extcon_find_cable_index(struct extcon_dev *edev, const char *cable_name)
-{
- int i;
-
- if (edev->supported_cable) {
- for (i = 0; edev->supported_cable[i]; i++) {
- if (!strncmp(edev->supported_cable[i],
- cable_name, CABLE_NAME_MAX))
- return i;
- }
- }
-
- return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(extcon_find_cable_index);
-
-/**
* extcon_get_cable_state_() - Get the status of a specific cable.
* @edev: the extcon device that has the cable.
* @index: cable index that can be retrieved by extcon_find_cable_index().
@@ -876,47 +850,6 @@ void extcon_dev_unregister(struct extcon_dev *edev)
}
EXPORT_SYMBOL_GPL(extcon_dev_unregister);
-#ifdef CONFIG_OF
-/*
- * extcon_get_edev_by_phandle - Get the extcon device from devicetree
- * @dev - instance to the given device
- * @index - index into list of extcon_dev
- *
- * return the instance of extcon device
- */
-struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
-{
- struct device_node *node;
- struct extcon_dev *edev;
-
- if (!dev->of_node) {
- dev_err(dev, "device does not have a device node entry\n");
- return ERR_PTR(-EINVAL);
- }
-
- node = of_parse_phandle(dev->of_node, "extcon", index);
- if (!node) {
- dev_err(dev, "failed to get phandle in %s node\n",
- dev->of_node->full_name);
- return ERR_PTR(-ENODEV);
- }
-
- edev = of_extcon_get_extcon_dev(node);
- if (!edev) {
- dev_err(dev, "unable to get extcon device : %s\n", node->name);
- return ERR_PTR(-ENODEV);
- }
-
- return edev;
-}
-#else
-struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
-{
- return ERR_PTR(-ENOSYS);
-}
-#endif /* CONFIG_OF */
-EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
-
static int __init extcon_class_init(void)
{
return create_extcon_class();
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index a571cad..939a7b0 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -210,8 +210,6 @@ extern int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state);
* They are used to access the status of each cable based on the cable_name
tt or cable_index, which is retrieved by extcon_find_cable_index
*/
-extern int extcon_find_cable_index(struct extcon_dev *sdev,
- const char *cable_name);
extern int extcon_get_cable_state_(struct extcon_dev *edev, int cable_index);
extern int extcon_set_cable_state_(struct extcon_dev *edev,
int cable_index, bool cable_state);
@@ -252,11 +250,6 @@ extern int extcon_register_notifier(struct extcon_dev
*edev,
extern int extcon_unregister_notifier(struct extcon_dev *edev,
struct notifier_block *nb);
-/*
- * Following API get the extcon device from devicetree.
- * This function use phandle of devicetree to get extcon device directly.
- */
-extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int
index);
#else /* CONFIG_EXTCON */
static inline int extcon_dev_register(struct extcon_dev *edev)
{
@@ -281,12 +274,6 @@ static inline int extcon_update_state(struct extcon_dev
*edev, u32 mask,
return 0;
}
-static inline int extcon_find_cable_index(struct extcon_dev *edev,
- const char *cable_name)
-{
- return 0;
-}
-
static inline int extcon_get_cable_state_(struct extcon_dev *edev,
int cable_index)
{
@@ -341,10 +328,5 @@ static inline int extcon_unregister_interest(struct
extcon_cable_nb
[PATCH 04/13] extcon: extcon-class: match extcon device by devicetree node
This patch modifies extcon_get_edev_by_phandle() function, to match
extcon device by devicetree node. This modification needed to add
field 'node' in extcon_dev structure, and fill it in probe function
of each extcon provider driver.
This patch replaces also extcon_get_extcon_dev() function with
of_extcon_get_extcon_dev(), returning extcon device which contains
given devicetree node.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-adc-jack.c |1 +
drivers/extcon/extcon-arizona.c |1 +
drivers/extcon/extcon-class.c| 19 +--
drivers/extcon/extcon-gpio.c |1 +
drivers/extcon/extcon-max14577.c |2 ++
drivers/extcon/extcon-max77693.c |1 +
drivers/extcon/extcon-max8997.c |1 +
drivers/extcon/extcon-palmas.c |1 +
include/linux/extcon.h |8 ++--
9 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index e23f1c2..d65915e 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -111,6 +111,7 @@ static int adc_jack_probe(struct platform_device *pdev)
}
data->edev.dev.parent = >dev;
+ data->edev.node = pdev->dev.of_node;
data->edev.supported_cable = pdata->cable_names;
/* Check the length of array and set num_cables */
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 98a14f6..fc69cca 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1153,6 +1153,7 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
info->edev.name = "Headset Jack";
info->edev.dev.parent = arizona->dev;
+ info->edev.node = pdev->dev.of_node;
info->edev.supported_cable = arizona_cable;
ret = extcon_dev_register(>edev);
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 1b98c4e..1075ce8 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -358,24 +358,23 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
- * extcon_get_extcon_dev() - Get the extcon device instance from the name
- * @extcon_name: The extcon name provided with extcon_dev_register()
+ * of_extcon_get_extcon_dev() - Get the extcon device instance from the name
+ * @np: The node of extcon device
*/
-struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name)
+struct extcon_dev *of_extcon_get_extcon_dev(const struct device_node *np)
{
- struct extcon_dev *sd;
+ struct extcon_dev *edev;
mutex_lock(_dev_list_lock);
- list_for_each_entry(sd, _dev_list, entry) {
- if (!strcmp(sd->name, extcon_name))
+ list_for_each_entry(edev, _dev_list, entry) {
+ if (edev->node == np)
goto out;
}
- sd = NULL;
+ edev = NULL;
out:
mutex_unlock(_dev_list_lock);
- return sd;
+ return edev;
}
-EXPORT_SYMBOL_GPL(extcon_get_extcon_dev);
static int _call_per_cable(struct notifier_block *nb, unsigned long val,
void *ptr)
@@ -827,7 +826,7 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct device
*dev, int index)
return ERR_PTR(-ENODEV);
}
- edev = extcon_get_extcon_dev(node->name);
+ edev = of_extcon_get_extcon_dev(node);
if (!edev) {
dev_err(dev, "unable to get extcon device : %s\n", node->name);
return ERR_PTR(-ENODEV);
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 13d5222..fc90b7a 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -100,6 +100,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
extcon_data->edev.name = pdata->name;
extcon_data->edev.dev.parent = >dev;
+ extcon_data->edev.node = pdev->dev.of_node;
extcon_data->gpio = pdata->gpio;
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 7a947d3..b017a0d 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -676,6 +676,8 @@ static int max14577_muic_probe(struct platform_device *pdev)
return -ENOMEM;
}
info->edev->name = DEV_NAME;
+ info->edev->dev.parent = >dev;
+ info->edev->node = pdev->dev.of_node;
info->edev->supported_cable = max14577_extcon_cable;
ret = extcon_dev_register(info->edev);
if (ret) {
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 7a014cd..2cd8892 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1200,6 +1200,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
}
[PATCH 00/13] extcon: major rework
This patchset adds many improvements to extcon class driver and extcon provider drivers. It changes extcon API to faster and safer by replaceing function taking extcon and cable names with functions working with structures representing this objects. It adds more advanced devicetree support which allows to pass specified cables to client drivers. It gives independency from cable naming conventions in individual extcon provider drivers, and allows to simply connect client drivers with providers in way that being transpatent for both of them. It adds also some minor fixes like additional checks for safety increase, and another improvements. Also added some improvements to extcon provider drivers, improved devicetree support and updated them to use faster extcon API. Patches contains also documentation for extcon, and devicetree bindings for all provider drivers. More details can be found in commit messages and Documentation. Best regards Robert Baldyga Samsung R Institute Poland Robert Baldyga (13): Documentation: add extcon devicetree bindings Documentation: update charger-manager devicetree bindings extcon: extcon-class: remove extcon_set_cable_state() function extcon: extcon-class: match extcon device by devicetree node extcon: extcon-class: improve extcon client API extcon: extcon-class: remove unused functions extcon: extcon-class: improve get_cable_state_()/set_cable_state_() functions extcon: extcon-class: simplify extcon_updata_state() function extcon: extcon-class: move example to Documentation extcon: extcon-gpio: add devicetree support extcon: extcon-adc-jack: add devicetree support extcon: extcon-max8997: check if pdata exists extcon: extcon-max77693: check if pdata exists .../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++ .../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++ .../devicetree/bindings/extcon/extcon-bindings.txt | 36 ++ .../devicetree/bindings/extcon/extcon-gpio.txt | 63 +++ .../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++ .../devicetree/bindings/extcon/extcon-max77693.txt | 56 +++ .../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++ .../devicetree/bindings/extcon/extcon-palmas.txt | 37 +- .../bindings/power_supply/charger-manager.txt | 11 +- Documentation/extcon/extcon.txt| 108 + drivers/extcon/extcon-adc-jack.c | 75 drivers/extcon/extcon-arizona.c|1 + drivers/extcon/extcon-class.c | 412 +--- drivers/extcon/extcon-gpio.c | 64 ++- drivers/extcon/extcon-max14577.c | 26 +- drivers/extcon/extcon-max77693.c | 82 ++-- drivers/extcon/extcon-max8997.c| 35 +- drivers/extcon/extcon-palmas.c | 28 +- drivers/power/charger-manager.c| 36 +- drivers/usb/dwc3/dwc3-omap.c | 68 ++-- drivers/usb/phy/phy-omap-otg.c | 72 ++-- include/linux/extcon.h | 157 +++- include/linux/extcon/extcon-gpio.h |2 +- include/linux/platform_data/usb-omap1.h|2 - include/linux/power/charger-manager.h |6 +- 25 files changed, 1067 insertions(+), 515 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-bindings.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max14577.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max77693.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max8997.txt create mode 100644 Documentation/extcon/extcon.txt -- 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 02/13] Documentation: update charger-manager devicetree bindings
This patch changes charger-manager bindings to be compatible with
new extcon bindings.
Signed-off-by: Robert Baldyga
---
.../bindings/power_supply/charger-manager.txt | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
index 2b33750..f987bb5 100644
--- a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
+++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
@@ -10,8 +10,7 @@ Required properties :
- subnode :
- cm-regulator-name : name of charger regulator
- subnode :
- - cm-cable-name : name of charger cable
- - cm-cable-extcon : name of extcon dev
+ - extcon-cable : specified extcon cable
(optional) - cm-cable-min : minimum current of cable
(optional) - cm-cable-max : maximum current of cable
@@ -65,14 +64,14 @@ Example :
regulator@0 {
cm-regulator-name = "chg-reg";
cable@0 {
- cm-cable-name = "USB";
- cm-cable-extcon = "extcon-dev.0";
+ /* USB cable */
+ extcon-cable = < 0>;
cm-cable-min = <475000>;
cm-cable-max = <50>;
};
cable@1 {
- cm-cable-name = "TA";
- cm-cable-extcon = "extcon-dev.0";
+ /* TA cable */
+ extcon-cable = < 1>;
cm-cable-min = <65>;
cm-cable-max = <675000>;
};
--
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: [writeback] 6903673566d: +2.5% fileio.requests_per_sec
On Thu, Apr 10, 2014 at 09:08:21PM +0800, Fengguang Wu wrote:
> On Thu, Apr 10, 2014 at 08:41:37PM +0800, Fengguang Wu wrote:
> > Hi Jan,
> >
> > I tried your writeback dirty list patchset and noticed some ups/downs.
> > The main performance changes are
> >
> > 1) +2.5% fileio.requests_per_sec
> > 2) -7.1% iostat.md0.wkB/s
> >
> > git://bee.sh.intel.com/git/wfg/linux-devel.git jan-dirty-list
> > commit 6903673566d0289680e593dac088c787d119b067 ("writeback: Replace
> > several writeback lists with inode tagging")
> >
> > 836ecc5f024669e 6903673566d0289680e593dac
> > --- -
> > 6526 ~ 0% +3.2% 6736 ~ 0%
> > snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqrewr-sync
> > 6441 ~ 0% +1.8% 6558 ~ 0%
> > snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqwr-sync
> > 12968 ~ 0% +2.5% 13295 ~ 0% TOTAL fileio.requests_per_sec
> >
> > 836ecc5f024669e 6903673566d0289680e593dac
> > --- -
> > 398147 ~ 0% -7.1% 369866 ~ 0%
> > lkp-st02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd
> > 398147 ~ 0% -7.1% 369866 ~ 0% TOTAL iostat.md0.wkB/s
>
> Here are the complete power performance comparisons:
>
> # the higher index, the better
> 98 perf-index ea87e2e7e0905325c58cf5643
>105 power-index ea87e2e7e0905325c58cf5643
> 99 latency-index ea87e2e7e0905325c58cf5643
Note that some few performance changes are caused by CPU frequency
unstableness. Sorry for showing results with some defects - I only
realized that after reading through the results..
v3.14-rc8 ea87e2e7e0905325c58cf5643
--- -
1.12 ~ 0% -0.4% 1.12 brickland1/micro/will-it-scale/brk1
1.14 ~ 0% +2.0% 1.16
brickland1/micro/will-it-scale/context_switch1
1.15 ~ 1% +0.6% 1.16
brickland1/micro/will-it-scale/eventfd1
1.23 ~ 2% +7.6% 1.32
brickland1/micro/will-it-scale/futex1
1.24 ~ 4% -4.2% 1.19
brickland1/micro/will-it-scale/futex2
1.15 ~ 1% -0.1% 1.15
brickland1/micro/will-it-scale/futex3
1.18 ~ 3% -4.2% 1.13
brickland1/micro/will-it-scale/futex4
1.14 ~ 1% -0.6% 1.13
brickland1/micro/will-it-scale/getppid1
1.09 ~14% +5.6% 1.15 brickland1/micro/will-it-scale/lock1
1.13 ~ 1% +1.9% 1.15
brickland1/micro/will-it-scale/lseek1
1.18 ~ 2% +3.6% 1.22
brickland1/micro/will-it-scale/malloc1
1.13 ~ 0% +0.6% 1.14
brickland1/micro/will-it-scale/malloc2
1.21 ~ 1% +2.3% 1.24 brickland1/micro/will-it-scale/mmap1
1.18 ~ 1% +6.6% 1.26 brickland1/micro/will-it-scale/mmap2
1.10 ~15% +5.8% 1.16 brickland1/micro/will-it-scale/open1
1.11 ~15% +4.9% 1.16 brickland1/micro/will-it-scale/open2
1.08 ~13% +4.2% 1.13
brickland1/micro/will-it-scale/page_fault1
1.08 ~14% +5.8% 1.14
brickland1/micro/will-it-scale/page_fault2
1.09 ~14% +5.0% 1.14
brickland1/micro/will-it-scale/page_fault3
1.08 ~14% +4.2% 1.13 brickland1/micro/will-it-scale/pipe1
1.09 ~15% +5.6% 1.15 brickland1/micro/will-it-scale/poll1
1.07 ~14% +5.2% 1.13 brickland1/micro/will-it-scale/poll2
1.09 ~14% +4.9% 1.14
brickland1/micro/will-it-scale/posix_semaphore1
1.07 ~14% +10.8% 1.19
brickland1/micro/will-it-scale/pread1
1.12 ~15% +4.5% 1.17
brickland1/micro/will-it-scale/pread2
1.08 ~14% +5.3% 1.14
brickland1/micro/will-it-scale/pthread_mutex1
1.08 ~14% +4.3% 1.13
brickland1/micro/will-it-scale/pthread_mutex2
1.09 ~14% +4.0% 1.13
brickland1/micro/will-it-scale/pwrite1
1.07 ~14% +5.1% 1.12
brickland1/micro/will-it-scale/pwrite2
1.07 ~14% +8.2% 1.16 brickland1/micro/will-it-scale/read1
1.07 ~14% +5.3% 1.13 brickland1/micro/will-it-scale/read2
1.09 ~14% +6.4% 1.16
brickland1/micro/will-it-scale/readseek
1.14 ~ 0% +0.4% 1.14
brickland1/micro/will-it-scale/sched_yield
1.36 ~ 5% +1.3% 1.38
brickland1/micro/will-it-scale/signal1
1.15 ~ 2% -2.4% 1.12 brickland1/micro/will-it-scale/unix1
1.11 ~ 0% +1.5% 1.13
brickland1/micro/will-it-scale/unlink1
1.18 ~ 1% +0.8% 1.19
brickland1/micro/will-it-scale/unlink2
1.13 ~ 0% +0.2% 1.13
brickland1/micro/will-it-scale/write1
1.15 ~ 1% +0.6% 1.16
[PATCH 01/13] Documentation: add extcon devicetree bindings
This patch adds extcon devicetree bindings. Documentation describes in general
client and provider bindings, and contains detailed desctiprion of bindings
for each extcon provider.
Signed-off-by: Robert Baldyga
---
.../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++
.../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++
.../devicetree/bindings/extcon/extcon-bindings.txt | 36 +++
.../devicetree/bindings/extcon/extcon-gpio.txt | 63
.../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++
.../devicetree/bindings/extcon/extcon-max77693.txt | 56 +
.../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++
.../devicetree/bindings/extcon/extcon-palmas.txt | 37 ++--
8 files changed, 393 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-bindings.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max14577.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max77693.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max8997.txt
diff --git a/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
b/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
new file mode 100644
index 000..6e43891
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
@@ -0,0 +1,60 @@
+* ADC JACK Extcon Controller
+
+ADC JACK extcon controller is responsible for cable detection.
+
+Required Properties:
+
+- compatible: should be "extcon-adc-jack".
+
+- #extcon-cells: should be 1.
+
+- subnode : node describing list of cables.
+ - subnode :
+ - cable-name: name of specific cable
+ - adc-min: minimum specific cable ADC values range
+ - adc-max: maximum specific cable ADC values range
+
+Subnodes of node 'cables' describes specific cables with ADC value ranges
+associated with this cables. When measured ADC value will be between min and
+max value for specific cable, clients will be notified about connection of
+this cable. Value ranges for individual cables cannot be overlaping.
+
+Example 1: An example of a extcon controller node is listed below.
+
+ extcon: adc-jack {
+ compatible = "extcon-adc-jack";
+ #extcon-cells = <1>;
+
+ cables {
+ cable@0 {
+ cable-name = "CABLE-0";
+ adc-min = 120;
+ adc-max = 240;
+ }
+ cable@1 {
+ cable-name = "CABLE-1";
+ adc-min = 250;
+ adc-max = 400;
+ }
+ cable@2 {
+ cable-name = "CABLE-2";
+ adc-min = 500;
+ adc-max = 700;
+ };
+ };
+ };
+
+Example 2: USB controller node that uses cable from the extcon
+ controller. Refer to the standard extcon bindings for
+ information about 'extcon-cables' and 'extcon-names'
+ property.
+
+ usb@1248 {
+ vusb_d-supply = <_reg>;
+ vusb_a-supply = <_reg>;
+
+ extcon-cables = < 0>;
+ extcon-names = "USB";
+
+ status = "okay";
+ };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
new file mode 100644
index 000..9af4422
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -0,0 +1,47 @@
+* Wolfson Arizona Extcon Controller
+
+The Wolfson Arizona Extcon Controller is responsible for cable
+detection.
+
+Required Properties:
+
+- compatible: should be "wlf,arizona-extcon".
+
+- #extcon-cells: should be 1.
+
+The following is the list of cables detected by the controller. Each
+cable is assigned an identifier and client nodes use this identifies
+to specify the cable which they are interested in.
+
+ CableID
+
+
+ Mechanical 0
+ Microphone 1
+ Headphone2
+ Line-out 3
+
+Example 1: An example of a extcon controller node is listed below.
+
+ extcon: arizona-extcon {
+ compatible = "wlf,arizona-extcon";
+ #extcon-cells = <1>;
+ };
+
+Example 2: Audio controller node that uses cable from the extcon
+ controller. Refer to the standard extcon bindings for
+
Re: [RFC PATCH v2 4/6] uprobes/x86: Emulate rip-relative call's
(2014/04/10 21:53), Denys Vlasenko wrote:
> On 04/09/2014 09:44 PM, Oleg Nesterov wrote:
>> +static void ttt_clear_displacement(struct arch_uprobe *auprobe, struct insn
>> *insn)
>
> Branch instruction's offset isn't called "displacement"
> on x86.
>
> How about ttt_clear_branch_offset?
I like his idea. "displacement" on x86 is so confused especially
with using x86 insn decoder.
Thank you,
>
>> +{
>> +/*
>> + * Turn this insn into "call 1f; 1:", this is what we will execute
>> + * out-of-line if ->emulate() fails.
>> + *
>> + * In the likely case this will lead to arch_uprobe_abort_xol(), but
>> + * see the comment in ->emulate(). So we need to ensure that the new
>> + * ->ip can't fall into non-canonical area and trigger #GP.
>> + *
>> + * We could turn it into (say) "pushf", but then we would need to
>> + * divorce ->insn[] and ->ixol[]. We need to preserve the 1st byte
>> + * of ->insn[] for set_orig_insn().
>> + */
>> +memset(auprobe->insn + insn_offset_immediate(insn),
>> +0, insn->immediate.nbytes);
>> +}
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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 1/4 v2] perf: Allow ability to map cpus to nodes easily
On Thu, Apr 10, 2014 at 11:31:46AM +0200, Jiri Olsa wrote:
> On Mon, Apr 07, 2014 at 02:55:21PM -0400, Don Zickus wrote:
>
> SNIP
>
> > +static int init_cpunode_map(void)
> > +{
> > + int i;
> > +
> > + set_max_cpu_num();
> > + set_max_node_num();
> > +
> > + cpunode_map = calloc(max_cpu_num, sizeof(int));
> > + if (!cpunode_map) {
> > + pr_err("%s: calloc failed\n", __func__);
> > + goto out;
> shuld probably be ^^^:
>
> return -1;
>
> > + }
> > +
> > + for (i = 0; i < max_cpu_num; i++)
> > + cpunode_map[i] = -1;
> > +
> > + return 0;
> > +out:
> > + return -1;
>
> and remove 'out' label code
Sorry, probably leftover code that after snipping and changing didn't get
noticed. Thanks.
>
> other than that, it seems ok.. I'll queue it
I assume you are making the changes locally or should I resubmit?
Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 4/5] Documentation: add the Marvell Berlin pinctrl documentation
Signed-off-by: Antoine Ténart
---
.../bindings/pinctrl/marvell,berlin-pinctrl.txt| 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
diff --git
a/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
new file mode 100644
index ..e21538a37734
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
@@ -0,0 +1,43 @@
+* Pinctrl driver for the Marvell Berlin SoCs
+
+The pins controlled by the Marvell Berlin controller are organized in groups.
+Configuration is done by group, so no actual pin information is needed.
+
+Required properties:
+- compatible: "marvell-berlin2cd-pinctrl",
+ "marvell-berlin2-pinctrl",
+ "marvell-berlin2q-pinctrl"
+- reg: registers physical addresses and lengths of the pin controller.
+- reg-names: name of the register regions.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+A pinctrl should contains subnodes representing the pinctrl pin group
+configurations, one per group. Each subnode has the group name and the muxing
+function used.
+
+Required subnode-properties:
+- berlin,group: a string describing the group's name.
+- berlin,function: the function used to mux the group.
+ 0: function 0
+ 1: function 1
+ ...
+
+Example:
+
+pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2q-pinctrl";
+ reg = <0xea 0x08>, <0xfc 0x44>;
+ reg-names = "global_base", "sm_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "GSM12";
+ berlin,function = <0>;
+ };
+}
+
+ {
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
+};
--
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 RESEND 5/5] ARM: dts: berlin: add the pinctrl node and muxing setup for uarts
The uart0 pinmux configuration is in the dtsi because uart0 will always
use uart0-pmux to work, no other possibility. Same thing for uart1.
Signed-off-by: Antoine Ténart
---
arch/arm/boot/dts/berlin2.dtsi | 20
arch/arm/boot/dts/berlin2cd.dtsi | 13 +
arch/arm/boot/dts/berlin2q.dtsi | 20
3 files changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 56a1af2f1052..43eb90c36050 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -176,6 +176,22 @@
};
};
+ pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2-pinctrl";
+ reg = <0xea 0x08>, <0xfc 0x44>;
+ reg-names = "global_base", "apb_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "GSM4";
+ berlin,function = <0>;
+ };
+
+ uart1_pmux: uart1-pmux {
+ berlin,group = "GSM5";
+ berlin,function = <1>;
+ };
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -191,6 +207,8 @@
reg-io-width = <1>;
interrupts = <8>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
@@ -201,6 +219,8 @@
reg-io-width = <1>;
interrupts = <9>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 094968c27533..4c04cff89226 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -169,6 +169,17 @@
};
};
+ pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2cd-pinctrl";
+ reg = <0xea 0x08>, <0xfc 0x44>;
+ reg-names = "global_base", "apb_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "G6";
+ berlin,function = <0>;
+ };
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -184,6 +195,8 @@
reg-io-width = <1>;
interrupts = <8>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 07452a7483fa..e6e556055dfc 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -183,6 +183,22 @@
};
};
+ pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2q-pinctrl";
+ reg = <0xea 0x4c>, <0xfcd000 0x44>;
+ reg-names = "global_base", "sm_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "GSM12";
+ berlin,function = <0>;
+ };
+
+ uart1_pmux: uart1-pmux {
+ berlin,group = "GSM14";
+ berlin,function = <1>;
+ };
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -198,6 +214,8 @@
interrupts = <8>;
clocks = <>;
reg-shift = <2>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
@@ -208,6 +226,8 @@
interrupts = <9>;
clocks = <>;
reg-shift = <2>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
[PATCH RESEND 0/5] ARM: berlin: add pinctrl support
I made a typo in the LAKML address, so resend it. This series add support for the Marvell Berlin pinctrl, allowing to configure the pinmuxing from the device tree. This is a group based pinmux and only group informations are defined. For this to work a modification in the pinctrl framework is needed so that get_group_pin could not be defined. Please have a look on patches 1/5 and 2/5 commit logs. This serie applies on top of patches introducing the Marvell Berlin BG2Q you can find on Sebastian's for-next branch[1] and Alexandre's BG2Q symbol introduction[2]. Tested on the Berlin BG2Q. [1] https://github.com/shesselba/linux-berlin/commits/for-next [2] https://patchwork.kernel.org/patch/3876141/ Antoine Ténart (5): pinctrl: allows not to define the get_group_pins operation pinctrl: berlin: add a pinctrl driver for Marvell Berlin SoCs ARM: berlin: add the pinctrl dependency for the Marvell Berlin SoCs Documentation: add the Marvell Berlin pinctrl documentation ARM: dts: berlin: add the pinctrl node and muxing setup for uarts .../bindings/pinctrl/marvell,berlin-pinctrl.txt| 43 ++ arch/arm/boot/dts/berlin2.dtsi | 20 + arch/arm/boot/dts/berlin2cd.dtsi | 13 + arch/arm/boot/dts/berlin2q.dtsi| 20 + arch/arm/mach-berlin/Kconfig | 2 + drivers/pinctrl/Kconfig| 4 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/core.c | 17 +- drivers/pinctrl/pinctrl-berlin.c | 498 + drivers/pinctrl/pinctrl-berlin.h | 72 +++ drivers/pinctrl/pinmux.c | 23 +- 11 files changed, 696 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-berlin.c create mode 100644 drivers/pinctrl/pinctrl-berlin.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/
Re: [writeback] 6903673566d: +2.5% fileio.requests_per_sec
On Thu, Apr 10, 2014 at 08:41:37PM +0800, Fengguang Wu wrote:
> Hi Jan,
>
> I tried your writeback dirty list patchset and noticed some ups/downs.
> The main performance changes are
>
> 1) +2.5% fileio.requests_per_sec
> 2) -7.1% iostat.md0.wkB/s
>
> git://bee.sh.intel.com/git/wfg/linux-devel.git jan-dirty-list
> commit 6903673566d0289680e593dac088c787d119b067 ("writeback: Replace several
> writeback lists with inode tagging")
>
> 836ecc5f024669e 6903673566d0289680e593dac
> --- -
> 6526 ~ 0% +3.2% 6736 ~ 0%
> snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqrewr-sync
> 6441 ~ 0% +1.8% 6558 ~ 0%
> snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqwr-sync
> 12968 ~ 0% +2.5% 13295 ~ 0% TOTAL fileio.requests_per_sec
>
> 836ecc5f024669e 6903673566d0289680e593dac
> --- -
> 398147 ~ 0% -7.1% 369866 ~ 0%
> lkp-st02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd
> 398147 ~ 0% -7.1% 369866 ~ 0% TOTAL iostat.md0.wkB/s
Here are the complete power performance comparisons:
# the higher index, the better
98 perf-index ea87e2e7e0905325c58cf5643
105 power-index ea87e2e7e0905325c58cf5643
99 latency-index ea87e2e7e0905325c58cf5643
v3.14-rc8 ea87e2e7e0905325c58cf5643
--- -
1193524 +8.9%1299790
brickland2/micro/vm-scalability/300s-anon-cow-rand-64G
205 -0.9%2041914
brickland2/micro/vm-scalability/300s-anon-cow-rand-mt-64G
10839519 -2.1% 10608884
brickland2/micro/vm-scalability/300s-anon-cow-seq-1T
26035343 +22.6% 31908627
brickland2/micro/vm-scalability/300s-anon-cow-seq-mt-1T
1814424 ~ 0% -0.3%1808366
brickland2/micro/vm-scalability/300s-anon-r-rand-mt
3321379 ~14% -14.9%2824943
brickland2/micro/vm-scalability/300s-anon-r-rand
10737450 ~ 8% -13.4%9300338
brickland2/micro/vm-scalability/300s-anon-r-seq-mt
56930858 ~31% -31.0% 39271193
brickland2/micro/vm-scalability/300s-anon-r-seq
3895406 ~10% -6.5%3641748
brickland2/micro/vm-scalability/300s-anon-rx-rand-mt
2815440 ~13% -13.2%2443920
brickland2/micro/vm-scalability/300s-anon-rx-seq-mt
1744586 +0.5%1752816
brickland2/micro/vm-scalability/300s-anon-w-rand-64G
1485732 +0.5%1493516
brickland2/micro/vm-scalability/300s-anon-w-rand-mt-64G
23398782 -2.7% 22776628
brickland2/micro/vm-scalability/300s-anon-w-seq-1T
6179895 -0.9%6126126
brickland2/micro/vm-scalability/300s-anon-w-seq-mt-64G
2050178 +8.8%2230773
brickland2/micro/vm-scalability/300s-anon-wx-rand-mt-64G
730440 -0.0% 730200
brickland2/micro/vm-scalability/300s-anon-wx-seq-mt-1T
1753278 ~ 1% -2.7%1705762
brickland2/micro/vm-scalability/300s-lru-file-mmap-read-rand
3548596 ~15% -15.9%2984023
brickland2/micro/vm-scalability/300s-lru-file-mmap-read
2094887 ~ 0% -0.3%2088757
brickland2/micro/vm-scalability/300s-lru-file-readonce
5288504 ~33% -33.0%3542054
brickland2/micro/vm-scalability/300s-lru-file-readtwice
26681167 -1.5% 26273119
brickland2/micro/vm-scalability/300s-lru-shm-128G
1352290 +2.7%1388276
brickland2/micro/vm-scalability/300s-lru-shm-rand-64G
1582183 ~ 4% +10.1%1742202
brickland2/micro/vm-scalability/300s-mmap-pread-rand-mt
2530025 ~11% -11.6%2237193
brickland2/micro/vm-scalability/300s-mmap-pread-rand
7963273 ~12% -9.8%7182114
brickland2/micro/vm-scalability/300s-mmap-pread-seq-mt
38368788 ~37% -39.9% 23048889
brickland2/micro/vm-scalability/300s-mmap-pread-seq
1761540 ~ 1% -0.3%1755774
brickland2/micro/vm-scalability/300s-mmap-xread-rand-mt
10933828 ~46% -44.9%6019920
brickland2/micro/vm-scalability/300s-mmap-xread-seq-mt
3.384e+08 ~ 0% +0.2% 3.391e+08
brickland2/micro/vm-scalability/300s-mremap-xread-rand-mt
1291559 +1.6%1311590
brickland2/micro/vm-scalability/300s-msync-mt-64G
3555867 +4.8%3728204
brickland2/micro/vm-scalability/300s-remap-128G
3456703 +0.2%3461950
brickland2/micro/vm-scalability/300s-shm-pread-rand-16G
3294497 +0.2%3299782
brickland2/micro/vm-scalability/300s-shm-pread-rand-mt-16G
18343419 -1.6% 18056113
brickland2/micro/vm-scalability/300s-shm-pread-seq-1T
8826997 -6.1%8284733
brickland2/micro/vm-scalability/300s-shm-pread-seq-mt-1T
3474590 -0.2%3466782
brickland2/micro/vm-scalability/300s-shm-xread-rand-16G
[PATCH RESEND 1/5] pinctrl: allows not to define the get_group_pins operation
When using a group only pinctrl driver, which does not have any
information on the pins it is useless to define a get_group_pins
always returning an empty list of pins.
When not using get_group_pin[1], a driver must implement it so
pins = NULL and num_pins = 0. This patch makes it the default
behaviour if not defined in the pinctrl driver when used in
pinmux enable and disable funtions and in pinctrl_groups_show.
It also adds a check in pinctrl_get_group_pins and return -EINVAL if
not defined. This function is called in the gpiolib when adding when
pingroup range. It cannot be used if no group is defined, so this seams
reasonable.
[1] get_group_pin(struct pinctrl_dev *pctldev,
unsigned selector,
const unsigned **pins,
unsigned *num_pins);
Signed-off-by: Antoine Ténart
---
drivers/pinctrl/core.c | 17 ++---
drivers/pinctrl/pinmux.c | 23 +--
2 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe6091566a..e09474ecde23 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -468,6 +468,9 @@ int pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
const char *pin_group,
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
int gs;
+ if (!pctlops->get_group_pins)
+ return -EINVAL;
+
gs = pinctrl_get_group_selector(pctldev, pin_group);
if (gs < 0)
return gs;
@@ -1362,15 +1365,16 @@ static int pinctrl_groups_show(struct seq_file *s, void
*what)
seq_puts(s, "registered pin groups:\n");
while (selector < ngroups) {
- const unsigned *pins;
- unsigned num_pins;
+ const unsigned *pins = NULL;
+ unsigned num_pins = 0;
const char *gname = ops->get_group_name(pctldev, selector);
const char *pname;
- int ret;
+ int ret = 0;
int i;
- ret = ops->get_group_pins(pctldev, selector,
- , _pins);
+ if (ops->get_group_pins)
+ ret = ops->get_group_pins(pctldev, selector,
+ , _pins);
if (ret)
seq_printf(s, "%s [ERROR GETTING PINS]\n",
gname);
@@ -1694,8 +1698,7 @@ static int pinctrl_check_ops(struct pinctrl_dev *pctldev)
if (!ops ||
!ops->get_groups_count ||
- !ops->get_group_name ||
- !ops->get_group_pins)
+ !ops->get_group_name)
return -EINVAL;
if (ops->dt_node_to_map && !ops->dt_free_map)
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 9248ce4efed4..051e8592990e 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -391,14 +391,16 @@ int pinmux_enable_setting(struct pinctrl_setting const
*setting)
struct pinctrl_dev *pctldev = setting->pctldev;
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
const struct pinmux_ops *ops = pctldev->desc->pmxops;
- int ret;
- const unsigned *pins;
- unsigned num_pins;
+ int ret = 0;
+ const unsigned *pins = NULL;
+ unsigned num_pins = 0;
int i;
struct pin_desc *desc;
- ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
- , _pins);
+ if (pctlops->get_group_pins)
+ ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
+ , _pins);
+
if (ret) {
const char *gname;
@@ -470,14 +472,15 @@ void pinmux_disable_setting(struct pinctrl_setting const
*setting)
struct pinctrl_dev *pctldev = setting->pctldev;
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
const struct pinmux_ops *ops = pctldev->desc->pmxops;
- int ret;
- const unsigned *pins;
- unsigned num_pins;
+ int ret = 0;
+ const unsigned *pins = NULL;
+ unsigned num_pins = 0;
int i;
struct pin_desc *desc;
- ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
- , _pins);
+ if (pctlops->get_group_pins)
+ ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
+ , _pins);
if (ret) {
const char *gname;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] cgroup: implement cgroup.subtree_populated for the default hierarchy
Hey, Serge. On Thu, Apr 10, 2014 at 05:08:55AM +0200, Serge E. Hallyn wrote: > Quoting Tejun Heo (t...@kernel.org): > > * It delivers events by forking and execing a userland binary > > specified as the release_agent. This is a long deprecated method of > > notification delivery. It's extremely heavy, slow and cumbersome to > > integrate with larger infrastructure. > > (Not seriously worried about this, but it's a point worth considering) > It does have one advantage though: if the userspace agent goes bad, > cgroups can still be removed on empty. > > Do you plan on keeping release-on-empty around? I assume only for a > while? The new mechanism is only for the unified hierarchy. The old one will be kept around for other hierarchies. > Do you think there is any value in having a simpler "remove-when-empty" > file? Doesn't call out to userspace, just drops the cgroup when there > are no more tasks or sub-cgroups? I don't think so. Implementing such simplistic mechanism in userland is trivial and even independent failover mechanisms can be easily implemented from userland as multiple entities can set up watches. I don't think there's much value in providing another mechanism from kernel side. The only reason why release_agent thing got as complex as it is is because the mechanism is fundamentally flawed - clumsy delivery, no multiple watches, single watch point - so people tried to work around it by adding event filtering from kernel side, which is quite backwards IMHO. With proper event mechanism, everything should be easily achievable from userland side. > > * Events are filtered from the kernel side. "notify_on_release" file > > is used to subscribe to or suppres release event and events are not > > generated if a cgroup becomes empty by moving the last task out of > > it; however, event is generated if it becomes empty because the last > > child cgroup is removed. This is inconsistent, awkward and > > Hm, maybe I'm misreading but this doesn't seem right. If I move > a task into x1 and kill the task, x1 goes away. Likewise if I > create x1/y1, and rmdir y1, x1 goes away. I suspect I'm misunderstanding > the case in which you say it doesn't happen? The case where you move a task out of x1/y1 to another cgroup doesn't generate an event. One could say that that's unnecessary because the mover knows that the cgroup is becoming empty; however, it excludes any cases where there are more than one actors and the same can be said for cases when the actor is removing a child. > > This patch implements interface file "cgroup.subtree_populated" which > > can be used to monitor whether the cgroup's subhierarchy has tasks in > > it or not. Its value is 1 if there is no task in the cgroup and its > > I think you meant this backward? It's 1 if there is *any task in > the cgroup and its descendants, else 0? Oops, yeap. Will update. Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 2/5] pinctrl: berlin: add a pinctrl driver for Marvell Berlin SoCs
The Marvell Berlin boards have a group based pinmuxing mechanism. This
driver adds the support for the BG2CD, BG2 and BG2Q. We actually do not
need any information about the pins here and only have the definition
of the groups.
Let's take the example of the uart0 pinmuxing on the BG2Q. Balls BK4 and
BH6 are muxed to respectively UART0 RX and TX if the group GSM12 is set
to mode 0:
Group Modes Offset Base Offset LSB Bit Width
GSM12 3 sm_base 0x400x100x2
BallGroup Mode 0 Mode 1 Mode 2
BK4 GSM12 UART0_RXIrDA0_RXGPIO9
BH6 GSM12 UART0_TXIrDA0_TXGPIO10
So in order to configure BK4 -> UART0_TX and BH6 -> UART0_RX, we need
to set (sm_base + 0x40 + 0x10) &= ff3f.
Signed-off-by: Antoine Ténart
---
drivers/pinctrl/Kconfig | 4 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-berlin.c | 498 +++
drivers/pinctrl/pinctrl-berlin.h | 72 ++
4 files changed, 575 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-berlin.c
create mode 100644 drivers/pinctrl/pinctrl-berlin.h
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index e49324032611..2d9339a7bd05 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -104,6 +104,10 @@ config PINCTRL_BCM2835
select PINMUX
select PINCONF
+config PINCTRL_BERLIN
+ bool
+ select PINMUX
+
config PINCTRL_CAPRI
bool "Broadcom Capri pinctrl driver"
depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 4b835880cf80..fd5a01d4475f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PINCTRL_BF60x) += pinctrl-adi2-bf60x.o
obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
obj-$(CONFIG_PINCTRL_BAYTRAIL) += pinctrl-baytrail.o
+obj-$(CONFIG_PINCTRL_BERLIN) += pinctrl-berlin.o
obj-$(CONFIG_PINCTRL_CAPRI)+= pinctrl-capri.o
obj-$(CONFIG_PINCTRL_IMX) += pinctrl-imx.o
obj-$(CONFIG_PINCTRL_IMX1_CORE)+= pinctrl-imx1-core.o
diff --git a/drivers/pinctrl/pinctrl-berlin.c b/drivers/pinctrl/pinctrl-berlin.c
new file mode 100644
index ..a377d6fbb127
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-berlin.c
@@ -0,0 +1,498 @@
+/*
+ * Marvell Berlin SoC pinctrl driver.
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "pinctrl-utils.h"
+#include "pinctrl-berlin.h"
+
+#define NFCTS(bit_width) (1 << ((bit_width) + 1))
+
+static const struct berlin_desc_group berlin2cd_pinctrl_groups[] = {
+ /* GSM */
+ BERLIN_PINCTRL_GROUP("GSM0", "apb_base",0x40, 0x2, 0x00),
+ BERLIN_PINCTRL_GROUP("GSM1", "apb_base",0x40, 0x2, 0x02),
+ BERLIN_PINCTRL_GROUP("GSM2", "apb_base",0x40, 0x2, 0x04),
+ BERLIN_PINCTRL_GROUP("GSM3", "apb_base",0x40, 0x2, 0x06),
+ BERLIN_PINCTRL_GROUP("GSM4", "apb_base",0x40, 0x2, 0x08),
+ BERLIN_PINCTRL_GROUP("GSM5", "apb_base",0x40, 0x2, 0x0a),
+ BERLIN_PINCTRL_GROUP("GSM6", "apb_base",0x40, 0x2, 0x0c),
+ BERLIN_PINCTRL_GROUP("GSM7", "apb_base",0x40, 0x1, 0x0e),
+ BERLIN_PINCTRL_GROUP("GSM8", "apb_base",0x40, 0x1, 0x0f),
+ BERLIN_PINCTRL_GROUP("GSM9", "apb_base",0x40, 0x1, 0x10),
+ BERLIN_PINCTRL_GROUP("GSM10", "apb_base",0x40, 0x1, 0x11),
+ BERLIN_PINCTRL_GROUP("GSM11", "apb_base",0x40, 0x1, 0x12),
+ /* G */
+ BERLIN_PINCTRL_GROUP("G0","global_base", 0x00, 0x1, 0x00),
+ BERLIN_PINCTRL_GROUP("G1","global_base", 0x00, 0x2, 0x01),
+ BERLIN_PINCTRL_GROUP("G2","global_base", 0x00, 0x2, 0x02),
+ BERLIN_PINCTRL_GROUP("G3","global_base", 0x00, 0x2, 0x04),
+ BERLIN_PINCTRL_GROUP("G4","global_base", 0x00, 0x2, 0x06),
+ BERLIN_PINCTRL_GROUP("G5","global_base", 0x00, 0x3, 0x08),
+ BERLIN_PINCTRL_GROUP("G6","global_base", 0x00, 0x2, 0x0b),
+ BERLIN_PINCTRL_GROUP("G7","global_base", 0x00, 0x3, 0x0d),
+ BERLIN_PINCTRL_GROUP("G8","global_base", 0x00, 0x3, 0x10),
+ BERLIN_PINCTRL_GROUP("G9","global_base", 0x00, 0x3, 0x13),
+ BERLIN_PINCTRL_GROUP("G10", "global_base", 0x00, 0x2, 0x16),
+ BERLIN_PINCTRL_GROUP("G11", "global_base", 0x00, 0x2, 0x18),
+ BERLIN_PINCTRL_GROUP("G12", "global_base", 0x00, 0x3, 0x1a),
+ BERLIN_PINCTRL_GROUP("G13", "global_base", 0x04, 0x3, 0x00),
+ BERLIN_PINCTRL_GROUP("G14", "global_base", 0x04, 0x1, 0x03),
+
[PATCH RESEND 3/5] ARM: berlin: add the pinctrl dependency for the Marvell Berlin SoCs
Signed-off-by: Antoine Ténart --- arch/arm/mach-berlin/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig index d3c5f14dc142..291f1cac6c3d 100644 --- a/arch/arm/mach-berlin/Kconfig +++ b/arch/arm/mach-berlin/Kconfig @@ -4,6 +4,8 @@ config ARCH_BERLIN select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF + select PINCTRL + select PINCTRL_BERLIN if ARCH_BERLIN -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/2] tracing: syscall_*regfunc() can race with copy_process()
On Wed, 9 Apr 2014 19:05:42 +0200
Oleg Nesterov wrote:
> syscall_regfunc() and syscall_unregfunc() should set/clear
> TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
> with copy_process() and miss the new child which was not added to
> init_task.tasks list yet.
>
> Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
> under tasklist.
>
> While at it,
>
> - remove _irqsafe from syscall_regfunc/syscall_unregfunc,
> read_lock(tasklist) doesn't need to disable irqs.
>
> - change syscall_unregfunc() to check PF_KTHREAD to skip
> the kernel threads, ->mm != NULL is the common mistake.
>
> Note: probably this check should be simply removed, needs
> another patch.
>
> Signed-off-by: Oleg Nesterov
> ---
> include/trace/syscall.h | 15 +++
> kernel/fork.c |2 ++
> kernel/tracepoint.c | 12 +---
> 3 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/include/trace/syscall.h b/include/trace/syscall.h
> index 84bc419..15a954b 100644
> --- a/include/trace/syscall.h
> +++ b/include/trace/syscall.h
> @@ -4,6 +4,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -31,4 +32,18 @@ struct syscall_metadata {
> struct ftrace_event_call *exit_event;
> };
>
> +#ifdef CONFIG_TRACEPOINTS
> +static inline void syscall_tracepoint_update(struct task_struct *p)
> +{
> + if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
> + set_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
> + else
> + clear_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
> +}
> +#else
> +static inline void syscall_tracepoint_update(struct task_struct *p)
> +{
> +}
> +#endif
> +
> #endif /* _TRACE_SYSCALL_H */
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 1766d32..e463f99 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1472,7 +1472,9 @@ static struct task_struct *copy_process(unsigned long
> clone_flags,
>
> total_forks++;
> spin_unlock(>sighand->siglock);
> + syscall_tracepoint_update(p);
> write_unlock_irq(_lock);
> +
So this looks to be a fix that probably should go to stable?
> proc_fork_connector(p);
> cgroup_post_fork(p);
> if (clone_flags & CLONE_THREAD)
> diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> index 0c05a45..a16754b 100644
> --- a/kernel/tracepoint.c
> +++ b/kernel/tracepoint.c
> @@ -732,33 +732,31 @@ static int sys_tracepoint_refcount;
>
> void syscall_regfunc(void)
> {
> - unsigned long flags;
> struct task_struct *g, *t;
>
> if (!sys_tracepoint_refcount) {
> - read_lock_irqsave(_lock, flags);
> + read_lock(_lock);
> do_each_thread(g, t) {
> /* Skip kernel threads. */
> - if (t->mm)
> + if (!(t->flags & PF_KTHREAD))
> set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
> } while_each_thread(g, t);
> - read_unlock_irqrestore(_lock, flags);
> + read_unlock(_lock);
> }
> sys_tracepoint_refcount++;
> }
>
> void syscall_unregfunc(void)
> {
> - unsigned long flags;
> struct task_struct *g, *t;
>
> sys_tracepoint_refcount--;
> if (!sys_tracepoint_refcount) {
> - read_lock_irqsave(_lock, flags);
> + read_lock(_lock);
> do_each_thread(g, t) {
> clear_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
> } while_each_thread(g, t);
> - read_unlock_irqrestore(_lock, flags);
> + read_unlock(_lock);
These changes should be in a separate patch, as they can wait till 3.16.
-- Steve
> }
> }
> #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] tracing: syscall_*regfunc() can race with copy_process()
On Wed, 9 Apr 2014 19:05:42 +0200 Oleg Nesterov wrote: > syscall_regfunc() and syscall_unregfunc() should set/clear > TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race > with copy_process() and miss the new child which was not added to > init_task.tasks list yet. > > Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT > under tasklist. > > While at it, > > - remove _irqsafe from syscall_regfunc/syscall_unregfunc, > read_lock(tasklist) doesn't need to disable irqs. > > - change syscall_unregfunc() to check PF_KTHREAD to skip > the kernel threads, ->mm != NULL is the common mistake. > > Note: probably this check should be simply removed, needs > another patch. > > Signed-off-by: Oleg Nesterov BTW, how important is this fix? Something we should aim for the current merge window? stable? Or can it wait till 3.16? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/27] irqchip: Declare cortex-a7's irqchip to initialize gic from dt
On Thu, Apr 10, 2014 at 11:04:59AM +0100, Marc Zyngier wrote: > On Thu, Apr 10 2014 at 10:28:24 am BST, Chanwoo Choi > wrote: > > This patch declare coretex-a7's irqchip to initialze gic from dt > > with "arm,cortex-a7-gic" data. > > > > Cc: Thomas Gleixner > > Signed-off-by: Chanwoo Choi > > Signed-off-by: Kyungmin Park > > --- > > drivers/irqchip/irq-gic.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > > index 4300b66..8e906e4 100644 > > --- a/drivers/irqchip/irq-gic.c > > +++ b/drivers/irqchip/irq-gic.c > > @@ -1069,6 +1069,7 @@ gic_of_init(struct device_node *node, struct > > device_node *parent) > > } > > IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init); > > IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init); > > +IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init); > > IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init); > > IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init); > > Frankly, this patch adds no value. Are we going to add > "arm,cortex-a12-gic", "arm,cortex-a17-gic", "arm,cortex-a53-gic", > "arm,cortex-a57-gic"? And that's just to mention the ARM Ltd cores... > > Instead, how about defining a generic "arm,gic" property, and mandate > that new DT files are using that? We can always use a more precise > compatible for quirks. Nit: s/property/compatible/ As mentioned elsewhere, "arm,gic-v2" would seem to fit the bill (and we can have "arm,gic" or "arm,gic-v1" for v1). > Mark, what do you think? I think this has been discussed in the past > already. It's been repeatedly brought up and agreed on, it's just that no-one's implemented it. I agree that having an "arm,gic-v2" binding that people can place in their compatible list is a sensible thing to do, and I'd be happy to Ack patches implementing it. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Was: Convert process iteration to use for_each_process_thread()
On Wed, 9 Apr 2014 19:05:05 +0200 Oleg Nesterov wrote: > On 04/09, Steven Rostedt wrote: > > > > The tasklist_lock is all that is needed. > > Yes, but not _irq. Plus this code is buggy ;) > > Steven, I sent these patches twice (at least!). This time I didn't > bother to recheck this code, but the patches still apply so perhaps > you can take a look? > > Last attempt, I promise ;) Ah OK, and I actually have time to look at them now :-) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 1/2] tracepoint: Fix sparse warnings in tracepoint.c
From: Mathieu Desnoyers
Fix the following sparse warnings:
CHECK kernel/tracepoint.c
kernel/tracepoint.c:184:18: warning: incorrect type in assignment (different
address spaces)
kernel/tracepoint.c:184:18:expected struct tracepoint_func *tp_funcs
kernel/tracepoint.c:184:18:got struct tracepoint_func [noderef]
*funcs
kernel/tracepoint.c:216:18: warning: incorrect type in assignment (different
address spaces)
kernel/tracepoint.c:216:18:expected struct tracepoint_func *tp_funcs
kernel/tracepoint.c:216:18:got struct tracepoint_func [noderef]
*funcs
kernel/tracepoint.c:392:24: error: return expression in void function
CC kernel/tracepoint.o
kernel/tracepoint.c: In function tracepoint_module_going:
kernel/tracepoint.c:491:6: warning: symbol 'syscall_regfunc' was not declared.
Should it be static?
kernel/tracepoint.c:508:6: warning: symbol 'syscall_unregfunc' was not
declared. Should it be static?
Link:
http://lkml.kernel.org/r/1397049883-28692-1-git-send-email-mathieu.desnoy...@efficios.com
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Steven Rostedt
---
include/linux/tracepoint.h | 5 +
include/trace/events/syscalls.h | 3 ---
kernel/tracepoint.c | 6 --
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 69a298b..9d30ee4 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -80,6 +80,11 @@ static inline void tracepoint_synchronize_unregister(void)
synchronize_sched();
}
+#ifdef CONFIG_HAVE_SYSCALL_TRACEPOINTS
+extern void syscall_regfunc(void);
+extern void syscall_unregfunc(void);
+#endif /* CONFIG_HAVE_SYSCALL_TRACEPOINTS */
+
#define PARAMS(args...) args
#endif /* _LINUX_TRACEPOINT_H */
diff --git a/include/trace/events/syscalls.h b/include/trace/events/syscalls.h
index 5a4c04a..14e49c7 100644
--- a/include/trace/events/syscalls.h
+++ b/include/trace/events/syscalls.h
@@ -13,9 +13,6 @@
#ifdef CONFIG_HAVE_SYSCALL_TRACEPOINTS
-extern void syscall_regfunc(void);
-extern void syscall_unregfunc(void);
-
TRACE_EVENT_FN(sys_enter,
TP_PROTO(struct pt_regs *regs, long id),
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 162be19..ca2cfe2 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -181,7 +181,8 @@ static int tracepoint_add_func(struct tracepoint *tp,
if (tp->regfunc && !static_key_enabled(>key))
tp->regfunc();
- tp_funcs = tp->funcs;
+ tp_funcs = rcu_dereference_protected(tp->funcs,
+ lockdep_is_held(_mutex));
old = func_add(_funcs, func);
if (IS_ERR(old)) {
WARN_ON_ONCE(1);
@@ -213,7 +214,8 @@ static int tracepoint_remove_func(struct tracepoint *tp,
{
struct tracepoint_func *old, *tp_funcs;
- tp_funcs = tp->funcs;
+ tp_funcs = rcu_dereference_protected(tp->funcs,
+ lockdep_is_held(_mutex));
old = func_remove(_funcs, func);
if (IS_ERR(old)) {
WARN_ON_ONCE(1);
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 0/2] tracing: Fix for sparse warnings and anonymous unions
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: abb43f6998eb6466ea392d3757e673bbdb6ae171 Mathieu Desnoyers (2): tracepoint: Fix sparse warnings in tracepoint.c tracing: Fix anonymous unions in struct ftrace_event_call include/linux/syscalls.h| 8 ++-- include/linux/tracepoint.h | 5 + include/trace/events/syscalls.h | 3 --- include/trace/ftrace.h | 12 +--- kernel/trace/trace_export.c | 6 -- kernel/tracepoint.c | 6 -- 6 files changed, 28 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 2/2] tracing: Fix anonymous unions in struct ftrace_event_call
From: Mathieu Desnoyers
gcc <= 4.5.x has significant limitations with respect to initialization
of anonymous unions within structures. They need to be surrounded by
brackets, _and_ they need to be initialized in the same order in which
they appear in the structure declaration.
Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
Link:
http://lkml.kernel.org/r/1397077568-3156-1-git-send-email-mathieu.desnoy...@efficios.com
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Steven Rostedt
---
include/linux/syscalls.h| 8 ++--
include/trace/ftrace.h | 12 +---
kernel/trace/trace_export.c | 6 --
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 1e67b7a..af94c98 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -119,8 +119,10 @@ extern struct trace_event_functions
exit_syscall_print_funcs;
static struct syscall_metadata __syscall_meta_##sname; \
static struct ftrace_event_call __used \
event_enter_##sname = { \
- .name = "sys_enter"#sname,\
.class = _class_syscall_enter, \
+ { \
+ .name = "sys_enter"#sname,\
+ }, \
.event.funcs= _syscall_print_funcs, \
.data = (void *)&__syscall_meta_##sname,\
.flags = TRACE_EVENT_FL_CAP_ANY, \
@@ -133,8 +135,10 @@ extern struct trace_event_functions
exit_syscall_print_funcs;
static struct syscall_metadata __syscall_meta_##sname; \
static struct ftrace_event_call __used \
event_exit_##sname = {\
- .name = "sys_exit"#sname, \
.class = _class_syscall_exit,\
+ { \
+ .name = "sys_exit"#sname, \
+ }, \
.event.funcs= _syscall_print_funcs,\
.data = (void *)&__syscall_meta_##sname,\
.flags = TRACE_EVENT_FL_CAP_ANY, \
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 9c44c11..0a1a4f7 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -470,8 +470,10 @@ static inline notrace int ftrace_get_offsets_##call(
\
* };
*
* static struct ftrace_event_call event_ = {
- * .tp = &__tracepoint_,
* .class = event_class_,
+ * {
+ * .tp = &__tracepoint_,
+ * },
* .event = _event_type_,
* .print_fmt = print_fmt_,
* .flags = TRACE_EVENT_FL_TRACEPOINT,
@@ -606,8 +608,10 @@ static struct ftrace_event_class __used __refdata
event_class_##call = { \
#define DEFINE_EVENT(template, call, proto, args) \
\
static struct ftrace_event_call __used event_##call = {
\
- .tp = &__tracepoint_##call, \
.class = _class_##template, \
+ { \
+ .tp = &__tracepoint_##call, \
+ }, \
.event.funcs= _event_type_funcs_##template, \
.print_fmt = print_fmt_##template, \
.flags = TRACE_EVENT_FL_TRACEPOINT,\
@@ -621,8 +625,10 @@ __attribute__((section("_ftrace_events"))) *__event_##call
= _##call
static const char print_fmt_##call[] = print; \
\
static struct ftrace_event_call __used event_##call = {
\
- .tp = &__tracepoint_##call, \
.class = _class_##template, \
+ { \
+ .tp = &__tracepoint_##call, \
+ }, \
.event.funcs= _event_type_funcs_##call, \
.print_fmt = print_fmt_##call, \
[PATCH for 3.14.y] x86/efi: Make efi virtual runtime map passing more robust
Hi Greg,
please take the patch into the stable 3.14.y queue. It fixes a number
of EFI machines which makes a stable backport a good thing. Before you
apply it though, cherry-pick 42a5477251f on which this patch depends.
Then, you apply the backport I'm adding below.
Thanks.
--
From: Borislav Petkov
Date: Sat, 18 Jan 2014 12:48:17 +0100
Subject: [PATCH] x86/efi: Make efi virtual runtime map passing more robust
Upstream commit: b7b898ae0c0a82489511a1ce1b35f26215e6beb5
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of resizing
the memmap we're doing did allocate from such physical addresses which
were not mapped anymore and boom:
http://lkml.kernel.org/r/1386806463.1791.295.ca...@misato.fc.hp.com
One way to take care of that issue is to reimplement the krealloc thing
but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
and when we deplete that memory (shouldn't happen all that often but you
know firmware) we realloc the next power-of-two pages.
Having the pages, it is much more handy and easy to map them into the
EFI page table with the already existing mapping code which we're using
for building the virtual mappings.
Thanks to Toshi Kani and Matt for the great debugging help.
Reported-by: Toshi Kani
Signed-off-by: Borislav Petkov
Tested-by: Toshi Kani
Signed-off-by: Matt Fleming
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/efi.h | 3 +-
arch/x86/platform/efi/efi.c| 99 +-
arch/x86/platform/efi/efi_32.c | 7 ++-
arch/x86/platform/efi/efi_64.c | 32 --
4 files changed, 115 insertions(+), 26 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index acd86c850414..f949715e3957 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -130,7 +130,8 @@ extern void efi_memory_uc(u64 addr, unsigned long size);
extern void __init efi_map_region(efi_memory_desc_t *md);
extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
extern void efi_sync_low_kernel_mappings(void);
-extern void efi_setup_page_tables(void);
+extern int efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages);
+extern void efi_cleanup_page_tables(unsigned long pa_memmap, unsigned
num_pages);
extern void __init old_map_region(efi_memory_desc_t *md);
extern void __init runtime_code_page_mkexec(void);
extern void __init efi_runtime_mkexec(void);
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index b97acecf3fd9..abb81b0ad83f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -939,14 +939,36 @@ static void __init efi_map_regions_fixed(void)
}
+static void *realloc_pages(void *old_memmap, int old_shift)
+{
+ void *ret;
+
+ ret = (void *)__get_free_pages(GFP_KERNEL, old_shift + 1);
+ if (!ret)
+ goto out;
+
+ /*
+* A first-time allocation doesn't have anything to copy.
+*/
+ if (!old_memmap)
+ return ret;
+
+ memcpy(ret, old_memmap, PAGE_SIZE << old_shift);
+
+out:
+ free_pages((unsigned long)old_memmap, old_shift);
+ return ret;
+}
+
/*
- * Map efi memory ranges for runtime serivce and update new_memmap with virtual
- * addresses.
+ * Map the efi memory ranges of the runtime services and update new_mmap with
+ * virtual addresses.
*/
-static void * __init efi_map_regions(int *count)
+static void * __init efi_map_regions(int *count, int *pg_shift)
{
+ void *p, *new_memmap = NULL;
+ unsigned long left = 0;
efi_memory_desc_t *md;
- void *p, *tmp, *new_memmap = NULL;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -961,20 +983,23 @@ static void * __init efi_map_regions(int *count)
efi_map_region(md);
get_systab_virt_addr(md);
- tmp = krealloc(new_memmap, (*count + 1) * memmap.desc_size,
- GFP_KERNEL);
- if (!tmp)
- goto out;
- new_memmap = tmp;
+ if (left < memmap.desc_size) {
+ new_memmap = realloc_pages(new_memmap, *pg_shift);
+ if (!new_memmap)
+ return NULL;
+
+ left += PAGE_SIZE << *pg_shift;
+ (*pg_shift)++;
+ }
+
memcpy(new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
+
+ left -= memmap.desc_size;
(*count)++;
}
return new_memmap;
-out:
- kfree(new_memmap);
- return NULL;
}
/*
@@ -1000,9 +1025,9 @@ out:
*/
void __init
Re: [PATCH] scripts/tags.sh: add regular expression replacement pattern for memcg
Sorry, the comment in previous patch is somewhat misguiding, this patch
replaces that one.
Currently, no regular expression replacement patterns for PageCgroup*
flag-ops are defined, which causes quite a few pain while reading code.
Just get rid of it.
Also, add a comment to inform people to add pattern for whatever new
flag-ops they add.
Signed-off-by: Jianyu Zhan
---
include/linux/page_cgroup.h | 6 ++
scripts/tags.sh | 8
2 files changed, 14 insertions(+)
diff --git a/include/linux/page_cgroup.h b/include/linux/page_cgroup.h
index 777a524..9c60b77 100644
--- a/include/linux/page_cgroup.h
+++ b/include/linux/page_cgroup.h
@@ -44,6 +44,12 @@ static inline void __init page_cgroup_init(void)
struct page_cgroup *lookup_page_cgroup(struct page *page);
struct page *lookup_cgroup_page(struct page_cgroup *pc);
+/*
+ * Note, whenever you add a *PCGFLAG operation here, please add a
+ * regular expression replacement pattern in scripts/tags.sh
+ * to inform our friendly and smart tags generator.
+ */
+
#define TESTPCGFLAG(uname, lname) \
static inline int PageCgroup##uname(struct page_cgroup *pc)\
{ return test_bit(PCG_##lname, >flags); }
diff --git a/scripts/tags.sh b/scripts/tags.sh
index 58c4559..c0d52d1 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -171,12 +171,16 @@ exuberant()
--regex-c++='/PAGEFLAG\(([^,)]*).*/ClearPage\1/'\
--regex-c++='/TESTSETFLAG\(([^,)]*).*/TestSetPage\1/' \
--regex-c++='/TESTPAGEFLAG\(([^,)]*).*/Page\1/' \
+ --regex-c++='/TESTPCGFLAG\(([^,)]*).*/PageCgroup\1/'\
--regex-c++='/SETPAGEFLAG\(([^,)]*).*/SetPage\1/' \
--regex-c++='/__SETPAGEFLAG\(([^,)]*).*/__SetPage\1/' \
+ --regex-c++='/SETPCGFLAG\(([^,)]*).*/SetPageCgroup\1/' \
--regex-c++='/TESTCLEARFLAG\(([^,)]*).*/TestClearPage\1/' \
--regex-c++='/__TESTCLEARFLAG\(([^,)]*).*/TestClearPage\1/' \
+ --regex-c++='/TESTCLEARPCGFLAG\(([^,)]*).*/TestClearPageCgroup\1/' \
--regex-c++='/CLEARPAGEFLAG\(([^,)]*).*/ClearPage\1/' \
--regex-c++='/__CLEARPAGEFLAG\(([^,)]*).*/__ClearPage\1/' \
+ --regex-c++='/CLEARPCGFLAG\(([^,)]*).*/ClearPageCgroup\1/' \
--regex-c++='/__PAGEFLAG\(([^,)]*).*/__SetPage\1/' \
--regex-c++='/__PAGEFLAG\(([^,)]*).*/__ClearPage\1/'\
--regex-c++='/PAGEFLAG_FALSE\(([^,)]*).*/Page\1/' \
@@ -229,12 +233,16 @@ emacs()
--regex='/PAGEFLAG(\([^,)]*\).*/ClearPage\1/' \
--regex='/TESTSETFLAG(\([^,)]*\).*/TestSetPage\1/' \
--regex='/TESTPAGEFLAG(\([^,)]*\).*/Page\1/'\
+ --regex='/TESTPCGFLAG\(([^,)]*).*/PageCgroup\1/'\
--regex='/SETPAGEFLAG(\([^,)]*\).*/SetPage\1/' \
--regex='/__SETPAGEFLAG(\([^,)]*\).*/__SetPage\1/' \
+ --regex='/SETPCGFLAG\(([^,)]*).*/SetPageCgroup\1/' \
--regex='/TESTCLEARFLAG(\([^,)]*\).*/TestClearPage\1/' \
--regex='/__TESTCLEARFLAG(\([^,)]*\).*/TestClearPage\1/'\
+ --regex='/TESTCLEARPCGFLAG\(([^,)]*).*/TestClearPageCgroup\1/' \
--regex='/CLEARPAGEFLAG(\([^,)]*\).*/ClearPage\1/' \
--regex='/__CLEARPAGEFLAG(\([^,)]*\).*/__ClearPage\1/' \
+ --regex='/CLEARPCGFLAG\(([^,)]*).*/ClearPageCgroup\1/' \
--regex='/__PAGEFLAG(\([^,)]*\).*/__SetPage\1/' \
--regex='/__PAGEFLAG(\([^,)]*\).*/__ClearPage\1/' \
--regex='/PAGEFLAG_FALSE(\([^,)]*\).*/Page\1/' \
--
1.9.0.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/10] arm64: efi: add EFI stub
On Wed, 2014-04-09 at 15:20 +0100, Mark Rutland wrote: > > > > +config EFI > > + bool "UEFI firmware support" > > + depends on OF > > I note we're not depending on !CPU_BIG_ENDIAN here, and it looks like > the implementation is not endian-clean (I've pointed out a few issues > below). > > We need to fix that up for CPU_BIG_ENDIAN. For the moment we could > depend on !CPU_BIG_ENDIAN which would at least to make it clear we don't > support EFI && CPU_BIG_ENDIAN yet. The commit message should be updated > to mention that. > Yes, the !CPU_BIG_ENDIAN was there at one point but got lost along the way. It may be best to put it back for now, but I'll take a stab at getting the stub part sorted out based on your comments. Full runtime services will be trickier and need a followup patch in the future after the initial patch series goes in. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 4/6] uprobes/x86: Emulate rip-relative call's
On 04/09/2014 09:44 PM, Oleg Nesterov wrote:
> +static void ttt_clear_displacement(struct arch_uprobe *auprobe, struct insn
> *insn)
Branch instruction's offset isn't called "displacement"
on x86.
How about ttt_clear_branch_offset?
> +{
> + /*
> + * Turn this insn into "call 1f; 1:", this is what we will execute
> + * out-of-line if ->emulate() fails.
> + *
> + * In the likely case this will lead to arch_uprobe_abort_xol(), but
> + * see the comment in ->emulate(). So we need to ensure that the new
> + * ->ip can't fall into non-canonical area and trigger #GP.
> + *
> + * We could turn it into (say) "pushf", but then we would need to
> + * divorce ->insn[] and ->ixol[]. We need to preserve the 1st byte
> + * of ->insn[] for set_orig_insn().
> + */
> + memset(auprobe->insn + insn_offset_immediate(insn),
> + 0, insn->immediate.nbytes);
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Oops in acpi_gpiochip_add on MacBookPro with Linux v3.14-12042-g69cd9eba3886
On Thu, Apr 10, 2014 at 8:40 AM, Mika Westerberg wrote: > On Thu, Apr 10, 2014 at 08:22:12AM -0400, Josh Boyer wrote: >> On Thu, Apr 10, 2014 at 2:50 AM, Rafał Miłecki wrote: >> > 2014-04-09 23:09 GMT+02:00 Josh Boyer : >> >> With Linux v3.14-12042-g69cd9eba3886 I get an oops from the bcma >> >> module on the MacBookPro 10,2 I have here. This works fine with Linux >> >> v3.14-7333-g59ecc26004e7. There have been no changes between those >> >> two versions to bcma itself, but the GPIO merge did go in that window. >> >> I can attempt to do a bisect tomorrow, but looking over some of the >> >> GPIO commits it seems pretty relevant to the ACPI GPIO changes. I'm >> >> hoping someone here has an idea on what the issue might be and has >> >> some possible things for me to test for fixes. >> > >> > Bug report: https://lkml.org/lkml/2014/3/24/262 >> > Patch: https://lkml.org/lkml/2014/3/24/293 >> > Tested by Sabrina: https://lkml.org/lkml/2014/3/24/304 >> > (all links are for the same thread). >> > >> > Now you simply have to find above patch in some git tree :) Not sure >> > if it's already in Linus's one. >> >> Ah, wonderful. I now wish I would have found those in my searching >> before doing the bisect. Oh well. For what it's worth, my bisect >> landed on the same commit. >> >> The fix isn't in Linus' tree or linux-next. I'm guessing Mika is >> either still on vacation, or hasn't sent out the formal fix yet. > > No, not on vacation anymore (unfortunately). I did send the formal patch > already: > > https://lkml.org/lkml/2014/3/31/135 > > but it isn't merged to Linus' GPIO tree yet. Ah, ok great. I'll test that today. Thanks. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/5] ARM: sunxi: update the default ARCH_NR_GPIO for sunxi arch
On Thu, Apr 10, 2014 at 02:25:47PM +0200, Boris BREZILLON wrote: > The A31 SoC has PL and PM banks, we thus need to increase the default > ARCH_NR_GPIO when building for the sunxi architecture. > > Signed-off-by: Boris BREZILLON Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH] spi: core: Increase timeout value
The existing timeout value in wait_for_completion_timeout is
calculated from the transfer length and speed with tolerance of 10msec.
This is too low because this is used for error conditions such as
hardware hang etc.
The xfer->speed_hz considered may not be the actual speed set
because the best clock divisor is chosen from a limited set such that
the actual speed <= requested speed. This will lead to timeout being
less than actual transfer time.
Considering acceptable latencies, this timeout can be set to a large
value >= 1*HZ typically.
This patch adds a tolerance of 2000 msec in the core accordingly.
Signed-off-by: Harini Katakam
---
drivers/spi/spi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 4eb9bf0..3fdecfa 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -775,7 +775,7 @@ static int spi_transfer_one_message(struct spi_master
*master,
if (ret > 0) {
ret = 0;
ms = xfer->len * 8 * 1000 / xfer->speed_hz;
- ms += 10; /* some tolerance */
+ ms += 2000; /* some tolerance */
ms =
wait_for_completion_timeout(>xfer_completion,
msecs_to_jiffies(ms));
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] pinctrl: sunxi: add reset control support
On Thu, Apr 10, 2014 at 02:25:46PM +0200, Boris BREZILLON wrote:
> The A31 SoC define a reset line for the R_PIO block which needs to be
> deasserted for the pin controller to be usable.
>
> Try to retrieve a reset line and deassert if one was found.
>
> Signed-off-by: Boris BREZILLON
> ---
> drivers/pinctrl/pinctrl-sunxi.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
> index ee62027..b752495 100644
> --- a/drivers/pinctrl/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/pinctrl-sunxi.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "core.h"
> @@ -792,6 +793,7 @@ static int sunxi_pinctrl_probe(struct platform_device
> *pdev)
> const struct of_device_id *device;
> struct pinctrl_pin_desc *pins;
> struct sunxi_pinctrl *pctl;
> + struct reset_control *rstc;
> int i, ret, last_pin;
> struct clk *clk;
>
> @@ -885,6 +887,13 @@ static int sunxi_pinctrl_probe(struct platform_device
> *pdev)
>
> clk_prepare_enable(clk);
>
> + rstc = devm_reset_control_get(>dev, NULL);
You should use devm_reset_control_get_optional here.
> + if (!IS_ERR(rstc)) {
> + ret = reset_control_deassert(rstc);
> + if (ret)
> + goto gpiochip_error;
> + }
> +
It would be good to put back the device in reset if probe fails later
on.
Thanks
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [RFC PATCH v2 6/6] uprobes/x86: Emulate rip-relative conditional "near" jmp's
On 04/09/2014 09:44 PM, Oleg Nesterov wrote: > + case 0x0f: > + if (insn->opcode.nbytes != 2) > + return -ENOSYS; > + /* > + * If it is a "near" conditional jmp, OPCODE2() - 0x10 matches > + * OPCODE1() of the "short" jmp which checks the same condition. > + */ I propose: /* * Near conditional jump opcodes: 0f 80..8f * Short conditional jump opcodes: 70..7f * Convert OPCODE2() to corresponding short jump opcode: */ > + opc1 = OPCODE2(insn) - 0x10; > default: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] pinctrl: berlin: add a pinctrl driver for Marvell Berlin SoCs
The Marvell Berlin boards have a group based pinmuxing mechanism. This
driver adds the support for the BG2CD, BG2 and BG2Q. We actually do not
need any information about the pins here and only have the definition
of the groups.
Let's take the example of the uart0 pinmuxing on the BG2Q. Balls BK4 and
BH6 are muxed to respectively UART0 RX and TX if the group GSM12 is set
to mode 0:
Group Modes Offset Base Offset LSB Bit Width
GSM12 3 sm_base 0x400x100x2
BallGroup Mode 0 Mode 1 Mode 2
BK4 GSM12 UART0_RXIrDA0_RXGPIO9
BH6 GSM12 UART0_TXIrDA0_TXGPIO10
So in order to configure BK4 -> UART0_TX and BH6 -> UART0_RX, we need
to set (sm_base + 0x40 + 0x10) &= ff3f.
Signed-off-by: Antoine Ténart
---
drivers/pinctrl/Kconfig | 4 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-berlin.c | 498 +++
drivers/pinctrl/pinctrl-berlin.h | 72 ++
4 files changed, 575 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-berlin.c
create mode 100644 drivers/pinctrl/pinctrl-berlin.h
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index e49324032611..2d9339a7bd05 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -104,6 +104,10 @@ config PINCTRL_BCM2835
select PINMUX
select PINCONF
+config PINCTRL_BERLIN
+ bool
+ select PINMUX
+
config PINCTRL_CAPRI
bool "Broadcom Capri pinctrl driver"
depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 4b835880cf80..fd5a01d4475f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PINCTRL_BF60x) += pinctrl-adi2-bf60x.o
obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
obj-$(CONFIG_PINCTRL_BAYTRAIL) += pinctrl-baytrail.o
+obj-$(CONFIG_PINCTRL_BERLIN) += pinctrl-berlin.o
obj-$(CONFIG_PINCTRL_CAPRI)+= pinctrl-capri.o
obj-$(CONFIG_PINCTRL_IMX) += pinctrl-imx.o
obj-$(CONFIG_PINCTRL_IMX1_CORE)+= pinctrl-imx1-core.o
diff --git a/drivers/pinctrl/pinctrl-berlin.c b/drivers/pinctrl/pinctrl-berlin.c
new file mode 100644
index ..a377d6fbb127
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-berlin.c
@@ -0,0 +1,498 @@
+/*
+ * Marvell Berlin SoC pinctrl driver.
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "pinctrl-utils.h"
+#include "pinctrl-berlin.h"
+
+#define NFCTS(bit_width) (1 << ((bit_width) + 1))
+
+static const struct berlin_desc_group berlin2cd_pinctrl_groups[] = {
+ /* GSM */
+ BERLIN_PINCTRL_GROUP("GSM0", "apb_base",0x40, 0x2, 0x00),
+ BERLIN_PINCTRL_GROUP("GSM1", "apb_base",0x40, 0x2, 0x02),
+ BERLIN_PINCTRL_GROUP("GSM2", "apb_base",0x40, 0x2, 0x04),
+ BERLIN_PINCTRL_GROUP("GSM3", "apb_base",0x40, 0x2, 0x06),
+ BERLIN_PINCTRL_GROUP("GSM4", "apb_base",0x40, 0x2, 0x08),
+ BERLIN_PINCTRL_GROUP("GSM5", "apb_base",0x40, 0x2, 0x0a),
+ BERLIN_PINCTRL_GROUP("GSM6", "apb_base",0x40, 0x2, 0x0c),
+ BERLIN_PINCTRL_GROUP("GSM7", "apb_base",0x40, 0x1, 0x0e),
+ BERLIN_PINCTRL_GROUP("GSM8", "apb_base",0x40, 0x1, 0x0f),
+ BERLIN_PINCTRL_GROUP("GSM9", "apb_base",0x40, 0x1, 0x10),
+ BERLIN_PINCTRL_GROUP("GSM10", "apb_base",0x40, 0x1, 0x11),
+ BERLIN_PINCTRL_GROUP("GSM11", "apb_base",0x40, 0x1, 0x12),
+ /* G */
+ BERLIN_PINCTRL_GROUP("G0","global_base", 0x00, 0x1, 0x00),
+ BERLIN_PINCTRL_GROUP("G1","global_base", 0x00, 0x2, 0x01),
+ BERLIN_PINCTRL_GROUP("G2","global_base", 0x00, 0x2, 0x02),
+ BERLIN_PINCTRL_GROUP("G3","global_base", 0x00, 0x2, 0x04),
+ BERLIN_PINCTRL_GROUP("G4","global_base", 0x00, 0x2, 0x06),
+ BERLIN_PINCTRL_GROUP("G5","global_base", 0x00, 0x3, 0x08),
+ BERLIN_PINCTRL_GROUP("G6","global_base", 0x00, 0x2, 0x0b),
+ BERLIN_PINCTRL_GROUP("G7","global_base", 0x00, 0x3, 0x0d),
+ BERLIN_PINCTRL_GROUP("G8","global_base", 0x00, 0x3, 0x10),
+ BERLIN_PINCTRL_GROUP("G9","global_base", 0x00, 0x3, 0x13),
+ BERLIN_PINCTRL_GROUP("G10", "global_base", 0x00, 0x2, 0x16),
+ BERLIN_PINCTRL_GROUP("G11", "global_base", 0x00, 0x2, 0x18),
+ BERLIN_PINCTRL_GROUP("G12", "global_base", 0x00, 0x3, 0x1a),
+ BERLIN_PINCTRL_GROUP("G13", "global_base", 0x04, 0x3, 0x00),
+ BERLIN_PINCTRL_GROUP("G14", "global_base", 0x04, 0x1, 0x03),
+
[PATCH 4/5] Documentation: add the Marvell Berlin pinctrl documentation
Signed-off-by: Antoine Ténart
---
.../bindings/pinctrl/marvell,berlin-pinctrl.txt| 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
diff --git
a/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
new file mode 100644
index ..e21538a37734
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt
@@ -0,0 +1,43 @@
+* Pinctrl driver for the Marvell Berlin SoCs
+
+The pins controlled by the Marvell Berlin controller are organized in groups.
+Configuration is done by group, so no actual pin information is needed.
+
+Required properties:
+- compatible: "marvell-berlin2cd-pinctrl",
+ "marvell-berlin2-pinctrl",
+ "marvell-berlin2q-pinctrl"
+- reg: registers physical addresses and lengths of the pin controller.
+- reg-names: name of the register regions.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices.
+
+A pinctrl should contains subnodes representing the pinctrl pin group
+configurations, one per group. Each subnode has the group name and the muxing
+function used.
+
+Required subnode-properties:
+- berlin,group: a string describing the group's name.
+- berlin,function: the function used to mux the group.
+ 0: function 0
+ 1: function 1
+ ...
+
+Example:
+
+pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2q-pinctrl";
+ reg = <0xea 0x08>, <0xfc 0x44>;
+ reg-names = "global_base", "sm_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "GSM12";
+ berlin,function = <0>;
+ };
+}
+
+ {
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
+};
--
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 0/5] ARM: berlin: add pinctrl support
This series add support for the Marvell Berlin pinctrl, allowing to configure the pinmuxing from the device tree. This is a group based pinmux and only group informations are defined. For this to work a modification in the pinctrl framework is needed so that get_group_pin could not be defined. Please have a look on patches 1/5 and 2/5 commit logs. This serie applies on top of patches introducing the Marvell Berlin BG2Q you can find on Sebastian's for-next branch[1] and Alexandre's BG2Q symbol introduction[2]. Tested on the Berlin BG2Q. [1] https://github.com/shesselba/linux-berlin/commits/for-next [2] https://patchwork.kernel.org/patch/3876141/ Antoine Ténart (5): pinctrl: allows not to define the get_group_pins operation pinctrl: berlin: add a pinctrl driver for Marvell Berlin SoCs ARM: berlin: add the pinctrl dependency for the Marvell Berlin SoCs Documentation: add the Marvell Berlin pinctrl documentation ARM: dts: berlin: add the pinctrl node and muxing setup for uarts .../bindings/pinctrl/marvell,berlin-pinctrl.txt| 43 ++ arch/arm/boot/dts/berlin2.dtsi | 20 + arch/arm/boot/dts/berlin2cd.dtsi | 13 + arch/arm/boot/dts/berlin2q.dtsi| 20 + arch/arm/mach-berlin/Kconfig | 2 + drivers/pinctrl/Kconfig| 4 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/core.c | 17 +- drivers/pinctrl/pinctrl-berlin.c | 498 + drivers/pinctrl/pinctrl-berlin.h | 72 +++ drivers/pinctrl/pinmux.c | 23 +- 11 files changed, 696 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,berlin-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-berlin.c create mode 100644 drivers/pinctrl/pinctrl-berlin.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] ARM: berlin: add the pinctrl dependency for the Marvell Berlin SoCs
Signed-off-by: Antoine Ténart --- arch/arm/mach-berlin/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig index d3c5f14dc142..291f1cac6c3d 100644 --- a/arch/arm/mach-berlin/Kconfig +++ b/arch/arm/mach-berlin/Kconfig @@ -4,6 +4,8 @@ config ARCH_BERLIN select GENERIC_IRQ_CHIP select DW_APB_ICTL select DW_APB_TIMER_OF + select PINCTRL + select PINCTRL_BERLIN if ARCH_BERLIN -- 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 5/5] ARM: dts: berlin: add the pinctrl node and muxing setup for uarts
The uart0 pinmux configuration is in the dtsi because uart0 will always
use uart0-pmux to work, no other possibility. Same thing for uart1.
Signed-off-by: Antoine Ténart
---
arch/arm/boot/dts/berlin2.dtsi | 20
arch/arm/boot/dts/berlin2cd.dtsi | 13 +
arch/arm/boot/dts/berlin2q.dtsi | 20
3 files changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 56a1af2f1052..43eb90c36050 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -176,6 +176,22 @@
};
};
+ pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2-pinctrl";
+ reg = <0xea 0x08>, <0xfc 0x44>;
+ reg-names = "global_base", "apb_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "GSM4";
+ berlin,function = <0>;
+ };
+
+ uart1_pmux: uart1-pmux {
+ berlin,group = "GSM5";
+ berlin,function = <1>;
+ };
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -191,6 +207,8 @@
reg-io-width = <1>;
interrupts = <8>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
@@ -201,6 +219,8 @@
reg-io-width = <1>;
interrupts = <9>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 094968c27533..4c04cff89226 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -169,6 +169,17 @@
};
};
+ pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2cd-pinctrl";
+ reg = <0xea 0x08>, <0xfc 0x44>;
+ reg-names = "global_base", "apb_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "G6";
+ berlin,function = <0>;
+ };
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -184,6 +195,8 @@
reg-io-width = <1>;
interrupts = <8>;
clocks = <>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 07452a7483fa..e6e556055dfc 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -183,6 +183,22 @@
};
};
+ pinctrl: pinctrl@0 {
+ compatible = "marvell,berlin2q-pinctrl";
+ reg = <0xea 0x4c>, <0xfcd000 0x44>;
+ reg-names = "global_base", "sm_base";
+
+ uart0_pmux: uart0-pmux {
+ berlin,group = "GSM12";
+ berlin,function = <0>;
+ };
+
+ uart1_pmux: uart1-pmux {
+ berlin,group = "GSM14";
+ berlin,function = <1>;
+ };
+ };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -198,6 +214,8 @@
interrupts = <8>;
clocks = <>;
reg-shift = <2>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
status = "disabled";
};
@@ -208,6 +226,8 @@
interrupts = <9>;
clocks = <>;
reg-shift = <2>;
+ pinctrl-0 = <_pmux>;
+ pinctrl-names = "default";
[PATCH 1/5] pinctrl: allows not to define the get_group_pins operation
When using a group only pinctrl driver, which does not have any
information on the pins it is useless to define a get_group_pins
always returning an empty list of pins.
When not using get_group_pin[1], a driver must implement it so
pins = NULL and num_pins = 0. This patch makes it the default
behaviour if not defined in the pinctrl driver when used in
pinmux enable and disable funtions and in pinctrl_groups_show.
It also adds a check in pinctrl_get_group_pins and return -EINVAL if
not defined. This function is called in the gpiolib when adding when
pingroup range. It cannot be used if no group is defined, so this seams
reasonable.
[1] get_group_pin(struct pinctrl_dev *pctldev,
unsigned selector,
const unsigned **pins,
unsigned *num_pins);
Signed-off-by: Antoine Ténart
---
drivers/pinctrl/core.c | 17 ++---
drivers/pinctrl/pinmux.c | 23 +--
2 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe6091566a..e09474ecde23 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -468,6 +468,9 @@ int pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
const char *pin_group,
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
int gs;
+ if (!pctlops->get_group_pins)
+ return -EINVAL;
+
gs = pinctrl_get_group_selector(pctldev, pin_group);
if (gs < 0)
return gs;
@@ -1362,15 +1365,16 @@ static int pinctrl_groups_show(struct seq_file *s, void
*what)
seq_puts(s, "registered pin groups:\n");
while (selector < ngroups) {
- const unsigned *pins;
- unsigned num_pins;
+ const unsigned *pins = NULL;
+ unsigned num_pins = 0;
const char *gname = ops->get_group_name(pctldev, selector);
const char *pname;
- int ret;
+ int ret = 0;
int i;
- ret = ops->get_group_pins(pctldev, selector,
- , _pins);
+ if (ops->get_group_pins)
+ ret = ops->get_group_pins(pctldev, selector,
+ , _pins);
if (ret)
seq_printf(s, "%s [ERROR GETTING PINS]\n",
gname);
@@ -1694,8 +1698,7 @@ static int pinctrl_check_ops(struct pinctrl_dev *pctldev)
if (!ops ||
!ops->get_groups_count ||
- !ops->get_group_name ||
- !ops->get_group_pins)
+ !ops->get_group_name)
return -EINVAL;
if (ops->dt_node_to_map && !ops->dt_free_map)
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 9248ce4efed4..051e8592990e 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -391,14 +391,16 @@ int pinmux_enable_setting(struct pinctrl_setting const
*setting)
struct pinctrl_dev *pctldev = setting->pctldev;
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
const struct pinmux_ops *ops = pctldev->desc->pmxops;
- int ret;
- const unsigned *pins;
- unsigned num_pins;
+ int ret = 0;
+ const unsigned *pins = NULL;
+ unsigned num_pins = 0;
int i;
struct pin_desc *desc;
- ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
- , _pins);
+ if (pctlops->get_group_pins)
+ ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
+ , _pins);
+
if (ret) {
const char *gname;
@@ -470,14 +472,15 @@ void pinmux_disable_setting(struct pinctrl_setting const
*setting)
struct pinctrl_dev *pctldev = setting->pctldev;
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
const struct pinmux_ops *ops = pctldev->desc->pmxops;
- int ret;
- const unsigned *pins;
- unsigned num_pins;
+ int ret = 0;
+ const unsigned *pins = NULL;
+ unsigned num_pins = 0;
int i;
struct pin_desc *desc;
- ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
- , _pins);
+ if (pctlops->get_group_pins)
+ ret = pctlops->get_group_pins(pctldev, setting->data.mux.group,
+ , _pins);
if (ret) {
const char *gname;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] pinctrl: sunxi: define A31 R_PIO pin functions
On Thu, Apr 10, 2014 at 02:25:45PM +0200, Boris BREZILLON wrote: > The A31 SoC provides both PL and PM pio bank through the R_PIO block. > > These pins all support gpio function and can bbe assigned to system > peripherals (like TWI, P2WI, JTAG, ...) > > Add new compatible string to the DT bindings doc. > > Signed-off-by: Boris BREZILLON Acked-by: Maxime Ripard Thanks! -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v12 1/4] thermal: samsung: replace inten_ bit fields with intclr_
Hi,
Zhang, could you please review/merge this patchset?
[ We have been waiting for a review for over 3 months now.. ]
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
On Friday, February 07, 2014 03:03:46 PM Naveen Krishna Ch wrote:
> Hello All,
>
> On 2 January 2014 08:03, Zhang Rui wrote:
> > On Thu, 2013-12-19 at 11:35 +0530, Naveen Krishna Chatradhi wrote:
> >> This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
> >> with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
> >> Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only
> >> used
> >> to configure intclr related registers.
> >>
> >> Description of H/W:
> >> The offset for the bits in the CLEAR register are not consistent across TMU
> >> modules in Exynso5250, 5420 and 5440.
> >>
> >> On Exynos5250, the FALL interrupt related en, status and clear bits are
> >> available at an offset of
> >> 16 in INTEN, INTSTAT registers and at an offset of
> >> 12 in INTCLEAR register.
> >>
> >> On Exynos5420, the FALL interrupt related en, status and clear bits are
> >> available at an offset of
> >> 16 in INTEN, INTSTAT and INTCLEAR registers.
> >>
> >> On Exynos5440,
> >> the FALL_IRQEN bits are at an offset of 4
> >> and the RISE_IRQEN bits are at an offset of 0
> >>
> >> Signed-off-by: Naveen Krishna Chatradhi
> >> Acked-by: Amit Daniel Kachhap
> >> Reviewed-by: Bartlomiej Zolnierkiewicz
> >> Reviewed-by: Tomasz Figa
> >
> > Eduardo,
> >
> > what do you think of this patch set?
> >
> > thanks,
> > rui
> >> ---
> >> Changes since v11:
> >> Added Reviewed by Tomasz
> >>
> >> Changes since v10:
> >> None
> >>
> >> drivers/thermal/samsung/exynos_tmu.c |6 +++---
> >> drivers/thermal/samsung/exynos_tmu.h | 16
> >> drivers/thermal/samsung/exynos_tmu_data.c | 18 +-
> >> drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
> >> 4 files changed, 22 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> >> b/drivers/thermal/samsung/exynos_tmu.c
> >> index 32f38b9..c493245 100644
> >> --- a/drivers/thermal/samsung/exynos_tmu.c
> >> +++ b/drivers/thermal/samsung/exynos_tmu.c
> >> @@ -237,7 +237,7 @@ skip_calib_data:
> >> writeb(pdata->trigger_levels[i], data->base +
> >> reg->threshold_th0 + i * sizeof(reg->threshold_th0));
> >>
> >> - writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
> >> + writel(reg->intclr_rise_mask, data->base +
> >> reg->tmu_intclear);
> >> } else {
> >> /* Write temperature code for rising and falling threshold */
> >> for (i = 0;
> >> @@ -264,8 +264,8 @@ skip_calib_data:
> >> writel(falling_threshold,
> >> data->base + reg->threshold_th1);
> >>
> >> - writel((reg->inten_rise_mask << reg->inten_rise_shift) |
> >> - (reg->inten_fall_mask << reg->inten_fall_shift),
> >> + writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
> >> + (reg->intclr_fall_mask << reg->intclr_fall_shift),
> >> data->base + reg->tmu_intclear);
> >>
> >> /* if last threshold limit is also present */
> >> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> >> b/drivers/thermal/samsung/exynos_tmu.h
> >> index 3fb6554..980859a 100644
> >> --- a/drivers/thermal/samsung/exynos_tmu.h
> >> +++ b/drivers/thermal/samsung/exynos_tmu.h
> >> @@ -122,10 +122,6 @@ enum soc_type {
> >> * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
> >> * @tmu_inten: register containing the different threshold interrupt
> >> enable bits.
> >> - * @inten_rise_shift: shift bits of all rising interrupt bits.
> >> - * @inten_rise_mask: mask bits of all rising interrupt bits.
> >> - * @inten_fall_shift: shift bits of all rising interrupt bits.
> >> - * @inten_fall_mask: mask bits of all rising interrupt bits.
> >> * @inten_rise0_shift: shift bits of rising 0 interrupt bits.
> >> * @inten_rise1_shift: shift bits of rising 1 interrupt bits.
> >> * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
> >> @@ -136,6 +132,10 @@ enum soc_type {
> >> * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
> >> * @tmu_intstat: Register containing the interrupt status values.
> >> * @tmu_intclear: Register for clearing the raised interrupt status.
> >> + * @intclr_fall_shift: shift bits for interrupt clear fall 0
> >> + * @intclr_rise_shift: shift bits of all rising interrupt bits.
> >> + * @intclr_rise_mask: mask bits of all rising interrupt bits.
> >> + * @intclr_fall_mask: mask bits of all rising interrupt bits.
> >> * @emul_con: TMU emulation controller register.
> >> * @emul_temp_shift: shift bits of emulation temperature.
> >> * @emul_time_shift: shift bits of emulation time.
> >>
[writeback] 6903673566d: +2.5% fileio.requests_per_sec
Hi Jan,
I tried your writeback dirty list patchset and noticed some ups/downs.
The main performance changes are
1) +2.5% fileio.requests_per_sec
2) -7.1% iostat.md0.wkB/s
git://bee.sh.intel.com/git/wfg/linux-devel.git jan-dirty-list
commit 6903673566d0289680e593dac088c787d119b067 ("writeback: Replace several
writeback lists with inode tagging")
836ecc5f024669e 6903673566d0289680e593dac
--- -
6526 ~ 0% +3.2% 6736 ~ 0%
snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqrewr-sync
6441 ~ 0% +1.8% 6558 ~ 0%
snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqwr-sync
12968 ~ 0% +2.5% 13295 ~ 0% TOTAL fileio.requests_per_sec
836ecc5f024669e 6903673566d0289680e593dac
--- -
398147 ~ 0% -7.1% 369866 ~ 0%
lkp-st02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd
398147 ~ 0% -7.1% 369866 ~ 0% TOTAL iostat.md0.wkB/s
836ecc5f024669e 6903673566d0289680e593dac
--- -
861 ~30% -78.7%183 ~33%
bay/micro/dd-write/1HDD-cfq-xfs-100dd
464 ~48% -91.7% 38 ~27%
lkp-st02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd
109 ~18% +54509.0% 59960 ~ 2%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
1436 ~35% +4089.8% 60182 ~ 2% TOTAL
proc-vmstat.nr_vmscan_immediate_reclaim
836ecc5f024669e 6903673566d0289680e593dac
--- -
123 ~29% -94.3% 7 ~ 0%
lkp-st02/micro/dd-write/11HDD-RAID5-cfq-xfs-10dd
123 ~29% -94.3% 7 ~ 0% TOTAL
ftrace.writeback_single_inode.md0.age
836ecc5f024669e 6903673566d0289680e593dac
--- -
55 ~19% +19305.5% 10750 ~17%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
55 ~19% +19305.5% 10750 ~17% TOTAL
numa-vmstat.node1.nr_vmscan_immediate_reclaim
836ecc5f024669e 6903673566d0289680e593dac
--- -
38 ~26% +22737.7% 8815 ~17%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
38 ~26% +22737.7% 8815 ~17% TOTAL
numa-vmstat.node0.nr_vmscan_immediate_reclaim
836ecc5f024669e 6903673566d0289680e593dac
--- -
145 ~16%+668.1% 1115 ~17%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
145 ~16%+668.1% 1115 ~17% TOTAL proc-vmstat.pgrotated
836ecc5f024669e 6903673566d0289680e593dac
--- -
1477 ~ 0%+275.0% 5541 ~ 1%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
1477 ~ 0%+275.0% 5541 ~ 1% TOTAL meminfo.Buffers
836ecc5f024669e 6903673566d0289680e593dac
--- -
1486 ~ 0%+273.3% 5546 ~ 1%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
1486 ~ 0%+273.3% 5546 ~ 1% TOTAL vmstat.memory.buff
836ecc5f024669e 6903673566d0289680e593dac
--- -
13328 ~ 0% -68.6% 4180 ~ 7%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
13328 ~ 0% -68.6% 4180 ~ 7% TOTAL proc-vmstat.pgpgin
836ecc5f024669e 6903673566d0289680e593dac
--- -
0.36 ~11% -78.9% 0.08 ~16%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
0.12 ~ 6% -22.0% 0.09 ~ 8%
snb-drag/sysbench/fileio/600s-100%-1HDD-xfs-64G-1024-seqrewr-sync
0.48 ~10% -65.0% 0.17 ~11% TOTAL turbostat.%pc3
836ecc5f024669e 6903673566d0289680e593dac
--- -
2 ~ 0% +50.0% 3 ~ 0%
bay/micro/dd-write/1HDD-cfq-xfs-100dd
1 ~ 0%+300.0% 4 ~ 0% bay/micro/dd-write/1HDD-cfq-xfs-10dd
3 ~ 0%+133.3% 7 ~ 0% TOTAL
ftrace.writeback_single_inode.sda.age
836ecc5f024669e 6903673566d0289680e593dac
--- -
105 ~11%+125.9%237 ~ 9% bay/micro/dd-write/1HDD-cfq-xfs-10dd
105 ~11%+125.9%237 ~ 9% TOTAL slabinfo.xfs_trans.active_objs
836ecc5f024669e 6903673566d0289680e593dac
--- -
105 ~11%+125.9%237 ~ 9% bay/micro/dd-write/1HDD-cfq-xfs-10dd
105 ~11%+125.9%237 ~ 9% TOTAL slabinfo.xfs_trans.num_objs
836ecc5f024669e 6903673566d0289680e593dac
--- -
868 ~ 2%+124.1% 1946 ~ 1%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
868 ~ 2%+124.1% 1946 ~ 1% TOTAL
slabinfo.journal_head.active_objs
836ecc5f024669e 6903673566d0289680e593dac
--- -
868 ~ 2%+124.1% 1946 ~ 1%
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-1dd
868 ~ 2%+124.1% 1946 ~ 1% TOTAL
Re: [PATCH v2 2/5] pinctrl: sunxi: support multiple pin controller
On Thu, Apr 10, 2014 at 02:25:44PM +0200, Boris BREZILLON wrote: > Add support for multiple pin controller instances. > > First remove the static definition of the sunxi gpio chip struct and fill > the dynamically struct instead. > Then define a new pin_base field in the sunxi_pinctrl_desc which will be > used to specify the gpiochip base pin. > > Signed-off-by: Boris BREZILLON Acked-by: Maxime Ripard Thanks! -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [RFC PATCH v2 2/6] uprobes/x86: Emulate unconditional rip-relative jmp's
On 04/09/2014 09:44 PM, Oleg Nesterov wrote:
> uprobes/x86: Emulate unconditional rip-relative jmp's
I propose "Emulate unconditional relative jmp's"
> + union {
> #ifdef CONFIG_X86_64
> - unsigned long rip_rela_target_address;
> + unsigned long rip_rela_target_address;
> #endif
> + struct {
> + s32 disp;
In x86-speak, jumps and calls have "offsets", not "displacements"
> + u8 ilen;
> + } ttt;
> + };
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] pinctrl: sunxi: add PL and PM pin definitions
Hi, On Thu, Apr 10, 2014 at 02:25:43PM +0200, Boris BREZILLON wrote: > Define PL and PM pin macros that will be used in A31 and A23 pin definitions. > > Signed-off-by: Boris BREZILLON Acked-by: Maxime Ripard Thanks! -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: Oops in acpi_gpiochip_add on MacBookPro with Linux v3.14-12042-g69cd9eba3886
On Thu, Apr 10, 2014 at 08:22:12AM -0400, Josh Boyer wrote: > On Thu, Apr 10, 2014 at 2:50 AM, Rafał Miłecki wrote: > > 2014-04-09 23:09 GMT+02:00 Josh Boyer : > >> With Linux v3.14-12042-g69cd9eba3886 I get an oops from the bcma > >> module on the MacBookPro 10,2 I have here. This works fine with Linux > >> v3.14-7333-g59ecc26004e7. There have been no changes between those > >> two versions to bcma itself, but the GPIO merge did go in that window. > >> I can attempt to do a bisect tomorrow, but looking over some of the > >> GPIO commits it seems pretty relevant to the ACPI GPIO changes. I'm > >> hoping someone here has an idea on what the issue might be and has > >> some possible things for me to test for fixes. > > > > Bug report: https://lkml.org/lkml/2014/3/24/262 > > Patch: https://lkml.org/lkml/2014/3/24/293 > > Tested by Sabrina: https://lkml.org/lkml/2014/3/24/304 > > (all links are for the same thread). > > > > Now you simply have to find above patch in some git tree :) Not sure > > if it's already in Linus's one. > > Ah, wonderful. I now wish I would have found those in my searching > before doing the bisect. Oh well. For what it's worth, my bisect > landed on the same commit. > > The fix isn't in Linus' tree or linux-next. I'm guessing Mika is > either still on vacation, or hasn't sent out the formal fix yet. No, not on vacation anymore (unfortunately). I did send the formal patch already: https://lkml.org/lkml/2014/3/31/135 but it isn't merged to Linus' GPIO tree yet. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
Hi, Zhang, could you please pick this patch up to your tree? [ Eduardos's tree hasn't been updated for over 4 months and seems to be dead.. ] Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics On Tuesday, November 26, 2013 09:22:31 AM Eduardo Valentin wrote: > On 26-11-2013 02:07, Amit Kachhap wrote: > > On 10/4/13, Bartlomiej Zolnierkiewicz wrote: > >> Menu for Samsung thermal support is visible on all Samsung > >> platforms while thermal drivers are currently available only > >> for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency > >> with ARCH_EXYNOS one. > >> > >> Signed-off-by: Bartlomiej Zolnierkiewicz > >> Signed-off-by: Kyungmin Park > > Looks good, so > > Acked-by: Amit Daniel Kachhap > > I will be queuing this one in my tree. > > Thanks Bartlomiej. > > > > >> --- > >> drivers/thermal/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > >> index a709c63..05cf95c 100644 > >> --- a/drivers/thermal/Kconfig > >> +++ b/drivers/thermal/Kconfig > >> @@ -198,7 +198,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig" > >> endmenu > >> > >> menu "Samsung thermal drivers" > >> -depends on PLAT_SAMSUNG > >> +depends on ARCH_EXYNOS > >> source "drivers/thermal/samsung/Kconfig" > >> endmenu > >> > >> -- > >> 1.8.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/6] uprobes/x86: fix the reprel jmp/call handling
On 04/09/2014 09:44 PM, Oleg Nesterov wrote: > On 04/06, Oleg Nesterov wrote: > uprobes/x86: fix the reprel jmp/call handling In x86 asm-speak, relative jumps and calls are called simply "relative" (meaning that instructions contain an offset relative to current instruction pointer). I propose to use the "relative" term when you refer to such branch instructions. Not, say, "rip-relative" - that term is used in x86-speak only for instruction-pointer-relative operands. MOV 0x123456(%RIP), %RCX *This* is rip-relative offset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] pinctrl: sunxi: add reset control support
The A31 SoC define a reset line for the R_PIO block which needs to be
deasserted for the pin controller to be usable.
Try to retrieve a reset line and deassert if one was found.
Signed-off-by: Boris BREZILLON
---
drivers/pinctrl/pinctrl-sunxi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index ee62027..b752495 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include "core.h"
@@ -792,6 +793,7 @@ static int sunxi_pinctrl_probe(struct platform_device *pdev)
const struct of_device_id *device;
struct pinctrl_pin_desc *pins;
struct sunxi_pinctrl *pctl;
+ struct reset_control *rstc;
int i, ret, last_pin;
struct clk *clk;
@@ -885,6 +887,13 @@ static int sunxi_pinctrl_probe(struct platform_device
*pdev)
clk_prepare_enable(clk);
+ rstc = devm_reset_control_get(>dev, NULL);
+ if (!IS_ERR(rstc)) {
+ ret = reset_control_deassert(rstc);
+ if (ret)
+ goto gpiochip_error;
+ }
+
pctl->irq = irq_of_parse_and_map(node, 0);
if (!pctl->irq) {
ret = -EINVAL;
--
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/5] ARM: sunxi: add multi pin controller support
Hello, This series rework the sunxi pinctrl driver to support the PL and PM pins available on the A31 SoC, which are controlled using the R_PIO block. This series add support for multi pin controller which was previously impossible for several reasons: 1) the pinctrl instance was registering a static instance of the gpio chip, which means, in case you were probing 2 devices, the gpio chip was added twice to the gpiochip list 2) the base pin of the gpio chip was always set to 0, and thus the 2 gpiochip pin numbers were overlapping I still haven't reworked the interrupt part (to handle the "per bank interrupt" instead of the "one interrupt for the whole gpio" chip approach), but this will be part of another series. Best Regards, Boris Changes since v1: - rework the pinctrl driver to support multiple pin controller instances - removed reset and clock gate patches from the series - removed A31 DT modifications from the series (we need to get the PRCM reset and clk drivers before being able to declare the r_pio node, and we're still discussing how this should be implemented) Boris BREZILLON (5): pinctrl: sunxi: add PL and PM pin definitions pinctrl: sunxi: support multiple pin controller pinctrl: sunxi: define A31 R_PIO pin functions pinctrl: sunxi: add reset control support ARM: sunxi: update the default ARCH_NR_GPIO for sunxi arch .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + arch/arm/Kconfig | 2 +- drivers/pinctrl/pinctrl-sunxi-pins.h | 74 ++ drivers/pinctrl/pinctrl-sunxi.c| 40 +++- drivers/pinctrl/pinctrl-sunxi.h| 69 5 files changed, 169 insertions(+), 17 deletions(-) -- 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 5/5] ARM: sunxi: update the default ARCH_NR_GPIO for sunxi arch
The A31 SoC has PL and PM banks, we thus need to increase the default ARCH_NR_GPIO when building for the sunxi architecture. Signed-off-by: Boris BREZILLON --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 503da0a..fe915ea 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1628,9 +1628,9 @@ config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX + default 416 if ARCH_SUNXI default 392 if ARCH_U8500 default 352 if ARCH_VT8500 - default 288 if ARCH_SUNXI default 264 if MACH_H4700 default 0 help -- 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 1/5] pinctrl: sunxi: add PL and PM pin definitions
Define PL and PM pin macros that will be used in A31 and A23 pin definitions. Signed-off-by: Boris BREZILLON --- drivers/pinctrl/pinctrl-sunxi.h | 68 + 1 file changed, 68 insertions(+) diff --git a/drivers/pinctrl/pinctrl-sunxi.h b/drivers/pinctrl/pinctrl-sunxi.h index 552b0e9..ed3c4d7 100644 --- a/drivers/pinctrl/pinctrl-sunxi.h +++ b/drivers/pinctrl/pinctrl-sunxi.h @@ -25,6 +25,8 @@ #define PG_BASE192 #define PH_BASE224 #define PI_BASE256 +#define PL_BASE352 +#define PM_BASE384 #define SUNXI_PINCTRL_PIN_PA0 PINCTRL_PIN(PA_BASE + 0, "PA0") #define SUNXI_PINCTRL_PIN_PA1 PINCTRL_PIN(PA_BASE + 1, "PA1") @@ -323,6 +325,72 @@ #define SUNXI_PINCTRL_PIN_PI30 PINCTRL_PIN(PI_BASE + 30, "PI30") #define SUNXI_PINCTRL_PIN_PI31 PINCTRL_PIN(PI_BASE + 31, "PI31") +#define SUNXI_PINCTRL_PIN_PL0 PINCTRL_PIN(PL_BASE + 0, "PL0") +#define SUNXI_PINCTRL_PIN_PL1 PINCTRL_PIN(PL_BASE + 1, "PL1") +#define SUNXI_PINCTRL_PIN_PL2 PINCTRL_PIN(PL_BASE + 2, "PL2") +#define SUNXI_PINCTRL_PIN_PL3 PINCTRL_PIN(PL_BASE + 3, "PL3") +#define SUNXI_PINCTRL_PIN_PL4 PINCTRL_PIN(PL_BASE + 4, "PL4") +#define SUNXI_PINCTRL_PIN_PL5 PINCTRL_PIN(PL_BASE + 5, "PL5") +#define SUNXI_PINCTRL_PIN_PL6 PINCTRL_PIN(PL_BASE + 6, "PL6") +#define SUNXI_PINCTRL_PIN_PL7 PINCTRL_PIN(PL_BASE + 7, "PL7") +#define SUNXI_PINCTRL_PIN_PL8 PINCTRL_PIN(PL_BASE + 8, "PL8") +#define SUNXI_PINCTRL_PIN_PL9 PINCTRL_PIN(PL_BASE + 9, "PL9") +#define SUNXI_PINCTRL_PIN_PL10 PINCTRL_PIN(PL_BASE + 10, "PL10") +#define SUNXI_PINCTRL_PIN_PL11 PINCTRL_PIN(PL_BASE + 11, "PL11") +#define SUNXI_PINCTRL_PIN_PL12 PINCTRL_PIN(PL_BASE + 12, "PL12") +#define SUNXI_PINCTRL_PIN_PL13 PINCTRL_PIN(PL_BASE + 13, "PL13") +#define SUNXI_PINCTRL_PIN_PL14 PINCTRL_PIN(PL_BASE + 14, "PL14") +#define SUNXI_PINCTRL_PIN_PL15 PINCTRL_PIN(PL_BASE + 15, "PL15") +#define SUNXI_PINCTRL_PIN_PL16 PINCTRL_PIN(PL_BASE + 16, "PL16") +#define SUNXI_PINCTRL_PIN_PL17 PINCTRL_PIN(PL_BASE + 17, "PL17") +#define SUNXI_PINCTRL_PIN_PL18 PINCTRL_PIN(PL_BASE + 18, "PL18") +#define SUNXI_PINCTRL_PIN_PL19 PINCTRL_PIN(PL_BASE + 19, "PL19") +#define SUNXI_PINCTRL_PIN_PL20 PINCTRL_PIN(PL_BASE + 20, "PL20") +#define SUNXI_PINCTRL_PIN_PL21 PINCTRL_PIN(PL_BASE + 21, "PL21") +#define SUNXI_PINCTRL_PIN_PL22 PINCTRL_PIN(PL_BASE + 22, "PL22") +#define SUNXI_PINCTRL_PIN_PL23 PINCTRL_PIN(PL_BASE + 23, "PL23") +#define SUNXI_PINCTRL_PIN_PL24 PINCTRL_PIN(PL_BASE + 24, "PL24") +#define SUNXI_PINCTRL_PIN_PL25 PINCTRL_PIN(PL_BASE + 25, "PL25") +#define SUNXI_PINCTRL_PIN_PL26 PINCTRL_PIN(PL_BASE + 26, "PL26") +#define SUNXI_PINCTRL_PIN_PL27 PINCTRL_PIN(PL_BASE + 27, "PL27") +#define SUNXI_PINCTRL_PIN_PL28 PINCTRL_PIN(PL_BASE + 28, "PL28") +#define SUNXI_PINCTRL_PIN_PL29 PINCTRL_PIN(PL_BASE + 29, "PL29") +#define SUNXI_PINCTRL_PIN_PL30 PINCTRL_PIN(PL_BASE + 30, "PL30") +#define SUNXI_PINCTRL_PIN_PL31 PINCTRL_PIN(PL_BASE + 31, "PL31") + +#define SUNXI_PINCTRL_PIN_PM0 PINCTRL_PIN(PM_BASE + 0, "PM0") +#define SUNXI_PINCTRL_PIN_PM1 PINCTRL_PIN(PM_BASE + 1, "PM1") +#define SUNXI_PINCTRL_PIN_PM2 PINCTRL_PIN(PM_BASE + 2, "PM2") +#define SUNXI_PINCTRL_PIN_PM3 PINCTRL_PIN(PM_BASE + 3, "PM3") +#define SUNXI_PINCTRL_PIN_PM4 PINCTRL_PIN(PM_BASE + 4, "PM4") +#define SUNXI_PINCTRL_PIN_PM5 PINCTRL_PIN(PM_BASE + 5, "PM5") +#define SUNXI_PINCTRL_PIN_PM6 PINCTRL_PIN(PM_BASE + 6, "PM6") +#define SUNXI_PINCTRL_PIN_PM7 PINCTRL_PIN(PM_BASE + 7, "PM7") +#define SUNXI_PINCTRL_PIN_PM8 PINCTRL_PIN(PM_BASE + 8, "PM8") +#define SUNXI_PINCTRL_PIN_PM9 PINCTRL_PIN(PM_BASE + 9, "PM9") +#define SUNXI_PINCTRL_PIN_PM10 PINCTRL_PIN(PM_BASE + 10, "PM10") +#define SUNXI_PINCTRL_PIN_PM11 PINCTRL_PIN(PM_BASE + 11, "PM11") +#define SUNXI_PINCTRL_PIN_PM12 PINCTRL_PIN(PM_BASE + 12, "PM12") +#define SUNXI_PINCTRL_PIN_PM13 PINCTRL_PIN(PM_BASE + 13, "PM13") +#define SUNXI_PINCTRL_PIN_PM14 PINCTRL_PIN(PM_BASE + 14, "PM14") +#define SUNXI_PINCTRL_PIN_PM15 PINCTRL_PIN(PM_BASE + 15, "PM15") +#define SUNXI_PINCTRL_PIN_PM16 PINCTRL_PIN(PM_BASE + 16, "PM16") +#define SUNXI_PINCTRL_PIN_PM17 PINCTRL_PIN(PM_BASE + 17, "PM17") +#define SUNXI_PINCTRL_PIN_PM18 PINCTRL_PIN(PM_BASE + 18, "PM18") +#define SUNXI_PINCTRL_PIN_PM19 PINCTRL_PIN(PM_BASE + 19, "PM19") +#define SUNXI_PINCTRL_PIN_PM20 PINCTRL_PIN(PM_BASE + 20, "PM20") +#define SUNXI_PINCTRL_PIN_PM21 PINCTRL_PIN(PM_BASE + 21, "PM21") +#define SUNXI_PINCTRL_PIN_PM22 PINCTRL_PIN(PM_BASE + 22, "PM22") +#define SUNXI_PINCTRL_PIN_PM23 PINCTRL_PIN(PM_BASE + 23, "PM23") +#define SUNXI_PINCTRL_PIN_PM24 PINCTRL_PIN(PM_BASE + 24, "PM24") +#define SUNXI_PINCTRL_PIN_PM25 PINCTRL_PIN(PM_BASE + 25, "PM25") +#define SUNXI_PINCTRL_PIN_PM26 PINCTRL_PIN(PM_BASE + 26, "PM26") +#define SUNXI_PINCTRL_PIN_PM27 PINCTRL_PIN(PM_BASE + 27, "PM27") +#define SUNXI_PINCTRL_PIN_PM28 PINCTRL_PIN(PM_BASE + 28, "PM28") +#define SUNXI_PINCTRL_PIN_PM29 PINCTRL_PIN(PM_BASE + 29, "PM29") +#define SUNXI_PINCTRL_PIN_PM30 PINCTRL_PIN(PM_BASE + 30, "PM30") +#define
[PATCH v2 2/5] pinctrl: sunxi: support multiple pin controller
Add support for multiple pin controller instances.
First remove the static definition of the sunxi gpio chip struct and fill
the dynamically struct instead.
Then define a new pin_base field in the sunxi_pinctrl_desc which will be
used to specify the gpiochip base pin.
Signed-off-by: Boris BREZILLON
---
drivers/pinctrl/pinctrl-sunxi.c | 30 ++
drivers/pinctrl/pinctrl-sunxi.h | 1 +
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index f9fabe9..64bcc68 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -538,19 +538,6 @@ static int sunxi_pinctrl_gpio_to_irq(struct gpio_chip
*chip, unsigned offset)
return irq_find_mapping(pctl->domain, desc->irqnum);
}
-static struct gpio_chip sunxi_pinctrl_gpio_chip = {
- .owner = THIS_MODULE,
- .request= sunxi_pinctrl_gpio_request,
- .free = sunxi_pinctrl_gpio_free,
- .direction_input= sunxi_pinctrl_gpio_direction_input,
- .direction_output = sunxi_pinctrl_gpio_direction_output,
- .get= sunxi_pinctrl_gpio_get,
- .set= sunxi_pinctrl_gpio_set,
- .of_xlate = sunxi_pinctrl_gpio_of_xlate,
- .to_irq = sunxi_pinctrl_gpio_to_irq,
- .of_gpio_n_cells= 3,
- .can_sleep = false,
-};
static int sunxi_pinctrl_irq_set_type(struct irq_data *d,
unsigned int type)
@@ -858,11 +845,22 @@ static int sunxi_pinctrl_probe(struct platform_device
*pdev)
}
last_pin = pctl->desc->pins[pctl->desc->npins - 1].pin.number;
- pctl->chip = _pinctrl_gpio_chip;
- pctl->chip->ngpio = round_up(last_pin, PINS_PER_BANK);
+ pctl->chip->owner = THIS_MODULE;
+ pctl->chip->request = sunxi_pinctrl_gpio_request,
+ pctl->chip->free = sunxi_pinctrl_gpio_free,
+ pctl->chip->direction_input = sunxi_pinctrl_gpio_direction_input,
+ pctl->chip->direction_output = sunxi_pinctrl_gpio_direction_output,
+ pctl->chip->get = sunxi_pinctrl_gpio_get,
+ pctl->chip->set = sunxi_pinctrl_gpio_set,
+ pctl->chip->of_xlate = sunxi_pinctrl_gpio_of_xlate,
+ pctl->chip->to_irq = sunxi_pinctrl_gpio_to_irq,
+ pctl->chip->of_gpio_n_cells = 3,
+ pctl->chip->can_sleep = false,
+ pctl->chip->ngpio = round_up(last_pin, PINS_PER_BANK) -
+ pctl->desc->pin_base;
pctl->chip->label = dev_name(>dev);
pctl->chip->dev = >dev;
- pctl->chip->base = 0;
+ pctl->chip->base = pctl->desc->pin_base;
ret = gpiochip_add(pctl->chip);
if (ret)
diff --git a/drivers/pinctrl/pinctrl-sunxi.h b/drivers/pinctrl/pinctrl-sunxi.h
index ed3c4d7..35d15b2 100644
--- a/drivers/pinctrl/pinctrl-sunxi.h
+++ b/drivers/pinctrl/pinctrl-sunxi.h
@@ -450,6 +450,7 @@ struct sunxi_pinctrl_desc {
int npins;
struct pinctrl_gpio_range *ranges;
int nranges;
+ unsignedpin_base;
};
struct sunxi_pinctrl_function {
--
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 3/5] pinctrl: sunxi: define A31 R_PIO pin functions
The A31 SoC provides both PL and PM pio bank through the R_PIO block.
These pins all support gpio function and can bbe assigned to system
peripherals (like TWI, P2WI, JTAG, ...)
Add new compatible string to the DT bindings doc.
Signed-off-by: Boris BREZILLON
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
drivers/pinctrl/pinctrl-sunxi-pins.h | 74 ++
drivers/pinctrl/pinctrl-sunxi.c| 1 +
3 files changed, 76 insertions(+)
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index f5da7e3..d8d0656 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -11,6 +11,7 @@ Required properties:
"allwinner,sun5i-a10s-pinctrl"
"allwinner,sun5i-a13-pinctrl"
"allwinner,sun6i-a31-pinctrl"
+ "allwinner,sun6i-a31-r-pinctrl"
"allwinner,sun7i-a20-pinctrl"
- reg: Should contain the register physical address and length for the
pin controller.
diff --git a/drivers/pinctrl/pinctrl-sunxi-pins.h
b/drivers/pinctrl/pinctrl-sunxi-pins.h
index 3d60669..51100ca 100644
--- a/drivers/pinctrl/pinctrl-sunxi-pins.h
+++ b/drivers/pinctrl/pinctrl-sunxi-pins.h
@@ -2820,6 +2820,74 @@ static const struct sunxi_desc_pin sun6i_a31_pins[] = {
SUNXI_FUNCTION(0x2, "nand1")),/* CE3 */
};
+static const struct sunxi_desc_pin sun6i_a31_r_pins[] = {
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL0,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_twi"), /* SCK */
+ SUNXI_FUNCTION(0x3, "s_p2wi")), /* SCK */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL1,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_twi"), /* SDA */
+ SUNXI_FUNCTION(0x3, "s_p2wi")), /* SDA */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL2,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart")), /* TX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart")), /* RX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL4,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_ir")), /* RX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL5,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* MS */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL6,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* CK */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL7,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* DO */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PL8,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* DI */
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM0,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM1,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM2,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "1wire")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM3,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM4,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM5,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM6,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN_PM7,
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "rtc")), /* CLKO */
+};
+
static const struct sunxi_desc_pin sun7i_a20_pins[] = {
SUNXI_PIN(SUNXI_PINCTRL_PIN_PA0,
SUNXI_FUNCTION(0x0, "gpio_in"),
@@ -3855,6
Re: "54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s
Op 10 apr. 2014, om 14:11 heeft Matt Fleming het volgende geschreven: > On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote: >> Hi, >> >> After updating from 3.14-rc7 to a recent git the kernel fails to boot on my >> thinkpad t440s and displays: >> >> Failed to get file info size >> Failed to alloc highmem for files >> >> After a morning of running git bisect and rebooting, the bad commit seems to >> be: >> >> 54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI >> services pointer table > > Thanks for the report. Can you try this patch against Linus' tree? That indeed fixes it, so: Tested-by: Koen Kooi regards, Koen > > > diff --git a/arch/x86/boot/compressed/eboot.c > b/arch/x86/boot/compressed/eboot.c > index 1e6146137f8e..280165524ee4 100644 > --- a/arch/x86/boot/compressed/eboot.c > +++ b/arch/x86/boot/compressed/eboot.c > @@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16, > efi_file_info_t *info; > efi_status_t status; > efi_guid_t info_guid = EFI_FILE_INFO_ID; > - u32 info_sz; > + u64 info_sz; > > status = efi_early->call((unsigned long)fh->open, fh, , filename_16, >EFI_FILE_MODE_READ, (u64)0); > -- > Matt Fleming, Intel Open Source Technology Center > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] SPI: Add driver for Cadence SPI controller
Hi Mark, On Thu, Apr 10, 2014 at 5:51 PM, Mark Brown wrote: > On Thu, Apr 10, 2014 at 05:43:49PM +0530, Harini Katakam wrote: > >> Firstly, the timeout value obtained from this is a too low. >> This timeout is typically used for an error conditions such as >> hardware hang etc. and using a value >1*HZ would be better. >> This driver used to use similar timeout and as I understand, other >> drivers also use similar values. > > Send patches... Ok thanks, I will. Regards, Harini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Oops in acpi_gpiochip_add on MacBookPro with Linux v3.14-12042-g69cd9eba3886
On Thu, Apr 10, 2014 at 2:50 AM, Rafał Miłecki wrote: > 2014-04-09 23:09 GMT+02:00 Josh Boyer : >> With Linux v3.14-12042-g69cd9eba3886 I get an oops from the bcma >> module on the MacBookPro 10,2 I have here. This works fine with Linux >> v3.14-7333-g59ecc26004e7. There have been no changes between those >> two versions to bcma itself, but the GPIO merge did go in that window. >> I can attempt to do a bisect tomorrow, but looking over some of the >> GPIO commits it seems pretty relevant to the ACPI GPIO changes. I'm >> hoping someone here has an idea on what the issue might be and has >> some possible things for me to test for fixes. > > Bug report: https://lkml.org/lkml/2014/3/24/262 > Patch: https://lkml.org/lkml/2014/3/24/293 > Tested by Sabrina: https://lkml.org/lkml/2014/3/24/304 > (all links are for the same thread). > > Now you simply have to find above patch in some git tree :) Not sure > if it's already in Linus's one. Ah, wonderful. I now wish I would have found those in my searching before doing the bisect. Oh well. For what it's worth, my bisect landed on the same commit. The fix isn't in Linus' tree or linux-next. I'm guessing Mika is either still on vacation, or hasn't sent out the formal fix yet. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] SPI: Add driver for Cadence SPI controller
On Thu, Apr 10, 2014 at 05:43:49PM +0530, Harini Katakam wrote: > Firstly, the timeout value obtained from this is a too low. > This timeout is typically used for an error conditions such as > hardware hang etc. and using a value >1*HZ would be better. > This driver used to use similar timeout and as I understand, other > drivers also use similar values. Send patches... signature.asc Description: Digital signature
[PATCH v3 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
Add spi-cadence bindings documentation.
Signed-off-by: Harini Katakam
---
v3 changes:
- Remove /bits/ 16 from num-cs property in example.
- Add is-decoded-cs optional property and add to description of num-cs.
v2 changes:
- Separate patch for bindings.
- Add xilinx compatible string; Make compatible string first in the node.
- Use property name num-cs. Make this property optional.
---
.../devicetree/bindings/spi/spi-cadence.txt| 31
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-cadence.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.txt
b/Documentation/devicetree/bindings/spi/spi-cadence.txt
new file mode 100644
index 000..94f0914
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-cadence.txt
@@ -0,0 +1,31 @@
+Cadence SPI controller Device Tree Bindings
+---
+
+Required properties:
+- compatible : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6".
+- reg : Physical base address and size of SPI registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clock-names : List of input clock names - "ref_clk", "pclk"
+ (See clock bindings for details).
+- clocks : Clock phandles (see clock bindings for details).
+
+Optional properties:
+- num-cs : Number of chip selects used.
+ If a decoder is used, this will be the number of
+ chip selects after the decoder.
+- is-decoded-cs: Flag to indicate whether decoder is used or
not.
+
+Example:
+
+ spi@e0007000 {
+ compatible = "xlnx,zynq-spi-r1p6";
+ clock-names = "ref_clk", "pclk";
+ clocks = < 26>, < 35>;
+ interrupt-parent = <>;
+ interrupts = <0 49 4>;
+ num-cs = <4>;
+ is-decoded-cs = <0>;
+ reg = <0xe0007000 0x1000>;
+ } ;
--
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/2] SPI: Add driver for Cadence SPI controller
Add driver for Cadence SPI controller. This is used in Xilinx Zynq. Signed-off-by: Harini Katakam --- Here is the v3 series but I have one concern. The recent change in spi-core to use wait_for_completion_timeout uses a timeout value calculated as follows: ms = xfer->len * 8 * 1000/xfer->speed_hz; wait_for_completion_timeout(msecs_to_jiffies(ms)); Firstly, the timeout value obtained from this is a too low. This timeout is typically used for an error conditions such as hardware hang etc. and using a value >1*HZ would be better. This driver used to use similar timeout and as I understand, other drivers also use similar values. Second, the xfer->speed_hz used here is not necessarily the actual speed set. The IP allows a limited set of divisors and the divisor is chosen in driver such that the actual speed is <= requested speed. Due to this the timeout value set here, sometimes falls short of the actual time required to complete transfer; this happens especially with very low frequencies. The difference in time higher than 20msecs. And for very small transfers, the timeout is set to 1 jiffy. Also, this is not considering any interrupt latencies or if the system is fully loaded. This might be cutting it too close, can the timeout value in core be increased? v3 changes: - Remove setup function. Make clock CPOL/CPHA setup a separate funtion and call this from prepare_transfer_hardware before enabling. - Remove clk_enable/disable in prepare/unprepare_tranfer_hardware. Clock enable/diable pairs will be retained as before only in probe/remove and suspend/resume. Use of runtime_pms for efficiency will be planned later. - Remove /bits/ in bindings for num-cs, use temporary u32 variable in driver. - Rename requested_bytes and remaining_bytes to tx_bytes/rx_bytes. - Remove unused macros. - Add is-decoded-cs property and add support in driver set_cs funtion. v2 changes: - Use xilinx compatible string too. - Changes read register and write register functions to static inline. - Removed unecessary dev_info and dev_dbg prints. - Return IRQ_HANDLED only when interrupt is handled. - Use a default num-cs value. - Do init_hardware before requesting irq. - Remove unecessary master_put() - Set master->max_speed_hz - Check for busy in cdns_setup(). Retained this function with this check as opposed to removing. The reason for this is clock configuration needs to be done for the first time before enable is done in prepare_hardware; prepare_hardware however, doesn't receive spi_device structure. - Implememnt transfer_one instead of transfer_one_message. Remove wait_for_completion as this is done by core. - Implement set_cs. - Clock enable/disable in prepare/unprepare respectively. - In suspend, remove reset of hardware; simply call unprepare_hardware. - In suspend/resume call master_suspend/resume respectively. - Check for irq<=0 in probe. - Remove MODULE_ALIAS. --- drivers/spi/Kconfig |7 + drivers/spi/Makefile |1 + drivers/spi/spi-cadence.c | 673 + 3 files changed, 681 insertions(+) create mode 100644 drivers/spi/spi-cadence.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index efe1960..b0f091b 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -148,6 +148,13 @@ config SPI_BUTTERFLY inexpensive battery powered microcontroller evaluation board. This same cable can be used to flash new firmware. +config SPI_CADENCE + tristate "Cadence SPI controller" + depends on SPI_MASTER + help + This selects the Cadence SPI controller master driver + used by Xilinx Zynq. + config SPI_CLPS711X tristate "CLPS711X host SPI controller" depends on ARCH_CLPS711X || COMPILE_TEST diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index bd79266..3e503d6 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_SPI_BFIN_V3) += spi-bfin-v3.o obj-$(CONFIG_SPI_BFIN_SPORT) += spi-bfin-sport.o obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o +obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c new file mode 100644 index 000..9a8289e --- /dev/null +++ b/drivers/spi/spi-cadence.c @@ -0,0 +1,673 @@ +/* + * Cadence SPI controller driver (master mode only) + * + * Copyright (C) 2008 - 2014 Xilinx, Inc. + * + * based on Blackfin On-Chip SPI Driver (spi_bfin5xx.c) + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at
Re: "54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI services pointer table" breaks boot on thinkpad t440s
On Thu, 10 Apr, at 12:43:43PM, Koen Kooi wrote: > Hi, > > After updating from 3.14-rc7 to a recent git the kernel fails to boot on my > thinkpad t440s and displays: > > Failed to get file info size > Failed to alloc highmem for files > > After a morning of running git bisect and rebooting, the bad commit seems to > be: > > 54b52d87268034859191d671505bb1cfce6bd74d - x86/efi: Build our own EFI > services pointer table Thanks for the report. Can you try this patch against Linus' tree? diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c index 1e6146137f8e..280165524ee4 100644 --- a/arch/x86/boot/compressed/eboot.c +++ b/arch/x86/boot/compressed/eboot.c @@ -112,7 +112,7 @@ __file_size64(void *__fh, efi_char16_t *filename_16, efi_file_info_t *info; efi_status_t status; efi_guid_t info_guid = EFI_FILE_INFO_ID; - u32 info_sz; + u64 info_sz; status = efi_early->call((unsigned long)fh->open, fh, , filename_16, EFI_FILE_MODE_READ, (u64)0); -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/27] ARM: EXYNOS:: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
On Thu, Apr 10 2014 at 11:56:33 am BST, Chanwoo Choi
wrote:
> On 04/10/2014 06:51 PM, Marc Zyngier wrote:
>> On Thu, Apr 10 2014 at 10:28:23 am BST, Chanwoo Choi
>> wrote:
>>> This patch decide proper lowpower mode of either a15 or a9 according to own
>>> ID
>>> from Main ID register.
>>>
>>> Signed-off-by: Chanwoo Choi
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> arch/arm/mach-exynos/hotplug.c | 13 ++---
>>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
>>> index 5eead53..36d3db6 100644
>>> --- a/arch/arm/mach-exynos/hotplug.c
>>> +++ b/arch/arm/mach-exynos/hotplug.c
>>> @@ -135,13 +135,20 @@ void __ref exynos_cpu_die(unsigned int cpu)
>>> int primary_part = 0;
>>>
>>> /*
>>> -* we're ready for shutdown now, so do it.
>>> -* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
>>> +* we're ready for shutdown now, so do it. Exynos4 is A9 based
>>> +* while Exynos5 is A15/Exynos7 is A7; check the CPU part
>>> * number by reading the Main ID register and then perform the
>>> * appropriate sequence for entering low power.
>>> */
>>> asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
>>
>> While you're touching that code, how about using:
>>
>> primary_part = read_cpuid(CPUID_ID);
>
> Or,
> I suggest read_cpuid_part_number() instead of assembler directly.
>
> primary_part = read_cpuid_part_number();
Yup, even better.
>>
>>> - if ((primary_part & 0xfff0) == 0xc0f0)
>>> +
>>> + /*
>>> +* Main ID register of Cortex series
>>> +* - Cortex-a7 : 0x410F_C07x
>>> +* - Cortex-a15 : 0x410F_C0Fx
>>> +*/
>>> + primary_part = primary_part & 0xfff0;
>>> + if (primary_part == 0xc0f0 || primary_part == 0xc070)
>>
>> ARM_CPU_PART_CORTEX_A15, ARM_CPU_PART_CORTEX_A7
>
> OK I'll use this defined constant as following:
>
> switch (primary_part)
> case ARM_CPU_PART_CORTEX_A7:
> case ARM_CPU_PART_CORTEX_A15:
> cpu_enter_lowpower_a15();
> break;
> default:
> cpu_enter_lowpower_a9();
> break;
> }
Looks good.
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8] DMA: Freescale: add suspend resume functions for DMA driver
On Thu, 2014-04-10 at 15:10 +0800, hongbo.zh...@freescale.com wrote:
> From: Hongbo Zhang
>
> This patch adds suspend resume functions for Freescale DMA driver.
> .prepare callback is used to stop further descriptors from being added into
> the
> pending queue, and also issue pending queues into execution if there is any.
> .suspend callback makes sure all the pending jobs are cleaned up and all the
> channels are idle, and save the mode registers.
> .resume callback re-initializes the channels by restore the mode registers.
Like we discussed with Vinod [1] the DMA controller drivers should go to
suspend after users and come back before them.
After you reconsider this point the patch logic might be modified a lot.
(Moreover, you abuse your own position to use only setters/getters to
access to the DMAc registers)
[1] http://www.spinics.net/lists/kernel/msg1650974.html
>
> Signed-off-by: Hongbo Zhang
> ---
> drivers/dma/fsldma.c | 100
> ++
> drivers/dma/fsldma.h | 16
> 2 files changed, 116 insertions(+)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index c9bf54a..d6da222 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -400,6 +400,14 @@ static dma_cookie_t fsl_dma_tx_submit(struct
> dma_async_tx_descriptor *tx)
>
> spin_lock_bh(>desc_lock);
>
> +#ifdef CONFIG_PM
> + if (unlikely(chan->pm_state != RUNNING)) {
> + chan_dbg(chan, "cannot submit due to suspend\n");
> + spin_unlock_bh(>desc_lock);
> + return -1;
> + }
> +#endif
> +
> /*
>* assign cookies to all of the software descriptors
>* that make up this transaction
> @@ -1311,6 +1319,9 @@ static int fsl_dma_chan_probe(struct fsldma_device
> *fdev,
> INIT_LIST_HEAD(>ld_running);
> INIT_LIST_HEAD(>ld_completed);
> chan->idle = true;
> +#ifdef CONFIG_PM
> + chan->pm_state = RUNNING;
> +#endif
>
> chan->common.device = >common;
> dma_cookie_init(>common);
> @@ -1450,6 +1461,92 @@ static int fsldma_of_remove(struct platform_device *op)
> return 0;
> }
>
> +#ifdef CONFIG_PM
> +static int fsldma_prepare(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct fsldma_device *fdev = platform_get_drvdata(pdev);
> + struct fsldma_chan *chan;
> + int i;
> +
> + for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
> + chan = fdev->chan[i];
> + if (!chan)
> + continue;
> +
> + spin_lock_bh(>desc_lock);
> + chan->pm_state = SUSPENDING;
> + if (!list_empty(>ld_pending))
> + fsl_chan_xfer_ld_queue(chan);
> + spin_unlock_bh(>desc_lock);
> + }
> +
> + return 0;
> +}
> +
> +static int fsldma_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct fsldma_device *fdev = platform_get_drvdata(pdev);
> + struct fsldma_chan *chan;
> + int i;
> +
> + for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
> + chan = fdev->chan[i];
> + if (!chan)
> + continue;
> +
> + spin_lock_bh(>desc_lock);
> + if (!chan->idle)
> + goto out;
> + chan->regs_save.mr = DMA_IN(chan, >regs->mr, 32);
> + chan->pm_state = SUSPENDED;
> + spin_unlock_bh(>desc_lock);
> + }
> + return 0;
> +
> +out:
> + for (; i >= 0; i--) {
> + chan = fdev->chan[i];
> + if (!chan)
> + continue;
> + chan->pm_state = RUNNING;
> + spin_unlock_bh(>desc_lock);
> + }
> + return -EBUSY;
> +}
> +
> +static int fsldma_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct fsldma_device *fdev = platform_get_drvdata(pdev);
> + struct fsldma_chan *chan;
> + u32 mode;
> + int i;
> +
> + for (i = 0; i < FSL_DMA_MAX_CHANS_PER_DEVICE; i++) {
> + chan = fdev->chan[i];
> + if (!chan)
> + continue;
> +
> + spin_lock_bh(>desc_lock);
> + mode = chan->regs_save.mr
> + & ~FSL_DMA_MR_CS & ~FSL_DMA_MR_CC & ~FSL_DMA_MR_CA;
> + DMA_OUT(chan, >regs->mr, mode, 32);
> + chan->pm_state = RUNNING;
> + spin_unlock_bh(>desc_lock);
> + }
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops fsldma_pm_ops = {
> + .prepare= fsldma_prepare,
> + .suspend= fsldma_suspend,
> + .resume = fsldma_resume,
> +};
> +#endif
> +
> static const struct of_device_id fsldma_of_ids[] = {
> { .compatible = "fsl,elo3-dma", },
> { .compatible = "fsl,eloplus-dma", },
> @@ -1462,6 +1559,9 @@ static struct platform_driver fsldma_of_driver = {
>
Re: [PATCH v2] bus: mvebu-mbus: Avoid setting an undefined window size
On Thu, Apr 10, 2014 at 08:53:46AM +0200, Thomas Petazzoni wrote: > Dear Jason Gunthorpe, > > On Wed, 9 Apr 2014 10:20:40 -0600, Jason Gunthorpe wrote: > > > > OK I just got it by adding two printk() in pci-mvebu.c. Both functions > > > mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change() > > > do pass a size which is in fact a mask (size - 1) and not the real size. > > > So the mbus is fed with an incorrect size which is off by one : > > > > Yes, that is right. I tested my patch here and didn't see any problem, > > but I realize now that the mbus code is bailing early due to this: > > > > kernel: mvebu_mbus: cannot add window '4:e8', conflicts with another window > > > > Which I've never got around to fixing.. (whole other story there) > > > > Your patch looks fine, and it obviously needs to be sequenced before > > mine. (Thomas/Jason C: how do you want to do this?) > > What I can propose is that I accumulate in a branch all the patches > needed to solve the various PCIe/Mbus problems we've identified: > > * Your patch adding warnings to the mvebu-mbus driver > * Willy's patch fixing the off-by-one on the size > * Neil's patch fixing the MSI teardown function > * My two patches fixing the rest of the MSI logic > * And patches to come for the link problem, and the cutting of >non-power-of-two BARs into power-of-two windows > > This way, everybody will be able to test than in his specific > hardware situations, the patches are solving all the problems. Then I > can take care of formally submitting those patches to the relevant > maintainers, of course keeping the authorship as appropriate. > > How does that sound? Great! Please do. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
